Granularity in disable mangling shebangs

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since redhat-rpm-config-97-1.fc28 you can use 2 new variables:

* `__brp_mangle_shebangs_exclude_from` to exclude specific paths from mangling.
* `__brp_mangle_shebangs_exclude` to exclude specific shebangs from mangling.

Those are using same syntax as Requires/Provides filtering (REGEX_EXTENDED), so
you can use AutoProvidesAndRequiresFiltering guidelines[0] as reference for
syntax. I have opened FPC ticket to mention this in guidelines[1].

Big thanks goes to Miro Hrončok for implementing this!

[0] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
[1] https://pagure.io/packaging-committee/issue/750
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFPXwACgkQaVcUvRu8
X0y8SA//dtvyU2BWbmvWix4fHm9KpHWp3ACpROdJpip+cJTW/7u6gP3q0GGED8cU
p7nlBArzg0DwLmi9pDmTum9Q7KanvgqFDnjUmxZw9H4Sz8D6xZMdokmVv0Q1mF5O
9sKmj+xpOqbn/CG/ywA7Y39JiNbGS+Fk+6eBSLLAbYGDKSGbzg5QAdFdgbiHVTD/
C832xUhlF3pP+L4LgYi11zjyWgTPdOSgL6/mK9dS/GDLU7nXx45Cp84hpnNfcJrr
tTtW2CP5Jnwtf7lH5hHIhyL51KEKPbfr/pm61EAO5LnS0Ufq9/a2bOvKJkcBpk7d
uhcpSvVi46a4DLybH2cNqVw8dmItzMOlWAS9GiR45x5x2eD2ptGtx854wHTZGBL9
4UQr6AF/NCZ0tizB003sWXmi6PDw1C8HZRR4PTxEua+RFofIYFSpk+887NHExwHX
EZEa32tQsOjH6/02J2pyyzvHRjZCnk7b0OWIq7doefUkYv4R50D0j9nrH6fSj4r9
CkW7rIijJTA/wW6hgYbbF2JsyDDdhI8BeUCcsogwvgF50a8Zc0qMwXiImXIwYrT2
TzlZ18TdMGutOGAtcJgMeKB7d4oh9ctAgH0t7q4DMsGVBW8A/+6dYVus7PJDkFfx
Coeb/eH3cqQcLbvOxvICRBI2gCEIBvY3HmdBnVm5ISzWR7tRIiE=
=Tn9w
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clang -mcet -fcf-protection

[Florian Weimer]

On 02/14/2018 08:22 PM, Richard W.M. Jones wrote:

It uses both.  In this case it uses clang because it has to build a
clang extension (as well as a gcc extension).


Isn't Clang compiled with GCC, too?  (At least in the past, we didn't 
bootstrap it.)  Why is Clang required to build the extension?


(Clang is obviously needed to test the plug-in, but upstream probably 
has very precise ideas about the compiler flags to use for that anyway.)


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

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Vít Ondruch]

Dne 14.2.2018 v 21:59 Igor Gnatenko napsal(a):
>
> * Speak up and tell package names I should not touch because … (you should
> complete this sentence).
> * Fix up packages and tell package names I should not touch because
> you did
> that already.
> * Tell package names you want to remove ldconfig scriptlets entirely
> instead
> of replacing them with %ldconfig_scriptlets and get fix **for free**.
> * Ignore this message and get fix **for free**.


> ruby jstribny mmorsi mtasaka ruby-packagers-sig
> skottler vondruch vondruch

https://src.fedoraproject.org/rpms/ruby/c/72c55bdcb29463642399ea365230a8b11c5c7842?branch=master


V.



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

Re: Removal of BuildRoot

[Vít Ondruch]

Dne 15.2.2018 v 07:55 Remi Collet napsal(a):
> Le 15/02/2018 à 07:47, Igor Gnatenko a écrit :
>> On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:
>>> nicolas.mail...@laposte.net wrote:
 Hi,

 Thank you for cleaning up the cruft in the repository !

 Regards,

>>> Agreed. I'm usually pretty anal about others touching packages I
>>> maintain without at least a heads-up but in this case it doesn't bother
>>> me. I guess particularly since he didn't spin up a build or poke the
>>> n-v-r so reverting it if I really hated it or it broke something would
>>> be trivially easy.
>>> As an aside, it might be nice though to be able to watch a package and
>>> get automated notifications when things change. I don't maintain that
>>> many packages though. I'd imagine that for some this could be rather
>>> onerous, but I had no idea these changed were applied until I went and
>>> looked.
>> It is possible with fedmsg which we use. You can set notifications in special
>> webservice[0] (although I find settings in it counter-intuitive). Simplest 
>> one
>> is to set up notifications on all packages you maintain.
> Sadly, commit notifications does NOT work for months
> (works for old packages, not for newly imported one)

It does not work at all. I did not get any notification about mass
rebuild changes what so ever. No build notifications, no commit
notifications, anything ...

V.

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

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

[Samuel Rakitničan]

Hello,

Need help figuring this out since I have no idea what this means.

The cbang code that is included in camotics fails to build with the following 
messages. It is failing only for i686 and armv7hl architectures.

g++ -o build/cbang/log/Logger.o -c -std=c++11 -ggdb -Wall -Werror 
-I/usr/include/v8-3.14/ -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions 
-fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
-Wno-error=parentheses -Wno-deprecated-declarations -DDEBUG -D_REENTRANT 
-DHAVE_EXPAT -DHAVE_PTHREADS -DHAVE_LIBSQLITE -DHAVE_V8 -DDEBUG_LEVEL=1 
-DUSING_CBANG -Iinclude -Isrc -Isrc/boost src/cbang/log/Logger.cpp
In file included from /usr/include/string.h:494,
 from src/boost/boost/range/detail/implementation_help.hpp:18,
 from src/boost/boost/range/end.hpp:24,
 from src/boost/boost/range/functions.hpp:19,
 from src/boost/boost/range/iterator_range_core.hpp:38,
 from src/boost/boost/range/iterator_range.hpp:13,
 from src/boost/boost/iostreams/traits.hpp:38,
 from src/boost/boost/iostreams/detail/dispatch.hpp:17,
 from src/boost/boost/iostreams/flush.hpp:17,
 from src/boost/boost/iostreams/close.hpp:18,
 from src/boost/boost/iostreams/operations.hpp:16,
 from src/cbang/http/ChunkedStreamFilter.h:41,
 from src/cbang/http/Transaction.h:37,
 from src/cbang/http/Transaction.cpp:33:
In function 'void* memcpy(void*, const void*, size_t)',
inlined from 'std::streamsize cb::HTTP::ChunkedStreamFilter::write(Sink&, 
const char*, std::streamsize) [with Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/cbang/http/ChunkedStreamFilter.h:131:19,
inlined from 'static std::streamsize 
boost::iostreams::detail::write_filter_impl::write(T&,
 Sink&, const typename boost::iostreams::char_type_of::type*, 
std::streamsize) [with T = cb::HTTP::ChunkedStreamFilter; Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/boost/boost/iostreams/write.hpp:142:31,
inlined from 'std::streamsize boost::iostreams::write(T&, Sink&, const 
typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = 
boost::reference_wrapper; Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/boost/boost/iostreams/write.hpp:55:45,
inlined from 'static std::streamsize 
boost::iostreams::detail::flt_wrapper_impl::write(Filter&,
 Sink*, const typename boost::iostreams::char_type_of::type*, 
std::streamsize) [with Filter = 
boost::reference_wrapper; Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/boost/boost/iostreams/detail/adapter/concept_adapter.hpp:278:30,
inlined from 'std::streamsize 
boost::iostreams::detail::concept_adapter::write(const char_type*, 
std::streamsize, Sink*) [with Sink = 
boost::iostreams::detail::linked_streambuf; T = 
boost::reference_wrapper]' at 
src/boost/boost/iostreams/detail/adapter/concept_adapter.hpp:85:32,
inlined from 'void boost::iostreams::detail::indirect_streambuf::sync_impl() [with T = 
boost::reference_wrapper; Tr = 
std::char_traits; Alloc = std::allocator; Mode = 
boost::iostreams::bidirectional]' at 
src/boost/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:392:18:
/usr/include/bits/string_fortified.h:34:33: error: 'void* 
__builtin_memcpy(void*, const void*, unsigned int)' reading 31 bytes from a 
region of size 16 [-Werror=stringop-overflow=]
   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
  ~~~^~~
In function 'void* memcpy(void*, const void*, size_t)',
inlined from 'std::streamsize cb::HTTP::ChunkedStreamFilter::write(Sink&, 
const char*, std::streamsize) [with Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/cbang/http/ChunkedStreamFilter.h:131:19,
inlined from 'static std::streamsize 
boost::iostreams::detail::write_filter_impl::write(T&,
 Sink&, const typename boost::iostreams::char_type_of::type*, 
std::streamsize) [with T = cb::HTTP::ChunkedStreamFilter; Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/boost/boost/iostreams/write.hpp:142:31,
inlined from 'std::streamsize boost::iostreams::write(T&, Sink&, const 
typename boost::iostreams::char_type_of::type*, std::streamsize) [with T = 
boost::reference_wrapper; Sink = 
boost::iostreams::detail::linked_streambuf]' at 
src/boost/boost/iostreams/write.hpp:55:45,
inlined 

Re: Removal of BuildRoot

[Remi Collet]

Le 15/02/2018 à 07:47, Igor Gnatenko a écrit :
> On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:
>> nicolas.mail...@laposte.net wrote:
>>> Hi,
>>>
>>> Thank you for cleaning up the cruft in the repository !
>>>
>>> Regards,
>>>
> 
>> Agreed. I'm usually pretty anal about others touching packages I
>> maintain without at least a heads-up but in this case it doesn't bother
>> me. I guess particularly since he didn't spin up a build or poke the
>> n-v-r so reverting it if I really hated it or it broke something would
>> be trivially easy.
> 
>> As an aside, it might be nice though to be able to watch a package and
>> get automated notifications when things change. I don't maintain that
>> many packages though. I'd imagine that for some this could be rather
>> onerous, but I had no idea these changed were applied until I went and
>> looked.
> 
> It is possible with fedmsg which we use. You can set notifications in special
> webservice[0] (although I find settings in it counter-intuitive). Simplest one
> is to set up notifications on all packages you maintain.

Sadly, commit notifications does NOT work for months
(works for old packages, not for newly imported one)


Remi

> 
> 
> [0] https://apps.fedoraproject.org/notifications
> ___
> 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: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 14:06 -0500, Rob Crittenden wrote:
> nicolas.mail...@laposte.net wrote:
> > Hi,
> > 
> > Thank you for cleaning up the cruft in the repository !
> > 
> > Regards,
> > 
> 
> Agreed. I'm usually pretty anal about others touching packages I
> maintain without at least a heads-up but in this case it doesn't bother
> me. I guess particularly since he didn't spin up a build or poke the
> n-v-r so reverting it if I really hated it or it broke something would
> be trivially easy.
> 
> As an aside, it might be nice though to be able to watch a package and
> get automated notifications when things change. I don't maintain that
> many packages though. I'd imagine that for some this could be rather
> onerous, but I had no idea these changed were applied until I went and
> looked.

It is possible with fedmsg which we use. You can set notifications in special
webservice[0] (although I find settings in it counter-intuitive). Simplest one
is to set up notifications on all packages you maintain.


[0] https://apps.fedoraproject.org/notifications
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqFLPsACgkQaVcUvRu8
X0wKAg/8CLwC1EubCyRYj5LCZfOToxMs3gU0uWQE81RYRRiFlgmMzs5Hw4H6K8XC
/Urix1yIGyPxBF79r/6sKoQsyhQpGDDZG6RmnYmilDWBC1JytjkN9UhnIc/lbyTP
+/gokc8+R1cPWEKXfHtW9dkJ6xvytcgEckr5Us/6psRxGL0WFbk6wv0UmSfMDDDA
hZY0blFfgRhmwOAIKe+1w6I4VMOBbwvAehZDvHIX0rhYd2UDfEvbK4SUzepd5tKk
7FWjdkufoFKYOIsAlnOuTQZ7WUXN6H4kGUaCY7q/ScXwsmew/mG9OWaDFf7fyKOf
eFo02xZpmSKHGgUMQiZigPp2tMpgTWmDwj95ykblf212hDGVLmEdz1+zL+OXNgBU
D1MxOE7wWSGtEHjCkEdyD6v+LWSfCKGBKe6prXZoXMh2U0VBfISFh6adqw209uuL
5U1IdylFLlr518adoPL0vm96sg/EF/96soeGjeqmJQ5cTHtLun1Kjv+jICEftJcI
rX0FX4YHjZTLJDlwQymcVxp2GcQI1OiM3lubgVE69lLI1pkjxazBNSvkUy5nKOWJ
SYhvUT3A+VXDEt1WGl7vjMHMjlOiHFbyDRoyOCByFR4M63wd4/APRq7rVcrKocJj
oL+VzX5Mw5aXeBRJaut/6qAh6S6nvX2cSysIthp7sYoIhyURhIQ=
=P48f
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] please review: Ticket 49566 - Improve ds-replcheck tool

[Mark Reynolds]

Add support for hidden conflict entries, add option to prompt for user
password, and improve man page

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

https://pagure.io/389-ds-base/issue/raw/files/1ea1fcfb8f8a04a3df3223136c13fbe5776c2ad4c008ad9f860900fdeed80103-0001-Ticket-49566-ds-replcheck-needs-to-work-with-hidden-.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

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



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

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

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

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

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

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

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

[J. Bruce Fields]

On Mon, Feb 05, 2018 at 06:06:29PM -0500, J. Bruce Fields wrote:
> Or this?:
> 
>   
> https://www.newegg.com/Product/Product.aspx?Item=N82E16820156153_re=ssd_power_loss_protection-_-20-156-153-_-Product

Ugh, Anandtech explains that their marketing is misleading, that drive
can't actually destage its volatile write cache on power loss:

https://www.anandtech.com/show/8528/micron-m600-128gb-256gb-1tb-ssd-revi
+ew-nda-placeholder

I've been trying to figure this out in part because I wondered what I
might use if I replaced my home server this year.  After some further
looking the cheapest PCIe-attached SSD with real power loss protection
that I've found is this Intel model a little over $300:


http://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/data-center-ssds/dc-p3520-series/dc-p3520-450gb-2-5inch-3d1.html

Kinda ridiculous to buy a 450 gig drive mainly so I can put a half-gig
journal on it.  It might turn out to be best for my case just to RAID a
couple of those SSDs and skip the conventional drives completely.

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

[Bug 1545467] New: perl-IPC-Cmd-1.00 is available

[bugzilla]

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

Bug ID: 1545467
   Summary: perl-IPC-Cmd-1.00 is available
   Product: Fedora
   Version: rawhide
 Component: perl-IPC-Cmd
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, st...@silug.org



Latest upstream release: 1.00
Current version/release in rawhide: 0.98-5.fc28
URL: http://search.cpan.org/dist/IPC-Cmd/

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

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

[389-devel] please review: Ticket 49568 - Fix integer overflow on 32bit platforms when calculating nsState information

[Mark Reynolds]

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

https://pagure.io/389-ds-base/issue/raw/files/bdc1e16ec6b026be823802df25197fd121be666398b3a4f3ede4f71bee280ba9-0001-Ticket-49568-Fix-integer-overflow-on-32bit-platforms.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Will Woods]

On Wed, Feb 14, 2018 at 4:14 PM, Matthew Miller
 wrote:
> I'd be super-interested in benchmarks comparing before and after
> install times. I guess since the plan is to do this _after_ the mass
> rebuild, we'll need to wait until after the *next* rebuild to see how
> much impact this has.

I don't think this single change will make a huge difference within
the existing ecosystem, but I think it's an important step in a larger
shift toward make package installation & image composition a)
introspectable and b) deterministic, so that we _can_ make
installs/composes faster and more reliable.

