[389-devel] Build failed in Jenkins: NIGHTLY #87

[mareynol]

See 


--
[...truncated 5271 lines...]
:assert: Should return error code 19
"""

suffix = DEFAULT_SUFFIX
subtree = "ou=people"
userid = "inactusr"
nousrs = 3
log.info('\''AccountInactivityLimit set to 10. Account will be 
inactivated if not accessed in 10 secs'\'')
add_users(topology_st, suffix, subtree, userid, nousrs, 0)
log.info('\''Sleep for 9 secs to check if account is not inactivated, 
expected value 0'\'')
time.sleep(9)
log.info('\''Account should not be inactivated since 
AccountInactivityLimit not exceeded'\'')
account_status(topology_st, suffix, subtree, userid, 3, 2, "Enabled")
log.info('\''Sleep for 2 more secs to check if account is 
inactivated'\'')
time.sleep(2)
account_status(topology_st, suffix, subtree, userid, 2, 0, "Disabled")
log.info('\''Sleep +9 secs to check if account {}3 is 
inactivated'\''.format(userid))
time.sleep(9)
account_status(topology_st, suffix, subtree, userid, 3, 2, "Disabled")
log.info('\''Add lastLoginTime attribute to all users and check if its 
activated'\'')
add_time_attr(topology_st, suffix, subtree, userid, nousrs, 
'\''lastLoginTime'\'')
>   account_status(topology_st, suffix, subtree, userid, nousrs, 0, 
> "Enabled")

:883:
 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

topology_st = 
suffix = '\''dc=example,dc=com'\'', subtree = '\''ou=people'\'', userid = 
'\''inactusr'\''
nousrs = 3, ulimit = 0, tochck = '\''Enabled'\''

def account_status(topology_st, suffix, subtree, userid, nousrs, ulimit, 
tochck):
"""Check account status for the given suffix, subtree, userid and 
nousrs"""

while (nousrs > ulimit):
usrrdn = '\''{}{}'\''.format(userid, nousrs)
userdn = '\''uid={},{},{}'\''.format(usrrdn, subtree, suffix)
if (tochck == "Enabled"):
try:
topology_st.standalone.simple_bind_s(userdn, USER_PASW)
except ldap.LDAPError as e:
log.error('\''User {} failed to login, expected 
0'\''.format(userdn))
>   raise e
E   CONSTRAINT_VIOLATION: {'\''info'\'': '\''Account inactivity 
limit exceeded. Contact system administrator to reset.'\'', '\''desc'\'': 
'\''Constraint violation'\''}

:306:
 CONSTRAINT_VIOLATION
 Captured stderr setup -
INFO:lib389.utils:Adding Local account policy plugin configuration entries
- Captured stderr call -
INFO:lib389.utils:AccountInactivityLimit set to 10. Account will be inactivated 
if not accessed in 10 secs
INFO:lib389.utils:add_users: Pass all of these as parameters suffix, subtree, 
userid and nousrs
INFO:lib389.utils:Sleep for 9 secs to check if account is not inactivated, 
expected value 0
INFO:lib389.utils:Account should not be inactivated since 
AccountInactivityLimit not exceeded
INFO:lib389.utils:Sleep for 2 more secs to check if account is inactivated
INFO:lib389.utils:Sleep +9 secs to check if account inactusr3 is inactivated
INFO:lib389.utils:Add lastLoginTime attribute to all users and check if its 
activated
INFO:lib389.utils:Enable account by replacing 
lastLoginTime/createTimeStamp/ModifyTimeStamp attribute
ERROR:lib389.utils:User uid=inactusr3,ou=people,dc=example,dc=com failed to 
login, expected 0
_ test_locinact_modrdn _

topology_st = 
accpol_local = None

def test_locinact_modrdn(topology_st, accpol_local):
"""Verify if user account is inactivated when moved from ou=groups to 
ou=people subtree.

:ID: 5f25bea3-fab0-4db4-b43d-2d47cc6e5ad1
:feature: Account Policy Plugin
:setup: Standalone instance, ou=people subtree configured for Local 
account
policy plugin configuration, set accountInactivityLimit to few 
secs.
:steps: 1. Add few users to ou=groups subtree in the default suffix
2. Plugin configured to ou=people subtree only.
3. Wait for few secs before it reaches accountInactivityLimit 
and check users.
4. Run ldapsearch as normal user, expected 0
5. Wait till accountInactivityLimit exceeded
6. Move users from ou=groups subtree to ou=people subtree
7. Check if users are inactivated, expected error 19
:assert: Should return error code 0 and 

Re: Requires for local install

[Samuel Sieb]

On 09/22/2017 06:47 PM, David Muse wrote:
I have a package with many subpackages.  Some of the subpackages depend 
on libraries provided by other subpackages.


When downloading with yum/dnf, the rpm's know what they depend on, and 
the dnf/yum can figure out what to install to satisfy the dependencies. 
No problem there.


But, when doing a yum localinstall or dnf install with a local path, the 
user has to either install all rpm's or manually resolve dependencies.


Is it common to specify inter-subpackage dependencies using Requires to 
resolve this, or are users just on their own if they're installing 
packages manually?


I'm not quite clear on what you're doing here, an example would be 
helpful.  But in general, if you are installing local packages, you have 
to pass all the local rpm files on the command line.  dnf will resolve 
any dependencies needed from the repos if necessary.  But obviously if 
there is a local file that is needed, dnf can't automatically find it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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
 807  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 801  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 691  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 663  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 273  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 169  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8dca05d55c   
drupal7-views-3.18-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e50abdd3d5   
python3-numpy-1.10.4-6.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e563119ec9   
php-horde-Horde-Image-2.5.2-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bfeae1e322   
wordpress-4.8.2-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5b8684c487   
php-horde-passwd-5.0.7-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e6c88309c0   
php-horde-wicked-2.0.8-1.el6
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a981889220   
php-horde-nag-4.2.17-1.el6


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

fedpkg-1.29-5.el6
golang-github-bgentry-speakeasy-0-0.11.git4aabc24.el6
golang-github-coreos-go-semver-0-0.14.git8ab6407.el6
php-symfony-psr-http-message-bridge-1.0.0-3.el6

Details about builds:



 fedpkg-1.29-5.el6 (FEDORA-EPEL-2017-5afb4ea106)
 Fedora utility for working with dist-git

Update Information:

Use correct build target for containers




 golang-github-bgentry-speakeasy-0-0.11.git4aabc24.el6 
(FEDORA-EPEL-2017-2d595bbd0c)
 Golang helpers for reading password input without cgo

Update Information:

Bump to upstream 4aabc24848ce5fd31929f7d1e4ea74d3709c14cd

References:

  [ 1 ] Bug #1250454 - Tracker for golang-github-bgentry-speakeasy
https://bugzilla.redhat.com/show_bug.cgi?id=1250454




 golang-github-coreos-go-semver-0-0.14.git8ab6407.el6 
(FEDORA-EPEL-2017-38842378ae)
 Go semantic versioning library

Update Information:

Bump to upstream 8ab6407b697782a06568d4b7f1db25550ec2e4c6

References:

  [ 1 ] Bug #1248718 - Tracker for golang-github-coreos-go-semver
https://bugzilla.redhat.com/show_bug.cgi?id=1248718




 php-symfony-psr-http-message-bridge-1.0.0-3.el6 (FEDORA-EPEL-2017-7246bc9c96)
 Symfony PSR HTTP message bridge

Update Information:

RPM only release  - Allow Symfony 3 - Modify tests - Apply patch to fix test
suite with !el6 and zendframework/zend-diactoros

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

Requires for local install

[David Muse]

Hello list,

I have a package with many subpackages.  Some of the subpackages depend 
on libraries provided by other subpackages.


When downloading with yum/dnf, the rpm's know what they depend on, and 
the dnf/yum can figure out what to install to satisfy the dependencies. 
No problem there.


But, when doing a yum localinstall or dnf install with a local path, the 
user has to either install all rpm's or manually resolve dependencies.


Is it common to specify inter-subpackage dependencies using Requires to 
resolve this, or are users just on their own if they're installing 
packages manually?


Thanks!

David Muse
david.m...@firstworks.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1494774] New: perl-System-Info-0.056 is available

[bugzilla]

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

Bug ID: 1494774
   Summary: perl-System-Info-0.056 is available
   Product: Fedora
   Version: rawhide
 Component: perl-System-Info
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.056
Current version/release in rawhide: 0.055-2.fc27
URL: http://search.cpan.org/dist/System-Info/

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

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

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

Based on the information from anitya: 
https://release-monitoring.org/project/15552/

-- 
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: How to chainbuild in a build override?

[Kevin Kofler]

Petr Pisar wrote:
> In rawhide, if you want a longer time isolation, you ask relengs for
> a sige tag, you do all builds there without affecting others and then
> you ask relengs to merge the builds back to rawhide. Of course this has
> same races and one needs to reaply all rawhide changes into the side tag
> otherwise a mismatches can happen after the merge.
> 
> I don't know if this procedure is acceptable for f27.

It is possible to do this (request a side tag) in a release. The KDE SIG 
frequently does this for larger updates, the GNOME team sometimes does too.

That said, side tags do put a strain on the infrastructure and thus should 
only be used where it makes sense.

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

Fedora 27 Beta 1.2 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 18/126 (x86_64), 1/18 (i386), 1/2 (arm)

ID: 146228  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/146228
ID: 146234  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146234
ID: 146243  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/146243
ID: 146255  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146255
ID: 146259  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/146259
ID: 146265  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/146265
ID: 146272  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/146272
ID: 146274  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/146274
ID: 146292  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/146292
ID: 146294  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/146294
ID: 146297  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/146297
ID: 146304  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/146304
ID: 146305  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/146305
ID: 146307  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/146307
ID: 146308  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/146308
ID: 146311  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/146311
ID: 146314  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/146314
ID: 146323  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/146323
ID: 146346  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/146346
ID: 146350  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/146350

Soft failed openQA tests: 4/126 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 146245  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/146245
ID: 146246  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/146246
ID: 146247  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/146247
ID: 146264  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/146264

Passed openQA tests: 100/126 (x86_64), 17/18 (i386)

Skipped openQA tests: 1 of 146
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170922.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 17/128 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170921.n.1):

ID: 145838  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/145838
ID: 145839  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/145839
ID: 145845  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/145845

Old failures (same test failed in Rawhide-20170921.n.1):

ID: 145802  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/145802
ID: 145808  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/145808
ID: 145824  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/145824
ID: 145828  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/145828
ID: 145847  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/145847
ID: 145866  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/145866
ID: 145867  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/145867
ID: 145868  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/145868
ID: 145869  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/145869
ID: 145871  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/145871
ID: 145872  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/145872
ID: 145883  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/145883
ID: 145889  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/145889
ID: 145904  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/145904
ID: 145921  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/145921

Soft failed openQA tests: 3/128 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170921.n.1):

ID: 145818  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/145818
ID: 145876  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/145876

Old soft failures (same test soft failed in Rawhide-20170921.n.1):

ID: 145819  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/145819

Passed openQA tests: 95/128 (x86_64)

New passes (same test did not pass in Rawhide-20170921.n.1):

