date:20180726

On Fri, Jul 27, 2018 at 12:54 AM Jens-Ulrik Petersen 
wrote:

> I should test some larger package sets to see how well rpmbuild-order
> scales too...
>

BTW are there any tarballs of all the fedora spec files available somewhere
these days?
Of course I could download srpms, or better: script pulling spec files from
dist git.
Just wondered if something is already available?

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

[389-devel] 389 DS nightly 2018-07-27 - 90% PASS

2018-07-26 Thread vashirov

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

Re: dokuwiki packagers unresponsive

2018-07-26 Thread Sérgio Basto

On Thu, 2018-07-26 at 21:43 -0400, Solomon Peachy wrote:
> On Thu, Jul 26, 2018 at 09:09:25PM +0200, Peter 'Pessoft' Kolínek
> wrote:
> > I'd like to fix some issues (including security problems) which are
> > for
> > a long time present in dokuwiki package. Maintainers of the
> > dokuwiki
> > however seem unresponsive. 
> 
> It's worth stating that "some issues" is a euphamism for "the 
> package has been fundamentally broken since Fedora 24."
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1372948


The main admin (togdog) usually give permission to commit if you ask
him , at least did to me . 

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

Re: dokuwiki packagers unresponsive

2018-07-26 Thread Solomon Peachy

On Thu, Jul 26, 2018 at 09:09:25PM +0200, Peter 'Pessoft' Kolínek wrote:
> I'd like to fix some issues (including security problems) which are for
> a long time present in dokuwiki package. Maintainers of the dokuwiki
> however seem unresponsive. 

It's worth stating that "some issues" is a euphamism for "the 
package has been fundamentally broken since Fedora 24."

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

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#

2018-07-26 Thread Mark Wielaard

On Wed, 2018-07-25 at 21:04 +0300, Pavel Alexeev wrote:
> On 07/23/2018 12:36 PM, Dan Horák wrote:
> > On Mon, 23 Jul 2018 10:43:43 +0200
> > Mark Wielaard  wrote:
> > 
> > > On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:
> > > > Hello.
> > > > 
> > > > I try build new version of perdition package.
> > > > 
> > > > It build fine
> > > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416)
> > > > on
> > > > all architectures except armv7hl and s390x. On that I got
> > > > (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/b
> > > > uild.log):
> > > > 
> > > > error: Installed (but unpackaged) file(s) found:
> > > > /usr/lib/debug/usr/sbin/perdition.imap4-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.sWwnyG
> > > > /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.eE9BPY
> > > > /usr/lib/debug/usr/sbin/perdition.imaps-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.WRTN7g
> > > > /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.GWCloz
> > > > /usr/lib/debug/usr/sbin/perdition.pop3-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.
> > > > 2Sm2W5 /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-
> > > > 1.fc29.s390x.debug.#dwz#.kvArfo
> > > > 
> > > > Could someone please help me solve that problem?
> > > 
> > > It looks like dwz crashed and left those temporary files behind.
> > > Strangely there are no indication in the log files that dwz
> > > crashed.
> > > But there is an rm -f statement in the log right before the
> > > find-debuginfo.sh/dwz invocation that does seem to touch those
> > > files.
> > > I cannot explain where that comes from. It must be somewhere at
> > > the
> > > end of the %install phase, but there is nothing in the .spec file
> > > that hints at where it is coming from.
> > > 
> > > It might be necessary to run on a real s390x or armv7vhl machine
> > > to track down what is going on.
> > 
> > so I can reproduce that locally on my rawhide s390x guest
> > 
> > Mark, I'll give you the machine info thru other channels.
> 
> Sorry, is there any progress?

Sorry, I did sent an update, but it apparently didn't go to the list
for some reason. See attached.

Unfortunately some other things came up, so I couldn't immediately try
to look deeper. And I managed to loose the files that helped me
replicate the issue.

Now trying to rebuild the package I suddenly get these errors:

