[Bug 1693934] New: perl-DateTime-Locale-1.24 is available

[bugzilla]

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

Bug ID: 1693934
   Summary: perl-DateTime-Locale-1.24 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-Locale
  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
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.24
Current version/release in rawhide: 1.23-2.fc30
URL: http://search.cpan.org/dist/DateTime-Locale/

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

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

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 104  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b7556983e8   
tomcat-7.0.92-1.el6
  28  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-06b243cced   
guacamole-server-1.0.0-1.el6
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b4ada0648b   
putty-0.71-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-62f9745b71   
drupal7-7.65-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-13e2a65b5e   
wordpress-5.1.1-4.el6


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

mbedtls-2.7.10-1.el6

Details about builds:



 mbedtls-2.7.10-1.el6 (FEDORA-EPEL-2019-8858606f5d)
 Light-weight cryptographic and SSL/TLS library

Update Information:

- Update to 2.7.10  Release notes: https://tls.mbed.org/tech-
updates/releases/mbedtls-2.16.1-and-2.7.10-released

ChangeLog:

* Thu Mar 28 2019 Morten Stevens  - 2.7.10-1
- Update to 2.7.10


___
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

[Bug 1690939] perl-LWP-MediaTypes-6.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-LWP-MediaTypes-6.04-1. |perl-LWP-MediaTypes-6.04-1.
   |fc31|fc31
   |perl-LWP-MediaTypes-6.04-1. |perl-LWP-MediaTypes-6.04-1.
   |fc28|fc28
   ||perl-LWP-MediaTypes-6.04-1.
   ||fc29



--- Comment #9 from Fedora Update System  ---
perl-LWP-MediaTypes-6.04-1.fc29 has been pushed to the Fedora 29 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

[Bug 1690193] perl-CPAN-2.26 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-CPAN-2.26-1.fc29 has been pushed to the Fedora 29 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

[389-devel] Please review 50310 sasl header fix

[William Brown]

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

https://pagure.io/389-ds-base/pull-request/50311

--
Sincerely,

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

[Bug 1690939] perl-LWP-MediaTypes-6.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-LWP-MediaTypes-6.04-1. |perl-LWP-MediaTypes-6.04-1.
   |fc31|fc31
   ||perl-LWP-MediaTypes-6.04-1.
   ||fc28
 Resolution|--- |ERRATA
Last Closed||2019-03-29 02:04:24



--- Comment #8 from Fedora Update System  ---
perl-LWP-MediaTypes-6.04-1.fc28 has been pushed to the Fedora 28 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

Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans

[Fabio Valentini]

On Fri, Mar 29, 2019 at 12:33 AM Miro Hrončok  wrote:
>
> On 20. 03. 19 9:57, Fabio Valentini wrote:
> > I've gone ahead with my proposal and created the Stewardship SIG.
> >
> > This includes the SIGs/Stewardship wiki page [0], the @stewardship-sig
> > FAS group [1], to which high-priority orphaned packages can be
> > assigned, and the stewardship-sig mailing list [2].
> > ...
> > [0]: https://fedoraproject.org/wiki/SIGs/Stewardship
> > [1]: https://src.fedoraproject.org/group/stewardship-sig
> > [2]: 
> > https://lists.fedoraproject.org/admin/lists/stewardship-sig.lists.fedoraproject.org
>
> We currently need to take:
>
> jansi-native, apache-commons-compress, maven-plugins-pom, bsf, joda-convert,
> apiguardian, univocity-parsers, zinc, apache-commons-collections4,
> jakarta-commons-httpclient, plexus-components-pom, jetty-build-support,
> maven-compiler-plugin, jansi, javacc-maven-plugin, plexus-languages,
> plexus-component-factories-pom, httpcomponents-project, batik, sisu-mojos,
> jflex, apache-commons-collections, kxml, jetty-toolchain,
> apache-resource-bundles, jetty-test-helper, maven-artifact-resolver,
> jdependency, objectweb-pom, jsoup, xstream, maven-mapping, geronimo-jpa,
> maven-shared-incremental, apache-commons-jexl, apache-commons-beanutils, 
> javacc,
> xalan-j2, maven-plugin-build-helper, maven-verifier, checkstyle,
> maven-script-interpreter, jetty-alpn, jaxen, maven-assembly-plugin,
> maven-shared-jarsigner, dain-snappy, felix-bundlerepository, 
> nodejs-array-union,
> apache-parent, jsch-agent-proxy, maven-shared-io, maven-shade-plugin, bcel,
> avalon-logkit, hawtjni, xbean, jna, junit5, nodejs-arrify,
> apache-commons-discovery, jetty-artifact-remote-resources,
> sonatype-plugins-parent, jetty-assembly-descriptors, 
> maven-dependency-analyzer,
> avalon-framework, multiverse, maven-jarsigner-plugin, maven-invoker,
> exec-maven-plugin, beust-jcommander, maven-dependency-plugin,
> geronimo-jaspic-spec, xz-java, groovy, snakeyaml, gpars, jetty,
> apache-commons-jxpath, jetty-schemas, felix-osgi-obr,
> apache-commons-configuration, plexus-interactivity, regexp, 
> sonatype-oss-parent,
> plexus-compiler, jetty-test-policy, glassfish-jsp-api, cal10n,
> jetty-distribution-remote-resources, plexus-cli, jetty-alpn-api, plexus-io,
> maven-source-plugin, base64coder, opentest4j, munge-maven-plugin
>
> Later we can chop off some optional deps.
>
> Any takers from the SIG? I already took plenty and this just seems like a lot.
>
> Thanks for help.
>
> https://src.fedoraproject.org/group/stewardship-sig

I've submitted a request to take these: https://pagure.io/releng/issue/8247

I've removed those from the list for which you already have an
unorphan request pending.

Fabio

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

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/28/19 4:39 PM, Miro Hrončok wrote:
> On 28. 03. 19 21:54, Tuomo Soini wrote:
>> On Thu, 28 Mar 2019 13:22:26 +0100
>> Miro Hrončok  wrote:
>>
>>>
>>> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>>
>>> I'm still not sure about how it will behave. We should probably test
>>> it.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1687196
>>
>> Check my bug report first. You only need obsoletes in one place and
>> there was my suggested patch which was not good enough for some, but it
>> i a lot better than suggested change from Conflicts to Obsoletes all
>> over.
> 
> I don't understand why the obsoletes all over are any worse than just one.

In this case it's likely more what we want anyhow, as we want people to
move off the python34 packages. I don't think we want to keep them
around and supporting them forever. Obsoletes on everything will remove
the old python34 (and not pull in the new one) unless there's something
installed that actually needs python34.

kevin



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 28. 03. 19 21:54, Tuomo Soini wrote:

On Thu, 28 Mar 2019 13:22:26 +0100
Miro Hrončok  wrote:



A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27



I'm still not sure about how it will behave. We should probably test
it.


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

Check my bug report first. You only need obsoletes in one place and
there was my suggested patch which was not good enough for some, but it
i a lot better than suggested change from Conflicts to Obsoletes all
over.


I don't understand why the obsoletes all over are any worse than just one.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans

[Miro Hrončok]

On 20. 03. 19 9:57, Fabio Valentini wrote:

I've gone ahead with my proposal and created the Stewardship SIG.

This includes the SIGs/Stewardship wiki page [0], the @stewardship-sig
FAS group [1], to which high-priority orphaned packages can be
assigned, and the stewardship-sig mailing list [2].
...
[0]: https://fedoraproject.org/wiki/SIGs/Stewardship
[1]: https://src.fedoraproject.org/group/stewardship-sig
[2]: 
https://lists.fedoraproject.org/admin/lists/stewardship-sig.lists.fedoraproject.org


We currently need to take:

