[389-devel] Re: Build failed in Jenkins: 389-DS-COMMIT #116

[William Brown]

> - Captured stderr call 
> -
> INFO:suites.basic.basic_test:Running test_basic_systemctl...

I'm investigating this, it's probably related to my changes in lib389. 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


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

[389-devel] Build failed in Jenkins: 389-DS-COMMIT #116

[Jenkins]

See 


Changes:

[firstyear] Ticket 48978 - refactor LDADebug() to slapi_log_err()

--
[...truncated 3176 lines...]
extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

extracting debug info from 

/usr/lib/rpm/sepdebugcrcfix: Updated 48 CRC32s, 1 CRC32s did match.
symlinked /usr/lib/debug/usr/lib64/dirsrv/libslapd.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libslapd.so.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/liblfds710.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/liblfds710.so.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/libnunc-stans.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libnunc-stans.so.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/libnunc-stans.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libnunc-stans.so.0.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/liblfds710.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/liblfds710.so.0.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/libns-dshttpd.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libns-dshttpd.so.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/libslapd.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libslapd.so.0.debug
symlinked /usr/lib/debug/usr/lib64/dirsrv/libns-dshttpd.so.0.0.0.debug to 
/usr/lib/debug/usr/lib64/dirsrv/libns-dshttpd.so.0.debug
cpio: 389-ds-base-1.3.6.0.20161012git9464bc8/acl.yy.cpp: Cannot stat: No such 
file or directory
cpio: 389-ds-base-1.3.6.0.20161012git9464bc8/aclscan.l: Cannot stat: No such 
file or directory
cpio: 389-ds-base-1.3.6.0.20161012git9464bc8/acltext.y: Cannot stat: No such 
file or directory
25751 blocks
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: 389-ds-base-1.3.6.0-20161012git9464bc8.fc24.x86_64
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.np3YWI
+ umask 022
+ cd 

+ cd 389-ds-base-1.3.6.0.20161012git9464bc8
+ 
DOCDIR=
+ export DOCDIR
+ /usr/bin/mkdir -p 

+ cp -pr LICENSE 

+ cp -pr LICENSE.GPLv3+ 

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 11, 2016 at 6:33 PM, Gerald B. Cox  wrote:

>
> I knew that it was experimental when I first set it up years ago, but I
> never imagined
> it would still be experimental in 2016.  I just got tired of waiting, and
> the statement
> that it would all most likely have to be rewritten was just the last straw
> for me.  The
> only reason I was using it was because of the ease and flexibility to run
> Raid5/6.  With
> that apparently nowhere now on the horizon, time to cut my loses and move
> on.


About the rewrite comment: that did not come from a developer, and is
definitely overstated. In any case, rewrites are not inherently bad
news, there's a bunch of OpenZFS videos from last yearss summit in
which the developers talk about various things being completely
rewritten from scratch, some things more than twice. So kinda par for
the course, and given enough time things get rewritten anyway. XFS has
had substantial changes over its history including numerous on disk
format changes even before it found its way onto Linux.

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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 11, 2016 at 6:33 PM, Gerald B. Cox  wrote:
> On Tue, Oct 11, 2016 at 4:48 PM, Chris Murphy 
> wrote:
>>
>> > As far as BTRFS
>>
>> > is concerned however, I believe that ship has sailed.  I used it for 4
>> > years, but after the recent news regarding RAID
>>
>> The only news about Btrfs RAID I can think of that you're referring to
>> is the raid5 scrub bug that corrupts parity in a very specific
>> situation. It's a bad bug, but it's also really rare.
>
>
> That may be, but all the articles I read suggested "be afraid, be very
> afraid".
> In addition, https://goo.gl/V2IyFq
> basically just comes out and says, not to use it.

That's stale and overstated but I'm fine with dire warnings because
otherwise people use experimental stuff and flip out when it face
plants. What's needed are people who can tediously gather an autopsy
report so it can be made better. And that's pretty much what's
happening.


> I knew that it was experimental when I first set it up years ago, but I
> never imagined
> it would still be experimental in 2016.  I just got tired of waiting, and
> the statement
> that it would all most likely have to be rewritten was just the last straw
> for me.  The
> only reason I was using it was because of the ease and flexibility to run
> Raid5/6.  With
> that apparently nowhere now on the horizon, time to cut my loses and move
> on.

Uhh OK, well it's an entirely new implementation of parity raid,
unlike md or ZFS ZRAID. It was first merged a bit over three years
ago, and the scrub and device replacement code only came last year.
And even still there's no concept of faulty devices - so you don't get
behaviors like devices being ejected from the array on write error or
massive numbers of reads. It's entirely reasonable to want something
more mature. If your use case requires bitrot and silent data
corruption protection and parity raid, the single option is OpenZFS
ZRAID.

>
>>
>> Anyway it's a bad bug. But it's not correct to assign this bug to the
>> other three raid profiles or Btrfs in general - where it has numerous
>> features not all of which have the same maturity.
>
>
> Agreed, but in my mind the last episode throws some serious shade
> on the entire project.  Once upon a time, there was talk about making the
> default in
> Fedora, but now - not so much.  In the meantime XFS is being improved and
> bcachefs is
> being developed.  Tick tock...

About the Fedora default, this recently came up on desktop@ so I'll
just refer to that:
https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/message/T6FNLLPJ7LICKSVTTPS4KSIDHOKUUPNC/


-- 
Chris Murphy
___
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
 461  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 455  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 387  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 345  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 317  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 203  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-30a8346813   
vtun-3.0.1-10.el6
  62  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a1450d7fe0   
knot-1.6.8-1.el6
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-edda50420f   
mongodb-2.4.14-4.el6
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-25e30f6dc3   
jansson-2.9-1.el6
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8602185c5   
links-2.13-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-efb0141e9c   
php-ZendFramework-1.12.20-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-63189174a4   
nsd-4.1.13-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3428efd3c   
php-symfony-2.3.42-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c4b3ba1af6   
nodejs-0.10.47-2.el6


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

fedfind-2.7.0-1.el6
guacamole-server-0.9.9-3.el6
python-distro-1.0.0-6.el6
python3-py-1.4.30-2.el6

Details about builds:



 fedfind-2.7.0-1.el6 (FEDORA-EPEL-2016-022c94df4e)
 Fedora Finder finds Fedora

Update Information:

This update further improves handling of ostree installer images. We 'correct'
the image dicts for the images the current Pungi release is producing (the
filenames have been improved to have `-ostree-` in them, but the type is still
`boot`). When synthesizing image dicts for releases without metadata, we catch
more ostree installer cases to assign the `dvd-ostree` type to.  This update
also will find many more images for Alpha, Beta and stable releases. This is
because when these releases are synced to the public mirrors, they are actually
split into two trees. Most of the bits go into the 'main' tree, which is found
under `/fedora/` on the mirrors, but some lesser-used deliverables are split
into a separate tree found under `/alt/` on the mirrors. Previously, fedfind was
not aware of this and would only find images in the 'main' location, it did not
find any of the images that were split off to the `alt` location. Now, fedfind
does find these images.  If you use the fedfind CLI, you do not need to do
anything special; queries for Alpha, Beta and stable releases will now show
these images where they did not before.  If you have code using the fedfind
module, be aware that the `MirrorRelease` subclasses now have a `alt_location`
property which is the full URL to the top-level location of the `alt` tree for
the release, and in the synthesized metadata and thus also in the `all_images`
list, the image dicts have an additional property, `alt`, which indicates
whether the image is the main tree or the alt tree. To get the correct URL for
an `alt` image, concatenate its path with the release's `alt_location` property.
If you only deal with non-split releases that have metadata - like the nightly
composes - nothing should change for you.    The major change in this update
is that fedfind now has the ability to effectively override the productmd-
formatted metadata provided by Pungi in specific cases where it's problematic.
There is a new helper function, `helpers.correct_image`, which applies these
'corrections', and the image dicts returned by the `Release.all_images` property
- commonly used for getting a flat list of image dicts from the compose metadata
- now have these corrections applied.  This is intended to work around a
[significant issue](https://pagure.io/pungi/issue/417) that's appeared along
with the introduction of a Workstation ostree installer image for Fedora: pungi
sets the `type` for ostree installer images to `boot`, but that means there is
no way to distinguish a Workstation network install image from a Workstation
ostree install image using the metadata. This is a major problem for several
things which distinguish between images based on the metadata (openQA,
fedora_nightlies, and wikitcms are all affected by this). For now, fedfind will
'correct' the `type` for these images from `boot` to `dvd-ostree`. fedfind will
also use the `dvd-ostree` type for ostree installer images when synthesizing
metadata for Releases 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 583  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 345  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
  64  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
  62  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-4b8dd3488d   
knot-1.6.8-1.el7
  47  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-28ad6782b3   
php-adodb-5.20.6-2.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-208f62faa6   
links-2.13-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-452534ff97   
php-ZendFramework-1.12.20-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-39560a2353   
mingw-c-ares-1.12.0-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-60045af95e   
mingw-libidn-1.33-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0890ae6d2d   
nsd-4.1.13-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-387d58ef27   
chromium-53.0.2785.143-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-03fb3c1531   
banshee-2.6.2-11.el7 dbus-sharp-0.7.0-15.el7 dbus-sharp-glib-0.5.0-13.el7 
gdata-sharp-1.4.0.2-18.el7 gio-sharp-0.3-14.el7 gkeyfile-sharp-0.1-19.el7 
gnome-sharp-2.24.2-12.el7 gtk-sharp-beans-2.14.0-17.el7 
gtk-sharp2-2.12.26-3.el7 gtk-sharp3-2.99.3-16.el7 gudev-sharp-0.1-18.el7 
libappindicator-12.10.0-11.el7 libgpod-0.8.3-8.el7 mono-4.2.4-7.el7 
mono-addins-1.1-3.el7 mono-cecil-0.9.6-6.el7 mono-zeroconf-0.9.0-16.el7 
notify-sharp-0.4.0-0.26.20100411svn.el7 notify-sharp3-3.0.3-2.el7 
nunit-3.5-1.el7 nunit2-2.6.4-14.el7 pinta-1.6-5.el7 taglib-sharp-2.1.0.0-3.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c3527eff6c   
libass-0.13.4-1.el7


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

fedfind-2.7.0-1.el7
monotone-1.1-15.el7
python-distro-1.0.0-6.el7
python-zope-sqlalchemy-0.7.7-1.el7

Details about builds:



 fedfind-2.7.0-1.el7 (FEDORA-EPEL-2016-b0bb4bddbc)
 Fedora Finder finds Fedora

Update Information:

This update further improves handling of ostree installer images. We 'correct'
the image dicts for the images the current Pungi release is producing (the
filenames have been improved to have `-ostree-` in them, but the type is still
`boot`). When synthesizing image dicts for releases without metadata, we catch
more ostree installer cases to assign the `dvd-ostree` type to.  This update
also will find many more images for Alpha, Beta and stable releases. This is
because when these releases are synced to the public mirrors, they are actually
split into two trees. Most of the bits go into the 'main' tree, which is found
under `/fedora/` on the mirrors, but some lesser-used deliverables are split
into a separate tree found under `/alt/` on the mirrors. Previously, fedfind was
not aware of this and would only find images in the 'main' location, it did not
find any of the images that were split off to the `alt` location. Now, fedfind
does find these images.  If you use the fedfind CLI, you do not need to do
anything special; queries for Alpha, Beta and stable releases will now show
these images where they did not before.  If you have code using the fedfind
module, be aware that the `MirrorRelease` subclasses now have a `alt_location`
property which is the full URL to the top-level location of the `alt` tree for
the release, and in the synthesized metadata and thus also in the `all_images`
list, the image dicts have an additional property, `alt`, which indicates
whether the image is the main tree or the alt tree. To get the correct URL for
an `alt` image, concatenate its path with the release's `alt_location` property.
If you only deal with non-split releases that have metadata - like the nightly
composes - nothing should change for you.




 monotone-1.1-15.el7 (FEDORA-EPEL-2016-044761d976)
 A free, distributed version control system

Update Information:

Import current Monotone package in EPEL7.

References:

  [ 1 ] Bug #1370080 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1370080




 

[389-devel] please review: Ticket 48978 - Fix log refactoring errors

[Mark Reynolds]

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

https://fedorahosted.org/389/attachment/ticket/48978/0001-Ticket-48978-refactor-LDADebug-to-slapi_log_err.2.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-DS-COMMIT #114

[Jenkins]

See 


Changes:

[mreynolds] Ticket 48978 - refactor LDADebug() to slapi_log_err()

--
[...truncated 1280 lines...]
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking return type of signal handlers... void
checking whether stat accepts an empty string... no
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... no
checking for strftime... yes
checking for vprintf... yes
checking for _doprnt... no
checking for clock_gettime... yes
checking for endpwent... yes
checking for ftruncate... yes
checking for getcwd... yes
checking for gethostbyname... yes
checking for inet_ntoa... yes
checking for localtime_r... yes
checking for memmove... yes
checking for memset... yes
checking for mkdir... yes
checking for munmap... yes
checking for putenv... yes
checking for rmdir... yes
checking for setrlimit... yes
checking for socket... yes
checking for strcasecmp... yes
checking for strchr... yes
checking for strcspn... yes
checking for strdup... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for strpbrk... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for tzset... yes
checking for --enable-debug... no
checking for --enable-asan... no
checking for --enable-gcc-security... no
checking for --enable-bundle... no
checking for --enable-pam-passthru... checking security/pam_appl.h usability... 
yes
checking security/pam_appl.h presence... yes
checking for security/pam_appl.h... yes
yes
checking for --enable-dna... yes
checking for --enable-ldapi... yes
checking for --enable-autobind... yes
checking for --enable-auto-dn-suffix... no
checking for --enable-bitwise... yes
checking for --enable-presence... no
checking for --enable-acctpolicy... yes
checking for --enable-posix-winsync... yes
checking for --enable-nunc-stans... yes
configure: checking for FHS...
checking for --with-fhs... no
checking for --with-fhs-opt... no
checking for --with-tmpfiles-d... /etc/tmpfiles.d
checking for --with-perldir... checking for --with-pythonexec... checking for 
--with-instconfigdir... no
checking for --with-initddir... no
checking for GCC provided 64-bit atomic bool cas function .. yes
checking for GCC provided 64-bit atomic ops functions .. yes
configure: checking for NSPR...
checking for --with-nspr... yes
checking for --with-nspr-inc... no
checking for --with-nspr-lib... no
checking for pkg-config... /bin/pkg-config
checking for nspr with pkg-config... using system NSPR
configure: checking for NSS...
checking for --with-nss... yes
checking for --with-nss-inc... using /usr/include/nss3
checking for --with-nss-lib... using /usr/lib64
configure: checking for OpenLDAP...
checking for --with-openldap... using system OpenLDAP
checking for --with-openldap-inc... no
checking for --with-openldap-lib... no
checking for --with-openldap-bin... no
checking for pkg-config... (cached) /bin/pkg-config
checking for OpenLDAP with pkg-config... no OpenLDAP pkg-config files
checking ldap_features.h usability... yes
checking ldap_features.h presence... yes
checking for ldap_features.h... yes
checking for ldap_initialize in -lldap-2.4... no
checking for ldap_initialize in -lldap... yes
checking for ldap_url_parse_ext in -lldap... yes
checking for _init in -lldif... no
configure: checking for Mozilla LDAPSDK...
checking for --with-ldapsdk... no
checking for --with-ldapsdk-inc... no
checking for --with-ldapsdk-lib... no
checking for --with-ldapsdk-bin... no
configure: checking for db...
checking for --with-db... yes
checking for --with-db-inc... no
checking for --with-db-lib... no
checking for db.h... using /usr/include/libdb/db.h
checking for db_create in -ldb-5.3... yes
configure: checking for SASL...
checking for --with-sasl... yes
checking for --with-sasl-inc... no
checking for --with-sasl-lib... no
checking for sasl.h... using /usr/include/sasl/sasl.h
configure: checking for SVRCORE...
checking for --with-svrcore... yes
checking for --with-svrcore-inc... using /usr/include
checking for --with-svrcore-lib... using /usr/lib64
configure: checking for LIBICU...
checking for --with-icu... yes
checking for --with-icu-inc... no
checking for --with-icu-lib... no
checking for --with-icu-bin... no
checking for icu-config... /bin/icu-config
checking for icu with icu-config... using system ICU
configure: checking for Net-SNMP...
checking for --with-netsnmp... yes
checking for --with-netsnmp-inc... no
checking for --with-netsnmp-lib... no
checking for net-snmp-includes.h... using 
/usr/include/net-snmp/net-snmp-includes.h
configure: checking for Kerberos...
checking for --with-kerberos... yes
checking for --with-kerberos-inc... no
checking for --with-kerberos-lib... no

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[Kevin Kofler]

Thomas Gilliard wrote:
> This sounds like a use for https://wiki.gnome.org/Apps/MultiWriter
> let the people bring their own USB keys

I already mentioned this sort of tool ("USB burning stations" – most of them 
were actually notebooks running software like this). It doesn't solve the 
problem that the operation is destructive and you cannot trust the user to 
not hand you in a key with important data and then blame you for destroying 
it (and then you have to prove that you actually warned them, and even if 
you can prove it, it won't keep the user from destroying your reputation).

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

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[Kevin Kofler]

Chris Murphy wrote:
> So if the context is 2Mbps or less, I'd think people would get
> frustrated fairly quickly with the ~ 1GiB+ downloads Gnome Software
> does in the background on first boot, with no UI for disabling it.

That is just unacceptable behavior from GNOME Software and ought to be 
fixed. plasma-pk-updates does not download anything you haven't asked for.

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

[Test-Announce] Re: Fedora 25 Workstation Wayland Test Day: 2016-10-13!

[Adam Williamson]

On Tue, 2016-10-11 at 17:27 -0700, Adam Williamson wrote:
> Hi folks! Time to announce another Fedora 25 Test Day: [Wayland Test
> Day][1]!

>  [1]: https://fedoraproject.org/wiki/Test_Day:2016-11-13_Wayland

Damnit, that's obviously a typo. Correct link:

https://fedoraproject.org/wiki/Test_Day:2016-10-13_Wayland
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
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: Fedora 25-20161011.n.0 compose check report

[Adam Williamson]

On Wed, 2016-10-12 at 00:44 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 7/102 (x86_64), 1/17 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in 25-20161010.n.0):
> 
> ID: 40461 Test: x86_64 Server-dvd-iso support_server
> URL: https://openqa.fedoraproject.org/tests/40461
> ID: 40483 Test: x86_64 universal support_server
> URL: https://openqa.fedoraproject.org/tests/40483

Seems like a step which copies the contents of the ISO image timed out;
I've extended its timeout.

> ID: 40498 Test: x86_64 universal upgrade_2_server_64bit
> URL: https://openqa.fedoraproject.org/tests/40498
> ID: 40500 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/40500

These seem like there were repo issues at the time the tests ran.

> ID: 40527 Test: x86_64 universal install_simple_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/40527

Boot just failed here, for some reason, but worked in all the other
universal UEFI tests.

> Old failures (same test failed in 25-20161010.n.0):
> 
> ID: 40432 Test: x86_64 Workstation-live-iso 
> desktop_notifications_postinstall
> URL: https://openqa.fedoraproject.org/tests/40432

This test is still a bit broken.

> ID: 40439 Test: x86_64 Workstation-boot-iso install_default
> URL: https://openqa.fedoraproject.org/tests/40439

Looks like a GNOME Shell crash.

> ID: 40456 Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/40456

Didn't get around to looking into this one yet...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161011.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 7/102 (x86_64), 1/17 (i386), 1/2 (arm)

New failures (same test did not fail in 25-20161010.n.0):

ID: 40461   Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/40461
ID: 40483   Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/40483
ID: 40498   Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/40498
ID: 40500   Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/40500
ID: 40527   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/40527

Old failures (same test failed in 25-20161010.n.0):

ID: 40432   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40432
ID: 40439   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/40439
ID: 40456   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/40456
ID: 40544   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/40544

Passed openQA tests: 90/102 (x86_64), 16/17 (i386)

New passes (same test did not pass in 25-20161010.n.0):

ID: 40441   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/40441
ID: 40460   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/40460
ID: 40466   Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/40466
ID: 40467   Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/40467
ID: 40470   Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/40470
ID: 40471   Test: x86_64 Server-dvd-iso server_database_client
URL: https://openqa.fedoraproject.org/tests/40471
ID: 40473   Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/40473
ID: 40475   Test: x86_64 Server-dvd-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/40475
ID: 40476   Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/40476
ID: 40477   Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/40477
ID: 40478   Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/40478
ID: 40548   Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/40548
ID: 40550   Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/40550
ID: 40551   Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/40551
ID: 40552   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/40552
ID: 40553   Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/40553

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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 11, 2016 at 4:48 PM, Chris Murphy 
wrote:

> > As far as BTRFS
>
> is concerned however, I believe that ship has sailed.  I used it for 4
> > years, but after the recent news regarding RAID
>
> The only news about Btrfs RAID I can think of that you're referring to
> is the raid5 scrub bug that corrupts parity in a very specific
> situation. It's a bad bug, but it's also really rare.
>

That may be, but all the articles I read suggested "be afraid, be very
afraid".
In addition, https://goo.gl/V2IyFq
basically just comes out and says, not to use it.

I knew that it was experimental when I first set it up years ago, but I
never imagined
it would still be experimental in 2016.  I just got tired of waiting, and
the statement
that it would all most likely have to be rewritten was just the last straw
for me.  The
only reason I was using it was because of the ease and flexibility to run
Raid5/6.  With
that apparently nowhere now on the horizon, time to cut my loses and move
on.


> Anyway it's a bad bug. But it's not correct to assign this bug to the
> other three raid profiles or Btrfs in general - where it has numerous
> features not all of which have the same maturity.


Agreed, but in my mind the last episode throws some serious shade
on the entire project.  Once upon a time, there was talk about making the
default in
Fedora, but now - not so much.  In the meantime XFS is being improved and
bcachefs is
being developed.  Tick tock...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jenkins]

See 


--
[...truncated 3766 lines...]
suites/paged_results/paged_results_test.py::test_search_limits_fail[21-50-cn=config-nsslapd-pagedsizelimit-5-SIZELIMIT_EXCEEDED]
 PASSED
suites/paged_results/paged_results_test.py::test_search_limits_fail[5-50-cn=config,cn=ldbm
 database,cn=plugins,cn=config-nsslapd-lookthroughlimit-20-ADMINLIMIT_EXCEEDED] 
PASSED
suites/paged_results/paged_results_test.py::test_search_sort_success PASSED
suites/paged_results/paged_results_test.py::test_search_abandon PASSED
suites/paged_results/paged_results_test.py::test_search_with_timelimit PASSED
suites/paged_results/paged_results_test.py::test_search_dns_ip_aci[dns = 
"localhost.localdomain"] PASSED
suites/paged_results/paged_results_test.py::test_search_dns_ip_aci[ip = "::1" 
or ip = "127.0.0.1"] PASSED
suites/paged_results/paged_results_test.py::test_search_multiple_paging PASSED
suites/paged_results/paged_results_test.py::test_search_invalid_cookie[1000] 
PASSED
suites/paged_results/paged_results_test.py::test_search_invalid_cookie[-1] 
PASSED
suites/paged_results/paged_results_test.py::test_search_abandon_with_zero_size 
PASSED
suites/paged_results/paged_results_test.py::test_search_pagedsizelimit_success 
PASSED
suites/paged_results/paged_results_test.py::test_search_nspagedsizelimit[5-15-PASS]
 PASSED
suites/paged_results/paged_results_test.py::test_search_nspagedsizelimit[15-5-SIZELIMIT_EXCEEDED]
 PASSED
suites/paged_results/paged_results_test.py::test_search_paged_limits[conf_attr_values0-ADMINLIMIT_EXCEEDED]
 PASSED
suites/paged_results/paged_results_test.py::test_search_paged_limits[conf_attr_values1-PASS]
 PASSED
suites/paged_results/paged_results_test.py::test_search_paged_user_limits[conf_attr_values0-ADMINLIMIT_EXCEEDED]
 PASSED
suites/paged_results/paged_results_test.py::test_search_paged_user_limits[conf_attr_values1-PASS]
 PASSED
suites/paged_results/paged_results_test.py::test_ger_basic PASSED
suites/paged_results/paged_results_test.py::test_multi_suffix_search PASSED
suites/paged_results/paged_results_test.py::test_maxsimplepaged_per_conn_success[None]
 PASSED
suites/paged_results/paged_results_test.py::test_maxsimplepaged_per_conn_success[-1]
 PASSED
suites/paged_results/paged_results_test.py::test_maxsimplepaged_per_conn_success[1000]
 PASSED
suites/paged_results/paged_results_test.py::test_maxsimplepaged_per_conn_failure[0]
 PASSED
suites/paged_results/paged_results_test.py::test_maxsimplepaged_per_conn_failure[1]
 PASSED
suites/pam_passthru_plugin/pam_test.py::test_pam_init PASSED
suites/pam_passthru_plugin/pam_test.py::test_pam_ PASSED
suites/passthru_plugin/passthru_test.py::test_passthru_init PASSED
suites/passthru_plugin/passthru_test.py::test_passthru_ PASSED
suites/password/password_test.py::test_password_init PASSED
suites/password/password_test.py::test_password_delete_specific_password PASSED
suites/password/pwdAdmin_test.py::test_pwdAdmin_init PASSED
suites/password/pwdAdmin_test.py::test_pwdAdmin PASSED
suites/password/pwdAdmin_test.py::test_pwdAdmin_config_validation PASSED
suites/password/pwdPolicy_attribute_test.py::test_change_pwd[on-off-UNWILLING_TO_PERFORM]
 PASSED
suites/password/pwdPolicy_attribute_test.py::test_change_pwd[off-off-UNWILLING_TO_PERFORM]
 PASSED
suites/password/pwdPolicy_attribute_test.py::test_change_pwd[off-on-None] PASSED
suites/password/pwdPolicy_attribute_test.py::test_change_pwd[on-on-None] PASSED
suites/password/pwdPolicy_attribute_test.py::test_pwd_min_age PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-off]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[on-off]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-on]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn=config]
 PASSED
suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn="cn=nsPwPolicyEntry,ou=People,dc=example,dc=com",cn=nsPwPolicyContainer,ou=People,dc=example,dc=com]
 PASSED
suites/password/pwdPolicy_syntax_test.py::test_pwdPolicy_syntax PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[ ] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[junk123] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[on] PASSED
suites/password/pwdPolicy_warning_test.py::test_different_values[off] PASSED
suites/password/pwdPolicy_warning_test.py::test_expiry_time PASSED
suites/password/pwdPolicy_warning_test.py::test_password_warning[passwordSendExpiringTime-off]
 PASSED
suites/password/pwdPolicy_warning_test.py::test_password_warning[passwordWarning-3600]
 PASSED
suites/password/pwdPolicy_warning_test.py::test_with_different_password_states 
PASSED
suites/password/pwdPolicy_warning_test.py::test_default_behavior PASSED

Re: OpenSSL 1.1.0 in Rawhide very soon

[David Woodhouse]

On Mon, 2016-10-10 at 16:29 +0200, Tomas Mraz wrote:
> 
> We will work on porting the dependent packages to the new API. If by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add -devel
> to the compat package. Note though that small changes in such packages
> will be needed anyway as the include files of the compat package will
> have to be in non-default include directory. (If the package doesn't
> use pkgconfig to find the needed CFLAGS automatically.)

