[Bug 1829975] perl-LWP-Protocol-PSGI for EL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-LWP-Protocol-PSGI-0.11
   ||-2.el8
 Resolution|--- |ERRATA
Last Closed||2020-05-16 05:59:06



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-6c5f57733b has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Self Introduction: Dick Marinus

[Dick Marinus]

Hi!

I guess it finally happened; Itamar asked me if I'd help maintaining a
package in Fedora (pgcli).

I'm a long time Red Hat user (started with Red Hat 7.2) and switched to
Fedora (Core) when it was released. I've architected and maintained 500
Fedora Workstations used by a retailer in the Netherlands and ported a
kernel driver from SCO to Linux for interfacing with the cash registers.

I love programming and hacking on open source projects.

Nowadays I'm employed at a software vendor in my local town where we're
working on getting our software available as a SaaS product in the AWS
cloud.

I've posted specfiles for pgcli a long time ago and helped Terje Røsten
to maintain mycli (I'm a core developer at dbcli).


Greetings,
Dick Marinus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-05-16 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/16/report-389-ds-base-1.4.4.2-20200515git9afa669.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2020-05-18 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting for Monday. We met
the last several weeks and finally got through the whole agenda, I
don't have anything urgent new this week, and Monday's a holiday for
me :)

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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



--- Comment #11 from Colin Macdonald  ---
Maybe this is no longer relevant, but I tried to post this and got a midair
collision:

On rawhide-test.fedorainfracloud.org, I tried to reinstall kpathsea and got
some errors:

$ sudo dnf reinstall texlive-kpathsea

Downloading Packages:
texlive-kpathsea-20200327-2.fc33.x86_64.rpm   6.6 MB/s | 1.1 MB
00:00
--
Total 2.0 MB/s | 1.1 MB
00:00 
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing:   
  1/1 
  Reinstalling : texlive-kpathsea-7:20200327-2.fc33.x86_64 
  1/2 
  Cleanup  : texlive-kpathsea-7:20200327-2.fc33.x86_64 
  2/2 
  Running scriptlet: texlive-kpathsea-7:20200327-2.fc33.x86_64 
  2/2 
cat: /usr/share/texlive/texmf-dist/web2c/fmtutil-hdr.cnf: No such file or
directory
warning: %triggerpostun(texlive-kpathsea-7:20200327-2.fc33.x86_64) scriptlet
failed, exit status 1

Error in  scriptlet in rpm package texlive-kpathsea
/var/tmp/rpm-tmp.2wk3Qz: line 11: /usr/bin/updmap-sys: No such file or
directory

  Verifying: texlive-kpathsea-7:20200327-2.fc33.x86_64 
  1/2 
  Verifying: texlive-kpathsea-7:20200327-2.fc33.x86_64 
  2/2 

Reinstalled:
  texlive-kpathsea-7:20200327-2.fc33.x86_64 

Complete!


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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

Orion Poplawski  changed:

   What|Removed |Added

  Flags|needinfo?(spot@linuxpower.o |
   |rg) |



--- Comment #10 from Orion Poplawski  ---
https://koji.fedoraproject.org/koji/taskinfo?taskID=44557359


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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



--- Comment #9 from Orion Poplawski  ---
Yeah, I have a fix for this coming shortly -
https://bugzilla.redhat.com/show_bug.cgi?id=1836464


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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

Colin Macdonald  changed:

   What|Removed |Added

 CC||s...@linuxpower.org
  Flags||needinfo?(spot@linuxpower.o
   ||rg)



--- Comment #8 from Colin Macdonald  ---
The test looks for plain.tex.

On Fedora 32:

$ kpsewhich plain.tex
/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex


On Rawhide, it doesn't return anything, even thought that file exists:


$ kpsewhich plain.tex
$
$ ls /usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex


Tom has something changed after the texlive upgrade?


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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



--- Comment #7 from Colin Macdonald  ---
Thanks!  @spot and @orion have done a lot.  There is a failing test I'm looking
at now:

```
t/utils.t . 
1..82
ok 1 - File location - 1
ok 2 - File location - 2
ok 3 - File location - 3
ERROR - Cannot find 'plain.tex'!
# Looks like your test exited with 2 just after 3.
Dubious, test returned 2 (wstat 512, 0x200)
Failed 79/82 subtests 
```


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Incompatible upgrade for oniguruma in EPEL 7

[Jeff Sheltren]

On Fri, May 15, 2020 at 4:19 PM Kevin Fenzi  wrote:

> On Fri, May 15, 2020 at 03:59:57PM -0500, Carl George wrote:
>
> > Let me know your thoughts and concerns about moving forward with this.
>
> +1 here and thanks for making epel a safer place.
>
>
+1, thanks!

-Jeff
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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 bugzilla / component listing limited

[Leon Fauster]

Am 15.05.20 um 22:04 schrieb Troy Dawson:

On Fri, May 15, 2020 at 12:39 PM Leon Fauster
 wrote:


I wanted to request a new EPEL package and noticed that it is not
possible to select the package name (fedora) in the component field
in the bug report form (Product: Fedora EPEL). Is this enforced or is
this a regression? I remember making such requests without problem.

The targeted package in request is: xdg-dbus-proxy

Any ideas?



If a package has never been in EPEL before, it isn't listed in
Product: Fedora EPEL.
I don't know if this is "enforced", it's just the way it is.
If a package was ever in EPEL, going back to EPEL5 or possibly 4, it's
listed.  But if it never has been (such as xdg-dbus-proxy) then it
isn't listed and you have to go through Fedora -> Fedora to request
it.


Okay, thanks to clarifying it. I will try that path ...

--
Leon





___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] EPEL bugzilla / component listing limited

[Leon Fauster]

I wanted to request a new EPEL package and noticed that it is not
possible to select the package name (fedora) in the component field
in the bug report form (Product: Fedora EPEL). Is this enforced or is
this a regression? I remember making such requests without problem.

The targeted package in request is: xdg-dbus-proxy

Any ideas?

--
Thanks,
Leon
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1836456] New: perl-PkgConfig-LibPkgConf-0.11 is available

[bugzilla]

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

Bug ID: 1836456
   Summary: perl-PkgConfig-LibPkgConf-0.11 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PkgConfig-LibPkgConf
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.11
Current version/release in rawhide: 0.10-5.fc32
URL: http://search.cpan.org/dist/PkgConfig-LibPkgConf/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/13749/


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Miro Hrončok]

On 15. 05. 20 20:12, Charalampos Stratakis wrote:

Hello everyone,

As of Python 3.8, python C extensions modules should not link to libpython, 
unless they embed the interpreter in their code. Relevant upstream 
PR:https://github.com/python/cpython/pull/12946
If your package links to libpython without requiring it, it won't be possible 
to use the python3-debug binary with your python C extension, unless you 
recompile the extension against it.

On Fedora Rawhide, there are at this point 144 packages linking to libpython, 
many of those possibly without any need for it.

If your package links to libpython but it does not embed the interpreter, I 
would like to ask you to unlink it. Usually the fix needs to be done at the 
package's build system.

If you are not sure if your package links to libpython, a way to figure this 
out  is to inspect the code for the Py_Initialize and the Py_Finalize calls 
[0]. If the code includes those calls, no action is required from your side. If 
it does not, linking to libpython is not required.

I might mass file bugzillas at a later date, but I wanted to provide you the 
heads up before that.

[0]https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter

List of possibly affected packages, provided through $ repoquery --repo=rawhide 
--source --whatrequires 'libpython3.8.so.1.0()(64bit)'


This is a list of packages that require libpython3.8.so.1.0()(64bit) but don't 
requires python(abi) (well, list of the components):


blender
calamares
cantor
collectd
freecad
gdb
getdp
glade
globus-net-manager
gplugin
hexchat
insight
Io-language
kdevelop-python
kig
kitty
krita
libpeas
libsigrokdecode
nautilus-python
nbdkit
nextpnr
nwchem
paraview
perl-Inline-Python
pidgin
postgresql
pynac
pyotherside
python-caja
renderdoc
scribus
sigil
swift-lang
syslog-ng
texworks
thunarx-python
trellis
vdr-epg-daemon
vim
weechat
znc

Those are more likely to actually link to libpython for a good reason.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Incompatible upgrade for oniguruma in EPEL 7

[Kevin Fenzi]

On Fri, May 15, 2020 at 03:59:57PM -0500, Carl George wrote:
> The current version of oniguruma in EPEL 7 is affected by multiple CVEs.
> 
> * rhbz#1466750 - CVE-2017-9224 CVE-2017-9225 CVE-2017-9226
> CVE-2017-9227 CVE-2017-9228 CVE-2017-9229
> * rhbz#1728967 - CVE-2019-13225
> * rhbz#1728972 - CVE-2019-13224
> * rhbz#1768999 - CVE-2019-16163
> * rhbz#1770213 - CVE-2019-16161
> * rhbz#1777538 - CVE-2019-19246
> * rhbz#1802053 - CVE-2019-19012
> * rhbz#1802063 - CVE-2019-19203
> * rhbz#1802072 - CVE-2019-19204
> 
> I've discussed doing an incompatible upgrade of the package with the
> other maintainers (rhbz#1777660), and so far no one is opposed to it.
> As far as I can tell, the only package that would need to be rebuilt
> is jq.
> 
> ```
> [root@c7-container:~]# repoquery --provides oniguruma | grep '\.so'
> libonig.so.2()(64bit)
> [root@c7-container:~]# repoquery --whatrequires 'libonig.so.2()(64bit)'
> jq-0:1.6-1.el7.x86_64
> oniguruma-devel-0:5.9.5-3.el7.x86_64
> [root@c7-container:~]# repoquery --quiet --disablerepo \*
> --queryformat '%{name}' --archlist src --enablerepo
> epel-source,epel-testing-source --whatrequires oniguruma-devel
> jq
> ```
> 
> Let me know your thoughts and concerns about moving forward with this.

+1 here and thanks for making epel a safer place. 

kevin


signature.asc
Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Jerry James]

On Fri, May 15, 2020 at 12:12 PM Charalampos Stratakis
 wrote:
> cvc4 brouhaha jjames

The cvc4 package has been fixed in Rawhide.  I'll talk to upstream about it.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Incompatible upgrade for oniguruma in EPEL 7

[Carl George]

The current version of oniguruma in EPEL 7 is affected by multiple CVEs.

* rhbz#1466750 - CVE-2017-9224 CVE-2017-9225 CVE-2017-9226
CVE-2017-9227 CVE-2017-9228 CVE-2017-9229
* rhbz#1728967 - CVE-2019-13225
* rhbz#1728972 - CVE-2019-13224
* rhbz#1768999 - CVE-2019-16163
* rhbz#1770213 - CVE-2019-16161
* rhbz#1777538 - CVE-2019-19246
* rhbz#1802053 - CVE-2019-19012
* rhbz#1802063 - CVE-2019-19203
* rhbz#1802072 - CVE-2019-19204

