[Bug 1412052] perl Math:: BigInt regression in ignoring white space with non-decimal numbers

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Summary|prel Math::BigInt   |perl Math::BigInt
   |regression in ignoring  |regression in ignoring
   |trailing whitespace |white space with
   ||non-decimal numbers



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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 674  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 436  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 155  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  81  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b2e637ff5a   
python-wikitcms-2.1.10-1.el7
  15  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0fa3a954b0   
borgbackup-1.0.9-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bb32162e83   
php-swiftmailer-5.4.5-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-92129d651d   
exim-4.88-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-770d2afc7d   
mingw-flac-1.3.2-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-fbb2447c6e   
php-PHPMailer-5.2.22-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-80cfb13391   
moodle-3.2.1-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3d29bf8e34   
php-ZendFramework2-2.4.11-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

fail2ban-0.9.6-2.el7
gfm-1.07-4.el7
nodejs-6.9.4-1.el7
packagedb-cli-2.14-1.el7
php-pdepend-PHP-Depend-2.4.0-1.el7
tito-0.6.9-1.el7

Details about builds:



 fail2ban-0.9.6-2.el7 (FEDORA-EPEL-2017-fc9588cf24)
 Daemon to ban hosts that cause multiple authentication errors

Update Information:

Fix fail2ban-regex with journal broken in 0.9.6-1.    Update to 0.9.6:  *
Misleading add resp. enable of (already available) jail in database, that
induced a subsequent error: last position of log file will be never retrieved
(gh-795) * Fixed a distribution related bug within
testReadStockJailConfForceEnabled   (e.g. test-cases faults on Fedora, see
gh-1353) * Fixed pythonic filters and test scripts (running via wrong python
version,   uses "fail2ban-python" now); * Fixed test case "testSetupInstallRoot"
for not default python version (also   using direct call, out of virtualenv); *
Fixed ambiguous wrong recognized date pattern resp. its optional parts (see
gh-1512); * FIPS compliant, use sha1 instead of md5 if it not allowed (see
gh-1540) * Monit config: scripting is not supported in path (gh-1556) *
`filter.d/apache-modsecurity.conf` - Fixed for newer version (one space,
gh-1626), optimized: non-greedy catch-all   replaced for safer match,
unneeded catch-all anchoring removed, non-capturing * `filter.d/asterisk.conf`
- Fixed to match different asterisk log prefix (source file: method:) *
`filter.d/dovecot.conf` - Fixed failregex ignores failures through some not
relevant info (gh-1623) * `filter.d/ignorecommands/apache-fakegooglebot` -
Fixed error within apache-fakegooglebot, that will be called   with wrong
python version (gh-1506) * `filter.d/assp.conf` - Extended failregex and
test cases to handle ASSP V1 and V2 (gh-1494) * `filter.d/postfix-sasl.conf`
- Allow for having no trailing space after 'failed:' (gh-1497) *
`filter.d/vsftpd.conf` - Optional reason part in message after FAIL LOGIN
(gh-1543) * `filter.d/sendmail-reject.conf` - removed mandatory double space
(if dns-host available, gh-1579) * filter.d/sshd.conf - recognized "Failed
publickey for" (gh-1477); - optimized failregex to match all of "Failed any-
method for ... from " (gh-1479) - eliminated possible complex
injections (on user-name resp. auth-info, see gh-1479) - optional port part
after host (see gh-1533, gh-1581)  * New Actions: - `action.d/npf.conf` for
NPF, the latest packet filter for NetBSD * New Filters: - `filter.d/mongodb-
auth.conf` for MongoDB (document-oriented NoSQL database engine)   (gh-1586,
gh-1606 and gh-1607)  * DateTemplate regexp extended with the word-end boundary,
additionally to   word-start boundary * Introduces new command "fail2ban-
python", as automatically created symlink to   python executable, where fail2ban
currently installed (resp. its modules are located): - allows to use the
same version, fail2ban currently running, e.g. in   external scripts just
via replace python with fail2ban-python:   ```diff   -#!/usr/bin/env
python   +#!/usr/bin/env fail2ban-python   ``` - always the same
pickle protocol - the same (and also guaranteed available) fail2ban modules
- simplified stand-alone install, resp. stand-alone 

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 552  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 546  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 478  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 436  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-245929d91a   
tinymce-4.5.1-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-62450e4e38   
libpng10-1.0.67-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-284a1cc356   
exim-4.88-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8c6c7bf06e   
dbus-sharp-0.7.0-16.el6 dbus-sharp-glib-0.5.0-14.el6 mono-4.2.4-9.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7d479b3940   
php-PHPMailer-5.2.22-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-50bd69   
icoutils-0.31.1-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4e597458f1   
php-ZendFramework2-2.2.10-3.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

tito-0.6.9-1.el6

Details about builds:



 tito-0.6.9-1.el6 (FEDORA-EPEL-2017-dcc4053dd7)
 A tool for managing rpm based git projects

Update Information:

Add support for --use-release when tagging.  Add support for bumping version in
Rust Cargo.toml files.  Bug, pep8, documentation fixes.

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

[Bug 1410277] perl-Net-HTTP-6.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-HTTP-6.12-1.fc26   |perl-Net-HTTP-6.12-1.fc26
   ||perl-Net-HTTP-6.12-1.fc25
 Resolution|--- |ERRATA
Last Closed||2017-01-11 02:23:10



--- Comment #13 from Fedora Update System  ---
perl-Net-HTTP-6.12-1.fc25 has been pushed to the Fedora 25 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1412052] prel Math::BigInt regression in ignoring trailing whitespace

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Version|25  |24



--- Comment #1 from Petr Pisar  ---
You are right. But I cannot find the report at upstream
. Can you point
me to your upstream bug report?

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

Re: F26 System Wide Change: GCC7

[Adam Williamson]

On Wed, 2017-01-11 at 04:17 +, Richard W.M. Jones wrote:
> On Tue, Jan 10, 2017 at 10:28:37AM +0100, Jan Kurik wrote:
> > * Other developers:
> > First few days/weeks just voluntary rebuilds using the new system gcc,
> > if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and
> > fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
> > analyze and report.
> 
> It seems like this link is broken.

Well, https://gcc.gnu.org/gcc-6/porting_to.html exists, and so does
https://gcc.gnu.org/gcc-5/porting_to.html . Presumably when the 7
porting guide is done, it'll be there.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1412052] New: prel Math:: BigInt regression in ignoring trailing whitespace

[bugzilla]

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

Bug ID: 1412052
   Summary: prel Math::BigInt regression in ignoring trailing
whitespace
   Product: Fedora
   Version: 25
 Component: perl-Math-BigInt
  Severity: high
  Assignee: ppi...@redhat.com
  Reporter: stew...@linux.vnet.ibm.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Description of problem:
The Math::BigInt manual states that leading and trailing whitespace is
ignored, and in fact this has been the behaviour for many years.

However, in recent Math::BigInt (that has shipped in Linux
distributions... e.g. Fedora 25), this behaviour is broken, which breaks
our tools that rely on this.

With Math::BigInt 1.999727:

'use Math::BigInt; print Dumper(Math::BigInt->new("0x10\n\t\t\t"));';
$VAR1 = bless( {
 'sign' => 'NaN',
 'value' => [
  0
]
   }, 'Math::BigInt' );

With Math::BigInt 1.9993:
'use Math::BigInt; print Dumper(Math::BigInt->new("0x10\n\t\t\t"));';
$VAR1 = bless( {
 'sign' => '+',
 'value' => [
  16
]
   }, 'Math::BigInt' );

The first version to exhibit this buggy behaviour was 1.999712, with
1.999710 and 1.9997_11 both not having the bug. All versions after
1.999712, including the latest, 1.999807 exhibit the bug.

Version-Release number of selected component (if applicable):
perl-Math-BigInt-1.9997.27-1.fc25.noarch

How reproducible:
100%

Steps to Reproduce:
1. Math::BigInt->new("0x10\n\t\t\t")

Actual results:
print Dumper(Math::BigInt->new("0x10\n\t\t\t"));';
$VAR1 = bless( {
 'sign' => 'NaN',
 'value' => [
  0
]
   }, 'Math::BigInt' );

Expected results:
'use Math::BigInt; print Dumper(Math::BigInt->new("0x10\n\t\t\t"));';
$VAR1 = bless( {
 'sign' => '+',
 'value' => [
  16
]
   }, 'Math::BigInt' );

Additional info:

I've reported this upstream, so I'm largely filing this as a Fedora bug so that
it's tracked for Fedora - as this means you cannot compile OpenPOWER firmware
on Fedora 25.

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

Re: Packages FTBFS with Python 3.6

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 11, 2017 at 03:58:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 11, 2017 at 03:38:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > PS. What's the status of the python3.6 rebuild? Can somebody post
> > a list of work-needing packages?
> 
> I guess that the right invocation:
> 
> $ dnf repoquery --whatrequires 'python(abi) = 3.5'
> dpm-python3-0:1.9.0-2.fc26.x86_64
> lfc-python3-0:1.9.0-2.fc26.x86_64
> python3-bsddb3-0:6.2.0-3.fc26.x86_64
> python3-django-admin-honeypot-0:1.0.0-1.fc26.noarch
> python3-django-avatar-0:3.0.0-1.fc26.noarch
> python3-django-countries-0:3.4.1-2.fc24.noarch
> python3-django-filter-0:0.10.0-3.fc24.noarch
> python3-flower-0:0.9.1-2.fc25.noarch
Blocked by #1410864.

