Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Remi Collet]

Le 18/02/2018 à 18:09, Igor Gnatenko a écrit :
> If you fixed package(s), found false positive, found missing packages in list
> or anything else -- please let me know.

All php-* packages (C extensions) should already be ok, BR on php-devel
should be enough.



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

[389-devel] Please review: 49570 - x.py

[William Brown]

https://pagure.io/389-ds-base/issue/49570

https://pagure.io/389-ds-base/issue/raw/files/028eb1c97dced4e42e7923a8c
9340dcc84912630c5916f8bd18cd00047406cd2-0001-Ticket-49570-Make-build-
commands-easier-to-run-and-a.patch

-- 
Thanks,

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

Re: Scilab, rkward install in Rawhide: nothing provides libgfortran.so.4()

[Amit Saha]

> On Sat, Feb 17, 2018 at 11:05:39AM -, Amit Saha wrote:
> 
> Rebuild whatever fortran packages have failed during mass rebuild which
> should have fixed this.

Sorry - can you please clarify?

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

Re: Unannounced soname bump: gnome-desktop3

[Neal Gompa]

On Sun, Feb 18, 2018 at 10:10 PM,   wrote:
>
> On Sun, Feb 18, 2018 at 1:13 PM, Yaakov Selkowitz 
> wrote:
>>
>> gnome-desktop3 was updated a week ago to 3.27.90, which bumped ABI from
>> .so.12 to .so.17.  AFAICS no notice was given, nor am I sure that this
>> was even noticed by the maintainer, because once again:
>>
>> %{_libdir}/lib*.so.*
>>
>> I have rebuilt my affected package.
>
>
> The wildcard in the files list is particularly dangerous because GNOME
> packages are updated by a script; humans only look when there are build
> failures. And unlike most other GNOME libraries, gnome-desktop does not
> pretend to have a stable API.
>
> I've junt changed it to:
>
> %{_libdir}/libgnome-desktop-3.so.17*
>
> Belatedly, I realize that will break if the soname is ever bumped to 170.
> What is considered the best practice for this?
>

I usually use something like the following:

%global somajor 17
...
%{_libdir}/libgnome-desktop-3.so.%{somajor}{,.*}


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

Re: Unannounced soname bump: gnome-desktop3

[mcatanzaro]

On Sun, Feb 18, 2018 at 1:13 PM, Yaakov Selkowitz  
wrote:
gnome-desktop3 was updated a week ago to 3.27.90, which bumped ABI 
from

.so.12 to .so.17.  AFAICS no notice was given, nor am I sure that this
was even noticed by the maintainer, because once again:

%{_libdir}/lib*.so.*

I have rebuilt my affected package.


The wildcard in the files list is particularly dangerous because GNOME 
packages are updated by a script; humans only look when there are build 
failures. And unlike most other GNOME libraries, gnome-desktop does not 
pretend to have a stable API.


I've junt changed it to:

%{_libdir}/libgnome-desktop-3.so.17*

Belatedly, I realize that will break if the soname is ever bumped to 
170. What is considered the best practice for this?


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

Fedora Rawhide-20180218.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Kde live i386

Failed openQA tests: 24/129 (x86_64), 6/22 (i386), 1/2 (arm)

ID: 193702  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193702
ID: 193703  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193703
ID: 193717  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/193717
ID: 193725  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193725
ID: 193727  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193727
ID: 193728  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193728
ID: 193729  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193729
ID: 193730  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193730
ID: 193732  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193732
ID: 193733  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/193733
ID: 193743  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193743
ID: 193745  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/193745
ID: 193746  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193746
ID: 193747  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/193747
ID: 193748  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/193748
ID: 193749  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/193749
ID: 193750  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193750
ID: 193751  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193751
ID: 193752  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/193752
ID: 193762  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/193762
ID: 193767  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/193767
ID: 193785  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/193785
ID: 193786  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/193786
ID: 193791  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/193791
ID: 193792  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/193792
ID: 193802  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/193802
ID: 193810  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/193810
ID: 193811  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/193811
ID: 193835  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/193835
ID: 193840  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/193840
ID: 193846  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/193846

Soft failed openQA tests: 66/129 (x86_64), 14/22 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 193705  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/193705
ID: 193706  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/193706
ID: 193707  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/193707
ID: 193708  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/193708
ID: 193709  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193709
ID: 193726  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/193726
ID: 193764  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/193764
ID: 193765  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/193765
ID: 193768  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/193768
ID: 193769  Test: x86_64 universal 

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Chuck Anderson]

On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

These are fixed: flac123 fping fxload ocp perl-HTML-Strip sedutil

I retired msed because sedutil replaced it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: can't push to perl-HTML-Strip master

[Chuck Anderson]

