[Bug 1611022] perl-App-cpm-0.978 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KHK3JGGBSAKM2UVB6UFOTD5GIU7HIR7N/

Schedule for Thursday's FPC Meeting (2018-08-02 16:00 UTC)

[James Antill]

  Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-08-02 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.


  Local time information (via. uitime):

= Day: Thursday ==
2018-08-02 09:00 PDT  US/Pacific
2018-08-02 12:00 EDT  --> US/Eastern <--
2018-08-02 16:00 UTC  UTC   
2018-08-02 17:00 BST  Europe/London 
2018-08-02 18:00 CEST Europe/Berlin 
2018-08-02 18:00 CEST Europe/Paris  
2018-08-02 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-08-03 00:00 HKT  Asia/Hong_Kong
2018-08-03 00:00 +08  Asia/Singapore
2018-08-03 01:00 JST  Asia/Tokyo
2018-08-03 02:00 AEST Australia/Brisbane


  Links to all tickets below can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting


= Followups =

#topic #665 SSLCertificateHandling policy update
.fpc 665
https://pagure.io/packaging-committee/issue/665

#topic #667 Recommend use of systemd sandboxing directives
.fpc 667
https://pagure.io/packaging-committee/issue/667

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #703 Inconsistency between "General Naming" and "Case Sensitivity"
.fpc 703
https://pagure.io/packaging-committee/issue/703

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #719 Simplify packaging of forge-hosted projects
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #726 Review for SELinux Independent Policy packaging Draft
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #740 Add "%python_enable_dependency_generator" onto Python
.fpc 740
https://pagure.io/packaging-committee/issue/740

#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc 743
https://pagure.io/packaging-committee/issue/743

#topic #775 Allow to have %{?suse_version} condition in spec file
.fpc 775
https://pagure.io/packaging-committee/issue/775

#topic #782 Forbid %{pythonX_site(lib|arch)}/* in %files 
.fpc 782
https://pagure.io/packaging-committee/issue/782

#topic #784 forbid globs for shared libraries as it conceals sonames
.fpc 784
https://pagure.io/packaging-committee/issue/784

= Open Floor =

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

https://pagure.io/packaging-committee/issues?status=Open=meeting

  If you would like to add something to this agenda, you can:
   * Reply to this e-mail
   * File a new ticket at: https://pagure.io/packaging-committee
   * E-mail me directly
   * Bring it up at the end of the meeting, during the open floor topic.
 Note that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6LPDSZ7ANLUPD67QVYIVGZRONIV5G4LB/

[389-devel] 389 DS nightly 2018-08-02 - 90% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/08/02/report-389-ds-base-1.4.0.13-20180801gitb14c836.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/RXMU2KFUGIQXVBOEGQREXPHJPEDWJFRQ/

[Bug 1611024] New: perl-DateTime-1.50 is available

[bugzilla]

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

Bug ID: 1611024
   Summary: perl-DateTime-1.50 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org,
trem...@tremble.org.uk



Latest upstream release: 1.50
Current version/release in rawhide: 1.49-3.fc29
URL: http://search.cpan.org/dist/DateTime/

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

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/WIYPYP7HNV6BP3HK2JCUMNP23ZA3LOOF/

[Bug 1611022] New: perl-App-cpm-0.978 is available

[bugzilla]

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

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



Latest upstream release: 0.978
Current version/release in rawhide: 0.977-1.fc29
URL: http://search.cpan.org/dist/App-cpm/

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

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/OFYBLWH6KF6UMKSCMDNHHSHS6QR7HTGG/

Re: binutils 2.31.1-4.fc29 - 2.31.1-7.fc29 produces broken ELF binaries

[Florian Weimer]

On 07/31/2018 12:18 PM, Florian Weimer wrote:
I'm attaching a list of affected packages in the Fedora rawhide 
buildroot, as of 2018-07-31 10:00.  This is based on ELF files which 
have a .gnu.build.attributes section (which is not allocated) between 
two allocated sections.  (The rawhide compose lags behind and has a 
different set of affected packages.)  Some of the affected packages are 
being rebuild, and I will schedule builds for the remaining ones.


I finished most of the rebuilds yesterday.  There were a few late 
rebuilds today because they were for Go packages on aarch64 and ppc64le, 
where apparently external linking (binutils ld) is used in more cases 
(or all the time).


I don't think the broken builds ever made it into a rawhide compose, but 
if they ever do, there might be a further delay until that is resolved.


Sorry about this mess and thanks for your patience,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PKJLVTJ7ZQ6DWYXFZJPM7TPDD7Z2OTHP/

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Carlos O'Donell]

On 07/27/2018 06:43 AM, Florian Weimer wrote:
> On 07/26/2018 06:03 PM, Jason L Tibbitts III wrote:
>>> "FW" == Florian Weimer  writes:
>> 
>> FW> I would like to request a change of the Packaging Guidelines, 
>> FW> advising packagers not to interpose malloc.
>> 
>> How strong of a restriction are you looking for?  This sort of
>> feels like something which would at the strongest be a "SHOULD NOT"
>> but maybe you're looking for an absolute ban.
> 
> An absolute ban strikes me as overly broad.  However, especially for
> shared objects (such as libruby), the implications should be clear:
> it is easy to LD_PRELOAD a different malloc, but if the library is
> linked against glibc malloc, jemalloc, and then you want to preload
> tcmalloc because it helps with your workload, you might run into
> problems (and if it's just excessive use of TLS data, most of it
> unused).

Agreed.

>> Some maintainers may find it difficult to comply with an absolute
>> ban if the relevant software doesn't make it easy to change the
>> allocator.
> 
> Sure, this is why I mentioned APR pools and Boehm GC—if the APIs a
> different, then we obviously can't require porting to system malloc.
> 
> If upstream bundles a custom malloc, especially one of the well-known
> ones separately packaged in Fedora, some work is required anyway
> because the bundled version cannot be installed in a system-wide
> location, and RPM provides for it must be suppressed.  (See the
> upstream varnish packages for an example of an accidental system-wide
> jemalloc installation.)

Right, if the relevant software doesn't make it easy to change the
allocator then that's OK, but what we ship must be made safe to ship.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV5XGF3HM3BPCEARZEYKNIG4OGIECXBO/

[389-devel] please review: PR 49876 - Add password policy functionality to CLI/UI

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49876
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/D3P6GQZAVN73WDC3OVJEZB4XV5URJ4PS/

Fedora Rawhide-20180801.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 66/138 (x86_64), 24/24 (i386), 1/2 (arm)

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

ID: 262444  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/262444
ID: 262488  Test: x86_64 AtomicWorkstation-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/262488
ID: 262494  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/262494
ID: 262505  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/262505
ID: 262510  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/262510
ID: 262516  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/262516
ID: 262559  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/262559
ID: 262577  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/262577

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