Even if it uses pkgconfig, it's still going to need to look for
openssl102.pc or whatever we call it, because just 'openssl' is going
to get it OpenSSL 1.1.

And if we *are* going to ship a separate -devel package for 1.0.2 and
1.1 in parallel we are *really* going to need to make sure that
*neither* of them live in /usr/include/openssl/ where they can be
picked up by default.

-- 
dwmw2

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

[Bug 1383850] New: perl-MooseX-App-1.36 is available

[bugzilla]

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

Bug ID: 1383850
   Summary: perl-MooseX-App-1.36 is available
   Product: Fedora
   Version: rawhide
 Component: perl-MooseX-App
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.36
Current version/release in rawhide: 1.35-2.fc25
URL: http://search.cpan.org/dist/MooseX-App/

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

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

[Test-Announce] Fedora 25 Workstation Wayland Test Day: 2016-10-13!

[Adam Williamson]

Hi folks! Time to announce another Fedora 25 Test Day: [Wayland Test
Day][1]! Note, the wiki page doesn't exist yet, as the wiki is having
issues right now, but I wanted to make the announcement early enough to
give people time to prepare.

You may have read that we plan to make Fedora 25 Workstation the first
release to default to [Wayland][2] (rather than X11) as the graphical
server. This has been in place since Fedora 25 Alpha, but to prepare
for the general release, we'd like to run a test day and get some
broad-based testing to ensure that Wayland is at least good enough for
an initial release, and that the option to switch to X11 works properly
for those cases where it might be necessary.

You'll be able to run most of the tests from a live image (without
doing a permanent installation). All the test instructions will be on
[the wiki page][1] and there will be QA and developer folks around all
day in [the IRC channel][3] to help you test and report any issues you
find.

Just about anyone with a computer can help with this testing, and we'd
like to have feedback from as many users as possible, so please, if you
have a little time on Thursday, come help out! As always, the event
will be in #fedora-test-day on Freenode IRC. If you don’t know how to
use IRC, you can read [these instructions][4], or just use [WebIRC][3].

 [1]: https://fedoraproject.org/wiki/Test_Day:2016-11-13_Wayland
 [2]: https://wayland.freedesktop.org/
 [3]: http://webchat.freenode.net/?channels=fedora-test-day
 [4]: http://fedoraproject.org/wiki/How_to_use_IRC
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
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: More texlive woes in rawhide

[Björn Esser]

Am 11.10.2016 um 19:49 schrieb gil:


hi

"Package resolution failed package 
texlive-latex-bin-bin-5:svn14050.0-8.20160520.fc26.1.noarch requires 
texlive-latex-bin, but none of the providers can be installed "


from https://apps.fedoraproject.org/koschei/package/metrics?collection=f26

any ideas?

regards

.g



Fixed ` texlive-2016-9.20160520.fc2{5,6}` has finished building…  Should 
be available in the build-repos in short.


Waiting for this, to successfully re-build one package,too.


Il 11/10/2016 18:03, Tomasz Kłoczko ha scritto:

It would be really stop this texlive madness.
Spec file with attached more than 100 source archives, with separated 
each bit in  and -bin (???)
Why the  not build base package with kind of platform which 
will allow build each tex package separately?
With current approach every single change i texlive will be affecting 
huge list of other packages reinstallations introducing nothing nw.


kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH*

On 11 October 2016 at 07:50, Gianluca Sforna > wrote:


Hi all,
it seems right now I can't rebuild the rdkit package [1] due to this:

pdflatex  'RDKit.tex'
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex)
 restricted \write18 enabled.
kpathsea: Running mktexfmt pdflatex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in
precedence order):
mktexfmt: mktexfmt is using the following fmtutil.cnf file for
writing changes:
mktexfmt:   /builddir/.cache/texlive/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under
/builddir/.cache/texlive/texmf-var/web2c
mktexfmt [INFO]: did not find entry for byfmt=pdflatex, skipped
mktexfmt [INFO]: Total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `pdflatex.fmt'!

Anyone can give me a clue?


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=16036105


--
Gianluca Sforna

http://plus.google.com/+gianlucasforna
 - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it
___
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 todevel-le...@lists.fedoraproject.org




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

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

Re: Please rebuild OpenEXR against GCC 6.2

[Björn Esser]

Am 11.10.2016 um 04:03 schrieb Luya Tshimbalanga:

After investigating the issues related to FTBS on Blender, it turned out
the change from glibc cause OpenEXR to fail on Rawhide repository
according to koschei report:

https://apps.fedoraproject.org/koschei/package/blender

I already filed the report on

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

as applications using OpenEXR may be affected.


Rebuild for GCC 6.2 [1] is running.


[1]  http://koji.fedoraproject.org/koji/taskinfo?taskID=16056229
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Chris Murphy]

On Tue, Oct 11, 2016 at 4:17 PM, Gerald B. Cox  wrote:
>
> On Tue, Oct 11, 2016 at 2:38 PM, Tomasz Kłoczko 
> wrote:
>>
>> You have still 4th option:
>> - create from snapshots separated boot environment (BE)
>> - do upgrade in BE
>> - restart system from new BE
>>
>> To be honest only tis method solves all hazards which are not listed in
>> your 3 points and additionally you will have possibility to create packages
>> without any post install/uninstall scripts which are biggest risk factor of
>> ANY upgrades.
>
>
> Thats fine, but first of all - those aren't my points - they are from the
> link I included regarding Project Tracer.
> My comment was directed at folks who were concerned about running dnf from a
> terminal within a DE - and
> were interested in some type of risk mitigation now.  Your suggestion
> requires a bit more work.

Running an update in the DE on an out of tree snapshot of the file
system is fairly trivial. The harder part is merging the changes that
happen from snapshot time to reboot time, and managing rollbacks.

> As far as BTRFS
> is concerned however, I believe that ship has sailed.  I used it for 4
> years, but after the recent news regarding RAID

The only news about Btrfs RAID I can think of that you're referring to
is the raid5 scrub bug that corrupts parity in a very specific
situation. It's a bad bug, but it's also really rare. First it
requires a data strip to contain corruption. During scrub, the data
block fails checksum, Btrfs does a good reconstruction from parity and
repairs the bad data strip, but then goes on to *sometimes* wrongly
recomputing parity and overwriting the good parity with bad parity. So
in effect, it has silently transposed the corruption from a data strip
to parity strip. Normal operation, you get your data, uncorrupted. If
you lose a drive, and now that bad parity is needed, it results in a
bad reconstruction of data, which results in EIO because the bad data
fails checksum. So to get this form of data loss you need an already
bad data strip, a scrub that hits this particular bug, and then lose a
device. But you don't get corrupt data propagated upward.

It's uncertain how this manifests on raid6, I haven't tested it. My
expectation is the failed csum from reconstruction using p-parity will
result in another attempt using q-parity, and then fixing up the data
and p-parities if the reconstruction passes the data checksum.

Understand that in the identical situation with mdraid and lvm raid, a
scrub check would only report a mismatch, it wouldn't tell you which
was correct. And if you did a scrub repair, it will assume data strips
are valid, and in this case it'd *always* result in the wrong parity
being written over good.

Anyway it's a bad bug. But it's not correct to assign this bug to the
other three raid profiles or Btrfs in general - where it has numerous
features not all of which have the same maturity.

https://btrfs.wiki.kernel.org/index.php/Status

> I switched everything to XFS.

There are many good and valid reasons to use it.


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

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Gerald B. Cox]

On Tue, Oct 11, 2016 at 2:38 PM, Tomasz Kłoczko 
wrote:

> You have still 4th option:
> - create from snapshots separated boot environment (BE)
> - do upgrade in BE
> - restart system from new BE
>
> To be honest only tis method solves all hazards which are not listed in
> your 3 points and additionally you will have possibility to create packages
> without any post install/uninstall scripts which are biggest risk factor of
> ANY upgrades.
>

Thats fine, but first of all - those aren't my points - they are from the
link I included regarding Project Tracer.
My comment was directed at folks who were concerned about running dnf from
a terminal within a DE - and
were interested in some type of risk mitigation now.  Your suggestion
requires a bit more work.  As far as BTRFS
is concerned however, I believe that ship has sailed.  I used it for 4
years, but after the recent news regarding RAID
I switched everything to XFS.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Tomasz Kłoczko]

 On 10 October 2016 at 00:04, Gerald B. Cox  wrote:

> You have 3 options how to resolve it:
>
>1. You ignore it completely and you patiently wait until your system
>crash.
>2. Do Offline Updates
>.
>3. After restart you carefully restart only those applications and
>daemons, which needs to be restarted.
>
> You have still 4th option:
- create from snapshots separated boot environment (BE)
- do upgrade in BE
- restart system from new BE

To be honest only tis method solves all hazards which are not listed in
your 3 points and additionally you will have possibility to create packages
without any post install/uninstall scripts which are biggest risk factor of
ANY upgrades.
Really Linux needs to start learning from what has been done on Solaris
more than decade ago.
What old SySV packages maintainers found that majority of different
customers problems on applying upgrades where generated by fully
customizable post install/uninstall scripts. This was main driving force on
implementing in IPS something which is called package action which is well
tested sequence of operation in some class of installed resources.

BE has very precise properties. It keeps only one kernel instance in each
BE and boot loader must collect on boot stage informations about available
BEs to present them as boot menu. Whatever needs to be customized as
command line boot parameter needs to be part of BE description. Only with
above approach is possible to stop updating boot entries and stop fighting
with many other problems with which all Linux distros are fighting more
than one and half decade.

Again: to solve all upgrade issues it needs to be synchronized few
technologies related to boot manager, package manager and used file
systems. At least using btrfs, grub2 and rpm with removed post
install/uninstall custom scripts is possible to solve finally all issues.
It is possible to prepare packages in some way allowing to use post
install/uninstall in case not using btrfs but it could be exact amin
decision to accept some well known risk coming with choosing old/legacy
approach.

Whatever would be not done if not done using above idea will be still with
non-zero risk of well known and new issues.
Some people must understand that whatever they will be trying to archive
without radical change which Solaris acceped and implemented decade ago it
will be only WASTE OF TIME.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: More texlive woes in rawhide

[gil]

hi

"Package resolution failed package 
texlive-latex-bin-bin-5:svn14050.0-8.20160520.fc26.1.noarch requires 
texlive-latex-bin, but none of the providers can be installed "


from https://apps.fedoraproject.org/koschei/package/metrics?collection=f26

any ideas?

regards

.g


Il 11/10/2016 18:03, Tomasz Kłoczko ha scritto:

It would be really stop this texlive madness.
Spec file with attached more than 100 source archives, with separated 
each bit in  and -bin (???)
Why the  not build base package with kind of platform which 
will allow build each tex package separately?
With current approach every single change i texlive will be affecting 
huge list of other packages reinstallations introducing nothing nw.


kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH*

On 11 October 2016 at 07:50, Gianluca Sforna > wrote:


Hi all,
it seems right now I can't rebuild the rdkit package [1] due to this:

pdflatex  'RDKit.tex'
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex)
 restricted \write18 enabled.
kpathsea: Running mktexfmt pdflatex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in
precedence order):
mktexfmt: mktexfmt is using the following fmtutil.cnf file for
writing changes:
mktexfmt:   /builddir/.cache/texlive/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under
/builddir/.cache/texlive/texmf-var/web2c
mktexfmt [INFO]: did not find entry for byfmt=pdflatex, skipped
mktexfmt [INFO]: Total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `pdflatex.fmt'!

Anyone can give me a clue?


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=16036105


--
Gianluca Sforna

http://plus.google.com/+gianlucasforna
 - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it
___
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


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

[Bug 1381101] perl-Text-Bidi-2.12 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Text-Bidi-2.12-1.fc26  |perl-Text-Bidi-2.12-1.fc26
   |perl-Text-Bidi-2.12-1.fc25  |perl-Text-Bidi-2.12-1.fc25
   ||perl-Text-Bidi-2.12-1.fc24



--- Comment #8 from Fedora Update System  ---
perl-Text-Bidi-2.12-1.fc24 has been pushed to the Fedora 24 stable repository.
If problems still persist, please make note of it in this bug report.

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

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[Chris Murphy]

On Tue, Oct 11, 2016 at 12:41 PM, DJ Delorie  wrote:
>
>> U.S. rural areas? :-D
>
> I'm pretty rural, and even I have good internet.  Maybe we need to
> redefine "rural" to be independent of physicality :-)

Yes it was sort of a ding on the state of affairs in the U.S. rather
than rural areas. U.S. bandwidth increases aren't keeping up with the
rest of the world, even including urban areas let alone excluding them
from the metric. And I'm in a rural area with ~18Mbps usually but it
varies below that sometimes by quite a bit, as low as 2Mbps.

So if the context is 2Mbps or less, I'd think people would get
frustrated fairly quickly with the ~ 1GiB+ downloads Gnome Software
does in the background on first boot, with no UI for disabling it.
Those without internet wouldn't have this problem of course. But they
get hit with a higher percent of unfixed bugs, even known bugs, that
just weren't bad enough to be blockers.

Another idea might be merging the optical media use case with another
one that already exists and has testers who might be in a position to
maintain working optical boot: Live respins.
http://dl.fedoraproject.org/pub/alt/live-respins/  This group is
making up to date Lives, so there's far less stale stuff with more bug
fixes than the official media.


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

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[Chris Murphy]

On Tue, Oct 11, 2016 at 6:47 AM, Richard Ryniker  wrote:
>>an optical specific Live Workstation spin
>
> Sounds like the proper category: will not block a regular Fedora release,
> will not consume test resources for primary Fedora deliverables, and will
> provide a focus for those with some stake in optical media.
>
> While lack of community to support an "optical spin" may not mean there
> are few who want it, it would mean there are insufficient people who will
> invest their talent to create it.