ID: 145820  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/145820
ID: 145834  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/145834
ID: 145835  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/145835
ID: 145836  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/145836
ID: 145837  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/145837
ID: 145840  Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/145840
ID: 145841  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/145841
ID: 145842  Test: x86_64 KDE-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/145842
ID: 145843  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/145843
ID: 145844  Test: x86_64 KDE-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/145844
ID: 145846  Test: x86_64 KDE-live-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/145846
ID: 145863  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/145863
ID: 145874  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/145874
ID: 145877  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/145877
ID: 145892  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/145892

Skipped openQA tests: 1 of 130

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.07 to 0.37
Previous test data: 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 929  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 691  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 273  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 171  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 169  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
 168  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  35  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-17b77b3268   
botan-1.10.16-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-59c79d3a8a   
google-api-python-client-1.6.3-1.el7 python-httplib2-0.9.2-0.1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7bdf242c17   
drupal7-views-3.18-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-10553ac5bd   
ReviewBoard-2.5.16-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9f88067c22   
mpg123-1.25.6-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2795d59fcc   
python3-numpy-1.10.4-5.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-30a9c74908   
php-horde-Horde-Image-2.5.2-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5b07cc6958   
wordpress-4.8.2-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8da6477f0a   
moodle-3.1.8-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3a2abe4898   
php-horde-passwd-5.0.7-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a3ae700da7   
php-horde-wicked-2.0.8-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d49c1ef800   
php-horde-nag-4.2.17-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b8147c68   
openvpn-auth-ldap-2.0.3-15.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e3436f7a95   
libbson-1.3.5-4.el7


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

ansible-lint-3.4.15-1.el7
fedpkg-1.29-5.el7
libbson-1.3.5-4.el7
php-symfony-psr-http-message-bridge-1.0.0-3.el7
php-symfony-security-acl-2.8.0-4.el7
rakudo-MIME-Base64-1.2.1-1.el7

Details about builds:



 ansible-lint-3.4.15-1.el7 (FEDORA-EPEL-2017-7588b1d6c5)
 Best practices checker for Ansible

Update Information:

Update to 3.4.15 version

References:

  [ 1 ] Bug #1494183 - not compatible with ansible 2.4
https://bugzilla.redhat.com/show_bug.cgi?id=1494183




 fedpkg-1.29-5.el7 (FEDORA-EPEL-2017-f302e809c8)
 Fedora utility for working with dist-git

Update Information:

Use correct build target for containers




 libbson-1.3.5-4.el7 (FEDORA-EPEL-2017-e3436f7a95)
 Building, parsing, and iterating BSON documents

Update Information:

This release fixes CVE-2017-14227 vulnerability, a crash when parsing an empty
code string of a codewscope type.

References:

  [ 1 ] Bug #1494401 - CVE-2017-14227 libbson: Heap based buffer over read in 
the bson_utf8_validate function
https://bugzilla.redhat.com/show_bug.cgi?id=1494401




 php-symfony-psr-http-message-bridge-1.0.0-3.el7 (FEDORA-EPEL-2017-8f41aee8f8)
 Symfony PSR HTTP message bridge

Update Information:

RPM only release  - Allow Symfony 3 - Modify tests - Apply patch to fix test
suite with !el6 and zendframework/zend-diactoros




 php-symfony-security-acl-2.8.0-4.el7 (FEDORA-EPEL-2017-afa02aa335)
 Symfony Security Component - ACL (Access Control 

Fedora 27-20170922.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Server boot i386
Kde live i386

Passed openQA tests: 2/128 (x86_64)

Installed system changes in test x86_64 Atomic-dvd_ostree-iso install_default: 
System load changed from 0.05 to 0.33
Previous test data: https://openqa.fedoraproject.org/tests/145486#downloads
Current test data: https://openqa.fedoraproject.org/tests/146129#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Fabio Valentini]

For what it's worth: I just installed the 4.13.2 kernel from the
kernel-stabilization repo, and the nvidia akmod module (from negativo17
repo) failed to build (as expected). But after rebooting with the new
kernel, the system uses the fallback to nouveau correctly - without any
manual intervention. So, from my point of view, it seems everything works
as it is supposed to (well, except the compilation failure, but that's got
nothing to do with fedora).

Fabio

On Fri, Sep 22, 2017 at 10:58 PM Nicolas Chauvet  wrote:

> 2017-09-22 20:46 GMT+02:00  :
> > Oh boy. :)
> >
> > Does anyone know if the fallback is working properly? Because if so, then
> Just restoring the fact here, because despite the fallback idea is
> hans/WG the implementation is "RPM Fusion Community" original works.
> (1)
> So yet as soon as you are using "RPM Fusion", it works as expected.
>
> And furthermore, if you want to switch from nvidia to nouveau while
> the nvidia driver remains installed, you just need to unblacklist
> nouveau from cmdline (remove rd.driver.blacklist=nouveau
> modprobe.blacklist=nouveau).
> This is only implemented by the RPM Fusion "clean design".
>
> And could even be improved:
> https://bugzilla.redhat.com/show_bug.cgi?id=1489317 if anyone cares...
>
>
> (1)
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4498
>
>
> --
> -
>
> Nicolas (kwizart)
> ___
> 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: Kernel 4.13 rebase plans

[Peter Robinson]

On Fri, Sep 22, 2017 at 7:46 PM,   wrote:
> Oh boy. :)
>
> Does anyone know if the fallback is working properly? Because if so, then
> everyone is happy and we don't need to be having this discussion. Sounds
> like there's a good chance that's the case. (I don't have an nvidia card to
> test myself.)

If fallback is not working I would say that is the responsibility of
the Workstation product to deal with and test on each kernel cycle to
ensure that it is because "Negativo support is important for product
strategy.". It's no different for any of the other groups that depend
on the kernel. I know that the architecture working groups spend a
reasonable amount of time each cycle to ensure that there's no
regressions on their architectures for the new kernels. Given that
4.13 is going to be the release kernel for F-27 and that has been
known for some time I'm kind of surprised that this is a surprise at
all as I kind of figured you'd have wanted it working on the latest
shiny GNOME by now the fact it's taken this long to be picked up
tells me that people care less than the rhetoric

> If the fallback is not working, then FESCo will probably need to decide
> indeed.
>
> 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

[Test-Announce] Fedora 27 Candidate Beta-1.2 Available Now!

[rawhide]

According to the schedule [1], Fedora 27 Candidate Beta-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

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

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_27_Beta_1.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Beta_1.2_Security_Lab

All Beta priority test cases for each of these test pages [2] must
pass in order to meet the Beta Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-27/f-27-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
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

Re: Kernel 4.13 rebase plans

[Nicolas Chauvet]

2017-09-22 20:46 GMT+02:00  :
> Oh boy. :)
>
> Does anyone know if the fallback is working properly? Because if so, then
Just restoring the fact here, because despite the fallback idea is
hans/WG the implementation is "RPM Fusion Community" original works.
(1)
So yet as soon as you are using "RPM Fusion", it works as expected.

And furthermore, if you want to switch from nvidia to nouveau while
the nvidia driver remains installed, you just need to unblacklist
nouveau from cmdline (remove rd.driver.blacklist=nouveau
modprobe.blacklist=nouveau).
This is only implemented by the RPM Fusion "clean design".

And could even be improved:
https://bugzilla.redhat.com/show_bug.cgi?id=1489317 if anyone cares...


(1)
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4498


-- 
-

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

Re: Kernel 4.13 rebase plans

[Justin Forbes]

On Fri, Sep 22, 2017 at 3:25 PM, Michael Catanzaro
 wrote:
> On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams  wrote:
>>
>> On what grounds?  There is nothing in the Fedora guidelines that makes
>> package maintainers beholden to third-party (by definition, not part of
>> Fedora) repos.  There's nothing for FESCo to vote on, unless you are
>> going to propose that change.
>
>
> OK, I'll bite. The grounds are that FESCo has granted the WG full control
> over the Workstation product, and the kernel package is part of that
> product. Although I can't speak for the entire WG today, I would be fairly
> astounded if the WG were to choose to allow kernel updates to break Negativo
> users after having identified Negativo as a strategic priority and
> advertised it as supported. So if a kernel update goes out that breaks
> Negativo users, I would expect a policy to delay future kernel upgrades
> until Negativo has been tested and confirmed to be working. Since that would
> be controversial, someone would surely appeal to FESCo. Probably easier for
> everyone to take it straight to FESCo, right?
>
> But again, if there is already a technical solution (a fallback to noveau)
> in place and working, as I suspect (would be really nice if somebody could
> confirm that!) then it doesn't matter.

The agreement when the whole Negativo strategy started was that a
technical fallback would be in place. If it is not ready, you can't
blame the kernel. But sure, let's take it to FESCo, that will be a fun
meeting. I am chairing next week, and would be happy to put it on the
agenda.

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

Re: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, Michael Catanzaro  said:
> OK, I'll bite. The grounds are that FESCo has granted the WG full
> control over the Workstation product

Where is it documented that "full control" includes non-Fedora content?
I would have assumed (unless otherwise stated) that anything that's part
of the Fedora project is made up of Fedora content and still follows all
Fedora guidelines.

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

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Fri, Sep 22, 2017 at 2:21 PM, Chris Adams  wrote:

On what grounds?  There is nothing in the Fedora guidelines that makes
package maintainers beholden to third-party (by definition, not part 
of

Fedora) repos.  There's nothing for FESCo to vote on, unless you are
going to propose that change.


OK, I'll bite. The grounds are that FESCo has granted the WG full 
control over the Workstation product, and the kernel package is part of 
that product. Although I can't speak for the entire WG today, I would 
be fairly astounded if the WG were to choose to allow kernel updates to 
break Negativo users after having identified Negativo as a strategic 
priority and advertised it as supported. So if a kernel update goes out 
that breaks Negativo users, I would expect a policy to delay future 
kernel upgrades until Negativo has been tested and confirmed to be 
working. Since that would be controversial, someone would surely appeal 
to FESCo. Probably easier for everyone to take it straight to FESCo, 
right?


But again, if there is already a technical solution (a fallback to 
noveau) in place and working, as I suspect (would be really nice if 
somebody could confirm that!) then it doesn't matter.


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

Re: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, mcatanz...@gnome.org  said:
> If the fallback is not working, then FESCo will probably need to
> decide indeed.

On what grounds?  There is nothing in the Fedora guidelines that makes
package maintainers beholden to third-party (by definition, not part of
Fedora) repos.  There's nothing for FESCo to vote on, unless you are
going to propose that change.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[mcatanzaro]

Oh boy. :)

Does anyone know if the fallback is working properly? Because if so, 
then everyone is happy and we don't need to be having this discussion. 
Sounds like there's a good chance that's the case. (I don't have an 
nvidia card to test myself.)


If the fallback is not working, then FESCo will probably need to decide 
indeed.


Thanks,

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

Re: Kernel 4.13 rebase plans

[Neal Gompa]