ID: 262415  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262415
ID: 262417  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262417
ID: 262428  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/262428
ID: 262429  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/262429
ID: 262436  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/262436
ID: 262438  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262438
ID: 262439  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/262439
ID: 262440  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262440
ID: 262442  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262442
ID: 262443  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262443
ID: 262453  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/262453
ID: 262455  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262455
ID: 262456  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/262456
ID: 262459  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/262459
ID: 262460  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/262460
ID: 262461  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/262461
ID: 262462  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/262462
ID: 262464  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/262464
ID: 262473  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/262473
ID: 262475  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/262475
ID: 262476  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/262476
ID: 262478  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/262478
ID: 262489  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/262489
ID: 262490  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/262490
ID: 262491  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/262491
ID: 262492  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/262492
ID: 262495  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/262495
ID: 262496  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/262496
ID: 262497  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/262497
ID: 262498  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/262498
ID: 262499  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/262499
ID: 262500  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/262500
ID: 262501  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/262501
ID: 

[Bug 1610977] New: [abrt] perl-XML-XPath: __libc_sigaction(): perl killed by SIGABRT

[bugzilla]

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

Bug ID: 1610977
   Summary: [abrt] perl-XML-XPath: __libc_sigaction(): perl killed
by SIGABRT
   Product: Fedora
   Version: 28
 Component: perl-XML-XPath
  Assignee: jples...@redhat.com
  Reporter: anth...@dedominic.pw
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, ka...@ucw.cz,
perl-devel@lists.fedoraproject.org



Description of problem:
how to reproduce:

#!/bin/sh
curl --silent --fail
"https://en.wiktionary.org/w/index.php?title=test=yes; \
| xpath -q -e \
'//div[@class = "mw-parser-output"]/*/span[@id = "Verb" or @id = "Noun" or
@id = "Adjective"]/ancestor::*/following-sibling::ol[1]/li'

Trying to parse wiktionary. messing with xpath just to experiment.
above seems to cause a problem. probably with how xpath buffers stdin?
when using a process substitution as an argument instead of stdin, it seems to
work correctly.

Version-Release number of selected component:
perl-XML-XPath-1.42-2.fc28

Additional info:
reporter:   libreport-2.9.5
backtrace_rating: 4
cmdline:/usr/bin/perl /usr/bin/xpath -q -e //div[@class =
"mw-parser-output"]/*/span[@id = "Verb" or @id = "Noun" or @id =
"Adjective"]/ancestor::*/following-sibling::ol[1]/li
crash_function: __libc_sigaction
executable: /usr/bin/perl
journald_cursor:
s=eed7f97804554ea880a518462e7c4cbb;i=8afd8;b=eba64ca943464449a349f01ba4ccb9e2;m=5335fb2d5;t=5726432a1d733;x=2ffc37276436acb9
kernel: 4.17.9-200.fc28.x86_64
rootdir:/
runlevel:   N 5
type:   CCpp
uid:1000

Truncated backtrace:
Thread no. 1 (1 frames)
 #0 __libc_sigaction at ../sysdeps/unix/sysv/linux/x86_64/sigaction.c: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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MXRGNTMSLJEBSUS2HKXKGPOYIV7AI4ZV/

Re: [fedora-arm] cmake segfault on 32-bit arches on Rawhide

[Adam Williamson]