I talked about all the reasons eliminating/reducing scriptlets is a
good idea (and how we can actually do it) at Flock and at DevConf[1],
but since you're asking about speed specifically, I can say that with
the weldr[2] proof-of-concept tooling (which skips scriptlets) we can
build a system image in about 6 seconds[3], where the current tools
took 5+ minutes to build an image with the same contents[4].

So: before-and-after install times within Fedora probably won't change
much immediately, but these kinds of changes are important to enable
future work that will eventually give us dramatically faster and more
reliable tooling.

-w

[1] If you want to know more about the proposed Scriptlet Reforms you
could watch the recording from DevConf:
https://www.youtube.com/watch?v=kE-8ZRISFqA#t=2m33
(Or: just ask me to explain more and I'll be all too happy to talk about it!)
[2] http://weldr.io/
[3] I played a short recorded demo showing this during the talk,
10m52s in: https://www.youtube.com/watch?v=kE-8ZRISFqA#t=10m52
[4] To be fair, those numbers are from comparisons I ran by hand 6
months ago. But we'll start doing regular benchmarks after we've
finished a few missing bits and landed the code in Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Non-responsive maintainer: Lubomir Rintel (lkundrak)

[Sandro Mani]

Hi

Does anyone know how to contact Lubomir Rintel (lkundrak)? He is 
obviously still active since his last koji build is as recent as last 
Sunday the 11th, but he isn't answering to this ticket [1] and I also 
had no luck e-mailing him directly.


Thanks

Sandro

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1531289
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2018-02-16)

[Randy Barlow]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

Note that this is a change in time from the previous FESCo meeting time.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-02-16 15:00 UTC'


Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda


= Followups =

#topic #1767 F28 Self Contained Changes
.fesco 1767
https://pagure.io/fesco/issue/1767

#topic #1767 F28 Self Contained Changes: VA-API 1.0.0
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0

#topic #1767 F28 Self Contained Changes: Removing ldconfig scriptlets
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets

#topic #1767 F28 Self Contained Changes: Atomic, Cloud and Docker images
for s390x
https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s390x


= New business =

#topic #1820 Adjust/Drop/Document batched updates policy
.fesco 1820
https://pagure.io/fesco/issue/1820

#topic #1838 Nonresponsive maintainer: joost
.fesco 1838
https://pagure.io/fesco/issue/1838

#topic #1839 Nonresponsive maintainer: radford
.fesco 1839
https://pagure.io/fesco/issue/1839

#topic #1840 Better policy for mass cleanups / trivial changes for
provenpackagers
.fesco 1840
https://pagure.io/fesco/issue/1840

#topic #1842 Nonresponsive maintainer: devrim
.fesco 1842
https://pagure.io/fesco/issue/1842


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.



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: Release notes vs. Changelogs

[Björn Persson]

Matthew Miller wrote:
> 1. Put real changelog info in the git log and have a separate standard
>fedora-package-release-notes.md (uh, or better name, but I bet that
>one doesn't have any conflicts!) which lives in dist-git (but not in
>the package) and gets fed into bodhi and whatever other tooling

The changelog in the spec file could serve that purpose if we could get
rid of all the "rebuilt" entries. I would rather write the release notes
in the spec file than in a separate file. If the requirement for a new
changelog entry for every build could be dropped, then the RPM changelog
could become the release notes (although, if it would be called
"%release_notes" instead of "%changelog", then it might help packagers
understad what to write there).

A separate file doesn't in itself prevent merge conflicts, but dropping
the "rebuilt" entries would make merge conflicts rarer.

Of course, if upstream provides a file with suitable release notes,
then the spec should just refer to that, so that the packager doesn't
have to copy and paste them.

Regarding the issue that started this thread: Users aren't expected to
know about RPM macros, so presence of an RPM macro in the release notes
would indicate that the packager has misunderstood what release notes
should contain.

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

Re: clang -mcet -fcf-protection

[Richard W.M. Jones]

On Tue, Feb 13, 2018 at 02:27:02PM +0100, Florian Weimer wrote:
> On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote:
> >redhat-rpm-config flags have usually been compatible with both gcc and
> >clang, so if there's no newer clang that supports this, it feels like
> >we've a few options
> >
> >  1. Have the RPM spec for apps using clang filter these flags out of
> > the RPM cflags.
> >  2. Revert the change in redhat-rpm-config so we're compatible with
> > clang
> >  3. Provide a second macro in redhat-rpm-config that is the cut down
> > set of cflags which still work with clang, that apps can opt for.
> 
> You forgot:
> 
> 4. Compile the package with GCC (porting it if necessary).
> 
> GCC is the Fedora system compiler, after all.

This package legitimately uses clang to build a clang plugin.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: HEADS UP: yaml-cpp 0.6.0 coming to rawhide

[Richard Shaw]

On Sun, Feb 11, 2018 at 1:24 PM, Richard Shaw  wrote:

> mongodb-3.6.2-1.fc28.src.rpm
>

Looks like arch dependent failures for ppc64le and s390x. I don't know if
they are yaml-cpp related or not.

http://koji.fedoraproject.org/koji/buildinfo?buildID=1044717

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

Re: Removal of BuildRoot

[David Cantrell]

On 02/14/2018 02:41 PM, Igor Gnatenko wrote:
> On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
>> On 02/14/2018 11:44 AM, Remi Collet wrote:
>>> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
 Just a small heads up, ...
>>>
>>>
>>> As I said on IRC
>>>
>>> - waste of time
>>> - waste of energy
>>> - absolutely no value
>>>
>>> And
>>>
>>> - abuse proven packager privileges
> 
>> +1
> 
> Ralf, Remi, David,
> 
> Please, read policy[0] once more.
> 
>> Sometimes there are situations where it's simply a lot easier to fix stuff
> directly in Git than via bugzilla and the proper maintainers. So much easier
> that we should leave this path open. These situations shouldn't arise that
> often. Some examples of situations were bypassing the proper maintained is
> considered fine: 
>> […]
>> * small fixes or adjustments for new or modified packaging 
> guidelines can be done directly in Git after being announced some days 
> in advance.
> 
> I just missed waiting for few days (kinda intentionally), because it would not
> help anyone and will just disturb maintainers to do the actual work whereas it
> doesn't make any sense because cleanup is automated.
> 
> 
> [0] 
> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
> r.2C_general_or_cleanup_changes
> 

I am not disputing the policy.  I feel this change is pointless and is a
lot of commits for no real benefit.  They are not fixes.  You're just
scrubbing spec files that are not broken.  Who cares?  Update the
packaging policy and be done with it.  Leaving this tag there hurts nothing.

It's also worth noting that Pagure gives us pull requests for these sort
of changes.  While a proven packager can drive a monster truck through
the package repositories unchecked, the nice thing to do in the
community is to bring the issue to the attention of the package
maintainer and let them handle it.  Pagure lets you send pull requests
for this (you can even automate it) and then leave it with the package
maintainer to take or ignore on their own.

Just because we have removed something like the BuildRoot tag from the
packaging policy does not automatically invalidate every existing spec file.

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

[Matthew Miller]

On Wed, Feb 14, 2018 at 09:59:27PM +0100, Igor Gnatenko wrote:
> The whole purpose of this is to make installation of packages FASTER and
> obviously to comply with guidelines. Most of packages would be possible to
> automate, however some would not and you would need to deal with it youself.

I'd be super-interested in benchmarks comparing before and after
install times. I guess since the plan is to do this _after_ the mass
rebuild, we'll need to wait until after the *next* rebuild to see how
much impact this has.


-- 
Matthew Miller

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

Re: Removal of BuildRoot

[Orion Poplawski]

On 02/13/2018 03:05 PM, Igor Gnatenko wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is oldest
supported one nowadays, it's been year or so after EL5 retirement). And we
don't support EL5 anymore, so...

I wanted to send this heads up before I actually did that, but I hit "enter"
button too early.

Anyway, this is straitghtforward change, so no one should notice anything
(apart from one commit with, hopefully, useful description in their
repositories) 


Thanks for your work cleaning up spec files.


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

Re: Call for users of darkserver

[Jason Callaway]

I was unaware of it, but I think it looks pretty great!

