Re: Rules regarding whitespace inside .spec files

[Michael Schwendt]

On Wed, 13 Jan 2016 06:18:31 -, Andrew Toskin wrote:

> > error: line 102: Unknown tag: Source1: firefox-45.0a2.tar.bz2  
> 
> ...and removing the leading whitespace removes the error.

If you test with elemental tags, such as Name, Version and Release, you
can observe that they are not recognised, if there's leading whitespace.

However, trailing whitespace before and after the colon is accepted:

  Name   :   something

That's in the documentation somewhere. Maximum RPM community edition probably.

I think it has been like that always. Syntax-highlighting performed inside
Emacs also doesn't recognize tags with leading whitespace.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Golang 1.6

[Florian Weimer]

On 01/13/2016 12:56 AM, Peter Robinson wrote:
> On Tue, Jan 12, 2016 at 5:30 PM, Matthew Miller
>  wrote:
>> On Tue, Jan 12, 2016 at 01:31:30AM +, Peter Robinson wrote:
>>> Will there be an ABI guaranteed beta or RC so that this can be
>>> complete before branching as per the schedule [1]? All major rebases
>>> should be complete prior to branching.
>>> [1] https://fedoraproject.org/wiki/Releases/24/Schedule
>>
>> Since everything is statically linked, the ABI isn't really a factor.
> 
> It is if it changes between say beta and GA because it'll still all
> then need another rebuild, hence the question.

Go library packages do not actually contain compiled code, right?  So
the ABI really should not matter, it's like Perl in this regard.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Kari Koskinen]

Apologies for spamming this thread with multiple copies. I was having some
problems with Claws Mail SMTP settings.

2016-01-13 11:16 GMT+02:00 Juan Orti Alcaine :

> 2016-01-13 2:13 GMT+01:00 Jonathan Wakely :
> > On 12/01/16 22:59 +, Jonathan Wakely wrote:
> >>
> >> The old version could be added as keepassx1, or just via COPR, for
> >> those who still want it.
> >
> >
> > I've created a COPR with keepassx 0.4.4 builds for F22 and F23:
> > https://copr.fedoraproject.org/coprs/jwakely/keepassx1/build/153188/
>
> Could you please rename the package to keepassx1? I wish them to be
> installed in parallel.
>
> Thank you.
>
> --
> Juan Orti
> https://apuntesderootblog.wordpress.com/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
Kari Koskinen
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rawhide report: 20160113 changes

[Fedora Rawhide Report]

Compose started at Wed Jan 13 05:15:02 UTC 2016
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[OpenColorIO]
OpenColorIO-tools-1.0.9-8.fc23.i686 requires libOpenImageIO.so.1.5
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[eclipse-jbosstools]
eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires 
osgi(org.eclipse.tm.terminal)
[fawkes]
fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so
fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10
[gcc-python-plugin]
gcc-python2-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python2-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-debug-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
gcc-python3-plugin-0.14-8.fc24.i686 requires gcc = 0:5.3.1-2.fc24
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-klash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
[golang-github-kraman-libcontainer]
golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch 
requires golang(github.com/docker/docker/pkg/netlink)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/info/v1)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/schema)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/registry)
golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires 
golang(github.com/coreos/fleet/pkg)

Re: Attempting to contact unresponsive maintainer - jklimes

[Vít Ondruch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dne 6.1.2016 v 01:07 Kevin Fenzi napsal(a):
>
> If you have a way to contact this maintainer, please let them
> know that we'd appreciate knowing what to do with their packages.
> Thanks!
>
> * jklimes - former email: jkli...@redhat.com
>
>


Not sure what will be future of the packages, but in any case, Jiří has
updated his email in FAS.


Vít
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWlgmNAAoJEAzgnueZF7h8fa8QAIVbJYefMYlUWuXcwyxMqIOz
7/5GNHbjbhCv6IlDvHL5qL8I9sJTbqmZGRy3Oa5nQM0s7jJw8MBjBCZyCHMyX6Rl
gseAZy0gDwGvxK3s6WCDP7sWpctnAUmYhuR9UeRY6qfmX6hT1S+Mk3BeXw7jJhQu
fMANtWmo6JC52YgQAwIHmHScj6l+H/15ZVgTjwhAFQYQHVHHX+fsWmVAuVgnt5mQ
Bt7SRa8BlnzAimWOpj8hEhd8wr9ar7Vqqa+v32kGzGlKjtRLRz83W5gZXI7sHPAx
cii9UO4rXKNGcT0ZwkTL+QDxLPacaLwmakbA0Atv9LCJ+EPRnIdr+ZVzxr5t0BtB
q52XgZAX94kR+DZYgyxbFLuMko+Y2RY/xoF4vrg4KXm9h9TXEbHYaF+n6wy5Y/nh
wnVvl+jyeh3kPzTwtMaZNybokHnh3z+rEpeMU1x+1rQ+FPKKouIgwh7HtVMf3hGH
Q0zTFtlQWSxIG4Wv7N8O3wKvF8NjYLAIfhqRUe6i781bLsj+oPoLZ9UO16K/nsGr
YlIQtj/0QIkBIoYueQuqkeHWfjGLLJiZ9LORVEA4By9rnhDKSlCwhW3mAMs4iJI/
4JOAvRJj/shiOFqo0PTuQd/uucPfz7ttJWxOkUr5yaIKZSc39cbg90keGpXLk3d5
Bi2TOzGgCShC2f/Cblkl
=LTwG
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Juan Orti Alcaine]

2016-01-13 2:13 GMT+01:00 Jonathan Wakely :
> On 12/01/16 22:59 +, Jonathan Wakely wrote:
>>
>> The old version could be added as keepassx1, or just via COPR, for
>> those who still want it.
>
>
> I've created a COPR with keepassx 0.4.4 builds for F22 and F23:
> https://copr.fedoraproject.org/coprs/jwakely/keepassx1/build/153188/

Could you please rename the package to keepassx1? I wish them to be
installed in parallel.

Thank you.

-- 
Juan Orti
https://apuntesderootblog.wordpress.com/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Jonathan Wakely]

On 13/01/16 10:16 +0100, Juan Orti Alcaine wrote:

Could you please rename the package to keepassx1? I wish them to be
installed in parallel.


It's not as simple as renaming the package.

It would mean renaming the binary and everything under /usr/share,
which I don't have time to do, sorry.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Kari Koskinen]

2016-01-13 0:59 GMT+02:00 Jonathan Wakely :

> So how should the maintainer proceed?
>
> The policy was violated, but it's done now.  F23 has already been
> updated, F22 has an update in testing now (with negative karma).
>
> The old version could be added as keepassx1, or just via COPR, for
> those who still want it.
>

 I don't see need for Keepass 0.4 package for Fedora 23. A COPR for
those who need it for compatibility would be enough at this point.

Since some people will already have the new version from F22's
> updates-testing repo maybe it's too late for F22 as well and it should
> be pushed to stable. In that case keepassx1 would be useful for F22
> too.


It is not too late. The point of updates testing is to catch problems
before they land in stable. Dealing with occasional downgrade is part
of running up dates testing. At this point it seems clear that updating
KeepasX to version 2 on Fedora 22 would be undesirable.

Though, Fedora 22 keepassx2 subpackage would be nice for those users
who need to synchronize the database between Fedora versions. It is
still easier to find packages in official repositories than COPR for
non-technical users.

-- 
Kari Koskinen
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Announce of package to mark as Orphan – repoview – rpmdepsize – snake - revisor

[Reindl Harald]

Am 13.01.2016 um 01:25 schrieb Nico Kadel-Garcia:

On Fri, Jan 8, 2016 at 10:37 AM, Sérgio Basto  wrote:

On Sex, 2016-01-08 at 08:54 -0500, Jaroslav Mracek wrote:

Hi everybody,

I would like to set following packages as Orphan due to that upstream
is dead or  maintainers do not respond:

repoview


have we a replace for repoview ?


Does anyone actually like it? I find it to be confusing eye candy,
unnecessary and interfering with basic content reviews, compared to a
flat filename based file list. I deliberately exclude "repoview" from
all repository mirrors


yes, for all internal repos as well as for the cache repo on the 
adminserver which deploys updates from dnf-cache to all other servers




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: keepassx 2.0?

[Jonathan Wakely]

On 13/01/16 11:07 +0200, Kari Koskinen wrote:

I don't see need for Keepass 0.4 package for Fedora 23. A COPR for
those who need it for compatibility would be enough at this point.


Agreed, that can be found here:
https://copr.fedoraproject.org/coprs/jwakely/keepassx1/


Though, Fedora 22 keepassx2 subpackage would be nice for those users
who need to synchronize the database between Fedora versions. It is
still easier to find packages in official repositories than COPR for
non-technical users.


I'll leave that to Francesco to do if he still wants v2 to be
available in F22.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 13.01.2016 um 14:01 schrieb Florian Festi:

On 01/11/2016 09:06 PM, Richard W.M. Jones wrote:

On Mon, Jan 11, 2016 at 03:46:27PM +0100, Jan Kurik wrote:

= Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
https://fedoraproject.org/wiki/Changes/NewRpmDBFormat


Details of the format?

What forward and backward compatibility guarantees are there?


RPM will keep support for BDB for now. But to get rid of the dependency
it will be dropped at some point in the future. So it will stay backward
compatible.

The file format is clearly not forward compatible (although you will be
for now be able to still use the old format)


"clearly not forward compatible"?

there needs to be a migration path to get a existing bdb rpmdb converted 
our you will blow with "will be dropped at some point in the future" a 
ton of users and admins to hell


we run 30 machines originally installed with Fedora 9 and updated until 
now to F23 which surived UsrMove, migration to grub2 including make 
space for grub2 on the bootdrive with parted and the switch to systemd 
without install them from scratch


so there is no justification to declare one need to install from scratch 
just because rpm which works for many years fine changes it's storage 
format




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Richard Hughes]

On 13 January 2016 at 13:13, Reindl Harald  wrote:
> so there is no justification to declare one need to install from scratch
> just because rpm which works for many years fine changes it's storage format

I don't think anyone said there was a need to reinstall from scratch.

Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Reindl Harald]

Am 13.01.2016 um 14:30 schrieb Richard Hughes:

On 13 January 2016 at 13:13, Reindl Harald  wrote:

so there is no justification to declare one need to install from scratch
just because rpm which works for many years fine changes it's storage format


I don't think anyone said there was a need to reinstall from scratch


so how do you translate "clearly not forward compatible"?



signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Richard W.M. Jones]

On Wed, Jan 13, 2016 at 02:01:23PM +0100, Florian Festi wrote:
> On 01/11/2016 09:06 PM, Richard W.M. Jones wrote:
> > On Mon, Jan 11, 2016 at 03:46:27PM +0100, Jan Kurik wrote:
> >> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
> >> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> > 
> > Details of the format?
> > 
> > What forward and backward compatibility guarantees are there?
> 
> RPM will keep support for BDB for now. But to get rid of the dependency
> it will be dropped at some point in the future. So it will stay backward
> compatible.

What I meant here is what about forward and backward compatibility of
the new format.  Obviously I understand why BDB is being dropped and
that the new format cannot possibly be compatible with BDB.  It's
accepted that there will be a break in Fedora 24 for reasons that are
outside our control.