On Wed, 2018-08-01 at 20:02 +0100, Peter Robinson wrote:
> On Thu, Jul 26, 2018 at 9:58 PM, Adam Williamson
>  wrote:
> > I just tried a rebuild of a package in Rawhide, it worked on most
> > arches, but failed on armv7hl and i686 (our only 32-bit arches). On
> > both arches, cmake seems to have segfaulted:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=28626511
> > https://kojipkgs.fedoraproject.org//work/tasks/6529/28626529/build.log
> > https://kojipkgs.fedoraproject.org//work/tasks/6531/28626531/build.log
> > 
> > + /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> > -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> > -DCMAKE_BUILD_TYPE=Release .
> > /var/tmp/rpm-tmp.0imLnb: line 47: 15870 Segmentation fault  (core
> > dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> > -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> > -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> > -DCMAKE_BUILD_TYPE=Release .
> > 
> > Just wanted to flag this up. I haven't yet tried doing the build in a
> > mock to try and get the core out, or anything like that.
> 
> Finally got a few cycles to look at this, looks like it's fixed, not
> sure what the issue/fix was but I suspect rdieter's new cmake major
> version or possibly something as a result of the binutils breakage
> fallout.

Sorry, yeah, I never followed up on list, but indeed Rex fixed it and
let me know on IRC.
-- 
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 Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TT7W5GFEJCYB7HF3P7J4DLJP4GIOKCQX/

Re: [fedora-arm] cmake segfault on 32-bit arches on Rawhide

[Peter Robinson]

On Thu, Jul 26, 2018 at 9:58 PM, Adam Williamson
 wrote:
> I just tried a rebuild of a package in Rawhide, it worked on most
> arches, but failed on armv7hl and i686 (our only 32-bit arches). On
> both arches, cmake seems to have segfaulted:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=28626511
> https://kojipkgs.fedoraproject.org//work/tasks/6529/28626529/build.log
> https://kojipkgs.fedoraproject.org//work/tasks/6531/28626531/build.log
>
> + /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> -DCMAKE_BUILD_TYPE=Release .
> /var/tmp/rpm-tmp.0imLnb: line 47: 15870 Segmentation fault  (core
> dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
> -DCMAKE_BUILD_TYPE=Release .
>
> Just wanted to flag this up. I haven't yet tried doing the build in a
> mock to try and get the core out, or anything like that.

Finally got a few cycles to look at this, looks like it's fixed, not
sure what the issue/fix was but I suspect rdieter's new cmake major
version or possibly something as a result of the binutils breakage
fallout.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NLPTACNLJSBIQMO27UOZK3EEN4TU5QDD/

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  52  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d801e05f92   
uwsgi-2.0.17.1-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aeb81e4fba   
libpng10-1.0.69-5.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a83d5ad82b   
redis-3.2.12-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b4f8d828cd   
perl-Parallel-ForkManager-1.20-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-68e2f541df   
pam_yubico-2.26-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4186e02757   
seamonkey-2.49.4-2.el6


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

configsnap-0.14-1.el6

Details about builds:



 configsnap-0.14-1.el6 (FEDORA-EPEL-2018-1fa6b61ca6)
 Record and compare system state

Update Information:

Update to 0.14

ChangeLog:

* Tue Jul 31 2018 Paolo Gigante  - 0.14-1
- Adjusted -w option to only overwrite specific tagged files
- Add option to compare existing files without gathering new data using the 
-C/--compare-only option
- Added the option to capture post data and compare to phases other than *.pre 
using the --pre option
- Added option to force a compare even id the phase does not contain "post" or 
"rollback" using the --force-compare option
* Thu Jul 12 2018 Fedora Release Engineering  - 0.13-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Feb  7 2018 Fedora Release Engineering  - 0.13-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/X5U3TSP5RKGX5IN5UAJYPOEXOER3O4VH/

Fedora testing-20180801.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PL3ZFE475OD76VRA3JVR4WT5B5XUIODF/

Fedora updates-20180801.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.61 to 0.28
Previous test data: https://openqa.fedoraproject.org/tests/262261#downloads
Current test data: https://openqa.fedoraproject.org/tests/262639#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SIG6FNCW6CVWHZHS4SQJ7ZWP72HTEISO/

[Bug 1606934] perl-Module-CoreList-5.20180720 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Module-CoreList-5.20180720-1.fc28 has been pushed to the Fedora 28 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MVAVWQU6GLBWPQJZ6DPLZCKYCXDDR4ZH/

[Bug 1599722] perl-Test-mysqld-1.0011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Test-mysqld-1.0012-1.f
   ||c28
 Resolution|--- |ERRATA
Last Closed||2018-08-01 13:41:43



--- Comment #4 from Fedora Update System  ---
perl-Test-mysqld-1.0012-1.fc28 has been pushed to the Fedora 28 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JPHQIGGOCRJIQC5TPVG7PMIHAI2AXG4W/

Fw: Re: [fedora-arm] Resizing the root partition when loading on a Raspberry Pi 3 B+

[BunnyApocalypse]

Sent from ProtonMail, Swiss-based encrypted email.

‐‐‐ Original Message ‐‐‐
On August 1, 2018 5:35 PM, BunnyApocalypse  
wrote:

> In my experience on the 3 B+, these were the commands that I needed to run:
>
> growpart /dev/mmcblk 0 3
> pvresize /dev/mmcblk0p3
> lvextend -l 100%FREE /dev/mapper/fedora-root
> xfs_growfs -d /
>
> Hopefully this helps you, perhaps we should update the raspberry pi wiki page 
> to have these commands, as the current ones do not work.
>
> -Chris
>
> ‐‐‐ Original Message ‐‐‐
> On August 1, 2018 4:43 PM, Nat W. Garrison, Jr. n...@natgarrison.com wrote:
>
> > I have loaded the arm 64-bit Server 28 version of Fedora on a 32 GB micro 
> > SSD and I can't get root to resize. I was able to resize the 3rd partition 
> > that root is contained within, but I can't get root bigger than 5.1 GB.
> > arm mailing list -- a...@lists.fedoraproject.org
> > To unsubscribe send an email to arm-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/message/JIAHRUPYYUCIC3UJYPAJNZBE4S5KMEPU/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HI3I3CM6UKV7EBMNC6E37MRBFM3GDMCX/

Fedora rawhide compose report: 20180801.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180731.n.0
NEW: Fedora-Rawhide-20180801.n.0

= SUMMARY =
Added images:2
Dropped images:  3
Added packages:  2
Dropped packages:1
Upgraded packages:   320
Downgraded packages: 2

Size of added packages:  16.86 MiB
Size of dropped packages:61.53 MiB
Size of upgraded packages:   14.32 GiB
Size of downgraded packages: 35.89 MiB

Size change of upgraded packages:   -34.10 MiB
Size change of downgraded packages: 10.08 KiB

= ADDED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20180801.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20180801.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20180731.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20180731.n.0.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20180731.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: R-pkgbuild-1.0.0-1.fc29
Summary: Find Tools Needed to Build R Packages
RPMs:R-pkgbuild
Size:106.71 KiB

Package: kwave-18.04.3-1.fc29
Summary: Sound Editor for KDE
RPMs:kwave kwave-doc
Size:16.76 MiB


= DROPPED PACKAGES =
Package: compat-libicu61-61.1-2.fc29
Summary: Compat package with icu libraries
RPMs:compat-libicu61
Size:61.53 MiB


= UPGRADED PACKAGES =
Package:  Canna-3.7p3-55.fc29
Old package:  Canna-3.7p3-54.fc29
Summary:  A Japanese character set input system.
RPMs: Canna Canna-devel Canna-libs
Size: 45.37 MiB
Size change:  73.45 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 3.7p3-55
  - Rebuild with fixed binutils


Package:  GMT-5.4.4-2.fc29
Old package:  GMT-5.4.4-1.fc29
Summary:  Generic Mapping Tools
RPMs: GMT GMT-common GMT-devel GMT-doc
Size: 89.24 MiB
Size change:  1.18 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 5.4.4-2
  - Rebuild with fixed binutils


Package:  ModemManager-1.8.0-4.fc29
Old package:  ModemManager-1.8.0-3.fc29
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 10.81 MiB
Size change:  98.15 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 1.8.0-4
  - Rebuild with fixed binutils


Package:  R-Rcpp-0.12.18-2.fc29
Old package:  R-Rcpp-0.12.18-1.fc29
Summary:  Seamless R and C++ Integration
RPMs: R-Rcpp R-Rcpp-devel R-Rcpp-examples
Size: 22.98 MiB
Size change:  13.45 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 0.12.18-2
  - Rebuild with fixed binutils


Package:  R-igraph-1.2.2-1.fc29
Old package:  R-igraph-1.2.1-2.fc29
Summary:  Network Analysis and Visualization
RPMs: R-igraph
Size: 24.53 MiB
Size change:  -5.85 KiB
Changelog:
  * Tue Jul 31 2018 Elliott Sales de Andrade  - 
1.2.2-1
  - Update to latest version


Package:  R-inline-0.3.15-1.fc29
Old package:  R-inline-0.3.14-5.fc29
Summary:  Functions to Inline C, C++, Fortran Function Calls from R
RPMs: R-inline
Size: 135.45 KiB
Size change:  112 B
Changelog:
  * Tue Jul 31 2018 Mattias Ellert  - 0.3.15-1
  - Update to version 0.3.15


Package:  SLOF-0.1.git20180621-1.fc29
Old package:  SLOF-0.1.git20171214-4.fc29
Summary:  Slimline Open Firmware
RPMs: SLOF
Size: 208.96 KiB
Size change:  13.00 KiB
Changelog:
  * Tue Jul 31 2018 Cole Robinson  - 0.1.git20180621-1
  - Update to SLOF 20180621 for qemu-3.0


Package:  aide-0.16-8.fc29
Old package:  aide-0.16-7.fc29
Summary:  Intrusion detection environment
RPMs: aide
Size: 983.97 KiB
Size change:  5.94 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 0.16-8
  - Rebuild with fixed binutils


Package:  alex4-1.0-28.fc29
Old package:  alex4-1.0-27.fc29
Summary:  Alex the Allegator 4 - Platform game
RPMs: alex4
Size: 4.33 MiB
Size change:  5.67 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 1.0-28
  - Rebuild with fixed binutils


Package:  alphabet-soup-1.1-24.fc29
Old package:  alphabet-soup-1.1-23.fc29
Summary:  Guide your worm through the soup to spell words
RPMs: alphabet-soup
Size: 5.40 MiB
Size change:  5.34 KiB
Changelog:
  * Tue Jul 31 2018 Florian Weimer  - 1.1-24
  - Rebuild with fixed binutils


Package:  ant-1.10.4-3.fc29
Old package:  ant-1.10.4-2.fc29
Summary:  Java build tool
RPMs: ant ant-antlr ant-apache-bcel ant-apache-bsf ant-apache-log4j 
ant-apache-oro ant-apache-regexp ant-apache-resolver ant-apache-xalan2 
ant-commons-logging ant-commons-net ant-javadoc ant-javamail ant-jdepend 
ant-jmf ant-jsch ant-junit ant-lib ant-manual ant-swing ant-testutil ant-xz
Size: 5.09 MiB
Size change:  3.00 KiB
Changelog

[Bug 1609590] perl-Log-Dispatch-FileRotate-1.36 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Log-Dispatch-FileRotat
   ||e-1.36-1.fc29
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |p...@city-fan.org
Last Closed||2018-08-01 11:59:12



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=28766735

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/RYOD6UPYECACAIEM5OXOGEKHLZPHNVYJ/

Re: Fedora Rawhide-20180731.n.0 compose check report

[Hans de Goede]

Hi,

On 01-08-18 17:33, Adam Williamson wrote:

On Tue, 2018-07-31 at 20:29 +, Fedora compose checker wrote:

No missing expected images.

Failed openQA tests: 60/138 (x86_64), 23/24 (i386), 1/2 (arm)

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


So the big change here is a kernel bug that showed up, which affects
console output in various ways and breaks a lot of the tests:

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

Hans is working on fixing that now.


Yes, this should be fixed in 4.18.0-0.rc7.git1.1 which is now building,
thank you for catching this.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZAIM46IIR3TRSNLMIT6YFBGFNNIA7JT/

Re: Welcome Christopher King!

[BunnyApocalypse]

Thank you so much for the warm welcome Rishi!

I would also like to thank everyone who has been helping in the review process. 
I look forward to continuing my contributions to the Fedora project moving 
forward.

-Chris

‐‐‐ Original Message ‐‐‐
On August 1, 2018 3:25 PM, Debarshi Ray  wrote:

> Hello everybody,
>
> I have just sponsored Christopher King (IRC, FAS: bunnyapocalypse)
> into the 'packager' group. He has been doing some great work getting
> the WPE port of WebKit into Fedora:
>
> -   https://bugzilla.redhat.com/show_bug.cgi?id=1601058
> -   https://bugzilla.redhat.com/show_bug.cgi?id=1601186
> -   https://bugzilla.redhat.com/show_bug.cgi?id=1602078
>
> Also, thanks to Michael Catanzaro and Robert-Andre Mauchin, who have
> been reviewing the bulk of his contributions.
>
> Welcome to Fedora, Chris!
>
> Cheers,
> Rishi
>
>
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FXTHJN4X3GGYYRYGW5RFIQGB3SH4XXME/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/22NYH6HBOZVJ2ECKVIOYQVDIY67VKN7O/

Re: Fedora Rawhide-20180731.n.0 compose check report

[Adam Williamson]

On Tue, 2018-07-31 at 20:29 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 60/138 (x86_64), 23/24 (i386), 1/2 (arm)
> 
> New failures (same test did not fail in Rawhide-20180730.n.0):

So the big change here is a kernel bug that showed up, which affects
console output in various ways and breaks a lot of the tests:

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

Hans is working on fixing that now.
-- 
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 Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6UTG6LDGC3GHLZLLYQKL7OYHI643PDLE/

Welcome Christopher King!

[Debarshi Ray]

Hello everybody,

I have just sponsored Christopher King (IRC, FAS: bunnyapocalypse)
into the 'packager' group.  He has been doing some great work getting
the WPE port of WebKit into Fedora:
  * https://bugzilla.redhat.com/show_bug.cgi?id=1601058
  * https://bugzilla.redhat.com/show_bug.cgi?id=1601186
  * https://bugzilla.redhat.com/show_bug.cgi?id=1602078

Also, thanks to Michael Catanzaro and Robert-Andre Mauchin, who have
been reviewing the bulk of his contributions.

Welcome to Fedora, Chris!

Cheers,
Rishi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FXTHJN4X3GGYYRYGW5RFIQGB3SH4XXME/

pghmcfc pushed to perl-Params-ValidationCompiler (master). "Update to 0.30 (..more)"

[notifications]

Notification time stamped 2018-08-01 14:59:20 UTC

From d0afed733a8a2288ef644937863c819eee7b5163 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Aug 01 2018 14:58:38 +
Subject: Update to 0.30


- New upstream release 0.30
  - Added a new option for named params, "return_object", which causes the
validation sub to return an object with methods for each param rather than
a hashref; this is a great way to avoid typos in hash keys (idea
shamelessly stolen from Toby Inkster's Type::Params module)
  - Tweaked the POD formatting so that the table of contents generated by
MetaCPAN is more useful
  - Optionally use Class::XSAccessor

---

diff --git a/perl-Params-ValidationCompiler.spec 
b/perl-Params-ValidationCompiler.spec
index 574815f..6b385d1 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -6,12 +6,12 @@
 %endif
 
 Name:  perl-Params-ValidationCompiler
-Version:   0.27
-Release:   4%{?dist}
+Version:   0.30
+Release:   1%{?dist}
 Summary:   Build an optimized subroutine parameter validator once, use it 
forever
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Params-ValidationCompiler
-Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Params-ValidationCompiler-%{version}.tar.gz
+Source0:   
https://cpan.metacpan.org/modules/by-module/Params/Params-ValidationCompiler-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils
@@ -22,6 +22,7 @@ BuildRequires:perl(ExtUtils::MakeMaker) > 6.75
 # Module
 BuildRequires: perl(B)
 BuildRequires: perl(Carp)
+BuildRequires: perl(Class::XSAccessor)
 BuildRequires: perl(Eval::Closure)
 BuildRequires: perl(Exception::Class)
 BuildRequires: perl(Exporter)
@@ -56,7 +57,8 @@ BuildRequires:perl(Types::Standard)
 %endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-Requires:  perl(Sub::Util) >= 1.40
+Recommends:perl(Class::XSAccessor)
+Recommends:perl(Sub::Util) >= 1.40
 
 %description
 Create a customized, optimized, non-lobotomized, uncompromised, and thoroughly
@@ -78,13 +80,23 @@ make test
 
 %files
 %license LICENSE
-%doc Changes eg/ README.md
+%doc Changes CODE_OF_CONDUCT.md CONTRIBUTING.md eg/ README.md
 %{perl_vendorlib}/Params/
 %{_mandir}/man3/Params::ValidationCompiler.3*
 %{_mandir}/man3/Params::ValidationCompiler::Compiler.3*
 %{_mandir}/man3/Params::ValidationCompiler::Exceptions.3*
 
 %changelog
+* Wed Aug  1 2018 Paul Howarth  - 0.30-1
+- Update to 0.30
+  - Added a new option for named params, "return_object", which causes the
+validation sub to return an object with methods for each param rather than
+a hashref; this is a great way to avoid typos in hash keys (idea
+shamelessly stolen from Toby Inkster's Type::Params module)
+  - Tweaked the POD formatting so that the table of contents generated by
+MetaCPAN is more useful
+  - Optionally use Class::XSAccessor
+
 * Fri Jul 13 2018 Fedora Release Engineering  - 
0.27-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
 
diff --git a/sources b/sources
index a8210df..178b644 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Params-ValidationCompiler-0.27.tar.gz) = 
1c045e7b4b68f7b54cc3f1aa927c515b7662ddd5252baf22be149365b7087b5910219d3e08752e005cfd89a10a740fb2e1a41d8f7fed8765a56eade5d406c9dc
+SHA512 (Params-ValidationCompiler-0.30.tar.gz) = 
5911f9317f0b72e17c72435420a3b6b9f36780ab70715510c46e847970094e730169b9b3085f29cb23ee0aca2e78f7f9edd0d093859a1062869f35c90172bf05



https://src.fedoraproject.org/rpms/perl-Params-ValidationCompiler/c/d0afed733a8a2288ef644937863c819eee7b5163?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JM35KJ2G5BIIDPXRVVW46HH4VYZHWSGQ/

glibc 2.28 rebase has landed in rawhide

[Florian Weimer]

rawhide has been updated to glibc 2.28.

I do not expect any issues because we have been importing development 
snapshots during the past six months, but if there any, please let us 
know ASAP.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WVWIOZSLMBMEXAK75FWJDF64JSQUPD7K/

Re: Python Bundled Wheels package

[Miro Hrončok]

On 1.8.2018 15:11, Petr Viktorin wrote:

On 07/22/18 11:49, Miro Hrončok wrote:

Hi Pythonistas and Fedora packagers.

Recently I've realized we bundle too much wheels with our pythons + 
virtualenv package. That is unfortunate:


  * we don't build those. stricly seeking, it's just a zip with python 
files in it, yet this is not permitted in Fedora
  * we only sometimes list it as Provides: bundled(...) and when we 
do, it is tedious
  * we never list bundled deps in those bundled wheels (pip bundles a 
lot)
  * we never adapt the license tag to include license of bundled 
wheels (and bundled deps in those) - it would be even more tedious, as 
pip License tag can be very complicated

  * we duplicate those across packages

I went ahead and prepared a concept in:
https://bugzilla.redhat.com/show_bug.cgi?id=1605156

This is one package that builds all the required wheels. It might be a 
bit weird that it's only one package, but I think it can lower the 
maintenance burden. Also, we won't update any wheel package, we only 
add or remove them, so there is no "life cycle". Later we can decide 
that there are simply too many thing sin one package and split it).


This package makes sure the license tag is right and all the virtual 
bundled provides are in place.


Even as one package, I think it's a big improvement comparing to 
current state of things.


Could you please review the decisions made in the spec? Namely:

  * naming (main package, subpackages)
  * virtual provides
  * that the spec is generated by a script and how that script works
  * the method of usage described in the package review request

I've also decided not to run tests, as for them to mean something, we 
would need to run them against all relevant Python versions. Also, it 
would complicate the package a lot.


The package is approved thanks to Robert-André Mauchin, yet I won't 
request the repo until it's settled that we want this.


Also, once we start using this, maybe we can stop doing rewheel and 
just use wheels from here in the python3 package as well?


Let me ask: do we actually need all those different versions of wheels? 
After all, the first thing I do after creating a venv is usually `pip 
install -U pip`.


The answer is in the middle. No, it doesn't need to be the hardcoded 
one. But for some Python version,s it needs to be relatively old one.


For example virtuelenv now bundles:

argparse = 1.4.0
pip = 9.0.3
pip = 10.0.1
setuptools = 36.8.0
setuptools = 39.1.0
wheel = 0.29.0
wheel = 0.31.1

Just to support Python 2.6, 3.4-3.7.

We may be able to reduce the number of versions. E.g. I don't really 
think we need both 9.0.1 and 9.0.3. Or I don't understand why pypy3 
ships both pip 8.1.2 & 9.0.1; setuptools 21.2.1 & 28.8.0.


We could probably reduce this to:

setuptools
  36.8.0 for virtualenv (py26)
  39.1.0 (or newer) for everything else

pip
  9.0.3 fior virtualenv (py26)
  10.x or 18.x for everything else

wheel
  0.29.0 for virtualenv (py26)
  0.31.1 (or newer) for everything else

argparse-1.4.0 for virtualenv (py26)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/CRBKMUC5ND4AHEF5F6XNNEHHXANQDK2I/

Re: "TLS reference ... mismatches non-TLS reference"

[Dave Love]

Vít Ondruch  writes:

> Dne 1.8.2018 v 13:48 Dave Love napsal(a):
>> I've been trying to build a new version of the scorep package with
>> %check running make check.  A couple of days ago it failed with strange
>> link errors concerning symbols not found which are defined in the
>> libraries it was linking against (apparently in the right order).  Now
>> it's failing on rawhide x86_64 and armv7hl with
>>
>>   /usr/bin/ld: pomp_tpd_: TLS reference in
>> ./.libs/libscorep_adapter_opari2_openmp_event.so mismatches non-TLS
>> reference in jacobi_omp_f90-jacobi.mod.o
>>
>> but working on aarch64, for instance.  There's an example at
>> https://koji.fedoraproject.org/koji/getfile?taskID=28756918=DEFAULT=build.log
>>
>> It also works on epel7 x86_64 outside of the packaging (although that
>> means it doesn't include support built with clang, since the clang
>> version is too old).
>>
>> What is that likely to be a symptom of, and why would the error have
>> changed in the last couple of days with the same source?  Thanks for any
>> enlightenment.
>
> Because openssl-1.1.1 landed in Rawhide?

I don't think so.  It doesn't use openssl and it currently behaves the
same in f28, which doesn't even have it in the build root.  (I assume
that's TLS as in "thread local storage"; this is instrumenting an OpenMP
program.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GJPQROTD6GXIED6LLTBRYWXTSKKRP7BG/

Re: Python Bundled Wheels package

[Petr Viktorin]

On 07/22/18 11:49, Miro Hrončok wrote:

Hi Pythonistas and Fedora packagers.

Recently I've realized we bundle too much wheels with our pythons + 
virtualenv package. That is unfortunate:


  * we don't build those. stricly seeking, it's just a zip with python 
files in it, yet this is not permitted in Fedora
  * we only sometimes list it as Provides: bundled(...) and when we do, 
it is tedious

  * we never list bundled deps in those bundled wheels (pip bundles a lot)
  * we never adapt the license tag to include license of bundled wheels 
(and bundled deps in those) - it would be even more tedious, as pip 
License tag can be very complicated

  * we duplicate those across packages

I went ahead and prepared a concept in:
https://bugzilla.redhat.com/show_bug.cgi?id=1605156

This is one package that builds all the required wheels. It might be a 
bit weird that it's only one package, but I think it can lower the 
maintenance burden. Also, we won't update any wheel package, we only add 
or remove them, so there is no "life cycle". Later we can decide that 
there are simply too many thing sin one package and split it).


This package makes sure the license tag is right and all the virtual 
bundled provides are in place.


Even as one package, I think it's a big improvement comparing to current 
state of things.


Could you please review the decisions made in the spec? Namely:

  * naming (main package, subpackages)
  * virtual provides
  * that the spec is generated by a script and how that script works
  * the method of usage described in the package review request

I've also decided not to run tests, as for them to mean something, we 
would need to run them against all relevant Python versions. Also, it 
would complicate the package a lot.


The package is approved thanks to Robert-André Mauchin, yet I won't 
request the repo until it's settled that we want this.


Also, once we start using this, maybe we can stop doing rewheel and just 
use wheels from here in the python3 package as well?


Let me ask: do we actually need all those different versions of wheels? 
After all, the first thing I do after creating a venv is usually `pip 
install -U pip`.
Can ensurepip be made to work with "the latest available" pip wheel, 
instead of a hardcoded one?


If that's true only the latest version is needed, we could build the pip 
wheel in the pip package instead.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/3LKTYWCVPEWUPEUWYLVQYULOT4P5ZLCE/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Vít Ondruch]