ssl.c: In function '__perdition_verify_callback':
ssl.c:243:35: error: dereferencing pointer to incomplete type
'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'}
  if (__perdition_verify_result(ctx->error, cert)
   ^~
ssl.c: In function '__perdition_ssl_check_common_name':
ssl.c:714:42: error: dereferencing pointer to incomplete type
'X509_NAME_ENTRY' {aka 'struct X509_name_entry_st'}
   if (!__perdition_ssl_compare_key(key, e->value->data,
  ^~
make[3]: *** [Makefile:643: ssl.o] Error 1

>  Should I fill bug for that? Against what component?

It really looks like a bug in dwz, so please file a bug against that.
I think a workaround for now would be to add %undefine
_find_debuginfo_dwz_opts to your spec. But I haven't been able to test
because of the above error.

Cheers,

Mark--- Begin Message ---
On Mon, Jul 23, 2018 at 11:36:14AM +0200, Dan Horák wrote:
> On Mon, 23 Jul 2018 10:43:43 +0200
> Mark Wielaard  wrote:
> > On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:
> > > all architectures except armv7hl and s390x. On that I got
> > > (https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log):
> > > 
> > > error: Installed (but unpackaged) file(s) found:
> > > /usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG
> > > /usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY
> > > /usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g
> > > /usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz
> > > /usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#.
> > > 2Sm2W5 
> > > /usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo
> > > 
> > > Could someone please help me solve that problem?
> > 
> > It looks like dwz crashed and left those temporary files behind.
> > Strangely there are no indication in the log files that dwz crashed.
> > But there is an rm -f statement in the log right before the
> > find-debuginfo.sh/dwz invocation that does seem to touch those files.
> > I cannot explain where that comes from. It must be somewhere at the
> > end of the %install phase, but there is nothing in the .spec file
> > that hints at where it is coming from.
> > 
> > It might be necessary to run on a real s390x or armv7vhl machine
> > to track down what is going on.
> 
> so I can reproduce that locally on my rawhide s390x guest
> 
> Mark, I'll give you the machine info thru other channels.

Thanks. I have replicated it. But don't understand

cmake segfault on 32-bit arches on Rawhide

2018-07-26 Thread Adam Williamson

I just tried a rebuild of a package in Rawhide, it worked on most
arches, but failed on armv7hl and i686 (our only 32-bit arches). On
both arches, cmake seems to have segfaulted:

https://koji.fedoraproject.org/koji/taskinfo?taskID=28626511
https://kojipkgs.fedoraproject.org//work/tasks/6529/28626529/build.log
https://kojipkgs.fedoraproject.org//work/tasks/6531/28626531/build.log

+ /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
-DCMAKE_BUILD_TYPE=Release .
/var/tmp/rpm-tmp.0imLnb: line 47: 15870 Segmentation fault  (core
dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib
-DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
-DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF
-DCMAKE_BUILD_TYPE=Release .

Just wanted to flag this up. I haven't yet tried doing the build in a
mock to try and get the core out, or anything like that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C4IWB2MNADAJTYL3ENQQVSQYWR3KMPPM/

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

2018-07-26 Thread R P Herrold

On Thu, 26 Jul 2018, Florian Weimer wrote:

> > Could you please mention a couple of bugs where this is shown?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1237260
> https://bugzilla.redhat.com/show_bug.cgi?id=1303323
> http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

thank you !!

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

Re: Release criteria proposal: installing / removing software

2018-07-26 Thread Adam Williamson

On Wed, 2018-07-18 at 12:51 -0700, Adam Williamson wrote:
> On Wed, 2018-07-18 at 08:49 +0200, drago01 wrote:
> > On Wednesday, July 18, 2018, Chris Murphy  wrote:
> > 
> > > On Tue, Jul 17, 2018 at 3:53 PM, Adam Williamson
> > >  wrote:
> > > > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote:
> > > > > I instinctively like the non-split form here because, to me, it
> > > > > emphasizes more clearly that "appropriately" applies to all three
> > > > > actions.
> > > > 
> > > > To be clearer here, consider these options:
> > > > 
> > > > "...to appropriately install, remove and update..."
> > > > "...to install, remove and update appropriately..."
> > > > "...appropriately to install, remove and update..."
> > > > 
> > > > To me, it's at least possible that someone might read the first as if
> > > > the "appropriately" applies only to the action "install", and the
> > > > second as if the "appropriately" applies only to the action "update".
> > > > The third, however, can't really be understood in any way *other* than
> > > > with "appropriately" applying to all three actions.
> > > 
> > > Use a colon.
> > > 
> > > to appropriately: install, remove, and update...
> > > 
> > > Unambiguous.
> > > 
> > 
> > Just drop "appropriately" and replace it with a footnote. Then there is no
> > need for all of this discussion and the text is easier to read (also
> > installing the correct update falls into common sense hence for most people
> > it will be clear even without reading the footnote).
> 
> There already is a footnote; to me the footnote reads better if it has
> a word in the text to key off.
> 
> To be honest I don't think anyone's actually pointed out any real
> *problem* with the revised draft yet and I'm inclined to just go with
> it, after a few more days for substantive feedback.

I'm going ahead and implementing the proposal broadly as last drafted,
I think there was sufficient agreement on the important parts of the
proposal. If the precise wording gives us trouble in future, it can
always be amended. Thanks, folks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VDZ6SQQANYNCZDN2Y7IGC7UGEYVP6UP2/

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

2018-07-26 Thread Florian Weimer


On 07/26/2018 06:45 PM, R P Herrold wrote:

On Thu, 26 Jul 2018, Florian Weimer wrote:


I would like to request a change of the Packaging Guidelines, advising
packagers not to interpose malloc.


The use here of 'interpose' is unclear to me -- are you saying
'substitute a different' ?


The reasons are:

* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs  do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
   malloc takes options away from system administrators.


Could you please mention a couple of bugs where this is shown?


https://bugzilla.redhat.com/show_bug.cgi?id=1237260
https://bugzilla.redhat.com/show_bug.cgi?id=1303323
http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

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

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

2018-07-26 Thread Carlos O'Donell

On 07/26/2018 12:45 PM, R P Herrold wrote:
> On Thu, 26 Jul 2018, Florian Weimer wrote:
> 
>> I would like to request a change of the Packaging Guidelines, advising
>> packagers not to interpose malloc.
> 
> The use here of 'interpose' is unclear to me -- are you saying 
> 'substitute a different' ?
> 
>> The reasons are:
>>
>> * We have resources to support glibc malloc, but not for other mallocs.
>> * Other mallocs  do not follow ABI and provide insufficient alignment.
>> * Choosing a malloc is workload-dependent and forcing a non-default
>>   malloc takes options away from system administrators.
> 
> Could you please mention a couple of bugs where this is shown?
Sure, issues like bug 1430223 are CLOSED/WONTFIX.

Bug 1430223 - In some conditions, tcmalloc memalign will segfault
https://bugzilla.redhat.com/show_bug.cgi?id=1430223

Do we have anyone with allocator experience beyond the Fedora glibc team?

I think a key point here is to reduce the number of allocators being
used by the distribution so we can keep the quality high and help
our users when they have problems.

Granted some people will need to use jemalloc because upstream links
against it directly, or is deeply integrated with it. I don't think
we should block that. We should however, avoid it where possible, and
standardize on an allocator that works well by default across a lot of
workloads, and let the system admins / DevOps people choose allocators
in the light of feedback from performance on production workloads
(not chosen by us, package managers, or upstream).

Allocator choice is always tightly coupled to workload.

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

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread Jeff Johnson

You are absolutely correct: there are times, e.g., that drinking coffee is 
"more important" to me than say, replying to e-mail. However I don't think that 
Haskel is the best language to feature up an already existing uglix tool.

Meanwhile I do not know of a tool that schedules rpm builds efficiently. I'd be 
happy to be wrong.

See the build scheduler for the Hurd in NixOS for what I was referring to

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

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

2018-07-26 Thread Carlos O'Donell

On 07/09/2018 07:03 PM, Igor Gnatenko wrote:
> today we finally dropped gcc and gcc-c++ from the buildroot
> .
> This made 12 packages go away along with 134MB installed size. This
> means that you need to add gcc/gcc-c++ in the BuildRequires
> (guidelines stated this for few years but not many were following
> them).

Great job!

In November 2015 (almost 3 years now) we added this requirement to
the packaging guidelines specifically for C and C++ :-)

"Packaging:C and C++"
https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B

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

dokuwiki packagers unresponsive

2018-07-26 Thread Peter 'Pessoft' Kolínek

Hello. 

I'd like to fix some issues (including security problems) which are for
a long time present in dokuwiki package. Maintainers of the dokuwiki
however seem unresponsive. 

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

Does anyone know how to contact maintainers? 

Thanks.

-- 
Kind regards,
Peter "Pessoft" Kolínek


Freehosting PIPNI - http://www.pipni.cz/___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5J7QBVGKGB5UWOQHEUKDHOE33KFMOHZX/

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

2018-07-26 Thread Carlos O'Donell

On 07/26/2018 12:24 PM, Vít Ondruch wrote:
> 
> 
> Dne 26.7.2018 v 18:03 Jason L Tibbitts III napsal(a):
>>> "FW" == Florian Weimer  writes:
>> FW> I would like to request a change of the Packaging Guidelines,
>> FW> advising packagers not to interpose malloc.
>>
>> How strong of a restriction are you looking for?  This sort of feels
>> like something which would at the strongest be a "SHOULD NOT" but maybe
>> you're looking for an absolute ban.
>>
>> Some maintainers may find it difficult to comply with an absolute ban if
>> the relevant software doesn't make it easy to change the allocator.  And
>> some upstreams may have strong preferences for one allocator over
>> another (which I imagine would often be linked to performance).  Will
>> assistance be offered to modify affected packages?  What about
>> contacting upstreams?
>>
>> How many packages would need to change to meet this guideline?
> 
> Just FTR, there is ongoing discussion about changing default to jemalloc
> in Ruby:
> 
> https://bugs.ruby-lang.org/issues/14718
> 
> Wouldn't it be better if glibc maintainers joined such discussions to
> improve glibc malloc implementation?

This is an orthogonal problem. I've responded in the Ruby ticket.

Improving glibc's malloc will take time, and we have already started.

We tackled performance for qemu and DJ Delorie implemented lockless thread
caching to reduce the fast path just like tcmalloc and jemalloc.

The next step is to tackle RSS and it is poorly understand and non-trivial.

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

Re: Installed (but unpackaged) file(s) found on s390x and armv7hl: .s390x.debug.#dwz#

2018-07-26 Thread Pavel Alexeev


Hello

On 07/23/2018 12:36 PM, Dan Horák wrote:

On Mon, 23 Jul 2018 10:43:43 +0200
Mark Wielaard  wrote:


On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:

Hello.

I try build new version of perdition package.

It build fine
(https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416) on
all architectures except armv7hl and s390x. On that I got
(https://kojipkgs.fedoraproject.org//work/tasks/6424/28526424/build.log):

error: Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/sbin/perdition.imap4-2.2-1.fc29.s390x.debug.#dwz#.sWwnyG
/usr/lib/debug/usr/sbin/perdition.imap4s-2.2-1.fc29.s390x.debug.#dwz#.eE9BPY
/usr/lib/debug/usr/sbin/perdition.imaps-2.2-1.fc29.s390x.debug.#dwz#.WRTN7g
/usr/lib/debug/usr/sbin/perdition.managesieve-2.2-1.fc29.s390x.debug.#dwz#.GWCloz
/usr/lib/debug/usr/sbin/perdition.pop3-2.2-1.fc29.s390x.debug.#dwz#.
2Sm2W5 
/usr/lib/debug/usr/sbin/perdition.pop3s-2.2-1.fc29.s390x.debug.#dwz#.kvArfo

Could someone please help me solve that problem?

It looks like dwz crashed and left those temporary files behind.
Strangely there are no indication in the log files that dwz crashed.
But there is an rm -f statement in the log right before the
find-debuginfo.sh/dwz invocation that does seem to touch those files.
I cannot explain where that comes from. It must be somewhere at the
end of the %install phase, but there is nothing in the .spec file
that hints at where it is coming from.

It might be necessary to run on a real s390x or armv7vhl machine
to track down what is going on.

so I can reproduce that locally on my rawhide s390x guest

Mark, I'll give you the machine info thru other channels.
Sorry, but is there some test machine with s390x or armv7vhl and 
rawhide? I cant find such on 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers 
and that issue cannot be reproduced in stable Fedora releases.



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


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

Re: F29 Self Contained Change: Deprecate YUM 3

2018-07-26 Thread Randy Barlow

On 06/27/2018 06:18 AM, Lubomír Sedlář wrote:
> Removing Yyum would mean that there will no longer be /usr/bin/pungi
> available in Fedora.

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

Fedora testing-20180726.0 compose check report

2018-07-26 Thread Fedora compose checker

No missing expected images.

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

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

2018-07-26 Thread R P Herrold

On Thu, 26 Jul 2018, Florian Weimer wrote:

> I would like to request a change of the Packaging Guidelines, advising
> packagers not to interpose malloc.

The use here of 'interpose' is unclear to me -- are you saying 
'substitute a different' ?

> The reasons are:
> 
> * We have resources to support glibc malloc, but not for other mallocs.
> * Other mallocs  do not follow ABI and provide insufficient alignment.
> * Choosing a malloc is workload-dependent and forcing a non-default
>   malloc takes options away from system administrators.

Could you please mention a couple of bugs where this is shown?

Thank you

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

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

2018-07-26 Thread Mark Reynolds




On 07/26/2018 11:43 AM, Daniel P. Berrangé wrote:

On Thu, Jul 26, 2018 at 04:37:33PM +0100, Daniel P. Berrangé wrote:

On Thu, Jul 26, 2018 at 05:32:32PM +0200, Igor Gnatenko wrote:

On Thu, Jul 26, 2018 at 5:29 PM Florian Weimer  wrote:


I would like to request a change of the Packaging Guidelines, advising
packagers not to interpose malloc.

The reasons are:

* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs  do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
malloc takes options away from system administrators.

This does not concern other allocators, such as Boehm GC or APR, only
the standard malloc interfaces.


How does one detect that some other allocator is used? Do we have some
automated tools? Do you have a draft?

If you know the other malloc impl, you can do a dnf query. For example
gperftools ships the tcmalloc impl. Looking at the ELF symbol it provides,
we can query for its usage thus:

# dnf repoquery --whatrequires 'libtcmalloc.so.4()(64bit)'
389-ds-base-0:1.4.0.6-2.fc28.x86_64
389-ds-base-libs-0:1.4.0.6-2.fc28.x86_64
389-ds-base-snmp-0:1.4.0.6-2.fc28.x86_64
Pound-1:2.7-3.fc24.x86_64
bro-core-0:2.5.3-2.fc28.x86_64
ceph-base-1:12.2.4-1.fc28.x86_64
ceph-base-1:12.2.7-1.fc28.x86_64
ceph-common-1:12.2.4-1.fc28.x86_64
ceph-common-1:12.2.7-1.fc28.x86_64
ceph-fuse-1:12.2.4-1.fc28.x86_64
ceph-fuse-1:12.2.7-1.fc28.x86_64
ceph-mds-1:12.2.4-1.fc28.x86_64
ceph-mds-1:12.2.7-1.fc28.x86_64
ceph-mgr-1:12.2.4-1.fc28.x86_64
ceph-mgr-1:12.2.7-1.fc28.x86_64
ceph-mon-1:12.2.4-1.fc28.x86_64
ceph-mon-1:12.2.7-1.fc28.x86_64
ceph-osd-1:12.2.4-1.fc28.x86_64
ceph-osd-1:12.2.7-1.fc28.x86_64
ceph-radosgw-1:12.2.4-1.fc28.x86_64
ceph-radosgw-1:12.2.7-1.fc28.x86_64
ceph-test-1:12.2.4-1.fc28.x86_64
ceph-test-1:12.2.7-1.fc28.x86_64
gperftools-devel-0:2.6.3-2.fc28.x86_64
mongodb-0:3.6.3-1.fc28.x86_64
mongodb-server-0:3.6.3-1.fc28.x86_64

Amuzingly/depressingly (delete as appropriate) we see 389-ds uses both
tcmalloc *and* jemalloc depending on sub-RPM in question !

This was fixed in 1.4.0.12-1


# dnf repoquery --whatrequires 'libjemalloc.so.2()(64bit)'
389-ds-base-devel-0:1.4.0.11-2.fc28.x86_64
blender-1:2.79b-2.fc28.x86_64
blender-1:2.79b-3.fc28.x86_64
blenderplayer-1:2.79b-2.fc28.x86_64
blenderplayer-1:2.79b-3.fc28.x86_64
jemalloc-devel-0:5.0.1-5.fc28.x86_64
neovim-0:0.2.2-1.fc28.x86_64
neovim-0:0.3.0-2.fc28.x86_64
redis-0:4.0.10-1.fc28.x86_64
redis-0:4.0.9-1.fc28.x86_64
varnish-0:5.2.1-4.fc28.x86_64

Regards,
Daniel

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

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread Adam Williamson

On Thu, 2018-07-26 at 15:40 +, Jeff Johnson wrote:
> There are easier ways to accomplish build ordering using tsort(1) and a minor 
> amount of scripting with the same simplifying assumptions your program is 
> making:
> 1) no cycles
> 2) every package provides its own name
> 3) every package supplies prerequisite package names without versions
> 
> tsort(1) just needs 1 line of input for each package containing the name 
> followed by a list of prerequisites ending with a new line
> 
> More important than build ordering is scheduling a set of builds
> efficiently across multiple build machines to complete in the
> shortest amount of time taking into account the cost in memory and
> cpu time of each package build.

This is a rather over-bold claim. What's "more important" depends on
what you're doing at the time. If you just need to bump and rebuild a
bunch of packages on Rawhide for an soname bump (just to give an
*ENTIRELY RANDOM EXAMPLE*, right juhp? :>), then a tool like this is
what you need. Since you won't be scheduling the builds - that's Koji's
job - you don't need a tool that does that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VRPULCYYOBUBTPJ5NXRAM45NAQUH5LK7/

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

2018-07-26 Thread Vít Ondruch

Dne 26.7.2018 v 18:03 Jason L Tibbitts III napsal(a):
>> "FW" == Florian Weimer  writes:
> FW> I would like to request a change of the Packaging Guidelines,
> FW> advising packagers not to interpose malloc.
>
> How strong of a restriction are you looking for?  This sort of feels
> like something which would at the strongest be a "SHOULD NOT" but maybe
> you're looking for an absolute ban.
>
> Some maintainers may find it difficult to comply with an absolute ban if
> the relevant software doesn't make it easy to change the allocator.  And
> some upstreams may have strong preferences for one allocator over
> another (which I imagine would often be linked to performance).  Will
> assistance be offered to modify affected packages?  What about
> contacting upstreams?
>
> How many packages would need to change to meet this guideline?

Just FTR, there is ongoing discussion about changing default to jemalloc
in Ruby:

https://bugs.ruby-lang.org/issues/14718

Wouldn't it be better if glibc maintainers joined such discussions to
improve glibc malloc implementation?

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

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

2018-07-26 Thread Daniel P . Berrangé

On Thu, Jul 26, 2018 at 11:03:08AM -0500, Jason L Tibbitts III wrote:
> > "FW" == Florian Weimer  writes:
> 
> FW> I would like to request a change of the Packaging Guidelines,
> FW> advising packagers not to interpose malloc.
> 
> How strong of a restriction are you looking for?  This sort of feels
> like something which would at the strongest be a "SHOULD NOT" but maybe
> you're looking for an absolute ban.
> 
> Some maintainers may find it difficult to comply with an absolute ban if
> the relevant software doesn't make it easy to change the allocator.  And
> some upstreams may have strong preferences for one allocator over
> another (which I imagine would often be linked to performance).  Will
> assistance be offered to modify affected packages?  What about
> contacting upstreams?

Yeah it is often linked to a supposed performance improvement. QEMU supports
choice of native, jemalloc or tcmalloc and in Fedora we used to use
tcmalloc for QEMU for a while. Then we checked performance again and found
that the delta to glibc's native malloc had essentially gone, so we've
stopped using tcmalloc.  IOW, even if it was done for performance reasons
originally, we should not assume that is still valid today as glibc has
improved its impl.

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

Orphan packages will be retired if they remain orphaned for six weeks"

2018-07-26 Thread R P Herrold

On Thu, 26 Jul 2018, Miro Hrončok wrote:

> Is $subj [1] an automated or manual process? Shall I retire packages I've
> orphaned before more weeks or just wait?
> 
> [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

NONE of the outlinks to the actual packages at: 

Lists of Orphan and Retired Packages
[ RH, EPEL 5, EPEL 6, or EPEL 7 ]

actually work, of course  (links as on that page, below)

I think proceeding is premature, when a person cannot in good 
faith, review what is to be dropped

-- Russ herrold


https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=master

https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=el5

https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=el6

https://admin.fedoraproject.org/pkgdb/orphaned/?status=Orphaned=epel7
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PKSL2OQOXDDMEQ6OHLCOTNP3EKTNFJJE/

Re: Starting a Container SIG

2018-07-26 Thread Alessio Ciregia

On Wed, Jul 25, 2018, 9:13 PM Eduard Lucena  wrote:

> Hi,
>
> I'm not familiar with the container technology, but I will love to learn
> it. I would like to help with this SIG.
>

Well, I'm not an expert at all, but like Eduard I would like to learn
something related to containers.

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 6:04 PM Jens-Ulrik Petersen 
wrote:

> On Fri, Jul 27, 2018 at 12:42 AM Jeff Johnson  wrote:
>
>> There are easier ways to accomplish build ordering using tsort(1) and a
>> minor amount of scripting with the same simplifying assumptions your
>> program is making:
>> 1) no cycles
>> 2) every package provides its own name
>> 3) every package supplies prerequisite package names without versions
>>
>
> Yes that is essentially what my program does (just using a graph library).
> (But I don't think tsort can determine reverse deps etc - but it could be
> scripted too sure.)
> I should test some larger package sets to see how well rpmbuild-order
> scales too...
>