On Sun, Feb 18, 2018 at 05:14:11PM -0800, Kevin Fenzi wrote:
> On 02/18/2018 04:29 PM, Chuck Anderson wrote:
> > Can someone please help me with this?  I'm listed as an admin on 
> > src.fedoraproject.org for perl-HTML-Strip, but I still cannot commit to 
> > master:
> > 
> >> fedpkg push
> > Enter passphrase for key '/home/cra/.ssh/fedora_rsa': 
> > X11 forwarding request failed on channel 0
> > Counting objects: 6, done.
> > Delta compression using up to 8 threads.
> > Compressing objects: 100% (6/6), done.
> > Writing objects: 100% (6/6), 846 bytes | 846.00 KiB/s, done.
> > Total 6 (delta 2), reused 0 (delta 0)
> > ^[[B^[[B^[[Bremote: FATAL: W refs/heads/master rpms/perl-HTML-Strip cra 
> > DENIED by fallthru
> > remote: error: hook declined to update refs/heads/master
> > To ssh://pkgs.fedoraproject.org/rpms/perl-HTML-Strip
> >  ! [remote rejected] master -> master (hook declined)
> > error: failed to push some refs to 
> > 'ssh://c...@pkgs.fedoraproject.org/rpms/perl-HTML-Strip'
> > Could not execute push: Command '['git', 'push']' returned non-zero exit 
> > status 1
> 
> Try now? I've regenerated the acls for that package and they look
> correct now.

Works now.  Thanks.

> Note: for things like you a releng or infrastructure ticket is the usual
> way to get them looked at.

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

Re: can't push to perl-HTML-Strip master

[Kevin Fenzi]

On 02/18/2018 04:29 PM, Chuck Anderson wrote:
> Can someone please help me with this?  I'm listed as an admin on 
> src.fedoraproject.org for perl-HTML-Strip, but I still cannot commit to 
> master:
> 
>> fedpkg push
> Enter passphrase for key '/home/cra/.ssh/fedora_rsa': 
> X11 forwarding request failed on channel 0
> Counting objects: 6, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (6/6), done.
> Writing objects: 100% (6/6), 846 bytes | 846.00 KiB/s, done.
> Total 6 (delta 2), reused 0 (delta 0)
> ^[[B^[[B^[[Bremote: FATAL: W refs/heads/master rpms/perl-HTML-Strip cra 
> DENIED by fallthru
> remote: error: hook declined to update refs/heads/master
> To ssh://pkgs.fedoraproject.org/rpms/perl-HTML-Strip
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to 
> 'ssh://c...@pkgs.fedoraproject.org/rpms/perl-HTML-Strip'
> Could not execute push: Command '['git', 'push']' returned non-zero exit 
> status 1

Try now? I've regenerated the acls for that package and they look
correct now.

Note: for things like you a releng or infrastructure ticket is the usual
way to get them looked at.

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Tom Hughes]

On 19/02/18 00:30, Hedayat Vatankhah wrote:

I've fixed all my packages except simspark & rcssserver3d, which seem to 
crash on i686 when generating docs using pdflatex, which will probably 
needs a fix in TeXLive.


Yes that's the crash that is blocking me as well... It is new since
the texlive rebuild last week for poppler and has caused the gdal
rebuild to fail.

Tom

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

[Test-Announce] 2018-02-19 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2018-02-19
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

Apologies for the late notice, but we haven't met for a few weeks, so I
thought we could do the meeting tomorrow - there's a few topics we
could talk about.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 28 status and branching
3. TCMSes again
4. Available tickets
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Hedayat Vatankhah]

Hi,
I've fixed all my packages except simspark & rcssserver3d, which seem to 
crash on i686 when generating docs using pdflatex, which will probably 
needs a fix in TeXLive.


Regards,
Hedayat

/*Igor Gnatenko*/ wrote on Sun, 18 Feb 2018 18:09:40 +0100:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt

Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.

If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.

Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).

List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

- -- 
- -Igor Gnatenko

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org


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

can't push to perl-HTML-Strip master

[Chuck Anderson]

Can someone please help me with this?  I'm listed as an admin on 
src.fedoraproject.org for perl-HTML-Strip, but I still cannot commit to master:

>fedpkg push
Enter passphrase for key '/home/cra/.ssh/fedora_rsa': 
X11 forwarding request failed on channel 0
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 846 bytes | 846.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
^[[B^[[B^[[Bremote: FATAL: W refs/heads/master rpms/perl-HTML-Strip cra DENIED 
by fallthru
remote: error: hook declined to update refs/heads/master
To ssh://pkgs.fedoraproject.org/rpms/perl-HTML-Strip
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 
'ssh://c...@pkgs.fedoraproject.org/rpms/perl-HTML-Strip'
Could not execute push: Command '['git', 'push']' returned non-zero exit status 
1

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

[Bug 1546590] New: perltidy-20180219 is available

[bugzilla]

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

Bug ID: 1546590
   Summary: perltidy-20180219 is available
   Product: Fedora
   Version: rawhide
 Component: perltidy
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org



Latest upstream release: 20180219
Current version/release in rawhide: 20180101-2.fc28
URL: http://search.cpan.org/dist/Perl-Tidy/

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

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

Re: dnf: Can't tell me what is pulling in a dependency?

[Nico Kadel-Garcia]

On Sun, Feb 18, 2018 at 9:10 AM, Richard Shaw  wrote:
> I was updating my mythtv box and I saw that it was pulling in some mysql
> community packages as a dependency but I looked through the options and I
> couldn't find ANYTHING that would tell me what was pulling in those
> packages. Nov "-v" and not "--debugsolver".
>
> Is it really not possible?
>
> Thanks,
> Richard

Yes, it's actually common place. You can select the relevant
mysql-community package if it is already installed and use "rpm -e
--test packagename" and see what would complain. Many binaries have a
dependency on "mysql-libs", and the version in mysql-community is
typically a more recent version than the base mysql package in fedora
or RHEL. My personal suspicion is postfix, which has MySQL library
dependencies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1546584] New: perl-Importer-0.025 is available

[bugzilla]

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

Bug ID: 1546584
   Summary: perl-Importer-0.025 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Importer
  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: 0.025
Current version/release in rawhide: 0.024-5.fc28
URL: http://search.cpan.org/dist/Importer/

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

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

Re: F29 System Wide Change: Remove GCC from BuildRoot

[Dennis Gilmore]

El vie, 16-02-2018 a las 12:56 +0100, Jan Kurik escribió:
> Proposed System Wide Change: Remove GCC from BuildRoot
> https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot
> 
> 
> Owner(s):
>   * Igor Gnatenko 
> 
> 
> Removing gcc and gcc-c++ from default buildroot in Koji and mock.
> 
> 
> 
> == Detailed description ==
> Since beginning of Fedora, gcc (and gcc-c++) are installed in every
> buildroot. Times have changed and nowadays many of packages are not
> written in C/C++, they are written in Python, Ruby, Node.js, Go,
> Rust,
> OCaml, Perl and so on so they don't need to have C/C++ compiler.
> Installing gcc and gcc-c++ takes time so if we remove it, we can
> improve build times for many of the packages.

What is the expected savinsg in time for builds? I realise it is hard
to measure, however it should only be a second or two per build at
most. Buildroot creation time is really not the slowest piece of the
pipeline. There is a lot of other areas that I feel would net a bigger
win. For instance machine learning bots to do package reviews and
package maintainenece, where changes like this could be automatically
built in to the package maintainece lifecycle.

Dennsi

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

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Dennis Gilmore]

El jue, 15-02-2018 a las 17:34 -0500, Matthew Miller escribió:
> As shown at https://www.happyassassin.net/nightlies.html, we haven't
> had a successful compose for almost two weeks. AIUI this is mostly
> worked out now, but it raises the question: who should be keeping
> track
> of this and coordinating fixes? For the releases, the blocker bug
> process basically handles this, so functionally the ownership ends up
> with QA (and the various heroes of QA who then track down all the
> problems). For rawhide, we don't have any such thing. Is it rel-eng?
> Is
> it FESCo? Is it the FPgM? Is it QA after all?
> 
> I suspect that right now, the answer is kind of "It's all of us
> together", which unfortunately practically speaking often comes down
> to
> 0.02% per person and rounds down to 0.
> 
> Or if the answer is: "Matthew, you are the FPL. It's you!" … then
> fine,
> but I'm going to then have to find some way to turn around and
> delegate. :)
> 
> I was chatting with Kevin Fenzi and he suggested naming a release
> manager for each release — someone who would keep track of stuff
> starting at branch, and help coordinate things like this.
> 
> This would help with more than just Rawhide — I'm sure everyone
> involved in the blocker bug process would be grateful for more help.
> At
> least, if it was someone who isn't already deeply involved in that.
> I'm
> thinking probably someone selected from FESCo — but it also could be
> a
> way for people with the particular set of skills required here to get
> involved in a way that's different from FESCo membership.
> 
> What do you think?

I think you are putting the cart before the horse slightly here. We
have a few issues that we need to address and that we have to
fundamentally step back and rethink how we put Fedora together. I feel
that your statement makes an assumption that how we do things today is
okay.

A fundamental issue we have today is that we have no way to test the
changes as they come in. As a result we hit apoint right before
branching where people put in a lot of change all at once, with the
result being it breaks things, we then get into fire fighting mode.
Having a project manager to stay on top of changes and change
management and trying to balance the change and get people to submit it
ealier may help some, but it would not fully address the issue of
making sure that the change is good.

I strongly believe that in order to really address the problem we need
to take a step back and look at the factory we have for making Fedora. 
 Today in order to make and ship Fedora we have a process that starts
by gathering by gathering together all of the rpms we have built,
putting them into a place so that we can feed them into making the
anaconda run time. Once we have the anaconda runtime we make the
distribution repos for the rpms and start the ostree creation. we then
create the Cloud images, containers, install dvd's, arm disk images,
livecd's etc. 

The entire process today is configured as a big blob. It requires that
the release engineer configuring the compose understand the end to end
process on how we build and ship everything. What the inputs for each
piece is, the expected outputs, and what pieces are required to make
other pieces. The way we have set things up means that the amount of
knowledge needed to be effecive is massive.  If you compare it to a
more traditional process, say a restaurant, you would have to go and
pick the fruits and vegetables that have been planted by someone else,
plan a extensive menu, answer the phone and take reservations, start
cooking the meals, greet the guest and seat them, take drink orders, go
make and deliver the drinks, take the meal orders, then go cook and
plate the meals, serve them to the guests and refresh drinks, make sure
that everyone is happy, once they are done eating clean the tables, and
take desert orders, go make plate and deliver desert, make any coffee
or tea thats required, deliver to the table, once the table is done,
you generate the bill, take it to the table, collect payment, then
clean up and do all the dishes after, wash the table linens and get
tings ready for the next meal.  If anything goes wrong during this
process that is run by a single person  you get to clean up and start
over from the start. That is a little long winded but shows how we have
not done the best by ourselves in how we have built and designed the
delivery of things today. Restaurants do not work in the way described
by a single person, neither does a car get built by having someone
design then build the car and get it out the door.  It can work for
special boutique offerings, it does not scale well for wide spread
distribution.

I would like to have us look at not only the processes for how we build
and ship the distribution. I have some ideas for how we can keep the
important pieces of how we build and ship things today, but give us the
flexibility to have the peices be more independent and controlled. 
Some 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 950  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 840  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 812  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 422  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 151  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  71  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  43  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  37  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab   
tomcat-7.0.84-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc1949f307   
p7zip-16.02-10.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-be69c94866   
clamav-0.99.3-8.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-87b20f1b26   
exim-4.90.1-2.el6


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

libidn2-2.0.4-3.el6
percolator-3.02.00-1.el6
seamonkey-2.49.2-2.el6

Details about builds:



 libidn2-2.0.4-3.el6 (FEDORA-EPEL-2018-8651f03a5a)
 Library to support IDNA2008 internationalized domain names

Update Information:

- Added upstream patch to fix STD3 ASCII rules (#1543021)

References:

  [ 1 ] Bug #1543021 - libidn2: Guidance needed for avoiding STD3 rules
https://bugzilla.redhat.com/show_bug.cgi?id=1543021




 percolator-3.02.00-1.el6 (FEDORA-EPEL-2018-9bd0b4a689)
 Software for postprocessing of shotgun proteomics data

Update Information:

- Update to 3.02.0 - Drop old patches - Link to libtirpc on fedora




 seamonkey-2.49.2-2.el6 (FEDORA-EPEL-2018-76121890f9)
 Web browser, e-mail, news, IRC client, HTML editor

Update Information:

Update to 2.49.2  Based on the Firefox/Thunderbird ESR (extension support
release) code version 52.6.1  Fixes various security issues, see
https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/ and
https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ for
more info.

References:

  [ 1 ] Bug #1545970 - seamonkey-2.49.2.source is available
https://bugzilla.redhat.com/show_bug.cgi?id=1545970

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

Re: to batch or not to batch?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Feb 18, 2018 at 11:40:47AM +0100, Fabio Valentini wrote:
> On Sat, Feb 17, 2018 at 11:15 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > Bodhi currently provides "batched updates" [1] which lump updates of
> > packages that are not marked urgent into a single batch, released once
> > per week. This means that after an update has graduated from testing,
> > it may be delayed up to a week before it becomes available to users.
> >
> > Batching is now the default, but maintainers can push theirs updates
> > to stable, overriding this default, and make the update available the
> > next day.
> >
> > Batching is liked by some maintainers, but hated by others
> > Unfortunately, the positive effects of batching are strongly
> > decreased when many packages are not batched. Thus, we should settle
> > on a single policy — either batch as much as possible, or turn
> > batching off. Having the middle ground of some batching is not very
> > effective and still annoys people who don't like batching.
> 
> (snip)
> 
> > To summarize the ups (+) and downs (-):
> >
> > + batching reduces the number of times repository metadata is updated.
> >   Each metadata update results in dnf downloading about 20-40 mb,
> >   which is expensive and/or slow for users with low bandwidth.
> 
> This savings effect is negligible, because metadata has to be updated
> even if only 1 urgent security update is pushed to stable.

[FTR, it's any urgent update, security or not.]
Yes, but we don't have urgent updates every day. Even if we have them
every other day, that'd still be 50% reduction in metadata downloads.

> > + a constant stream of metadata updates also puts strain on our mirrors.
> >
> > + a constant stream of updates feels overwhelming to users, and a
> >   predictable once-per-week batch is perceived as easier. In
> >   particular corporate users might adapt to this and use it to
> >   schedule an update of all machines at fixed times.
> 
> I'd rather want to see a small batch of updates more frequently than a
> large batch that I won't care to read through.

Yes, but I think you are in the minority. I'm pretty sure most users
don't bother reading descriptions. Of course it's hard to gauge this,
but I'd expect that with the frequency of updates in Fedora only very
dedicated admins can look at every package and every changelog. Most
people install the whole set and investigate only if something goes
wrong.

> > + a batch of updates may be tested as one, and, at least in principle,
> >   if users then install this batch as one, QA that was done on the
> >   batch matches the user systems more closely, compared to QA testing
> >   package updates one by one as they come in, and users updating them
> >   at a slightly different schedule.
> 
> Well, is any such testing of the "batched state" being done, and if it
> is, does it influence which packages get pushed to stable?

Sorry, I don't think we have any data on this. Maybe adamw and other
QA people can pitch in?
 
> > - batching delays updates of packages between 0 and 7 days after
> >   they have reached karma and makes it hard for people to immediately
> >   install updates when they graduate from testing.
> 
> This delay can be circumvented by maintainers by pushing directly to
> stable instead of batched (thereby rendering the batched state
> obsolete, however).

I meant that it is hard for *end-users*. Essentially, end users lose
the control of the timing, even though individual maintainers can still
control the timing of their updates.

> > - some users (or maybe it's just maintainers?) actually prefer a
> >   constant stream of small updates, and find it easier to read
> >   changelogs and pinpoint regressions, etc. a few packages at a time.
> 
> I certainly belong to this group.
> 
> > - batching (when done on the "server" side) interferes with clients
> >   applying their own batching policy. This has two aspects:
> >   clients might want to pick a different day of the week or an
> >   altogether different schedule,
> >   clients might want to pick a different policy of updates, e.g. to
> >   allow any updates for specific packages to go through, etc.
> >
> >   In particular gnome-software implements its own style of batching, where
> >   it will suggest an update only once per week, unless there are security
> >   updates.
> 
> Which further delays the distribution of stable updates by up to a
> week (depending on the schedule of gnome-software, I didn't check
> that). That makes a total of up to 3 weeks (!).
> 
> > Unfortunately there isn't much data on the effects of batching.
> > Kevin posted some [2], as did the other Kevin [3] ;), but we certainly
> > could use more detailed stats.
> >
> > One of the positive aspects of batching — reduction in metadata downloads,
> > might be obsoleted by improving download efficiency through delta downloads.
> > A proof-of-concept has been implemented [4].
> 
> A simpler approach might be to just flush all 

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Tomasz Kłoczko]

On 18 February 2018 at 20:52, Igor Gnatenko
 wrote:
[..]
>> Yesterday I've replayed on your proposal but I've not realized that my
>> reply was held by the moderator.
>> You started introducing changes only after less than 24h after
>> publishing proposal.
>> It does not make any sense sending any proposals if you will be not
>> waiting for feedback at least few days :-/
>
> I didn't introduce any changes, I just made mass rebuild and asked people to
> fix their packages.

Gosh .. you are right.
Really sorry :-/
After spotting +1k new emails notifications I did not check who made
those changes and I've been thinking that it was some mass change
introduced by one of the proven packagers.

It does not look good if people before finishing discussion on
*proposal* will be making changes :-/

Or maybe everything has been triggered not by the proposal but by this
thread which has in the Subject "[ACTION NEEDED]" ?

[..]
>> Q: does it really needs to be gcc? What about clang?
>> A: theoretically it does not need to be gcc .. especially as macros
>> like %cmake, %configure are injecting over CC, CXX and other variables
>> exact commands.
>
> Yes, theoretically. I think the real reason is because we want explicitly to
> use GCC and nothing else.

Looks like this intention has not been verbalised in the proposal.
Here few questions related to such intention.

If Fedora provides more than one C/C++ compilers and both are in the
main part of the distribution -> Why Fedora packages must be glued
statically to gcc/gcc-c++ as C/C++ compilers?
Maybe there are more unverbalised intentions related to such assumption?

Or maybe it is something wrong with clang?
I'm asking because I don't know anything about such issues.
FreeBSD is using now clang/llvm to compile everything so it would be a
real surprise if it is already some known big issue.

[..]
> Are you willing to work on Guidelines Draft for FPC on this? Right now I just
> want to get rid out of gcc/gcc-c++ in buildroot and I chose following
> **existing guidelines** as a base for this while what you are proposing
> requires coordination with FPC.

I've drafted only some idea which was not complete.
Have no idea where did you get this that I'm willing anything.

> I'm not against this idea at all, but this is totally outside of scope of this
> change. In any case, once we will have necessary BuildRequires all over the
> place we can easily replace them with whatever we will decide is correct.

This is not about arrogance.
If you will be just stopping reading after the first sentence you are
exposing yourself to miss something.

In this first sentence literally was that what is below is out of the
scope of the proposal.
In reply where only a few humble question and asking for few seconds
to consider modify original scope to open some new possibilities.
Now looks like it is to late and changes already started :-(

kloczek
PS. If you really don't like my comments just add my email to spam
filters and let me know about this in prv email.
I promise that I'll never reply to any of your emails.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Robert-André Mauchin]

On dimanche 18 février 2018 18:09:40 CET Igor Gnatenko wrote:
> Over this weekend I've performed scratch-mass-rebuild without having gcc
> and gcc-c++ in buildroot of all Fedora packages, many of which failed due
> to random reasons and I grepped all logs for some common errors found by
> analyzing hundreds of build logs.
> 
> Guidelines:
> https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
> s_and_Requies
> 
> The grep output is located here:
> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> 
> Some packages might be missed due to short koji outage, broken dependencies
> and so on, but majority of real failures is below.
> 
> If you fixed package(s), found false positive, found missing packages in
> list or anything else -- please let me know.
> 

Fixed:
eclipseo   cmrt libva-intel-hybrid-driver qdirstat zegrapher


Best regards,

Robert-André

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

drpm

[Zbigniew Jędrzejewski-Szmek]

On Sun, Feb 18, 2018 at 01:13:26PM -, Artur Iwicki wrote:
> By the way - does drpm handling depend on repo / mirror settings? I
> ask because I'm under the impression that lately hardly any package
> update on my system is done via delta-RPMs; it's about 1-in-100 or
> so. Is this more a matter of me needing to tweak dnf config, or can
> this depend on the package mirrors?
Indeed. I think something changed, because it certainly used to be more
like half of packages, but now I'm seeing just 3 drpms vs 188 full
downloads in a dnf update, and 0 vs 88 on another.

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

[Bug 1544283] perl-Mojolicious-7.66 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.66-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2018-02-18 16:20:34



--- Comment #2 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/packageinfo?packageID=10481

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

[Bug 1546413] perl-Moose-2.2010 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Moose-2.2010-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-18 16:12:17



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1045787

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

Re: Removal of BuildRoot

[Athos Ribeiro]

On Sun, Feb 18, 2018 at 09:13:22AM +0100, Pierre-Yves Chibon wrote:
> On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
> > On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  
> > wrote:
> > >> "DS" == David Sommerseth  writes:
> > >
> > > DS> False positives are also easily filtered out by adding .rpmlint to
> > > DS> the dist-git repository.
> > >
> > > Which is an absolutely terrible name for that.  Really.  Why would
> > > anyone at all ever think it is a good idea to _hide_ the file that
> > > controls that?
> > >
> > 
> > I agree. What do we need to do to change this to .rpmlintrc?
> 
> A pull-request to fedpkg or rpkg sounds like a good start :)

https://pagure.io/rpkg/pull-request/293

-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 20:45 +, Philip Kovacs wrote:
> Ok, my configure.ac initializes libtool with both c and c++ :
> LT_INIT()LT_LANG([C])LT_LANG([C++])
> where only C is needed.   There are no ill-effects other than producing some
> noise in the configureoutput, but I will patch out the LT_LANG([C++]) line to
> trim the noise.

Yeah, either you need to add BuildRequires: gcc-c++ or remove this
LT_LANG([C++]). If you won't do any of this, it will stop building 

Thanks for fixing!
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJ6DUACgkQaVcUvRu8
X0wHBhAAiVfDEOBkaS7MYEsRNglSLRq1i0s9PUe5LTjFN2+5ORO7++CHzUo9tQXx
Ca3RYMD9F8hMG0lyqcVmqElWJsnBhnZkytyXxH295ZrUffD2ZPs1cpK6eN+8bcIh
BzWKJqHLlWSBGZqX6xRqSDXq36H8yZL5+IpsyDFkkqC6zfXn/9H8e1yoq+NMzAyr
iHWfHjkvcZgnLz5h/RSpTWCsjGhoCP8vuG0993VXDn/AEX7wAPWNCuS2RITUzfiD
TiekSEn9vOUiFIHPmpUYdfHhVVGt06PCnmTJVNrZnuQ94Yu9FKR+1Lg+BavzyHz7
BjZvvH5iOggrlTAsjCrVgKj5VCiS/LAQchnxkDSPh1iZJsBJ3AsdaIqzNZwKdkGa
qBUDJVmwFwavpzqSHzmEJo9XSBgIJJ/8HT/E5oEEOLZ+eZrAZWLjGMSOmYC4JN7I
atE1LfkFZhLytHMMy1jnXEgBiSHDptZdMNtNpJpYMLgpAJPwLC5XlSQdInp0yZ8A
/MlqPwGRcthpD0LGpnFPWJtiaAmHad2s6jq6vTIvV1RkPjjzze4xwup8Aw7R2P55
8W+SbE9+mVQiZbUKNRZS82C44go/8qEvRfxXpVeFPDBdTcgWxIdHWOgnv6DvUJXC
IkmzL03cS2aqC/IngeFvUCUgZuFp3ko/jenuT5yHKkt1QC5qh/I=
=3gzd
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 20:36 +, Tomasz Kłoczko wrote:
> On 18 February 2018 at 17:09, Igor Gnatenko
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Over this weekend I've performed scratch-mass-rebuild without having gcc
> > and
> > gcc-c++ in buildroot of all Fedora packages, many of which failed due to
> > random
> > reasons and I grepped all logs for some common errors found by analyzing
> > hundreds of build logs.
> 
> Yesterday I've replayed on your proposal but I've not realized that my
> reply was held by the moderator.
> You started introducing changes only after less than 24h after
> publishing proposal.
> It does not make any sense sending any proposals if you will be not
> waiting for feedback at least few days :-/

I didn't introduce any changes, I just made mass rebuild and asked people to
fix their packages.

> Here is the copy of my yesterday reply:

I have seen it, but as usual with your messages (which are very long and mix
different things) I stopped reading after second paragraph..

> Q: does it really needs to be gcc? What about clang?
> A: theoretically it does not need to be gcc .. especially as macros
> like %cmake, %configure are injecting over CC, CXX and other variables
> exact commands.

Yes, theoretically. I think the real reason is because we want explicitly to
use GCC and nothing else.

> As long as none of the macros like %cmake or %cobfigure has straight
> dependency and are not forcing to use gcc (those macros are using
> other macros like %{__cc}) already it possible to test build package
> written in C using C++ compiler to for example expose some set of
> compile warnings generated by C++ compiler or .. use clang.
> Build the whole package with using some C code security scanners? No
> problem. It is possible to do this without touching spec file.

Actually csmock already can do that. Probably not in very nice way, but it
works.

> Now by default %/{__cc} is provided by gcc but if here it will be
> introduced small flexible it should be possible to control which
> the compiler should be used even if in packagers build system will be
> installed both gcc and clang by simple few changes in ~.rpmrc or on
> Fedora build systems in ~mock/.rpmrc file.
> 
> So maybe instead:
> 
> BuildRequires: gcc
> 
> better would be to use:
> 
> BuildRequires: %{__cc}
> 
> or:
> 
> BuildRequires: c-compiler
> 
> ??
> if  both gcc and clang will have:
> 
> Provides: c-compiler
> 
> still it will be possible installed gcc and clang without conflicts.
> I'm sure that above it is not complete idea and few small bits still
> are missing.
> 
> I think that we should hold for few seconds and consider change a bit
> this proposal to pen those possibilities.

Are you willing to work on Guidelines Draft for FPC on this? Right now I just
want to get rid out of gcc/gcc-c++ in buildroot and I chose following
**existing guidelines** as a base for this while what you are proposing
requires coordination with FPC.


I'm not against this idea at all, but this is totally outside of scope of this
change. In any case, once we will have necessary BuildRequires all over the
place we can easily replace them with whatever we will decide is correct.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJ54AACgkQaVcUvRu8
X0zGLBAAuOA1jXfXJFdOaqhsTDBeANpTpS7zwFOZmbBpuAAq6cVpWyAcaGiJwNiE
EBYvpUJKZsSoVAMP4E2rneKnjgje9TAA8/ccpcrmv8b8iBf4qyx/uwEJIo3skFpB
qcOonXZamMm4v/afb1rVWbG6ogKS+1TPZ3YN/N8iaie8XHt4s/jcla/Miv3Yz6Gv
Y9NwzOQ8kkYr5Z6hVwWs07kjZHbkccaAa7u218Gho2hlhPLrhguKXm3SvcfQETit
F5wBeyxDPgAdNLhsDwXeeIYeClJsj91Z7YDCyfPZaB9vKMuap/dHsz/GWtT7kLNW
RaLlci0K0ElCx/Y/Ogdjk64su3//TkIjVRVG3fcPfqAu7bO7C7rvO3VFEAeYcqeP
K/ZQ39rbqs7vADPu5FgWnWE+Wryddh843Y7m7Qo1yj+G+/JXrX0dkl6a++mtiz/E
OVaq+sGiwnQOYtygRoLQ3a9jKduLOwAx8V7ghnUFnuZqOUy3XmHPJfAM9Htb0XWt
jpNBHo5BL/vM66QcNFrSPO/OiVwYnCrCMkKYPgPhWK7RGR1dmB+5lk2B8GTeuhwt
525iOfu2ivfU84oOoZXiXKbJPufRtWeg9cAwWJ3bGoKEEz9KLVBlQXilOWwTSBkb
faTPfcn9dD3LL4oH78ladalsb0f7qAZGgozsm2lBTR+9bTqJQT8=
=Ll0I
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Tomasz Kłoczko]

On 18 February 2018 at 18:06, Stephen John Smoogen  wrote:
[..]
>> I think that you are not fully aware what you've just done.
>
> Actually I am fully aware. I have been agreeing with parts of what you
> have written but you keep thinking I am attacking you because I don't
> agree with everything you have written. Then you keep interpreting
> everything I say as some sort of agenda.

It is really sad to see a comment ignoring almost all technical
argumenta and main analogy with how kernel tree is maintained.
Instead, you are focusing *only* on one (first) sentence commenting
what do you think that I'm thinking.
Plase stop doing this and try to focus on the subject.

I can only say that you completely missed my point.
Please read my reply one more time and try to not think about who
wrote this reply, or at least try to read this reply without first
sentence.

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

Re: Intent to retire: zerofree

[Richard W.M. Jones]

On Sun, Feb 18, 2018 at 09:19:09PM +0100, Robert Scheck wrote:
> On Sun, 18 Feb 2018, Richard W.M. Jones wrote:
> > There's also a more serious data safety issue: Although this probably
> > works OK for ext2 since that format is frozen in time, it probably
> > corrupts ext4 filesystems containing features that it doesn't know
> > about.
> > 
> > It is for these reasons that I don't think you should use this package
> > and I intend to retire it unless anyone says otherwise.
> 
> Last time I used it (a year ago?) it worked properly for ext3 and ext4, but
> on RHEL rather on Fedora. Not sure which features you are talking about in
> detail, but bumping zerofree from 1.0.3 to 1.1.0 would add 64 bit block no.
> support at least...

Would fstrim or virt-sparsify have worked for you?

I feel that supporting something which has been rejected by the
e2fsprogs community is difficult, especially when it concerns data
integrity.

If you wish to take it over, I can orphan it instead.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Philip Kovacs]

Ok, my configure.ac initializes libtool with both c and c++ :
LT_INIT()LT_LANG([C])LT_LANG([C++])
where only C is needed.   There are no ill-effects other than producing some 
noise in the configureoutput, but I will patch out the LT_LANG([C++]) line to 
trim the noise.


On Sunday, February 18, 2018 3:37 PM, Tomasz Kłoczko 
 wrote:
 

 On 18 February 2018 at 17:09, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to 
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.

Yesterday I've replayed on your proposal but I've not realized that my
reply was held by the moderator.
You started introducing changes only after less than 24h after
publishing proposal.
It does not make any sense sending any proposals if you will be not
waiting for feedback at least few days :-/


Here is the copy of my yesterday reply:


As definitely proposed change will create the whole wave of small
changes adding at least one new BuildRequires I just started thinking
about going slightly deeper (but only a bit deeper ;) ).

When gcc or other compilers are no longer part of the core build env
suit/env as you mention it is necessary to add it straight in
BuildRequires for example gcc.
That is OK.

Q: does it really needs to be gcc? What about clang?
A: theoretically it does not need to be gcc .. especially as macros
like %cmake, %configure are injecting over CC, CXX and other variables
exact commands.

As long as none of the macros like %cmake or %cobfigure has straight
dependency and are not forcing to use gcc (those macros are using
other macros like %{__cc}) already it possible to test build package
written in C using C++ compiler to for example expose some set of
compile warnings generated by C++ compiler or .. use clang.
Build the whole package with using some C code security scanners? No
problem. It is possible to do this without touching spec file.

OK, so .. at the moment macros like:

%__cc gcc
%__cpp gcc -E
%__cxx g++

are defined in /usr/lib/macros which is part of the rpm.
If those macros will be removed from this file and moved to
/usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
the platform which will open the whole spectrum of completely new
possibilities with some minimal changes in whole build env and no
other changes in all specs.
Only weak point in above is how to force use gcc if both gcc and clang
will be installed (which will be quite typical in case all packages
private build envs).
However, I think that even this is a very small obstacle which can be
easily handled.

Now by default %/{__cc} is provided by gcc but if here it will be
introduced small flexible it should be possible to control which
the compiler should be used even if in packagers build system will be
installed both gcc and clang by simple few changes in ~.rpmrc or on
Fedora build systems in ~mock/.rpmrc file.

So maybe instead:

BuildRequires: gcc

better would be to use:

BuildRequires: %{__cc}

or:

BuildRequires: c-compiler

??
if  both gcc and clang will have:

Provides: c-compiler

still it will be possible installed gcc and clang without conflicts.
I'm sure that above it is not complete idea and few small bits still
are missing.

I think that we should hold for few seconds and consider change a bit
this proposal to pen those possibilities.


Comments?

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


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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Athos Ribeiro]

On Sun, Feb 18, 2018 at 11:09 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> If you fixed package(s), found false positive, found missing packages in
> list
> or anything else -- please let me know.

python-compreffor
rats

Fixed in rawhide



-- 
Athos Ribeiro

http://www.ime.usp.br/~athoscr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Tomasz Kłoczko]

On 18 February 2018 at 17:09, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to 
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.

Yesterday I've replayed on your proposal but I've not realized that my
reply was held by the moderator.
You started introducing changes only after less than 24h after
publishing proposal.
It does not make any sense sending any proposals if you will be not
waiting for feedback at least few days :-/


Here is the copy of my yesterday reply:


As definitely proposed change will create the whole wave of small
changes adding at least one new BuildRequires I just started thinking
about going slightly deeper (but only a bit deeper ;) ).

When gcc or other compilers are no longer part of the core build env
suit/env as you mention it is necessary to add it straight in
BuildRequires for example gcc.
That is OK.

Q: does it really needs to be gcc? What about clang?
A: theoretically it does not need to be gcc .. especially as macros
like %cmake, %configure are injecting over CC, CXX and other variables
exact commands.

As long as none of the macros like %cmake or %cobfigure has straight
dependency and are not forcing to use gcc (those macros are using
other macros like %{__cc}) already it possible to test build package
written in C using C++ compiler to for example expose some set of
compile warnings generated by C++ compiler or .. use clang.
Build the whole package with using some C code security scanners? No
problem. It is possible to do this without touching spec file.

OK, so .. at the moment macros like:

%__cc gcc
%__cpp gcc -E
%__cxx g++

are defined in /usr/lib/macros which is part of the rpm.
If those macros will be removed from this file and moved to
/usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
the platform which will open the whole spectrum of completely new
possibilities with some minimal changes in whole build env and no
other changes in all specs.
Only weak point in above is how to force use gcc if both gcc and clang
will be installed (which will be quite typical in case all packages
private build envs).
However, I think that even this is a very small obstacle which can be
easily handled.

Now by default %/{__cc} is provided by gcc but if here it will be
introduced small flexible it should be possible to control which
the compiler should be used even if in packagers build system will be
installed both gcc and clang by simple few changes in ~.rpmrc or on
Fedora build systems in ~mock/.rpmrc file.

So maybe instead:

BuildRequires: gcc

better would be to use:

BuildRequires: %{__cc}

or:

BuildRequires: c-compiler

??
if  both gcc and clang will have:

Provides: c-compiler

still it will be possible installed gcc and clang without conflicts.
I'm sure that above it is not complete idea and few small bits still
are missing.

I think that we should hold for few seconds and consider change a bit
this proposal to pen those possibilities.


Comments?

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 14:18 -0600, Greg Hellings wrote:
> Igor
> 
> On Sun, Feb 18, 2018 at 11:09 AM, Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > If you fixed package(s), found false positive, found missing packages in
> > list
> > or anything else -- please let me know.
> > 
> > 
> 
> biblesync

Doesn't seem that it should have BuildRequires: gcc, because based on grep it
wants only CXX compiler.

> mingw-nspr

Looks good.

> Fixed

Thanks!
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJ4rMACgkQaVcUvRu8
X0wh7g/+LntjNx+M/8zkY/bTAFC7GhNB3lljvp/1rBH/IdUYJvDUcqeObuTXY9nG
3WZmmAKe5mRbepxiR2CIRHzdKu8fIXdsRPSQ1zFPlRPOsczqRsOhW/HWH1p2XTS/
To9CHHige6Nq8BGmIzjLZ43u1LpNfrzhmadcCiK2UEERJWGLX64mbrY9281XsPjw
t65+40ygnXlzzQ0LFziiOFBCVmcOowsbWrmV/IYl8FWFpI4ouepQRdv/dUljm9J5
3H9sEC+1Bvmr08f2Sh+edxYFv4vqAacTqdEAvEu5zuAqts1Dk+TyDImeOwCQkTFn
VAbaS5oTU0CYd5EWa+ec93B3BsJr6EhttkKFYSi2XDUPkwJCa+8YmWjWY0s/Yoop
HNlKxQl8b7Ch56NwWTbSOEQc4/a0k97WChQIlW6U5/IFmhRDy2vCjmRJdmzxOeRo
opSpXnfY4scym53VLg/bpWNXqKnE5wu0evK9CcfAcgnBgsaQeQpn8JDp/+faCYZV
tOrtSvlnFq/vyn3IqhWedpgUAkHf4GmrubjtU6rTQtVEIWRKsOO4sJKF2Qcpc3U9
/ZIVNHfmEaUgGQAgQFMtWTHZFEtKNw1aPXH1pBxBvQWqOvph+vMTYW22IoYkPuYP
W1RLkOvXMgTO6gUCY2S6NtyDvw781F5Kh7QJBxjuw0lA26lYTIs=
=f07h
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1546523] perl-Mouse-2.5.2 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mouse-2.5.2-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-18 15:25:23



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1045775

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

Re: Intent to retire: zerofree

[Chris Adams]

Once upon a time, Robert Scheck  said:
> On Sun, 18 Feb 2018, Richard W.M. Jones wrote:
> > There's also a more serious data safety issue: Although this probably
> > works OK for ext2 since that format is frozen in time, it probably
> > corrupts ext4 filesystems containing features that it doesn't know
> > about.
> > 
> > It is for these reasons that I don't think you should use this package
> > and I intend to retire it unless anyone says otherwise.
> 
> Last time I used it (a year ago?) it worked properly for ext3 and ext4, but
> on RHEL rather on Fedora. Not sure which features you are talking about in
> detail, but bumping zerofree from 1.0.3 to 1.1.0 would add 64 bit block no.
> support at least...

Also note that zerofree does something different than fstrim; fstrim
only works on block devices that support discard, while zerofree will
work on any type of device.

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Greg Hellings]

Igor

On Sun, Feb 18, 2018 at 11:09 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> If you fixed package(s), found false positive, found missing packages in
> list
> or anything else -- please let me know.
>
>
biblesync
mingw-nspr

Fixed

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

Re: Intent to retire: zerofree

[Robert Scheck]

On Sun, 18 Feb 2018, Richard W.M. Jones wrote:
> There's also a more serious data safety issue: Although this probably
> works OK for ext2 since that format is frozen in time, it probably
> corrupts ext4 filesystems containing features that it doesn't know
> about.
> 
> It is for these reasons that I don't think you should use this package
> and I intend to retire it unless anyone says otherwise.

Last time I used it (a year ago?) it worked properly for ext3 and ext4, but
on RHEL rather on Fedora. Not sure which features you are talking about in
detail, but bumping zerofree from 1.0.3 to 1.1.0 would add 64 bit block no.
support at least...


Regards,
  Robert


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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 20:06 +, Philip Kovacs wrote:
> False positive on project pmix.  I checked my rawhide build logs for all six
> arches and there is no `checking for c++`, as you report, in the autotools
> configure output. The project is a C project and the spec properly lists
> BuildRequires: gcc`.  There is nothing wrong and nothing to do. 

- From latest build log
(https://kojipkgs.fedoraproject.org//packages/pmix/2.1.0/2.fc28/data/logs/x86_6
4/build.log):
checking for g++... g++

but you don't have BuildRequires: gcc-c++

> On Sunday, February 18, 2018 2:53 PM, Tom Hughes  wrote:
>  
> 
>  On 18/02/18 19:01, Igor Gnatenko wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > On Sun, 2018-02-18 at 18:53 +, Tom Hughes wrote:
> > > On 18/02/18 17:09, Igor Gnatenko wrote:
> > > 
> > > > Over this weekend I've performed scratch-mass-rebuild without having
> > > > gcc
> > > > and
> > > > gcc-c++ in buildroot of all Fedora packages, many of which failed due
> > > > to
> > > > random
> > > > reasons and I grepped all logs for some common errors found by
> > > > analyzing
> > > > hundreds of build logs.
> > > > 
> > > > Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#Buil
> > > > dReq
> > > > uire
> > > > s_and_Requies
> > > > 
> > > > The grep output is located here:
> > > > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> > > 
> > > I can see python-mapnik at least in there is one of mine and I'll
> > > be happy to fix it once the current dependency hell in rawhide allows
> > > me to build it...
> > 
> > Just push commit, not necessary to build it right away.
> 
> Tried that with mapnik and ldconfig scriptlets and I'm still
> trying to get a build three weeks later ;-)
> 
> I've pushed it now anyway, and also fixed libdwarf and osmpbf.
> 
> Tom
> 

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJ3dMACgkQaVcUvRu8
X0x8CQ/+JOYdE+mFwiTko7I23xC2jIMEl+H4ADIw1Dn6OdLa8bh6xAPcm5Nh+y/c
A/r/IubYi8ujRzc6PGD5n0P4dmCU7PPoKZXiX2Dd15Dinf211wJMluBWgKjqakQX
eH5S8QV25x7fNEi+BmgtR8lxHYY71uQAOpnB+Zz91FgN3Qx+lhlAqyzBtF9v0cEx
6hNxiEsgWfMxZ5ul8lBpNufHxvLXw6xpM27c/f52T4ebuSoCe35jtA072Gn0UmPn
9yhOZqKSjIqrhV39UzyF/wfgLGIjBGyLM/7k6u6NBRdHSu/tIInVrGhaOS7Mo/QR
yjQcO8ZCfqsuHQZ8cFaeoyzPqIwBLmxz0k1BJkHMdlolZ2HGcUmVdySBq+yF57Y5
JWDAhn7OGjQQOAqmj9d8bD4Ww/4NW51pmhGD8iDHIry2IP2Fqe1zLGwUWxQOx1v6
+4KJrkbdaj62ZSaII+CSIY//3a4pmZcPvu5TwyuG+UXQS8rtK2mMo5EbUD+RCGnR
hD9cUVtLMmt/DWoD8+ENAb9stmhVJAxbJnuz3V44phdykL/UQ0w4Nty7h2Xg3vlO
JDchM3pEeaXyvUD67p+4Z1ns8zUYBo2jUEPnNLSfKzXkBTGwTUi2Vw8EyfvXQ45x
qnj141ZUwbQYY2B8lPTderQHDos2riPg8LCvavcmDMCPx4Y34Ho=
=VmA6
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Philip Kovacs]

False positive on project pmix.  I checked my rawhide build logs for all six 
arches and there is no `checking for c++`, as you report, in the autotools 
configure output. The project is a C project and the spec properly lists 
BuildRequires: gcc`.  There is nothing wrong and nothing to do. 

On Sunday, February 18, 2018 2:53 PM, Tom Hughes  wrote:
 

 On 18/02/18 19:01, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, 2018-02-18 at 18:53 +, Tom Hughes wrote:
>> On 18/02/18 17:09, Igor Gnatenko wrote:
>>
>>> Over this weekend I've performed scratch-mass-rebuild without having gcc
>>> and
>>> gcc-c++ in buildroot of all Fedora packages, many of which failed due to
>>> random
>>> reasons and I grepped all logs for some common errors found by analyzing
>>> hundreds of build logs.
>>>
>>> Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildReq
>>> uire
>>> s_and_Requies
>>>
>>> The grep output is located here:
>>> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
>>
>> I can see python-mapnik at least in there is one of mine and I'll
>> be happy to fix it once the current dependency hell in rawhide allows
>> me to build it...
> 
> Just push commit, not necessary to build it right away.

Tried that with mapnik and ldconfig scriptlets and I'm still
trying to get a build three weeks later ;-)

I've pushed it now anyway, and also fixed libdwarf and osmpbf.

Tom

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


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

[Bug 1546520] perl-Perl6-Export-Attrs-0.000006 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Perl6-Export-Attrs-0.0
   ||6-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-18 14:53:57



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1045762

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Tom Hughes]

On 18/02/18 19:01, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 18:53 +, Tom Hughes wrote:

On 18/02/18 17:09, Igor Gnatenko wrote:


Over this weekend I've performed scratch-mass-rebuild without having gcc
and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to
random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildReq
uire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt


I can see python-mapnik at least in there is one of mine and I'll
be happy to fix it once the current dependency hell in rawhide allows
me to build it...


Just push commit, not necessary to build it right away.


Tried that with mapnik and ldconfig scriptlets and I'm still
trying to get a build three weeks later ;-)

I've pushed it now anyway, and also fixed libdwarf and osmpbf.

Tom

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

Re: dnf: Can't tell me what is pulling in a dependency?

[Sérgio Basto]

On Sun, 2018-02-18 at 09:13 -0500, Neal Gompa wrote:
> On Sun, Feb 18, 2018 at 9:10 AM, Richard Shaw 
> wrote:
> > I was updating my mythtv box and I saw that it was pulling in some
> > mysql
> > community packages as a dependency but I looked through the options
> > and I
> > couldn't find ANYTHING that would tell me what was pulling in those
> > packages. Nov "-v" and not "--debugsolver".
> > 
> > Is it really not possible?
> > 
> > 
> 
> One way is to rerun the transaction with "--exclude=community-
> mysql*".
> Paired with --assumeno, it'll give you the proposal and not do it.

dnf repoquery -q --whatprovides mysql

community-mysql-0:5.7.18-2.fc26.x86_64
community-mysql-0:5.7.20-1.fc26.x86_64
mariadb-3:10.1.21-5.fc26.x86_64
mariadb-3:10.1.30-2.fc26.x86_64


but on update is strange that pull community-mysql, because you should
have mariadb already.  

on install you may do :
dnf install mythtv mariadb mariadb-server 

and shouldn't pull any community-mysql package I hope .


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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Artur Iwicki]

modem-manager-gui and tworld have been fixed on all actively used branches.

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

Unannounced soname bump: gnome-desktop3

[Yaakov Selkowitz]

gnome-desktop3 was updated a week ago to 3.27.90, which bumped ABI from
.so.12 to .so.17.  AFAICS no notice was given, nor am I sure that this
was even noticed by the maintainer, because once again:

%{_libdir}/lib*.so.*

I have rebuilt my affected package.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Richard W.M. Jones]

On Sun, Feb 18, 2018 at 07:54:28PM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, 2018-02-18 at 18:38 +, Richard W.M. Jones wrote:
> > On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > Over this weekend I've performed scratch-mass-rebuild without having
> > > gcc and gcc-c++ in buildroot of all Fedora packages,
> > 
> > Do you mind me asking how long that took (weekend = 2 days?!) and what
> > sort of computing resources you used?  I'd like to compare it to the
> > rebuild we're doing for riscv64.
> 
> Yes, 2 days (7 hours less if I would notice out of disk space). It was that
> fast because 5k builds (1/4 of all packages) failed pretty quickly with 
> missing
> gcc 
> 
> * 4x Intel(R) Xeon(R) CPU E7-8860 v4 @ 2.20GHz
> * 256 GiB RAM
> 
> Actually not all resources have been used, I had 10 koji builders on this
> server with 12 CPUs and 16G memory each.

Interesting stuff, I didn't think it would be so fast even given the
dependency failures.

On:

* 16 x Intel(R) Xeon(R) CPU E5-2609 v4 @ 1.70GHz
* 64 GB RAM

it's probably going to take something like 5 or 6 days to mass rebuild
for Fedora/RISC-V (using qemu-system-riscv64).

This is not very comparable however because: (a) we're not recompiling
any noarch packages, we're just copying those in from Koji, and
(b) probably only 20% of the archful packages can be successfully
recompiled at this time.

Status if interested:

  https://fedorapeople.org/groups/risc-v/autobuild-status.html

(it updates at the bottom of the page).

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 18:53 +, Tom Hughes wrote:
> On 18/02/18 17:09, Igor Gnatenko wrote:
> 
> > Over this weekend I've performed scratch-mass-rebuild without having gcc
> > and
> > gcc-c++ in buildroot of all Fedora packages, many of which failed due to
> > random
> > reasons and I grepped all logs for some common errors found by analyzing
> > hundreds of build logs.
> > 
> > Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildReq
> > uire
> > s_and_Requies
> > 
> > The grep output is located here:
> > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> 
> I can see python-mapnik at least in there is one of mine and I'll
> be happy to fix it once the current dependency hell in rawhide allows
> me to build it...

Just push commit, not necessary to build it right away.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJzaQACgkQaVcUvRu8
X0x65RAAhv0qKTntxBoa+TWsVE52crKK2pIfkDBLIptPQatMR1PQRdQH4eAF2Ahp
eoL35tiTK5qWF9uc3Oicb6GMBUUVPAKdU3njRdHxxqOgbxW7t64MTClDU7TuDALX
YD8f3O32zL0JEF7/E3S7J6Eq/xjTXb+DJeP78FI8CfLGVyLX3sZt1POHn3l5NUG2
OC2WPoobFRJ34FOVBW6SlGFX+/hXZAvfbqYndEkLaYbJUSCytke8ldkT8GTTxdD8
lX1+sVkFAtby4m6pVIB6Mtre6/1cPCSo2XMpoIFHmmGn9SBHPrfGRagCadf5NG5Z
oxR55c24to5FU3MYk/CbU7yOTh5CyubWC1ZZRz998Ismy7cVzHtSxt/A7qQbzM2S
C/a1R4mvIgR+o0eK5GyA0oZcCS1+EJskl7BMQzi5Yby4ffAmWoaTbCdQndwQGam6
GMiZS16xHBxG0Axw5ylFtxoVz+/w0Ah+gRmIwoztGlo28k4pZMwJvqQjgl15m82+
bGlJSm4EQFpfbPGKv+2msD3QuECLxMeHplwYNG6BjXKKG7BH4GHyrgPLiKzTDn0u
sy3QYPyEfiZYmtgrWFzlSa1SvGkYulEOKZg6649/185AOzTmzyFSodpNhsGyis3/
5fnKA2z961km1nXJtvejOIgseVL4VrtsHWalzY1Ew0kx8DhQNjg=
=5mXE
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 19:44 +0100, Göran Uddeborg wrote:
> Is there any way for me as a regular packager to test my fixes?  The
> "how to test" section on the wiki
> (https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot#How_To_Test
> )
> still says "mock with configuration provided (TODO)".  I tried a
> standard mock build, with mock version 1.4.8-1, and it succeeded
> WITHOUT any fix.

You can copy mock's fedora-rawhide-x86_64 config file and replace:
- -config_opts['chroot_setup_cmd'] = 'install @buildsys-build'
+config_opts['chroot_setup_cmd'] = 'install bash bzip2 coreutils cpio diffutils
fedora-release findutils gawk grep gzip info make patch redhat-rpm-config rpm-
build sed shadow-utils tar unzip util-linux which xz'

Half of this is not really needed, but kinda outside of scope of this change.
All these packages were taken from comps.xml and simply removed gcc/gcc-c++
from that list.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJzQYACgkQaVcUvRu8
X0zdEQ/8DlH6+DgxYVt6XmNNnlIgNRg40D4BEuMKzYNvIcJAYi05ePBzMJDqeywa
vt2rfhiCrm4f35Y1tK4alnZY327CnUk13hNfnBw4Z7k/ldJzC9gdx3e+QyiSo6Lz
B4Q8bSW5RGnoWQtgNJUt8HMbXQGFr8lPxk07O0DPTGtQEmPl69SEpzuPdIWhGi/i
yh+SZEG/MuKqIRXzFrZ59/UWkM1K4R5vzZnkb0IoiLhRC6I/OkKDvjKCwJmLKFH3
kHSENgcgrqFhIplrZD+KOoxXHZByMfphz2iOVNxVds2dddmXke5wxd/HqlFyjcFL
VE0RniNH9OASwbFW5XTxVFAtgT2k0PlAaE0QlzWNfiZTir+e5K8Sj2aBg5lp73Ee
rEPXntPwOf2tSknjPTKU0vGu5qci2i5CSgyyZjCqyg8JRzh1V6IuyLuzkIDMV0H8
8W9SiINndkhxYtFTMNt9pFuffrDzUl8fWQUK93IYenZmeXoy4na7u7NKPD8vHNha
RNos7HUlFtXSka5Ve6UxjO3ckz6q9DXC8KutD+Ayq2a/JlQjMSJ1FqhiXIXVYZFF
wG8SIXsyRwg1p2Wm323Ldh/Ogex2rZRwufrRPGMKZF6aeRo5qekvItUyFWENkaoU
M50IDTHvYBa3Mkg65lNnGoVpz+9B7yE6sPADhQxcryzjac3fdYY=
=wfNq
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 18:38 +, Richard W.M. Jones wrote:
> On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Over this weekend I've performed scratch-mass-rebuild without having
> > gcc and gcc-c++ in buildroot of all Fedora packages,
> 
> Do you mind me asking how long that took (weekend = 2 days?!) and what
> sort of computing resources you used?  I'd like to compare it to the
> rebuild we're doing for riscv64.

Yes, 2 days (7 hours less if I would notice out of disk space). It was that
fast because 5k builds (1/4 of all packages) failed pretty quickly with missing
gcc 

* 4x Intel(R) Xeon(R) CPU E7-8860 v4 @ 2.20GHz
* 256 GiB RAM

Actually not all resources have been used, I had 10 koji builders on this
server with 12 CPUs and 16G memory each.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJy+QACgkQaVcUvRu8
X0zdhRAAvb2LZC3r45AVGFAZ7Te9E0Vtk9v0sfW0xVgKB9Cexc4Z0jvvJh8xt1FY
KroQClpKHCQilJoWxyYdpB4HF/IcvWlVNN1yS8CNTsxoOwSblUcClSom9K229iRh
vjRVnEbXXwBpKUucV4DwKagwe//WF0GRRD8s3c4ReYy4R6FuNQewmQ/YsSCRsH6S
OxF4UM6ta0DOaJHNFVOtUg9XVlRRXog63OZB6X62CO4qk/TQHB7LaAIrbORPXD86
JGxKvM1u2UUZf+kEXCOlLNJe51denLTdFZ0elU1y329o4mqH57jGOdwfZsI84aWS
/QYdUP4i5lQrfAa7v26yygo6bXmdL2xPXqUdGSH5t8cMOgNHyeL/m9qyUE7NCRsg
OK5iHfi5tOpvWqtgn4ebh2t0p/9wvtqlDWNpAk3KRfSwTlXbjxnlK0apbQSb/VPC
LLBJjA5nF56aEVmgJd8V5duGfX7gyqhdgAfDMFJuU8emacxU3EaIFM9XbIKT30W7
HdXJraO9kXJBHH9x9kvGQycxYx0Jhn63pdwI/pfvGIyYDhzPSUaINRk6byHRMw2b
tVuQ5joVz4GCZQ61ro4TiqIVyMISB5v1ASFRxefq86U5RqXMGM0TUkncrZsApkIZ
M1T8Yfupb51zPNfkYw6J3coKbaNi18mvrfNoXgn6CugCNyvAm5M=
=4E2m
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Tom Hughes]