Dne 1.8.2018 v 13:09 Kamil Paral napsal(a):
> On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch  > wrote:
>
> I'm somehow missing the point probably, but as a rawhide user,
> when I want to take some package from F28 (typically kernel), then
> I have to do "sudo dnf update --disablerepo=*
> --enablerepo=updates{,-testing} kernel\* --release 28", i.e. the
> problem is that I have to enable the "updates" repositories and
> that is about organization of the packages, not about the 28 vs
> Rawhide. So how would your proposal help with this?
>
>
> The current situation is that 'fedora', 'updates' and
> 'updates-testing' repos are disabled in Rawhide, and instead a single
> 'rawhide' repo is enabled (with hardcoded paths). It's true that if
> you specifically disable the rawhide repo and instead enable the
> fedora/updates/updates-testing ones (note: you're missing the fedora
> repo in your example)

Obviously I am not enabling "fedora" repo, because it is too old. But
now I see what you are talking about. I should have enabled "fedora"
repo all the time and it should work the same way for f28 as for the
rawhide. This would make the life easier indeed.


V.


> , the command does work. But it's again one example of what you need
> to do differently on Rawhide than on other releases. I'd like to see
> the same approach wherever you are.
>
> With the new approach, you could do simply this:
> $ dnf list/download/repoquery/whatever package --releasever=28
> the same way as you do this on other releases.
>
> Now, there are two ways how this can be handled by Fedora releng.
> Either they only enable the 'fedora' repo on Rawhide, and then if you
> wanted to access updates/updates-testing repos with this command line,
> you'd need to add --enablerepo=updates and/or
> --enablerepo=updates-testing. (You can say that this is still
> consistent with stable releases, it's just that the general
> expectation is that 'updates' repo is always enabled). Or they enable
> 'updates' repo by default on Rawhide as well (the same way stable
> releases have it), and they point it to an empty repo dir (they can
> even set it to never expire or almost never). In that case no
> --enablerepo will be necessary, and this will be 100% matching stable
> releases approach.
>
> I admit the end-user benefit here is very small (except for
> consistency and perhaps documentation). When you start automating
> tasks and need to run such commands on different Fedora releases
> including Rawhide, the benefit might be larger.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7KUNFZHFPDEK4OH5OJ4GWJXJPMSFTBNZ/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6KICTGT3R4NDW5XMBK5CVTXNYD375SAD/

