[EPEL-devel] Re: libbibutils 6.6 update with soname bump in epel7

[Jens-Ulrik Petersen]

(adding epel-devel too)

Vasiliy, I have decoupled ghc-hs-bibutils from bibutils in epel7 now too,
so you shouldn't need to worry about it anymore.

Thanks for maintaining Fedora bibutils!

Jens

On Wed, Jul 25, 2018 at 8:00 PM Vascom  wrote:

> Jens-Ulrik,
> Add me as co-maintainer to this packages too please.
>
> --
> Best regards,
> Vasiliy Glazov
>
> ср, 25 июл. 2018 г. в 12:40, Vascom :
>
>> Hi,
>> I am updating libbibutils to 6.6. It has soname bump from 5 to 6 in EPEL
>> 7 repo.
>>
>> Need update dependent packages:
>> ghc-hs-bibutils
>> pandoc-citeproc
>>
>> As I understand rebuild not needed for rawhide/F29?
>>
>> --
>> Best regards,
>> Vasiliy Glazov
>>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org/message/G4MM7QK3QWBFSEPF6IA2WDBUTV5C6IZ2/

Re: libbibutils 6.6 update with soname bump in epel7

[Jens-Ulrik Petersen]

(adding epel-devel too)

Vasiliy, I have decoupled ghc-hs-bibutils from bibutils in epel7 now too,
so you shouldn't need to worry about it anymore.

Thanks for maintaining Fedora bibutils!

Jens

On Wed, Jul 25, 2018 at 8:00 PM Vascom  wrote:

> Jens-Ulrik,
> Add me as co-maintainer to this packages too please.
>
> --
> Best regards,
> Vasiliy Glazov
>
> ср, 25 июл. 2018 г. в 12:40, Vascom :
>
>> Hi,
>> I am updating libbibutils to 6.6. It has soname bump from 5 to 6 in EPEL
>> 7 repo.
>>
>> Need update dependent packages:
>> ghc-hs-bibutils
>> pandoc-citeproc
>>
>> As I understand rebuild not needed for rawhide/F29?
>>
>> --
>> Best regards,
>> Vasiliy Glazov
>>
>
___
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/G4MM7QK3QWBFSEPF6IA2WDBUTV5C6IZ2/

Re: libbibutils 6.6 update with soname bump in epel7

[Jens-Ulrik Petersen]

Sorry for the late reply - I only noticed this mail yesterday.

On Wed, Jul 25, 2018 at 6:40 PM Vascom  wrote:

> Hi,
> I am updating libbibutils to 6.6. It has soname bump from 5 to 6 in EPEL 7
> repo.
>

Yeah unfortunately libbibutils bumps soname every minor release...


> Need update dependent packages:
> ghc-hs-bibutils
> pandoc-citeproc
>

That's right - for the above reason I started using the bundled bibutils in
hs-bibutils: so they have been decoupled for some time in Fedora.

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

[Bug 1609443] New: perl-Net-Netmask-1.9104 is available

[bugzilla]

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

Bug ID: 1609443
   Summary: perl-Net-Netmask-1.9104 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-Netmask
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, maria...@tuxette.fr,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.9104
Current version/release in rawhide: 1.9103-3.fc29
URL: http://search.cpan.org/dist/Net-Netmask/

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

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

Re: Fedora Rawhide-20180726.n.2 compose check report

[Adam Williamson]

On Fri, 2018-07-27 at 10:45 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 82/138 (x86_64), 23/24 (i386), 1/2 (arm)

This compose isn't actually quite as bad as all that, anaconda changed
the hub design and the 'timbuktu warning', which broke all the openQA
tests. I'm updating the needles and re-running tests now.

There *is* one significant new bug that breaks all Server package set
installs:
https://bugzilla.redhat.com/show_bug.cgi?id=1609393
-- 
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/PCU3U72WZ2F3XJ5VQVOLL6CPG2KLM7PT/

Re: dokuwiki packagers unresponsive

[Sérgio Basto]

On Sat, 2018-07-28 at 00:14 +0200, Robert-André Mauchin wrote:
> On vendredi 27 juillet 2018 23:50:50 CEST Sérgio Basto wrote:
> > On Fri, 2018-07-27 at 23:09 +0200, Peter 'Pessoft' Kolínek wrote:
> > 
> > > On 2018-07-27 03:51, Sérgio Basto wrote:
> > > 
> > > > 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 .
> > > 
> > > 
> > > I've created pull request for his other package (ike) a week ago.
> > > Also 
> > > tried email (without reply) and reported some security bugs
> > > against 
> > > dokuwiki, but without response in BZ.
> > > Which communication method you used to get a response?
> > 
> > 
> > I only got from him, one short email that him give me commit access
> > :)
> > IIRC.
> 
>  
> > How do I request commit access to a dist-git repo?
> > [1]
> > 
> > Email the packagename-ow...@fedoraproject.org alias asking to be
> > given
> > access, or file a bugzilla bug on the package asking for access. 
> 
>  
> > [1]
> > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#H
> > ow_do_I_r
> > equest_commit_access_to_a_dist-git_repo.3F
> 
>  
> Shouldn't he be made member of the packager group first?

