Heads up: F23 products/spins, weak rpm dependencies, and you
In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. This has implications for spin kickstarts: the set of packages included in media derived from a kickstart will be a subset of the packages you would see installed by passing the kickstart package/group list to dnf. As a result, any packages that you want to see included on the generated media must be either explicitly listed in the kickstart, or brought in with Requires: from another package. Technically this is not different from previous Fedora releases, but it is different from what you might get from using F23's dnf to compute a package list. Product and spin kickstart maintainers are advised to double-check the package manifests for the produced media to ensure all packages they want included actually are included. - ajax ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
[389-devel] please review: Ticket 48215 - verify_db.pl doesn't verify DB files specified by -a option
https://fedorahosted.org/389/ticket/48215 https://fedorahosted.org/389/attachment/ticket/48215/0001-Ticket-48215-verify_db.pl-doesn-t-verify-DB-specifie.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #48228: wrong password check if passwordInHistory is decreased.
https://fedorahosted.org/389/ticket/48228 https://fedorahosted.org/389/attachment/ticket/48228/0001-Ticket-48228-wrong-password-check-if-passwordInHisto.patch https://fedorahosted.org/389/attachment/ticket/48228/0002-Ticket-48228-CI-test-added-test-cases-for-ticket-482.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: ncurses update to 6.0
On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote: On 4 August 2015 at 04:33, Miroslav Lichvar mlich...@redhat.com wrote: As for updating the ncurses package, my current plan is to build the libs in both ABIs (so there are four builds total with the wide and narrow versions), use the ncurses-libs subpackage for the new ABI 6 libs and create a new subpackage for ABI 5 libs. What would be a good name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, or something else? Are you looking to do this for F23 branch and rawhide or just rawhide and have it land in F24 when it is ready? Or is that still to be determined. I was thinking about doing this in rawhide only with no ncurses-specific rebuilds. After the next mass rebuild everything that didn't FTBFS should be using the ABI 6 libs. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
On Wed, Aug 5, 2015 at 12:34 AM, Jason L Tibbitts III ti...@math.uh.edu wrote: The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. I have a bug report about the macros. Where should I file it, FPC ticket or Bugzilla against the python* packages that ship the affected macro files? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-08-05)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-08-05 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic 1455 F23 System Wide Change: Standardized Passphrase Policy .fesco 1455 https://fedorahosted.org/fesco/ticket/1455 #topic 1463 upgrades for F23 and beyond .fesco 1463 https://fedorahosted.org/fesco/ticket/1463 #topic #1466 non-responsive maintainer exception process for skottler .fesco 1466 https://fedorahosted.org/fesco/ticket/1466 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 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/fesco, 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Boost updated to 1.58.0 in rawhide and f23
On 31/07/15 14:49 +0100, Richard W.M. Jones wrote: Ceph failed to build with some impenetrable C++ error: In file included from /usr/include/boost/optional/optional.hpp:28:0, from /usr/include/boost/optional/optional_io.hpp:19, from ./include/encoding.h:289, from ./include/uuid.h:8, from ./include/types.h:21, from mon/OSDMonitor.h:28, from mon/OSDMonitor.cc:21: /usr/include/boost/variant/get.hpp: In instantiation of 'typename boost::add_referenceconst U::type boost::strict_get(const boost::variantT0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19) [with U = int; T0 = std::__cxx11::basic_stringchar; T1 = bool; T2 = long long int; T3 = double; T4 = std::vectorstd::__cxx11::basic_stringchar ; T5 = boost::detail::variant::void_; T6 = boost::detail::variant::void_; T7 = boost::detail::variant::void_; T8 = boost::detail::variant::void_; T9 = boost::detail::variant::void_; T10 = boost::detail::variant::void_; T11 = boost::detail::variant::void_; T12 = boost::detail::variant::void_; T13 = boost::detail::variant::void_; T14 = boost::detail::variant::void_; T15 = boost::detail::variant::void_; T16 = boost::detail::variant::void_; T17 = boost::detail::variant::void_; T18 = boost::detail::variant::void_; T19 = boost::detail::variant::void_; typename boost::add_referenceconst U::type = const int]': /usr/include/boost/variant/get.hpp:299:25: required from 'typename boost::add_referenceconst U::type boost::get(const boost::variantT0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19) [with U = int; T0 = std::__cxx11::basic_stringchar; T1 = bool; T2 = long long int; T3 = double; T4 = std::vectorstd::__cxx11::basic_stringchar ; T5 = boost::detail::variant::void_; T6 = boost::detail::variant::void_; T7 = boost::detail::variant::void_; T8 = boost::detail::variant::void_; T9 = boost::detail::variant::void_; T10 = boost::detail::variant::void_; T11 = boost::detail::variant::void_; T12 = boost::detail::variant::void_; T13 = boost::detail::variant::void_; T14 = boost::detail::variant::void_; T15 = boost::detail::variant::void_; T16 = boost::detail::variant::void_; T17 = boost::detail::variant::void_; T18 = boost::detail::variant::void_; T19 = boost::detail::variant::void_; typename boost::add_referenceconst U::type = const int]' ./common/cmdparse.h:47:26: required from 'bool cmd_getval(CephContext*, const cmdmap_t, std::__cxx11::string, T) [with T = int; cmdmap_t = std::mapstd::__cxx11::basic_stringchar, boost::variantstd::__cxx11::basic_stringchar, bool, long long int, double, std::vectorstd::__cxx11::basic_stringchar ; std::__cxx11::string = std::__cxx11::basic_stringchar]' mon/OSDMonitor.cc:3002:54: required from here /usr/include/boost/variant/get.hpp:195:5: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILUREfalse' BOOST_STATIC_ASSERT_MSG( ^ Makefile:15876: recipe for target 'mon/OSDMonitor.lo' failed -- Any ideas on that one? This blocks qemu and all the rest of the virt stack. It's a static assertion failure. Line 195 in boost/variant/get.hpp is BOOST_STATIC_ASSERT_MSG( (boost::detail::variant::holds_elementboost::variant BOOST_VARIANT_ENUM_PARAMS(T) , const U ::value), boost::variant does not contain specified type U, call to boost::getU(const boost::variantT...*) will always return NULL ); Which is pretty descriptive. It's the same problem as described at https://lists.fedoraproject.org/pipermail/devel/2015-July/212789.html i.e. caused by the breaking change to Boost.Variant, which can be fixed by changing the source or defining a macro to use relaxed_get() intstead of strict_get(). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote: Either %config or %config(noreplace) can cause problems during update. Neither one is completely safe with regard to breaking a program at runtime. It can be necessary to switch from %config(noreplace) to %config, or vice versa, in updates. FWIW rpm-ostree (really ostree) consistently uses the equivalent of %config(noreplace) always for everything in /etc, regardless of what the input RPM says. I think global predictability and consistency here is superior to per-package choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
Hi folks,
I can't reproduce this issue.
$ sudo dnf install
https://kojipkgs.fedoraproject.org//packages/blktap/3.0.0/3.fc23.git0.9.2/x86_64/blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/blktap/3.0.0/3.fc23.git0.9.2/x86_64/blktap-3.0.0-3.fc23.git0.9.2.x86_64.rpm
-C
Last metadata expiration check performed 1:22:41 ago on Wed Aug 5
11:51:08 2015.
The downloaded packages were saved in cache till the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'
Error: nothing provides blktap(x86-64) =
%{epoch}:3.0.0-3.fc23.git0.9.2 needed by
blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages)
Please let us know:
$ rpm -q libsolv hawkey dnf
$ sudo dnf install blktap-devel --debugsolver (it will create
'debugdata' directory which we want)
On Tue, Aug 4, 2015 at 11:47 PM, Michael Schwendt mschwe...@gmail.com wrote:
On Fri, 31 Jul 2015 03:51:12 -0400, Christopher Meng wrote:
Broken deps for x86_64
Surprisingly, the report is incomplete and doesn't find some unresolvable
dependencies. DNF doesn't either.
An undefined %{epoch} in a dependency is not found. This has been reported
to blktap: https://bugzilla.redhat.com/1248912
Note how DNF tells Dependencies resolved, but later fails during the
transaction check. How could it resolve the unexpanded %{epoch} earlier?
I'm confused as well, I never saw any problem in this package before.
Obviously. ;) If the Rawhide broken deps report had found it, breakage could
have been avoided.
A different try:
https://fedorahosted.org/rel-eng/ticket/6225
Or file it in the infrastructure tracker instead? I don't know. There are lots
of active tickets in both.
And what about DNF? Are the DNF developers interesting in looking into
it, too? Or is by design that the Dependencies resolved step doesn't
discover the unresolvable dependency?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Wed, 5 Aug 2015 13:47:42 +0300, Igor Gnatenko wrote:
I can't reproduce this issue.
Believe me, you can. You only created a completely different test-case,
which may not suffer from the same problem.
How to reproduce:
1. Use Fedora 22.
2. dnf install blktap-devel --disablerepo=updates-testing
It is important to not pull in the fixed test update for blktap.
What happens?
Dependency problem is only found during transaction check, i.e. after
the Dependencies resolved step and after downloading packages.
# dnf install blktap-devel --disablerepo=updates-testing
Last metadata expiration check performed 0:42:49 ago on Wed Aug 5 12:11:33
2015.
Dependencies resolved.
PackageArch Version RepositorySize
Installing:
blktap x86_64 3.0.0-2.fc22.git0.9.2 fedora 243 k
blktap-devel x86_64 3.0.0-2.fc22.git0.9.2 fedora21 k
Transaction Summary
Install 2 Packages
Total download size: 263 k
Installed size: 773 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): blktap-devel-3.0.0-2.fc22.git0.9.2.x86_6 4.1 kB/s | 21 kB 00:05
(2/2): blktap-3.0.0-2.fc22.git0.9.2.x86_64.rpm 46 kB/s | 243 kB 00:05
Total36 kB/s | 263 kB 00:07
Running transaction check
Error: transaction check vs depsolve:
blktap(x86-64) = %{epoch}:3.0.0-2.fc22.git0.9.2 is needed by
blktap-devel-3.0.0-2.fc22.git0.9.2.x86_64
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the
issue.
The downloaded packages were saved in cache till the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'
# rpm -q libsolv hawkey dnf
libsolv-0.6.11-1.fc22.x86_64
hawkey-0.5.9-3.fc22.x86_64
dnf-1.0.2-3.fc22.noarch
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Wed, Aug 5, 2015 at 1:58 PM, Michael Schwendt mschwe...@gmail.com wrote:
On Wed, 5 Aug 2015 13:47:42 +0300, Igor Gnatenko wrote:
I can't reproduce this issue.
Believe me, you can. You only created a completely different test-case,
which may not suffer from the same problem.
How to reproduce:
1. Use Fedora 22.
2. dnf install blktap-devel --disablerepo=updates-testing
Can you send debugdata from dnf?
# dnf install blktap-devel --disablerepo=updates-testing --debugsolver
and then archive 'debugdata' directory.
It is important to not pull in the fixed test update for blktap.
What happens?
Dependency problem is only found during transaction check, i.e. after
the Dependencies resolved step and after downloading packages.
# dnf install blktap-devel --disablerepo=updates-testing
Last metadata expiration check performed 0:42:49 ago on Wed Aug 5 12:11:33
2015.
Dependencies resolved.
PackageArch Version Repository
Size
Installing:
blktap x86_64 3.0.0-2.fc22.git0.9.2 fedora 243
k
blktap-devel x86_64 3.0.0-2.fc22.git0.9.2 fedora21
k
Transaction Summary
Install 2 Packages
Total download size: 263 k
Installed size: 773 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): blktap-devel-3.0.0-2.fc22.git0.9.2.x86_6 4.1 kB/s | 21 kB 00:05
(2/2): blktap-3.0.0-2.fc22.git0.9.2.x86_64.rpm 46 kB/s | 243 kB 00:05
Total36 kB/s | 263 kB 00:07
Running transaction check
Error: transaction check vs depsolve:
blktap(x86-64) = %{epoch}:3.0.0-2.fc22.git0.9.2 is needed by
blktap-devel-3.0.0-2.fc22.git0.9.2.x86_64
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the
issue.
The downloaded packages were saved in cache till the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'
# rpm -q libsolv hawkey dnf
libsolv-0.6.11-1.fc22.x86_64
hawkey-0.5.9-3.fc22.x86_64
dnf-1.0.2-3.fc22.noarch
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Wed, 5 Aug 2015 14:00:59 +0300, Igor Gnatenko wrote: How to reproduce: 1. Use Fedora 22. 2. dnf install blktap-devel --disablerepo=updates-testing Can you send debugdata from dnf? # dnf install blktap-devel --disablerepo=updates-testing --debugsolver and then archive 'debugdata' directory. https://mschwendt.fedorapeople.org/tmp/debugdata-undef-epoch-problem.tar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On Wed, 05 Aug 2015 06:37:41 -0400, Colin Walters wrote: On Tue, Aug 4, 2015, at 01:38 PM, Michael Schwendt wrote: Either %config or %config(noreplace) can cause problems during update. Neither one is completely safe with regard to breaking a program at runtime. It can be necessary to switch from %config(noreplace) to %config, or vice versa, in updates. FWIW rpm-ostree (really ostree) consistently uses the equivalent of %config(noreplace) always for everything in /etc, regardless of what the input RPM says. I think global predictability and consistency here is superior to per-package choice. MUST: Admin must painstakingly review and handle all .rpmnew/.rpmsave files, which are created when installing an update. Aiming for consistency, I agree with that. Predictability? Nah. Both %config and %config(noreplace) bear risks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-23 Branched report: 20150805 changes
Compose started at Wed Aug 5 07:15:03 UTC 2015 Broken deps for armhfp -- [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [aws] aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so [deltaspike] deltaspike-test-utils-1.2.1-3.fc23.noarch requires mvn(org.jboss.arquillian.container:arquillian-container-test-spi) [dpm-contrib-admintools] dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires MySQL-python(armv7hl-32) [gammaray] gammaray-qt5-2.2.1-10.fc23.armv7hl requires qt5-qtbase(armv7hl-32) = 0:5.4.2 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-7.fc23.armv7hl requires ghc(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae) ghc-hjsmin-devel-0.1.4.7-7.fc23.armv7hl requires ghc-devel(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae) [gnome-python2] gnome-python2-bonobo-2.28.1-16.fc23.armv7hl requires pyorbit(armv7hl-32) = 0:2.0.1 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.11.0-0.3.gitc7ad79d3.fc23.armv7hl requires libgnome-desktop-3.so.10 [gtksourceview-sharp] gtksourceview-sharp-2.0.12-24.fc23.armv7hl requires gtksourceview [hadoop] hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) [hawaii-shell] hawaii-shell-0.3.0-3.fc22.armv7hl requires libqtaccountsservice-qt5.so.0.1.2 [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [klavaro] klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0 [mariadb-galera] 1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera = 0:25.3.3 [mesos] mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8 python-mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8 [moon-buggy] moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0 [ncbi-blast+] ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxformat.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxcleanup.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libvalid.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libpubmed.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmlacli.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmla.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmedlars.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libgbseq.so [netbeans-platform] 1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura = 0:1.9.3 [nodejs-grunt-contrib-copy] nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) 0:0.2 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) = 0:0.1.0 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) = 0:0.5.1 [nodejs-grunt-saucelabs]
Re: Boost updated to 1.58.0 in rawhide and f23
On Thursday, 23 July 2015 at 19:21, Jonathan Wakely wrote:
On 23/07/15 14:27 +0200, David Tardon wrote:
Hi,
On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote:
Any problems rebuilding either open a bug or feel free to email me or
ping me on IRC (my freenode nick is 'redi') and I'll be happy to help.
This is a work-in-progress list of FTBFS packages:
* Build failures:
- F23 + Rawhide
mkvtoolnix
For mkvtoolnix I get this error in rawhide:
In file included from ./src/mkvtoolnix-gui/util/files_drag_drop_widget.h:6:0,
from src/mkvtoolnix-gui/util/files_drag_drop_widget.moc:9:
src/mkvtoolnix-gui/util/files_drag_drop_handler.h:12:44: error: expected
class-name before '{' token
class FilesDragDropHandler: public QObject {
^
That seems to be another missing header (as with rhbz1234405) not a
Boost problem.
This is fixed upstream. I've updated to 8.2.0 for f23+.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote: On Fri, 17 Jul 2015 17:28:48 + Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383] 'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap a Fedora chroot. The only snag is that --nogpg is often recommended, because fedora-repos only provides the GPG keys for the current and next release. It would be convenient (and safe!) to provide keys for past and future releases, so such bootstrapping can be done without either importing the keys manually and/or using --nogpg. I thought I'd ask here first: is there a strong reason *not* to include those keys? So, I missed this thread, but saw it from the bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1246701 Several things here: * If we ship gpg keys for old eol Fedora releases, aren't we encouraging people to setup things we no longer support? I never asked for keys from EOL releases. I think keys should be removed after EOL. * If we only ship supported releases in each fedora-repos package, it means more churn for that package for everyone as when a release goes EOL we would need to push a new update that removes the old EOL key. Is everyone the users or they maintainers of fedora-repos.rpm? The churn is really tiny: the package is small, and this happens only twice a year, so I dont' think users will notice or care. As for the maintainers: I know it is a bit of extra work. I'm trying to ask nicely :) * As till pointed out, mock seems to already carry these keys, so some coordination here seems like a good idea no matter what we do. ;) Yeah. One issue I see is that mock seems to be always trailing with the updates. Mock in F22 now has /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary The version in updates-testing removes keys for F19 and F20, and adds keys for F23. It has chroot definitions to match those keys. *If* mock was relying on fedora-repos to carry they keys, it would be possible to have chroots without a matching key. I don't know if that would be good (EOL chroots stop working as expected) or bad (EOL chroots stop working unexpectedly). I disagree that including the keys for EOL'd releases counts as encouraging people to use old stuff. If someone has a reason to be building RPMs for something way-old, I think it'd be nice for us to keep those GPG keys available for them. Speaking only for myself, whenever I have to build something for a very old box, the last thing I want is mock giving me grief about not having a GPG key that old. * Can you describe the use case here a bit more? Why wouldn't you use mock (which has the keys already) to make a chroot? I want to use dnf to create containers, e.g. for running with systemd-nspawn. Sometimes for installation of Fedora on a disk to bootstrap a new machine. In either way, it is a one-time operation where the result is permanent. mock is about repeatedly creating chroots tailored for rpm building... The underlying installation mechanism is pretty much the same, but that's about it. Zbyszek -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: F23 products/spins, weak rpm dependencies, and you
In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. This has implications for spin kickstarts: the set of packages included in media derived from a kickstart will be a subset of the packages you would see installed by passing the kickstart package/group list to dnf. As a result, any packages that you want to see included on the generated media must be either explicitly listed in the kickstart, or brought in with Requires: from another package. Technically this is not different from previous Fedora releases, but it is different from what you might get from using F23's dnf to compute a package list. Product and spin kickstart maintainers are advised to double-check the package manifests for the produced media to ensure all packages they want included actually are included. - ajax ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Wed, Aug 5, 2015 at 8:41 AM, Ryan S. Brown rya...@redhat.com wrote: On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote: On Fri, 17 Jul 2015 17:28:48 + Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383] 'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap a Fedora chroot. The only snag is that --nogpg is often recommended, because fedora-repos only provides the GPG keys for the current and next release. It would be convenient (and safe!) to provide keys for past and future releases, so such bootstrapping can be done without either importing the keys manually and/or using --nogpg. I thought I'd ask here first: is there a strong reason *not* to include those keys? So, I missed this thread, but saw it from the bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1246701 Several things here: * If we ship gpg keys for old eol Fedora releases, aren't we encouraging people to setup things we no longer support? I never asked for keys from EOL releases. I think keys should be removed after EOL. * If we only ship supported releases in each fedora-repos package, it means more churn for that package for everyone as when a release goes EOL we would need to push a new update that removes the old EOL key. Is everyone the users or they maintainers of fedora-repos.rpm? The churn is really tiny: the package is small, and this happens only twice a year, so I dont' think users will notice or care. As for the maintainers: I know it is a bit of extra work. I'm trying to ask nicely :) * As till pointed out, mock seems to already carry these keys, so some coordination here seems like a good idea no matter what we do. ;) Yeah. One issue I see is that mock seems to be always trailing with the updates. Mock in F22 now has /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary The version in updates-testing removes keys for F19 and F20, and adds keys for F23. It has chroot definitions to match those keys. *If* mock was relying on fedora-repos to carry they keys, it would be possible to have chroots without a matching key. I don't know if that would be good (EOL chroots stop working as expected) or bad (EOL chroots stop working unexpectedly). I disagree that including the keys for EOL'd releases counts as encouraging people to use old stuff. If someone has a reason to be building RPMs for something way-old, I think it'd be nice for us to keep those GPG keys available for them. Speaking only for myself, whenever I have to build something for a very old box, the last thing I want is mock giving me grief about not having a GPG key that old. * Can you describe the use case here a bit more? Why wouldn't you use mock (which has the keys already) to make a chroot? I want to use dnf to create containers, e.g. for running with systemd-nspawn. Sometimes for installation of Fedora on a disk to bootstrap a new machine. In either way, it is a one-time operation where the result is permanent. mock is about repeatedly creating chroots tailored for rpm building... The underlying installation mechanism is pretty much the same, but that's about it. Zbyszek -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct As someone who is regularly using mock to build RPMs for various Fedora releases for $DAYJOB as well as for packages that I submit to Fedora Project, I would prefer if the ability to build RPMs for older releases is preserved (even EOL ones). As for the container things, it'd be interesting if mock could use DNF+nspawn for that work in the future, and if that means splitting out GPG keys and such into a package that both DNF and mock can use, that would be great. I personally don't think that having mock being able to build for older releases would encourage the view that Fedora supports older releases. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, Aug 5, 2015 at 10:38 AM, Adam Jackson a...@redhat.com wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. This has implications for spin kickstarts: the set of packages included in media derived from a kickstart will be a subset of the packages you would see installed by passing the kickstart package/group list to dnf. As a result, any packages that you want to see included on the generated media must be either explicitly listed in the kickstart, or brought in with Requires: from another package. Technically this is not different from previous Fedora releases, but it is different from what you might get from using F23's dnf to compute a package list. Product and spin kickstart maintainers are advised to double-check the package manifests for the produced media to ensure all packages they want included actually are included. - ajax ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Are the compose tools going to match DNF's behavior in package dependency resolution in the near future? -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, Aug 5, 2015 at 11:33 AM, Neal Gompa ngomp...@gmail.com wrote: On Wed, Aug 5, 2015 at 10:38 AM, Adam Jackson a...@redhat.com wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. This has implications for spin kickstarts: the set of packages included in media derived from a kickstart will be a subset of the packages you would see installed by passing the kickstart package/group list to dnf. As a result, any packages that you want to see included on the generated media must be either explicitly listed in the kickstart, or brought in with Requires: from another package. Technically this is not different from previous Fedora releases, but it is different from what you might get from using F23's dnf to compute a package list. Product and spin kickstart maintainers are advised to double-check the package manifests for the produced media to ensure all packages they want included actually are included. Are the compose tools going to match DNF's behavior in package dependency resolution in the near future? When they are ported to use DNF they will. That isn't going to be for F23 though. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, 2015-08-05 at 11:33 -0400, Neal Gompa wrote: On Wed, Aug 5, 2015 at 10:38 AM, Adam Jackson a...@redhat.com wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. Are the compose tools going to match DNF's behavior in package dependency resolution in the near future? There are beta patches for yum to support recommends/suggests on install, which are being evaluated, they'll hopefully get in before F23 GA ... but there's no guarantees, and even then match DNF's behavior is not how anyone would describe it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On 08/04/2015 05:12 PM, Bill Nottingham wrote: Paul W. Frields (sticks...@gmail.com) said: Here's my perspective as an i686 Fedora user... I have a box (2009-ish) that's in use as a file/backup server. I have 3 i686 boxen. 2 are 2009-ish atom-netbook, one is a 2000-ish PIII-desktop. As such, I don't spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs the prereleases until beta or later time. If something breaks, I'll look at it, send some feedback, update it as necessary, and back off to a working version. And historically, it *hasn't* broken. But, if it did break that hard... would I spend a month digging into the kernel source and bisecting to try and find a fix? Or would I spend the $100-120 to slap a new motherboard in it and install the x86_64 version? I'd like to say I'd do the former. But realisitically it's the latter. And I wonder how much of the i686 Fedora-using community is in the same boat. ACK. I would switch the 2009-atoms to Windows (They are dual boot with Win) and the PIII to a different Linux distro. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On Tue, 2015-08-04 at 11:12 -0400, Bill Nottingham wrote: Here's my perspective as an i686 Fedora user... I have a box (2009-ish) that's in use as a file/backup server. As such, I don't spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs the prereleases until beta or later time. If something breaks, I'll look at it, send some feedback, update it as necessary, and back off to a working version. And historically, it *hasn't* broken. But, if it did break that hard... would I spend a month digging into the kernel source and bisecting to try and find a fix? Or would I spend the $100-120 to slap a new motherboard in it and install the x86_64 version? I'd like to say I'd do the former. But realisitically it's the latter. And I wonder how much of the i686 Fedora-using community is in the same boat. So we have a product that is installed on about ~80 netbooks running i386-PAE kernels. They are now running f21 I think. I considered updating them but they are offline machines for nearly their entire life. I had contemplated putting CentOS 7 but there is no i386 for that. I would imagine that the hardware would be replaced by newer netbooks that handle x64. If they can't be they'll run EOL'd versions of fedora till death. If I can update them eventually it wouldn't matter to me if the i386 system saw less love but eventually came out. Granted if fedora dropped i386 completely I'd find a distro to use that supported it I guess if any. It wouldn't be the end of the world for me. -- Nathanael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] ucommon update
On Tue, 4 Aug 2015 18:57:20 +0200 Sandro Mani manisan...@gmail.com wrote: ok. I will transfer libzrtcpp to you. ;) You should talk to dyfet directly about sipwitch... Well I just did the non-reponsive maintainer procedure for ucommon, his other package. I suppose it is fair to assume that he'll also be unresponsive for sipwitch? Ah indeed. I've set you as the point of contact for sipwitch too. ;) Thanks for caring for these packages. kevin pgpIjaLNAz_rK.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
On Wed, 5 Aug 2015 10:11:26 +0300 Ville Skyttä ville.sky...@iki.fi wrote: On Wed, Aug 5, 2015 at 12:34 AM, Jason L Tibbitts III ti...@math.uh.edu wrote: The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. I have a bug report about the macros. Where should I file it, FPC ticket or Bugzilla against the python* packages that ship the affected macro files? I'd say a FPC ticket since they might want to look at any proposed changes, then they can file bug(s) against the macro carrying packages. kevin pgpUBCBwxk7Ak.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Tue, 4 Aug 2015 22:47:31 +0200 Michael Schwendt mschwe...@gmail.com wrote: Obviously. ;) If the Rawhide broken deps report had found it, breakage could have been avoided. A different try: https://fedorahosted.org/rel-eng/ticket/6225 Or file it in the infrastructure tracker instead? I don't know. There are lots of active tickets in both. Rawhide/branched broken dep reports use the 'spam-o-matic' script in the mash package: https://pagure.io/mash/blob/master/f/utils/spam-o-matic which in turn seems to import the yum 'repoclosure' util. So, I'd say try and duplicate it with repoclosure and then file against yum-utils? And what about DNF? Are the DNF developers interesting in looking into it, too? Or is by design that the Dependencies resolved step doesn't discover the unresolvable dependency? Of course the above is a short term thing, we should look at what we might replace spam-o-matic with that is dnf based. There is a dnf repoclosure plugin, but not sure how well it works off hand. kevin pgpa8LS3Tit0f.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, Aug 05, 2015 at 10:38:07AM -0400, Adam Jackson wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. To clarify the state of things a bit -- lorax is already using DNF (and python3) so anything creating a boot.iso or a DVD based on the boot.iso will use DNF to select the packages. livecd-creator is still yum and python2 based. I have no plans to change this, it's time for us to switch to using Anaconda via livemedia-creator so that we can keep the installation logic in one maintainable place. rel-eng is still using livecd-creator for Fedora 23. Hopefully livemedia-creator koji integration will be working for Fedora 24. In the meantime you can still use livecd-creator. Anaconda is using DNF by default and is also python3 for Fedora 23 so any package based installations will use DNF. livemedia-creator documentation is here: https://rhinstaller.github.io/lorax/livemedia-creator.html And I've written a blog post here: https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning python-ufc
Dear All, I have orphaned the python-ufc package. This package has been superceded by python-ffc, and upstream have abandoned python-ufc. FWIW, python-ffc is under review[0], but it seems the submission has been abandoned by the submitter (Fabian Abfolter). I actually tried to retire this package, but running a fedpkg retire resulted in: Could not retire package: You are not allowed to retire the package: python-ufc on branch f21, so I decided to simply orphan it, and let it be garbage collected. Cheers, Jonathan [0] https://bugzilla.redhat.com/show_bug.cgi?id=693137 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS UP] libappstream-glib update
Hi all, Next week I'm going to update to the new libappstream-glib with a soname bump in F23 and rawhide. The only deps (gnome-software and fwupd) just needs updating to the newest releases and these are my packages also. Any problems, please squeak. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning python-ufc
On Wed, Aug 05, 2015 at 05:45:59PM +0100, Jonathan Underwood wrote: Dear All, I have orphaned the python-ufc package. This package has been superceded by python-ffc, and upstream have abandoned python-ufc. FWIW, python-ffc is under review[0], but it seems the submission has been abandoned by the submitter (Fabian Abfolter). I actually tried to retire this package, but running a fedpkg retire resulted in: Could not retire package: You are not allowed to retire the package: python-ufc on branch f21, so I decided to simply orphan it, and let it be garbage collected. That's to be expected, you can only retire package on branch `under development` so currently rawhide and F23, most of the time: only rawhide. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, Aug 5, 2015 at 12:28 PM, Brian C. Lane b...@redhat.com wrote: On Wed, Aug 05, 2015 at 10:38:07AM -0400, Adam Jackson wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. To clarify the state of things a bit -- lorax is already using DNF (and python3) so anything creating a boot.iso or a DVD based on the boot.iso will use DNF to select the packages. livecd-creator is still yum and python2 based. I have no plans to change this, it's time for us to switch to using Anaconda via livemedia-creator so that we can keep the installation logic in one maintainable place. rel-eng is still using livecd-creator for Fedora 23. Hopefully livemedia-creator koji integration will be working for Fedora 24. In the meantime you can still use livecd-creator. Anaconda is using DNF by default and is also python3 for Fedora 23 so any package based installations will use DNF. livemedia-creator documentation is here: https://rhinstaller.github.io/lorax/livemedia-creator.html And I've written a blog post here: https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct What keeps us from completing livemedia-creator Koji integration for Fedora 23? And what of the state of pungi? -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, 2015-08-05 at 13:36 -0400, Neal Gompa wrote: What keeps us from completing livemedia-creator Koji integration for Fedora 23? And what of the state of pungi? Time and resources. We don't have enough of either to do it in F23. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wed, Aug 05, 2015 at 01:36:20PM -0400, Neal Gompa wrote: On Wed, Aug 5, 2015 at 12:28 PM, Brian C. Lane b...@redhat.com wrote: On Wed, Aug 05, 2015 at 10:38:07AM -0400, Adam Jackson wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. To clarify the state of things a bit -- lorax is already using DNF (and python3) so anything creating a boot.iso or a DVD based on the boot.iso will use DNF to select the packages. livecd-creator is still yum and python2 based. I have no plans to change this, it's time for us to switch to using Anaconda via livemedia-creator so that we can keep the installation logic in one maintainable place. rel-eng is still using livecd-creator for Fedora 23. Hopefully livemedia-creator koji integration will be working for Fedora 24. In the meantime you can still use livecd-creator. Anaconda is using DNF by default and is also python3 for Fedora 23 so any package based installations will use DNF. livemedia-creator documentation is here: https://rhinstaller.github.io/lorax/livemedia-creator.html And I've written a blog post here: https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct What keeps us from completing livemedia-creator Koji integration for Fedora 23? And what of the state of pungi? Time. And potential disruption due to using new things in the middle of a release. Better to wait, get this running with rawhide first. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Btrfs as default filesystem for Fedora 23?
On Tue, Jun 23, 2015 at 12:24 PM, Neal Gompa ngomp...@gmail.com wrote: Hey all, Over the last few months (since Fedora 22 beta's release), I've been using Btrfs as my daily driver filesystem across a multitude of machines. After Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few machines with fantastic success (there aren't even any scary warnings about being experimental anymore!). Admittedly, my tests have been specific to my needs (media center storage, workstations, laptops with SSDs, etc.), but it appears to work really well now. Also, with kernel 4.1 imported into rawhide, we've now got performance improvements for large (20TB) filesystems (though it's been plenty fast for my 48TB array). As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming the default in Fedora 23. At this point, I'm personally convinced that it is certainly ready and doable for F23. Perhaps other guys with more experience on this stuff could chime in with feedback/information/etc, but it feels like we should start the process to get everything ready for Btrfs being default in Fedora 23. The question now is: as a distribution, where are we on this? The tools seem to work, the filesystem appears stable, and I've not been able to cause the filesystem to corrupt itself with any kind of user error or cause it to keel over. So, what's left? Sorry I completely missed this conversation. I'm not interested in pushing btrfs into Fedora now. There is nobody to support it if things go wrong. If you want to use btrfs you can, or you can use Suse. We're finding and fixing things in our internal testing at Facebook, and the power fail testing stuff I added early this year has given me a lot of confidence in our ability to not lose all of your data due to some weird bug. In a few months we'll have switched over lots of our boxes onto btrfs so that will give us a pretty good way to keep track of stability in a production environment. After that I imagine it'll be good to go for Fedora, but that'll be somebody else's decision, I'm no longer super interested in driving anything in Fedora. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F23 products/spins, weak rpm dependencies, and you
On Wednesday, August 05, 2015 01:36:20 PM Neal Gompa wrote: On Wed, Aug 5, 2015 at 12:28 PM, Brian C. Lane b...@redhat.com wrote: On Wed, Aug 05, 2015 at 10:38:07AM -0400, Adam Jackson wrote: In Fedora 23, rpm has grown support for weak dependencies (Recommends: and Suggests: tags). However, the compose tools have not been ported to dnf/libsolv yet, which means these tags will have no effect at image compose time. To clarify the state of things a bit -- lorax is already using DNF (and python3) so anything creating a boot.iso or a DVD based on the boot.iso will use DNF to select the packages. livecd-creator is still yum and python2 based. I have no plans to change this, it's time for us to switch to using Anaconda via livemedia-creator so that we can keep the installation logic in one maintainable place. rel-eng is still using livecd-creator for Fedora 23. Hopefully livemedia-creator koji integration will be working for Fedora 24. In the meantime you can still use livecd-creator. Anaconda is using DNF by default and is also python3 for Fedora 23 so any package based installations will use DNF. livemedia-creator documentation is here: https://rhinstaller.github.io/lorax/livemedia-creator.html And I've written a blog post here: https://www.brianlane.com/creating-live-isos-with-livemedia-creator.html -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct What keeps us from completing livemedia-creator Koji integration for Fedora 23? And what of the state of pungi? pungi is python2 and yum only at this point, Brian's DVD claim is not totally correct. dnf is used to install the packages into the boot.iso but yum is used to select the packages that are included on the installation DVD and tree. but then dnf is used to do a install on the end users system. Jon Disnard is tasked with getting livemedia-creator working in koji but we will enable it in rawhide first and only consider using it for f23 if it gets done soon enough and we are sure that it works 100% Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 23 Alpha Release Candidate 1 (RC1) (mostly) Available Now!
[sorry this is late, I sent it from the wrong email address : RC2 will be landing in ~8 hours] Somewhat later than scheduled [1], Fedora 23 Alpha Release Candidate 1 (RC1) is now available for testing. Please help us complete as much of the validation testing as we can! We already know we'll need an RC2, but so far the expected change is minor (likely just dropping some packages from Server DVD). We definitely need to fill out all the Alpha tests with RC1 to find any other lurking blockers, so please help! The Cloud base i386 image is hitting a mysterious failure during compose. releng will work on it tomorrow, but if we can't fix it there's a possibility it'll simply be dropped. All other significant images should be available. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6213#comment:6 . Please see the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download- ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary All Alpha priority test cases for each of these test pages [2] must pass in order to meet the Alpha Release Criteria [3]. We are also trying to run the Beta and Final tests at this time, to try and identify later release blocker bugs as early as possible. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 23 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6213 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-23/f-23-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes for today's FESCo meeting (2015-08-05)
=== #fedora-meeting: FESCO (2015-08-05) === Meeting started by paragan at 18:00:09 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-08-05/fesco.2015-08-05-18.00.log.html . Meeting summary --- * init process (paragan, 18:00:09) * 1455 F23 System Wide Change: Standardized Passphrase Policy (paragan, 18:02:20) * LINK: https://fedorahosted.org/fesco/ticket/1455 (paragan, 18:02:20) * LINK: https://fedoraproject.org/wiki/Passphrase_policy (nirik, 18:03:12) * AGREED: : Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+7, 0, 0) (paragan, 18:13:07) * 1463 upgrades for F23 and beyond (paragan, 18:13:35) * LINK: https://fedorahosted.org/fesco/ticket/1463 (paragan, 18:13:35) * AGREED: : Accepted https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades (+7, 0, 0) (paragan, 18:19:04) * #1466 non-responsive maintainer exception process for skottler (paragan, 18:19:34) * LINK: https://fedorahosted.org/fesco/ticket/1466 (paragan, 18:19:35) * AGREED: : jwb to commit and build the 2.0.3 update to fix the CVEs (+8, 0, 0) (paragan, 18:32:56) * #1467 F23 Changes - Progress at Change Checkpoint: Completion deadline (testable) (paragan, 18:34:27) * LINK: https://fedorahosted.org/fesco/ticket/1467 (paragan, 18:34:29) * AGREED: : moving all them to f24 except these (two week atomic/layered docker images) Changes, (+5, 0, 0) (paragan, 18:53:29) * Next week's chair (paragan, 18:53:41) * no meeting next week (paragan, 18:54:53) * LINK: http://flock2015.sched.org/event/85fbdf579fa91c49ba13d45a9c1774eb (nirik, 18:56:27) * sgallagh to chair next meeting (paragan, 19:00:06) * Open Floor (paragan, 19:00:35) * LINK: https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD (dgilmore, 19:07:33) Meeting ended at 19:18:04 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * paragan (63) * nirik (53) * number80 (40) * jwb (40) * sgallagh (36) * dgilmore (34) * adamw (18) * rishi` (14) * zodbot (10) * jkurik (8) * ajax (7) * swilkerson (3) * roshi (3) * rishi (0) * thozza (0) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2015-08-06 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-08-06 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-08-06 09:00 Thu US/Pacific PDT 2015-08-06 12:00 Thu US/Eastern EDT 2015-08-06 16:00 Thu UTC - 2015-08-06 17:00 Thu Europe/London BST 2015-08-06 18:00 Thu Europe/Paris CEST 2015-08-06 18:00 Thu Europe/Berlin CEST 2015-08-06 21:30 Thu Asia/Calcutta IST --new day-- 2015-08-07 00:00 Fri Asia/Singapore SGT 2015-08-07 00:00 Fri Asia/Hong_Kong HKT 2015-08-07 01:00 Fri Asia/Tokyo JST 2015-08-07 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 = New business = #topic #555 Copylib bundling request: kwsys in castxml .fpc 555 https://fedorahosted.org/fpc/ticket/555 = 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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] rpm-4.12.90 in rawhide
On Wed, 2015-07-29 at 09:49 +0200, Vít Ondruch wrote: Dne 28.7.2015 v 18:15 Matthias Clasen napsal(a): On Tue, 2015-07-28 at 14:49 +0200, Vít Ondruch wrote: Just out of curiosity, do you have already any candidates for File Triggers? I suppose /sbin/ldconfig is one of them. Do you plan to have some F24 feature to get rid of these? Here is a list of candidates: https://fedoraproject.org/wiki/Workstation/Tasklist#filetrigger Workstation WG is keeping an eye on this. Very nice. Thank you. As a test balloon, I've now added file triggers to gdk-pixbuf2-2.31.5 -2.fc24, and librsvg2-2.40.9-3.fc24 now relies on them to get its pixbuf loader registered. Let me know if you see any problems with those updates that might be caused by the file triggers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
On Wed, Aug 5, 2015 at 7:22 PM, Kevin Fenzi ke...@scrye.com wrote: On Wed, 5 Aug 2015 10:11:26 +0300 Ville Skyttä ville.sky...@iki.fi wrote: On Wed, Aug 5, 2015 at 12:34 AM, Jason L Tibbitts III ti...@math.uh.edu wrote: The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. I have a bug report about the macros. Where should I file it, FPC ticket or Bugzilla against the python* packages that ship the affected macro files? I'd say a FPC ticket since they might want to look at any proposed changes, then they can file bug(s) against the macro carrying packages. https://fedorahosted.org/fpc/ticket/557 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] rpm-4.12.90 in rawhide
On 08/05/2015 10:02 PM, Matthias Clasen wrote: As a test balloon, I've now added file triggers to gdk-pixbuf2-2.31.5 -2.fc24, and librsvg2-2.40.9-3.fc24 now relies on them to get its pixbuf loader registered. Let me know if you see any problems with those updates that might be caused by the file triggers. I fixed up a small typo that made the gdk-pixbuf2 triggers spew errors, but besides the typo they seem to be working fine here in quick testing. Very much looking forward to using them in other packages as well! Awesome that the support is finally there in rpm. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1239777] perl-MongoDB: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1239777 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||ppi...@redhat.com Resolution|--- |DUPLICATE Last Closed||2015-08-05 04:20:21 --- Comment #6 from Petr Pisar ppi...@redhat.com --- *** This bug has been marked as a duplicate of bug 1134882 *** -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1209679] perl-MongoDB-v0.708.3.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1209679 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||ppi...@redhat.com Resolution|--- |DUPLICATE Last Closed||2015-08-05 04:21:36 --- Comment #11 from Petr Pisar ppi...@redhat.com --- *** This bug has been marked as a duplicate of bug 855072 *** -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250360] New: perl-DateTime-Format-Excel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250360 Bug ID: 1250360 Summary: perl-DateTime-Format-Excel and Trademark problem. Product: Fedora Version: rawhide Component: perl-DateTime-Format-Excel Assignee: jples...@redhat.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com This package name contain excel or Excel. but Excel is trademark. http://tsdr.uspto.gov/#caseNumber=78400429caseType=SERIAL_NOsearchType=statusSearch http://tsdr.uspto.gov/#caseNumber=85467589caseType=SERIAL_NOsearchType=statusSearch I suggest that rename package name, or contact trademark owner. Thanks -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250360] perl-DateTime-Format-Excel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250360 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Blocks||182235 (FE-Legal) --- Comment #1 from mejiko kame55-itasenpara...@y2.dion.ne.jp --- Blocking FE-legal, This is trademark problem. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250365] New: perl-Spreadsheet-ParseExcel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250365 Bug ID: 1250365 Summary: perl-Spreadsheet-ParseExcel and Trademark problem. Product: Fedora Version: rawhide Component: perl-Spreadsheet-ParseExcel Assignee: psab...@redhat.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: mpet...@mac.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com, st...@silug.org This package name contain excel or Excel. but Excel is trademark. http://tsdr.uspto.gov/#caseNumber=78400429caseType=SERIAL_NOsearchType=statusSearch http://tsdr.uspto.gov/#caseNumber=85467589caseType=SERIAL_NOsearchType=statusSearch I suggest that rename package name, or contact trademark owner. Thanks -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250365] perl-Spreadsheet-ParseExcel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250365 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Blocks||182235 (FE-Legal) --- Comment #1 from mejiko kame55-itasenpara...@y2.dion.ne.jp --- Blocking FE-Legal, This is trademark problem. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250372] New: perl-Spreadsheet-ParseExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250372 Bug ID: 1250372 Summary: perl-Spreadsheet-ParseExcel-Simple and Trademark problem. Product: Fedora Version: rawhide Component: perl-Spreadsheet-ParseExcel-Simple Assignee: psab...@redhat.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com This package name contain excel or Excel. but Excel is trademark. http://tsdr.uspto.gov/#caseNumber=78400429caseType=SERIAL_NOsearchType=statusSearch http://tsdr.uspto.gov/#caseNumber=85467589caseType=SERIAL_NOsearchType=statusSearch I suggest that rename package name, or contact trademark owner. Thanks. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250372] perl-Spreadsheet-ParseExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250372 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Blocks||182235 (FE-Legal) --- Comment #1 from mejiko kame55-itasenpara...@y2.dion.ne.jp --- Blocking FE-Legal, This is trademark problem. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250373] New: perl-Spreadsheet-WriteExcel is Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250373 Bug ID: 1250373 Summary: perl-Spreadsheet-WriteExcel is Trademark problem. Product: Fedora Version: rawhide Component: perl-Spreadsheet-WriteExcel Assignee: tcall...@redhat.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: oli...@linux-kernel.at, perl-devel@lists.fedoraproject.org, tcall...@redhat.com This package name contain excel or Excel. but Excel is trademark. http://tsdr.uspto.gov/#caseNumber=78400429caseType=SERIAL_NOsearchType=statusSearch http://tsdr.uspto.gov/#caseNumber=85467589caseType=SERIAL_NOsearchType=statusSearch I suggest that rename package name, or contact trademark owner. Thanks. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250373] perl-Spreadsheet-WriteExcel is Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250373 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Blocks||182235 (FE-Legal) --- Comment #1 from mejiko kame55-itasenpara...@y2.dion.ne.jp --- Blocking FE-Legal, This is trademark problem. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250375] perl-Spreadsheet-WriteExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250375 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Blocks||182235 (FE-Legal) --- Comment #1 from mejiko kame55-itasenpara...@y2.dion.ne.jp --- Blocking FE-Legal, This is trademark problem. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250375] New: perl-Spreadsheet-WriteExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250375 Bug ID: 1250375 Summary: perl-Spreadsheet-WriteExcel-Simple and Trademark problem. Product: Fedora Version: rawhide Component: perl-Spreadsheet-WriteExcel-Simple Assignee: psab...@redhat.com Reporter: kame55-itasenpara...@y2.dion.ne.jp QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com This package name contain excel or Excel. but Excel is trademark. http://tsdr.uspto.gov/#caseNumber=78400429caseType=SERIAL_NOsearchType=statusSearch http://tsdr.uspto.gov/#caseNumber=85467589caseType=SERIAL_NOsearchType=statusSearch I suggest that rename package name, or contact trademark owner. Thanks. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250373] perl-Spreadsheet-WriteExcel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250373 mejiko kame55-itasenpara...@y2.dion.ne.jp changed: What|Removed |Added Summary|perl-Spreadsheet-WriteExcel |perl-Spreadsheet-WriteExcel |is Trademark problem. |and Trademark problem. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-BeginLift
perl-Devel-BeginLift has broken dependencies in the F-23 tree: On x86_64: perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-BeginLift-0.001003-9.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV
perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the F-23 tree: On x86_64: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires libperl.so.5.20 On armhfp: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the F-23 tree: On x86_64: polymake-2.13-22.git20141013.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: polymake-2.13-22.git20141013.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20 On armhfp: polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the F-23 tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-POE-API-Peek
perl-POE-API-Peek has broken dependencies in the F-23 tree: On x86_64: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Method-Signatures
perl-Method-Signatures has broken dependencies in the F-23 tree: On x86_64: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the F-23 tree: On x86_64: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the F-23 tree: On x86_64: perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Carp-REPL
perl-Carp-REPL has broken dependencies in the F-23 tree: On x86_64: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On i386: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On armhfp: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-AutoBuild
perl-Test-AutoBuild has broken dependencies in the F-23 tree: On x86_64: perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CatalystX-REPL
perl-CatalystX-REPL has broken dependencies in the F-23 tree: On x86_64: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-FindRef
perl-Devel-FindRef has broken dependencies in the F-23 tree: On x86_64: perl-Devel-FindRef-1.44-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-FindRef-1.44-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Dump-Streamer
perl-Data-Dump-Streamer has broken dependencies in the F-23 tree: On x86_64: perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Catalyst
perl-Task-Catalyst has broken dependencies in the F-23 tree: On x86_64: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250528] perl-Prima-1.44 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250528 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Failed to kick off scratch build. cmd: sha256sum /var/tmp/thn-ja1rq6/100.0% return code: 1 stdout: stderr: sha256sum: /var/tmp/thn-ja1rq6/100.0%: No such file or directory -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250528] New: perl-Prima-1.44 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250528 Bug ID: 1250528 Summary: perl-Prima-1.44 is available Product: Fedora Version: rawhide Component: perl-Prima Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.44 Current version/release in rawhide: 1.43-4.fc23 URL: http://search.cpan.org/dist/Prima/ 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250532] New: perl-Text-Xslate-3.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250532 Bug ID: 1250532 Summary: perl-Text-Xslate-3.3.5 is available Product: Fedora Version: rawhide Component: perl-Text-Xslate Keywords: FutureFeature, Triaged Assignee: i...@cicku.me Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: i...@cicku.me, perl-devel@lists.fedoraproject.org Latest upstream release: 3.3.5 Current version/release in rawhide: 3.3.4-1.fc23 URL: http://search.cpan.org/dist/Text-Xslate/ 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250532] perl-Text-Xslate-3.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250532 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Failed to kick off scratch build. cmd: spectool -g /var/tmp/thn-sXjU5I/perl-Text-Xslate.spec return code: 22 stdout: Getting http://www.cpan.org/authors/id/G/GF/GFUJI/Text-Xslate-3.3.5.tar.gz to ./Text-Xslate-3.3.5.tar.gz stderr: % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV
perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree: On x86_64: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires libperl.so.5.20 On armhfp: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-FindRef
perl-Devel-FindRef has broken dependencies in the rawhide tree: On x86_64: perl-Devel-FindRef-1.44-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-FindRef-1.44-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the rawhide tree: On x86_64: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the rawhide tree: On x86_64: polymake-2.13-22.git20141013.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: polymake-2.13-22.git20141013.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20 On armhfp: polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CatalystX-REPL
perl-CatalystX-REPL has broken dependencies in the rawhide tree: On x86_64: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Carp-REPL
perl-Carp-REPL has broken dependencies in the rawhide tree: On x86_64: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On i386: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On armhfp: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Dump-Streamer
perl-Data-Dump-Streamer has broken dependencies in the rawhide tree: On x86_64: perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Method-Signatures
perl-Method-Signatures has broken dependencies in the rawhide tree: On x86_64: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-BeginLift
perl-Devel-BeginLift has broken dependencies in the rawhide tree: On x86_64: perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-BeginLift-0.001003-9.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-AutoBuild
perl-Test-AutoBuild has broken dependencies in the rawhide tree: On x86_64: perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-POE-API-Peek
perl-POE-API-Peek has broken dependencies in the rawhide tree: On x86_64: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the rawhide tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Catalyst
perl-Task-Catalyst has broken dependencies in the rawhide tree: On x86_64: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
ppisar uploaded Prima-1.44.tar.gz for perl-Prima
efc577c1e60dc378f58b24a2e90d8aa6 Prima-1.44.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Prima/Prima-1.44.tar.gz/md5/efc577c1e60dc378f58b24a2e90d8aa6/Prima-1.44.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
ppisar pushed to perl-Prima (master). 1.44 bump
From 0f9c6c87d76ac4aec6a85e3d20b59e6241d1f282 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
Date: Wed, 5 Aug 2015 15:47:09 +0200
Subject: 1.44 bump
diff --git a/.gitignore b/.gitignore
index 4339be4..74fa322 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Prima-1.41.tar.gz
/Prima-1.42.tar.gz
/Prima-1.43.tar.gz
+/Prima-1.44.tar.gz
diff --git a/Prima-1.43-FcPatternAddDouble.patch
b/Prima-1.43-FcPatternAddDouble.patch
deleted file mode 100644
index db42ef5..000
--- a/Prima-1.43-FcPatternAddDouble.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From a06569708a2edc124c0290c68af5c17d57b22e51 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
-Date: Thu, 23 Apr 2015 09:10:21 +0200
-Subject: [PATCH] FcPatternAddDouble
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-URL: https://rt.cpan.org/Ticket/Display.html?id=103484
-
-Hi Petr,
-
-May I ask to test with another patch? This time I cannot give the
-proper one because it's too far off with all debug stuff I've added,
-but can you try something like this fix below?
-
-Signed-off-by: Petr Písař ppi...@redhat.com
-
-diff --git a/unix/xft.c b/unix/xft.c
-index 442c702..a530d37 100644
a/unix/xft.c
-+++ b/unix/xft.c
-@@ -690,7 +690,7 @@ prima_xft_font_pick( Handle self, Font * source, Font *
dest, double * size, Xft
- FcPatternAddDouble( request, FC_SIZE, *size);
- XFTdebug(FC_SIZE = %.1f, *size);
- } else {
-- FcPatternAddInteger( request, FC_SIZE, requested_font. size);
-+ FcPatternAddDouble( request, FC_SIZE, requested_font. size);
- XFTdebug(FC_SIZE = %d, requested_font. size);
- }
-} else {
---
-2.1.0
-
diff --git a/Prima-1.43-fxa_average_width_inconsistent_with_xlfd_width.patch
b/Prima-1.43-fxa_average_width_inconsistent_with_xlfd_width.patch
deleted file mode 100644
index eb3d8fb..000
--- a/Prima-1.43-fxa_average_width_inconsistent_with_xlfd_width.patch
+++ /dev/null
@@ -1,65 +0,0 @@
-From rt-cpan-org-ret...@perl.org Thu Apr 16 19:00:18 2015
-Return-Path: rt-cpan-org-ret...@perl.org
-Received: from zmta05.collab.prod.int.phx2.redhat.com (LHLO
- zmta05.collab.prod.int.phx2.redhat.com) (10.5.81.12) by
- zmail14.collab.prod.int.phx2.redhat.com with LMTP; Thu, 16 Apr 2015
- 13:00:18 -0400 (EDT)
-Received: from int-mx10.intmail.prod.int.phx2.redhat.com
(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
- by zmta05.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id
A372F17C123
- for ppi...@mail.corp.redhat.com; Thu, 16 Apr 2015 13:00:18 -0400 (EDT)
-Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com
[10.5.110.21])
- by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id t3GH0IDE022350
- for ppi...@redhat.com; Thu, 16 Apr 2015 13:00:18 -0400
-Received: from rtcpan.develooper.com (rtcpan.develooper.com [207.171.7.181])
- by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3GH0Hlj004418
- for ppi...@redhat.com; Thu, 16 Apr 2015 13:00:17 -0400
-Received: by rtcpan.develooper.com (Postfix, from userid 536)
- id 91CAE5D7; Thu, 16 Apr 2015 10:00:16 -0700 (PDT)
-Precedence: normal
-Subject: [rt.cpan.org #103484] Font tests fail with hlv fonts
-From: KARASIK via RT bug-pr...@rt.cpan.org
-Reply-To: bug-pr...@rt.cpan.org
-In-Reply-To: rt-4.0.18-23549-1428916055-238.103484-...@rt.cpan.org
-References: rt-ticket-103...@rt.cpan.org
- rt-4.0.18-23549-1428916055-238.103484-...@rt.cpan.org
-Message-ID: rt-4.0.18-29430-1429203616-1071.103484-...@rt.cpan.org
-X-RT-Loop-Prevention: rt.cpan.org
-RT-Ticket: rt.cpan.org #103484
-Managed-BY: RT 4.0.18 (http://www.bestpractical.com/rt/)
-RT-Originator: kara...@cpan.org
-To: ppi...@redhat.com
-MIME-Version: 1.0
-Content-Transfer-Encoding: 8bit
-Content-Type: text/plain; charset=utf-8
-X-RT-Original-Encoding: utf-8
-Date: Thu, 16 Apr 2015 13:00:16 -0400
-X-RedHat-Spam-Score: -1.9 (BAYES_00,SPF_PASS,URIBL_BLOCKED) 207.171.7.181
rtcpan.develooper.com 207.171.7.181 rtcpan.develooper.com
rt-cpan-org-ret...@perl.org
-X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
-X-Scanned-By: MIMEDefang 2.68 on 10.5.110.21
-Status: RO
-Content-Length: 960
-Lines: 22
-
-URL: https://rt.cpan.org/Ticket/Display.html?id=103484
-
-Hi, thanks for the report! These fonts indeed are corner cases, reporting
FXA_AVERAGE_WIDTHs inconsistent with the requested XLFD widths; I think I
adapted for this now. May I ask you
-to run the test again with the following patch and see if that works for you?
-
-Sincerely, Dmitry
-
a/unix/apc_font.c
-+++ b/unix/apc_font.c
-@@ -1291,7 +1291,10 @@ AGAIN:
-
- /* detailing width */
- if ( f- font. width == 0 || !f- flags. width) {
-- if ( XGetFontProperty( s, FXA_AVERAGE_WIDTH, v) v) {
-+if ( f- vecname font- width 0) {
-+f- font. width = font- width;
-+Fdebug(font: width = copy as is
[Bug 1250528] perl-Prima-1.44 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250528 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- ppisar's perl-Prima-1.44-1.fc24 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=675517 -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250528] perl-Prima-1.44 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250528 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Prima-1.44-1.fc24 Resolution|--- |RAWHIDE Last Closed||2015-08-05 10:26:01 -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: gpg keys of older/newer fedora versions
On 7/18/15, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I thought I'd ask here first: is there a strong reason *not* to include those keys? It's not recommended to encourage end users installing EOL releases. However a seperate package for gpg keys from EOL releases is OK. But is it worthwhile to move these keys out from mock? Thanks. -- Yours sincerely, Christopher Meng http://awk.io -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 23 Release Notes are Open!
Hello Fedora, The Fedora 22 release cycle is in full swing, and beats have been opened for the F22 Releasae Notes. Over the coming weeks, the release notes for the next version of Fedora will be assembled by Docs team writers, packageers, developers, and community members of all forms. Yeah, that's a pretty broad group. You can help - not a figurative, abstract you, but you, reader, can personally contribute to this fine periodical publication. Not a technical writer? That's OK! The most difficult part is the initial prep and research, and that's where we can use you the most. Here are some examples of ways you could contribute: - You maintain a package, and are able to update it to the next major version for F23. The new version has some long-awaited features added that users would enjoy. To signal the Docs team to write a bit about these changes, you open the release monitoring bugzilla ticket and check the fedora_requires_release_note flag. We can take it from there, but please be available for follow up questions! - You subscribe to a mailing list (one? who is this guy?) and a discussion reveals some notable change in a component of Fedora. While mailing lists are discoverable, the archives aren't one's first stop, so you forward the thread to a dedicated mailing list, relnotes-cont...@lists.fedoraproject.org. Like all Fedora's lists, you must subscribe to send - but don't worry, we'll watch the approval queue. - As a contributor to Fedora QA, you are were one of the earliest adopters of Fedora 23 as a daily driver. While testing packages and generally going about your business, you find that something has changed; the syntax or location of a config file, perhaps, or maybe the user experience of your favorite media player. Drop a note into the wiki at https://fedoraproject.org/wiki/Category:Documentation_beats and some writers will come along to write the prose and share it with the world. - You're an active member of a SIG. There are some exciting changes and additions to the packages supported by your SIG. It could be a new skychart from Astronomy, or a new mapping client from GIS, or new applications and features on the XFCE spin. You drop in to #fedora-docs on Freenode to hash it out with the Docs team (there's almost always someone there, but you might have to wait a bit for the first reply.) I'm getting long-winded now, but there's one point I want to stress. Note that none of these options said anything like Write comprehensive, gramatically correct documentation in American English that is ready for publication. If you want to participate to that degree, great! If not, don't be dissuaded. It's a huge help to have leads and requests thrown into the funnel, there are writers waiting to take it the rest of the way. -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanet...@fedoraproject.org signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1244501] perl-HTTP-Message-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1244501 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-HTTP-Message-6.10-1.fc |perl-HTTP-Message-6.10-1.fc |21 |22 --- Comment #12 from Fedora Update System upda...@fedoraproject.org --- perl-HTTP-Message-6.10-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1241727] perl-HTTP-Message-6.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1241727 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-HTTP-Message-6.10-1.fc |perl-HTTP-Message-6.10-1.fc |21 |22 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-HTTP-Message-6.10-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1242918] perl-Flickr-API-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1242918 --- Comment #10 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Failed to kick off scratch build. cmd: sha256sum /var/tmp/thn-A_kYqw/100.0% return code: 1 stdout: stderr: sha256sum: /var/tmp/thn-A_kYqw/100.0%: No such file or directory -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1242918] perl-Flickr-API-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1242918 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Flickr-API-1.16 is |perl-Flickr-API-1.17 is |available |available --- Comment #9 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.17 Current version/release in rawhide: 1.13-1.fc23 URL: http://search.cpan.org/dist/Flickr-API/ 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250756] perl-REST-Client-273 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250756 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Failed to kick off scratch build. cmd: sha256sum /var/tmp/thn-nJMyT6/100.0% return code: 1 stdout: stderr: sha256sum: /var/tmp/thn-nJMyT6/100.0%: No such file or directory -- 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250756] New: perl-REST-Client-273 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1250756 Bug ID: 1250756 Summary: perl-REST-Client-273 is available Product: Fedora Version: rawhide Component: perl-REST-Client Keywords: FutureFeature, Triaged Assignee: dd...@cpan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org Latest upstream release: 273 Current version/release in rawhide: 272-3.fc23 URL: http://search.cpan.org/dist/REST-Client/ 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 https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ncurses update to 6.0
On Aug 5, 2015 2:55 AM, Miroslav Lichvar mlich...@redhat.com wrote: On Tue, Aug 04, 2015 at 10:09:34AM -0600, Stephen John Smoogen wrote: On 4 August 2015 at 04:33, Miroslav Lichvar mlich...@redhat.com wrote: As for updating the ncurses package, my current plan is to build the libs in both ABIs (so there are four builds total with the wide and narrow versions), use the ncurses-libs subpackage for the new ABI 6 libs and create a new subpackage for ABI 5 libs. What would be a good name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, or something else? Are you looking to do this for F23 branch and rawhide or just rawhide and have it land in F24 when it is ready? Or is that still to be determined. I was thinking about doing this in rawhide only with no ncurses-specific rebuilds. After the next mass rebuild everything that didn't FTBFS should be using the ABI 6 libs. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct If you can provide both versions, I don't see a reason to not provide it in Fedora 23 branch too. We could just not force a rebuild in the branch and do that only in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
