date:20180710

On Tue, Jul 03, 2018 at 02:39:05PM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: ZRAM support for ARM images =
> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
> 
> 
> Owner(s):
>   * Peter Robinson 
> 
> 
> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
> improve performance and reliability on ARM Single Board Computers such
> a the Raspberry Pi.
> 
> 
> == Detailed description ==
> Current Fedora release artifacts for ARM platforms enable a small
> amount of swap by default. While this has generally works OK in the
> past it can cause a number of issues primarily wearing out SD cards
> due to excess use of wear leveling. ZRAM can mitigate this and provide
> more memory for ARM SBCs by compressing part of memory and using it as
> a swap space. This provides better performance and improved
> reliability across this class of device which overall provides a
> better end user experience.
> 
> 
> == Scope ==
> 
> * Proposal owners:
> Package and include zram config and systemd units.

Which "zram" config? There have been various attempts, e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan
to reuse one of the existing projects, or create something from
scratch?

Zbyszek
___
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/Z5YYYBCMTN5BOBQFO5HN5E5JL5UQB56V/

Intent to retire cryptominisat4

2018-07-10 Thread Jerry James

With cvc4 1.6 building in Rawhide right now, the last Fedora user of
cryptominisat 4.x is gone.  All Fedora consumers are now on
cryptominisat 5.x, which is in the cryptominisat package.
Consequently, I intend to retire the cryptominisat4 package soon.  If
somebody needs it, let me know and I will give it to you instead of
retiring it.
-- 
Jerry James
http://www.jamezone.org/
___
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/BPUJVEIE5GB7EI6E7LL7FYHRE72KDTZP/

cvc4 license change

2018-07-10 Thread Jerry James

The license of cvc4 has been corrected from GPv3+ to "Boost and BSD
and MIT".  Since that is a less restrictive license, it should cause
no issues.
-- 
Jerry James
http://www.jamezone.org/
___
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/LV3YW72LGXWFK2CRUFKK2SPCNTVUQ6X7/

Re: Packages which use the BuildRoot: directive

Unfortunately it seems that many of these packages have had the
BuildRoot tags _added back in_ after previously having them removed.  A
number of the commits even delete existing changelog entries, a sure
sign that someone is just copying the specfile from some outside source.

As a reminder, the Fedora's git repository is the canonical location for
Fedora's spec files.  Simply overwriting what is in git with a file
copied from some external source is not permitted by the Fedora
packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity

 - J<
___
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/6IVPRWILO5PISUON6TI5ITA73GVMGZI6/

[Bug 1599931] New: perl-MongoDB-v2.0.1 is available

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

Bug ID: 1599931
   Summary: perl-MongoDB-v2.0.1 is available
   Product: Fedora
   Version: rawhide
 Component: perl-MongoDB
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: m...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com



Latest upstream release: v2.0.1
Current version/release in rawhide: 2.0.0-2.fc29
URL: http://search.cpan.org/dist/MongoDB/

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

-- 
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/2MFK33MVZU7PNF6FSL7TPF64SAEIAP3I/

[Bug 1599930] New: perl-Net-Amazon-S3-0.83 is available

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

Bug ID: 1599930
   Summary: perl-Net-Amazon-S3-0.83 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Amazon-S3
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rr...@redhat.com



Latest upstream release: 0.83
Current version/release in rawhide: 0.82-1.fc29
URL: http://search.cpan.org/dist/Net-Amazon-S3/

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

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

[Bug 1599926] New: perl-BSON-v1.6.7 is available

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

Bug ID: 1599926
   Summary: perl-BSON-v1.6.7 is available
   Product: Fedora
   Version: rawhide
 Component: perl-BSON
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: v1.6.7
Current version/release in rawhide: 1.6.6-4.fc29
URL: http://search.cpan.org/dist/BSON/

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

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

Re: F29 System Wide Change: uEFI for ARMv7

2018-07-10 Thread Kyle Marek

On 07/10/2018 04:51 PM, Cole Robinson wrote:
> On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
 Move to uEFI as the default boot mechanism for ARMv7 devices.
>>> Will this work with virt-manager too? Currently, while aarch64 boots via
>>> uEFI there, it seems that armv7 is only supported by manually specifying
>>> a kernel and initrd.
>> Ping.
>>
> Currently this won't work with virt-manager.
>
> If this arm32 stuff works similar to aarch64, then what we need is:
> extend the edk2 package to build working arm32 images, some packaging
> changes to libvirt, and some straightforward-but-not-trivial changes to
> virt-manager to match.
>
> Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
> someone can figure out the magic qemu incantation to get those working
> with Fedora, similar to how aarch64 works, I can do the rest

Is it not the usual "-drive
file=OVMF_CODE.fd,format=raw,readonly=on,if=plfash" on a "-machine virt"
type of VM?
___
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/4VGRHWACRQGJ6ODR6WQZXRGJCGMTUDWI/

Re: F29 System Wide Change: ZRAM support for ARM images

2018-07-10 Thread Kevin Fenzi

On 07/03/2018 05:39 AM, Jan Kurik wrote:
> = Proposed System Wide Change: ZRAM support for ARM images =
> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages
> 
> 
> Owner(s):
>   * Peter Robinson 
> 
> 
> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
> improve performance and reliability on ARM Single Board Computers such
> a the Raspberry Pi.
> 
> 
> == Detailed description ==
> Current Fedora release artifacts for ARM platforms enable a small
> amount of swap by default. While this has generally works OK in the
> past it can cause a number of issues primarily wearing out SD cards
> due to excess use of wear leveling. ZRAM can mitigate this and provide
> more memory for ARM SBCs by compressing part of memory and using it as
> a swap space. This provides better performance and improved
> reliability across this class of device which overall provides a
> better end user experience.

So, it looks like anaconda has zram support and enables it if there's
2GB memory or less or you pass 'inst.zram=1' on the boot line.

How does this interact with that? Could we perhaps get both of them to
use the same setup so we don't have multiple places we enable this?

Perhaps it's worth enabling on other arches as well?

Finally I wonder if the 2GB limit is still right?
Should we increase that? I have heard of lot of people say recent
releases need more memory, this might help that out?

kevin



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

Re: F29 System Wide Change: uEFI for ARMv7

2018-07-10 Thread Cole Robinson

On 07/10/2018 04:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
>> On 07/03/2018 05:15 AM, Jan Kurik wrote:
>>> Move to uEFI as the default boot mechanism for ARMv7 devices.
>>
>> Will this work with virt-manager too? Currently, while aarch64 boots via
>> uEFI there, it seems that armv7 is only supported by manually specifying
>> a kernel and initrd.
> 
> Ping.
> 

Currently this won't work with virt-manager.

If this arm32 stuff works similar to aarch64, then what we need is:
extend the edk2 package to build working arm32 images, some packaging
changes to libvirt, and some straightforward-but-not-trivial changes to
virt-manager to match.

Gerd Hoffman has a nightly edk2 repo which builds arm32 images. If
someone can figure out the magic qemu incantation to get those working
with Fedora, similar to how aarch64 works, I can do the rest

https://www.kraxel.org/repos/

Thanks,
Cole
___
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/D3AZWOAVWPV6SRKBXQTAZV3OM7ZYY64Z/

Packages which use banned tags

The packaging guidelines indicate that the following tags must not be
used:
  Copyright:
  Packager:
  Vendor:
  PreReq:
https://fedoraproject.org/wiki/Packaging:Guidelines#Tags_and_Sections

I wasn't aware that a package would even build if the first three were
used, but it seems that a few instances of these tags persist.

Nothing uses Copyright:.

Five packages use Vendor:
  dpkg etoys gold netbeans storhaug

Packager: is used by mcollective

apmud has Prereq: chkconfig which is obviously a sign that something is
amiss.  But it's also marked ExclusiveArch: ppc which means that it
hasn't existed anywhere since we dropped 32 bit ppc around, what, Fedora
12?  The only commits are from mass rebuilds and people doing general
cleanup.

ceph has "PreReq: %fillup_prereq" and I don't even know what that does.
It seems to be inside of some suse-exclusive block, and so I'm not sure
what is supposed to happen.  Which is why that kind of thing is not
permitted in Fedora.  I guess that has to be another of those "nobody
can touch this" packages.

In any case, I will now proceed to dead.package apmud, remove the few
Vendor: and Packager: uses and try to pretend ceph does not exist.  But
for the record, here are the usual (but pleasantly short) lists:

Maintainers by package:
apmuddwmw2
ceph branto dachary dmick ke4qqq kkeithle ktdreyer steve 
stingray
dpkg kanarip sergiomb topdog
etoysdsd gavin tuxbrewr
gold zaniyah
mcollective  maxamillion
netbeans moceap
storhaug kkeithle

Packages by maintainer:
branto ceph
dacharyceph
dmick  ceph
dsdetoys
dwmw2  apmud
gavin  etoys
kanaripdpkg
ke4qqq ceph
kkeithle   ceph storhaug
ktdreyer   ceph
maxamillion mcollective
moceap netbeans
sergiomb   dpkg
steve  ceph
stingray   ceph
topdog dpkg
tuxbrewr   etoys
zaniyahgold
___
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/RALCUFKEKK6MKFLDGL3K7WQJSOV5FK32/

Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries

On Tue, Jul 10, 2018 at 10:28:40PM +0200, Florian Weimer wrote:
> On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
> >>On 07/03/2018 10:13 AM, Jan Kurik wrote:
> >>>= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
> >>>https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
> >>
> >>>OpenLDAP will not ship non-threaded version of libldap. Instead,
> >>>libldap will be built with the same threading support as libldap_r.
> >>
> >>Why is this a system-wide change?  Is it actually about linking
> >>applications and libraries against libldap_r instead of libdap?
> >
> >No, the change says that anything that links to libldap will continue
> >to do that, but that libldap will now be a copy of libdap_r, differing
> >only the so-name.
> 
> I don't see that.  The idea of the symbolic link is explicitly
> rejected, which I think implies also the use of a copy.

The way I understand this:
right now there's two libraries: libldap_r (threaded) and libldap (nonthreaded)
proposed state: two libraries: libldap_r (threaded) and libldap (threaded)
So anything which links to libldap will continue to do that, but despite the
name, libldap will really similar to libldap_r.