Just take ripgrep and try to revdep it.


> More important than build ordering is scheduling a set of builds
>> efficiently across multiple build machines to complete in the shortest
>> amount of time taking into account the cost in memory and cpu time of each
>> package build.
>
>
> That's correct, and I want to do ordered parallel builds over such
> dependency graphs.
>
> Jens
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RFLLWLFFPAJON5UX7ORXJOZXRBFMIIBV/
>
-- 

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

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

2018-07-26 Thread Jason L Tibbitts III

> "FW" == Florian Weimer  writes:

FW> I would like to request a change of the Packaging Guidelines,
FW> advising packagers not to interpose malloc.

How strong of a restriction are you looking for?  This sort of feels
like something which would at the strongest be a "SHOULD NOT" but maybe
you're looking for an absolute ban.

Some maintainers may find it difficult to comply with an absolute ban if
the relevant software doesn't make it easy to change the allocator.  And
some upstreams may have strong preferences for one allocator over
another (which I imagine would often be linked to performance).  Will
assistance be offered to modify affected packages?  What about
contacting upstreams?

How many packages would need to change to meet this guideline?

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Fri, Jul 27, 2018 at 12:42 AM Jeff Johnson  wrote:

> There are easier ways to accomplish build ordering using tsort(1) and a
> minor amount of scripting with the same simplifying assumptions your
> program is making:
> 1) no cycles
> 2) every package provides its own name
> 3) every package supplies prerequisite package names without versions
>