All Fedora ISO's start out as ISO 9660, with El Torito extensions
added; and GRUB 2 and ISOLINUX to boot UEFI and BIOS systems
respectively. The ISO 9660 and El Torito parts are probably pretty
statically reliable. The gotcha comes from the ever changing
bootloaders, and there are two of them. Even if we standardized on one
of them, they're in effect two still, because BIOS and UEFI systems
use completely different binary files and boot mechanisms following
the El Torito part that enables discovery of the bootloader. So the
bottom line is, if we want optical to work, it has to be tested.
*shrug* Otherwise there's a chance we run into bugs like this [1]
which is an bug only affecting boot when the ISO image is burned onto
actual physical optical media, the problem doesn't happen with the
same image written to USB sticks.

Bolted onto that however, isohybrid adds an MBR, and then also a GPT
and APM (yes no kidding three partitions) are added. This is how we
boot Macs from optical or USB sticks, and everything else BIOS or UEFI
from USB sticks. This is for x86_64, I'm not sure what other archs'
ISO's look like.

Is there a less fragile way to do all of this? *shrug* It's a very
delicately, and eyebrow raising, balanced boat. Maybe the strongest
argument for thinning the heard of parts on these ISOs is, it'd be
easier to modify a single partition map to bring about persistence to
the USB stick, but that just makes us trade problems we know for
problems we don't know. There's no net increase in stability,
probably.


[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1148087


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

Re: Installation validation test change proposal: merge USB tests into 'default boot and install', add more environment columns

[DJ Delorie]

> U.S. rural areas? :-D

I'm pretty rural, and even I have good internet.  Maybe we need to
redefine "rural" to be independent of physicality :-)

> Based on feedback from Ambassadors, DVD images may still be useful
> giveaways in regions with less access to bandwidth. I'm not sure what
> to do about that.

Having been through the "mail disks" end of things myself, I can agree
that having *some* way of bulk transferring data to people in need is,
if not mandatory, at least very useful.  However, I would condition that
with "any method that works" - it doesn't need to be an installable
image, for example, as long as the recipient can use it locally to do an
install somehow (for example, a split-up directory tree that, when
combined, makes an nfs-installable repo, would be sufficient).

We'd need to consider how often such disks are needed vs the effort of
making them "pretty" on our end.  For example, if an Ambassador can use
their laptop, or a USB stick, to bootstrap an install (i.e. at an
installfest), then use that machine to install to others... etc.

Just saying, while a cd/dvd/bluray is the easiest thing to mail, it's
not the only option to enable those folks.  We need to balance
stack-of-cds vs bluray vs usbstick vs laptop vs effort on our end vs
what the actual problem is (i.e. "test Fedora" vs "local full repo").

(personally, I think a bootable USB is much more useful than an
installable disc, as long as the USB can store user data and thus not be
transient, but I too have a few older machines that can't boot USB)

> I downloaded djgpp over a second-hand 1200 baud modem in the early 90s.

Me too.  Oh wait... ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Weak password madness is back again

[stan]

On Tue, 11 Oct 2016 08:35:35 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Tue, Oct 11, 2016 at 09:15:12AM +0200, Björn Persson wrote:
> > Zbigniew Jędrzejewski-Szmek  wrote:  
> > > Yes. The hint that "this passphrase is weak" is very useful. But
> > > enforcing any policy is just too inflexible. I just tried to
> > > explain (unsuccessfully) to a kid (2nd grade, so any "strong"
> > > password would simply be immediately forgotten) why she cannot
> > > change the password in the gnome dialogue, and it was a total
> > > waste of time.  
> > 
> > Is a second-grader actually unable to remember "correct horse
> > battery staple"? I strongly doubt that. Spell it, maybe not, but
> > surely she could remember a four-word string?  
> 
> A pass*phrase* like that is certainly much more feasible than a
> pass*word*.  But I still think it'd be an effort, for example I'd
> estimate a 50-50 chance of a passphrase being forgotten over a two
> week break.
> 
> And as for the spelling, notice the double-r and double-t, those would
> be a source of trouble ;) Without any feedback and only three tries,
> this would be rather frustrating.

How about a phrase she will remember, and will take pleasure in
typing? ;-)

"you are a good girl" or variation.  Does she have a favorite passage
in a book she reads?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Chris Murphy]

Yeah surely there's a better way to handle this than physically
connecting the device. Maybe OBEX and do it wirelessly with Bluetooth?
Mounting the device seems fraught with problems, even MTP isn't well
suited for this anymore.


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

[EPEL-devel] [Fedocal] Reminder meeting : EPSCO meeting

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPSCO meeting on 2016-10-12 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
Extra Packages for Enterprise Linux Steering COmmittee (EPSCO) has a weekly 
meeting to go over concerns and problems in the EPEL distribution. 

You are kindly invited to come and meet with us


Source: https://apps.fedoraproject.org/calendar/meeting/4639/

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

[Bug 1378192] Upstream bug causes attachments to fail with " Invalid Encoding" error.

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Mail-Sender-0.8.23-1.e
   ||l7
 Resolution|--- |ERRATA
Last Closed||2016-10-11 13:21:10



--- Comment #2 from Fedora Update System  ---
perl-Mail-Sender-0.8.23-1.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: iphone mount in nautilus on Fedora 24

[Timothy Ward]

On Tue, 2016-10-11 at 09:52 -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > 
> > 
> > > 
> > > 
> > > - Original Message -
> > > 
> > > Yup. The "normal" mount contains nothing that normal users
> > > should access.
> > > Accessing the photos will leave ghosts on the device, and there
> > > have been
> > > no
> > > ways to update the music database in Linux for a few iOS
> > > releases.
> > 
> > I very much doubt that anyone would release any code to touch an
> > idevice
> > music database due to fear of
> > legal action from the manufacturer. It may exist already.
> > 
> > The ability to sync contacts, calendars and events, meeting info,
> > notes,
> > pictures etc ( anything that would be considered the personal data
> > entered
> > by the idevice owner is another matter entirely. Anything that the
> > law
> > provides in most countries such as the IP to that person or the
> > copyright of
> > documents or photos etc, and yes it can be a very grey area
> > between the laws
> > in different countries. This is just the other side of the coin
> > but this
> > time from the owners perspective and legal rights.
> 
> What Linux applications support syncing those contacts? Are you sure
> they actually
> require the mounted filesystem?

These do not need the exposure of the mounted filesystem in nautilus.
 

Command line application do exist to sync phone contact's from
evolution data server to an idevice. one-way sync only at present
and is still work in progress and requires work to extend to other
sync operations.

https://github.com/gitsop01/eds-to-idevice


Spring Board Manager

Sbmanager from  
https://github.com/libimobiledevice/sbmanager - original gtk2 code
proof of concept for libimobiledevice library.

Still a work in progress with lots of refactoring and updating
of code to do.
https://github.com/gitsop01/sbmanager- Updated gtk3 port

> 
> 
> > 
> > 
> > is
> > > 
> > > 
> > > 
> > > You can still access the device by editing the URL in the
> > > "Documents on..."
> > > location. Just remove the ":3" at the end.
> > 
> > Thanks for this info,
> > > 
> > > 
> > > 
> > > If you have use cases that aren't the 2 mentioned above, or
> > > using your
> > > iDevice
> > > as a thumb drive, please file bugs against gvfs in the upstream
> > > GNOME
> > > Bugzilla.
> > > 
> > > Cheers
> > 
> > 
> > While I agree for the normal non developer user, the removal, to
> > be able to
> > access what you could originally access, on the idevice before the
> > code
> > change, may be of little value.
> > 
> > It is frustrating if you are developing applications and need
> > access to these
> > areas for debugging, checking directory, files and structure etc
> > of the
> > idevice.
> > 
> > It is even more frustrating when the Fedora workstation is being
> > targetted as
> > a developer's platform, and it also affects any downstream
> > distribution
> > developers in the same way.
> 
> How do you develop iOS applications on Linux? In any case, it's not
> a target
> of Fedora Workstation. It could be, but it's not.

This is more to do about developing applications for linux
to access the idevice that about iOS development on Fedora
Workstation but it may just help this also.

> 
> 
> > 
> > 
> > While nautilus still exposes the pictures on an idevice
> > through  gphoto2
> > system does not seem to have changed.
> 
> I can't parse that.
> 
> > 
> > 
> > As far as I am aware it is possible to copy pictures from the
> > idevice but
> > transfers of pictures to the idevice will succeed, but will not be
> > shown on
> > the idevice by native apps without further hacking.

This is only because a camera roll management needs implementation to
parse the file format. 
> 
> 
> So it doesn't work. Sure you could use, and you can still use, the
> partition
> as storage. But I don't see the point in doing that.

And it will stay that way if we do not allow developers easy access to
these area on the idevice. So everyone looses.

> 
> 
> > 
> > 
> > The other mount exposes the so called document folder of some user
> > installed
> > apps on the idevice and may be useful for someone developing
> 
> It's useful for adding files to applications, for example, music,
> photos, or
> documents in most 3rd-party applications.
> 
Agreed.
> 
> > 
> > 
> > but is off
> > limited use to a normal non developer user, unless the normal non
> > developer
> > wants to use the phone as a usb drive to transport files without
> > carrying an
> > extra usb drive.
> > 
> > The removal of the nautilus properties page on an connected
> > idevice does have
> > an effect that a nautilus-ideviceinfo extension that has been in
> > gnome git
> > for many years cannot be easily exposed and used and a gnome
> > bugzilla entry
> > has been active from last year without even a comment to date.
> 
> That's unrelated.
> 
Actually it is not unrelated at all as supports the subject of the
email.


The fact that a properties dialogue is not 

Copr && Rawhide -- no "rolling updates" workflow

[Pavel Raiskup]

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

Seems like the `fedora-rawhide-x86_64` chroot is not going to exist from
now, which is IMO unnecessary change ... but what could be other than
those "obvious" consequences for both Copr repo maintainers and users?
Does this sound like acceptable change?

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 16:46 +, Petr Pisar wrote:
> On 2016-10-11, Remi Collet  wrote:
> > 
> > It doesn't seem possible to use a compat library (else we will very
> > probably going to encounter issues is both library versions are
> > used in
> > the same process, because of the numerous libraries linked to PHP
> > or its
> > extensions)
> > 
> That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
> while the ported code build and passed all tests when built against
> old
> OpenSSL, it crashed when linked to the new OpenSSL. The reason there
> was
> another Perl package loaded into the process that was linked to the
> old
> OpenSSL.
> 
> Therefore I conclude it will be necessary to rebuild all packages
> requiring the old soname against new OpenSSL in the order of
> dependencies.

In my testing of application that pulled both old (indirectly) and new
OpenSSL (directly), it did not crash and I did not see anything wrong
with it. So it seems not all cases are broken however apparently the
above is reason for moving dependencies to 1.1.0 as quickly as
possible.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

[Bug 1383760] New: perl-Crypt-OpenSSL-PKCS10-0.15-3.fc26 FTBFS: dereferencing pointer to incomplete type ' EVP_PKEY {aka struct evp_pkey_st}'

[bugzilla]

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

Bug ID: 1383760
   Summary: perl-Crypt-OpenSSL-PKCS10-0.15-3.fc26 FTBFS:
dereferencing pointer to incomplete type 'EVP_PKEY
{aka struct evp_pkey_st}'
   Product: Fedora
   Version: rawhide
 Component: perl-Crypt-OpenSSL-PKCS10
  Assignee: wjhns...@hardakers.net
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wjhns...@hardakers.net
Blocks: 1383740



perl-Crypt-OpenSSL-PKCS10-0.15-3.fc26 fails to build in F26:

gcc -c   -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom
-fasynchronous-unwind-tables -fwrapv -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"0.15\"
-DXS_VERSION=\"0.15\" -fPIC "-I/usr/lib/perl5/CORE"  -DPERL5 -Wall PKCS10.c
[...]
PKCS10.xs:439:10: error: dereferencing pointer to incomplete type 'EVP_PKEY
{aka struct evp_pkey_st}'
  if (pkey->type == EVP_PKEY_RSA) {
  ^~

This is caused by upgrading openssl from 1:1.0.2j-1.fc26 to 1:1.1.0b-1.fc26.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not ported to new
OpenSSL 1.1.0 API
-- 
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-Crypt-OpenSSL-EC (master). "Rebuild against OpenSSL 1.1.0"

[notifications]

From 450119f5ec54af5d9578c0606292990ea82382c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 11 Oct 2016 18:48:15 +0200
Subject: Rebuild against OpenSSL 1.1.0

---
 perl-Crypt-OpenSSL-EC.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Crypt-OpenSSL-EC.spec b/perl-Crypt-OpenSSL-EC.spec
index c904df8..66af07d 100644
--- a/perl-Crypt-OpenSSL-EC.spec
+++ b/perl-Crypt-OpenSSL-EC.spec
@@ -1,6 +1,6 @@
 Name:   perl-Crypt-OpenSSL-EC
 Version:1.01
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Perl extension for OpenSSL EC (Elliptic Curves) library
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -60,6 +60,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 11 2016 Petr Pisar  - 1.01-6
+- Rebuild against OpenSSL 1.1.0
+
 * Sun May 15 2016 Jitka Plesnikova  - 1.01-5
 - Perl 5.24 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Crypt-OpenSSL-EC.git/commit/?h=master=450119f5ec54af5d9578c0606292990ea82382c8
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1383759] New: perl-Crypt-OpenSSL-X509-1.807-1.fc26 FTBFS: unknown type name 'NETSCAPE_X509'

[bugzilla]

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

Bug ID: 1383759
   Summary: perl-Crypt-OpenSSL-X509-1.807-1.fc26 FTBFS: unknown