jansi-native, apache-commons-compress, maven-plugins-pom, bsf, joda-convert, 
apiguardian, univocity-parsers, zinc, apache-commons-collections4, 
jakarta-commons-httpclient, plexus-components-pom, jetty-build-support, 
maven-compiler-plugin, jansi, javacc-maven-plugin, plexus-languages, 
plexus-component-factories-pom, httpcomponents-project, batik, sisu-mojos, 
jflex, apache-commons-collections, kxml, jetty-toolchain, 
apache-resource-bundles, jetty-test-helper, maven-artifact-resolver, 
jdependency, objectweb-pom, jsoup, xstream, maven-mapping, geronimo-jpa, 
maven-shared-incremental, apache-commons-jexl, apache-commons-beanutils, javacc, 
xalan-j2, maven-plugin-build-helper, maven-verifier, checkstyle, 
maven-script-interpreter, jetty-alpn, jaxen, maven-assembly-plugin, 
maven-shared-jarsigner, dain-snappy, felix-bundlerepository, nodejs-array-union, 
apache-parent, jsch-agent-proxy, maven-shared-io, maven-shade-plugin, bcel, 
avalon-logkit, hawtjni, xbean, jna, junit5, nodejs-arrify, 
apache-commons-discovery, jetty-artifact-remote-resources, 
sonatype-plugins-parent, jetty-assembly-descriptors, maven-dependency-analyzer, 
avalon-framework, multiverse, maven-jarsigner-plugin, maven-invoker, 
exec-maven-plugin, beust-jcommander, maven-dependency-plugin, 
geronimo-jaspic-spec, xz-java, groovy, snakeyaml, gpars, jetty, 
apache-commons-jxpath, jetty-schemas, felix-osgi-obr, 
apache-commons-configuration, plexus-interactivity, regexp, sonatype-oss-parent, 
plexus-compiler, jetty-test-policy, glassfish-jsp-api, cal10n, 
jetty-distribution-remote-resources, plexus-cli, jetty-alpn-api, plexus-io, 
maven-source-plugin, base64coder, opentest4j, munge-maven-plugin


Later we can chop off some optional deps.

Any takers from the SIG? I already took plenty and this just seems like a lot.

Thanks for help.

https://src.fedoraproject.org/group/stewardship-sig

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

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 11:47, Neal Gompa  wrote:
[..]

> No. The rpm plugins are runtime activated things, that's why they are
> split out.
>

Exactly. Just checked and in python code those modules initialisation looks
like below:

-- 
# try to import build bits but dont require it
try:
from rpm._rpmb import *
except ImportError:
pass

# try to import signing bits but dont require it
try:
from rpm._rpms import *
except ImportError:
pass
-- 

So technically those rpmb and rpms pythoon DSOs can be separated.

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

[389-devel] please review: PR 50039 - Fix memory leaks around replication and bind dn thread data

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50309
___
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

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 20:57, Neal Gompa  wrote:
[..]

> > Other things related to the rpm.
> > Why in main rpm package is possible to find whole /usr/lib/rpm/platform?
> That directory contains ONLY resources used during build!!! Why main rpm
> package includes documentation about building packages? =:-#
> >
>
> They can be used at runtime as well, especially if you use
> runtime-evaluated macros in scriptlets.
>

Hopefully it is still only theory ..

1) Exactly those macros long time ago have been separated as build stage
dependent set. (Just in case if it is not obvious) in platform/ are all
archs files because that allows use rpm to do cross arch builds.
2) Theoretically someone may do any possible s*d thing in such scriptlets
and still it does not mean that those macros should be used :)
3) I don't know anything about such cases like you mention in any Fedora
spec files uses that (just done I've done few greps and still potential
list is empty) and it is already some non-empty set of such specs that
should be corrected ASAP because using something like this potentially
could be like opening Pandora box.

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

[389-devel] please review: PR 50307 - Revise CleanAllRUV restart process

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50307
___
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

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Tuomo Soini]

On Thu, 28 Mar 2019 13:22:26 +0100
Miro Hrončok  wrote:

> 
> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27

> I'm still not sure about how it will behave. We should probably test
> it.

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

Check my bug report first. You only need obsoletes in one place and
there was my suggested patch which was not good enough for some, but it
i a lot better than suggested change from Conflicts to Obsoletes all
over.


-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
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

Re: Loopy rpm subpackages dependencies

[Neal Gompa]

On Thu, Mar 28, 2019 at 1:43 PM Tomasz Kłoczko  wrote:
>
> On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý  wrote:
>>
>> Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
>> > dnf does not provide any signing functions and I was not even aware that 
>> > someone implemented in base dnf building
>> > functionalities (someone is using that?)
>>
>> No, DNF likely does not user rpmb and rpms.
>> Both libraries has 21K + 15K. It is really worth the work? Note that the 
>> split will affect ~ 16 other packages in
>> Fedora. And likely some outside of Fedora. They need to be notified of the 
>> split, reconsider their dependencies. For
>> saving 36K?
>
>
> Yes, I care about every possible (even smallest) cut on the elephant skin 
> which will die if thousand small cuts on his skin will be done :P
>
> If that does't matter why the  rpm package build produces generates 
> so many subpackages??
> If on typical system most of those packages are not optional why make so many 
> subpackages? To make Packages table in rpm database longer only?
> Not mentioning about fact that even usability of current grouping of the rpm 
> files has zero usability in case of multilib scenarios (which could be some 
> logical reason for thatcase but isn't)
> Just for fun/Because we can(tm)?
>
> If may I point on one cardinal argument which is .. KISS!!!
>
> There is no any other single package which during build may require signing 
> library (only). Not keeping sign library in rpm-sign is purely artificial. In 
> other words probability that this package would be required in some multilib 
> scenarios is ZERO!
>
> Other things related to the rpm.
> Why in main rpm package is possible to find whole /usr/lib/rpm/platform? That 
> directory contains ONLY resources used during build!!! Why main rpm package 
> includes documentation about building packages? =:-#
>

They can be used at runtime as well, especially if you use
runtime-evaluated macros in scriptlets.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/28/19 5:22 AM, Miro Hrončok wrote:
> 
> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
> 
> I'm still not sure about how it will behave. We should probably test it.

I just did a bunch of testing and the Obsoletes works great.

It does mean if someone has only packages that depend on
/usr/bin/python3 and has python34 installed for that, on upgrade they
will get just python36 and no python34. However, I think thats fine.

If they have other things that depend on 34 (the abi, or libs or the
like), they will get python36 and the updated python34 that doesn't
provide /usr/bin/python3.

I'm +1 to add this to the update and give it some more baking time.

kevin




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
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

Re: Student Introduction

[Ankur Sinha]

On Wed, Mar 27, 2019 20:12:32 +0530, Hemant Kumar Singh wrote:
> Greetings,
> I am Hemant Kumar Singh, 

Hi Hemant,

Welcome to Fedora!

> a computer science undergrad studying in NIT Warangal,
> India. I am interested to work on the project "CentOS CI User Front End" with
> Fedora Project under the guidance of Brian Stinson and Vipul Siddharth; this
> project requires HTML5 and CSS; I have done HTML in my high school and this is
> my 2nd semester pursuing a computer science major in NITW where I've been
> learning CSS on my own. Although I am new to the open source community, I feel
> I am a potential candidate for the same and will post my draft proposal asap
> for your feedback.

That sounds good! We wish you the best---please do not hesitate to post
queries to this mailing list. We're always happy to help each other
pick up new skills.


-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"
https://fedoraproject.org/wiki/User:Ankursinha

Time zone: Europe/London


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

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Przemek Klosowski]

On 3/28/19 4:17 AM, Tomasz Kłoczko wrote:


>Really?
>Really do you want me to answer on the question "why there is no
any sense
>repeat 42 times some tests on the source code configuration
stage?" ??

Yes, because you repeatedly make the mistake of assuming that one
dimension of a problem is the only one that matters, and that all
other considerations are irrelevant.


Just to be clear ..
So you want to say that I'm making mistake because I'm assuming that 
speed/performance matters?