Say, for example, that Fedora 24 moves to the new format.  Will Fedora 34
be able to read Fedora 24 RPM databases?  How about Fedora 24 being
able to read Fedora 34 RPM databases?

> > Currently we use the (BDB-specific obviously) db_dump tool for this
> > purpose.  Other distros such as Debian as much simpler in this regard
> > since they expose the package data as plain text files.
> > 
> > https://github.com/libguestfs/libguestfs/blob/master/src/inspect-apps.c
> 
> I would advice to change these over to using librpm or one of the rpm
> cli tools. If there are any tools missing, please let me know and we
> will try to come up with them.
>
> If possible the rpm installation of the system examined should be used.

This isn't possible - it's insecure to rely on running guest code
(and not even possible in some situations).

Carrying around old versions of librpm on the host isn't ideal either.

> If this cannot be done you might need a new version of rpm on the host
> system.

Are you implying that all Fedora librpm will be backwards compatible?
(not caring about Fedora < 24 obviously)

Another thing to think about is endianness and word size, since with
BDB we can examine, say, an i686 guest from an ppc64 host (and people
even do this).

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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I enable C++11 to build a package?

[Michael Schwendt]

On Wed, 13 Jan 2016 12:03:06 +, Ankur Sinha wrote:

> Hiya,
> 
> The subtitleeditor package seems to require C++11 enabled to build.
> Here's an error in the mock log[1] for the latest failed build[2] for
> example:
> 
> /usr/include/glibmm-2.4/glibmm/error.h:41:20: note: C++11 'noexcept'
> only available with -std=c++11 or -std=gnu++11
> 
> Can I enable C++11 to get it to build correctly?

Yes.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Can I enable C++11 to build a package?

[Ankur Sinha]

Hiya,

The subtitleeditor package seems to require C++11 enabled to build.
Here's an error in the mock log[1] for the latest failed build[2] for
example:

/usr/include/glibmm-2.4/glibmm/error.h:41:20: note: C++11 'noexcept'
only available with -std=c++11 or -std=gnu++11

Can I enable C++11 to get it to build correctly? I haven't found a
policy that forbids or permits it.

[1] https://kojipkgs.fedoraproject.org//work/tasks/2903/12492903/build.log
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=12492903

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD"

http://fedoraproject.org/wiki/User:Ankursinha



signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python-rpm-macros - splitting out the macros

[Matej Stuchlik]

- Original Message -
> From: "Orion Poplawski" 
> To: python-de...@lists.fedoraproject.org, python-ow...@fedoraproject.org, 
> python3-ow...@fedoraproject.org,
> "Development discussions related to Fedora" 
> Sent: Tuesday, January 12, 2016 11:42:13 PM
> Subject: python-rpm-macros - splitting out the macros
> 
> On 01/08/2016 11:27 AM, bugzi...@redhat.com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294904
> > 
> > Antonio Trande  changed:
> > 
> >What|Removed |Added
> > 
> >   Flags|fedora-review?  |fedora-review+
> > 
> > 
> > 
> > --- Comment #12 from Antonio Trande  ---
> > Package approved.
> > 
> 
> I still have heard nothing from the main python maintainers, and I'd like to
> get some kind of an ack for the following plan:
> 
> - Dropping the python3-pkgversion-macros package, replaced with
> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
> and epel-rpm-macros (in EPEL).
> 
> - Dropping the python-macros sub-package from python, replace by Requires:
> python-rpm-macros from above package.  python3 requires this as well.
> 
> - Dropping macros.python2 from python-devel, replaced with Requires:
> python2-rpm-macros from above package.
> 
> - Dropping macros.python3 from python3-devel, replaced with Requires:
> python3-rpm-macros from above package.
> 
> This achieves the goal of decoupling modifying/updating the python macros
> from
> updating the main python package, which has become a serious hindrance to
> developing new python rpm macros.
> 
> The reviewed package contains the Fedora macros.  macros will be changed on
> the EPEL branches.

Sorry for the late response -- extended vacation. :)

We're 100% behind this, it's been something that's been on our todo list for a
while now. :)

Matt

> I've requested a side tag to do the build in here -
> https://fedorahosted.org/rel-eng/ticket/6331
> 
> as I think the timing is tricky and the possibility of breaking the buildroot
> moderate.
> 
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
> ___
> python-devel mailing list
> python-de...@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/python-de...@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 05:26 PM, Kalev Lember wrote:
> On 01/11/2016 03:46 PM, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>
>> Change owner(s):
>> * Florian Festi < ffesti AT redhat DOT com >
>>
>>
>> Change format of the RPM Database from Berkeley DB to RPM's own format.
>>
>> == Detailed Description ==
>> The current implementation of the RPM Database is based on Berkeley
>> DB. There are doubts about the its future and level of maintenance. In
>> addition rpm's use of the database has multiple issues on its own. As
>> a result RPM upstream is working to replace the database format with a
>> new implementation.
> 
> Is the new database going to be able to support yumdb use cases as well?
> Might be a good time to get rid of separate rpmdb and yumdb and merge
> them together.

No, this is a pretty straight forward replacement of the backend. While
the whole area has still a lot the be desired this change only replaces
the BDB. No other fancy changes.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/13/2016 02:36 PM, Reindl Harald wrote:
> 
> 
> Am 13.01.2016 um 14:30 schrieb Richard Hughes:
>> On 13 January 2016 at 13:13, Reindl Harald 
>> wrote:
>>> so there is no justification to declare one need to install from scratch
>>> just because rpm which works for many years fine changes it's storage
>>> format
>>
>> I don't think anyone said there was a need to reinstall from scratch
> 
> so how do you translate "clearly not forward compatible"?

"forward compatible" means the old version of a program being able to
read/process newer version data.

The current rpm versions will not be able to read the new database format.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I enable C++11 to build a package?

[Ankur Sinha]

On Wed, 2016-01-13 at 13:08 +0100, Michael Schwendt wrote:
> Yes.

Thanks Michael. Follow up question:

What is the cleanest way of doing this - replacing -ansi with
-std=c++11 in %{_optflags} while using the %configure macro?
-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD"

http://fedoraproject.org/wiki/User:Ankursinha



signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 03:57 PM, Dan Horák wrote:
> On Mon, 11 Jan 2016 15:46:27 +0100
> Jan Kurik  wrote:
> 
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>
>> Change owner(s):
>> * Florian Festi < ffesti AT redhat DOT com >
>>
>>
>> Change format of the RPM Database from Berkeley DB to RPM's own
>> format.
>>
>> == Detailed Description ==
>> The current implementation of the RPM Database is based on Berkeley
>> DB. There are doubts about the its future and level of maintenance. In
>> addition rpm's use of the database has multiple issues on its own. As
>> a result RPM upstream is working to replace the database format with a
>> new implementation.
> 
> does it mean rpm is changing from Berkeley DB library to another
> library or to a completely new implementation of a database engine?

We change to our own format. One of the problem is the bit special
requirements of rpm where you want to have non privileged readers that
must not have any write access - which is required for most databases
for locking.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 09:06 PM, Richard W.M. Jones wrote:
> On Mon, Jan 11, 2016 at 03:46:27PM +0100, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> 
> Details of the format?
> 
> What forward and backward compatibility guarantees are there?

RPM will keep support for BDB for now. But to get rid of the dependency
it will be dropped at some point in the future. So it will stay backward
compatible.

The file format is clearly not forward compatible (although you will be
for now be able to still use the old format).

> libguestfs reads the rpmdb of guests (of any version, new or old) in
> order to get the list of packages installed in a guest.  Remember that
> the host and guest may be very different versions, eg. a RHEL 9 host
> accessing a Fedora 24 guest.  Or vice versa.

> Currently we use the (BDB-specific obviously) db_dump tool for this
> purpose.  Other distros such as Debian as much simpler in this regard
> since they expose the package data as plain text files.
> 
> https://github.com/libguestfs/libguestfs/blob/master/src/inspect-apps.c

I would advice to change these over to using librpm or one of the rpm
cli tools. If there are any tools missing, please let me know and we
will try to come up with them.

If possible the rpm installation of the system examined should be used.
If this cannot be done you might need a new version of rpm on the host
system.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

yarock needs maintainers

[mastaiza]

Hi
take this package please
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Heads up: glew soname bump in F24

[Adam Jackson]

I'm planning to bump glew to 1.13.0 in the next day or so. This will
require rebuilding roughly 43 dependent packages (see list below). I'm
running through a mass mockchain of that locally, I'll kick off
rebuilds in koji once that's complete and assuming things mostly
rebuild successfully.

The following source packages will be affected:

amanith
avogadro
blender
bzflag
calligra
cegui
cegui06
compat-SFML16
dreamchess
enblend
FlightGear-Atlas
gambas3
gimp-normalmap
glew
gource
hugin
kicad
libgltf
libprojectM
libreoffice
linphone
logstalgia
maniadrive
megaglest
mesa-demos
meshlab
OpenColorIO
opencsg
OpenImageIO
openmsx
openscad
pymol
root
rss-glx
scorched3d
sdljava
spring
supertux
toped
warzone2100
widelands
wt
wxmacmolplt

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Orphaned Packages in rawhide (2016-01-13)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Package (co)maintainers Status Change 
=
cherrytreeorphan, ohaessler, zqfan  5 weeks ago   
flasm orphan10 weeks ago  
ipcalculator  orphan, jhrozek   9 weeks ago   
radiusclient-ng   orphan, nmav, swilkerson  1 weeks ago   
shorewall orphan, digimer, jgu, orion   0 weeks ago   
tailororphan, sharkcz   2 weeks ago   
tmw   orphan, mgieseki  0 weeks ago   
tmw-music orphan, mgieseki  0 weeks ago   
yarockorphan, jam3s 6 weeks ago   

The following packages require above mentioned packages:
Depending on: radiusclient-ng (10), status change: 2016-01-05 (1 weeks ago)
asterisk (maintained by: jsmith, itamarjp, lbazan, leifmadsen, russellb)
asterisk-13.3.2-1.fc23.2.src requires radiusclient-ng-devel = 
0.5.6-14.fc23
asterisk-radius-13.3.2-1.fc23.2.i686 requires 
libradiusclient-ng.so.2

nagios-plugins (maintained by: nb, kmf, mhayden, ondrejj, swilkerson)
nagios-plugins-2.0.3-3.fc24.src requires radiusclient-ng-devel 
= 0.5.6-14.fc23
nagios-plugins-radius-2.0.3-3.fc24.i686 requires 
libradiusclient-ng.so.2

opensips (maintained by: ivaxer, peter)
opensips-1.10.5-8.fc24.src requires radiusclient-ng-devel = 
0.5.6-14.fc23
opensips-aaa_radius-1.10.5-8.fc24.i686 requires 
libradiusclient-ng.so.2

asterisk-gui (maintained by: fantom)
asterisk-gui-2.0-11.20120518svn5220.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2