I've discussed doing an incompatible upgrade of the package with the
other maintainers (rhbz#1777660), and so far no one is opposed to it.
As far as I can tell, the only package that would need to be rebuilt
is jq.

```
[root@c7-container:~]# repoquery --provides oniguruma | grep '\.so'
libonig.so.2()(64bit)
[root@c7-container:~]# repoquery --whatrequires 'libonig.so.2()(64bit)'
jq-0:1.6-1.el7.x86_64
oniguruma-devel-0:5.9.5-3.el7.x86_64
[root@c7-container:~]# repoquery --quiet --disablerepo \*
--queryformat '%{name}' --archlist src --enablerepo
epel-source,epel-testing-source --whatrequires oniguruma-devel
jq
```

Let me know your thoughts and concerns about moving forward with this.

-- 
Carl George
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: TeXLive 2020 landing in rawhide

[Tom Callaway]

I'm hoping that when texlive is able to fully install this issue will go
away. I just got a successful build for -21 that _should_ resolve all the
broken deps except for biber.

Tom

On Fri, May 15, 2020 at 10:33 AM Orion Poplawski  wrote:

> On 5/14/20 10:48 PM, Orion Poplawski wrote:
> > On 5/14/20 3:55 PM, Tom Callaway wrote:
> >> I've just kicked off new builds for texlive and texlive-base for
> >> TeXLive 2020 in rawhide. Hopefully, everything that depends on them
> >> will continue to work, but if you notice any new issues generating
> >> docs (or any missing components or broken dependencies), feel free to
> >> email me or open Bugzilla tickets.
> >
> > I'm working on trying to fix the biber failure.  It's an odd one that I
> > cannot reproduce locally in mock.  What I've been able to determine is
> > that is appears that the "ls-R" files are not present in the koji
> > buildroots for some reason.  Perhaps this is an arch dependent thing
> > since I seem to be landing on armv7 builders all the time.
>
> Well, it fails on an x86 builder as well so that's not it.  I think
> we're going to need to remove the stderr redirects and maybe add some
> debugging in the scriptlets that build the ls-R files to try to see
> what's failing there.  But I think I'll leave this to others.
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
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 bugzilla / component listing limited

[Troy Dawson]

On Fri, May 15, 2020 at 12:39 PM Leon Fauster
 wrote:
>
> I wanted to request a new EPEL package and noticed that it is not
> possible to select the package name (fedora) in the component field
> in the bug report form (Product: Fedora EPEL). Is this enforced or is
> this a regression? I remember making such requests without problem.
>
> The targeted package in request is: xdg-dbus-proxy
>
> Any ideas?
>

If a package has never been in EPEL before, it isn't listed in
Product: Fedora EPEL.
I don't know if this is "enforced", it's just the way it is.
If a package was ever in EPEL, going back to EPEL5 or possibly 4, it's
listed.  But if it never has been (such as xdg-dbus-proxy) then it
isn't listed and you have to go through Fedora -> Fedora to request
it.

Troy
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Miro Hrončok]

On 15. 05. 20 20:12, Charalampos Stratakis wrote:

libarcus churchyard gferon
libarcus-lulzbot spot
libsavitar   churchyard gferon


I know for sure those packages link to libpython unnecessarily just because 
their cmake build script does so. The fix is simple:


https://src.fedoraproject.org/rpms/libarcus/pull-request/8

But I didn't want to carry this downstream only and my cmake skills are 
basically zero, so I don't know how to adapt the cmake file to support both 
pre-3.8 and 3.8+ use cases (which is necessary to make the fix upstreamable).


Help from cmake experts would be appreciated.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Jorge Gallegos]

Hi,

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> Hello everyone,
> 
> As of Python 3.8, python C extensions modules should not link to libpython, 
> unless they embed the interpreter in their code. Relevant upstream PR: 
> https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be possible 
> to use the python3-debug binary with your python C extension, unless you 
> recompile the extension against it.
> 
> On Fedora Rawhide, there are at this point 144 packages linking to libpython, 
> many of those possibly without any need for it.
> 
> If your package links to libpython but it does not embed the interpreter, I 
> would like to ask you to unlink it. Usually the fix needs to be done at the 
> package's build system.
> 
> If you are not sure if your package links to libpython, a way to figure this 
> out  is to inspect the code for the Py_Initialize and the Py_Finalize calls 
> [0]. If the code includes those calls, no action is required from your side. 
> If it does not, linking to libpython is not required.
> 
> I might mass file bugzillas at a later date, but I wanted to provide you the 
> heads up before that.
> 
> [0] 
> https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter
> 
> List of possibly affected packages, provided through $ repoquery 
> --repo=rawhide --source --whatrequires 'libpython3.8.so.1.0()(64bit)'
> 
> Maintainers by package:
> 
> COPASI   sagitter
> HepMC3   ellert
> Io-language  limb
> OpenImageIO  hobbes1069
> PyQt4rdieter than
> YafaRay  luya roma slaanesh
> apbs rathann sagitter
> babeltrace2  mjeanson
> blender  design-sw hobbes1069 ignatenkobrain kwizart luya roma 
> s4504kr slaanesh
> boostdenisarnaud jwakely
> calamareskkofler mattia
> calibre  chkr heliocastro kevin nushio zbyszek
> cantor   jreznik rdieter than
> ceph adeza branto dmick ke4qqq kkeithle ktdreyer steve 
> stingray
> clingo   thofmann
> collectd fab kevin mhlavink ruben xaeth
> condor   bbockelm bcotton eerlands matt matyas stevetraylen 
> tstclair ttheisen valtri
> createrepo_c dmach jrohel mblaha pkratoch tmlcoch
> csound   pbrobinson sdz
> cvc4 brouhaha jjames
> dionaea  rebus
> dmlite   adev andreamanzi gbitzes okeeble rocha
> fontforgefrixxon kevin pnemade
> freecad  hobbes1069 jkastner zultron
> gdb  jankratochvil keiths kevinb sergiodj
> gdcm ankursinha ignatenkobrain mrceresa sebp
> gdl  orion
> getdpignatenkobrain smani
> gladekalev
> globus-net-manager   ellert
> glom hguemar
> gnucash  notting
> gnuradio jskarvad mmahut
> gpaw marcindulak
> gplugin  ignatenkobrain
> gr-air-modes jskarvad
> gr-fcdproplusjskarvad
> gr-hpsdr jskarvad
> gr-iqbal jskarvad
> gr-osmosdr   cottsay jskarvad
> gr-rds   jskarvad sharkcz
> hamlib   hobbes1069 jskarvad lucilanga
> hexchat  ohaessler tingping
> hokuyoaist   rmattes
> huginbpostle cicku denisarnaud
> insight  lkundrak monnerat
> kdevelop-python  dvratil jgrulich minh
> kernel-tools jcline jforbes jwboyer labbott pbrobinson
> kicadavigne coremodule lkundrak stevenfalco tnorth
> kig  jreznik kkofler rdieter
> kittyatim
> kritaheliocastro rdieter
> lammps   ellio167 junghans
> ldns pemensik pwouters thozza
> libCombine   sagitter
> libarcus churchyard gferon
> libarcus-lulzbot spot
> libbatch smani
> libcec   pbrobinson
> libcomps akozumpl dmach jluza jmracek mblaha pkratoch
> libdnf   dmach jmracek jrohel mblaha pkratoch
> libftdi  hobbes1069 lucilanga
> libkml   smani
> libkolabxml  tpokorra
> libldb   abbra asn gd iboukris jhrozek lslebodn sgallagh simo
> libnuml  sagitter
> libpeas  amigadave hadess nacho
> libplist hadess pbrobinson
> libreoffice  caolanm dtardon erack sbergmann
> librepo  dmach pkratoch tmlcoch
> libsavitar   churchyard gferon
> libsbml  sagitter zbyszek
> libsedml sagitter
> libsigrokdecode  mrnuke
> libtallocasn gd iboukris jhrozek lslebodn sgallagh simo
> libyang  tkorbar
> libyui-bindings  makowski ngompa tpokorra
> link-grammar devos fabiand limb
> lldb airlied daveisfera jankratochvil sergesanspaille 
> siddharths 

Re: HEADS UP: icu 67 coming to rawhide

[Eike Rathke]

Hi Pete,

On Friday, 2020-05-15 09:57:35 +0100, Pete Walter wrote:

>I am in the process of updating icu from 65.1 to 67.1 in rawhide. This
>comes with a soname bump, but as usual, I'm including a compat package

Thanks a lot!

On Monday I did the necessary changes in LibreOffice to be able to build
against ICU 66|67 so that should land soon in rawhide as well.

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1836390] New: perl-GnuPG-Interface-1.00 is available

[bugzilla]

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

Bug ID: 1836390
   Summary: perl-GnuPG-Interface-1.00 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-GnuPG-Interface
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, fed...@mj41.cz,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.00
Current version/release in rawhide: 0.52-16.fc33
URL: http://search.cpan.org/dist/GnuPG-Interface/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/12665/


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Charalampos Stratakis]

- Original Message -
> From: "Richard W.M. Jones" 
> To: "Charalampos Stratakis" 
> Cc: "Development discussions related to Fedora" 
> , ebl...@redhat.com
> Sent: Friday, May 15, 2020 8:50:31 PM
> Subject: Re: Many packages unnecessarily link to libpython
> 
> On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> > nbdkit   rjones
> 
> I guess nbdkit is one of the good ones?  We link to libpython because
> we want to run Python code from a C main program (nbdkit, an NBD
> server written in C).
> 
> http://libguestfs.org/nbdkit-python-plugin.3.html
> http://libguestfs.org/nbdkit.1.html
> https://en.wikipedia.org/wiki/Network_block_device
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> 

By having a quick glance at plugins/python/python.c it seems that indeed nbdkit 
is required to link to libpython.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Richard W.M. Jones]

On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> nbdkit   rjones

I guess nbdkit is one of the good ones?  We link to libpython because
we want to run Python code from a C main program (nbdkit, an NBD
server written in C).

http://libguestfs.org/nbdkit-python-plugin.3.html
http://libguestfs.org/nbdkit.1.html
https://en.wikipedia.org/wiki/Network_block_device

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned apache-commons-vfs

[Fabio Valentini]

Hi all,

I have just orphaned apache-commons-vfs. The package is working and
up-to-date, but the Stewardship SIG no longer requires it. Only one
fedora package still depends on it in rawhide -
apache-commons-configuration - which is itself not required by
anything in rawhide, and which already has other broken dependencies -
so probably both packages can be safely removed.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Many packages unnecessarily link to libpython

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-05-15 at 14:12 -0400, Charalampos Stratakis wrote:
> Hello everyone,
Hey,

> As of Python 3.8, python C extensions modules should not link to
> libpython, unless they embed the interpreter in their code. Relevant
> upstream PR: https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be
> possible to use the python3-debug binary with your python C
> extension, unless you recompile the extension against it.
> 
> On Fedora Rawhide, there are at this point 144 packages linking to
> libpython, many of those possibly without any need for it.
> 
> If your package links to libpython but it does not embed the
> interpreter, I would like to ask you to unlink it. Usually the fix
> needs to be done at the package's build system.
> 
> If you are not sure if your package links to libpython, a way to
> figure this out  is to inspect the code for the Py_Initialize and the
> Py_Finalize calls [0]. If the code includes those calls, no action is
> required from your side. If it does not, linking to libpython is not
> required.
> 
> I might mass file bugzillas at a later date, but I wanted to provide
> you the heads up before that.
> 
> [0] 
> https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter
> 
> List of possibly affected packages, provided through $ repoquery --
> repo=rawhide --source --whatrequires 'libpython3.8.so.1.0()(64bit)'
> 
> Maintainers by package:
> 
> COPASI   sagitter
> HepMC3   ellert
> Io-language  limb
> OpenImageIO  hobbes1069
> PyQt4rdieter than
> YafaRay  luya roma slaanesh
> apbs rathann sagitter
> babeltrace2  mjeanson
> blender  design-sw hobbes1069 ignatenkobrain kwizart luya
> roma s4504kr slaanesh
I think this embeds python interp for plugins, but not sure.