On Fri, Sep 22, 2017 at 2:20 PM, Laura Abbott  wrote:
> On 09/22/2017 09:43 AM, mcatanz...@gnome.org wrote:
>>
>> On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth 
>> wrote:
>>>
>>> Pretty sure the last testing I did with the details form Hans's blog[0]
>>> the behaviour was that if the nvidia driver failed then the nouveau driver
>>> was a fallback (rather than the older instructions that totally blacklisted
>>> it leaving no GPU at all).
>>
>>
>> If that fallback is working, then I guess that's fine. (Though I'm not
>> speaking for the whole Working Group here... perhaps others expect it to
>> always work, I'm not sure.)
>>
>> But if Negativo users start complaining that their computers don't boot
>> anymore, then we'll definitely need to stop doing major kernel updates
>> ("taking the entire distro hostage" I guess) as the Negativo support is
>> important for product strategy. Hopefully it doesn't come to that.
>>
>> Michael
>>
>
> I appreciate that not having the nVidia driver work is not a good
> experience but we choose to do major kernel updates multiple times
> per release for many reasons. One of the biggest is that kernel
> versions eventually go EOL and no longer get official updates
> from the community (see https://www.kernel.org/ that 4.12 is now
> EOL). We have no hope of trying to sync to a LTS release and it's
> not feasible right now to have the two kernel maintainers try and
> manage our own stable release. Moving to a new major kernel version
> is the best way to provide bug fixes and security updates to
> Fedora users. It's not a perfect process by any means but any
> ideas about process improvement need to take that into account as
> well.

I would be extremely upset if we did move to longterm kernels. I use
Fedora precisely because I get current, up to date, relatively close
to vanilla builds of the kernel. If the Workstation WG is having
trouble with their current arrangement, then they should be exerting
pressure to fix the situation from NVIDIA's side, not Fedora's.

For that matter, if they *really* want that, then why not talk to NVIDIA
to have them set up an official repository that builds everything
properly (like negativo and RPM Fusion) and tracks our kernels and
builds kmod packages, just like they do for openSUSE Leap and
Tumbleweed.

It's not even difficult to do, since they clearly have an OBS that
supports tracking kernels and building kmod packages correctly. Just
have them build it for our distribution like they do for openSUSE and
publish. Then the WG can use that and stop trying to "hold the
distribution hostage".


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

Re: Kernel 4.13 rebase plans

[Laura Abbott]

On 09/22/2017 09:43 AM, mcatanz...@gnome.org wrote:
On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth  
wrote:
Pretty sure the last testing I did with the details form Hans's 
blog[0] the behaviour was that if the nvidia driver failed then the 
nouveau driver was a fallback (rather than the older instructions that 
totally blacklisted it leaving no GPU at all).


If that fallback is working, then I guess that's fine. (Though I'm not 
speaking for the whole Working Group here... perhaps others expect it to 
always work, I'm not sure.)


But if Negativo users start complaining that their computers don't boot 
anymore, then we'll definitely need to stop doing major kernel updates 
("taking the entire distro hostage" I guess) as the Negativo support is 
important for product strategy. Hopefully it doesn't come to that.


Michael



I appreciate that not having the nVidia driver work is not a good
experience but we choose to do major kernel updates multiple times
per release for many reasons. One of the biggest is that kernel
versions eventually go EOL and no longer get official updates
from the community (see https://www.kernel.org/ that 4.12 is now
EOL). We have no hope of trying to sync to a LTS release and it's
not feasible right now to have the two kernel maintainers try and
manage our own stable release. Moving to a new major kernel version
is the best way to provide bug fixes and security updates to
Fedora users. It's not a perfect process by any means but any
ideas about process improvement need to take that into account as
well.

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

[389-devel] [lib389] Issue #98: Improve dbscan output

[Sankar Ramalingam]

https://pagure.io/lib389/issue/98
https://pagure.io/lib389/issue/raw/files/bd77cfa7416a20e48ce1e1e62c163f229e06c879c58654dc8abd11b76a60530b-0001-fix-dbscan-out.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Luya Tshimbalanga]

On 12/09/17 02:47 PM, Laura Abbott wrote:
> On 09/05/2017 09:41 AM, Laura Abbott wrote:
>> Hi,
>>
>> Kernel 4.13 was released this past weekend. This kernel has been
>> built for rawhide and is building for F27 as well. We will be
>> following the same upgrade procedure as in the past. F25 and F26
>> will get rebased to 4.13 after a few stable releases, typically
>> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>> does not give release dates for stable release but given past
>> timings, this will probably happen towards the end of September.
>> As always, if you have any questions please let me know.
>>
>> Thanks,
>> Laura
>>
>
> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
> this morning but given it was released in conjunction with a new
> publicized CVE, it was slightly smaller and I'm inclined to wait
> for 4.13.3 before attempting to push anything to bodhi for F26.
>
> Thanks,
> Laura
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

On the topic, it will be nice to enable amdgpu for both AMD SI and CIK
cards (the earlier GCN) as well to help our fellow AMD team[0]. I am
currently using mystro256 COPR amd-staging-kernel[1] and sometime
amd-mainline-kernel[2] repositories for testing purpose.

The goal is simple: supporting all GCN cards with amdgpu drive and leave
radeon for pre-GCN while playing a fallback should amdgpu fail somehow.
The process may be too late for F27 but could be useful for F28.


References

[0] https://cgit.freedesktop.org/~agd5f/linux/?h=amd-mainline-hybrid-4.11
[1] https://copr.fedorainfracloud.org/coprs/mystro256/amd-staging-kernel/
[2] https://copr.fedorainfracloud.org/coprs/mystro256/amd-mainline-kernel/

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net

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

[Bug 1494301] perl-Test-Moose-More-0.050 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Test-Moose-More-0.050-1.fc27 has been pushed to the Fedora 27 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-2017-7ee35d9cdd

-- 
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 1494297] perl-libwww-perl-6.27 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-libwww-perl-6.27-2.fc27 has been pushed to the Fedora 27 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-2017-124d8d9481

-- 
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: Kernel 4.13 rebase plans

[Chris Adams]

Once upon a time, mcatanz...@gnome.org  said:
> But if Negativo users start complaining that their computers don't
> boot anymore, then we'll definitely need to stop doing major kernel
> updates ("taking the entire distro hostage" I guess) as the Negativo
> support is important for product strategy. Hopefully it doesn't come
> to that.

Just... no.

I don't use nVidia hardware (in part because of the driver shenanigans)
and I had not heard of Negativo before today.  That's not Fedora, and
certainly should not dictate how Fedora is run.

If any third-party repo wants to dictate kernel update requirements,
they can maintain their own kernels.  There is zero reason for all
Fedora users to suffer because of non-Fedora repos.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Ben Rosser]

On Fri, Sep 22, 2017 at 1:06 PM, Stephen John Smoogen  wrote:
> On 22 September 2017 at 12:43,   wrote:
>> But if Negativo users start complaining that their computers don't boot
>> anymore, then we'll definitely need to stop doing major kernel updates
>> ("taking the entire distro hostage" I guess) as the Negativo support is
>> important for product strategy. Hopefully it doesn't come to that.
>>
>
> Please don't try that. No one wins from fights like that.
>
> Anything further I could write on this is hard because I am so tired
> of this yearly self-inflicted headache.

I, too, am tired of this sort of thing, but I feel that someone needs
to say something here so...

Something seems wrong about basing "product strategy" for Fedora on
compatibility with a single third party repository. This is *not* how
the third party repository policy was sold; the goal was supposedly to
curate useful repositories for given Fedora editions, not to make them
the center of our "strategy". In fact I was concerned at the time that
more central oversight of third party repositories was needed rather
than leaving it up to the individual working groups, but I was
reassured that it wasn't because they were just sort of optional
extras.

If we block changes to the entire distro because we are concerned
about breaking a specific third party repository, then effectively,
it's *not* a third party repository. It's as much a part of Fedora as
any other component, except for a thin pretense that we are not
distributing this nonfree software directly.

In which case, I would be prepared to argue again that it should be
FESCo that curates the list of such repositories, not the working
groups.

I use nvidia drivers on my system and I'm all for acknowledging that
in the "real world" people use nonfree software, but I find myself
somewhat concerned at the apparent change of culture and direction
here. All the more so because of the apparent attempt to brush this
potential concern under the rug with the "taking the distro hostage"
comment, which I think is an overly excitable way to phrase a
legitimate concern.

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

Re: Kernel 4.13 rebase plans

[Tomasz Torcz]

On Fri, Sep 22, 2017 at 11:43:21AM -0500, mcatanz...@gnome.org wrote:
> On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth 
> wrote:
> > Pretty sure the last testing I did with the details form Hans's blog[0]
> > the behaviour was that if the nvidia driver failed then the nouveau
> > driver was a fallback (rather than the older instructions that totally
> > blacklisted it leaving no GPU at all).
> 
> If that fallback is working, then I guess that's fine. (Though I'm not
> speaking for the whole Working Group here... perhaps others expect it to
> always work, I'm not sure.)
> 
> But if Negativo users start complaining that their computers don't boot
> anymore, then we'll definitely need to stop doing major kernel updates
> ("taking the entire distro hostage" I guess) as the Negativo support is
> important for product strategy. Hopefully it doesn't come to that.

  I cannot believe what I read. I don't think there would ever be
agreement to forfeit one of the greatest Fedora strength - current
kernel – for the sake of users of proprietary driver from 3rd repo!

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Stephen John Smoogen]

On 22 September 2017 at 12:43,   wrote:
> On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth 
> wrote:
>>
>> Pretty sure the last testing I did with the details form Hans's blog[0]
>> the behaviour was that if the nvidia driver failed then the nouveau driver
>> was a fallback (rather than the older instructions that totally blacklisted
>> it leaving no GPU at all).
>
>
> If that fallback is working, then I guess that's fine. (Though I'm not
> speaking for the whole Working Group here... perhaps others expect it to
> always work, I'm not sure.)
>
> But if Negativo users start complaining that their computers don't boot
> anymore, then we'll definitely need to stop doing major kernel updates
> ("taking the entire distro hostage" I guess) as the Negativo support is
> important for product strategy. Hopefully it doesn't come to that.
>

Please don't try that. No one wins from fights like that.

Anything further I could write on this is hard because I am so tired
of this yearly self-inflicted headache.


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



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

Re: Kernel 4.13 rebase plans

[mcatanzaro]

On Fri, Sep 22, 2017 at 8:41 AM, James Hogarth 
 wrote:
Pretty sure the last testing I did with the details form Hans's 
blog[0] the behaviour was that if the nvidia driver failed then the 
nouveau driver was a fallback (rather than the older instructions 
that totally blacklisted it leaving no GPU at all).


If that fallback is working, then I guess that's fine. (Though I'm not 
speaking for the whole Working Group here... perhaps others expect it 
to always work, I'm not sure.)


But if Negativo users start complaining that their computers don't boot 
anymore, then we'll definitely need to stop doing major kernel updates 
("taking the entire distro hostage" I guess) as the Negativo support is 
important for product strategy. Hopefully it doesn't come to that.


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