On 18/02/18 17:09, Igor Gnatenko wrote:


Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt


I can see python-mapnik at least in there is one of mine and I'll
be happy to fix it once the current dependency hell in rawhide allows
me to build it...

Tom

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

Intent to retire: zerofree

[Richard W.M. Jones]

zerofree is a package that can take an ext2 (only?) filesystem, work
out what parts of the filesystem are not used, and either zero them or
sparsify them.

This was useful in about 2009 when I added it to Fedora.  However
nowadays it's more convenient to use the equivalent kernel
functionality (via the ‘fstrim’ command or equivalent ioctls).  The
kernel functionality also works correctly for other filesystem types.

There's also a more serious data safety issue: Although this probably
works OK for ext2 since that format is frozen in time, it probably
corrupts ext4 filesystems containing features that it doesn't know
about.

It is for these reasons that I don't think you should use this package
and I intend to retire it unless anyone says otherwise.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Göran Uddeborg]

Is there any way for me as a regular packager to test my fixes?  The
"how to test" section on the wiki
(https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot#How_To_Test)
still says "mock with configuration provided (TODO)".  I tried a
standard mock build, with mock version 1.4.8-1, and it succeeded
WITHOUT any fix.


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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Richard W.M. Jones]

On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having
> gcc and gcc-c++ in buildroot of all Fedora packages,