> boostdenisarnaud jwakely
> calamareskkofler mattia
> calibre  chkr heliocastro kevin nushio zbyszek
> cantor   jreznik rdieter than
> ceph adeza branto dmick ke4qqq kkeithle ktdreyer
> steve stingray
> clingo   thofmann
> collectd fab kevin mhlavink ruben xaeth
> condor   bbockelm bcotton eerlands matt matyas
> stevetraylen tstclair ttheisen valtri
> createrepo_c dmach jrohel mblaha pkratoch tmlcoch
> csound   pbrobinson sdz
> cvc4 brouhaha jjames
> dionaea  rebus
> dmlite   adev andreamanzi gbitzes okeeble rocha
> fontforgefrixxon kevin pnemade
> freecad  hobbes1069 jkastner zultron
> gdb  jankratochvil keiths kevinb sergiodj
> gdcm ankursinha ignatenkobrain mrceresa sebp
> gdl  orion
> getdpignatenkobrain smani
I'll check it.

> gladekalev
> globus-net-manager   ellert
> glom hguemar
> gnucash  notting
> gnuradio jskarvad mmahut
> gpaw marcindulak
> gplugin  ignatenkobrain
I believe this one needs it.

> gr-air-modes jskarvad
> gr-fcdproplusjskarvad
> gr-hpsdr jskarvad
> gr-iqbal jskarvad
> gr-osmosdr   cottsay jskarvad
> gr-rds   jskarvad sharkcz
> hamlib   hobbes1069 jskarvad lucilanga
> hexchat  ohaessler tingping
> hokuyoaist   rmattes
> huginbpostle cicku denisarnaud
> insight  lkundrak monnerat
> kdevelop-python  dvratil jgrulich minh
> kernel-tools jcline jforbes jwboyer labbott pbrobinson
> kicadavigne coremodule lkundrak stevenfalco tnorth
> kig  jreznik kkofler rdieter
> kittyatim
> kritaheliocastro rdieter
> lammps   ellio167 junghans
> ldns pemensik pwouters thozza
> libCombine   sagitter
> libarcus churchyard gferon
> libarcus-lulzbot spot
> libbatch smani
> libcec   pbrobinson
> libcomps akozumpl dmach jluza jmracek mblaha pkratoch
> libdnf   dmach jmracek jrohel mblaha pkratoch
> libftdi  hobbes1069 lucilanga
> libkml   smani
> libkolabxml  tpokorra
> libldb   abbra asn gd iboukris jhrozek lslebodn sgallagh
> simo
> libnuml  sagitter
> libpeas  amigadave hadess nacho
> libplist hadess pbrobinson
> libreoffice  caolanm dtardon erack sbergmann
> librepo  dmach pkratoch tmlcoch
> libsavitar   churchyard gferon
> libsbml  sagitter zbyszek
> libsedml sagitter
> libsigrokdecode  mrnuke
> libtallocasn gd iboukris jhrozek lslebodn sgallagh simo
> libyang  tkorbar
> libyui-bindings  makowski ngompa 

Many packages unnecessarily link to libpython

[Charalampos Stratakis]

Hello everyone,

As of Python 3.8, python C extensions modules should not link to libpython, 
unless they embed the interpreter in their code. Relevant upstream PR: 
https://github.com/python/cpython/pull/12946
If your package links to libpython without requiring it, it won't be possible 
to use the python3-debug binary with your python C extension, unless you 
recompile the extension against it.

On Fedora Rawhide, there are at this point 144 packages linking to libpython, 
many of those possibly without any need for it.

If your package links to libpython but it does not embed the interpreter, I 
would like to ask you to unlink it. Usually the fix needs to be done at the 
package's build system.

If you are not sure if your package links to libpython, a way to figure this 
out  is to inspect the code for the Py_Initialize and the Py_Finalize calls 
[0]. If the code includes those calls, no action is required from your side. If 
it does not, linking to libpython is not required.

I might mass file bugzillas at a later date, but I wanted to provide you the 
heads up before that.

[0] 
https://docs.python.org/3/c-api/init.html#initializing-and-finalizing-the-interpreter

List of possibly affected packages, provided through $ repoquery --repo=rawhide 
--source --whatrequires 'libpython3.8.so.1.0()(64bit)'

Maintainers by package:

COPASI   sagitter
HepMC3   ellert
Io-language  limb
OpenImageIO  hobbes1069
PyQt4rdieter than
YafaRay  luya roma slaanesh
apbs rathann sagitter
babeltrace2  mjeanson
blender  design-sw hobbes1069 ignatenkobrain kwizart luya roma 
s4504kr slaanesh
boostdenisarnaud jwakely
calamareskkofler mattia
calibre  chkr heliocastro kevin nushio zbyszek
cantor   jreznik rdieter than
ceph adeza branto dmick ke4qqq kkeithle ktdreyer steve stingray
clingo   thofmann
collectd fab kevin mhlavink ruben xaeth
condor   bbockelm bcotton eerlands matt matyas stevetraylen 
tstclair ttheisen valtri
createrepo_c dmach jrohel mblaha pkratoch tmlcoch
csound   pbrobinson sdz
cvc4 brouhaha jjames
dionaea  rebus
dmlite   adev andreamanzi gbitzes okeeble rocha
fontforgefrixxon kevin pnemade
freecad  hobbes1069 jkastner zultron
gdb  jankratochvil keiths kevinb sergiodj
gdcm ankursinha ignatenkobrain mrceresa sebp
gdl  orion
getdpignatenkobrain smani
gladekalev
globus-net-manager   ellert
glom hguemar
gnucash  notting
gnuradio jskarvad mmahut
gpaw marcindulak
gplugin  ignatenkobrain
gr-air-modes jskarvad
gr-fcdproplusjskarvad
gr-hpsdr jskarvad
gr-iqbal jskarvad
gr-osmosdr   cottsay jskarvad
gr-rds   jskarvad sharkcz
hamlib   hobbes1069 jskarvad lucilanga
hexchat  ohaessler tingping
hokuyoaist   rmattes
huginbpostle cicku denisarnaud
insight  lkundrak monnerat
kdevelop-python  dvratil jgrulich minh
kernel-tools jcline jforbes jwboyer labbott pbrobinson
kicadavigne coremodule lkundrak stevenfalco tnorth
kig  jreznik kkofler rdieter
kittyatim
kritaheliocastro rdieter
lammps   ellio167 junghans
ldns pemensik pwouters thozza
libCombine   sagitter
libarcus churchyard gferon
libarcus-lulzbot spot
libbatch smani
libcec   pbrobinson
libcomps akozumpl dmach jluza jmracek mblaha pkratoch
libdnf   dmach jmracek jrohel mblaha pkratoch
libftdi  hobbes1069 lucilanga
libkml   smani
libkolabxml  tpokorra
libldb   abbra asn gd iboukris jhrozek lslebodn sgallagh simo
libnuml  sagitter
libpeas  amigadave hadess nacho
libplist hadess pbrobinson
libreoffice  caolanm dtardon erack sbergmann
librepo  dmach pkratoch tmlcoch
libsavitar   churchyard gferon
libsbml  sagitter zbyszek
libsedml sagitter
libsigrokdecode  mrnuke
libtallocasn gd iboukris jhrozek lslebodn sgallagh simo
libyang  tkorbar
libyui-bindings  makowski ngompa tpokorra
link-grammar devos fabiand limb
lldb airlied daveisfera jankratochvil sergesanspaille 
siddharths tstellar
mapserverdevrim jujens oliver pali
mathgl   deji krege mycae
med  smani
mod_wsgi jdornak jkaluza jorton lmacken mrunge
mraa pbrobinson
nautilus-python  dignan genodeftest kalev
nbdkit   rjones
nemo-extensions  

[EPEL-devel] Re: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Troy Dawson]

On Fri, May 15, 2020 at 10:37 AM Michel Alexandre Salim
 wrote:
> Or have a "purgatory" repo where packages retired in EL 8.2 get to live
> until, say, a month after CentOS 8.2 is GA? Again, seems like too much work.
>

Or, perhaps we could archive things before a release.
I guess my reply got trimmed off and/or ignored.

There is the EPEL archives.

This is fairly recent, but we did a snapshot of 8.1 a bit before 8.2 came out.
We plan on doing this for each minor release (7 and 8).
Fedora Archives are not on all the mirrors, so it might be a little
slower, depending on where you get it from, but at least it's there.

https://archives.fedoraproject.org/pub/archive/epel/8.1/

Troy
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Michel Alexandre Salim]

On 5/14/20 4:59 PM, Nico Kadel-Garcia wrote:


It's an ongoing problem. EPEL's decision to show only the most recent
versions of RPMs, and to trim old RPMs out, is a destabilizing problem
and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
internal access to old packages.


So that's a problem we have with Fedora (e.g. hardware regressions 
preventing some hardware from being in the latest kernel, *but* if they 
were not updating often enough, the last known-good version might not be 
available anymore unless you pull from Koji).


But it does not really apply to the EPEL retirement. If a decision is 
made to retire packages for a given branch, it does not matter how many 
versions you keep, they will all be retired, right?


Perhaps having additional metadata in dist-git (e.g. "retire from EL 8.2 
onwards") would allow maintainers to keep building as normal, we can 
publish epel/8-all, epel/8.1, epel/8.2 etc. repos where the first repo 
has all packages, and the others have symlinks to 8-all but filtering 
out the retired packages?


But that won't work if there are ABI incompatibilities... so yeah, 
overall I think the best solution is to just try and get CentOS releases 
out of the door sooner rather than later.


Or have a "purgatory" repo where packages retired in EL 8.2 get to live 
until, say, a month after CentOS 8.2 is GA? Again, seems like too much work.


In our case, hopefully this is a one-off (it's because we deploy 
RPM-with-zstd internally).


--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:33:47 -0500, you wrote:

>* Game developers largely refuse to support Linux, and the some of the 
>few that have have or are currently pulling support citing 
>fragmentation(support) issues.

Game developers refuse to support Linux because there is no userbase -
even Steam, who moved to Linux for strategic rather than financial
reasons, consistently reports a neglible installed base of Linux
gamers.

The fragmentation may not help, but it isn't the driving force (if
Linux gaming was a $10billion a year business they would find a way to
deal with the issues).

>* Hardware support for AMD GPUs is all over the place and even if 
>technically supported, can be too buggy to use. This is largely because 
>kernel/mesa versions are all over the place.

Surprise, writing drivers and the associated code for modern GPU's is
hard - even for the in house development teams providing binary only
drivers, as anyone who follows GPU issues on Windows is aware.

>* You often need to install third-party repos to get up-to-date software 
>since packages are way too slow, or the distros just choose to use very 
>old software(Debian).

Part of choosing a distro is choosing new vs well tested.

Anyone choosing the released versions of Debian is doing so on the
basis they want well tested releases and new versions aren't a
priority.

If you want new version, you choose a different distro.

>* Bugs fixed in newer versions of Gnome shell aren't backported to older 
>versions. It looks like they have extended support, but I doubt it's for 
>the same amount of time Ubuntu supports an LTS. Even if it did, only 
>newer Gnome shell versions are supported for that long. 18.04 probably 
>has shell bugs right now that are fixed in newer Gnome versions.