I think people pointed out that GCC bundles several subsystems that are 
independently developed and therefore have their own autoconf processes. 
Trying to merge them together, like you propose, would make sense from 
the performance point of view but does not reflect the reality of how 
they are developed.


Jonathan is saying that efficiency has multiple axis: there's the simple 
'CPU cycles' but there are others, e.g. 'how many keystrokes does a 
developer have to type, and how often' and 'how many people have to 
coordinate changes to this file'.


It's good that people like you re-examine various assumptions, because 
some things can be improved on all axes simultaneously, and changing 
them makes life immediately better for everyone.


Other times, however, improvements on one axis make other axes worse, at 
least initially. If that's the case, you have to persuade people to 
adopt this change,  by addressing their concerns and showing a clear 
path forward, in a way that's acceptable to everyone. This is usually 
harder than solving the specific technical issue.


___
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

Re: Need assistance to build luxcorerender due to boost

[Robert-André Mauchin]

On Thursday, 28 March 2019 16:17:33 CET Luya Tshimbalanga wrote:
> Hello team,
> 
> I encountered an issue related to luxcorerender unable to use the new
> boost dependency. See
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=33804165
> 
> Could someone resolve that problem?
> 
> 
> Thanks
> 
> 
> Luya
> 


Pass the correct Python version to cmake:

%cmake \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \
-DBOOST_ROOT=%{_prefix} \
-DLUXRAYS_DISABLE_OPENCL=0 \
-DPYTHON_V=%{python3_version_nodots} \
..


You'll need to apply the patch 
"use-non_native-fp_classify-for-boost-106900.patch" or the build will fail with 
Boost 1.69.

___
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

Re: Anitya not working again?

[Robert-André Mauchin]

On Thursday, 28 March 2019 19:38:30 CET Michal Konecny wrote:
> I found out what is wrong, you created the project without Fedora 
> mapping, so the first version was retrieved without knowing how this is 
> packaged in Fedora. But I see, that the mapping was added later, but the 
> message about the mapping wasn't send by Anitya. Did you added the 
> mapping using API, maybe the message is not published when the mapping 
> is changed using API?
> 

Yes I first created the project without Fedora mapping. Then added the mapping 
in a second time, all using the API.


> I can still see few golang updates coming through recently:
> golang-github-hashicorp-mdns - [0]
> golang-github-pierrec-lz4 - [1]
> 
> Could you check what exactly is missing from the projects you added. You 
> could check the latest messages from the-new-hotness in [2]
> 
> [0] - 
> https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-866
> 3-7ea15f434774_raw=true=extra-large
 [1] -
> https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-825
> 0-ebe8deec6b26_raw=true=extra-large
 [2] -
> https://apps.fedoraproject.org/datagrepper/raw?category=hotness=259200
> 0

For my example, the message says:

hotness.update.drop the-new-hotness saw an update for stats, but release-
monitoring.org doesn't know what that project is called in Fedora land

 
https://apps.fedoraproject.org/datagrepper/id?id=2019-40749965-2805-4e33-a037-cbbd4a6283bb_raw=true=extra-large

Doesn't it send the notification if the mapping is added afterward?

___
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

Re: Orphaned some Java packages

[Christopher]

On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski  wrote:
> - javapackages-tools, stream 201801 (buildroot-only module, not
> intended to be delivered to users)

How do I enable/install this module locally? It would be very helpful
for local builds/testing, but is not available in:
sudo dnf --releasever=30 module list
___
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

Re: Anitya not working again?

[Michal Konecny]

I found out what is wrong, you created the project without Fedora 
mapping, so the first version was retrieved without knowing how this is 
packaged in Fedora. But I see, that the mapping was added later, but the 
message about the mapping wasn't send by Anitya. Did you added the 
mapping using API, maybe the message is not published when the mapping 
is changed using API?


I can still see few golang updates coming through recently:
golang-github-hashicorp-mdns - [0]
golang-github-pierrec-lz4 - [1]

Could you check what exactly is missing from the projects you added. You 
could check the latest messages from the-new-hotness in [2]


[0] - 
https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-8663-7ea15f434774_raw=true=extra-large
[1] - 
https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-8250-ebe8deec6b26_raw=true=extra-large
[2] - 
https://apps.fedoraproject.org/datagrepper/raw?category=hotness=2592000


On 28/03/19 19:19, Michal Konecny wrote:

Hi,

this is really suspicious, I didn't saw any issue related to 
the-new-hotness or Anitya in recent days.

I will check what is going on.

mkonecny

On 28/03/19 19:09, Robert-André Mauchin wrote:

Hello,

Earlier this week, I wrote a script to check and add all Golang 
packages to
Anitya. Everything went smoothly, and dozens of packages were 
registered and

got their version retrieved.
Since our float of Golang packages is severely out of date, I was 
expecting a
load of new messages from Bugzilla. But niet, nada, zilch: no new bug 
were

filed as part of this process.
So is Anitya broken again? Is it not supposed to fill bugs for new 
versions?


For example, I registered golang-github-montanaflynn-stats:

Latest version upstream is 0.5.0
https://release-monitoring.org/project/19511/

Version in Fedora is 0.2.0
https://src.fedoraproject.org/rpms/golang-github-montanaflynn-stats/

Yet no bug was filled for it.

Any help please?


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

___
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

___
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

Re: Anitya not working again?

[Michal Konecny]

On 28/03/19 19:17, Jason L Tibbitts III wrote:

"RM" == Robert-André Mauchin  writes:

RM> Since our float of Golang packages is severely out of date, I was
RM> expecting a load of new messages from Bugzilla.

I don't believe it notifies when the project is first added.  It should
notify when the project is next updated.


It should notify about every new version and when new mapping to Fedora 
is added.


  - 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

___
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

Re: Anitya not working again?

[Michal Konecny]

Hi,

this is really suspicious, I didn't saw any issue related to 
the-new-hotness or Anitya in recent days.

I will check what is going on.

mkonecny

On 28/03/19 19:09, Robert-André Mauchin wrote:

Hello,

Earlier this week, I wrote a script to check and add all Golang packages to
Anitya. Everything went smoothly, and dozens of packages were registered and
got their version retrieved.
Since our float of Golang packages is severely out of date, I was expecting a
load of new messages from Bugzilla. But niet, nada, zilch: no new bug were
filed as part of this process.
So is Anitya broken again? Is it not supposed to fill bugs for new versions?

For example, I registered golang-github-montanaflynn-stats:

Latest version upstream is 0.5.0
https://release-monitoring.org/project/19511/

Version in Fedora is 0.2.0
https://src.fedoraproject.org/rpms/golang-github-montanaflynn-stats/

Yet no bug was filled for it.

Any help please?


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

___
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

Re: Anitya not working again?

[Jason L Tibbitts III]

> "RM" == Robert-André Mauchin  writes:

RM> Since our float of Golang packages is severely out of date, I was
RM> expecting a load of new messages from Bugzilla.

I don't believe it notifies when the project is first added.  It should
notify when the project is next updated.

 - 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

Anitya not working again?

[Robert-André Mauchin]

Hello,

Earlier this week, I wrote a script to check and add all Golang packages to 
Anitya. Everything went smoothly, and dozens of packages were registered and 
got their version retrieved.
Since our float of Golang packages is severely out of date, I was expecting a 
load of new messages from Bugzilla. But niet, nada, zilch: no new bug were 
filed as part of this process.
So is Anitya broken again? Is it not supposed to fill bugs for new versions?

For example, I registered golang-github-montanaflynn-stats:

Latest version upstream is 0.5.0
https://release-monitoring.org/project/19511/

Version in Fedora is 0.2.0
https://src.fedoraproject.org/rpms/golang-github-montanaflynn-stats/

Yet no bug was filled for it.

Any help please?


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

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý  wrote:

> Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
> > dnf does not provide any signing functions and I was not even aware that
> someone implemented in base dnf building
> > functionalities (someone is using that?)
>
> No, DNF likely does not user rpmb and rpms.
> Both libraries has 21K + 15K. It is really worth the work? Note that the
> split will affect ~ 16 other packages in
> Fedora. And likely some outside of Fedora. They need to be notified of the
> split, reconsider their dependencies. For
> saving 36K?
>

Yes, I care about every possible (even smallest) cut on the elephant skin
which will die if thousand small cuts on his skin will be done :P

If that does't matter why the  rpm package build produces
generates so many subpackages??
If on typical system most of those packages are not optional why make so
many subpackages? To make Packages table in rpm database longer only?
Not mentioning about fact that even usability of current grouping of the
rpm files has zero usability in case of multilib scenarios (which could be
some logical reason for thatcase but isn't)
Just for fun/Because we can(tm)?

If may I point on one cardinal argument which is .. KISS!!!

There is no any other single package which during build may require signing
library (only). Not keeping sign library in rpm-sign is purely artificial.
In other words probability that this package would be required in some
multilib scenarios is ZERO!

Other things related to the rpm.
Why in main rpm package is possible to find whole /usr/lib/rpm/platform?
That directory contains ONLY resources used during build!!! Why main rpm
package includes documentation about building packages? =:-#

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

Re: Fedora Packaging Location & Symlinks Question

[Nicolas Mailhot]

Le 2019-03-28 17:26, Michael Zhang a écrit :
Hi


We read in the guidelines that all jars and class files should go
under %{_javadir} (/usr/share/java by default). We were initially
thinking of symlinking all the jars and class files but recently, we
thought "could we put the whole OpenLiberty install under
/usr/share/java/openliberty?" I ask because we have jars in locations
other than one folder and I think moving everything is going to be
problematic to manage.


symlinking from a shared /usr/share/java is easy, doing it the other way 
is not


If you don't put jars from the start up in /usr/share/java with clean 
naming and versioning, you and the other entities that wish to reuse 
your code will spend years fighting your private directory layout. 
Remember, sharing is a core Fedora value, putting things in Fedora 
without making them share-able sort of misses the point.


Share your code blocks in /usr/share/java, keep your app directory 
layout private.


And then if putting code in /usr/share/java, or pulling it from 
/usr/share/java, is painful, that means you should work with other java 
stakeholders in Fedora to improve the conventions and tooling used to 
share java code.


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

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Jason L Tibbitts III]

> "MH" == Miro Hrončok  writes:

MH> You realize that once it is maintained by the group, nobody else is
MH> going to take it?

When the stewardship SIG maintains a package, it should be for the sole
purpose of keeping it around just long enough to avoid serious
disruption that would be caused by that package being removed from the
distribution.  The SIG shouldn't be maintaining things indefinitely and
should always give the expectation that the packages _will_ be retired
(not just orphaned again) unless someone picks them up.

 - 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

Fedora GPG signing/verifying question

[Michael Zhang]

Hi,When publishing, does Fedora:     a) rebuild a maintainer's package from source and gpg sign it with their own fedora gpg key
              (ex. /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-11-primary)
OR:
     b) publish the package that the maintainer personally compiled and gpg signed with their personal key?If the answer is b), why do we import a Fedora public key to verify packages/rpms?
 

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.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

Re: Loopy rpm subpackages dependencies

[Miroslav Suchý]

Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a):
> dnf does not provide any signing functions and I was not even aware that 
> someone implemented in base dnf building
> functionalities (someone is using that?)

No, DNF likely does not user rpmb and rpms.
Both libraries has 21K + 15K. It is really worth the work? Note that the split 
will affect ~ 16 other packages in
Fedora. And likely some outside of Fedora. They need to be notified of the 
split, reconsider their dependencies. For
saving 36K?

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

Re: Fedora GPG signing/verifying question

[Michael Zhang]

Thanks for the response.

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.com
 

 
 
 
- Original message -From: Tom Hughes To: Development discussions related to Fedora , Michael Zhang Cc:Subject: Re: Fedora GPG signing/verifying questionDate: Thu, Mar 28, 2019 12:27 PM 
On 28/03/2019 16:24, Michael Zhang wrote:> When publishing, does Fedora:>       a) rebuild a maintainer's package from source and gpg sign it with> their own fedora gpg key>                (ex. /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-11-primary)> OR:>       b) publish the package that the maintainer personally compiled and> gpg signed with their personal key?>> If the answer is b), why do we import a Fedora public key to verify> packages/rpms?The first - all packages are built from source in koji and thensigned with the Fedora key.Tom--Tom Hughes (t...@compton.nu)http://compton.nu/___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
 

___
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

Re: Fedora GPG signing/verifying question

[Tom Hughes]

On 28/03/2019 16:24, Michael Zhang wrote:


When publishing, does Fedora:
      a) rebuild a maintainer's package from source and gpg sign it with 
their own fedora gpg key

               (ex. /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-11-primary)
OR:
      b) publish the package that the maintainer personally compiled and 
gpg signed with their personal key?


If the answer is b), why do we import a Fedora public key to verify 
packages/rpms?


The first - all packages are built from source in koji and then
signed with the Fedora key.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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

Fedora Packaging Location & Symlinks Question

[Michael Zhang]

Hey, We read in the guidelines that all jars and class files should go under %{_javadir} (/usr/share/java by default). We were initially thinking of symlinking all the jars and class files but recently, we thought "could we put the whole OpenLiberty install under /usr/share/java/openliberty?" I ask because we have jars in locations other than one folder and I think moving everything is going to be problematic to manage.Yours Sincerely,
 

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.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

Re: F31 Self-Contained Change proposal: Include several modules in the EFI build of Grub2 for security use-cases

[Ben Cotton]

On Mon, Mar 25, 2019 at 4:12 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2
>
This Change proposal is on hold.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
___
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

mythes-eo package

[Carmen Bianca Bakker]

Hello developers,

I have created a `mythes` and `hyphen` package for the Esperanto language.
Unfortunately, I am not a sponsored Fedora developer, and the package
doesn't seem like it'll be accepted unless I become sponsored.

Between all manner of tasks, I do not have the time to pursue becoming
sponsored.  But even so I would like the package to enter Fedora.  It
likely requires zero maintenance.

Is there someone who would like to take this package from me?

The bug report is:

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

Many thanks and with kindness,
Carmen


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

Need assistance to build luxcorerender due to boost

[Luya Tshimbalanga]

Hello team,

I encountered an issue related to luxcorerender unable to use the new
boost dependency. See

https://koji.fedoraproject.org/koji/taskinfo?taskID=33804165

Could someone resolve that problem?


Thanks


Luya

___
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

Re: Orphaned some Java packages

[Mikolaj Izdebski]

On Thu, Mar 28, 2019 at 3:04 PM Miro Hrončok  wrote:
> On 28. 03. 19 14:49, Mikolaj Izdebski wrote:
> > On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok  wrote:
> >>
> >> I took over google-gson, but I see no stream branch.
> >
> > IIRC google-gson is not part of any modules I am currently maintaining
> > in Fedora.
>
> So from the 259 orphaned packages, how many are actually in modules?

When you look at source package counts, only 127 out of 259 orphaned
packages are part of javapackages-tools module. This is because the
module is built with lots of non-essential features disabled through
multiple bconds [1]

[1] 
https://src.fedoraproject.org/modules/javapackages-tools/blob/201801/f/javapackages-tools.yaml#_32

--
Mikolaj Izdebski
___
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

Re: strange failures with gcc-9.0.1-0.11.fc31.x86_64

[Mark Wielaard]

Hi,