> python3-gensim-addons-0:0.10.0-5.fc24.x86_64
> python3-gensim-core-0:0.10.0-5.fc24.noarch
> python3-gensim-test-0:0.10.0-5.fc24.noarch
> python3-kdcproxy-0:0.3.2-3.fc24.noarch
> python3-moss-0:0.3.4-7.fc26.noarch
> python3-os-brick-0:1.3.0-2.fc25.noarch
> python3-oslo-messaging-0:5.10.0-1.fc26.noarch
> python3-oslo-messaging-tests-0:5.10.0-1.fc26.noarch
> python3-oslo-middleware-0:3.19.0-1.fc26.noarch
> python3-oslo-middleware-tests-0:3.19.0-1.fc26.noarch
> python3-oslo-versionedobjects-0:1.8.0-1.fc26.noarch
> python3-oslo-versionedobjects-tests-0:1.8.0-1.fc26.noarch
> python3-profilehooks-0:1.8.0-3.fc25.noarch
> python3-pyopencl-0:2016.1-4.fc26.x86_64
> python3-recommonmark-0:0.4.0-7.git7ca5247.fc25.noarch
> python3-repoze-who-plugins-sa-0:1.0.1-11.20160106gite1a36c5.fc25.noarch
> python3-shogun-0:4.1.0-7.fc26.x86_64
> rb_libtorrent-python3-0:1.1.1-1.fc26.x86_64
> root-python3-0:6.06.08-2.fc26.i686
> root-python3-0:6.06.08-2.fc26.x86_64
> 
> I fixed those two:
> python3-sphinxcontrib-programoutput-0:0.8-6.fc24.noarch
> python3-mdp-0:3.5-4.fc25.noarch
> 
> This might be fixed, I fired off a build in koji now:
> python3-sympy-0:1.0-3.fc25.noarch
Pfff, it still fails in the test suite :(

> This one depends on sympy, so might be ready to build when sympy is done:
> python3-nipy-0:0.4.0-5.fc25.x86_64
> 
> All in all, this doesn't look to bad.

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

Re: F26 System Wide Change: GCC7

[Richard W.M. Jones]

On Tue, Jan 10, 2017 at 10:28:37AM +0100, Jan Kurik wrote:
> * Other developers:
> First few days/weeks just voluntary rebuilds using the new system gcc,
> if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and
> fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
> analyze and report.

It seems like this link is broken.

Rich.

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

Re: Packages FTBFS with Python 3.6

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 11, 2017 at 03:38:59AM +, Zbigniew Jędrzejewski-Szmek wrote:
> PS. What's the status of the python3.6 rebuild? Can somebody post
> a list of work-needing packages?

I guess that the right invocation:

$ dnf repoquery --whatrequires 'python(abi) = 3.5'
dpm-python3-0:1.9.0-2.fc26.x86_64
lfc-python3-0:1.9.0-2.fc26.x86_64
python3-bsddb3-0:6.2.0-3.fc26.x86_64
python3-django-admin-honeypot-0:1.0.0-1.fc26.noarch
python3-django-avatar-0:3.0.0-1.fc26.noarch
python3-django-countries-0:3.4.1-2.fc24.noarch
python3-django-filter-0:0.10.0-3.fc24.noarch
python3-flower-0:0.9.1-2.fc25.noarch
python3-gensim-addons-0:0.10.0-5.fc24.x86_64
python3-gensim-core-0:0.10.0-5.fc24.noarch
python3-gensim-test-0:0.10.0-5.fc24.noarch
python3-kdcproxy-0:0.3.2-3.fc24.noarch
python3-moss-0:0.3.4-7.fc26.noarch
python3-os-brick-0:1.3.0-2.fc25.noarch
python3-oslo-messaging-0:5.10.0-1.fc26.noarch
python3-oslo-messaging-tests-0:5.10.0-1.fc26.noarch
python3-oslo-middleware-0:3.19.0-1.fc26.noarch
python3-oslo-middleware-tests-0:3.19.0-1.fc26.noarch
python3-oslo-versionedobjects-0:1.8.0-1.fc26.noarch
python3-oslo-versionedobjects-tests-0:1.8.0-1.fc26.noarch
python3-profilehooks-0:1.8.0-3.fc25.noarch
python3-pyopencl-0:2016.1-4.fc26.x86_64
python3-recommonmark-0:0.4.0-7.git7ca5247.fc25.noarch
python3-repoze-who-plugins-sa-0:1.0.1-11.20160106gite1a36c5.fc25.noarch
python3-shogun-0:4.1.0-7.fc26.x86_64
rb_libtorrent-python3-0:1.1.1-1.fc26.x86_64
root-python3-0:6.06.08-2.fc26.i686
root-python3-0:6.06.08-2.fc26.x86_64

I fixed those two:
python3-sphinxcontrib-programoutput-0:0.8-6.fc24.noarch
python3-mdp-0:3.5-4.fc25.noarch

This might be fixed, I fired off a build in koji now:
python3-sympy-0:1.0-3.fc25.noarch

This one depends on sympy, so might be ready to build when sympy is done:
python3-nipy-0:0.4.0-5.fc25.x86_64

All in all, this doesn't look to bad.

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

[389-devel] Please review: 49027 - Do not store clear on secfailure

[William Brown]

https://fedorahosted.org/389/ticket/49027

https://fedorahosted.org/389/attachment/ticket/49027/0001-Ticket-49027-on-secfailure-do-not-store-cleartext-pa.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Please review: Nunc Stans, make tevent optional

[William Brown]

https://pagure.io/nunc-stans/issue/70

https://pagure.io/nunc-stans/issue/raw/files/8dd0fb698209522beda23f835614a7c448f35763e6dae7cb770888d59acc48e9-0001-Ticket-70-Make-tevent-an-optional-component-of-nunc-.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: BuildRequires on obsoleted packages provided by Python

[Adam Williamson]

On Fri, 2016-09-02 at 12:44 +0200, Kalev Lember wrote:
> On 08/31/2016 02:10 PM, Charalampos Stratakis wrote:
> > Hello all,
> > 
> > While checking out the SPEC file of python, it seems there were some 
> > packages that, while separate at some point, they got included in python's 
> > stdlib and then obsoleted as standalone packages (thus to cope with the 
> > change, python was obsoleting these packages and providing them as well in 
> > the SPEC). So every package that currently (Build)Requires any of these 
> > packages will essentially drag python with it.
> > 
> > I will remove these provides soon, since the packages were orphaned long 
> > time ago, but the packages that still require them, will need to be fixed 
> > and (Build)Require python instead.
> 
> My suggestion would be to request provenpackager access and just fix all
> those packages yourself in rawhide. If you file bugs, these are probably
> going to take quite a bit of time to get fixed and you won't be able to
> drop the compatibility provides for several Fedora releases.

Please be careful with such 'fixes'. Some specs are also built for EPEL
6; in EPEL 6, some of these (e.g. python-argparse) are still separate
packages.

I kind of agree with Neal / Kevin that removing these is pointless and
unnecessary. Now I will have to conditionalize my affected specs
somehow in order to keep using them to do builds both for EPEL 6 (where
 I *must* include Requires: python-argparse) and Rawhide (where I now
*cannot* include Requires: python-argparse)...which is a pain.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

tag-invalid not allowed in appdata

[Gerald B. Cox]

I opened a bug on this here:

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

I received an update to the weather-widget and am getting this error now when

I try to rebuild:

FAILED:
? tag-invalid   :  not allowed in appdata
? tag-invalid   : stock icon is not valid [weather-widget]
Validation of files failed

My understanding was that the desktop entry spec file was used to
generate the desktop and xml files.  Both are generated to include the
icon tag - but now according to appstream-util this isn't allowed in
the xml file any longer.  I checked in /usr/share/appdata and did a
random check on org.kde.plasma.colorpicker.appdata.xml among others
and they also have the  tag and also now fail.

I also looked here:https://www.freedesktop.org/software/appstream/docs


and it appears that the  tag is
valid./chap-CollectionData.html#sect-AppStream-XML



So it appears that we have an error in either the process which is
autogenerating the appdata file or the validation program has a bug.

I can certainly hack around this, but would prefer not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Hans de Goede]

Hi,

On 01/10/2017 06:59 PM, Michael Cronenworth wrote:

On 01/10/2017 08:22 AM, Hans de Goede wrote:

If you encounter any issues causes by this change, please file
a bug in bugzilla.


Are performance regressions covered under this clause?


User visible changes, (e.g. some program
slowing to a few fps, this has happened in some cases)
yes.

Micro benchmark results, no.

Regards,

Hans





Iris 5100 (Haswell)
gtkperf - Intel = ~29 seconds
gtkperf - Modeset = ~35 seconds

Fairly significant change.

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

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

Re: announcing arch excludes mailing list

[Dennis Gilmore]

El mar, 10-01-2017 a las 14:34 -0600, Dennis Gilmore escribió:
> Hi All,
> 
> A new mailing list has been created https://lists.fedoraproject.org/a
> dm
> in/lists/arch-excludes.lists.fedoraproject.org/ I would invite anyone
> who is interested in any architecture in fedora to subscribe to the
> list. every commit to git that adds or removes
> ExcludeArch/ExclusiveArch will trigger a notification email.
> additionally there will be a summary email sent every day of all
> packages with ExcludeArch/ExclusiveArch highlighting changes.
> 
> Thanks
> 
> Dennis

a better url is https://lists.fedoraproject.org/archives/list/arch-excl
u...@lists.fedoraproject.org/

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: announcing arch excludes mailing list

[Dennis Gilmore]