asterisk-sounds-core (maintained by: jsmith, itamarjp)
asterisk-sounds-core-en-1.4.26-2.fc23.noarch requires asterisk 
= 13.3.2-1.fc23.2
asterisk-sounds-core-en-alaw-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-g722-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-g729-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-gsm-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-siren14-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-siren7-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-sln16-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-ulaw-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en-wav-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-alaw-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-g722-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-g729-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-gsm-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-siren14-1.4.26-2.fc23.noarch 
requires asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-siren7-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-sln16-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-ulaw-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_AU-wav-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_GB-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_GB-alaw-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_GB-g722-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_GB-g729-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2
asterisk-sounds-core-en_GB-gsm-1.4.26-2.fc23.noarch requires 
asterisk = 13.3.2-1.fc23.2

Updated license for python-coverage

[Orion Poplawski]

License for python-coverage changed from BSD and (MIT or GPLv2) to ASL 2.0.

Not sure when this change actually occurred (I'm not the maintainer), but at
least with version 4.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Updated license for python-coverage

[Orion Poplawski]

On 01/13/2016 11:58 AM, Orion Poplawski wrote:
> License for python-coverage changed from BSD and (MIT or GPLv2) to ASL 2.0.
> 
> Not sure when this change actually occurred (I'm not the maintainer), but at
> least with version 4.
> 
> 

And updated again to:

ASL 2.0 and MIT and (MIT or GPL)

due to bundled jquery libraries.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2016-01-14 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-01-14 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2016-01-14 09:00 Thu US/Pacific PST
2016-01-14 12:00 Thu US/Eastern EST
2016-01-14 17:00 Thu UTC <-
2016-01-14 17:00 Thu Europe/London <-
2016-01-14 18:00 Thu Europe/Paris   CET
2016-01-14 18:00 Thu Europe/Berlin  CET
2016-01-14 22:30 Thu Asia/Calcutta  IST
--new day--
2016-01-15 01:00 Fri Asia/Singapore SGT
2016-01-15 01:00 Fri Asia/Hong_Kong HKT
2016-01-15 02:00 Fri Asia/Tokyo JST
2016-01-15 03:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/13

= Followups =

#topic #558 Application/Library distinction and package splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558

#topic #566 RPM file triggers
.fpc 566
https://fedorahosted.org/fpc/ticket/566

#topic #567 Packaging Python 3 applications and modules for EPEL 7+
.fpc 567
https://fedorahosted.org/fpc/ticket/567

= New business =

#topic #587 Node.js Guideline ExclusiveArch incorrect
.fpc 587
https://fedorahosted.org/fpc/ticket/587

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://fedorahosted.org/fpc/report/13

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Packaging of PlayOnLinux

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 12, 2016 at 08:59:09AM +0100, Jiří Konečný wrote:
> On Sat, 2016-01-09 at 23:36 -0600, Bruno Wolff III wrote:
> > On Mon, Jan 04, 2016 at 10:33:01 +0100,
> >   Jiří Konečný  wrote:
> > > On Fri, 2015-12-11 at 10:44 +0100, Jiří Konečný wrote:
> > > > Hello all,
> > > > 
> > > > it was some time but I finally made it to the Fedora review 
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1290513
> > > > 
> > > > This is my first package so I need a sponsor. Could anyone please
> > > > look
> > > > on this. I will gladly take any help you can give me.
> > 
> > Hans was looking to do a review swap for a shooter game not too long
> > ago.
> 
> Thank you for telling me this but I don't thing that I as a new
> packager have enough experience to do review of another package.
> 
> I'm going to look on his package if I find there something wrong but
> I'm mostly learning how to create package properly now.

I'd be happy to sponsor you. I'll follow up with some details in
the review ticket.

Reviewing other people's packages is the best way to learn. You'll
probably get some things wrong in the beginning, everybody does. But
then the submitter of the package respond, and both parties learn
something in the process. So doing a few reviews of other packages
is a requirement for new packagers.

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I enable C++11 to build a package?

[Jonathan Wakely]

On 13/01/16 15:36 +0100, Kalev Lember wrote:

Also, GCC 6 that is going to land in F24 in 2 or 3 weeks is going to
switch the global default to -std=gnu++14 or -std=c++14, I've forgotten
which.


gnu++14

Currently the default is gnu++98, so we're only changing 98 -> 14, not
c++ -> gnu++ (i.e. GNU extensions are still enabled by default).
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Debugging practices and hardened packages

[Roman Tsisyk]

Hi,

Fedora enables hardened builds [1] by default.
This implies  -fomit-frame-pointer -fstack-protector and -fPIE.

[1]: https://fedoraproject.org/wiki/Packaging:Guidelines#PIE

How it is supposed to be debugged by upstream developers?

It would be nice to have **at least** a proper backtrace for crashed daemons.
Even better to have a) coredump b) binary c) debug symbols for this version of 
binary.
Otherwise I can't suggest to use such packages for the end users.

Does ABRT [2] actually work? Who have experience with it on production?
Is there somewhere a guide for sysadmins about a preferred way to produce 
meaningful
bug reports with stripped hardened binaries?

[2]: https://fedoraproject.org/wiki/Features/ABRT

Thanks!

-- 
WBR,
  Roman Tsisyk 
  http://tarantool.org/ - an efficient in-memory data store and a Lua 
application server
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Petr Spacek]

On 13.1.2016 13:48, Florian Festi wrote:
> On 01/11/2016 03:57 PM, Dan Horák wrote:
>> On Mon, 11 Jan 2016 15:46:27 +0100
>> Jan Kurik  wrote:
>>
>>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
>>>
>>> Change owner(s):
>>> * Florian Festi < ffesti AT redhat DOT com >
>>>
>>>
>>> Change format of the RPM Database from Berkeley DB to RPM's own
>>> format.
>>>
>>> == Detailed Description ==
>>> The current implementation of the RPM Database is based on Berkeley
>>> DB. There are doubts about the its future and level of maintenance. In
>>> addition rpm's use of the database has multiple issues on its own. As
>>> a result RPM upstream is working to replace the database format with a
>>> new implementation.
>>
>> does it mean rpm is changing from Berkeley DB library to another
>> library or to a completely new implementation of a database engine?
> 
> We change to our own format. One of the problem is the bit special
> requirements of rpm where you want to have non privileged readers that
> must not have any write access - which is required for most databases
> for locking.

I'm curious! Would it be possible to elaborate on reasons why no existing DB
was good enough for RPM?

https://bugzilla.redhat.com/show_bug.cgi?id=1086784#c8 indicates that this
locking requirement is not a problem/obstacle for using LMDB.

Thank you for your time!

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging practices and hardened packages

[Florian Weimer]

On 01/14/2016 07:37 AM, Roman Tsisyk wrote:
> Hi,
> 
> Fedora enables hardened builds [1] by default.
> This implies  -fomit-frame-pointer -fstack-protector and -fPIE.
> 
> [1]: https://fedoraproject.org/wiki/Packaging:Guidelines#PIE
> 
> How it is supposed to be debugged by upstream developers?

With GDB?

Fedora provides debugging information for most of its packages, and you
can extract them from RPMs and specify “set debug-file-directory” in GDB
to use them, even without installing them.

Note that Fedora also compiles with -fexceptions, which provides
unwinding information despite missing frame pointers.  In general, the
debugging experience is *much* better than on other systems.

> It would be nice to have **at least** a proper backtrace for crashed daemons.
> Even better to have a) coredump b) binary c) debug symbols for this version 
> of binary.
> Otherwise I can't suggest to use such packages for the end users.

coredumpctl works well enough for me.

Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Rules regarding whitespace inside .spec files

[Jonathan Wakely]

On 13/01/16 23:19 -, Andrew Toskin wrote:

Is there a way to convert tags like "BuildRequires:" into %macros so that they 
*can* be indented?


That would be highly unconventional, and so unlikely to make the .spec
file easier to follow.

If it's really a problem you could use comments:

%if %{some_condition}
BuildRequires: foo
BuildRequires: bar
BuildRequires: baz
%endif # some_condition
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

ELF arch question

[Orion Poplawski]