Not a Gnome problem (says a person who doesn't even like Gnome
anymore).

When Ubuntu/Red Hat/CentOS/etc release whatever their variation of a
distro with a long support lifetime is they take on the burden of
supporting the software for the duration of that release, not the
upstream.

So in your complaint, it is not up to Gnome to continue supporting
that version of Gnome, it is up to Ubuntu to backport/create fixes as
necessary - that is after all the whole point of offering a LTS
release that people pay Ubuntu to provide support on.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Thu, 14 May 2020 06:59:47 -0500, you wrote:

>What i'm saying is: Distros like Fedora actively hurt the very people 
>who are directly or indirectly helping them. There are single-person run 
>projects, like mine, out there that can't possibly do all the work 
>needed to have a dozen packages for each distro. It's just not possible 
>or, in the case of Java based projects, not even needed to begin with.

1) nobody is forcing upstream developers to package their projects -
that's what the packagers in the various distrobutions do.

2) the fact that people want to package the Java packages, and that
other people want to install those packages, indicates that there is a
need.

>That is to say nothing of those distros doing things like Fedora now 
>does like running X as user which break otherwise perfectly running 
>applications. 

Running X as a user would be a change done to decrease the security
risk of running applications using X, or X itself.

It is the type of change that anyone should expect a distribution to
make, and the type of change even Apple and Microsoft make (anyone who
used Windows in the past will recall the applications that insisted on
being run as an Administrator for no valid reason, and eventually
Microsoft learned the hard way and cracked down - I am sure just like
you seem to be a lot of Windows developers made the same false claim
that MS was breaking otherwise perfectly running applications.

>I can't check in every 6 months to make sure y'all didn't 
>break something.

Then perhaps you need to look for a different hobby/career?

The software development field is full of constant change that
developers need to be aware of regardless of OS or environment.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32: samba 4.12.2: Problem with access from win10b to win10a via remote desktop

[Dario Lesca]

I have a test environment for test samba AD MIT kerberos out of the box

I have a AD-DC samba on Fedora 32 (addc1), a Centos 8 member server
(centos8) and two PC windows 10 (win10a and win10b), fedora.loc is the
AD domain name

All work fine except access from windows to windows with remote
desktop. I work with administra...@fedora.loc and when I try to accessI get a 
password request for this user and  

This is what I get into /var/log/samba/mit_kdc.log:

mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), 
UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.122.102: 
NEEDED_PREAUTH: Administrator@FEDORA for krbtgt/FEDORA@FEDORA, Additional 
pre-authentication required
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): AS_REQ (6 etypes 
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), 
UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.122.102: ISSUE: 
authtime 1589554729, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, 
Administrator@FEDORA for krbtgt/FEDORA@FEDORA
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): TGS_REQ (5 etypes 
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24), 
UNSUPPORTED:(-135)}) 192.168.122.102: ISSUE: authtime 1589554729, etypes 
{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), 
ses=aes256-cts-hmac-sha1-96(18)}, administra...@fedora.loc for 
TERMSRV/win...@fedora.loc
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): TGS_REQ 192.168.122.102: 
2ND_TKT_MISMATCH: authtime 1589554729, administra...@fedora.loc for 
TERMSRV/win...@fedora.loc, 2nd tkt client WIN10A$@FEDORA.LOC
mag 15 16:58:49 addc1.fedora.loc krb5kdc[821](info): closing down fd 19

If I access via file manager (\\win10a\share) from window to a shared
folder on another windows it work.

If I try to access to win10a from fedora addc1 server with xfreerdp
utility I can access without problem, this is the log:

[lesca@addc1 ~]$ xfreerdp  /u:administra...@fedora.loc /v:win10a.fedora.loc
[18:01:32:549] [2340:2341] [INFO][com.freerdp.core] - 
freerdp_connect:freerdp_set_last_error_ex resetting error state
[18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx rdpdr
[18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx rdpsnd
[18:01:32:549] [2340:2341] [INFO][com.freerdp.client.common.cmdline] - loading 
channelEx cliprdr
[18:01:35:857] [2340:2341] [INFO][com.freerdp.primitives] - primitives 
autodetect, using optimized
[18:01:35:864] [2340:2341] [INFO][com.freerdp.core] - 
freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error 
state
[18:01:35:867] [2340:2341] [INFO][com.freerdp.core] - 
freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[18:01:35:886] [2340:2341] [WARN][com.freerdp.crypto] - Certificate 
verification failure 'unable to get local issuer certificate (20)' at stack 
position 0
[18:01:35:886] [2340:2341] [WARN][com.freerdp.crypto] - CN = win10a.fedora.loc
Password: 
[18:01:39:264] [2340:2341] [INFO][com.freerdp.gdi] - Local framebuffer format  
PIXEL_FORMAT_BGRX32
[18:01:39:265] [2340:2341] [INFO][com.freerdp.gdi] - Remote framebuffer format 
PIXEL_FORMAT_RGB16
[18:01:40:343] [2340:2341] [INFO][com.winpr.clipboard] - initialized POSIX 
local file subsystem
[18:01:41:829] [2340:2341] [INFO][com.freerdp.channels.rdpsnd.client] - Loaded 
fake backend for rdpsnd
[18:02:12:906] [2340:2341] [INFO][com.freerdp.core] - 
rdp_set_error_info:freerdp_set_last_error_ex resetting error state
[18:02:12:906] [2340:2347] [WARN][com.freerdp.channels.cliprdr.common] - 
[cliprdr_packet_format_list_new] called with invalid type 
 
Is this a know issue or it is a bugs?

If you need some other informations let me know

Many thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 32 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-05-15 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/15/report-389-ds-base-1.4.4.2-20200515git1ba7370.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Orhpaning rubygem-inflecto

[Vít Ondruch]

This package is deprecated upstream, nothing depends on it and I have no
use for it, therefore I orphaning the package.


VĂ­t

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

Re: Another libxc soname bump...

[Marcin Dulak]

FYI: elk developers have been informed about the upcoming libxc bugfix
release, and elk is tracked here
https://bugzilla.redhat.com/show_bug.cgi?id=1831479
GPAW is tracked here https://bugzilla.redhat.com/show_bug.cgi?id=1830675
I've orphaned exciting, since there was not much collaboration from the
developers.

On Fri, May 15, 2020 at 11:44 AM Susi Lehtola <
jussileht...@fedoraproject.org> wrote:

> On Fri, 15 May 2020 12:15:05 +0300
> Susi Lehtola  wrote:
> > Hello,
> >
> >
> > unfortunately there's going to be *another* soname bump to libxc.
> > Libxc 5 replaced the ancient "Fortran '90" interface with the Fortran
> > 2003 version based on iso_c_binding. However, this included
> > *renaming* the Fortran 2003 module and functions, which is obviously
> > inconvenient for downstream projects and has caused a lot of hassle.
> >
> > This change is reverted in the upcoming libxc release, resulting in
> > another soname bump, but a more backwards compatible API... It appears
> > that the Fortran codes elk and exciting have not yet been compiled
> > against libxc 5; the next release will be easier to compile against.
>
> Nevermind, there's not going to be a soname bump; a copy of the
> erroneously renamed library will also be shipped in the next release...
> the main point being that libxcf03 will be there as well and stay there.
> --
> Susi Lehtola
> Fedora Project Contributor
> jussileht...@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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1821882] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8]

[bugzilla]

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



--- Comment #6 from Philipp Trulson  ---
Thanks for this info Paul! The same thing already happened with zstd, it's a
pity that this breaks so many dependent programs on CentOS.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[stan via devel]

On Fri, 15 May 2020 08:02:34 +0200
Michal Srb  wrote:

> > I realize that this is technically possible to achieve, but that is
> > not how people use it. If you want to distribute your Java app, you
> > just bundle it with all its dependencies into a beefy tarball and
> > ship it. And if Java apps never share dependencies, then developers
> > are not really forced to keep up with latest versions of libraries.
> > Nobody can update the non-existent system-wide Java library that
> > would break their application. They are in control.

An aside, just to clarify for myself.  That means that all Java apps are
the equivalent of statically linked, right?  And are related to things
like flatpaks and modules?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review swaps

[Jerry James]

Who would like to swap reviews?  I need the following:

ocaml-fieldslib: https://bugzilla.redhat.com/show_bug.cgi?id=1833469

ocaml-variantslib: https://bugzilla.redhat.com/show_bug.cgi?id=1833471

ocaml-ppx-inline-test: https://bugzilla.redhat.com/show_bug.cgi?id=1833474

ocaml-ppx-compare:
https://bugzilla.redhat.com/show_bug.cgi?id=1833475; depends on
1833474

ocaml-ppx-fields-conv:
https://bugzilla.redhat.com/show_bug.cgi?id=1833476; depends on
1833469 and 1833474

ocaml-ppx-sexp-conv:
https://bugzilla.redhat.com/show_bug.cgi?id=1833477; depends on
1833474

ocaml-ppx-variants-conv:
https://bugzilla.redhat.com/show_bug.cgi?id=1833478; depends on
1833471 and 1833474

ocaml-ppx-custom-printf:
https://bugzilla.redhat.com/show_bug.cgi?id=1833479; depends on
1833477

Let me know what you would like reviewed in exchange.  If you don't
need a review, I will also swap for a debugging session.  Thanks!
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is dist-git a good place for work?

[Simo Sorce]

On Thu, 2020-05-14 at 14:30 +0200, Ondřej Lysoněk wrote:
> I was originally excited about source-git, however currently I don't see
> an approach to source-git that would work for me and I don't think I'd
> use it if it became available. And frankly, I think I wouldn't want
> other people using it either because it would make understanding their
> packages hard.

So, another way that could work, with minimal tooling is that we keep 
the master branch strictly mirroring whatever upstream branch we
follow, and then for each fedora release you have a fedora branch where
you add the downstream stuff (spec file, patches, etc..).
Whenever you want to bring in a new upstream release you would update
the master tree to the release as tagged in the upstream master branch,
then you branch off a new fedora branch, say fedora33, and then you
cherry-pick on top of it whatever donwstream patches you had in the
fedora32 branch.

The downside of this is that you cannot rebase mid-release. But then
you can always cherry-pick patches from a rebase master or from
upstream if you want.

And the branching, including cherry-picking of downstream patches can
be done automatically for the most part.

Some issues we normally have can also be handled with some discipline:
- upstream has code we cannot ship
- upstream does not use git
- other issues preventing mirroring

For all of these what we do is just use tarballs to create a diff from
current master and then do megacommits with the diff on the master
branch, and use the fedora branches just for the downstream patches and
auto-cherry-picking.

Ideally the tarballs are referenced somehow in the master commit via
sha256 ids so that you can reconstruct exactly what was layered on top.
Those tarballs could also still be stored in the lookaside as a audit
trail as well if preferred.

The critical thing is how to ensure the master branch is sane, or
alternatively how to enable tooling that can switch around the master
branch should surgery be required such that the previous one is
preserved as a historical branch. (for example if upstream force
pushes, we still should have an audited command that saves the previous
master as a branch and then allows a rebase).

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

[Bug 1836267] rpmbuild with .rpmrc and .rpmmacros: Too many levels of recursion when expanding the macro. This is probably caused by a recursive macro declaration.

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC|perl-devel@lists.fedoraproj |igor.ra...@gmail.com,
   |ect.org |m...@fedoraproject.org,
   ||packaging-team-maint@redhat
   ||.com, pmati...@redhat.com,
   ||pmora...@redhat.com,
   ||vmukh...@redhat.com
  Component|perl-rpm-build-perl |rpm
   Assignee|ppi...@redhat.com   |packaging-team-maint@redhat
   ||.com
   Doc Type|--- |If docs needed, set a value