El mar, 10-01-2017 a las 14:34 -0600, Dennis Gilmore escribió:
> Hi All,
> 
> A new mailing list has been created https://lists.fedoraproject.org/a
> dm
> in/lists/arch-excludes.lists.fedoraproject.org/ I would invite anyone
> who is interested in any architecture in fedora to subscribe to the
> list. every commit to git that adds or removes
> ExcludeArch/ExclusiveArch will trigger a notification email.
> additionally there will be a summary email sent every day of all
> packages with ExcludeArch/ExclusiveArch highlighting changes.
> 
> Thanks
> 
> Dennis

a better url is https://lists.fedoraproject.org/archives/list/arch-excl
u...@lists.fedoraproject.org/

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

announcing arch excludes mailing list

[Dennis Gilmore]

Hi All,

A new mailing list has been created https://lists.fedoraproject.org/adm
in/lists/arch-excludes.lists.fedoraproject.org/ I would invite anyone
who is interested in any architecture in fedora to subscribe to the
list. every commit to git that adds or removes
ExcludeArch/ExclusiveArch will trigger a notification email.
additionally there will be a summary email sent every day of all
packages with ExcludeArch/ExclusiveArch highlighting changes.

Thanks

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

announcing arch excludes mailing list

[Dennis Gilmore]

Hi All,

A new mailing list has been created https://lists.fedoraproject.org/adm
in/lists/arch-excludes.lists.fedoraproject.org/ I would invite anyone
who is interested in any architecture in fedora to subscribe to the
list. every commit to git that adds or removes
ExcludeArch/ExclusiveArch will trigger a notification email.
additionally there will be a summary email sent every day of all
packages with ExcludeArch/ExclusiveArch highlighting changes.

Thanks

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Migrating More Git Projects to Pagure

[Adam Williamson]

On Tue, 2017-01-10 at 11:13 -0700, Tim Flink wrote:
> On Mon, 9 Jan 2017 09:21:16 -0700
> Tim Flink  wrote:
> 
> > This came up in the qadevel meeting today and I wanted to put a bit
> > more detail out.
> > 
> > Bitbucket was never intended to be the long-term home for our git
> > projects - I think we're about the only folks in Fedora using it and
> > it's not free software. As fedorahosted is closed down, we need to
> > find a new home for blockerbugs but I figure that now is as good of a
> > time as any to get all of our git projects in the same place.
> > 
> > I'm proposing the following moves:
> > 
> > * Move all Taskotron projects to pagure.io using the taskotron group:
> >- pagure.io/taskotron/libtaskotron
> >- pagure.io/taskotron/resultsdb
> >- etc.
> > 
> > * Move blockerbugs under the existing fedora-qa namespace in pagure:
> >- pagure.io/fedora-qa/blockerbugs
> > 
> > I'm not sure if there are any plans for the openqa stuff that
> > currently lives on bitbucket but it'd be nice to see that moved as
> > well.
> > 
> > Any objections, comments, concerns?
> 
> To be a bit more explicit, I'm planning to do these migrations tomorrow
> unless there are objections.

Sounds good to me. BTW, one small gotcha in case you don't know about
it - the pagure namespaces and groups aren't actually associated /
related. Putting a project under the fedora-qa namespace doesn't give
fedora-qa members commit access to it; you have to do that separately
(in the project settings).

I'll try and move the openqa repos this week, I guess.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Fedora 26 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)

[Jan Kurik]

Greetings!

Today, on 2017-January-10, we have reached Fedora 26 Change
Checkpoint: Proposal submission deadline (Changes requiring mass
rebuild) [1].

At this point, only Changes not requiring mass rebuild will be
accepted for Fedora 26. Any Change Proposal requiring mass rebuild
should be scheduled for a later Fedora release.

System Wide as well as Self Contained Changes not causing a need for
mass rebuild are still accepted according to the F26 schedule [1].

[1] https://fedoraproject.org/wiki/Releases/26/Schedule

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

Fedora 26 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild)

[Jan Kurik]

Greetings!

Today, on 2017-January-10, we have reached Fedora 26 Change
Checkpoint: Proposal submission deadline (Changes requiring mass
rebuild) [1].

At this point, only Changes not requiring mass rebuild will be
accepted for Fedora 26. Any Change Proposal requiring mass rebuild
should be scheduled for a later Fedora release.

System Wide as well as Self Contained Changes not causing a need for
mass rebuild are still accepted according to the F26 schedule [1].

[1] https://fedoraproject.org/wiki/Releases/26/Schedule

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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Brendan Conoboy]

On 01/10/2017 01:36 AM, Florian Weimer wrote:

On 01/09/2017 03:37 PM, Dennis Gilmore wrote:


the only reason that aarch64 used /usr/lib64 was so it looked more like
 x86_64 from a user perspective, there is 64 bit arches like alpha that
use /usr/lib for their libraries.


We'll see soon what the non-multiarch layout will be for aarch64 (but
hopefully not in Fedora).  Maybe something like this?

/usr/lib ARMv7/armhfp binaries
/usr/lib64   aarch64 64-bit binaries
/usr/lib32   aarch64 in ILP32 mode (32-bit binaries)

This is similar to x86_64, where the conjectured layout is:

/usr/lib i386
/usr/lib64   x86_64 64-bit binaries
/usr/libx32  x86_64 in ILP32 (x32, 32-bit binaries)


These seem so arbitrary though- that's the appeal of a gnu triplet, 
even though Debian doesn't take full advantage of it.



The Debian multi-arch approach has the advantage that it provides a
consistent way to determine the paths, and also a systematic way to
deal with file conflicts in /usr/include.


Making the compiler sys-root and the runtime the same path and 
binaries is really nice.  Pursuing this path would also mean changing 
dnf/rpm since today they generally don't like to install packages for 
non-native architectures.


Stephen, are we in a seductive detail here or is this conversation 
applicable to your original problem?


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Brendan Conoboy]

On 01/10/2017 07:49 AM, Langdon White wrote:
[snip]

Exactly, yes, a huge *potential* problem. However, it is fixable with
policy and changeable by exception. Just because we can have 40
versions of one thing doesn't mean Fedora will allow that. However, if
there is a genuinely good reason and we can track whether that reason
continues to exist over time, having the capability is a win.


Is "the maintainer wants to keep maintaining it" a good enough reason? 
 Because really when that is no longer true, that evaluation follows.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Elections January 2017 - Voting period has started

[Jan Kurik]

Hi,

the Voting period of the currently running Fedora Elections has
started today morning. Please vote for your candidates to Council [1],
FAmSCo[2] and FESCo [3].
You can vote till January 16th, 2017 when the voting ends at 23:59:00 UTC.

Some of the candidates have also published their interviews on the
Community Blog [4]. Please have a look at it.

[1] https://admin.fedoraproject.org/voting/vote/council-january-2017
[2] https://admin.fedoraproject.org/voting/vote/famsco-jauary-2017
[3] https://admin.fedoraproject.org/voting/vote/fesco-january-2017

[4] https://communityblog.fedoraproject.org/tag/elections/

Thanks for your support.
Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Fedora Elections January 2017 - Voting period has started

[Jan Kurik]

Hi,

the Voting period of the currently running Fedora Elections has
started today morning. Please vote for your candidates to Council [1],
FAmSCo[2] and FESCo [3].
You can vote till January 16th, 2017 when the voting ends at 23:59:00 UTC.

Some of the candidates have also published their interviews on the
Community Blog [4]. Please have a look at it.

[1] https://admin.fedoraproject.org/voting/vote/council-january-2017
[2] https://admin.fedoraproject.org/voting/vote/famsco-jauary-2017
[3] https://admin.fedoraproject.org/voting/vote/fesco-january-2017

[4] https://communityblog.fedoraproject.org/tag/elections/

Thanks for your support.
Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Migrating More Git Projects to Pagure

[Tim Flink]

On Mon, 9 Jan 2017 09:21:16 -0700
Tim Flink  wrote:

> This came up in the qadevel meeting today and I wanted to put a bit
> more detail out.
> 
> Bitbucket was never intended to be the long-term home for our git
> projects - I think we're about the only folks in Fedora using it and
> it's not free software. As fedorahosted is closed down, we need to
> find a new home for blockerbugs but I figure that now is as good of a
> time as any to get all of our git projects in the same place.
> 
> I'm proposing the following moves:
> 
> * Move all Taskotron projects to pagure.io using the taskotron group:
>- pagure.io/taskotron/libtaskotron
>- pagure.io/taskotron/resultsdb
>- etc.
> 
> * Move blockerbugs under the existing fedora-qa namespace in pagure:
>- pagure.io/fedora-qa/blockerbugs
> 
> I'm not sure if there are any plans for the openqa stuff that
> currently lives on bitbucket but it'd be nice to see that moved as
> well.
> 
> Any objections, comments, concerns?

To be a bit more explicit, I'm planning to do these migrations tomorrow
unless there are objections.

Tim


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

Re: fedup upload failure

[Steve Dickson]

On 01/10/2017 12:17 PM, Steve Dickson wrote:
> Hello,
>
> I'm getting the following error when I'm uploading a new tarball
>
> $ fedpkg upload libnfsidmap-0.27.tar.bz2
> Could not execute upload: Can not upload a new source file with a sha512 
> hash, as the "/home/src/fc/libnfsidmap/sources" file contains at least one 
> line with a md5 hash.
>
> Please redo the whole "/home/src/fc/libnfsidmap/sources" file using: 
> `/usr/bin/fedpkg new-sources file1 file2 ...`
>
> when use fedpkg new-sources I get
> $ fedpkg new-sources libnfsidmap-0.27.tar.bz
> Could not execute new_sources: Request is unauthorized.
>
> Any ideas as to why I can not do an fedpkg upload? I'm able
> to do a fedpkg clone so my rsa keys are good...
The answer is. Remove the old md5 hash from the sources file.

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