Do you mind me asking how long that took (weekend = 2 days?!) and what
sort of computing resources you used?  I'd like to compare it to the
rebuild we're doing for riscv64.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1459433] Unescaped % character in changelog

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Plack-1.0047-1.fc27 has been pushed to the Fedora 27 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2808f7d416

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Ed Marshall]

On Sun, Feb 18, 2018 at 9:09 AM, Igor Gnatenko 
 wrote:
If you fixed package(s), found false positive, found missing packages 
in list

or anything else -- please let me know.


I've updated fritzing.

--
Ed Marshall 
Felix qui potuit rerum cognoscere causas.
https://esm.logic.net/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Todd Zullinger]

Hi Igor,

Igor Gnatenko wrote:
> If you fixed package(s), found false positive, found missing packages in list
> or anything else -- please let me know.

> git  amahdal besser82 chrisw pcahyna pstodulk skisela tmz
> paperkey fale tmz

These are both fixed.  I pushed git on Friday, but likely
during or after your mass-rebuild.  I had fixed paperkye
locally when this discussion started, but hadn't pushed it.
That's now down.

> cgit kevin praiskup tmz

I've got a scratch build running now, with some other
cleanups I had made locally (removing %{buildroot} cleanup
and removing old EL-5 conditionals among them).

Once I check that a bit I'll push it and cgit will be done
as well.