On Thu, 2019-03-28 at 14:28 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 28, 2019 at 02:14:31PM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 28, 2019 at 08:52:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Wed, Mar 27, 2019 at 01:55:44PM +, Zbigniew Jędrzejewski-Szmek 
> > > wrote:
> > > > I'm trying to compile systemd in koji and mock, and I'm getting 
> > > > suspicious
> > > > crashes...
> > > > 
> > > > $ valgrind x86_64-redhat-linux-gnu/test-terminal-util
> > > > /* test_default_term_for_tty */
> > > > ...
> > > > /* test_read_one_char */
> > > > ==21== Invalid read of size 4
> > > > ==21==at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so)
> > > > ==21==by 0x109301: UnknownInlinedFun (test-terminal-util.c:43)
> > > > ==21==by 0x109301: main (test-terminal-util.c:80)
> > > > ==21==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > > > ==21== 
> > > > ==21== 
> > > > ==21== Process terminating with default action of signal 11 (SIGSEGV)
> > > > 
> > > > The problem is at this line, there is just a call to (a function which
> > > > transitively calls) mkostemp(). It seems like the inlining is somehow
> > > > going wrong.
> > > 
> > > It turns out that our test case was wrong. I was confused because the
> > > inlining causes the backtrace to report an unrelated spot.
> > 
> > So do you still need anything from me to debug?
> 
> Thanks. I need some advice mostly. There's still the question of bogus
> backtrace returned by valgrind. Is this a valgrind issue or the debug
> data produced by gdb or something else? If we cannot rely on
> backtraces with LTO, this would be a big drawback.

The above backtrace is produced by valgrind. The addresses should be
correct, but as "UnknownInlinedFun" shows it has some trouble resolving
the associated function/symbol names.

I don't know if LTO makes that valgrind bug worse.

If gdb works then you can also use gdb and valgrind together:
https://tromey.com/blog/?p=731

http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

gdb probably can produce a better backtrace than valgrind.
___
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

Re: strange failures with gcc-9.0.1-0.11.fc31.x86_64

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 28, 2019 at 02:14:31PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 28, 2019 at 08:52:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 27, 2019 at 01:55:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I'm trying to compile systemd in koji and mock, and I'm getting suspicious
> > > crashes...
> > > 
> > > $ valgrind x86_64-redhat-linux-gnu/test-terminal-util
> > > /* test_default_term_for_tty */
> > > ...
> > > /* test_read_one_char */
> > > ==21== Invalid read of size 4
> > > ==21==at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so)
> > > ==21==by 0x109301: UnknownInlinedFun (test-terminal-util.c:43)
> > > ==21==by 0x109301: main (test-terminal-util.c:80)
> > > ==21==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > > ==21== 
> > > ==21== 
> > > ==21== Process terminating with default action of signal 11 (SIGSEGV)
> > > 
> > > The problem is at this line, there is just a call to (a function which
> > > transitively calls) mkostemp(). It seems like the inlining is somehow
> > > going wrong.
> > 
> > It turns out that our test case was wrong. I was confused because the
> > inlining causes the backtrace to report an unrelated spot.
> 
> So do you still need anything from me to debug?

Thanks. I need some advice mostly. There's still the question of bogus
backtrace returned by valgrind. Is this a valgrind issue or the debug
data produced by gdb or something else? If we cannot rely on
backtraces with LTO, this would be a big drawback.

> gdb crashes I'll defer to the gdb team.  Is that with LTO only btw?

No, LTO doesn't seem to be relevant, despite what I said earlier.
With some programs (I tried a few, some crash, so don't, no idea what
is the rule, but it seems that the very simple ones don't):

In mock buildroot of systemd:
$ ninja -C x86_64-redhat-linux-gnu systemd
$ gdb x86_64-redhat-linux-gnu/systemd
GNU gdb (GDB) Fedora 8.3.50.20190321-3.fc31
...
$ r
...
Trying to run as user instance, but the system has not been booted with systemd.
[Inferior 1 (process 2466) exited with code 01]
Segmentation fault (core dumped)

So the crash seems to be when returning to the gdb prompt, either because
the debugee exited or crashed or hit a breakpoint (all three end the same).

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

Re: Orphaned some Java packages

[Miro Hrončok]

On 28. 03. 19 14:49, Mikolaj Izdebski wrote:

On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok  wrote:


On 05. 02. 19 11:07, Mikolaj Izdebski wrote:

I've just orphaned 259 packages listed below. Almost all of them are
Java packages which I will continue to maintain as part of modules.
Intent to orphan them was already announced on java-devel [1] and
devel [2] lists, with detailed reasoning.


Hi Mikolaj,

do you have some kind out outline about what packages are in what modules?


Currently I maintain the following 4 modules/streams:

- javapackages-tools, stream 201801 (buildroot-only module, not
intended to be delivered to users)
- maven, stream 3.5
- ant, stream 1.10
- scala, stream 2.10

Below I explained how to get lists of packages in each of the modules.



I took over google-gson, but I see no stream branch.


IIRC google-gson is not part of any modules I am currently maintaining
in Fedora.


So from the 259 orphaned packages, how many are actually in modules?


junit has javapackages branch
https://src.fedoraproject.org/rpms/junit/commits/javapackages

Is this the branch you use to build a module?


Correct.


Thanks.


A friend sent me a list of package they were able to find in a module by some
dark magic. BTW what is the supported way to query this kind of information?


First you need to find out module NSVC (name, stream version and
context). You can do that in many ways, for example to query Koji for
complete javapackages-tools module builds with highest version you can
run this query:

koji list-builds --type module --package javapackages-tools --state
COMPLETE -k version | head -3

Once you know NSVC you can see component builds corresponding to that
module using the following command:

koji list-tagged module-${NAME}-${STREAM}-${VERSION}-${CONTEXT}

For example:

koji list-tagged module-javapackages-tools-201801-2820190319130429-819b5873



I will try this. Thank You.


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

Re: Orphaned some Java packages

[Mikolaj Izdebski]

On Thu, Mar 28, 2019 at 8:44 AM Vít Ondruch  wrote:
> Trying to take look from the other side, the java.yaml might need some
> love [1], because the GH links are broken [2, 3]

java module doesn't have any complete builds. It is not actively maintained.

--
Mikolaj Izdebski
___
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

Re: Orphaned some Java packages

[Mikolaj Izdebski]

On Thu, Mar 28, 2019 at 12:49 AM Miro Hrončok  wrote:
>
> On 05. 02. 19 11:07, Mikolaj Izdebski wrote:
> > I've just orphaned 259 packages listed below. Almost all of them are
> > Java packages which I will continue to maintain as part of modules.
> > Intent to orphan them was already announced on java-devel [1] and
> > devel [2] lists, with detailed reasoning.
>
> Hi Mikolaj,
>
> do you have some kind out outline about what packages are in what modules?

Currently I maintain the following 4 modules/streams:

- javapackages-tools, stream 201801 (buildroot-only module, not
intended to be delivered to users)
- maven, stream 3.5
- ant, stream 1.10
- scala, stream 2.10

Below I explained how to get lists of packages in each of the modules.

>
> I took over google-gson, but I see no stream branch.

IIRC google-gson is not part of any modules I am currently maintaining
in Fedora.

> junit has javapackages branch
> https://src.fedoraproject.org/rpms/junit/commits/javapackages
>
> Is this the branch you use to build a module?

Correct.

> A friend sent me a list of package they were able to find in a module by some
> dark magic. BTW what is the supported way to query this kind of information?

First you need to find out module NSVC (name, stream version and
context). You can do that in many ways, for example to query Koji for
complete javapackages-tools module builds with highest version you can
run this query:

koji list-builds --type module --package javapackages-tools --state
COMPLETE -k version | head -3

Once you know NSVC you can see component builds corresponding to that
module using the following command:

koji list-tagged module-${NAME}-${STREAM}-${VERSION}-${CONTEXT}

For example:

koji list-tagged module-javapackages-tools-201801-2820190319130429-819b5873

--
Mikolaj Izdebski
___
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

Re: strange failures with gcc-9.0.1-0.11.fc31.x86_64

[Jakub Jelinek]

On Thu, Mar 28, 2019 at 08:52:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 27, 2019 at 01:55:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > I'm trying to compile systemd in koji and mock, and I'm getting suspicious
> > crashes...
> > 
> > $ valgrind x86_64-redhat-linux-gnu/test-terminal-util
> > /* test_default_term_for_tty */
> > ...
> > /* test_read_one_char */
> > ==21== Invalid read of size 4
> > ==21==at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so)
> > ==21==by 0x109301: UnknownInlinedFun (test-terminal-util.c:43)
> > ==21==by 0x109301: main (test-terminal-util.c:80)
> > ==21==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > ==21== 
> > ==21== 
> > ==21== Process terminating with default action of signal 11 (SIGSEGV)
> > 
> > The problem is at this line, there is just a call to (a function which
> > transitively calls) mkostemp(). It seems like the inlining is somehow
> > going wrong.
> 
> It turns out that our test case was wrong. I was confused because the
> inlining causes the backtrace to report an unrelated spot.