Re: Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Michael Cronenworth]

On 01/10/2017 08:22 AM, Hans de Goede wrote:

If you encounter any issues causes by this change, please file
a bug in bugzilla. 


Are performance regressions covered under this clause?

Iris 5100 (Haswell)
gtkperf - Intel = ~29 seconds
gtkperf - Modeset = ~35 seconds

Fairly significant change.

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

Re: fedup upload failure

[Steve Dickson]

On 01/10/2017 12:20 PM, Jon Ciesla wrote:
>
>
> On Tue, Jan 10, 2017 at 11:17 AM, Steve Dickson  > wrote:
>
> Hello,
>
> I'm getting the following error when I'm uploading a new tarball
>
> $ fedpkg upload libnfsidmap-0.27.tar.bz2
> Could not execute upload: Can not upload a new source file with a sha512 
> hash, as the "/home/src/fc/libnfsidmap/sources" file contains at least one 
> line with a md5 hash.
>
> Please redo the whole "/home/src/fc/libnfsidmap/sources" file using: 
> `/usr/bin/fedpkg new-sources file1 file2 ...`
>
> when use fedpkg new-sources I get
> $ fedpkg new-sources libnfsidmap-0.27.tar.bz 
> 
> Could not execute new_sources: Request is unauthorized.
>
> Any ideas as to why I can not do an fedpkg upload? I'm able
> to do a fedpkg clone so my rsa keys are good...
>
> tia,
>
> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
>
>
> Did you 'kinit f...@fedoraproject.org '?
Good idea... but it did not work...

steved.

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

Re: fedup upload failure

[Jon Ciesla]

On Tue, Jan 10, 2017 at 11:17 AM, Steve Dickson  wrote:

> Hello,
>
> I'm getting the following error when I'm uploading a new tarball
>
> $ fedpkg upload libnfsidmap-0.27.tar.bz2
> Could not execute upload: Can not upload a new source file with a sha512
> hash, as the "/home/src/fc/libnfsidmap/sources" file contains at least
> one line with a md5 hash.
>
> Please redo the whole "/home/src/fc/libnfsidmap/sources" file using:
> `/usr/bin/fedpkg new-sources file1 file2 ...`
>
> when use fedpkg new-sources I get
> $ fedpkg new-sources libnfsidmap-0.27.tar.bz
> Could not execute new_sources: Request is unauthorized.
>
> Any ideas as to why I can not do an fedpkg upload? I'm able
> to do a fedpkg clone so my rsa keys are good...
>
> tia,
>
> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>

Did you 'kinit f...@fedoraproject.org'?

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

fedup upload failure

[Steve Dickson]

Hello,

I'm getting the following error when I'm uploading a new tarball

$ fedpkg upload libnfsidmap-0.27.tar.bz2
Could not execute upload: Can not upload a new source file with a sha512 hash, 
as the "/home/src/fc/libnfsidmap/sources" file contains at least one line with 
a md5 hash.

Please redo the whole "/home/src/fc/libnfsidmap/sources" file using: 
`/usr/bin/fedpkg new-sources file1 file2 ...`

when use fedpkg new-sources I get
$ fedpkg new-sources libnfsidmap-0.27.tar.bz
Could not execute new_sources: Request is unauthorized.

Any ideas as to why I can not do an fedpkg upload? I'm able
to do a fedpkg clone so my rsa keys are good...

tia,

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

Re: Enabling running Taskotron tasks on Koji scratch builds

[Kamil Paral]

> Couldn't we use the task ID as the primary identifier but use the srpm
> for readability sake since there is no "build" NVR for scratch builds?

Systems like new hotness will need to query according to the task ID, though 
(to get reliable results). So we're talking about hacking just resultsdb 
*frontend* here, e.g. by having "item: task_id" and "item_display: nvr" in the 
results yaml. I don't like it much. Searching in the frontend would have to 
search both in item and item_display.

Or we could use our existing "note" field to put NEVR inside, and it would be 
easily visible in the frontend without any ugly hacks. People would have to 
know that if they want to search by NEVR for scratch builds, they need to put 
the NEVR in the note search field (we'd have to add it).

I assume you proposed using task id as primary identifier just to scratch 
builds (but not standard builds). If you also mean it for standard builds, then 
scheduling tasks locally starts to be quite inconvenient (for each build you 
want to run your task on, you need to find its task id first; it's hard to 
re-run something from shell history). We would also be changing something 
that's a de-facto standard in our infra (using NEVR as a unique identifier 
across projects).


> Either that or make the primary ID a tuple of (srpm name, koji task
> start time) either stored that way or rendered as a string e.g
> foo-1.2-3.fc99.src.rpm built at 201701092100 (MMDDHHMM) would become
> foo-1.2-3.fc99-201701092100.

The same problem with inconvenient local execution. The command line starts to 
be hard to read (in tutorials, etc).

Also, the srpm name doesn't have to be anything reasonable, Koji will happily 
accept anything (it doesn't care, for scratch builds). So we can easily receive 
"1.srpm" or "my-new-patch.srpm" from the fedmsg (we actually tried this [1]). 
Deriving any useful info from this input is probably a mistake. We would have 
to download the srpm and look into the included spec file to reliably decide 
which package this is related to.

[1] 
https://apps.fedoraproject.org/datagrepper/id?id=2017-2fe001d2-32d4-434a-b3a9-29ab31eebbb0_raw=true=extra-large

> 
> > During a discussion with Kamil, a few solutions were mentioned (none
> > of them is pretty):
> > 
> > 1. We can ask koji developers if there is a way to add a method that
> > would return all koji scratch builds for a given NVR - we would then
> > take the latest one and work with it.
> 
> How would we get the NVR if there's no build identifier on scratch
> builds? Are you talking about the SRPM name in the fedmsg?

Yes. Not from the fedmsg, but from the Koji task (the fedmsg gets this value 
from the srpm filename included in the Koji task, I believe). But see the 
problem described above with srpm file naming (can be arbitrary). So even 
better would be if Koji could search and return scratch build info containing 
the metadata of the srpm or from the spec file included.

But I'm honestly not sure it is a good idea even if they wanted to implement 
it. More on that below.

> 
> > 2. We can use "koji download-task" which works for both. That would
> > mean koji_build item type would eat koji task IDs instead of NVRs.
> > This would lead to having koji task IDs in resultsdb instead of NVR's
> > which kills readability. Unless libtaskotron finds the NVR from the
> > koji task ID in the case of "real" build" and stores it in a field in
> > resultsdb...Also, we need NVRs for fedmsgs. So add code to the fedmsg
> > layer that would take care of somehow adding a NVR to fedmsg of
> > completed scratch builds tasks...
> 
> Can't we tell the difference between an NVR and a task ID just by the
> form that the content takes? Wouldn't the following work:
> 
>   1. attempt to parse input as NVR, if there are no issues, assume that
>  it's a build ID
>   2. if the NVR parse fails, check to see if the input is an int. if
>  assume that it's a koji task ID

The reverse might be easier, but yes, that's of course possible. There are 
other caveats, though.

> 
> It'd mean that our koji downloading code would get more complicated but
> it seems like nothing that more unit tests couldn't mitigate. Unless
> I'm mis-thinking here, the changes needed to pull this off in trigger
> would be even smaller.

I'm afraid our code could get infested with if clauses pretty soon. This is not 
just about downloading rpms in the koji directive. We have more koji 
build-related functionality and we'll sure get more in the future. For example, 
we currently support "download_latest_stable", but that might be very tricky 
for scratch builds with "1.srpm" files (which package is that?). If we ever 
needed to work with package epoch, it is unavailable for scratch builds (since 
there is no build info object to be returned). Another example, we have 
dist-git directive. Without clear identification of the package you can't use 
dist-git directive. Even if we download 1.srpm and look into it, you 

Re: Kernel 4.9 rebase plans

[Laura Abbott]

On 12/12/2016 09:14 AM, Laura Abbott wrote:
> Hi,
> 
> Kernel 4.9 was officially released yesterday, December 11. This kernel is
> being built for rawhide today. The plan for bringing this kernel into 
> F24/F25 is going to follow roughly the same schedule as in the past.
> This means pushing the new rebase when we think it's stable enough.
> In the past, this has happened around the .2 stable release (so 4.9.2
> in this case). Given the holidays, this won't be happening until 2017
> but we'll be monitoring closely. I'll update with more information
> once it gets closer. As always, please let us know if you have any
> questions.
> 
> Thanks,
> Laura
> 

4.9.2 has been built in koji and filed as an update in bodhi for F25. Once
F25 gets some testing, F24 will be updated as well. As always, please test
and give appropriate karma.

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

Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

[Florian Weimer]

On 01/10/2017 11:49 AM, Matthew Miller wrote:

On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:

Apache httpd and KDE are very interesting examples.  Both KDE and
Apache httpd integrate with Subversion, on two levels: KDE has
Subversion client support, Apache httpd has server support.  And
Subversion is implemented using apr (the Apache Portable Runtime
library).

So unless we start building Subversion twice, once for use with
Apache httpd, and once for use within KDE, modules containing KDE
and Apache httpd will have to agree on the same version of
Subversion and the same version of apr.  To cut down support
overhead, we'd probably want them to use the same versions, too, but
this might not always be possible (e.g., newer upstream versions may
have obliterate support, which would be considered an important
server-side feature, but also change the working copy format, which
would not be acceptable for a stable desktop release).


Thanks, Florian - that's a great example. This is an area where Fedora,
in our well-meaning attempt to integrate everything, has hobbled
ourselves compared to more focused distributions. A project like Solus
can focus on just the desktop case and doesn't have to care about
Apache as an actual server; a server-only distro can make the opposite
choice. In Fedora right now, someone has to lose. Modularity gives us
flexibility to make a different decision on a case-by-case basis.


We can deal with this in Fedora today, and we do:

mozjs17.x86_64 : JavaScript interpreter and libraries
mozjs24.x86_64 : JavaScript interpreter and libraries
mozjs31.x86_64 : JavaScript interpreter and libraries
mozjs38.x86_64 : JavaScript interpreter and libraries
mozjs45.x86_64 : JavaScript interpreter and libraries

Plus the copies in Firefox and Thunderbird at the very least.

The Spidermonkey Javascript implementation is probably not such a great 
example because there is a lot of development, but for other projects 
with API/ABI changes, but without so many internal changes, it would be 
nice to have a way to build slightly different upstream versions with 
the same pile of patches applied on top.


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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Langdon White]

