Fedora-Atomic 27-20180307.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 2/2 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is the second iteration of my mass-scratch-rebuild without
gcc/gcc-c++ in the buildroot[0]. Everything what was written in
original mail still applies.

Since people might have fixed their packages after I started rebuild, I
decided to include information about commits I have used to build
packages. Hope this helps.


New list of packages, their commits and build logs are available:
* https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
* https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx
t
* https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt


[0] https://lists.fedoraproject.org/archives/list/devel-announce@lists.
fedoraproject.org/thread/IJFYI5Q2BYZKIGDFS2WLOBDUSEGWHIKV/
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqfmBkACgkQaVcUvRu8
X0x5/hAAt1gDH1lzIlkxn9ImLM8339foWlEnLKcqfFH5/dKpIE5x7rgjofRn3OYG
+Ca/qtC/iWwOZUYJncXCl+nEPaaBX5v+zpMHAlIZWe/TL7mbLAfwGCAuSupl3agb
DG6zuD4gcM0N+5Y5+CtEBv4Yawh+xjb0sKbjCwY8aFsHaVIJHlrnSjWNUz+mUUc1
bEcLUAwf2p581ATN7N3ZiJFvlb8LKuwKtEl3EmIk7K8URE/MDOZLBl0dy8+mXywP
BXwPeb4mHXZz/JADocWWMKhotVhPc/kUTixLeSmN7RNAcrgqEkNRQ2imy3LxoygE
px2I5UO1H/Tko0ALN8Ga5SeSrpU9U6yqJ2uhreCkPEZN6yRUQYY7kCUULTnh17P5
cYUV6Uu6LELN7mzt6lZ1C0xMtV+WNVK35XkHDwKe/yk0upFb85jFTOKy65L/QvEi
CsAs2sOMfQ4KhZoKyPx3iDavickk4PA2DJ40ALWKuroxCnc+IVu1Q7ZZqqsdys+c
bL764wTBbmz1pye2sLNerVAwd7Z4e9y+4AZnVTyNTZl0GBhcxumqp1La0Ku9Gl40
jxxHMGhjkkRSwoWiltlj26I13C+L48xYeldxXSvXwjG5YDhQ47pf2cj3oA78i9m/
eNk7cW4zTIdmsNG7WdKZ8kRsExasOxNV1tDxdHAq20hMnpDtbQ0=
=yy9a
-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

[Bug 1552447] New: perl-Catalyst-Runtime-5.90117-2.fc29 FTBFS: Failed test 'elapsed' at t/unit_stats.t

[bugzilla]

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

Bug ID: 1552447
   Summary: perl-Catalyst-Runtime-5.90117-2.fc29 FTBFS: Failed
test 'elapsed' at t/unit_stats.t
   Product: Fedora
   Version: 28
 Component: perl-Catalyst-Runtime
  Assignee: emman...@seyman.fr
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
   External Bug ID: CPAN 124459



perl-Catalyst-Runtime-5.90117-2.fc29 fails to build in F29 because a test
fails:

#   Failed test 'elapsed'
#   at t/unit_stats.t line 94.
#  got: '1520251689.51182'
# expected: '14'
# Looks like you failed 1 test of 13.
t/unit_stats.t  
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/13 subtests 

This is triggered by upgrading perl-Time-HiRes from 1.9753-2.fc28 to
1.9754-1.fc28 and caused by Catalyst-Runtime test that redefines
Time::HiRes::gettimeofday() but than calls Time::HiRes::tv_interval() and
expects  Time::HiRes::tv_interval() will call Time::HiRes::gettimeofday(). This
is not true since Time-HiRes-1.9754.

A fix exists at
.

Also Fedora 28 is affected.

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

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

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is the second iteration of my mass-scratch-rebuild without
gcc/gcc-c++ in the buildroot[0]. Everything what was written in
original mail still applies.

Since people might have fixed their packages after I started rebuild, I
decided to include information about commits I have used to build
packages. Hope this helps.


New list of packages, their commits and build logs are available:
* https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
* https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-commits-2.tx
t
* https://ignatenkobrain.fedorapeople.org/gcc-removal-2.txt


[0] https://lists.fedoraproject.org/archives/list/devel-announce@lists.
fedoraproject.org/thread/IJFYI5Q2BYZKIGDFS2WLOBDUSEGWHIKV/
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqfmBkACgkQaVcUvRu8
X0x5/hAAt1gDH1lzIlkxn9ImLM8339foWlEnLKcqfFH5/dKpIE5x7rgjofRn3OYG
+Ca/qtC/iWwOZUYJncXCl+nEPaaBX5v+zpMHAlIZWe/TL7mbLAfwGCAuSupl3agb
DG6zuD4gcM0N+5Y5+CtEBv4Yawh+xjb0sKbjCwY8aFsHaVIJHlrnSjWNUz+mUUc1
bEcLUAwf2p581ATN7N3ZiJFvlb8LKuwKtEl3EmIk7K8URE/MDOZLBl0dy8+mXywP
BXwPeb4mHXZz/JADocWWMKhotVhPc/kUTixLeSmN7RNAcrgqEkNRQ2imy3LxoygE
px2I5UO1H/Tko0ALN8Ga5SeSrpU9U6yqJ2uhreCkPEZN6yRUQYY7kCUULTnh17P5
cYUV6Uu6LELN7mzt6lZ1C0xMtV+WNVK35XkHDwKe/yk0upFb85jFTOKy65L/QvEi
CsAs2sOMfQ4KhZoKyPx3iDavickk4PA2DJ40ALWKuroxCnc+IVu1Q7ZZqqsdys+c
bL764wTBbmz1pye2sLNerVAwd7Z4e9y+4AZnVTyNTZl0GBhcxumqp1La0Ku9Gl40
jxxHMGhjkkRSwoWiltlj26I13C+L48xYeldxXSvXwjG5YDhQ47pf2cj3oA78i9m/
eNk7cW4zTIdmsNG7WdKZ8kRsExasOxNV1tDxdHAq20hMnpDtbQ0=
=yy9a
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

grubby - /boot on btrfs support

[Nathaniel McCallum]

https://bodhi.fedoraproject.org/updates/grubby-8.40-10.fc28

We've built grubby with support for /boot on btrfs. We're trying to
land this in F28. But we need testers. That's where you come in! If
you ever interact with grubby and especially if you have an exotic
grub2 setup, please download and test this release. As usual provide
feedback in Bodhi (link at the top of this email). Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): brotli (libbrotli{common,enc,dec}.so.1.0.1 -> libbrotli{common,enc,dec}.so.1)

[Kevin Kofler]

mcatanz...@gnome.org wrote:
> Anyway, the only thing better than one soname bump is a second one, so:
> https://github.com/google/brotli/pull/645

That change is just wrong:
https://github.com/google/brotli/pull/645#issuecomment-371011990

Kevin Kofler
___
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++

[Tim Orling]

On Tue, Mar 6, 2018 at 7:08 AM, Jan Rybar  wrote:

> done: procps-ng, psmisc, psacct
>
>
> On 02/18/2018 06:09 PM, 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.
>>
>> Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#Build
>> Require
>> 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
>>
>>
Forgot to email the list, but I took care of bwm-ng (which was FTBFS as
well) and pystatgrab. For the others next to my name I am not a primary or
even secondary maintainer, so I am a little bit hesitant to make the
changes.

I do wonder if libstatgrab needs the fix or the fact that it depends on
autotools has already indirectly taken care of it such that it is not on
your list? Happy to add it if needed/wanted/desired.

FAS: ttorling

- -- - -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.fed
>> oraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unannounced soname bump (Rawhide): brotli (libbrotli{common,enc,dec}.so.1.0.1 -> libbrotli{common,enc,dec}.so.1)

[mcatanzaro]

I see in the file list:

%{_libdir}/*.so.*

I've lost count of how many problems we've had from unannounced soname 
bumps recently. It's going to keep happening so long as our packaging 
guidelines continue to allow this construction.


Anyway, the only thing better than one soname bump is a second one, so: 
https://github.com/google/brotli/pull/645


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

Re: Unannounced soname bump (Rawhide): brotli (libbrotli{common,enc,dec}.so.1.0.1 -> libbrotli{common,enc,dec}.so.1)

[pouar]

On Tue, 06 Mar 2018 14:46:46 -0800
Adam Williamson  wrote:

> brotli was updated from 1.0.1-3 to 1.0.3-1 in Rawhide on 2018-03-03.
> This update bumped the sonames from libbrotli{common,enc,dec}.so.1.0.1
> to libbrotli{common,enc,dec}.so.1 (not a typo, that's really the change).
> This soname bump was not announced, as it is supposed to be.
> 
> httpd (Apache) and webkit2gtk3 (via woff2) depend on these libs. So this
> broke any web server, and multiple images (including release blocking
> ones) which depend on webkit2gtk3 for one reason or another, and so the
> whole Rawhide compose - the 20180305.n.0 Rawhide compose failed due to
> this issue.
> 
> Both dependencies have now been rebuilt. However, I still wanted to
> send this mail to draw attention to another unannounced soname bump
> that broke the compose.
> 
> Once again, folks, *please* announce your soname bumps, and co-ordinate 
> rebuilds.

Didn't know I was supposed to. Sorry about that. I'll try and remember to
do so next time.

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


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

[Bug 1552358] New: perl-Test2-Suite-0.000106 is available

[bugzilla]

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

Bug ID: 1552358
   Summary: perl-Test2-Suite-0.000106 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test2-Suite
  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.000106
Current version/release in rawhide: 0.000104-1.fc29
URL: http://search.cpan.org/dist/Test2-Suite/

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

-- 
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: Critpath karma

[Adam Williamson]

On Tue, 2018-03-06 at 08:48 -0500, Randy Barlow wrote:
> Greetings!
> 
> Does anybody here know the history and/or purpose behind Bodhi's
> critical path karma? A brief grepping of Bodhi's codebase makes me think
> it isn't really used by Bodhi for any purpose other than recording and
> displaying people's entries. I.e., it doesn't seem to be used in Bodhi's
> state machine. It also seems to be confusing for testers.
> 
> Does it serve a purpose? If not, should we remove it?

None of the replies so far was quite correct. It exists more or less
entirely because of this old post of mine:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5ADUVYLOHQVOEKPPOYQYVLCBGPNMOVI7/

which wound up being quite a significant input into Bodhi 2.0's design.
Quite a few things in Bodhi 2 are there more or less "because that post
 suggested them".

The reason you're confused is we never really finished hooking up all
the ideas from that post. We put some of the necessary bits into Bodhi,
but didn't get any further than that.

So this separate feedback item exists, I think, basically because of
this idea:

"For me, one the principal benefits of such a system would be that we
could make the 'This update breaks critical path functionality'
checkbox an absolutely red flashing light, wailing siren emergency
button. I mean, you hit that thing and trucks roll from Fedora HQ,
metaphorically speaking. It would have a confirmation page which
clearly described the impact of asserting that an update broke
critpath, so we could be confident that it didn't get falsely triggered
very often. I'd suggest that:

1. Any update that is marked as 'critpath breaking' by a FAS-registered 
tester would be blocked from going any further in the update process
without manual intervention (no autopushes at all)

2. Any update marked as 'critpath breaking' by a proven tester would be
blocked from being pushed stable at all - automatically or manually -
until the PT modified the feedback or it was overridden by someone with
appropriately godlike powers (TBD, but probably not just the
maintainer)

3. Any update marked as 'critpath breaking' should probably get
announced on at least test-announce and/or devel-announce

4. Any update marked as 'critpath breaking' *after it has already been
pushed* would similarly trigger a major response: notify maintainer
very hard, notify lists, generally do stuff to make sure it gets
immediate attention"

But in the end...we put the separate feedback item into Bodhi 2's
design, then stopped. We never actually implemented all of (or any of)
the things I suggested there. So it's a bit of an odd duck at present.

Removing it is one choice, sure. Looking at those ideas again and
deciding if we want to actually go ahead and implement any of them is
another choice.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Meeting Agenda for 2018-03-07

[Stephen John Smoogen]

I am currently sick due to pertussis so may not be able to run the
meeting. The items on the agenda are:

* Has anyone evaluated changes in upcoming 7.5?
* Developertoolset 7 has been synced and turned on in koji
* What to do with other SCL's?
* What to do when dts-8 comes out?
* Other?

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

[EPEL-devel] Re: Adding devtoolset to EPEL

[Kevin Fenzi]

On 02/14/2018 08:36 AM, Peter Robinson wrote:
>>> I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora
>>> Infrastructure batcave. I have not been able to get aarch64
>>> downloaded. I need help here on getting the cdn address correct.
>>>
>>> I need someone from releng (I guess it would be Peter?) to help us
>>> enable this in koji.
>>>
>>> After that dts should be ready for updates.
>>
>> Any updates? :)
> 
> Sorry, I took the action to sort out the aarch64 DTS and to close out
> the rest to get it enabled in koji. Had other deadlines in the last
> week or so that took priority, those are now done (as of about 90 mins
> ago) so I'll finish this up this afternoon and reply to this mail once
> complete.

ok, with many thanks to Peter and Smooge we finally have this enabled.

You should be able to use devtoolset now in specs.

Note that we have only approved devtoolset use currently, so please
don't use other SCLs at least yet. In tomorrow's meeting we should
discuss them.

IMHO, I would prefer to allow any scl that has no runtime dependency on
SCLs. ie, users can install and use it as they do now. If we ship things
that do have runtime dependencies on SCLs we need to make sure they can
install those (ie, how do they enable them in CentOS? In RHEL? what
error(s) would they get).

kevin




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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Thank you Björn you clarified all my remaining doubts!
I will remove "BuildArch: noarch" because in my opinion is the best
solution. Then I will resume the %{_libdir} macros
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Björn Persson]

Germano Massullo wrote:
> # in noarch builds, %%{_libdir} is not defined in cmake, so the default
> # installation would try installing for example
> # file onepinopenscpkcs11.json
> # into /usr/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # even if the system architecture is 64bit. This will lead to errors because
> # the %%files entry
> # %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # would be defined as
> # /usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # that is different from the previous one

onepin-opensc-pkcs11.so is an architecture-dependent file. Its content
is different on different processor architectures, and it's also
installed with different pathnames on different architectures.
Therefore anything that refers to the file by its absolute pathname is
also architecture-dependent.

When you insert the pathname into onepinopenscpkcs11.json, that makes
the JSON file architecture-dependent. It must contain different
pathnames on different architectures. A noarch package cannot contain
such a file. "noarch" means that the package's content is exactly the
same on all architectures.

To make a noarch package you must find a way to have a relative
pathname in onepinopenscpkcs11.json – one that contains neither "lib"
nor "lib64" – and install the file in a directory that doesn't depend
on _libdir, perhaps somewhere under %{_datadir}/mozilla.

If that isn't possible, then you must remove "BuildArch: noarch" from
firefox-pkcs11-loader.spec, allowing the package to differ between
architectures, and use _libdir where applicable.

Björn Persson


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

Unannounced soname bump (Rawhide): brotli (libbrotli{common,enc,dec}.so.1.0.1 -> libbrotli{common,enc,dec}.so.1)

[Adam Williamson]

brotli was updated from 1.0.1-3 to 1.0.3-1 in Rawhide on 2018-03-03.
This update bumped the sonames from libbrotli{common,enc,dec}.so.1.0.1
to libbrotli{common,enc,dec}.so.1 (not a typo, that's really the change).
This soname bump was not announced, as it is supposed to be.

httpd (Apache) and webkit2gtk3 (via woff2) depend on these libs. So this
broke any web server, and multiple images (including release blocking
ones) which depend on webkit2gtk3 for one reason or another, and so the
whole Rawhide compose - the 20180305.n.0 Rawhide compose failed due to
this issue.

Both dependencies have now been rebuilt. However, I still wanted to
send this mail to draw attention to another unannounced soname bump
that broke the compose.

Once again, folks, *please* announce your soname bumps, and co-ordinate 
rebuilds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please test f28-backgrounds package

[Adam Williamson]

On Mon, 2018-03-05 at 21:58 -0800, Luya Tshimbalanga wrote:
> f28-backgrounds just got packaged and ready for beta release. Please
> test and give positive if everything works as intended.
> 
> https://bodhi.fedoraproject.org/updates/f28-backgrounds-28.1.0-1.fc28%20desktop-backgrounds-28.0.0-1.fc28

Note F28 is frozen ATM. If this needs to go in for Beta, we need a
blocker or FE bug for it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Adam Williamson]

On Fri, 2018-03-02 at 04:40 +0100, Kevin Kofler wrote:
> 
> > I disagree entirely with the above. I think the solution is to gate
> > packages coming into rawhide and hold or reject those that break the
> > compose until they are fixed. I think being proactive is VASTLY better
> > than being reactive. Not breaking something in the first place is much
> > easier to deal with than trying to fix it later.
> 
> And how do you propose doing that? The only reliable way to hold packages 
> that break the compose would be to actually try to run the whole compose 
> process after every package build. That just does not scale.

Then we need to compose faster. This is precisely one of the reasons
why there's quite a lot of work going into exactly that.

"Composes take multiple hours" isn't an immutable law of the universe.
It's a limitation of our compose process, and one we really ought to
fix.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Kevin Kofler]

Stephen Gallagher wrote:
> Intuitively, I completely agree with you. I want to have a last warning
> that I need to hurry up and land my changes before I miss my window.
> 
> But when I think about it further, I have other thoughts too. The schedule
> is public and anyone can look it up at will, so it's not as if this is the
> only warning they see. And there's actually net value to the Project as a
> whole to *not* give the 24-hour warning. We've always had a high incidence
> of mass changes arriving in the last 24-48 hours before each Freeze, which
> generally translates into instability for a few days because people see it
> as their last chance and land stuff that isn't ready. So I can actually
> see an argument for *not* widely encouraging more people to land stuff at
> the last minute.
> 
> We also do have the one-week notice the Tuesday before, which is probably
> our best option; we should continue encourage people to land in the week
> before Freeze and try to work out the instabilities beforehand.

I was not really talking about the announcements (though having a warning 
BEFORE it is too late would be nice, indeed), but about the dates listed in 
the table on the wiki.

Right now, they say what amounts to:

2018-03-06   Beta Freeze (*)

(*) You won't actually have even one second on the listed day to do your
change in. You should have done it yesterday. Ha ha, fooled you! And of
course there are no exceptions (unless the change qualifies as a Blocker
or Freeze Exception) because it's all your fault that you have not read
the fine print, so get lost!

Not that it really matters for me this time because the only change I would 
have liked to land is not ready today either. (Falkon was only released by 
upstream last week, and my package is still stuck in the review process.) 
But still, the misleading freeze dates make me angry each time.

Compare with, e.g.:
https://community.kde.org/Schedules/Applications/18.04_Release_Schedule

Fedora:
> Beta and Final freezes are in effect from 00:00 UTC of the freeze day.

KDE:
> All deadlines are due 23:59 UTC, but if you need a few more hours, notify
> someone from the release team.

So not only do they put the actual last day in the table rather than the day 
it's already too late, but they also allow for extension requests in the 
hours range.

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

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Randy Barlow wrote:

> On 03/03/2018 01:34 PM, Kevin Kofler wrote:
>> That is due to the "Rawhide can never go backwards" policy, which I still
>> do not understand the point of, especially in the light of "distro-sync"
>> having been supported by both the old yum and the new dnf for years.
> 
> Sometimes an updated package makes changes to its data structures. For
> example, consider if the package does some kind of migration to its data
> in such a way that the new version can read it, but the old cannot (e.g.
> a PostgreSQL upgrade, and IIRC the Firefox discussion from a while ago
> also noted that it cannot be downgraded in all cases). Thus, distro-sync
> doesn't work in all cases if the upgraded package has already made
> changes on the user's system.

But bumping Epoch, as the policy makes you do in such a case, does 
absolutely nothing to fix that. So I don't see how the current policy helps.

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

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Nicolas Mailhot wrote:
> The “never go backwards” policy means that as soon something hits devel
> other packages can rely on your package and start adapting
> their packages on the basis of your changes. You can not pull the carpet
> from under their feet just because you changed your mind.

This is entirely orthogonal to the current monotonic EVR policy because 
Epoch exists (and is used to revert to older upstream releases in Rawhide at 
times, which is perfectly compliant with the current policy) and because 
pure packaging changes are not covered at all (given that you can just bump 
Release again when reverting them).

The policy you would like to see does not exist at this time and would have 
to be worded entirely differently.

And additionally, I would argue the opposite: It is just impossible to do 
development without sometimes trying something that may fail and thus have 
to be reverted. Banning that would also contradict the Changes process (see 
the contingency plans).

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

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Kevin Fenzi wrote:
> Do note that distro-sync can downgrade packages, but can't handle all
> the cases. ie, upgrade postgresql and update all your data you can't
> just downgrade the rpm and be fine. Or any number of other scriptlets
> that do things that cannot easily be reversed.

The Epoch hack that the current policy forces us to use does not solve any 
of that though.

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 966  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 856  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 827  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 438  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 167  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  86  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  58  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2ffe688829   
freexl-1.0.5-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5d12c76136   
drupal7-7.57-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7e91105260   
clamav-0.99.4-1.el6


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

ocserv-0.11.11-1.el6
perl-Image-ExifTool-10.80-1.el6

Details about builds:



 ocserv-0.11.11-1.el6 (FEDORA-EPEL-2018-b4bb9c4bc8)
 OpenConnect SSL VPN server

Update Information:

Update to upstream 0.11.11 release




 perl-Image-ExifTool-10.80-1.el6 (FEDORA-EPEL-2018-00e0248288)
 Utility for reading and writing image meta info

Update Information:

Update to 10.80 (latest stable).

References:

  [ 1 ] Bug #1550526 - Upgrade perl-Image-ExifTool to 10.80
https://bugzilla.redhat.com/show_bug.cgi?id=1550526

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

[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Image-ExifTool-10.80-1.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2018-97782e8897

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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1093  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 856  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 438  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 335  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 167  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
 104  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  54  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  28  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50566f0a39   
uwsgi-2.0.16-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0296296d7c   
mingw-wavpack-5.1.0-4.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9111777f91   
freexl-1.0.5-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3e70a38ad4   
drupal7-7.57-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aacf1b47d6   
clamav-0.99.4-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-815e0064e9   
tor-0.2.9.15-1.el7


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

lammps-20180222-1.el7
nginx-1.12.2-2.el7
ocserv-0.11.11-1.el7
openssl-pkcs11-0.4.7-5.el7
perl-Image-ExifTool-10.80-1.el7
qodem-1.0.0-1.el7
slrn-1.0.3a-1.el7

Details about builds:



 lammps-20180222-1.el7 (FEDORA-EPEL-2018-6ec72c2bfe)
 Molecular Dynamics Simulator

Update Information:

Version bump to 20180222




 nginx-1.12.2-2.el7 (FEDORA-EPEL-2018-bf5d0a5f01)
 A high performance web server and reverse proxy server

Update Information:

Enable building the `ngx_http_auth_request_module` module.

References:

  [ 1 ] Bug #1471107 - [patch] enable nginx http_auth_request_module
https://bugzilla.redhat.com/show_bug.cgi?id=1471107




 ocserv-0.11.11-1.el7 (FEDORA-EPEL-2018-82f93c622a)
 OpenConnect SSL VPN server

Update Information:

Update to upstream 0.11.11 release




 openssl-pkcs11-0.4.7-5.el7 (FEDORA-EPEL-2018-8fb8727eed)
 A PKCS#11 engine for use with OpenSSL

Update Information:

Fixed broken Obsoletes




 perl-Image-ExifTool-10.80-1.el7 (FEDORA-EPEL-2018-97782e8897)
 Utility for reading and writing image meta info

Update Information:

Update to 10.80 (latest stable).

References:

  [ 1 ] Bug #1550526 - Upgrade perl-Image-ExifTool to 10.80
https://bugzilla.redhat.com/show_bug.cgi?id=1550526




 qodem-1.0.0-1.el7 (FEDORA-EPEL-2018-ce366143b0)
 Terminal emulator and communications package

Update Information:

Update to 1.0.0 release.

References:

  [ 1 ] Bug #1551451 - update 1.0.0
https://bugzilla.redhat.com/show_bug.cgi?id=1551451




 slrn-1.0.3a-1.el7 (FEDORA-EPEL-2018-936cc370f8)
 A threaded Internet news reader

Update Information:

Update 

[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Image-ExifTool-10.80-1.el6 has been pushed to the Fedora EPEL 6 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-EPEL-2018-00e0248288

-- 
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: Test gate failures

[Michael Cronenworth]

On 03/06/2018 02:26 AM, Kamil Paral wrote:
We reported invalid multilib results, so I disabled multilib checking by simply 
not downloading any i386 packages. However, it didn't occur to me that that will 
break x86_64 packages that have a hard requirement on i386 packages, like wine 
does. I'll have to fix this somehow.


In the meantime, please verify manually that your update can be installed (no 
broken deps) and file a waiver for it:

https://fedoraproject.org/wiki/Package_update_HOWTO#Handling_feedback_from_automated_tests


Seeing as how the Requires for wine sub-packages have not changed in years... Yes, 
it can be installed. I'll look into the waiver.

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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 18:17, Germano Massullo ha scritto:
> Thank you Dennis. Therefore I think that rpmlint messages should be
> improved about noarch packages.
> I started working on %{_lib} / %{_libdir} on firefox-pkcs11-loader spec
> file because originally there were %files entries like
> %_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> and rpmlint returned errors like
>
> firefox-pkcs11-loader.src:43: E: hardcoded-library-path in 
> %_prefix/lib/mozilla/pkcs11-modules/
> firefox-pkcs11-loader.src:44: E: hardcoded-library-path in 
> %_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>
> So I started working to fix them
> Source:
> https://taskotron.fedoraproject.org/artifacts/all/46067844-18bd-11e8-9d96-525400fc9f92/task_output/firefox-pkcs11-loader-3.13.0-1.fc27.log
> https://bodhi.fedoraproject.org/updates/FEDORA-2018-4558f54f10

An interesting discussion about %{_lib} and noarch packages
https://pagure.io/packaging-committee/issue/203
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Kevin Fenzi]

On 03/06/2018 07:47 AM, Pierre-Yves Chibon wrote:
> On Tue, Mar 06, 2018 at 02:58:45PM +, Stephen Gallagher wrote:
...snip...
>> But that has its own issues.
> 
> Sorry, just to be clear, what would have its own issues:
> - asking rawhide users to use distro-sync instead of update?
> - automatically have dnf detect it's running in rawhide and default to
>   distro-sync instead of update?
> - or.. ?

I'll note that this has come up before in the past after we had
distro-sync, and I tried here to use distro-sync instead of update on my
rawhide laptop, and I ran into issues. Unfortunately, it's been a while
so I can't fully recall what the problem was, but I do remember
distro-sync failed and I had to use update. I can give it a try again
and see if things are any better.

Do note that distro-sync can downgrade packages, but can't handle all
the cases. ie, upgrade postgresql and update all your data you can't
just downgrade the rpm and be fine. Or any number of other scriptlets
that do things that cannot easily be reversed.
> 
> Random stupid question, what does update bring in addition to distro-sync?
> Is one more cpu/memory/bandwidth expensive than the other?

No, just distro-sync will downgrade things to match the repo in addition
to upgrading things to match the repo.

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

[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Image-ExifTool-10.80-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-0150540ebe

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2018-03-07 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
The EPEL Steering Committee will have a weekly meeting to cover current tasks 
and problems needed to keep EPEL going.


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

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

Re: Frequently broken Rawhide/Branched composes

[Randy Barlow]

On 03/03/2018 01:34 PM, Kevin Kofler wrote:
> That is due to the "Rawhide can never go backwards" policy, which I still do 
> not understand the point of, especially in the light of "distro-sync" having 
> been supported by both the old yum and the new dnf for years.

Sometimes an updated package makes changes to its data structures. For
example, consider if the package does some kind of migration to its data
in such a way that the new version can read it, but the old cannot (e.g.
a PostgreSQL upgrade, and IIRC the Firefox discussion from a while ago
also noted that it cannot be downgraded in all cases). Thus, distro-sync
doesn't work in all cases if the upgraded package has already made
changes on the user's system.



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

[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Image-ExifTool-10.80-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-989ad3ad8a

-- 
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: Critpath karma

[Randy Barlow]

I've filed https://github.com/fedora-infra/bodhi/issues/2194 about
considering removing this feature from Bodhi. I listed an example there
where I thought the feature was actively harmful in a particular case,
due to users not knowing that the field doesn't actually count for anything.



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: Critpath karma

[Randy Barlow]

On 03/06/2018 10:30 AM, Dennis Gilmore wrote:
> In the past we required a proven tester to sign off on testing a
> critpath package to provide extra assurance that the update worked and
> did not break critical functionality. I do not believe that we are
> using proven testers any longer. Having some requirements on automated
> testing for critpath I think could be useful. I would suggest that we
> look at how we could reuse it to a different purpose rather than
> throwing it out.

Interesting, so it had a purpose in the past but nothing uses it
anymore. We do have requirements for critical path packages to reach a
certain level of normal karma, and we do have Greenwave to enforce
automated tests. The critpath karma field does seem like it wouldn't
serve a purpose anymore, even given automated testing.



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: Critpath karma

[Randy Barlow]

On 03/06/2018 08:53 AM, Peter Robinson wrote:
> Critical path were (are) packages that were in blocking deliverables,
> it pre-dates the Editions, basically if it was a core blocking package
>  eg part of Workstaiton, it needed to get more testing/karma before it
> could go stable, adamw probably has the most knowledge I suspect :)

Yeah I'm familiar with the critical path packages, but I meant to focus
more on why Bodhi has a separate karma for them, in addition to the
regular karma, that basically doesn't get used.



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

[Bug 1550055] perl-Test-Harness-3.41 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Test-Harness-3.41-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1542731] Please provide a package for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Sys-Statistics-Linux-0
   ||.66-14.el7
 Resolution|--- |ERRATA
Last Closed||2018-03-06 12:30:21



--- Comment #5 from Fedora Update System  ---
perl-Sys-Statistics-Linux-0.66-14.el7 has been pushed to the Fedora EPEL 7
stable repository. If problems still persist, please make note of it in this
bug report.

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

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc26 has been pushed to the Fedora 26
stable repository. If problems still persist, please make note of it in this
bug report.

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

[Bug 1547462] perl-Term-Chrome-2.01 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Term-Chrome-2.01-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1549556] perl-libwww-perl-6.33 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-libwww-perl-6.33-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|bugzilla-5.0.4-1.fc27   |bugzilla-5.0.4-1.fc27
   ||bugzilla-5.0.4-1.fc26



--- Comment #7 from Fedora Update System  ---
bugzilla-5.0.4-1.fc26 has been pushed to the Fedora 26 stable repository. If
problems still persist, please make note of it in this bug report.

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

[Bug 1546584] perl-Importer-0.025 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Importer-0.025-1.fc26 has been pushed to the Fedora 26 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1544162] perl-Dancer-Session-Cookie-0.28 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.29-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1546961] perl-Dancer-Session-Cookie-0.29 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.29-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1532539] [PATCH] Invalid definitions in macros.perl

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-5.24.3-396.fc26 has been pushed to the Fedora 26 stable repository. If
problems still persist, please make note of it in this bug report.

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

[Bug 1544277] perl-Dist-Zilla-6.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Dist-Zilla-6.011-1.fc2 |perl-Dist-Zilla-6.011-1.fc2
   |7   |7
   ||perl-Dist-Zilla-6.011-1.fc2
   ||6



--- Comment #6 from Fedora Update System  ---
perl-Dist-Zilla-6.011-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1548207] perl-DateTime-Format-Flexible-0.29 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-DateTime-Format-Flexible-0.29-1.fc27 has been pushed to the Fedora 27
stable repository. If problems still persist, please make note of it in this
bug report.

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

[Bug 1547462] perl-Term-Chrome-2.01 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Term-Chrome-2.01-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1546961] perl-Dancer-Session-Cookie-0.29 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.29-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1544162] perl-Dancer-Session-Cookie-0.28 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.29-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1479864] Upgrade perl-Net-SSH-Perl to 2.12

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1479864
Bug 1479864 depends on bug 1546648, which changed state.

Bug 1546648 Summary: Review Request: perl-IO-Socket-Socks - Provides a way to 
create socks (4 or 5) client or server
https://bugzilla.redhat.com/show_bug.cgi?id=1546648

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
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 1546584] perl-Importer-0.025 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Importer-0.025-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||bugzilla-5.0.4-1.fc27
 Resolution|--- |ERRATA
Last Closed||2018-03-06 12:19:42



--- Comment #6 from Fedora Update System  ---
bugzilla-5.0.4-1.fc27 has been pushed to the Fedora 27 stable repository. If
problems still persist, please make note of it in this bug report.

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

[Bug 1544277] perl-Dist-Zilla-6.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Dist-Zilla-6.011-1.fc2
   ||7
 Resolution|--- |ERRATA
Last Closed||2018-03-06 12:19:22



--- Comment #5 from Fedora Update System  ---
perl-Dist-Zilla-6.011-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 17:42, Dennis Gilmore ha scritto:
> El mar, 06-03-2018 a las 17:20 +0100, Germano Massullo escribió:
>> Il 06/03/2018 16:35, Dennis Gilmore ha scritto:
>>> El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
 During package firefox-pkcs11-loader build, the following two
 spec
 file
 lines

 %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
 %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json

 and also this variant

 %dir %{_libdir}/mozilla/pkcs11-modules/
 %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json

 lead to errors

 Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-
 loader-
 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
 File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
 modules/onepinopenscpkcs11.json
>>> noarch only builds do not have %{_lib} or %{_libdir} defined 
>>>
>> Thank you very much, I solved with
>> %{cmake} . -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}
>>
>> Could you please leave a feedback about the comment I am going to
>> attach
>> in the spec file?
>>
>> # in noarch builds, %%{_libdir} is not defined in cmake, so the
>> default
>> # installation would try installing for example
>> # file onepinopenscpkcs11.json
>> # into /usr/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>> # even if the system architecture is 64bit. This will lead to errors
>> because
>> # the %%files entry
>> # %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>> # would be defined as
>> # /usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>> # that is different from the previous one
> so the content should always be in /usr/lib for a noarch build as it
> has to work for cases where _lib is both lib64 and lib  if the content
> needs to be in /usr/lib64/mozilla/pkcs11-modules on systems with lib64
> as the value for _lib then your content and package needs to be
> archful. I am concerned that you are not going to get the outcome you
> expect here.

Thank you Dennis. Therefore I think that rpmlint messages should be
improved about noarch packages.
I started working on %{_lib} / %{_libdir} on firefox-pkcs11-loader spec
file because originally there were %files entries like
%_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
and rpmlint returned errors like

firefox-pkcs11-loader.src:43: E: hardcoded-library-path in 
%_prefix/lib/mozilla/pkcs11-modules/
firefox-pkcs11-loader.src:44: E: hardcoded-library-path in 
%_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json

So I started working to fix them
Source:
https://taskotron.fedoraproject.org/artifacts/all/46067844-18bd-11e8-9d96-525400fc9f92/task_output/firefox-pkcs11-loader-3.13.0-1.fc27.log
https://bodhi.fedoraproject.org/updates/FEDORA-2018-4558f54f10
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Sérgio Basto]

On Tue, 2018-03-06 at 12:20 +0100, Florian Weimer wrote:
> On 03/05/2018 05:55 PM, Sérgio Basto wrote:
> > On Mon, 2018-01-22 at 16:24 +0100, Florian Weimer wrote:
> > > ### Disable strict symbol checks in the link editor (ld)
> > > 
> > > By default, the link editor will refuse to link shared objects
> > > which
> > > contain undefined symbols.  In some cases (such as when a DSO is
> > > loaded as a plugin and is expected to bind to symbols in the main
> > > executable), undefined symbols are expected.  In this case, you
> > > can
> > > add
> > > 
> > >   %undefine _strict_symbol_defs_build
> > > 
> > > to the RPM spec file to disable these strict
> > > checks.  Alternatively,
> > > you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the
> > > gcc
> > > command line).  The latter needs binutils 2.29.1-12.fc28 or
> > > later.
> > > 
> > > 
> > > This is also part of the build flags documentation at:
> > > 
> > >  > > /f/b
> > > uildflags.md>
> > IMHO, also in https://fedoraproject.org/wiki/Changes/BINUTILS2291
> > or
> > should link to  https://src.fedoraproject.org/rpms/redhat-rpm-confi
> > g/bl
> > ob/master/f/buildflags.md or should mention that we may use:
> > %undefine _strict_symbol_defs_build
> 
> The change was reverted, so this is currently not necessary.
> 
> The next change will discuss remedies.

Again, IMHO, wiki page should be updated (add something like: -z defs
was postponed ... ) and still it should be added a link to
buildflags.md . 

BTW "%define _strict_symbol_defs_build 1" will enable -z defs ? 


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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Dennis Gilmore]

El mar, 06-03-2018 a las 17:20 +0100, Germano Massullo escribió:
> Il 06/03/2018 16:35, Dennis Gilmore ha scritto:
> > El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
> > > During package firefox-pkcs11-loader build, the following two
> > > spec
> > > file
> > > lines
> > > 
> > > %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
> > > %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> > > 
> > > and also this variant
> > > 
> > > %dir %{_libdir}/mozilla/pkcs11-modules/
> > > %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> > > 
> > > lead to errors
> > > 
> > > Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-
> > > loader-
> > > 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
> > > File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> > > 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
> > > modules/onepinopenscpkcs11.json
> > 
> > noarch only builds do not have %{_lib} or %{_libdir} defined 
> > 
> 
> Thank you very much, I solved with
> %{cmake} . -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}
> 
> Could you please leave a feedback about the comment I am going to
> attach
> in the spec file?
> 
> # in noarch builds, %%{_libdir} is not defined in cmake, so the
> default
> # installation would try installing for example
> # file onepinopenscpkcs11.json
> # into /usr/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # even if the system architecture is 64bit. This will lead to errors
> because
> # the %%files entry
> # %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # would be defined as
> # /usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> # that is different from the previous one

so the content should always be in /usr/lib for a noarch build as it
has to work for cases where _lib is both lib64 and lib  if the content
needs to be in /usr/lib64/mozilla/pkcs11-modules on systems with lib64
as the value for _lib then your content and package needs to be
archful. I am concerned that you are not going to get the outcome you
expect here.


Dennis

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: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 06, 2018 at 05:15:45PM +0100, Steve Grubb wrote:
> On Tue, 06 Mar 2018 14:34:58 +
> Stephen Gallagher  wrote:
> 
> > On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:  
> > 
> > > On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:  
> > > > On Mon, 5 Mar 2018 23:11:12 +
> > > > Zbigniew Jędrzejewski-Szmek  wrote:
> > > >  
> > > > > - somewhat independently, systemd-sysusers has been beefed up
> > > > > so it is possible to use it to create system users before any
> > > > > files are installed on disk, but honouring admin overrides. In
> > > > > short, we now recommend the following invocation to create
> > > > > users for an rpm which contains files owned by those users:
> > > > >
> > > > > %sysusers_create_package %{name} %SOURCEN
> > > > >
> > > > >   where %SOURCEN is the tmpfiles.d config file which will be
> > > > > installed by package. This expands to
> > > > >
> > > > > echo "u NAME - -" | systemd-sysusers
> > > > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > > > >
> > > > >   and the "u NAME - -" configuration is applied with a priority
> > > > > that /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > > > >   /etc/sysusers.d/NAME.conf will override this).
> > > > >
> > > > > [1]
> > > > > https://raw.githubusercontent.com/systemd/systemd/master/NEWS  
> > > >
> > > > How does this interact with useradd and groupadd? Does this
> > > > replace them? And if so, does this send the required audit
> > > > events?  
> > >
> > > It's a very simple tool to create system users and group
> > > in /etc/passwd. It just creates entries
> > > in /etc/{passwd,group,shadow}, and does not interact with audit in
> > > any way afaik. 
> > 
> > Is there some guideline that requires an audit log message to occur
> > whenever a user is added to a system?
> 
> Yes. Absolutely. Even if that user is a system account.
> 
> > We can't necessarily know on every end-user system when a user is
> > added by a central authority like FreeIPA, for example.
> 
> That also has to be audited.
> 
> > Even if we only limit it to dealing with /etc/passwd and friends, there are
> > still plenty of ways for this file to be modified that wouldn't cause
> > it to trigger an audit event unless we added a service to monitor
> > with inotify or similar.
> 
> True. And we do include rules to catch these occurrences. But this not
> the preferred way because it does not give us the full information
> that is required. If we know that we are adding user accounts, we need
> to maintain the information for the whole lifecycle. If FreeIPA adds an
> account, it gets used and trips some audit events, then gets removed,
> we need the history of when it was added and when it was removed and
> by who.

I assume that there some standarized log message to be emitted in this
case? If this is documented somewhere, we could add that, although it'd
probably be easier if somebody who knows audit submitted a pull request.
The sysusers code is at
https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1205.

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

Re: systemd 238 and sysusers

[Steve Grubb]

On Tue, 6 Mar 2018 14:24:27 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> > On Mon, 5 Mar 2018 23:11:12 +
> > Zbigniew Jędrzejewski-Szmek  wrote:
> >   
> > > - somewhat independently, systemd-sysusers has been beefed up so
> > > it is possible to use it to create system users before any files
> > > are installed on disk, but honouring admin overrides. In short,
> > > we now recommend the following invocation to create users for an
> > > rpm which contains files owned by those users:
> > > 
> > > %sysusers_create_package %{name} %SOURCEN
> > > 
> > >   where %SOURCEN is the tmpfiles.d config file which will be
> > > installed by package. This expands to
> > > 
> > > echo "u NAME - -" | systemd-sysusers
> > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > > 
> > >   and the "u NAME - -" configuration is applied with a priority
> > > that /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > >   /etc/sysusers.d/NAME.conf will override this).
> > > 
> > > [1]
> > > https://raw.githubusercontent.com/systemd/systemd/master/NEWS  
> > 
> > How does this interact with useradd and groupadd? Does this replace
> > them? And if so, does this send the required audit events?  
> 
> It's a very simple tool to create system users and group
> in /etc/passwd. It just creates entries
> in /etc/{passwd,group,shadow}, and does not interact with audit in
> any way afaik.

OK. We need it to. I can help you with the events if you can point me
to the code that creates the account/group.

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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 16:35, Dennis Gilmore ha scritto:
> El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
>> During package firefox-pkcs11-loader build, the following two spec
>> file
>> lines
>>
>> %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
>> %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>>
>> and also this variant
>>
>> %dir %{_libdir}/mozilla/pkcs11-modules/
>> %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
>>
>> lead to errors
>>
>> Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
>> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
>> File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
>> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
>> modules/onepinopenscpkcs11.json
> noarch only builds do not have %{_lib} or %{_libdir} defined 
>

Thank you very much, I solved with
%{cmake} . -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir}

Could you please leave a feedback about the comment I am going to attach
in the spec file?

# in noarch builds, %%{_libdir} is not defined in cmake, so the default
# installation would try installing for example
# file onepinopenscpkcs11.json
# into /usr/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
# even if the system architecture is 64bit. This will lead to errors because
# the %%files entry
# %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
# would be defined as
# /usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
# that is different from the previous one
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Steve Grubb]

On Tue, 06 Mar 2018 14:34:58 +
Stephen Gallagher  wrote:

> On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:  
> 
> > On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:  
> > > On Mon, 5 Mar 2018 23:11:12 +
> > > Zbigniew Jędrzejewski-Szmek  wrote:
> > >  
> > > > - somewhat independently, systemd-sysusers has been beefed up
> > > > so it is possible to use it to create system users before any
> > > > files are installed on disk, but honouring admin overrides. In
> > > > short, we now recommend the following invocation to create
> > > > users for an rpm which contains files owned by those users:
> > > >
> > > > %sysusers_create_package %{name} %SOURCEN
> > > >
> > > >   where %SOURCEN is the tmpfiles.d config file which will be
> > > > installed by package. This expands to
> > > >
> > > > echo "u NAME - -" | systemd-sysusers
> > > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > > >
> > > >   and the "u NAME - -" configuration is applied with a priority
> > > > that /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > > >   /etc/sysusers.d/NAME.conf will override this).
> > > >
> > > > [1]
> > > > https://raw.githubusercontent.com/systemd/systemd/master/NEWS  
> > >
> > > How does this interact with useradd and groupadd? Does this
> > > replace them? And if so, does this send the required audit
> > > events?  
> >
> > It's a very simple tool to create system users and group
> > in /etc/passwd. It just creates entries
> > in /etc/{passwd,group,shadow}, and does not interact with audit in
> > any way afaik. 
> 
> Is there some guideline that requires an audit log message to occur
> whenever a user is added to a system?

Yes. Absolutely. Even if that user is a system account.

> We can't necessarily know on every end-user system when a user is
> added by a central authority like FreeIPA, for example.

That also has to be audited.

> Even if we only limit it to dealing with /etc/passwd and friends, there are
> still plenty of ways for this file to be modified that wouldn't cause
> it to trigger an audit event unless we added a service to monitor
> with inotify or similar.

True. And we do include rules to catch these occurrences. But this not
the preferred way because it does not give us the full information
that is required. If we know that we are adding user accounts, we need
to maintain the information for the whole lifecycle. If FreeIPA adds an
account, it gets used and trips some audit events, then gets removed,
we need the history of when it was added and when it was removed and
by who.

> So, I don't see this being any worse than the current state of the
> art. Realistically, such an audit event is useless and noisy;

Not really, it gives us information about account creation or removal
and who did it. This may be normal or an anomaly.

> whether a user is *available* is not interesting in comparison to when that
> user logs in.

That is also interesting as are a lot of things. But if we are creating
accounts then we need the whole lifecycle recorded.

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

Re: [HEADS UP] Changes in wireshark package name

[Randy Barlow]

On 03/06/2018 06:23 AM, Michal Ruprich wrote:
> the plan to drop the GTK+ GUI [1] was approved by FESCO, so I will be
> dropping the wireshark-gtk package in rawhide(currently F29). Also I
> would like to propose that we change the name of wireshark-qt. There are
> three packages now - wireshark-cli, wireshark-gtk and wireshark-qt.
> Since the wireshark-gtk is going away I would like to suggest that we
> change the wireshark-qt to something more generic like wireshark-gui. If
> you feel like there is a reason why I should not do that, please just
> respond to this email.

You can add a Provides on the old name for backwards compatibility if
you want.



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: Frequently broken Rawhide/Branched composes

[Nicolas Mailhot]

Le mardi 06 mars 2018 à 15:53 +0100, Pierre-Yves Chibon a écrit :
> On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> > Pierre-Yves Chibon wrote:
> > 
> > > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> > > > So please let us just repeal that "Rawhide can never go
> > > > backwards"
> > > > policy.
> > > 
> > > This is actually a fair point, but I wonder what prevents us from
> > > doing it today.
> > 
> > Technically, nothing. This is purely a policy issue.
> 
> I'd be curious if there isn't more than just this, or if someone
> remembers why
> that policy was created.

The “never go backwards” policy means that as soon something hits devel
other packages can rely on your package and start adapting
their packages on the basis of your changes. You can not pull the carpet
from under their feet just because you changed your mind.

Stable releases do not need this policy because devel is used to
coordinate the direction the distro does towards.

That's pretty much the only way to run development over a large pile of
code that involves many people over many organisations, timezones and
countries. There is just not enough bandwidth to communicate changes
better than "here is the repo that makes authority, you can rely on it
always going forward".

Linus has pretty much the same policy when he forces kernel developers
to commit on the API they push to him.

Regards,

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

Re: Frequently broken Rawhide/Branched composes

[Pierre-Yves Chibon]

On Tue, Mar 06, 2018 at 02:58:45PM +, Stephen Gallagher wrote:
>On Tue, Mar 6, 2018 at 9:54 AM Pierre-Yves Chibon 
>wrote:
> 
>  On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
>  > Pierre-Yves Chibon wrote:
>  >
>  > > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
>  > >> So please let us just repeal that "Rawhide can never go backwards"
>  > >> policy.
>  > >
>  > > This is actually a fair point, but I wonder what prevents us from
>  doing it
>  > > today.
>  >
>  > Technically, nothing. This is purely a policy issue.
> 
>  I'd be curious if there isn't more than just this, or if someone
>  remembers why
>  that policy was created.
> 
>I *think* that the reason for Rawhide not being able to go backwards is
>simple RPM limitations; if people have updated their system with rawhide
>packages and encounter a serious bug, if we just roll the updates repo
>back to the previous working package, the people who upgraded to it have
>no *automatic* way forwards.
>Though, I suppose we could perhaps implement this policy if we
>special-cased (or simply encouraged) people on Rawhide to use distro-sync
>instead of simple update. 

> But that has its own issues.

Sorry, just to be clear, what would have its own issues:
- asking rawhide users to use distro-sync instead of update?
- automatically have dnf detect it's running in rawhide and default to
  distro-sync instead of update?
- or.. ?

Random stupid question, what does update bring in addition to distro-sync?
Is one more cpu/memory/bandwidth expensive than the other?


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

[Modularity] Working Group IRC meeting minutes (2018-03-06)

[Nils Philippsen]

=
#fedora-meeting-3: Meeting of the Modularity Working Group (once every two 
weeks)
=


Meeting started by nils at 15:00:00 UTC.

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-03-06/modularity_wg.2018-03-06-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-03-06/modularity_wg.2018-03-06-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-3/2018-03-06/modularity_wg.2018-03-06-15.00.log.html


Meeting summary
---
* Roll Call  (nils, 15:00:06)

* Agenda  (nils, 15:01:48)
  * [puiterwijk]: Using Bodhi for modular content  (nils, 15:01:48)
  * [sgallagh]:  imminent libmodulemd-1.1 release  (nils, 15:03:37)

* Using Bodhi for modular content  (nils, 15:03:59)
  * puiterwijk's suggestion to enable the bodhi workflow for modules was
accepted  (nils, 15:21:57)

* imminent libmodulemd-1.1 release  (nils, 15:22:19)
  * libmodulemd-1.1 coming sometime this week, may require minor tweaks
to python import  (sgallagh, 15:28:19)

* Open Floor  (nils, 15:29:11)
  * autosigning is now working for modules and signs it as soon as a
module is submitted to Bodhi  (nils, 15:30:03)

Meeting ended at 15:33:01 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nils (40)
* sgallagh (24)
* puiterwijk (20)
* zodbot (15)
* contyk (5)
* sct (4)
* tflink (2)
* langdon (2)
* asamalik (1)
* dgilmore (1)
* mikedep333 (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Dennis Gilmore]

El mar, 06-03-2018 a las 15:29 +0100, Germano Massullo escribió:
> During package firefox-pkcs11-loader build, the following two spec
> file
> lines
> 
> %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
> %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> and also this variant
> 
> %dir %{_libdir}/mozilla/pkcs11-modules/
> %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> lead to errors
> 
> Directory not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
> File not found: /builddir/build/BUILDROOT/firefox-pkcs11-loader-
> 3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-
> modules/onepinopenscpkcs11.json

noarch only builds do not have %{_lib} or %{_libdir} defined 

Dennis

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: Critpath karma

[Dennis Gilmore]

El mar, 06-03-2018 a las 08:48 -0500, Randy Barlow escribió:
> Greetings!
> 
> Does anybody here know the history and/or purpose behind Bodhi's
> critical path karma? A brief grepping of Bodhi's codebase makes me
> think
> it isn't really used by Bodhi for any purpose other than recording
> and
> displaying people's entries. I.e., it doesn't seem to be used in
> Bodhi's
> state machine. It also seems to be confusing for testers.
> 
> Does it serve a purpose? If not, should we remove it?

In the past we required a proven tester to sign off on testing a
critpath package to provide extra assurance that the update worked and
did not break critical functionality. I do not believe that we are
using proven testers any longer. Having some requirements on automated
testing for critpath I think could be useful. I would suggest that we
look at how we could reuse it to a different purpose rather than
throwing it out.

Dennis

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: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Daniel P . Berrangé]

On Tue, Mar 06, 2018 at 04:19:48PM +0100, Germano Massullo wrote:
> Il 06/03/2018 15:50, Daniel P. Berrangé ha scritto:
> > On Tue, Mar 06, 2018 at 03:46:38PM +0100, Germano Massullo wrote:
> >> Il 06/03/2018 15:34, Daniel P. Berrangé ha scritto:
> >>> %{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
> >>> to "/usr/lib64", but your app is installing files into "/usr/lib"
> >>> instead.
> >> I suspected this, but I found no hardcoded paths in
> >> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt#L37
> >> so I don't understand why it installs in /usr/lib
> > In the specfile it has  %{cmake} which expands to
> >
> >   ...some compiler flags stuff...
> >   /usr/bin/cmake \
> > -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
> > -DCMAKE_INSTALL_PREFIX:PATH=/usr \
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
> > -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
> > -DSYSCONF_INSTALL_DIR:PATH=/etc \
> > -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
> > %if "lib64" == "lib64" 
> > -DLIB_SUFFIX=64 \
> > %endif 
> > -DBUILD_SHARED_LIBS:BOOL=ON
> >
> > So could be something not correctly honouring LIB_INSTALL_DIR and
> > or LIB_SUFFIX variables.
> >
> > Regards,
> > Daniel
> In
> https://copr-be.cloud.fedoraproject.org/results/germano/firefox-pkcs11-loader/fedora-27-x86_64/00724888-firefox-pkcs11-loader/builder-live.log
> 
> I can read
> 
> CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:237 
> (message):
>   Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
>   target architecture is known.  Please enable at least one language before
>   including GNUInstallDirs.
> 
> So I guess it is a bug in
> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt
> If you have any idea how I could patch it, I would be happy to make a
> pull request

Afraid I stay away from CMake in general so leave that upto someone else
to suggest a fix

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 16:19, Germano Massullo ha scritto:
> Il 06/03/2018 15:50, Daniel P. Berrangé ha scritto:
>> On Tue, Mar 06, 2018 at 03:46:38PM +0100, Germano Massullo wrote:
>>> Il 06/03/2018 15:34, Daniel P. Berrangé ha scritto:
 %{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
 to "/usr/lib64", but your app is installing files into "/usr/lib"
 instead.
>>> I suspected this, but I found no hardcoded paths in
>>> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt#L37
>>> so I don't understand why it installs in /usr/lib
>> In the specfile it has  %{cmake} which expands to
>>
>>   ...some compiler flags stuff...
>>   /usr/bin/cmake \
>> -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
>> -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
>> -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
>> -DCMAKE_INSTALL_PREFIX:PATH=/usr \
>> -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
>> -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
>> -DSYSCONF_INSTALL_DIR:PATH=/etc \
>> -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
>> %if "lib64" == "lib64" 
>> -DLIB_SUFFIX=64 \
>> %endif 
>> -DBUILD_SHARED_LIBS:BOOL=ON
>>
>> So could be something not correctly honouring LIB_INSTALL_DIR and
>> or LIB_SUFFIX variables.
>>
>> Regards,
>> Daniel
> In
> https://copr-be.cloud.fedoraproject.org/results/germano/firefox-pkcs11-loader/fedora-27-x86_64/00724888-firefox-pkcs11-loader/builder-live.log
>
> I can read
>
> CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:237 
> (message):
>   Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
>   target architecture is known.  Please enable at least one language before
>   including GNUInstallDirs.
>
> So I guess it is a bug in
> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt
> If you have any idea how I could patch it, I would be happy to make a
> pull request

I tried to manually build the software using upstream procedure, and I
got the same errors, so I filled a bugreport
https://github.com/open-eid/firefox-pkcs11-loader/issues/10
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Call for testing of xserver 1.20 release candidates

[Adam Jackson]

On Tue, 2018-03-06 at 12:57 +, Leigh Scott wrote:
> > On Mon, 2018-03-05 at 18:03 +0100, Kalev Lember wrote:
> > 
> > Much as I would like to, the change process does exist, and says it's
> > far too late for that for F28 gold.
> 
> Can't  new Xorg wait till F29?,  isn't this change to big and prone
> to breakage to be pushed after F28 release?

That I'm suggesting doing it is evidence that I think it should be safe
to do. We've rebased llvm in live releases and that's far more
disruptive.

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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 15:50, Daniel P. Berrangé ha scritto:
> On Tue, Mar 06, 2018 at 03:46:38PM +0100, Germano Massullo wrote:
>> Il 06/03/2018 15:34, Daniel P. Berrangé ha scritto:
>>> %{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
>>> to "/usr/lib64", but your app is installing files into "/usr/lib"
>>> instead.
>> I suspected this, but I found no hardcoded paths in
>> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt#L37
>> so I don't understand why it installs in /usr/lib
> In the specfile it has  %{cmake} which expands to
>
>   ...some compiler flags stuff...
>   /usr/bin/cmake \
> -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
> -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
> -DCMAKE_INSTALL_PREFIX:PATH=/usr \
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
> -DSYSCONF_INSTALL_DIR:PATH=/etc \
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
> %if "lib64" == "lib64" 
> -DLIB_SUFFIX=64 \
> %endif 
> -DBUILD_SHARED_LIBS:BOOL=ON
>
> So could be something not correctly honouring LIB_INSTALL_DIR and
> or LIB_SUFFIX variables.
>
> Regards,
> Daniel
In
https://copr-be.cloud.fedoraproject.org/results/germano/firefox-pkcs11-loader/fedora-27-x86_64/00724888-firefox-pkcs11-loader/builder-live.log

I can read

CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:237 
(message):
  Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
  target architecture is known.  Please enable at least one language before
  including GNUInstallDirs.

So I guess it is a bug in
https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt
If you have any idea how I could patch it, I would be happy to make a
pull request
___
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++

[Jan Rybar]

done: procps-ng, psmisc, psacct

On 02/18/2018 06:09 PM, 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.

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


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

Re: Frequently broken Rawhide/Branched composes

[Stephen Gallagher]

On Tue, Mar 6, 2018 at 9:54 AM Pierre-Yves Chibon 
wrote:

> On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> > Pierre-Yves Chibon wrote:
> >
> > > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> > >> So please let us just repeal that "Rawhide can never go backwards"
> > >> policy.
> > >
> > > This is actually a fair point, but I wonder what prevents us from
> doing it
> > > today.
> >
> > Technically, nothing. This is purely a policy issue.
>
> I'd be curious if there isn't more than just this, or if someone remembers
> why
> that policy was created.
>
>
I *think* that the reason for Rawhide not being able to go backwards is
simple RPM limitations; if people have updated their system with rawhide
packages and encounter a serious bug, if we just roll the updates repo back
to the previous working package, the people who upgraded to it have no
*automatic* way forwards.

Though, I suppose we could perhaps implement this policy if we
special-cased (or simply encouraged) people on Rawhide to use distro-sync
instead of simple update. But that has its own issues.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Stephen Gallagher]

On Tue, Mar 6, 2018 at 9:43 AM Kevin Kofler  wrote:

> Jan Kurik wrote:
> > " Beta and Final freezes are in effect from 00:00 UTC of the freeze day."
>
> I always find this very misleading. IMHO, the freeze date announced should
> be the day before (i.e., this needs no actual change to the policies, just
> to the announced days) so that the announced date is the last date that
> changes are allowed.
>
> If I see a deadline given as Tuesday, I expect to be able to submit things
> up to and including Tuesday, not Monday.
>

Intuitively, I completely agree with you. I want to have a last warning
that I need to hurry up and land my changes before I miss my window.

But when I think about it further, I have other thoughts too. The schedule
is public and anyone can look it up at will, so it's not as if this is the
only warning they see. And there's actually net value to the Project as a
whole to *not* give the 24-hour warning. We've always had a high incidence
of mass changes arriving in the last 24-48 hours before each Freeze, which
generally translates into instability for a few days because people see it
as their last chance and land stuff that isn't ready. So I can actually see
an argument for *not* widely encouraging more people to land stuff at the
last minute.

We also do have the one-week notice the Tuesday before, which is probably
our best option; we should continue encourage people to land in the week
before Freeze and try to work out the instabilities beforehand.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Pierre-Yves Chibon]

On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> 
> > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> >> So please let us just repeal that "Rawhide can never go backwards"
> >> policy.
> > 
> > This is actually a fair point, but I wonder what prevents us from doing it
> > today.
> 
> Technically, nothing. This is purely a policy issue.

I'd be curious if there isn't more than just this, or if someone remembers why
that policy was created.

> > The only thing I can think of is that we have no mechanism to choose what
> > goes in rawhide and what does not, from the moment you build it, it will
> > go into rawhide.
> > So maybe gating rawhide, would give us that mechanism to a) prevent
> > package we know are broken from entering rawhide, b) potentially remove
> > from rawhide package we later find are breaking things.
> 
> "b)" can be done without any gating. That's what koji untag-pkg is for.

I suspect there is an ACL question here (which may be one of the reasons why the
policy was put in place).

> > I guess another issue with removing something from rawhide is that
> > something else may have been built on the top of it, thus removing A would
> > imply, automatically rebuilding B, and C, and D...
> 
> That would have to happen anyway, even if you bump Epoch to revert A as is 
> the policy now.

Fair, would be nice to have a way to do that automatically though :)

Maybe, we should only allow removing builds from rawhide for a limited period of
time and when that happens, just rebuild everything that has been built since
the build being removed happened.
There is a need for some tooling there to make it comfortable for all of us, but
we would need to map out carefully the requirements.
I'm not entirely sure I can commit on writing the tool right now, but would you
be willing to help mapping out the requirements this tool would have?

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

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Daniel P . Berrangé]

On Tue, Mar 06, 2018 at 03:46:38PM +0100, Germano Massullo wrote:
> Il 06/03/2018 15:34, Daniel P. Berrangé ha scritto:
> > %{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
> > to "/usr/lib64", but your app is installing files into "/usr/lib"
> > instead.
> 
> I suspected this, but I found no hardcoded paths in
> https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt#L37
> so I don't understand why it installs in /usr/lib

In the specfile it has  %{cmake} which expands to

  ...some compiler flags stuff...
  /usr/bin/cmake \
-DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
-DCMAKE_INSTALL_PREFIX:PATH=/usr \
-DINCLUDE_INSTALL_DIR:PATH=/usr/include \
-DLIB_INSTALL_DIR:PATH=/usr/lib64 \
-DSYSCONF_INSTALL_DIR:PATH=/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/share \
%if "lib64" == "lib64" 
-DLIB_SUFFIX=64 \
%endif 
-DBUILD_SHARED_LIBS:BOOL=ON

So could be something not correctly honouring LIB_INSTALL_DIR and
or LIB_SUFFIX variables.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

Il 06/03/2018 15:34, Daniel P. Berrangé ha scritto:
> %{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
> to "/usr/lib64", but your app is installing files into "/usr/lib"
> instead.

I suspected this, but I found no hardcoded paths in
https://github.com/open-eid/firefox-pkcs11-loader/blob/master/CMakeLists.txt#L37
so I don't understand why it installs in /usr/lib
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Kevin Kofler]

Jan Kurik wrote:
> " Beta and Final freezes are in effect from 00:00 UTC of the freeze day."

I always find this very misleading. IMHO, the freeze date announced should 
be the day before (i.e., this needs no actual change to the policies, just 
to the announced days) so that the announced date is the last date that 
changes are allowed.

If I see a deadline given as Tuesday, I expect to be able to submit things 
up to and including Tuesday, not Monday.

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

Re: [HEADS UP] Changes in wireshark package name

[Kevin Kofler]

Michal Ruprich wrote:
> the plan to drop the GTK+ GUI [1] was approved by FESCO, so I will be
> dropping the wireshark-gtk package in rawhide(currently F29). Also I
> would like to propose that we change the name of wireshark-qt. There are
> three packages now - wireshark-cli, wireshark-gtk and wireshark-qt.
> Since the wireshark-gtk is going away I would like to suggest that we
> change the wireshark-qt to something more generic like wireshark-gui. If
> you feel like there is a reason why I should not do that, please just
> respond to this email.

Why not just "wireshark", if the CLI has its own name anyway?

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

Re: systemd 238 and sysusers

[Stephen Gallagher]

On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> > On Mon, 5 Mar 2018 23:11:12 +
> > Zbigniew Jędrzejewski-Szmek  wrote:
> >
> > > - somewhat independently, systemd-sysusers has been beefed up so it is
> > >   possible to use it to create system users before any files are
> > >   installed on disk, but honouring admin overrides. In short, we now
> > >   recommend the following invocation to create users for an rpm which
> > >   contains files owned by those users:
> > >
> > > %sysusers_create_package %{name} %SOURCEN
> > >
> > >   where %SOURCEN is the tmpfiles.d config file which will be installed
> > >   by package. This expands to
> > >
> > > echo "u NAME - -" | systemd-sysusers
> > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > >
> > >   and the "u NAME - -" configuration is applied with a priority that
> > >   /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > >   /etc/sysusers.d/NAME.conf will override this).
> > >
> > > [1] https://raw.githubusercontent.com/systemd/systemd/master/NEWS
> >
> > How does this interact with useradd and groupadd? Does this replace
> > them? And if so, does this send the required audit events?
>
> It's a very simple tool to create system users and group in /etc/passwd.
> It just creates entries in /etc/{passwd,group,shadow}, and does not
> interact with audit in any way afaik.
>


Is there some guideline that requires an audit log message to occur
whenever a user is added to a system? We can't necessarily know on every
end-user system when a user is added by a central authority like FreeIPA,
for example. Even if we only limit it to dealing with /etc/passwd and
friends, there are still plenty of ways for this file to be modified that
wouldn't cause it to trigger an audit event unless we added a service to
monitor with inotify or similar.

So, I don't see this being any worse than the current state of the art.
Realistically, such an audit event is useless and noisy; whether a user is
*available* is not interesting in comparison to when that user logs in.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: %{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Daniel P . Berrangé]

On Tue, Mar 06, 2018 at 03:29:58PM +0100, Germano Massullo wrote:
> During package firefox-pkcs11-loader build, the following two spec file
> lines
> 
> %dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
> %_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> and also this variant
> 
> %dir %{_libdir}/mozilla/pkcs11-modules/
> %{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> lead to errors
> 
> Directory not found: 
> /builddir/build/BUILDROOT/firefox-pkcs11-loader-3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
> File not found: 
> /builddir/build/BUILDROOT/firefox-pkcs11-loader-3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> (Copr build path URL [1] )
> 
> instead
> 
> %dir %_prefix/lib/mozilla/pkcs11-modules/
> %_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json
> 
> works fine
> (Copr build path URL [2] )
> 
> How can you explain this?

%{_lib} expands to 'lib64' on x86_64, and %{_libdir} thus expands
to "/usr/lib64", but your app is installing files into "/usr/lib"
instead.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Frequently broken Rawhide/Branched composes

[Kevin Kofler]

Pierre-Yves Chibon wrote:

> On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
>> So please let us just repeal that "Rawhide can never go backwards"
>> policy.
> 
> This is actually a fair point, but I wonder what prevents us from doing it
> today.

Technically, nothing. This is purely a policy issue.

> The only thing I can think of is that we have no mechanism to choose what
> goes in rawhide and what does not, from the moment you build it, it will
> go into rawhide.
> So maybe gating rawhide, would give us that mechanism to a) prevent
> package we know are broken from entering rawhide, b) potentially remove
> from rawhide package we later find are breaking things.

"b)" can be done without any gating. That's what koji untag-pkg is for.

> I guess another issue with removing something from rawhide is that
> something else may have been built on the top of it, thus removing A would
> imply, automatically rebuilding B, and C, and D...

That would have to happen anyway, even if you bump Epoch to revert A as is 
the policy now.

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

%{_lib} leads to dir not found, whereas lib works fine (firefox-pkcs11-loader)

[Germano Massullo]

During package firefox-pkcs11-loader build, the following two spec file
lines

%dir %_prefix/%{_lib}/mozilla/pkcs11-modules/
%_prefix/%{_lib}/mozilla/pkcs11-modules/onepinopenscpkcs11.json

and also this variant

%dir %{_libdir}/mozilla/pkcs11-modules/
%{_libdir}/mozilla/pkcs11-modules/onepinopenscpkcs11.json

lead to errors

Directory not found: 
/builddir/build/BUILDROOT/firefox-pkcs11-loader-3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules
File not found: 
/builddir/build/BUILDROOT/firefox-pkcs11-loader-3.13.0-2.fc27.x86_64/usr/lib64/mozilla/pkcs11-modules/onepinopenscpkcs11.json

(Copr build path URL [1] )

instead

%dir %_prefix/lib/mozilla/pkcs11-modules/
%_prefix/lib/mozilla/pkcs11-modules/onepinopenscpkcs11.json

works fine
(Copr build path URL [2] )

How can you explain this?

Thank you for your time


[1]: failed build
https://copr-be.cloud.fedoraproject.org/results/germano/firefox-pkcs11-loader/fedora-27-x86_64/00724879-firefox-pkcs11-loader/

[2]: successful build
https://copr-be.cloud.fedoraproject.org/results/germano/firefox-pkcs11-loader/fedora-27-x86_64/00724888-firefox-pkcs11-loader/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide

[Kalev Lember]

On 03/06/2018 03:24 PM, Björn 'besser82' Esser wrote:
> Am Dienstag, den 06.03.2018, 15:18 +0100 schrieb Kalev Lember:
>> Can you wait with this until after the F28 beta freeze is lifted? If
>> you
>> do a large scale soname bump during the freeze it pretty much makes it
>> impossible to get freeze exception and blocker fixes out to any of the
>> packages in your rebuild list, as they'd be built against the new
>> soname
>> and the stable repo has the old soname.
> 
> Allright, I'll delay fc28 until the beta-freeze is lifted.  Since this
> doesn't affect Rawhide, I'll start with the builds over there in short.

Sounds good to me. Thanks Björn!

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

Re: [SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide

[Björn 'besser82' Esser]

Am Dienstag, den 06.03.2018, 15:18 +0100 schrieb Kalev Lember:
> On 03/06/2018 03:10 PM, Björn 'besser82' Esser wrote:
> > Hello folks,
> > 
> > I'll update json-c to v0.13.1 for fc28 and Rawhide.  This will bump
> > libjson-c so-name from 3 to 4 without any changes to the API.  The
> > bump
> > was done, because some distributions already bumped the so-name to 3
> > with json-c v0.12 on their own.
> > 
> > I'll bump and rebuild all affected packages in one run.  There are
> > no
> > adjustments nor patches needed.
> 
> Can you wait with this until after the F28 beta freeze is lifted? If
> you
> do a large scale soname bump during the freeze it pretty much makes it
> impossible to get freeze exception and blocker fixes out to any of the
> packages in your rebuild list, as they'd be built against the new
> soname
> and the stable repo has the old soname.
> 
> -- 
> Kalev


Allright, I'll delay fc28 until the beta-freeze is lifted.  Since this
doesn't affect Rawhide, I'll start with the builds over there in short.

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

Re: systemd 238 and sysusers

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> On Mon, 5 Mar 2018 23:11:12 +
> Zbigniew Jędrzejewski-Szmek  wrote:
> 
> > - somewhat independently, systemd-sysusers has been beefed up so it is
> >   possible to use it to create system users before any files are
> >   installed on disk, but honouring admin overrides. In short, we now
> >   recommend the following invocation to create users for an rpm which
> >   contains files owned by those users:
> > 
> > %sysusers_create_package %{name} %SOURCEN
> > 
> >   where %SOURCEN is the tmpfiles.d config file which will be installed
> >   by package. This expands to
> > 
> > echo "u NAME - -" | systemd-sysusers
> > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > 
> >   and the "u NAME - -" configuration is applied with a priority that
> >   /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> >   /etc/sysusers.d/NAME.conf will override this).
> > 
> > [1] https://raw.githubusercontent.com/systemd/systemd/master/NEWS
> 
> How does this interact with useradd and groupadd? Does this replace
> them? And if so, does this send the required audit events?

It's a very simple tool to create system users and group in /etc/passwd.
It just creates entries in /etc/{passwd,group,shadow}, and does not
interact with audit in any way afaik.

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

Re: [SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide

[Kalev Lember]

On 03/06/2018 03:10 PM, Björn 'besser82' Esser wrote:
> Hello folks,
> 
> I'll update json-c to v0.13.1 for fc28 and Rawhide.  This will bump
> libjson-c so-name from 3 to 4 without any changes to the API.  The bump
> was done, because some distributions already bumped the so-name to 3
> with json-c v0.12 on their own.
> 
> I'll bump and rebuild all affected packages in one run.  There are no
> adjustments nor patches needed.

Can you wait with this until after the F28 beta freeze is lifted? If you
do a large scale soname bump during the freeze it pretty much makes it
impossible to get freeze exception and blocker fixes out to any of the
packages in your rebuild list, as they'd be built against the new soname
and the stable repo has the old soname.

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

[SO-NAME BUMP] libjson-c.so.4 comes to fc28 and Rawhide

[Björn 'besser82' Esser]

Hello folks,

I'll update json-c to v0.13.1 for fc28 and Rawhide.  This will bump
libjson-c so-name from 3 to 4 without any changes to the API.  The bump
was done, because some distributions already bumped the so-name to 3
with json-c v0.12 on their own.

I'll bump and rebuild all affected packages in one run.  There are no
adjustments nor patches needed.

There might be some general fallout for builds of many packages in
Rawhide for a few minutes;  see `Circular dependencies` for the
reason.

I don't see any big complications during the rebuild as v0.13.1 just
brings the set of patches I already carried downstream in the present
v0.13 builds.

As soon as the builds are done, I'll give a short update of the status.

Cheers,
  Björn


=== Circular dependencies ===

Since we have a circular dependency in rebuilding cryptsetup (and many
other packages having direct or indirect (systemd !!!) BuildRequires on
that package, I'll do the rebuild chains in two passes:

json-c (with a copy of libjson-c.so.3* included) : cryptsetup

and after the rebuilt cryptsetup has landed the build-repos:

json-c (final build, no copy of libjson-c.so.3*) : $other_packages


=== Affected packages (my own packages excluded) ===

abrt
bluez
bti
cryptsetup
device-mapper-multipath
fastd
filezilla
freeradius
fwts
gdal
gdcm
gfal2
girara
gluster-block
lcgdm-dav
libmypaint
libreport
libstorj
libu2f-host
libu2f-server
libverto-jsonrpc
libvmi
mypaint
ndctl
newsbeuter
openhpi
opensips
postgis
riemann-c-client
strongswan
sway
syslog-ng
systemtap
tlog
zmap

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: Kernel marking files in /boot as %ghost

[Colin Walters]

On Tue, Mar 6, 2018, at 3:27 AM, Samuel Rakitničan wrote:

> But what are the original reasons exactly? Seems like those files are 
> used by rpm-ostree. 

The `/usr` files are also copied by grubby.  And while it's true *today*
that rpm-ostree adapted to the /usr/lib/modules change, in fact the
rpm-ostree maintainers were never consulted or notified about this
change and we only found out when things broke in Fedora.
https://github.com/projectatomic/rpm-ostree/pull/143

And there's been a number of followups since then:
https://github.com/projectatomic/rpm-ostree/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed+kernel

> Fedora until this date still uses rpm as a default 
> package manager 

You're not the first to say or imply "rpm-ostree" is not "rpm based",
but I still find it funny.   It's right there in the name of the project!
It's just *also* ostree based.  More about this
https://github.com/projectatomic/rpm-ostree#rpm-ostree-a-true-hybrid-imagepackage-system
and in my recent Devconf.cz talk: https://www.youtube.com/watch?v=eWoFpOoA-tE

> and I don't see why they need to be present by default. 
> Especially because:
> 
> 1. Wasting space when installed
> 2. Breaking rpm feature

Hm, it's a bit surprising to me that the `20-grubby.install` doesn't
pass `--reflink=auto` to `cp`, or actually try to use hardlinks.
That'd probably be an easy patch.
If you have /boot as the same partition, at least ostree does both of those
so you won't actually duplicate space.

As far as `rpm -V`, on ostree-based systems that's spelled `ostree fsck`,
although you still *can* run `rpm -V`.

In practice though honestly rpm-ostree today *doesn't* require "kernel in 
usr/lib/modules"
because since
https://github.com/projectatomic/rpm-ostree/pull/969
we effectively enforce it, regardless of what the kernel.rpm does.  (We need
this for RHEL7 which hasn't made this change, and our dynamic path translation
on import also allows us to e.g. fix up everything for UsrMove, etc.)

So if someone were to try to revert this I wouldn't care too much either way.

But of course I have to say: if you want a fully transactional update system 
for your host, so you're
never worried about interrupted updates and trying to `rpm -V` your kernel, 
that's
what rpm-ostree is today.


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

Re: Critpath karma

[Peter Robinson]

On Tue, Mar 6, 2018 at 1:48 PM, Randy Barlow
 wrote:
> Greetings!
>
> Does anybody here know the history and/or purpose behind Bodhi's
> critical path karma? A brief grepping of Bodhi's codebase makes me think
> it isn't really used by Bodhi for any purpose other than recording and
> displaying people's entries. I.e., it doesn't seem to be used in Bodhi's
> state machine. It also seems to be confusing for testers.
>
> Does it serve a purpose? If not, should we remove it?

Critical path were (are) packages that were in blocking deliverables,
it pre-dates the Editions, basically if it was a core blocking package
 eg part of Workstaiton, it needed to get more testing/karma before it
could go stable, adamw probably has the most knowledge I suspect :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Critpath karma

[Randy Barlow]

Greetings!

Does anybody here know the history and/or purpose behind Bodhi's
critical path karma? A brief grepping of Bodhi's codebase makes me think
it isn't really used by Bodhi for any purpose other than recording and
displaying people's entries. I.e., it doesn't seem to be used in Bodhi's
state machine. It also seems to be confusing for testers.

Does it serve a purpose? If not, should we remove it?



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

[Bug 1549504] perl-Event-Lib-1.03-35.fc29 FTBFS: Lib.xs:131:14: error: ' struct event' has no member named 'ev_arg'

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Event-Lib-1.03-37.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-66d5557fbd

-- 
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 1549504] perl-Event-Lib-1.03-35.fc29 FTBFS: Lib.xs:131:14: error: ' struct event' has no member named 'ev_arg'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Event-Lib-1.03-37.fc29



-- 
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 1549504] perl-Event-Lib-1.03-35.fc29 FTBFS: Lib.xs:131:14: error: ' struct event' has no member named 'ev_arg'

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|kwiz...@gmail.com   |ppi...@redhat.com



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

Re: Call for testing of xserver 1.20 release candidates

[Leigh Scott]

> On Mon, 2018-03-05 at 18:03 +0100, Kalev Lember wrote:
> 
> Much as I would like to, the change process does exist, and says it's
> far too late for that for F28 gold.
> 
> - ajax
Can't  new Xorg wait till F29?,  isn't this change to big and prone to breakage 
to be pushed after F28 release?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Re: Trying out More Go Packaging: Bugs and Questions

[Jan Chaloupka]

Hi Athos,

hope everything is fine and you have better things to do than spending 
much time updating the Go spec files :)


Anything you need and/or anything that could help you to minimize your 
packaging time, please, let us know :).



On 03/04/2018 08:20 PM, Nicolas Mailhot wrote:

Le samedi 03 mars 2018 à 11:47 -0300, Athos Ribeiro a écrit :

Are there any intentions to push the macros into f28? I really liked
the
improvements in the spec file sizes, but porting too many packages now
and keep them updated in both f28 and rawhide (making the branches
completely different) would mean a lot of extra work. Or maybe I am
just
too late here since we are quite close from the beta freeze.

The intention is to get everything in a state everyone likes in -devel,
and then push it back to as many stable releases as possible (including
maybe EL7, EL6 really seems too old)


I took a liberty and pushed the new macros into f27+ yesterday.
The naming and API of each macro should be pretty stable now.
There may be slight changes in the API but that should not be fatal.
Feel free to update you packages on f27+ and let us know if there are 
any difficulties :).



The nice thing about using new macro names is that is can not break any
existing spec file, unchanged specs just won't see the changes (except
maybe %gotest, we had to change it brutally because of its insane
argument structure)


+1


The tooling work has progressed a lot those past days, it should now be
able to accommodate both Jan's workflow and mine. The remaining sticking
points are:

1. have the redhat-rpm-config maintainers push the %forge macros to
stable as they promised, now we're reasonably sure they are bug-free


Once the macro.forge are available in f27+ (maybe even f26), I will be 
more than happy

to dispose all the fallback code I added so the new macros work on f27+.


2. testing testing (help appreciated)!


Definitely. Anything you feel is not right or does not work as expected, 
feel free to open an issue on https://github.com/gofed/go-macros .




2. fixing (ditto)

3. defining a form of default policy (right now we have lots of flags to
exclude things in install/check/autodeps, but no real opinion on what
exclusions make sense)


Agree, so far most of the Go projects I have encountered with seems 
pretty default. But you never know.
The more "exotic" layouts we have, the more logic we can put into the 
macros so the packaging is still user-friendly.



4. documenting the changes in the wiki (help *very* appreciated)!

The latest code is in:
https://github.com/gofed/symbols-extractor/ (for the go code)
https://github.com/gofed/go-macros (for Jan's version of macros and
scripts) or
https://github.com/nim-nim/go-macros/tree/improve-integration (for the
changes I did and Jan didn't merge yet)

…and of course in go-compilers and go-srpm-macros whenever Jan does a
build.

I works fine in the simple tests I had time to do, without the warts and
problems reported after the initial merge. Still have some ideas on how
to improve handling of test and example code


Let's please keep in mind we still need to do decide what we are going 
to do with both wikis.
I would like to consolidate both [1] and [2] documents into a single one 
so there is only

one source of truth about the Go packaging.

[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
[2] https://fedoraproject.org/wiki/More_Go_packaging


Major changes, by memory:

1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix

2. %goinstall now computes project files that need installation, you
don't need the gofiles=$( line anymore. Though of course you can specify
additional files to install as %goinstall arguments. Passing a file
goinstall already wants to install should be transparent without
duplicated file warnings

3. you can add files by extension in goinstall with -e

4. you can specify another import path to goinstall with -i (though that
does not change how code actually references itself so YMMV)

5. new -d -t -r flags to exclude honoured by pretty much all the macros,
read the doc in the macro files of in %{_bindir}/go-rpm-integration

6. lots of tweaks that should be mostly invisible but make things do the
right thing automatically as much as possible

7. automated md file installation and marking as %doc %gocolllectmd is
dead (in my version, not merged by Jan yet)

8. primitive detection of bundled code (but please just rm -fr vendor)

9. lots of weird user cases now work, even if I'm not sure they're all a
good idea

Anyway if someone wants to test the files, check the spec programmingAPI  is 
convenient and sane, and update
https://fedoraproject.org/wiki/More_Go_packaging
with the changes help would be very appreciated.

We tried to keep API changes to the minimum, but there are some, and I'm
not sure I remember all of them, new eyes would be good.

Regards,



Cheers
Jan
___
devel 

Re: Re: Trying out More Go Packaging: Bugs and Questions

[Jan Chaloupka]

On 02/27/2018 07:22 PM, Nicolas Mailhot wrote:

Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit :


How do we test this? I installedtho go-srpm-macros from Rawhide but it
doesn't seem to have the required macros?

Yes in rawhide go-compilers and go-srpm-macros are in an intermediary
not fully tested/integrated state.

The original PR that matched what's in the wiki and is known to work is
here
https://src.fedoraproject.org/rpms/go-compilers/pull-request/2

Just grab the files rebuild the resulting go-compilers package and
you're set to try it on your projects (in a fedora-devel buildroot)

I'll try to mix it with all the nice work Jan did to keep all the parts
where he improved the implementation without the loss of integration
polish of the go-srpm-macros and go-compilers packages he pushed to
fedora-devel. And I definitely do not want something that requires
rewriting the wiki once again :)

Regards,



The latest go-srpm-macros and go-compilers ship the latest version of 
the new macros. Please, let us now if it still does not work for you :).

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

Re: Trying out More Go Packaging: Bugs and Questions

[Jan Chaloupka]

Hi Fabio,

thank you for staying with us in the Go packaging world and for sharing 
any difficulty or problem you encounter with.
I created github repository [1] where you can report all issues wrt. 
macros used in Go packaging.
We are currently in a process of iterating over all the macros. Though, 
I am finally confident we are going in the right direction.
Providing set of macros we can share with goal to simplify and minimize 
package maintenance.
I did not want to make the new macros publicly aware until me and 
Nicolas are sure they work in both our environments.

Yet, it's great to see they are already getting accepted.

[1] https://github.com/gofed/go-macros

Let me answer all question as best as I can as well.

On 02/27/2018 05:21 PM, Nicolas Mailhot wrote:

Le 2018-02-27 15:49, Fabio Valentini a écrit :

Hi


I'll answer in more detail since I have a little more time now


2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".


That's one of the changes Jan made I don't understand either. It's 
looks like an attempt to reintroduce old Go packaging conventions, but 
as they overlap with the new ones (but are not sufficient to replace 
them), no good can come out of it.




The %provider_prefix and %gobaseipath are already gone.
For the %provider_prefix I needed to get more familiar with the forge 
macros Nicolas introduced so I can decide if it is sufficient 
replacement. And it is.
The %gobaseipath macro had the same meaning as %goipath. I wanted to 
stress it must contain the base import path so packagers do not 
accidentally set it to invalid value.
I still believe we should stress that information. However, it can be 
mentioned in the documentation. If not explicitly stressed in the macro 
names it can be later checked by a Go specific spec linter.



3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and
"%{commit}" or "%{version}" is missing as far as I can see.


The original code is in redhat-rpm-config in devel only, Jan tried to 
rewrite it so it works on stable too, and the result is what you saw. 
I think the simplest solution is just to revert this part of the 
rewrite and ask the redhat-rpm-config maintainers to push the original 
working code to stable redhat-rpm-config (they've already indicated 
they will push it to stable as soon as we give them the green light, 
so the whole rewrite thing to avoid doing what was already planed is a 
misunderstanding)




Thanks Nicolas for providing the forge macros. We no longer have to deal 
with the gosource (and other macros) manipulation in the context of the 
Go packaging. The project repository sources processing has been moved 
under general solution. If anything goes wrong with the forged macros, 
please open a bz bug for redhat-rpm-config component (CC'ing Nicolas as 
well).



4) The downloaded tarball has potentially ambiguous names, for example
one of my golang packages (github.com/AudriusButkevicius/cli [1])
produces a "cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball
when using %gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file
with gofed.


But you can't do that. The URL in the spec file is supposed to be 
auditable. Cut and pasting the url in any download tool should 
download the expected archive with the expected filename without any 
manual fixing. Changing the archive name in the end of a github URL 
still produces the file name you do not like in Firefox for example, 
so you have to live with this filename.


It is unfortunate that the archive naming conventions chosen by github 
and most of its competitors are so ambiguous, but we can not change 
them at Fedora level. It makes setting

%_sourcedir %{_topdir}/SOURCES/%{name}

in .rpmmacros almost mandatory when working with such hosting services.


5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released
version, ignoring the "commit" tag completely.


That's one of the rewrite simplifications that does not work out in 
practice.



6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files


This part is simple, just do not include a %build section if you're 
not building anything.




Thanks Igor (ignatenko) for pointing this out :). If the %build section 
is specified the rpm tries to create debuginfo rpm. Which it fails to do 
so as pure devel rpm does not ship any binary.



(and warnings about duplicate files)


This looks like a rewrite bug, I never had this with the original code 
I submitted :(



The contents of the .spec file at the point where I gave up trying to
get it to build successfully are available via this gist link:

Re: Attempting to contact unresponsive maintainers - xing, noriko, aortega, jcholast, mzatko

[Pavel Valena]

- Original Message -
> From: "Kevin Fenzi" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, March 5, 2018 9:03:50 PM
> Subject: Re: Attempting to contact unresponsive maintainers - xing, noriko, 
> aortega, jcholast, mzatko
> 
> On 02/07/2018 10:27 AM, Kevin Fenzi wrote:
> > Greetings, we've been told that the email addresses for these package
> > maintainers are no longer valid. I'm starting the unresponsive
> > maintainer policy to find out if they are still interested in
> > maintaining their packages (and if so, have them update their email
> > addresses in FAS).
> > 
> > If they're not interested in maintaining or we can't locate them in 1
> > week, I'll have FESCo orphan the packages so that others can take them
> > over.
> > 
> > If you have a way to contact these maintainers, please let them know
> > that we'd appreciate knowing what to do with their packages. Thanks!
> 
> I've heard back from one of them, but not any of the others.
> 
> So, accordingly I have orphaned the following packages:
> 
> rpms/perl-Pod-Plainer
> rpms/peervpn
> rpms/arm-none-eabi-gdb
> rpms/rubygem-awesome_print

I'd like to take rubygem-awesome_print - https://pagure.io/releng/issue/7373

Pavel


> rpms/rubygem-colored
> rpms/rubygem-slim
> 
> If you wish to become point of contact for these or any other orphaned
> packages, please let this list know and file a releng ticket to reassign
> the package(s).
> 
> and have also removed the bugzilla component for
> rpms/qpidpy as this package no longer existed in Fedora.
> 
> kevin
> --
> > 
> > xing:
> > 
> >   https://src.fedoraproject.org/user/xning
> > 
> >   Projects:
> > 
> >   https://src.fedoraproject.org/rpms/perl-Pod-Plainer [product: Fedora]
> 
> 
> ...snip...
> > 
> > aortega:
> > 
> >   Projects:
> > 
> >   qpidpy [product: Fedora]
> > 
> >   qpidrb [product: Fedora]
> > 
> > jcholast:
> > 
> >   https://src.fedoraproject.org/user/jcholast
> > 
> >   Projects:
> > 
> >   peervpn [product: Fedora]
> > 
> > mzatko:
> > 
> >   https://src.fedoraproject.org/user/mzatko
> > 
> >   Projects:
> > 
> >   arandr [product: Fedora]
> >   rubygem-slim [product: Fedora]
> >   rubygem-awesome_print [product: Fedora]
> >   rubygem-colored [product: Fedora]
> >   arm-none-eabi-gdb [product: Fedora]
> > 
> > kevin
> > 
> > 

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org