-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?

[Neal Gompa]

On Fri, May 15, 2020 at 10:37 AM Orion Poplawski  wrote:
>
> On 5/15/20 8:32 AM, Alexander Korsunsky wrote:
> >> Has anyone asked if CMake could be updated in RHEL yet?
> >
> > This would be the absolute best option here, but it depends on the 
> > benevolence of Red Hat.
> >
> > I don't have a subscription and I don't know how to ask them for a rebase 
> > without one. Maybe there's some kind of process for getting stuff into 
> > CentOS Stream? So far the interaction with upstream seems to be limited to 
> > "create an issue on Bugzilla".
>
> That would be my suggestion:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=cmake

Wrong place. This is the correct one:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208=cmake


-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Updating CMake in EPEL-8: How to create a module?

[Orion Poplawski]

On 5/15/20 8:32 AM, Alexander Korsunsky wrote:

Has anyone asked if CMake could be updated in RHEL yet?


This would be the absolute best option here, but it depends on the benevolence 
of Red Hat.

I don't have a subscription and I don't know how to ask them for a rebase without one. 
Maybe there's some kind of process for getting stuff into CentOS Stream? So far the 
interaction with upstream seems to be limited to "create an issue on Bugzilla".


That would be my suggestion:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=cmake

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: TeXLive 2020 landing in rawhide

[Orion Poplawski]

On 5/14/20 10:48 PM, Orion Poplawski wrote:

On 5/14/20 3:55 PM, Tom Callaway wrote:
I've just kicked off new builds for texlive and texlive-base for 
TeXLive 2020 in rawhide. Hopefully, everything that depends on them 
will continue to work, but if you notice any new issues generating 
docs (or any missing components or broken dependencies), feel free to 
email me or open Bugzilla tickets.


I'm working on trying to fix the biber failure.  It's an odd one that I 
cannot reproduce locally in mock.  What I've been able to determine is 
that is appears that the "ls-R" files are not present in the koji 
buildroots for some reason.  Perhaps this is an arch dependent thing 
since I seem to be landing on armv7 builders all the time.


Well, it fails on an x86 builder as well so that's not it.  I think 
we're going to need to remove the stderr redirects and maybe add some 
debugging in the scriptlets that build the ls-R files to try to see 
what's failing there.  But I think I'll leave this to others.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?

[Alexander Korsunsky]

> Has anyone asked if CMake could be updated in RHEL yet?

This would be the absolute best option here, but it depends on the benevolence 
of Red Hat.

I don't have a subscription and I don't know how to ask them for a rebase 
without one. Maybe there's some kind of process for getting stuff into CentOS 
Stream? So far the interaction with upstream seems to be limited to "create an 
issue on Bugzilla".
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1836267] New: rpmbuild with .rpmrc and .rpmmacros: Too many levels of recursion when expanding the macro. This is probably caused by a recursive macro declaration.

[bugzilla]

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

Bug ID: 1836267
   Summary: rpmbuild with .rpmrc and .rpmmacros: Too many levels
of recursion when expanding the macro. This is
probably caused by a recursive macro declaration.
   Product: Fedora
   Version: 31
  Hardware: x86_64
Status: NEW
 Component: perl-rpm-build-perl
  Severity: low
  Assignee: ppi...@redhat.com
  Reporter: d.kuc...@dk-software.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem:
when i try to build rpms with my .rpmrc and .rpmmacros (see it down) file it
fails - it works with none spec file with my pure-ftpd.spec file its the same
error - see down on the page my pure-ftpd file

installed rpm-build version: 
[root@buildserver:~]$rpm -qa | grep rpm-build
rpm-build-4.15.1-2.fc31.x86_64
rpm-build-libs-4.15.1-2.fc31.x86_64

[builduser@buildserver:~/rpmbuild/SPECS]$rpmbuild -bb wireguard-tools.spec 
Error: /home/d.kucher/rpmbuild/SPECS/wireguard-tools.spec: line 20: Too many
levels of recursion when expanding the macro. This is probably caused by a
recursive macro declaration.

SPEC-File:
Name:   wireguard-tools
Summary:Fast, modern and secure VPN tunnel
Version:1.0.20200513
Release:1%{?dist}
Epoch:  1
License:GPLv2
URL:https://git.zx2c4.com/wireguard-tools/
Source0:%{name}-%{version}.tar.xz
BuildRequires:  autoconf
Provides:   wireguard = %{version}
Obsoletes:  wireguard < %{version}

%description
WireGuard is a VPN that runs inside the Linux Kernel and utilizes
state-of-the-art cryptography

%prep
%autosetup -p1

%build
export CFLAGS="%{optflags} -fPIE"
export LDFLAGS="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -pie -fPIE"
%make_build RUNSTATEDIR=%{_rundir} -C src

%install
mkdir -p %{buildroot}%{_bindir}
%make_install BINDIR=%{_bindir} MANDIR=%{_mandir} RUNSTATEDIR=%{_rundir}
WITH_BASHCOMPLETION=yes WITH_WGQUICK=no WITH_SYSTEMDUNITS=no -C src
strip --strip-unneeded %{buildroot}%{_bindir}/wg
rm -rf %{buildroot}%{_mandir}

%files
%{_bindir}/wg
%{_datadir}/bash-completion/completions/wg


[builduser@buildserver:~]$cat .rpmrc
optflags: x86_64 %{__global_cflags} -m64 -march=core2 -mtune=core2 

[builduser@buildserver:~]$cat .rpmmacros 
%_topdir %(echo $HOME)/rpmbuild
%__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot

%fedora 31
%dist   .fc%fedora.%(echo $(/usr/bin/date +%Y%m%d)).dk
%packager   Dominik Kucher
%vendor Dominik Kucher
%php_api.php71
%php_debug_build0
%O3_flags   -O3 -fno-strict-aliasing -fno-gcse-after-reload
-fno-inline-functions -fno-ipa-cp -fno-ipa-cp-clone -fno-peel-loops
-fno-predictive-commoning -fno-tree-loop-distribute-patterns
-fno-unswitch-loops
%_smp_mflags-j8
%_include_minidebuginfo 0
%debug_package  %{nil}
%__perl_requires%{nil}
%_binary_payloadw1.gzdio
%_source_payloadw1.gzdio
%__global_ldflags   -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld

%configure \
CFLAGS="${CFLAGS:-%optflags}"; export CFLAGS; \
CXXFLAGS="${CXXFLAGS:-%optflags}"; export CXXFLAGS; \
FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}"; export FFLAGS; \
FCFLAGS="${FCFLAGS:-%optflags -I%_fmoddir}"; export FCFLAGS; \
  LDFLAGS="${LDFLAGS:-%__global_ldflags}"; export LDFLAGS; \
  ./configure \\\
   --host=x86_64-redhat-linux \\\
   --build=x86_64-redhat-linux \\\
   --target=x86_64-redhat-linux \\\
   --program-prefix=%{?_program_prefix} \\\
   --disable-dependency-tracking \\\
   --prefix=%{_prefix} \\\
   --exec-prefix=%{_exec_prefix} \\\
   --bindir=%{_bindir} \\\
   --sbindir=%{_sbindir} \\\
   --sysconfdir=%{_sysconfdir} \\\
   --datadir=%{_datadir} \\\
   --includedir=%{_includedir} \\\
   --libdir=%{_libdir} \\\
   --libexecdir=%{_libexecdir} \\\
   --localstatedir=%{_localstatedir} \\\
   --sharedstatedir=%{_sharedstatedir} \\\
   --mandir=%{_mandir} \\\


Name:  pure-ftpd
Version:   1.0.49
Release:   1%{?dist}
Epoch: 1
Summary:   Lightweight, fast and secure FTP server
Group: System Environment/Daemons
License:   BSD
URL:   https://www.pureftpd.org/project/pure-ftpd
Source0:   %{name}-%{version}.tar.bz2
Source1:   %{name}.service

Provides:  ftpserver
BuildRequires: pam-devel
BuildRequires: perl
BuildRequires: python
BuildRequires: libcap-devel
BuildRequires: mariadb-devel
BuildRequires: checkpolicy
Requires:  usermode

%description
Pure-FTPd is a fast, production-quality, standard-comformant FTP 

[EPEL-devel] Re: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Fri, 15 May 2020 at 09:06, Nico Kadel-Garcia  wrote:

> On Fri, May 15, 2020 at 8:02 AM Stephen John Smoogen 
> wrote:
> >
> >
> >
> > On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia 
> wrote:
> >>
> >> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > We're working on validating CentOS 8 for some desktop use cases at
> work,
> >> > and noticed that after working fine on a machine that's installed
> >> > several months ago, it's now failing on a freshly-installed machine.
> >>
> >> Do not get me *started* on the ansible version fun and games, or the
> >> confusing state of the python3 for various EPEL, RHEL and CentOS
> >> migrations. The situation is exacerbated when RHEL elects to use a
> >> kind-of-sort-of distinct naming scheme for software previously
> >> published via EPEL.
> >>
> >> It's an ongoing problem. EPEL's decision to show only the most recent
> >> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> >> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> >> internal access to old packages.
> >
> >
> > To be clear here.. the 'decision' is that EPEL is built using the same
> build system that Fedora uses. The Fedora build system does not keep older
> versions of packages in its composes for a space and so EPEL can not keep
> older versions of packages either. We tried several 'hacks' to do this and
> they broke the Fedora side or didn't do what we wanted on the EPEL side
> either.
>
> That is not clear at all. Build systems normally build new versions of
> software and deploy them to some target space. The decision to delete
> older packages is a very distinct one. Review of that workspace and
> expiration of old packages pretty much *must* be a distinct one.
> Deletion of obsolete packages in anticipation of their activation in
> an entirely distinct repository  is a very distinct decision.
>
>
I believe Dennis Gilmore and others have tried to explain this multiple
times in the past, but it seems that it just doesn't get through. Here is
my take on it.. which is not as nice as theirs and probably flawed because
I am tired.

The Fedora build system means everything from pkgs, pdc, bodhi, koji,
pungi, and several other tools. The way that this system is built is to
build a complete operating system with the 'compose' being just like what
is in rawhide or a release. Everything is tagged to be in the compose, a
fresh tree is generated, createrepo and other items are built on that tree,
and that tree then replaces the old one on the download servers. Just like
F32 directories and rawhide do not have older copies of packages.. neither
does EPEL.  So to the system there are no old rpms to keep around.. [and
trying to keep them seems to end up with a good many mirrors carrying new
packages but old repodata (or vice versa.. new repodata but no new rpms) so
can't be used by yum/dnf]

Of course there could be other solutions that would fix this problem.. but
each one takes time and energy that no one seems to have the time to
volunteer to get done. If you have the time to do so, I am sure people will
welcome it.



-- 
Stephen J Smoogen.
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Orphaning uglify-js

[Antonio Trande]

Hi all.

`uglify-js` is no longer needed for me, so i'm orphaning it again.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Documentation for EPEL modules?

[Stephen Gallagher]

On Fri, May 15, 2020 at 7:57 AM Petr Pisar  wrote:
>
> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> > On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> >
> > > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > > Shortly (Martin is in Cc to confirm):
> > > >
> > > > 1) Make a module:
> > > >
> > > > $ fedpkg clone cmake3
> > > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > > >
> > > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > > repository and "epel8" stream and "epel8" branch. I don't know if you
> > > really
> > > want to create "cmake3-latest:epel8" module stream.
> > >
> >
> > Since this is a module, is there any point in using the cmake3 namespace
> > over just cmake?
> >
> I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
> cmake-3 but installable in parallel, then it would make sense. (Like Python.)
> Because you cannot install more streams of the same module at the same time.
> Otherwise I would also go with plain "cmake" module name.