On Tue, Jan 10, 2017 at 8:20 AM, Ian Malone  wrote:

> On 10 January 2017 at 10:08, Florian Weimer  wrote:
> > On 01/08/2017 01:52 AM, Kevin Kofler wrote:
> >>
> >> Brendan Conoboy wrote:
> >>>
> >>> Enhancing interoperability increases the reach of Fedora and doesn't
> >>> require a bit of compromise on the the Freedom principle.
> >>
> >>
> >> Splitting a single well-integrated distribution (where all the pieces
> are
> >> known to work well together) into a bunch of loosely-coupled black-box
> >> modules that have no idea what libraries the other modules even contain
> >> actually DECREASES interoperability.
> >
> >
> > Only if you do not rebuild each modules from scratch (with the exception
> of
> > the build tools themselves, but which do not end up in the module). If
> you
> > do rebuild the module, the build process of each component could be made
> > aware what is available in the module, and integrate well with the
> features
> > which are available.
> >
> > I think this would resemble what's being done in the embedded space with
> > Yocto and BitBake.
> >
>
> Isn't that another problem? Aside from the fact you now need to
> rebuild dependencies of each component every time, there's now scope
> for package foo to be built with bar-2.1 while faa is built against
> bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5.
> While having to watch useful programs drop out (occasionally) and be
> replaced (or not) because they didn't keep up with the rest of the
> ecosystem is a bit annoying, the containerise-everything alternative
> means reducing the incentive for programs to keep up to date,
> particularly a worry for security issues, but also generally. The
> externally nice and shiny container may contain code well past its
> use-by-date, this is always my worry when someone suggests containers
> as a way around compatibility issues, they have their uses, but they
> can also amount to sweeping problems under the carpet.
>
> --
> imalone
> http://ibmalone.blogspot.co.uk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>


Exactly, yes, a huge *potential* problem. However, it is fixable with
policy and changeable by exception. Just because we can have 40 versions of
one thing doesn't mean Fedora will allow that. However, if there is a
genuinely good reason and we can track whether that reason continues to
exist over time, having the capability is a win.

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

glew 2.0.0 unannounced soname bump

[Orion Poplawski]

glew 2.0.0 was just built in rawhide the other day.  This was a soname bump
and broke dependencies in a lot of packages.  This was not announced on the
devel list as required.  Please coordinate these updates in the future.  I'm
working on rebuilding most of the deps.

-- 
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Updates in testing for EOL releases stuck forever in Bodhi?

[Kevin Fenzi]

On Tue, 10 Jan 2017 10:15:38 +0100
Michal Schorm  wrote:

> +1
> 
> On Tue, Jan 10, 2017 at 9:43 AM, Sandro Mani 
> wrote:
> 
> > Hi
> >
> > Just wondering: is there any way to get rid of the entries of
> > updates stuck in testing for EOL releases in
> > bodhi.fedoraproject.org/update s/?user==testing ?

https://github.com/fedora-infra/bodhi/issues/752

kevin


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

[Bug 1409156] perl-Ham-Reference-QRZ-0.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Ham-Reference-QRZ-0.04 |perl-Ham-Reference-QRZ-0.04
   |-1.fc26 |-1.fc26
   |perl-Ham-Reference-QRZ-0.04 |perl-Ham-Reference-QRZ-0.04
   |-1.fc25 |-1.fc25
   ||perl-Ham-Reference-QRZ-0.04
   ||-1.fc24



--- Comment #10 from Fedora Update System  ---
perl-Ham-Reference-QRZ-0.04-1.fc24 has been pushed to the Fedora 24 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1409151] perl-DB_File-1.840 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DB_File-1.840-1.fc26   |perl-DB_File-1.840-1.fc26
   |perl-DB_File-1.840-1.fc25   |perl-DB_File-1.840-1.fc25
   ||perl-DB_File-1.840-1.fc24



--- Comment #7 from Fedora Update System  ---
perl-DB_File-1.840-1.fc24 has been pushed to the Fedora 24 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed xavierb's 'watchbugzilla' permission on perl-Mail-POP3Client (epel7) to 'Approved'

[notifications]

limb changed xavierb's 'watchbugzilla' permission on perl-Mail-POP3Client 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed xavierb's branch request for perl-Mail-POP3Client in epel7 from Awaiting Review to Approved

[notifications]

limb changed xavierb's branch request for perl-Mail-POP3Client in epel7 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed xavierb's 'approveacls' permission on perl-Mail-POP3Client (epel7) to 'Approved'

[notifications]

limb changed xavierb's 'approveacls' permission on perl-Mail-POP3Client (epel7) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed xavierb's 'commit' permission on perl-Mail-POP3Client (epel7) to 'Approved'

[notifications]

limb changed xavierb's 'commit' permission on perl-Mail-POP3Client (epel7) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb created the branch 'epel7' for the package 'perl-Mail-POP3Client'

[notifications]

limb created the branch 'epel7' for the package 'perl-Mail-POP3Client'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

limb changed xavierb's 'watchcommits' permission on perl-Mail-POP3Client (epel7) to 'Approved'

[notifications]

limb changed xavierb's 'watchcommits' permission on perl-Mail-POP3Client 
(epel7) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Mail-POP3Client/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Headsup: Xserver update switching Intel GPUs from xorg-x11-drv-intel to -modesetting by default coming to rawhide

[Hans de Goede]

Hi,

A while back Debian has switched to using the modesetting Xorg driver
rather then the intel Xorg driver for Intel GPUs.

There are several good reasons for this, rather then repeating them
I'm just going to point to the Debian announcement:

https://tjaalton.wordpress.com/2016/07/23/intel-graphics-gen4-and-newer-now-defaults-to-modesetting-driver-on-x/

This mail is to let all Fedora users know that starting with
Fedora-26 / rawhide as of today, we are making the same change.

Note that the xorg-x11-drv-intel package has already been carrying
a Fedora patch to not bind to the GPU on Skylake or newer, even
before Debian announced this, this just makes the same change for
older Intel GPUs.

For people who are using the now default GNOME3 on Wayland session,
nothing changes, since Xwayland always uses glamor for X
acceleration, just like the modesetting driver.

If you encounter any issues causes by this change, please file
a bug in bugzilla.

Regards,

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

Re: MongoDB on Big Endian

[Vít Ondruch]

Cool \ó/

Thx


V.


Dne 10.1.2017 v 15:03 Marek Skalický napsal(a):
> Hi,
> MongoDB upstream does not support ppc64 BE.
>
> But there is support for s390x, so code is ported/ready for Big Endian. I've 
> managed to make MongoDB building and passing basic tests on ppc64.
> So in rawhide in latest build, all fedora primary architectures are 
> functional. Testing is very welcomed.
>
> Marek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: MongoDB on Big Endian

[Marek Skalický]

Hi,
MongoDB upstream does not support ppc64 BE.

But there is support for s390x, so code is ported/ready for Big Endian. I've 
managed to make MongoDB building and passing basic tests on ppc64.
So in rawhide in latest build, all fedora primary architectures are functional. 
Testing is very welcomed.

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

Broken dependencies: perl-ZMQ-LibZMQ3

[buildsys]

perl-ZMQ-LibZMQ3 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.x86_64 requires libzmq.so.3()(64bit)
On armhfp:
perl-ZMQ-LibZMQ3-1.19-5.fc25.armv7hl requires libzmq.so.3
On ppc64le:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64le requires libzmq.so.3()(64bit)
On aarch64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.aarch64 requires libzmq.so.3()(64bit)
On ppc64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64 requires libzmq.so.3()(64bit)
On i386:
perl-ZMQ-LibZMQ3-1.19-5.fc25.i686 requires libzmq.so.3
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZMQ-LibZMQ2

[buildsys]

perl-ZMQ-LibZMQ2 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZMQ-LibZMQ2-1.09-9.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZMQ-LibZMQ2-1.09-9.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Broken dependencies: perl-OpenOffice-UNO

[buildsys]

perl-OpenOffice-UNO has broken dependencies in the rawhide tree:
On armhfp:
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires libuno_cppu.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(LIBO_UDK_4.4)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(UDK_3.1)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppu.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppuhelpergcc3.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires libuno_sal.so.3
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_sal.so.3(UDK_3_0_0)
perl-OpenOffice-UNO-0.07-20.fc25.armv7hl requires 
libuno_salhelpergcc3.so.3
Please resolve this as soon as possible.

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

Broken dependencies: perl-Alien-ROOT

[buildsys]

perl-Alien-ROOT has broken dependencies in the rawhide tree:
On aarch64:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
On ppc64:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
On ppc64le:
perl-Alien-ROOT-5.34.36.1-2.fc26.noarch requires root-core
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZeroMQ

[buildsys]