-- 
Todd
~~
Prejudice, n. A vagrant opinion without any visible means of support.
-- Ambrose Bierce, "The Devil's Dictionary"



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

Re: dnf: Can't tell me what is pulling in a dependency?

[Sérgio Basto]

On Sun, 2018-02-18 at 08:10 -0600, Richard Shaw wrote:
> I was updating my mythtv box and I saw that it was pulling in some
> mysql community packages as a dependency but I looked through the
> options and I couldn't find ANYTHING that would tell me what was
> pulling in those packages. Nov "-v" and not "--debugsolver".
> Is it really not possible?

it is debugsolver : 
dnf --debugsolver upgrade -b

but it is my fault I added Requires:  mysql-compat-server >=
5Requires:  mysql >= 5  
maybe we need added Suggests: mariadb-server  mariadb 
> Thanks,
> Richard
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of sln

[Richard W.M. Jones]

On Sun, Feb 18, 2018 at 04:06:31PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Feb 18, 2018 at 12:47:24PM +, Richard W.M. Jones wrote:
> > On Sat, Feb 17, 2018 at 04:08:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Feb 16, 2018 at 09:53:35PM +, Richard W.M. Jones wrote:
> > > > sln (staticly linked ‘ln’) was removed from glibc recently:
> > > > 
> > > >   https://bugzilla.redhat.com/show_bug.cgi?id=1531546
> > > > 
> > > > The explanation for this was:
> > > > 
> > > >   "The sln program is no longer useful, so we will not ship it anymore."
> > > > 
> > > > and it was removed from Rawhide 3 days later.
> > > > 
> > > > There are some %post scripts which still use this, notably
> > > > ca-certificates, so that's now broken.  But more to the point what do
> > > > you do if you are in a situation where you need to make a symlink to
> > > > save some core shared library on the currently running system?
> > > > 
> > > > I also don't think rather fundamental, useful and old tools like this
> > > > should be removed without discussion.
> > > 
> > > Why is normal ln not enough? It should be installed and runnable on
> > > pretty much any system, even during upgrades of glibc and other basic
> > > libraries.
> > 
> > The idea behind sln is that it works even if you've broken the libc
> > symlink.
> 
> Right. But does this really happen? In my experience, 10 years ago
> this kind of stuff happened, either because the tools were less
> reliable, or rather more likely because the human operating them
> didn't yet know how to operate them properly. I think we have all moved
> far in the direction of systems-as-cattle, and when we get to the point
> where libc is hosed, well, that's it, we provision a new installation.