[Bug 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2017 |impact=moderate,public=2017
   |0912,reported=20170913,sour |0912,reported=20170913,sour
   |ce=upstream,cvss3=6.5/CVSS: |ce=upstream,cvss3=6.5/CVSS:
   |3.0/AV:N/AC:H/PR:N/UI:N/S:U |3.0/AV:N/AC:H/PR:N/UI:N/S:U
   |/C:L/I:N/A:H,cwe=CWE-125,rh |/C:L/I:N/A:H,cwe=CWE-125,rh
   |el-5/perl=new,rhel-6/perl=n |el-5/perl=notaffected,rhel-
   |ew,rhel-7/perl=wontfix,rhsc |6/perl=notaffected,rhel-7/p
   |l-2/rh-perl520-perl=wontfix |erl=notaffected,rhscl-2/rh-
   |,rhscl-2/rh-perl524-perl=wo |perl520-perl=notaffected,rh
   |ntfix,fedora-all/perl=affec |scl-2/rh-perl524-perl=wontf
   |ted |ix,fedora-all/perl=affected



--- Comment #3 from Cedric Buissart  ---
This is a side effect of upstream commit 285b5ca0, introduced in perl v5.24.0.
As a consequence, perl as shipped in RHEL-5 & RHEL-6 & RHEL-7 are not affected.

-- 
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 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2017 |impact=moderate,public=2017
   |0912,reported=20170913,sour |0912,reported=20170913,sour
   |ce=upstream,cvss3=6.5/CVSS: |ce=upstream,cvss3=6.5/CVSS:
   |3.0/AV:N/AC:H/PR:N/UI:N/S:U |3.0/AV:N/AC:H/PR:N/UI:N/S:U
   |/C:L/I:N/A:H,cwe=CWE-125,rh |/C:L/I:N/A:H,cwe=CWE-125,rh
   |el-5/perl=new,rhel-6/perl=n |el-5/perl=new,rhel-6/perl=n
   |ew,rhel-7/perl=new,rhscl-2/ |ew,rhel-7/perl=wontfix,rhsc
   |rh-perl520-perl=new,rhscl-2 |l-2/rh-perl520-perl=wontfix
   |/rh-perl524-perl=new,fedora |,rhscl-2/rh-perl524-perl=wo
   |-all/perl=affected  |ntfix,fedora-all/perl=affec
   ||ted



-- 
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: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 15:02, James Hogarth 
wrote:

>
>
> On 22 September 2017 at 14:50, Gary Gatling  wrote:
>
>>
>>
>> On Fri, Sep 22, 2017 at 9:41 AM, James Hogarth 
>> wrote:
>>
>>>

>>> Pretty sure the last testing I did with the details form Hans's blog[0]
>>> the behaviour was that if the nvidia driver failed then the nouveau driver
>>> was a fallback (rather than the older instructions that totally blacklisted
>>> it leaving no GPU at all).
>>>
>>> Of course this is only helpful when the GPU is supported by nouveau ;)
>>>
>>> Note I haven't tested the negativo driver yet on the stabalization copr
>>> as I prefer the bumblebee experience since that keeps the discrete GPU
>>> powered down saving battery and temperatures when not in use ... and the
>>> negativo driver flips everything over to running on the discrete GPU and
>>> ignores the Intel integrated one.
>>>
>>> Given that it's fundamentally the same driver though I expect the
>>> experience to be the same - willing to test and report back :)
>>>
>>>
>> Hello,
>>
>> I am looking at the patch referenced earlier in the thread. There was a
>> problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
>> if it was really needed.
>>
>> I will try to test it with bumblebee-nvidia when I have time this weekend
>> on 4.12 and 4.13 beta.
>>
>> Thank you.
>>
>>
>> _
>>
>>
> Do keep in mind that the patching which is done to get it working (note
> that patch still failed compiling for me on 4.13.2 ... no patch was needed
> on 4.13.1) also has to change the license type so that it works, as a
> non-GPL symbol in use was marked GPL apparently ... which of course means
> it cannot be distributed by Negativo as a "fix" ...
>
> Checking the comments on the Negativo nvidia-driver site[0] it appears
> that there's already reports of it not working on F27 with that kernel:
>
> > ANARCHISTCAT
> > September 20, 2017 at 12:52 am
> > With Fedora 27 nvidia driver 384.69-1.fc27 and kernel
> 4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile
> the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
> > 2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module
> nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
> > 2017/09/20 00:40:28 akmodsbuild: make[2]: ***
> [scripts/Makefile.modpost:91: __modpost] Error 1
> > 2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules]
> Error 2
> > 2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory
> ‘/usr/src/kernels/4.13.2-300.fc27.x86_64’
>
>
>
> [0] https://negativo17.org/nvidia-driver/
>
>
And just to confirm my own experiences 

With the negativo driver the build fails:

  CC [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-drm/nv-pci-table.o
ld -r -o /var/lib/dkms/nvidia/384.69/build/nvidia/nv-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-frontend.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-instance.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-acpi.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-chrdev.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-cray.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-dma.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-gvi.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-i2c.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-mempool.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-mmap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-p2p.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-pat.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-procfs.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-usermap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-vm.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-vtophys.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-mlock.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-pci.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-registry.o
/var/lib/dkms/nvidia/384.69/build/nvidia/os-usermap.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-modeset-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-pci-table.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-kthread-q.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-kthread-q-selftest.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv-memdbg.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nv_uvm_interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia/nvlink_linux.o
ld -r -o
/var/lib/dkms/nvidia/384.69/build/nvidia-modeset/nv-modeset-interface.o
/var/lib/dkms/nvidia/384.69/build/nvidia-modeset/nvidia-modeset-linux.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-uvm.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-modeset.o
  LD [M]  /var/lib/dkms/nvidia/384.69/build/nvidia-drm.o
  Building modules, stage 2.
  MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'lockdep_init_map'
make[2]: *** 

[EPEL-devel] Re: EOL for EPEL

[James Hogarth]

On 22 September 2017 at 15:21, Stephen John Smoogen 
wrote:

> On 22 September 2017 at 07:28, Somers-Harris, David | David | OPS
>  wrote:
> > Hello,
> >
> >
> >
> > It is my understanding that the EOL for each EPEL is in line with RHEL.
> >
> >
>
> 1. The EOL of any EPEL repository is the "public" lifetime of an
> upstream Red Hat Enterprise Linux. Public currently means when a RHEL
> is in Production Level 1,2 or 3. It does not cover when the product is
> in what is currently known as Extended User Support. [I use currently
> because this email may be read 4-10 years from now and those terms may
> have been relabeled.]
>
> 2. The EOL of a package in an EPEL repository is set by the
> maintainer(s) of that package. They can orphan or remove a package at
> their discretion and the package will be removed soon afterwords.
>
> https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
> https://access.redhat.com/solutions/690063
>
>
>
To make this a little clearer, and highlight some of the limitations we
face as packagers maintaining things in EPEL, I had to EOL owncloud in
EPEL6 a year (ish) back as the version of PHP that was shipped was too old
to support the application ... even though upstream or alternate repos like
remirepo can still support the package and maintain it on EL6 as they use
stuff like SCL to have the newer PHP version.

Similarly very soon (weeks or month or two at most) I'll be retiring
owncloud and nextcloud from EPEL7 as it's no longer possible for me to
maintain it there, though using upstream or alternate repos would still be
an option.

Since EPEL is a volunteer effort for any packages you really care about
it's important to mirror locally so you can rebuild systems safely, and we
value help in testing where we've carried out maintainer patches to handle
the package on something that is otherwise generally unsupported upstream
(I did this for sslh on EPEL5 for a while for instance)... it's also best
effort so please pay attention and file bugs where maintainers don't notice
an upstream release or where there is a need to formally retire for the
sake of security etc when it can no longer be built on the older systems.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

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


--- Doc Text *updated* by Cedric Buissart  ---
A heap buffer overread was found in perl's grok_bslash_N() function, which is 
used in the compilation of Unicode nodes in regular expressions, possibly 
leading to crash or dump of memory segments via the error output. An attacker 
able to provide a specially crafted regular expression could look for sensible 
information in the error message, or crash perl.


-- 
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 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

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


--- Doc Text *updated* by Cedric Buissart  ---
A heap buffer overread was found in perl's grok_bslash_N() function, which is 
used in the compilation of Unicode nodes in regular expressions, possibly 
leading to crash or dump of memory segments via the error output. An attacker 
able to give maliciously crafted regular expression could look for sensible 
information in the error message, or crash perl.


-- 
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

[389-devel] [lib389] Issue #98: Improve dbscan output

[Sankar Ramalingam]

https://pagure.io/lib389/issue/98
https://pagure.io/lib389/issue/raw/files/b8852d368512f2bf5fcfb5912802bf8d18d2496e046bd12d29931495d9c69272-0001-fix-dbscan-out.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1492093] CVE-2017-12883 perl: Buffer over-read in regular expression parser

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

   Priority|low |medium
   Fixed In Version||perl 5.24.3, perl 5.26.1,
   ||perl 5.27.4
 Whiteboard|impact=low,public=20170912, |impact=moderate,public=2017
   |reported=20170913,source=up |0912,reported=20170913,sour
   |stream,cvss3=6.5/CVSS:3.0/A |ce=upstream,cvss3=6.5/CVSS:
   |V:N/AC:H/PR:N/UI:N/S:U/C:L/ |3.0/AV:N/AC:H/PR:N/UI:N/S:U
   |I:N/A:H,cwe=CWE-125,rhel-5/ |/C:L/I:N/A:H,cwe=CWE-125,rh
   |perl=new,rhel-6/perl=new,rh |el-5/perl=new,rhel-6/perl=n
   |el-7/perl=new,rhscl-2/rh-pe |ew,rhel-7/perl=new,rhscl-2/
   |rl520-perl=new,rhscl-2/rh-p |rh-perl520-perl=new,rhscl-2
   |erl524-perl=new,fedora-all/ |/rh-perl524-perl=new,fedora
   |perl=affected   |-all/perl=affected
   Severity|low |medium



-- 
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] Re: EOL for EPEL

[Stephen John Smoogen]

On 22 September 2017 at 07:28, Somers-Harris, David | David | OPS
 wrote:
> Hello,
>
>
>
> It is my understanding that the EOL for each EPEL is in line with RHEL.
>
>

1. The EOL of any EPEL repository is the "public" lifetime of an
upstream Red Hat Enterprise Linux. Public currently means when a RHEL
is in Production Level 1,2 or 3. It does not cover when the product is
in what is currently known as Extended User Support. [I use currently
because this email may be read 4-10 years from now and those terms may
have been relabeled.]

2. The EOL of a package in an EPEL repository is set by the
maintainer(s) of that package. They can orphan or remove a package at
their discretion and the package will be removed soon afterwords.

https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
https://access.redhat.com/solutions/690063



>
> For example, RHEL 6 EOL is 2020-11-30 so EPEL-6 EOL is also 2020-11-30.
>
> However, I can’t find this clearly documented anywhere.
>
>
>
> I found historical information which backs up my understanding, for example
> for EPEL-5: https://www.spinics.net/linux/fedora/epel-devel/msg00956.html
>
>
>
> But I can’t find any official document which lays it out clearly.
>
>
>
> Can somebody point me to something which spells out the EOL date for EPEL-6
> and EPEL-7?
>
> Or at least the relationship between EPEL EOLs and RHEL EOLs.
>
>
>
> Thanks!
>
> David
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>



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

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 14:50, Gary Gatling  wrote:

>
>
> On Fri, Sep 22, 2017 at 9:41 AM, James Hogarth 
> wrote:
>
>>
>>>
>> Pretty sure the last testing I did with the details form Hans's blog[0]
>> the behaviour was that if the nvidia driver failed then the nouveau driver
>> was a fallback (rather than the older instructions that totally blacklisted
>> it leaving no GPU at all).
>>
>> Of course this is only helpful when the GPU is supported by nouveau ;)
>>
>> Note I haven't tested the negativo driver yet on the stabalization copr
>> as I prefer the bumblebee experience since that keeps the discrete GPU
>> powered down saving battery and temperatures when not in use ... and the
>> negativo driver flips everything over to running on the discrete GPU and
>> ignores the Intel integrated one.
>>
>> Given that it's fundamentally the same driver though I expect the
>> experience to be the same - willing to test and report back :)
>>
>>
> Hello,
>
> I am looking at the patch referenced earlier in the thread. There was a
> problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
> if it was really needed.
>
> I will try to test it with bumblebee-nvidia when I have time this weekend
> on 4.12 and 4.13 beta.
>
> Thank you.
>
>
> _
>
>
Do keep in mind that the patching which is done to get it working (note
that patch still failed compiling for me on 4.13.2 ... no patch was needed
on 4.13.1) also has to change the license type so that it works, as a
non-GPL symbol in use was marked GPL apparently ... which of course means
it cannot be distributed by Negativo as a "fix" ...

Checking the comments on the Negativo nvidia-driver site[0] it appears that
there's already reports of it not working on F27 with that kernel:

> ANARCHISTCAT
> September 20, 2017 at 12:52 am
> With Fedora 27 nvidia driver 384.69-1.fc27 and kernel
4.13.2-300.fc27.x86_64 i got with akmod an error and its unable to compile
the driver 2017/09/20 00:40:28 akmodsbuild: MODPOST 4 modules
> 2017/09/20 00:40:28 akmodsbuild: FATAL: modpost: GPL-incompatible module
nvidia.ko uses GPL-only symbol ‘lockdep_init_map’
> 2017/09/20 00:40:28 akmodsbuild: make[2]: ***
[scripts/Makefile.modpost:91: __modpost] Error 1
> 2017/09/20 00:40:28 akmodsbuild: make[1]: *** [Makefile:1520: modules]
Error 2
> 2017/09/20 00:40:28 akmodsbuild: make[1]: Leaving directory
‘/usr/src/kernels/4.13.2-300.fc27.x86_64’



[0] https://negativo17.org/nvidia-driver/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Gary Gatling]

On Fri, Sep 22, 2017 at 9:41 AM, James Hogarth 
wrote:

>
>>
> Pretty sure the last testing I did with the details form Hans's blog[0]
> the behaviour was that if the nvidia driver failed then the nouveau driver
> was a fallback (rather than the older instructions that totally blacklisted
> it leaving no GPU at all).
>
> Of course this is only helpful when the GPU is supported by nouveau ;)
>
> Note I haven't tested the negativo driver yet on the stabalization copr as
> I prefer the bumblebee experience since that keeps the discrete GPU powered
> down saving battery and temperatures when not in use ... and the negativo
> driver flips everything over to running on the discrete GPU and ignores the
> Intel integrated one.
>
> Given that it's fundamentally the same driver though I expect the
> experience to be the same - willing to test and report back :)
>
>
Hello,

I am looking at the patch referenced earlier in the thread. There was a
problem with a missing file in nvidia's archive (nv_compiler.h) I am unsure
if it was really needed.

I will try to test it with bumblebee-nvidia when I have time this weekend
on 4.12 and 4.13 beta.

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

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 22 September 2017 at 14:34, Matthew Miller 
wrote:

> On Fri, Sep 22, 2017 at 09:22:08AM -0400, Josh Boyer wrote:
> > > repo is supported and it needs to not break. We've been super super
> lenient
> >
> > That's a completely untenable position.  There is only one kernel for
> > all the Editions.  There will be times where the kernel needs to be
> > updated to fix a CVE and it breaks the nVidia driver.  There is no way
> > you can hold the entire distro hostage to an out-of-tree *proprietary*
> > driver.
>
> I thought the desktop team was working on a plan where if there is a
> kernel update with no working Nvidia driver, the new kernel would be
> installed but the default boot would stay the old one until the driver
> update is available (overridable by the user at any time or on the
> distro side if we flag a kernel update as important or critical for
> security). I've got some misgivings about even that, but it sounds far
> better than holding back the kernel overall.
>
>
>
Pretty sure the last testing I did with the details form Hans's blog[0] the
behaviour was that if the nvidia driver failed then the nouveau driver was
a fallback (rather than the older instructions that totally blacklisted it
leaving no GPU at all).

Of course this is only helpful when the GPU is supported by nouveau ;)

Note I haven't tested the negativo driver yet on the stabalization copr as
I prefer the bumblebee experience since that keeps the discrete GPU powered
down saving battery and temperatures when not in use ... and the negativo
driver flips everything over to running on the discrete GPU and ignores the
Intel integrated one.

Given that it's fundamentally the same driver though I expect the
experience to be the same - willing to test and report back :)




[0] https://hansdegoede.livejournal.com/17356.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[Matthew Miller]

On Fri, Sep 22, 2017 at 09:22:08AM -0400, Josh Boyer wrote:
> > repo is supported and it needs to not break. We've been super super lenient
> 
> That's a completely untenable position.  There is only one kernel for
> all the Editions.  There will be times where the kernel needs to be
> updated to fix a CVE and it breaks the nVidia driver.  There is no way
> you can hold the entire distro hostage to an out-of-tree *proprietary*
> driver.

I thought the desktop team was working on a plan where if there is a
kernel update with no working Nvidia driver, the new kernel would be
installed but the default boot would stay the old one until the driver
update is available (overridable by the user at any time or on the
distro side if we flag a kernel update as important or critical for
security). I've got some misgivings about even that, but it sounds far
better than holding back the kernel overall.

-- 
Matthew Miller

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

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Fri, Sep 22, 2017 at 9:05 AM, Michael Catanzaro
 wrote:
> On Fri, Sep 22, 2017 at 6:54 AM, Josh Boyer 
> wrote:
>>
>> Absolutely not.
>>
>> josh
>
>
> If it breaks the Negativo repo, then yes it is. The Nvidia driver from that

No, it's really not.

> repo is supported and it needs to not break. We've been super super lenient

That's a completely untenable position.  There is only one kernel for
all the Editions.  There will be times where the kernel needs to be
updated to fix a CVE and it breaks the nVidia driver.  There is no way
you can hold the entire distro hostage to an out-of-tree *proprietary*
driver.

> with allowing kernel updates in the Workstation product, since it seems to
> be working well for everyone involved, but that would need to be
> reconsidered if a kernel update intentionally breaks an important subset of
> our users. (Note: we only support Nvidia if installed from the Negativo
> repo, not from anywhere else.)

No, you misunderstand.  Nobody intentionally broke nvidia.  It happens
during the normal course of development because nvidia is out-of-tree
and the upstream project does not preserve ABI.  This is the price a
driver pays for being out of tree.  The only viable solution is to get
the driver upstream, which is not likely to happen.

> It sounds like patches are already available, so it shouldn't be a huge
> problem to get the Nvidia package updated.

Great.

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

Re: Kernel 4.13 rebase plans

[Michael Catanzaro]

On Fri, Sep 22, 2017 at 6:54 AM, Josh Boyer  
wrote:

Absolutely not.

josh


If it breaks the Negativo repo, then yes it is. The Nvidia driver from 
that repo is supported and it needs to not break. We've been super 
super lenient with allowing kernel updates in the Workstation product, 
since it seems to be working well for everyone involved, but that would 
need to be reconsidered if a kernel update intentionally breaks an 
important subset of our users. (Note: we only support Nvidia if 
installed from the Negativo repo, not from anywhere else.)


It sounds like patches are already available, so it shouldn't be a huge 
problem to get the Nvidia package updated.


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

[HEADS UP] Removing unnecessary dac_override capability in SELinux modules

[Lukas Vrabec]

Hi Everybody,

I'll push builds with updated SELinux security policy into Rawhide soon, 
this build will remove unnecessary dac_override capability in domains 
where it's not needed. Because of this change, we're able to remove a 
lot of unnecessary rules allowing dac_override, which means tightened 
security in whole Fedora from SELinux POV.


This change will be part of build: selinux-policy-3.13.1-288.fc28.noarch

Tracker bug is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1494520

This may result in some AVCs related to missing DAC_OVERRIDE capability. 
Feel free to create a bugzilla or add AVCs to this issue on github:

https://github.com/fedora-selinux/selinux-policy/issues/200

I'll be lurking around fedora rawhide bugs very often and I'm ready to 
fix all these bugs asap also with new builds.

Feel free to use selinux-policy nightly builds to get fixes ASAP:
https://copr.fedorainfracloud.org/coprs/lvrabec/selinux-policy-nightly/

Thanks,
Lukas.

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to chainbuild in a build override?

[Ralf Corsepius]

On 09/22/2017 01:07 PM, Petr Pisar wrote:

On 2017-09-22, Ralf Corsepius  wrote:

How to build a sub tree of packages in fc27, when the root of this tree
changed SONAME?


In rawhide, if you want a longer time isolation, you ask relengs for
a sige tag, you do all builds there without affecting others and then
you ask relengs to merge the builds back to rawhide. Of course this has
same races and one needs to reaply all rawhide changes into the side tag
otherwise a mismatches can happen after the merge.


This certainly makes sense for larger number of packages.


I don't know if this procedure is acceptable for f27.

I would not want to do this.

However, I meanwhile seem to have resolved my problem.

The trick was to use several build overrides, one for each "tree level" 
of the package tree being involved.


In this case, the tree was 2 levels deep, comprising 6 packages, with a 
dependency graph like this:


A1 -> B1
   -> B2
   -> B3 -> C1
 -> C2

One build override on "A1" and one build override on "B3".

As Tom said, painful, but doable due to the fairly small size of 
packages being involved ;)



In my opinion the whole idea of chaning a SONAME in f27 is wrong.


Nah, it's just a more or less a last minute update (Remember F27 is 
still in testing!), which seemed useful because A1's upstream released 
the first major bugfix update for ca. 2 years. "Just in time"/"last 
minute" to make it into Fedora.


In former Fedora times, I would have updated A1 by brute force and then 
gradually have let the other packages catch up.


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

Re: Kernel 4.13 rebase plans

[Josh Boyer]

On Fri, Sep 22, 2017 at 4:42 AM, James Hogarth  wrote:
>
>
> On 15 September 2017 at 11:00, James Hogarth 
> wrote:
>>
>>
>>
>> On 13 September 2017 at 01:39, James Hogarth 
>> wrote:
>>>
>>>
>>>
>>> On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:
>>>
>>> On 09/05/2017 09:41 AM, Laura Abbott wrote:

 Hi,

 Kernel 4.13 was released this past weekend. This kernel has been
 built for rawhide and is building for F27 as well. We will be
 following the same upgrade procedure as in the past. F25 and F26
 will get rebased to 4.13 after a few stable releases, typically
 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
 does not give release dates for stable release but given past
 timings, this will probably happen towards the end of September.
 As always, if you have any questions please let me know.

 Thanks,
 Laura