perl-ZeroMQ has broken dependencies in the rawhide tree:
On x86_64:
perl-ZeroMQ-0.23-13.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZeroMQ-0.23-13.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZeroMQ-0.23-13.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZeroMQ-0.23-13.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZeroMQ-0.23-13.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZeroMQ-0.23-13.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
On ppc64le:
perl-Data-Alias-1.20-2.fc24.ppc64le requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.ppc64le requires perl(:MODULE_COMPAT_5.22.1)
On aarch64:
perl-Data-Alias-1.20-2.fc24.aarch64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.aarch64 requires perl(:MODULE_COMPAT_5.22.1)
On ppc64:
perl-Data-Alias-1.20-2.fc24.ppc64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.ppc64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

[Test-Announce] Fedora 26 Rawhide 20170110.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 26 Rawhide 20170110.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20170105.n.0: anaconda-26.17-1.fc26.src, 20170110.n.0: 
anaconda-26.18-1.fc26.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/26

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170110.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Self Contained Change: Automated AMI test and release

[Jan Kurik]

= Proposed Self Contained Change: Automated AMI test and release =
https://fedoraproject.org/wiki/Automated_AMI_test_and_release

Change owner(s):
* Kushal Das 
* Sayan Chowdhury 

We will test the AMI image we build on one single region using the
same tests used in Vagrant/local Autocloud testing, and if the tests
pass, then only the AMI will be uploaded to all the regions and
released.


== Detailed Description ==
Currenly fedming tool creates and uploads the AMI images to AWS, in
all the regions. It only tests the output /usr/bin/true command to
determine if an image is right or not.

The proposed change will split the process in the two parts. fedimg
will first upload the image to only one region and emit a fedmsg
message. Autocloud listening to these message will start testing the
image using the same tests it uses for Vagrant/Atomic qcow2. Autocloud
will upload the test details to ResultsDB. Fedimg will listen to
ResultsDB fedmsg messages for the results of the test and if all the
tests passes then then fedimg would copy the images to other regions
as well.


== Scope ==
* Proposal owners: to implement this Change

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

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

F26 Self Contained Change: Automated AMI test and release

[Jan Kurik]

= Proposed Self Contained Change: Automated AMI test and release =
https://fedoraproject.org/wiki/Automated_AMI_test_and_release

Change owner(s):
* Kushal Das 
* Sayan Chowdhury 

We will test the AMI image we build on one single region using the
same tests used in Vagrant/local Autocloud testing, and if the tests
pass, then only the AMI will be uploaded to all the regions and
released.


== Detailed Description ==
Currenly fedming tool creates and uploads the AMI images to AWS, in
all the regions. It only tests the output /usr/bin/true command to
determine if an image is right or not.

The proposed change will split the process in the two parts. fedimg
will first upload the image to only one region and emit a fedmsg
message. Autocloud listening to these message will start testing the
image using the same tests it uses for Vagrant/Atomic qcow2. Autocloud
will upload the test details to ResultsDB. Fedimg will listen to
ResultsDB fedmsg messages for the results of the test and if all the
tests passes then then fedimg would copy the images to other regions
as well.


== Scope ==
* Proposal owners: to implement this Change

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

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

[Bug 1408537] perl-GraphViz-2.24 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-GraphViz-2.24-1.fc26   |perl-GraphViz-2.24-1.fc26
   ||perl-GraphViz-2.24-1.fc25
 Resolution|--- |ERRATA
Last Closed||2017-01-10 08:21:05



--- Comment #4 from Fedora Update System  ---
perl-GraphViz-2.24-1.fc25 has been pushed to the Fedora 25 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1409156] perl-Ham-Reference-QRZ-0.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Ham-Reference-QRZ-0.04 |perl-Ham-Reference-QRZ-0.04
   |-1.fc26 |-1.fc26
   ||perl-Ham-Reference-QRZ-0.04
   ||-1.fc25
 Resolution|--- |ERRATA
Last Closed||2017-01-10 08:21:22



--- Comment #9 from Fedora Update System  ---
perl-Ham-Reference-QRZ-0.04-1.fc25 has been pushed to the Fedora 25 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1409151] perl-DB_File-1.840 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-DB_File-1.840-1.fc26   |perl-DB_File-1.840-1.fc26
   ||perl-DB_File-1.840-1.fc25
 Resolution|--- |ERRATA
Last Closed||2017-01-10 08:21:16



--- Comment #6 from Fedora Update System  ---
perl-DB_File-1.840-1.fc25 has been pushed to the Fedora 25 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Ian Malone]

On 10 January 2017 at 10:08, Florian Weimer  wrote:
> On 01/08/2017 01:52 AM, Kevin Kofler wrote:
>>
>> Brendan Conoboy wrote:
>>>
>>> Enhancing interoperability increases the reach of Fedora and doesn't
>>> require a bit of compromise on the the Freedom principle.
>>
>>
>> Splitting a single well-integrated distribution (where all the pieces are
>> known to work well together) into a bunch of loosely-coupled black-box
>> modules that have no idea what libraries the other modules even contain
>> actually DECREASES interoperability.
>
>
> Only if you do not rebuild each modules from scratch (with the exception of
> the build tools themselves, but which do not end up in the module). If you
> do rebuild the module, the build process of each component could be made
> aware what is available in the module, and integrate well with the features
> which are available.
>
> I think this would resemble what's being done in the embedded space with
> Yocto and BitBake.
>

Isn't that another problem? Aside from the fact you now need to
rebuild dependencies of each component every time, there's now scope
for package foo to be built with bar-2.1 while faa is built against
bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5.
While having to watch useful programs drop out (occasionally) and be
replaced (or not) because they didn't keep up with the rest of the
ecosystem is a bit annoying, the containerise-everything alternative
means reducing the incentive for programs to keep up to date,
particularly a worry for security issues, but also generally. The
externally nice and shiny container may contain code well past its
use-by-date, this is always my worry when someone suggests containers
as a way around compatibility issues, they have their uses, but they
can also amount to sweeping problems under the carpet.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] PROPOSAL: Ticket 49085 - Make a short topology fixture alias

[Simon Pichugin]

Hi team,
please, share your thoughts on the topic here:
https://fedorahosted.org/389/ticket/49085

Thanks,
Simon


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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Matthew Miller]

On Mon, Jan 09, 2017 at 06:06:24PM -0500, langdon wrote:
> I also am not sure I am comfortable with the move toward exposing
> proprietary software that we have been considering/implementing.
> However, I do think there is some benefit to being able to show
> firefox next to chrome when someone looks to install it. With
> information about the differences. We have no opportunity to educate
> users when they just go to google and download it directly. Again,
> modularity or containers have no bearing on that discussion, they
> are an implementation detail.

N.B. this is referring to yet a separate thing unrelated to *either*
multilib or Modularity; a proposal from Workstation to allow users to
opt-in to selected third-party repositories which may contain
proprietary software. It's a good conversation but *way* off the topic
here. (And I know I'm encouraging the wandering by replying but I just
wanted to make sure that that's clear for anyone following along or
finding this later.)

-- 
Matthew Miller

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

[Bug 1402386] perl-Text-Fuzzy-0.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Fuzzy-0.25-1.fc25 |perl-Text-Fuzzy-0.25-1.fc25
   ||perl-Text-Fuzzy-0.25-1.el7



--- Comment #10 from Fedora Update System  ---
perl-Text-Fuzzy-0.25-1.el7 has been pushed to the Fedora EPEL 7 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1406379] perl-Test-mysqld-0.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Test-mysqld-0.20-1.fc2 |perl-Test-mysqld-0.20-1.fc2
   |5   |5
   ||perl-Test-mysqld-0.20-1.el7



--- Comment #10 from Fedora Update System  ---
perl-Test-mysqld-0.20-1.el7 has been pushed to the Fedora EPEL 7 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1398627] perl-Time-Moment-0.41 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Time-Moment-0.41-1.fc2 |perl-Time-Moment-0.41-1.fc2
   |5   |5
   |perl-Time-Moment-0.41-1.fc2 |perl-Time-Moment-0.41-1.fc2
   |4   |4
   ||perl-Time-Moment-0.41-1.el7



--- Comment #17 from Fedora Update System  ---
perl-Time-Moment-0.41-1.el7 has been pushed to the Fedora EPEL 7 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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Transdiff

[Brian Exelbierd]

On Tue, Jan 10, 2017, at 09:39 AM, Jan Kurik wrote:
> = Proposed Self Contained Change: Transdiff =
> https://fedoraproject.org/wiki/Changes/Transdiff
> 
> Change owner(s):
> *Sundeep Anand 
> 
> Often even after 100% translation in Zanata, few packages do not get
> build with latest translations in Fedora. This result in poor
> localization experience. Transdiff is a python program to run on
> products installations for tracking translations with project upstream
> and generate diff reports.
> 
> == Detailed Description ==
> Often even after 100% translation in Zanata, few packages do not get
> build with latest translations in Fedora. This result in poor
> localization experience. Transdiff is a python program to run on
> products installations for tracking translations with project upstream
> and generate diff reports.

Is this focused solely on Fedora originated projects translated in the
Fedora Zanata?  As Tom pointed out, if it isn't, why are we modifying
the upstream?

If it is, it seems we are working at this backward.  Zanata has the
ability to trigger an event when a project reaches 100% translation. 
Why not set up that infrastructure to ensure that translation completion
becomes a build triggering/update triggering event for the projects in
question?  Also, why not work with Zanata to make this notification more
robust so that projects could, for example, say that any translation
update should trigger a rebuild?

regards,

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

F26 Self Contained Change: Transdiff (Jan Kurik)

[Sundeep Anand]