Zbyszek
___
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/5NSPRDE3JQ7Z423CV5MAMRWNJOUVGRFP/

Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries

2018-07-10 Thread Florian Weimer


On 07/10/2018 10:19 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:

On 07/03/2018 10:13 AM, Jan Kurik wrote:

= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries



OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.


Why is this a system-wide change?  Is it actually about linking
applications and libraries against libldap_r instead of libdap?


No, the change says that anything that links to libldap will continue
to do that, but that libldap will now be a copy of libdap_r, differing
only the so-name.


I don't see that.  The idea of the symbolic link is explicitly rejected, 
which I think implies also the use of a copy.


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

Re: F29 System Wide Change: uEFI for ARMv7

On Tue, Jul 03, 2018 at 10:14:43PM -0700, Thomas Daede wrote:
> On 07/03/2018 05:15 AM, Jan Kurik wrote:
> > Move to uEFI as the default boot mechanism for ARMv7 devices.
> 
> Will this work with virt-manager too? Currently, while aarch64 boots via
> uEFI there, it seems that armv7 is only supported by manually specifying
> a kernel and initrd.

Ping.

Zbyszek
___
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/IJS7DSFOVOCJA4SS74ZYMFRQKA7S3R43/

Re: F29 System Wide Change: OpenLDAP without Non-threaded Libraries

On Tue, Jul 03, 2018 at 11:26:02AM +0200, Florian Weimer wrote:
> On 07/03/2018 10:13 AM, Jan Kurik wrote:
> >= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
> >https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
> 
> >OpenLDAP will not ship non-threaded version of libldap. Instead,
> >libldap will be built with the same threading support as libldap_r.
> 
> Why is this a system-wide change?  Is it actually about linking
> applications and libraries against libldap_r instead of libdap?

No, the change says that anything that links to libldap will continue
to do that, but that libldap will now be a copy of libdap_r, differing
only the so-name.

Zbyszek
___
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/PKC2NLR5WMBHCH4Q4EVULV77DKQM7XU5/

Re: Packages which use the BuildRoot: directive

On Tue, Jul 10, 2018 at 03:03:56PM -0500, Jason L Tibbitts III wrote:
> The usual lists are below.  Feel free to fix your packages if you like;
> there should be no need to rebuild.  I will wait a few days and then fix
> up the instances which remain.

Thanks! It'll be nice to see BuildRoot finally gone.

Zbyszek
___
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/5G6YJSDFUHOUKVB4VHPTL7H5PA4XR3V2/

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, Jul 10, 2018 at 06:03:33PM +0200, Igor Gnatenko wrote:
> On Tue, Jul 10, 2018 at 5:52 PM Kevin Kofler  wrote:
> 
> > Igor Gnatenko wrote:
> > > As per Changes/Remove GCC from BuildRoot
> > > , I'm
> > > going to automatically add BuildRequires: gcc and/or BuildRequires:
> > > gcc-c++ to packages which fail to build with common messages (like gcc:
> > > command not found, also autotools/cmake/meson are supported).
> > >
> > > I'm going to do this tomorrow.
> > >
> > > After which, I'm going to ask rel-eng to finally remove it from
> > buildroot.
> > > This will happen before mass rebuild. Stay tuned.
> >
> > I still think that this change is absolutely counterproductive, because it
> > will actually INCREASE local mock build times for all C/C++ programs for
> > all
> > packagers, because gcc and gcc-c++ will no longer be included in the root
> > cache.
> >
> 
> However, it will DECREASE local mock build times for all non-C/C++
> programs. And now we will know which packages actually need C and/or C++
> compiler.

Yes.

Also, we'll have a mass rebuild tomorrow. If it turns out to be slower
than the previous one, we can easily re-add gcc to the koji buildroot.

Zbyszek
___
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/XYFUCJP4HV37JOWKF2IUQDPFWHOMGIYQ/

Packages which use the BuildRoot: directive

The Packaging Guidelines indicate that BuildRoot: should not be used in
Fedora specfiles.

The BuildRoot: tag has not been required since RHEL6 and was also not
required in EPEL5 (due to some magic in epel-rpm-macros).  It has not
been needed in any Fedora release since at least Fedora 12.

It has already been removed from most packages due to previous efforts
but it lingers in a few (91, to be exact).  Additionally, a few packages
(24) employ an odd construct like the following:

%{?el5:BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} 
-n)}

which was always unnecessary and now is completely pointless because we
can't build for el5 in any case.  And one does this odd bit:

%{?!buildroot:BuildRoot: %_tmppath/buildroot-%name-%version-%release}

Which is also pointless in Fedora (and is using an unsafe value which
was never allowed in Fedora or EPEL).  I found all of these with a
simple grep for '^(%{?.*)?BuildRoot:' but I did add a find-buildroot
script to https://pagure.io/fedora-misc-package-utilities

The usual lists are below.  Feel free to fix your packages if you like;
there should be no need to rebuild.  I will wait a few days and then fix
up the instances which remain.

Maintainers by package:
NLoptbesser82
binutils aoliva jakub jankratochvil law nickc
carbon-c-relay   piotrp
clamsmtp gnat
cmconvertpcfe
cmockery2lpabon
cocotueno
cracklib nalin tmraz
crashcrash
cross-binutils   dhowells lkundrak sharkcz
ctagsthan
cyrus-sasl   jjelen plautrba
dbh  fabiand limb
dev86jnovy lkundrak
dfishjkaluza
dmlite   adev andreamanzi gbitzes okeeble rocha
dmlite-plugins-s3adev andreamanzi okeeble rocha
dpm-dsi  andreamanzi ellert okeeble rocha simonm
dreamweb besser82
dspamgnat
dtachlon
edg-mkgridmapandreamanzi gbitzes
ejectorphan
exim dwmw2 jskarvad tremble
exim-doc dwmw2 tremble
fgrunbellet
fido besser82 cdamian rfenkhuber
fprobe-ulog  stingray
freecolordfateyev
freetigerbesser82
fuseiso  orphan
gdb  jankratochvil sergiodj
gdesklets-goodweather orphan
genchemlab   limb
glibc64  codonell jakub
gmic berrange cheese
goferjortel
gt5  szpak
inetvis  orphan
inn  ovasik rathann s4504kr
iperfsomlo strobert
ipmiutil arcress
irssi-xmpp   lbazan maha
isomasterlimb szpak
jcommon-serializer   caolanm
jfsutils fcami itamarjp
jnettop  wolfy
lcgdm-davadev andreamanzi gbitzes okeeble rocha
libasr   dfateyev
libjoedogbesser82 cdamian rfenkhuber
liblayoutcaolanm
liblinearbesser82
libmatchbox  cwickert dwalsh
libwhirlpool dfateyev
litmus   aalvarez jorton rocha
lpairs   szpak
matchbox-window-manager cwickert dwalsh
mhashlimb spot
mingw-qwtrjones sailer
mrxvtmtasaka
msr-toolsgbailey
mtools   dkaspar
nagios-plugins-fts   andreamanzi simonm
nagios-plugins-lcgdm adev andreamanzi gbitzes rocha
nxtrcdwrobel
oragekevin nonamedotc
pan  adalloz pmkovar
pardsorphan
parted   bcl
passwd   fkluknav jkucera mitr tmraz
patchtwaugh
pentaho-reporting-flow-engine caolanm
perl-Array-Uniquedfateyev
perl-Encode-Detect   ralston
perl-File-Tempdirdfateyev
perl-Sys-Virtberrange jplesnik steve
perl-Tie-Cache   dfateyev
perl-Time-ParseDate  dfateyev ppisar xavierb
perl-enumdfateyev
publican-fedora  immanetize rlandmann zoglesby
publican-genome  orphan
publican-jboss   rlandmann
pymssql  swilkerson
python-sphinx-theme-flask besser82
python-sphinxcontrib-cheeseshop besser82
python3-dns  aviso
radial   mkasik
rear gdha
rubygem-narray   besser82
rubygem-rspec-longrun besser82
salt dmurphy18 herlo terminalmage
sendmail jskarvad olysonek
shadow-utils pvrabec tmraz
shogun-data  besser82 lupinix
singularity  bbockelm dwd loveshack
spamprobestrobert
squidhno jsteffan luhliarik pavlix thozza
srcpddfateyev
strace   ldv vda
subscription-manager awood bkearney csnyder
sudo jvymazal kzak mattdm mildew rsroka tosykora
syslinux pjones
system-switch-displaymanager than
tcl-mysqltcl renep
textcat  besser82
tgif mtasaka tremble
tkgate   tnorth
ucx

Re: GCC 8/9 ABI change: call for rebuilds

2018-07-10 Thread Adam Williamson

On Tue, 2018-07-10 at 15:31 -0400, Marek Polacek wrote:
> Recently a serious bug in the compiler was discovered whereby we miscompiled
> several packages. The problem only occurs in C++ programs that contain a class
> with a trivial move constructor and deleted copy constructor.  For such
> programs, the calling convention changed inappropriately, in the sense that an
> object was passed via memory rather than via registers.  See
> .
> 
> I did a scratch mass rebuild with a specially-tweaked gcc in order to find out
> which packages need to be rebuilt.  Since the problem occurred in both GCC 8
> and GCC 9, we will need to rebuild packages in F28 and F29:
> 
> ceph-12.2.4-1.fc29.src.rpm
> chromium-67.0.3396.79-1.fc29.src.rpm
> firefox-60.0.1-6.fc29.src.rpm
> gdb-8.1.50.20180605-18.fc29.src.rpm
> insight-8.1.50.20180216-2.fc29.src.rpm
> mame-0.198-1.fc29.src.rpm
> v8-6.7.17-4.fc29.src.rpm
> polymake-3.2r3-1.fc29.src.rpm
> pybind11-2.2.2-3.fc29.src.rpm
> qt5-qtwebengine-5.10.1-7.fc29.src.rpm
> cpprest-2.10.2-2.fc28.src.rpm
> waylandpp-0.2.3-1.fc29.src.rpm
> webkit2gtk3-2.21.3-1.fc29.src.rpm
> webrtc-audio-processing-0.3-7.fc29.src.rpm
> 
> The problem is fixed in gcc-8.1.1-2.fc28 and gcc-8.1.1-2.fc29.  But it seems
> the F28 buildroots still have the unpatched version:
> 
> $ koji latest-pkg f28-build gcc
> Build Tag   Built by
>     
> 
> gcc-8.1.1-1.fc28  f28-updates   jakub
> 
> So perhaps the rebuild in F28 needs to wait a bit.