Re: "TLS reference ... mismatches non-TLS reference"

[Vít Ondruch]

Dne 1.8.2018 v 13:48 Dave Love napsal(a):
> I've been trying to build a new version of the scorep package with
> %check running make check.  A couple of days ago it failed with strange
> link errors concerning symbols not found which are defined in the
> libraries it was linking against (apparently in the right order).  Now
> it's failing on rawhide x86_64 and armv7hl with
>
>   /usr/bin/ld: pomp_tpd_: TLS reference in 
> ./.libs/libscorep_adapter_opari2_openmp_event.so mismatches non-TLS reference 
> in jacobi_omp_f90-jacobi.mod.o
>
> but working on aarch64, for instance.  There's an example at
> https://koji.fedoraproject.org/koji/getfile?taskID=28756918=DEFAULT=build.log
>
> It also works on epel7 x86_64 outside of the packaging (although that
> means it doesn't include support built with clang, since the clang
> version is too old).
>
> What is that likely to be a symptom of, and why would the error have
> changed in the last couple of days with the same source?  Thanks for any
> enlightenment.

Because openssl-1.1.1 landed in Rawhide?

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L3AH75WZAO47SHC33RNBSZMFHSS4RJEF/

"TLS reference ... mismatches non-TLS reference"

[Dave Love]