Transdiff is second part of "String Breakage Monitoring System" - whose
first part is Zanata Sync. Zanata Sync tries to keep upstream updated with
new translations, making chances greater that extra translations are
packaged too, which is to be verified by transdiff. Basically an attempt to
tie-up upstream, translation platform and release stream. I am doing a
project[1] on the similar lines and perhaps we may give some more time to
Transdiff. Basically the scope may be kept limited to "identifying string
breakage in fedora packages".

thanks,
sundeep

[1] https://github.com/sundeep-co-in/transtats


On Tue, Jan 10, 2017 at 2:46 PM, 
wrote:

> Send devel mailing list submissions to
> devel@lists.fedoraproject.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> devel-requ...@lists.fedoraproject.org
>
> You can reach the person managing the list at
> devel-ow...@lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
> Today's Topics:
>
>1. Re: Self Introduction: Christophe Delaere
>   (Zbigniew Jędrzejewski-Szmek)
>2. Re: Proposal: Rethink Fedora multilib support (Take Two!)
>   (Richard W.M. Jones)
>3. Re: Proposal: Rethink Fedora multilib support (Take Two!)
>   (Richard W.M. Jones)
>4. [Fedocal] Reminder meeting : Modularity WG (jku...@redhat.com)
>5. F26 Self Contained Change: Transdiff (Jan Kurik)
>6. Updates in testing for EOL releases stuck forever in Bodhi?
>   (Sandro Mani)
>7. Re: F26 Self Contained Change: Transdiff (Tom Hughes)
>8. Re: Updates in testing for EOL releases stuck forever in Bodhi?
>   (Michal Schorm)
>
>
> --
>
> Date: Tue, 10 Jan 2017 09:09:29 +
> From: Tom Hughes 
> Subject: Re: F26 Self Contained Change: Transdiff
> To: Development discussions related to Fedora
> 
> Message-ID: <2a518f00-db23-7c57-b074-3b9532e12...@compton.nu>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 10/01/17 08:39, Jan Kurik wrote:
>
> > Often even after 100% translation in Zanata, few packages do not get
> > build with latest translations in Fedora. This result in poor
> > localization experience.
>
> I don't really understand the logic here...
>
> I would expect anything in Fedora to be built with whatever translations
> are provided in the upstream release - are you saying that packagers are
> routinely removing such translations for some reason? or just forgetting
> to package the extra translations?
>
> Or are you proposing that packagers should be pulling translations from
> some additional source above and beyond what upstream provides?
>
> Zanata appears to be a web based translation platform that developers
> can use so I would expect the workflow for a package that uses Zanata to
> be that upstream pulls the latest translations from it at regular
> intervals and incorporates them in the releases they make which then get
> packaged in Fedora.
>
> I'm not saying we should package a tool for analysing translation status
> as I'm sure it will be useful to upstream developers but it's not clear
> how you envisage it fitting into the Fedora development process.
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
> --
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Transdiff

[Matthew Miller]

On Tue, Jan 10, 2017 at 12:01:38PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Nice. On the wiki page, you (Sundeep) also mention automation.
> Where do you see this in our packaging pipeline?
> 
> As a taskotron check? A regular report mailed to the devel list?

A taskotron check sending mail to the translations list?

-- 
Matthew Miller

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

Re: F26 Self Contained Change: Transdiff

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 10 January 2017 at 09:39, Jan Kurik wrote:
> = Proposed Self Contained Change: Transdiff =
> https://fedoraproject.org/wiki/Changes/Transdiff
> 
> Change owner(s):
> *Sundeep Anand 
> 
> Often even after 100% translation in Zanata, few packages do not get
> build with latest translations in Fedora. This result in poor
> localization experience. Transdiff is a python program to run on
> products installations for tracking translations with project upstream
> and generate diff reports.

Nice. On the wiki page, you (Sundeep) also mention automation.
Where do you see this in our packaging pipeline?

As a taskotron check? A regular report mailed to the devel list?

> == Detailed Description ==
> Often even after 100% translation in Zanata, few packages do not get
> build with latest translations in Fedora. This result in poor
> localization experience. Transdiff is a python program to run on
> products installations for tracking translations with project upstream
> and generate diff reports.

Same as summary. Also, why does this warrant a change?

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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

[Igor Gnatenko]

On Tue, Jan 10, 2017 at 11:49 AM, Matthew Miller
 wrote:
>
> On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
> > Apache httpd and KDE are very interesting examples.  Both KDE and
> > Apache httpd integrate with Subversion, on two levels: KDE has
> > Subversion client support, Apache httpd has server support.  And
> > Subversion is implemented using apr (the Apache Portable Runtime
> > library).
> >
> > So unless we start building Subversion twice, once for use with
> > Apache httpd, and once for use within KDE, modules containing KDE
> > and Apache httpd will have to agree on the same version of
> > Subversion and the same version of apr.  To cut down support
> > overhead, we'd probably want them to use the same versions, too, but
> > this might not always be possible (e.g., newer upstream versions may
> > have obliterate support, which would be considered an important
> > server-side feature, but also change the working copy format, which
> > would not be acceptable for a stable desktop release).
>
> Thanks, Florian - that's a great example. This is an area where Fedora,
> in our well-meaning attempt to integrate everything, has hobbled
> ourselves compared to more focused distributions. A project like Solus
> can focus on just the desktop case and doesn't have to care about
> Apache as an actual server; a server-only distro can make the opposite
> choice. In Fedora right now, someone has to lose. Modularity gives us
> flexibility to make a different decision on a case-by-case basis.
At this point modularity doesn't help with this at all. It doesn't
solve problems when you want to have library with 2 variants.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org




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

Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

[Matthew Miller]

On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
> Apache httpd and KDE are very interesting examples.  Both KDE and
> Apache httpd integrate with Subversion, on two levels: KDE has
> Subversion client support, Apache httpd has server support.  And
> Subversion is implemented using apr (the Apache Portable Runtime
> library).
> 
> So unless we start building Subversion twice, once for use with
> Apache httpd, and once for use within KDE, modules containing KDE
> and Apache httpd will have to agree on the same version of
> Subversion and the same version of apr.  To cut down support
> overhead, we'd probably want them to use the same versions, too, but
> this might not always be possible (e.g., newer upstream versions may
> have obliterate support, which would be considered an important
> server-side feature, but also change the working copy format, which
> would not be acceptable for a stable desktop release).

Thanks, Florian - that's a great example. This is an area where Fedora,
in our well-meaning attempt to integrate everything, has hobbled
ourselves compared to more focused distributions. A project like Solus
can focus on just the desktop case and doesn't have to care about
Apache as an actual server; a server-only distro can make the opposite
choice. In Fedora right now, someone has to lose. Modularity gives us
flexibility to make a different decision on a case-by-case basis.

-- 
Matthew Miller

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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Florian Weimer]

On 01/10/2017 12:06 AM, langdon wrote:


Now, there are some use cases where the interop of the components is
very important and a distribution enables this because all the things
are tightly integrated. However, there is no particularly good reason
for httpd and kde to be tightly integrated. Why can't they be using
different versions of libraries assuming they are equally secure but
different in feature set?


Apache httpd and KDE are very interesting examples.  Both KDE and Apache 
httpd integrate with Subversion, on two levels: KDE has Subversion 
client support, Apache httpd has server support.  And Subversion is 
implemented using apr (the Apache Portable Runtime library).


So unless we start building Subversion twice, once for use with Apache 
httpd, and once for use within KDE, modules containing KDE and Apache 
httpd will have to agree on the same version of Subversion and the same 
version of apr.  To cut down support overhead, we'd probably want them 
to use the same versions, too, but this might not always be possible 
(e.g., newer upstream versions may have obliterate support, which would 
be considered an important server-side feature, but also change the 
working copy format, which would not be acceptable for a stable desktop 
release).


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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 673  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 435  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 154  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  80  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b2e637ff5a   
python-wikitcms-2.1.10-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0fa3a954b0   
borgbackup-1.0.9-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bb32162e83   
php-swiftmailer-5.4.5-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-92129d651d   
exim-4.88-2.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-770d2afc7d   
mingw-flac-1.3.2-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-fbb2447c6e   
php-PHPMailer-5.2.22-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-80cfb13391   
moodle-3.2.1-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3d29bf8e34   
php-ZendFramework2-2.4.11-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

ansible-review-0.13.0-2.el7
bitlbee-3.5-1.el7
collectd-5.7.0-1.el7
cowsay-3.04-4.el7
golang-github-onsi-ginkgo-1.1.0-11.el7
golang-github-onsi-gomega-1.0-0.1.git2152b45.el7
moodle-3.2.1-1.el7
ocserv-0.11.6-4.el7
perl-Number-Bytes-Human-0.11-1.el7
php-PHPMailer-5.2.22-1.el7
php-ZendFramework2-2.4.11-1.el7
php-tcpdf-6.2.13-1.el7
python-productmd-1.4-1.el7
stoken-0.91-1.el7

Details about builds:



 ansible-review-0.13.0-2.el7 (FEDORA-EPEL-2017-725e09e9a9)
 Reviews Ansible playbooks, roles and inventory and suggests improvements

Update Information:

RHBZ#1410896: depend on python-flake8    upstream release 0.13.0

References:

  [ 1 ] Bug #1410896 - ansible-review doesn't work, unless I manually install 
python2-flake8
https://bugzilla.redhat.com/show_bug.cgi?id=1410896
  [ 2 ] Bug #1405253 - ansible-review-0.13.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1405253




 bitlbee-3.5-1.el7 (FEDORA-EPEL-2017-af619b306b)
 IRC to other chat networks gateway

Update Information:

Update to the latest upstream.

