PYTEST.pyc files
It appears that in at least some situations pytest will create
-PYTEST.pyc files, and sometimes (always?) with weird permissions:
-rw---. 1 root root 1614 Jul 13 2018
/usr/lib64/python3.7/site-packages/cytoolz/__pycache__/utils_test.cpython-37-PYTEST.pyc
I've noticed the following packages have them:
pytest-4.4.1-1.fc31.src.rpm
python-astropy-healpix-0.4-1.fc31.src.rpm
python-cytoolz-0.9.0.1-3.fc30.src.rpm
python-healpy-1.12.9-1.fc31.src.rpm
python-pytest-repeat-0.8.0-1.fc31.src.rpm
python-pytest-rerunfailures-6.0-1.fc31.src.rpm
python-pytest-shutil-1.6.0-2.fc31.src.rpm
python-reproject-0.4-6.fc30.src.rpm
python3-pytest-asyncio-0.10.0-1.fc31.src.rpm
scipy-1.2.1-1.fc31.src.rpm
These can be prevented by setting PYTHONDONTWRITEBYTECODE=1 when run pytest.
Can anyone else shed more light on this? Should we add this to the
guidelines? (Possibly not since there do not appear to be many packages
like this). I suspect it comes in when has to set
PYTHONPATH=%{buildroot}%{python3_sitearch} due to needing to load
compiled modules.
- Orion
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2019-04-27 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/04/27/report-389-ds-base-1.4.1.2-20190426git6a6b8d9.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1703627] New: perl-Regexp-Grammars-1.050 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703627 Bug ID: 1703627 Summary: perl-Regexp-Grammars-1.050 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Regexp-Grammars Keywords: FutureFeature, Triaged Assignee: wf...@worldbroken.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, wf...@worldbroken.com Target Milestone: --- Classification: Fedora Latest upstream release: 1.050 Current version/release in rawhide: 1.049-2.fc30 URL: http://search.cpan.org/dist/Regexp-Grammars/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3295/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703626] New: perl-Module-Faker-0.021 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703626 Bug ID: 1703626 Summary: perl-Module-Faker-0.021 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-Faker Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.021 Current version/release in rawhide: 0.020-4.fc30 URL: http://search.cpan.org/dist/Module-Faker/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6989/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1664030] perl-Class-DBI-Plugin-Type-0.02-35.fc30 FTBFS: tests fail with perl-DBD-SQLite-1.62-1.fc30
https://bugzilla.redhat.com/show_bug.cgi?id=1664030 Fedora Release Engineering changed: What|Removed |Added Flags||needinfo?(tcallawa@redhat.c ||om) --- Comment #3 from Fedora Release Engineering --- Dear Maintainer, your package has not been built successfully in f30. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. Following the latest policy for such packages [2], your package can be orphaned if this bug remains in NEW state more than 8 weeks. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703622] New: perl-Mojolicious-8.15 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703622 Bug ID: 1703622 Summary: perl-Mojolicious-8.15 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious 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, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Latest upstream release: 8.15 Current version/release in rawhide: 8.14-1.fc31 URL: https://metacpan.org/release/Mojolicious Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5966/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
On 26. 04. 19 23:49, Ben Cotton wrote: * Python 3 will disappear from buildroot (yes, it was there just because of GDB) \o/ That would simplify Python 3.N+1 bootstrapping! Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1698172] perl-Sereal-4.007 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1698172 --- Comment #7 from Fedora Update System --- perl-Sereal-4.007-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7dbf06532f -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot == Summary == Create gdb-minimal package (without XML support, Python support, Syntax Highlight and such) and switch to it in buildroot. == Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio Durigan Junior]] * Email: ignatenkobr...@fedoraproject.org, sergi...@sergiodj.net == Detailed Description == Create subpackage in gdb source package called gdb-minimal that will contain 2 files: * /usr/libexec/gdb-minimal — GDB executable built without optional unneeded features * /usr/bin/gdb-add-index — Executable script shared with gdb-headless package (modified to fallback to gdb-minimal if exists) debuginfo code in RPM needs just gdb-add-index and that one doesn't need any syntax highlight or python plugins to work. As of Apr 26, following packages would disappear from buildroot: boost-regex-1.69.0-6.fc30.x86_64 ctags-5.8-25.fc30.x86_64 gdbm-libs-1:1.18-4.fc30.x86_64 libbabeltrace-1.5.6-2.fc30.x86_64 libicu-63.1-2.fc30.x86_64 libipt-2.0-2.fc30.x86_64 python-pip-wheel-19.0.3-1.fc31.noarch python-setuptools-wheel-40.8.0-1.fc30.noarch python3-3.7.3-2.fc31.x86_64 python3-libs-3.7.3-2.fc31.x86_64 python3-pip-19.0.3-1.fc31.noarch python3-setuptools-40.8.0-1.fc30.noarch source-highlight-3.1.8-24.fc31.x86_64 sqlite-libs-3.27.2-3.fc31.x86_64 == Benefit to Fedora == * Python 3 will disappear from buildroot (yes, it was there just because of GDB) * RPM download size for buildroot preparation will go down from 101M to 85M * installed buildroot size will go down from 439M to 350M == Scope == * Proposal owners: Create a subpackage in gdb, Add Suggests: gdb-minimal into rpm-build * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/8311 #8311] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == User Experience == Python 3 will disappear from buildroot, but nobody should have ever relied on it since we have guidelines about that for long time: https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot == Summary == Create gdb-minimal package (without XML support, Python support, Syntax Highlight and such) and switch to it in buildroot. == Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio Durigan Junior]] * Email: ignatenkobr...@fedoraproject.org, sergi...@sergiodj.net == Detailed Description == Create subpackage in gdb source package called gdb-minimal that will contain 2 files: * /usr/libexec/gdb-minimal — GDB executable built without optional unneeded features * /usr/bin/gdb-add-index — Executable script shared with gdb-headless package (modified to fallback to gdb-minimal if exists) debuginfo code in RPM needs just gdb-add-index and that one doesn't need any syntax highlight or python plugins to work. As of Apr 26, following packages would disappear from buildroot: boost-regex-1.69.0-6.fc30.x86_64 ctags-5.8-25.fc30.x86_64 gdbm-libs-1:1.18-4.fc30.x86_64 libbabeltrace-1.5.6-2.fc30.x86_64 libicu-63.1-2.fc30.x86_64 libipt-2.0-2.fc30.x86_64 python-pip-wheel-19.0.3-1.fc31.noarch python-setuptools-wheel-40.8.0-1.fc30.noarch python3-3.7.3-2.fc31.x86_64 python3-libs-3.7.3-2.fc31.x86_64 python3-pip-19.0.3-1.fc31.noarch python3-setuptools-40.8.0-1.fc30.noarch source-highlight-3.1.8-24.fc31.x86_64 sqlite-libs-3.27.2-3.fc31.x86_64 == Benefit to Fedora == * Python 3 will disappear from buildroot (yes, it was there just because of GDB) * RPM download size for buildroot preparation will go down from 101M to 85M * installed buildroot size will go down from 439M to 350M == Scope == * Proposal owners: Create a subpackage in gdb, Add Suggests: gdb-minimal into rpm-build * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/8311 #8311] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == User Experience == Python 3 will disappear from buildroot, but nobody should have ever relied on it since we have guidelines about that for long time: https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/25/19 6:10 PM, Björn Persson wrote: It's perfectly possible for a number to be unique without being random. As an example, you could hash the machine ID, which is supposedly unique in space, and the system clock, which is unique in time. That makes the hash unique in both space and time. Produce invocation IDs by counting up from that value, or by hashing repeatedly. That way you wouldn't need entropy for invocation IDs at every boot, only during installation. Such values would of course be somewhat predictable, but according to what you've said in this thread, invocation IDs don't need to be unpredictable. You've only said that you want them unique. That is a good point---and by the way, you COULD make the same argument for hashing: one could create another installation-time seed value that will be guaranteed to not leak from the system, and mix it in the hash creation, making the hash unpredictable. Between those two workarounds, it looks to me like we don't need randomness in secular systemd startup at all? (Of course one needs to be aware that collisions are not impossible, only improbable. That's equally true for hashes and random numbers.) At the UUID-level bit lengths, the probability is vanishingly small---although one does have to realize that even very small probability events can be realized with enough statistics, like in this recent measurement of Xenon124 radioactive decay with time constant of over 10^22 years, trillion times longer than the life of the Universe: https://www.nature.com/articles/s41586-019-1124-4 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rpmlint whitelisting broken in taskotron?
On Fri, Apr 26, 2019, 20:24 Tim Flink wrote: > On Fri, 26 Apr 2019 16:42:30 +0200 > Fabio Valentini wrote: > > > Hi, > > > > I've noticed that my bodhi updates started showing rpmlint errors for > > my packages again, where they were previously silent because I supply > > a $SRCNAME.rpmlintrc file in my dist-git repos. > > > > It looks like taskotron is broken and/or ignores this file again. Is > > this a known issue? > > > > For example, this build from today shows rpmlint issues that are > > explicitly whitelisted (using the file locally suppresses the > > warnings/errors as intended): > > > > update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecaba1eef1 > > in repo: > > > https://src.fedoraproject.org/rpms/elementary-greeter/blob/f30/f/elementary-greeter.rpmlintrc > > This was not a known issue, no. It stems from us depending on the cgit > interface which was taken down a few days ago - we're getting 404s when > we try to grab the rpmlintrc file > > I'm still looking into this but have filed an issue track it: > > https://pagure.io/taskotron/libtaskotron/issue/429 > > Thanks for the report and sorry for the bother. > > Tim > Great, thanks for looking into it! pagure provides really simple URLs to fetch raw files, so it shouldn't be hard to adapt the code from cgit, for example: https://src.fedoraproject.org/rpms/elementary-photos/raw/47e73b7ac14dea07b5fcbd39b5f2aff67fea4fbc/f/elementary-photos.rpmlintrc Thanks again, Fabio ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: rpmlint whitelisting broken in taskotron?
On Fri, 26 Apr 2019 16:42:30 +0200 Fabio Valentini wrote: > Hi, > > I've noticed that my bodhi updates started showing rpmlint errors for > my packages again, where they were previously silent because I supply > a $SRCNAME.rpmlintrc file in my dist-git repos. > > It looks like taskotron is broken and/or ignores this file again. Is > this a known issue? > > For example, this build from today shows rpmlint issues that are > explicitly whitelisted (using the file locally suppresses the > warnings/errors as intended): > > update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecaba1eef1 > in repo: > https://src.fedoraproject.org/rpms/elementary-greeter/blob/f30/f/elementary-greeter.rpmlintrc This was not a known issue, no. It stems from us depending on the cgit interface which was taken down a few days ago - we're getting 404s when we try to grab the rpmlintrc file I'm still looking into this but have filed an issue track it: https://pagure.io/taskotron/libtaskotron/issue/429 Thanks for the report and sorry for the bother. Tim pgpoygVPxciLF.pgp 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 Final is GO
The Fedora 30 Final RC1.2 compose [1] is GO and will to be shipped live on Tuesday, April 30, 2019. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. Thank you to everyone who has worked on this release and getting it out on time. [1] https://dl.fedoraproject.org/pub/alt/stage/30_RC-1.2/ [2] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-26/f30-final-go_no_go-meeting.2019-04-26-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-26/f30-final-go_no_go-meeting.2019-04-26-17.00.log.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
[Test-Announce] Fedora 30 Final is GO
The Fedora 30 Final RC1.2 compose [1] is GO and will to be shipped live on Tuesday, April 30, 2019. For more information please check the Go/No-Go meeting minutes [2] or logs [3]. Thank you to everyone who has worked on this release and getting it out on time. [1] https://dl.fedoraproject.org/pub/alt/stage/30_RC-1.2/ [2] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-26/f30-final-go_no_go-meeting.2019-04-26-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting-1/2019-04-26/f30-final-go_no_go-meeting.2019-04-26-17.00.log.html -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis Pronouns: he/him ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190426.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Compose FAILS proposed Rawhide gating check! 2 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 9/146 (x86_64), 3/23 (i386), 1/2 (arm) ID: 391878 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/391878 ID: 391910 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/391910 ID: 391911 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/391911 ID: 391913 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/391913 ID: 391927 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/391927 ID: 391929 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/391929 ID: 391935 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/391935 ID: 391978 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/391978 ID: 391988 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/391988 ID: 392001 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/392001 ID: 392010 Test: x86_64 universal install_multi_empty URL: https://openqa.fedoraproject.org/tests/392010 ID: 392014 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/392014 ID: 392026 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/392026 Soft failed openQA tests: 3/23 (i386), 7/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 391890 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/391890 ID: 391891 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/391891 ID: 391900 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/391900 ID: 391909 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/391909 ID: 391914 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/391914 ID: 391949 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/391949 ID: 391951 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/391951 ID: 391952 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/391952 ID: 391953 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/391953 ID: 392009 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/392009 Passed openQA tests: 130/146 (x86_64), 17/23 (i386) Skipped non-gating openQA tests: 1 of 171 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-04-26)
=== #fedora-meeting: FESCO (2019-04-29) === Meeting started by bowlofeggs at 15:00:00 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-04-26/fesco.2019-04-26-15.00.log.html . Meeting summary --- * init process (bowlofeggs, 15:00:06) * #2088 F31 Change – “dnf --best” as default behavior (bowlofeggs, 15:03:47) * AGREED: ask for a response from jmracek and punt till next week (+6, 0, -0) (bowlofeggs, 15:19:05) * #2096 F31 System-Wide Change: BuildRequires generators (bowlofeggs, 15:19:14) * AGREED: APPROVED (+7, 0, -0) (bowlofeggs, 15:22:44) * #2114 What is the scope of Modularity? (bowlofeggs, 15:23:07) * LINK: https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/ still mentions it. (nirik, 15:49:24) * AGREED: FESCo forbids the addition of new default stream settings without FESCo approval until further notice while we work out the buildroot problems. (+7, 0, -0) (bowlofeggs, 16:06:04) * ACTION: mhroncok to file a bug on the modularity Taiga describing the use cases we need to keep in mind when writing those (modularity default streams) rules (mhroncok, 16:08:05) * #2115 Missing PkgDB features should be implemented (bowlofeggs, 16:10:24) * AGREED: APPROVED (+6, 0, -0) (bowlofeggs, 16:14:56) * ACTION: mhroncok will file a council ticket (bowlofeggs, 16:16:52) * Next week's chair (bowlofeggs, 16:17:49) * ACTION: jforbes will chair next week's meeting (bowlofeggs, 16:18:45) * ACTION: mhroncok will chair in two weeks if we remember this #action line (bowlofeggs, 16:19:00) * Open Floor (bowlofeggs, 16:19:12) * ACTION: somebody to remember what bowlofeggs #actioned (zbyszek, 16:19:26) * LINK: http://testdays.fedorainfracloud.org/events/64 (nirik, 16:22:42) * ACTION: mhroncok to file a releng or infra ticket about cronjob for FTBFS weekly bugzilla reminders (mhroncok, 16:25:42) Meeting ended at 16:28:35 UTC. Action Items * mhroncok to file a bug on the modularity Taiga describing the use cases we need to keep in mind when writing those (modularity default streams) rules * mhroncok will file a council ticket * jforbes will chair next week's meeting * mhroncok will chair in two weeks if we remember this #action line * somebody to remember what bowlofeggs #actioned * mhroncok to file a releng or infra ticket about cronjob for FTBFS weekly bugzilla reminders Action Items, by person --- * bowlofeggs * somebody to remember what bowlofeggs #actioned * jforbes * jforbes will chair next week's meeting * mhroncok * mhroncok to file a bug on the modularity Taiga describing the use cases we need to keep in mind when writing those (modularity default streams) rules * mhroncok will file a council ticket * mhroncok will chair in two weeks if we remember this #action line * mhroncok to file a releng or infra ticket about cronjob for FTBFS weekly bugzilla reminders * **UNASSIGNED** * (none) People Present (lines said) --- * bowlofeggs (112) * mhroncok (87) * nirik (56) * sgallagh (45) * zbyszek (38) * bookwar (26) * jforbes (26) * zodbot (18) * ignatenkobrain (9) * bcotton (4) * mboddu (1) * otaylor (0) * contyk (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On Fri, 26 Apr 2019 11:07:54 - (UTC) Petr Pisar wrote: I am a fedora user with no dog in this fight. > Controversial property of modules are private build-time dependencies. > Modularity allows packagers to hide them and to not to support them > (to the extend that they work in my module). However, this > privatisation has costs. It means duplication of work unless two ... Isn't this contrary to the Fedora rules? If I'm understanding this correctly, it means that modules in Fedora can contain dependencies on code that isn't available, so that Fedora (and users) can't build that module from source. And that the module could contain basically anything because no one can examine the contents that built the module. Could someone privately pull in something like the proprietary nvidia binary blob and use it to build their module without anyone knowing? Because I'm not knowledgeable about this, it might be that private dependencies have to be packages built from source code available in the Fedora ecosystem, and so this is not possible. I just want to clarify my understanding. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Who's right? Fedora armv7hl-redhat-linux-gnu vs GNU armv7l-unknown-linux-gnueabihf
On Fri, 2019-04-26 at 16:38 +0100, Richard W.M. Jones wrote:
> On 32-bit ARM Fedora's %{configure} macro forces:
>
> ./configure ... --host=armv7hl-redhat-linux-gnu ...
>
> On the same host, config.guess prints:
>
> armv7l-unknown-linux-gnueabihf
>
> The OCaml configure script tests for:
>
> AS_CASE([$host],
> ...
> [armv7*-*-linux-gnueabihf],
> [arch=arm; model=armv7; system=linux_eabihf],
> ...
> [armv7*-*-linux-gnueabi],
> [arch=arm; model=armv7; system=linux_eabi],
>
> As a result it works if $host contains the GNU string, but fails on
> the forced Fedora host string.
>
> Who's right here? Also can I change what Fedora's %{configure} macro
> sets --host to by modifying only the spec file?
>
Hum it seems something similar with [1]
In resume is a difference between Debian vs Redhat , I believe the
solution is patch test script .
[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1134914#c9
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog:
> http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine. Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190426.n.0 changes
OLD: Fedora-Rawhide-20190425.n.0
NEW: Fedora-Rawhide-20190426.n.0
= SUMMARY =
Added images:9
Dropped images: 3
Added packages: 10
Dropped packages:2
Upgraded packages: 76
Downgraded packages: 0
Size of added packages: 39.22 MiB
Size of dropped packages:3.35 MiB
Size of upgraded packages: 6.21 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 17.49 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20190426.n.0.iso
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20190426.n.0.iso
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20190426.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190426.n.0.s390x.raw.xz
Image: LXQt live i386
Path: Spins/i386/iso/Fedora-LXQt-Live-i386-Rawhide-20190426.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20190426.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190426.n.0.s390x.qcow2
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20190426.n.0.s390x.vmdk
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20190426.n.0.iso
= DROPPED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20190425.n.0-sda.raw.xz
Image: KDE live i386
Path: Spins/i386/iso/Fedora-KDE-Live-i386-Rawhide-20190425.n.0.iso
Image: Python_Classroom raw-xz armhfp
Path:
Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20190425.n.0-sda.raw.xz
= ADDED PACKAGES =
Package: black-hole-solver-0.20.0-1.fc31
Summary: The Black Hole Solitaire Solver Executable
RPMs:black-hole-solver libblack-hole-solver-devel libblack-hole-solver1
Size:277.91 KiB
Package: dnf-plugin-diff-1.0-2.fc31
Summary: Show local changes in RPM packages
RPMs:dnf-plugin-diff
Size:19.65 KiB
Package: flat-remix-icon-theme-0.0.20190413-1.fc31
Summary: Icon theme inspired on material design
RPMs:flat-remix-icon-theme
Size:18.56 MiB
Package: la-capitaine-icon-theme-0.6.1-2.20190418gitbc48265.fc31
Summary: Icon pack designed to integrate with most desktop environments
RPMs:la-capitaine-icon-theme
Size:2.64 MiB
Package: minder-1.2.1-1.fc31
Summary: Mind-mapping application
RPMs:minder
Size:1.46 MiB
Package: notes-up-2.0.0-3.fc31
Summary: Markdown notes editor & manager
RPMs:notes-up
Size:1.29 MiB
Package: perl-Class-AutoClass-1.56-1.fc31
Summary: Define classes and objects for Perl
RPMs:perl-Class-AutoClass
Size:34.29 KiB
Package: perl-Net-BGP-0.16-2.fc31
Summary: Perl module for object-oriented API to the BGP protocol
RPMs:perl-Net-BGP
Size:78.62 KiB
Package: rust-tokei-9.1.1-1.module_f31+4028+7b1d259e
Summary: Utility that allows you to count code, quickly
RPMs:tokei
Size:6.08 MiB
Package: suru-icon-theme-0-3.20180927git2d81020.fc31
Summary: Suru icon and cursor set
RPMs:suru-icon-theme
Size:8.79 MiB
= DROPPED PACKAGES =
Package: california-0.4.0-18.fc30
Summary: Calendar application
RPMs:california
Size:3.32 MiB
Package: perl-AutoClass-1.56-4.fc30
Summary: Automatically define classes and objects for Perl
RPMs:perl-AutoClass
Size:34.77 KiB
= UPGRADED PACKAGES =
Package: R-rgeos-0.4.3-1.fc31
Old package: R-rgeos-0.4.2-1.fc30
Summary: Interface to Geometry Engine - Open Source ('GEOS')
RPMs: R-rgeos
Size: 3.54 MiB
Size change: 14.75 KiB
Changelog:
* Thu Apr 25 2019 Elliott Sales de Andrade -
0.4.3-1
- Update to latest version
Package: airnef-1.1-6.fc31
Old package: airnef-1.1-5.fc30
Summary: Wireless download from your Nikon/Canon Camera
RPMs: airnef
Size: 182.68 KiB
Size change: 84 B
Changelog:
* Thu Apr 25 2019 Pavel Raiskup - 1.1-6
- require python3-tkinter (rhbz#1702714)
Package: bcc-0.9.0-1.fc31
Old package: bcc-0.8.0-4.fc31
Summary: BPF Compiler Collection (BCC)
RPMs: bcc bcc-devel bcc-doc bcc-lua bcc-tools python3-bcc
Size: 48.83 MiB
Size change: 2.78 MiB
Changelog:
* Mon Apr 22 2019 Neal Gompa - 0.8.0-5
- Make the Python 3 bindings package noarch
- Small cleanups to the spec
* Thu Apr 25 2019 Rafael dos Santos - 0.9.0-1
- Rebase to latest upstream version (#1686626)
- Rename libbpf header to libbcc_bpf
Package: berusky-1.7.1-12.fc31
Old package: berusky-1.7.1-11.fc30
Summary: Sokoban clone
RPMs: berusky
Size: 1002.48 KiB
Size change: 24.39 KiB
Changelog:
* Thu Apr 25 2019 Martin Stransky 1.7.1-12
- Fixed missing SDL.h headers in flatpak build.
Package: cpprest-2.10.13-1.fc31
Old package: cpprest-2.10.12-3.fc31
Summary: C++ REST library
RPMs: cpprest cpprest-devel
Who's right? Fedora armv7hl-redhat-linux-gnu vs GNU armv7l-unknown-linux-gnueabihf
On 32-bit ARM Fedora's %{configure} macro forces:
./configure ... --host=armv7hl-redhat-linux-gnu ...
On the same host, config.guess prints:
armv7l-unknown-linux-gnueabihf
The OCaml configure script tests for:
AS_CASE([$host],
...
[armv7*-*-linux-gnueabihf],
[arch=arm; model=armv7; system=linux_eabihf],
...
[armv7*-*-linux-gnueabi],
[arch=arm; model=armv7; system=linux_eabi],
As a result it works if $host contains the GNU string, but fails on
the forced Fedora host string.
Who's right here? Also can I change what Fedora's %{configure} macro
sets --host to by modifying only the spec file?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1703498] New: perl-Test2-Suite-0.000120 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703498 Bug ID: 1703498 Summary: perl-Test2-Suite-0.000120 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test2-Suite Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.000120 Current version/release in rawhide: 0.000119-1.fc31 URL: http://search.cpan.org/dist/Test2-Suite/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/9536/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On Thu, Apr 25, 2019 at 8:25 PM Miro Hrončok wrote: > There was the packager UX initiative draft [2] proposed in December 2018, > however it seems nobody really is eager to go and start doing this. > It seems that this is a bit too much for volunteers and Red Hat paid Fedora > contributors are already folly occupied by their primary responsibilities. > > [2] https://fedoraproject.org/wiki/Objectives/Packager_Experience I was the author of that proposal. I started working on it because I completely agree with the complaints that have been raised in this thread thus far. In fact, I *made* similar complaints back in December and was encouraged to file the objective proposal in question. Unfortunately, I've realized over the last few months that I did not have the time or energy to be the sole person pushing this forward. I'm sorry that I've let it languish. I'd still like to see the objective be realized. Though, perhaps, rather than have the objective proposal suggest creating a SIG or WG to organize packager experience efforts, we need to do this the other way around: we should create a SIG or packager experience and then *that SIG as a group* should prepare and submit an objective proposal describing what they want to work on. Ben Rosser ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On Fri, Apr 26, 2019 at 3:23 PM Nicolas Mailhot wrote: > > Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit : > > Fighting with the "Modularity team", whoever they are > > (a SIG? a mailing list?, a team at RedHat? ... I don't really know > > who they are) > > Just to be clear: this is not about fighting the Modularity team (or > any other team, for that matter). Modularity, Silverblue, RHEL, etc, > all assume something to build upon. And this something may be Fedora as > we know it today, or something else entirely, I don’t care (much). > > Yet there is no public advocate of this something. All the energy is > poured in “value-added” endeavours which delegate hard problems to a > backbone starved of investments and resources. > > This is not healthy or sustainable. I completely agree. While I understand that it's more exciting to work on the "new shiny project" (Modularity), the basis we all want to build upon (traditional RPM packages in the "normal" repos, in this case) cannot be allowed to rot, or we all stand on shaky ground. For example, the Stewardship SIG recently took ownership of around 200 orphaned, now mostly module-only packages - some of which have a dependency tree larger than 2000 (!) binary packages. TL;DR: I don't think pulling the rug out under a significant portion of the fedora package set (and maintainers) is a good idea, until we're sure that there's solid ground under our feet. Fabio > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers
On 26. 04. 19 16:24, Zuzana Svetlikova wrote: > I'll take them. Already mine (announced in the js-jquery orphaning thread) ;) -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
rpmlint whitelisting broken in taskotron?
Hi, I've noticed that my bodhi updates started showing rpmlint errors for my packages again, where they were previously silent because I supply a $SRCNAME.rpmlintrc file in my dist-git repos. It looks like taskotron is broken and/or ignores this file again. Is this a known issue? For example, this build from today shows rpmlint issues that are explicitly whitelisted (using the file locally suppresses the warnings/errors as intended): update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ecaba1eef1 in repo: https://src.fedoraproject.org/rpms/elementary-greeter/blob/f30/f/elementary-greeter.rpmlintrc Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Making Perl site paths ABI-specific
On Thu, Apr 25, 2019 at 3:36 PM Petr Pisar wrote: > > Any opinions? Should we go with this change? Wich format do you like most? > I think this is a great idea, and the first option is most similar to normal Perl lib paths. -Dan ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers
I'll take them. On Tue, Apr 16, 2019 at 10:56 AM Miro Hrončok wrote: > On 15. 04. 19 18:52, Christopher wrote: > > If nobody picks up the ones by my name (nodejs-path-exists, > > nodejs-bluebird, nodejs-grunt-known-options), then I will probably > > have to orphan js-jquery, because it probably needs those for its > > build (I can't think of any other reason my name would be listed next > > to those). > > That is indeed the reason. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Making Perl site paths ABI-specific
On Thu, 25 Apr 2019 16:36:38 +0200 Petr Pisar wrote: > It was a long time ago I wrote to this list. I'm thinking about > changing site paths. > > Now, perl configures site paths to: > > /usr/local/lib64/perl5 > /usr/local/share/perl5 > > so that anyone installing distributions from CPAN in a system-wide > manner will install his modules there. These two paths are listed > before core and vendor path used by Fedora packages in order to allow > users to override Perl modules coming with Fedora. > > This layout has the nice feature that user's code is available across > Fedora upgrades. However, this feature is also bad because perl tends > to change ABI and as a result XS modules stop working and becuse the > site location precedence they can hinder even Fedora's Perl code. > Then inexperienced users report bugs for perl that Perl stopped > working after upgrade Fedora. > > My proposal is make the two paths changing with every new > incompatible Perl release (that happens every year with a new minor > Perl version). Example: > > /usr/local/lib64/perl5/5.30 > /usr/local/share/perl5/5.30 > > As a result when users upgrade to Perl 5.30, their locally installed > modules become unavailable and thus they won't be able to affect the > new system. Also the user immediatelly recongnizes that his locally > installed code "disappeared" instead of receiving some cryptic error > message from XSLoader few days later when some optional XS module > gets loaded. Having seen a few of these bugs, I think this is a good idea. > So if we conclude that this change is good and should be implemented, > the only uncertainity is the issue of aestetic: How exactly should > the paths be named? I can see these posibilities: > > > /usr/local/share/perl5/5.30 > /usr/local/share/perl5/30 > /usr/local/share/perl5.30 > > The first two keep all Perl files under one directory, while the > third one proliferates directories right under /usr/local/share. It > also is backward compatible for people who back up or NFS-mount the > paths. The last two makes the path a little bit shorter. While the > first and last resembles a soname we already give to libperl.so > (/usr/lib64/libperl.so.5.30). The first two have also a very tiny > posibility of a clash with Perl modules namespaced into "5.30::" or > "30::" that could survive from current days (installed > into /usr/local/share/perl5). I like the first option. > > Any opinions? Should we go with this change? Wich format do you like > most? I like the first one too. Paul. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Modular packages and Python 3.8 rebuild
The following modular packages require Python 3.7 on Fedora 30:
$ dnf repoquery --releasever 30 --repo=fedora-modular
--repo=updates{,-testing}-modular --whatrequires 'libpython3.7m.so.1.0()(64bit)'
python3-pygit2-0:0.27.4-1.module_f30+2959+693db98d.x86_64
$ dnf repoquery --releasever 30 --repo=fedora-modular
--repo=updates{,-testing}-modular --whatrequires 'python(abi) = 3.7'
meson-0:0.50.0-1.module_f30+3586+7354b37a.noarch
meson-0:0.50.1-1.module_f30+3966+49c83da1.noarch
python3-aexpect-0:1.5.1-4.module_f30+2883+7f6a800a.noarch
python3-pygit2-0:0.27.4-1.module_f30+2959+693db98d.x86_64
stratis-cli-0:1.0.2-1.module_f30+3525+55cfb91a.x86_64
That's:
python-pygit2-0.27.4-1.module_f30+2959+693db98d.src.rpm
meson-0.50.0-1.module_f30+3586+7354b37a.src.rpm
meson-0.50.1-1.module_f30+3966+49c83da1.src.rpm
python-aexpect-1.5.1-4.module_f30+2883+7f6a800a.src.rpm
python-pygit2-0.27.4-1.module_f30+2959+693db98d.src.rpm
stratis-cli-1.0.2-1.module_f30+3525+55cfb91a.src.rpm
I have no idea how to query rawhide, because i only get nothing provides
module(platform:f31) errors when I try to set releasever to 31 or to query
--repo=rawhide-modular.
I'd like to know what shall I do about Python 3.8 rebuilds of those.
How do I do it? Where do I do it?
How do I test it against my copr before we proceed in a rawhide side tag?
Should I just fetch the srpms and use them as they are? Will they build? Do I
have all their build dependencies? How can I tell without trying?
How do I cc their maintainers?
Does -maintain...@fedoraproject.org include the maintainers of the
modular build?
So many questions. Can somebody please help me handle those?
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
Le jeudi 25 avril 2019 à 20:00 -0400, Christopher a écrit : > Fighting with the "Modularity team", whoever they are > (a SIG? a mailing list?, a team at RedHat? ... I don't really know > who they are) Just to be clear: this is not about fighting the Modularity team (or any other team, for that matter). Modularity, Silverblue, RHEL, etc, all assume something to build upon. And this something may be Fedora as we know it today, or something else entirely, I don’t care (much). Yet there is no public advocate of this something. All the energy is poured in “value-added” endeavours which delegate hard problems to a backbone starved of investments and resources. This is not healthy or sustainable. -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: update-desktop-database in %post snippet
Petr Mensik wrote: > Is it still valid request to add update-desktop-database into %post, > like mentioned by fedora-review tool [1]? Almost at the end of the > comment. I were not able to find any information about it in Package > Guidelines. Here's a link to relevant guideline, https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/ (spoiler alert: no, update-desktop-database is no longer needed) -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Retire Python 2
On Fri, Apr 26, 2019 at 8:09 AM Nico Kadel-Garcia wrote: > > On Fri, Apr 26, 2019 at 5:17 AM Miro Hrončok wrote: > > > > On 26. 04. 19 3:08, Nico Kadel-Garcia wrote: > > > On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok wrote: > > >> > > >> On 25. 04. 19 20:35, Stephen John Smoogen wrote: > > >>> > How much is going to be needed for "mock" to still work for > > >>> older > > >>> > operating systems? > > >>> > > >>> I'm confused. How is the change relevant for mock? I think I'm > > >>> missing some > > >>> pieces of the thought process here, could you please elaborate on > > >>> that? > > >>> > > >>> > > >>> In the past, changes where old versions of python were no longer > > >>> supported in > > >>> Fedora, then newer versions of mock/etc became dead in older OS's like > > >>> RHEL-5's > > >>> python24 and RHEL-6's python26. This would make compiling packages for > > >>> certain > > >>> versions of the OS impossible because the parent operating system > > >>> didn't have a > > >>> version of python it could use and you couldn't use newer source code > > >>> on the > > >>> older os. > > >>> > > >>> The question is moot because you are the wrong person to ask. The > > >>> person to ask > > >>> is the owner of mock and I expect the answer will be... I don't have > > >>> time to > > >>> support N versions of python but you have the source code.. so do it > > >>> yourself. > > >>> [Probably nicer than that.. but the general effect.] > > >> > > >> mock in EPEL 6 is already "dead" in that matter: > > >> > > >> https://bugzilla.redhat.com/show_bug.cgi?id=1694159 > > >> > > >> mock in EPEL 7 can run on Python 3.6: > > >> > > >> https://src.fedoraproject.org/rpms/mock/pull-request/6 > > > > > > Which could make sense, but makes mock more awkward to install. > > > > How is that more awkward? The installation would still be be `yum install > > epel-release && yum install mock`. > > It brings in a distinct scripting language that is not part of the > commercially supported base OS and makes the OS image for the server > with mick installed notably larger. It's not *outrageous*, but it > branches the tools for mock further from the base python on older, > RHEL 7 systems. It adds support and places even more commoercial grade > support on the EPEL repository.packages. Not for long. RHEL 7.7 is going to include Python 3 in the base: https://bugzilla.redhat.com/show_bug.cgi?id=1639030 And even if it wasn't, mock only exists in EPEL anyway, so we can consider EPEL dependencies for mock itself. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Retire Python 2
On Fri, Apr 26, 2019 at 5:17 AM Miro Hrončok wrote: > > On 26. 04. 19 3:08, Nico Kadel-Garcia wrote: > > On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok wrote: > >> > >> On 25. 04. 19 20:35, Stephen John Smoogen wrote: > >>> > How much is going to be needed for "mock" to still work for older > >>> > operating systems? > >>> > >>> I'm confused. How is the change relevant for mock? I think I'm > >>> missing some > >>> pieces of the thought process here, could you please elaborate on > >>> that? > >>> > >>> > >>> In the past, changes where old versions of python were no longer > >>> supported in > >>> Fedora, then newer versions of mock/etc became dead in older OS's like > >>> RHEL-5's > >>> python24 and RHEL-6's python26. This would make compiling packages for > >>> certain > >>> versions of the OS impossible because the parent operating system didn't > >>> have a > >>> version of python it could use and you couldn't use newer source code on > >>> the > >>> older os. > >>> > >>> The question is moot because you are the wrong person to ask. The person > >>> to ask > >>> is the owner of mock and I expect the answer will be... I don't have time > >>> to > >>> support N versions of python but you have the source code.. so do it > >>> yourself. > >>> [Probably nicer than that.. but the general effect.] > >> > >> mock in EPEL 6 is already "dead" in that matter: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1694159 > >> > >> mock in EPEL 7 can run on Python 3.6: > >> > >> https://src.fedoraproject.org/rpms/mock/pull-request/6 > > > > Which could make sense, but makes mock more awkward to install. > > How is that more awkward? The installation would still be be `yum install > epel-release && yum install mock`. It brings in a distinct scripting language that is not part of the commercially supported base OS and makes the OS image for the server with mick installed notably larger. It's not *outrageous*, but it branches the tools for mock further from the base python on older, RHEL 7 systems. It adds support and places even more commoercial grade support on the EPEL repository.packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1703411] perl-App-cpm-0.980 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703411 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpm-0.980-1.fc31 Resolution|--- |RAWHIDE Last Closed||2019-04-26 11:33:43 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703294] perl-DBD-Pg-3.8.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703294 --- Comment #1 from Fedora Update System --- perl-DBD-Pg-3.8.0-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-314a5d5185 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
FYI: Fedora 31 will drop ocaml-emacs subpackage
Upstream moved the ocaml-emacs subpackage into a separate repository, out of the main compiler repository: https://github.com/ocaml/ocaml/commit/20425ec4bbc3b7a22b1494970f5ed8a0aed0041d As a result I will drop the ocaml-emacs subpackage when we move to OCaml 4.08.0 in Fedora 31. We already package emacs-tuareg which is a better emacs mode for OCaml editing, and really everyone should use that instead. However it's likely not compatible at the elisp level so it's not a straight replacement package. If someone wants to turn the caml-mode repository into a Fedora package then let me know and I can help, but I'm not in any rush to do it myself because I use tuareg mode. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1703294] perl-DBD-Pg-3.8.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703294 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-DBD-Pg-3.8.0-1.fc31 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On 2019-04-26, Miro Hrončok wrote: > On 26. 04. 19 10:55, Vít Ondruch wrote: >> How does modularity make it easier though? >>> >>> It seems to me that it does the exact opposite - instead of having >>> one version of each package to maintain I now have multiple versions >>> to worry about! I mean obviously I could convert to a module and >>> only maintain one version but what would be the point? >> >> Converting to module does not mean maintaining one version. It means >> that you have to maintain the one version on multiple versions of >> Fedora, where previously this was not needed. >> >> E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified >> somehow, then the modification has to be compatible with older Fedoras, >> whereas previously you would do that change just for Rawhide. >> >> TBH, keeping modules alive is much harder then it was without modules. >> Not even mentioning the possibility of having multiple versions ... > > And yet somehow, somebody considers that easier. > I still try to understand that and I always fail. > Modularity was designed to have a module life cycle independent from the underlying distribution. I.e. having one stream built from one sources for multiple Fedoras. This is a benefit for users. (If we assume that users care what version of software they use. We could maybe consider users as developers in this matter.) Having the same sources on multiple Fedoras of course implies a packager has to maintain compatibility across multiple Fedoras. In the end it's exactly what an upstream struggles for. If you are an upstream then you want to enable your users to build the same code for multiple distributions. It makes packagers to produce more upstreamable patches. Is it more labour for packagers? Yes, it is. But it frees the packager from worrying Did I apply the fix for all supported Fedoras? Do I have to resolve merge conflicts when backporting patches? I believe this is what Mikołaj found attractive and why decided for modules. This is especially true for closed ecosystems like Java packages that have almost no dependencies on non-Java stuff. In this perspective modularity can be beneficial for packagers too. Controversial property of modules are private build-time dependencies. Modularity allows packagers to hide them and to not to support them (to the extend that they work in my module). However, this privatisation has costs. It means duplication of work unless two packager realize they can refer to the same package from their modules. But the common package is whose responsibility now? And looking back at users, poor users won't get that package for free. Yes, I agree that that this aspect of modularity hinders an integration role of packaging. Integrating thousounds of pieces of software, all of them as first-class citizens and offering them to users makes distributions very attractive for developers or anyone who wants to fork or spin of flavour or extend the distribution. One can dispute that now nobody, especially developers, needs distributions with a wide selection of software because everybody uses containers and installs software from upstream bypassing distributor's packages. Well, that may be true for closed ecosystems (like Java maven artifacts, Ruby gems etc.), however, look at any CI configuration files (those foo.yml poluting roots for git repositories). They start with "dnf install openssl-devel"-like incantation. Distributions are not dead. They are still needed. And will be needed untill those fancy upstream ecosystems (CPAN, PyPI etc.) gets to know how integrate with foreign pieces (e.g. with C libraries). In my humble opinion modularity would be more beneficial if every RPM package gets it's own that-package-contained module by default. This plethora of modules would of course demand appropriate tooling. Tooling as we have around RPM (repositories, composes, package managers). Or vice versa instead of reinventig weel enable Koji to expand-build one SRPM for multiple Fedoras. And enable composes to contain multiple version of packages. And having the build-only packages/modules in a separate "unsupported" repository or just flagged in metadata as unsupported. The issue with modules in Fedora is that they look like aliens (metadata and tooling), behave like aliens (dnf system-upgrade) and are born like aliens (MBS above Koji). -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1703411] New: perl-App-cpm-0.980 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1703411 Bug ID: 1703411 Summary: perl-App-cpm-0.980 is available Product: Fedora Version: rawhide Status: NEW Component: perl-App-cpm Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.980 Current version/release in rawhide: 0.979-1.fc31 URL: http://search.cpan.org/dist/App-cpm/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/8399/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: update-desktop-database in %post snippet
On Friday, 26 April 2019 11:30:22 CEST Petr Mensik wrote: > Hi! > > Is it still valid request to add update-desktop-database into %post, > like mentioned by fedora-review tool [1]? Almost at the end of the > comment. I were not able to find any information about it in Package > Guidelines. Should that hint be removed from fedora-review or should be > documentation updated? > > Are my eyes too tired to find correct place? > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1658153#c85 > > Regards, > Petr > Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02 Update your fedora-review to 7.2. It should be in stable now, if not use updates-testing. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: update-desktop-database in %post snippet
No. It must be removed from %post. пт, 26 апр. 2019 г. в 12:30, Petr Mensik : > > Hi! > > Is it still valid request to add update-desktop-database into %post, > like mentioned by fedora-review tool [1]? Almost at the end of the > comment. I were not able to find any information about it in Package > Guidelines. Should that hint be removed from fedora-review or should be > documentation updated? > > Are my eyes too tired to find correct place? > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1658153#c85 > > Regards, > Petr > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com PGP: 65C6C973 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
update-desktop-database in %post snippet
Hi! Is it still valid request to add update-desktop-database into %post, like mentioned by fedora-review tool [1]? Almost at the end of the comment. I were not able to find any information about it in Package Guidelines. Should that hint be removed from fedora-review or should be documentation updated? Are my eyes too tired to find correct place? 1. https://bugzilla.redhat.com/show_bug.cgi?id=1658153#c85 Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Plan to retire ffgtk (Fritzbox manager)
hi all, I am planning to retire ffgtk as I no longer use it and it does no longer work with "recent" Fritzbox modem firmware from AVM. Any objections? I now Roger exists s replacement, but I have no interest in packiging it. best regards, Louis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
Dne 26. 04. 19 v 11:15 Miro Hrončok napsal(a): > On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it > easier though? >>> >>> It seems to me that it does the exact opposite - instead of having >>> one version of each package to maintain I now have multiple versions >>> to worry about! I mean obviously I could convert to a module and >>> only maintain one version but what would be the point? >> >> >> Converting to module does not mean maintaining one version. It means >> that you have to maintain the one version on multiple versions of >> Fedora, where previously this was not needed. >> >> E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified >> somehow, then the modification has to be compatible with older Fedoras, >> whereas previously you would do that change just for Rawhide. >> >> TBH, keeping modules alive is much harder then it was without modules. >> Not even mentioning the possibility of having multiple versions ... > > > And yet somehow, somebody considers that easier. Of course. If Java in RHEL is in module, then Fedora maintainer probably does not have desire to maintain it in Fedora differently. Also, just FTR, there used to be 3 people working on Java packages in Red Hat and now it is not more than 1,5 if I am not mistaken. That must be visible somewhere. TBH, the disconnect between RHEL and Fedora is IMHO much bigger then it used to be and this is also plays its role. Vít > I still try to understand that and I always fail. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Retire Python 2
On 26. 04. 19 3:08, Nico Kadel-Garcia wrote: On Thu, Apr 25, 2019 at 3:20 PM Miro Hrončok wrote: On 25. 04. 19 20:35, Stephen John Smoogen wrote: > How much is going to be needed for "mock" to still work for older > operating systems? I'm confused. How is the change relevant for mock? I think I'm missing some pieces of the thought process here, could you please elaborate on that? In the past, changes where old versions of python were no longer supported in Fedora, then newer versions of mock/etc became dead in older OS's like RHEL-5's python24 and RHEL-6's python26. This would make compiling packages for certain versions of the OS impossible because the parent operating system didn't have a version of python it could use and you couldn't use newer source code on the older os. The question is moot because you are the wrong person to ask. The person to ask is the owner of mock and I expect the answer will be... I don't have time to support N versions of python but you have the source code.. so do it yourself. [Probably nicer than that.. but the general effect.] mock in EPEL 6 is already "dead" in that matter: https://bugzilla.redhat.com/show_bug.cgi?id=1694159 mock in EPEL 7 can run on Python 3.6: https://src.fedoraproject.org/rpms/mock/pull-request/6 Which could make sense, but makes mock more awkward to install. How is that more awkward? The installation would still be be `yum install epel-release && yum install mock`. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
On 26. 04. 19 10:55, Vít Ondruch wrote:>> How does modularity make it easier though? It seems to me that it does the exact opposite - instead of having one version of each package to maintain I now have multiple versions to worry about! I mean obviously I could convert to a module and only maintain one version but what would be the point? Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed. E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide. TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ... And yet somehow, somebody considers that easier. I still try to understand that and I always fail. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning js-jquery
Dne 25. 04. 19 v 20:37 Tom Hughes napsal(a): > On 25/04/2019 19:29, Stephen John Smoogen wrote: >> >> >> On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot >> mailto:nicolas.mail...@laposte.net>> >> wrote: >> >> Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit : >> > >> > FWIW, things should *not* be getting harder. Some folks just >> jumped >> > the gun and made changes they weren't supposed to (yet) and >> now the >> > Modularity team has a lot of fires to put out and very few >> resources >> > with which to do it. >> >> That’s not overly nice to the people that “jumped the gun”. They’re >> using modularity exactly as it was designed. Tragedy of the >> commons is >> an entirely predictible outcome, of something without a built-in >> sharing strategy. >> >> >> That is my view of the matter also. There are a lot of packagers with >> way too many packages... and we have too many dependencies... so any >> tool which allows for that to be 'easier' is going to start an >> avalanche of packages getting moved out of the 'ursine commons'. As >> someone said yesterday to me, it is like showing that you can make a >> better living as a farmer using industrial farming techniques and >> then complaining that the small old-fashioned farmer no longer >> exists... or that a lot of people quit being farmers because those >> who used the industrial methods took over the market. > > How does modularity make it easier though? > > It seems to me that it does the exact opposite - instead of having > one version of each package to maintain I now have multiple versions > to worry about! I mean obviously I could convert to a module and > only maintain one version but what would be the point? Converting to module does not mean maintaining one version. It means that you have to maintain the one version on multiple versions of Fedora, where previously this was not needed. E.g. if there is new OpenSSL in Rawhide and Ruby needs to be modified somehow, then the modification has to be compatible with older Fedoras, whereas previously you would do that change just for Rawhide. TBH, keeping modules alive is much harder then it was without modules. Not even mentioning the possibility of having multiple versions ... Vít > There would > still be extra metadata relating to the module to maintain anyway. > > Tom > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 --- Comment #4 from Fedora Update System --- perl-Sereal-Encoder-4.007-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-cea20b75e9 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 --- Comment #3 from Fedora Update System --- perl-Sereal-Encoder-4.007-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8fa1d1a00c -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- perl-Sereal-Encoder-4.007-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd6c7244a7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1703269] serious typo in Summary
https://bugzilla.redhat.com/show_bug.cgi?id=1703269 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar --- That's indeed a sereous problem. I will fix it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false
On Thu, Apr 25, 2019 at 11:50 PM Jan Pokorný wrote: > > On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote: > > Also please note that fedora-cisco-openh264.repo ships with > > "skip_if_unavailable=true". > > off-topic: which in fact doesn't matter much, since you'll, sooner > or later and whether you want or not, receive non-free (in a sense) > binaries over the native Firefox channel (guidelines yada yada yada) > anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1648024 Not entirely off topic, the change description states that Fedora repositories ship with skip_if_unavailable=false but fedora-cisco-openh264.repo doesn't. Thanks for the bug report, that explains what I thought was pebcak when this was introduced and all I could do was disable the plugin. But I would argue that bug is off topic ;-) I just hope the DNF team would implement a retry on failed downloads to not consider a repository unavailable right off the bat especially when we have a list of mirrors to pick from. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 RC 1.2 compose check report
No missing expected images. Failed openQA tests: 1/146 (x86_64), 1/2 (arm) ID: 391523 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/391523 ID: 391526 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/391526 Soft failed openQA tests: 3/24 (i386), 3/146 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 391486 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/391486 ID: 391487 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/391487 ID: 391496 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/391496 ID: 391505 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/391505 ID: 391506 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/391506 ID: 391510 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/391510 Passed openQA tests: 142/146 (x86_64), 21/24 (i386) Skipped non-gating openQA tests: 1 of 172 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 30 Candidate RC-1.2 Available Now!
According to the schedule [1], Fedora 30 Candidate RC-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/30 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_30_RC_1.2_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-30/f-30-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_30_RC_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
