Re: Onboarding package
Stephen Snow kirjoitti 5.10.2021 klo 15.39: we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. However, discussing this back and forth, we figured that it might also where new coming package maintainer could gradually gain experience with the packaging workflows. So the simplest tasks could be: 1) Add changelog entry into onboarding package and open PR with the change. This would not require too many privileges. Alternatively this current Fedora contributors might be interested to send such PR ;) I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. Well, in the Quick Docs, we already have Creating RPM packages [1]. It has subpage "Publishing your software on Copr", which somehow covers the publishing aspect. But honestly, when I was starting out, I spent some time with those instructions, but could not understand them or complete the tutorials. So one thing would be to revisit these instructions and make the better — there is a task about moving them over to Package Maintainer Docs [2], it was in progress at some point, but apparently stalled now. After that, improvement could happen. About every packager publishing their own test package, in Copr that can be done for sure. If it is deemed too far from the official Fedora repositories, the perhaps it could be done in staging. I have never really used it, I cannot say if that is a good idea or not. A similar but different idea I have is to create a "Fedora Packaging Guidelines Web Course" that you can complete by yourself. It could be implemented as a Git repository. For each entry in the the Review Guidelines [3], there would be a directory with a specfile and a srpm. For simplicity, we could first implement cases which fedora-review can check automatically. The student's assignment would be to run fedora-review on the specfile, find the error it gives, refer to the Packaging Guidelines to figure out how to fix it, modify the specfile as needed and run fedora-review again to check their answer. The assignment is completed when fedora-review does not complain any more. Later, the course could be expanded also to cases where there is no automated check available, either by involving a mentor, or simply by adding a SOLUTION file. Awarding a badge for completing this course would be a good idea, if a technical solution can be found. I see this course as complementary to Vít's original proposal about the onboarding package. The orboarding package tasks are about learning the build system, certainly a required skill for packages. The course is about learning the Guidelines. Currently the recommended method to do that is to submit inofficial reviews to live Review Requests. That has the advantage of exposing the applicant to real packages with real problems, but 1) has no guarantee of producing an effective learning path, the package that is picked may well be a very tricky case and thus unsuitable for starting out and 2) is psychologically unsafe, because a total newcomer must participate in discussion of two experts who are actually trying to get a package into Fedora, not educating the packagers. [1]: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/ [2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. This could be extended in the future. E.g. next step could be: 3) Submit module update. Apart from gaining experience, this could also help with the common question "where should I start". And of course our sponsoring guidelines could be refreshed suggesting/requesting to take these steps at some point. Thoughts? Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Are you aware of the page "Package maintainer responsibilities" [4]? Is there some aspects of the responsibilities that are not covered there? [4]: https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
Hi folks, @Matthew Miller Are you still trying to save Fedora from packaging the ocean? :) On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini wrote: > On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller > wrote: > > > > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > > > I'm not sure what's the best solution, but I guess the number one > > > reason to have packages within the Fedora distribution is for a matter > > > of trust, if this is the case I would argue that a curated list of > > > maven packages served via a Fedora managed repository would be a > > > better investment. > > > > I'd love to see someone interested in this pursue this idea! I know we > > talked about it as long ago as... Flock Prague... and probably before. > > This approach will buy you *literally nothing* compared to how things > already work, assuming you don't advocate just redistributing binary > artifacts / JARs from Maven Central. > > Given that assumption, JARs would still need to be built 1) from > source, in a 2) trusted environment, 3) against trusted dependencies, > as I don't think any other approach should be acceptable for content > distributed by the Fedora Project. > > But then you're back to *exactly how Fedora packages for Java projects > already work* - only with the added complication that distributing > those build artifacts as plain JARs instead of RPMs now makes them > impossible to consume as dependencies from other RPM builds. > I think it would actually make a huge difference. Unlike RPM repositories, Maven repositories can easily hold multiple versions of libraries. Once a JAR is built, the resulting bytecode will work with current and future JVMs. There is no need to mass-rebuild JARs every 6 months. And there is certainly no need to try to run every single Java application with a single "system-wide" version of a library. Fedora could ship just Java applications that would bundle JARs (whatever version they need) from the Fedora Maven repository. I don't see this as a problem, as long as it would be possible to track what JARs are bundled in what application. Fedora maintainers could then focus on maintaining applications, and not maintaining a ton of individual libraries that nobody really cares about that much. Thanks, Michal > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2011114] New: perl-Encode-3.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=204 Bug ID: 204 Summary: perl-Encode-3.13 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Encode Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.13 Current version/release in rawhide: 3.12-480.fc35 URL: http://search.cpan.org/dist/Encode/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2849/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=204 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a50497600b chromium-94.0.4606.61-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d146456623 dr_libs-0-0.7.20211002gitf13cbcf.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing jaxb-api-2.3.3-5.el8 mxparser-1.2.1-2.el8 mxparser-1.2.2-1.el8 python-fiona-1.8.20-3.el8 xstream-1.4.18-3.el8 Details about builds: jaxb-api-2.3.3-5.el8 (FEDORA-EPEL-2021-b1ab26dec0) Jakarta XML Binding API Update Information: Modified for RHEL. ChangeLog: References: [ 1 ] Bug #2010316 - Provide jaxb-api for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=2010316 mxparser-1.2.1-2.el8 (FEDORA-EPEL-2021-ff6316436e) Parser of xpp3_min 1.1.7 with merged changes of the Plexus fork Update Information: Adapted for RHEL builds. ChangeLog: mxparser-1.2.2-1.el8 (FEDORA-EPEL-2021-31014fd52c) Parser of xpp3_min 1.1.7 with merged changes of the Plexus fork Update Information: Update to version 1.2.2 Adapted for RHEL builds. ChangeLog: python-fiona-1.8.20-3.el8 (FEDORA-EPEL-2021-9d84d78e92) Fiona reads and writes spatial data files Update Information: Introduce python-fiona package for EPEL 8. ChangeLog: References: [ 1 ] Bug #2009910 - Please build python-fiona for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=2009910 xstream-1.4.18-3.el8 (FEDORA-EPEL-2021-b2cd60438b) Java XML serialization library Update Information: Added build on RHEL. ChangeLog: References: [ 1 ] Bug #1990050 - Provide xstream for EPEL-8 https://bugzilla.redhat.com/show_bug.cgi?id=1990050 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Mon, Oct 4, 2021, at 3:08 PM, Fabio Valentini wrote: > But then you're back to *exactly how Fedora packages for Java projects > already work* - only with the added complication that distributing > those build artifacts as plain JARs instead of RPMs now makes them > impossible to consume as dependencies from other RPM builds. One needs to be a bit careful using the term "impossible" in software. Some things, such as the halting problem have actually been proven impossible. But this is not impossible =) I use non-RPM things as part of building RPMs all the time. So do many other systems. I think you instead mean e.g.: "would require our use of RPM to not be fully self-hosting" or "would require some tooling to e.g. automatically generate RPMs from external binaries" etc. That's more of a policy question, far from impossible. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS Community Video Meeting 2021-10-06
Hi All, Tomorrow we will be holding a video meeting for the Fedora CoreOS community. Harshal Patil will be joining us to give a brief overview of how Fedora CoreOS is used for the e2e node tests in upstream Kubernetes. https://github.com/coreos/fedora-coreos-tracker/issues/984 We'll also be discussing any meeting tickets and possibly revisit our list of high level issues. Time: 16:30 UTC (same as normal) on Wednesday October 6th Location: https://meet.google.com/cgh-oxhd-axg (will be recorded) Agenda/Notes: https://hackmd.io/vMWlKGH5TAOsLKYiqce61Q Dusty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20211005.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 1/15 (aarch64) New failures (same test not failed in Fedora-IoT-35-20211004.0): ID: 1015053 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1015053 ID: 1015067 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1015067 Old failures (same test failed in Fedora-IoT-35-20211004.0): ID: 1015074 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1015074 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20211004.0): ID: 1015059 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1015059 Passed openQA tests: 13/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.11 to 0.27 Previous test data: https://openqa.fedoraproject.org/tests/1013345#downloads Current test data: https://openqa.fedoraproject.org/tests/1015063#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.35 to 0.69 Previous test data: https://openqa.fedoraproject.org/tests/1013350#downloads Current test data: https://openqa.fedoraproject.org/tests/1015068#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
> Am 04.10.2021 um 21:08 schrieb Fabio Valentini : > > > But then you're back to *exactly how Fedora packages for Java projects > already work* - only with the added complication that distributing > those build artifacts as plain JARs instead of RPMs now makes them > impossible to consume as dependencies from other RPM builds. I think, the key is "via a Fedora managed repository“, something like a fedora.maven.central. That could make the process easier. Somewhere I had read on "federated repository“ as a specific narrow defined cooperation with distributions or projects with similar principles as Fedora. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OCaml 4.13.1 in Rawhide
https://bodhi.fedoraproject.org/updates/FEDORA-2021-37d56e6b48 Just to let everyone know that OCaml 4.13.1 has been pushed to Fedora Rawhide. There should be no major changes or surprises in this release since it's small incremental change[1] towards OCaml 5. But if you find problems let me know. Rich. [1] https://ocaml.org/releases/4.13.0.html -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
New Browser with Pics
Formal greetings everyone!! :)
My name is Gregory Cohen.
I am looking for developers to work on this new project with me.
I have recently joined certain mailing lists, and I am looking to get the
word out. There is no readme file yet, but I explain everything here, so
don't get mad :)
Feel free to ask me any questions about anything anytime.
My email is gregorycoh...@gmail.com
Some pictures
https://imgur.com/4vRpN9m.png
https://imgur.com/qKNkHxR.png
https://imgur.com/vBy9XnW.png
https://imgur.com/0zv6oSc.png
https://imgur.com/WRVB9X1.png
With Compiz
https://imgur.com/sTzNUm9.png
https://imgur.com/T9BeS0o.png
Program is downloadable at ethicify.online/improve_the_world/tools/FOR_SHOW
(FOR_SHOW folder includes scripts and binaries (non-malicious), everything
can be recompiled)
Emerald-browser (a radical new web browser, working prototype exists, BSD
licensed (I could change this to GPL))
Goals
Not bothersome (person shouldn't be bothered by anything)
Full control
To be fully written in C += 2
* Uses the same engine as Chrome, with QWebEngine
Ubuntu and fedora have packages
emerald-browser [number of terminals, default 1]
C += 2 compiler is called "g+". It's a wrapper for g++
Usage
g+ foo.cpp -O3 -Wall -Wextra -o foo
Example C += 2 program
---
main
puts("Hello world")
--
(No need for #includes)
g+ is written in Ruby. It could be ported to Crystal
TODO
1. Make g+ work better
It doesn't support classes, structs or namespaces currently
You can always #include C++ or C files though
C += 2 is, and always will be a PREPROCESSOR FOR MODERN C++. IT CAN DO
ANYTHING C++ CAN DO AND MORE.
Some things I want to implement
These should be a single unary option buton, like what GNOME 40 or Chrome
has.
In that, there should be many options. Maybe even things like Update System
There should be a close button for panes.
The source code should be tidied up, but please don't clutter it with too
much OOP.
Currently, everything gets googled. There could be a cache of some kind.
Everything you would want to do on your computer, should be doable in this
program. Currently, it makes a full-screen widget.
If there could be a Compiz cube for tabs, that would be really interesting.
There was a program that converted Chrome tabs to a filesystem extension.
Maybe something like this could be added.
Port to Mac.
Port to Windows??? No Terminal then
Port to FreeBSD
Would need to work for certain in X and Wayland
open should be improved
To open tabs, do
open [query1] [query2?]... (number of Google results per query to show in
panes)
Example
open 'ruby talk' 'ruby docs' 3
That would open 3 google results for ruby talk, and 3 google results for
ruby docs
Googler is used to search google. Googler is automatically installed.
Googler is written in python
* This browser should be as fast or faster than Chrome.
* Downloads don't currently work
* Fullscreen doesn't currently work
* Opening pages in new tabs doesn't currently work
* You currently can't close tabs, only open them
* The simplest way to close the browser currently is killall emerald-browser
* Add signal and slot to close program when window closes. This doesn't
currently happen.
Back and forward buttons should be added, somewhere.
Currently, you can right click, and do navigation
A way to type in addresses manually should be added.
Currently, you can do echo 'open [full url]' > /tmp/emerald-browser-fifo
Doing echo open /home/' > /tmp/emerald-browser-fifo should work
* Multiple instances needs to work
* Want installation to be super simple. Download a binary
* Let's get a fully functional browser, THEN care about packaging
If there could be a flip 3d for tabs, that would be cool
There's an interesting cover flow widget for Qt. Maybe that could be useful.
Are you interested in collaborating?
If you can help in any way, please send me a message :)
Sincerely,
Gregory David Evan Cohen
gregorycoh...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Tue, Oct 5, 2021 at 11:27 AM Matthew Miller wrote: > > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > > >Is this really necessary? > > > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. So you're going to ensure that the people using this package to experiment/learn can *only* submit via PR? I like that. I find it to be better, but not sufficient depending on how that works. > Overall, we put a lot of trust in maintainers. I don't see this _particular_ > route as a likely one for violating that trust. I think I'd like to see a more sketched out flow. This isn't for maintainers, it's for people trying to learn to be maintainers. They're still building that trust via this whole thing, right? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
On Tue, Oct 5, 2021 at 7:00 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2021-10-06 from 11:00:00 to 12:00:00 > America/Indiana/Indianapolis >At fedora-meetin...@libera.chat > > More information available at: > https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/ > We will evaluate the following bug: * gnome-shell: gnome-shell killed by SIGSEGV — https://bugzilla.redhat.com/show_bug.cgi?id=1960938 There are no open accepted prioritized bugs. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-35-20211005.n.0 compose check report
No missing expected images. Failed openQA tests: 9/204 (x86_64), 13/141 (aarch64) New failures (same test not failed in Fedora-35-20211004.n.0): ID: 1014349 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/1014349 ID: 1014390 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1014390 ID: 1014400 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1014400 ID: 1014402 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1014402 ID: 1014437 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1014437 ID: 1014492 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1014492 ID: 1014500 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1014500 ID: 1014514 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/1014514 ID: 1014519 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/1014519 ID: 1014523 Test: x86_64 universal install_blivet_with_swap URL: https://openqa.fedoraproject.org/tests/1014523 ID: 1014564 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/1014564 ID: 1014595 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/1014595 ID: 1014606 Test: aarch64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1014606 ID: 1014614 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/1014614 ID: 1014628 Test: aarch64 universal install_kickstart_nfs@uefi URL: https://openqa.fedoraproject.org/tests/1014628 Old failures (same test failed in Fedora-35-20211004.n.0): ID: 1014387 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1014387 ID: 1014433 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1014433 ID: 1014441 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1014441 ID: 1014442 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1014442 ID: 1014476 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1014476 ID: 1014499 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1014499 ID: 1014605 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1014605 Soft failed openQA tests: 2/204 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-35-20211004.n.0): ID: 1014361 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1014361 ID: 1014415 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1014415 ID: 1014488 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1014488 ID: 1014506 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1014506 Passed openQA tests: 181/204 (x86_64), 126/141 (aarch64) New passes (same test not passed in Fedora-35-20211004.n.0): ID: 1014542 Test: x86_64 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/1014542 ID: 1014559 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/1014559 ID: 1014622 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1014622 Skipped non-gating openQA tests: 12 of 345 Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 5 MiB to 6 MiB Previous test data: https://openqa.fedoraproject.org/tests/1012581#downloads Current test data: https://openqa.fedoraproject.org/tests/1014356#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.93 to 1.08 Previous test data: https://openqa.fedoraproject.org/tests/1012607#downloads Current test data: https://openqa.fedoraproject.org/tests/1014382#downloads Installed system changes in test aarch64 Server-boot-iso install_default@uefi: System load changed from 0.35 to 0.20 Previous test data: https://openqa.fedoraproject.org/tests/1012656#downloads Current test data: https://openqa.fedoraproject.org/tests/1014431#downloads Installed system changes in test aarch64 Server-dvd-iso install_default_upload@uefi: System load changed from 0.33 to
Re: Onboarding package
On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote: > > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > > >Is this really necessary? > > > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. > > Overall, we put a lot of trust in maintainers. I don't see this _particular_ > route as a likely one for violating that trust. > I think part of the problem is that I don't think the proposal has enough flesh on its bones for people not to see it causing all kinds of problems somewhere. Or vice versa seeing not enough to see it being worthwhile for a beginner. [For many a developer, PR's aren't that interesting to most developers and not what they think about when looking at packaging. Running fedpkg and making a spec file work on my system and through the complicated koji+bodhi+mbs+.. stack is real packaging.] So we need a real proposal with an end to end idea of what is being done, what is to be learned, and how it is to be 'watched' by real developers to make sure people are learning things. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-10-06 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://calendar.fedoraproject.org//meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 4, 2021 at 10:13 PM Neal Gompa wrote: > > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi wrote: > > > > On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote: > > > Hi all! I just got back from Open Source Summit, several of the talks I > > > found interesting were on RISC-V -- a high-level one about the > > > organizational structure, and Drew Fustini's more technical talk. > > > > > > In that, he noted that there's a Fedora build *, but it isn't an official > > > Fedora arch. As I understand it, the major infrastructure blocker is > > > simply > > > that there isn't server-class hardware (let alone hardware that will build > > > fast enough that it isn't a frustrating bottleneck). > > > > We have avoided using emulation in the past because we would be chasing > > bugs in our emulation that aren't in real hardware and vice versa. > > How good is the emulation support? Do we know/have people who can fix > > things in it when we hit them? Tools folks: is emulation an option here? > > Or do we still forbid it? > > > > > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances > > > as builders, could we build fast enough under QEMU emulation to work? We > > > have a nice early advantage, but if we don't keep moving, we'll lose that. > > > > > > But beyond that: What other things might be limits? Are there key bits of > > > the distro which don't build yet? Is there a big enough risc-v team to > > > respond to arch-specific build failures? And, do we have enough people to > > > do > > > QA around release time? > > > > Well, one big thing is that it's been a while since we had any secondary > > arches and it's unclear how they would work today. In the distant past > > secondary arches had their own koji and builders and composes and > > releases and used koji-shadow to try and match up with primary koji. > > This was basically more than a full time job for someone and I am sure > > koji-shadow has atrophied in recent years, but perhaps at least some > > subset could be made to work again. > > > > On the other hand we could just add it into primary koji, but then it > > really really has to keep up or it's going to block everything else. > > > > So, probibly a 'secondary' koji and builders to start with to bootstrap > > and to gather info on how hard it is to keep up and good emulation is > > would be worthwhile, but it's gonna need some dedicated work. > > > > Perhaps we could get a up to date status report from folks working on > > this, answering such questions as: > > > > * How good is emulation support > > The lack of real hardware for RISC-V has made it so almost everyone is > working with emulation. It's not realistic right now to work with real > hardware. > > > * What would it take to keep up with the other arches? Is that possible? Right now we run 170 QEMUs and a few boards. Most QEMU VMs run with 4 cores, but some are configured with 8 cores + 32GB of RAM. The number of boards (physical machines) will increase. With the QEMU setup we could deliver thousands of builds per week. Of course we cannot fully keep up. For example OpenJDK doesn't have a JIT which can be used in some packages (building or running tests). In general we have been running Fedora GNOME Wayland Desktop setup with RISC-V SoC (SiFive) + AMD GPUs for years now. I can even play a 4K movie (thanks to the GPU acceleration). > > The real hardware options do not have the performance to keep up with > the other architectures. > > > * What device(s) would we want to target and could we get sufficent > > numbers of them for QA and devel folks to debug problems and test? > > This is probably more of a question for Fedora RISC-V folks like > Richard W.M. Jones... The only device capable of PC-like setup is SiFive Unmatched today. That's the only board you could buy. There are cheaper boards based on Allwinner D1, but that cheap is a complicated story. They used some reversed bits in PTE and RVV is 0.7.1, which is not compatible with what will be ratified. Technically the chip can run in "compatible" mode, but that would kill peripherals IIUC. The current RISC-V Platforms and Profiles specifications are also not finished thus there aren't any devices that would have the official stamps of some compatibility level. If everything goes well these things will be finalized / ratified sooner than later. > > > * Are there folks who can bootstrap/shepard the koji shadowing process? > > > > We already have the other Koji instance that could be converted into a > shadow Koji, couldn't it? I currently avoided "koji shadow" and used my silly scripts (which works as long as you learn all Fedora packages and how things work with some packages/ecosystems). Cheers, david > > > > -- > 真実はいつも一つ！/ 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
Re: Onboarding package
On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > >Is this really necessary? > > Yes. Because anyone can add something like this: > %post > rm -rf / > > And it will destroy the installed system or even the hardware. Yeah, but... that's not going get through the PR process? In fact, that specific thing should fail in CI before a human gets to it even. Overall, we put a lot of trust in maintainers. I don't see this _particular_ route as a likely one for violating that trust. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Personally speaking I think the real barrier is someone with a large > > colourful hat putting up the money to hire a full time developer to > > work on the project. > Also, I think one of the pre-requisites to enabling it in koji would be > making at least one machine available to package maintainers. Yeah, I think we'd want to have at least a remote-shell system plus also an initiative to get dev boards to maintainers with specific interest. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Tue, 5 Oct 2021 at 12:08, Peter Boy wrote: > > > > Am 04.10.2021 um 15:07 schrieb Mat Booth : > > Like many Open Source projects, Fedora is a "do-ocracy“ — …. > > A nice phrase with a decent connotation. And it’s true without doubt. > > And at the same time it is also true, Fedora as many other Open Source > projects is as well about coordination and successful cooperation and > communication. And when Debian distribution got into rough waters decades ago > it was not because of a lack of packaging and "do-ocracy“, but of a lack of > coordination and cooperation - just as an example. Same is true for various > Fedora sub-projects. > > And by the way > > As I said before there's always a lot of discussion from people who, > in the end, never get involved. ... > > > your implicit advice for me to just take action instead of arguing is nice > and welcome. However, I have been doing this for quite some time, e.g. by > igniting development of a systematic and supported installation of Wildfly - > albeit mainly as part of my commitment to Fedora Server WG. Not via packaging > - that was found to be practically unfeasible here - but by alternative > means. I invite you to support the effort with your knowledge and experience, > e.g. to find the optimal way to install the upstream binary (simply in /opt > or is there a better way of integration into Fedora Java runtime system, e.g. > similar to Tomcat split up to the different FSH subdirectories, or something > else). > Thanks for the invite, but I've never used Wildfly and have no interest in contributing to Wildfly. > The development of alternatives to rpm packaging was also one of the > suggestions that came up in this thread. > Been there, done that, got the t-shirt. I used my knowledge and experience to develop the flatpak distribution of Eclipse IDE as an alternative to RPMs. Then we orphaned the RPMs in favour using Eclipse as a flatpak application from Flathub. No-one stepped up to continue maintenance of the RPM version so it went away. This is the proper lifecycle of a RPM package; I won't be made to feel bad about that :-) > > … do-ocracy in action! Picking a goal you care about and setting about > achieving it doesn't require a SIG, it requires you to "do." > > So, do you have any specific, concrete goal you want to achieve? If > the removal of a Java package has affected you directly or a Java > application you care about is in danger of being removed that would be > a excellent place to start. > > > Most of this thread was not about package x.y.z but about broader issues, > such as outdated/misleading documentation and information, disruptive and > untrustworthy development histories (failing one of the core values of Java), > need for alternatives to the current packaging process (e.g. "curated list“ > as mentioned in a previous post), etc. All this has an impact on the Fedora > Java eco system. Unfortunately, an answer to those issues cannot get worked > out as a one-man show, I guess. > > > What else really interests me: The "java-maint-sig" will be removed soon. > Then you are really completely content with the Fedora Java world? No > change? No preferrable improvement anywhere? > > Yes I'm content because I have everything I need: a well maintained JDK and well maintained maven. I get my IDE from Flathub and my libraries from Maven Central. I'm a programmer so my use-cases are very basic. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 35 compose report: 20211005.n.0 changes
OLD: Fedora-35-20211004.n.0 NEW: Fedora-35-20211005.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:11 Upgraded packages: 26 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:16.46 MiB Size of upgraded packages: 566.98 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20211005.n.0.x86_64.vagrant-virtualbox.box Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-35-20211005.n.0.x86_64.vagrant-libvirt.box = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: clufter-0.77.2-9.fc33 Summary: Tool/library for transforming/analyzing cluster configuration formats RPMs:clufter-bin clufter-cli clufter-common clufter-lib-ccs clufter-lib-general clufter-lib-pcs python3-clufter Size:626.09 KiB Package: idm-console-framework-1.2.0-9.fc35 Summary: Identity Management Console Framework RPMs:idm-console-framework Size:1.04 MiB Package: jaxb-2.3.3-6.fc35 Summary: JAXB Reference Implementation RPMs:jaxb-bom jaxb-bom-ext jaxb-codemodel jaxb-codemodel-annotation-compiler jaxb-impl jaxb-relaxng-datatype jaxb-rngom jaxb-runtime jaxb-txw2 jaxb-txwc2 jaxb-xjc jaxb-xsom Size:3.57 MiB Package: jaxb-dtd-parser-1.4.3-5.fc35 Summary: SAX-like API for parsing XML DTDs RPMs:jaxb-dtd-parser jaxb-dtd-parser-javadoc Size:371.40 KiB Package: jaxb-fi-1.2.18-4.fc35 Summary: Implementation of the Fast Infoset Standard for Binary XML RPMs:jaxb-fi Size:354.78 KiB Package: jaxb-istack-commons-3.0.11-4.fc35 Summary: iStack Common Utility Code RPMs:import-properties-plugin istack-commons-maven-plugin jaxb-istack-commons jaxb-istack-commons-runtime jaxb-istack-commons-tools Size:163.99 KiB Package: jaxb-stax-ex-1.8.3-4.fc35 Summary: Extended StAX API RPMs:jaxb-stax-ex Size:46.84 KiB Package: pki-core-11.0.0-0.2.alpha1.fc35 Summary: Dogtag PKI Core Package RPMs:pki-acme pki-base pki-base-java pki-ca pki-kra pki-server pki-symkey pki-tests pki-tools python3-pki Size:10.19 MiB Package: trac-customfieldadmin-plugin-0.2.5-0.19.svn9652.fc34 Summary: Expose ticket custom fields via the web admin interface RPMs:trac-customfieldadmin-plugin Size:19.37 KiB Package: trac-watchlist-plugin-0.5-0.20.svn11062.fc34 Summary: Watchlist plugin for Trac for watching tickets or wiki pages RPMs:trac-watchlist-plugin Size:38.95 KiB Package: xmlstreambuffer-1.5.9-5.fc35 Summary: Stream Based Representation for XML Infoset RPMs:xmlstreambuffer Size:79.70 KiB = UPGRADED PACKAGES = Package: Thunar-4.16.10-1.fc35 Old package: Thunar-4.16.8-2.fc35 Summary: Thunar File Manager RPMs: Thunar Thunar-devel Thunar-docs Size: 10.03 MiB Size change: -29.28 KiB Changelog: * Sun Sep 12 2021 Mukundan Ragavan - 4.16.9-1 - Update to 4.16.9 * Sun Sep 12 2021 Mukundan Ragavan - 4.16.9-2 - Drop dep on dbus-x11 (fixes bz#1975572) * Sun Sep 19 2021 Mukundan Ragavan - 4.16.10-1 - Update to 4.16.10 Package: cc1541-3.3-1.fc35 Old package: cc1541-3.2-5.fc35 Summary: Tool for creating Commodore 1541 Floppy disk images in D64, G64, D71 or D81 format RPMs: cc1541 Size: 226.52 KiB Size change: 44.03 KiB Changelog: * Mon Oct 04 2021 Bj??rn Esser - 3.3-1 - New upstream release Package: cinnamon-5.0.5-4.fc35 Old package: cinnamon-5.0.5-3.fc35 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8.63 MiB Size change: 2.30 KiB Changelog: * Mon Sep 27 2021 Leigh Scott - 5.0.5-4 - Drop fallback patches Package: cockpit-254-1.fc35 Old package: cockpit-253-1.fc35 Summary: Web Console for Linux servers RPMs: cockpit cockpit-bridge cockpit-doc cockpit-kdump cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws Size: 16.74 MiB Size change: 35.99 KiB Changelog: * Wed Sep 29 2021 Matej Marusak - 254-1 - Overview: Move last login to Health Card - Webserver: Restrict frame embedding to same origin - Login: Add Arch Linux branding - Users: Add login history Package: cp2k-8.2-1.fc35 Old package: cp2k-7.1-2.20200925gitdbf7a77.fc35 Summary: Ab Initio Molecular Dynamics RPMs: cp2k cp2k-common cp2k-mpich cp2k-openmpi Size: 256.67 MiB Size change: 1.49 MiB Changelog: * Thu Sep 30 2021 Dominik Mierzejewski - 8.2-1 - update to 8.2 (#1911741) - drop obsolete patch - enable spglib support Package: devhelp-1:41.2-1.fc35 Old package: devhelp-1:41.1-2.fc35 Summary: API documentation browser RPMs
Fedora 35 Final Freeze
Hi all, Today, Oct 5th 2021, is an important day on the Fedora 35 schedule [1], with significant cut-offs. Today we have the Final Freeze [2] which starts at 14:00 UTC. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. [1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist Regards, Mohan Boddu Release Engineering ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Python 3.10 in Fedora 36+: sysconfig's "posix_prefix" install scheme now has /usr/local
Hello Pythonistas, since Fedora 27, we have been patching Python to install packages to /usr/local/lib(64)/python3.X/site-packages if not in rpmbuild: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe The patch was a pragmatic hack in the distutils module that proved to be working quite reliably over the years. Unfortunately, the distutils module is deprecated and is going to be removed from Python 3.12: https://www.python.org/dev/peps/pep-0632/ Working with the upstreams of setuptools, pip, and Python, as well as other Linux distros Python maintainers (Arch, Debian), we have now changed the way the patch works to patch the sysconfig module instead, changing the posix_prefix install scheme to use /usr/local paths. See https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/104 for details. This change is aligned with the upstream plan for Python 3.11 to offer distributors a way to supply their installation schemes to sysconfig: https://bugs.python.org/issue43976 Nothing should change for Fedora packages. If you encounter problems, do let us know and we'll try to help solve them. Software that reads the posix_prefix install_scheme on runtime to figure out where to install stuff should behave the right way by default. OTOH software that reads it to figure out where to load stuff from might need changes, see e.g. the change we did in dnf: https://github.com/rpm-software-management/dnf/pull/1782 Relevant commit: https://src.fedoraproject.org/rpms/python3.10/c/47935cfb9870 Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2021-31c7a2fca8 We might later introduce this to older Python versions as well, but we are not planning to backport this to older Fedora releases. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 35 Final Freeze
Hi all, Today, Oct 5th 2021, is an important day on the Fedora 35 schedule [1], with significant cut-offs. Today we have the Final Freeze [2] which starts at 14:00 UTC. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. [1] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/34/final/buglist Regards, Mohan Boddu Release Engineering ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
> Am 05.10.2021 um 14:56 schrieb Stephen Snow : > > Hello, > > (snip) > > So are the meetings being held with the java-sig? When are they? All of > us interested java community members should attend I think if we want > to offer an opinion or even just have something to say. If you search fedora calendar for java-sig you get an empty list. There is java-devel mailing list which is a (very) „low traffic“ list. > In my simple life and use of java, I find having a stable JDK and the > recent(ish) maven sufficient. Everything else is difficult to pin down > and I find alot of it is project dependant and changes based on that, > not based on the Distro I'm using. If I look at a commercially > available OS that is quite popular, they only package the JRE leaving > averything else up to the user WRT what they need for a dev stack. I use often what is probably „the other" commercially available OS. I’ve to download everything including the JRE from third party sources and have to setup and maintain everything myself. On Fedora, especially all my servers, I really appreciate that all of this is done for me automatically, including notification and installation of updates - if a rpm is available. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages
On Tuesday, 05 October 2021 at 00:20, Peter Robinson wrote: > Looking through the packages I own there's a bunch I no longer use. > I've tried to group these, from memory, where I own something because > it's a dependency of something else. I was going to ask people if they > were interested in them but I decided to straight up orphan them so > they#ll can go through the usual garbage collection process unless > someone claims them. The top two groups of packages need to be > maintained together as the key package, at the top, depends on the > rest. The bottom group are independent. [...] > flite Taken, it's a dependency of FFmpeg (over at RPM Fusion). As usual, co-maintainers welcome. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
> (snip) > You also need people who are good at documentation which frankly many > developers are not. Be it a history of 'the only true documentation > is > the code' to 'look its simple why didn't you just no one would think of and impossible to document without knowing why > it was chosen or used>. It's the most obvious choice? Too true, I personally have been doing systems integration goin on (oh god) 35 yrs, and the last bit of work (you know tha documents that prove you should get paid for the work) is the hardest for me. In fact I have spent a considerable amount of foundation work over the years to get templating and scripting in place for me to be able to automate as much of my documentation as possible. > It isn't that the developer is trying to be obtuse, I think it is how > the brain works for a lot of people. My autism makes it very hard for > me to communicate about code. I can think it, see it, dream it, but > once I get into 'word' mode I can't access it easily. And vice versa, > when I am in code mode, I am almost non-verbal and my emails get very > short and succinct (at least to me..).. Switch me over to word mode > and it takes me hours to be productive in code again. [I have to set > my emails and meetings in a block without working in much code.] My > social skills are also myopic.. I can work with people when I am in > word mode but I can not if I am in code mode beyond 'share code, get > reviewed, fix bugs, point out problems'. > Ditto, though I don't have to deal with an ASD, I stll find if I am at the top of my technical game and really performing, then my communication skills adjust to the berevity the thought mode enforces. > It takes a lot of work to document what I do, and when I am under > water with too many tasks/packages it can be a lot easier to just > make > it work versus doing that. I would like to say 'this is just me' but > when I have explained my problem to a lot of other developers there > are the nods of 'yep that is what it's like'. Getting a truly working > SIG together is a lot of emotional work that a lot of people don't > have the energy to deal with while also doing whatever they are > currently doing. > Honestly, this is another area maybe the community is lacking in right now, we don't seem to have as many "champions" taking the lead on running things like a java-sig. It really does require some organization skills and a marketing mindset. > Getting documentation is a full time job usually with someone who has > to have patience and persistence to get the information they need out > of the developers in code mode and also get the words down into a way > that someone who isn't a developer in code mode can read. > As it has been revealed repeatedly, documentation is an ongoing and ever demanding requirement that, since Fedora Linux release cadence is what it is, and the changes that come every release cycle, ensure a constant need and constant changes happening in those documents. Stephen > > > -- > Stephen J Smoogen. > I've seen things you people wouldn't believe. Flame wars in > sci.astro.orion. I have seen SPAM filters overload because of > Godwin's > Law. All those moments will be lost in time... like posts on a BBS... > time to shutdown -h now. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: co/lead-maintainer sought: python-mailmerge (python)
Hi, On Tue, Oct 5, 2021 at 1:11 PM Blaise Pabon wrote: > I have been wanting to take over a package for the past few years and this > seems like a good opportunity. I may need to refresh some of my access > tokens. > I'll share the same response as before :) Sweet. Onuralp replied via direct mail and I have added them to the repo as well. Can you work with them (or agree on any other organization) around the upgrades indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1937525 also, send me your FAS id so I can add you to the repo. Once the upgrades are good I can hand off the repo to one of you all as main maintainer :) Thank you. regards, bex > > Blaise > > On Wed, May 5, 2021, 6:02 AM Brian (bex) Exelbierd > wrote: > >> Hi, >> >> I added python-mailmerge to Fedora Linux as it was super important to >> large parts of my work as FCAIC. In my current $dayjob I use it less >> frequently, though I know of colleagues who still depend on it. >> >> I'd love to find a maintainer to help me with it. There is a new >> release pending, which I suspect will just be "build the rpm with new >> code; test it; ship it" level effort. I am happy to hand the whole >> thing off to someone or to work with you. >> >> Thank you. >> >> regards, >> >> bex >> -- >> Did this email arrive after work for you? Stop reading it and enjoy >> some work/life balance. >> >> Brian "bex" Exelbierd (he/him/his) >> Community Business Owner, RHEL Product Management >> @bexelbie | http://www.winglemeyer.org >> bexel...@redhat.com >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > -- Did this email arrive after work for you? Stop reading it and enjoy some work/life balance. Brian "bex" Exelbierd (he/him/his) Community Business Owner, RHEL Product Management @bexelbie | http://www.winglemeyer.org bexel...@redhat.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20211005.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 8/206 (x86_64), 17/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211004.n.0): ID: 1013991 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1013991 ID: 1013993 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1013993 ID: 1014031 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1014031 ID: 1014090 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1014090 ID: 1014134 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1014134 ID: 1014207 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/1014207 ID: 1014209 Test: aarch64 universal install_mirrorlist_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1014209 ID: 1014216 Test: aarch64 universal upgrade_2_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1014216 ID: 1014221 Test: aarch64 universal install_kickstart_nfs@uefi URL: https://openqa.fedoraproject.org/tests/1014221 ID: 1014231 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/1014231 ID: 1014232 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/1014232 Old failures (same test failed in Fedora-Rawhide-20211004.n.0): ID: 1013918 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1013918 ID: 1013931 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1013931 ID: 1013935 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1013935 ID: 1013937 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1013937 ID: 1013978 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1013978 ID: 1014043 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1014043 ID: 1014060 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1014060 ID: 1014066 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1014066 ID: 1014067 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1014067 ID: 1014069 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1014069 ID: 1014092 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1014092 ID: 1014192 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1014192 ID: 1014198 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1014198 ID: 1014222 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1014222 Soft failed openQA tests: 2/206 (x86_64), 2/141 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20211004.n.0): ID: 1013952 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1013952 ID: 1014006 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1014006 ID: 1014081 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1014081 ID: 1014099 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1014099 Passed openQA tests: 122/141 (aarch64), 185/206 (x86_64) New passes (same test not passed in Fedora-Rawhide-20211004.n.0): ID: 1014187 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1014187 ID: 1014223 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1014223 Skipped non-gating openQA tests: 11 of 347 Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 1 packages(s) added since previous compose: iwlax2xx-firmware Previous test data: https://openqa.fedoraproject.org/tests/1011939#downloads Current test data: https://openqa.fedoraproject.org/tests/1013892#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: Used mem changed from 235 MiB to 207 MiB 1 packages(s) added since previous compose:
Re: Fedora Java: The Death of Two SIGs
Hello,
(snip)
> However, we lack concepts on how to proceed after removing java-
> maint-sig. What consequences do we draw from the analyses?
>
> Emmanuel Seyman has made some suggestions, about 16 posts back.
> Thoughts on those? I posted on the java list some ideas some time ago
> ('Empowering Fedora Java’). Any comments on those?
>
I think the java-maint-sig should be shut down if it isn't actively
doing anything, and since the sentiment seems to be that there isn't a
real need for it. The only problem is I would be reluctant to offend
anyone who is a part of it by just arbitraily taking it down,
especially if they have been just quietly doing their part, and jsut
reluctant to talk about it for whatever reason.
>
There are members of the comunity who have spoken up here that are
actively contributing to java in Fedora Linux community.
So are the meetings being held with the java-sig? When are they? All of
us interested java community members should attend I think if we want
to offer an opinion or even just have something to say.
In my simple life and use of java, I find having a stable JDK and the
recent(ish) maven sufficient. Everything else is difficult to pin down
and I find alot of it is project dependant and changes based on that,
not based on the Distro I'm using. If I look at a commercially
available OS that is quite popular, they only package the JRE leaving
averything else up to the user WRT what they need for a dev stack.
Just my 2c worth
Stephen
>
> Peter
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Onboarding package
Hello Vit, I was one of those potential packagers who started a conversation here regarding the apparent dificulies experienced by some to varying degrees. In my simple non-packager perspective, There needs to be some tool used to help sponsors feel comfortable with the potential packagers capability and also for the packager to help them guage their own competence. (snip) > we were initially discussing that it could be useful to have some > package one can experiment with without being too much worried about > the > result. > > However, discussing this back and forth, we figured that it might > also > where new coming package maintainer could gradually gain experience > with > the packaging workflows. So the simplest tasks could be: > > 1) Add changelog entry into onboarding package and open PR with the > change. This would not require too many privileges. Alternatively > this > current Fedora contributors might be interested to send such PR ;) > I like this approach, but I was also thinking of a small tutorial/app to actually package a piece of software as required, going through the various steps but be a "fake" package that is only used to teach and test with. This app could record the FAS user ID and assign a badge to it once they complete the tutorial successfully. Sort of a base starting point for all new packagersd that give both them some confidence going in and the sponsors some confidence too about the level of the new committers capabilities. > packager to be already sponsored and they could go through the whole > process themeselves just with some light guidance if needed. > > This could be extended in the future. E.g. next step could be: > > 3) Submit module update. > > Apart from gaining experience, this could also help with the common > question "where should I start". And of course our sponsoring > guidelines > could be refreshed suggesting/requesting to take these steps at some > point. > > Thoughts? > Personnaly I am for this type of approach since it is also clarifying the roles a bit more too. It wouldn't hurt to outline what is expected of a packager of Fedora Linux in general. You know expectations are very often left unsaid thinking that roles and responsibilities fill in the info, but that is not always the case. Looking forward to this progress, Stephen > > Vít > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
On Tue, Oct 05, 2021 at 12:28:03PM +0200, Petr Menšík wrote: > I like the idea. > > I think we can even setup tests namespace repo for it, which would > ensure all content in this package is %doc only. It does not contain > %post scripts and no executable, unless strictly predefined content. > That CI repo would have more strict access to ensure newcomers cannot > avoid automated checks. > > We could ask new contributors to review PRs of candidates and merge and > build them. > > I think this package definitely should be part of the distribution. > Other packages should not depend on it, so it would get installed only > by those who want it. New contributors could also be proud once they > have their name in a real package. Don't force anyone, but blocking is > not needed IMHO. Yep. In particular, changes should generate a visible %changelog entry, so that prospective maintainers can see how their commit message are visible to users. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Tue, 5 Oct 2021 at 07:26, Peter Boy wrote: > > > > > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski : > > > > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote: > >> However, we lack concepts on how to proceed after removing java-maint-sig. > >> What consequences do we draw from the analyses? > > > > … If you want > > to improve docs, just do it. And so on. ... > > ... or to plan editing the wiki. Whoever wants to clean up some wiki > > pages can simply do so, without asking. > > It’s not as easy as you think of. That way you will end with the docs as > Stephen Smoogen described 4 posts back, just chaos and misinformation. You > need collaboration and agreement (shared plan) from participants in all > affected areas - including you as the (main) developer of a core package (not > writing text, but e.g check the concept, check technical correctness and > completeness). It simply doesn’t work the way you are proposing. You also need people who are good at documentation which frankly many developers are not. Be it a history of 'the only true documentation is the code' to 'look its simple why didn't you just . It's the most obvious choice?' It isn't that the developer is trying to be obtuse, I think it is how the brain works for a lot of people. My autism makes it very hard for me to communicate about code. I can think it, see it, dream it, but once I get into 'word' mode I can't access it easily. And vice versa, when I am in code mode, I am almost non-verbal and my emails get very short and succinct (at least to me..).. Switch me over to word mode and it takes me hours to be productive in code again. [I have to set my emails and meetings in a block without working in much code.] My social skills are also myopic.. I can work with people when I am in word mode but I can not if I am in code mode beyond 'share code, get reviewed, fix bugs, point out problems'. It takes a lot of work to document what I do, and when I am under water with too many tasks/packages it can be a lot easier to just make it work versus doing that. I would like to say 'this is just me' but when I have explained my problem to a lot of other developers there are the nods of 'yep that is what it's like'. Getting a truly working SIG together is a lot of emotional work that a lot of people don't have the energy to deal with while also doing whatever they are currently doing. Getting documentation is a full time job usually with someone who has to have patience and persistence to get the information they need out of the developers in code mode and also get the words down into a way that someone who isn't a developer in code mode can read. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: python3-jwt+crypto and python3-cryptography
Ohh, thanks Miro. I didn't see that :) Em ter, 5 de out de 2021 08:21, Miro Hrončok escreveu: > On 05. 10. 21 13:13, Geraldo Simião Kutz wrote: > > Good morning/afternoon everyone, > > > > I'm having this dependency problem, is this correct? > > > > If i use dnf up --best --allowerasing it will naturally remove > python3-jwt+crypto > > > > Will this be normalyzed by the end of freeze? > > > > # > > Problema: pacote python3-jwt+crypto-2.1.0-2.fc35.noarch requer > > (python3.10dist(cryptography) < 4 with python3.10dist(cryptography) >= > 3.3.1), > > mas nenhum dos provedores pode ser instalado > >- não é possível instalar python3-cryptography-35.0.0-2.fc35.x86_64 e > > python3-cryptography-3.4.7-5.fc35.x86_64 > >- não é possível instalar o melhor candidato à atualização para o > pacote > > python3-jwt+crypto-2.1.0-2.fc35.noarch > >- não é possível instalar o melhor candidato à atualização para o > pacote > > python3-cryptography-3.4.7-5.fc35.x86_64 > > > = > > Pacote Arquitetura > > > VersãoRepositório > > > Tam. > > > = > > Ignorando pacotes com conflitos: > > (adicionar --best --allowerasing' a linha de comando para forçar sua > atualização): > > python3-cryptography x86_64 > > > 35.0.0-2.fc35 updates-testing > 1.0 M > > > > Resumo da transação > > > = > > Ignorar 1 Pacote > > https://bugzilla.redhat.com/show_bug.cgi?id=2010061 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads Up: OpenImageIO 2.3.x (rawhide only)
All dependencies have been rebuilt. A few packages needed patching to deal with some small architectural changes in OIIO. https://bodhi.fedoraproject.org/updates/FEDORA-2021-61d474b674 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211005.n.0 changes
OLD: Fedora-Rawhide-20211004.n.0 NEW: Fedora-Rawhide-20211005.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 5 Dropped packages:4 Upgraded packages: 117 Downgraded packages: 0 Size of added packages: 1.76 MiB Size of dropped packages:1.95 MiB Size of upgraded packages: 7.42 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 75.45 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: golang-github-git-lfs-pktline-0-0.2.20211004git06e9096.fc36 Summary: Git pkt-line Toolkit RPMs:golang-github-git-lfs-pktline-devel Size:16.95 KiB Package: golang-github-git-lfs-wildmatch-2-2.0.1-2.fc36 Summary: Pattern matching language for filepaths compatible with Git RPMs:golang-github-git-lfs-wildmatch-2-devel Size:20.38 KiB Package: python-sphinx-sitemap-2.2.0-1.fc36 Summary: Sitemap generator for Sphinx RPMs:python3-sphinx-sitemap Size:20.63 KiB Package: rust-serde_with-1.9.4-1.fc36 Summary: Custom de/serialization functions for Rust's serde RPMs:rust-serde_with+chrono-devel rust-serde_with+chrono_crate-devel rust-serde_with+default-devel rust-serde_with+hex-devel rust-serde_with+json-devel rust-serde_with-devel Size:102.74 KiB Package: xstream-1.4.18-2.fc36 Summary: Java XML serialization library RPMs:xstream xstream-benchmark xstream-javadoc Size:1.60 MiB = DROPPED PACKAGES = Package: clufter-0.77.2-9.fc33 Summary: Tool/library for transforming/analyzing cluster configuration formats RPMs:clufter-bin clufter-cli clufter-common clufter-lib-ccs clufter-lib-general clufter-lib-pcs python3-clufter Size:626.09 KiB Package: jakarta-commons-httpclient-1:3.1-38.fc35 Summary: Jakarta Commons HTTPClient implements the client side of HTTP standards RPMs:jakarta-commons-httpclient jakarta-commons-httpclient-demo jakarta-commons-httpclient-javadoc jakarta-commons-httpclient-manual Size:1.28 MiB Package: trac-customfieldadmin-plugin-0.2.5-0.19.svn9652.fc34 Summary: Expose ticket custom fields via the web admin interface RPMs:trac-customfieldadmin-plugin Size:19.37 KiB Package: trac-watchlist-plugin-0.5-0.20.svn11062.fc34 Summary: Watchlist plugin for Trac for watching tickets or wiki pages RPMs:trac-watchlist-plugin Size:38.95 KiB = UPGRADED PACKAGES = Package: PyQt-builder-1.11.0-1.fc36 Old package: PyQt-builder-1.10.3-2.fc36 Summary: The PEP 517 compliant PyQt build system RPMs: PyQt-builder Size: 85.03 KiB Size change: 1.72 KiB Changelog: * Mon Oct 04 2021 Scott Talbert - 1.11.0-1 - Update to new upstream release (#2010060) Package: PyYAML-6.0-0.1.b1.fc36 Old package: PyYAML-5.4.1-4.fc35 Summary: YAML parser and emitter for Python RPMs: python3-pyyaml Size: 933.18 KiB Size change: -3.26 KiB Changelog: * Mon Oct 04 2021 John Eckersberg - 6.0-0.1.b1 - New upstream beta release 6.0b1 (rhbz#2010501) Package: R-testthat-3.1.0-1.fc36 Old package: R-testthat-3.0.4-2.fc35 Summary: Unit Testing for R RPMs: R-testthat Size: 7.61 MiB Size change: 208.40 KiB Changelog: * Mon Oct 04 2021 Tom Callaway - 3.1.0-1 - update to 3.1.0 Package: automake-1.16.5-1.fc36 Old package: automake-1.16.4-1.fc36 Summary: A GNU tool for automatically creating Makefiles RPMs: automake Size: 672.14 KiB Size change: 943 B Changelog: * Mon Oct 04 2021 Ondrej Dubaj - 1.16.5-1 - Rebase to upstream version 1.16.5 Package: azure-cli-2.28.0-4.fc36 Old package: azure-cli-2.28.0-3.fc36 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 3.60 MiB Size change: 343 B Changelog: * Mon Oct 04 2021 Major Hayden 2.28.0-4 - Allow for newer versions of humanfriendly Package: cc1541-3.3-1.fc36 Old package: cc1541-3.2-5.fc35 Summary: Tool for creating Commodore 1541 Floppy disk images in D64, G64, D71 or D81 format RPMs: cc1541 Size: 226.55 KiB Size change: 44.06 KiB Changelog: * Mon Oct 04 2021 Bj??rn Esser - 3.3-1 - New upstream release Package: coreutils-9.0-2.fc36 Old package: coreutils-8.32-32.fc36 Summary: A set of basic GNU tools commonly used in shell scripts RPMs: coreutils coreutils-common coreutils-single Size: 18.28 MiB Size change: -223.47 KiB Changelog: * Sun Sep 26 2021 Kamil Dudka - 9.0-1 - new upstream release 9.0 * Mon Oct 04 2021 Kamil Dudka - 9.0-2 - chmod: fix exit status when ignoring symlinks Package: csmock-3.0.0-1.fc36 Old package: csmock-2.9.0-1.fc36 Summary: A mock wrapper for Static Analysis tools RPMs: csbuild csmock csmock-common csmock-plugin-bandit csmock-plugin-cbmc csmock-plugin-clang csmock-plugin-cppcheck csmock-plugin
Re: Fedora Java: The Death of Two SIGs
> Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski :
>
> On Mon, Oct 4, 2021 at 2:08 PM Peter Boy wrote:
>> However, we lack concepts on how to proceed after removing java-maint-sig.
>> What consequences do we draw from the analyses?
>
> … If you want
> to improve docs, just do it. And so on. ...
> ... or to plan editing the wiki. Whoever wants to clean up some wiki
> pages can simply do so, without asking.
It’s not as easy as you think of. That way you will end with the docs as
Stephen Smoogen described 4 posts back, just chaos and misinformation. You need
collaboration and agreement (shared plan) from participants in all affected
areas - including you as the (main) developer of a core package (not writing
text, but e.g check the concept, check technical correctness and completeness).
It simply doesn’t work the way you are proposing.
>> I posted on the java list some ideas some time ago ('Empowering Fedora
>> Java’). Any comments on those?
>
> These were about java-maint-sig, IIRC, which basically does not exist
> any longer.
No! It was about:
> The biggest success is that with all the adversities in java packaging we
> have a stabilized Fedora Java core platform.
>
> The next urgent step, in my opinion, is to update and improve information
> materials and documentation, followed by a community building process based
> on it.
>
>
> I can offer to do the writing. …
followed by tentative ideas about details of documentation.
You wrote:
> Java SIG has resources in form
> of communication channels that can be used by members to help each
> other. There is a mailing list and an IRC channel.
So much for the theory, yes. I would have appreciated even a tiny bit of it.
You are one of the developers without whose contributions the Fedora Java stack
would probably collapse in a short time. I would really be interested in the
same question as to Mat: With java-paint-sig removed, are you really completely
content with the Fedora Java world? No change? No improvement anywhere?
And just in case you see some preferable improvement anywhere, what do you
think should be done to promote and achieve this?
Best
Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: python3-jwt+crypto and python3-cryptography
On 05. 10. 21 13:13, Geraldo Simião Kutz wrote: Good morning/afternoon everyone, I'm having this dependency problem, is this correct? If i use dnf up --best --allowerasing it will naturally remove python3-jwt+crypto Will this be normalyzed by the end of freeze? # Problema: pacote python3-jwt+crypto-2.1.0-2.fc35.noarch requer (python3.10dist(cryptography) < 4 with python3.10dist(cryptography) >= 3.3.1), mas nenhum dos provedores pode ser instalado - não é possível instalar python3-cryptography-35.0.0-2.fc35.x86_64 e python3-cryptography-3.4.7-5.fc35.x86_64 - não é possível instalar o melhor candidato à atualização para o pacote python3-jwt+crypto-2.1.0-2.fc35.noarch - não é possível instalar o melhor candidato à atualização para o pacote python3-cryptography-3.4.7-5.fc35.x86_64 = Pacote Arquitetura Versão Repositório Tam. = Ignorando pacotes com conflitos: (adicionar --best --allowerasing' a linha de comando para forçar sua atualização): python3-cryptography x86_64 35.0.0-2.fc35 updates-testing 1.0 M Resumo da transação = Ignorar 1 Pacote https://bugzilla.redhat.com/show_bug.cgi?id=2010061 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
python3-jwt+crypto and python3-cryptography
Good morning/afternoon everyone, I'm having this dependency problem, is this correct? If i use dnf up --best --allowerasing it will naturally remove python3-jwt+crypto Will this be normalyzed by the end of freeze? # Problema: pacote python3-jwt+crypto-2.1.0-2.fc35.noarch requer (python3.10dist(cryptography) < 4 with python3.10dist(cryptography) >= 3.3.1), mas nenhum dos provedores pode ser instalado - não é possível instalar python3-cryptography-35.0.0-2.fc35.x86_64 e python3-cryptography-3.4.7-5.fc35.x86_64 - não é possível instalar o melhor candidato à atualização para o pacote python3-jwt+crypto-2.1.0-2.fc35.noarch - não é possível instalar o melhor candidato à atualização para o pacote python3-cryptography-3.4.7-5.fc35.x86_64 = Pacote Arquitetura VersãoRepositório Tam. = Ignorando pacotes com conflitos: (adicionar --best --allowerasing' a linha de comando para forçar sua atualização): python3-cryptography x86_64 35.0.0-2.fc35 updates-testing 1.0 M Resumo da transação = Ignorar 1 Pacote # Best regards Geraldo geraldosimiao ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: co/lead-maintainer sought: python-mailmerge (python)
I have been wanting to take over a package for the past few years and this seems like a good opportunity. I may need to refresh some of my access tokens. Blaise On Wed, May 5, 2021, 6:02 AM Brian (bex) Exelbierd wrote: > Hi, > > I added python-mailmerge to Fedora Linux as it was super important to > large parts of my work as FCAIC. In my current $dayjob I use it less > frequently, though I know of colleagues who still depend on it. > > I'd love to find a maintainer to help me with it. There is a new > release pending, which I suspect will just be "build the rpm with new > code; test it; ship it" level effort. I am happy to hand the whole > thing off to someone or to work with you. > > Thank you. > > regards, > > bex > -- > Did this email arrive after work for you? Stop reading it and enjoy > some work/life balance. > > Brian "bex" Exelbierd (he/him/his) > Community Business Owner, RHEL Product Management > @bexelbie | http://www.winglemeyer.org > bexel...@redhat.com > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
> Am 04.10.2021 um 15:07 schrieb Mat Booth : > > Like many Open Source projects, Fedora is a "do-ocracy“ — …. A nice phrase with a decent connotation. And it’s true without doubt. And at the same time it is also true, Fedora as many other Open Source projects is as well about coordination and successful cooperation and communication. And when Debian distribution got into rough waters decades ago it was not because of a lack of packaging and "do-ocracy“, but of a lack of coordination and cooperation - just as an example. Same is true for various Fedora sub-projects. And by the way > As I said before there's always a lot of discussion from people who, > in the end, never get involved. ... your implicit advice for me to just take action instead of arguing is nice and welcome. However, I have been doing this for quite some time, e.g. by igniting development of a systematic and supported installation of Wildfly - albeit mainly as part of my commitment to Fedora Server WG. Not via packaging - that was found to be practically unfeasible here - but by alternative means. I invite you to support the effort with your knowledge and experience, e.g. to find the optimal way to install the upstream binary (simply in /opt or is there a better way of integration into Fedora Java runtime system, e.g. similar to Tomcat split up to the different FSH subdirectories, or something else). The development of alternatives to rpm packaging was also one of the suggestions that came up in this thread. > … do-ocracy in action! Picking a goal you care about and setting about > achieving it doesn't require a SIG, it requires you to "do." > > So, do you have any specific, concrete goal you want to achieve? If > the removal of a Java package has affected you directly or a Java > application you care about is in danger of being removed that would be > a excellent place to start. Most of this thread was not about package x.y.z but about broader issues, such as outdated/misleading documentation and information, disruptive and untrustworthy development histories (failing one of the core values of Java), need for alternatives to the current packaging process (e.g. "curated list“ as mentioned in a previous post), etc. All this has an impact on the Fedora Java eco system. Unfortunately, an answer to those issues cannot get worked out as a one-man show, I guess. What else really interests me: The "java-maint-sig" will be removed soon. Then you are really completely content with the Fedora Java world? No change? No preferrable improvement anywhere? Best Peter — Dr. Peter Boy Universität Bremen Mary-Sommerville-Str. 5 28359 Bremen Germany p...@uni-bremen.de www.uni-bremen.de Are you looking for a web content management system for scientific research organizations? Have a look at http://www.scientificcms.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
I like the idea. I think we can even setup tests namespace repo for it, which would ensure all content in this package is %doc only. It does not contain %post scripts and no executable, unless strictly predefined content. That CI repo would have more strict access to ensure newcomers cannot avoid automated checks. We could ask new contributors to review PRs of candidates and merge and build them. I think this package definitely should be part of the distribution. Other packages should not depend on it, so it would get installed only by those who want it. New contributors could also be proud once they have their name in a real package. Don't force anyone, but blocking is not needed IMHO. Cheers, Petr On 10/4/21 21:09, Kevin Fenzi wrote: > On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote: >> On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote: I like the idea! We can block such a package from ever appearing in a compose in pungi. >>> Is this really necessary? The package will not be open to anyone, >>> but only for approved contributors. Malicious behaviour is not more >>> likely then in any other package (and would be immediately caught). >>> I think we're thinking up technical solutions to something that is >>> not a problem. >> Yeah, I think making it a real package is a good idea. Maybe even a little >> packaged script that runs >> >> xdg-open https://docs.fedoraproject.org/en-US/fedora-join/ >> >> ? >> >> The package itself can even be a gateway to onboarding for the curious, but >> more importantly, it'd act more like a real package. > True. As long as there's a group of experenced folks watching it, that > should be ok. > > kevin > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: > [...] > > Personally speaking I think the real barrier is someone with a large > > colourful hat putting up the money to hire a full time developer to > > work on the project. > > Also, I think one of the pre-requisites to enabling it in koji would be > making at least one machine available to package maintainers. I agree. In practice it would likely be easier to ensure that we have clearer instructions for setting up qemu and timely delivery of images to run on qemu, eg through virt-builder. (I don't know about anyone else but I much prefer to work on something in a local environment.) This would be something for the person hired above to do. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211005.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211004.0): ID: 1013871 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1013871 ID: 1013879 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1013879 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RISC-V -- are we ready for more, and what do we need to do it?
> On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller wrote: > > I think the primary problem here is that koji does support neither > external builders nor building on top of qemu emulation. > However, COPR *does* support building on emulated architectures > (that's how its armv7 and s390x support works there). > I think your wrong about koji not supporting external builders, rpmfusion koji uses external builders. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL package and Java 11 requirement.
When opening a Buzilla, these common issues popped up: java-11-openjdk-headless RPM does not provide java-headless capability - https://bugzilla.redhat.com/show_bug.cgi?id=1797054 - "Hi. This is intentional. It will be added once jdk8 will stop to be the system JDK." javapackages-tools: wrong generated Requires: `java-headless >= 11` - https://bugzilla.redhat.com/show_bug.cgi?id=1993879 - "The culprint *may* be xmvn, as there is (at least) one pkg in rhel8 which is jdk11 based but is build by Makefile, and do not suffer the issue." - "A proper long-term fix would mean redesigning how provides and auto-requires are supposed to work. There are several possibilities." - "Another possibility is removing auto-requires on java-headless altogether - they add little value and cause much trouble." Is it possible to disable the auto-require generation in xmvn? Otherwise it seems I have to skip usage of xmvn just for that. Best wishes, Stefan - Ursprüngliche Mail - Von: "fedoraproject org" An: "epel-devel" Gesendet: Dienstag, 5. Oktober 2021 09:05:13 Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. Hello Mike, I thought (!) I read somewhere that this difference between java-headless and java-11-headless was intentional (or at least I understood it that way). Let me open a Bugzilla against Java 11. How did others tackle this issue in the past/currently though? I can't be the first one creating an rpm with an autogenerated java-headless >= 1:9 tag. Is there a way to disable/remove this autogeneration or force it to be something different? Also I noticed some packages where the headless tag was not generated at all. So maybe I could just remove the trigger for that. I tried removing maven-compiler-plugin from the pom and adding the compiler.target=11 line in the build section but that gave the same result. Thanks and best wishes, Stefan - Ursprüngliche Mail - Von: "Mike Rochefort" An: "epel-devel" Gesendet: Montag, 4. Oktober 2021 22:57:09 Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. On Mon, Oct 4, 2021 at 3:50 PM Stefan Bluhm wrote: > > it provides "java-11-headless". Not "java-headless". At least not on my > machine Doing my own checks on CentOS Stream 8 and RHEL 8.4, this sounds like a Fedora change that didn't make its way back to RHEL. Worth opening a Bugzilla report on? For posterity, only java-1.8.0 returns when checking for java-headless on EL8 (latest versions on RHEL for 1.8 and 11 as of writing). $ rpm -qp --provides java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64.rpm /usr/bin/jjs config(java-1.8.0-openjdk-headless) = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.302.b08-0.el8_4 java-headless = 1:1.8.0 java-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-headless = 1:1.8.0 jre-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 libjava.so()(64bit) libjava.so(SUNWprivate_1.1)(64bit) libjsig.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libverify.so()(64bit) libverify.so(SUNWprivate_1.1)(64bit) $ rpm -qp --provides java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64.rpm config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4 java-11-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4 jre-11-headless = 1:11.0.12.0.7-0.el8_4 jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 -- Mike ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
Fedora-Cloud-33-20211005.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211004.0): ID: 1013797 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1013797 ID: 1013805 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1013805 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Onboarding package
Dne 04. 10. 21 v 16:22 Vitaly Zaitsev via devel napsal(a): On 04/10/2021 10:57, Vít Ondruch wrote: Recently, there have been a lot of discussions on this list as well as we have internally about onboarding. During our internal brainstorming, we were initially discussing that it could be useful to have some package one can experiment with without being too much worried about the result. I like this idea, but such packages shouldn't be pushed to the official Fedora repositories. 2) Second step could be something similar, but that would require the packager to be already sponsored and they could go through the whole process themeselves just with some light guidance if needed. We have COPR. It doesn't require anything other than the FAS account. I was thinking about this in my follow up, but I am not sure if Copr workflow is separate case or if it should precede the fokflow (2). The thing is that these two are quite distinct. While submitting package into Copr is definitely good step introducing new package into Fedora, I don't know how to integrate this into onboarding to not be side step. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL package and Java 11 requirement.
Hello Mike, I thought (!) I read somewhere that this difference between java-headless and java-11-headless was intentional (or at least I understood it that way). Let me open a Bugzilla against Java 11. How did others tackle this issue in the past/currently though? I can't be the first one creating an rpm with an autogenerated java-headless >= 1:9 tag. Is there a way to disable/remove this autogeneration or force it to be something different? Also I noticed some packages where the headless tag was not generated at all. So maybe I could just remove the trigger for that. I tried removing maven-compiler-plugin from the pom and adding the compiler.target=11 line in the build section but that gave the same result. Thanks and best wishes, Stefan - Ursprüngliche Mail - Von: "Mike Rochefort" An: "epel-devel" Gesendet: Montag, 4. Oktober 2021 22:57:09 Betreff: [EPEL-devel] Re: EPEL package and Java 11 requirement. On Mon, Oct 4, 2021 at 3:50 PM Stefan Bluhm wrote: > > it provides "java-11-headless". Not "java-headless". At least not on my > machine Doing my own checks on CentOS Stream 8 and RHEL 8.4, this sounds like a Fedora change that didn't make its way back to RHEL. Worth opening a Bugzilla report on? For posterity, only java-1.8.0 returns when checking for java-headless on EL8 (latest versions on RHEL for 1.8 and 11 as of writing). $ rpm -qp --provides java-1.8.0-openjdk-headless-1.8.0.302.b08-0.el8_4.x86_64.rpm /usr/bin/jjs config(java-1.8.0-openjdk-headless) = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 java-1.8.0-openjdk-headless(x86-64) = 1:1.8.0.302.b08-0.el8_4 java-headless = 1:1.8.0 java-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-headless = 1:1.8.0.302.b08-0.el8_4 jre-1.8.0-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 jre-headless = 1:1.8.0 jre-openjdk-headless = 1:1.8.0.302.b08-0.el8_4 libjava.so()(64bit) libjava.so(SUNWprivate_1.1)(64bit) libjsig.so()(64bit) libjvm.so()(64bit) libjvm.so(SUNWprivate_1.1)(64bit) libverify.so()(64bit) libverify.so(SUNWprivate_1.1)(64bit) $ rpm -qp --provides java-11-openjdk-headless-11.0.12.0.7-0.el8_4.x86_64.rpm config(java-11-openjdk-headless) = 1:11.0.12.0.7-0.el8_4 java-11-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 java-11-openjdk-headless(x86-64) = 1:11.0.12.0.7-0.el8_4 jre-11-headless = 1:11.0.12.0.7-0.el8_4 jre-11-openjdk-headless = 1:11.0.12.0.7-0.el8_4 -- Mike ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