Yes , but if you not in the packager group there is no point on open an
unresponsive process ... . I thought that was the case. 
So you are asking for a proven packager ? that merge yours pull request
or something like that ? I think I can't help you.

Best regards 

> ___
> 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_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/SSIMQEJCQCN4C6IEHJKWKGI7CQUUEXUA/
-- 
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/37RXZQQ7KB2G76H6AWRIKD5CZT7KVJZZ/

Re: dokuwiki packagers unresponsive

[Robert-André Mauchin]

On vendredi 27 juillet 2018 23:50:50 CEST Sérgio Basto wrote:
> On Fri, 2018-07-27 at 23:09 +0200, Peter 'Pessoft' Kolínek wrote:
> 
> > On 2018-07-27 03:51, Sérgio Basto wrote:
> > 
> > > 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 .
> > 
> > 
> > I've created pull request for his other package (ike) a week ago.
> > Also 
> > tried email (without reply) and reported some security bugs against 
> > dokuwiki, but without response in BZ.
> > Which communication method you used to get a response?
> 
> 
> I only got from him, one short email that him give me commit access :)
> IIRC.
 
> How do I request commit access to a dist-git repo?
> [1]
> 
> Email the packagename-ow...@fedoraproject.org alias asking to be given
> access, or file a bugzilla bug on the package asking for access. 
 
> [1]
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_r
> equest_commit_access_to_a_dist-git_repo.3F
 
Shouldn't he be made member of the packager group first?

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

Re: dokuwiki packagers unresponsive

[Sérgio Basto]

On Fri, 2018-07-27 at 23:09 +0200, Peter 'Pessoft' Kolínek wrote:
> On 2018-07-27 03:51, Sérgio Basto wrote:
> > 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 .
> 
> I've created pull request for his other package (ike) a week ago.
> Also 
> tried email (without reply) and reported some security bugs against 
> dokuwiki, but without response in BZ.
> Which communication method you used to get a response?

I only got from him, one short email that him give me commit access :) IIRC.

How do I request commit access to a dist-git repo?
[1]

Email the packagename-ow...@fedoraproject.org alias asking to be given access, 
or file a bugzilla bug on the package asking for access. 

[1]
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_request_commit_access_to_a_dist-git_repo.3F

> -- 
> 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_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/U4RXTSPFIZGBE25I5NGNC54QJ43AEXPB/
-- 
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/IHJYQ7QY6RR4GZNMY4OYQLWMCDUJFU3Y/

Re: What to BuildRequire for libstdc++.so __cxa_demangle?

[Mark Wielaard]

On Sat, 2018-07-21 at 18:52 +0200, Mark Wielaard wrote:
> The elfutils tools can demangle C++ symbols through the standard
> _cxa_demangle interface. The elfutils tools are written in C and
> so simply link with -lstdc++ to get access to __cxa_demangle.
> 
> There is a BuildRequires: libstdc++-devel in the elfutils.spec.
> But it looks like that isn't enough anymore to pull in libstdc++.so
> to build against.
> 
> It looks like that is provided through a symlink in gcc-c++.
> Should the elfutils.spec just BuildRequires: gcc-c++ instead of
> libstdc++-devel? Or is this a packaging/requires issue somewhere
> else?

Just in case anybody else is wondering what the correct answer is.
Whether libstdc++.so is provided by by gcc-c++ or libstdc++-devel is
architecture dependent. libstdc++-devel is there for multilib reasons.
You should just depend on gcc-c++ if you need to link against
libstdc++.so. Even if you don't use g++ to link against it. gcc-c++
requires libstdc++-devel.

Cheers,

Mark
___
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/ZK47BQOLXNLPNRYU6YTTOB246FXWEQK6/

Re: dokuwiki packagers unresponsive

[Peter 'Pessoft' Kolínek]

On 2018-07-27 03:51, Sérgio Basto wrote:

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 .


I've created pull request for his other package (ike) a week ago. Also 
tried email (without reply) and reported some security bugs against 
dokuwiki, but without response in BZ.

Which communication method you used to get a response?

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

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

[DJ Delorie]

Jan Kratochvil  writes:
> So why glibc greated an N+1 allocator (by DJ Delorie) instead of just
> importing/using tcmalloc (which is license-compatible with glibc)?

I didn't create an N+1 allocator.  We're still using the Doug Lea
allocator from ancient times.  My recent work added a relatively minor
bit of code that improved performance (which makes alternate allocators
less of a win, and sometimes worse), and we've been working on security
bugs all along, but it's not a "new" allocator by any stretch of the
imagination.