rpm flags shared libraries of ELFCLASS64 with '(64bit)' on all architectures
except Alpha (which thankfully we don't support).  My question is, are
ELFCLASS64 libraries always installed in /usr/lib64 on all Fedora platforms,
or am I going to have to read the elf class of the file to be sure?


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Rules regarding whitespace inside .spec files

[Jason L Tibbitts III]

> "AT" == Andrew Toskin  writes:

AT> Is there a way to convert tags like "BuildRequires:" into %macros so
AT> that they *can* be indented?

Sure there is, but please don't actually try to do that in Fedora
packages.  There are cases where such things might be easier to read,
but in general I don't think that would be the case.

A better approach if you care about readability is to stop trying to use
one spec across everything.  You don't need any
%if clauses at all if you do that.

Or you could locate the situations which cause large numbers of packages
to require %if clauses in order to keep spec compatibility across
multiple releases.  Make lists and bring them forward for discussion.
It might be possible to do something about it.

 - J<
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Rules regarding whitespace inside .spec files

[Andrew Toskin]

That's unfortunate. The spec file I've forked has certain tags *inside* of %if 
blocks. Things like this:

%if %{?system_cairo}
BuildRequires:  pkgconfig(cairo) >= %{cairo_version}
%endif

In some of the longer blocks, no indentation makes it much harder to tell where 
the %if begins and ends.

Is there a way to convert tags like "BuildRequires:" into %macros so that they 
*can* be indented?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python-rpm-macros - splitting out the macros

[Orion Poplawski]

On 01/13/2016 09:44 AM, Orion Poplawski wrote:
> On 01/12/2016 03:42 PM, Orion Poplawski wrote:
>> - Dropping the python3-pkgversion-macros package, replaced with
>> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
>> and epel-rpm-macros (in EPEL).
> 
> Rawhide now has redhat-rpm-config requiring python-srpm-macros.  So we now
> have %python3_pkgversion in rawhide.
> 
>> - Dropping the python-macros sub-package from python, replace by Requires:
>> python-rpm-macros from above package.  python3 requires this as well.
> 
> python-devel and python3-devel will now be bringing in python-rpm-macros from
> the new package.
> 
>> - Dropping macros.python2 from python-devel, replaced with Requires:
>> python2-rpm-macros from above package.
>>
>> - Dropping macros.python3 from python3-devel, replaced with Requires:
>> python3-rpm-macros from above package.
> 
> I'm working on this and testing changes in a copr before building for rawhide.

This is now complete as well in rawhide.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Updating hdf5 and netcdf in rawhide tomorrow

[Orion Poplawski]

I'll be updating hdf5 to 1.8.16 and netcdf to 4.4.0 in rawhide tomorrow.
These include soname bumps and I'll be rebuilding all deps.

bes-3.14.0-8.fc24.src.rpm
CBFlib-0.9.5.14-1.fc24.src.rpm
cgnslib-3.2.1-5.fc23.src.rpm
dx-4.4.4-36.fc23.src.rpm
engrid-2.0.0-0.8.gitbaef0ce.fc24.src.rpm
Field3D-1.6.1-8.fc24.src.rpm
gdal-2.0.1-3.fc24.src.rpm
gdl-0.9.5-10.fc24.src.rpm
GMT-5.2.1-1.fc24.src.rpm
gpaw-0.11.0.13004-16.fc24.src.rpm
grace-5.1.25-4.fc24.src.rpm
grads-2.0.2-14.fc24.src.rpm
grib_api-1.14.4-1.fc24.src.rpm
gtatool-2.1.0-9.fc24.src.rpm
h5py-2.5.0-5.fc24.src.rpm
hdf5-1.8.15-8.patch1.fc24.src.rpm
InsightToolkit-4.8.2-2.fc24.src.rpm
jhdf5-2.11.0-4.fc24.src.rpm
kst-2.0.8-4.fc23.src.rpm
libASL-0.1.6-1.fc24.src.rpm
libminc-2.3.00-2.fc24.src.rpm
mathgl-2.3.3-7.fc24.src.rpm
matio-1.5.2-7.fc23.src.rpm
med-3.0.8-4.fc23.src.rpm
moose-3.0.2-0.4.fc24.beta.2.src.rpm
mrpt-1.3.2-1.fc24.src.rpm
ncl-6.3.0-6.fc24.src.rpm
nco-4.5.3-1.fc24.src.rpm
ncview-2.1.5-2.fc23.src.rpm
netcdf-4.3.3.1-7.fc24.src.rpm
netcdf4-python-1.1.6-3.fc24.src.rpm
netcdf-cxx-4.2-13.fc24.src.rpm
netcdf-cxx4-4.2.1-10.fc24.src.rpm
netcdf-fortran-4.4.2-3.fc24.src.rpm
netcdf-perl-1.2.4-20.fc23.src.rpm
octave-4.0.0-8.fc24.src.rpm
octave-communications-1.2.1-1.fc23.src.rpm
octave-netcdf-1.0.7-1.fc23.src.rpm
octave-octcdf-1.1.8-1.fc23.src.rpm
OpenImageIO-1.6.8-2.fc24.src.rpm
paraview-5.0.0-0.4.RC3.fc24.src.rpm
petpvc-0.0.0-0.1.git8b28893.fc24.src.rpm
python-tables-3.2.2-2.fc24.src.rpm
R-Rsolid-0.9.31-16.fc23.src.rpm
scilab-6.0.0-0.1.alpha2.fc24.src.rpm
shogun-4.0.1-0.6.git20151219.af8c1df.fc24.src.rpm
vigra-1.10.0-15.fc24.src.rpm
vips-8.2.1-1.fc24.src.rpm
ViTables-2.1-12.fc23.src.rpm
vtk-6.3.0-2.fc24.src.rpm
wgrib2-2.0.1-4.fc23.src.rpm

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Issue with undefined reference with assembler in rr

[Dave Johansen]

I was working on packaging rr [1] and one of the tests [2] fails to build
when optimizations are turned on. I've reduced it to the following and
still been able to reproduce the issue:

static const float xmm0 = 10;

int main() {
  __asm__ __volatile__(
#if __i386__
  "movss xmm0, %xmm0\n\t"
#elif __x86_64__
  "movss xmm0(%rip), %xmm0\n\t"
#else
#error unexpected architecture
#endif
  );

  return 0;
}

Here's the output on F23 x86_64:
$ gcc fxregs.c -O0
$ gcc fxregs.c -O1
/tmp/cccdze3O.o: In function `main':
fxregs.c:(.text+0x4): undefined reference to `xmm0'
collect2: error: ld returned 1 exit status

Is this a gcc bug or is there something that I need to do in the build to
get the tests to build without error?

Thanks,
Dave

[1]: https://github.com/mozilla/rr
[2]:
https://github.com/mozilla/rr/blob/9a532fd786f6378d6b8c2cd70a04731341cf0609/src/test/fxregs.c
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Package name for EPEL7 branch

[Orion Poplawski]

On 01/13/2016 09:30 PM, Greg Hellings wrote:

I'm working with a package (rubygem-minitest) which already exists in
the core EL packages on the 4.x series. In order to enable a whole
slew of new packages to be created in EPEL7, it will be necessary to
package the 5.x series. However, since we don't want to mask the EL
package it has been proposed and agreed to that the EPEL package be
named rubygem-minitest5.

In order to bring this about, would I need to submit a Review Request
for a new package named rubygem-minitest5 and go through the normal
new package process? Or is there an expedited way I can just get
rubygem-minitest5 added to the tags for epel7 in koji?

--Greg


new package = new review


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Package name for EPEL7 branch

[Greg Hellings]

I'm working with a package (rubygem-minitest) which already exists in
the core EL packages on the 4.x series. In order to enable a whole
slew of new packages to be created in EPEL7, it will be necessary to
package the 5.x series. However, since we don't want to mask the EL
package it has been proposed and agreed to that the EPEL package be
named rubygem-minitest5.

In order to bring this about, would I need to submit a Review Request
for a new package named rubygem-minitest5 and go through the normal
new package process? Or is there an expedited way I can just get
rubygem-minitest5 added to the tags for epel7 in koji?

--Greg
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Call for Fedora 24 Test Days

[Adam Williamson]

The Fedora 24 schedule [1] is winding up, and it's time we started
thinking about what we'd want to have a test day for. There are several
changes accepted already for F24, and the window for proposals is still
open so more may come. You can find the list of accepted Changes here:

http://fedoraproject.org/wiki/Releases/24/ChangeSet

Please take some time and look through the list and see if there's
anything you'd be interested in testing - or if there's something you
think should get some testing that isn't in the ChangeSet!

For those of you not familiar with them, a test day is an online event
aimed at testing a specific feature of an upcoming Fedora release. By
utilizing IRC for organization/coordination and a Wiki page for
instructions and results, test days are easy to organize. Anyone can
request to host a test day or request that the QA team help you out
with the organization of the test day. A test day can be run for any
feature or area of a distribution that focused testing would be useful
for. More information on test days can be found here:
https://fedoraproject.org/wiki/QA/Test_Days .

To propose a test day, file a ticket on the QA Trac. A full explanation
can be found here:
https://fedoraproject.org/wiki/QA/Test_Days/Create
The SOP for hosting a test day is here:
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management

Traditionally test days have been held on Thursdays, but if you'd
prefer to have it on another day that's fine too. We're pretty
flexible, but having plenty of lead time helps to get the word out.
Just put in your ticket the date or time-frame you'd like, and we'll
figure it out from there.

If you have any questions about test days or the process, please don't
hesitate to contact me or any other QA Team member in #fedora-qa on
Freenode or respond on the test list.

Thanks and happy testing!

[1] https://fedoraproject.org/wiki/Releases/24/Schedule
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide 20160113 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp

No images in this compose but not Rawhide 20160112

No images in Rawhide 20160112 but not this.

Failed openQA tests: 4 of 66

ID: 3055Test: x86_64 kde_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/3055
ID: 3054Test: x86_64 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3054
ID: 3053Test: i386 kde_live default_install
URL: https://openqa.fedoraproject.org/tests/3053
ID: 3051Test: x86_64 workstation_live base_services_start
URL: https://openqa.fedoraproject.org/tests/3051

Passed openQA tests: 62 of 66
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Florian Festi]

On 01/11/2016 05:08 PM, Colin Walters wrote:
> 
> 
> On Mon, Jan 11, 2016, at 09:46 AM, Jan Kurik wrote:
>> = Proposed System Wide Change: Change Proposal Name NewRpmDBFormat =
>> https://fedoraproject.org/wiki/Changes/NewRpmDBFormat
> 
> It'd be interesting to know the technical details, worth reposting once 
> there's
> a design document or prototype PR.

The format is already in the rpm upstream master branch. Give us a bit
on the documentation.

> I added rpm-ostree to the list, and one thing I'd like to note regarding that:
> We always generate a new DB rather than mutate-in-place, because
> rpm-ostree always generates atomic updates.  This means that
> mutation speed is not very relevant to us, but query speed still
> is.

We did some benchmarks. So far performance seems OK or better.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I enable C++11 to build a package?

[Kalev Lember]

On 01/13/2016 03:21 PM, Björn Esser wrote:

Am 13.01.2016 um 15:06 schrieb Ankur Sinha:

On Wed, 2016-01-13 at 13:08 +0100, Michael Schwendt wrote:

Yes.


Thanks Michael. Follow up question:

What is the cleanest way of doing this - replacing -ansi with
-std=c++11 in %{_optflags} while using the %configure macro?


You can do it the following way, by placing this override on top of your
spec-file:

%global optflags "-std=c++11 %{optflags}"

That will override the %optflags in scope of your spec-file to carry a
prepended "-std=c++11", too.  The %configure-macro will use your custom
enhanced %optflags, then.


It's also easy enough to do search and replace in %optflags if the
appending trick isn't enough. Although in this case I think it won't do
anything useful since -ansi isn't actually coming from %optflags:

%global optflags %(echo %{optflags} | sed 's/-ansi/-std=c++11/')

Also, GCC 6 that is going to land in F24 in 2 or 3 weeks is going to
switch the global default to -std=gnu++14 or -std=c++14, I've forgotten
which.

--
Hope this helps,
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Can I enable C++11 to build a package?

[Björn Esser]

Am 13.01.2016 um 15:06 schrieb Ankur Sinha:

On Wed, 2016-01-13 at 13:08 +0100, Michael Schwendt wrote:

Yes.


Thanks Michael. Follow up question:

What is the cleanest way of doing this - replacing -ansi with
-std=c++11 in %{_optflags} while using the %configure macro?


You can do it the following way, by placing this override on top of your 
spec-file:


%global optflags "-std=c++11 %{optflags}"

That will override the %optflags in scope of your spec-file to carry a 
prepended "-std=c++11", too.  The %configure-macro will use your custom 
enhanced %optflags, then.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Daniel P. Berrange]

On Wed, Jan 13, 2016 at 01:30:59PM +, Richard Hughes wrote:
> On 13 January 2016 at 13:13, Reindl Harald  wrote:
> > so there is no justification to declare one need to install from scratch
> > just because rpm which works for many years fine changes it's storage format
> 
> I don't think anyone said there was a need to reinstall from scratch.

Well the feature writeup is rather fuzzy on this.  It says that in Fedora
24 rpm will be able to read both old and new format, but it also says
that future RPM versions will drop support for the old format. So unless
there is a mandatory data format conversion during some Fedora upgrade,
then at some point RPM will cease to be able to read existing installs
with the old format which could imply a need to reinstall.

IMHO the feature proposal text needs to be more explicit about the upgrade
path and exactly when any data conversion will take place, to avoid leaving
existing installs with old format stuck with Fedora 25 rpm (or later) drops
BDB support entirely.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Golang 1.6

[Jakub Cajka]

- Original Message -
> From: "Florian Weimer" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, January 13, 2016 9:46:15 AM
> Subject: Re: F24 System Wide Change: Golang 1.6
> 
> On 01/13/2016 12:56 AM, Peter Robinson wrote:
> > On Tue, Jan 12, 2016 at 5:30 PM, Matthew Miller
> >  wrote:
> >> On Tue, Jan 12, 2016 at 01:31:30AM +, Peter Robinson wrote:
> >>> Will there be an ABI guaranteed beta or RC so that this can be
> >>> complete before branching as per the schedule [1]? All major rebases
> >>> should be complete prior to branching.
> >>> [1] https://fedoraproject.org/wiki/Releases/24/Schedule
> >>
> >> Since everything is statically linked, the ABI isn't really a factor.
> > 
> > It is if it changes between say beta and GA because it'll still all
> > then need another rebuild, hence the question.
> 
> Go library packages do not actually contain compiled code, right? So
> the ABI really should not matter, it's like Perl in this regard.
>