>>>
>>> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
>>> this morning but given it was released in conjunction with a new
>>> publicized CVE, it was slightly smaller and I'm inclined to wait
>>> for 4.13.3 before attempting to push anything to bodhi for F26.
>>>
>>>
>>>
>>> Thanks for the update Laura
>>>
>>> I'll pop that on my system tomorrow for some early testing and when
>>> you're ready with the bodhi update will add the feedback.
>>>
>>
>> Hi,
>>
>> Installed and running well here:
>>
>> Intel® Core™ i5-6300HQ CPU @ 2.30GHz × 4 Intel® HD Graphics 530 (Skylake
>> GT2) / Nvidia-bumblebee 384.69 on NV117
>>
>> WiFI working, bluetooth working, GPU works still.
>>
>> Ran through both the default and performance kernel regression tests[0] -
>> both passed.
>>
>> https://apps.fedoraproject.org/kerneltest/kernel/4.13.1-200.fc26.x86_64
>>
>> Incidentally I enabled the bfq scheduler for my spinning rust large data
>> drive and kyber for my SSD (since they have had some time to initially "bed
>> in" in 4.12)  and the system feels noticeably more responsive than on cfq
>> before ... though I wonder how much is a placebo effect ... might be fun to
>> switch it up and do some bonnie and iozone testing at some point.
>>
>> Cheers,
>>
>> James
>>
>>
>> [0] https://fedoraproject.org/wiki/KernelTestingInitiative
>
>
>
> Something happened in the 4.13.2 release which broke the nvidia driver.
>
> A few symbols changed and there was something that flipped to a GPL labelled
> symbol.
>
> I know we don't directly provide that for various reasons, but there is the
> initiative with Negativo etc that the Workstation Working Group has
> highlighted several times.
>
> See these posts:
>
> http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/
>
> https://devtalk.nvidia.com/default/topic/1023822/linux/-patch-384-69-kernel-4-13-4-14-staging-/
>
> It refers to 4.14-rc1 but I saw the identical issues on 4.13.2-200 with
> this.
>
> Is this something worth holding back on the kernel release on F26 for the
> time being?

Absolutely not.

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

Broken perl-libwww-perl-6.27-1.fc28

[Petr Pisar]

I accidentally build perl-libwww-perl-6.27-1.fc28 that cannot be
installed because of broken dependencies. There is already
perl-libwww-perl-6.27-2.fc28 that fixes, but it still has not yet get
into f28-build target.

Hopefully next compose will resolve it because it looks like after
introducing the rawhide autosigning packagers are unable to untag
thier builds:

$ koji untag f28 perl-libwww-perl-6.27-1.fc28
ActionNotAllowed: tag requires autosign permission

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

[EPEL-devel] EOL for EPEL

[Somers-Harris, David | David | OPS]

Hello,

It is my understanding that the EOL for each EPEL is in line with RHEL.

For example, RHEL 6 EOL is 2020-11-30 so EPEL-6 EOL is also 2020-11-30.
However, I can’t find this clearly documented anywhere.

I found historical information which backs up my understanding, for example for 
EPEL-5: https://www.spinics.net/linux/fedora/epel-devel/msg00956.html

But I can’t find any official document which lays it out clearly.

Can somebody point me to something which spells out the EOL date for EPEL-6 and 
EPEL-7?
Or at least the relationship between EPEL EOLs and RHEL EOLs.

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

Re: How to chainbuild in a build override?

[Petr Pisar]

On 2017-09-22, Ralf Corsepius  wrote:
> How to build a sub tree of packages in fc27, when the root of this tree 
> changed SONAME?
>
In rawhide, if you want a longer time isolation, you ask relengs for
a sige tag, you do all builds there without affecting others and then
you ask relengs to merge the builds back to rawhide. Of course this has
same races and one needs to reaply all rawhide changes into the side tag
otherwise a mismatches can happen after the merge.

I don't know if this procedure is acceptable for f27.

In my opinion the whole idea of chaning a SONAME in f27 is wrong.

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

[389-devel] [lib389] Issue #98: Improve dbscan output

[Sankar Ramalingam]

https://pagure.io/lib389/issue/98
https://pagure.io/lib389/issue/raw/files/8e0ef32b53c7cb775d1a663a7c6e8669c908c296cbf8489680d64acf7d66f435-0001-fix-dbscan-out.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[Bug 1494297] perl-libwww-perl-6.27 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-libwww-perl-6.27-2.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-124d8d9481

-- 
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

ppisar pushed to perl-libwww-perl (f27). "Provide hidden modules"

[notifications]

From 5f0972df100b38531969bf7902755c1e5a154075 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 10:05:30 +
Subject: Provide hidden modules


---

diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index c54cc13..14741dd 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,6 +1,6 @@
 Name:   perl-libwww-perl
 Version:6.27
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:A Perl interface to the World-Wide Web
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/libwww-perl/
@@ -106,6 +106,9 @@ Requires:   perl(Net::HTTP) >= 6.07
 Requires:   perl(URI) >= 1.10
 Requires:   perl(URI::Escape)
 Requires:   perl(WWW::RobotRules) >= 6
+Provides:   perl(LWP::Debug::TraceHTTP::Socket) = %{version}
+Provides:   perl(LWP::Protocol::http::Socket) = %{version}
+Provides:   perl(LWP::Protocol::http::SocketMethods) = %{version}
 
 %description
 The libwww-perl collection is a set of Perl modules which provides a simple and
@@ -145,6 +148,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 6.27-2
+- Provide hidden modules
+
 * Fri Sep 22 2017 Petr Pisar  - 6.27-1
 - 6.27 bump
 



https://src.fedoraproject.org/rpms/perl-libwww-perl/c/5f0972df100b38531969bf7902755c1e5a154075?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-libwww-perl (master). "Provide hidden modules"

[notifications]

From 5f0972df100b38531969bf7902755c1e5a154075 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 10:05:30 +
Subject: Provide hidden modules


---

diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index c54cc13..14741dd 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,6 +1,6 @@
 Name:   perl-libwww-perl
 Version:6.27
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:A Perl interface to the World-Wide Web
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/libwww-perl/
@@ -106,6 +106,9 @@ Requires:   perl(Net::HTTP) >= 6.07
 Requires:   perl(URI) >= 1.10
 Requires:   perl(URI::Escape)
 Requires:   perl(WWW::RobotRules) >= 6
+Provides:   perl(LWP::Debug::TraceHTTP::Socket) = %{version}
+Provides:   perl(LWP::Protocol::http::Socket) = %{version}
+Provides:   perl(LWP::Protocol::http::SocketMethods) = %{version}
 
 %description
 The libwww-perl collection is a set of Perl modules which provides a simple and
@@ -145,6 +148,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 6.27-2
+- Provide hidden modules
+
 * Fri Sep 22 2017 Petr Pisar  - 6.27-1
 - 6.27 bump
 



https://src.fedoraproject.org/rpms/perl-libwww-perl/c/5f0972df100b38531969bf7902755c1e5a154075?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1494297] perl-libwww-perl-6.27 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version|perl-libwww-perl-6.27-1.fc2 |perl-libwww-perl-6.27-2.fc2
   |8   |8



-- 
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 1494300] perl-Verilog-Perl-3.444 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Verilog-Perl-3.444-1.f
   ||c28
 Resolution|--- |RAWHIDE
Last Closed||2017-09-22 04:59:33



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 28.

-- 
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

ppisar pushed to perl-Verilog-Perl (master). "3.444 bump"

[notifications]

From 39ae70b9d484026f16b33ab3b985cf9917635f46 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 08:44:25 +
Subject: 3.444 bump


---

diff --git a/.gitignore b/.gitignore
index 198d7a7..2cf50db 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,3 +17,4 @@ Verilog-Perl-3.301.tar.gz
 /Verilog-Perl-3.430.tar.gz
 /Verilog-Perl-3.440.tar.gz
 /Verilog-Perl-3.442.tar.gz
+/Verilog-Perl-3.444.tar.gz
diff --git a/perl-Verilog-Perl.spec b/perl-Verilog-Perl.spec
index 3ff0d84..15883e2 100644
--- a/perl-Verilog-Perl.spec
+++ b/perl-Verilog-Perl.spec
@@ -1,5 +1,5 @@
 Name:  perl-Verilog-Perl
-Version:   3.442
+Version:   3.444
 Release:   1%{?dist}
 Summary:   Verilog parsing routines
 License:   LGPLv3 or Artistic 2.0
@@ -88,6 +88,9 @@ make test
 
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 3.444-1
+- 3.444 bump
+
 * Wed Sep 20 2017 Petr Pisar  - 3.442-1
 - 3.442 bump
 
diff --git a/sources b/sources
index ade9ef9..8e7f43d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Verilog-Perl-3.442.tar.gz) = 
89b6facac710f80cc18e79809fda36e8b508020f28613a1f80f8da03445d73be947e92263510d5e05b37de25593e380b52f8d1b12564efda4cd9b5b9e472e670
+SHA512 (Verilog-Perl-3.444.tar.gz) = 
e3eeb0db2849f00c4621e083ae01b15f1224c31542f65453d273eb19ccf45c049cd81f2891a7cf67a568fd5cb03bb4d66d992842a69fe5dc68f188b94f2df5bc



https://src.fedoraproject.org/rpms/perl-Verilog-Perl/c/39ae70b9d484026f16b33ab3b985cf9917635f46?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Verilog-Perl-3.444.tar.gz for perl-Verilog-Perl

[notifications]

e3eeb0db2849f00c4621e083ae01b15f1224c31542f65453d273eb19ccf45c049cd81f2891a7cf67a568fd5cb03bb4d66d992842a69fe5dc68f188b94f2df5bc
  Verilog-Perl-3.444.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Verilog-Perl/Verilog-Perl-3.444.tar.gz/sha512/e3eeb0db2849f00c4621e083ae01b15f1224c31542f65453d273eb19ccf45c049cd81f2891a7cf67a568fd5cb03bb4d66d992842a69fe5dc68f188b94f2df5bc/Verilog-Perl-3.444.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Kernel 4.13 rebase plans

[James Hogarth]

On 15 September 2017 at 11:00, James Hogarth 
wrote:

>
>
> On 13 September 2017 at 01:39, James Hogarth 
> wrote:
>
>>
>>
>> On 12 Sep 2017 10:49 pm, "Laura Abbott"  wrote:
>>
>> On 09/05/2017 09:41 AM, Laura Abbott wrote:
>>
>>> Hi,
>>>
>>> Kernel 4.13 was released this past weekend. This kernel has been
>>> built for rawhide and is building for F27 as well. We will be
>>> following the same upgrade procedure as in the past. F25 and F26
>>> will get rebased to 4.13 after a few stable releases, typically
>>> 4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
>>> does not give release dates for stable release but given past
>>> timings, this will probably happen towards the end of September.
>>> As always, if you have any questions please let me know.
>>>
>>> Thanks,
>>> Laura
>>>
>>>
>> 4.13.1 is now in the kernel-stabilization COPR. 4.13.2 was released
>> this morning but given it was released in conjunction with a new
>> publicized CVE, it was slightly smaller and I'm inclined to wait
>> for 4.13.3 before attempting to push anything to bodhi for F26.
>>
>>
>>
>> Thanks for the update Laura
>>
>> I'll pop that on my system tomorrow for some early testing and when
>> you're ready with the bodhi update will add the feedback.
>>
>>
> Hi,
>
> Installed and running well here:
>
> Intel® Core™ i5-6300HQ CPU @ 2.30GHz × 4 Intel® HD Graphics 530 (Skylake
> GT2) / Nvidia-bumblebee 384.69 on NV117
>
> WiFI working, bluetooth working, GPU works still.
>
> Ran through both the default and performance kernel regression tests[0] -
> both passed.
>
> https://apps.fedoraproject.org/kerneltest/kernel/4.13.1-200.fc26.x86_64
>
> Incidentally I enabled the bfq scheduler for my spinning rust large data
> drive and kyber for my SSD (since they have had some time to initially "bed
> in" in 4.12)  and the system feels noticeably more responsive than on cfq
> before ... though I wonder how much is a placebo effect ... might be fun to
> switch it up and do some bonnie and iozone testing at some point.
>
> Cheers,
>
> James
>
>
> [0] https://fedoraproject.org/wiki/KernelTestingInitiative
>


Something happened in the 4.13.2 release which broke the nvidia driver.

A few symbols changed and there was something that flipped to a GPL
labelled symbol.

I know we don't directly provide that for various reasons, but there is the
initiative with Negativo etc that the Workstation Working Group has
highlighted several times.

See these posts:

http://mom.hlmjr.com/2017/09/09/driver-wars-nvidia-drivers-384-69-vs-kernel-4-13/

https://devtalk.nvidia.com/default/topic/1023822/linux/-patch-384-69-kernel-4-13-4-14-staging-/

It refers to 4.14-rc1 but I saw the identical issues on 4.13.2-200 with
this.

Is this something worth holding back on the kernel release on F26 for the
time being?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1494300] perl-Verilog-Perl-3.444 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com |ppi...@redhat.com
   Assignee|jples...@redhat.com |ppi...@redhat.com



-- 
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 1494301] perl-Test-Moose-More-0.050 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Test-Moose-More-0.050-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-7ee35d9cdd

-- 
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

dist.rpmdeplint FAILED for perl-libwww-perl-6.27-1.fc27

[notifications]

dist.rpmdeplint FAILED for perl-libwww-perl-6.27-1.fc27

https://taskotron.fedoraproject.org/artifacts/all/6f37c45a-9f70-11e7-86a7-525400817a8f/task_output/perl-libwww-perl-6.27-1.fc27.x86_64.log
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Test-Moose-More (f27). "0.050 bump"

[notifications]

From bbcfd47132a87862e25f3117f993ad38bc96ba70 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 08:26:01 +
Subject: 0.050 bump


---

diff --git a/.gitignore b/.gitignore
index 548ab4e..c14eb67 100644
--- a/.gitignore
+++ b/.gitignore
@@ -31,3 +31,4 @@
 /Test-Moose-More-0.046.tar.gz
 /Test-Moose-More-0.047.tar.gz
 /Test-Moose-More-0.048.tar.gz
+/Test-Moose-More-0.050.tar.gz
diff --git a/perl-Test-Moose-More.spec b/perl-Test-Moose-More.spec
index 30e08a8..a8d5232 100644
--- a/perl-Test-Moose-More.spec
+++ b/perl-Test-Moose-More.spec
@@ -1,14 +1,14 @@
 Name:   perl-Test-Moose-More
-Version:0.048
-Release:2%{?dist}
+Version:0.050
+Release:1%{?dist}
 Summary:More tools for testing Moose packages
 License:LGPLv2+
 URL:http://search.cpan.org/dist/Test-Moose-More/
 Source0:
http://www.cpan.org/authors/id/R/RS/RSRCHBOY/Test-Moose-More-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  make
-BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
@@ -26,7 +26,7 @@ BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::Moose)
 BuildRequires:  perl(Test::More) >= 0.94
 # Tests only:
-BuildRequires:  perl(blib) >= 1.01
+BuildRequires:  perl(blib)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(IPC::Open3)
@@ -70,6 +70,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 0.050-1
+- 0.050 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.048-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 22d345f..809b5ad 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Test-Moose-More-0.048.tar.gz) = 
af9c050f67af03d612a348769489187ddd819da4636d452323ab788a2baeb8a339dc356313f29bc9d867a37ced2ea39814416f20fc70b1a674d90cb5ebf07ca6
+SHA512 (Test-Moose-More-0.050.tar.gz) = 
03c3d71cbe903b7b7e74b6aa44950f6b3fb21f83d7f787d101bb53f2c245b41f9722300124c5bd98f9a32f455f014b34c89fda5394145aa08933099715374801



https://src.fedoraproject.org/rpms/perl-Test-Moose-More/c/bbcfd47132a87862e25f3117f993ad38bc96ba70?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar uploaded Test-Moose-More-0.050.tar.gz for perl-Test-Moose-More

[notifications]

03c3d71cbe903b7b7e74b6aa44950f6b3fb21f83d7f787d101bb53f2c245b41f9722300124c5bd98f9a32f455f014b34c89fda5394145aa08933099715374801
  Test-Moose-More-0.050.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Test-Moose-More/Test-Moose-More-0.050.tar.gz/sha512/03c3d71cbe903b7b7e74b6aa44950f6b3fb21f83d7f787d101bb53f2c245b41f9722300124c5bd98f9a32f455f014b34c89fda5394145aa08933099715374801/Test-Moose-More-0.050.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Test-Moose-More (master). "0.050 bump"

[notifications]

From bbcfd47132a87862e25f3117f993ad38bc96ba70 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 08:26:01 +
Subject: 0.050 bump


---

diff --git a/.gitignore b/.gitignore
index 548ab4e..c14eb67 100644
--- a/.gitignore
+++ b/.gitignore
@@ -31,3 +31,4 @@
 /Test-Moose-More-0.046.tar.gz
 /Test-Moose-More-0.047.tar.gz
 /Test-Moose-More-0.048.tar.gz
+/Test-Moose-More-0.050.tar.gz
diff --git a/perl-Test-Moose-More.spec b/perl-Test-Moose-More.spec
index 30e08a8..a8d5232 100644
--- a/perl-Test-Moose-More.spec
+++ b/perl-Test-Moose-More.spec
@@ -1,14 +1,14 @@
 Name:   perl-Test-Moose-More
-Version:0.048
-Release:2%{?dist}
+Version:0.050
+Release:1%{?dist}
 Summary:More tools for testing Moose packages
 License:LGPLv2+
 URL:http://search.cpan.org/dist/Test-Moose-More/
 Source0:
http://www.cpan.org/authors/id/R/RS/RSRCHBOY/Test-Moose-More-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  make
-BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(strict)
 BuildRequires:  perl(warnings)
@@ -26,7 +26,7 @@ BuildRequires:  perl(Test::Builder)
 BuildRequires:  perl(Test::Moose)
 BuildRequires:  perl(Test::More) >= 0.94
 # Tests only:
-BuildRequires:  perl(blib) >= 1.01
+BuildRequires:  perl(blib)
 BuildRequires:  perl(File::Spec)
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(IPC::Open3)
@@ -70,6 +70,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 0.050-1
+- 0.050 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
0.048-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 22d345f..809b5ad 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Test-Moose-More-0.048.tar.gz) = 
af9c050f67af03d612a348769489187ddd819da4636d452323ab788a2baeb8a339dc356313f29bc9d867a37ced2ea39814416f20fc70b1a674d90cb5ebf07ca6
+SHA512 (Test-Moose-More-0.050.tar.gz) = 
03c3d71cbe903b7b7e74b6aa44950f6b3fb21f83d7f787d101bb53f2c245b41f9722300124c5bd98f9a32f455f014b34c89fda5394145aa08933099715374801



https://src.fedoraproject.org/rpms/perl-Test-Moose-More/c/bbcfd47132a87862e25f3117f993ad38bc96ba70?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1494301] perl-Test-Moose-More-0.050 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-Moose-More-0.050-
   ||1.fc28



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 27.

-- 
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 1494297] perl-libwww-perl-6.27 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-libwww-perl-6.27-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-124d8d9481

-- 
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 1486717] abi-compliance-checker-2.2 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|abi-compliance-checker-2.2- |abi-compliance-checker-2.2-
   |1.fc25  |1.fc25
   |abi-compliance-checker-2.2- |abi-compliance-checker-2.2-
   |1.el7   |1.el7
   ||abi-compliance-checker-2.2-
   ||1.el6



--- Comment #18 from Fedora Update System  ---
abi-compliance-checker-2.2-1.el6, abi-dumper-1.1-1.el6, abi-tracker-1.11-1.el6,
rfcdiff-1.45-3.el6 has been pushed to the Fedora EPEL 6 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

ppisar pushed to perl-libwww-perl (f27). "6.27 bump"

[notifications]

From 81e677c73fc8acf8aaefbed302272100e33996bb Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 08:09:43 +
Subject: 6.27 bump


---

diff --git a/.gitignore b/.gitignore
index b1a36b1..a0ffa26 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@ libwww-perl-5.834.tar.gz
 /libwww-perl-6.24.tar.gz
 /libwww-perl-6.25.tar.gz
 /libwww-perl-6.26.tar.gz
+/libwww-perl-6.27.tar.gz
diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index cb805be..c54cc13 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,6 +1,6 @@
 Name:   perl-libwww-perl
-Version:6.26
-Release:3%{?dist}
+Version:6.27
+Release:1%{?dist}
 Summary:A Perl interface to the World-Wide Web
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/libwww-perl/
@@ -9,8 +9,8 @@ Source0:
http://www.cpan.org/authors/id/O/OA/OALDERS/libwww-perl-%{versio
 Patch0: libwww-perl-6.19-Accept-proxy-URLs-with-IPv6-host-names.patch
 BuildArch:  noarch
 BuildRequires:  make
-BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
 BuildRequires:  perl(:VERSION) >= 5.8.1
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(File::Copy)
@@ -145,6 +145,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 6.27-1
+- 6.27 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
6.26-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 3da0615..0e2960a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (libwww-perl-6.26.tar.gz) = 
0af62f1c393b82b2d665f4f460990bb9a446975507cc07148e9e5eebbfbcdd8ea8190dfe1ecb72a229ffa9a5e42edd9eb6c50ac1d3de89ac4681462069a3acb5
+SHA512 (libwww-perl-6.27.tar.gz) = 
ceb7df71ef2773752dfa8a46f6e48cfbe7501f543d53ddaf50ee97da2cb21025be4bb32bee62d6f6fa837a7b0726718b3b8470de0b8a9d789e40c16a42b894e7



https://src.fedoraproject.org/rpms/perl-libwww-perl/c/81e677c73fc8acf8aaefbed302272100e33996bb?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ppisar pushed to perl-libwww-perl (master). "6.27 bump"