Yes that is essentially what my program does (just using a graph library).
(But I don't think tsort can determine reverse deps etc - but it could be
scripted too sure.)
I should test some larger package sets to see how well rpmbuild-order
scales too...

More important than build ordering is scheduling a set of builds
> efficiently across multiple build machines to complete in the shortest
> amount of time taking into account the cost in memory and cpu time of each
> package build.


That's correct, and I want to do ordered parallel builds over such
dependency graphs.

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

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

2018-07-26 Thread Daniel P . Berrangé

On Thu, Jul 26, 2018 at 04:37:33PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 26, 2018 at 05:32:32PM +0200, Igor Gnatenko wrote:
> > On Thu, Jul 26, 2018 at 5:29 PM Florian Weimer  wrote:
> > 
> > > I would like to request a change of the Packaging Guidelines, advising
> > > packagers not to interpose malloc.
> > >
> > > The reasons are:
> > >
> > > * We have resources to support glibc malloc, but not for other mallocs.
> > > * Other mallocs  do not follow ABI and provide insufficient alignment.
> > > * Choosing a malloc is workload-dependent and forcing a non-default
> > >malloc takes options away from system administrators.
> > >
> > > This does not concern other allocators, such as Boehm GC or APR, only
> > > the standard malloc interfaces.
> > >
> > 
> > How does one detect that some other allocator is used? Do we have some
> > automated tools? Do you have a draft?
> 
> If you know the other malloc impl, you can do a dnf query. For example
> gperftools ships the tcmalloc impl. Looking at the ELF symbol it provides,
> we can query for its usage thus:
> 
> # dnf repoquery --whatrequires 'libtcmalloc.so.4()(64bit)'
> 389-ds-base-0:1.4.0.6-2.fc28.x86_64
> 389-ds-base-libs-0:1.4.0.6-2.fc28.x86_64
> 389-ds-base-snmp-0:1.4.0.6-2.fc28.x86_64
> Pound-1:2.7-3.fc24.x86_64
> bro-core-0:2.5.3-2.fc28.x86_64
> ceph-base-1:12.2.4-1.fc28.x86_64
> ceph-base-1:12.2.7-1.fc28.x86_64
> ceph-common-1:12.2.4-1.fc28.x86_64
> ceph-common-1:12.2.7-1.fc28.x86_64
> ceph-fuse-1:12.2.4-1.fc28.x86_64
> ceph-fuse-1:12.2.7-1.fc28.x86_64
> ceph-mds-1:12.2.4-1.fc28.x86_64
> ceph-mds-1:12.2.7-1.fc28.x86_64
> ceph-mgr-1:12.2.4-1.fc28.x86_64
> ceph-mgr-1:12.2.7-1.fc28.x86_64
> ceph-mon-1:12.2.4-1.fc28.x86_64
> ceph-mon-1:12.2.7-1.fc28.x86_64
> ceph-osd-1:12.2.4-1.fc28.x86_64
> ceph-osd-1:12.2.7-1.fc28.x86_64
> ceph-radosgw-1:12.2.4-1.fc28.x86_64
> ceph-radosgw-1:12.2.7-1.fc28.x86_64
> ceph-test-1:12.2.4-1.fc28.x86_64
> ceph-test-1:12.2.7-1.fc28.x86_64
> gperftools-devel-0:2.6.3-2.fc28.x86_64
> mongodb-0:3.6.3-1.fc28.x86_64
> mongodb-server-0:3.6.3-1.fc28.x86_64

Amuzingly/depressingly (delete as appropriate) we see 389-ds uses both
tcmalloc *and* jemalloc depending on sub-RPM in question !

# dnf repoquery --whatrequires 'libjemalloc.so.2()(64bit)'
389-ds-base-devel-0:1.4.0.11-2.fc28.x86_64
blender-1:2.79b-2.fc28.x86_64
blender-1:2.79b-3.fc28.x86_64
blenderplayer-1:2.79b-2.fc28.x86_64
blenderplayer-1:2.79b-3.fc28.x86_64
jemalloc-devel-0:5.0.1-5.fc28.x86_64
neovim-0:0.2.2-1.fc28.x86_64
neovim-0:0.3.0-2.fc28.x86_64
redis-0:4.0.10-1.fc28.x86_64
redis-0:4.0.9-1.fc28.x86_64
varnish-0:5.2.1-4.fc28.x86_64

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

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread Jeff Johnson

There are easier ways to accomplish build ordering using tsort(1) and a minor 
amount of scripting with the same simplifying assumptions your program is 
making:
1) no cycles
2) every package provides its own name
3) every package supplies prerequisite package names without versions

tsort(1) just needs 1 line of input for each package containing the name 
followed by a list of prerequisites ending with a new line

More important than build ordering is scheduling a set of builds efficiently 
across multiple build machines to complete in the shortest amount of time 
taking into account the cost in memory and cpu time of each package build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NSQZKDOHSTZLI2LJXTLIVJRFKAZT4VEM/

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

On Thu, Jul 26, 2018 at 5:32 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> On Thu, Jul 26, 2018 at 5:29 PM Florian Weimer  wrote:
>
>> I would like to request a change of the Packaging Guidelines, advising
>> packagers not to interpose malloc.
>>
>> The reasons are:
>>
>> * We have resources to support glibc malloc, but not for other mallocs.
>> * Other mallocs  do not follow ABI and provide insufficient alignment.
>> * Choosing a malloc is workload-dependent and forcing a non-default
>>malloc takes options away from system administrators.
>>
>> This does not concern other allocators, such as Boehm GC or APR, only
>> the standard malloc interfaces.
>>
>
>> Comments?
>>
>
> How does one detect that some other allocator is used? Do we have some
> automated tools? Do you have a draft?
>
> P.S. Packaged Rust uses glibc's allocator, upstream uses malloc.
>

jemalloc I meant.

>
>


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

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

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