I've been trying to build a new version of the scorep package with
%check running make check.  A couple of days ago it failed with strange
link errors concerning symbols not found which are defined in the
libraries it was linking against (apparently in the right order).  Now
it's failing on rawhide x86_64 and armv7hl with

  /usr/bin/ld: pomp_tpd_: TLS reference in 
./.libs/libscorep_adapter_opari2_openmp_event.so mismatches non-TLS reference 
in jacobi_omp_f90-jacobi.mod.o

but working on aarch64, for instance.  There's an example at
https://koji.fedoraproject.org/koji/getfile?taskID=28756918=DEFAULT=build.log

It also works on epel7 x86_64 outside of the packaging (although that
means it doesn't include support built with clang, since the clang
version is too old).

What is that likely to be a symptom of, and why would the error have
changed in the last couple of days with the same source?  Thanks for any
enlightenment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XFNUSK7SJQH2FCLDRDLNLC3EUT76UFFY/

Re: F29 System Wide Change: Remove Excessive Linking

[Karel Zak]

On Tue, Jul 03, 2018 at 10:21:42AM +0200, Jan Kurik wrote:
> Note from Change Wrangler: This Change Proposal requires mass rebuild.
> However, two weeks ago (June 19th), we have already passed the
> deadline for Change proposals requiring mass rebuild. I will leave the
> decision whether this Change proposal is accepted or not to RelEng and
> FESCo teams.
> 
> = Proposed System Wide Change: Remove Excessive Linking =
> https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
> 
> 
> Owner(s):
>   * Igor Gnatenko 
>   * Neal Gompa 
> 
> 
> Pass "--as-needed" flag the linker through default system-wide LDFLAGS.
> 
> 
> == Detailed description ==
> The flag ("--as-needed") tells the linker to link in the produced
> binary only the libraries containing symbols actually used by the
> binary itself. This binary can be either a final executale or another
> library.
> The use of the "--as-needed" flag allows the linker to avoid linking
> extra libraries in a binary. This not only improves startup times (as
> the loader does not have to load all the libraries for every step) but
> might avoid the full initialization of big frameworks.

Well, --as-needed is workaround and nothing else. The real problem is 
mess in makefiles and .pc (pkg-config) files. 

It would be better to use --as-needed for testing purpose only, and
ask maintainers why the result with --as-needed is different. 

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MYHBQVFB3ZWBAUVPNN3PCM2OVYUKXXU5/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Kamil Paral]

On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch  wrote:

> I'm somehow missing the point probably, but as a rawhide user, when I want
> to take some package from F28 (typically kernel), then I have to do "sudo
> dnf update --disablerepo=* --enablerepo=updates{,-testing} kernel\*
> --release 28", i.e. the problem is that I have to enable the "updates"
> repositories and that is about organization of the packages, not about the
> 28 vs Rawhide. So how would your proposal help with this?
>

The current situation is that 'fedora', 'updates' and 'updates-testing'
repos are disabled in Rawhide, and instead a single 'rawhide' repo is
enabled (with hardcoded paths). It's true that if you specifically disable
the rawhide repo and instead enable the fedora/updates/updates-testing ones
(note: you're missing the fedora repo in your example), the command does
work. But it's again one example of what you need to do differently on
Rawhide than on other releases. I'd like to see the same approach wherever
you are.

With the new approach, you could do simply this:
$ dnf list/download/repoquery/whatever package --releasever=28
the same way as you do this on other releases.

Now, there are two ways how this can be handled by Fedora releng. Either
they only enable the 'fedora' repo on Rawhide, and then if you wanted to
access updates/updates-testing repos with this command line, you'd need to
add --enablerepo=updates and/or --enablerepo=updates-testing. (You can say
that this is still consistent with stable releases, it's just that the
general expectation is that 'updates' repo is always enabled). Or they
enable 'updates' repo by default on Rawhide as well (the same way stable
releases have it), and they point it to an empty repo dir (they can even
set it to never expire or almost never). In that case no --enablerepo will
be necessary, and this will be 100% matching stable releases approach.

I admit the end-user benefit here is very small (except for consistency and
perhaps documentation). When you start automating tasks and need to run
such commands on different Fedora releases including Rawhide, the benefit
might be larger.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7KUNFZHFPDEK4OH5OJ4GWJXJPMSFTBNZ/

Re: Review swap, Perl flavored

[José Abílio Matos]

On Tuesday, 31 July 2018 23.12.22 WEST Robert-André Mauchin wrote:
> Hello,
> 
> 
> Today is my first year anniversary of contributing to Fedora, yay us!

Congratulations for all your (hard) work Robert-André. :-)