As for replacing it, I/we are not against that in principle, although
that's a glibc topic and not a Fedora topic.  However, keep in mind that
glibc's allocator has been tested against a HUGE collection of software,
compared to other mallocs that might have a much smaller testing
breadth.  To replace glibc's allocator would require a huge testing
effort, and careful consideration of EVERY glibc-specific feature, hack,
hook, and historical divot that Fedora apps might rely on (I'm looking
at you, Emacs).

So if you can prove that some alternate allocator can serve as a
*general* purpose *system-wide* default allocator, and has better
performance (speed, RSS, VSZ, etc) all the time, for all apps in Fedora
(and other Linux distros, and Hurd, etc) that use it, with fewer
security bugs and no missing features... yeah, we're listening.
Patches welcome :-)

I will repeat that this is not really a Fedora topic, and is independent
of the "alternate mallocs in Fedora" topic, which exists for a different
reason.  I'm posting this purely for clarification.
___
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/Y4SE4ODPMRGSZRSEXHE3QBZIXARPICL2/

Re: Golang SIG for Fedora

[Robert-André Mauchin]

On vendredi 27 juillet 2018 15:28:12 CEST Jakub Cajka wrote:
> Hello,
> 
>   it seems that lately there has been more people maintaining Go package in
> the Fedora. I would like to propose to join up and form Go SIG so we could
> better co-ordinate and collaborate on the packaging issues and general
> developer experience.
 
>   There are few big outstanding issues that needs to be solved that need
> more than individual work, most notably the Go packaging guidelines and
> tooling. I think that should be one of the first tasks for the SIG.
 
>   To introduce myself. I'm for some while golang (co-)maintainer and
> recently started co-maintaining origin package. I'm mostly interested in
> the compiler and developer experience.
 
>   Please reply if you would like to participate. 
> 
> JC
> 
>   PS: Also I will be at Flock this year and would like to meet up with
> anyone interested there.
 
> 

I maintain around 130 Golang packages and I'd be interested in participating 
in a SIG.


Best regards,

Robert-André



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

Fedora testing-20180727.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Fedora updates-20180727.0 compose check report

[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: 
System load changed from 0.10 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/260524#downloads
Current test data: https://openqa.fedoraproject.org/tests/261185#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/OZYXRZSM2JZV7USAUAS3U2O7QR2WARU2/

Re: [atomic-devel] Starting a Container SIG

[Jeff Ligon]

I too would like to be a part of this but I’m not sure how much I’d be able
to help.

On Fri, Jul 27, 2018 at 1:29 PM Owen Taylor  wrote:

> I'm interested in participating with a special interest in Flatpaks - the
> other type of Fedora container ;-) - I want to keep things aligned as much
> as possible. And also from the perspective of using containers for
> development within Fedora Workstation.
>
> I can contribute a certain familiarity with OCI images, OSBS, the image
> registry, etc.
>
> Owen
>
>
> On Wed, Jul 25, 2018 at 1: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.
>>
>> Regards,
>> Clément
>>
>> [0] - https://fedoraproject.org/wiki/Container:Guidelines
>> [1] - https://fedoraproject.org/wiki/Container:Review_Process
>>
>>
> --

JEFF LIGON

MANAGER, SOFTWARE ENGINEERING

Red Hat RDU 

jli...@redhat.com T: 919.301.3170  M:
919.522.2698  gpg key


TRIED. TESTED. TRUSTED. 
___
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/NNMHBXO4BIRCQIWGSYCOGTWMBJO5MPIJ/

Re: [atomic-devel] Starting a Container SIG

[Owen Taylor]

I'm interested in participating with a special interest in Flatpaks - the
other type of Fedora container ;-) - I want to keep things aligned as much
as possible. And also from the perspective of using containers for
development within Fedora Workstation.

I can contribute a certain familiarity with OCI images, OSBS, the image
registry, etc.

Owen


On Wed, Jul 25, 2018 at 1: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.
>
> 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/IH7ETUX3VHOP3MSE4WMSYIAXMICRJT5C/

[Bug 1608617] perl-Monitoring-Plugin-0.40 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

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

[Owen Taylor]

On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer  wrote:

> On 07/27/2018 03:33 PM, John Reiser wrote:The key principle is that
> sizeof(foo) must be the stride of an array of foo,
>
> and the array must guarantee alignment of each element in the array.
>>
>
> Why do you think that?  If some documentation claims this is the case for
> individual objects, we need to fix it.


struct sizes *do* have this property - they are rounded up so that arrays
have the correct alignment.
But that certainly doesn't imply that malloc(7) is allowed to give you
unaligned memory.

Owen
___
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/PVZ3KXKN2IQGGI2DI2KQSJWZOZPYIIRV/

Rust SIG

[Igor Gnatenko]

Hello,

it seems to be a week of SIG announcements, so why shouldn't I share that
we also have Rust SIG .

At this point we have over 400 crates packaged, few applications like
ripgrep, tokei, stratisd and more.

IRC: #fedora-rust
ML: r...@lists.fedoraproject.org

Feel free to stop by and don't hesitate to ping me ;)