The greater point was that our toolchain shouldn't make loads of
changes with minimal discussion.  This is just one example of several
which have happened recently:

 - removal of crypt
 - removal of xdr_* functions (breaking ABIs!) and rpcgen
 - adding flags which break CLANG
 - changes which break very long-standing assumptions around linking

These things need to be signalled _long_ (years) in advance and
coordinated with users.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1459433] Unescaped % character in changelog

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Plack-1.0047-1.fc26 has been pushed to the Fedora 26 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f06b7cf746

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

[Bug 1438957] icons are missing on bugzilla's front page

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
bugzilla-5.0.4-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b79f325c48

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

[Bug 1438957] icons are missing on bugzilla's front page

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
bugzilla-5.0.4-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-1e0e37e148

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

Re: Removal of BuildRoot

[Stephen John Smoogen]

On 18 February 2018 at 00:46, Tomasz Kłoczko  wrote:
> On 16 February 2018 at 15:50, Stephen John Smoogen  wrote:
> [..]
>>
>> Even before EPEL-5 was EOL, very little of Fedora would compile out of
>>
>> the box and required massive amounts of %if and other hacks to even
>> try to compile from a rawhide spec file.
>>
>> If someone wanted to keep compiling for EL-5 they should branch the
>> code themselves and maintain it as such versus trying to keep the
>> cruft in the main tree. I believe that is what arbitrary branching is
>> for.
>
>
> I think that you are not fully aware what you've just done.

Actually I am fully aware. I have been agreeing with parts of what you
have written but you keep thinking I am attacking you because I don't
agree with everything you have written. Then you keep interpreting
everything I say as some sort of agenda.

The part that you are not getting though is that even if I agree with
you on parts makes it that it will happen any time soon. Fedora is not
a centrally ruled organization. It is a collection of people doing
what they want and bringing what they want to the OS. They will follow
guidelines and rules to a point and only after they have each
convinced themselves that the rule/guideline makes sense to them. Any
time someone tries to make people do things even if it is in their
best interest, it causes a majority of members to get their backs up,
fight, and ignore the solution.

That is the part I have disagreed with you on. The idea that somehow
you can enforce a large change like this even if you did all the
changes yourself. People would revert them and route around them in
ways that may make the original problem worse. If you want to get
something done, you have to build group consensus and you have to show
what you want multiple times even if you think the 49th time should
have been enough. And show is not usually in words. It is in having
specs and tools which help people see why it fixes a problem. And
finally you have to realize that there will always be a thousand
corner cases which will trump a central rule for some reason and need
case by case exceptions.

This is all I am going to be saying on this.

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

Re: Changing config from a %post?

[Chris Adams]

Once upon a time, Reindl Harald  said:
> Am 16.02.2018 um 15:35 schrieb Chris Adams:
> >The imapproxy package config defaults to user "nobody", which should be
> >changed (probably should have been done a while back, but whatever).
> >The user is set in the config though, and the config has to be edited
> >for the package to work (to at least set the upstream IMAP server), so
> >changing the packaged config will only result in a .rpmnew file.
> >
> >What's the proper way to fix this?  I can update the package to create a
> >user and use it in the default config, but is it correct to have a %post
> >that changes the existing config (something like a "sed -i")?
> >
> >I'd also like to switch it from running in daemon mode to foreground
> >mode (and change the systemd unit to match), but again, that requires
> >editing the config; there's no command-line option for either of these.
> >
> >I'm not sure of the "best practice" here... as a system admin, it feels
> >wrong to have RPM scriptlets editing config, but I don't see another way
> >forward, short of modifying the program to accept command-line overrides
> >for these options (which has its own "fun")
> 
> don't touch configs - Apache 2.2 and Apache 2.4 configs also where
> widely incompatible and within a distr-upgrade as admin you are
> supposed to handle such changes but when you touch my configs for
> whatever package i get terrible angry because you can't know if it
> even works as you expect combined with other non.default options
> which are the point of configfiles

This is nothing like the Apache change - in this case, the config is
exactly the same, but a couple of options need to be changed to continue
to work.

The user change won't hurt, it's just something that should have been
changed from the start.

The daemon/foreground change though has to match the systemd unit.  I
plan to change the unit to expect/use a foreground process, which means
if the config is not changed to match, the service won't work right.

Is it "okay" to break and require manual configuration intervention on a
Fedora version upgrade?

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1077  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 840  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 422  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 319  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 151  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  88  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  24  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-069884a87f   
p7zip-16.02-10.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-72e5d3ef89   
suricata-4.0.4-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-276ec6ee2b   
exim-4.90.1-2.el7


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

ddupdate-0.6.0-2.el7
libidn2-2.0.4-3.el7
percolator-3.02.00-1.el7
python-biopython-1.70-10.el7
seamonkey-2.49.2-2.el7

Details about builds:



 ddupdate-0.6.0-2.el7 (FEDORA-EPEL-2018-842be2e212)
 Tool updating DNS data for dynamic IP addresses

Update Information:

New package in epel




 libidn2-2.0.4-3.el7 (FEDORA-EPEL-2018-823d88dfeb)
 Library to support IDNA2008 internationalized domain names

Update Information:

- Added upstream patch to fix STD3 ASCII rules (#1543021)

References:

  [ 1 ] Bug #1543021 - libidn2: Guidance needed for avoiding STD3 rules
https://bugzilla.redhat.com/show_bug.cgi?id=1543021




 percolator-3.02.00-1.el7 (FEDORA-EPEL-2018-d1af041341)
 Software for postprocessing of shotgun proteomics data

Update Information:

- Update to 3.02.0 - Drop old patches - Link to libtirpc on fedora




 python-biopython-1.70-10.el7 (FEDORA-EPEL-2018-5daa80df62)
 Python tools for computational molecular biology

Update Information:

- Fix Python2 required package on rhel - Fix Python2 mysql-connector packages on
fedora

References:

  [ 1 ] Bug #1546089 - python2-biopython-1.70-2.el7: Summary is shown as %{sum}
https://bugzilla.redhat.com/show_bug.cgi?id=1546089




 seamonkey-2.49.2-2.el7 (FEDORA-EPEL-2018-e50c94a832)
 Web browser, e-mail, news, IRC client, HTML editor

Update Information:

Update to 2.49.2  Based on the Firefox/Thunderbird ESR (extension support
release) code version 52.6.1  Fixes various security issues, see
https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/ and
https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ for
more info.

References:

  [ 1 ] Bug #1545970 - seamonkey-2.49.2.source is available
https://bugzilla.redhat.com/show_bug.cgi?id=1545970

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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 17:38 +, Artur Iwicki wrote:
> > If you fixed package(s), 
> 
> Just to make sure: the missing "BuildRequires:" should be added only on the
> master (Rawhide) dist-git branch, or on all actively-in-use branches?

It would not hurt if you will do same in all branches, but at least you need to
make fix in Rawhide.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJvV0ACgkQaVcUvRu8
X0wPsQ//cYJYTJQvPHvEI8MhOvwdt9aS+YgarAO3CHI7WyfKEejCbz0qTOp0PQ77
05wCYGdhD+T3htY2FYzePSNYAEGQhxCbUhxt+K0KVM10GwWgCvsNg5PWWd/bkcU1
m5lZ7JeB9be/Knob30rPnC2AURe5RWewRIyWl5JvLIFGLtkSGbDDUO15mfXkpFTd
zr97IbG1inXnLcacAxYxo3sKkqI9vjyrSAuPDIkMLg1p2LWQKZzV2rdwZy7cix5H
ERB/KJqM9JDWEHKZl4QMrfOgBHoKOa03qS+aHcbhZ4iG0pBPkRoYfiSMw1cAGR/l
TW9PZ5kh18lr56nFpzJ/Ekkksov44JIYvoLS+zQqMWQBGLziQLSpYNOhl96CSxFA
T772wm8wsgs135LO4Gz/VLESh3fpCWuN6u9gSXxumalPC1TaDdB1+ZqeZrc9+gBo
X6/P5vA8sGat3PiQs1tWWW75Dt7BMEusV5Be/Di2x9Fb1mo+j3zueHtvk3VM+SON
2l9MLVqus9Iu2tXykTn69zMM0/1qAZw9qf+gqa/4hWORE5VFg6wQ2RoD2u9ClCFM
XhbgR0EWVJCEK5MGqQRFnE9CVC9/j4K1GEKB2TckLvEeP3X5btRWoG17lUEQbKic
BW9AjtKh7iup+V6Ur9DIqFMLpIbM4uwDwqY2wiuoIJWCdFgubdg=
=Lu2k
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2018-02-18 at 17:33 +, Sérgio Basto wrote:
> Hi Igor ,
> 
> On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote:
> > Over this weekend I've performed scratch-mass-rebuild without having
> > gcc and
> > gcc-c++ in buildroot of all Fedora packages, many of which failed due
> > to random
> > reasons and I grepped all logs for some common errors found by
> > analyzing
> > hundreds of build logs.
> > 
> > Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#Bu
> > ildRequire
> > s_and_Requies
> > 
> > The grep output is located here:
> > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> > 
> > Some packages might be missed due to short koji outage, broken
> > dependencies and
> > so on, but majority of real failures is below.
> > 
> > If you fixed package(s), found false positive, found missing packages
> > in list
> > or anything else -- please let me know.
> > 
> > Note to packages which use CMake buildsystem. When you have
> > project(xxx) in
> > CMakeLists.txt it checks both for C and CXX compilers. So you might
> > encounter
> > packages where you have BuildRequires: gcc and it fails on CXX
> > compiler (even
> > you think you don't need it). Solution for this is to send patch to
> > upstream
> > switching to something like project(xxx C), or if problem is opposite
> > to
> > project(xxx CXX).
> > 
> > List of packages and respective maintainers:
> > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt
> 
> I support your work, but I was thinking instead one mass change detail
> by detail .

That will come, in few weeks / month.

> Why not ? one mass spec clean up with all the items ?

* Get attention from people.
* There might be false positives, so I would like people to check their
packages.
* Whoever will ignore this will get automatic fix later (but it doesn't mean
that it will be 100% correct, although will fix bbuild).
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJu9IACgkQaVcUvRu8
X0x8bA//e51cbHahF7N8IHtq8MKLvEHvaNJAaC7buqmWwVYFj++Yo8M9mgjKtlGG
4VZPdxmF0TKNGZAGvv7Dx71B42i6acFbwsMAaIcZTc54jHNWo9tV/NXwmOWeG/ce
sZYZt8yye/wgsFBzOnuvs9VJrF+4JGxM0Xyw0UN9JIPtACoRCY0/xkAat28LZILP
2yoe+K8sQkGyiIZthJGpRuScppjfs0PxbEXYaBLuZ6kbdejwwyf30EoPN9OE4uur
pa7iDepfOZqfxaKoF7++dE19uID1AfHNCwcS1Yj93duFWhZMp8MszjVPbvXavo6u
CLhhtMxjEb2yMmQp/PzVoR1RCJV8PSCAxTEc6r6I0WUgElin3ri0McHqefvF2bC2
MrP1Uz1M1ZrQK9wEDL0Ks4Fy/dYKTeWmO6m/ZUnbPHqzcnJJvth6U0S0feUHAOte
y6eh/p/XGs2K7dUi8vuChVj2IKQPwWKeooXL2SA2tuvfAanFhqHyxOLELS/NVWtP
+faB5ZcjFTeRNo0LGalzmDVhCkEaKldHj8xvFZo2A9+IGVPZluY4ef3fdNX8n1yB
wxHWXiRAGTseOT+l2EONK8/MmnnTTVTolPJwhgmk2FjCpCqiawSq4MATCt/eJQfL
PSP/eoL2G+JXAai4v4IB+FIbsLI+HNdDhN43BehRxgpn9KHF1MA=
=E67h
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Artur Iwicki]

> If you fixed package(s), 
Just to make sure: the missing "BuildRequires:" should be added only on the 
master (Rawhide) dist-git branch, or on all actively-in-use branches?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Göran Uddeborg]

Igor Gnatenko:
> If you fixed package(s),

I haven't yet, but I certainly will fix my packages (emacs-vm mindless
ttf2pt1 xpenguins).


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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Sérgio Basto]

Hi Igor ,