type name 'NETSCAPE_X509'
   Product: Fedora
   Version: rawhide
 Component: perl-Crypt-OpenSSL-X509
  Assignee: wjhns...@hardakers.net
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wjhns...@hardakers.net
Blocks: 1383740



perl-Crypt-OpenSSL-X509-1.807-1.fc26 fails to build in F26:

gcc -c  -I/usr/include/openssl -I/usr/local/include/ssl
-I/usr/local/ssl/include -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32
-march=i686 -mtune=atom -fasynchronous-unwind-tables -fwrapv
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"1.807\" -DXS_VERSION=\"1.807\" -fPIC
"-I/usr/lib/perl5/CORE"   X509.c
X509.xs: In function '_decode_netscape':
X509.xs:217:5: error: unknown type name 'NETSCAPE_X509'
 NETSCAPE_X509 nx;
 ^

This is caused by upgrading openssl from 1:1.0.2j-1.fc26 to 1:1.1.0b-1.fc26.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not ported to new
OpenSSL 1.1.0 API
-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 6:08 PM, Tomas Mraz  wrote:
> On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
>> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch 
>> wrote:
>> >
>> > Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
>> > 1.1.0
>> > support:
>> >
>> > https://bugs.ruby-lang.org/issues/12830
>> >
>> > Not sure if you'll have also some Fedora specific tracker 
>> Would be nice to get tracking bug created on RHBZ, so we can track
>> all
>> the packages.
>
> Created:
> https://bugzilla.redhat.com/show_bug.cgi?id=1383740
Thanks!

I opened couple of bugreports against my packages so I will try to fix
myself and notify upstream. Just wanted bug to track things to do.
>
> --
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> (You'll never know whether the road is wrong though.)
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

[Bug 1383756] New: perl-Crypt-SSLeay-0.72-9.fc26 FTBFS: blib/arch/auto/ Crypt/SSLeay/SSLeay.so: undefined symbol: SSLv2_client_method

[bugzilla]

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

Bug ID: 1383756
   Summary: perl-Crypt-SSLeay-0.72-9.fc26 FTBFS:
blib/arch/auto/Crypt/SSLeay/SSLeay.so: undefined
symbol: SSLv2_client_method
   Product: Fedora
   Version: rawhide
 Component: perl-Crypt-SSLeay
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 1383740



perl-Crypt-SSLeay-0.72-9.fc26 fails to build in F26 because tests fail:

+ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- SSLeay.bs
blib/arch/auto/Crypt/SSLeay/SSLeay.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t
#   Failed test 'use Crypt::SSLeay;'
#   at t/00-basic.t line 6.
# Tried to use 'Crypt::SSLeay'.
# Error:  Can't load
'/builddir/build/BUILD/Crypt-SSLeay-0.72/blib/arch/auto/Crypt/SSLeay/SSLeay.so'
for module Crypt::SSLeay:
/builddir/build/BUILD/Crypt-SSLeay-0.72/blib/arch/auto/Crypt/SSLeay/SSLeay.so:
undefined symbol: SSLv2_client_method at /usr/lib64/perl5/DynaLoader.pm line
193.

This is caused by upgrading openssl from 1:1.0.2j-1.fc26 to 1:1.1.0b-1.fc26.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not easily ported to
new OpenSSL API
-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Petr Pisar]

On 2016-10-11, Remi Collet  wrote:
> It doesn't seem possible to use a compat library (else we will very
> probably going to encounter issues is both library versions are used in
> the same process, because of the numerous libraries linked to PHP or its
> extensions)
>
That's true. I was just porting a Perl package to OpenSSL 1.1.0 and
while the ported code build and passed all tests when built against old
OpenSSL, it crashed when linked to the new OpenSSL. The reason there was
another Perl package loaded into the process that was linked to the old
OpenSSL.

Therefore I conclude it will be necessary to rebuild all packages
requiring the old soname against new OpenSSL in the order of
dependencies.

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

ppisar pushed to perl-Crypt-OpenSSL-Bignum (master). "Rebuild against OpenSSL 1.1.0"

[notifications]

From 49dc43c4fcf64a61b4896ee790664164084409d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Tue, 11 Oct 2016 18:46:48 +0200
Subject: Rebuild against OpenSSL 1.1.0

---
 perl-Crypt-OpenSSL-Bignum.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Crypt-OpenSSL-Bignum.spec b/perl-Crypt-OpenSSL-Bignum.spec
index 306c201..f3e8bbb 100644
--- a/perl-Crypt-OpenSSL-Bignum.spec
+++ b/perl-Crypt-OpenSSL-Bignum.spec
@@ -1,6 +1,6 @@
 Name:   perl-Crypt-OpenSSL-Bignum
 Version:0.06
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Perl interface to OpenSSL for Bignum
 License:GPL+ or Artistic 
 Group:  Development/Libraries
@@ -48,6 +48,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*
 
 %changelog
+* Tue Oct 11 2016 Petr Pisar  - 0.06-6
+- Rebuild against OpenSSL 1.1.0
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.06-5
 - Perl 5.24 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Crypt-OpenSSL-Bignum.git/commit/?h=master=49dc43c4fcf64a61b4896ee790664164084409d3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1383654] perl-Crypt-SMIME-0.17-1.fc26 FTBFS: 'PKCS7_F_B64_WRITE_PKCS7 ' undeclared

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1383740




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not easily ported to
new OpenSSL API
-- 
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

Curios - Why python3 is not in critical path?

[William Moreno]

Hello!

Looking at the pkgdb looks like python3 it is not included in the Fedora
critical path:

https://admin.fedoraproject.org/pkgdb/package/rpms/python3/
https://admin.fedoraproject.org/pkgdb/package/rpms/python/

In the updates system also python3 is not part of the critical path update:

https://bodhi.fedoraproject.org/updates/FEDORA-2016-d49f8ec161

I think the critical path in bodhi is important to get enought karma before
go to stable.

I have filler a but about that:
https://bugzilla.redhat.com/show_bug.cgi?id=1383750

Regards.


*William Moreno Reyes*
Colaborador Proyecto Fedora | Nicaragua
IRC:  williamjmorenor Canales: #fedora-latam ; #fedora-ni
https://fedoraproject.org/wiki/User:Williamjmorenor
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1383652] perl-Crypt-OpenSSL-ECDSA-0.08-1.fc26 FTBFS: unknown type name 'ECDSA_METHOD'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1383740




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not easily ported to
new OpenSSL API
-- 
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 1383651] perl-Crypt-OpenSSL-DSA-0.15-5.fc26 FTBFS: dereferencing pointer to incomplete type 'DSA {aka struct dsa_st}'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1383740




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not easily ported to
new OpenSSL API
-- 
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 1383650] perl-Crypt-OpenSSL-RSA-0.28-15.fc26 FTBFS: dereferencing pointer to incomplete type 'RSA {aka struct rsa_st}'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Blocks||1383740




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1383740
[Bug 1383740] Tracker bug for dependencies that are not easily ported to
new OpenSSL API
-- 
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: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch 
> wrote:
> > 
> > Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
> > 1.1.0
> > support:
> > 
> > https://bugs.ruby-lang.org/issues/12830
> > 
> > Not sure if you'll have also some Fedora specific tracker 
> Would be nice to get tracking bug created on RHBZ, so we can track
> all
> the packages.

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

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Tomas Mraz]

On Út, 2016-10-11 at 09:25 -0600, Orion Poplawski wrote:
> On 10/07/2016 06:49 AM, Tomas Mraz wrote:
> > 
> > Hi all,
> > 
> > the openssl will be rebased in Rawhide to 1.1.0 on Monday. There
> > will
> > be also 1.0.2 compat package (compat-openssl10) so the dependencies
> > are
> > not broken and Rawhide should be installable. Also things that do
> > not
> > depend on openssl should be rebuildable without changes.
> > 
> > On the other hand due to the major API changes in 1.1.0 if your
> > package
> > uses OpenSSL it will not be possible to rebuild it without
> > patching.
> > Some upstreams already updated their code to work with 1.1.0 so if
> > it
> > is your case again there might not be any problems rebuilding it.
> > 
> > I will be also working on patching and rebuilding the dependencies
> > starting with minimal install and expanding to broader installs of
> > Fedora. However there might be cases where the package is using
> > some
> > obscure features of the old 1.0.x API and the port might be non-
> > trivial 
> > - I do not expect such packages to be common however cooperation
> > with
> > the respective package upstream might be needed in such cases.
> > 
> > At worst if the patching of a package is highly non-trivial and the
> > upstream is not responsive we might have to drop the package from
> > Fedora.
> > 
> > We do not want to keep 1.0.2 devel around as that could make it to
> > look
> > like the 1.0.2 is still fully "supported" in Fedora and there would
> > be
> > no incentive to switch to 1.1.0. Also to get any new features from
> > upstream OpenSSL we have to move to newer versions as they are
> > released
> > as the old versions get only bug fixes.
> > 
> It appears that setting:
> 
> -DOPENSSL_API_COMPAT=0x1002L
> 
> Should at least partially get you the 1.0.2 API.  Although clamav's
> configure
> test for SSL_library_init() doesn't #include  so that doesn't
> work for
> it out of the box.

Yes, it basically works for deprecated functions. However it does not
work for things that access structure members in the 1.0 API.

> Also, getting:
> 
> crypto.c: In function 'cl_load_crl':
> crypto.c:1113:32: error: dereferencing pointer to incomplete type
> 'X509_CRL
> {aka struct X509_crl_st}'
>  tm = cl_ASN1_GetTimeT(x->crl->nextUpdate);
> ^~
> 
> So looks like it doesn't work for all cases.

Yes, all the structures are opaque regardless of OPENSSL_API_COMPAT.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


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

Re: More texlive woes in rawhide

[Tomasz Kłoczko]

It would be really stop this texlive madness.
Spec file with attached more than 100 source archives, with separated each
bit in  and -bin (???)
Why the  not build base package with kind of platform which will
allow build each tex package separately?
With current approach every single change i texlive will be affecting huge
list of other packages reinstallations introducing nothing nw.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *

On 11 October 2016 at 07:50, Gianluca Sforna  wrote:

> Hi all,
> it seems right now I can't rebuild the rdkit package [1] due to this:
>
> pdflatex  'RDKit.tex'
> This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
> (preloaded format=pdflatex)
>  restricted \write18 enabled.
> kpathsea: Running mktexfmt pdflatex.fmt
> mktexfmt: mktexfmt is using the following fmtutil.cnf files (in
> precedence order):
> mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing
> changes:
> mktexfmt:   /builddir/.cache/texlive/texmf-config/web2c/fmtutil.cnf
> mktexfmt [INFO]: writing formats under /builddir/.cache/texlive/
> texmf-var/web2c
> mktexfmt [INFO]: did not find entry for byfmt=pdflatex, skipped
> mktexfmt [INFO]: Total formats: 0
> mktexfmt [INFO]: exiting with status 0
> I can't find the format file `pdflatex.fmt'!
>
> Anyone can give me a clue?
>
>
> [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=16036105
>
> --
> Gianluca Sforna
>
> http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
> Tinker Garage - http://tinkergarage.it
> ___
> 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: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

[Chris Murphy]

On Tue, Oct 11, 2016 at 1:53 AM, Gerd Hoffmann  wrote:

>> 4. An issue with using syslinux's format, as well as the original
>> bootloader spec format, and a major source of disagreement, is the
>> assumption that the kernel and initrd are on the same file system as
>> the bootloader and its configuration file.
>
> Dropping that assumption makes the boot loaders alot more complex
> though.  Suddenly you can't rely on the firmware any more for file
> access, need to understand partition schemes and filesystems, ...

No. The format must provide superset functionality for all
bootloaders. The bootloader can choose how to fail gracefully if a
particular boot entry snippet references files in a manner it doesn't
support.


>> This is necessary to avoid putting the kernel and initrd on the EFI
>> System partition, and causing a lot of installation grief with how to
>> deal with dual boot support.
>
> Hmm, not sure why you want avoid that, as I understand it the idea of
> the efi system partition is that everything needed to boot is there (for
> all operating systems in case of dual/multi-boot).  So why don't use it
> that way?

No. The EFI system partition is intended to be for the firmware:
bootloaders and configuration files. That's why by default no system
installer, not Fedora's, Ubuntu's, openSUSE, Apple or Microsoft, make
them bigger than 260MiB. Many are a good deal smaller. One of the
first things the Microsoft bootloader teaches the firmware is how to
read NTFS, so it can find and boot the Windows kernel. It's no
different than what Fedora and most other distros do.

And as I said earlier in the thread, for dual and multiboot systems,
the existing ESP is only barely big enough to share when restricted to
bootloaders and their files. There simply isn't enough room to put
kernels and initramfs's on them at all. And there's no practical way
to resize or replace them.



>
> It isn't that simple on !EFI systems though.

Very simple technically, not at all simple politically/cooperatively.


>
>> Anyway, regardless of what format you want to base things on, it
>> probably should be a superset of the menu entry functions, including a
>> way to specify volumes by device designation, LVM, or volume UUID, or
>> now your format isn't actually compatible with GRUB on UEFI as well as
>> a bunch of less common scenarios.
>
> Well, the bootloaderspec menu *entries* should not need that, just place
> them next to kernel + initrd and have a pointer to the directory (plus
> optional volume in case you place them outside the efi system partition,
> or on !EFI systems) to scan into the bootloader config file.

It's not workable for all the reasons I've previously mentioned, more
reasoning is in this proposed variant of the spec [1]. Plus it's a
step backwards for anyone wanting to snapshot /boot along with /usr,
so that kernels aren't orphaned from their modules.


[1]
https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/


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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Orion Poplawski]