No update has been submitted for gcc-8.1.1-2.fc28. A buildroot override
was submitted for gcc-8.1.1-4.fc28, but it expired already:

https://bodhi.fedoraproject.org/overrides/gcc-8.1.1-4.fc28

the only ways for a package to get into the buildroot are to be in a
stable update or to have an active buildroot override. So either an
update for GCC needs to be sent out and pushed stable before the
rebuilds are done, or the buildroot override must be renewed and
extended (this could be done, for instance, if we wanted to submit an
update of GCC and the rebuilt packages together, after doing the
rebuilds).
-- 
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/J3AO2RTJH7IJQW3QJS3CTHUXBCGVDW4W/

GCC 8/9 ABI change: call for rebuilds

2018-07-10 Thread Marek Polacek

Recently a serious bug in the compiler was discovered whereby we miscompiled
several packages. The problem only occurs in C++ programs that contain a class
with a trivial move constructor and deleted copy constructor.  For such
programs, the calling convention changed inappropriately, in the sense that an
object was passed via memory rather than via registers.  See
.

I did a scratch mass rebuild with a specially-tweaked gcc in order to find out
which packages need to be rebuilt.  Since the problem occurred in both GCC 8
and GCC 9, we will need to rebuild packages in F28 and F29:

ceph-12.2.4-1.fc29.src.rpm
chromium-67.0.3396.79-1.fc29.src.rpm
firefox-60.0.1-6.fc29.src.rpm
gdb-8.1.50.20180605-18.fc29.src.rpm
insight-8.1.50.20180216-2.fc29.src.rpm
mame-0.198-1.fc29.src.rpm
v8-6.7.17-4.fc29.src.rpm
polymake-3.2r3-1.fc29.src.rpm
pybind11-2.2.2-3.fc29.src.rpm
qt5-qtwebengine-5.10.1-7.fc29.src.rpm
cpprest-2.10.2-2.fc28.src.rpm
waylandpp-0.2.3-1.fc29.src.rpm
webkit2gtk3-2.21.3-1.fc29.src.rpm
webrtc-audio-processing-0.3-7.fc29.src.rpm

The problem is fixed in gcc-8.1.1-2.fc28 and gcc-8.1.1-2.fc29.  But it seems
the F28 buildroots still have the unpatched version:

$ koji latest-pkg f28-build gcc
Build Tag   Built by
    
gcc-8.1.1-1.fc28  f28-updates   jakub

So perhaps the rebuild in F28 needs to wait a bit.

Marek
___
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/KECGQVOYOURLKFP4ZEM63JZDK32GADI4/

Re: Plan to update Brotli to 1.0.5 in Rawhide

2018-07-10 Thread pouar

On Tue, 10 Jul 2018 11:30:12 -0700
Adam Williamson  wrote:

> On Tue, 2018-07-10 at 11:43 -0500, po...@pouar.net wrote:
> > So did anyone try to see if there were any problems or did they not try
> > it yet? Kinda new to the collaborating thing with potentially ABI
> > breaking updates and am not sure whether I should proceed or not, and I
> > don't really want to accidentally cause a repeat of the "unannounced
> > soname bump" thing
>   
> 
> FWIW I'd say you're fine to go ahead if no-one wrote back and said 'oh
> god no, stop!' Maybe just say 'hey, I'm going to go ahead and do this
> on date X if no-one complains', then do it on that date, and send out
> another mail asking folks to do rebuilds.

So that's a yes, I can update it?

-- 
GPG Keys: https://keybase.io/pouar
Tox ID:
2EA7A6D5494C10B2E0F32004A1E9CBD971777E551A902059E5EA7E73E5A299272F29D9FF5F6A
Matrix ID: @Pouar:matrix.org Social Links: https://www.pouar.net/social.php


pgp39_Bj7ZCww.pgp
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/2J6VD7XVRAK64IAO3V52S5G37DTMMO5H/

Re: Plan to update Brotli to 1.0.5 in Rawhide

2018-07-10 Thread Adam Williamson

On Tue, 2018-07-10 at 11:43 -0500, po...@pouar.net wrote:
> So did anyone try to see if there were any problems or did they not try it
> yet? Kinda new to the collaborating thing with potentially ABI breaking
> updates and am not sure whether I should proceed or not, and I don't really
> want to accidentally cause a repeat of the "unannounced soname bump" thing

FWIW I'd say you're fine to go ahead if no-one wrote back and said 'oh
god no, stop!' Maybe just say 'hey, I'm going to go ahead and do this
on date X if no-one complains', then do it on that date, and send out
another mail asking folks to do rebuilds.
-- 
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/H7Z3AYT4JMLUJ4IJ2VER5BIDHJSQZUXW/

Fedora Rawhide-20180710.n.0 compose check report

2018-07-10 Thread Fedora compose checker

No missing expected images.

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

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

ID: 256117  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/256117
ID: 256131  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/256131
ID: 256134  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/256134
ID: 256137  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/256137
ID: 256139  Test: x86_64 Workstation-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/256139
ID: 256150  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/256150
ID: 256154  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/256154
ID: 256157  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/256157
ID: 256159  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/256159
ID: 256179  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/256179
ID: 256187  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/256187
ID: 256188  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/256188
ID: 256218  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/256218
ID: 256236  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/256236
ID: 256245  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/256245
ID: 256246  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/256246

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

ID: 256111  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/256111
ID: 256112  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/256112
ID: 256126  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/256126
ID: 256127  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/256127
ID: 256130  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/256130
ID: 256147  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/256147
ID: 256148  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/256148
ID: 256149  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/256149
ID: 256163  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/256163
ID: 256164  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/256164
ID: 256229  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/256229
ID: 256250  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/256250
ID: 256252  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/256252
ID: 256253  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/256253
ID: 256254  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/256254
ID: 256255  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/256255
ID: 256256  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/256256
ID: 256257  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/256257
ID: 256258  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/256258
ID: 256259  Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/256259
ID: 256260  Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/256260
ID: 256261  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/256261
ID: 256262  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/256262
ID: 256263  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/256263
ID: 256264  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/256264
ID: 256265  Test: i386 universal

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, Jul 10, 2018 at 5:52 PM Kevin Kofler  wrote:

> Igor Gnatenko wrote:
> > As per Changes/Remove GCC from BuildRoot
> > , I'm
> > going to automatically add BuildRequires: gcc and/or BuildRequires:
> > gcc-c++ to packages which fail to build with common messages (like gcc:
> > command not found, also autotools/cmake/meson are supported).
> >
> > I'm going to do this tomorrow.
> >
> > After which, I'm going to ask rel-eng to finally remove it from
> buildroot.
> > This will happen before mass rebuild. Stay tuned.
>
> I still think that this change is absolutely counterproductive, because it
> will actually INCREASE local mock build times for all C/C++ programs for
> all
> packagers, because gcc and gcc-c++ will no longer be included in the root
> cache.
>

However, it will DECREASE local mock build times for all non-C/C++
programs. And now we will know which packages actually need C and/or C++
compiler.

A lot of packages in 2018 are not written in C/C++, welcome to XXI century!


> It is also yet another pointless mass change to a huge number of packages,
> right after the %defattr one.
>

It came up multiple times and we are pretty much in agreement that we *need*
such cleanups.
-- 

-Igor Gnatenko
___
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/3TFLEJIW5LGDNYT2QXSG6GBN2V4N263X/

Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 28.20180708.0

2018-07-10 Thread Sinny Kumari

On Tue, Jul 10, 2018 at 8:28 PM,  wrote:

>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 28.20180708.0
> Commit(x86_64): 5736e832b1fd59208465458265136f
> be2aa4ba89517d8bdcc91bc84724f40a8e
> Commit(aarch64): 4066f8e2f2f13709d0cf9a562a1f24
> cd2459bdc9f13e1ea1034a367586f79dac
> Commit(ppc64le): a197bd8bfb8cf039e8f2cccf7f743c
> bb92dde30fffa6ccb0729f8ad13e757b17
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/aarch64/images/
> Fedora-AtomicHost-28-20180709.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/aarch64/images/
> Fedora-AtomicHost-28-20180709.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/aarch64/iso/Fedora-
> AtomicHost-ostree-aarch64-28-20180709.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/ppc64le/images/
> Fedora-AtomicHost-28-20180709.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/ppc64le/images/
> Fedora-AtomicHost-28-20180709.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/ppc64le/iso/Fedora-
> AtomicHost-ostree-ppc64le-28-20180709.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/images/
> Fedora-AtomicHost-28-20180709.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/images/
> Fedora-AtomicHost-28-20180709.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/images/
> Fedora-AtomicHost-Vagrant-28-20180709.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/images/
> Fedora-AtomicHost-Vagrant-28-20180709.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/iso/Fedora-
> AtomicHost-ostree-x86_64-28-20180709.0.iso
>
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/aarch64/images/
> Fedora-AtomicHost-28-20180709.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/aarch64/iso/Fedora-
> AtomicHost-28-20180709.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/ppc64le/images/
> Fedora-AtomicHost-28-20180709.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/ppc64le/iso/Fedora-
> AtomicHost-28-20180709.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/images/
> Fedora-AtomicHost-28-20180709.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-
> Atomic-28-20180709.0/AtomicHost/x86_64/iso/Fedora-
> AtomicHost-28-20180709.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
>
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
>

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

2018-07-10 Thread Kevin Fenzi