Basically yes, at the moment.

Peter Robinson proposed to me "merging" the golang re-build with scheduled mass 
rebuild. I think it should work.
Golang have pre-releases and they should be good enough for the re-build and I 
don't expect any API/ABI breakages.
I will update the change proposal accordingly also added link to the COPR witch 
will contain pre-release builds.

Jakub

> 
> Florian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: 4.3 rebase in F23 updates-testing

[Eric Griffith]

On Jan 12, 2016 15:03, "Josh Boyer"  wrote:
>
> On Tue, Jan 12, 2016 at 2:08 PM, Mattia Verga 
wrote:
> > Il 07/01/2016 20:30, Tomasz Torcz ha scritto:
> >>
> >> On Thu, Jan 07, 2016 at 01:33:22PM -0500, Josh Boyer wrote:
> >>>
> >>> Hello,
> >>>
> >>> The 4.3.3 kernel has been pushed to updates-testing for F23.  As of
> >>> right now, it has a +12 karma score.  Given that it is a major release
> >>> rebase, we're going to wait at least a few days to see how it fares.
> >>>
> >>> If you are so inclined, testing would be appreciated.  As usual,
> >>> please give karma as appropriate but we would appreciate it if you
> >>> only give negative karma for new, not reported issues and with a bug
> >>> link associated.  If a bug is fixed, we have marked it as such.  If it
> >>> isn't, we haven't and giving negative karma for those known issues
> >>> simply prevents fixes from getting into the hands of other users.
> >>>
> >>   Please note there seem to be a btrfs regression in since 4.3:
> >> namely fstrim could discard beginning of the disk, removing the
> >> bootloader.  This commit fixes the issue:
> >>
> >>
> >>
http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=integration-4.5=7b6cb6618b45bb383f9336ec89df5f1f31f9935b
> >>
> > So, is it safe to install kernel 4.3.3-300? I see it's now in stable
repo,
> > but I think it doesn't carry the commit above...
>
> The commit above isn't in any released kernel, Fedora or upstream or
> otherwise.  It was only added to the main btrfs maintainer's tree
> about a day ago.
>
> As far as I understand the bug, it only happens if you have the
> bootloader installed in the root partition (not a separate /boot) and
> you run an fstrim on the whole partition (fstrim /) either manually or
> from a system script or such.  I suppose it would possibly happen if
> you have the bootloader installed in a btrfs /boot partition and ran
> fstrim on that too.  However, Fedora doesn't support booting from a
> btrfs filesystem at the moment and typical installs create a separate
> /boot partition that is ext4.  I may have some details wrong and would
> gladly be corrected if so.

Can confirm. Just head to reinstall an F23 system. Automatically generated
partitions (Encrypted btrfs raid0) gave me an ext4 /boot

> We'll pick up the fix once it lands in Linus' tree.  Until then, the
> safety is mostly determine by that of btrfs in general.  Opinions
> vary.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unreachable Developer

[Greg Hellings]

Neal,

I've tried reaching him at the email address listed on his account, which is 
via a public provider. I was unaware of his website. I will try reaching out 
across that medium as well. Thanks.

--Greg
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python-rpm-macros - splitting out the macros

[Orion Poplawski]

On 01/12/2016 03:42 PM, Orion Poplawski wrote:
> - Dropping the python3-pkgversion-macros package, replaced with
> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
> and epel-rpm-macros (in EPEL).

Rawhide now has redhat-rpm-config requiring python-srpm-macros.  So we now
have %python3_pkgversion in rawhide.

> - Dropping the python-macros sub-package from python, replace by Requires:
> python-rpm-macros from above package.  python3 requires this as well.

python-devel and python3-devel will now be bringing in python-rpm-macros from
the new package.

> - Dropping macros.python2 from python-devel, replaced with Requires:
> python2-rpm-macros from above package.
> 
> - Dropping macros.python3 from python3-devel, replaced with Requires:
> python3-rpm-macros from above package.

I'm working on this and testing changes in a copr before building for rawhide.


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unreachable Developer

[Neal Gompa]

Have you tried contacting him by strzi...@strzibny.name (his email
address on his website)?

On Wed, Jan 13, 2016 at 11:41 AM, Greg Hellings  wrote:
> I've been trying to reach jstribny(
> https://admin.fedoraproject.org/accounts/user/view/jstribny) for a few
> weeks regarding commit privileges on EPEL7 to several packages in
> pkgdb. Most notable among those are:
> rubygem-minitest
> rubygem-i18n
> rubygem-tzinfo
>
> As yet, I have been unable to produce a response, either in pkgdb or
> via email. Has anyone had contact with him lately? For some of my
> pending requests, there are other package maintainers who have been
> wonderfully helpful in responding, but I've been completely unable to
> reach jstribny.
>
> Assistance would be appreciated. Thanks!
>
> --Greg
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unreachable Developer

[Greg Hellings]

I've been trying to reach jstribny(
https://admin.fedoraproject.org/accounts/user/view/jstribny) for a few
weeks regarding commit privileges on EPEL7 to several packages in
pkgdb. Most notable among those are:
rubygem-minitest
rubygem-i18n
rubygem-tzinfo

As yet, I have been unable to produce a response, either in pkgdb or
via email. Has anyone had contact with him lately? For some of my
pending requests, there are other package maintainers who have been
wonderfully helpful in responding, but I've been completely unable to
reach jstribny.

Assistance would be appreciated. Thanks!

--Greg
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: 4.3 rebase in F23 updates-testing

[Chris Murphy]

On Wed, Jan 13, 2016 at 8:33 AM, Eric Griffith  wrote:
>
> On Jan 12, 2016 15:03, "Josh Boyer"  wrote:
>>
>> On Tue, Jan 12, 2016 at 2:08 PM, Mattia Verga 
>> wrote:
>> > Il 07/01/2016 20:30, Tomasz Torcz ha scritto:
>> >>
>> >> On Thu, Jan 07, 2016 at 01:33:22PM -0500, Josh Boyer wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> The 4.3.3 kernel has been pushed to updates-testing for F23.  As of
>> >>> right now, it has a +12 karma score.  Given that it is a major release
>> >>> rebase, we're going to wait at least a few days to see how it fares.
>> >>>
>> >>> If you are so inclined, testing would be appreciated.  As usual,
>> >>> please give karma as appropriate but we would appreciate it if you
>> >>> only give negative karma for new, not reported issues and with a bug
>> >>> link associated.  If a bug is fixed, we have marked it as such.  If it
>> >>> isn't, we haven't and giving negative karma for those known issues
>> >>> simply prevents fixes from getting into the hands of other users.
>> >>>
>> >>   Please note there seem to be a btrfs regression in since 4.3:
>> >> namely fstrim could discard beginning of the disk, removing the
>> >> bootloader.  This commit fixes the issue:
>> >>
>> >>
>> >>
>> >> http://git.kernel.org/cgit/linux/kernel/git/fdmanana/linux.git/commit/?h=integration-4.5=7b6cb6618b45bb383f9336ec89df5f1f31f9935b
>> >>
>> > So, is it safe to install kernel 4.3.3-300? I see it's now in stable
>> > repo,
>> > but I think it doesn't carry the commit above...
>>
>> The commit above isn't in any released kernel, Fedora or upstream or
>> otherwise.  It was only added to the main btrfs maintainer's tree
>> about a day ago.
>>
>> As far as I understand the bug, it only happens if you have the
>> bootloader installed in the root partition (not a separate /boot) and
>> you run an fstrim on the whole partition (fstrim /) either manually or
>> from a system script or such.  I suppose it would possibly happen if
>> you have the bootloader installed in a btrfs /boot partition and ran
>> fstrim on that too.  However, Fedora doesn't support booting from a
>> btrfs filesystem at the moment and typical installs create a separate
>> /boot partition that is ext4.  I may have some details wrong and would
>> gladly be corrected if so.
>
> Can confirm. Just head to reinstall an F23 system. Automatically generated
> partitions (Encrypted btrfs raid0) gave me an ext4 /boot

It takes a lot of gymnastics to get Fedora into this situation, and it
can't be done via the GUI installer and maybe not even with kickstart.
Whereas on openSUSE, where the bug was found, it's their default
layout at install time. First they don't step on the bootloader in LBA
0 by default, and new installs use parted's jump code. So no matter
what, the MBR bootloader code jumps to the VBR of the partition with
an active bit set. The Btrfs VBR is huge, 64KiB, which is why it's
supported as a GRUB bootloader pad, and that's where openSUSE embeds
GRUB whether on MBR or GPT disks.

So anyone with a 92 ways to boot Linux wall poster needs to update it to 93.


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

the application lxqt

[mastaiza]

in my opinion lacks the two applications is lxqt-admin obconf-qt
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Bug 1298003] perl-PAR-Packer-1.029 is available

[bugzilla]

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

Petr Šabata  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PAR-Packer-1.029-1.fc2
   ||4
 Resolution|--- |RAWHIDE
Last Closed||2016-01-13 06:39:08



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1298184] perl-XML-XPath-1.22 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12532030

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1298184] perl-XML-XPath-1.22 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1114394
  --> https://bugzilla.redhat.com/attachment.cgi?id=1114394=edit
[patch] Update to 1.22 (#1298184)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1298184] New: perl-XML-XPath-1.22 is available

[bugzilla]

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

Bug ID: 1298184
   Summary: perl-XML-XPath-1.22 is available
   Product: Fedora
   Version: rawhide
 Component: perl-XML-XPath
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.22
Current version/release in rawhide: 1.21-1.fc24
URL: http://search.cpan.org/dist/XML-XPath/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Re: python-rpm-macros - splitting out the macros

[Matej Stuchlik]

- Original Message -
> From: "Orion Poplawski" 
> To: python-devel@lists.fedoraproject.org, python-ow...@fedoraproject.org, 
> python3-ow...@fedoraproject.org,
> "Development discussions related to Fedora" 
> Sent: Tuesday, January 12, 2016 11:42:13 PM
> Subject: python-rpm-macros - splitting out the macros
> 
> On 01/08/2016 11:27 AM, bugzi...@redhat.com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294904
> > 
> > Antonio Trande  changed:
> > 
> >What|Removed |Added
> > 
> >   Flags|fedora-review?  |fedora-review+
> > 
> > 
> > 
> > --- Comment #12 from Antonio Trande  ---
> > Package approved.
> > 
> 
> I still have heard nothing from the main python maintainers, and I'd like to
> get some kind of an ack for the following plan:
> 
> - Dropping the python3-pkgversion-macros package, replaced with
> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
> and epel-rpm-macros (in EPEL).
> 
> - Dropping the python-macros sub-package from python, replace by Requires:
> python-rpm-macros from above package.  python3 requires this as well.
> 
> - Dropping macros.python2 from python-devel, replaced with Requires:
> python2-rpm-macros from above package.
> 
> - Dropping macros.python3 from python3-devel, replaced with Requires:
> python3-rpm-macros from above package.
> 
> This achieves the goal of decoupling modifying/updating the python macros
> from
> updating the main python package, which has become a serious hindrance to
> developing new python rpm macros.
> 
> The reviewed package contains the Fedora macros.  macros will be changed on
> the EPEL branches.

Sorry for the late response -- extended vacation. :)