OOC, is there an alternative service that one could use if this is
decommissioned? Or would we have to dig through Koji and Bodhi logs?

I'll bet the CHAOSS folks [0] would like it, if that helps. Dunno if
they're aware of it, though. I'll introduce them to it if there's no
objection.

[0] - https://chaoss.community/


On Wed, Feb 14, 2018 at 5:02 AM, Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> The week before DevConf, a number of the members of the Fedora
> Infrastructure
> met in Brno to discuss states and plans for the infrastructure.
> One of the question that raised was about darkserver.
>
> This application is available at: https://darkserver.fedoraproject.org/
> and is meant to:
>
> enable developer tools to identify exact package builds from which process
> images (e.g. core dumps) come. This can enable their analysis, debugging
> profiling, by finding out where the rpm / elf / dwarf files may be found,
> so
> they can download them. (This is even better than
> abrt-action-install-debuginfo-to-abrt-cache because that apparently
> cannot query
> files no longer indexed by repodata.)
>
> Source: https://fedoraproject.org/wiki/Darkserver
>
>
> However, it seems this application has not been working for a long time
> now and
> not many people asked about it.
>
> So, is anyone using this service?
>
> If there is little interest for this project, we will likely decommission
> it in
> the coming weeks (say end of March).
>
>
> Thanks for your attention and your feedback,
>
> Pierre
> For the Fedora Infrastructure team
>
>
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.
> fedoraproject.org
>
>


-- 
Jason Callaway | jcalla...@redhat.com | (240) 285-9529 | GPG Key 0x81ED4A9A
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 14:25 -0500, David Cantrell wrote:
> On 02/14/2018 11:44 AM, Remi Collet wrote:
> > Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> > > Just a small heads up, ...
> > 
> > 
> > As I said on IRC
> > 
> > - waste of time
> > - waste of energy
> > - absolutely no value
> > 
> > And
> > 
> > - abuse proven packager privileges
> 
> +1

Ralf, Remi, David,

Please, read policy[0] once more.

> Sometimes there are situations where it's simply a lot easier to fix stuff
directly in Git than via bugzilla and the proper maintainers. So much easier
that we should leave this path open. These situations shouldn't arise that
often. Some examples of situations were bypassing the proper maintained is
considered fine: 
> […]
> * small fixes or adjustments for new or modified packaging 
guidelines can be done directly in Git after being announced some days 
in advance.

I just missed waiting for few days (kinda intentionally), because it would not
help anyone and will just disturb maintainers to do the actual work whereas it
doesn't make any sense because cleanup is automated.


[0] https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Mino
r.2C_general_or_cleanup_changes
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEkNsACgkQaVcUvRu8
X0ynChAAi6ysL7vNKx/iOlXR8QwgeYPrGUls1wDcf+Pfk5TG5KnCHPD2Z1Ze5hOV
4m1LQXjG0uljIzRX0WjRQijCFgUgk8l5EEdy/bUNIocdPU4eUrTOkGW1ZUbs5XB7
5qkmllsn8EaYWf3FN1WeN198qh1cepCJkhyldTz/nzWWJQ3Shx1XjGboBPzHeDFP
NaAuOV7brE5S3yoXmRNbk1SVchqlt16KzLDkWZ0F0yvGlc2yThjeib8WRA8oKB4b
XqNnZGPHGbSvlRI/AbJGcn4G2/Fqiu9RG+0j223zAOXIU3xNrdgW/Rac2q27+TZt
sZLC7M3fq+lmGdZTU056v+DW3r7YaIuhxwVt+FotzxR5ax4SIN42nc9ufH35eq2M
9wNdGmT4ZzB2KZ+RJHWeIDn5VL3fxx2zZyboKCYlYXjhY5qm6KAL+pKN9QGiU6It
dVtm+GoosiN574tZU6chzeIAL2ysehK0xAo8xBuXRF/Jn7ERjpFAUj9dJxVMvRdF
f5Rdn2le88YQBNOoLAJSBJlCe5ONGYqSbUKySMZFcKkS/B4vk13H5tswKhOUDjtM
2N3fBwNEl+he+4SB1KEKEV70w5/Jdcze0UUlvnQRS8IDb7Mf4GrqqFkGC4D7CqWr
OESCudSLz0mrtIZ9YBd6bJJt924AhaUQnyPTZFsVb3SnZ+quxVM=
=hbS8
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Chuck Anderson]

On Tue, Feb 13, 2018 at 11:05:28PM +0100, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is 
> oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
> 
> I wanted to send this heads up before I actually did that, but I hit "enter"
> button too early.
> 
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 
> -- 
> -Igor Gnatenko

FWIW, I support your efforts with this, so thank you.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[David Cantrell]

On 02/14/2018 11:44 AM, Remi Collet wrote:
> Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
>> Just a small heads up, ...
> 
> 
> As I said on IRC
> 
> - waste of time
> - waste of energy
> - absolutely no value
> 
> And
> 
> - abuse proven packager privileges

+1

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clang -mcet -fcf-protection

[Richard W.M. Jones]

On Wed, Feb 14, 2018 at 11:03:28AM -0800, Tom Stellard wrote:
> On 02/13/2018 02:18 AM, Richard W.M. Jones wrote:
> > 
> > My build of american-fuzzy-lop fails because clang doesn't
> > understand the ‘-mcet -fcf-protection’ flags which seem to be
> > added by RPM.
> > 
> 
> Is there a particular reason this packages uses clang and not gcc?

It uses both.  In this case it uses clang because it has to build a
clang extension (as well as a gcc extension).

Rich.

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

Re: Removal of BuildRoot

[Rob Crittenden]

nicolas.mail...@laposte.net wrote:
> Hi,
> 
> Thank you for cleaning up the cruft in the repository !
> 
> Regards,
> 

Agreed. I'm usually pretty anal about others touching packages I
maintain without at least a heads-up but in this case it doesn't bother
me. I guess particularly since he didn't spin up a build or poke the
n-v-r so reverting it if I really hated it or it broke something would
be trivially easy.

As an aside, it might be nice though to be able to watch a package and
get automated notifications when things change. I don't maintain that
many packages though. I'd imagine that for some this could be rather
onerous, but I had no idea these changed were applied until I went and
looked.

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

Re: clang -mcet -fcf-protection

[Tom Stellard]

On 02/13/2018 02:18 AM, Richard W.M. Jones wrote:
> 
> My build of american-fuzzy-lop fails because clang doesn't
> understand the ‘-mcet -fcf-protection’ flags which seem to be
> added by RPM.
> 

Is there a particular reason this packages uses clang and not gcc?

-Tom

>   clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
> -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\" 
> -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\"  afl-clang-fast.c -o 
> ../afl-clang-fast 
>   clang-6.0: error: unknown argument: '-mcet'
>   clang-6.0: error: unknown argument: '-fcf-protection'
> 
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571)
> 
> This suggests a bug in our RPM configuration.
> 
> Rich.
> 
___
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
 946  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 836  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 807  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 418  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 147  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  66  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6
  33  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-752a7c9ad4   
rootsh-1.5.3-17.el6
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-369a48191f   
clamav-0.99.3-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fc6e2820ab   
tomcat-7.0.84-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bc1949f307   
p7zip-16.02-10.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f742513635   
jhead-3.00-9.el6


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

is-interface-1.15.0-1.el6
python-regex-2018.02.08-1.el6
rho-0.0.32-1.el6

Details about builds:



 is-interface-1.15.0-1.el6 (FEDORA-EPEL-2018-91a43d9dc7)
 Information service library for the lcg bdii system

Update Information:

Fix requires for -devel package

References:

  [ 1 ] Bug #1545190 - is-interface is using arch-dependent BuildRequires
https://bugzilla.redhat.com/show_bug.cgi?id=1545190




 python-regex-2018.02.08-1.el6 (FEDORA-EPEL-2018-a832561459)
 Alternative regular expression module, to replace re

Update Information:

Update to the latest released version.    Update to the latest released
version.




 rho-0.0.32-1.el6 (FEDORA-EPEL-2018-c93f12eaa7)
 An SSH system profiler

Update Information:

# Testing Rho  To set up Rho, you create profiles that control how to run each
scan. - Authentication profiles contain user credentials for a user with
sufficient authority to complete the scan (for example, a root user or one with
root-level access obtained through -sudo privilege escalation). - Network
profiles contain network identifiers (for example, a hostname, IP address, or
range of IP addresses) and the authentication profiles to be used for a scan.
Complete the following steps, repeating them as necessary to access all parts of
your environment that you want to scan: 1. Create at least one authentication
profile with root-level access to Rho: ``` rho auth add --name auth_name
--username root_name(--sshkeyfile key_file | --password) ```  a. At the Rho
vault password prompt, create a new Rho vault password. This password is
required to access the encrypted Rho data, such as authentication and network
profiles, scan data, and other information.  b. If you did not use the
sshkeyfile option to provide an SSH key for the username value, enter the
password of the user with root-level access at the connection password prompt.
For example, for an authentication profile where the authentication profile name
is roothost1, the user with root-level access is root, and the SSH key for the
user is in the path ~/.ssh/id_rsa, you would enter the following command: ```
rho auth add --name roothost1 --username root --sshkeyfile ~/.ssh/id_rsa ``` You
can also use the sudo-password option to create an authentication profile for a
user with root-level access who requires a password to obtain this privilege.
You can use the sudo-password option with either the sshkeyfile or the password
option. For example, for an authentication profile where the authentication
profile name is sudouser1, the user with root-level access is sysadmin, and the
access is obtained through the password option, you would enter the following
command: ``` rho auth add --name sudouser1 --username sysadmin --password
--sudo-password ```  After you enter this command, you are prompted to enter two
passwords. First, you would 

[Bug 1544065] perl-Net-DNS-1.15 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Net-DNS-1.15-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-2697615f0c

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

Re: Removal of BuildRoot

[Kevin Fenzi]

On 02/13/2018 02:05 PM, Igor Gnatenko wrote:
> Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is 
> oldest
> supported one nowadays, it's been year or so after EL5 retirement). And we
> don't support EL5 anymore, so...
> 
> I wanted to send this heads up before I actually did that, but I hit "enter"
> button too early.
> 
> Anyway, this is straitghtforward change, so no one should notice anything
> (apart from one commit with, hopefully, useful description in their
> repositories) 

Thanks for making these simple cleanup changes.

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 1544065] perl-Net-DNS-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Net-DNS-1.15-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-344ecfd015

-- 
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
 1073  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 836  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 418  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 315  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 147  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  84  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
  34  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-73ee944e65   
rootsh-1.5.3-17.el7
  20  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df   
knot-resolver-1.5.3-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-18ea640f19   
tomcat-native-1.2.16-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f09712d924   
pdns-3.4.11-4.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7134fc92a1   
jhead-3.00-7.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-069884a87f   
p7zip-16.02-10.el7


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

bluez-tools-0.2.0-0.7.git20170912.7cb788c.el7
exim-4.90.1-1.el7
perl-Net-SSH-0.09-26.el7
perl-Term-ReadPassword-0.11-27.el7
pwkickstart-1.0.2-1.el7
python-execnet-1.2.0-5.el7
python-pytest-xdist-1.17.1-2.el7
python-regex-2018.02.08-1.el7
rho-0.0.32-1.el7
standard-test-roles-2.8-1.el7

Details about builds:



 bluez-tools-0.2.0-0.7.git20170912.7cb788c.el7 (FEDORA-EPEL-2018-36e3e1fcc2)
 A set of tools to manage Bluetooth devices for Linux

Update Information:

- New snapshot




 exim-4.90.1-1.el7 (FEDORA-EPEL-2018-097b4381c7)
 The exim mail transfer agent

Update Information:

This is new version fixing CVE-2018-6789.

References:

  [ 1 ] Bug #1543268 - CVE-2018-6789 exim: Buffer overflow in utility function, 
when pre-conditions are met, can lead to remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1543268




 perl-Net-SSH-0.09-26.el7 (FEDORA-EPEL-2018-e3d95da142)
 Perl extension for secure shell

Update Information:

Add new package to EPEL 7




 perl-Term-ReadPassword-0.11-27.el7 (FEDORA-EPEL-2018-de208fcb1d)
 Asking the user for a password

Update Information:

Add new package to EPEL 7




 pwkickstart-1.0.2-1.el7 (FEDORA-EPEL-2018-0b09e66084)
 Helps to generate kickstart passwords

Update Information:

Initial version

References:

  [ 1 ] Bug #1543813 - Review Request: pwkickstart - generate kickstart 
passwords
https://bugzilla.redhat.com/show_bug.cgi?id=1543813




 python-execnet-1.2.0-5.el7 (FEDORA-EPEL-2018-5d7309bdb9)
 Elastic Python Deployment

Update Information:

Enable python3 build on EPEL7.




 python-pytest-xdist-1.17.1-2.el7 (FEDORA-EPEL-2018-59c93d3504)
 py.test plugin for distributed testing and loop-on-failing modes

Update Information:

Build for EPEL7 (#1542647)

[Bug 1542771] perl-Sub-Quote-2.005000 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Sub-Quote-2.005000-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 1540220] perl-Gearman-Client-Async-0.94-28.fc28 FTBFS: Timeout, test fails at t/allinone.t line 62.

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Gearman-2.004.0013-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 1542279] perl-Gearman-2.004.0013 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Gearman-2.004.0013-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 1541736] perl-bignum-0.49 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-bignum-0.49-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 1541186] perl-bignum-0.48 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-bignum-0.49-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 1541190] perl-Bot-BasicBot-0.92 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Bot-BasicBot-0.92-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 1392479] perl-Alien-ROOT not available on ppc64le because root is not there

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-10.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 1392475] perl-Alien-ROOT not available on ppc64 because root is not there

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-10.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: New "tests" namespace to share test code

[Adam Williamson]

On Wed, 2018-02-14 at 17:28 +0100, Petr Šplíchal wrote:
> Hi!
> 
> During the last days there have been concerns raised regarding
> what is an appropriate content for the tests namespace. [1] My
> original idea was to enable sharing tests even across branches of
> the same component, not only for tests to be used by completely
> different packages. The initial examples might have been a bit
> misleading in this respect. One of the main points still holds:
> 
> >  * Tests might follow a different branching pattern than the
> >dist-git repo, leading to code duplication
> 
> From the feedback from developers I feel they always keep on mind
> and care a lot about the maintenance costs. So it perfectly makes
> sense to me if they want to keep and maintain tests in a separate
> repo instead of merging/cherry-picking between dist-git branches.
> 
> When, for a particular package, it is the most efficient way to
> maintain tests in a separate repo why should we discourage from
> this approach? There are packages where it makes more sense to
> store test code directly in dist-git. And it is still an option.
> But why should we enforce this for all?
> 
> Please share your thoughts and real-life examples. For those who
> are not familiar with the topic there is a new wiki page with a
> summary of the Share Test Code approach [2].

I don't have any problem with the concept *in itself*; in fact I know
of another reason to have something like it. That is 'generic' tests,
tests we want to run on all packages, or at least a very large set of
packages - like the tests currently running in Taskotron, which are
generally run on all packages (rpmgrill, rpmdeplint...) or a large
subset (the Python tests).

What I did think was maybe a concern is that we should figure out in
advance the squishy human consequences of different technical
approaches.

Basically this boiled down to "who is responsible for these 'shared'
tests, and who gets to decide which 'shared' tests can/should block
packages?"

Looking at the proposal, I think it actually has at least workable
initial explicit/implicit answers to this, if I'm reading it correctly.
Anyone can create a shared test repository (and is therefore
"responsible" for maintaining it), but the definition of which tests
are run on which packages remains in the package repositories. Thus the
package maintainer(s) retain the ultimate choice over which tests are
run against their packages (and thus can pick which shared tests are
run, and disable shared tests if they are no longer properly testing
their package).

The question 'who decides which tests block which packages' is left a
bit up in the air, but in fact no more so than it already was for
package-specific tests...
-- 
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: Call for users of darkserver

[Jan Kratochvil]

On Wed, 14 Feb 2018 11:02:52 +0100, Pierre-Yves Chibon wrote:
> If there is little interest for this project, we will likely decommission it 
> in
> the coming weeks (say end of March).

The darkserver project ws initiated AFAIK by me as there is always a problem
how to reproduce an ABRT bugreport.

The darkserver usability problems were related to each other,
a chicken-and-egg problem:
 * It never really started working.  When I tried to use it once upon few
   months when I found time to process some ABRT bugreports which were not
   obvious enough darkserver failed and after contacting Kushal Das
   (darkserver author) he found some new software or data bug why it did not
   work that time.
 * There was never a tool making it convenient enough to reconstruct the
   tree of files based on their build-ids.
 * There was never enough users (was there any besides me?) that started using
   darkserver, because of the two problems above.

So I believe darkserver would be great but not in its current state of
functionality.

Also I believe ABRT project already contains most of the infrastructure and
code required, I believe darkserver could be rather just few lines of code
added to the ABRT project - that is to interactively run the crashed program
with all matching versions of libraries - not just getting the non-interative
core file backtrace (which ABRT submits to Bugzilla).


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

[Bug 1541186] perl-bignum-0.48 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
perl-bignum-0.49-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 1541736] perl-bignum-0.49 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-bignum-0.49-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 1541190] perl-Bot-BasicBot-0.92 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Bot-BasicBot-0.92-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 1392479] perl-Alien-ROOT not available on ppc64le because root is not there

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-7.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 1392475] perl-Alien-ROOT not available on ppc64 because root is not there

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Alien-ROOT-5.34.36.1-7.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

Re: Removal of BuildRoot

[nicolas . mailhot]

Hi,

Thank you for cleaning up the cruft in the repository !

Regards,

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

Re: Call for users of darkserver

[Jan Kratochvil]

On Wed, 14 Feb 2018 15:55:20 +0100, Pierre-Yves Chibon wrote:
> darkserver itself doesn't store anything.

Darkserver was at least in the past using debuginfo storage from ABRT server
which is much more rich than what Koji server keeps.


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

Re: Removal of BuildRoot

[Ralf Corsepius]

IMO, bikesheding and stylishness with any actual usefulness.

If you really want to enforce this, make it a feature request for f30 
and have FESCO vote on it.


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

Re: HEADS UP: yaml-cpp 0.6.0 coming to rawhide

[Richard Shaw]

On Sun, Feb 11, 2018 at 1:24 PM, Richard Shaw  wrote:

> I may wait a few days for all the build problems with gcc 8 and there are
> still several packages that haven't been properly rebuilt against boost
> 1.66, but I plan to build yaml-cpp 0.6.0 and rebuild its dependencies in
> the near future:
>
> $ repoquery --repoid=rawhide --source --whatrequires
> "libyaml-cpp.so.0.5()(64bit)"
> Last metadata expiration check: 0:01:30 ago on Sun 11 Feb 2018 01:21:13 PM
> CST.
> OpenColorIO-1.1.0-1.fc28.src.rpm
>

Circular dependency problem with OpenImageIO and yaml-cpp, my package so
I'm fixing.



> calamares-3.1.8-6.fc28.src.rpm
>

DEBUG util.py:439:  Error:
DEBUG util.py:439:   Problem: package
qt5-qtwebengine-devel-5.10.0-3.fc28.x86_64 requires
libQt5WebEngineCore.so.5()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides
libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit) needed by
qt5-qtwebengine-5.10.0-3.fc28.x86_64



> facter-3.9.3-1.fc28.src.rpm
>

DEBUG util.py:439:  Error:
DEBUG util.py:439:   Problem: package cpp-hocon-devel-0.1.6-3.fc28.x86_64
requires libcpp-hocon.so.0.1.6()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by cpp-hocon-0.1.6-3.fc28.x86_64


fawkes-1.0.1-13.fc28.src.rpm
>

DEBUG util.py:439:  Error:
DEBUG util.py:439:   Problem 1: package player-devel-3.1.0-4.fc27.x86_64
requires libplayercommon.so.3.1()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by player-3.1.0-4.fc27.x86_64
DEBUG util.py:439:   Problem 2: package pcl-devel-1.8.0-13.fc28.x86_64
requires libpcl_common.so.1.8()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by pcl-1.8.0-13.fc28.x86_64
DEBUG util.py:439:   Problem 3: package
gazebo-ode-devel-8.1.1-4.fc28.x86_64 requires libgazebo_ode.so.8()(64bit),
but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by gazebo-ode-8.1.1-4.fc28.x86_64
DEBUG util.py:439:   Problem 4: package gazebo-devel-8.1.1-4.fc28.x86_64
requires libgazebo_ode.so.8()(64bit), but none of the providers can be
installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by gazebo-ode-8.1.1-4.fc28.x86_64
DEBUG util.py:439:   Problem 5: package gazebo-media-8.1.1-4.fc28.noarch
requires gazebo = 8.1.1-4.fc28, but none of the providers can be installed
DEBUG util.py:439:- conflicting requests
DEBUG util.py:439:- nothing provides libboost_system.so.1.64.0()(64bit)
needed by gazebo-8.1.1-4.fc28.x86_64


librime-1.2-19.fc28.src.rpm
>

Done.



> mongodb-3.6.2-1.fc28.src.rpm
>

Takes forever to build. Will follow up.



> pdns-4.1.0-2.fc28.src.rpm
>