P.S. I'm going to Flock this year, so let me know if you would like to meet
and work on.
-- 

-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/35T2HEEPFBX75Q4AQLEYBSWADBGIC6TW/

Re: Introduction

[Przemek Klosowski]

On 07/27/2018 05:31 AM, Jeff Mitchell wrote:
Hi I'm Jeff Mitchell and I volunteer for 2 charities in my city 
(currently unemployed).

Welcome! Props for helping others while you can.
I've frequently used Linux since 2007 and I'd like to become a Fedora 
package maintainer. I have two desktop PCs and I have Fedora 28 XFCE 
on my older system - I use this system to experiment on. I've read 
most of the guides on maintaining packages, now I just need a package 
to maintain...
You might consider becoming a co-packager for an existing package, if 
you don't already have an existing candidate package that you personally 
like.
As you self-describe as a hands-on guy, perhaps you'll like the 
packaging tutorial I wrote a while ago

https://docs.fedoraproject.org/quick-docs/en-US/create-hello-world-rpm.html
Come to think about it, this may be up for an update---so please pitch 
in if you see something to add. In particular, there's no mention of 
localization in there, so please research and add something if you feel 
so inclined.
Similarly, I have a Vox Valvetronix guitar amplifier and after 6 years 
I finally discovered that you can only get good tones if you put the 
master volume up really high (master volume drives the tube). I wish I 
had a musician friend who could have told me that when I bought it! 
Nothing beats proper advice from someone who knows what they're doing.

Hey, does your master volume go to 11 :)?
___
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/MLTZ73I6EJYSPBLYGQSOB4FXXYYIOX6F/

[Bug 1406558] build perl-Coro for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Coro-6.514-4.el7
 Resolution|--- |ERRATA
Last Closed|2016-12-25 12:58:58 |2018-07-27 10:31:24



--- Comment #9 from Fedora Update System  ---
perl-Coro-6.514-4.el7 has been pushed to the Fedora EPEL 7 stable repository.
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/VWJCZLANWMLR4SDPMF6ACC6BTGCRW7WZ/

Re: Golang SIG for Fedora

[Ricardo Martinelli Oliveira]

+1, I started looking on packaging Go libraries and looking for
recommendations. I saw [1] but as this seems more a draft (so a WIP
document) it would be good if we have specific group to discuss best
practices, package reviews, etc.



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

On Fri, Jul 27, 2018 at 10:28 AM, Jakub Cajka  wrote:
> Hello,
>
>   it seems that lately there has been more people maintaining Go package in 
> the Fedora. I would like to propose to join up and form Go SIG so we could 
> better co-ordinate and collaborate on the packaging issues and general 
> developer experience.
>
>   There are few big outstanding issues that needs to be solved that need more 
> than individual work, most notably the Go packaging guidelines and tooling. I 
> think that should be one of the first tasks for the SIG.
>
>   To introduce myself. I'm for some while golang (co-)maintainer and recently 
> started co-maintaining origin package. I'm mostly interested in the compiler 
> and developer experience.
>
>   Please reply if you would like to participate.
>
> JC
>
>   PS: Also I will be at Flock this year and would like to meet up with anyone 
> interested there.
>
>
> ___
> 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/XVYPQH2WNMT4X3NYIKYPTRFOUITWADC7/
___
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/SWB2Z47JTQEMFB2SB4K252MUGCK5IUFU/

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

[Florian Weimer]

On 07/27/2018 03:33 PM, John Reiser wrote:

On 07/27/2018 08:21 UTC, Florian Weimer wrote:

On 07/27/2018 05:10 AM, John Reiser wrote:

Always requiring 16-byte alignment on x86_64 can waste too much space
due to internal fragmentation.  The rule should be:
    The required alignment is at least  min(16, max_p2_divisor_of_size)
    where the second argument max_p2_divisor_of_size is the maximum 
power of 2

    that divides the requested size [when 0!= size].
Thus a request for 6 bytes may be satisfied by a block whose address is
divisible by 2.


But this rule is wrong.  Consider this:

struct string
{
   size_t length;
   char data[];
};

To allocate a one-byte string, malloc would be called with an argument 
of sizeof (size_t) + 1.  Your rule gives alignment 1, but in reality, 
alignment 4 or 8 is required.