We're 100% behind this, it's been something that's been on our todo list for a
while now. :)

Matt

> I've requested a side tag to do the build in here -
> https://fedorahosted.org/rel-eng/ticket/6331
> 
> as I think the timing is tricky and the possibility of breaking the buildroot
> moderate.
> 
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
> 
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

[389-devel] Please review: Ticket 48341

[Ludwig Krispenz]

Hi,

to have my suggestion discussed by a wider audience, please have a look:

https://fedorahosted.org/389/ticket/48341
https://fedorahosted.org/389/attachment/ticket/48341/0001-Ticket-48341-deadlock-on-connection-mutex.patch

Ludwig
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1298184] perl-XML-XPath-1.22 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-XML-XPath-1.22-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2016-01-13 08:38:10



-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik uploaded XML-XPath-1.22.tar.gz for perl-XML-XPath

[notifications]

0764193055f2ebec5c2414fbc9235c7e  XML-XPath-1.22.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-XML-XPath/XML-XPath-1.22.tar.gz/md5/0764193055f2ebec5c2414fbc9235c7e/XML-XPath-1.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik pushed to perl-XML-XPath (master). "0.22 bump"

[notifications]

From 3d156d8ecf43659278533dd418b9d53bf9cd06f9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Wed, 13 Jan 2016 14:35:34 +0100
Subject: 0.22 bump

---
 .gitignore  | 1 +
 perl-XML-XPath.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 3e1596c..5246c11 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ XML-XPath-1.13.tar.gz
 /XML-XPath-1.19.tar.gz
 /XML-XPath-1.20.tar.gz
 /XML-XPath-1.21.tar.gz
+/XML-XPath-1.22.tar.gz
diff --git a/perl-XML-XPath.spec b/perl-XML-XPath.spec
index 508429e..7cd9fee 100644
--- a/perl-XML-XPath.spec
+++ b/perl-XML-XPath.spec
@@ -1,5 +1,5 @@
 Name:   perl-XML-XPath
-Version:1.21
+Version:1.22
 Release:1%{?dist}
 Summary:XPath parser and evaluator for Perl
 License:Artistic 2.0
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Wed Jan 13 2016 Jitka Plesnikova  - 1.22-1
+- 1.22 bump
+
 * Tue Jan 12 2016 Petr Pisar  - 1.21-1
 - 1.21 bump
 
diff --git a/sources b/sources
index 2ced2f2..ee3d039 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-67c84a3d9408fcbd6bdcc5fd9a333974  XML-XPath-1.21.tar.gz
+0764193055f2ebec5c2414fbc9235c7e  XML-XPath-1.22.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-XML-XPath.git/commit/?h=master=3d156d8ecf43659278533dd418b9d53bf9cd06f9
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Orphaned Packages in epel7 (2016-01-13)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package(co)maintainers Status Change 
==
electronics-menu   orphan, chitlesh  14 weeks ago  
faience-icon-theme orphan2 weeks ago   
gfal2-plugin-xrootdorphan, aalvarez, adev9 weeks ago   
gtk-unico-engine   orphan2 weeks ago   
mate-applet-lockkeys   orphan2 weeks ago   
passenger  orphan10 weeks ago  
shorewall  orphan, digimer, jgu, orion   0 weeks ago   

The following packages require above mentioned packages:
Depending on: faience-icon-theme (1), status change: 2015-12-29 (2 weeks ago)
mate-themes-extras (maintained by: raveit65)
mate-themes-extras-3.8.4-2.el7.noarch requires 
faience-icon-theme = 0.5-4.el7


Depending on: shorewall (1), status change: 2016-01-06 (0 weeks ago)
fail2ban (maintained by: orion, athmane, atkac)
fail2ban-shorewall-0.9.3-1.el7.noarch requires shorewall = 
4.6.5.3-1.el7


Affected (co)maintainers
aalvarez: gfal2-plugin-xrootd
adev: gfal2-plugin-xrootd
athmane: shorewall
atkac: shorewall
chitlesh: electronics-menu
digimer: shorewall
jgu: shorewall
orion: shorewall
raveit65: faience-icon-theme

Orphans (7): electronics-menu faience-icon-theme gfal2-plugin-xrootd
gtk-unico-engine mate-applet-lockkeys passenger shorewall


Orphans (dependend on) (2): faience-icon-theme shorewall


Orphans (epel7) for at least 6 weeks (dependend on) (0):


Orphans  (epel7)(not depended on) (5): electronics-menu
gfal2-plugin-xrootd gtk-unico-engine mate-applet-lockkeys
passenger


Orphans (epel7) for at least 6 weeks (not dependend on) (3):
electronics-menu gfal2-plugin-xrootd passenger


Depending packages (epel7) (2): fail2ban mate-themes-extras


Packages depending on packages orphaned (epel7) for more than 6 weeks
(0):


Not found in repo (epel7) (1): passenger

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its trac instance:
https://fedorahosted.org/rel-eng/
The sources of this script can be found at:
https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Orphaned Packages in epel5 (2016-01-13)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package (co)maintainers   Status Change 
=
dinotrace orphan, chitlesh  14 weeks ago  
electronics-menu  orphan, chitlesh  14 weeks ago  
gdl   orphan, orion 10 weeks ago  
gfal2-plugin-xrootd   orphan, aalvarez, adev9 weeks ago   
gnucaporphan, chitlesh  14 weeks ago  
iverilog  orphan, chitlesh  14 weeks ago  
jna   orphan, lfarkas, walters  32 weeks ago  
libstroke orphan, chitlesh  14 weeks ago  
perl-libintl  orphan, perl-sig, rjones, thias   15 weeks ago  
php-ZendFramework orphan13 weeks ago  
pulseaudioorphan5 weeks ago   
python-matplotlib orphan, jspaleta  18 weeks ago  
re2c  orphan, thias 15 weeks ago  
rubygem-bacon orphan, bkabrda, stevetraylen 27 weeks ago  
shorewall orphan, digimer, jgu, orion   0 weeks ago   

The following packages require above mentioned packages:
Depending on: dinotrace (1), status change: 2015-10-07 (14 weeks ago)
gplcver (maintained by: jcapik, chitlesh)
gplcver-2.11a-2.el5.x86_64 requires dinotrace = 9.4c-1.el5


Depending on: electronics-menu (2), status change: 2015-10-07 (14 weeks ago)
qucs (maintained by: jcapik, chitlesh)
qucs-0.0.15-6.el5.x86_64 requires electronics-menu = 1.0-6.el5

tkgate (maintained by: tnorth, chitlesh)
tkgate-2.0-7.beta9.el5.x86_64 requires electronics-menu = 
1.0-6.el5


Depending on: gnucap (1), status change: 2015-10-07 (14 weeks ago)
emacs-spice-mode (maintained by: sagarun, chitlesh)
emacs-spice-mode-1.2.25-4.el5.noarch requires gnucap = 
0.35-6.el5


Depending on: iverilog (1), status change: 2015-10-07 (14 weeks ago)
teal (maintained by: jcapik, chitlesh)
teal-1_40b-4.el5.i386 requires iverilog = 0.9.2001-1.el5
teal-1_40b-4.el5.src requires iverilog-devel = 
0.9.2001-1.el5
teal-1_40b-4.el5.x86_64 requires iverilog = 0.9.2001-1.el5


Depending on: jna (2), status change: 2015-06-03 (32 weeks ago)
gstreamer-java (maintained by: lfarkas)
gstreamer-java-1.5-1.el5.src requires jna = 3.4.0-4.el5, 
jna-contrib = 3.4.0-4.el5
gstreamer-java-1.5-1.el5.x86_64 requires jna = 3.4.0-4.el5
gstreamer-java-swt-1.5-1.el5.x86_64 requires jna-contrib = 
3.4.0-4.el5

java-dirq (maintained by: lcons, mpaladin, stevetraylen)
java-dirq-1.4-1.el5.noarch requires jna = 3.4.0-4.el5
java-dirq-1.4-1.el5.src requires jna = 3.4.0-4.el5


Depending on: libstroke (1), status change: 2015-10-07 (14 weeks ago)
fvwm (maintained by: peter, jhogarth, pertusus)
fvwm-2.5.26-2.el5.2.src requires libstroke-devel = 0.5.1-21.el5
fvwm-2.5.26-2.el5.2.x86_64 requires libstroke.so.0()(64bit)


Depending on: perl-libintl (4), status change: 2015-09-30 (15 weeks ago)
hivex (maintained by: rjones, mdbooth)
hivex-1.3.5-6.el5.src requires perl-libintl = 1.16-9.el5

libguestfs (maintained by: rjones, agk, group::virtmaint-sig, mdbooth, 
ptoscano)
libguestfs-1.20.8-1.el5.src requires perl-libintl = 1.16-9.el5
libguestfs-tools-1.20.8-1.el5.x86_64 requires 
perl(Locale::TextDomain) = 1.16
perl-Sys-Guestfs-1.20.8-1.el5.x86_64 requires 
perl(Locale::TextDomain) = 1.16

pgp-tools (maintained by: s4504kr, fale)
pgp-tools-1.1.4-1.el5.x86_64 requires perl(Locale::Recode)

xls2csv (maintained by: hubbitus, fale)
xls2csv-1.06-5.el5.noarch requires perl(Locale::Recode)
xls2csv-1.06-5.el5.src requires perl(Locale::Recode)


Depending on: php-ZendFramework (1), status change: 2015-10-12 (13 weeks ago)
ganglia (maintained by: noodles, georgiou, ggillies, terjeros)
ganglia-web-3.6.2-1.el5.x86_64 requires php-ZendFramework = 
1.12.13-2.el5