Never seen this one before:
/bin/sh ../../libtool  --tag=CXX   --mode=link g++  -fPIE -DPIE
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 --param ssp-buffer-size=4
-fstack-protector -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection
-module -avoid-version -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z,relro
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libgeoipbackend.la -rpath
/usr/lib64/pdns geoipbackend.lo -Llib64 -lyaml-cpp  -lGeoIP
make[3]: Leaving directory
'/builddir/build/BUILD/pdns-4.1.0/modules/geoipbackend'
../../libtool: line 6000: cd: lib64: No such file or directory
libtool: link: cannot determine absolute directory name of `lib64'


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

Re: RANT: Packaging is changing too fast and is not well documented

[Paul W. Frields]

On Mon, Feb 12, 2018 at 10:37:38AM -0800, Kevin Fenzi wrote:
> On 02/12/2018 10:14 AM, Ken Dreyer wrote:
> > On Sat, Feb 10, 2018 at 6:48 AM, Richard Shaw  wrote:
> >> Not coming from a programming background I found the learning curve pretty
> >> steep when I first tried to become a packager, I'm not sure I wouldn't have
> >> given up if I had to do it now.
> > 
> > Thanks for speaking up about this. I'm having trouble following along
> > with the latest changes too.
> > 
> > Pagure brings a ton of benefits to dist-git management, so I don't
> > diss Pagure and all the hard work folks have put into making that a
> > reality. I just miss the easy birds-eye-view that the pkgdb web UI
> > provided.
> 
> I agree things are rough around the edges. Thats why I proposed the
> number one deliverable from our upcoming Infrastructure Hackfest (
> https://fedoraproject.org/wiki/Infrastructure_Hackathon_2018 ) be
> cleaning up all our documentation and improving any workflows and
> scripts we can.
> 
> I hope we can fix some of these issues there...

Along those lines, I would suggest collecting from this group the
common workflows (if needed), document them on the wiki and advertise
here for review.  Then we could use that as a punch list to guide that
work at the hackathon.

If someone wants to start the list of workflows, you can use this wiki
section:

https://fedoraproject.org/w/index.php?title=Infrastructure_Hackathon_2018=edit=5

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New "tests" namespace to share test code

[Honza Horak]

On 02/14/2018 05:28 PM, Petr Šplíchal wrote:

Hi!

During the last days there have been concerns raised regarding
what is an appropriate content for the tests namespace. [1] My
original idea was to enable sharing tests even across branches of
the same component, not only for tests to be used by completely
different packages. The initial examples might have been a bit
misleading in this respect. One of the main points still holds:


  * Tests might follow a different branching pattern than the
dist-git repo, leading to code duplication


 From the feedback from developers I feel they always keep on mind
and care a lot about the maintenance costs. So it perfectly makes
sense to me if they want to keep and maintain tests in a separate
repo instead of merging/cherry-picking between dist-git branches.


+1

From my PoV, it makes perfect sense to share tests between branches, or 
between different versions of packages available in modules streams (soon).


Honza


When, for a particular package, it is the most efficient way to
maintain tests in a separate repo why should we discourage from
this approach? There are packages where it makes more sense to
store test code directly in dist-git. And it is still an option.
But why should we enforce this for all?

Please share your thoughts and real-life examples. For those who
are not familiar with the topic there is a new wiki page with a
summary of the Share Test Code approach [2].

psss...

[1] https://pagure.io/fedora-infrastructure/issue/6695
[2] https://fedoraproject.org/wiki/CI/Share_Test_Code

On 7 December 2017 at 10:38, Petr Splichal  wrote:

Hi!

While working on adding CI tests [0] using the Standard Test
Interface a need arose to have a shared git repository where tests
could be stored:

  * A large number of test files makes a dist-git repository more
difficult to maintain

  * Tests might follow a different branching pattern than the
dist-git repo, leading to code duplication

  * Shared maintenance for tests sometimes benefits from different
access levels than the release dist-git repository

The plan is to create a new “tests” namespace in Fedora git/pagure
dedicated to storing the shared test code. To enable execution of
these tests by the CI pipeline, tests.yml file in dist-git will be
used to link the tests in the standard way as defined by the
Standard Test Interface [1].

This approach should help to efficiently maintain tests & minimize
test code duplication. Using a dedicated git repo for test code
also means to keep dist-git more as a place for storing metadata
only: Build metadata (spec file = how to build the package) and
test metadata (tests.yml = how to test the package) rather than
mixing spec files with test code itself.

Please note that this does not mean that all tests should now go
into this new namespace. You can still link tests directly from
upstream (like GitHub) or any other source. Also, for unit tests
it makes more sense to be kept directly with the project source
and executed there. Shared tests namespace in Fedora will be
suitable especially for functional and integration testing which
should help to continuously ensure the OS works as a whole.

For more detailed motivation and real-life examples see the Share
Test Code proposal on the Fedora CI list [2]. If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:

https://pagure.io/fedora-infrastructure/issue/6478

Thanks.

psss...

[0] https://fedoraproject.org/wiki/CI
[1] https://fedoraproject.org/wiki/Changes/InvokingTests
[2] 
https://lists.fedoraproject.org/archives/list/c...@lists.fedoraproject.org/thread/55U6V6UHA54MJLD2F6JF46EOLMVRUAE7/

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

Re: Removal of BuildRoot

[Remi Collet]

Le 13/02/2018 à 23:05, Igor Gnatenko a écrit :
> Just a small heads up, ...


As I said on IRC

- waste of time
- waste of energy
- absolutely no value

And

- abuse proven packager privileges


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

[Guidelines change] Changes to the packaging guidelines

[Jason L Tibbitts III]

Just this one change, but it has implications for many packages.

The Scriptlet guidelines have received several changes regarding the
installation of shared libraries and ldconfig.  Use of the new macros
is detailed, and there is a new section on the scriptlets required when
linker configuration files are installed.

* https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
* https://fedoraproject.org/wiki/Packaging:Scriptlets#Shared_Libraries
* https://pagure.io/packaging-committee/issue/654

Please note the following before attempting to use the new macros
outside of rawhide builds:

1) The updates for F27 (redhat-rpm-config-70.1.fc27) and F26
   (redhat-rpm-cponfig-64.1.fc26) which provide the new macros are
   currently on their way to stable and will hopefully be generally
   available in a day or so.

2) The epel-rpm-macros updates for EPEL7 and EPEL6, which provide the
   new macros for those EPEL releases, are in the testing repositories
   and need more karma before they can be pushed to stable:
   * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c5ae067f71
   * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-580a31cb75
   
___
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

[Guidelines change] Changes to the packaging guidelines

[Jason L Tibbitts III]

Just this one change, but it has implications for many packages.

The Scriptlet guidelines have received several changes regarding the
installation of shared libraries and ldconfig.  Use of the new macros
is detailed, and there is a new section on the scriptlets required when
linker configuration files are installed.

* https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
* https://fedoraproject.org/wiki/Packaging:Scriptlets#Shared_Libraries
* https://pagure.io/packaging-committee/issue/654

Please note the following before attempting to use the new macros
outside of rawhide builds:

1) The updates for F27 (redhat-rpm-config-70.1.fc27) and F26
   (redhat-rpm-cponfig-64.1.fc26) which provide the new macros are
   currently on their way to stable and will hopefully be generally
   available in a day or so.

2) The epel-rpm-macros updates for EPEL7 and EPEL6, which provide the
   new macros for those EPEL releases, are in the testing repositories
   and need more karma before they can be pushed to stable:
   * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c5ae067f71
   * https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-580a31cb75
   
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

[HEADS UP] Package wireshark-gtk going away

[Michal Ruprich]

Hi,

the wireshark-gtk is no longer supported by the upstream since
wireshark-2.4.0. You may have noticed that there is new GUI based on Qt
since wireshark-2.0. This GUI will become default and the GTK-based GUI
will be dropped and no longer provided. This change should appear in
Fedora 29.

-- 
Michal Ruprich
Associate Software Engineer

Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[Bug 1456817] Use of uninitialized value $fh in pattern match (m//) at / usr/share/perl5/vendor_perl/Proc/PID/File.pm line 286.

[bugzilla]

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

Edgar Hoch  changed:

   What|Removed |Added

Version|26  |27



--- Comment #3 from Edgar Hoch  ---
The error still occurs on Fedora 27.

perl-Proc-PID-File-1.28-4.fc27.noarch

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

[389-devel] Please review: Add a test suite for ds-replcheck tool RFE

[Simon Pichugin]

Hi team,
please, review a draft of RFE tests

https://pagure.io/389-ds-base/pull-request/49567
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 16:17 +, Michael J Gruber wrote:
> No, that commit description was not helpful as it did not explain why you see
> a need to exert your proven packager privileges, nor the fact that this is a
> mass change. I had to go around and look for you and some info about your
> commit.

You see, I assume that you you are average packager and you don't know that
BuildRoot definition was needed last in EL5, do you expect other average
maintainers to know this?

> Frankly, I hate it when I notice that someone is stepping on my toes in
> packages that I maintain without even trying to contact me. We have pull-
> requests for exactly that purpose now - communication right where it belongs,
> open and transparent.

Do you think it's reasonable to ask person to open 2.000+ Pull Requests and
track all of them which just remove one single line?

> As for the change itself - those legacy spec features are neither necessary
> nor harmful. No need for urgent action at all.

It's fine as long as people actually remove them. But the reality is different
- - no one is removing old cruft from spec files which is accumulating there for
ages (try to grep specs for `0%{?rhel} < 4`.

They are actually harmful in a sense that when new people come they look at
existing spec files and copy them over and over.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEZY8ACgkQaVcUvRu8
X0zNLA//WG9vGnJ45cKes3zT2fU1XIqb+ULgBF7gsCaFXIZyOYEySLtKgQayz812
N9fLQyU96U9HwGTNy4fm3Kg/wIbxuQnAAs6iMHqFJGM1xRpKwhcnAK4T41OVJ8j3
ukOC4RfiovU9ypGBQkBLvfHTZl3nA9ZjscSmGKSynY9tbWn1XKmXlK1ALdr/7HsL
EYjlhRq9j4dUih9UgNtm1JEv0nb6P8UEXzKtQk9GAt3bAL0e4Faok/Nc3dqBHgQu
3nCOpJ17awqAA92xOolW3nuCIngqtDERuOHeyqg9t5pAgMNGAmXCOf1pbT+RHYqT
MZHUd8kT25l5yDuvidaqEX+gST6SfK2ZBmzlEWjw5lMYJuCh1E05aeODQmtMnrRt
uHWMr7Zqv5hvkGMtFNbt+G0B1KujLAWqrNTR3zIhPKTpFJEAczacHEsfgaOxMQaC
cA86Nsh/HGBILKX4lcD5ByYMoKBpy4o19hKV89qqCOXDiBr8PpVhdVIUxSGEQsHZ
lID6+fXefu9nwv8kAD0IQf/D+PbnmstwlzG2VDb45/lpf284HJsVA/oCy9tRnitN
Mk8E2l1NDvGpmbvMVAVPA1T1zxEZjdZ1zUBFgOSvghuSRs5uV/Fy9KKw0ALMK/yd
P3kMb9QdTl1c6/XDFg/3WqdIpSnhZnMUaUKDEoq1Id8WxDISBQE=
=gZN6
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Adding devtoolset to EPEL

[Peter Robinson]

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

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

Re: New "tests" namespace to share test code

[Petr Šplíchal]

Hi!

During the last days there have been concerns raised regarding
what is an appropriate content for the tests namespace. [1] My
original idea was to enable sharing tests even across branches of
the same component, not only for tests to be used by completely
different packages. The initial examples might have been a bit
misleading in this respect. One of the main points still holds:

>  * Tests might follow a different branching pattern than the
>dist-git repo, leading to code duplication

From the feedback from developers I feel they always keep on mind
and care a lot about the maintenance costs. So it perfectly makes
sense to me if they want to keep and maintain tests in a separate
repo instead of merging/cherry-picking between dist-git branches.

When, for a particular package, it is the most efficient way to
maintain tests in a separate repo why should we discourage from
this approach? There are packages where it makes more sense to
store test code directly in dist-git. And it is still an option.
But why should we enforce this for all?

Please share your thoughts and real-life examples. For those who
are not familiar with the topic there is a new wiki page with a
summary of the Share Test Code approach [2].

psss...

[1] https://pagure.io/fedora-infrastructure/issue/6695
[2] https://fedoraproject.org/wiki/CI/Share_Test_Code

On 7 December 2017 at 10:38, Petr Splichal  wrote:
> Hi!
>
> While working on adding CI tests [0] using the Standard Test
> Interface a need arose to have a shared git repository where tests
> could be stored:
>
>  * A large number of test files makes a dist-git repository more
>difficult to maintain
>
>  * Tests might follow a different branching pattern than the
>dist-git repo, leading to code duplication
>
>  * Shared maintenance for tests sometimes benefits from different
>access levels than the release dist-git repository
>
> The plan is to create a new “tests” namespace in Fedora git/pagure
> dedicated to storing the shared test code. To enable execution of
> these tests by the CI pipeline, tests.yml file in dist-git will be
> used to link the tests in the standard way as defined by the
> Standard Test Interface [1].
>
> This approach should help to efficiently maintain tests & minimize
> test code duplication. Using a dedicated git repo for test code
> also means to keep dist-git more as a place for storing metadata
> only: Build metadata (spec file = how to build the package) and
> test metadata (tests.yml = how to test the package) rather than
> mixing spec files with test code itself.
>
> Please note that this does not mean that all tests should now go
> into this new namespace. You can still link tests directly from
> upstream (like GitHub) or any other source. Also, for unit tests
> it makes more sense to be kept directly with the project source
> and executed there. Shared tests namespace in Fedora will be
> suitable especially for functional and integration testing which
> should help to continuously ensure the OS works as a whole.
>
> For more detailed motivation and real-life examples see the Share
> Test Code proposal on the Fedora CI list [2]. If you have any
> questions or comments feel free to share them here or in the
> pagure issue requesting the new namespace:
>
> https://pagure.io/fedora-infrastructure/issue/6478
>
> Thanks.
>
> psss...
>
> [0] https://fedoraproject.org/wiki/CI
> [1] https://fedoraproject.org/wiki/Changes/InvokingTests
> [2] 
> https://lists.fedoraproject.org/archives/list/c...@lists.fedoraproject.org/thread/55U6V6UHA54MJLD2F6JF46EOLMVRUAE7/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1545307] License tag does not match Text-Template-1.47 content

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-02-14 11:21:37



--- Comment #1 from Tom "spot" Callaway  ---
Fixed in rawhide.

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

Re: Removal of BuildRoot

[Michael J Gruber]

No, that commit description was not helpful as it did not explain why you see a 
need to exert your proven packager privileges, nor the fact that this is a mass 
change. I had to go around and look for you and some info about your commit.

Frankly, I hate it when I notice that someone is stepping on my toes in 
packages that I maintain without even trying to contact me. We have 
pull-requests for exactly that purpose now - communication right where it 
belongs, open and transparent.

As for the change itself - those legacy spec features are neither necessary nor 
harmful. No need for urgent action at all. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Package wireshark-gtk going away

[Martin Sehnoutka]

This is a well known bug for few people who updated from older Wireshark
package to a new one while it was moved from sbin to bin. There is a
scriptlet, that should take care of this. If it does not work, you can
just fix it by hand. Remove the package, remove the alternatives and
install it again. Fresh installation works just fine.

Martin

On 02/14/2018 04:42 PM, Tom Hughes wrote:
> On 14/02/18 15:28, Michal Ruprich wrote:
> 
>> the wireshark-gtk is no longer supported by the upstream since
>> wireshark-2.4.0. You may have noticed that there is new GUI based on Qt
>> since wireshark-2.0. This GUI will become default and the GTK-based GUI
>> will be dropped and no longer provided. This change should appear in
>> Fedora 29.
> 
> You might want to fix the packaging... Installing that on F27 produces
> script noise:
> 
> failed to read link /usr/sbin/wireshark: No such file or directory
> the primary link for wireshark must be /usr/sbin/wireshark
> warning: %post(wireshark-qt-1:2.4.4-1.fc27.x86_64) scriptlet failed,
> exit status 2
> Non-fatal POSTIN scriptlet failure in rpm package wireshark-qt
> Non-fatal POSTIN scriptlet failure in rpm package wireshark-qt
> 
> I believe that wireshark-gtk has been doing the same for some time.
> 
> As best I can figure you are trying to use alternatives to manage
> the /usr/sbin/wireshark command as a link to one or the other but
> alternatives is upset that nothing has created an initial value for
> that link or something.
> 
> Tom
> 

-- 
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.



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: [HEADS UP] Package wireshark-gtk going away

[Tom Hughes]

On 14/02/18 15:42, Tom Hughes wrote:


As best I can figure you are trying to use alternatives to manage
the /usr/sbin/wireshark command as a link to one or the other but
alternatives is upset that nothing has created an initial value for
that link or something.


Actually apparently it's now in /usr/bin but I had old state left
in /var/lib/alternatives/wireshark for /usr/sbin that hadn't been
cleaned up when it moved and which was preventing an install to the
new path.

Tom

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

[EPEL-devel] Re: Adding devtoolset to EPEL

[Tom Callaway]

On 02/07/2018 05:24 PM, Stephen John Smoogen wrote:

> Status Report:
> 
> 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? :)

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

Re: [HEADS UP] Package wireshark-gtk going away

[Tom Hughes]

On 14/02/18 15:28, Michal Ruprich wrote:


the wireshark-gtk is no longer supported by the upstream since
wireshark-2.4.0. You may have noticed that there is new GUI based on Qt
since wireshark-2.0. This GUI will become default and the GTK-based GUI
will be dropped and no longer provided. This change should appear in
Fedora 29.


You might want to fix the packaging... Installing that on F27 produces 
script noise:


failed to read link /usr/sbin/wireshark: No such file or directory
the primary link for wireshark must be /usr/sbin/wireshark
warning: %post(wireshark-qt-1:2.4.4-1.fc27.x86_64) scriptlet failed, 
exit status 2

Non-fatal POSTIN scriptlet failure in rpm package wireshark-qt
Non-fatal POSTIN scriptlet failure in rpm package wireshark-qt

I believe that wireshark-gtk has been doing the same for some time.

As best I can figure you are trying to use alternatives to manage
the /usr/sbin/wireshark command as a link to one or the other but
alternatives is upset that nothing has created an initial value for
that link or something.

Tom

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

[HEADS UP] Package wireshark-gtk going away

[Michal Ruprich]

Hi,

the wireshark-gtk is no longer supported by the upstream since
wireshark-2.4.0. You may have noticed that there is new GUI based on Qt
since wireshark-2.0. This GUI will become default and the GTK-based GUI
will be dropped and no longer provided. This change should appear in
Fedora 29.

-- 
Michal Ruprich
Associate Software Engineer

Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[Bug 1198991] License tag should mention GPLv2+

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1545307



-- 
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 1545307] License tag does not match Text-Template-1.47 content

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

External Bug ID||CPAN 102523
   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1198991



-- 
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 1545307] New: License tag does not match Text-Template-1.47 content

[bugzilla]

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

Bug ID: 1545307
   Summary: License tag does not match Text-Template-1.47 content
   Product: Fedora
   Version: rawhide
 Component: perl-Text-Template
  Assignee: tcall...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Text-Template-1.47 changed license declarations to address
. That means there is no
(GPLv2+ or Artistic) code in the release.

However, the License: tag was not changed and it still is:

(GPL+ or Artistic) and (GPLv2+ or Artistic)

It should be changed to:

GPL+ or Artistic

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

Release notes vs. Changelogs [was Re: Escaping macros in %changelog]

[Matthew Miller]

On Wed, Feb 14, 2018 at 10:00:18AM +0100, nicolas.mail...@laposte.net wrote:
> Actually, the problem is we're all talking about changelogs, when users ask 
> for release notes.
> That's not exactly the same thing.

Yes! Thanks, that puts nicely what I'm trying to say. Right now, the
git log is basically a (often poor, because it seems redudant with the
%changelog) changelog, the bodhi update info is release notes (when it
exists), and the %changelog is a weird mix.

I'd like to see us do one of:

1. Put real changelog info in the git log and have a separate standard
   fedora-package-release-notes.md (uh, or better name, but I bet that
   one doesn't have any conflicts!) which lives in dist-git (but not in
   the package) and gets fed into bodhi and whatever other tooling

2. Put both in git log but mark the release notes lines in some way so
   they can be extracted.

3. Or something else along these lines. The key parts are: reduce
   duplication and at the same time make the separation between release
   notes and changelog more clear so that both can be better.

-- 
Matthew Miller

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

Re: inject rpm dependency depending on library symbol?

[Rex Dieter]

Kevin Kofler wrote:

> Rex Dieter wrote:
>> (I know this would be handled automatically if the Qt_5_PRIVATE_API
>> symbol was versioned, but that's an option we'd rather avoid if
>> reasonably possible)
> 
> IMHO, the right approach is to do just that. There is already a patch that
> does this:
> https://build.opensuse.org/package/view_file/KDE:Qt:5.9/libqt5-qtbase/tell-the-truth-about-private-api.patch?expand=1
> It just needs to be applied in Fedora.
> 
> Binary compatibility with upstream is irrelevant here because we are
> talking about private APIs only. Any third-party package that notices this
> at all is using private APIs and so can already break at any time. Any
> binaries not using private APIs will see any difference at all.

OK, that's the approach we're going with for now.  We'll see how well it 
works out in practice and testing.

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

Re: Call for users of darkserver

[Pierre-Yves Chibon]

On Wed, Feb 14, 2018 at 12:41:36PM +0100, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, 2018-02-14 at 11:02 +0100, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > The week before DevConf, a number of the members of the Fedora 
> > Infrastructure
> > met in Brno to discuss states and plans for the infrastructure.
> > One of the question that raised was about darkserver.
> > 
> > This application is available at: https://darkserver.fedoraproject.org/
> > and is meant to:
> > 
> > enable developer tools to identify exact package builds from which process
> > images (e.g. core dumps) come. This can enable their analysis, debugging
> > profiling, by finding out where the rpm / elf / dwarf files may be found, so
> > they can download them. (This is even better than
> > abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot
> > query
> > files no longer indexed by repodata.)
> > 
> > Source: https://fedoraproject.org/wiki/Darkserver
> > 
> > 
> > However, it seems this application has not been working for a long time now
> > and
> > not many people asked about it.
> > 
> > So, is anyone using this service?
> 
> I heard about this service, but never used it... But since debuginfo is now
> parallel-installable, it would be nice to have a place where all debuginfo
> (from all releases / builds) is available so people could install it even it
> disappeared from repositories.

I just confirmed it with Kushal (the developer of darkserver), darkserver
provides you an URL but that's basically sending you to koji (which keeps a good
chunk of the RPMs shipped to our user, but not all).
darkserver itself doesn't store anything.


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

Re: CheckRequire: in spec?

[Rex Dieter]

Marian Csontos wrote:

> I wonder, when there is a %check in spec, and the testsuite requires
> more packages than BuildRequires, is there a way to have them installed
> only if check is running?
> 
> Or shall I just throw them in as BuildRequire`s?