On Sun, 2018-02-18 at 18:09 +0100, Igor Gnatenko wrote:
> Over this weekend I've performed scratch-mass-rebuild without having
> gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due
> to random
> reasons and I grepped all logs for some common errors found by
> analyzing
> hundreds of build logs.
> 
> Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#Bu
> ildRequire
> s_and_Requies
> 
> The grep output is located here:
> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
> 
> Some packages might be missed due to short koji outage, broken
> dependencies and
> so on, but majority of real failures is below.
> 
> If you fixed package(s), found false positive, found missing packages
> in list
> or anything else -- please let me know.
> 
> Note to packages which use CMake buildsystem. When you have
> project(xxx) in
> CMakeLists.txt it checks both for C and CXX compilers. So you might
> encounter
> packages where you have BuildRequires: gcc and it fails on CXX
> compiler (even
> you think you don't need it). Solution for this is to send patch to
> upstream
> switching to something like project(xxx C), or if problem is opposite
> to
> project(xxx CXX).
> 
> List of packages and respective maintainers:
> https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

I support your work, but I was thinking instead one mass change detail
by detail .

Why not ? one mass spec clean up with all the items ?

Thanks,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt

Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.

If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.

Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).

List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Over this weekend I've performed scratch-mass-rebuild without having gcc and
gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
reasons and I grepped all logs for some common errors found by analyzing
hundreds of build logs.

Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
s_and_Requies

The grep output is located here:
https://ignatenkobrain.fedorapeople.org/gcc-removal.txt

Some packages might be missed due to short koji outage, broken dependencies and
so on, but majority of real failures is below.

If you fixed package(s), found false positive, found missing packages in list
or anything else -- please let me know.

Note to packages which use CMake buildsystem. When you have project(xxx) in
CMakeLists.txt it checks both for C and CXX compilers. So you might encounter
packages where you have BuildRequires: gcc and it fails on CXX compiler (even
you think you don't need it). Solution for this is to send patch to upstream
switching to something like project(xxx C), or if problem is opposite to
project(xxx CXX).

List of packages and respective maintainers:
https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8
X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+
ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon
f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9
bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH
uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5
ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo
z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn
Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY
zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy
NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7
Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8=
=KRiO
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 8: camotics fails to build for i686, ARMv7 arches (reading 31 bytes from a region of size 16)

[Samuel Rakitničan]

> It means the package should probably not be using -Werror

Oh yes forgot that upstream forces -Werror. For now I will keep upstream 
preference as long as the issues reported gets fixed.

All the reported issues was fixed upstream and the package built successfully 
for Fedora 28.

Thank you for looking at it!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F29 System Wide Change: Remove GCC from BuildRoot

[Zbigniew Jędrzejewski-Szmek]

Fedora decided to use gcc as *the* compiler [1], and frankly, we have
enough trouble getting packages to compile without trying to support
more than one compiler (vide the lass mass rebuild).

What you propose: building with a different compiler, makes sense
mostly at the level of a single package. For example, I often build
systemd with clang, because although gcc generally provides better
diagnostics, clang does catch some different errors. But to make use
of this (and to diagnose failures), requires pretty intimate knowledge
about the package and the code being compiled. Thus, its something that
a maintainer might do for their package, or even more likely, something
that upstream will use in development. Doing this at the level of the
whole distro is pointless, we already get quite a few build warnings
from gcc, and almost nobody looks at them.

In effect, my feeling is that although what you propose might be useful
sometimes, that "sometimes" would not be very often, and the required
complexity is not worth it.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler

Zbyszek


On Sun, Feb 18, 2018 at 10:10:46AM +, Tomasz Kłoczko wrote:
> On 16 February 2018 at 11:56, Jan Kurik  wrote:
> [..]
> > ** List of deliverables:
> > N/A (not a System Wide Change)
> >
> > * Policies and guidelines:
> > Nothing needed, guidelines already have paragraph about listing all
> > required BuildRequires.
> 
> As definitely proposed change will create the whole wave of small
> changes adding at least one new BuildRequires I just started thinking
> about going slightly deeper (but only a bit deeper ;) ).
> 
> When gcc or other compilers are no longer part of the core build env
> suit/env as you mention it is necessary to add it straight in
> BuildRequires for example gcc.
> That is OK.
> 
> Q: does it really needs to be gcc? What about clang?
> A: theoretically it does not need to be gcc .. especially as macros
> like %cmake, %configure are injecting over CC, CXX and other variables
> exact commands.
> 
> As long as none of the macros like %cmake or %cobfigure has straight
> dependency and are not forcing to use gcc (those macros are using
> other macros like %{__cc}) already it possible to test build package
> written in C using C++ compiler to for example expose some set of
> compile warnings generated by C++ compiler or .. use clang.
> Build the whole package with use some C code security scanners? No
> problem. It is possible to do this without touching spec file.
> 
> OK, so .. at the moment macros like:
> 
> %__cc gcc
> %__cpp gcc -E
> %__cxx g++
> 
> are defined in /usr/lib/macros which is part of the rpm.
> If those macros will be removed from this file and moved to
> /usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
> the platform which will open the whole spectrum of completely new
> possibilities with some minimal changes in whole build env and no
> other changes in all specs.
> Only weak point in above is how to force use gcc if both gcc and clang
> will be installed (which will be quite typical in case all packagers
> private build envs).
> However, I think that even this is a very small obstacle which can be
> easily handled.
> 
> Now by default %/{__cc} is provided by gcc but if here it will be
> introduced small flexible it should be possible to control which
> compiler should be used even if in packagers build system will be
> installed both gcc and clang by simple few changes in ~.rpmrc or on
> Fedora build systems in ~mock/.rpmrc file.
> 
> So maybe instead:
> 
> BuildRequires: gcc
> 
> better would be to use:
> 
> BuildRequires: %{__cc}
> 
> or:
> 
> BuildRequires: c-compiler
> 
> ??
> if  both gcc and clang will have:
> 
> Provides: c-compiler
> 
> still it will be possible installed gcc and clang without conflicts.
> I'm sure that above it is not complete idea and few small bits still
> are missing.
> 
> I think that we should hold for few seconds and consider change a bit
> this proposal to pen those possibilities.
> 
> 
> Comments?
> 
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedup upload failure

[Kevin Fenzi]

On 02/18/2018 06:54 AM, Martin Gansser wrote:
> keberos ticket
> 
> $ klist -A
> Ticket cache: KCM:1000
> Default principal: marti...@fedoraproject.org
> 
> Valid starting ExpiresService principal
> 02/11/18 11:46:54  02/12/18 11:45:58  
> HTTP/src.fedoraproject@fedoraproject.org
>   renew until 02/18/18 11:45:58
> 02/11/18 11:46:02  02/12/18 11:45:58  
> krbtgt/fedoraproject@fedoraproject.org
>   renew until 02/18/18 11:45:58
> 02/11/18 12:04:42  02/12/18 11:45:58  
> HTTP/koji.fedoraproject@fedoraproject.org
>   renew until 02/18/18 11:45:58

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

You can disable kcm to get things working. I think one of the comments
there has the way to do that.

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

Re: Removal of sln

[Zbigniew Jędrzejewski-Szmek]

On Sun, Feb 18, 2018 at 12:47:24PM +, Richard W.M. Jones wrote:
> On Sat, Feb 17, 2018 at 04:08:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Feb 16, 2018 at 09:53:35PM +, Richard W.M. Jones wrote:
> > > sln (staticly linked ‘ln’) was removed from glibc recently:
> > > 
> > >   https://bugzilla.redhat.com/show_bug.cgi?id=1531546
> > > 
> > > The explanation for this was:
> > > 
> > >   "The sln program is no longer useful, so we will not ship it anymore."
> > > 
> > > and it was removed from Rawhide 3 days later.
> > > 
> > > There are some %post scripts which still use this, notably
> > > ca-certificates, so that's now broken.  But more to the point what do
> > > you do if you are in a situation where you need to make a symlink to
> > > save some core shared library on the currently running system?
> > > 
> > > I also don't think rather fundamental, useful and old tools like this
> > > should be removed without discussion.
> > 
> > Why is normal ln not enough? It should be installed and runnable on
> > pretty much any system, even during upgrades of glibc and other basic
> > libraries.
> 
> The idea behind sln is that it works even if you've broken the libc
> symlink.

Right. But does this really happen? In my experience, 10 years ago
this kind of stuff happened, either because the tools were less
reliable, or rather more likely because the human operating them
didn't yet know how to operate them properly. I think we have all moved
far in the direction of systems-as-cattle, and when we get to the point
where libc is hosed, well, that's it, we provision a new installation.

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

Re: fedup upload failure

[Martin Gansser]

keberos ticket

$ klist -A
Ticket cache: KCM:1000
Default principal: marti...@fedoraproject.org

Valid starting ExpiresService principal
02/11/18 11:46:54  02/12/18 11:45:58  
HTTP/src.fedoraproject@fedoraproject.org
renew until 02/18/18 11:45:58
02/11/18 11:46:02  02/12/18 11:45:58  krbtgt/fedoraproject@fedoraproject.org
renew until 02/18/18 11:45:58
02/11/18 12:04:42  02/12/18 11:45:58  
HTTP/koji.fedoraproject@fedoraproject.org
renew until 02/18/18 11:45:58
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedup upload failure

[Martin Gansser]

I see more error now ...

$ koji build --scratch f27 ~/rpmbuild/SRPMS/vdr-epg2vdr-1.1.86-1.fc27.src.rpm 
AuthError: unable to obtain a session

$ kinit -R marti...@fedoraproject.org
kinit: Ticket expired while renewing credentials
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

fedup upload failure

[Martin Gansser]

Hello,

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

$ kinit marti...@fedoraproject.org
$ fedpkg new-sources vdr-plugin-epg2vdr-1.1.86.tar.bz2
Could not execute new_sources: Request is unauthorized.

Any ideas as to why I can not do an fedpkg upload? I'm able to do a fedpkg 
clone so my rsa keys are good...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf: Can't tell me what is pulling in a dependency?

[Neal Gompa]

On Sun, Feb 18, 2018 at 9:10 AM, Richard Shaw  wrote:
> I was updating my mythtv box and I saw that it was pulling in some mysql
> community packages as a dependency but I looked through the options and I
> couldn't find ANYTHING that would tell me what was pulling in those
> packages. Nov "-v" and not "--debugsolver".
>
> Is it really not possible?
>
>

One way is to rerun the transaction with "--exclude=community-mysql*".
Paired with --assumeno, it'll give you the proposal and not do it.


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

dnf: Can't tell me what is pulling in a dependency?

[Richard Shaw]

I was updating my mythtv box and I saw that it was pulling in some mysql
community packages as a dependency but I looked through the options and I
couldn't find ANYTHING that would tell me what was pulling in those
packages. Nov "-v" and not "--debugsolver".

Is it really not possible?

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

Re: to batch or not to batch?

[Artur Iwicki]

> Batching is now the default, but maintainers can push theirs updates
> to stable, overriding this default, and make the update available the
> next day.
I think that since "batch override" doesn't push the package immediately, but 
rather schedules it for the next day, I agree with Fabio that it might be a 
good idea to flush the "batch queue" when a package is explicitly pushed to 
stable by someone. This won't increase the number of metadata expirations - so 
there isn't really any drawback to end users - while allowing updates to reach 
users faster.
 
> + batching reduces the number of times repository metadata is updated.
>   Each metadata update results in dnf downloading about 20-40 mb,
>   which is expensive and/or slow for users with low bandwidth.
As someone with a rather small data cap, I'd say that heavy metadata downloads 
during "dnf update" are acceptable - since I can just choose to run "dnf 
update" only once a week or so. But it always irks me a bit when I want to 
install a new package and dnf starts downloading the repository metadata again. 
Bandwidth issues aside, it's just incredibly annoying having to wait for a 
40MiB download to complete before I can fetch a single 600KiB package.

> - batching delays updates of packages between 0 and 7 days after
>   they have reached karma and makes it hard for people to immediately
>   install updates when they graduate from testing.
I agree with Jerry here - many packages don't get any karma while testing. The 
only time my packages received testing karma was when I was introducing new 
packages; didn't happen for updates. So having the package sit in limbo for 
another week after going through a week of "maybe someone'll take a look at 
this" is a bit discouraging.

> One of the positive aspects of batching — reduction in metadata downloads,
> might be obsoleted by improving download efficiency through delta downloads.
> A proof-of-concept has been implemented [4].
This could be a rather interesting feature, as it'd resolve some of the issues 
I wrote two paragraphs above.

By the way - does drpm handling depend on repo / mirror settings? I ask because 
I'm under the impression that lately hardly any package update on my system is 
done via delta-RPMs; it's about 1-in-100 or so. Is this more a matter of me 
needing to tweak dnf config, or can this depend on the package mirrors?

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

[389-devel] Re: please review: Ticket 49296 - Fix race condition in connection code that allows anonymous limits to be applied after the initial bind occurs

[Mark Reynolds]

Fixed typos in commit message

https://pagure.io/389-ds-base/issue/raw/files/5fe67b5583f885d5954485320da3eb3fd0dc11b6d3be4fc0e2d6146232db0b9e-0001-Ticket-49296-Fix-race-condition-in-connection-code-w.patch