2018-07-26 Thread Daniel P . Berrangé

On Thu, Jul 26, 2018 at 05:32:32PM +0200, Igor Gnatenko wrote:
> On Thu, Jul 26, 2018 at 5:29 PM Florian Weimer  wrote:
> 
> > I would like to request a change of the Packaging Guidelines, advising
> > packagers not to interpose malloc.
> >
> > The reasons are:
> >
> > * We have resources to support glibc malloc, but not for other mallocs.
> > * Other mallocs  do not follow ABI and provide insufficient alignment.
> > * Choosing a malloc is workload-dependent and forcing a non-default
> >malloc takes options away from system administrators.
> >
> > This does not concern other allocators, such as Boehm GC or APR, only
> > the standard malloc interfaces.
> >
> 
> How does one detect that some other allocator is used? Do we have some
> automated tools? Do you have a draft?

If you know the other malloc impl, you can do a dnf query. For example
gperftools ships the tcmalloc impl. Looking at the ELF symbol it provides,
we can query for its usage thus:

# dnf repoquery --whatrequires 'libtcmalloc.so.4()(64bit)'
389-ds-base-0:1.4.0.6-2.fc28.x86_64
389-ds-base-libs-0:1.4.0.6-2.fc28.x86_64
389-ds-base-snmp-0:1.4.0.6-2.fc28.x86_64
Pound-1:2.7-3.fc24.x86_64
bro-core-0:2.5.3-2.fc28.x86_64
ceph-base-1:12.2.4-1.fc28.x86_64
ceph-base-1:12.2.7-1.fc28.x86_64
ceph-common-1:12.2.4-1.fc28.x86_64
ceph-common-1:12.2.7-1.fc28.x86_64
ceph-fuse-1:12.2.4-1.fc28.x86_64
ceph-fuse-1:12.2.7-1.fc28.x86_64
ceph-mds-1:12.2.4-1.fc28.x86_64
ceph-mds-1:12.2.7-1.fc28.x86_64
ceph-mgr-1:12.2.4-1.fc28.x86_64
ceph-mgr-1:12.2.7-1.fc28.x86_64
ceph-mon-1:12.2.4-1.fc28.x86_64
ceph-mon-1:12.2.7-1.fc28.x86_64
ceph-osd-1:12.2.4-1.fc28.x86_64
ceph-osd-1:12.2.7-1.fc28.x86_64
ceph-radosgw-1:12.2.4-1.fc28.x86_64
ceph-radosgw-1:12.2.7-1.fc28.x86_64
ceph-test-1:12.2.4-1.fc28.x86_64
ceph-test-1:12.2.7-1.fc28.x86_64
gperftools-devel-0:2.6.3-2.fc28.x86_64
mongodb-0:3.6.3-1.fc28.x86_64
mongodb-server-0:3.6.3-1.fc28.x86_64

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

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

On Thu, Jul 26, 2018 at 5:29 PM Florian Weimer  wrote:

> I would like to request a change of the Packaging Guidelines, advising
> packagers not to interpose malloc.
>
> The reasons are:
>
> * We have resources to support glibc malloc, but not for other mallocs.
> * Other mallocs  do not follow ABI and provide insufficient alignment.
> * Choosing a malloc is workload-dependent and forcing a non-default
>malloc takes options away from system administrators.
>
> This does not concern other allocators, such as Boehm GC or APR, only
> the standard malloc interfaces.
>

> Comments?
>

How does one detect that some other allocator is used? Do we have some
automated tools? Do you have a draft?

P.S. Packaged Rust uses glibc's allocator, upstream uses malloc.


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

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

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

2018-07-26 Thread Florian Weimer

I would like to request a change of the Packaging Guidelines, advising 
packagers not to interpose malloc.


The reasons are:

* We have resources to support glibc malloc, but not for other mallocs.
* Other mallocs  do not follow ABI and provide insufficient alignment.
* Choosing a malloc is workload-dependent and forcing a non-default
  malloc takes options away from system administrators.

This does not concern other allocators, such as Boehm GC or APR, only 
the standard malloc interfaces.


Comments?

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

Fedora updates-20180726.0 compose check report

2018-07-26 Thread Fedora compose checker

No missing expected images.

Passed openQA tests: 2/2 (x86_64)

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

Re: Starting a Container SIG

2018-07-26 Thread Ivan Chavero

I would like to help!

El mié., 25 de jul. de 2018 12:12 PM, Clement Verna <
cve...@fedoraproject.org> escribió:

> Greeting all,
>
> The container effort in Fedora has until now been looked after by the
> Atomic WG, since this Working Group is now going to focus mostly on
> Fedora CoreOS, I propose to create a new container SIG to regroup
> people interested in the maintenance of application containers in
> Fedora.
>
> This SIG would look after the container guidelines [0], the container
> review process [1] and also the release process and tooling.
>
> Please Reply if you're interested with helping out making the
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.
>
> Regards,
> Clément
>
> [0] - https://fedoraproject.org/wiki/Container:Guidelines
> [1] - https://fedoraproject.org/wiki/Container:Review_Process
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/55QK4AYKBFGLFXCGAVJSXLEVEMC5NJQ2/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZ2QEJJ5WLSTSF4CNZEZSG7LDOXXZ3UQ/

Re: [CoreOS] Starting a Container SIG

2018-07-26 Thread Micah Abbott


On 07/25/2018 01:09 PM, Clement Verna wrote:

Greeting all,

The container effort in Fedora has until now been looked after by the
Atomic WG, since this Working Group is now going to focus mostly on
Fedora CoreOS, I propose to create a new container SIG to regroup
people interested in the maintenance of application containers in
Fedora.

This SIG would look after the container guidelines [0], the container
review process [1] and also the release process and tooling.

Please Reply if you're interested with helping out making the
Container story great in Fedora. If there is a good response, I will
create a Container SIG wiki page, and I guess we can ask for
container-devel mailing list for SIG discussions.


I'm interested in helping out with the SIG where possible.  I've got 
experience working with containers on Atomic Host and on Silverblue.


I look forward to having a great container story for Fedora!


Regards,
Clément

[0] - https://fedoraproject.org/wiki/Container:Guidelines
[1] - https://fedoraproject.org/wiki/Container:Review_Process
___
CoreOS mailing list -- cor...@lists.fedoraproject.org
To unsubscribe send an email to coreos-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/cor...@lists.fedoraproject.org/message/55QK4AYKBFGLFXCGAVJSXLEVEMC5NJQ2/


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

Fedora 29 Self-Contained Change: Kubernetes modules

https://fedoraproject.org/wiki/Changes/kubernetes-modules

== Summary ==
Create modules for all supported Kubernetes versions.
* Name: Lokesh Mandvekar
* Email: l...@fedoraproject.org

== Detailed Description ==
Currently, the Kubernetes upstream project develops and supports
multiple versions of Kubernetes, along with component tools like
cri-o/cri-tools which have their versions tightly coupled to OpenShift
versions. This change will result in creation of module builds which
will contain the rpms for Kubernetes / cri-o and other required tools.

== Benefit to Fedora ==
Ability to support/switch between multiple Kubernetes versions with
minimal effort on the user's part would make both users and
maintainers happy.

== Scope ==
* Proposal owners: Creation / review / koji builds of Kubernetes modules

== User Experience ==
Users will be able to quickly setup Kubernetes environments and switch
between versions.


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/RSLZ5HMEMMNXBAYIQSS3G435QVQEPQJZ/

Fedora 29 Self-Contained Change: Cloud Provider Image Updates

https://fedoraproject.org/wiki/Changes/CloudProviderImageUpdates

== Summary ==
Provide monthly updates to cloud provider images.

== Owner ==
* SIG: Cloud
* Primary Contact: [[User:jdoss| Joe Doss]]
* Product: Cloud
* Responsible WG: Cloud SIG

== Detailed Description ==

Fedora Cloud images are not updated after the initial release of the
most current Fedora version. This can leave outstanding issues with
the images that can impact the user experience long after they have
been addressed by package updates. Providing updated Cloud images
across all supported cloud providers on a monthly basis post release
will ensure end users are getting the best Fedora Cloud experience
possible.

== Benefit to Fedora ==

Update Cloud images will provide a better end user experience as it
will ensure it is up to date with the most current packages. This
gives users faster Fedora Cloud provisioning times and a secure out of
the box Cloud instance.

== Scope ==
* Proposal owners:
Cloud SIG

== User Experience ==