On 07/10/2018 03:36 AM, Igor Gnatenko wrote:
> On Tue, Jul 10, 2018 at 12:22 PM Vít Ondruch  wrote:
> 
>> Thank you for pushing this forward!
>>
>>
>> One question though. I see that this works in Koji, but trying to test
>> this locally it does not work.
>>
>> 1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
>> --enablerepo=local
>>
>> This still installs gcc.
>>
>> 2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
>> --disablerepo=* --enablerepo=local
>>
>> This fails:
>>
>> ~~~
>>
>> Warning: Module or Group 'buildsys-build' does not exist.
>> Error: Nothing to do.
>>
>> ~~~
>>
>> Trying to get the latest comps from local repository:
>>
>> ~~~
>>
>>
>> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repodata/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-comps.xml
>>
>> ~~~
>>
>> This has "build" group which references gcc/gcc-c++ and does not reference
>> any buildsys-build group. So where is this file coming from? Why does it
>> differ from regular Fedora repos?
>>
> This is  interesting question. I've sent PR to update comps
> ,
> but I don't know how it is being pushed through… We should ask rel-eng to
> help with this.
> 
> Mohan, Kevin?

Looks like Mohan merged it a while back now...

kevin




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

Fedora rawhide compose report: 20180710.n.0 changes

2018-07-10 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180709.n.0
NEW: Fedora-Rawhide-20180710.n.0

= SUMMARY =
Added images:5
Dropped images:  1
Added packages:  2
Dropped packages:8
Upgraded packages:   154
Downgraded packages: 0

Size of added packages:  892.89 KiB
Size of dropped packages:290.09 MiB
Size of upgraded packages:   3.99 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   380.02 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Minimal_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Minimal-Base-Rawhide-20180710.n.0.armhfp.tar.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20180710.n.0-sda.raw.xz
Image: Container_Base docker armhfp
Path: 
Container/armhfp/images/Fedora-Container-Base-Rawhide-20180710.n.0.armhfp.tar.xz
Image: AtomicHost qcow2 aarch64
Path: 
AtomicHost/aarch64/images/Fedora-AtomicHost-Rawhide-20180710.n.0.aarch64.qcow2
Image: AtomicHost raw-xz aarch64
Path: 
AtomicHost/aarch64/images/Fedora-AtomicHost-Rawhide-20180710.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20180709.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: ibus-input-pad-1.4.99.20140916-8.fc29
Summary: Input Pad for IBus
RPMs:ibus-input-pad
Size:290.46 KiB

Package: python-libsass-0.14.5-1.fc29
Summary: Python bindings for libsass
RPMs:python3-libsass
Size:602.43 KiB


= DROPPED PACKAGES =
Package: eclipse-fedorapackager-0.6.0-4.fc28
Summary: Fedora Packager for Eclipse
RPMs:eclipse-fedorapackager
Size:2.72 MiB

Package: iksemel-1.5-0.1.git978b733.fc26
Summary: An XML parser library designed for Jabber applications
RPMs:iksemel iksemel-devel iksemel-utils python2-iksemel
Size:1.03 MiB

Package: libhfi1-0.5-26.fc27
Summary: Intel Omni-Path HFI Userspace Driver
RPMs:libhfi1 libhfi1-static
Size:29.18 KiB

Package: llvm34-3.4.2-10.fc26
Summary: The Low Level Virtual Machine
RPMs:llvm34 llvm34-devel llvm34-doc llvm34-libs llvm34-static
Size:133.23 MiB

Package: llvm35-3.5.2-4.fc26
Summary: The Low Level Virtual Machine
RPMs:llvm35 llvm35-devel llvm35-doc llvm35-libs llvm35-static
Size:152.05 MiB

Package: mingw-cximage-600-19.fc29
Summary: MinGW Windows CxImage manipulation library
RPMs:mingw32-cximage mingw32-cximage-static mingw64-cximage 
mingw64-cximage-static
Size:844.31 KiB

Package: python-gevent-websocket-0.9.5-6.fc28
Summary: Websocket handler for the gevent pywsgi server
RPMs:python2-gevent-websocket
Size:43.04 KiB

Package: spice-xpi-2.8.90-11.fc26
Summary: SPICE extension for Mozilla
RPMs:spice-xpi
Size:168.55 KiB


= UPGRADED PACKAGES =
Package:  Agda-stdlib-0.15-1.fc29
Old package:  Agda-stdlib-0.13-3.fc27
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 124.71 MiB
Size change:  18.57 MiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering  - 
0.13-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Sun Jul 01 2018 Jens Petersen  - 0.15-1
  - update to 0.15 for Agda-2.5.3


Package:  GLC_lib-2.5.0-1.fc29
Old package:  GLC_lib-2.2.0-17.fc27
Summary:  C++ class library for OpenGL application based on Qt 4
RPMs: GLC_lib GLC_lib-devel
Size: 4.09 MiB
Size change:  510.61 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering  - 
2.2.0-18
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Mon Jul 09 2018 Nicolas Chauvet  - 2.5.0-1
  - Update to 2.5.0


Package:  NearTree-5.1.1-1.fc29
Old package:  NearTree-3.1.1-8.fc21
Summary:  An API for finding nearest neighbors
RPMs: NearTree NearTree-devel
Size: 755.31 KiB
Size change:  121.51 KiB
Changelog:
  * Fri Feb 10 2017 Fedora Release Engineering  - 
3.1.1-12
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild

  * Wed Jul 26 2017 Fedora Release Engineering  - 
3.1.1-13
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

  * Wed Aug 02 2017 Fedora Release Engineering  - 
3.1.1-14
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild

  * Wed Feb 07 2018 Fedora Release Engineering  - 
3.1.1-15
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Tue Jul 10 2018 Dmitrij S. Kryzhevich  - 5.1.1 - 1
  - Update to new 5.1.1.
  - Disable test for now. They are too arch dependent.