On 02/17/2018 06:45 PM, Mark Reynolds wrote:
> https://pagure.io/389-ds-base/issue/49296
>
> https://pagure.io/389-ds-base/issue/raw/files/e472a4a1d560bb5fdad852a5d6097ec4ffa8d87dc67416524d36ecfdbc1ff488-0001-Ticket-49296-Fix-race-condition-in-connection-code-w.patch
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: to batch or not to batch?

[Ralf Corsepius]

On 02/17/2018 11:15 PM, Zbigniew Jędrzejewski-Szmek wrote:

Bodhi currently provides "batched updates" [1] which lump updates of
packages that are not marked urgent into a single batch, released once
per week. This means that after an update has graduated from testing,
it may be delayed up to a week before it becomes available to users.

Batching is now the default, but maintainers can push theirs updates
to stable, overriding this default, and make the update available the
next day.

Batching is liked by some maintainers, but hated by others


As a maintainer, I hate them, because the primary effect "batched" has, 
is to furtherly increase update delay from 1 week up to 2 weeks or more 
(like in recent times).


That said, I consider "batched" to be superfluous bureaucracy.

Ralf


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

Re: Removal of sln

[Richard W.M. Jones]

On Sat, Feb 17, 2018 at 04:08:09PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Feb 16, 2018 at 09:53:35PM +, Richard W.M. Jones wrote:
> > sln (staticly linked ‘ln’) was removed from glibc recently:
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1531546
> > 
> > The explanation for this was:
> > 
> >   "The sln program is no longer useful, so we will not ship it anymore."
> > 
> > and it was removed from Rawhide 3 days later.
> > 
> > There are some %post scripts which still use this, notably
> > ca-certificates, so that's now broken.  But more to the point what do
> > you do if you are in a situation where you need to make a symlink to
> > save some core shared library on the currently running system?
> > 
> > I also don't think rather fundamental, useful and old tools like this
> > should be removed without discussion.
> 
> Why is normal ln not enough? It should be installed and runnable on
> pretty much any system, even during upgrades of glibc and other basic
> libraries.

The idea behind sln is that it works even if you've broken the libc
symlink.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1459433] Unescaped % character in changelog

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Plack-1.0047-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f06b7cf746

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

[Bug 1459433] Unescaped % character in changelog

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Plack-1.0047-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2808f7d416

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

[Bug 1544589] perl-SNMP-Info-3.46 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-SNMP-Info-3.45 is  |perl-SNMP-Info-3.46 is
   |available   |available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.46
Current version/release in rawhide: 3.43-1.fc28
URL: http://search.cpan.org/dist/SNMP-Info/

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

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

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

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

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

[Bug 1546523] New: perl-Mouse-2.5.2 is available

[bugzilla]

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

Bug ID: 1546523
   Summary: perl-Mouse-2.5.2 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Mouse
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest upstream release: 2.5.2
Current version/release in rawhide: 2.5.1-2.fc28
URL: http://search.cpan.org/dist/Mouse/

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

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

[Bug 1546520] New: perl-Perl6-Export-Attrs-0.000006 is available

[bugzilla]

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

Bug ID: 1546520
   Summary: perl-Perl6-Export-Attrs-0.06 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Perl6-Export-Attrs
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.06
Current version/release in rawhide: 0.05-7.fc28
URL: http://search.cpan.org/dist/Perl6-Export-Attrs/

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

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

Re: Koji build: cannot find spec file

[Patrick マルタインアンドレアス Uiterwijk]

> On 02/17/2018 08:22 PM, Jerry James wrote:
> 
> Yeah, it's still broken. I looked at it a bit but couldn't see what the
> exact cause of the breakage is. ;(
> 
> If we cannot get it fixed by tomorrow morning, I'll revert us back to
> the older koji version. ;(

We have found and fixed the issue with koji 1.15.0, and patched the build 
system.
Builds should be working as of now again.

> 
> Sorry for the hassles.
> 
> kevin

Thanks for your patience,
Patrick
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: to batch or not to batch?

[Peter Oliver]

> Did I miss something on the plus or minus side? 

+ Without batched updates, running “dnf update” gives a variable reward, like 
clicking refresh on Facebook or playing a fruit machine.  Accumulating updates 
into a batch gives a calmer, more ordered experience.

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

Re: to batch or not to batch?

[Fabio Valentini]

On Sat, Feb 17, 2018 at 11:15 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> Bodhi currently provides "batched updates" [1] which lump updates of
> packages that are not marked urgent into a single batch, released once
> per week. This means that after an update has graduated from testing,
> it may be delayed up to a week before it becomes available to users.
>
> Batching is now the default, but maintainers can push theirs updates
> to stable, overriding this default, and make the update available the
> next day.
>
> Batching is liked by some maintainers, but hated by others
> Unfortunately, the positive effects of batching are strongly
> decreased when many packages are not batched. Thus, we should settle
> on a single policy — either batch as much as possible, or turn
> batching off. Having the middle ground of some batching is not very
> effective and still annoys people who don't like batching.

(snip)

> To summarize the ups (+) and downs (-):
>
> + batching reduces the number of times repository metadata is updated.
>   Each metadata update results in dnf downloading about 20-40 mb,
>   which is expensive and/or slow for users with low bandwidth.

This savings effect is negligible, because metadata has to be updated
even if only 1 urgent security update is pushed to stable.

> + a constant stream of metadata updates also puts strain on our mirrors.
>
> + a constant stream of updates feels overwhelming to users, and a
>   predictable once-per-week batch is perceived as easier. In
>   particular corporate users might adapt to this and use it to
>   schedule an update of all machines at fixed times.

I'd rather want to see a small batch of updates more frequently than a
large batch that I won't care to read through.

> + a batch of updates may be tested as one, and, at least in principle,
>   if users then install this batch as one, QA that was done on the
>   batch matches the user systems more closely, compared to QA testing
>   package updates one by one as they come in, and users updating them
>   at a slightly different schedule.

Well, is any such testing of the "batched state" being done, and if it
is, does it influence which packages get pushed to stable?

> - batching delays updates of packages between 0 and 7 days after
>   they have reached karma and makes it hard for people to immediately
>   install updates when they graduate from testing.

This delay can be circumvented by maintainers by pushing directly to
stable instead of batched (thereby rendering the batched state
obsolete, however).

> - some users (or maybe it's just maintainers?) actually prefer a
>   constant stream of small updates, and find it easier to read
>   changelogs and pinpoint regressions, etc. a few packages at a time.

I certainly belong to this group.

> - batching (when done on the "server" side) interferes with clients
>   applying their own batching policy. This has two aspects:
>   clients might want to pick a different day of the week or an
>   altogether different schedule,
>   clients might want to pick a different policy of updates, e.g. to
>   allow any updates for specific packages to go through, etc.
>
>   In particular gnome-software implements its own style of batching, where
>   it will suggest an update only once per week, unless there are security
>   updates.

Which further delays the distribution of stable updates by up to a
week (depending on the schedule of gnome-software, I didn't check
that). That makes a total of up to 3 weeks (!).

> Unfortunately there isn't much data on the effects of batching.
> Kevin posted some [2], as did the other Kevin [3] ;), but we certainly
> could use more detailed stats.
>
> One of the positive aspects of batching — reduction in metadata downloads,
> might be obsoleted by improving download efficiency through delta downloads.
> A proof-of-concept has been implemented [4].

A simpler approach might be to just flush all batched updates to
stable if there is at least one update (possibly an urgent security
update) anyway. That way, the metadata don't have to be downloaded for
just one update, and all packages reach stable sooner.

> Second positive aspect of batching — doing updates in batches at a
> fixed schedule, may just as well be implemented on the client side,
> although that does not recreate the testing on the whole batch, since
> now every client it doing it at a different time. It's not clear though
> if this additional testing is actually useful.

Well, the whole testing/installing batches of updates sounds a lot
like what Atomic Workstation is doing (which I really like).
However, forcing the same kind of process onto the current way of
doing things (with individual updates and packages) doesn't seem to
make anybody happy right now ...

> There's an open FESCo ticket to "adjust/drop/document" batching [5].
> That discussion has not been effective, because this issue has many
> aspects, and depending on priorities, the view on batching is 

Re: F29 System Wide Change: Remove GCC from BuildRoot

[Tomasz Kłoczko]

On 16 February 2018 at 11:56, Jan Kurik  wrote:
[..]
> ** List of deliverables:
> N/A (not a System Wide Change)
>
> * Policies and guidelines:
> Nothing needed, guidelines already have paragraph about listing all
> required BuildRequires.

As definitely proposed change will create the whole wave of small
changes adding at least one new BuildRequires I just started thinking
about going slightly deeper (but only a bit deeper ;) ).

When gcc or other compilers are no longer part of the core build env
suit/env as you mention it is necessary to add it straight in
BuildRequires for example gcc.
That is OK.

Q: does it really needs to be gcc? What about clang?
A: theoretically it does not need to be gcc .. especially as macros
like %cmake, %configure are injecting over CC, CXX and other variables
exact commands.

As long as none of the macros like %cmake or %cobfigure has straight
dependency and are not forcing to use gcc (those macros are using
other macros like %{__cc}) already it possible to test build package
written in C using C++ compiler to for example expose some set of
compile warnings generated by C++ compiler or .. use clang.
Build the whole package with use some C code security scanners? No
problem. It is possible to do this without touching spec file.

OK, so .. at the moment macros like:

%__cc gcc
%__cpp gcc -E
%__cxx g++

are defined in /usr/lib/macros which is part of the rpm.
If those macros will be removed from this file and moved to
/usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
the platform which will open the whole spectrum of completely new
possibilities with some minimal changes in whole build env and no
other changes in all specs.
Only weak point in above is how to force use gcc if both gcc and clang
will be installed (which will be quite typical in case all packagers
private build envs).
However, I think that even this is a very small obstacle which can be
easily handled.

Now by default %/{__cc} is provided by gcc but if here it will be
introduced small flexible it should be possible to control which
compiler should be used even if in packagers build system will be
installed both gcc and clang by simple few changes in ~.rpmrc or on
Fedora build systems in ~mock/.rpmrc file.

So maybe instead:

BuildRequires: gcc

better would be to use:

BuildRequires: %{__cc}

or:

BuildRequires: c-compiler

??
if  both gcc and clang will have:

Provides: c-compiler

still it will be possible installed gcc and clang without conflicts.
I'm sure that above it is not complete idea and few small bits still
are missing.

I think that we should hold for few seconds and consider change a bit
this proposal to pen those possibilities.


Comments?

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

unannounced soname bump: gnome-desktop3 / libgnome-desktop-3

[Fabio Valentini]

FYI, the .so version of libgnome-desktop-3 was bumped from 12 to 17
with the build of gnome-desktop3-3.27.90-1.fc28 without previous
announcement.

Packages that will have to be rebuilt - if it hasn't happened already
(I didn't check individual changelogs, so no guarantee for correctness
or completeness of this list):

cheese-2:3.26.0-3.fc28.src
control-center-1:3.26.2-4.fc28.src
deepin-mutter-0:3.20.26-1.fc28.src
deepin-wm-0:1.9.21-2.fc28.src
eog-0:3.26.2-2.fc28.src
epiphany-1:3.27.1-3.fc28.src
evince-0:3.26.0-3.fc28.src
evolution-0:3.27.4-1.fc28.src
gnome-clocks-0:3.26.1-2.fc28.src
gnome-contacts-0:3.26.1-1.fc28.src
gnome-directory-thumbnailer-0:0.1.9-3.fc27.src
gnome-documents-0:3.26.1-3.fc28.src
gnome-font-viewer-0:3.26.0-1.fc28.src
gnome-initial-setup-0:3.26.0-2.fc28.src
gnome-screensaver-0:3.6.1-18.fc27.src
gnome-session-0:3.26.1-3.fc28.src
gnome-settings-daemon-0:3.26.2-4.fc28.src
gnome-shell-extension-pomodoro-0:0.13.4-1.fc28.src
gnome-shell-extensions-0:3.27.1-2.fc28.src
gnome-software-0:3.27.4-1.fc28.src
mutter-0:3.27.1-1.fc28.src
nautilus-0:3.26.2-2.fc28.src
switchboard-plug-display-0:0.1.3-4.fc28.src
switchboard-plug-pantheon-shell-0:0.2.6-4.fc28.src
totem-1:3.26.0-5.fc28.src
xviewer-0:1.6.0-4.fc28.src

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

Re: Removal of BuildRoot

[Pierre-Yves Chibon]

On Sat, Feb 17, 2018 at 10:37:08PM -0500, Neal Gompa wrote:
> On Fri, Feb 16, 2018 at 4:25 PM, Jason L Tibbitts III  
> wrote:
> >> "DS" == David Sommerseth  writes:
> >
> > DS> False positives are also easily filtered out by adding .rpmlint to
> > DS> the dist-git repository.
> >
> > Which is an absolutely terrible name for that.  Really.  Why would
> > anyone at all ever think it is a good idea to _hide_ the file that
> > controls that?
> >
> 
> I agree. What do we need to do to change this to .rpmlintrc?

A pull-request to fedpkg or rpkg sounds like a good start :)


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