Regards,
-- 
José Abílio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2EQLXUDDBLO23YQGCZHIGM633VEMNFMQ/

Re: Making Fedora secure - Package exit policy for security

[Daniel P . Berrangé]

On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote:
> On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote:
> 
> > 
> > Do we have any analysis showing what would be the fallout if we applied
> > these purge rules today ? ie what packages would be dropped today due
> > to unaddressed CVEs.
> > 
> See reply to my previous email. Also i have attached the list here. I
> did some random analysis and came up with the following conclusion:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1493497
> This one is ftbs on ppc
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1488785
> This one was actually fixed, but the bug did not close
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1487715
> This is iamgemagick so one of many cves which are open against it.

The list of ImageMagick CVEs is horrific - 59 open CVEs - for something
that is often going to be used in a scenario where it is fed untrustworthy
images.  exiv2 is pretty concerning too with 19 open CVEs, again for
something often used with untrustworthy input images :-(

> > Then, from that list of packages, do we have idea of reasons why
> > their CVEs are not getting fixed in Fedora. This could perhaps identify
> > changes to help with the problem(s), rather than jumping straight to
> > the big stick of dropping packages.
> 
> I definitely want to address the core problem here, but i dont want to
> go through tens and even sometimes hundreds of bugs to figure out why
> they have not been fixed. Shouldnt the package maintainer be doing it in
> the first place?

Obviously the responsibility lies with the package maintainer, but look
at what Fedora says their responsibility is:

  https://fedoraproject.org/wiki/Package_maintainer_responsibilities

[quote]
  Manage security issues

  Package maintainer should handle security issues quickly, and if they
  need help they should contact the Security Response Team.
[/quote]

The bugs we file against packages have big boilerplate text, but that's
focused around the mechanics of submitting updates, and again doesn't
give any guidance on how effectively triage the security bugs.

Some maintainers are lucky enough to have experience of dealing with CVEs
from RHEL work, but many/most are not. The reality is much more nuanced
than "should handle security issues quickly". IMPORTANT and CRITICAL rated
security bugs must be handled on very different timeframe from LOW rated
bugs. The latter would be valid to just wait for a rebase in future Fedora
major release and mark CLOSED->UPSTREAM, while the former is something
you'd want to urgently backport fixes for into all existing releases.
MODERATE bugs get into a grey area where its hard to give a clear rule,
as urgency to fix them varies depending on usage context of the package.

So I can't put all blame on the package maintainers for failing to deal
with CVEs appropriately, when we're setting them up to fail by giving
little-to-no guidance on what's really expected in this area.

That's obviously not the entire story here though - even with better docs,
I'm confident we'd still have a significant problem to consider. Some of
this may well be a result of maintainers simply having too many packages
to deal with. With the traditional "single owner" model of Fedora package
maint there's a tendancy to leave the fixing to the officially assigned
owner. For packages that we see a high volume of CVEs against, we perhaps
need to work ensure there are multiple maintainers recorded against the
package to give some redundancy.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XO2BWQQBYOJGVARM45VUKSWU66NOLRPV/

Re: Updates to mathematical software

[Paul Howarth]

Hi Jerry,

On Tue, 31 Jul 2018 19:09:02 -0600
Jerry James  wrote:

> On Tue, May 29, 2018 at 4:36 AM Paul Howarth 
> wrote:
> > On Mon, 28 May 2018 21:03:34 -0600
> > Jerry James  wrote:  
> > > It looks like the giac, Macaulay2, and sagemath stacks are the
> > > only pari consumers.  There is also a pending update to clisp
> > > that will bring its pari integration back; that has been missing
> > > for a few years.  And sure enough, I've got my fingers in all of
> > > those pies. :-)  I'm happy to take pari off of your hands if you
> > > want to hand it over.  
> >
> > OK, done. Have fun!  
> 
> Are you also the maintainer of the pari-elldata, pari-galdata,
> pari-galpol, and pari-seadata packages?  If so, I might as well take
> those, too.  An update to pari-galpol is needed for the latest version
> of pari.

I've now given these to you too. Enjoy :-)

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/72G6WRZ3Z7B5TD4PHKTAC2Y2W4IVCIAX/

Re: RFC: make $releasever return "rawhide" on Rawhide

[Vít Ondruch]

I'm somehow missing the point probably, but as a rawhide user, when I
want to take some package from F28 (typically kernel), then I have to do
"sudo dnf update --disablerepo=* --enablerepo=updates{,-testing}
kernel\* --release 28", i.e. the problem is that I have to enable the
"updates" repositories and that is about organization of the packages,
not about the 28 vs Rawhide. So how would your proposal help with this?