Depending on: pulseaudio (4), status change: 2015-12-08 (5 weeks 

[EPEL-devel] Orphaned Packages in epel6 (2016-01-13)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package   (co)maintainers Status Change 
=
dinotrace orphan, chitlesh  14 weeks ago  
directfb  orphan, kwizart, thias15 weeks ago  
electronics-menu  orphan, chitlesh  14 weeks ago  
gfal2-plugin-xrootd   orphan, aalvarez, adev9 weeks ago   
gnucaporphan, chitlesh  14 weeks ago  
iverilog  orphan, chitlesh  14 weeks ago  
libstroke orphan, chitlesh  14 weeks ago  
mot-adms  orphan, chitlesh  14 weeks ago  
shorewall orphan, digimer, jgu, orion   0 weeks ago   
tailororphan, sharkcz   2 weeks ago   

The following packages require above mentioned packages:
Depending on: dinotrace (1), status change: 2015-10-07 (14 weeks ago)
gplcver (maintained by: jcapik, chitlesh)
gplcver-2.12a-3.el6.x86_64 requires dinotrace = 9.4c-1.el6


Depending on: directfb (4), status change: 2015-09-30 (15 weeks ago)
xine-lib (maintained by: rdieter)
xine-lib-1.1.21-11.el6.src requires directfb-devel = 
1.4.11-3.el6
xine-lib-extras-1.1.21-11.el6.i686 requires libdirect-1.4.so.0, 
libdirectfb-1.4.so.0, libfusion-1.4.so.0
xine-lib-extras-1.1.21-11.el6.x86_64 requires 
libdirect-1.4.so.0()(64bit), libdirectfb-1.4.so.0()(64bit), 
libfusion-1.4.so.0()(64bit)

gxine (maintained by: mso)
gxine-0.5.905-2.el6.x86_64 requires libxine.so.1()(64bit)

kaffeine (maintained by: rdieter)
kaffeine-1.2.2-8.el6.x86_64 requires libxine.so.1()(64bit)

xine-ui (maintained by: mjg)
xine-ui-0.99.6-32.el6.x86_64 requires libxine.so.1()(64bit), 
xine-lib = 1.1.21-11.el6
xine-ui-aaxine-0.99.6-32.el6.x86_64 requires 
libxine.so.1()(64bit)


Depending on: electronics-menu (8), status change: 2015-10-07 (14 weeks ago)
gnusim8085 (maintained by: puiterwijk, chitlesh)
gnusim8085-1.3.7-3.el6.x86_64 requires electronics-menu = 
1.0-8.el6

gsim85 (maintained by: fab, chitlesh)
gsim85-0.3-2.el6.x86_64 requires electronics-menu = 1.0-8.el6

kicad (maintained by: jcapik, chitlesh, lkundrak)
kicad-2013.06.11-1.rev4021.el6.i686 requires electronics-menu = 
1.0-8.el6
kicad-2013.06.11-1.rev4021.el6.x86_64 requires electronics-menu 
= 1.0-8.el6

qelectrotech (maintained by: remi)
qelectrotech-0.30-1.el6.x86_64 requires electronics-menu = 
1.0-8.el6

qucs (maintained by: jcapik, chitlesh)
qucs-0.0.15-6.el6.x86_64 requires electronics-menu = 1.0-8.el6

tkgate (maintained by: tnorth, chitlesh)
tkgate-2.0-10.beta10.el6.x86_64 requires electronics-menu = 
1.0-8.el6

xcircuit (maintained by: mayorga, chitlesh, sophiekovalevsky)
xcircuit-3.6.164-1.el6.x86_64 requires electronics-menu = 
1.0-8.el6

perl-Verilog-CodeGen (maintained by: jplesnik, chitlesh)
perl-Verilog-CodeGen-0.9.4-3.el6.noarch requires tkgate = 
2.0-10.beta10.el6


Depending on: gnucap (1), status change: 2015-10-07 (14 weeks ago)
emacs-spice-mode (maintained by: sagarun, chitlesh)
emacs-spice-mode-1.2.25-4.el6.noarch requires gnucap = 
0.35-6.el6


Depending on: iverilog (1), status change: 2015-10-07 (14 weeks ago)
teal (maintained by: jcapik, chitlesh)
teal-1_40b-4.el6.i686 requires iverilog = 0.9.20120609-1.el6
teal-1_40b-4.el6.src requires iverilog-devel = 
0.9.20120609-1.el6
teal-1_40b-4.el6.x86_64 requires iverilog = 0.9.20120609-1.el6


Depending on: libstroke (1), status change: 2015-10-07 (14 weeks ago)
fvwm (maintained by: peter, jhogarth, mcermak, pertusus)
fvwm-2.6.5-9.el6.src requires libstroke-devel = 0.5.1-24.el6
fvwm-2.6.5-9.el6.x86_64 requires libstroke.so.0()(64bit)


Depending on: mot-adms (1), status change: 2015-10-07 (14 weeks ago)
ngspice (maintained by: mayorga, chitlesh, sophiekovalevsky)
ngspice-23-1.el6.src requires mot-adms = 2.2.9-1.svn1186.el6


Affected (co)maintainers
aalvarez: gfal2-plugin-xrootd

[EPEL-devel] Orphaned Packages in epel5 (2016-01-13)

[opensource]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

  Package (co)maintainers   Status Change 
=
dinotrace orphan, chitlesh  14 weeks ago  
electronics-menu  orphan, chitlesh  14 weeks ago  
gdl   orphan, orion 10 weeks ago  
gfal2-plugin-xrootd   orphan, aalvarez, adev9 weeks ago   
gnucaporphan, chitlesh  14 weeks ago  
iverilog  orphan, chitlesh  14 weeks ago  
jna   orphan, lfarkas, walters  32 weeks ago  
libstroke orphan, chitlesh  14 weeks ago  
perl-libintl  orphan, perl-sig, rjones, thias   15 weeks ago  
php-ZendFramework orphan13 weeks ago  
pulseaudioorphan5 weeks ago   
python-matplotlib orphan, jspaleta  18 weeks ago  
re2c  orphan, thias 15 weeks ago  
rubygem-bacon orphan, bkabrda, stevetraylen 27 weeks ago  
shorewall orphan, digimer, jgu, orion   0 weeks ago   

The following packages require above mentioned packages:
Depending on: dinotrace (1), status change: 2015-10-07 (14 weeks ago)
gplcver (maintained by: jcapik, chitlesh)
gplcver-2.11a-2.el5.x86_64 requires dinotrace = 9.4c-1.el5


Depending on: electronics-menu (2), status change: 2015-10-07 (14 weeks ago)
qucs (maintained by: jcapik, chitlesh)
qucs-0.0.15-6.el5.x86_64 requires electronics-menu = 1.0-6.el5

tkgate (maintained by: tnorth, chitlesh)
tkgate-2.0-7.beta9.el5.x86_64 requires electronics-menu = 
1.0-6.el5


Depending on: gnucap (1), status change: 2015-10-07 (14 weeks ago)
emacs-spice-mode (maintained by: sagarun, chitlesh)
emacs-spice-mode-1.2.25-4.el5.noarch requires gnucap = 
0.35-6.el5


Depending on: iverilog (1), status change: 2015-10-07 (14 weeks ago)
teal (maintained by: jcapik, chitlesh)
teal-1_40b-4.el5.i386 requires iverilog = 0.9.2001-1.el5
teal-1_40b-4.el5.src requires iverilog-devel = 
0.9.2001-1.el5
teal-1_40b-4.el5.x86_64 requires iverilog = 0.9.2001-1.el5


Depending on: jna (2), status change: 2015-06-03 (32 weeks ago)
gstreamer-java (maintained by: lfarkas)
gstreamer-java-1.5-1.el5.src requires jna = 3.4.0-4.el5, 
jna-contrib = 3.4.0-4.el5
gstreamer-java-1.5-1.el5.x86_64 requires jna = 3.4.0-4.el5
gstreamer-java-swt-1.5-1.el5.x86_64 requires jna-contrib = 
3.4.0-4.el5

java-dirq (maintained by: lcons, mpaladin, stevetraylen)
java-dirq-1.4-1.el5.noarch requires jna = 3.4.0-4.el5
java-dirq-1.4-1.el5.src requires jna = 3.4.0-4.el5


Depending on: libstroke (1), status change: 2015-10-07 (14 weeks ago)
fvwm (maintained by: peter, jhogarth, pertusus)
fvwm-2.5.26-2.el5.2.src requires libstroke-devel = 0.5.1-21.el5
fvwm-2.5.26-2.el5.2.x86_64 requires libstroke.so.0()(64bit)


Depending on: perl-libintl (4), status change: 2015-09-30 (15 weeks ago)
hivex (maintained by: rjones, mdbooth)
hivex-1.3.5-6.el5.src requires perl-libintl = 1.16-9.el5

libguestfs (maintained by: rjones, agk, group::virtmaint-sig, mdbooth, 
ptoscano)
libguestfs-1.20.8-1.el5.src requires perl-libintl = 1.16-9.el5
libguestfs-tools-1.20.8-1.el5.x86_64 requires 
perl(Locale::TextDomain) = 1.16
perl-Sys-Guestfs-1.20.8-1.el5.x86_64 requires 
perl(Locale::TextDomain) = 1.16

pgp-tools (maintained by: s4504kr, fale)
pgp-tools-1.1.4-1.el5.x86_64 requires perl(Locale::Recode)

xls2csv (maintained by: hubbitus, fale)
xls2csv-1.06-5.el5.noarch requires perl(Locale::Recode)
xls2csv-1.06-5.el5.src requires perl(Locale::Recode)


Depending on: php-ZendFramework (1), status change: 2015-10-12 (13 weeks ago)
ganglia (maintained by: noodles, georgiou, ggillies, terjeros)
ganglia-web-3.6.2-1.el5.x86_64 requires php-ZendFramework = 
1.12.13-2.el5


Depending on: pulseaudio (4), status change: 2015-12-08 (5 weeks 

[EPEL-devel] Re: LibRaw is in EPEL testing and also in Base

[Ding Yi Chen]

- Original Message -
> 2016-01-12 16:28 GMT+01:00 Johnny Hughes :
> > 'LibRaw-0.17.1-3.el7.x86_64 (epel-testing)' and
> > 'LibRaw-0.14.8-5.el7.20120830git98d925.x86_64 (@base/$releasever)' are
> > conflicting
> >
> 
> Maybe it needs to be synced but it's not on the list of packages that
> should be shipped by EPEL.
> https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json

This looks like packages black-listed for EPEL, and LibRaw is not in it. :-P

I have file a bug against RHEL 7.2 and see how should thing go.
https://bugzilla.redhat.com/show_bug.cgi?id=1298452

Regards,

-- 
Ding-Yi Chen
Software Engineer
Globalization Group
DID: +61 7 3514 8239
Email: dc...@redhat.com

Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8100
Fax: +61 7 3514 8199
Website: www.redhat.com

Red Hat, Inc.
Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC
Twitter: Red Hat APAC | Red Hat ANZ
LinkedIn: Red Hat APAC | JBoss APAC
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[Bug 1296356] perl-Mojolicious-6.40 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Mojolicious-6.39 is|perl-Mojolicious-6.40 is
   |available   |available



--- Comment #4 from Upstream Release Monitoring 
 ---
Latest upstream release: 6.40
Current version/release in rawhide: 6.39-1.fc24
URL: http://mojolicio.us/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[389-devel] Re: Prereview for ticket #48402 , required by ticket #48380 SynRepl does not handle database re-initialization properly

[Mark Reynolds]

On 01/13/2016 10:01 AM, Ludwig Krispenz wrote:
Ticket 48380 requires that sync repl handles database 
reinitializations properly, to be able to determine if cookies are 
presented are valid.
To achieve this plugins need to be able to detcet if the database is 
imported or restored and this is tarcked in ticket 48402.


Before implementing a fix, I would like to get feedback on the design: 
http://www.port389.org/docs/389ds/design/detect-startup-after-import-or-restore.html
The design looks good to me.  I really like the use of the "db event" 
file(like the guardian file).


Thanks,
Ludwig
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1296356] perl-Mojolicious-6.40 is available

[bugzilla]

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



--- Comment #5 from Upstream Release Monitoring 
 ---
Created attachment 1114618
  --> https://bugzilla.redhat.com/attachment.cgi?id=1114618=edit
[patch] Update to 6.40 (#1296356)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[389-devel] Re: Prereview for ticket #48402 , required by ticket #48380 SynRepl does not handle database re-initialization properly

[William Brown]

On Wed, 2016-01-13 at 17:34 -0500, Mark Reynolds wrote:
> 
> On 01/13/2016 10:01 AM, Ludwig Krispenz wrote:
> > Ticket 48380 requires that sync repl handles database 
> > reinitializations properly, to be able to determine if cookies are 
> > presented are valid.
> > To achieve this plugins need to be able to detcet if the database
> > is 
> > imported or restored and this is tarcked in ticket 48402.
> > 
> > Before implementing a fix, I would like to get feedback on the
> > design: 
> > http://www.port389.org/docs/389ds/design/detect-startup-after-impor
> > t-or-restore.html
> The design looks good to me.  I really like the use of the "db
> event" 
> file(like the guardian file).


I really like the simplicity of this. It's very elegant.

With the startup check for restore and import, why not make both of
them have the same flag setting mechanism in the backend? Rather than
one setting a global variable and one setting a be flag?

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane



signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1298397] New: perl-DateTime-Format-Strptime-1.63 is available

[bugzilla]

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

Bug ID: 1298397
   Summary: perl-DateTime-Format-Strptime-1.63 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime-Format-Strptime
  Keywords: FutureFeature, Triaged
  Assignee: psab...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
psab...@redhat.com, st...@silug.org



Latest upstream release: 1.63
Current version/release in rawhide: 1.62-1.fc24
URL: http://search.cpan.org/dist/DateTime-Format-Strptime/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1296356] perl-Mojolicious-6.40 is available

[bugzilla]

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



--- Comment #6 from Upstream Release Monitoring 
 ---
Scratch build completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=12539391

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

corsepiu pushed to perl-File-Remove (master). "Upstream update. (..more)"

[notifications]

From 5717bdf840a3ca1bdaa9c0aa64e4d26127641633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Thu, 14 Jan 2016 03:36:40 +0100
Subject: Upstream update.

- Reflect upstream URL-having changed.
- Update BRs.
- Spec cosmetics.
- Introduce %license.
---
 .gitignore|  2 +-
 perl-File-Remove.spec | 28 +---
 sources   |  2 +-
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/.gitignore b/.gitignore
index c6acb8f..0c4badc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/File-Remove-1.52.tar.gz
+/File-Remove-1.55.tar.gz
diff --git a/perl-File-Remove.spec b/perl-File-Remove.spec
index c63127b..d921f0c 100644
--- a/perl-File-Remove.spec
+++ b/perl-File-Remove.spec
@@ -1,22 +1,29 @@
 Name:  perl-File-Remove
-Version:   1.52
-Release:   11%{?dist}
+Version:   1.55
+Release:   1%{?dist}
 Summary:   Convenience module for removing files and directories
 License:   GPL+ or Artistic
 Group: Development/Libraries
 URL:   http://search.cpan.org/dist/File-Remove/
-Source0:   
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/File-Remove-%{version}.tar.gz
+Source0:   
http://search.cpan.org/CPAN/authors/id/S/SH/SHLOMIF/File-Remove-%{version}.tar.gz
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 BuildRequires: perl(constant)
-BuildRequires: perl(Cwd)
+BuildRequires: perl(Cwd) >= 3.29
 BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(ExtUtils::MM_Unix)
+BuildRequires:  perl(File::Copy)
 BuildRequires: perl(File::Glob)
 BuildRequires: perl(File::Path)
 BuildRequires: perl(File::Spec) >= 3.29
 BuildRequires: perl(File::Spec::Functions)
 BuildRequires: perl(File::Temp)
+BuildRequires:  perl(IO::Handle)
+BuildRequires:  perl(IPC::Open3)
+BuildRequires:  perl(Module::Build) >= 0.28
+BuildRequires:  perl(strict)
 BuildRequires: perl(Test::More) >= 0.42
+BuildRequires:  perl(vars)
+BuildRequires:  perl(warnings)
+
 BuildArch: noarch
 
 %description
@@ -32,18 +39,25 @@ make %{?_smp_mflags}
 %install
 make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
 chmod -R u+w $RPM_BUILD_ROOT/*
 
 %check
 make test
 
 %files
-%doc Changes README LICENSE
+%doc Changes README
+%license LICENSE
 %{perl_vendorlib}/File
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jan 14 2016 Ralf Corsépius  - 1.55-1
+- Upstream update.
+- Reflect upstream URL-having changed.
+- Update BRs.
+- Spec cosmetics.
+- Introduce %%license.
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.52-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 3748ba1..eb02831 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e9d6c33a2aac9789036afb4cc23ed8eb  File-Remove-1.52.tar.gz
+b12cd5a311bcfd96fc08bdcd781a9193  File-Remove-1.55.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-File-Remove.git/commit/?h=master=5717bdf840a3ca1bdaa9c0aa64e4d26127641633
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

corsepiu uploaded File-Remove-1.55.tar.gz for perl-File-Remove

[notifications]

b12cd5a311bcfd96fc08bdcd781a9193  File-Remove-1.55.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-File-Remove/File-Remove-1.55.tar.gz/md5/b12cd5a311bcfd96fc08bdcd781a9193/File-Remove-1.55.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-RRD-Simple (perl-RRD-Simple-1.44-23.fc24). "Use %global rather than %define"

[notifications]

From 7aece5ecd8df429463bb494063e583b071ec7f7a Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 12 Jan 2016 16:13:16 +
Subject: Use %global rather than %define

---
 perl-RRD-Simple.spec | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/perl-RRD-Simple.spec b/perl-RRD-Simple.spec
index ec72fb9..0163044 100644
--- a/perl-RRD-Simple.spec
+++ b/perl-RRD-Simple.spec
@@ -3,7 +3,7 @@
 
 Name:  perl-RRD-Simple
 Version:   1.44
-Release:   22%{?dist}
+Release:   23%{?dist}
 Summary:   Simple interface to create and store data in RRD files
 Group: Development/Libraries
 License:   ASL 2.0
@@ -12,6 +12,9 @@ Source0:  
http://search.cpan.org/CPAN/authors/id/N/NI/NICOLAW/RRD-Simple-%{versio
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch: noarch
 # Module Build
+BuildRequires: coreutils
+BuildRequires: findutils
+BuildRequires: make
 BuildRequires: perl
 BuildRequires: perl(Config)
 BuildRequires: perl(Module::Build)
@@ -68,14 +71,14 @@ if you do not need to, nor want to, bother defining custom 
RRA definitions.
 # Apply provides/requires filters
 %if %{rpm49}
 %global provfilt /bin/sh -c "%{docfilt} | %{__perllib_provides} | %{verfilt}"
-%define __perllib_provides %{provfilt}
+%global __perllib_provides %{provfilt}
 %global reqfilt /bin/sh -c "%{docfilt} | %{__perllib_requires}"
-%define __perllib_requires %{reqfilt}
+%global __perllib_requires %{reqfilt}
 %else
 %global provfilt /bin/sh -c "%{docfilt} | %{__perl_provides} | %{verfilt}"
-%define __perl_provides %{provfilt}
+%global __perl_provides %{provfilt}
 %global reqfilt /bin/sh -c "%{docfilt} | %{__perl_requires}"
-%define __perl_requires %{reqfilt}
+%global __perl_requires %{reqfilt}
 %endif
 
 %build
@@ -109,6 +112,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/RRD::Simple::Examples.3*
 
 %changelog
+* Tue Jan 12 2016 Paul Howarth  - 1.44-23
+- Use %%global rather than %%define
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.44-22
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-RRD-Simple.git/commit/?h=perl-RRD-Simple-1.44-23.fc24=7aece5ecd8df429463bb494063e583b071ec7f7a
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[389-devel] Prereview for ticket #48402 , required by ticket #48380 SynRepl does not handle database re-initialization properly

[Ludwig Krispenz]

Ticket 48380 requires that sync repl handles database reinitializations 
properly, to be able to determine if cookies are presented are valid.
To achieve this plugins need to be able to detcet if the database is 
imported or restored and this is tarcked in ticket 48402.


Before implementing a fix, I would like to get feedback on the design: 
http://www.port389.org/docs/389ds/design/detect-startup-after-import-or-restore.html


Thanks,
Ludwig
--
389-devel mailing list
389-devel@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

jplesnik changed perl-sig's 'watchbugzilla' permission on perl-Object-Remote (master) to 'Approved'

[notifications]

jplesnik changed perl-sig's 'watchbugzilla' permission on perl-Object-Remote 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Object-Remote/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jplesnik changed perl-sig's 'watchcommits' permission on perl-Object-Remote (master) to 'Approved'

[notifications]

jplesnik changed perl-sig's 'watchcommits' permission on perl-Object-Remote 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Object-Remote/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata pushed to perl-PAR-Packer (master). "1.029 bump"

[notifications]

From 021e252bfd6a8a06443cd7b15513c75528b57481 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= 
Date: Wed, 13 Jan 2016 12:32:50 +0100
Subject: 1.029 bump

---
 .gitignore   | 1 +
 perl-PAR-Packer.spec | 7 +--
 sources  | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index 323dafc..bf8461f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,4 @@ PAR-Packer-1.005.tar.gz
 /PAR-Packer-1.025.tar.gz
 /PAR-Packer-1.026.tar.gz
 /PAR-Packer-1.028.tar.gz
+/PAR-Packer-1.029.tar.gz
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index 07bace7..20d5225 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,5 +1,5 @@
 Name:   perl-PAR-Packer
-Version:1.028
+Version:1.029
 Release:1%{?dist}
 Summary:PAR Packager
 License:GPL+ or Artistic
@@ -129,7 +129,7 @@ fi
 /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
 
 %files
-%doc AUTHORS Changes README TODO
+%doc AUTHORS Changes README
 %{perl_vendorlib}/*
 %{_bindir}/par.pl
 %{_bindir}/parl
@@ -146,6 +146,9 @@ fi
 %{_datadir}/icons/hicolor/32x32/apps/tkpp.gif
 
 %changelog
+* Wed Jan 13 2016 Petr Šabata  - 1.029-1
+- 1.029 bump
+
 * Thu Nov 19 2015 Petr Šabata  - 1.028-1
 - 1.028 bump
 
diff --git a/sources b/sources
index 26c405b..b112fa5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8fe37f242f6633558266b3575c5e200e  PAR-Packer-1.028.tar.gz
+51ba75d7e0cd72d0b0bf753a196f5952  PAR-Packer-1.029.tar.gz
-- 
cgit v0.11.2



http://pkgs.fedoraproject.org/cgit/perl-PAR-Packer.git/commit/?h=master=021e252bfd6a8a06443cd7b15513c75528b57481
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

psabata uploaded PAR-Packer-1.029.tar.gz for perl-PAR-Packer

[notifications]

51ba75d7e0cd72d0b0bf753a196f5952  PAR-Packer-1.029.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-PAR-Packer/PAR-Packer-1.029.tar.gz/md5/51ba75d7e0cd72d0b0bf753a196f5952/PAR-Packer-1.029.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org