(Flexible struct members are not strictly required to implement this, 
of course, so it's not a new problem at all.)


As written, sizeof(struct string) is 4 on a 32-bit machine, or 8 on a 
64-bit machine.

Actually storing something in data[] requires more bytes; the question is,
"How many more?".  The answer is round_up(size_for_data, 
sizeof(string.length))

in order to guarantee alignment for string.length;


That's simply not true for top-level allocations which are not part of 
an array.


The key principle is that sizeof(foo) must be the stride of an array of 
foo,

and the array must guarantee alignment of each element in the array.


Why do you think that?  If some documentation claims this is the case 
for individual objects, we need to fix it.


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

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

[John Reiser]

On 07/27/2018 08:21 UTC, Florian Weimer wrote:

On 07/27/2018 05:10 AM, John Reiser wrote:

Always requiring 16-byte alignment on x86_64 can waste too much space
due to internal fragmentation.  The rule should be:
    The required alignment is at least  min(16, max_p2_divisor_of_size)
    where the second argument max_p2_divisor_of_size is the maximum power of 2
    that divides the requested size [when 0!= size].
Thus a request for 6 bytes may be satisfied by a block whose address is
divisible by 2.


But this rule is wrong.  Consider this:

struct string
{
   size_t length;
   char data[];
};

To allocate a one-byte string, malloc would be called with an argument of 
sizeof (size_t) + 1.  Your rule gives alignment 1, but in reality, alignment 4 
or 8 is required.

(Flexible struct members are not strictly required to implement this, of 
course, so it's not a new problem at all.)


As written, sizeof(struct string) is 4 on a 32-bit machine, or 8 on a 64-bit 
machine.
Actually storing something in data[] requires more bytes; the question is,
"How many more?".  The answer is round_up(size_for_data, sizeof(string.length))
in order to guarantee alignment for string.length; and this calculation
should be done by the caller of malloc(), not inside malloc().
The key principle is that sizeof(foo) must be the stride of an array of foo,
and the array must guarantee alignment of each element in the array.

For illustration: if data[] is to store 5 bytes, then that is equivalent to
struct string5
{
size_t length;
char data[5];
};
and sizeof(struct string5) is 12 on a 32-bit machine, or 16 ln a 64-bit machine.
So 12, or 16, should be the argument to malloc().
___
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/5OZHNIM2Y4S2R65LND6Z46CFQATJM2FU/

Golang SIG for Fedora

[Jakub Cajka]

Hello,

  it seems that lately there has been more people maintaining Go package in the 
Fedora. I would like to propose to join up and form Go SIG so we could better 
co-ordinate and collaborate on the packaging issues and general developer 
experience.

  There are few big outstanding issues that needs to be solved that need more 
than individual work, most notably the Go packaging guidelines and tooling. I 
think that should be one of the first tasks for the SIG.

  To introduce myself. I'm for some while golang (co-)maintainer and recently 
started co-maintaining origin package. I'm mostly interested in the compiler 
and developer experience.

  Please reply if you would like to participate. 

JC

  PS: Also I will be at Flock this year and would like to meet up with anyone 
interested there.
  
  
___
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/XVYPQH2WNMT4X3NYIKYPTRFOUITWADC7/

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

[Pavel Raiskup]

On Saturday, June 16, 2018 1:38:43 AM CEST Jason L Tibbitts III wrote:
> cgit kevin praiskup tmz
> ...
> praiskup   cgit

There are two *.py files mistakenly byte-compiled (scripts used as
filters), but it's OK to wait till
%_python_bytecompile_extra becomes '0' system-wide.

Pavel


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

[Bug 1609256] New: perl-CPAN-Perl-Releases-3.72 is available

[bugzilla]

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

Bug ID: 1609256
   Summary: perl-CPAN-Perl-Releases-3.72 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 3.72
Current version/release in rawhide: 3.70-1.fc29
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

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

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

Non responsive maintainer - Wolnei Cândido Tomazelli Junior

[Vascom]

Hello!

According Non-responsive Maintainer Policy I'm asking the maintainer
to respond and resolve FTBFS issues with package kio-gdrive.

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

--
Best regards,
Vasiliy Glazov
___
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/NPSIU34FJX2KA3XVE2DG4APETG53BF5W/

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

[Miro Hrončok]

On 27.7.2018 10:51, Pavel Raiskup wrote:

On Friday, July 27, 2018 10:01:42 AM CEST Miro Hrončok wrote:

On 27.7.2018 07:55, Pavel Raiskup wrote:

On Thursday, July 26, 2018 2:29:17 PM CEST Miro Hrončok wrote:

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?


I'm not sure.  Can I simply use %py_byte_compile without
'%_python_bytecompile_extra 0'?


You CAN use %py_byte_compile anywhere. With or without
'%_python_bytecompile_extra 0'.

You MUST use '%_python_bytecompile_extra 0' if you have /usr/bin/python
in buildroot and you DON'T want it to be used to bytecompile Python
files outside of Python dirs.


So from your note it looks like the /usr/bin/python can cause troubles?

Consider:
   - I have /usr/bin/python in buildroot mistakenly
   - I do some explicit %py_byte_compile some files in %buildroot in
 "extra" dirs, by either python3 only or both python{2,3}
   - I don't explicitly set '%_python_bytecompile_extra 0'

Then, brp-python-bytecompile goes and recompiles (by /bin/python) those
files, right?  But where's the problem?  Python2 and Python3 store the
byte compiled files to different directories...   (yes,
brp-python-bytecompile could avoid recompiling files which are alrady
compiled, but that's detail).

Yes, I see a very low-prio issue -> if the package is Python 3 only, it
can get inadvertently installed python2 '*.pyc' files.  But that's only
small issue (size of RPM) and it's temporary issue (we plan to turn
%_python_bytecompile_extra to 0 system wide soon).


I can confirm everything you've said.

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

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

[Jan Kratochvil]

On Thu, 26 Jul 2018 21:14:14 +0200, Carlos O'Donell wrote:
> Bug 1430223 - In some conditions, tcmalloc memalign will segfault
> https://bugzilla.redhat.com/show_bug.cgi?id=1430223

It looks as a tcmalloc bug which could be fixed; it also has been probably
fixed in the meantime as stated there.


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

So why glibc greated an N+1 allocator (by DJ Delorie) instead of just
importing/using tcmalloc (which is license-compatible with glibc)?


On Thu, 26 Jul 2018 22:34:09 +0200, Florian Weimer wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1237260
 = gperftools: tcmalloc breaks ABI on x86_64

You (Florian Weimer) have not provided any countercase (*) why small
allocations under alignment size (16 bytes) still should be aligned to 16 bytes.
This is why tcmalloc upstream closed it:
https://github.com/gperftools/gperftools/issues/724

(*) https://github.com/gperftools/gperftools/issues/724#issuecomment-147369562
I do not see how that can be useful in practice, do you?


> https://bugzilla.redhat.com/show_bug.cgi?id=1303323
 = tcsh: interposed malloc is not ABI-compliant due to lack of alignment

This was a bug in tcsh custom allocator. (That is unrelated to tcmalloc.)

 
> http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

Looking at its source it looks to me mozjemalloc still in use by Fedora
Firefox still has only 8-byte alignment.


Jan
___
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/YNZXINTXTMQ4SGFU6LT5A4FDQ4ANXGLS/

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

[Nicolas Mailhot]

Le jeudi 26 juillet 2018 à 21:01 +0900, Jens-Ulrik Petersen a écrit :
> On Thu, Jul 26, 2018 at 7:10 PM Nicolas Mailhot <
> 

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

Basically if there is a cycle and the packager anticipated it one or
more specs of the cycle will include bootstrap-specific conditionals as
per
https://fedoraproject.org/wiki/Packaging:Guidelines#Bootstrapping

When the conditional is activated the package builds with reduced
functionality and reduced requirements, breaking the cycle

Of course once you've built the packages depending on the boostrapped
spec you need to rebuild it in normal (full) mode)


You have an exemple of the result here
https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging/builds/

There are quite a lot of cycles requiring bootstraping there. The devel
builds are probably obsolete by now, but I doubt the el7 situation
changed much since

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/735WI6Y7XK5MTUI7TYJ5ZHAU6HZJO5VJ/

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

[Jan Kratochvil]

On Thu, 26 Jul 2018 17:43:06 +0200, Daniel P. Berrangé wrote:
> # 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

firefox on x86* is using its internal fork of jemalloc (mozjemalloc).


Jan
___
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/IQ474EQXGAHPYRPPBOTLRAUVREQUKA2D/

Fedora Rawhide-20180726.n.2 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 260699  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/260699
ID: 260700  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260700
ID: 260701  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/260701
ID: 260702  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260702
ID: 260712  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/260712
ID: 260713  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/260713
ID: 260720  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/260720
ID: 260724  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/260724
ID: 260725  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260725
ID: 260727  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/260727
ID: 260728  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260728
ID: 260739  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/260739
ID: 260740  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/260740
ID: 260741  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/260741
ID: 260742  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260742
ID: 260746  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/260746
ID: 260747  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260747
ID: 260762  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/260762
ID: 260763  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260763
ID: 260764  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default_upload
URL: https://openqa.fedoraproject.org/tests/260764
ID: 260765  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
install_default@uefi
URL: https://openqa.fedoraproject.org/tests/260765
ID: 260766  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/260766
ID: 260773  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/260773
ID: 260774  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/260774
ID: 260775  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/260775
ID: 260776  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/260776
ID: 260777  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/260777
ID: 260782  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/260782
ID: 260785  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/260785
ID: 260786  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/260786
ID: 260787  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/260787
ID: 260789  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/260789
ID: 260790  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/260790
ID: 260791  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/260791
ID: 260792  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/260792
ID: 260793  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/260793
ID: 260794  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/260794
ID: 260795  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/260795
ID: 260796  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/260796
ID: 260797  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/260797
ID: 260798  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/260798
ID: 260799  

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

[Florian Weimer]

On 07/26/2018 06:03 PM, 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.


An absolute ban strikes me as overly broad.  However, especially for 
shared objects (such as libruby), the implications should be clear: it 
is easy to LD_PRELOAD a different malloc, but if the library is linked 
against glibc malloc, jemalloc, and then you want to preload tcmalloc 
because it helps with your workload, you might run into problems (and if 
it's just excessive use of TLS data, most of it unused).



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.


Sure, this is why I mentioned APR pools and Boehm GC—if the APIs a 
different, then we obviously can't require porting to system malloc.


If upstream bundles a custom malloc, especially one of the well-known 
ones separately packaged in Fedora, some work is required anyway because 
the bundled version cannot be installed in a system-wide location, and 
RPM provides for it must be suppressed.  (See the upstream varnish 
packages for an example of an accidental system-wide jemalloc installation.)


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

[Bug 1609221] New: License 'public domain' is not valid

[bugzilla]

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

Bug ID: 1609221
   Summary: License 'public domain' is not valid
   Product: Fedora
   Version: rawhide
 Component: perl-DBIx-Simple
  Assignee: jples...@redhat.com
  Reporter: dave.olstho...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Description of problem:
RPM spec file describes the licence as "public domain" while the real licence
specifies the following list to choose from
https://opensource.org/licenses/alphabetical. This list does not include public
domain.

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

[Bug 1609221] License 'public domain' is not valid

[bugzilla]

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

Dave Olsthoorn  changed:

   What|Removed |Added

 Blocks||182235 (FE-Legal)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=182235
[Bug 182235] Fedora Legal Tracker
-- 
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/J5XRRRYFN2JNEFGBW2VVG2KNCD4ZEXZX/

Introduction

[Jeff Mitchell]

Hi I'm Jeff Mitchell and I volunteer for 2 charities in my city (currently 
unemployed). I've frequently used Linux since 2007 and I'd like to become a 
Fedora package maintainer. I have two desktop PCs and I have Fedora 28 XFCE on 
my older system - I use this system to experiment on. I've read most of the 
guides on maintaining packages, now I just need a package to maintain. Last 
year I failed a programming course and I'm not sure if I ever want to do 
programming as a job. I'd rather work on Fedora packages and get into 
programming as a hobby, but working as a full-time programmer doesn't appeal to 
me. I know a lot of guys who work as programmers and there's nothing amazing 
about that job. As a teenager I thought that programmers were cool and 
rebellious but I find that most of them are cookie-cutter personalities, and 
their opinions are uninteresting (game developers are the obvious exception, 
but they don't make much money in this country!)

For a long time I wanted to work as a programmer but now I'm not so sure. I 
volunteer my time for projects which help children and people down on their 
luck, this is a pretty good life! If I am to maintain packages, then I'm going 
to need someone to give me direction. I could Google "software Linux" and find 
something that isn't already packaged, but the "just google it bro" approach is 
bad in my opinion, it's better to have a mentor. Sure there are a few freak 
geniuses who are good at computery-stuff but those guys are the exception, and 
for most people the best thing is friendly human advice. I could use Google 50 
times to find information, or I could have someone email to me 3 relevant URLs 
and a couple of brief paragraphs explaining. One of the problems in my youth 
was that I tried to teach programming to myself - my goals weren't clear and I 
developed a lot of bad habits which I only un-learned 10 years later. 
Similarly, I have a Vox Valvetronix guitar amplifier and after 6 years I 
finally discovered that you can only get good tones if you put the master 
volume up really high (master volume drives the tube). I wish I had a musician 
friend who could have told me that when I bought it! Nothing beats proper 
advice from someone who knows what they're doing.
___
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/XQN5O7CBHWNF6P3PWVUPMKUKUYSKMIRQ/

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

[Jens-Ulrik Petersen]

On Fri, Jul 27, 2018 at 1:21 PM Michal Novotny  wrote:

> On Fri, Jul 27, 2018 at 4:56 AM Jens-Ulrik Petersen 
> wrote:
>
>> 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?
>>
>
> They are here:
> https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz
>

Thanks, Michal

I played with them a bit.

python-* had some circular BRs.  perl* worked fine. Of course I tried ghc*
before.
* got down to broken bcg729.spec. php* had one circular BR pair. nodejs-*
seemed okay.
(I may not have all the required macros etc installed though.)
It seems to be a good way of finding broken or more exotic spec files
anyway. ;)


I wrote a small script to see the most common package prefices in Fedora:

2915 perl
1995 python
1564 nodejs
 729 php
 661 rubygem
 616 golang
 461 ghc
 403 rust
 284 *-fonts
 264 mingw
 256 R
 139 gnome
 123 kf5
 122 hunspell
 110 erlang
  99 drupal7
  98 ocaml
  85 maven
  74 jboss
  69 eclipse
  67 sugar
  58 globus
  52 gap
  50 apache
___
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/UEP6QJF5VS65N3IYK73EJ3CTXPGRMIJL/

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

[Pavel Raiskup]

On Friday, July 27, 2018 10:01:42 AM CEST Miro Hrončok wrote:
> On 27.7.2018 07:55, Pavel Raiskup wrote:
> > On Thursday, July 26, 2018 2:29:17 PM CEST Miro Hrončok wrote:
> >>> 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?
> > 
> > I'm not sure.  Can I simply use %py_byte_compile without
> > '%_python_bytecompile_extra 0'? 
> 
> You CAN use %py_byte_compile anywhere. With or without 
> '%_python_bytecompile_extra 0'.
> 
> You MUST use '%_python_bytecompile_extra 0' if you have /usr/bin/python 
> in buildroot and you DON'T want it to be used to bytecompile Python 
> files outside of Python dirs.

So from your note it looks like the /usr/bin/python can cause troubles?

Consider:
  - I have /usr/bin/python in buildroot mistakenly
  - I do some explicit %py_byte_compile some files in %buildroot in
"extra" dirs, by either python3 only or both python{2,3}
  - I don't explicitly set '%_python_bytecompile_extra 0'

Then, brp-python-bytecompile goes and recompiles (by /bin/python) those
files, right?  But where's the problem?  Python2 and Python3 store the
byte compiled files to different directories...   (yes,
brp-python-bytecompile could avoid recompiling files which are alrady
compiled, but that's detail).

Yes, I see a very low-prio issue -> if the package is Python 3 only, it
can get inadvertently installed python2 '*.pyc' files.  But that's only
small issue (size of RPM) and it's temporary issue (we plan to turn
%_python_bytecompile_extra to 0 system wide soon).

Pavel


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

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

[Florian Weimer]

On 07/27/2018 05:10 AM, John Reiser wrote:

Always requiring 16-byte alignment on x86_64 can waste too much space
due to internal fragmentation.  The rule should be:
    The required alignment is at least  min(16, max_p2_divisor_of_size)
    where the second argument max_p2_divisor_of_size is the maximum 
power of 2

    that divides the requested size [when 0!= size].
Thus a request for 6 bytes may be satisfied by a block whose address is
divisible by 2.


But this rule is wrong.  Consider this:

struct string
{
  size_t length;
  char data[];
};

To allocate a one-byte string, malloc would be called with an argument 
of sizeof (size_t) + 1.  Your rule gives alignment 1, but in reality, 
alignment 4 or 8 is required.


(Flexible struct members are not strictly required to implement this, of 
course, so it's not a new problem at all.)


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/6AIETYCBHSJMUMBXNA7I3L32VKIPLK5E/

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

[Vít Ondruch]

Dne 27.7.2018 v 00:31 Mark Wielaard napsal(a):
> 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

Please note that OpenSSL 1.1.1 landed in Rawhide a few days ago. That
could explain this errors ...

V.

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

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

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

[Miro Hrončok]

On 27.7.2018 07:55, Pavel Raiskup wrote:

On Thursday, July 26, 2018 2:29:17 PM CEST Miro Hrončok wrote:

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?


I'm not sure.  Can I simply use %py_byte_compile without
'%_python_bytecompile_extra 0'? 


You CAN use %py_byte_compile anywhere. With or without 
'%_python_bytecompile_extra 0'.


You MUST use '%_python_bytecompile_extra 0' if you have /usr/bin/python 
in buildroot and you DON'T want it to be used to bytecompile Python 
files outside of Python dirs.


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

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

[Vít Ondruch]

Dne 26.7.2018 v 20:58 Carlos O'Donell napsal(a):
> 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.

I very appreciate your response to upstream ticket, because otherwise,
you know, I am the one who would have to justify whatever the decision
would be to one or to the other side. But I don't really want to take
sides 

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

I understand. Thx for the effort.

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

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

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-App-cpm-0.976-1.fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-27 03:21:22



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

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

[Mikolaj Izdebski]

On 07/26/2018 11:52 AM, Igor Gnatenko wrote:
>>> Note that mizdebsk already had such tool for quite some time.
>>>
>>
>> Do you have a reference?
>>
> 
> CCing Mikolaj.

Latest version of the code Igor is talking about is available at [1].
The tool is targeted for solving specific problem - generating modulemd
files, with correct and optimal buildorder, but it can be adapted for
other things.

It supports:
* conditionals (parsing spec files is done by rpmbuild,, so you can use
any construct supported by rpm, you can define macros to enable/disable
features, do bootstrap builds etc.).
* auto-provides (packages are built before generating final build order)
* rich deps (for dependency solving it uses libsolv via hawkey API)

[1]
https://github.com/fedora-java/modularity-utils/blob/master/generate-modulemd.py

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JR4ZQXNUOHRPBN63IXBESI7DVDAEHBNV/

Re: [atomic-devel] Starting a Container SIG

[Tomas Tomecek]

I'm interested.

Clement, thanks for setting this up!

Tomas


On Wed, Jul 25, 2018 at 7:10 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.
>
> 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/Z6ZWABRSWNU7VT2TCYC3YGWNXTFSRWFD/

[Bug 1608617] perl-Monitoring-Plugin-0.40 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Monitoring-Plugin-0.40-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bcc87ec1e2

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

[Bug 1608617] perl-Monitoring-Plugin-0.40 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Monitoring-Plugin-0.40
   ||-1.fc29



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/EFID56DS2FALA64RYLAWFXL7RHHGSJLQ/