[notifications]

From 81e677c73fc8acf8aaefbed302272100e33996bb Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Sep 22 2017 08:09:43 +
Subject: 6.27 bump


---

diff --git a/.gitignore b/.gitignore
index b1a36b1..a0ffa26 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,3 +20,4 @@ libwww-perl-5.834.tar.gz
 /libwww-perl-6.24.tar.gz
 /libwww-perl-6.25.tar.gz
 /libwww-perl-6.26.tar.gz
+/libwww-perl-6.27.tar.gz
diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index cb805be..c54cc13 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,6 +1,6 @@
 Name:   perl-libwww-perl
-Version:6.26
-Release:3%{?dist}
+Version:6.27
+Release:1%{?dist}
 Summary:A Perl interface to the World-Wide Web
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/libwww-perl/
@@ -9,8 +9,8 @@ Source0:
http://www.cpan.org/authors/id/O/OA/OALDERS/libwww-perl-%{versio
 Patch0: libwww-perl-6.19-Accept-proxy-URLs-with-IPv6-host-names.patch
 BuildArch:  noarch
 BuildRequires:  make
-BuildRequires:  perl-interpreter
 BuildRequires:  perl-generators
+BuildRequires:  perl-interpreter
 BuildRequires:  perl(:VERSION) >= 5.8.1
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires:  perl(File::Copy)
@@ -145,6 +145,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Fri Sep 22 2017 Petr Pisar  - 6.27-1
+- 6.27 bump
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
6.26-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 
diff --git a/sources b/sources
index 3da0615..0e2960a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (libwww-perl-6.26.tar.gz) = 
0af62f1c393b82b2d665f4f460990bb9a446975507cc07148e9e5eebbfbcdd8ea8190dfe1ecb72a229ffa9a5e42edd9eb6c50ac1d3de89ac4681462069a3acb5
+SHA512 (libwww-perl-6.27.tar.gz) = 
ceb7df71ef2773752dfa8a46f6e48cfbe7501f543d53ddaf50ee97da2cb21025be4bb32bee62d6f6fa837a7b0726718b3b8470de0b8a9d789e40c16a42b894e7



https://src.fedoraproject.org/rpms/perl-libwww-perl/c/81e677c73fc8acf8aaefbed302272100e33996bb?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1494297] perl-libwww-perl-6.27 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-libwww-perl-6.27-1.fc2
   ||8



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 27.

-- 
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

ppisar uploaded libwww-perl-6.27.tar.gz for perl-libwww-perl

[notifications]

ceb7df71ef2773752dfa8a46f6e48cfbe7501f543d53ddaf50ee97da2cb21025be4bb32bee62d6f6fa837a7b0726718b3b8470de0b8a9d789e40c16a42b894e7
  libwww-perl-6.27.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-libwww-perl/libwww-perl-6.27.tar.gz/sha512/ceb7df71ef2773752dfa8a46f6e48cfbe7501f543d53ddaf50ee97da2cb21025be4bb32bee62d6f6fa837a7b0726718b3b8470de0b8a9d789e40c16a42b894e7/libwww-perl-6.27.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: How to chainbuild in a build override?

[Tom Hughes]

On 22/09/17 08:50, Ralf Corsepius wrote:

How to build a sub tree of packages in fc27, when the root of this tree 
changed SONAME?


Well it's painful - you have to build each one then add an override for 
it and wait for that to appear and then move on to the next one etc...


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: How to chainbuild in a build override?

[Ralf Corsepius]

On 09/22/2017 09:32 AM, Tom Hughes wrote:

On 22/09/17 08:03, Ralf Corsepius wrote:


I am trying to build a chain of packages in a build override?

I.e. a series of packages: A->B->C

I set up a build override for A, and B built successfully. Now, I 
would have expect building C to pickup B from the A-override.


You seem to be confused about what an override is ;-)


Quite likely, I rarely used them and have always found the tooling to be 
hard to use ;)


It's not a separate environment just for you - if it was then you would 
have to say which override you wanted to use when building.

Correct. That's a issue I never understood about build overrides.

Rather it just adds that package to the global build environment that 
everybody sees.


But in order for B to appear in the build environment for C to use you 
would need to add an override for B and then wait for it to appear 
there.


That's what I had presumed. But this implies me to deliberately break deps.

I believe chainbuild knows how to do the waiting but not how to 
request an override.


So in summary chainbuild is I believe only useful in rawhide, and in 
branched before bodhi is enabled.
That's clear. I was using the term chain-building in the meaning of 
building a hierarchy of packages.


So let me rephrase my question:

How to build a sub tree of packages in fc27, when the root of this tree 
changed SONAME?



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

Re: How to chainbuild in a build override?

[Tom Hughes]

On 22/09/17 08:03, Ralf Corsepius wrote:


I am trying to build a chain of packages in a build override?

I.e. a series of packages: A->B->C

I set up a build override for A, and B built successfully. Now, I would 
have expect building C to pickup B from the A-override.


You seem to be confused about what an override is ;-)

It's not a separate environment just for you - if it was then you would 
have to say which override you wanted to use when building.


Rather it just adds that package to the global build environment that 
everybody sees.


But in order for B to appear in the build environment for C to use you 
would need to add an override for B and then wait for it to appear 
there. I believe chainbuild knows how to do the waiting but not how to 
request an override.


So in summary chainbuild is I believe only useful in rawhide, and in 
branched before bodhi is enabled.


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

[Bug 1493804] perl-Module-CoreList-5.20170920 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20170920-1.fc25 has been pushed to the Fedora 25 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-2017-e3e52de757

-- 
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 1493797] perl-CPAN-Perl-Releases-3.36 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.36-1.fc25 has been pushed to the Fedora 25 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-2017-c35562ef9b

-- 
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: State of Sparkeshare in Fedora

[James Hogarth]

On 22 Sep 2017 4:46 am, "Luya Tshimbalanga"  wrote:

On 21/09/17 08:02 AM, James Hogarth wrote:



On 21 September 2017 at 07:17, Luya Tshimbalanga 
wrote:

> Sparkleshare package is currently behind upstream which just reach
> 2.0[1][2]
> The maintainer was contacted for updating the package with current broken
> dependency below on Fedora 27 and above:
>
>  Problem: package sparkleshare-1.2.0-8.fc26.x86_64 requires
> mono(webkit-sharp) = 1.1.15.0, but none of the providers can be installed
>   - conflicting requests
>   - nothing provides webkitgtk needed by webkit-sharp-0.3-19.fc26.x86_64
>
>  but no response so far[3][4].
> As the application is used by Design Team, could someone make the change
> because I cannot access it?
> Thanks in advance,
>
> Luya
>
> References
> --
> [1] https://github.com/hbons/SparkleShare/releases/tag/2.0.0
> [2] https://apps.fedoraproject.org/packages/sparkleshare
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1151172
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1375789
>
>
>
A quick look of course shows this to be an issue with the retiring of
webkitgtk as that's no longer in the repos for webkit-sharp to build
against, which then means sparkleshare doesn't have its dependency
satisfied.

According to the sparkleshare release notes[0] the 1.3.0 release added the
gtk3 bindings... so any of those ought to help.

The build dependencies are more complex than I can do in a few minutes
though[1]

The 2.0 release the release notes states has breaking changes from 1.X ...

To get this updated someone needs to package webkit2-sharp (and any
dependencies that needs to build) ... gtk-sharp3 is already packaged though
which should help.

They say that as of 2.0 they have a flatpak release - have you tried that
so at least you'll have access to the application in F27?

Wearing Design Suite lab maintainer's hat, I would love to include a
flatpak version of 2.0 as default for F27 if there is a proper mechanism to
do so.

Just a quick look, I made a spec file for guideline[1]

References
---
[1] https://luya.fedorapeople.org/packages/SPECS/webkit2-sharp.spec


-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net


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


Ah I thought you meant the application for you to use. Last I heard how to
formally include a flatpak app in Fedora is still up for debate.

The Workstation working group may have some ideas there.

Not making any promises but if no-one else has got to it by the end of next
week I'll try and get something together.

I'm not familiar with the app though so it'll take a little getting up to
speed.

Based on the fedora update policy and the acknowledged breaking changes in
2.0 we should only really update to the most recent 1.x in F27 and below at
this time.

The latest version should be a self contained change in F28.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to chainbuild in a build override?

[Ralf Corsepius]

Hi,

I am trying to build a chain of packages in a build override?

I.e. a series of packages: A->B->C

I set up a build override for A, and B built successfully. Now, I would 
have expect building C to pickup B from the A-override.


This does not seem to apply. C fails to build, apparently because 
building doesn't pickup "B" from A's build override.


Is this a timing issue (Do I need to wait)? Do I have to setup another 
build-override for B?


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

ignatenkobrain pushed to perl-Alien-pkgconf (master). "Rebuild against pkgconf-1.3.9 (..more)"

[notifications]

From 861b88c67721937db1d0a2189320acd6a7c49935 Mon Sep 17 00:00:00 2001
From: Igor Gnatenko 
Date: Sep 22 2017 06:37:18 +
Subject: Rebuild against pkgconf-1.3.9


Signed-off-by: Igor Gnatenko 

---

diff --git a/perl-Alien-pkgconf.spec b/perl-Alien-pkgconf.spec
index b1e0be2..c42b1b5 100644
--- a/perl-Alien-pkgconf.spec
+++ b/perl-Alien-pkgconf.spec
@@ -1,6 +1,6 @@
 Name:   perl-Alien-pkgconf
 Version:0.10
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Discover pkgconf and libpkgconf
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Alien-pkgconf/
@@ -76,6 +76,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Sep 22 2017 Igor Gnatenko  - 0.10-12
+- Rebuild against pkgconf-1.3.9
+
 * Thu Aug 03 2017 Fedora Release Engineering  - 
0.10-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Alien-pkgconf/c/861b88c67721937db1d0a2189320acd6a7c49935?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

ignatenkobrain pushed to perl-Alien-pkgconf (f27). "Rebuild against pkgconf-1.3.9 (..more)"

[notifications]

From 861b88c67721937db1d0a2189320acd6a7c49935 Mon Sep 17 00:00:00 2001
From: Igor Gnatenko 
Date: Sep 22 2017 06:37:18 +
Subject: Rebuild against pkgconf-1.3.9


Signed-off-by: Igor Gnatenko 

---

diff --git a/perl-Alien-pkgconf.spec b/perl-Alien-pkgconf.spec
index b1e0be2..c42b1b5 100644
--- a/perl-Alien-pkgconf.spec
+++ b/perl-Alien-pkgconf.spec
@@ -1,6 +1,6 @@
 Name:   perl-Alien-pkgconf
 Version:0.10
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Discover pkgconf and libpkgconf
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Alien-pkgconf/
@@ -76,6 +76,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Sep 22 2017 Igor Gnatenko  - 0.10-12
+- Rebuild against pkgconf-1.3.9
+
 * Thu Aug 03 2017 Fedora Release Engineering  - 
0.10-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Alien-pkgconf/c/861b88c67721937db1d0a2189320acd6a7c49935?branch=f27
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org