use BuildRequires

If these extra deps could cause complications (say, for bootstrapping), you 
can make them conditional (e.g. only used if %{bootstrap} macro is not 
defined)

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

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 12:07 -0800, Adam Williamson wrote:
> On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like
> > tell
> > me what things changed in the new glibc package, not that the glibc
> > RPM
> > has been upgraded to the new release.  I can figure out that part
> > myself.
> 
> As an alternative perspective on this, I am *constantly* frustrated
> by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely
> impossible
> to answer the question from the information available.


Yes!  As a lifelong developer and user with the gray hair of "been
there, done that" I couldn't agree more with this sentiment.  SCM
messages are for developers, not users.  I want an SCM message to
briefly summary WHAT happened and then in detail WHY it happened.  The
changed code itself gives details of WHAT and if it's unclear it ought
have comments in the code, not the SCM message.  Users, on the other
hand, likely don't care about any of that, unless they too are a
developer.  Fine, they don't need anything else.  Plain, non-developer
users however, need to know HOW this impacts them and might appreciate
the WHY.

Beyond that, I really don't care how we get there.  But IMHO, that
should be the goal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[John Florian]

On Tue, 2018-02-13 at 15:33 -0500, Josh Boyer wrote:
> 
> The point is, we have LOTS of places where change information or
> discussion occurs.  We should try and have a canonical location for
> the *descriptive summary* of these changes/discussions.

This hit home.  Way back in the early 90s when I was new to Linux this
was one of the more frustrating things for me.  Mastering RHL (later
Fedora) was an exercise in knowing *where* to look and you can't even
know to look there until you become aware that there's yet one more
source.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RPM Lint Errors

[Greg Hellings]

I have a package that includes a group of Ansible playbooks embedded into a
Python module. The playbooks include a number of templates that are
designed to be uploaded into remote systems, templated out with appropriate
variables, and then executed on the remote system.

Since the templates are designed to become executables on the remote hosts,
they have she-bang lines as appropriate (mostly shell scripts, a few Python
scripts). However, they are not yet supposed to be executed, since they are
template files that generate the executable files.

Rpmlint flags these files as executables (because of the she-bang) that
lack the executable flag (because that flag will be set after templating
and upload). Is there a way for me to specifically tell rpmlint to ignore
that particular error for those files so I can avoid these false positives?
Do I just have to pony up and deal with it?

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

Re: Mass Rebuild for Fedora 28

[Tomasz Kłoczko]

On 12 February 2018 at 23:06, Dennis Gilmore  wrote:
[..]

> [1] https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
>
kloczek (1):xml-security-c

Looks like at the moment Fedora build infrastructure is using set of
packages which is still not pushed to public repo.
This particular build fail looks like is caused by new version of
the xerces-c.
Will check this when new xerces-c-devel 3.2.0 will be in public rawhide
repo.

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

Re: CheckRequire: in spec?

[Tomasz Kłoczko]

On 14 February 2018 at 08:56, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Wed, 2018-02-14 at 09:39 +0100, Marian Csontos wrote:
> > I wonder, when there is a %check in spec, and the testsuite requires
> > more packages than BuildRequires, is there a way to have them installed
> > only if check is running?
>
> This has been brought up few time... There is nothing like that. The
> consensus,
> IIRC, was to use %bcond_without check and have
> %if %{with check}
> BuildRequires: ...
> %endif
>
> same for %check section itself. I think someone wanted to implement this
> generally in RPM, but this didn't happen.
>