On 10/07/2016 06:49 AM, Tomas Mraz wrote:
> Hi all,
> 
> the openssl will be rebased in Rawhide to 1.1.0 on Monday. There will
> be also 1.0.2 compat package (compat-openssl10) so the dependencies are
> not broken and Rawhide should be installable. Also things that do not
> depend on openssl should be rebuildable without changes.
> 
> On the other hand due to the major API changes in 1.1.0 if your package
> uses OpenSSL it will not be possible to rebuild it without patching.
> Some upstreams already updated their code to work with 1.1.0 so if it
> is your case again there might not be any problems rebuilding it.
> 
> I will be also working on patching and rebuilding the dependencies
> starting with minimal install and expanding to broader installs of
> Fedora. However there might be cases where the package is using some
> obscure features of the old 1.0.x API and the port might be non-trivial 
> - I do not expect such packages to be common however cooperation with
> the respective package upstream might be needed in such cases.
> 
> At worst if the patching of a package is highly non-trivial and the
> upstream is not responsive we might have to drop the package from
> Fedora.
> 
> We do not want to keep 1.0.2 devel around as that could make it to look
> like the 1.0.2 is still fully "supported" in Fedora and there would be
> no incentive to switch to 1.1.0. Also to get any new features from
> upstream OpenSSL we have to move to newer versions as they are released
> as the old versions get only bug fixes.
> 

It appears that setting:

-DOPENSSL_API_COMPAT=0x1002L

Should at least partially get you the 1.0.2 API.  Although clamav's configure
test for SSL_library_init() doesn't #include  so that doesn't work for
it out of the box.

Also, getting:

crypto.c: In function 'cl_load_crl':
crypto.c:1113:32: error: dereferencing pointer to incomplete type 'X509_CRL
{aka struct X509_crl_st}'
 tm = cl_ASN1_GetTimeT(x->crl->nextUpdate);
^~

So looks like it doesn't work for all cases.

ClamAV upstream request: https://bugzilla.clamav.net/show_bug.cgi?id=11646

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

Fedora Rawhide-20161011.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Kde live x86_64
Kde live i386

Failed openQA tests: 3/91 (x86_64), 2/16 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20161010.n.0):

ID: 40308   Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/40308
ID: 40355   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/40355

Old failures (same test failed in Rawhide-20161010.n.0):

ID: 40313   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/40313
ID: 40413   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/40413
ID: 40419   Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/40419
ID: 40422   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/40422

Passed openQA tests: 88/91 (x86_64), 14/16 (i386)

New passes (same test did not pass in Rawhide-20161010.n.0):

ID: 40362   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/40362
ID: 40368   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/40368
ID: 40403   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/40403
ID: 40414   Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/40414

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

Re: More texlive woes in rawhide

[Gianluca Sforna]

On Tue, Oct 11, 2016 at 2:14 PM, Richard Fearn  wrote:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1382447
>
> spot said the problem should be fixed in the -8 build
> (http://koji.fedoraproject.org/koji/buildinfo?buildID=808434), which
> has completed. I see your failed build used the -7 packages, so
> perhaps you just need to try it again.

Thanks for the info. I tried but mine is still failing, I added a
comment in the bug.

-- 
Gianluca Sforna

http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

spot pushed to perl-DateTime-Calendar-Julian (master). "extra br"

[notifications]

From 5e5a8eac499f25f629d6a8c6e18a9241f1277d2d Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Tue, 11 Oct 2016 10:40:34 -0400
Subject: extra br

---
 perl-DateTime-Calendar-Julian.spec | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 7729e9b..67163e0 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,13 +1,13 @@
 Name:  perl-DateTime-Calendar-Julian
 Version:   0.04
-Release:   3%{?dist}
+Release:   4%{?dist}
 License:   GPL+ or Artistic 
 Group: Development/Libraries
 Summary:   Julian Calendar support for DateTime.pm 
 Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
 Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
 BuildArch: noarch
-BuildRequires: perl-generators
+BuildRequires: perl-generators, perl, coreutils, findutils, make
 BuildRequires: perl(DateTime) >= 0.15
 BuildRequires: perl(ExtUtils::MakeMaker)
 BuildRequires: perl(Test::More) perl(Test::Harness)
@@ -39,6 +39,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Tue Oct 11 2016 Tom Callaway  - 0.04-4
+- add pedantic br
+
 * Mon Oct 10 2016 Tom Callaway  - 0.04-3
 - add BR: perl-generators (deps are overrated)
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime-Calendar-Julian.git/commit/?h=master=5e5a8eac499f25f629d6a8c6e18a9241f1277d2d
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F25 Self Contained Change: IBus Emoji Typing

[Bastien Nocera]

- Original Message -
> On 07/11/16 20:25, Bastien Nocera-san wrote:
> >
> >
> > - Original Message -
> >> On 07/08/16 20:41, Bastien Nocera-san wrote:
> >>> I think that the emoji input method should be a separate input method, so
> >>> that most users would have the choice between inputting using the
> >>> keyboard
> >>> layout that matches their keyboard, and a separate input method for
> >>> emojis.
> >>
> >> I think the emoji typing does not depend on XKB but is used frequently and
> >> I
> >> don't think it should be separated.
> >
> > It is on every other platform I can think of.
> 
> I don't think so.
> I can see Emoji input on MS-IME in MS-Windows without switching engines in
> Japanese.
> I can see Emoji input on Mac without switching engines with
> Command-Control-Space key.
> I can see Emoji input on Xperia keyboard in Android without switching
> engines.

Fair enough. Where's the design work for this functionality?

> >>> The IBus XKB engine is not discoverable (it's not listed in GNOME's
> >>> Region
> >>> & Language settings) and the keyboard shortcut to input emojis is also
> >>> not
> >>> discoverable. Having a separate input method is likely the better way to
> >>> implement this.
> >>
> >> I replied this.
> >
> > You haven't. You're implementing this without any regards for prior art and
> > design work that's been done. You certainly can implement this internally
> > however you want, but the end result has to match certain expectations, and
> > designs. Your implementation won't, and as a result won't be discoverable.
> >
> 
> What do you mean in the certain expectations and designs.
> As I explained, a radio button would be a idea to resolve your disacoverable
> way because I think you mean the GUI access.

A radio button somewhere in ibus doesn't make it discoverable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1383051] perl-PDL-2.017 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-PDL-2.17.0-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2016-10-11 10:08:53



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

Announcing the release of Fedora 25 Beta

[Mohan Boddu]

The Fedora Project is pleased to announce the immediate availability of
Fedora 25 Beta, the next big step on our journey to the exciting Fedora
25 release in November.

Fedora's journey is not simply about updating one operating system with
the latest and greatest packages. It's also about innovation for the
many different platforms represented in the Fedora Project:
Workstation, Server, Atomic, and the various Spins. Coordinating the
efforts across the many working groups is no small task, and serves as
a testament to the talent and professionalism found within the Fedora
community.


Download the prerelease from our Get Fedora site:

* Get Fedora 25 Beta Workstation
  https://getfedora.org/en/workstation/prerelease/

* Get Fedora 25 Beta Server
  https://getfedora.org/en/server/prerelease/

Looking for Cloud edition? Check out the section on Fedora Atomic
below. Or, check out one of our popular variants:

* Get Fedora 25 Beta Spins
  https://spins.fedoraproject.org/prerelease

* Get Fedora 25 Beta Labs
  https://labs.fedoraproject.org/prerelease

* Get Fedora 25 Beta ARM
  https://arm.fedoraproject.org/prerelease


What's New?
===

As we move into this Beta phase of the Fedora 25 release cycle, what
can users expect?


Fedora-Wide Changes
===

Some of the changes that will be seen across all aspects of Fedora
include:

* Docker updated to version 1.12

* Support for weaker certificate authorities (i.e., 1024-bit) has
  been removed

* Node.js updated to version 6.x, providing a new and better version of
  the popular server-side JavaScript engine

* "Secondary architectures" now known as "alternate architectures"

* Rust: Fedora 25 brings the support for the Rust programming
  language. Rust is a system programming language which runs
  blazingly fast, and prevents almost all crashes, segfaults, and
  data races.

* Python: Alongside the "standard" Python versions included in
  Fedora 25 (3.5 and 2.7), Python programmers can now install Python
  3.4, 3.3, and 2.6 from the repositories to help them run test
  suites on multiple Python versions, as well as on PyPy, PyPy3, and
  Jython, which were already there.


Fedora Workstation
==

The Workstation edition of Fedora 25 Beta is going to show off its
stuff, too:

* GNOME 3.22: Fedora 25 includes GNOME 3.22 in its pre-release and in
  the Final version, coming soon. Helpful new features include multiple
  file renaming, a redesigned keyboard settings tool, and many other UI
  improvements across the environment. For full details, refer to the
  GNOME 3.22 release notes. https://help.gnome.org/misc/release-notes/3.22/

* New Fedora media writer: The new Fedora Media Writer is a tool that
  downloads the latest stable Fedora for you. It then helps you write it
  to media such as a USB stick, so you can take Fedora for a spin on your
  system. If you like what you see, you can install to your system from
  the live environment. The Fedora Media Writer is available for Windows,
  Mac OS, and Linux.

* Wayland has been under development for several years. While like most
  software it still has some bugs, we believe it's ready to serve as a
  default that works for many users. Users can still select the old X11
  system if necessary to avoid a problem that affects them.

* Improved Flatpak support in the Software tool: The Software tool
  has the ability to install, update, and remove Flatpak software where a
  Fedora system is configured to point to a repo that offers it.

* GNOME Shell extensions are no longer checked for compatibility with
  the current version of the Shell. This was originally required because
  the GNOME interfaces were changing rapidly during the early days of
  GNOME 3. Now these interfaces have stabilized, and extensions can
  generally be expected to work with new releases. Any problems with an
  extension should be reported to the author through the homepage, as
  listed on the Extensions site.


Fedora Server
=

Fedora 25 Server is also going to see some interesting changes in this
cycle, particularly in the Cockpit tool:

* SELinux Troubleshooter module: Cockpit now has a SELinux
  Troubleshooter module similar to Fedora Workstation.

  If a system encounters an SELinux denial, it will display information
  about the issue as well as suggestions for correcting the issue if it
  was unexpected. Without the module, an administrator has to notice a
  denial occurred, dig through log files for the denial, and search for
  workarounds. The SELinux Troubleshooter presents information clearly
  and to the point all from the convenience of Cockpit.

* Displays host SSH keys in the system dashboard: Easy to see and
  understand what SSH keys are added to the system for connecting to the
  machine.

* Includes support for network teaming, Docker volume, and storage
  management, as well as the creation of systemd timer units

* Supports multi-step (including two-factor) authentication

jplesnik pushed to perl-PDL (master). "2.017 bump"

[notifications]

From 38f6a7e89d5138110cee3847d24aad49bce5e9a1 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 11 Oct 2016 15:58:48 +0200
Subject: 2.017 bump

---
 .gitignore |  1 +
 PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch | 12 
 PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch  |  4 ++--
 perl-PDL.spec  | 10 --
 sources|  2 +-
 5 files changed, 24 insertions(+), 5 deletions(-)
 create mode 100644 PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch

diff --git a/.gitignore b/.gitignore
index ea6fbf7..e2adc74 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ PDL-2.4.6.tar.gz
 /PDL-2.014.tar.gz
 /PDL-2.015.tar.gz
 /PDL-2.016.tar.gz
+/PDL-2.017.tar.gz
diff --git a/PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch 
b/PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch
new file mode 100644
index 000..9608f17
--- /dev/null
+++ b/PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch
@@ -0,0 +1,12 @@
+diff -up PDL-2.017/Basic/Core/Makefile.PL.orig PDL-2.017/Basic/Core/Makefile.PL
+--- PDL-2.017/Basic/Core/Makefile.PL.orig  2016-10-11 15:16:14.037949668 
+0200
 PDL-2.017/Basic/Core/Makefile.PL   2016-10-11 15:16:29.306874952 +0200
+@@ -206,7 +206,7 @@ pdlapi.c :: pdl.h pdlcore.h\n"
+ pdlmagic.c :: pdlcore.h\n"
+ ."
+ 
+-pdlsections.c :: pdl.h pdlcore.h\n"
++pdlsections.c :: pdl.h pdlcore.h pdlsimple.h\n"
+ ."
+ 
+ pdlconv.c:: pdlconv.c.PL Types.pm\n"
diff --git a/PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch 
b/PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch
index 2b389d4..58e7c3a 100644
--- a/PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch
+++ b/PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch
@@ -19,7 +19,7 @@ Signed-off-by: Petr Písař 
 diff -up PDL-2.008/Lib/Minuit/Makefile.PL.orig PDL-2.008/Lib/Minuit/Makefile.PL
 --- PDL-2.008/Lib/Minuit/Makefile.PL.orig  2015-05-25 10:40:25.504280235 
+0200
 +++ PDL-2.008/Lib/Minuit/Makefile.PL   2015-05-25 10:41:31.262090495 +0200
-@@ -135,13 +135,12 @@ undef ::postamble; # suppress warning
+@@ -136,13 +136,12 @@ undef ::postamble; # suppress warning
  my $mycompiler = $f77->compiler();
  my $mycflags   = $f77->cflags();
my $orig = pdlpp_postamble_int(@pack);
@@ -37,7 +37,7 @@ diff -up PDL-2.008/Lib/Minuit/Makefile.PL.orig 
PDL-2.008/Lib/Minuit/Makefile.PL
 diff -up PDL-2.008/Lib/Slatec/Makefile.PL.orig PDL-2.008/Lib/Slatec/Makefile.PL
 --- PDL-2.008/Lib/Slatec/Makefile.PL.orig  2015-05-25 10:41:48.991308954 
+0200
 +++ PDL-2.008/Lib/Slatec/Makefile.PL   2015-05-25 10:42:20.934702247 +0200
-@@ -125,13 +125,12 @@ undef ::postamble; # suppress warning
+@@ -126,13 +126,12 @@ undef ::postamble; # suppress warning
  my $mycompiler = $f77->compiler();
  my $mycflags   = $f77->cflags();
my $orig = pdlpp_postamble_int(@pack);
diff --git a/perl-PDL.spec b/perl-PDL.spec
index 75e39ab..7667dc3 100644
--- a/perl-PDL.spec
+++ b/perl-PDL.spec
@@ -9,8 +9,8 @@
 %endif
 
 Name:   perl-PDL
-%global cpan_version 2.016
-Version:2.16.0
+%global cpan_version 2.017
+Version:2.17.0
 Release:1%{?dist}
 Summary:The Perl Data Language
 Group:  Development/Libraries
@@ -26,6 +26,7 @@ Patch2: PDL-2.4.10-Disable-PDL-GIS-Proj.patch
 Patch3: PDL-2.6.0.90-Compile-Slatec-code-as-PIC.patch
 # Disable Slatec code crashing on PPC64, bug #1041304
 Patch4: PDL-2.14.0-Disable-PDL-Slatec.patch
+Patch5: PDL-2.17.0-Update-additional-deps-for-Basic-Core.patch
 BuildRequires:  coreutils
 BuildRequires:  fftw2-devel
 BuildRequires:  findutils
@@ -94,6 +95,7 @@ BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(SelfLoader)
 BuildRequires:  perl(Symbol)
 BuildRequires:  perl(Text::Balanced) >= 1.89
+BuildRequires:  perl(version)
 # Tests:
 BuildRequires:  perl(Benchmark)
 BuildRequires:  perl(ExtUtils::testlib)
@@ -174,6 +176,7 @@ such commercial packages as IDL and MatLab.
 %if %{without slatec}
 %patch4 -p1 -b .slatec
 %endif
+%patch5 -p1
 # Fix shellbang
 sed -e 's,^#!/usr/bin/env perl,%(perl -MConfig -e 'print 
$Config{startperl}'),' -i Perldl2/pdl2
 
@@ -212,6 +215,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Oct 10 2016 Jitka Plesnikova  - 2.17.0-1
+- 2.017 bump
+
 * Mon Jun 06 2016 Jitka Plesnikova  - 2.16.0-1
 - 2.016 bump
 
diff --git a/sources b/sources
index 2c99d4d..a0bc630 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ffb55fe4520354b3cf77b01ab6416dd4  PDL-2.016.tar.gz
+9966447f0afd61625e3ea871f731adf1  PDL-2.017.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-PDL.git/commit/?h=master=38f6a7e89d5138110cee3847d24aad49bce5e9a1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To 

spot pushed to perl-DateTime-Calendar-Julian (f23). "import"

[notifications]

From db6f470261e83713db0364f735791d6674cb5718 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Tue, 11 Oct 2016 09:51:06 -0400
Subject: import

---
 .gitignore |  1 +
 perl-DateTime-Calendar-Julian.spec | 49 ++
 sources|  1 +
 3 files changed, 51 insertions(+)
 create mode 100644 perl-DateTime-Calendar-Julian.spec

diff --git a/.gitignore b/.gitignore
index e69de29..8355315 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Calendar-Julian-0.04.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
new file mode 100644
index 000..7729e9b
--- /dev/null
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -0,0 +1,49 @@
+Name:  perl-DateTime-Calendar-Julian
+Version:   0.04
+Release:   3%{?dist}
+License:   GPL+ or Artistic 
+Group: Development/Libraries
+Summary:   Julian Calendar support for DateTime.pm 
+Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
+Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl-generators
+BuildRequires: perl(DateTime) >= 0.15
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More) perl(Test::Harness)
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+DateTime object in the Julian calendar.
+
+%prep
+%setup -q -n DateTime-Calendar-Julian-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc README Changes
+%{perl_vendorlib}/DateTime/
+%{_mandir}/man3/DateTime::Calendar::Julian.3pm*
+
+%changelog
+* Mon Oct 10 2016 Tom Callaway  - 0.04-3
+- add BR: perl-generators (deps are overrated)
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-2
+- do not nuke buildroot at the beginning of install. This is not 2005.
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-1
+- initial package
diff --git a/sources b/sources
index e69de29..52c19d4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+de688324eb33a27449ac2a5bfe1453a0  DateTime-Calendar-Julian-0.04.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime-Calendar-Julian.git/commit/?h=f23=db6f470261e83713db0364f735791d6674cb5718
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: iphone mount in nautilus on Fedora 24