References:

  [ 1 ] Bug #1411171 - bitlbee-3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1411171




 collectd-5.7.0-1.el7 (FEDORA-EPEL-2017-a024a859e3)
 Statistics collection daemon for filling RRD files

Update Information:

Update to 5.7.0. Fixes bug #1410193

References:

  [ 1 ] Bug #1410193 - write_http plugin broken on collect 5.6.0/5.6.1, fixed 
in 5.6.2
https://bugzilla.redhat.com/show_bug.cgi?id=1410193




 cowsay-3.04-4.el7 (FEDORA-EPEL-2017-c9ddd271bc)
 Configurable speaking/thinking cow

Update Information:

Require perl-Encode

References:

  [ 1 ] Bug #1411168 - Missing dependency perl-Encode for cowsay package
https://bugzilla.redhat.com/show_bug.cgi?id=1411168




 golang-github-onsi-ginkgo-1.1.0-11.el7 (FEDORA-EPEL-2017-d205e9dda2)
 A Golang BDD Testing Framework

Update Information:

Add missing Provides    Bump to 

[Bug 1411308] perl-Number-Bytes-Human-0.11 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Number-Bytes-Human-0.11-1.el7 has been pushed to the Fedora EPEL 7 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-07220aab98

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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 551  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 545  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 477  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 435  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 407  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 138  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-245929d91a   
tinymce-4.5.1-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-62450e4e38   
libpng10-1.0.67-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-284a1cc356   
exim-4.88-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8c6c7bf06e   
dbus-sharp-0.7.0-16.el6 dbus-sharp-glib-0.5.0-14.el6 mono-4.2.4-9.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7d479b3940   
php-PHPMailer-5.2.22-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-50bd69   
icoutils-0.31.1-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4e597458f1   
php-ZendFramework2-2.2.10-3.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

bitlbee-3.5-1.el6
golang-github-onsi-ginkgo-1.1.0-11.el6
golang-github-onsi-gomega-1.0-0.1.git2152b45.el6
icoutils-0.31.1-1.el6
php-PHPMailer-5.2.22-1.el6
php-ZendFramework2-2.2.10-3.el6
php-tcpdf-6.2.13-1.el6
python-productmd-1.4-1.el6

Details about builds:



 bitlbee-3.5-1.el6 (FEDORA-EPEL-2017-88b1fb3523)
 IRC to other chat networks gateway

Update Information:

Update to the latest upstream.

References:

  [ 1 ] Bug #1411171 - bitlbee-3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1411171




 golang-github-onsi-ginkgo-1.1.0-11.el6 (FEDORA-EPEL-2017-54a7538f99)
 A Golang BDD Testing Framework

Update Information:

Add missing Provides    Bump to upstream
7f8ab55aaf3b86885aa55b762e803744d1674700

References:

  [ 1 ] Bug #1214619 - Tracker for golang-github-onsi-ginkgo
https://bugzilla.redhat.com/show_bug.cgi?id=1214619




 golang-github-onsi-gomega-1.0-0.1.git2152b45.el6 (FEDORA-EPEL-2017-7feec15962)
 Ginkgo's Preferred Matcher Library

Update Information:

Bump to upstream 2152b45fa28a361beba9aab0885972323a444e28    internal
packages are no longer provided Update of spec file to spec-2.0

References:

  [ 1 ] Bug #1248013 - Tracker for golang-github-onsi-gomega
https://bugzilla.redhat.com/show_bug.cgi?id=1248013




 icoutils-0.31.1-1.el6 (FEDORA-EPEL-2017-50bd69)
 Utility for extracting and converting Microsoft icon and cursor files

Update Information:

This new point release fixes a security vulnerability in wrestool. For further
details see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850017

References:

  [ 1 ] Bug #1411251 - CVE-2017-5208 icoutils: Check_offset overflow on 64-bit 
systems
https://bugzilla.redhat.com/show_bug.cgi?id=1411251




 php-PHPMailer-5.2.22-1.el6 (FEDORA-EPEL-2017-7d479b3940)
 PHP email transport class with a lot of features

Update Information:

**Version 5.2.22** (January 5th 2017)  * **SECURITY** Fix

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Florian Weimer]

On 01/08/2017 01:52 AM, Kevin Kofler wrote:

Brendan Conoboy wrote:

Enhancing interoperability increases the reach of Fedora and doesn't
require a bit of compromise on the the Freedom principle.


Splitting a single well-integrated distribution (where all the pieces are
known to work well together) into a bunch of loosely-coupled black-box
modules that have no idea what libraries the other modules even contain
actually DECREASES interoperability.


Only if you do not rebuild each modules from scratch (with the exception 
of the build tools themselves, but which do not end up in the module). 
If you do rebuild the module, the build process of each component could 
be made aware what is available in the module, and integrate well with 
the features which are available.


I think this would resemble what's being done in the embedded space with 
Yocto and BitBake.


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

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Florian Weimer]

On 01/09/2017 03:37 PM, Dennis Gilmore wrote:


the only reason that aarch64 used /usr/lib64 was so it looked more like
 x86_64 from a user perspective, there is 64 bit arches like alpha that
use /usr/lib for their libraries.


We'll see soon what the non-multiarch layout will be for aarch64 (but 
hopefully not in Fedora).  Maybe something like this?


/usr/lib ARMv7/armhfp binaries
/usr/lib64   aarch64 64-bit binaries
/usr/lib32   aarch64 in ILP32 mode (32-bit binaries)

This is similar to x86_64, where the conjectured layout is:

/usr/lib i386
/usr/lib64   x86_64 64-bit binaries
/usr/libx32  x86_64 in ILP32 (x32, 32-bit binaries)

The Debian multi-arch approach has the advantage that it provides a 
consistent way to determine the paths, and also a systematic way to deal 
with file conflicts in /usr/include.


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

F26 System Wide Change: GCC7

[Jan Kurik]

= System Wide Change: GCC7 =
https://fedoraproject.org/wiki/Changes/GCC7

Change owner(s):
* Jakub Jelínek 

Switch GCC in Fedora 26 to 7.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 27.

== Detailed Description ==
GCC 7 is currently in stage3, will move to stage4 on January 19th, in
prerelease state with only regression bugfixes and documentation fixes
allowed. The release will happen probably in the middle of April. We
are working on scratch gcc rpms and will perform a test mass rebuild.

== Scope ==
All packages should be rebuilt with the new gcc once it hits f26, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.

* Proposal owners:
Build gcc in f26, rebuild packages that have direct dependencies on
exact gcc version (libtool, llvm, gcc-python-plugin, odb).

* Other developers:
First few days/weeks just voluntary rebuilds using the new system gcc,
if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html and
fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.

* Release engineering:
Organize a mass rebuild, either in f26 or in f27

* Policies and guidelines:
No policies need to be changed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Updates in testing for EOL releases stuck forever in Bodhi?

[Michal Schorm]

+1

On Tue, Jan 10, 2017 at 9:43 AM, Sandro Mani  wrote:

> Hi
>
> Just wondering: is there any way to get rid of the entries of updates
> stuck in testing for EOL releases in bodhi.fedoraproject.org/update
> s/?user==testing ?
>
> Thanks
> Sandro
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 

Michal Schorm
Core Services - Databases Team
mail: msch...@redhat.com
Brno-IRC: mschorm
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Transdiff

[Tom Hughes]

On 10/01/17 08:39, Jan Kurik wrote:


Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience.


I don't really understand the logic here...

I would expect anything in Fedora to be built with whatever translations 
are provided in the upstream release - are you saying that packagers are 
routinely removing such translations for some reason? or just forgetting 
to package the extra translations?


Or are you proposing that packagers should be pulling translations from 
some additional source above and beyond what upstream provides?


Zanata appears to be a web based translation platform that developers 
can use so I would expect the workflow for a package that uses Zanata to 
be that upstream pulls the latest translations from it at regular 
intervals and incorporates them in the releases they make which then get 
packaged in Fedora.


I'm not saying we should package a tool for analysing translation status 
as I'm sure it will be useful to upstream developers but it's not clear 
how you envisage it fitting into the Fedora development process.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Updates in testing for EOL releases stuck forever in Bodhi?

[Sandro Mani]

Hi

Just wondering: is there any way to get rid of the entries of updates 
stuck in testing for EOL releases in 
bodhi.fedoraproject.org/updates/?user==testing ?


Thanks
Sandro

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

F26 Self Contained Change: Transdiff

[Jan Kurik]

= Proposed Self Contained Change: Transdiff =
https://fedoraproject.org/wiki/Changes/Transdiff

Change owner(s):
*Sundeep Anand 

Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Detailed Description ==
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Scope ==
* Proposal owners: Complete script and package it for Fedora.

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

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

F26 Self Contained Change: Transdiff

[Jan Kurik]

= Proposed Self Contained Change: Transdiff =
https://fedoraproject.org/wiki/Changes/Transdiff

Change owner(s):
*Sundeep Anand 

Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Detailed Description ==
Often even after 100% translation in Zanata, few packages do not get
build with latest translations in Fedora. This result in poor
localization experience. Transdiff is a python program to run on
products installations for tracking translations with project upstream
and generate diff reports.

== Scope ==
* Proposal owners: Complete script and package it for Fedora.

* Other developers: N/A (not a System Wide Change)

* Release engineering: N/A (not a System Wide Change)

* List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)

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

[Bug 1411553] perl-File-Find-Object-v0.3.1 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-File-Find-Object-0.3.1
   ||-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2017-01-10 03:19:19



--- Comment #4 from Paul Howarth  ---
Build done (yesterday):
https://koji.fedoraproject.org/koji/taskinfo?taskID=17223078

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