Using such constructions is not compliant with --nocheck rpmbuild command
line option.
When I've proposed here CheckRequire few months ago on this list original
intention was to use those additional dependency when rpmbuild is not
executed with --nocheck option.

kloczek
PS. Igor may I ask you disable use PGP signs in public emails? or at least
switch to use PGP signature as MIME attachment? Please ..
I can understand that using PGP is OK or is sometimes necessary when
someone who receives your emails needs to be sure that it is your emails.
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: vdr-live build fails for rawhide

[Martin Gansser]

> Mamoru TASAKA wrote on 02/14/2018 08:21 PM:
> 
> And actually disabling parallel make seems to help this:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25039927
> 
> Regards,
> Mamoru

Thanks for your help, disabling %{?_smp_mflags} works
Regards Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1545223] perl-Test2-Suite-0.000100 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test2-Suite-0.000100-1
   ||.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-14 08:32:55



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 28.

-- 
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 1545223] New: perl-Test2-Suite-0.000100 is available

[bugzilla]

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

Bug ID: 1545223
   Summary: perl-Test2-Suite-0.000100 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.000100
Current version/release in rawhide: 0.97-2.fc28
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

[Bug 1544283] perl-Mojolicious-7.66 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Mojolicious-7.65 is|perl-Mojolicious-7.66 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 7.66
Current version/release in rawhide: 7.64-1.fc28
URL: http://mojolicio.us/

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

-- 
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: vdr-live build fails for rawhide

[Mamoru TASAKA]

Mamoru TASAKA wrote on 02/14/2018 08:21 PM:

Martin Gansser wrote on 02/14/2018 05:19 PM:

when building vdr-live for rawhide it fails [1] for ppc64le and ppc64
when adding "-Wsizeof-pointer-memaccess" to the build flags, then it fails [2] 
for s390x.

%build
make CFLAGS="%{optflags} -fPIC" CXXFLAGS="%{optflags} -fPIC 
-Wsizeof-pointer-memaccess" %{?_smp_mflags} all

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25033068
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25033656


Just a guess:

CC osd_status.o
LD libvdr-live.so
osd_status.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status


may mean that ld tries to collect osd_status.o but at the timing
osd_status.o was still under build - i.e. parallel make may be failing.

Maybe disabling parallel make fixes this.



And actually disabling parallel make seems to help this:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25039927

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

Re: Call for users of darkserver

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 11:02 +0100, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> The week before DevConf, a number of the members of the Fedora Infrastructure
> met in Brno to discuss states and plans for the infrastructure.
> One of the question that raised was about darkserver.
> 
> This application is available at: https://darkserver.fedoraproject.org/
> and is meant to:
> 
> enable developer tools to identify exact package builds from which process
> images (e.g. core dumps) come. This can enable their analysis, debugging
> profiling, by finding out where the rpm / elf / dwarf files may be found, so
> they can download them. (This is even better than
> abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot
> query
> files no longer indexed by repodata.)
> 
> Source: https://fedoraproject.org/wiki/Darkserver
> 
> 
> However, it seems this application has not been working for a long time now
> and
> not many people asked about it.
> 
> So, is anyone using this service?

I heard about this service, but never used it... But since debuginfo is now
parallel-installable, it would be nice to have a place where all debuginfo
(from all releases / builds) is available so people could install it even it
disappeared from repositories.

I don't know if existing service is doing exactly what I want..
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqEIHAACgkQaVcUvRu8
X0wn1g/8C7z4bXpQCEAMaPRqw3IPlPd+pZqH3/Ilq05mOagrLfR3h6mM6HUqrgSu
RshooEd17J1H9gtrlqIJuUrp9Hv8C7yf77AOTMvcc2Kgo9ZC5o2VL/AyMUyot7vw
Hla9EUZtvGGHQAulyjg1XPRXB7K+p0C9LFs3x87bchpCnJeAwoU2QpyOpWP2tM8z
Zipq4+4empZ0mVlPuXLZN1w4BNAfm/4YbvNQxQW6PYDKKfjZQemaDkKfiukTo8cH
an65qQPOCxA1ohxF8m/zxnBOtubYxEvWEa9HGWVFqavihZvWBUuhvaed58RmHwY6
8V0/sUt9euN5xBQHiWdLm+Ovx8icMw0qHbr+YcrbS4PmqxB5i9RyHWX05lhVafy0
c7dgT9dX76/xhzperIreMoBmLzkM5OWWxso6PRlIFWzeghf1nRTESVI2NjPiyRe4
j0lNVGPiCsTj6LuoUQxyftYgNHnbwM8RDqF0tP7oo8QCxzu/21DgdUNchaXdGUSs
CY6pSCtKjuLihkjnqC4OVr1b+ESFQytO1Af/HO81rAnxXexFMihIibzAB6evIbbX
jCs4aXXO5XRaBAyIAyiWoE9/NQy24cs5gePsnLEQOZ/2TwifWbTLXvBqWM451jF2
CqDG5S21dY9i93/0BshfSEX3CZLcuI+SBx/ZcAB6U6W2yUCUNmU=
=VZxp
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Call for users of darkserver

[Pierre-Yves Chibon]

Good Morning Everyone,

The week before DevConf, a number of the members of the Fedora Infrastructure
met in Brno to discuss states and plans for the infrastructure.
One of the question that raised was about darkserver.

This application is available at: https://darkserver.fedoraproject.org/
and is meant to:

enable developer tools to identify exact package builds from which process
images (e.g. core dumps) come. This can enable their analysis, debugging
profiling, by finding out where the rpm / elf / dwarf files may be found, so
they can download them. (This is even better than
abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot query
files no longer indexed by repodata.)

Source: https://fedoraproject.org/wiki/Darkserver


However, it seems this application has not been working for a long time now and
not many people asked about it.

So, is anyone using this service?

If there is little interest for this project, we will likely decommission it in
the coming weeks (say end of March).


Thanks for your attention and your feedback,

Pierre
For the Fedora Infrastructure team



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

Call for users of darkserver

[Pierre-Yves Chibon]

Good Morning Everyone,

The week before DevConf, a number of the members of the Fedora Infrastructure
met in Brno to discuss states and plans for the infrastructure.
One of the question that raised was about darkserver.

This application is available at: https://darkserver.fedoraproject.org/
and is meant to:

enable developer tools to identify exact package builds from which process
images (e.g. core dumps) come. This can enable their analysis, debugging
profiling, by finding out where the rpm / elf / dwarf files may be found, so
they can download them. (This is even better than
abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot query
files no longer indexed by repodata.)

Source: https://fedoraproject.org/wiki/Darkserver


However, it seems this application has not been working for a long time now and
not many people asked about it.

So, is anyone using this service?

If there is little interest for this project, we will likely decommission it in
the coming weeks (say end of March).


Thanks for your attention and your feedback,

Pierre
For the Fedora Infrastructure team



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

Re: vdr-live build fails for rawhide

[Mamoru TASAKA]

Martin Gansser wrote on 02/14/2018 05:19 PM:

when building vdr-live for rawhide it fails [1] for ppc64le and ppc64
when adding "-Wsizeof-pointer-memaccess" to the build flags, then it fails [2] 
for s390x.

%build
make CFLAGS="%{optflags} -fPIC" CXXFLAGS="%{optflags} -fPIC 
-Wsizeof-pointer-memaccess" %{?_smp_mflags} all

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25033068
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25033656


Just a guess:

CC osd_status.o
LD libvdr-live.so
osd_status.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status


may mean that ld tries to collect osd_status.o but at the timing
osd_status.o was still under build - i.e. parallel make may be failing.

Maybe disabling parallel make fixes this.

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

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

On Wed, Feb 14, 2018 at 11:16 AM, Pavel Raiskup  wrote:

> On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny wrote:
> > Hello Pavel,
> >
> > On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup 
> wrote:
> >
> > > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny 
> > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček <
> msima...@redhat.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > > > >>
> > > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > > > >>>
> > > > >>> Pavel
> > > > >>>
> > > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup
> wrote:
> > > > >>>
> > > >  Because we are unable to find a consensus on implementation
> details,
> > > >  it's
> > > >  likely we'll drop this feature from copr API and it will be
> > > probably a
> > > >  bit
> > > >  more complicated to setup mock chroot for local tests in future
> > > (you'll
> > > >  need to have builder machine with copr-rpmbuild installed, which
> > > brings
> > > >  a
> > > >  lot more runtime dependencies at least).
> > > > 
> > > >   From user perspective, do you mind if we dropped `copr
> mock-config`
> > > >  command?
> > > > 
> > > > 
> > > > >> I didn't know this command existed, but there were multiple times
> in
> > > the
> > > > >> past where I wished something like this had been available (It
> didn't
> > > exist
> > > > >> back then). It was usually situation like this: "Hi, I'm trying to
> > > build
> > > > >> $package in $copr and it fails because of $build_tool that you
> > > maintain,
> > > > >> can you help me?". And since I had no idea how his copr was set
> up,
> > > it took
> > > > >> me a lot of time before I was able to reproduce the problem. So, I
> > > would
> > > > >> find the feature useful, especially in instances outside Fedora,
> which
> > > > >> usually have more complex configurations.
> > > > >> If it had to be dropped, I'd appreciate if copr could display the
> > > > >> configuration of given project for non-owners. That way it would
> be
> > > easier
> > > > >> to construct my own config, without trying to guess stuff based on
> > > the logs.
> > > > >>
> > > > >
> > > > > First, thanks for your input. This is very useful information for
> us.
> > > > > Next, I would like to ask if it was ok to put all the functionality
> > > about
> > > > > build-testing and building itself into just a single package:
> > > > > copr-rpmbuild. I think having things on just one place can help us
> > > focus on
> > > > > doing them really well and as the copr-rpmbuild tool is already
> > > responsible
> > > > > for building, I think it would be a perfect place to add additional
> > > > > build-debugging functionality like printing-out/dumping mock
> configs,
> > > > > enablement to run just a part of the build process, possibility to
> > > enter
> > > > > the build environment interactively etc. Would this be alright?
> > > > >
> > > >
> > > > I need to add that with this tool you really need to know _what_ you
> are
> > > > building to be on the safe side. It is similar to running rpmbuild
> > > locally
> > > > (unless you are really just dumping mock configs).
> > >
> > > I use 'copr mock-config' for working with buildroot, even if I don't
> want
> > > to build anything (mock --shell).  So except from mock, any other deps
> > > installed by copr-rpmbuild are useless and I don't want them on my box
> > > basically.
> > >
> >
> > Alright, we can set some most prominent deps of copr-rpmbuild as weak
> deps.
> >
> > It will be then possible to install the minimal package setup e.g. with:
> >
> > # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
> >
> > I opened https://pagure.io/copr/copr/issue/222.
> >
> > Thanks!
>
> I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still
> can
> install mock/copr-cli and I can experiment with copr bulidroot through
> `copr
> mock-config` feature.  IOW, enforcing user to install another client tool
> for generating mock config doesn't make sense.
>

Actually, I would like to make some deps as very weak deps ('Suggests' tag),
so that they are not installed by default.

I am not sure what's the status of yum in EPEL7 but I think it would be very
nice if this functionality was backported there. If not, I will need to add
separate
Require tags for rhel. But thanks for that note!


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

rubygem-file-tail license change

[Vít Ondruch]

rubygem-file-tail-1.2.0-1.fc28 changed license from:

GPLv2

to:

ASL 2.0



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

Re: Usefulness of `copr mock-config ` feature?

[Pavel Raiskup]