It turns out, cmake already has a presence[1] in the modules namespace
of dist-git. It is a relic of the Modularity 1.0 effort, but it's
already there and that will make this easier.

The first thing to look at is CMake's compatibility policy. At a quick
glance, it appears that CMake upstream expects to maintain
backwards-compatible support for all minor releases within the "3.x"
major release number. So from my perspective, the best choice for you
would be to pick the stream name "3", resulting in `cmake:3` as your
module stream. This will allow you to update to any future 3.x release
within the same stream. If CMake 4 is ever released, you can create
the `cmake:4` stream in the same manner.

To do this, request the "3" branch for the cmake module with:
$ fedpkg request-branch --namespace modules cmake 3

Once that branch is created:
$ fedpkg clone modules/cmake
$ fedpkg switch-branch 3

Create a `cmake.yaml` file in the dist-git checkout as described in
the docs [2], commit and push it to dist-git and then do:
$ fedpkg module-build

When creating the definition, you'll want to either leave the
dependencies at `platform: [ ]` (meaning build for all supported
releases, Fedora and EPEL) or else specifically use `platform: [ el8
]` to build only for EPEL 8.

All of this said: it's important to note that this approach also means
that any package that wants to use your newer CMake to build in EPEL 8
will need to build as a module and set their module dependency to
include `cmake:3`. It won't be available in the buildroot for
non-modular packages.


[1] https://src.fedoraproject.org/modules/cmake
[2] 
https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: koji build of libqxt-qt5 fails on rawhide

[Sandro Mani]

On 15.05.20 13:50, Martin Gansser wrote:

what should I do there, any proposal ?


You'll need to unretire and probably fix libqxt, as it installed the pc 
file in


%{_libdir}/qt5/plugins/designer/pkgconfig/QxtDesignerPlugins-qt5.pc

which should probably be

%{_libdir}/pkgconfig/QxtDesignerPlugins-qt5.pc



Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 33 Rawhide 20200515.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 33 Rawhide 20200515.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200510.n.0: anaconda-33.13-1.fc33.src, 20200515.n.0: 
anaconda-33.14-1.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200515.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1821882] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [epel-8]

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 CC||p...@city-fan.org



--- Comment #5 from Paul Howarth  ---
Whilst you wait for CentOS 8.2 to be released, you can find the old EPEL
package here:

https://archives.fedoraproject.org/pub/archive/epel/8.1/Everything/x86_64/Packages/p/perl-Convert-ASN1-0.27-16.el8.noarch.rpm


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia  wrote:

> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
>  wrote:
> >
> > Hi,
> >
> > We're working on validating CentOS 8 for some desktop use cases at work,
> > and noticed that after working fine on a machine that's installed
> > several months ago, it's now failing on a freshly-installed machine.
>
> Do not get me *started* on the ansible version fun and games, or the
> confusing state of the python3 for various EPEL, RHEL and CentOS
> migrations. The situation is exacerbated when RHEL elects to use a
> kind-of-sort-of distinct naming scheme for software previously
> published via EPEL.
>
> It's an ongoing problem. EPEL's decision to show only the most recent
> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> internal access to old packages.
>

To be clear here.. the 'decision' is that EPEL is built using the same
build system that Fedora uses. The Fedora build system does not keep older
versions of packages in its composes for a space and so EPEL can not keep
older versions of packages either. We tried several 'hacks' to do this and
they broke the Fedora side or didn't do what we wanted on the EPEL side
either.

At this point it is either someone finding the time to deep dive into pungi
and other tools to make it work for this 2 different case mode or moving
EPEL to a different build system. Both are giant projects which no one has
had the time to do.


-- 
Stephen J Smoogen.
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


signature.asc
Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: koji build of libqxt-qt5 fails on rawhide

[Martin Gansser]

what should I do there, any proposal ?

Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Documentation for EPEL modules?

[Richard Shaw]

On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:

> On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > Shortly (Martin is in Cc to confirm):
> >
> > 1) Make a module:
> >
> > $ fedpkg clone cmake3
> > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> >
> This will request for creating "cmake3-latest" module and "cmake3-latest"
> repository and "epel8" stream and "epel8" branch. I don't know if you
> really
> want to create "cmake3-latest:epel8" module stream.
>

Since this is a module, is there any point in using the cmake3 namespace
over just cmake?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1816436] perl-Cache-FastMmap-1.49 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-05-15 11:27:04



--- Comment #2 from Jan Pazdziora  ---
The build was pushed to rawhide on 2020-03-30.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1823191] perl-Scalar-List-Utils-1.55 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-05-15 11:27:27



--- Comment #3 from Jan Pazdziora  ---
The build was pushed to rawhide on 2020-04-16.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1814917] perl-Net-GitHub-0.99 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-05-15 11:26:14



--- Comment #3 from Jan Pazdziora  ---
The build was pushed to rawhide on 2020-03-30.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1814482] perl-Net-GitHub-0.97 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-05-15 11:25:53



--- Comment #2 from Jan Pazdziora  ---
The build was pushed to rawhide on 2020-03-18.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1826569] perl-Net-GitHub-1.01 is available

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2020-05-15 11:24:42



--- Comment #3 from Jan Pazdziora  ---
The new build was pushed to rawhide on 2020-04-27.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


signature.asc
Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Updating CMake in EPEL-8: How to create a module?

[Neal Gompa]

On Fri, May 15, 2020 at 4:58 AM Alexander Korsunsky
 wrote:
>
> Hi there,
>
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11, 
> which is becoming more and more outdated. Me (and a few other people, judging 
> by bug report participation) would quite like to have a newer version of 
> CMake on their systems.
>

Has anyone asked if CMake could be updated in RHEL yet? Unlike in the
CMake 2.x days, CMake 3.x tends to maintain behavioral compatibility
extraordinarily well...




-- 
真実はいつも一つ！/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Is dist-git a good place for work?

[Ondřej Lysoněk]

clime  writes:

> On Thu, 14 May 2020 at 14:31, Ondřej Lysoněk  wrote:
>>
>> Hunor Csomortáni  writes:
>>
>> > On Wed, May 6, 2020 at 10:24 PM Simo Sorce  wrote:
>> >> Well, a way to allow force pushes would be to have a git hook that
>> >> branches the tree before the force push. (creating a branch named
>> >> something like audit-force-push-)
>> >> That way you can retain data for legal/auditing reasons, while allowing
>> >> every day history to be rewritten.
>> >
>> > Wouldn't it be easier to approach this from a build system perspective
>> > and let for example the build system (or tools) tag the commits which
>> > were built from with some for-ever-living tags? This would still
>> > ensure a complete audit trail for whatever was built and shipped, but
>> > could eliminate the need for a complete lock down of dist/source-git.
>> >
>> >> Not sure how "nice" that would be for an auditor that has to
>> >> reconstruct what happened over multiple force pushes that way, it also
>> >> will generate quite an amount of noisy metadata (branches), but it
>> >> could work.
>> >
>> > Refs created for auditing purposes could be kept in a separate git
>> > namespace so they don't create noise in everyday workflows.
>>
>> As someone who works with git history all the time, I cannot imagine how
>> I would work in such an environment. Consider the simple task of finding
>> the commit that first introduced a downstream change. Currently with
>> dist-git, I can just do 'git log patch-file', scroll to the very end and
>> be done with it.
>>
>
> It's a good point that this operation would be harder but it could be
> solved, I think.
>
> I mean it could have beneficial features for maybe not all packages
> but at least some.

I think that source-git could make sense for packages that have
historically *not* had many patches - be that downstream or cherry-picked
patches. (And I realize that is quite the opposite of what others have
said here.) With such packages, I could just git-pull new upstream
releases, review the changes and git-push them to Fedora, instead of
having to juggle with tarballs. That's a very appealing proposition to
me. And with such packages, you wouldn't run into the downside of
accumulating a history that is hard to understand.

So my opinion is that for simple packages that have no patches and where
the conversion between source-git and dist-git is relatively
straightforward, source-git could be a great option. For other packages,
not really.

>
> I suspect on such scale as Fedora operates, it might be quite hard to
> do something which improves things for everybody.

Agreed.

Ondřej

>
>> If what you're proposing was implemented, then I'd have to manually try
>> all the tags until I found the "right history" where the change was
>> first introduced.
>>
>> In an email in this thread clime suggested a similar approach, only
>> instead of tags there would be a separate branch for each upstream
>> release. While that eliminates the need to allow force-pushes, for the
>> purposes of digging through the history it's the same thing. The only
>> difference is that instead of iterating over tags, I'd be iterating over
>> branches.
>>
>> The only other approach to source-git that I can think of is merging new
>> upstream releases instead of git-rebasing on top of them. That is the
>> approach that I originally thought would work, but one of Neal's
>> responses made me realize that this approach also has a significant
>> drawback - it makes distinguishing between downstream changes and
>> cherry-picked upstream changes hard.
>>
>> I was originally excited about source-git, however currently I don't see
>> an approach to source-git that would work for me and I don't think I'd
>> use it if it became available. And frankly, I think I wouldn't want
>> other people using it either because it would make understanding their
>> packages hard.
>>
>> I completely agree that dist-git is difficult to work with, but perhaps
>> instead of inventing something completely new, we could focus on making
>> working with dist-git easier by dropping the changlog and Release from
>> the specfiles and on creating tools for ourselves to make working with
>> patches easier? I'm currently looking into Quilt, mentioned by several
>> people here, to see if it could make my life easier at all. Just a
>> suggestion.
>>
>> Thanks everyone for this enlightening thread.
>>
>> Ondřej Lysoněk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1836176] New: perl-Text-Table-1.134 is available

[bugzilla]

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

Bug ID: 1836176
   Summary: perl-Text-Table-1.134 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-Table
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.134
Current version/release in rawhide: 1.133-9.fc33
URL: http://search.cpan.org/dist/Text-Table/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/3449/


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

[EPEL-devel] Re: Documentation for EPEL modules?

[Antonio Trande]

Shortly (Martin is in Cc to confirm):

1) Make a module:

$ fedpkg clone cmake3
$ fedpkg request-repo --namespace modules --exception cmake3-latest
$ fedpkg request-branch --namespace modules --repo cmake3-latest epel8

2) Writing a `modulemd` file based on this example [1]:

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/

3) Build the module:

$ fedpkg module-build