So do you still need anything from me to debug?
gdb crashes I'll defer to the gdb team.  Is that with LTO only btw?

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

Re: Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

On Thu, 28 Mar 2019 at 12:47, M A Young  wrote:
[..]

> > python3-rpm is required by dnf so it is really hard to have manageable
> > system without that part (however in extreme cases it is still possible
> to
> > drop completely dnf).
>
> You could always use microdnf instead.
>

If it is really possible why it is not used that way by default?
dnf does not provide any signing functions and I was not even aware that
someone implemented in base dnf building functionalities (someone is using
that?)

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

[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Neal Gompa]

On Thu, Mar 28, 2019 at 8:22 AM Miro Hrončok  wrote:
>
> On 26. 03. 19 1:51, Miro Hrončok wrote:
> > On 25. 03. 19 18:56, Kevin Fenzi wrote:
> >> Just make python36 obsolete the old version of python34 that had
> >> /usr/bin/python3. This causes yum to install the new python34 and pull
> >> in python36 for /usr/bin/python3.
> >
> > If that works, we are good. Does it really behave like that with plain 
> > upgrade?
> > E.g. without specifying what to upgrade?
> >
> > I thought that obsoleting old py34 can do one of the following:
> >
> > A) python34 gets queued for upgrading first, there is no more old python34 
> > to be
> > obsoleted by python36, python36 isn't installed.
> >
> > B) python36 gets queued for obsoleting old python34 first, python34 gets 
> > queued
> > for removing instead of updating, there is more pytho34 to be updated.
> >
> > C) what you said.
> >
> > If C) is the guaranteed behavior, I guess we are good to do this.
> >
> >> It does mean people with 3rd party software are now using python36
> >> instead of 34, but if they only speficied /usr/bin/python3, it should
> >> just run with any python3 version right?
> >
> > As long as they are only using standard library, yes. Otherwise there might 
> > be
> > problems. However that was anticipated.
>
> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>
> I'm still not sure about how it will behave. We should probably test it.
>

Obsoletes means that the old package will get removed as part of the
upgrade. Conflicts means that yum has to figure out a way to keep it.
That's the difference.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: LD_LIBRARY_PATH vs rpath and libtool

[Pavel Raiskup]

On Thursday, March 28, 2019 1:27:34 PM CET Pavel Raiskup wrote:
> Hi Ingvar,
> 
> On Thursday, March 28, 2019 11:58:21 AM CET Ingvar Hagelund wrote:
> > Fedora prohibits the use of rpath, ref 
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
> > 
> > When compiling varnish with litbool, I ensure this by the usual
> > 
> > sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
> > s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
> 
> With new enough libtool script, you can use this instead:
> 
> %configure LT_SYS_LIBRARY_PATH=%_libdir
> 
> or if that makes sense in your case:
> 
> %configure LT_SYS_LIBRARY_PATH=%_libdir:
> 
> This is unfortunately needed because it is not easy to detect whether the
> linker uses /usr/lib64 path by default.  Ideas?  Libtool attempts to parse
> ld.so.conf & friends, but the desired info isn't there

We could though work-around this system-wide, if there's no better way:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/55

Pavel

> > However, during build and check, I need access to a library in the build. 
> > For
> > example, the test suite uses the binary varnishtest to access
> > libvarnishapi.so.2, which is not visible as the package is not installed 
> > yet.
> 
> If you use the LT_SYS_LIBRARY_PATH instead DIE_RPATH_DIE the tests should
> just work.
> 
> > I have gotten around this by putting in LD_LIBRARY_PATH where I need,
> > but rpmlint gives me a warning on that.
> 
> Can you post the warnings?  I've been using LD_LIBRARY_PATH in %check for
> quite some time [1], and rpmlint did not complain...
> 
> > Are there other possibilities to solve this?
> 
> Report that to rpmlint so they don't complain in %check?  Push to rpmlint
> upstream to implement ignore file?
> 
> [1] 
> https://src.fedoraproject.org/rpms/libarchive/c/f64e33e456d935e34f6202449cecb9eb00136436?branch=master
> 
> 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
> 



___
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

Re: Loopy rpm subpackages dependencies

[M A Young]

On Thu, 28 Mar 2019, Tomasz Kłoczko wrote:

> Hi,
> 
> Just found that on some minimal system it is not possible to remove some rpm
> subpackages.
> 
> * Current state
> 
> # rpm -qa | grep rpm
> rpm-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-4.14.2.1-4.fc30.1.x86_64
> python3-rpm-4.14.2.1-4.fc30.1.x86_64
> rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
> 
> python3-rpm is required by dnf so it is really hard to have manageable
> system without that part (however in extreme cases it is still possible to
> drop completely dnf).

You could always use microdnf instead.

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

Re: LD_LIBRARY_PATH vs rpath and libtool

[Pavel Raiskup]

Hi Ingvar,

On Thursday, March 28, 2019 11:58:21 AM CET Ingvar Hagelund wrote:
> Fedora prohibits the use of rpath, ref 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
> 
> When compiling varnish with litbool, I ensure this by the usual
> 
> sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
> s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

With new enough libtool script, you can use this instead:

%configure LT_SYS_LIBRARY_PATH=%_libdir

or if that makes sense in your case:

%configure LT_SYS_LIBRARY_PATH=%_libdir:

This is unfortunately needed because it is not easy to detect whether the
linker uses /usr/lib64 path by default.  Ideas?  Libtool attempts to parse
ld.so.conf & friends, but the desired info isn't there

> However, during build and check, I need access to a library in the build. For
> example, the test suite uses the binary varnishtest to access
> libvarnishapi.so.2, which is not visible as the package is not installed yet.

If you use the LT_SYS_LIBRARY_PATH instead DIE_RPATH_DIE the tests should
just work.

> I have gotten around this by putting in LD_LIBRARY_PATH where I need,
> but rpmlint gives me a warning on that.

Can you post the warnings?  I've been using LD_LIBRARY_PATH in %check for
quite some time [1], and rpmlint did not complain...

> Are there other possibilities to solve this?

Report that to rpmlint so they don't complain in %check?  Push to rpmlint
upstream to implement ignore file?

[1] 
https://src.fedoraproject.org/rpms/libarchive/c/f64e33e456d935e34f6202449cecb9eb00136436?branch=master

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

Re: Loopy rpm subpackages dependencies

[Panu Matilainen]

On 3/28/19 1:31 PM, Tomasz Kłoczko wrote:

Hi,

Just found that on some minimal system it is not possible to remove some 
rpm subpackages.


* Current state

# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64

python3-rpm is required by dnf so it is really hard to have manageable 
system without that part (however in extreme cases it is still possible 
to drop completely dnf).


Yes and the split in all its painfullness is exactly to support those 
minimal environments where there's no python, no dnf etc.




Problem is that on minimal system rpm-sign-libs and rpm-build-libs 
theoretically should be not needed, however because python module in 
current form combines in single package all its three DSOs:


# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so 

/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so 

/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so 

it causes that it is not possible to use only core rpm package 
management on minimal system.

I think that it would be good to split python3-rpm into python3-rpm{,b,s}.


That's one possibility but hasn't been done because it makes it even 
more painful, and actually the build part would be dragged in by the 
builddep dnf plugin anyway.


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

Re: Loopy rpm subpackages dependencies

[Neal Gompa]

On Thu, Mar 28, 2019 at 7:32 AM Tomasz Kłoczko  wrote:
>
> Hi,
>
> Just found that on some minimal system it is not possible to remove some rpm 
> subpackages.
>
> * Current state
>
> # rpm -qa | grep rpm
> rpm-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-4.14.2.1-4.fc30.1.x86_64
> python3-rpm-4.14.2.1-4.fc30.1.x86_64
> rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
> rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
>
> python3-rpm is required by dnf so it is really hard to have manageable system 
> without that part (however in extreme cases it is still possible to drop 
> completely dnf).
>
> Problem is that on minimal system rpm-sign-libs and rpm-build-libs 
> theoretically should be not needed, however because python module in current 
> form combines in single package all its three DSOs:
>
> # rpm -ql python3-rpm | grep so$
> /usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
> /usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
> /usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
>
> it causes that it is not possible to use only core rpm package management on 
> minimal system.
> I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
>
> * Proposal
>
> In current form keeping separated rpm-plugin-selinux is a bit pointless so 
> that part IMO should be joined with rpm-build.
> As well probably rpm-plugin-ima could be merged with rpm-sign.
>
> With that changes total number of generated packages will be the same and 
> will make IMO much more sense in case of non-devel/build systems and systems 
> which are used for signing packages.
>
> Comments?
>

No. The rpm plugins are runtime activated things, that's why they are split out.

And why are you complaining about library packages?! It adds very
little in the way of space usage or such. It's also only "loopy" if
you are insane enough to split the updating of these packages into
separate transactions.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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

Loopy rpm subpackages dependencies

[Tomasz Kłoczko]

Hi,

Just found that on some minimal system it is not possible to remove some
rpm subpackages.

* Current state

# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64

python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible to
drop completely dnf).

Problem is that on minimal system rpm-sign-libs and rpm-build-libs
theoretically should be not needed, however because python module in
current form combines in single package all its three DSOs:

# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so

it causes that it is not possible to use only core rpm package management
on minimal system.
I think that it would be good to split python3-rpm into python3-rpm{,b,s}.

* Proposal

In current form keeping separated rpm-plugin-selinux is a bit pointless so
that part IMO should be joined with rpm-build.
As well probably rpm-plugin-ima could be merged with rpm-sign.

With that changes total number of generated packages will be the same and
will make IMO much more sense in case of non-devel/build systems and
systems which are used for signing packages.

Comments?

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

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Fabio Valentini]

On Thu, Mar 28, 2019 at 11:57 AM Miro Hrončok  wrote:
>
> On 27. 03. 19 20:53, Fabio Valentini wrote:> On the other side, I don't think
> that the problem of orphaned
> > "important" packages will go away, and this group can offer
> > maintenance until a "proper" new maintainer for those packages is
> > found.
>
> You realize that once it is maintained by the group, nobody else is going to
> take it?

I realize that these packages won't be tracked by the weekly "Orphaned
packages" report anymore, but I don't think that accumulating more and
more packages is sustainable, either.

So I was thinking about regularly (monthly or so?) posting the list of
packages that's currently maintained by the SIG, and actively ask for
new maintainers, similar to the "orphaned packages" report.

Fabio

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

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Fabio Valentini]

On Thu, Mar 28, 2019 at 11:46 AM Aleksandra Fedorova  wrote:
>
> I propose to change the scope of the SIG a bit.
>
> Maintaining packages could be one of the activities of the SIG, but its 
> primary purpose should be to deal with this topic in general.
>
> Watch for orphans, develop orphaning and retirement workflows, develop a 
> strategy how to manage those cases, how to prevent them, suggest guidelines 
> on how to decide whether or not one should move package to the module - 
> topics like that.
>
> It extends the scope, but it also opens some possibilities for us to work on 
> the root cause.
>
> What do you think?

I agree 100% here.

Since my intention was to improve the situation around orphaned
packages, this is exactly what I was thinking about:

- provide (temporary) maintenance of important, orphaned packages
- monitor orphaned packages, spot issues early, actively look for new
maintainers
- probably report the current status regularly
- discuss and refine the current orphaning / retirement process

Fabio

> --
> Aleksandra Fedorova
> bookwar
>
>
> ___
> 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
___
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

LD_LIBRARY_PATH vs rpath and libtool

[Ingvar Hagelund]

Fedora prohibits the use of rpath, ref 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath

When compiling varnish with litbool, I ensure this by the usual

sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

However, during build and check, I need access to a library in the
build. For example, the test suite uses the binary varnishtest to
access libvarnishapi.so.2, which is not visible as the package is not
installed yet.

I have gotten around this by putting in LD_LIBRARY_PATH where I need,
but rpmlint gives me a warning on that.

Are there other possibilities to solve this?

Ingvar

___
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

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Miro Hrončok]

On 27. 03. 19 20:53, Fabio Valentini wrote:> On the other side, I don't think 
that the problem of orphaned

"important" packages will go away, and this group can offer
maintenance until a "proper" new maintainer for those packages is
found.


You realize that once it is maintained by the group, nobody else is going to 
take it?


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

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

[Aleksandra Fedorova]

I propose to change the scope of the SIG a bit.

Maintaining packages could be one of the activities of the SIG, but its
primary purpose should be to deal with this topic in general.

Watch for orphans, develop orphaning and retirement workflows, develop a
strategy how to manage those cases, how to prevent them, suggest guidelines
on how to decide whether or not one should move package to the module -
topics like that.

It extends the scope, but it also opens some possibilities for us to work
on the root cause.

What do you think?

-- 
Aleksandra Fedorova
bookwar
___
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

Re: pkgconfig usage

[Fabio Valentini]

On Thu, Mar 28, 2019 at 12:08 AM Luya Tshimbalanga
 wrote:
>
> On 2019-03-26 10:07 a.m., Georg Sauthoff wrote:
> > Hello,
> >
> > when packaging a C/C++ program, the rpm automatic dependency feature
> > usually works well for shared libraries.
> >
> > That mean when program 'bar' needs libfoo-devel at build time it's
> > sufficient to add
> >
> > BuildRequires: libfoo-devel
> >
> > and I can omit
> >
> > Requires: libfoo
> >
> > because rpm automatically adds something like:
> >
> > libfoo.so.1()(64bit)
> >
> > Of course, I could still add a superfluous
> >
> > Requires: libfoo
> >
> > and then the resulting binary package would contain a redundant
> > dependency like this:
> >
> > libfoo
> > libfoo.so.1()(64bit)
> >
> > Has Fedora a policy against such redundant dependencies?
> >
> > Best regards
> > Georg
> > ___
> > 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
>
> Sightly related to the topic, is there an effective way to use
> pkgconfig(foo) for packages rather foo-devel?  It seems very few
> packages use that method.

I use the 'pkgconfig(foo)' style dependencies for BuildRequires in all
of my packages, where possible. I found that it's more robust,
especially when there are compat versions of libraries involved.

Since most of the projects that I maintain use either CMake (with
PkgConfig module) or meson, it's really easy to look up the names of
the required pkgconfig modules for the dependencies by just looking at
the upstream project's build system.

Fabio

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