V.


Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
> Hello devel list,
>
> this is a request for comments for a recent proposal I filed at releng
> tracker:
> https://pagure.io/releng/issue/7445
>
> In short, package managers on Rawhide would no longer replace
> $releasever variable with a numerical value (like '29' at this moment,
> soon '30'), but with 'rawhide' string instead. I hope this change will
> make life a bit easier for third-party repos maintainers, for users,
> for developers and sysadmins, and for release engineering. The
> technical implementation can be seen in the ticket (it's the 'Proposed
> solution 1'), together with a long discussion.
>
> To provide a longer explanation of the improvements I expect this to
> bring:
> * Third-party repo maintainers will no longer need to provide two
> different repo files, one for stable Fedora releases using $releasever
> in URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding
> $releasever in URL. (Technically, two repo files are not needed if you
> always use a numbered dir even for Rawhide, but that's
> maintenance-heavy, because you need to change the directory number
> precisely at Branching time). This involves COPR as well. 
> * Users will be able to run commands like "dnf ... --releasever=28"
> even on Rawhide. That doesn't work at the moment, because most repo
> files don't use $releasever and instead have 'rawhide/' hardcoded.
> * Developers and sysadmins will be able to use the same approach
> regarding repositories for stable Fedora releases and Rawhide. Rawhide
> will no longer be different, requiring special treatment. For example,
> the same repo URL can be used to install a system, or the same URL can
> be used to add an additional repository to an existing system. As an
> engineer working on automation, I was always annoyed how I need to
> special-case Rawhide everywhere (and of course, maintain a config file
> that states which release number Rawhide currently maps to). That will
> hopefully be no longer necessary, or very much reduced.
> * Fedora release engineers should be able to get rid of
> fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use
> the standard repo files instead (making use of $releasever).
>
> There might be other advantages, which I haven't tested or though of.
>
> There are also disadvantages. The only one I know of at this moment,
> is that PackageKit is currently incompatible with this change (it uses
> custom logic for populating $releasever, different from dnf logic) and
> will need adjustments.
>
> Fedora releng has pre-approved this change in the ticket, and the
> point of this email is to ask for more feedback from all of you. I'd
> appreciate if you could help us identify edge cases we haven't thought
> of, or point out which tools would be incompatible with this change,
> so that we can track them and discuss it with their developers.
>
> Thanks,
> Kamil
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUJUEHMKDFAYZCBNK6BRY72ZNQ4EHWAE/

Re: Orphaning winswitch

[Antonio Trande]

Is it still maintained by upstream?

On 01/08/2018 02:18, Jonathan Underwood wrote:
> On 29 July 2018 at 19:14, Jonathan Underwood
>  wrote:
>> Dear All,
>>
>> I haven't used winswitch for a few years now, and haven't really got
>> the bandwidth to maintain the package, and so I plan to orphan it in
>> the coming week. Winswitch is developed by the same person as Xpra and
>> provides a front end to Xpra as well as other remote desktop
>> applications. I've cc'd the Xpra package owner in case he wants to
>> pick it up.
> 
> I have now orphaned this package (and also removed admin rights from
> cicku/Christopher Meng who stopped contributing to the project a long
> time ago).
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TGK2ZS336EQOIHCLDEWWEP6BKOQU6ZBE/

Re: Making Fedora secure - Package exit policy for security

[Daniel P . Berrangé]

On Wed, Aug 01, 2018 at 10:33:11AM +0530, Huzaifa Sidhpurwala wrote:
> On 07/31/2018 08:33 PM, Rex Dieter wrote:
> 
> >> 1. If a CRITICAL or IMPORTANT security issue is open against a package
> >> in Fedora-X and by the time X is EOL and the issue is not addressed,
> >> proactively remove the package from X+1
> >> 2. If a MODERATE or LOW security issue is open against a package in
> >> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
> >> it from X+2
> > 
> > I don't think this is practical, we'll lose half the distro (are at least 
> > large chunks).
> > 
> > Initially, such a proposal may be possible if generally limited to leaf 
> > packages.
> > 
> 
> So, i did some analysis of the number of packages which would be
> actually removed if we allowed this policy. I generated a list of open
> CVE bugs against X-2 which in this case is Fedora-26 and i got the
> following list:
> 
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26
> 
> If you extract the list of components ,it yields 57 unique components.
> out of that components like xorg-server etc would probably be in the
> critical list.

binutils is in the list, and without that, we won't have a distro at all !

Chances are though, that the bugs were fixed in upstream and so available
in newer Fedora version, so merely F26 left unfixed and the BZ status
outdated.  I imagine this probably applies to most open CVEs against
RPMs which have an active upstream community. Its the ones with dead
upstream that and not fixed in Fedora that would be the serious concern.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LTWXRKW3KBKFPFNYMLEQQ6IBULJ4T7MV/

Re: Making Fedora secure - Package exit policy for security

[Nikos Mavrogiannopoulos]

On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote:
> Hi All,
> 
> I was asked to bring this issue[1] to the developer community before
> FESCO makes a decision.
> 
> In several instances[2] there exists packages in Fedora, in which
> package-maintainers did not patch security issues, for multiple
> reasons
> including 1. non-responsive maintainer 2. issue hard to patch 3. no
> one
> cares?
> 
> This is a risk for the distribution, our users and community as a
> whole
> and not to mentioned bad PR :)
> 
> I would like to propose the following:
> 
> 
> 1. If a CRITICAL or IMPORTANT security issue is open against a
> package
> in Fedora-X and by the time X is EOL and the issue is not addressed,
> proactively remove the package from X+1
> 2. If a MODERATE or LOW security issue is open against a package in
> Fedora -X and by the time X+! is EOL, the issue is not addressed,
> remove
> it from X+2
> 
> Note:
> 1. Once pkg is patches, it can be rebuild and re-introduced into the
> distro
> 2. X/X+1 is the best boundary to remove the insecure packages imo,
> since
> inbetween removals are not possible due to the way mirrors work.
> 3. Maintain a list somewhere (automated maybe) of the list of
> packages
> removed and why.
> 4. Have a list of critical pkg, which cannot be removed which will
> break
> the distro.
> 
> The above is not set in stone, but is open for discussion. Let me
> know
> what you guys think!
> 
> In the end, i would like you leave you all with this parting link:
> 

Thank you Huzaifa for bringing that up. I have a talk on fedora and
crypto in flock, and my recommendation will be towards having some
process to remove old packages from fedora. CVEs were not the drivers
there, but the continuous expansion of the crypto core which at the end
as you say causes CVEs which no-one addresses. To add to that, we ship
several packages which are the result of an internship, thesis,
packages which are there just in case and all expand the attack
surface.

So yes, I'd support something like that, and even further than that, if
there is no update (upstream release) for 5 years, the
package+dependencies is marked for removal as well. Cancelling that
process would have to go through a fedora committee.

regards,
Nikos

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/

Re: Intent to retire python-svgwrite

[Pierre-Yves Chibon]

On Tue, Jul 31, 2018 at 03:25:49PM -0400, Robert Brown wrote:
>Got it. Thanks. I'm not sure what to do at this point.

Log out and log back into src.fp.o, groups are synced upon login :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VGMJFDFFKCRCUPN7FDHOJJ6LCMWWUCMI/

Re: Making Fedora secure - Package exit policy for security

[Huzaifa Sidhpurwala]

On 07/31/2018 01:19 PM, Pavel Zhukov wrote:

>> 1. If a CRITICAL or IMPORTANT security issue is open against a package
>> in Fedora-X and by the time X is EOL and the issue is not addressed,
>> proactively remove the package from X+1
> By the time FX is EOL'ed it's too late even for FX+2 to drop the
> package. Besides of that CVE could be fixed in FX+2 but not fixed in FX
> so the logic should be a way more complex.

Sure, the above is just a proposal. We could perhaps drop it while FX+2
is beta etc. I am open to idea, as long as there is a way we could exit
the package if it has a consistently bad security record.

Also if CVE is fixed in FX+2 and will not be fixed in FX, the bug
against FX should be closed as wontfix!

>> 2. If a MODERATE or LOW security issue is open against a package in
>> Fedora -X and by the time X+! is EOL, the issue is not addressed, remove
>> it from X+2
> Same here. 

>>
>> Note:
>> 1. Once pkg is patches, it can be rebuild and re-introduced into the distro
>> 2. X/X+1 is the best boundary to remove the insecure packages imo, since
>> inbetween removals are not possible due to the way mirrors work.
>> 3. Maintain a list somewhere (automated maybe) of the list of packages
>> removed and why.
>> 4. Have a list of critical pkg, which cannot be removed which will break
>> the distro.
>>
>> The above is not set in stone, but is open for discussion. Let me know
>> what you guys think!
>>
>> In the end, i would like you leave you all with this parting link:
>> https://sensorstechforum.com/arch-linux-aur-repository-found-contain-malware/
>>
>> [1] https://pagure.io/fesco/issue/1935
>> [2]
>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9076731=changeddate%2Cpriority%2Cbug_id=Fedora_based_on=_format=advanced


-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BXJFXBW4AX5B7QGM2NOS6CFFHSGLBADI/