On 14/05/20 17:51, Petr Pisar wrote:
> On Thu, May 14, 2020 at 06:46:29AM -0500, Richard Shaw wrote:
>> So this happened:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ad02b27ee3
>> https://bugzilla.redhat.com/show_bug.cgi?id=1830748
>>
>> TLDR; So we need an updated version of CMake in EPEL 8 but RHEL/CentOS
>> already provide a "3" version. Worse both the Fedora and EL versions
>> provide "cmake3" packages and binaries so it's not possible to install the
>> cmake3 package in EL 8.
>>
>> So here's a great use case for modularity but I have no idea how it works
>> and there doesn't seem to be any EPEL specific documentation even though
>> it's obviously getting used:
>>
>> https://bodhi.fedoraproject.org/releases/EPEL-8M
>>
>> Do we need a epel8 branch? Or is the EL module created from master?
>>
> I believe modules in EPEL are similar to modules in Fedora. I'm not aware
> about a documentation for modules in EPEL. There were some attempts to draft
> the guide lines like forbiding default streams and mandating stream prefixes,
> but I do not remember any output.
> 
> Let's look at real examples.
>  lists 
> avocado-latest-820200512173744.9edba152 module. That's this
>  module build
> in Koji. The Source field reads 
> .
> 
> Theat means "fedpkg clone modules/avocado" and there these branches:
> 
> * latest
>   remotes/origin/52lts
>   remotes/origin/69lts
>   remotes/origin/HEAD -> origin/latest
>   remotes/origin/f29
>   remotes/origin/latest
>   remotes/origin/master
>   remotes/origin/stable
> 
> The module stream is called "latest", let us check "latest" branch:
> 
> commit 12e2140e759fdb0a4477ab2432c411a4452d8efc (HEAD -> latest, 
> origin/latest, origin/HEAD)
> Author: Merlin Mathesius 
> Date:   Tue May 12 12:37:44 2020 -0500
> 
> Rebuild with avocado 79.0.
> 
> Signed-off-by: Merlin Mathesius 
> 
> So you can see the module is built from a non-epel8 branch. An avocado.yaml
> file lists these dependencies:
> 
>   dependencies:
>   - buildrequires:
>   platform: []
> requires:
>   platform: []
> 
> So "platform" is left empty to expand it by MBS on all available platforms. If
> you look at koji listing
> , there are
> five modules avocado-latest-*20200512173744 builds of from the same sources.
> That probably means that Koji attempts to build the module for all Fedoras and
> EPEL 8. Technically, it's possible to override the platform with "fedpkg
> module-build" command, but I cannot see any trace of it in the logs.
> 
> That buld was performed by "merlinm" users. You can ask him for more details.
> 
> -- Petr
> 
> 
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Documentation for EPEL modules?

[Antonio Trande]

Shortly (Martin is in Cc to confirm):

1) Make a module:

$ fedpkg clone cmake3
$ fedpkg request-repo --namespace modules --exception cmake3-latest
$ fedpkg request-branch --namespace modules --repo cmake3-latest epel8

2) Writing a `modulemd` file based on this example [1]:

[1]
https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/

3) Build the module:

$ fedpkg module-build


On 14/05/20 17:51, Petr Pisar wrote:
> On Thu, May 14, 2020 at 06:46:29AM -0500, Richard Shaw wrote:
>> So this happened:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ad02b27ee3
>> https://bugzilla.redhat.com/show_bug.cgi?id=1830748
>>
>> TLDR; So we need an updated version of CMake in EPEL 8 but RHEL/CentOS
>> already provide a "3" version. Worse both the Fedora and EL versions
>> provide "cmake3" packages and binaries so it's not possible to install the
>> cmake3 package in EL 8.
>>
>> So here's a great use case for modularity but I have no idea how it works
>> and there doesn't seem to be any EPEL specific documentation even though
>> it's obviously getting used:
>>
>> https://bodhi.fedoraproject.org/releases/EPEL-8M
>>
>> Do we need a epel8 branch? Or is the EL module created from master?
>>
> I believe modules in EPEL are similar to modules in Fedora. I'm not aware
> about a documentation for modules in EPEL. There were some attempts to draft
> the guide lines like forbiding default streams and mandating stream prefixes,
> but I do not remember any output.
> 
> Let's look at real examples.
>  lists 
> avocado-latest-820200512173744.9edba152 module. That's this
>  module build
> in Koji. The Source field reads 
> .
> 
> Theat means "fedpkg clone modules/avocado" and there these branches:
> 
> * latest
>   remotes/origin/52lts
>   remotes/origin/69lts
>   remotes/origin/HEAD -> origin/latest
>   remotes/origin/f29
>   remotes/origin/latest
>   remotes/origin/master
>   remotes/origin/stable
> 
> The module stream is called "latest", let us check "latest" branch:
> 
> commit 12e2140e759fdb0a4477ab2432c411a4452d8efc (HEAD -> latest, 
> origin/latest, origin/HEAD)
> Author: Merlin Mathesius 
> Date:   Tue May 12 12:37:44 2020 -0500
> 
> Rebuild with avocado 79.0.
> 
> Signed-off-by: Merlin Mathesius 
> 
> So you can see the module is built from a non-epel8 branch. An avocado.yaml
> file lists these dependencies:
> 
>   dependencies:
>   - buildrequires:
>   platform: []
> requires:
>   platform: []
> 
> So "platform" is left empty to expand it by MBS on all available platforms. If
> you look at koji listing
> , there are
> five modules avocado-latest-*20200512173744 builds of from the same sources.
> That probably means that Koji attempts to build the module for all Fedoras and
> EPEL 8. Technically, it's possible to override the platform with "fedpkg
> module-build" command, but I cannot see any trace of it in the logs.
> 
> That buld was performed by "merlinm" users. You can ask him for more details.
> 
> -- Petr
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1742913] biber-2.14 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #6 from Petr Pisar  ---
Fedora 33 just received texlive-biblatex-svn53063-20.fc33.noarch with
/usr/share/texlive/texmf-dist/bibtex/bst/biblatex/biblatex.bst file:

FUNCTION {initialize} {
  "$Revision: 3.13 $"

For your information, a test in current Fedora's biber fails
.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora-Cloud-31-20200515.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Re: koji build of libqxt-qt5 fails on rawhide

[Antonio Trande]

Looks clear:

sed: can't read ../../lib/pkgconfig/QxtDesignerPlugins-qt5.pc: No such
file or directory

even if on F32 this error is ignored.

On 15/05/20 08:14, Martin Gansser wrote:
> Hi,
> 
> I' am trying to compile libqxt-qt5 on rawhide [1], but this fails with the 
> following error message:
> Fedora 32 [2] build fine.
> 
> make[1]: Entering directory 
> '/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5/src/designer'
> /usr/lib64/qt5/bin/qmake -install qinstall -exe 
> ../../lib/libQxtDesignerPlugins-qt5.so 
> /builddir/build/BUILDROOT/libqxt-qt5-0.7.0-0.22.20130718giteaf6872f6ad4.fc33.x86_64/usr/lib64/qt5/plugins/designer/libQxtDesignerPlugins-qt5.so
> sed  -e s,/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5,/usr,g 
> ../../lib/pkgconfig/QxtDesignerPlugins-qt5.pc > 
> /builddir/build/BUILDROOT/libqxt-qt5-0.7.0-0.22.20130718giteaf6872f6ad4.fc33.x86_64/usr/lib64/qt5/plugins/designer/pkgconfig/QxtDesignerPlugins-qt5.pc
> sed: can't read ../../lib/pkgconfig/QxtDesignerPlugins-qt5.pc: No such file 
> or directory
> make[1]: *** [Makefile:760: install_target] Error 2
> make[1]: Leaving directory 
> '/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5/src/designer'
> make: *** [Makefile:117: sub-src-designer-install_subtargets] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.2ZEK8P (%install)
> Bad exit status from /var/tmp/rpm-tmp.2ZEK8P (%install)
> RPM build errors:
> Child return code was: 1
> EXCEPTION: [Error()]
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py", line 
> 93, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 755, in 
> do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command, output), 
> child.returncode)
> mockbuild.exception.Error: Command failed: 
>  # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps 
> /builddir/build/SPECS/libqxt-qt5.spec
> 
> [1] https://kojipkgs.fedoraproject.org//work/tasks/4180/44514180/build.log
> [2] https://kojipkgs.fedoraproject.org//work/tasks/9961/44479961/build.log
> 
> Have anybody a idea ?
> Regards
> Martin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Another libxc soname bump...

[Susi Lehtola]

On Fri, 15 May 2020 12:15:05 +0300
Susi Lehtola  wrote:
> Hello,
> 
> 
> unfortunately there's going to be *another* soname bump to libxc.
> Libxc 5 replaced the ancient "Fortran '90" interface with the Fortran
> 2003 version based on iso_c_binding. However, this included
> *renaming* the Fortran 2003 module and functions, which is obviously
> inconvenient for downstream projects and has caused a lot of hassle.
> 
> This change is reverted in the upcoming libxc release, resulting in
> another soname bump, but a more backwards compatible API... It appears
> that the Fortran codes elk and exciting have not yet been compiled
> against libxc 5; the next release will be easier to compile against.

Nevermind, there's not going to be a soname bump; a copy of the
erroneously renamed library will also be shipped in the next release...
the main point being that libxcf03 will be there as well and stay there.
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?

[Petr Pisar]

On Fri, May 15, 2020 at 08:58:21AM -, Alexander Korsunsky wrote:
> Hi there,
> 
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11,
> which is becoming more and more outdated. Me (and a few other people,
> judging by bug report participation) would quite like to have a newer
> version of CMake on their systems.
> 
> Now, if I understand correctly, according to the EPEL policies,
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is
> prohibited to replace packages from the base distribution. It is, however,
> allowed to replace these packages in modules that are not enabled by
> default.
> 
> Unfortunately, nobody really seems to know how to build modules for EPEL.
> There is documentation for Fedora:
> https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However,
> being not very familiar with modularity, I have no clue which parts of the
> documentation apply to EPEL, and I could not find EPEL-specific
> documentations and recommendations. I have seen some threads on this list
> *discussing* these, but it's hard for me to discern the consensus and best
> practices from mailing list threads.
> 
> Would the Modularity magicians be so kind as to reply with some pointers on
> how to create modules for EPEL? If that already exists, my apologies, I hope
> you can direct me to that resource.
> 
I replied to the same question yesterday on Fedora devel list
.
 

-- Petr


signature.asc
Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

libqb soname bump

[Christine Caulfield]

I've uploaded libqb 2.0.0 into rawhide which has a soname bump.

It's currently built on side-tag f33-build-side-23348 and I'll release
it when I think everything is built.

Most of the dependencies are in my (HA cluster) team so I can chat with
them and get things built, and I've emailed the maintainer of usbguard.

If anyone else thinks they might be dependent on libq then please build
on that side-tag and let me know. Hopefully it can all be sorted by next
week.

Chrissie
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: i3 new SIG

[Till Hofmann]

Hi Eduard,

On 5/15/20 12:21 AM, Eduard Lucena wrote:
> 
> As others have already mentioned in the thread: we should look into
> joining forces with the sway SIG (which I am also a member of).
> 
> 
> It's not a bad idea, but TBH, I still want to stay away from Wayland.
> 
> While a lot of the packages of interest are not really shared, the
> general
> similarity would allow us to save a lot of time when it comes to QA and
> the creation of a spin. Maybe we should merge into the tilling window
> manager SIG? (with a better name of course).
> 
> 
> Well, we can join effort for packaging but produce different Spins, why
> not? wdyt?
>  

It's nice to see more interest in i3! But I'm not sure that joining
efforts is such a good idea. While sway and i3 may be very similar from
a user perspective, they are not from a packager's perspective. Also,
while you don't really care about sway, I don't have much interest in
i3. So what exactly would a joined SIG do? All the work would be either
towards i3 or sway, I don't see any synergetic effects of a joint SIG.

Kind regards,
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Another libxc soname bump...

[Susi Lehtola]

Hello,