[Bastien Nocera]

- Original Message -
> > - Original Message -
> > 
> > Yup. The "normal" mount contains nothing that normal users should access.
> > Accessing the photos will leave ghosts on the device, and there have been
> > no
> > ways to update the music database in Linux for a few iOS releases.
> 
> I very much doubt that anyone would release any code to touch an idevice
> music database due to fear of
> legal action from the manufacturer. It may exist already.
> 
> The ability to sync contacts, calendars and events, meeting info, notes,
> pictures etc ( anything that would be considered the personal data entered
> by the idevice owner is another matter entirely. Anything that the law
> provides in most countries such as the IP to that person or the copyright of
> documents or photos etc, and yes it can be a very grey area between the laws
> in different countries. This is just the other side of the coin but this
> time from the owners perspective and legal rights.

What Linux applications support syncing those contacts? Are you sure they 
actually
require the mounted filesystem?

> is
> > 
> > You can still access the device by editing the URL in the "Documents on..."
> > location. Just remove the ":3" at the end.
> 
> Thanks for this info,
> > 
> > If you have use cases that aren't the 2 mentioned above, or using your
> > iDevice
> > as a thumb drive, please file bugs against gvfs in the upstream GNOME
> > Bugzilla.
> > 
> > Cheers
> 
> 
> While I agree for the normal non developer user, the removal, to be able to
> access what you could originally access, on the idevice before the code
> change, may be of little value.
> 
> It is frustrating if you are developing applications and need access to these
> areas for debugging, checking directory, files and structure etc of the
> idevice.
> 
> It is even more frustrating when the Fedora workstation is being targetted as
> a developer's platform, and it also affects any downstream distribution
> developers in the same way.

How do you develop iOS applications on Linux? In any case, it's not a target
of Fedora Workstation. It could be, but it's not.

> While nautilus still exposes the pictures on an idevice through  gphoto2
> system does not seem to have changed.

I can't parse that.

> As far as I am aware it is possible to copy pictures from the idevice but
> transfers of pictures to the idevice will succeed, but will not be shown on
> the idevice by native apps without further hacking.

So it doesn't work. Sure you could use, and you can still use, the partition
as storage. But I don't see the point in doing that.

> The other mount exposes the so called document folder of some user installed
> apps on the idevice and may be useful for someone developing

It's useful for adding files to applications, for example, music, photos, or
documents in most 3rd-party applications.

> but is off
> limited use to a normal non developer user, unless the normal non developer
> wants to use the phone as a usb drive to transport files without carrying an
> extra usb drive.
> 
> The removal of the nautilus properties page on an connected idevice does have
> an effect that a nautilus-ideviceinfo extension that has been in gnome git
> for many years cannot be easily exposed and used and a gnome bugzilla entry
> has been active from last year without even a comment to date.

That's unrelated.

> https://bugzilla.gnome.org/show_bug.cgi?id=741302
> 
> https://git.gnome.org/browse/nautilus-ideviceinfo/log/?ofs=100
> 
> http://blog.sukimashita.com/2015/01/09/gtk-3-support-for-nautilus-ideviceinfo/
> 
> I hope this can  be resolved in the short term as it provides all users of
> idevices with info that is expected today and further benefits
> the foss community and the goals of Fedora, Gnome and downstream
> distributions etc.

Showing all the possible partitions doesn't help anyone, that I can see. Explain
how the data on that partition is useful to the large majority of iOS/Linux 
users,
and we can investigate.

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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Matthew Miller]

On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote:
> very low. Just for an information: on Fedora we have every week
> created approx. 400 - 500 new bugs. I can not imagine doing review of
> such an amount of bugs on (bi-)weekly basic. Blocker bug meeting

Oh my no. We wouldn't review all bugs, just ones which are nominated,
and I am envisioning being quite strict with whether they meet the
criterion I suggested:

   Issues eligible for this status would be those which do not
   necessarily fail a release criterion but which have critical impact
   on a Fedora Edition or on a council-approved Fedora Objective.

with a possible additional:

  Issues may also be nominated from the Common Bugs list when they are
  deemed by QA to have critical impact.

or something like that. If it becomes necessary, we could even restrict
nominations to those submitted by QA, the Edition WGs, or Objective
leads — but I'd rather start less formal and introduce that rule if it
becomes a problem.


-- 
Matthew Miller

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

spot pushed to perl-DateTime-Calendar-Julian (f25). "import"

[notifications]

From db6f470261e83713db0364f735791d6674cb5718 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Tue, 11 Oct 2016 09:51:06 -0400
Subject: import

---
 .gitignore |  1 +
 perl-DateTime-Calendar-Julian.spec | 49 ++
 sources|  1 +
 3 files changed, 51 insertions(+)
 create mode 100644 perl-DateTime-Calendar-Julian.spec

diff --git a/.gitignore b/.gitignore
index e69de29..8355315 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Calendar-Julian-0.04.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
new file mode 100644
index 000..7729e9b
--- /dev/null
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -0,0 +1,49 @@
+Name:  perl-DateTime-Calendar-Julian
+Version:   0.04
+Release:   3%{?dist}
+License:   GPL+ or Artistic 
+Group: Development/Libraries
+Summary:   Julian Calendar support for DateTime.pm 
+Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
+Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl-generators
+BuildRequires: perl(DateTime) >= 0.15
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More) perl(Test::Harness)
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+DateTime object in the Julian calendar.
+
+%prep
+%setup -q -n DateTime-Calendar-Julian-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc README Changes
+%{perl_vendorlib}/DateTime/
+%{_mandir}/man3/DateTime::Calendar::Julian.3pm*
+
+%changelog
+* Mon Oct 10 2016 Tom Callaway  - 0.04-3
+- add BR: perl-generators (deps are overrated)
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-2
+- do not nuke buildroot at the beginning of install. This is not 2005.
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-1
+- initial package
diff --git a/sources b/sources
index e69de29..52c19d4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+de688324eb33a27449ac2a5bfe1453a0  DateTime-Calendar-Julian-0.04.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime-Calendar-Julian.git/commit/?h=f25=db6f470261e83713db0364f735791d6674cb5718
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

spot pushed to perl-DateTime-Calendar-Julian (f24). "import"

[notifications]

From db6f470261e83713db0364f735791d6674cb5718 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Tue, 11 Oct 2016 09:51:06 -0400
Subject: import

---
 .gitignore |  1 +
 perl-DateTime-Calendar-Julian.spec | 49 ++
 sources|  1 +
 3 files changed, 51 insertions(+)
 create mode 100644 perl-DateTime-Calendar-Julian.spec

diff --git a/.gitignore b/.gitignore
index e69de29..8355315 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Calendar-Julian-0.04.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
new file mode 100644
index 000..7729e9b
--- /dev/null
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -0,0 +1,49 @@
+Name:  perl-DateTime-Calendar-Julian
+Version:   0.04
+Release:   3%{?dist}
+License:   GPL+ or Artistic 
+Group: Development/Libraries
+Summary:   Julian Calendar support for DateTime.pm 
+Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
+Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl-generators
+BuildRequires: perl(DateTime) >= 0.15
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More) perl(Test::Harness)
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+DateTime object in the Julian calendar.
+
+%prep
+%setup -q -n DateTime-Calendar-Julian-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc README Changes
+%{perl_vendorlib}/DateTime/
+%{_mandir}/man3/DateTime::Calendar::Julian.3pm*
+
+%changelog
+* Mon Oct 10 2016 Tom Callaway  - 0.04-3
+- add BR: perl-generators (deps are overrated)
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-2
+- do not nuke buildroot at the beginning of install. This is not 2005.
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-1
+- initial package
diff --git a/sources b/sources
index e69de29..52c19d4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+de688324eb33a27449ac2a5bfe1453a0  DateTime-Calendar-Julian-0.04.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime-Calendar-Julian.git/commit/?h=f24=db6f470261e83713db0364f735791d6674cb5718
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

spot pushed to perl-DateTime-Calendar-Julian (master). "import"

[notifications]

From db6f470261e83713db0364f735791d6674cb5718 Mon Sep 17 00:00:00 2001
From: Tom Callaway 
Date: Tue, 11 Oct 2016 09:51:06 -0400
Subject: import

---
 .gitignore |  1 +
 perl-DateTime-Calendar-Julian.spec | 49 ++
 sources|  1 +
 3 files changed, 51 insertions(+)
 create mode 100644 perl-DateTime-Calendar-Julian.spec

diff --git a/.gitignore b/.gitignore
index e69de29..8355315 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Calendar-Julian-0.04.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
new file mode 100644
index 000..7729e9b
--- /dev/null
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -0,0 +1,49 @@
+Name:  perl-DateTime-Calendar-Julian
+Version:   0.04
+Release:   3%{?dist}
+License:   GPL+ or Artistic 
+Group: Development/Libraries
+Summary:   Julian Calendar support for DateTime.pm 
+Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
+Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl-generators
+BuildRequires: perl(DateTime) >= 0.15
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More) perl(Test::Harness)
+Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+%description
+DateTime object in the Julian calendar.
+
+%prep
+%setup -q -n DateTime-Calendar-Julian-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2>/dev/null
+%{_fixperms} %{buildroot}
+
+%check
+make test
+
+%files
+%license LICENSE
+%doc README Changes
+%{perl_vendorlib}/DateTime/
+%{_mandir}/man3/DateTime::Calendar::Julian.3pm*
+
+%changelog
+* Mon Oct 10 2016 Tom Callaway  - 0.04-3
+- add BR: perl-generators (deps are overrated)
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-2
+- do not nuke buildroot at the beginning of install. This is not 2005.
+
+* Mon Oct 10 2016 Tom Callaway  - 0.04-1
+- initial package
diff --git a/sources b/sources
index e69de29..52c19d4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+de688324eb33a27449ac2a5bfe1453a0  DateTime-Calendar-Julian-0.04.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-DateTime-Calendar-Julian.git/commit/?h=master=db6f470261e83713db0364f735791d6674cb5718
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-Alien-ROOT

