Re: employment related packager groups
On Sat, May 27, 2023 at 2:52 PM Ali Erdinc Koroglu wrote: > > > > On 27/05/2023 15:18, Florian Weimer wrote: > > * Kevin Fenzi: > > > >> Today we have packager groups used in src.fedoraproject.org to allow a > >> group of people to maintain packages. In the past this has been used for > >> SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the > >> like. > >> > >> FESCo has been asked about creating company related groups. > >> ( https://pagure.io/fesco/issue/2966 and > >> https://pagure.io/fesco/issue/2929 ) > >> ie, foocorp-sig / foocopr-packagers. These groups would then be used to > >> help maintain packages that foocorp finds of interest/value. > > > > Will these groups automatically make members part of the packager group? > > Or will that be a separate step? > > I think this can be like that: "To join the foocorp-SIG, packager group > membership is a requirement" > IMO, we should not call these SIGs either. I'm not sure exactly what the naming convention should be, but one thought would be "corp-maint_" (or flip it around if you wish). e.g., "corp-maint_aiven" for Aiven employees. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
Gary Buhrmaster wrote: > Any particular position (in a large enough company like IBM, or RH) has > about zero impact on any organization's profits. Which is why they have laid off a whole bunch of people. They just happen to not be as visible as the (now former) Fedora Program Manager. > It *may* indicate priorities (which is a completely different discussion, > and which you might, legitimately, ask if IBM and RH is committed, and at > what level, to Fedora in the long term(*)). It was pretty clear in IBM's acquisition announcement that they are only interested in RH as a cloud services company and do not care at all about RHEL, let alone Fedora. The word "Linux" did not show up a single time in the whole announcement! Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Deprecation of the aspell package
Sam Varshavchik wrote: > I have one package in Fedora. It uses aspell's C++ API. > > Hunspell does not have a functionally-equivalent C++ API. Then use Enchant2, as already suggested. It has a C (enchant.h) and a C++ (enchant++.h) API. Or if it is a Qt/KDE application, just use Sonnet. > it does not have a C++ API that offers a convenient way for applications > to run a spell check against the system's default dictionary. Enchant and Sonnet both handle that for you (they use the Hunspell C++ API and do their own file lookup in system paths), see: https://github.com/AbiWord/enchant/blob/e224b4cbc9856d86335afb43dd1a6651f99fc58e/providers/enchant_hunspell.cpp#L196 https://invent.kde.org/frameworks/sonnet/-/blob/88ba0b8c53d4bc6fbb45ab5350bdf5aa4fde23d7/src/plugins/hunspell/hunspellclient.cpp#L23 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Deprecation of the aspell package
Peter Oliver wrote: > If we’re going to recommend migration to anything, shouldn’t it be > enchant2? Users would be able to configure their preferred spellchecking > engine per language (which I imagine is more important for some languages > than others), and we wouldn’t have to go through this again in the future > if we hypothetically decided that, say, Nuspell should replace Hunspell as > our default spellchecker. It shall be noted that KDE upstream actually dropped Enchant support in Sonnet in KF5 and switched to using Hunspell directly. (They also support aspell, hspell, and voikko. All 4 are optional at compile-time, and plugins at runtime.) Though to be fair, Sonnet is already an abstraction similar to Enchant, and having an abstraction built on top of an abstraction apparently did not work out that well. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Deprecation of the aspell package
ijaaskelai...@outlook.com wrote: > What are Finnish users supposed to do once aspell-fi retires? As I understand it, the only spellchecker the Finnish spellchecking community supports is Voikko. Unfortunately, upstreams have been reluctant to add support for a single-language spellchecking library when the rest of the world has been moving to Hunspell. You can find some ancient unmaintained Hunspell dictionaries for Finnish, which are based on the same ispell-fi 0.7 from 2000 as the aspell-fi dictionaries you are apparently using: https://github.com/fluks/fi-FI-mozilla-spellchecker The copyright file says the dictionaries come from the Debian myspell-fi package, which is built from the ispell-fi source package: https://sources.debian.org/src/ispell-fi/ https://launchpad.net/ubuntu/+source/ispell-fi/0.7-18 (That source code should probably be included, given the GPL license of the dictionaries.) This changelog: https://sources.debian.org/src/ispell-fi/0.7-18/CHANGELOG/ gives the date of the last upstream change as "3rd of September 2000". These could be packaged as hunspell-fi, but upstream is completely dead. (Even the GitHub repository that just republishes the files has not been touched since 2017. No changes have been made in that repository at all. The Debian package was last touched in 2011, the original upstream in 2000.) There is also a hyphenation dictionary for Hunspell's "hyphen": http://hlt.sztaki.hu/resources/hunspell/Finnish/fi_FI.zip converted 2003-11-03 from a LaTeX rule file apparently last touched in 1995. This could be packaged as hyphen-fi, but there too, upstream is dead. If you want these rules to be maintained, somebody who speaks the Finnish language will have to do it. (There was a suggestion to look for inspiration at the rules for Estonian, which, as you probably know, is closely related.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
On Mon, May 29, 2023 at 3:28 AM Kevin Kofler via devel wrote: > > Gary Buhrmaster wrote: > > RH's staff redundancies > > The position was clearly NOT redundant. The word (and all words are made up) is used by organizations to meet certain legal requirements (talk to *your* lawyer for a better explanation of all the details and subtleties of employment law if you don't understand employment law, as it is complex (and even more complex in multi- national organizations such as IBM and RH as some countries have "interesting" requirements); my understanding is based on occasional discussions with my employment lawyer colleagues, and I have mostly decided that is not a field I wish to become an expert in). > This is just RH unilaterally killing > jobs including a central Fedora position in order to increase IBM's profits. Any particular position (in a large enough company like IBM, or RH) has about zero impact on any organization's profits. It *may* indicate priorities (which is a completely different discussion, and which you might, legitimately, ask if IBM and RH is committed, and at what level, to Fedora in the long term(*)). Personally, I think the Fedora Program Manager (as embodied most recently in Ben) provided value to the Fedora community, as some of the work being done was something that volunteers cannot easily pick up (simply due to available time (resources)). I fervently hope that the council members will not (in the long term) try to "make do" with fewer people (asking others to do 130%), but will either offload to the community, or drop (after consultation with the community) some of the work the Program Manager or other members of the Council did (there needs to be a prioritized list of work and reassigments). If no one is willing/able to step up, some functions will need to be terminated for the good of the work/life balance of the remaining Council members (yes, some people live to work, and work to live, but that is not something we should expect of our hatters.). (*) Someone, and I am not sure of the process or protocol, should ask RH what they see and want Fedora to be, and how they intend to support (fund) that going forward. It is, perhaps, not a place I (or you) wish to be, but right now all we really know is that RH has decided to de-commit some resources. Perhaps they intend to add more resources in a different way. I would like to think that discussion may have happened (or at least started) at the RH summit, but as I do not not attend (no one is paying my attendance), I have no idea. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
Gary Buhrmaster wrote: > RH's staff redundancies The position was clearly NOT redundant. This is just RH unilaterally killing jobs including a central Fedora position in order to increase IBM's profits. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bypassing setuptools_scm
On Sun, May 28, 2023, at 8:03 PM, Orion Poplawski wrote: > Is there a canonical way to bypass setuptools_scm? Sometimes one would > like to build from a github tarball (e.g. for test data) but then > setuptool_scm fails to detect a version. Setting the environment variable SETUPTOOLS_SCM_PRETEND_VERSION should do what you want. This also works for packages that use hatch-vcs. https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Test-Announce] 2023-05-29 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-05-29 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! It's meeting time again! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Bypassing setuptools_scm
Is there a canonical way to bypass setuptools_scm? Sometimes one would like to build from a github tarball (e.g. for test data) but then setuptool_scm fails to detect a version. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2210601] New: perl-DateTime-Locale-1.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2210601 Bug ID: 2210601 Summary: perl-DateTime-Locale-1.39 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Locale Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.39 Upstream release that is considered latest: 1.39 Current version/release in rawhide: 1.38-1.fc39 URL: https://metacpan.org/dist/DateTime-Locale/ 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://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/6477/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-DateTime-Locale -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2210601 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2210600] New: perl-Business-ISBN-Data-20230528.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2210600 Bug ID: 2210600 Summary: perl-Business-ISBN-Data-20230528.001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Business-ISBN-Data Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 20230528.001 Upstream release that is considered latest: 20230528.001 Current version/release in rawhide: 20230516.001-1.fc39 URL: https://metacpan.org/dist/Business-ISBN-Data/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/2674/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Business-ISBN-Data -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2210600 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change
On Sun, May 28, 2023 at 9:43 AM Vitaly Zaitsev via devel wrote: > > On 27/05/2023 14:33, Fabio Valentini wrote: > > It would probably be better if the legal docs made this explicit, and > > made Rust no longer a special case. The fact that only Rust is called > > out is an artifact of this rule having been moved from the Rust > > Packaging Guidelines to the legal docs, but other languages that are in > > similar situations didn't even have guidelines for this case. > > I have the opposite opinion. Even Rust packages should only include to > the License tag libraries bundled into the source tarball. > > All other licenses can be traced, if necessary, from the corresponding > -devel packages. > > If one had to manually track each header-only library in the dependency > tree, check their licenses, and document them in the License tag, that > would add useless extra work to the maintainers. It must be automated. Sure, I don't like the way we need to do this for Rust packages either ... But like it or not, your opinion doesn't really matter if Red Hat Legal says we need to do it this way. At least for Rust packages, we do have some amount of automation now to help with this chore. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Deprecation of the aspell package
Mattia Verga via devel writes: I'd also like to raise attention to what I think is a misleading Change Summary: > Deprecating aspell package because it is no longer > Required/Buildrequired by any package in Fedora. This is clearly not true, as the change is about migrating package to another spellchecker. I have one package in Fedora. It uses aspell's C++ API. Hunspell does not have a functionally-equivalent C++ API. It has a C++ API of its own, but it's targeted at applications that come with their own language dictionaries. Its C++ API is, basically, a lookup function against a dictionary file that the application also supplies, it does not have a C++ API that offers a convenient way for applications to run a spell check against the system's default dictionary. The way for an application to do it is to have it run hunspell itself separately, and talk to it via pipes. Hopefully, it's easy for the application to do that without leaking other file descriptors. I'll have to code that, which I'll do, but I don't know how many other applications currently rely on aspell's C++ API, and whether their upstreams are also willing to update. pgpSbgVnsdHrA.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/bugzilla] PR #3: remove ifdef's for fedora as they don't make any sense
eseyman merged a pull-request against the project: `bugzilla` that you are following. Merged pull-request: `` remove ifdef's for fedora as they don't make any sense `` https://src.fedoraproject.org/rpms/bugzilla/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/bugzilla] PR #3: remove ifdef's for fedora as they don't make any sense
The pull-request: `remove ifdef's for fedora as they don't make any sense` of project: `bugzilla` has been assigned to `eseyman` by eseyman. https://src.fedoraproject.org/rpms/bugzilla/pull-request/3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230528.n.0 changes
OLD: Fedora-Rawhide-20230526.n.0
NEW: Fedora-Rawhide-20230528.n.0
= SUMMARY =
Added images:0
Dropped images: 4
Added packages: 4
Dropped packages:0
Upgraded packages: 216
Downgraded packages: 0
Size of added packages: 10.79 MiB
Size of dropped packages:0 B
Size of upgraded packages: 3.97 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 20.13 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
= DROPPED IMAGES =
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230526.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230526.n.0.s390x.raw.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20230526.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20230526.n.0.s390x.qcow2
= ADDED PACKAGES =
Package: golang-github-pin-tftp-3-3.0.0-1.fc39
Summary: TFTP server and client library for Golang
RPMs:golang-github-pin-tftp-3-devel
Size:32.56 KiB
Package: onnx-1.13.0-3.fc39
Summary: Open standard for machine learning interoperability
RPMs:onnx-devel onnx-libs python3-onnx
Size:5.74 MiB
Package: perl-Carmel-0.1.56-16.fc39
Summary: CPAN Artifact Repository Manager
RPMs:perl-Carmel
Size:51.46 KiB
Package: qt6-qtlocation-6.5.1-1.fc39
Summary: Qt6 - Location Libraries
RPMs:qt6-qtlocation qt6-qtlocation-devel qt6-qtlocation-examples
Size:4.97 MiB
= DROPPED PACKAGES =
= UPGRADED PACKAGES =
Package: NiaAML-GUI-0.1.13-4.fc39
Old package: NiaAML-GUI-0.1.13-3.fc39
Summary: GUI for NiaAML Python package
RPMs: NiaAML-GUI
Size: 90.77 KiB
Size change: -17 B
Package: Pencil2D-0.6.6-22.fc39
Old package: Pencil2D-0.6.6-21.fc39
Summary: Create traditional hand-drawn animation using both bitmap and
vector graphics
RPMs: Pencil2D
Size: 6.33 MiB
Size change: 598 B
Package: R-knitr-1.43-1.fc39
Old package: R-knitr-1.42-1.fc39
Summary: A General-Purpose Package for Dynamic Report Generation in R
RPMs: R-knitr
Size: 1.37 MiB
Size change: 5.40 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 1.43-1
- update to 1.43
Package: R-rgeos-0.6.3-1.fc39
Old package: R-rgeos-0.6.2-2.fc39
Summary: Interface to Geometry Engine - Open Source ('GEOS')
RPMs: R-rgeos
Size: 3.14 MiB
Size change: -5.83 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 0.6.3-1
- update to 0.6-3
Package: R-statnet.common-4.9.0-1.fc39
Old package: R-statnet.common-4.7.0-3.fc39
Summary: Common R Scripts and Utilities Used by the Statnet Project
Software
RPMs: R-statnet.common
Size: 1.38 MiB
Size change: 116.81 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 4.9.0-1
- update to 4.9.0
Package: R-styler-1.10.0-1.fc39
Old package: R-styler-1.9.1-3.fc39
Summary: Non-Invasive Pretty Printing of R Code
RPMs: R-styler
Size: 869.29 KiB
Size change: -13.39 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 1.10.0-1
- update to 1.10.0
Package: R-timeSeries-4030.106-1.fc39
Old package: R-timeSeries-4021.105-1.fc39
Summary: Financial Time Series Objects (Rmetrics)
RPMs: R-timeSeries
Size: 2.17 MiB
Size change: 77.16 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 4030.106-1
- update to 4030.106
Package: R-waldo-0.5.1-1.fc39
Old package: R-waldo-0.4.0-3.fc39
Summary: Find Differences Between R Objects
RPMs: R-waldo
Size: 121.17 KiB
Size change: 2.80 KiB
Changelog:
* Fri May 26 2023 Tom Callaway - 0.5.1-1
- update to 0.5.1
- switch to conditionalized suggests
- disable tests because they keep landing on ppc and failing *sigh*
Package: advancecomp-2.5-5.fc39
Old package: advancecomp-2.5-2.fc39
Summary: Recompression utilities for .png, .mng, .zip and .gz files
RPMs: advancecomp
Size: 685.12 KiB
Size change: 1.26 KiB
Package: agenda-1.1.2-13.fc39
Old package: agenda-1.1.2-11.fc38
Summary: A simple, slick, speedy and no-nonsense task manager
RPMs: agenda
Size: 386.34 KiB
Size change: -2.20 KiB
Package: alizams-1.9.0-1.fc39
Old package: alizams-1.8.3-2.fc38
Summary: Aliza MS DICOM Viewer
RPMs: alizams
Size: 4.29 MiB
Size change: -3.18 KiB
Changelog:
* Fri May 26 2023 Alessio - 1.9.0-1
- Update to version 1.9.0 (rhbz#2210227)
- RPM converted to autorelease and autochangelog
- Side-by-side view in multi-view (study) widget (s. 'Anchor' action)
- Drag-and-drop from list widget to multi-view (study) widget
- Improved support for Dimension Organization of enhanced IODs (s.
'Settings')
- Adjust contours width
- Special LUT for binary and label images (s. 'Labels-4096')
- Option to force Windows-1251
FMN Documentation and UI complaints
Hi folks, The new Fedora Messaging Notifications (FMN) 3.0 has recently been launched. I followed the announcement and the discussion, questions that followed. Yet, I hadn't had time to look into it until now. TL;DR I'm lost. I haven't got a clue how this works, what I need to do, if anything. Documentation isn't helpful. I logged in to FMN today and was greeted with: No Rules Below that is a button "Create a Rule". In the top right above the box is another button "Add a new rule". Are these different buttons with a different purpose? They are labelled differently. There is no explanation anywhere on the site. No inline tutorial or helpful notes. Okay, let's start clicking... Or, maybe, look for some documentation, which I found [1] and read. Yet, I'm as clueless as before. So, some basic things that need to be clarified, preferably in the UI itself and elaborated in the documentation: 1. What happens if no rules are created? 2. Explain terminology (artifacts, tracking rules, generation rules, etc.) 3. Examples, examples, examples Depending on the answer to 1., there will be follow up questions arising, which should be answered and/or examples given. I've given up for now and left it at no rules. So far, I haven't noticed missing certain messages or getting more than usual. [1] https://fmn.readthedocs.io/en/latest/rules.html Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change
On 27/05/2023 14:33, Fabio Valentini wrote: It would probably be better if the legal docs made this explicit, and made Rust no longer a special case. The fact that only Rust is called out is an artifact of this rule having been moved from the Rust Packaging Guidelines to the legal docs, but other languages that are in similar situations didn't even have guidelines for this case. I have the opposite opinion. Even Rust packages should only include to the License tag libraries bundled into the source tarball. All other licenses can be traced, if necessary, from the corresponding -devel packages. If one had to manually track each header-only library in the dependency tree, check their licenses, and document them in the License tag, that would add useless extra work to the maintainers. It must be automated. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete of DNF by DNF5 in RAWHIDE
Il 24/05/23 09:40, Jaroslav Mracek ha scritto: > Hello, > > I have great news that the upcoming release of DNF5 will obsolete DNF > in rawhide (Fedora 39). The release is planned not before the end of > May. The change was already announced in > https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. > > Best regards > > Jaroslav Mracek I've started to see failing tests upon Bodhi update submission like the following: Error: Problem: conflicting requests - nothing provides pkgconfig(lz4;pugixml;zlib) needed by libXISF-devel-0.2.5-1.fc39.x86_64 from brew-101573635 Looks like multiple 'BuildRequires: pkgconfig()' are squashed to a single one and dnf5 can't understand them? Mattia ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