On Wednesday, February 14, 2018 10:54:48 AM CET Michal Novotny wrote:
> Hello Pavel,
> 
> On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup  wrote:
> 
> > On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny 
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček  > >
> > > > wrote:
> > > >
> > > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > > >>
> > > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > > >>>
> > > >>> Pavel
> > > >>>
> > > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> > > >>>
> > >  Because we are unable to find a consensus on implementation details,
> > >  it's
> > >  likely we'll drop this feature from copr API and it will be
> > probably a
> > >  bit
> > >  more complicated to setup mock chroot for local tests in future
> > (you'll
> > >  need to have builder machine with copr-rpmbuild installed, which
> > brings
> > >  a
> > >  lot more runtime dependencies at least).
> > > 
> > >   From user perspective, do you mind if we dropped `copr mock-config`
> > >  command?
> > > 
> > > 
> > > >> I didn't know this command existed, but there were multiple times in
> > the
> > > >> past where I wished something like this had been available (It didn't
> > exist
> > > >> back then). It was usually situation like this: "Hi, I'm trying to
> > build
> > > >> $package in $copr and it fails because of $build_tool that you
> > maintain,
> > > >> can you help me?". And since I had no idea how his copr was set up,
> > it took
> > > >> me a lot of time before I was able to reproduce the problem. So, I
> > would
> > > >> find the feature useful, especially in instances outside Fedora, which
> > > >> usually have more complex configurations.
> > > >> If it had to be dropped, I'd appreciate if copr could display the
> > > >> configuration of given project for non-owners. That way it would be
> > easier
> > > >> to construct my own config, without trying to guess stuff based on
> > the logs.
> > > >>
> > > >
> > > > First, thanks for your input. This is very useful information for us.
> > > > Next, I would like to ask if it was ok to put all the functionality
> > about
> > > > build-testing and building itself into just a single package:
> > > > copr-rpmbuild. I think having things on just one place can help us
> > focus on
> > > > doing them really well and as the copr-rpmbuild tool is already
> > responsible
> > > > for building, I think it would be a perfect place to add additional
> > > > build-debugging functionality like printing-out/dumping mock configs,
> > > > enablement to run just a part of the build process, possibility to
> > enter
> > > > the build environment interactively etc. Would this be alright?
> > > >
> > >
> > > I need to add that with this tool you really need to know _what_ you are
> > > building to be on the safe side. It is similar to running rpmbuild
> > locally
> > > (unless you are really just dumping mock configs).
> >
> > I use 'copr mock-config' for working with buildroot, even if I don't want
> > to build anything (mock --shell).  So except from mock, any other deps
> > installed by copr-rpmbuild are useless and I don't want them on my box
> > basically.
> >
> 
> Alright, we can set some most prominent deps of copr-rpmbuild as weak deps.
> 
> It will be then possible to install the minimal package setup e.g. with:
> 
> # dnf -y install copr-rpmbuild --setopt=install_weak_deps=False
> 
> I opened https://pagure.io/copr/copr/issue/222.
> 
> Thanks!

I wouldn't be able to install copr-rpmbuild on EPEL7 then, where I still can
install mock/copr-cli and I can experiment with copr bulidroot through `copr
mock-config` feature.  IOW, enforcing user to install another client tool
for generating mock config doesn't make sense.

Pavel


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

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

Hello Pavel,

On Wed, Feb 14, 2018 at 10:18 AM, Pavel Raiskup  wrote:

> On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> > On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny 
> wrote:
> >
> > > Hello,
> > >
> > > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček  >
> > > wrote:
> > >
> > >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> > >>
> > >>> Sorry, I wanted to CC fedora devel before, forwarding.
> > >>>
> > >>> Pavel
> > >>>
> > >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> > >>>
> >  Because we are unable to find a consensus on implementation details,
> >  it's
> >  likely we'll drop this feature from copr API and it will be
> probably a
> >  bit
> >  more complicated to setup mock chroot for local tests in future
> (you'll
> >  need to have builder machine with copr-rpmbuild installed, which
> brings
> >  a
> >  lot more runtime dependencies at least).
> > 
> >   From user perspective, do you mind if we dropped `copr mock-config`
> >  command?
> > 
> > 
> > >> I didn't know this command existed, but there were multiple times in
> the
> > >> past where I wished something like this had been available (It didn't
> exist
> > >> back then). It was usually situation like this: "Hi, I'm trying to
> build
> > >> $package in $copr and it fails because of $build_tool that you
> maintain,
> > >> can you help me?". And since I had no idea how his copr was set up,
> it took
> > >> me a lot of time before I was able to reproduce the problem. So, I
> would
> > >> find the feature useful, especially in instances outside Fedora, which
> > >> usually have more complex configurations.
> > >> If it had to be dropped, I'd appreciate if copr could display the
> > >> configuration of given project for non-owners. That way it would be
> easier
> > >> to construct my own config, without trying to guess stuff based on
> the logs.
> > >>
> > >
> > > First, thanks for your input. This is very useful information for us.
> > > Next, I would like to ask if it was ok to put all the functionality
> about
> > > build-testing and building itself into just a single package:
> > > copr-rpmbuild. I think having things on just one place can help us
> focus on
> > > doing them really well and as the copr-rpmbuild tool is already
> responsible
> > > for building, I think it would be a perfect place to add additional
> > > build-debugging functionality like printing-out/dumping mock configs,
> > > enablement to run just a part of the build process, possibility to
> enter
> > > the build environment interactively etc. Would this be alright?
> > >
> >
> > I need to add that with this tool you really need to know _what_ you are
> > building to be on the safe side. It is similar to running rpmbuild
> locally
> > (unless you are really just dumping mock configs).
>
> I use 'copr mock-config' for working with buildroot, even if I don't want
> to build anything (mock --shell).  So except from mock, any other deps
> installed by copr-rpmbuild are useless and I don't want them on my box
> basically.
>

Alright, we can set some most prominent deps of copr-rpmbuild as weak deps.

It will be then possible to install the minimal package setup e.g. with:

# dnf -y install copr-rpmbuild --setopt=install_weak_deps=False

I opened https://pagure.io/copr/copr/issue/222.

Thanks!


>
> Pavel
>
> > > Thank you again for your feedback
> > > Michal
> > >
> > >
> > >>
> > >> Michael
> > >> ___
> > >> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> > >> To unsubscribe send an email to copr-devel-leave@lists.
> fedorahosted.org
> > >>
> > >
> > >
>
>
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Pavel Raiskup]

On Tuesday, February 13, 2018 10:15:42 PM CET Michal Novotny wrote:
> On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny  wrote:
> 
> > Hello,
> >
> > On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček 
> > wrote:
> >
> >> On 2018-02-13 11:47, Pavel Raiskup wrote:
> >>
> >>> Sorry, I wanted to CC fedora devel before, forwarding.
> >>>
> >>> Pavel
> >>>
> >>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> >>>
>  Because we are unable to find a consensus on implementation details,
>  it's
>  likely we'll drop this feature from copr API and it will be probably a
>  bit
>  more complicated to setup mock chroot for local tests in future (you'll
>  need to have builder machine with copr-rpmbuild installed, which brings
>  a
>  lot more runtime dependencies at least).
> 
>   From user perspective, do you mind if we dropped `copr mock-config`
>  command?
> 
> 
> >> I didn't know this command existed, but there were multiple times in the
> >> past where I wished something like this had been available (It didn't exist
> >> back then). It was usually situation like this: "Hi, I'm trying to build
> >> $package in $copr and it fails because of $build_tool that you maintain,
> >> can you help me?". And since I had no idea how his copr was set up, it took
> >> me a lot of time before I was able to reproduce the problem. So, I would
> >> find the feature useful, especially in instances outside Fedora, which
> >> usually have more complex configurations.
> >> If it had to be dropped, I'd appreciate if copr could display the
> >> configuration of given project for non-owners. That way it would be easier
> >> to construct my own config, without trying to guess stuff based on the 
> >> logs.
> >>
> >
> > First, thanks for your input. This is very useful information for us.
> > Next, I would like to ask if it was ok to put all the functionality about
> > build-testing and building itself into just a single package:
> > copr-rpmbuild. I think having things on just one place can help us focus on
> > doing them really well and as the copr-rpmbuild tool is already responsible
> > for building, I think it would be a perfect place to add additional
> > build-debugging functionality like printing-out/dumping mock configs,
> > enablement to run just a part of the build process, possibility to enter
> > the build environment interactively etc. Would this be alright?
> >
> 
> I need to add that with this tool you really need to know _what_ you are
> building to be on the safe side. It is similar to running rpmbuild locally
> (unless you are really just dumping mock configs).

I use 'copr mock-config' for working with buildroot, even if I don't want
to build anything (mock --shell).  So except from mock, any other deps
installed by copr-rpmbuild are useless and I don't want them on my box
basically.

Pavel

> > Thank you again for your feedback
> > Michal
> >
> >
> >>
> >> Michael
> >> ___
> >> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> >> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
> >>
> >
> >



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

Re: Usefulness of `copr mock-config ` feature?

[nicolas . mailhot]

Hi,

BTW, in my own very basic use of copr, I'm mostly annoyed with:
1. copr failing builds because of problems syncing repodata → not my problem as 
packager, retry till you manage to sync repositories and package groups
2. copr sometimes starting the next build, before finishing syncing the results 
of the previous one on all builders → again not my problem as packager, I want 
to see problems in *my* packaging only

That basically means a mass rebuild can not fire and forget srpms to copr once 
they build in local mock successfully, it needs to wait for each copr build to 
succeed and kick it again and again every time copr fails for 
non-packaging-related reasons.

With some builds taking an hour or more that means adding days of waiting to a 
complete coprified mass rebuild.

Regards,

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

Re: CheckRequire: in spec?

[Vascom]

%check run only on build stage so you can use just BuildRequire for it.

ср, 14 февр. 2018 г. в 11:47, Marian Csontos :

> I wonder, when there is a %check in spec, and the testsuite requires
> more packages than BuildRequires, is there a way to have them installed
> only if check is running?
>
> Or shall I just throw them in as BuildRequire`s?
>
> -- Martian
> ___
> 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: Escaping macros in %changelog

[nicolas . mailhot]

Hi,

Actually, the problem is we're all talking about changelogs, when users ask for 
release notes.
That's not exactly the same thing.

Regards,

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

Re: CheckRequire: in spec?

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2018-02-14 at 09:39 +0100, Marian Csontos wrote:
> I wonder, when there is a %check in spec, and the testsuite requires 
> more packages than BuildRequires, is there a way to have them installed 
> only if check is running?

This has been brought up few time... There is nothing like that. The consensus,
IIRC, was to use %bcond_without check and have
%if %{with check}
BuildRequires: ...
%endif

same for %check section itself. I think someone wanted to implement this
generally in RPM, but this didn't happen.

> Or shall I just throw them in as BuildRequire`s?

Yes.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqD+cEACgkQaVcUvRu8
X0zwmA//XPNf9ZitR5HU0azJJxifIv982/ZiDhEZh/newKtni2FMNE4Q53n734yT
rx+pyYsaR2stbASR4DrOUTq/6MjEkCFhLs5Dm+bRi1TC34t6QD8/VHh6qu2KAWqM
OPEUE85rEGW8E3glv4aZCNll6TBlJcok2XvnP0LgfcNtQLhvc/GLzGMjtkze2t+H
B3iWXj/g10WhCGQ6TV7xxCdlBoDEkusLWHGyxpD/mOKdN7JW9Tkplmz5kJirOmf5
+yMQhG6O3lzfL3bXw8JMJ2FocSYL+rD8agbu59xSE2QMGx0zwWjzvh5M6+ji7UPF
UQUf9JhHrf42SRYDbP11P2u3k6Y9IwioPqa+BUfqJEMO9cEM8yk0OIoPPuUjLCKt
3TAqmd6tYgp4K3wMvrc3tofFccPnLdYIHWsLHuiVKIV3qZn19d3acK/kL66bULk2
laG2hFaDD9/DLoEoome/FnqIpW25Czmpr24aotaF0wskCVSmC9PCsfqw2KJk4ugZ
tVAu9IDkCOIL7qzx/Eg6AH2AQa/BN2L1B6kt1i8DLmkdO9Oer5ZK0Uc+9MR8Mxvd
zpNr15kJzuyytqxcQsrbrYX4nci2iacBIWPJZEYYyU2Uw/PbiAhizY8VA2WO7Xd8
zjqo8M2CaFzQlZtxXsv6XDg5AEXCMA/pI/YR7+vlIkM6PMDMuOc=
=1auY
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org