Package:  annobin-8.7-1.fc29
Old package:  annobin-8.4-1.fc29
Summary:  Binary annotation plugin for GCC
RPMs: annobin
Size: 828.88 KiB
Size change:  2.27 KiB
Changelog:
  * Mon Jul 09 2018 Nick Clifton  - 8.5-1
  - Do not call function_section.  (#1598961)

  * Mon Jul 09 2018 Nick Clifton  - 8.6-1
  - Use the assembler (c++ mangled) version of function names when switching 
sections.  (#1598579

Re: Packages which needlessly use %defattr

2018-07-10 Thread Kevin Fenzi

On 07/10/2018 08:53 AM, Miro Hrončok wrote:
> On 10.7.2018 17:45, Till Maas wrote:
>> Hi,
>>
>> On Tue, Jul 10, 2018 at 10:36:08AM -0500, Jason L Tibbitts III wrote:
>>
>>> I haven't written any scripts which modify specfiles, only scripts which
>>> find issues.  And in any case:
>>>
>>> https://fedoraproject.org/wiki/Mass_package_changes#Automated_cleanup
>>>
>>> Besides... this is git.  And rawhide.  If I broke something seriously
>>> then I or any maintainer or any provenpackager can revert the commit.
>>>
>>> Really, if we just waited until every spec maintainer had a chance to
>>> ack every script that's used to modify packages, there would be no point
>>> in ever trying to do automated cleanup.  Sorry, but my work with Fedora
>>> will be aimed towards progress, not sitting around not changing anything
>>> for fear of potentially breaking something.
>>>
>>> The removals of %defattr that I did a few hours ago were done by hand,
>>> not scripted.  I don't doubt that there's a reasonable chance that I
>>> could have screwed up one or two out of nearly 2700 packages.  That's
>>> life.
>>
>> thank you Jason for doing this. IMHO we need to embrace this approach.
>> As you write, it is the path for progress and I hope we have more of
>> these automatic cleanups to reduce the need for manual interventions as
>> much as possible.
> 
> I second that. We need to remove old cruft from packaging and Jason is
> doing a great job.

Yep. Completely agree. This is saving everyone take and energy.

Where we can safely identify and change something over the collection
that needs changed, we should do so.

Thanks tibbs.

kevin




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

Re: Plan to update Brotli to 1.0.5 in Rawhide

2018-07-10 Thread pouar

So did anyone try to see if there were any problems or did they not try it
yet? Kinda new to the collaborating thing with potentially ABI breaking
updates and am not sure whether I should proceed or not, and I don't really
want to accidentally cause a repeat of the "unannounced soname bump" thing

-- 
GPG Keys: https://keybase.io/pouar
Tox ID:
2EA7A6D5494C10B2E0F32004A1E9CBD971777E551A902059E5EA7E73E5A299272F29D9FF5F6A
Matrix ID: @Pouar:matrix.org Social Links: https://www.pouar.net/social.php


pgpPObX7r5dl_.pgp
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/HV6OOHIJXPEOOJQPOYZ5PXZNABMIFHFL/

Re: Packages which needlessly use %defattr

In case it wasn't obvious from all of the commit messages, I did go
ahead and remove many needless %defattr directives from a large number
of packages a few hours ago.

I used the output of the find-needless-defattr script from
https://pagure.io/fedora-misc-package-utilities as a guide for which
packages needed modifications, but I made the changes by sed'ing out
only specific %defattr directives (not all defattr statements) appearing
as the _first_ line of a %files section (including the %files sections
for subpackages). This probably does not capture all needless uses of
%defattr but it certainly gets the vast majority of them.

I verified that the %defaddr directives removed were equivalent to the
default, individually verified the diffs to ensure that I did not delete
lines I did not intend to delete, and then committed and pushed the
changes. I did not update Release: or add to %changelog as these
changes do not result in any changes to the build products.

Expect more automated cleanup like this in the future. Next up is the
few remaining packages which still use BuildRoot:. Later I will go back
and audit by hand the remaining uses of %defattr in the distribution.

- J<
___
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/DHGU7NFGM5AJOFDQ7BMP3SLF67JZUYBR/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Till Maas

On Tue, Jul 10, 2018 at 05:44:50PM +0200, Kevin Kofler wrote:

> I still think that this change is absolutely counterproductive, because it 
> will actually INCREASE local mock build times for all C/C++ programs for all 
> packagers, because gcc and gcc-c++ will no longer be included in the root 
> cache.

If you or someone else cares about this for their own setup I recommend
to change or add a mock config that just extends the chroot_setup_cmd to
include gcc and gcc-c++ and the problem is solved.

Kind regards
Till
___
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/P6PBAOLYYD74JED5RFH6UQ5GFV5DDC3A/

Re: Packages which needlessly use %defattr

2018-07-10 Thread Miro Hrončok

On 10.7.2018 17:45, Till Maas wrote:

Hi,

On Tue, Jul 10, 2018 at 10:36:08AM -0500, Jason L Tibbitts III wrote:

I haven't written any scripts which modify specfiles, only scripts which
find issues. And in any case:

https://fedoraproject.org/wiki/Mass_package_changes#Automated_cleanup

Besides... this is git. And rawhide. If I broke something seriously
then I or any maintainer or any provenpackager can revert the commit.

Really, if we just waited until every spec maintainer had a chance to
ack every script that's used to modify packages, there would be no point
in ever trying to do automated cleanup. Sorry, but my work with Fedora
will be aimed towards progress, not sitting around not changing anything
for fear of potentially breaking something.

The removals of %defattr that I did a few hours ago were done by hand,
not scripted. I don't doubt that there's a reasonable chance that I
could have screwed up one or two out of nearly 2700 packages. That's
life.

thank you Jason for doing this. IMHO we need to embrace this approach.
As you write, it is the path for progress and I hope we have more of
these automatic cleanups to reduce the need for manual interventions as
much as possible.

I second that. We need to remove old cruft from packaging and Jason is
doing a great job.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/6ZYQY63LEQAZGQJ2OMOP2JDPYD2ND6VA/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Kamil Dudka

On Tuesday, July 10, 2018 5:44:50 PM CEST Kevin Kofler wrote:
> Igor Gnatenko wrote:
> 
> > As per Changes/Remove GCC from BuildRoot
> > , I'm
> > going to automatically add BuildRequires: gcc and/or BuildRequires:
> > gcc-c++ to packages which fail to build with common messages (like gcc:
> > command not found, also autotools/cmake/meson are supported).
> > 
> > I'm going to do this tomorrow.
> > 
> > After which, I'm going to ask rel-eng to finally remove it from
> > buildroot.
> > This will happen before mass rebuild. Stay tuned.
> 
> 
> I still think that this change is absolutely counterproductive, because it 
> will actually INCREASE local mock build times for all C/C++ programs for
> all packagers, because gcc and gcc-c++ will no longer be included in the
> root cache.

You are free to tweak your local mock configs to preinstall arbitrary packages 
(and include them in root cache) if build speed is your concern.  Have a look
at the 'chroot_setup_cmd' option.

Kamil

> It is also yet another pointless mass change to a huge number of packages, 
> right after the %defattr one.
> 
> Kevin Kofler
> ___
> 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/LIQJUDDE2WBU32PGOVHRAR2SBJ4ILR2R/

___
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/XYZVDBUIY6PWSAFM46ZT5B44SB4Y744N/

Re: Packages which needlessly use %defattr

2018-07-10 Thread Till Maas

Hi,

On Tue, Jul 10, 2018 at 10:36:08AM -0500, Jason L Tibbitts III wrote:

> I haven't written any scripts which modify specfiles, only scripts which
> find issues.  And in any case:
> 
> https://fedoraproject.org/wiki/Mass_package_changes#Automated_cleanup
> 
> Besides... this is git.  And rawhide.  If I broke something seriously
> then I or any maintainer or any provenpackager can revert the commit.
> 
> Really, if we just waited until every spec maintainer had a chance to
> ack every script that's used to modify packages, there would be no point
> in ever trying to do automated cleanup.  Sorry, but my work with Fedora
> will be aimed towards progress, not sitting around not changing anything
> for fear of potentially breaking something.
> 
> The removals of %defattr that I did a few hours ago were done by hand,
> not scripted.  I don't doubt that there's a reasonable chance that I
> could have screwed up one or two out of nearly 2700 packages.  That's
> life.

thank you Jason for doing this. IMHO we need to embrace this approach.
As you write, it is the path for progress and I hope we have more of
these automatic cleanups to reduce the need for manual interventions as
much as possible.

Kind regards
Till
___
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/E6LI3KR274QO243SSCOL3WNXGWR3NIJY/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Kevin Kofler

Igor Gnatenko wrote:
> As per Changes/Remove GCC from BuildRoot
> , I'm
> going to automatically add BuildRequires: gcc and/or BuildRequires:
> gcc-c++ to packages which fail to build with common messages (like gcc:
> command not found, also autotools/cmake/meson are supported).
> 
> I'm going to do this tomorrow.
> 
> After which, I'm going to ask rel-eng to finally remove it from buildroot.
> This will happen before mass rebuild. Stay tuned.

I still think that this change is absolutely counterproductive, because it 
will actually INCREASE local mock build times for all C/C++ programs for all 
packagers, because gcc and gcc-c++ will no longer be included in the root 
cache.

It is also yet another pointless mass change to a huge number of packages, 
right after the %defattr one.

Kevin Kofler
___
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/LIQJUDDE2WBU32PGOVHRAR2SBJ4ILR2R/

Re: Packages which needlessly use %defattr

> "NK" == Nico Kadel-Garcia writes:

NK> Would you please post, or post a link to, your updated filter
NK> script?

It remains at https://pagure.io/fedora-misc-package-utilities :
https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-needless-defattr

I currently have no unpushed commits to that repository.

NK> I'd be especially curious if it inserts a record of the
NK> work in the %changelog stanza.

Well, the script just detects issues, it doesn't change the specfiles.

NK> As good as you may be at writing such tools, I'd be a bit wary of "I
NK> have this script that's touching hundreds or thousands of spec
NK> files, and which I've updated again, and no one has seen the final
NK> form, but you can verify my work by checking the thousands of
NK> modified RPM's I've built". It seems somewhat risky.

I haven't written any scripts which modify specfiles, only scripts which
find issues. And in any case:

https://fedoraproject.org/wiki/Mass_package_changes#Automated_cleanup

Besides... this is git. And rawhide. If I broke something seriously
then I or any maintainer or any provenpackager can revert the commit.

Oh, and I did not modify the package %changelog sections, or change
Release:. That would be pointless; the change is of course tracked in
git, but as it makes no difference at all to the generated package,
there is no point in it receiving a changelog entry. If you really want
to add one, be my guest.

Fedora Atomic Host Two Week Release Announcement: 28.20180708.0

2018-07-10 Thread noreply


A new Fedora Atomic Host update is available via an OSTree update:

Version: 28.20180708.0
Commit(x86_64): 5736e832b1fd59208465458265136fbe2aa4ba89517d8bdcc91bc84724f40a8e
Commit(aarch64): 
4066f8e2f2f13709d0cf9a562a1f24cd2459bdc9f13e1ea1034a367586f79dac
Commit(ppc64le): 
a197bd8bfb8cf039e8f2cccf7f743cbb92dde30fffa6ccb0729f8ad13e757b17


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180709.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180709.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-28-20180709.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180709.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180709.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-28-20180709.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180709.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180709.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180709.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180709.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-28-20180709.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180709.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-28-20180709.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180709.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-28-20180709.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180709.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180709.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-28-20180709.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filename

For more

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Charalampos Stratakis



- Original Message -
> From: "Tomasz Kłoczko" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, July 10, 2018 2:27:40 PM
> Subject: Re: [HEADS UP] Removal of GCC from the buildroot
> 
> On Tue, 10 Jul 2018 at 12:52, Till Maas  wrote:
> [..]
> > > PS. And really I don't care that again above will be taken as kind of
> > > personal attack (which is not my intention).
> >
> > The Fedora Code of Conduct is not optional therefore I expect you to
> > care about this. If you believe your e-mail might be offensive, it is
> > your job to ensure that it is not.
> 
> Sorry to say this without telling openly some past stories straight
> about things which only few people knows it is not possible to
> understand why at the moment I'm not able to trust what Igor is doing.
> One time it may be accident ..
> Truth is that not one but at least few time he miscarried few things.
> I would be not surprised if I'll be not only person with such
> experience.
> IMO even if he has some potential I'm guessing that he is still
> relatively young and if it is true he may still need proper mentoring

Can you really not see what is wrong and hurtful with that statement of yours?

> (however I'm not going or want to be his mentor)
> I can honestly promise that if he will be somehow cross the line with
> things which sometimes I'm trying to take care next time my reaction
> will be as same as before. You may say that from this point of view
> I'm 100% predictable.
> 

This is not about how Igor is reacting but how you keep coming up
with ridiculous excuses to justify your toxic behaviour.

> IMO he needs to learn meaning of some old sentence "Errare humanum est
> perseverare autem diabolicum"
> If he will not learn few thing I don't want to be around next time.
> 

Everyone needs to learn things, especially when dealing with others.
Noone though should justify bad actions or wording due to real or hypothetical
actions of other people. Please stop using Igor as a scapegoat.

> If you or someone else can give me the lesson how to say above without
> hurting someone personal fillings or not act as someone offensive I'm
> really ready to pay whatever price someone will ask for.
> 

Noone should feel obliged to give someone a lesson in order to
learn to behave properly or in a civilized manner on a public discussions.
You inability to do that is not anyone's fault but yours. Please work
on that first before deciding to place the blame of your action onto other 
people.

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

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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/2DC3EDXGLPA6H4LLGNOF364KWYLXHWSV/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

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


--- Doc Text *updated* by Eric Christensen  ---
It was found that the Archive::Tar module did not properly sanitize symbolic 
links when extracting tar archives. An attacker, able to provide a specially 
crafted archive for processing, could use this flaw to write or overwrite 
arbitrary files in the context of the Perl interpreter.


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

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, Jul 10, 2018 at 3:12 PM Vít Ondruch  wrote:

>
>
> Dne 10.7.2018 v 14:03 Tomasz Kłoczko napsal(a):
> > On Tue, 10 Jul 2018 at 12:26, Tomasz Kłoczko 
> wrote:
> > [..]
> >> # dnf -C repoquery --qf "%{name}.%{arch} %{source_name} %{reponame}" |
> >> grep -w rawhide | grep x86_64 | awk '{print $2}' | sort | uniq | wc -l
> >> Last metadata expiration check: 0:03:06 ago on Tue 10 Jul 2018 12:17:44
> BST.
> >> 9314
> > Just one more comment about this number and why this is quite precise
> > number of the packages which even not now depends on gcc soon maybe
> > have such dependency.
>
> AFAIK, the list of packages where "BR: gcc{,-g++}" was added had been
> compiled based on real rebuild errors and not on some artificial query.
>

Yes, I've performed 5 mass-scratch-rebuilds, grepped logs for some common
errors and then added BuildRequires. It might be inaccurate for some of the
packages (e.g. if they depend on something what should depend on gcc
itself), but it won't hurt anyone.


> The rest of you email is OT. Changing BR for every package is much
> simpler task then adding BR to packages where it belongs.
>
>
> V.
>
> > Simple someone may bring as the argument that not all x86_64
> > containing packages now needs gcc.
> > That is (now) 100% true however it is one additional fact: related to
> > LTO optimisation.
> >
> > On use LTO optimisation is necessary to use gcc-{ar,nm,ranlib}
> > executable and so far even if some non-C/C++ compilers may be able to
> > produce .o LTO aware bytecode to be able link using ld to produce
> > final DSO or ELF executables.
> > In such cases I don't think that it will be possible to use  such
> > compilers straight (like ada, go or other) if someone will be trying
> > to use LTO optimisation.
> > This will probably force to go over produce asm -> as [-> ar/ranlib] ->
> ld.
> > In such pipeline LTO aware wrappers are part of the gcc.
> >
> > # rpm -qf /usr/bin/gcc-{ar,nm,ranlib}
> > gcc-8.1.1-4.fc29.1.x86_64
> > gcc-8.1.1-4.fc29.1.x86_64
> > gcc-8.1.1-4.fc29.1.x86_64
> >
> > LTO still is not prod ready and I found that it produces now some
> > highly unstable binaries. In case od zabbix code I found that
> > zabbix_agentd crashes and zabbix_server on processing triggers using
> > pcre library functions (which has not been optimised using LTO)
> > produces binaries which behaves not as expected (producing negated
> > values).
> > If someone is interested is bugzilla ticket about this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1567112
> >
> > In other words even if now not all binaries may have straight gcc
> > dependency as long as LTO will be stable it will change.
> > Looks like clang/llvm 7 will be able produce LTO aware bytecode so
> > from this point of view probably it can be used as full gcc
> > replacement even to use LTO.
> > https://llvm.org/docs/LinkTimeOptimization.html
> > In other words above adds last few missing lines to the picture with
> > title "why putting gcc BRs is/was wrong?"
> >
> > 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
> > 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/A6JBPULBPEFIUYBCD3C66QHRFIVYEKOY/
>
> ___
> 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/VQCAF7DR27Y4ZBZW46XJ6N6ZM3YK5OTE/
>
-- 

-Igor Gnatenko
___
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/YWNEOD3R6XTCIVML7QWLQKR3JYHRIMIY/

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, 10 Jul 2018 at 10:57, Vít Ondruch  wrote:
[..]
> Explicit "BR: gcc" definitely does the switch to other compiler easier,
> because one of the main question for this change was actually "how many
> packages actually requires C/C++" and it was quite tricky to answer such
> question. Now it will much easier.

FYI using dnf repoquery you don't need to guesses as now is possible
to produce precise/exact such metrics value using oneliner like below.

# dnf -C repoquery --qf "%{name}.%{arch} %{source_name} %{reponame}" |
grep -w rawhide | grep x86_64 | awk '{print $2}' | sort | uniq | wc -l
Last metadata expiration check: 0:03:06 ago on Tue 10 Jul 2018 12:17:44 BST.
9314

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

Orphaning metamorphose2

2018-07-10 Thread Pierre-Yves Chibon

Good Morning Everyone,

metamorphose2 is a small wxPython (GUI) app allowing to mass-rename files.
The last commit upstream is from July 22nd 2016, so almost 2 years ago.
It fails to build from source now.

I'm intending to orphan it.

If someone is interested in picking it up, let me know and I'll give it to you
:)


Pierre


signature.asc
Description: PGP 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/V2TVQLEOHRK7A46HKD7Y2DCMFAKFV267/

[Bug 1596132] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip [fedora-all]

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



--- Comment #3 from Fedora Update System  ---
perl-Archive-Zip-1.59-6.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ebebe9abe2

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

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Vít Ondruch



Dne 10.7.2018 v 14:03 Tomasz Kłoczko napsal(a):
> On Tue, 10 Jul 2018 at 12:26, Tomasz Kłoczko  wrote:
> [..]
>> # dnf -C repoquery --qf "%{name}.%{arch} %{source_name} %{reponame}" |
>> grep -w rawhide | grep x86_64 | awk '{print $2}' | sort | uniq | wc -l
>> Last metadata expiration check: 0:03:06 ago on Tue 10 Jul 2018 12:17:44 BST.
>> 9314
> Just one more comment about this number and why this is quite precise
> number of the packages which even not now depends on gcc soon maybe
> have such dependency.

AFAIK, the list of packages where "BR: gcc{,-g++}" was added had been
compiled based on real rebuild errors and not on some artificial query.

The rest of you email is OT. Changing BR for every package is much
simpler task then adding BR to packages where it belongs.


V.

> Simple someone may bring as the argument that not all x86_64
> containing packages now needs gcc.
> That is (now) 100% true however it is one additional fact: related to
> LTO optimisation.
>
> On use LTO optimisation is necessary to use gcc-{ar,nm,ranlib}
> executable and so far even if some non-C/C++ compilers may be able to
> produce .o LTO aware bytecode to be able link using ld to produce
> final DSO or ELF executables.
> In such cases I don't think that it will be possible to use  such
> compilers straight (like ada, go or other) if someone will be trying
> to use LTO optimisation.
> This will probably force to go over produce asm -> as [-> ar/ranlib] -> ld.
> In such pipeline LTO aware wrappers are part of the gcc.
>
> # rpm -qf /usr/bin/gcc-{ar,nm,ranlib}
> gcc-8.1.1-4.fc29.1.x86_64
> gcc-8.1.1-4.fc29.1.x86_64
> gcc-8.1.1-4.fc29.1.x86_64
>
> LTO still is not prod ready and I found that it produces now some
> highly unstable binaries. In case od zabbix code I found that
> zabbix_agentd crashes and zabbix_server on processing triggers using
> pcre library functions (which has not been optimised using LTO)
> produces binaries which behaves not as expected (producing negated
> values).
> If someone is interested is bugzilla ticket about this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1567112
>
> In other words even if now not all binaries may have straight gcc
> dependency as long as LTO will be stable it will change.
> Looks like clang/llvm 7 will be able produce LTO aware bytecode so
> from this point of view probably it can be used as full gcc
> replacement even to use LTO.
> https://llvm.org/docs/LinkTimeOptimization.html
> In other words above adds last few missing lines to the picture with
> title "why putting gcc BRs is/was wrong?"
>
> 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
> 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/A6JBPULBPEFIUYBCD3C66QHRFIVYEKOY/

___
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/VQCAF7DR27Y4ZBZW46XJ6N6ZM3YK5OTE/

[Bug 1596132] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip [fedora-all]

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



--- Comment #2 from Fedora Update System  ---
perl-Archive-Zip-1.60-3.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6abfa0012f

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

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Richard Hughes

On Tue, 10 Jul 2018 at 13:35, Tomasz Kłoczko  wrote:
> IMO even if he has some potential I'm guessing that he is still
> relatively young and if it is true he may still need proper mentoring

Not cool, you stepped over the line. Igor has done some great work in
Fedora in the last few months.

Richard.
___
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/FMVOGK3LH5W7TD4DGBAY5SCVCH2QS5IB/

[Bug 1596132] CVE-2018-10860 perl-Archive-Zip: Directory traversal in Archive::Zip [fedora-all]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Archive-Zip-1.60-4.fc2
   ||9



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

Re: Hiding the grub menu by default on single OS installs

2018-07-10 Thread Christian Glombek

Hello Everyone,

Regarding boot success determination:
For the current Fedora GSoC project that I am participating in, I wrote
greenboot, a generic health check framework for systemd:
https://github.com/LorbusChris/greenboot
In greenboot, health checks can be defined in the form of scripts and/or
systemd units. This could be useful in this case for determining boot
success, allowing for more sophisticated checks than just a timer.

Maybe it's a little late to get this into F29, as the project is not in the
Fedora repos, yet (it is being build on copr: lorbus/greenboot) and there
are still some improvements to be made, but it'll certainly be ready by the
time F30 is coming.

WDYT?

Thank you Javier to pointing me to this.

Regards,

Christian Glombek
FAS Lorbus


Am Sa., 30. Juni 2018 um 17:12 Uhr schrieb Nicolas Mailhot <
nicolas.mail...@laposte.net>:

> Le samedi 30 juin 2018 à 14:32 +0200, Hans de Goede a écrit :
>
> Hi
>
> > > 4. you check every single bit needed to use them works before
> > > declaring a boot successful
> >
> > A boot is declared successful if a user logs in (or the
> > user session starts if autologin is enabled) and the
> > usersession lasts at least 2 minutes. So even if login
> > works, but then for some reason the session crashes immediately
> > afterwards, that still will NOT count as a boot success.
>
> It'd be nice if there was a way to check grub2-editenv works (some dummy
> action that is tested on boot). I've lost the number of times I had to
> re-run anaconda on a system just to reinstall the boot stack, because it
> tends to bork itself on hardware or selinux changes and there is no
> clear way to reinit it.
>
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> 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/O23PNWENZ4H7FH6W5PE6QK34B4DBHKT2/
>
___
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/LR2FRLPTQW7COV44SYMBGQXL4NA5DTCR/

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, 10 Jul 2018 at 12:52, Till Maas  wrote:
[..]
> > PS. And really I don't care that again above will be taken as kind of
> > personal attack (which is not my intention).
>
> The Fedora Code of Conduct is not optional therefore I expect you to
> care about this. If you believe your e-mail might be offensive, it is
> your job to ensure that it is not.

Sorry to say this without telling openly some past stories straight
about things which only few people knows it is not possible to
understand why at the moment I'm not able to trust what Igor is doing.
One time it may be accident ..
Truth is that not one but at least few time he miscarried few things.
I would be not surprised if I'll be not only person with such
experience.
IMO even if he has some potential I'm guessing that he is still
relatively young and if it is true he may still need proper mentoring
(however I'm not going or want to be his mentor)
I can honestly promise that if he will be somehow cross the line with
things which sometimes I'm trying to take care next time my reaction
will be as same as before. You may say that from this point of view
I'm 100% predictable.

IMO he needs to learn meaning of some old sentence "Errare humanum est
perseverare autem diabolicum"
If he will not learn few thing I don't want to be around next time.

If you or someone else can give me the lesson how to say above without
hurting someone personal fillings or not act as someone offensive I'm
really ready to pay whatever price someone will ask for.

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

[Bug 1599722] New: perl-Test-mysqld-1.0010 is available

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

Bug ID: 1599722
   Summary: perl-Test-mysqld-1.0010 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-mysqld
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.0010
Current version/release in rawhide: 1.-2.fc29
URL: http://search.cpan.org/dist/Test-mysqld/

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

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

Re: [HEADS UP] Removal of GCC from the buildroot

On Tue, 10 Jul 2018 at 12:26, Tomasz Kłoczko  wrote:
[..]
> # dnf -C repoquery --qf "%{name}.%{arch} %{source_name} %{reponame}" |
> grep -w rawhide | grep x86_64 | awk '{print $2}' | sort | uniq | wc -l
> Last metadata expiration check: 0:03:06 ago on Tue 10 Jul 2018 12:17:44 BST.
> 9314

Just one more comment about this number and why this is quite precise
number of the packages which even not now depends on gcc soon maybe
have such dependency.
Simple someone may bring as the argument that not all x86_64
containing packages now needs gcc.
That is (now) 100% true however it is one additional fact: related to
LTO optimisation.

On use LTO optimisation is necessary to use gcc-{ar,nm,ranlib}
executable and so far even if some non-C/C++ compilers may be able to
produce .o LTO aware bytecode to be able link using ld to produce
final DSO or ELF executables.
In such cases I don't think that it will be possible to use  such
compilers straight (like ada, go or other) if someone will be trying
to use LTO optimisation.
This will probably force to go over produce asm -> as [-> ar/ranlib] -> ld.
In such pipeline LTO aware wrappers are part of the gcc.

# rpm -qf /usr/bin/gcc-{ar,nm,ranlib}
gcc-8.1.1-4.fc29.1.x86_64
gcc-8.1.1-4.fc29.1.x86_64
gcc-8.1.1-4.fc29.1.x86_64

LTO still is not prod ready and I found that it produces now some
highly unstable binaries. In case od zabbix code I found that
zabbix_agentd crashes and zabbix_server on processing triggers using
pcre library functions (which has not been optimised using LTO)
produces binaries which behaves not as expected (producing negated
values).
If someone is interested is bugzilla ticket about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1567112

In other words even if now not all binaries may have straight gcc
dependency as long as LTO will be stable it will change.
Looks like clang/llvm 7 will be able produce LTO aware bytecode so
from this point of view probably it can be used as full gcc
replacement even to use LTO.
https://llvm.org/docs/LinkTimeOptimization.html
In other words above adds last few missing lines to the picture with
title "why putting gcc BRs is/was wrong?"

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

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Till Maas

Hi,

On Tue, Jul 10, 2018 at 08:42:09AM +0100, Tomasz Kłoczko wrote:

> At the bottom I want only flag that people like Igor as they have
> proven packager perms are able to make at the end more harm than good.
> I don't know him (how experienced developer he really is) as my only
> personal contact with him was when on IRC he asked me where my texinfo
> PR and bugzilla ticket are.
> If some wide changes so badly prepared and conducted will happen again
> IMO someone at least should consider withdraw his proven packager
> privs.

I am glad for Igor doing this work and he is doing a lot more good than
harm.

> kloczek
> PS. And really I don't care that again above will be taken as kind of
> personal attack (which is not my intention).

The Fedora Code of Conduct is not optional therefore I expect you to
care about this. If you believe your e-mail might be offensive, it is
your job to ensure that it is not.

Kind regards
Till
___
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/T47HPT7BUWHC2NPMGHY274HEDUI4ZJMA/

Orphaning eclipse-xtext and dependencies

2018-07-10 Thread Aleksandar Kurtakov

eclipse-xtext and its dependencies eclipse-xpand and eclipse-emf-mwe have
just been orphaned. Eclipse SIG has no use of these packages anymore
(despite them being really active upstream), the build system is quite
complicated and they haven't been properly kept upto date lately.

-- 
Alexander Kurtakov
Red Hat Eclipse 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/53UPH4FPNNFZVXEUZFKOSQCSN5BM5OZG/

Re: Packages which needlessly use %defattr

2018-07-10 Thread Nico Kadel-Garcia

On Mon, Jul 9, 2018 at 7:53 PM, Jason L Tibbitts III  wrote:
>> "KF" == Kevin Fenzi  writes:
>
> KF> I agree. If this could be done before mass rebuild we can catch any
> KF> issues/typos/mistakes in this with the mass rebuild.
>
> I've been away from computers for a bit, but I could certainly do this
> without too much effort.  I just know that some people are somewhat...
> prickly about "their" packages and wanted to give some room for
> discussion.  But I will just go ahead and fix at least a big batch of
> these previous to the rebuild.  If someone really, really doesn't like
> it then I guess they can revert, but I do intend to keep running this
> and the rest of the reports I've been running recently.
>
> Also, the reason gdb didn't show up is because it uses yet another form
> of the line which I didn't account for: %defattr(-,root,root).  The fact
> that there are so many forms and most couldn't tell you which arguments
> are which (and yet copy it into their specfiles because some other
> specfile has it) is more than sufficient reason for removing it.
>
> Anyway, modifying the check for that additional defattr mode adds 306
> packages (not including gdb because it was fixed).  That list (in the
> usual format) is below.
>
> Finally, the checks I'm doing aren't intended to be comprehensive.  It
> only looks for one specific case.  After this is done I may work on
> auditing all of the remaining uses of defattr.

Would you please post, or post a link to, your updated filter script?
I'd be especially curious if it inserts a record of the work in the
%changelog stanza.

As good as you may be at writing such tools, I'd be a bit wary of "I
have this script that's touching hundreds or thousands of spec files,
and which I've updated again, and no one has seen the final form, but
you can verify my work by checking the thousands of modified RPM's
I've built". It seems somewhat risky.
___
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/VBHRCULXLQ2JEURRAODATRZGRP264O2U/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

On Tue, Jul 10, 2018 at 12:22 PM Vít Ondruch  wrote:

> Thank you for pushing this forward!
>
>
> One question though. I see that this works in Koji, but trying to test
> this locally it does not work.
>
> 1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --enablerepo=local
>
> This still installs gcc.
>
> 2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --disablerepo=* --enablerepo=local
>
> This fails:
>
> ~~~
>
> Warning: Module or Group 'buildsys-build' does not exist.
> Error: Nothing to do.
>
> ~~~
>
> Trying to get the latest comps from local repository:
>
> ~~~
>
>
> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repodata/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-comps.xml
>
> ~~~
>
> This has "build" group which references gcc/gcc-c++ and does not reference
> any buildsys-build group. So where is this file coming from? Why does it
> differ from regular Fedora repos?
>
This is  interesting question. I've sent PR to update comps
,
but I don't know how it is being pushed through… We should ask rel-eng to
help with this.

Mohan, Kevin?

>
> Thx
>
>
> Vít
>
>
>
>
> Dne 10.7.2018 v 01:03 Igor Gnatenko napsal(a):
>
> Hello everyone,
>
> today we finally dropped gcc and gcc-c++ from the buildroot
> . This
> made 12 packages go away along with 134MB installed size. This means that
> you need to add gcc/gcc-c++ in the BuildRequires (guidelines stated this
> for few years but not many were following them).
>
> Also Mark fixed bug today which was pulling in systemd in the buildroot
> which was pulling gnutls/libgcrypt/nettle and stuff like that. I don't have
> exact numbers what we saved here.
>
> But looking into simple package build for f28 and f29 I see some nice
> trend.
>
> F28:
> DEBUG util.py:439:  Install  179 Packages
> DEBUG util.py:439:  Total download size: 146 M
> DEBUG util.py:439:  Installed size: 570 M
>
> F29:
> DEBUG util.py:439:  Install  144 Packages
> DEBUG util.py:439:  Total download size: 87 M
> DEBUG util.py:439:  Installed size: 425 M
>
> ---
> Thanks for attention!
> --
>
> -Igor Gnatenko
>
>
> ___
> 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/TDPFN4KWRZNGGLS4PGWDRFHRKFLVOHXA/
>
>
> ___
> 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/ENPIJVO2Y7374F6UNTXG2LXR7UOQ7SQH/
>
-- 

-Igor Gnatenko
___
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/X7HNNFDUUA3ZBBEY6MDL3PG3CXQNIJWM/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

2018-07-10 Thread Mikolaj Izdebski

On 07/10/2018 12:14 PM, Vít Ondruch wrote:
> Thank you for pushing this forward!
> 
> 
> One question though. I see that this works in Koji, but trying to test
> this locally it does not work.

It should work with config generated with "koji mock-config" command:

  koji mock-config --tag f29-build --arch x86_64 >my.cfg
  mock -r ./my.cfg [...]

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/3NU5ZSNJDQTH4HD7RNZNZXLKKDOSTYDP/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

On Tue, Jul 10, 2018 at 2:17 AM Tomasz Kłoczko 
wrote:

> On Tue, 10 Jul 2018 at 01:02, Tomasz Kłoczko 
> wrote:
> [..]
> > > F28:
> > > DEBUG util.py:439:  Install  179 Packages
> > > DEBUG util.py:439:  Total download size: 146 M
> > > DEBUG util.py:439:  Installed size: 570 M
> > >
> > > F29:
> > > DEBUG util.py:439:  Install  144 Packages
> > > DEBUG util.py:439:  Total download size: 87 M
> > > DEBUG util.py:439:  Installed size: 425 M
> >
> > I'm almost 100% sure that it would be possible to save probably more
> > by remove generate Requires dependencies using {Lib,Requires}.private
> > out of .pc files (..)
>
> Yet another question..
> Did above storage used sizes are when all packages are installed with
> --excludedocs and --define="%_install_langs en,C"?
>

No. While we can probably assume that no one needs docs, the install_langs
is dangerous. See the
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
for existing proposal.
-- 

-Igor Gnatenko
___
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/VUUPHVNI4HE3KXQ24I4K24BL32N5ZO6P/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

On Tue, Jul 10, 2018 at 2:12 AM Tomasz Kłoczko 
wrote:

> On Tue, 10 Jul 2018 at 00:17, Igor Gnatenko
>  wrote:
> [..]
> > But looking into simple package build for f28 and f29 I see some nice
> trend.
> >
> > F28:
> > DEBUG util.py:439:  Install  179 Packages
> > DEBUG util.py:439:  Total download size: 146 M
> > DEBUG util.py:439:  Installed size: 570 M
> >
> > F29:
> > DEBUG util.py:439:  Install  144 Packages
> > DEBUG util.py:439:  Total download size: 87 M
> > DEBUG util.py:439:  Installed size: 425 M
>
> I'm almost 100% sure that it would be possible to save probably more
> by remove generate Requires dependencies using {Lib,Requires}.private
> out of .pc files (which are for static linking which is not possible
> to use on Fedora because only few devel packages provides static
> libraries) than generate 1.7k git changes and remove gcc from minimal
> set of packages. Not to mention that similar effect would be possible
> to reach by add gcc to glibc-devel and gcc-g++ to libbstdc++-devel
> requires.
>

I don't disagree with you. Moreover, I support this idea, but the problem
here is that you don't have way to say "hey, here is -static subpackage
which owns this .pc file, can you add auto-generated dependencies there?".
Once someone implements this in RPM (I would appreciate this because I have
use-case for Rust packages), we can submit Change Proposal and


> Just one technical question about forming stub Fedora build env
> (because I don't know how it is assembled).
> How it is done? Just one time by create minimal build image after add
> some set of new updates to official repository than snapshot and clone
> such image and use it as base on start build all new packages until
> next batch of packages will be pushed to repo used by build systems or
> every time which comes new build request such build env is assembled
> from scratch?
> Using for example btrfs and snapshosts would be possible to start
> adding all packages listed in BR instantly. Total storage overhead
> will be only ~150MB and nothing would be necessary to download to
> assemble such base build env. Cleanup all after finished build .. just
> remove shanpshot.
>

Every build it is generating new build environment. I also agree that
creating snapshot would be nice, but this is not implemented. If you would
like to work on this - I would appreciate that. In any case, you need to
talk to Koji  developers.
-- 

-Igor Gnatenko
___
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/4FUC2JOCZXVQJLTULUDCSQITCBB62F5N/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

2018-07-10 Thread Mathieu Bridon

Hi,

On Tue, 2018-07-10 at 12:14 +0200, Vít Ondruch wrote:
> One question though. I see that this works in Koji, but trying to
> test this locally it does not work.
> 1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --enablerepo=local
> This still installs gcc.
> 2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
> --disablerepo=* --enablerepo=local
> This fails:
> ~~~
> Warning: Module or Group 'buildsys-build' does not exist.
> Error: Nothing to do.
> ~~~
> Trying to get the latest comps from local repository:
> ~~~
> https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repoda
> ta/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-
> comps.xml
> ~~~
> This has "build" group which references gcc/gcc-c++ and does not
> reference any buildsys-build group. So where is this file coming
> from? Why does it differ from regular Fedora repos?

The groups in Koji are defined differently from the groups in the
Fedora repos.

In the repos, you can find them defined in the comps.xml file, for
example:

http://dl.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86
_64/os/repodata/b140b2b55e06b7ba6c765d27dd9dbae905745e788a97a390be8b829
80b8c282e-comps-Everything.x86_64.xml

This contains a `buildsys-build` group, which mock installs when
creating a chroot.

In Koji, the groups can be seen with the command:

$ koji list-groups f29-build
[… snip …]
build  [f29]
  bash: None, mandatory  [f29]
  bzip2: None, mandatory  [f29]
  coreutils: None, mandatory  [f29]
  cpio: None, mandatory  [f29]
  diffutils: None, mandatory  [f29]
  fedora-release: None, mandatory  [f29]
  findutils: None, mandatory  [f29]
  gawk: None, mandatory  [f29]
  grep: None, mandatory  [f29]
  gzip: None, mandatory  [f29]
  info: None, mandatory  [f29]
  make: None, mandatory  [f29]
  patch: None, mandatory  [f29]
  redhat-rpm-config: None, mandatory  [f29]
  rpm-build: None, mandatory  [f29]
  sed: None, mandatory  [f29]
  shadow-utils: None, mandatory  [f29]
  tar: None, mandatory  [f29]
  unzip: None, mandatory  [f29]
  util-linux: None, mandatory  [f29]
  which: None, mandatory  [f29]
  xz: None, mandatory  [f29]
[… snip …]
srpm-build  [f29]
  bash: None, mandatory  [f29]
  fedora-release: None, mandatory  [f29]
  fedpkg-minimal: None, mandatory  [f29]
  gnupg2: None, mandatory  [f29]
  redhat-rpm-config: None, mandatory  [f29]
  rpm-build: None, mandatory  [f29]
  shadow-utils: None, mandatory  [f29]

The `srpm-build` group is what gets installed in the chroot to build
the SRPM (see the buildSRPMFromSCM subtask in any build task) and the
`build` group is what gets installed when building binary RPMs (see the
buildArch subtasks in any build task).

I do not know **why** we have this difference between Koji and the main
repos, I just know that we do have it.

This change needs to be reflected in Comps, so that Mock installs the
same thing in its buildroots as Koji.


-- 
Mathieu
___
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/TB4YLBIHDCNORB4MHSAUVT2HXXN4MNAQ/

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

2018-07-10 Thread Vít Ondruch

Thank you for pushing this forward!


One question though. I see that this works in Koji, but trying to test
this locally it does not work.

1) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
--enablerepo=local

This still installs gcc.

2) $ mock -r fedora-rawhide-x86_64 rubygem-abrt-0.3.0-3.fc29.src.rpm
--disablerepo=* --enablerepo=local

This fails:

~~~

Warning: Module or Group 'buildsys-build' does not exist.
Error: Nothing to do.

~~~

Trying to get the latest comps from local repository:

~~~

https://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/repodata/db824c6dd6664943bcec0a8fcd3bda7fc855e5a787623c0da6d49deb79438fc7-comps.xml

~~~

This has "build" group which references gcc/gcc-c++ and does not
reference any buildsys-build group. So where is this file coming from?
Why does it differ from regular Fedora repos?


Thx


Vít




Dne 10.7.2018 v 01:03 Igor Gnatenko napsal(a):
> Hello everyone,
>
> today we finally dropped gcc and gcc-c++ from the buildroot
> .
> This made 12 packages go away along with 134MB installed size. This
> means that you need to add gcc/gcc-c++ in the BuildRequires
> (guidelines stated this for few years but not many were following them).
>
> Also Mark fixed bug today which was pulling in systemd in the
> buildroot which was pulling gnutls/libgcrypt/nettle and stuff like
> that. I don't have exact numbers what we saved here.
>
> But looking into simple package build for f28 and f29 I see some nice
> trend.
>
> F28:
> DEBUG util.py:439:  Install  179 Packages
> DEBUG util.py:439:  Total download size: 146 M
> DEBUG util.py:439:  Installed size: 570 M
>
> F29:
> DEBUG util.py:439:  Install  144 Packages
> DEBUG util.py:439:  Total download size: 87 M
> DEBUG util.py:439:  Installed size: 425 M
>
> ---
> Thanks for attention!
> -- 
>
> -Igor Gnatenko
>
>
>
> ___
> 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/TDPFN4KWRZNGGLS4PGWDRFHRKFLVOHXA/

___
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/ENPIJVO2Y7374F6UNTXG2LXR7UOQ7SQH/

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-10 Thread Vít Ondruch

Dne 10.7.2018 v 09:42 Tomasz Kłoczko napsal(a):
> On Tue, 10 Jul 2018 at 06:37, David Tardon  wrote:
> [..]
>>> My proposition is *not* to add gcc/g++ explicit to BuildReequires and
>>> use instead glibc-devel and libstdc++-devel modifications and ban use
>>> gcc/gcc-c++ in BuildRequires (in most of the cases all current
>>> gcc/g++
>>> BuildRequires could be replaced by glibc-devel and libstdc++-devel).
>>> All because it is not possible to use C compiler without glibc-devel
>>> and C++ compiler without libstdc++-devel.
>> It might be a surprise for you, but there are other implementations of
>> C and C++ standard libraries. If I try to imagine Fedora wanting to
>> switch to clang in the future,
> It is not but it is quite interesting how you are trying to move
> technical discussion to kind of "argumentum ad hominem" field.
>
>> I can very well imagine it wanting to
>> switch to libc++ at the same time... So your "improved" proposal is,
>> in fact, just as arbitrary and choice-limiting as the one you
>> criticize.
> So you want to tell that putting explicit gcc/gcc-g++ BRs makes such
> switching (which is less important) or test build (which is way more
> interesting and valuable options) easier and/or opens some option?
> Really?

Explicit "BR: gcc" definitely does the switch to other compiler easier,
because one of the main question for this change was actually "how many
packages actually requires C/C++" and it was quite tricky to answer such
question. Now it will much easier.

And of course if we can switch from no requires to "BR: gcc", then it
won't be harder to switch to "BR: clang". If we were going to switch to
another compiler, it even gives us the choice so selectively stay with
gcc , where previously it could be ambiguous which compiler is used 

BTW I am deliberately not going to read the rest of you email, because
it is simple too much words.

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

[Bug 1599499] perl-PPIx-Regexp-0.061 is available

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PPIx-Regexp-0.061-1.fc
   ||29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-10 05:19:31



--- Comment #1 from Petr Pisar  ---
An enhancement release safer for Rawhide only.

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

Re: [HEADS UP] Removal of GCC from the buildroot