[Bug 1796214] perl-CDB_File-1.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1796214 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CDB_File-1.02-1.fc32 |perl-CDB_File-1.02-1.fc32 ||perl-CDB_File-1.02-1.fc31 --- Comment #15 from Fedora Update System --- FEDORA-2020-7081f6fa6d has been pushed to the Fedora 31 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
Re: FTBFS bug not reassigned
On Sun, 2020-05-17 at 04:10 +0100, Lyes Saadi wrote: > Hi! > > This might be related to this issue: > https://pagure.io/fedora-infrastructure/issue/8628 > > I had the same problem a month ago... Maybe you can ask for someone > there to fix your account's permissions manually? Thanks for the link! I'll take a look and see if I can get my perms added. -ben signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: FTBFS bug not reassigned
Hi! This might be related to this issue: https://pagure.io/fedora-infrastructure/issue/8628 I had the same problem a month ago... Maybe you can ask for someone there to fix your account's permissions manually? Le 17/05/2020 à 00:25, Benjamin Lowry a écrit : I recently adopted flatbuffers, which was orphaned due to an open FTBFS in F32 [1]. I've fixed the spec, rebuilt, and made an update in bodhi, but I'm unable to close the FTBFS bug because it hasn't been reassigned to me. What should I do? Am I supposed to be able to edit this bug? I'm in the editbugs group... -ben [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799345 ___ 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
[389-devel] 389 DS nightly 2020-05-17 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/17/report-389-ds-base-1.4.4.2-20200516git9afa669.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
[Bug 1831525] perl-Regexp-Grammars-1.054 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1831525 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Regexp-Grammars-1.055- ||1.fc32 Resolution|WONTFIX |ERRATA --- Comment #5 from Fedora Update System --- FEDORA-2020-867c47a660 has been pushed to the Fedora 32 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
[Bug 1796214] perl-CDB_File-1.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1796214 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-CDB_File-1.02-1.fc32 Resolution|--- |ERRATA Last Closed||2020-05-17 02:41:42 --- Comment #14 from Fedora Update System --- FEDORA-2020-20a68258ba has been pushed to the Fedora 32 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
[Bug 1833166] perl-Regexp-Grammars-1.055 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1833166 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Regexp-Grammars-1.055- ||1.fc32 Resolution|--- |ERRATA Last Closed||2020-05-17 02:42:13 --- Comment #3 from Fedora Update System --- FEDORA-2020-867c47a660 has been pushed to the Fedora 32 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
[Bug 1830631] perl-Regexp-Grammars-1.053 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1830631 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Regexp-Grammars-1.055- ||1.fc32 Resolution|WONTFIX |ERRATA --- Comment #7 from Fedora Update System --- FEDORA-2020-867c47a660 has been pushed to the Fedora 32 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
FTBFS bug not reassigned
I recently adopted flatbuffers, which was orphaned due to an open FTBFS in F32 [1]. I've fixed the spec, rebuilt, and made an update in bodhi, but I'm unable to close the FTBFS bug because it hasn't been reassigned to me. What should I do? Am I supposed to be able to edit this bug? I'm in the editbugs group... -ben [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1799345 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
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: ...snip... >kevin calibre collectd fontforge thunarx-python calibre has Py_Initialize / Py_Finalize. collectd has Py_Initialize / Py_Finalize. fontforge has Py_Initialize / Py_Finalize. thunarx-python has Py_Initialize / Py_Finalize. I assume you all are keeping a whitelist or something for this? (so you don't file bugs on the ones already checked). Thanks for the notice! kevin 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
Soname bump gloox ibgloox.so.13 -> 17
Hi, I am going to update gloox to the newest version. I am going to build in the side tag f33-build-side-23466 0ad and uwsgi need to be rebuild. $ dnf repoquery --whatrequires gloox-devel --repo=rawhide-source 0ad-0:0.0.23b-13.fc33.src uwsgi-0:2.0.18-8.fc33.src Cheers, David ___ 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: moreutils newly in PowerTools repo in centos-8
Am 16.05.20 um 20:42 schrieb clime: > I am a long term epel user and I had no idea about PowerTools. Yeah, I don't think you are the only one. Most EPEL 8 users do not need anything from PowerTools so it goes pretty much unnoticed. I got 3 or 4 bug reports about this when I added certbot to EPEL 8 and it required python3-mock from PowerTools. (The good thing was that this prompted upstream to change its code. With the latest version I could drop the dependency on python3-mock :-) Felix ___ 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
swift-lang includes its own private copy of LLDB for its REPL, which uses Python as its scripting language so it too is linking correctly. ___ 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: AskFedora: Can someone please answer this question on security fixes on
On Sat, May 16, 2020 at 01:09:32PM +0100, Ian McInerney wrote: > On Sat, May 16, 2020 at 11:39 AM Dominique Martinet > wrote: > > > Hi, > > > > Ankur Sinha wrote on Sat, May 16, 2020: > > > As subject says: > > > > > https://ask.fedoraproject.org/t/comparing-fedora-centos-security-fix-lag/7117 > > > > > > (I looked around a bit and couldn't find any documentation on this). > > > > I've tried for a bit (~10 mins) but I really can't get discourse to let > > me reply, probably an issue on my end but since I'm also curious about > > it I can give the start of an answer here: > > > > - first for opaque security issues, fedora isn't on linux-distro list: > > https://oss-security.openwall.org/wiki/mailing-lists/distros > > This means that fedora as its own entity does not benefit from advanced > > warning when such an issue occurs, apparently. > > I'm curious about this point, there is a security team[0] so it could be > > interesting to get one of them on the list? I'm not following quite > > close enough what they do... > > [0] https://fedoraproject.org/wiki/Category:Security_Team?rd=Security_Team > > > It lists "Red Hat", not "Red Hat Enterprise Linux", so it is entirely > possible that Fedora is under the Red Hat umbrella for that list. Also, I > would imagine fixes can be ported back from RHEL maintainers when they are > able (and with the recent initiative to merge the kernel patches that may > mean Fedora gets the kernel patches when they are able to go public). It's possibly worth noting here that Fedora has currently not much ability to stange fixes for embargoed security bugs. Since our source commits, builds and such are all public we can't build and get everything ready to go when an embargo lifts. As noted upthread, maintainers may well know about embargoed / not yet public bugs (via a number of means: they are also the RHEL maintainer and get a heads up via the linux-distros list/reporters, they may get a heads up from upstream if they have a close relationship there, etc). So the answer to: "Does Fedora wait for opaque security errata from RHEL releases like CentOS, or is there a more cooperative relationship?" is more "No, Fedora doesn't wait for RHEL, but it waits generally until things are public and the maintainer(s) produce an update" It's also I think worth noting that all security updates are not urgent. There's a ton of things people file CVE's for that don't matter at all (affect some other os or config than what Fedora uses), matters little (like requires some massively nonstandard configuration and env to matter), or matters rarely (some DOS against a service thats not usually public, etc). And finally I'll trot out the old "Please realize that security is not a checkbox" thing. :) The answer to "is your machine secure?" is never "yes" it's "against what or who for why?" kevin 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: Soname bump of libb2 on F31/EPEL7
Am 16.05.20 um 19:39 schrieb Antonio Trande: > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a > soname bump, so all dependent packages need to be rebuilt: > > $ repoquery --whatrequires libb2-devel --disablerepo=* > --enablerepo=*-source > R-argon2-0:0.2.0-8.fc32.src > borgbackup-0:1.1.11-1.fc32.src > gtkhash-0:1.2-2.fc32.src fine by me. Ideally we could push out all the updated packages in a single update to avoid inconsistencies. Felix ___ 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] Soname bump of libb2 on F31/EPEL7
Am 16.05.20 um 19:39 schrieb Antonio Trande: > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a > soname bump, so all dependent packages need to be rebuilt: > > $ repoquery --whatrequires libb2-devel --disablerepo=* > --enablerepo=*-source > R-argon2-0:0.2.0-8.fc32.src > borgbackup-0:1.1.11-1.fc32.src > gtkhash-0:1.2-2.fc32.src fine by me. Ideally we could push out all the updated packages in a single update to avoid inconsistencies. Felix ___ 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: moreutils newly in PowerTools repo in centos-8
On Sat, May 16, 2020 at 08:42:20PM +0200, clime wrote: > On Sat, 16 May 2020 at 20:33, Paul Howarth wrote: > > > > On Sat, 16 May 2020 20:23:35 +0200 > > clime wrote: > > > I am co-maintaining an epel-7 package (dist-git) and I wanted to add > > > it to epel-8 too. But right now, it wouldn't install because one of > > > the dependencies (moreutils) is newly in PowerTools repo > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1833810). > > > > > > I assume that basically means I cannot depend on such package from an > > > epel-8 package or at least I will solve it like this by removing the > > > dependency. Something like this is a bit surprising, however. I didn't > > > know a repo like that existed. > > > > You can safely depend on things in the PowerTools repo as it's expected > > that EPEL-8 users will also use that repository: > > > > https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F > > > > Looking at the BZ ticket, it seems you discovered that yourself. > > I think in the end it is actually perl(IPC::Run) which is provided by > PowerTools. > > The thing is that the yum error message doesn't say "Enable PowerTools > to install this package". > > I am a long term epel user and I had no idea about PowerTools. Part of the confusion may be that: RHEL's Code Ready Builder repo == CentOS PowerTools. They have the same packages in them, just different names. https://wiki.centos.org/FAQ/CentOS8#Where_is_the_CentOS_8_codeready-developer_equivalent_repo.3F kevin 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
HEADS UP: License change for rust-wild (MIT → MIT or ASL 2.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Starting with version 2.0.3. - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7ASD0ACgkQEV1auJxc Hh5QBhAAssR1Byvq+LuUMsL3zqmBHwCMnu4xVjNq8VDMp0KELM3H8HzMV7jKsa8w s2v1P7HRtKQkGXQMiOgcuLhlhv8b0wMFdPgMlV34UG191EQTMjaJ1KUs3AZoiEo/ 9T8gjcUK3QH/fmlH8KGLq60iUwUd1XWk18R5iPdoO7pT1og/ZEFdaCB6peK+rKNy vtnARytjyntsx8XysqXhplodQgD9msSKFz9F0kpd3FTiIGoI0d6x+7MGN5QwwA+z iwv34OeUYlpGndUB7xEsbFzeI2PeTF+bDfgA8JxzViu2Mi52MZ0Ut1nzded+DoSu f5tLHlgIvx1Pv5DWBdGyuS9sP5aqkzOeAcrza9bCRPxxVxOHuVZjrPhePhf03Xiy XsKRiUpvRo8fkOQJTewebbkw8yJhWYlmrONOYxnOlskW5Vu65mkF75xN4fQygT6M VhrGw/DHO0H0A5DGVRPvhXbsUrxD0IzS1WQi8wnAtM17KOgBqMwJOTAm71JPgHmM zU//pY8zgE6p+Hf53dMhxpga2MJrPpJq7G/yXaceOOWV/CmjEDRGx09MtemDvHzJ Q4nxZHHTLSZuYz1yJa9qA/ILyiWN5m/B9n/MrSu6OOlttRdmSAnS95xFBtqY8pGn iBfGo7jzncd7nIA1zGuj2BeUaH/MAHOTjDiJlAUqVsqGKgEp0fU= =0t/p -END 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
Orphaning vala - asking for new owner
Hi all, I'm still the primary maintainer for Vala, but de facto have not been doing much with it -- it mostly gets auto-upgraded together with the rest of the GNOME stack. As such I'm not really the best person to have issues assigned to, and if anyone else wants to take over the reign, I'll transfer ownership directly rather than causing a mad scramble by directly orphaning. Thanks, -- 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 ___ 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: Fedora 32: samba 4.12.2: Problem with access from win10b to win10a via remote desktop
On la, 16 touko 2020, Dario Lesca wrote:
Il giorno ven, 15/05/2020 alle 18.08 +0200, Dario Lesca ha scritto:
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
Is this the right place for submit this kind of question?
Or I must use another channel? what?
Please open a bug in bugzilla.
This is one of user-to-user authentication cases that aren't implemented
properly in MIT Kerberos and Samba AD for aliases (SPNs) of the machine
account:
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
From Windows point of view TERMSRV/win10a is a service principal
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Samuel Sieb wrote on Sat, May 16, 2020: > On 5/16/20 3:56 AM, Dominique Martinet wrote: >> - down to 0.130s after moving /etc/bash_completion.d/* to >> /usr/share/bash-completion/completions/ > > I thought that generally, the /etc versions of config directories > were intended for the purpose of local overrides of the /usr/share > versions. Well that is for sure where I would install my own completion scripts not in rpms, similarily to how just about everything else works with /etc vs /usr (systemd, udev and friends at least) >> This one is not actually a no-op: bash-completion loads things from /etc >> at shell startup time, but things in /usr at first tab time, so if the >> file in /usr/share is not named by the same prefix as the command it >> help completes it won't work anymore, but in most case here it will >> still work just the same (slightly slower on first use) > > That's a strange separation of functionality. Maybe that's why some > of them are in there? The usual "solution" in this case for products that want to maintain a single script is just to add symlinks to the main one, for example see lvm: lvchange lvcreate lvdisplay etc etc all symlink to 'lvm' in /usr/share/bash-completion/completions. Although in this case very few would need to make one, in the full list above they almost all complete a single command so just renaming the file for some would be enough. In the list I gave, the only two exceptions are lilv which completes two commands so would need one link, and fzf which overrides the existing completion for kill so I guess that one has a valid reason to stay in /etc even if I hadn't noticed until now... -- 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
CPE Weekly: 2020-05-16
# CPE Weekly: 2020-05-16 --- title: CPE Weekly status email tags: CPE Weekly, email --- Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS.Check out our teams info here https://docs.fedoraproject.org/en-US/cpe/ ## GitForge Updates I am going to try provide weekly updates here https://fedoraproject.org/wiki/Git_forge_update, however this is project is a huge undertaking and will not be achieved over the next few months, so some weeks I may not have any new information to share with you. Currently our entire infra team are engaged in a datacentre move, and then our team will be assisting in the F33 release so the rest of 2020 is pretty full to say the least! This lengthy period of investigation is good though because it serves as a great opportunity to explore every inch of this project technically to ensure the best possible outcome from this change that everyone benefits from. We as a team can actively engage in real time with the community via the [ticket filed in GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/217350) by cverna for technical mapping and through my office hours on IRC @ 1300 UTC on #fedora-meeting-1 every Thursday for real conversation and engagement with us. Its optional, but I really appreciate when people can stop by and talk to me (and us) about this. During these office hours I was reminded the Pagure community was owed some insight on how Pagure was viewed during the process. This text has been ported to a hackmd file from a google doc for readers who use terminals, etc for easier reading and here is the link to the email https://lists.pagure.io/archives/list/pagure-de...@lists.pagure.io/thread/JLFPP374GCEMVUXJ3RMA7WSIWBGNGQFA/ Thank you again for your continued engagement with us and your patience over the coming months as we move slowly through all of the technical aspects of this project. ### Current Projects We are Working on The CPE team are using taiga.io for our projects backlog and to show what projects we are currently working on. Each team updates their project card with current information on their project. If you want to see what we currently have in progress, and whats in our backlog for our next quarter, feel free to check it out at: https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null Its a work in progress and not perfect but we hope this is a good way to get our initiatives out in the public in an easy to see manner. ### CFP Dates * DevConf.US CFP open - https://www.devconf.info/us/ * CentOS Dojo @ DevConf.US CFP also open - https://wiki.centos.org/Events/Dojo/DevconfUS2020 ### Data Centre Move * Communishift is unfortunately still offline until mid to end of June. * Our primary focus is the bringup of the reduced Fedora offering that is expected to be live from June 15th 2020 and will be in place until estimated 28th July 2020. * A recap of services you can expect to still have access to can be found here https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view * Updates to impacted services are also being posted here https://status.fedoraproject.org/ * Again, as this project is currently being run by a two man team, we both appreciate and thank you for your patience for delayed replies to tickets/requests/pings related to Fedora infra. ### AAA Replacement * Recent changes include a few bugfixes, UI improvements, and a way for users to programmatically request a certificate to be signed by the IPA CA (CentOS packagers authenticate to their Koji instances with certificates). * Check out our new side-module Flask-Healthz if you have a Flask app and you want to add the liveness and readiness checks in OpenShift. We needed that so we made a reusable module that all our Flask apps should be able to use should they need to. It’s on PyPI already, and very simple to use. ### Sustaining Team * We have Pull Requests for the ansible repo :-) and it works great. Changes are verified with ansible-review by our Zuul CI. * Bodhi 5.3 released, looking to deploy it next week in prod (rebuild bodhi-backend01 to Fedora 32) * Sigul is buildable now, the last time it was built is on F29. * Improvement to our Ticket Dashboard, we are in a good place to start using it. https://fedora-infra.github.io/tbs/ * Next few weeks will be focusing helping with Colo move (deployment of apps in the IAD2)so some of our team members will be unavailable for support ## Mbbox Our Issue tracker dashboard is here https://github.com/fedora-infra/mbbox/projects/1 * This weeks work included: * Identity container image for testing * Set up ReadTheDocs documentation * Koji-builder CRD - still some issues connecting to koji-hub, but most of the work on koji-builder is done * Koji-hub CRD documentation * Koji-builder MBOX automatic image build on quay.io -this is only the image we provide as part of mbox, the koji doesn’t provide any ## CentOS Updates ### CentOS CI *
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
On 5/16/20 3:56 AM, Dominique Martinet wrote: - down to 0.130s after moving /etc/bash_completion.d/* to /usr/share/bash-completion/completions/ I thought that generally, the /etc versions of config directories were intended for the purpose of local overrides of the /usr/share versions. This one is not actually a no-op: bash-completion loads things from /etc at shell startup time, but things in /usr at first tab time, so if the file in /usr/share is not named by the same prefix as the command it help completes it won't work anymore, but in most case here it will still work just the same (slightly slower on first use) That's a strange separation of functionality. Maybe that's why some of them are in there? ___ 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: moreutils newly in PowerTools repo in centos-8
On Sat, 16 May 2020 at 20:33, Paul Howarth wrote: > > On Sat, 16 May 2020 20:23:35 +0200 > clime wrote: > > I am co-maintaining an epel-7 package (dist-git) and I wanted to add > > it to epel-8 too. But right now, it wouldn't install because one of > > the dependencies (moreutils) is newly in PowerTools repo > > (https://bugzilla.redhat.com/show_bug.cgi?id=1833810). > > > > I assume that basically means I cannot depend on such package from an > > epel-8 package or at least I will solve it like this by removing the > > dependency. Something like this is a bit surprising, however. I didn't > > know a repo like that existed. > > You can safely depend on things in the PowerTools repo as it's expected > that EPEL-8 users will also use that repository: > > https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F > > Looking at the BZ ticket, it seems you discovered that yourself. I think in the end it is actually perl(IPC::Run) which is provided by PowerTools. The thing is that the yum error message doesn't say "Enable PowerTools to install this package". I am a long term epel user and I had no idea about PowerTools. clime > > Paul. > ___ > 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
Review Swap and/or simple review: studio-controls and mudita24
Hi all, I would like to get a couple of packages reviewed, and maybe do a review swap, but I'm not sure how much help I would be on other packages since I still feel pretty new to this. First up is studio-controls: https://bugzilla.redhat.com/show_bug.cgi?id=1836542 Studio Controls is formerly known as Ubuntu Studio Controls. It is the bread-and-butter of the audio setup in Ubuntu Studio that makes it so simple to work with Jack and work with multiple audio devices with Jack which is not possible with other utilities, namely qjackctl. Recently, the main developer and I made this a true upstream project. I wish to bring this application to Fedora. Next is mudita24: https://bugzilla.redhat.com/show_bug.cgi?id=1836540 mudita24 is a modification of envy24control in alsa-tools. envy24control has some limitations and is known for being extremely buggy. This application fills a lot of the shortcomings that envy24control has. Let me know if you have any questions. Erich Erich Eickmeyer Fedora Jam 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: moreutils newly in PowerTools repo in centos-8
On Sat, 16 May 2020 20:23:35 +0200 clime wrote: > I am co-maintaining an epel-7 package (dist-git) and I wanted to add > it to epel-8 too. But right now, it wouldn't install because one of > the dependencies (moreutils) is newly in PowerTools repo > (https://bugzilla.redhat.com/show_bug.cgi?id=1833810). > > I assume that basically means I cannot depend on such package from an > epel-8 package or at least I will solve it like this by removing the > dependency. Something like this is a bit surprising, however. I didn't > know a repo like that existed. You can safely depend on things in the PowerTools repo as it's expected that EPEL-8 users will also use that repository: https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F Looking at the BZ ticket, it seems you discovered that yourself. Paul. ___ 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
moreutils newly in PowerTools repo in centos-8
Hello, I am co-maintaining an epel-7 package (dist-git) and I wanted to add it to epel-8 too. But right now, it wouldn't install because one of the dependencies (moreutils) is newly in PowerTools repo (https://bugzilla.redhat.com/show_bug.cgi?id=1833810). I assume that basically means I cannot depend on such package from an epel-8 package or at least I will solve it like this by removing the dependency. Something like this is a bit surprising, however. I didn't know a repo like that existed. clime ___ 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: Fedora 32: samba 4.12.2: Problem with access from win10b to win10a via remote desktop
Il giorno ven, 15/05/2020 alle 18.08 +0200, Dario Lesca ha scritto:
> 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
>
Is this the right place for submit this kind of question?
Or I must use another channel? what?
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:
[Bug 1836538] New: perl-HTML-Mason-1.59 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1836538 Bug ID: 1836538 Summary: perl-HTML-Mason-1.59 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-Mason Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.59 Current version/release in rawhide: 1.58-8.fc32 URL: http://www.masonhq.com 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/7116/ -- 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: Soname bump of libb2 on F31/EPEL7
On 16/05/20 19:39, Antonio Trande wrote: > Hi all. > > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a > soname bump, so all dependent packages need to be rebuilt: > > $ repoquery --whatrequires libb2-devel --disablerepo=* > --enablerepo=*-source > R-argon2-0:0.2.0-8.fc32.src > borgbackup-0:1.1.11-1.fc32.src > gtkhash-0:1.2-2.fc32.src > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1836534 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1836535 -- --- 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: Soname bump of libb2 on F31/EPEL7
On 16/05/20 19:39, Antonio Trande wrote: > Hi all. > > `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a > soname bump, so all dependent packages need to be rebuilt: > > $ repoquery --whatrequires libb2-devel --disablerepo=* > --enablerepo=*-source > R-argon2-0:0.2.0-8.fc32.src > borgbackup-0:1.1.11-1.fc32.src > gtkhash-0:1.2-2.fc32.src > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1836534 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1836535 -- --- 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
Soname bump of libb2 on F31/EPEL7
Hi all. `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a soname bump, so all dependent packages need to be rebuilt: $ repoquery --whatrequires libb2-devel --disablerepo=* --enablerepo=*-source R-argon2-0:0.2.0-8.fc32.src borgbackup-0:1.1.11-1.fc32.src gtkhash-0:1.2-2.fc32.src -- --- 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
[EPEL-devel] Soname bump of libb2 on F31/EPEL7
Hi all. `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a soname bump, so all dependent packages need to be rebuilt: $ repoquery --whatrequires libb2-devel --disablerepo=* --enablerepo=*-source R-argon2-0:0.2.0-8.fc32.src borgbackup-0:1.1.11-1.fc32.src gtkhash-0:1.2-2.fc32.src -- --- 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
looking for scipy on python 3.8 (RISCV Fedora Release 32)
Hello All, I was working on getting tensorflow compiled within the *RISCV *Fedora environment. I am using the latest release 32 build. Currently I am unable to install the dependent library, scipy due to the same not being available for python 3.8.1 which is currently installed. *[riscv@fedora-riscv ~]$ sudo dnf install python3-scipyLast metadata expiration check: 0:22:10 ago on Sat 16 May 2020 12:02:37 PM EDT.Error: Problem: conflicting requests - nothing provides libpython3.7m.so.1.0()(64bit) needed by python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64 - nothing provides python(abi) = 3.7 needed by python3-scipy-1.1.0-3.0.riscv64.fc29.riscv64(try to add '--skip-broken' to skip uninstallable packages)* *[riscv@fedora-riscv ~]$ cat /etc/redhat-releaseFedora release 32 (Rawhide)[riscv@fedora-riscv ~]$ python3 --versionPython 3.8.1* Can you please let me know if we can have the same soon? Regards, Arun SL ___ 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: Licence confirmation for tpcclib
Hey, I confirmed it with upstream. The files with GPL 2 license were actually not included in compilation and > are now removed. Most of the small files without license are test data > which obviously cannot be edited to contain license, but I have omitted the > license from individual code files too, because I hope it would be > sufficient to have GPL3 in the main docs, covering the whole library. > > The winpthreads.md needs to be included with Windows binaries, but that > library is not used in other platforms, and thus not relevant to this. > Should I go ahead with GPL3 then? Regards, Purusharth S. On Sat, 9 May 2020 at 00:18, David Cantrell wrote: > On Fri, May 08, 2020 at 06:11:32PM +0100, J. Randall Owens wrote: > >On 08/05/2020 17:33, David Cantrell wrote: > >> On Fri, May 08, 2020 at 03:41:36AM +0530, Purusharth Saxena wrote: > >>> Hi folks, > >>> > >>> I'm packaging tpcclib > >>> (https://bugzilla.redhat.com/show_bug.cgi?id=1832562) > >>> and as per the review, I wanted to confirm the licence for tpcclib ( > >>> https://gitlab.utu.fi/vesoik/tpcclib/-/blob/master/license.md) > >>> Should it be "GPLv2+ and GPLv3+ "or something else? > >> > >> The copying.md file includes this: > >> > >> "This program library is free software; you can redistribute it and/or > >> modify > >> it under the terms of the GNU General Public License as published by the > >> Free > >> Software Foundation; either version 3 of the License, or (at your > >> option) any > >> later version." > >> > >> The '+' on the GPLv3+ means "GPL version 3 or any later version. > >> > >> It's also a good idea to check for license text in individual files in > the > >> project. For GPL projects, I like to do this: > >> > >> find . -type f | xargs grep "General Public" > >> > >> Which does a more or less ok job of finding files with what is probably > >> a GPL > >> boilerplate. That gives me 39 files. Now, that's all files including > >> non-source. But in this case I am looking for any file that would > indicate > >> something other than GPLv3+ Further refining: > >> > >> find . -type f | xargs grep "General Public" | \ > >> cut -d ':' -f 1 | sort | uniq > >> > >> Gives me 10 files. I can do this: > >> > >> find . -type f | xargs grep "General Public" | \ > >> cut -d ':' -f 1 | sort | uniq \ > >> xargs grep -i "any later version" > >> > >> And see it matches 6 files. So 4 of those original files found lack the > >> same > >> kind of boilerplate. Running the previous command and comparing it to > what > >> was found, I see the sounds files in v1/ and v2/ were left out. > > > >Side tip: I'm guessing you don't know about `grep -rl`, & maybe a little > >`sort -u`? These could be much simplified as: > >grep -rl "General Public" > >grep -rl "General Public" | xargs grep -i "any later version" > >(which I guess eliminates the `sort | uniq` step anyway). > > I do actually know about those options. They've just never made it to my > muscle memory. cut(1) is my hammer and stdin are nails. ¯\_(ツ)_/¯ > > In this case, my needlessly exhaustive and verbose command makes it clear > to > the reader what I'm doing where condensing it with options could be > somewhat > more confusing depending on the audience. (though cut is also cryptic to > anyone who hasn't used it...oh well) > > Thanks, > > -- > David Cantrell > Red Hat, Inc. | Boston, MA | EST5EDT > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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
Re: Proposal: Revise FESCo voting policy
On Sat, May 16, 2020 at 9:02 AM Kevin Kofler wrote: > > Stephen Gallagher wrote: > > One thing that I think this conversation thread *has* achieved is > > identifying that most Fedorans don't consider a FESCo member voting in > > favor of their own Change Proposal to be a conflict of interest. I > > think we should probably recognize this and take that out of the > > equation (which also has the side-effect of reducing the frequency we > > might need to deal with such things). > > For the record, I *do* consider this a conflict of interest. > > But there are actually many more conflicts of interest that are not > immediately recognized, even by the people concerned. Many FESCo members are > members of some workgroup and will thus be biased in favor of changes > submitted by that workgroup. I don't think this necessarily is as strong conflict of interest as you'd expect. Most folks are involved in multiple teams (WGs, SIGs, etc.) and those "conflicts" naturally exist. I think the only *real* conflict would be a change owner voting *for* their change. For example, If this were such a thing to worry about, I'd be unable to vote for any change proposal, due to the number of groups I *actually* do work in. > Also, FESCo members are often Red Hat > employees. > Only way to fix that is for more non-RHers to run for FESCo. ;) But again, I don't necessarily see them being employed by Red Hat as a negative there. It *does* induce some bias, for sure, but in general, this is a lot less pronounced than many folks would expect. And I'm speaking as someone who tends to run into them more often than not. ;) Today, there are a mix of Red Hat and non-Red Hat folks, and it seems to work out fine. And even Red Hatters have pushed back against other Red Hat-driven changes. So I think this fear is mostly unfounded. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
On Sat, 16 May 2020 11:23:03 +0200 Nicolas Mailhot wrote: > Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit : > > On Fri, 15 May 2020 08:02:34 +0200 > > Michal Srb wrote: > > > > 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? > > No, that’s similar to venv everywhere. The language has bytecode- > sharing objects. Java upstreams just got used not to share those > executable objects between projects, not to version them properly, not > to manage their ABI breaks, and to change things in the local copy > instead of contributing changes to the original project. > > That’s non-free software open source to its extreme. The code is > available for a dev to copy and resell at his next work, but > everything is organised (at the human not technical level) so it’s > not possible to reuse the bytecode directly without paying someone to > copy and fork the original code that this bytecode was generated from > in the next project. > > The practical effect is technical stagnation and market capture by > deep pocket companies. Thanks for the explanation. ___ 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
Charalampos Stratakis wrote: > kkoflercalamares kig These both embed the Python interpreter and thus necessarily link to libpython. Kevin Kofler ___ 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: Proposal: Revise FESCo voting policy
Stephen Gallagher wrote: > One thing that I think this conversation thread *has* achieved is > identifying that most Fedorans don't consider a FESCo member voting in > favor of their own Change Proposal to be a conflict of interest. I > think we should probably recognize this and take that out of the > equation (which also has the side-effect of reducing the frequency we > might need to deal with such things). For the record, I *do* consider this a conflict of interest. But there are actually many more conflicts of interest that are not immediately recognized, even by the people concerned. Many FESCo members are members of some workgroup and will thus be biased in favor of changes submitted by that workgroup. Also, FESCo members are often Red Hat employees. Kevin Kofler ___ 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: Proposal: Revise FESCo voting policy
Jared K. Smith wrote: > I'm going to disagree with you here, specifically with regards to the "I > don't care" piece. From my time in FESCo, and as the FPL before that -- I > can never remember a time when someone abstained because they didn't care. > I remember people abstaining because they didn't feel it was appropriate > for them to vote on their own ticket, or they felt uncomfortable for > whatever reason, but never simply because they didn't care. > > Please remember that FESCo members can vote either "+1" or "0" or "-1" for > a particular change. I would think voting "0" would be more appropriate > for a "I don't care" vote. But I still don't see an "I don't care" vote > as a reason to abstain. Voting "0" is exactly what I mean by "abstain". Kevin Kofler ___ 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?
Le samedi 16 mai 2020 à 11:09 +0200, Nicolas Mailhot a écrit :
> Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit :
> > So, another way that could work, with minimal tooling is that we
> > keep
> > the master branch strictly mirroring whatever upstream branch we
> > follow,
>
> For some projects we are not hopping between branches of the same
> upstream git, we are hopping between branches in different forked
> repos of the same upstream
To expand a little: when you are creating a Fedora package, you are
packaging a fixed code state (and the state must stay fixed for trivial
reproducibility, auditing, and security reasons). In git speak that
means you are packaging a specific commit reference, that may (if
upstream is careful and serious) be tagged with a clean fixed version
string.
That means packaging a branch is a no-go. It’s not a fixed git
reference, it’s a moving reference.
*How* upstream arrived to this fixed state from the last packaged fixed
state is deeply uninteresting from the srpm POW.
It may not even exist
as clean git history upstream (assuming upstream uses git). For
exemple, you package foo project, it gets in governance trouble and the
original repository is no longuer updated, so you bet on fork foo1,
that seems to have picked up the dev. Six months later you lost your
bet, devs have consolidated on foo2 fork. There is no clean upstream
git history from foo1 to foo2, foo1 is a dead evolutionary path.
Also there may even be a complete state tracking hole somewhere in the
middle, because the creator of foo2 did not bother importing foo
history in its own repo, and did some private dev starting from a
partial copy of some (reformatted/reprocessed) foo files. Having needed
to reconstitute fragmentary dev history in a new consolidated upstream
git, I can tell you splicing past repo history fragments is non-
trivial. I can totally understand why some upstreams do not bother with
it after a governance accident.
Therefore, all the systems that try to base a Fedora package history on
the mirorring of a unified unchanging monotonic upstream repo are
broken by construction. The only thing you can reliably import in
Fedora land are specific hashes or tags. And the upstream repo where
you can find those hashes or tags may change over time.
I suppose you *could* ask a downstream Fedora scm “mirror” to compute a
git path from the last packaged state to the new one, faking a merge of
the new state over the last state, and faking continuous regular
upstream history.
But why bother? You’d be creating artificial git history
complexity that will exist Fedora-side only, and that upstream will not
understand and disagree with, just to avoid cloning the upstream repo
of the day separately to make your changes and PRs there.
Also, rpm is able to package multiple source archives in a single spec,
and we have packagers that make use of this capability. If you wanted a
fully working scm mirroring system, not only would you need to fake
continuity between upstream scm repositories that do not provide this
continuity, but to merge multiple upstream scm repositories in a single
downstream git (good luck producing patches that upstream will accept
from this unified repository).
In the meanwhile, you could just dump in your spec file
%global forgeurl0 https://repo0
%global commit0 hash0
# repo0 time handling is broken
%global time0 2020-05-16T12:25:43+00:00
%global forgeurl1 https://repo1
%global tag1x.y.z
%global forgepatchlist1 %{expand:
foo1X.patch
foo2X.patch
}
%forgemeta
%sourcelist
%forgesources
%patchlist
%forgepatches
…
%setup
%forgesetup
and be done. All existing Fedora tools like spectool will work just
fine on that (actually the forge macros are not quite there yet in the
version included in redhat-rpm-config, I still need to upstream
multipatch handling once I finish QAing it)
Regards,
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://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: AskFedora: Can someone please answer this question on security fixes on
On Sat, May 16, 2020 at 11:39 AM Dominique Martinet wrote: > Hi, > > Ankur Sinha wrote on Sat, May 16, 2020: > > As subject says: > > > https://ask.fedoraproject.org/t/comparing-fedora-centos-security-fix-lag/7117 > > > > (I looked around a bit and couldn't find any documentation on this). > > I've tried for a bit (~10 mins) but I really can't get discourse to let > me reply, probably an issue on my end but since I'm also curious about > it I can give the start of an answer here: > > - first for opaque security issues, fedora isn't on linux-distro list: > https://oss-security.openwall.org/wiki/mailing-lists/distros > This means that fedora as its own entity does not benefit from advanced > warning when such an issue occurs, apparently. > I'm curious about this point, there is a security team[0] so it could be > interesting to get one of them on the list? I'm not following quite > close enough what they do... > [0] https://fedoraproject.org/wiki/Category:Security_Team?rd=Security_Team It lists "Red Hat", not "Red Hat Enterprise Linux", so it is entirely possible that Fedora is under the Red Hat umbrella for that list. Also, I would imagine fixes can be ported back from RHEL maintainers when they are able (and with the recent initiative to merge the kernel patches that may mean Fedora gets the kernel patches when they are able to go public). -Ian ___ 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: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Hi Dominique, Dominique Martinet writes: > *snip* > > 341 to 130ms is a good start I guess, the rest of the waiting time > probably now outweights bash and will get some looking at at a later > point, but might as well start somewhere. That's quite the improvement! Good job and thanks for looking into that! > > How should I go about with that? Open bz bugs to all the packages I > listed? I would suggest to directly create pull requests on pagure (with a reference to this thread), as that will make it more likely that this change will actually happen. > strongly suggesting to get things to move to /usr/share (17) and > flatpak (suggest some kind of cache? not sure they'll be > interested...) and environment-modules (not sure what to suggest > there, I only have environment-modules because I need to test > something with openmpi from time to time and it comes with it...) > > > It might also make sense to have a packaging guideline suggesting to > avoid /etc/bash_completion.d in favor of the /usr/share variant, I > couldn't find anything here[1] but I might not have looked thoroughly > enough... Afaik we don't have an entry in the packaging guidelines about bash completion files. Maybe the packaging committee should look into that? Cheers, Dan 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Vascom wrote on Sat, May 16, 2020: > Are you use SSD? > > I have 0.087s on it. Yes, I have a SSD. The bottleneck here really is cpu speed; I have my laptop's frequency limited to 1GHz in normal circumstances (when not building code or similar activities) so the fan doesn't turn up With max (4.6GHz) clocking the whole time is a bit less drastic, but still worth more than half the time: going from 0.097s to 0.037s I'd rather not use "I have a performant machine" as an excuse, though - my next laptop will likely be based on a low power ARM soc and I might not be that aggressive on throttling since it won't have a fan in the first place, but it will likely be much slower than this :P That's precisely the kind of thinking that makes everything feel just as slow today than they were 20 years ago despite having much more powerful computers... -- 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
Re: AskFedora: Can someone please answer this question on security fixes on
On Sat, May 16, 2020 at 12:38:06PM +0200, Dominique Martinet wrote: > I'm curious about this point, there is a security team[0] so it could be > interesting to get one of them on the list? I'm not following quite > close enough what they do... Currently there is not too much activity in the security team. Historically the tasks were mostly keeping an eye on open security issues and checking for long unfixed issues. For packages having the same maintainer in RHEL and Fedora I suppose there is a synergy effect that fixes also land in Fedora early. In both irc channels (#fedora-security, #fedora-security-team) now and then someone joins with a security related question, there are a few people there answering those. The mailinglist is mostly dead - I'd guess it might be a good idea to send out security reports again. All the best, David 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
Re: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Are you use SSD? I have 0.087s on it. сб, 16 мая 2020 г., 13:57 Dominique Martinet : > Hi, > > once in a while I get annoyed at how slow bash is to startup; using a > tiling wm poping a new shell is supposed to be quite fast but I'm > staring at a new empty window for ~1s everytime and it gets annoying... > > According to https://xkcd.com/1205/ wasting 1s 50+ times a day is worth > spending some time to try to improve it so let's see what we can do :) > > > Here's the baseline on my machine: > $ time bash -l < /dev/null > > real0m0.341s > user0m0.198s > sys 0m0.146s > > > And a few low hanging fruits I could find adding `-x 2>&1 | ts "%.s"`: > - down to 0.288s after removing /etc/profile.d/flatpak.sh > (flatpak-1.6.3-1.fc32.x86_64) > > - down to 0.225s after removing /etc/profile.d/modules.sh > (environment-modules-4.4.1-2.fc32.x86_64) > > - down to 0.130s after moving /etc/bash_completion.d/* to > /usr/share/bash-completion/completions/ > This one is not actually a no-op: bash-completion loads things from /etc > at shell startup time, but things in /usr at first tab time, so if the > file in /usr/share is not named by the same prefix as the command it > help completes it won't work anymore, but in most case here it will > still work just the same (slightly slower on first use) > > Here's the list of files I had in there and their packages: > authselect-completion.sh authselect-1.2.1-1.fc32.x86_64 > fcoeadm fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 > javaws.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 > perf perf-5.6.7-300.fc32.x86_64 > trace-cmd.bash trace-cmd-2.8.3-1.fc32.x86_64 > bpftool bpftool-5.6.7-300.fc32.x86_64 > fcoemon fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 > policyeditor.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 > xl.sh xen-runtime-4.13.0-7.fc32.x86_64 > cargo cargo-1.43.1-1.fc32.x86_64 > fzf fzf-0.21.1-1.fc32.x86_64 > lilv lilv-0.24.6-2.fc32.x86_64 > python-argcomplete.sh python3-argcomplete-1.10.0-4.fc32.noarch > dbus-bash-completion.sh dbus-glib-devel-0.110-7.fc32.x86_64 > gluster glusterfs-cli-7.5-1.fc32.x86_64 > lldpad lldpad-1.0.1-16.git036e314.fc32.x86_64 > redefine_filedir bash-completion-2.8-8.fc32.noarch > dog sheepdog-1.0.1-10.fc31.x86_64 > itweb-settings.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 > lldptool lldpad-1.0.1-16.git036e314.fc32.x86_64 > torsocks torsocks-2.3.0-5.fc32.x86_64 > > > 341 to 130ms is a good start I guess, the rest of the waiting time > probably now outweights bash and will get some looking at at a later > point, but might as well start somewhere. > > How should I go about with that? Open bz bugs to all the packages I > listed? strongly suggesting to get things to move to /usr/share (17) and > flatpak (suggest some kind of cache? not sure they'll be interested...) > and environment-modules (not sure what to suggest there, I only have > environment-modules because I need to test something with openmpi from > time to time and it comes with it...) > > > It might also make sense to have a packaging guideline suggesting to > avoid /etc/bash_completion.d in favor of the /usr/share variant, I > couldn't find anything here[1] but I might not have looked thoroughly > enough... > [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > Would anyone be willing to help, something is telling me that doing this > alone would take more time than what I'd save in the end, but a few > people considering it'll help everyone might be ;) > > > Thanks! > -- > 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 > ___ 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
Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Hi, once in a while I get annoyed at how slow bash is to startup; using a tiling wm poping a new shell is supposed to be quite fast but I'm staring at a new empty window for ~1s everytime and it gets annoying... According to https://xkcd.com/1205/ wasting 1s 50+ times a day is worth spending some time to try to improve it so let's see what we can do :) Here's the baseline on my machine: $ time bash -l < /dev/null real0m0.341s user0m0.198s sys 0m0.146s And a few low hanging fruits I could find adding `-x 2>&1 | ts "%.s"`: - down to 0.288s after removing /etc/profile.d/flatpak.sh (flatpak-1.6.3-1.fc32.x86_64) - down to 0.225s after removing /etc/profile.d/modules.sh (environment-modules-4.4.1-2.fc32.x86_64) - down to 0.130s after moving /etc/bash_completion.d/* to /usr/share/bash-completion/completions/ This one is not actually a no-op: bash-completion loads things from /etc at shell startup time, but things in /usr at first tab time, so if the file in /usr/share is not named by the same prefix as the command it help completes it won't work anymore, but in most case here it will still work just the same (slightly slower on first use) Here's the list of files I had in there and their packages: authselect-completion.sh authselect-1.2.1-1.fc32.x86_64 fcoeadm fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 javaws.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 perf perf-5.6.7-300.fc32.x86_64 trace-cmd.bash trace-cmd-2.8.3-1.fc32.x86_64 bpftool bpftool-5.6.7-300.fc32.x86_64 fcoemon fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 policyeditor.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 xl.sh xen-runtime-4.13.0-7.fc32.x86_64 cargo cargo-1.43.1-1.fc32.x86_64 fzf fzf-0.21.1-1.fc32.x86_64 lilv lilv-0.24.6-2.fc32.x86_64 python-argcomplete.sh python3-argcomplete-1.10.0-4.fc32.noarch dbus-bash-completion.sh dbus-glib-devel-0.110-7.fc32.x86_64 gluster glusterfs-cli-7.5-1.fc32.x86_64 lldpad lldpad-1.0.1-16.git036e314.fc32.x86_64 redefine_filedir bash-completion-2.8-8.fc32.noarch dog sheepdog-1.0.1-10.fc31.x86_64 itweb-settings.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 lldptool lldpad-1.0.1-16.git036e314.fc32.x86_64 torsocks torsocks-2.3.0-5.fc32.x86_64 341 to 130ms is a good start I guess, the rest of the waiting time probably now outweights bash and will get some looking at at a later point, but might as well start somewhere. How should I go about with that? Open bz bugs to all the packages I listed? strongly suggesting to get things to move to /usr/share (17) and flatpak (suggest some kind of cache? not sure they'll be interested...) and environment-modules (not sure what to suggest there, I only have environment-modules because I need to test something with openmpi from time to time and it comes with it...) It might also make sense to have a packaging guideline suggesting to avoid /etc/bash_completion.d in favor of the /usr/share variant, I couldn't find anything here[1] but I might not have looked thoroughly enough... [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ Would anyone be willing to help, something is telling me that doing this alone would take more time than what I'd save in the end, but a few people considering it'll help everyone might be ;) Thanks! -- 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
Fedora-Cloud-32-20200516.0 compose check report
No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 599812 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/599812 -- 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
Fedora-Cloud-31-20200516.0 compose check report
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: AskFedora: Can someone please answer this question on security fixes on
Hi, Ankur Sinha wrote on Sat, May 16, 2020: > As subject says: > https://ask.fedoraproject.org/t/comparing-fedora-centos-security-fix-lag/7117 > > (I looked around a bit and couldn't find any documentation on this). I've tried for a bit (~10 mins) but I really can't get discourse to let me reply, probably an issue on my end but since I'm also curious about it I can give the start of an answer here: - first for opaque security issues, fedora isn't on linux-distro list: https://oss-security.openwall.org/wiki/mailing-lists/distros This means that fedora as its own entity does not benefit from advanced warning when such an issue occurs, apparently. I'm curious about this point, there is a security team[0] so it could be interesting to get one of them on the list? I'm not following quite close enough what they do... [0] https://fedoraproject.org/wiki/Category:Security_Team?rd=Security_Team - However in practice that does not seem to be much of a problem, taking any random recent CVE e.g. CVE-2020-5260 which was made public on April 14 2020 got released April 17 for debian[1], April 21 for rhel7[2] & hitting centos on april 29[3], and april 15 for fedora[4] (stable on 25th[5]). I guess it wasn't marked as critical to skip through testing but overall this isn't so bad, I guess? The update itself actually got pushed to fedora before rhel customers got it, so anyone with fedora-testing enabled would have gotten it pretty damn fast. [1] https://tracker.debian.org/pkg/git (2.20.1-2+deb10u2) [2] https://access.redhat.com/errata/RHSA-2020:1511 [3] http://mirror.centos.org/centos-7/7/updates/x86_64/Packages/ [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=1493735 (for f32 but other branches as well) [5] https://bodhi.fedoraproject.org/updates/FEDORA-2020-c6548b488f Hope this helps, -- 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
Re: [EPEL-devel] Re: Documentation for EPEL modules?
On 15/05/20 14:57, Stephen Gallagher wrote: > 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. Petr, can you take care of this module for epel8, too? -- --- 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
[EPEL-devel] Re: Documentation for EPEL modules?
On 15/05/20 14:57, Stephen Gallagher wrote: > 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. Petr, can you take care of this module for epel8, too? -- --- 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
AskFedora: Can someone please answer this question on security fixes on
Hello, As subject says: https://ask.fedoraproject.org/t/comparing-fedora-centos-security-fix-lag/7117 (I looked around a bit and couldn't find any documentation on this). -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Le vendredi 15 mai 2020 à 08:30 -0700, stan via devel a écrit : > On Fri, 15 May 2020 08:02:34 +0200 > Michal Srb wrote: > > 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? No, that’s similar to venv everywhere. The language has bytecode- sharing objects. Java upstreams just got used not to share those executable objects between projects, not to version them properly, not to manage their ABI breaks, and to change things in the local copy instead of contributing changes to the original project. That’s non-free software open source to its extreme. The code is available for a dev to copy and resell at his next work, but everything is organised (at the human not technical level) so it’s not possible to reuse the bytecode directly without paying someone to copy and fork the original code that this bytecode was generated from in the next project. The practical effect is technical stagnation and market capture by deep pocket companies. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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?
Le vendredi 15 mai 2020 à 11:11 -0400, Simo Sorce a écrit : > > So, another way that could work, with minimal tooling is that we > keep > the master branch strictly mirroring whatever upstream branch we > follow, For some projects we are not hopping between branches of the same upstream git, we are hopping between branches in different forked repos of the same upstream Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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 1835620] perl-Clipboard-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1835620 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Clipboard-0.25 is |perl-Clipboard-0.26 is |available |available --- Comment #3 from Upstream Release Monitoring --- Latest upstream release: 0.26 Current version/release in rawhide: 0.24-1.fc33 URL: http://search.cpan.org/dist/Clipboard/ 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/14091/ -- 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 1835620] perl-Clipboard-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1835620 --- Comment #4 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- 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: > 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. Would it make sense to work around this by some other means? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
On pe, 15 touko 2020, 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)' Samba does use Py_Initialize and thus link correctly. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ 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-20200516.0 compose check report
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: Self Introduction: Dick Marinus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-05-16 at 07:04 +0200, Dick Marinus wrote: > Hi! 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). Welcome aboard! > > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl6/jwcACgkQEV1auJxc Hh4/rg//SQl9NWvQbByk/5iLDtItR6bZ4FStCZJlZwUc0yPnM9xbBN12afsUxelc Cf6vEzYkqfIkvITjXN4hAP3YFZMn/XmQP4b6yGJXghgK3BaIe/Be1YIL7lSs5aAA 6X0ghLRmeWcPNoZz+dUKBnIrulxNlv9DZArfV7a+CDQL7crunMxB0zvx8gQHtpM2 UW+VLutqa8j78bunlJiLiU2nNQXNw+9Kg3ekS3En99wldADh2jfGYmEAiYdEcqF3 ABzaPbFurnwtaQwBqPiR5cR9s+ea6pvnn8Nk+ZVl3CsiV0CTUnvjsTiBg9TaosZY zTLbVqJB/PzNf7w8pioOqrTh75g1PZ/i5rw/7wW7sVBYqZ2suvy4Z3XdPaO620hm /DZPh7hj4cigfMPKSzMMDoqh9Gsc0kEtu/LKIALugwuWKSBPboBnUq5gTygG9lMs y3yg/YolJOPZkNCtU/Pao1zdNEOHULG7MpwD2EDPX2Z0/H6Z/YBDwlD2s8ITj2T4 +UZXnDxokmTTjQmU1YEasPWomBoVc70e42n8ZIA1Jq4tpoDI8xyoozv/3I//0fJU h63DmIfO6MrrRDASRvB5dWTY5iwFbpDAy4C9coQEfcmqddju5/9yTq/FkrFcwKUj YUfeBLIGtZT7TuXRCfwFt8gKzXeMm8nRzROqeXMdPyY5Tsf8e3g= =TWLI -END 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