[buildsys]

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

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

Broken dependencies: perl-Data-Alias

[buildsys]

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

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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Remi Collet]

mongo-c-driver 1.3.5 (current version in rawhide) is not compatible.


mongo-c-driver 1.4+ is

But pecl/mongodb 1.2.0 is not yet released (alpha3) and will require
both libbson 1.5.0 and mongo-c-driver 1.5.0 (only RC for now)

So, stalled for now.


Remi.


P.S.1: v1.4 drop a private lib, only used by the PHP ext.,
so is really something I'm waiting for.

P.S.2: https://jira.mongodb.org/browse/CDRIVER-1066
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] openbabel-2.4 update (ABI bump)

[Dominik 'Rathann' Mierzejewski]

Hello,
I've just pushed (not built yet) openbabel-2.4.1 in rawhide. I rebuilt
all the affected packages locally to ensure there are no issues.
The only thing failing is xdrawchem, which I maintain and that's
not due to openbabel update anyway.

Affected packages which I'll be rebuilding later today, after openbabel:
IQmol
avogadro
ghemical
gnome-chemistry-utils
kalzium
xdrawchem

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Vít Ondruch]

Dne 11.10.2016 v 12:57 Petr Viktorin napsal(a):
>
> The alternative to packaging those Pythons in Fedora is putting them
> in some COPR. I believe this would send a bad message. If we want to
> make Fedora friendly for Python developers, we should make
> cross-version testing officially supported, and as easy as possible.
> "Bring your own Python from somewhere" does not give Fedora any
> advantage over any other OS.

But this goes back to mttdm's "rings" proposal IMO. Yes, provide these
packages somewhere, but not in the main repositories.

I can't see nothing wrong suggesting "dnf copr enable
pythondevel/pythons" to make tox work. And if you want to be fancy and
want to really start the ring proposal, the "copr" dnf plugin could be
forked into some "ring" plugin with some ring specific functionality
(whatever it is, e.g. "dnf ring enable pythondevel").


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

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

[Jan Kurik]

On Mon, Oct 10, 2016 at 11:09 PM, Matthew Miller
 wrote:
> On Wed, Oct 05, 2016 at 02:33:37PM -0700, Adam Williamson wrote:
>> We used to have exactly this, up until Fedora 14. We had 'Target'
> [much snip]
>> lighter process than the blocker review process, though I don't have a
>> specific proposal for how that could look at this point in time. If it
>> would mainly be used by the FPL and FPM, perhaps it could simply be the
>> rule that they got to decide what bugs went on it?
>
> *nod*
>
> Based on your other message elsewhere in the thread, I promise not to
> pull you or anyone else in QA under the bus, but I mght drag Jan
> Kurik with me as FPGM. Jan, what do you think about doing a Lightweight
> Critical Issues Review Meeting every, say, two weeks? We could start it
> with you and me and anyone else who wants to show up, and give it a
> hard limit of half an hour.

Well, I did not jump into this discussion as I do not have a clear
point of view on this topic. On one hand I see the benefit of having a
list of prioritized bugs. On the other hand there were already such
activities in the past (like the Target trackers described by Adam, or
BugZappers with their Triage meetings) which disappeared over the time
as ratio of the benefit to effort needed to maintain such a list was
very low. Just for an information: on Fedora we have every week
created approx. 400 - 500 new bugs. I can not imagine doing review of
such an amount of bugs on (bi-)weekly basic. Blocker bug meeting
typically takes 2-3 hours every week and the amount of proposed
blockers is typically less than 10. Even on the Blocker bug meetings I
see the need to check/consult an issue with a representative of a
WG/SIG or a maintainer to fully understand what is really going on in
the bug. With the amount of bugs Fedora receives I can not imagine
doing the review without representatives from WGs and SIGs, just
because of expertise needed to make a qualify decision. As such, the
cost to have such a list of prioritized bugs is quite high and the
benefit is questionable due to lack of enforcement.

[1] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

Regards,
Jan

> Adam, if we do that, would it be hard to add to the existing
> blockerbugs app, so we don't need to stand up new infrastructure?
>
> Then we could try it for a bit and see if it is working / helpful or
> just another crazy idea.
>
> --
> Matthew Miller
> 
> Fedora Project Leader



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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch  wrote:
> Just FTR, I opened Ruby upstream ticket asking about the OpenSSL 1.1.0
> support:
>
> https://bugs.ruby-lang.org/issues/12830
>
> Not sure if you'll have also some Fedora specific tracker 
Would be nice to get tracking bug created on RHBZ, so we can track all
the packages.
>
>
> Vít
>
>
>
>
> Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
>> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
>>> Tomas Mraz wrote:
 At worst if the patching of a package is highly non-trivial and the
 upstream is not responsive we might have to drop the package from
 Fedora.

 We do not want to keep 1.0.2 devel around as that could make it to
 look
 like the 1.0.2 is still fully "supported" in Fedora and there would
 be
 no incentive to switch to 1.1.0. Also to get any new features from
 upstream OpenSSL we have to move to newer versions as they are
 released
 as the old versions get only bug fixes.
>>> IMHO, this is not acceptable. If the API of a library changes enough
>>> to
>>> warrant a compat package, you have to provide the -devel for the
>>> compat
>>> package as well. Dropping all the packages that don't build against
>>> the new
>>> incompatible version from Fedora is not a reasonable plan.
>> We will work on porting the dependent packages to the new API. If by
>> some reasonable deadline there are still some packages that are not
>> dead by other reasons and we are unable to port them we can add -devel
>> to the compat package. Note though that small changes in such packages
>> will be needed anyway as the include files of the compat package will
>> have to be in non-default include directory. (If the package doesn't
>> use pkgconfig to find the needed CFLAGS automatically.)
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: "Could not retire package"

[Bastien Nocera]

- Original Message -
> On Thursday, September 15, 2016 12:20:57 PM CDT Bastien Nocera wrote:
> > - Original Message -
> > 
> > > On Thursday, September 15, 2016 11:51:47 AM CDT Bastien Nocera wrote:
> > > > Could not retire package: You are not allowed to retire the package:
> > > > rpms/obexd on branch f24.
> > > > 
> > > > obexd has been integrated in bluez since version 5.something, which
> > > > happened at least 5 Fedora releases ago.
> > > > 
> > > > My guess is that the "critpath" status of the package is stopping that.
> > > > 
> > > > Cheers
> > > 
> > > you can not retire packages from stable Fedora releases,  because we have
> > > no way to remove it from already shipped pieces
> > 
> > Do you know where does the message come from, so that I can file a bug for
> > the message to actually say that?
> 
> I belive it is pkgdb that returns the message. however fedpkg may need some
> loginc to interprit the message

Filed as https://github.com/fedora-infra/pkgdb2/issues/400
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Vít Ondruch]

Just FTR, I opened Ruby upstream ticket asking about the OpenSSL 1.1.0
support:

https://bugs.ruby-lang.org/issues/12830

Not sure if you'll have also some Fedora specific tracker 


Vít




Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
>> Tomas Mraz wrote:
>>> At worst if the patching of a package is highly non-trivial and the
>>> upstream is not responsive we might have to drop the package from
>>> Fedora.
>>>
>>> We do not want to keep 1.0.2 devel around as that could make it to
>>> look
>>> like the 1.0.2 is still fully "supported" in Fedora and there would
>>> be
>>> no incentive to switch to 1.1.0. Also to get any new features from
>>> upstream OpenSSL we have to move to newer versions as they are
>>> released
>>> as the old versions get only bug fixes.
>> IMHO, this is not acceptable. If the API of a library changes enough
>> to 
>> warrant a compat package, you have to provide the -devel for the
>> compat 
>> package as well. Dropping all the packages that don't build against
>> the new 
>> incompatible version from Fedora is not a reasonable plan.
> We will work on porting the dependent packages to the new API. If by
> some reasonable deadline there are still some packages that are not
> dead by other reasons and we are unable to port them we can add -devel
> to the compat package. Note though that small changes in such packages
> will be needed anyway as the include files of the compat package will
> have to be in non-default include directory. (If the package doesn't
> use pkgconfig to find the needed CFLAGS automatically.)
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Self Contained Change: PHP 7.1

[Jan Kurik]

= Proposed Self Contained Change: PHP 7.1 =
https://fedoraproject.org/wiki/Changes/php71

Change owner(s):
* Remi Collet 


Update the PHP stack in Fedora to latest version 7.1.x


== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.1.x.
* PHP 7.1.0RC3 was released Sep 29th
* PHP 7.1.0 is planed for end of year.

Compatibility for PHP code is very good. PHP 7.1 is the first
compatible version with OpenSSL 1.1.


== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing.

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

* Release engineering: needed mass rebuild (C extensions) done by change owner.

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

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

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

F26 Self Contained Change: PHP 7.1

[Jan Kurik]

= Proposed Self Contained Change: PHP 7.1 =
https://fedoraproject.org/wiki/Changes/php71

Change owner(s):
* Remi Collet 


Update the PHP stack in Fedora to latest version 7.1.x


== Detailed Description ==
Update the PHP stack in Fedora to latest version 7.1.x.
* PHP 7.1.0RC3 was released Sep 29th
* PHP 7.1.0 is planed for end of year.

Compatibility for PHP code is very good. PHP 7.1 is the first
compatible version with OpenSSL 1.1.


== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing.

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

* Release engineering: needed mass rebuild (C extensions) done by change owner.

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

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

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

puiterwijk changed spot's 'approveacls' permission on perl-DateTime-Calendar-Julian (f23) to 'Approved'

[notifications]

puiterwijk changed spot's 'approveacls' permission on 
perl-DateTime-Calendar-Julian (f23) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in f23 from Awaiting Review to Approved

[notifications]

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in 
f23 from Awaiting Review to Approved

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchbugzilla' permission on perl-DateTime-Calendar-Julian (f23) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchbugzilla' permission on 
perl-DateTime-Calendar-Julian (f23) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchcommits' permission on perl-DateTime-Calendar-Julian (f23) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchcommits' permission on 
perl-DateTime-Calendar-Julian (f23) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk created the branch 'f23' for the package 'perl-DateTime-Calendar-Julian'

[notifications]

puiterwijk created the branch 'f23' for the package 
'perl-DateTime-Calendar-Julian'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchcommits' permission on perl-DateTime-Calendar-Julian (f24) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchcommits' permission on 
perl-DateTime-Calendar-Julian (f24) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'approveacls' permission on perl-DateTime-Calendar-Julian (f24) to 'Approved'

[notifications]

puiterwijk changed spot's 'approveacls' permission on 
perl-DateTime-Calendar-Julian (f24) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in f24 from Awaiting Review to Approved

[notifications]

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in 
f24 from Awaiting Review to Approved

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian (f23) to 'Approved'

[notifications]

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian 
(f23) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk created the branch 'f24' for the package 'perl-DateTime-Calendar-Julian'

[notifications]

puiterwijk created the branch 'f24' for the package 
'perl-DateTime-Calendar-Julian'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchbugzilla' permission on perl-DateTime-Calendar-Julian (f24) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchbugzilla' permission on 
perl-DateTime-Calendar-Julian (f24) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian (f24) to 'Approved'

[notifications]

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian 
(f24) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'approveacls' permission on perl-DateTime-Calendar-Julian (f25) to 'Approved'

[notifications]

puiterwijk changed spot's 'approveacls' permission on 
perl-DateTime-Calendar-Julian (f25) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk created the branch 'f25' for the package 'perl-DateTime-Calendar-Julian'

[notifications]

puiterwijk created the branch 'f25' for the package 
'perl-DateTime-Calendar-Julian'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchbugzilla' permission on perl-DateTime-Calendar-Julian (f25) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchbugzilla' permission on 
perl-DateTime-Calendar-Julian (f25) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in f25 from Awaiting Review to Approved

[notifications]

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in 
f25 from Awaiting Review to Approved

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian (f25) to 'Approved'

[notifications]

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian 
(f25) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchcommits' permission on perl-DateTime-Calendar-Julian (f25) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchcommits' permission on 
perl-DateTime-Calendar-Julian (f25) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed perl-sig's 'watchbugzilla' permission on perl-DateTime-Calendar-Julian (master) to 'Approved'

[notifications]

puiterwijk changed perl-sig's 'watchbugzilla' permission on 
perl-DateTime-Calendar-Julian (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in master from Awaiting Review to Approved

[notifications]

puiterwijk changed spot's package request for perl-DateTime-Calendar-Julian in 
master from Awaiting Review to Approved

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'approveacls' permission on perl-DateTime-Calendar-Julian (master) to 'Approved'

[notifications]

puiterwijk changed spot's 'approveacls' permission on 
perl-DateTime-Calendar-Julian (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed perl-sig's 'watchcommits' permission on perl-DateTime-Calendar-Julian (master) to 'Approved'

[notifications]

puiterwijk changed perl-sig's 'watchcommits' permission on 
perl-DateTime-Calendar-Julian (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian (master) to 'Approved'

[notifications]

puiterwijk changed spot's 'commit' permission on perl-DateTime-Calendar-Julian 
(master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

puiterwijk changed spot's 'watchcommits' permission on perl-DateTime-Calendar-Julian (master) to 'Approved'

[notifications]

puiterwijk changed spot's 'watchcommits' permission on 
perl-DateTime-Calendar-Julian (master) to 'Approved'

https://admin.fedoraproject.org/pkgdb/package/perl-DateTime-Calendar-Julian/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org