* Outstanding bugs post release will no longer be present in images.
* Improved provisioning times as the initial dnf update will be quicker.
* Improved base image security.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AHZSMUJPBELONVXSOTQDAR3LPP6RXW2R/

Fedora 29 Self-Contained Change: Kubernetes modules

https://fedoraproject.org/wiki/Changes/kubernetes-modules

== Summary ==
Create modules for all supported Kubernetes versions.
* Name: Lokesh Mandvekar
* Email: l...@fedoraproject.org

== Detailed Description ==
Currently, the Kubernetes upstream project develops and supports
multiple versions of Kubernetes, along with component tools like
cri-o/cri-tools which have their versions tightly coupled to OpenShift
versions. This change will result in creation of module builds which
will contain the rpms for Kubernetes / cri-o and other required tools.

== Benefit to Fedora ==
Ability to support/switch between multiple Kubernetes versions with
minimal effort on the user's part would make both users and
maintainers happy.

== Scope ==
* Proposal owners: Creation / review / koji builds of Kubernetes modules

== User Experience ==
Users will be able to quickly setup Kubernetes environments and switch
between versions.


-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RSLZ5HMEMMNXBAYIQSS3G435QVQEPQJZ/

Fedora 29 Self-Contained Change: Update Haskell packages to Stackage LTS 11

https://fedoraproject.org/wiki/Changes/Update_Haskell_to_Stackage_LTS_11

== Summary ==
Update the Haskell package set from Stackage LTS 10 to LTS 11.
This updates a subset of the Haskell libraries and packages to newer versions.

== Owner ==
* Name: Jens Petersen, Fedora Haskell SIG
* Email: 

== Detailed Description ==
The Haskell Stackage project provides consist sets of buildable
packages from the upstream Hackage repository.