Re: strange failures with gcc-9.0.1-0.11.fc31.x86_64

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 27, 2019 at 01:55:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> I'm trying to compile systemd in koji and mock, and I'm getting suspicious
> crashes...
> 
> $ valgrind x86_64-redhat-linux-gnu/test-terminal-util
> /* test_default_term_for_tty */
> ...
> /* test_read_one_char */
> ==21== Invalid read of size 4
> ==21==at 0x48C09EC: fputs (in /usr/lib64/libc-2.29.9000.so)
> ==21==by 0x109301: UnknownInlinedFun (test-terminal-util.c:43)
> ==21==by 0x109301: main (test-terminal-util.c:80)
> ==21==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==21== 
> ==21== 
> ==21== Process terminating with default action of signal 11 (SIGSEGV)
> 
> The problem is at this line, there is just a call to (a function which
> transitively calls) mkostemp(). It seems like the inlining is somehow
> going wrong.

It turns out that our test case was wrong. I was confused because the
inlining causes the backtrace to report an unrelated spot.

> Strangely, gdb also crashes:
> $ gdb x86_64-redhat-linux-gnu/test-terminal-util
> GNU gdb (GDB) Fedora 8.3.50.20190321-3.fc31
> ...
> Reading symbols from x86_64-redhat-linux-gnu/test-terminal-util...
> (gdb) r
> Starting program: 
> /builddir/build/BUILD/systemd-49bd196d693efe0acfc8d56c4e3d8f7ba9f91b5d/x86_64-redhat-linux-gnu/test-terminal-util
>  
> Missing separate debuginfos, use: dnf debuginfo-install 
> glibc-2.29.9000-8.fc31.x86_64
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> /* test_default_term_for_tty */
> ...
> /* test_read_one_char */
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77e759ec in fputs () from /lib64/libc.so.6
> Segmentation fault (core dumped)

This is still a problem. gdb crashes on any program in rawhide mock
for me right now. But gcc seems to be fine.

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

Re: [Test-Announce] Re: Fedora 30 Beta Go/No-Go meeting

[Silvia Sánchez]

Hi,

Just to say I won't be able to attend, sorry.

Regards,
Silvia
FAS:  Lailah




On Wed, 27 Mar 2019 at 15:55, Ben Cotton  wrote:

> Reminder: the Go/No-Go meeting for the Fedora 30 Beta release will be
> held TOMORROW, 2019-03-28 at 17:00 UTC in #fedora-meeting-1. For more
> information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
>
> View the meeting on Fedocal at:
> https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491
>
> --
> Ben Cotton
> Fedora Program Manager
> TZ=America/Indiana/Indianapolis
> Pronouns: he/him
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> test-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/test-annou...@lists.fedoraproject.org
> ___
> 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
>
___
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

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

On Wed, 27 Mar 2019 at 21:27, Jonathan Wakely 
wrote:

> On 26/03/19 11:40 +, Tomasz Kłoczko wrote:
> >On Tue, 26 Mar 2019 at 08:57, Jonathan Wakely 
> >wrote:
> >[..]
> >
> >> >What does this 42 means in this case? It means that during whole gcc
> build
> >> >are repeated 42 times some subset of *autoconf tests*. How it was
> possible
> >> >to loose that?!? 樂
> >> >gcc is quite monolithic and it should have only one configure.ac. Yes,
> >>
> >> Why?
> >>
> >
> >Really?
> >Really do you want me to answer on the question "why there is no any sense
> >repeat 42 times some tests on the source code configuration stage?" ??
>
> Yes, because you repeatedly make the mistake of assuming that one
> dimension of a problem is the only one that matters, and that all
> other considerations are irrelevant.
>

Just to be clear ..
So you want to say that I'm making mistake because I'm assuming that
speed/performance matters?
Could you please confirm that is is what you are thinking reading what I
wrote?
Could you please as well crush my assumption using logical arguments and
facts?

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

Re: Orphaned some Java packages

[Vít Ondruch]

Dne 28. 03. 19 v 0:48 Miro Hrončok napsal(a):
> On 05. 02. 19 11:07, Mikolaj Izdebski wrote:
>> I've just orphaned 259 packages listed below. Almost all of them are
>> Java packages which I will continue to maintain as part of modules.
>> Intent to orphan them was already announced on java-devel [1] and
>> devel [2] lists, with detailed reasoning.
>
> Hi Mikolaj,
>
> do you have some kind out outline about what packages are in what
> modules?
>
> I took over google-gson, but I see no stream branch.
>
> junit has javapackages branch
> https://src.fedoraproject.org/rpms/junit/commits/javapackages
>
> Is this the branch you use to build a module?
>
> A friend sent me a list of package they were able to find in a module
> by some dark magic. BTW what is the supported way to query this kind
> of information?
>
> You say almost all of the 259 Java packages will be maintained as part
> of modules, yet it's hard for me to find the rest.


Trying to take look from the other side, the java.yaml might need some
love [1], because the GH links are broken [2, 3]


Vít




[1] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml

[2] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_18

[3] https://src.fedoraproject.org/modules/java/blob/master/f/java.yaml#_19


>
> Thanks.
>
> ant-antlr: ant
> ant-apache-bcel: ant
> ant-apache-bsf: ant
> ant-apache-log4j: ant
> ant-apache-oro: ant
> ant-apache-regexp: ant
> ant-apache-resolver: ant
> ant-apache-xalan2: ant
> ant-commons-logging: ant
> ant-commons-net: ant
> ant-javamail: ant
> ant-jdepend: ant
> ant-jmf: ant
> ant-jsch: ant
> ant-junit5: ant
> ant-junit: ant
> ant-lib: ant
> ant-swing: ant
> ant-testutil: ant
> ant-xz: ant
> ant: ant
> antlr-C++-doc: ant
> antlr-tool: ant
> aopalliance: maven
> apache-commons-cli: maven
> apache-commons-codec: maven
> apache-commons-io: maven
> apache-commons-lang3: maven
> apache-commons-logging: ant
> apache-commons-logging: maven
> apache-commons-net: ant
> atinject: maven
> bcel: ant
> bsf: ant
> cdi-api: maven
> geronimo-annotation: maven
> glassfish-el-api: maven
> google-guice: maven
> guava20: maven
> hamcrest-core: ant
> hawtjni-runtime: maven
> hawtjni-runtime: scala
> httpcomponents-client: maven
> httpcomponents-core: maven
> jakarta-oro: ant
> jansi-native: maven
> jansi-native: scala
> jansi: maven
> jansi: scala
> javamail: ant
> jboss-interceptors-1.2-api: maven
> jcl-over-slf4j: maven
> jdepend: ant
> jline: scala
> jsch: ant
> jsoup: maven
> junit5: ant
> junit: ant
> jzlib: ant
> log4j12: ant
> maven-lib: maven
> maven-resolver-api: maven
> maven-resolver-connector-basic: maven
> maven-resolver-impl: maven
> maven-resolver-spi: maven
> maven-resolver-transport-wagon: maven
> maven-resolver-util: maven
> maven-shared-utils: maven
> maven-wagon-file: maven
> maven-wagon-http-shared: maven
> maven-wagon-http: maven
> maven-wagon-provider-api: maven
> maven: maven
> opentest4j: ant
> plexus-cipher: maven
> plexus-classworlds: maven
> plexus-containers-component-annotations: maven
> plexus-interpolation: maven
> plexus-sec-dispatcher: maven
> plexus-utils: maven
> python2-antlr: ant
> regexp: ant
> scala-apidoc: scala
> scala-swing: scala
> scala: scala
> sisu-inject: maven
> sisu-plexus: maven
> slf4j: maven
> univocity-parsers: ant
> xalan-j2: ant
> xerces-j2: ant
> xml-commons-apis: ant
> xml-commons-resolver: ant
> xz-java: ant
>
___
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

Re: Orphaning python-Lektor

[Sasa Savic]

On Wed, 2019-03-27 at 11:38 -0400, Charalampos Stratakis wrote:
> Not interested anymore in this package, feel free to reach me out if
> you'd like to take it, I'll orphan it this week.

I'm actively using Lektor so I'll take it off your shoulders gladly.
Thank you for your work on it. 

Br,
Saš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