unfortunately there's going to be *another* soname bump to libxc. Libxc
5 replaced the ancient "Fortran '90" interface with the Fortran 2003
version based on iso_c_binding. However, this included *renaming* the
Fortran 2003 module and functions, which is obviously inconvenient for
downstream projects and has caused a lot of hassle.

This change is reverted in the upcoming libxc release, resulting in
another soname bump, but a more backwards compatible API... It appears
that the Fortran codes elk and exciting have not yet been compiled
against libxc 5; the next release will be easier to compile against.
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200515.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 598896  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/598896
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Updating CMake in EPEL-8: How to create a module?

[Alexander Korsunsky]

Hi there,

the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11, 
which is becoming more and more outdated. Me (and a few other people, judging 
by bug report participation) would quite like to have a newer version of CMake 
on their systems.

Now, if I understand correctly, according to the EPEL policies, 
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is 
prohibited to replace packages from the base distribution. It is, however, 
allowed to replace these packages in modules that are not enabled by default.

Unfortunately, nobody really seems to know how to build modules for EPEL. There 
is documentation for Fedora: 
https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However, 
being not very familiar with modularity, I have no clue which parts of the 
documentation apply to EPEL, and I could not find EPEL-specific documentations 
and recommendations. I have seen some threads on this list *discussing* these, 
but it's hard for me to discern the consensus and best practices from mailing 
list threads.

Would the Modularity magicians be so kind as to reply with some pointers on how 
to create modules for EPEL? If that already exists, my apologies, I hope you 
can direct me to that resource.

Kind Regards,
Alexander
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

HEADS UP: icu 67 coming to rawhide

[Pete Walter]

Hi,I am in the process of updating icu from 65.1 to 67.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good weekend!Pete___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: TeXLive 2020 landing in rawhide

[Miro Hrončok]

On 15. 05. 20 4:10, Tom Callaway wrote:

I'll get that fixed up first thing tomorrow.


Thanks, Tom.


Apologies,


No worries. I can only imagine the horrors of maintaining this.

--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why we package Rust crates

[Kushal Das]

On 5/15/20 1:05 AM, Igor Raits wrote:
> Hello,
> 
> This email attempts to answer some frequently asked questions about
> Rust SIG packaging of crates. For those who don't know what a "crate"
> is: it is the name for a collection of functionality in Rust, similar
> to libraries (C/C++), modules (Python/Perl/PHP), gems (Ruby), etc.
> 
Thank you all for the hard work. It is amazing to see so many nice tools
available in Fedora.

Kushal
-- 
Public Interest Technologist, Freedom of the Press Foundation
CPython Core Developer
Director, Python Software Foundation
https://kushaldas.in
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-30-20200515.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Re: i3 new SIG

[Porfirio Andrés Páiz Carrasco]

El mié., 13 de may. de 2020 a la(s) 10:51, Eduard Lucena
(x3m...@fedoraproject.org) escribió:
>
> Hello guys,

Hi.

> [1] https://fedoraproject.org/wiki/SIGs/i3

Regarding to the minimum packages list pending on the Wiki, what I
have always done to install i3wm without having to rely on other
install mediums like Fedora Workstation Live DVD or any other Spin, is
to use the Fedora-Everything-netinst-x86_64 from https://alt.fedoraproject.org/

This install media provides the option of a very minimal Fedora
Install, you only have to mark the checkbox for Minimal or Custom
Install, just that. No more than that. Then after the first boot up
you will have to rely on a Wired Network interface connection or a
Mobile USB Tethered Network to install the rest of the packages set
which are the followings.

dnf -y group install networkmanager-submodules
dnf -y group install core
dnf -y install dial-up
dnf -y group install fonts
dnf -y group install guest-desktop-agents
dnf -y group install hardware-support
dnf -y group install multimedia
dnf -y group install standard
dnf -y group install base-x
dnf -y group install input-methods
dnf -y install fedora-icon-theme
dnf -y install gnome-icon-theme
dnf -y install gnome-icon-theme-extras
dnf -y install i3
dnf -y install lightdm-gtk
dnf -y install xdg-user-dirs

Then I just:

systemctl set-default graphical.target

And:

systemctl enable lightdm.service

Finally:

reboot.

I guess after all this, you can generate the list of packages with:
dnf list installed > fedora_i3wm.txt

There are other issues to solve that we can discuss on the SIG Mailing
list so we can achieve a MVP that suits the Spin philosophy.

Porfirio.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

koji build of libqxt-qt5 fails on rawhide

[Martin Gansser]

Hi,

I' am trying to compile libqxt-qt5 on rawhide [1], but this fails with the 
following error message:
Fedora 32 [2] build fine.

make[1]: Entering directory 
'/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5/src/designer'
/usr/lib64/qt5/bin/qmake -install qinstall -exe 
../../lib/libQxtDesignerPlugins-qt5.so 
/builddir/build/BUILDROOT/libqxt-qt5-0.7.0-0.22.20130718giteaf6872f6ad4.fc33.x86_64/usr/lib64/qt5/plugins/designer/libQxtDesignerPlugins-qt5.so
sed  -e s,/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5,/usr,g 
../../lib/pkgconfig/QxtDesignerPlugins-qt5.pc > 
/builddir/build/BUILDROOT/libqxt-qt5-0.7.0-0.22.20130718giteaf6872f6ad4.fc33.x86_64/usr/lib64/qt5/plugins/designer/pkgconfig/QxtDesignerPlugins-qt5.pc
sed: can't read ../../lib/pkgconfig/QxtDesignerPlugins-qt5.pc: No such file or 
directory
make[1]: *** [Makefile:760: install_target] Error 2
make[1]: Leaving directory 
'/builddir/build/BUILD/libqxt-libqxt-eaf6872f6ad4/qt5/src/designer'
make: *** [Makefile:117: sub-src-designer-install_subtargets] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.2ZEK8P (%install)
Bad exit status from /var/tmp/rpm-tmp.2ZEK8P (%install)
RPM build errors:
Child return code was: 1
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/mockbuild/trace_decorator.py", line 
93, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.7/site-packages/mockbuild/util.py", line 755, in 
do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command, output), 
child.returncode)
mockbuild.exception.Error: Command failed: 
 # bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps 
/builddir/build/SPECS/libqxt-qt5.spec

[1] https://kojipkgs.fedoraproject.org//work/tasks/4180/44514180/build.log
[2] https://kojipkgs.fedoraproject.org//work/tasks/9961/44479961/build.log

Have anybody a idea ?
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[Michal Srb]

On Thu, May 14, 2020 at 2:42 PM Vít Ondruch  wrote:

>
> Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
>
> Hello,
>
> On Tue, May 12, 2020 at 12:57 PM Felix Schwarz 
> wrote:
>
>>
>> Am 12.05.20 um 12:32 schrieb Ty Young:
>> > Right, I figured it was some Fedora policy and not up to you. I suppose
>> I
>> > should have been more clear there. Sorry for any confusion, it was
>> aimed at
>> > the Fedora project as a whole as this is a Fedora issue.
>>
>> This is not a Fedora issue but a consequence of Fedora's core values. You
>> not
>> agree with it but "building from source" is so fundamental that it does
>> not
>> make sense to even start a discussion about it on fedora-devel.
>>
>> I suggest you read up on the rationale behind that policy (which is why I
>> linked the policy document in the first place).
>>
>
> I agree that building from sources is the right thing to do. However, let
> me play devil's advocate here :)
>
> What makes Java apps different from other language ecosystems is that Java
> apps never share dependencies. There is no concept of "system-wide"
> 3rd-party Java libraries that would be automatically added to classpath
> when JVM starts.
>
>
> And now how is this different to different language ecosystems? All
> languages I have ever worked with has this attitude, more or less. The
> Linux distributions are fighting against this but with various success.
> With Java, Fedora is failing ATM.
>

Since Java apps always ship their dependencies in tarballs, it's like
upstream is pinning down dependencies to specific versions. There is no
room for any version ranges like for example "as long as you have
java-lib>=2.3 on your system, the dependency will be satisfied". Installing
(well, "unpacking") other Java application that requires java-lib>=3.0 will
never break the first app.

Then Fedora comes in and tries not only to run both Java App #1 and Java
App #2 on the same system, ideally with the single version of
java-lib(latest), but also to build both the apps on the same system (the
build system being the 3rd Java app).
I am not saying this is something bad, it's just something completely
unnatural for the Java App ecosystem.
Java developers ship their tested self-contained tarballs which work on
Linux, Mac and Windows. And Linux distributions take those apps and try to
run them with a completely different set of dependencies. I kinda
understand why upstream projects are not always happy about that...

Although you're right that there are plenty of Python projects out there
that straight up tell you to isolate their applications in a virtual
environment when you're pip-installing them from PyPI. It's not all though.
There are still plenty of projects that tell you that as long as you have
python-lib>=2.3 on your machine, you will be fine. This makes Python
packaging so much easier, at least in my opinion. Such Python apps are not
in full control of their dependency chains, they realize that newer
python-lib could introduce some breaking changes and if you open a pull
request with a patch, they are not surprised, they know what the problem is
and why the pull request should be merged. That's what they signed up for
by saying that python-lib>=2.3 is fine.

Thanks,
Michal


> And if the bundling is not happening on language level, then we are back
> to bundling in containers and flatpacks and what not.
>
>
> Vít
>
>
> I realize that this is technically possible to achieve, but that is not
> how people use it. If you want to distribute your Java app, you just bundle
> it with all its dependencies into a beefy tarball and ship it.
> And if Java apps never share dependencies, then developers are not really
> forced to keep up with latest versions of libraries. Nobody can update the
> non-existent system-wide Java library that would break their application.
> They are in control.
>
> Since there is no standard place for shared Java libraries on your laptop,
> how can you use the packaged Java libraries and develop software against
> them? Sure, you can hack it and make it work on your Fedora 32 machine, but
> your custom Makefile is not guaranteed to work on Fedora 31 or later on 33.
> And your colleague that is on CentOS is out of luck of course. And so are
> all your potential external contributors on their MacBooks and Ubuntus.
> What I am trying to say in this paragraph is that shipping (in RPMs) and
> maintaining individual build-only Java libraries is, at least in my
> opinion, questionable.
>
> Fedora and other linux distributions are trying to do the right thing, but
> things like Java apps simply don't fit in. What Java app developers are
> doing may not be the best thing, but it's been like that for ~20 years, and
> it seems to be "good enough" for the majority of people involved (well,
> developers at least).
> Fedora alone is too insignificant to change it I am afraid.
>
> However, with all that being said. I do like "dnf install my-java-app"
> better than unpacking some tarballs 

Re: Orphaned packages looking for new maintainers

[Dominique Martinet]

Hi Dan,

Dan Čermák wrote on Thu, May 14, 2020 at 11:58:27PM +0200:
> Thanks for the offer to sponsor Dominique Kevin!

Yes! Thanks Kevin, I was able to take waypipe just now.

> Dominique, would you be interested in joining the sway SIG as waypipe
> fits quite well into our maintained packages
> (https://fedoraproject.org/wiki/SIGs/Sway#Packages)?

I don't actually use sway (although I do have a few patches in
it... :D), but sure it does fit well.

I'd be very interested in trying to sort out what we can do with
redshift as well, upstream has not been very cooperative but it looks
like just ENOTIME to me and it might be possible to engage a discussion
somehow. I'll start a thread on the sway SIG list; I've just subscribed
and will send a mail about that after work.

-- 
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org