[https://www.stackage.org/lts-11 Stackage LTS 11] was released in
March, it unlocks newer versions of a number of import Haskell
libraries and other packages.
GHC and its core libraries remain unchanged compared to LTS 10, so
only about half the packages will need to be rebuild (about 200
version bumps and their reverse dependencies).

(The just released Stackage LTS 12 which has a major ghc version bump
to 8.4.3 will wait for Fedora 30.)

== Benefit to Fedora ==
Fedora users will have a newer version of Haskell Stackage LTS
packages to use and develop on.

== Scope ==
* Proposal owners:
** Bump the affected Haskell packages from LTS 10 to LTS 11 using
cabal-rpm, rpmbuild-order and fedora-haskell-tools
** Build them and their reverse dependencies for Rawhide (using
f29-ghc sidetag to avoid disruption)
** Push the builds to Rawhide
** Verify the dependencies are consistent

== How To Test ==
* sudo dnf install ghc-*-devel cabal-install
* sudo dnf update ghc*
* cabal install Favorite-Package

== User Experience ==
The Fedora Haskell packages will be upgraded from Stackage LTS 10 to
LTS 11 versions.

== Documentation ==
https://www.stackage.org/diff/lts-10.10/lts-11.17

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HHNY4523LWWWQWXUMS53NDQLCDTDWMTU/

Fedora 29 Self-Contained Change: Stratis Storage 1.0

https://fedoraproject.org/wiki/Changes/StratisStorage-1.0

== Summary ==
Add support for Stratis version 1.0, a local storage management
solution. This will allow further testing and user feedback that will
guide Stratis's development and stabilization, and let us consider
future integration into Anaconda and other more critical aspects of
Fedora.

== Owner ==
* Name: Andy Grover, Igor Gnatenko
* Email: agro...@redhat.com, ignatenkobr...@fedoraproject.org

== Detailed Description ==

Stratis is a local storage system akin to Btrfs, ZFS, and LVM. Its
goal is to enable easier setup and management of disks and SSDs, as
well as enabling the use of advanced storage features -- such as thin
provisioning, snapshots, integrity, and a cache tier -- without
requiring expert-level storage administration knowledge. Furthermore,
Stratis includes monitoring and repair capabilities, and a
programmatic API, for better integration with higher levels of system
management software.

== Benefit to Fedora ==

Stratis can benefit Fedora users by making it easier and less hassle
to administer the system's storage devices. Making this easier is key
to increasing the uptake of advanced storage features (listed above),
which can further benefit the user in reduced administration
headaches, increased reliability, and greater flexibility.

Down the road, integrating Stratis support into Anaconda and other
management tools via its API could simplify the installation
experience, and make a dnf upgrade-rollback feature much easier.

== Scope ==
* Change owner: Stratis is currently in-development, with a 1.0
release coming soon. Stratis pre-1.0 versions are in Fedora 28 and
Rawhide. Although there are clearly later opportunities for
system-wide changes based on Stratis, Stratis 1.0 will be
self-contained.

== Upgrade/compatibility impact ==
Stratis 1.0 will change the on-disk metadata format, so any
bleeding-edge testers of Stratis 0.5 will need to recreate pools. (The
metadata format will be frozen for 1.0 so this will not be the case
going forward.)

== How To Test ==
Stratis 1.0 will be usable only for non boot or root partitions.
Fedora users and testers can use Stratis on non-primary disks, and put
it through its paces to generate bug reports and feature requests that
can guide Stratis future development.

== Contingency Plan ==

Just don't include the Stratis-specific packages in the final release.

== Documentation ==

Please see https://stratis-storage.github.io/ for design documents and
API reference.

Development and issue tracking is at https://github.com/stratis-storage/stratisd

--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7LYYXCJJWQQNSXZBC7YH2BVQZWOEC634/

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-07-26 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Jun 15, 2018 at 06:38:43PM -0500, Jason L Tibbitts III wrote:
> zbyszekcalibre python-music21

I fixed those two.

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

Re: EXTERNAL: Re: [atomic-devel] Starting a Container SIG

2018-07-26 Thread Wells, Roger K.

On 07/26/2018 12:45 AM, Masami Ichikawa wrote:
> I'm interested in a container technology, so I'd like to help the SIG.
+1
>
> On Thu, Jul 26, 2018 at 1:15 PM, Tim Orling  wrote:
>>
>> On Wed, Jul 25, 2018 at 2:42 PM Dusty Mabe  wrote:
>>>
>>>
>>> On 07/25/2018 01:09 PM, Clement Verna wrote:
 Please Reply if you're interested with helping out making the
 Container story great in Fedora. If there is a good response, I will
 create a Container SIG wiki page, and I guess we can ask for
 container-devel mailing list for SIG discussions.
>>> Unfortunately I can't sign up to do a bunch of work but I would like to
>>> join
>>> and help represent Fedora CoreOS and related interests in the SIG.
>>
>> Also not sure how much I can sign up for, but I have a significant amount of
>> container development and usage on Fedora at work and play.
>>
>> FAS:ttorling
>>>
>>> Dusty
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPTYH5DDCPYUCUCBZGGNOATXYHO5O2HG/
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OJDLS772CXLGX6VK2X3C7VPVUJKFXLB6/
>>
>
> cheers,
>

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

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

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-07-26 Thread Miro Hrončok


On 26.7.2018 14:23, Pavel Raiskup wrote:

On Saturday, June 16, 2018 1:38:43 AM CEST Jason L Tibbitts III wrote:

In order to prepare for the default to change in a future release, the
packaging guidelines have changed to require packages which install .py
files outside of the regular python library locations to do the
following:

* Set %_python_bytecompile_extra to 0 to disable the automatic
   compilation of the extra python files.
* Manually byte-compile those files which do actually need to be
   compiled.  This is done with the %py_byte_compile macro, which as a
   bonus requires that you specify which python version will be used for
   the compilation.


Wouldn't it be better if users simply started "manual" byte compilation
for certain paths with %py_byte_compile, so maintainers could forgot about
semantically pretty hard-to-understand %_python_bytecompile_extra macro?
Even if we plan to have the automatic byte compilation machinery enabled
for some time -- how does the machinery collide with explicit
%py_byte_compile?  Why do we have to turn it off?

I really dislike putting some temporarily macros into spec files...  Or
please read mi like that: There are two kinds of packages,

- first type has maintainers who plan to fix such issues promptly, and
   they would certainly appreciate if we turned
   '%_python_bytecompile_extra 0' system-wide sooner

- the second type of package has slower maintainers, and they will wait
   till they have to do the change ..., and in many cases, provenpackagers
   will have to step in with '%_python_bytecompile_extra 1' sooner or
   later, no matter when we change the default behavior

Please, either make sure that %py_byte_compile doesn't collide with the
default byte compilation machinery, or change the default right now (and
define the '%_python_bytecompile_extra 0' in batch).  The former is
preferred of course.


How does it collide exactly?

Note that there was a proposal on the FPC meeting (from tibbs IIRC) that 
we make `%_python_bytecompile_extra 0` the default and we push mass 
update with `%_python_bytecompile_extra 1` to packages that ship pyc/pyo 
files outside of Python directories. However that was not part of the 
approved change and it was to late to change it. We can propose it as a 
Fedora 30 change.


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

Re: Packages with compiled python files outside of /usr/lib*/python8

2018-07-26 Thread Pavel Raiskup

On Saturday, June 16, 2018 1:38:43 AM CEST Jason L Tibbitts III wrote:
> In order to prepare for the default to change in a future release, the
> packaging guidelines have changed to require packages which install .py
> files outside of the regular python library locations to do the
> following:
> 
> * Set %_python_bytecompile_extra to 0 to disable the automatic
>   compilation of the extra python files.
> * Manually byte-compile those files which do actually need to be
>   compiled.  This is done with the %py_byte_compile macro, which as a
>   bonus requires that you specify which python version will be used for
>   the compilation.

Wouldn't it be better if users simply started "manual" byte compilation
for certain paths with %py_byte_compile, so maintainers could forgot about
semantically pretty hard-to-understand %_python_bytecompile_extra macro?
Even if we plan to have the automatic byte compilation machinery enabled
for some time -- how does the machinery collide with explicit
%py_byte_compile?  Why do we have to turn it off?

I really dislike putting some temporarily macros into spec files...  Or
please read mi like that: There are two kinds of packages,

- first type has maintainers who plan to fix such issues promptly, and
  they would certainly appreciate if we turned
  '%_python_bytecompile_extra 0' system-wide sooner

- the second type of package has slower maintainers, and they will wait
  till they have to do the change ..., and in many cases, provenpackagers
  will have to step in with '%_python_bytecompile_extra 1' sooner or
  later, no matter when we change the default behavior

Please, either make sure that %py_byte_compile doesn't collide with the
default byte compilation machinery, or change the default right now (and
define the '%_python_bytecompile_extra 0' in batch).  The former is
preferred of course.

Pavel

> An example of the changes required for a package: 
> https://src.fedoraproject.org/rpms/python-uranium/pull-request/1#request_diff
> 
> I looked for .pyc files existing outside of /usr/lib(64)?/python\d\.\d
> in order to find packages which _may_ need changes in order to follow
> this guideline (and if not fixed may break in the future when the
> default for %_python_bytecompile_extra changes to 0).  Two lists follow.
> One lists packages and their maintainers; the other lists maintainers
> and their packages.  Both lists include comaintainers.
> 
> 
> Maintainers by package:
> 389-ds-base  mreynolds nhosoi nkinder rmeggins
> CGAL rineau
> FlightCrew   jwrdegoede sharkcz
> InsightToolkit   ignatenkobrain mrceresa sebp
> Macaulay2rdieter tremble
> PySolFC  orphan
> PyXB lef marcusk mmahut
> R-reticulate qulogic
> Singular pcpa rdieter
> accerciser   kalev
> adonthellnobrakal orphan
> ambari   coolsvap moceap orphan
> anaconda-realmd  stefw vpodzime
> anjuta   kalev limb moezroy rakesh
> anki chkr thomasfedb
> apitrace smani
> aqsiskwizart pmachata
> arm-none-eabi-gdborphan
> asterisk itamarjp jsmith russellb
> asymptotespot
> atomic   adimania baude dwalsh fkluknav lsm5 runcom walters
> audio-convert-modfirewing
> audit-viewer mitr
> autocloudkushal rtnpro sayanchowdhury
> avogadro sagitter
> backintime   cicku hannes raphgro
> bakefile filiperosset swt2c
> bibusalexlan ankursinha
> bkchem   limb
> bleachbitcicku nonamedotc
> blueberrybesser82 leigh123linux
> bluefish pghmcfc
> bodhibowlofeggs jcline lmacken
> boo  elsupergomez tpokorra
> boostdenisarnaud jwakely
> boothjpokorny
> bro  fab mildew
> bugyou   sayanchowdhury
> bugzilla eseyman itamarjp
> bup  tadej
> calamareskkofler mattia
> calibre  chkr heliocastro kevin nushio zbyszek
> cas  astokes
> catkin   rmattes thofmann
> ceph branto dachary dmick jdieter ke4qqq kkeithle ktdreyer 
> steve stingray
> ceph-ansible fcami ktdreyer
> cgit kevin praiskup tmz
> chameleonjortel
> check-mk averi
> cherokee pali
> chromium spot tpopela
> cinnamon-screensaver besser82 leigh123linux
> clangairlied daveisfera sbergmann siddharths tstellar
> clufter  jpokorny
> cobbler  jimi kwizart orion shenson
> comixmtasaka
> community-mysql  hhorak jdornak jstanek mschorm
> copr-backend clime dturecek frostyx msuchy
> copr-frontendclime dturecek frostyx msuchy
> coq  amdunn jjames
> cura churchyard
> cura-lulzbot churchyard spot
>

[Bug 1608871] New: perl-App-cpm-0.976 is available

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

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



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

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

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

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

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

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 7:10 PM Nicolas Mailhot 
wrote:

> Le 2018-07-26 07:20, Jens-Ulrik Petersen a écrit :
> > https://github.com/juhp/rpmbuild-order
> > It works by reading the BRs in spec files of the packages you want to
> > build, generating a graph of their interdependencies internally, from
> > which it outputs the packages in a build dependency order. If you have
> > a complete family of packages checked out, it can also output the
> > dependencies or reverse dependency of any of the packages.
>
> That's very nice.
>

Thanks

To be complete it should also be boostrap-aware  : do intermediary
> bootsrap builds whenever there is a cycle and one or more links in the
> cycle have bootstraping instructions in their spec.


I see: hmm cyclic deps are tricky...
Currently it gives up if there is a cycle in the graph.
Maybe an example would help me, if you have one.

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 6:53 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> On Thu, Jul 26, 2018 at 11:44 AM Jens-Ulrik Petersen 
> wrote:
>
>> On Thu, Jul 26, 2018 at 2:44 PM Igor Gnatenko <
>> ignatenkobr...@fedoraproject.org> wrote:
>>
>>> So… Since I have hard times understanding code, I will just ask
>>> questions here:
>>> * Does it use libsolv? I guess not.
>>> * Does it handle rich dependencies? I guess not.
>>>
>>
>> It only uses BuildRequires directly from .spec files.
>>
>
> So what will happen if I have bunch of spec files where I have
> BuildRequires: (foo >= 1.0.0 with foo < 2.0.0), will it work in that case?
>

Currently, it ignores bounds (for BRs).

* How does it know Provides if package is not built yet?
>>>
>>
>> I could add Provides too perhaps.
>>
>
> That doesn't help for packages which use dependency generators to generate
> Requires/Provides (99% of packages).
>

Do you have any examples?
99% is a lot... :)

Not sure if we have different use-cases in mind.

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

Interested to take ownership of liberation-narrow-fonts package

2018-07-26 Thread Vishal Vijayraghavan

Hi,

I wish to ownership of liberation-narrow-fonts package.

Enclosing package related information:
Package Name: liberation-narrow-fonts [1]
Branch : Master
Issue : 7660 [2]
Bugzilla Review Ticket : 1607713 [3]

[1] https://github.com/liberationfonts/liberation-sans-narrow
[2] https://pagure.io/releng/issue/7660
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1607713

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

Re: "Orphan packages will be retired if they remain orphaned for six weeks"

2018-07-26 Thread Till Maas

On Thu, Jul 26, 2018 at 10:38:33AM +0200, Miro Hrončok wrote:
> Is $subj [1] an automated or manual process? Shall I retire packages I've
> orphaned before more weeks or just wait?

Please retire the pkgs yourself. This is currently not happening. The
deprecation of pkgdb broke the script and the new setup did not support
orphaning on a per-branch level.

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

Re: [CoreOS] Starting a Container SIG

2018-07-26 Thread Jakub Cajka


- Original Message -
> From: "Clement Verna" 
> To: "atomic-devel" , "Development discussions 
> related to Fedora"
> , cor...@lists.fedoraproject.org
> Sent: Wednesday, July 25, 2018 7:09:39 PM
> Subject: [CoreOS] Starting a Container SIG
> 
> Greeting all,
> 
> The container effort in Fedora has until now been looked after by the
> Atomic WG, since this Working Group is now going to focus mostly on
> Fedora CoreOS, I propose to create a new container SIG to regroup
> people interested in the maintenance of application containers in
> Fedora.
> 
> This SIG would look after the container guidelines [0], the container
> review process [1] and also the release process and tooling.
> 
> Please Reply if you're interested with helping out making the
> Container story great in Fedora. If there is a good response, I will
> create a Container SIG wiki page, and I guess we can ask for
> container-devel mailing list for SIG discussions.
> 
> Regards,
> Clément
> 
> [0] - https://fedoraproject.org/wiki/Container:Guidelines
> [1] - https://fedoraproject.org/wiki/Container:Review_Process

Count me in. I would like to help and contribute especially in areas of 
Multi-Arch, Go and OpenShift Origin.

Also I would like to propose to meet up at this year Flock, if you are coming 
there.

What do you think?

JC

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 3:58 PM David Tardon  wrote:

> On Thu, 2018-07-26 at 14:20 +0900, Jens-Ulrik Petersen wrote:
> > You can try it from my copr repo:
> > https://copr.fedorainfracloud.org/coprs/petersen/rpmbuild-order
>
>   - nothing provides
> libHSexplicit-exception-0.1.9.2-6IciBnUHzJA6pzrqvgpq00-ghc8.2.2.so()(64bit)
> needed by rpmbuild-order-0.1-1.fc28.x86_64


Oops, I should have tested -- I meant to do static builds in copr.

I just pushed a new build to copr which should fix this - thanks for the
feedback.

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

rubygem-coderay license change

2018-07-26 Thread Jun Aruga

License of rubygem-coderay package was changed
from: LGPLv2+
to: MIT

https://src.fedoraproject.org/rpms/rubygem-coderay/c/24c8b248c94fb8f0c4173e59bc8eb17f291c767e?branch=master

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

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread Nicolas Mailhot


Le 2018-07-26 07:20, Jens-Ulrik Petersen a écrit :

Hi


https://github.com/juhp/rpmbuild-order
It works by reading the BRs in spec files of the packages you want to
build, generating a graph of their interdependencies internally, from
which it outputs the packages in a build dependency order. If you have
a complete family of packages checked out, it can also output the
dependencies or reverse dependency of any of the packages.


That's very nice.

To be complete it should also be boostrap-aware  : do intermediary 
bootsrap builds whenever there is a cycle and one or more links in the 
cycle have bootstraping instructions in their spec.


Regards,

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 11:44 AM Jens-Ulrik Petersen 
wrote:

> On Thu, Jul 26, 2018 at 2:44 PM Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
>
>> So… Since I have hard times understanding code, I will just ask questions
>> here:
>> * Does it use libsolv? I guess not.
>> * Does it handle rich dependencies? I guess not.
>>
>
> It only uses BuildRequires directly from .spec files.
>

So what will happen if I have bunch of spec files where I have
BuildRequires: (foo >= 1.0.0 with foo < 2.0.0), will it work in that case?


> * How does it know Provides if package is not built yet?
>>
>
> I could add Provides too perhaps.
>

That doesn't help for packages which use dependency generators to generate
Requires/Provides (99% of packages).

* How does it handle conditions in specs?
>>
>
> It leaves that to rpmspec.
>
>
>> Note that mizdebsk already had such tool for quite some time.
>>
>
> Do you have a reference?
>

CCing Mikolaj.


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

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

[Bug 1606813] perl-XML-Xerces: FTBFS in Fedora rawhide

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

Igor Gnatenko  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2018-07-26 05:38:31



--- Comment #4 from Igor Gnatenko  ---
There has been at least one successfull build after mass rebuild.

perl-XML-Xerces-2.7.0_0-42.fc29:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1130812

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

Re: tool to order packages by build dependencies (rpmbuild-order)

On Thu, Jul 26, 2018 at 2:44 PM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> So… Since I have hard times understanding code, I will just ask questions
> here:
> * Does it use libsolv? I guess not.
> * Does it handle rich dependencies? I guess not.
>

It only uses BuildRequires directly from .spec files.

* How does it know Provides if package is not built yet?
>

I could add Provides too perhaps.

* How does it handle conditions in specs?
>

It leaves that to rpmspec.


> Note that mizdebsk already had such tool for quite some time.
>

Do you have a reference?

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

[rpms/perl-XML-Xerces] New Commits To "rpms/perl-XML-Xerces" (master)

2018-07-26 Thread pagure


The following commits were pushed to the repo rpms/perl-XML-Xerces on branch
master, which you are following:
ee59f1c6920689b5a35959a822afea0352192fecXavier BachelotFix FTBFS#1606813



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-XML-Xerces/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BRATEEGJXU2JSLTBAGYHLZBFMH7XA27C/

"Orphan packages will be retired if they remain orphaned for six weeks"

2018-07-26 Thread Miro Hrončok

Is $subj [1] an automated or manual process? Shall I retire packages 
I've orphaned before more weeks or just wait?


[1] 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

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

[Bug 1399506] perl-File-Find-Rule-Age-0.302-5.fc26 FTBFS randomly

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



--- Comment #4 from Tim Orling  ---
https://apps.fedoraproject.org/koschei/package/perl-File-Find-Rule-Age?

Two failures.

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

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread Robin Lee

On Thu, Jul 26, 2018 at 1:21 PM Jens-Ulrik Petersen  wrote:
>
> Hi,
>
> This is an early announcement about a tool called 'rpmbuild-order' I made to 
> sort RPM-based packages in build dependency order. I am not sure if such a 
> tool exists already?  Certainly some tools like `mockchain` can already order 
> builds in this way, but I don't know of such a standalone utility.
>
> https://github.com/juhp/rpmbuild-order
>
> It works by reading the BRs in spec files of the packages you want to build, 
> generating a graph of their interdependencies internally, from which it 
> outputs the packages in a build dependency order. If you have a complete 
> family of packages checked out, it can also output the dependencies or 
> reverse dependency of any of the packages.
>
> You can try it from my copr repo:
> https://copr.fedorainfracloud.org/coprs/petersen/rpmbuild-order
>
> Let me know if you if it works for you or you find any problems.
> I have tested it lightly a set of about 400 packages. There are probably 
> optimization that could be made.  I feel it would be good to do mass-rebuilds 
> for example in dependency order perhaps.
>
> Also, I am planning to add this package to Fedora: before doing that I am 
> open to suggestions for alternative names for the tool - I couldn't really 
> think of a better one..
>
> Cheers, Jens
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ECWHXZHDJ5UEPTLRHGYYGN65EW7Y6GRU/

I use a tool with similar function named Planex[1]

[1] https://github.com/xenserver/planex

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

[Bug 1598971] perl-Log-Any-1.706 is available

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

Tim Orling  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Tim Orling  ---
Updated 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NWGOU2F7MI2J2J2IRYKQLHFH53IPTAZ7/

[Bug 1589408] perl-Unix-Statgrab-0.112 is available

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

Tim Orling  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Tim Orling  ---
Updated 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/T5KPMJ4FCXPO5SZHLAFDG276KWKRSN4H/

Re: tool to order packages by build dependencies (rpmbuild-order)

2018-07-26 Thread David Tardon

On Thu, 2018-07-26 at 14:20 +0900, Jens-Ulrik Petersen wrote:
> You can try it from my copr repo: 
> https://copr.fedorainfracloud.org/coprs/petersen/rpmbuild-order

Error: 
 Problem: conflicting requests
  - nothing provides 
libHSexplicit-exception-0.1.9.2-6IciBnUHzJA6pzrqvgpq00-ghc8.2.2.so()(64bit) 
needed by rpmbuild-order-0.1-1.fc28.x86_64

Tried on F-27 and F-28, with the same result.

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

[Bug 1399506] perl-File-Find-Rule-Age-0.302-5.fc26 FTBFS randomly

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

Tim Orling  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #3 from Tim Orling  ---
Petr/Jitka have we seen any recent FTBFS on this package (no failures in last
14 builds on koji)? If so, we can either skip the tests that are failing or
retire it. If not, perhaps infrastructure changes (or other) have fixed an
underlying issue. I have no reason to believe upstream will fix the tests.

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

Re: [fesco] Updated FTBFS package policy