Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)
Jens-Ulrik Petersen skrev: > Do you want to try adding native compilation your package? As it turns out, emacs-vm might not be the best package for this experiment. I could not get VM to work with native compilation. Instead, I had to turn the native compilation off completely for all vm*.el files before I could get emacs-vm usable again. My guess is that it is related to (some of) the warnings issued during compilation. It will be a significant work to get it up to date with the pretty dormant upstreams. It is thus not a good candidate as a guinea pig for bundling native-compiled eln files in add-on packages. ___ 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
https://packages.fedoraproject.org Re: Check out the Fedora Packager Dashboard!
Hi, Also https://packages.fedoraproject.org/ is new On Thu, 2022-08-25 at 10:32 +0200, Miro Hrončok wrote: > Hello folks, > > this is just a reminder that there is a Fedora Packager Dashboard > that you > might not know about: > > Go to https://packager-dashboard.fedoraproject.org/ > > Enter your FAS username, (sit down and relax for a while if coming > for the > first time) and enjoy aggregated information about your Fedora and > EPEL > packages from: > > - Bugzilla > - Bodhi > - ABRT > - Koschei > - src.fedoraproject.org PRs > - orphans reports > - non-installability reports > - Fedora release schedule > - Package calendars (currently GNOME and Python, but extensible) > - and possibly more in the future > > With various filtering options. > > Also works for FAS groups or custom views of multiple users that can > be used > for triages, e.g.: > > https://packager-dashboard.fedoraproject.org/dashboard?users=churchyard,pviktori,cstratak,torsava,lbalhar,thrnciar,ksurma,vstinner > > See the help page for more: > > https://packager-dashboard.fedoraproject.org/helpmepls > > -- > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: GTK 2 removal from RHEL 10+
On Sat, 2022-08-27 at 01:44 +0200, Kevin Kofler via devel wrote: > Tomáš Popela wrote: > > This is an early heads-up about GTK 2 removal from RHEL 10+ (the > > gtk2 > > package was marked as unwanted in ELN with > > https://github.com/minimization/content-resolver-input/commit/b6d44e496f46bd2444e8e24dd3e9113b326817ac > > ). > > I suppose it could be carried in EPEL if needed. Or is somebody > attempting > to veto that too? > Finally I got this idea , we should have the *archived packages group*, that can be excluded from mass rebuild and gcc and python updates etc . The rest of the idea is instead force the retirement of the package we move it to the archive group , and by default archive group is not used , but if any one need a library to run an obsoleted applications he can . As Kevin Kofler (more or less) wrote in "Pcre Deprecation" thread, maybe we should be prepared to support pcre-1 forever and IMO we also can extend the concept to other packages, btw GTK2 is one of them . Checking on rawhide gtk2 still have 385 packages that depend on gtk2 ... -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
ansible-collection-community-mysql License Change
Hi Fedorians, The license of ansible-collection-community-mysql has been updated from "GPLv3+ and Python" to "GPL-3.0-or-later AND PSF-2.0 AND BSD-2-Clause". See https://src.fedoraproject.org/rpms/ansible-collection-community-mysql/c/242bcaa709334c0a5ec0d78d1a2da3daaae532ce?branch=rawhide. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Check out the Fedora Packager Dashboard!
Zbigniew Jędrzejewski-Szmek wrote: > I think it > is important to remember that the page is _supposed_ to be "dense". > It is intended to pack a lot of information into a small area It leaves plenty of empty space on my screen. It seems to prioritize aesthetics over information density. Björn Persson pgppvLZZS0iXx.pgp Description: OpenPGP digital signatur ___ 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: hardened memory allocate port to linux-fedora system for secutiry
On 8/26/22 12:22, Daniel Micay via devel wrote: > Also, you hardened_malloc doesn't use a thread cache for security > reasons. It invalidates many of the security properties. If you compare > to glibc malloc in the light configuration with tcache disabled in glibc > malloc it will compare well, and hardened_malloc can scale better when > given enough arenas. If you want to make the substantial security > sacrifices required for a traditional thread cache, then I don't think > hardened_malloc makes sense, which is why it doesn't include the option > to do thread caching even though it'd be easy to implement. It may one > day include the option to do thread batched allocation, but it isn't > feasible to do it for deallocation without losing a ton of the strong > security properties. I'm an upstream glibc developer, but I've tried to remove my bias here and present the facts as they are for the existing heap-based allocator that is in use by the distributions today and why it's hard to change. (1) Pick your own allocator vs. use the default. We allow any end user to make those choices by interposing the final allocator with an allocator of their choice depending on specific workload criteria. This means that distributions don't have a strong incentive to change system allocators unless they are making a strategic change in their core values or vision for the distribution (like Graphene OS makes for security). At the ELF level we make sure that we can interpose a new allocator, and we work carefully to ensure that newer features at the compiler level can be supported incrementally (_FORTIFIY_SOURCE=3 and __builtin_dynamic_object_size) by newer allocators. In summary: If the "good enough" allocator doesn't meet your requirements, then you can use one of the alternatives. (2) Switching the default vs. improving the default. It is arguably lower TCO for all distributions using glibc to improve glibc's malloc. Some improvements can't be made, but some buy enough benefit that there is no strong reason to change allocators. For example: - jemalloc/tcmalloc used a fast per-thread cache. - glibc implemented fast per-thread caching in 2.26 (2017) (DJ Delorie's work) - Chromium started using safe-linking pointer hardening. - glibc implemented safe-linking pointer hardening for fastbins and tcache (2020) (Eyal Itkin's work) Next steps for glibc's malloc is probably: - Improve internal fragmentation [1] - Round-robin arena assignment with uniform arena assignment as a goal. - Provide a packed arena for sub 16-byte sized allocations to improve utilization. - We have seen some C++ workloads/frameworks that create trillions of 13-byte objects. (3) Requirements vs. change. While Facebook/BSD (jemalloc), Google (tcmalloc), Microsoft (mimalloc) have very good allocators, issues seen with those allocators can be more difficult to correct because of the impact those changes have on wider workloads beyond distribution workloads. For example if Graphene OS, with it's own goals, and Fedora with it's own goals had a conflict of interest for the direction of the allocator e.g. cost vs. security, what kind of choice would the hardened_allocator maintainers make? Upstream glibc has largely been aligned with traditional distribution requirements for a long time, and continues to be aligned with the notion of a "general purpose" distribution via the contributors and deep network of developers in the distributions: https://sourceware.org/glibc/wiki/MAINTAINERS#Distribution_Maintainers --- The combination of (1), (2) and (3) mean that for general purpose distributions the choice of staying with glibc's malloc means having an ecosystem of distributions that are using the same allocator and benefit from wide application testing and development and support when required. It would be easier to approach glibc upstream and convince them that the default allocator in glibc should be replaced with hardened_alloc or jemalloc or tcmalloc or mimalloc... -- Cheers, Carlos. [1] https://patchwork.sourceware.org/project/glibc/patch/xn4jz19fts@greed.delorie.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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 37 compose report: 20220827.n.0 changes
OLD: Fedora-37-20220826.n.0 NEW: Fedora-37-20220827.n.0 = SUMMARY = Added images:2 Dropped images: 5 Added packages: 1 Dropped packages:0 Upgraded packages: 4 Downgraded packages: 0 Size of added packages: 1013.73 KiB Size of dropped packages:0 B Size of upgraded packages: 415.51 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 205.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-37-20220827.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-37-20220827.n.0.iso = DROPPED IMAGES = Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-37-20220826.n.0.x86_64.vagrant-libvirt.box Image: SoaS raw-xz aarch64 Path: Spins/aarch64/images/Fedora-SoaS-37-20220826.n.0.aarch64.raw.xz Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-37-20220826.n.0.aarch64.raw.xz Image: Scientific vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-37-20220826.n.0.x86_64.vagrant-virtualbox.box Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-37-20220826.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: libshumate-1.0.0~alpha.1-6.20220818git7808f24.fc37 Summary: GTK widget to display maps RPMs:libshumate libshumate-devel libshumate-doc Size:1013.73 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: fedora-obsolete-packages-37-5 Old package: fedora-obsolete-packages-37-4 Summary: A package to obsolete retired packages RPMs: fedora-obsolete-packages Size: 24.90 KiB Size change: 1.56 KiB Changelog: * Wed Aug 24 2022 Tom Hrn??iar - 37-5 - Update the list of obsoleted Python 3.10 packages, second batch Package: firefox-104.0-5.fc37 Old package: firefox-104.0-3.fc37 Summary: Mozilla Firefox Web browser RPMs: firefox firefox-langpacks firefox-wayland firefox-x11 Size: 412.19 MiB Size change: 205.74 MiB Changelog: * Tue Aug 23 2022 Jan Horak - 104.0-4 - Rebuild due to ppc64le fixes * Tue Aug 23 2022 Kalev Lember - 104.0-5 - Use constrain_build macro to simplify parallel make handling - Drop obsolete build conditionals - Drop unused patches - Use build_ldflags - Drop hardened_build option - Re-enable s390x builds Package: gnome-maps-43~beta-2.fc37 Old package: gnome-maps-43~alpha-3.fc37 Summary: Map application for GNOME RPMs: gnome-maps Size: 3.16 MiB Size change: -5.44 KiB Changelog: * Tue Aug 23 2022 Kalev Lember - 43~beta-1 - Update to 43.beta * Tue Aug 23 2022 Kalev Lember - 43~beta-2 - Add missing dep on libsoup3 Package: litecli-1.9.0-1.fc37 Old package: litecli-1.8.0-1.fc37 Summary: CLI for SQLite databases RPMs: litecli python3-litecli Size: 136.94 KiB Size change: 39.19 KiB Changelog: * Thu Jun 16 2022 Python Maint - 1.8.0-2 - Rebuilt for Python 3.11 * Thu Jul 21 2022 Fedora Release Engineering - 1.8.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Fri Aug 19 2022 Fabian Affolter - 1.9.0-1 - Update to latest upstream release 1.9.0 (closes #2094169, closes #2098742) = DOWNGRADED PACKAGES =___ 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: Heads-up: abseil-cpp 20220623.0 and grpc 1.48.0 coming to Rawhide and F37
This is done now. I have created the Bodhi updates for F38/Rawhide and F37/Branched. Thanks for everyone’s help in completing the necessary rebuilds! F38: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2eed8152f6 F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-014e78ee9d On 8/15/22 01:15, Ben Beasley wrote: In one week, on 2022-08-21, I plan to update abseil-cpp to 20220623.0[1] and grpc to 1.48.0[2] in Rawhide and F37. Both updates contain .so version bumps; for grpc, both the C and the C++ .so versions have changed. Because I want to merge the side tag for these packages in time for the 2022-08-23 F37 beta freeze, I plan to start doing builds in side tags a couple of days before the announced 2022-08-21 update date. I am in the process of verifying compatibility of dependent packages using local mock builds on x86_64; COPR is currently broken due to RPM signature issues related to F37 branching. In the unlikely event I find a regression I cannot trivially fix, I will delay one or both updates and will leave the PR’s unmerged. The following packages will need to be rebuilt into side tags for F38/Rawhide and F37. - bear (abseil-cpp, grpc) - bloaty (abseil-cpp) - fastnetmon (abseil-cpp, grpc) - fcitx5-mozc (abseil-cpp) - frr (abseil-cpp, grpc) - ilbc (abseil-cpp) - libarrow (grpc) - mozc (abseil-cpp) - perl-grpc-xs (grpc) Maintainers of affected packages should have received this email directly. I will rebuild bear and libarrow as a co-maintainer. Maintainers of other affected packages should expect an email when the side tags are ready. If you maintain one of the affected packages and you want me to handle these rebuilds in the future, you can add me (FAS music) to the project with “commit” privileges. [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/8 [2] https://src.fedoraproject.org/rpms/grpc/pull-request/14 ___ 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: Check out the Fedora Packager Dashboard!
On Fri, Aug 26, 2022 at 06:21:23PM +0200, Björn Persson wrote: > Fabio Valentini wrote: > > On Thu, Aug 25, 2022 at 11:43 AM Artur Frenszek-Iwicki > > wrote: > > > I'll forget the meaning and the numbers will go back to being visual > > > clutter. It would be immensely helpful > > > to have some symbolic icons next to the numbers, which would allow to > > > easily guess what each of them means. > > > > Sounds like you need to clear your browser cache or something, because > > there *are* symbols next to these numbers: > > https://decathorpe.fedorapeople.org/packager-dashboard.png > > I too can see the icons when I allow fontawesome.com, but few of them > help with understanding the numbers. The beetle for "bugs" and the > speech bubble for "comments" are pretty obvious, but I still have to > point to all the others to find out what they mean, and even then many > of them seem completely random. How does a lightning bolt symbolize > updates? What's the connection between a shield and priority? A > triangle, a circle and a square combine into "overrides"? There are two > different line chart icons. How does one remember which is which? And a > seatbelt apparently means "orphans" somehow. Hi Björn, I'll reply to your mail, but it's something that I wanted to express also in reply to some previous replies in this thread… It's valid to critique individual details of design, but I think it is important to remember that the page is _supposed_ to be "dense". It is intended to pack a lot of information into a small area, and it is also _intended_ to be used by a narrow group people over and over and over. I think a lot of the critisism that numbers are only shown with symbolic icons and that abbreviations are used, etc, applies the first few times one uses the page, and after a while one remembers what is what. And the page does have tooltips and help with that first few times. If anything, I expect that _more_ information will be packed into the page over time. > I assume that "PRs" stands for "pull requests". The icon for that is > the word "git". That's better than a random unrelated picture, but if a > picture is just text, then it should be actual text and not a picture. > It's also somewhat inaccurate because pull requests aren't a Git thing > but a concept that some web interfaces layer on top of Git. Strictly speaking, the concept of pull requests predate the web frontends. E-mail pull requests were part of the original way people used git… > Rather than hiding the intelligible words in mouseover boxes, it would > be better to write them directly on the screen instead of the icons. If > there is some idea that the icons should be language-independent, then > the beetle also fails. Software defects are not called insects in all > languages. > > > > Similarly, at the top of the page, I get a banner that informs me about > > > FAS integration and says: > > > > After linking the dashboard with your FAS through the settings menu... > > > Which is all nice and dandy, but doing a Ctrl+F on the page for > > > "settings" gives exactly one match - > > > that being the text in the banner. So there's no visible link to said > > > "settings menu" anywhere. > > > How do I access it? > > > > The big "gear" icon (the almost universal symbol for "Settings") in > > the top panel should be what you're looking for. > > The gear is called "Options", and beside it is an icon called > "Customize dashboard". "Settings" could refer to either of those. It > would be nice to have consistent terminology, but hey, we can always > click on everything and explore. > > The gear icon is also misleading. It alludes to machinery in motion, so > it suggests a menu of commands to do things, rather than options or > settings. There is a wrench icon that would be a good symbol for > settings, but that apparently means Koschei. Yeah, the split between 'search' and 'Options' is not very clear. Maybe it'd make sense to change the gear icon to an eye icon, because there aren't settings there, but mostly switches to turn things on and off in the view. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20220827.n.0 changes
OLD: Fedora-Rawhide-20220826.n.0 NEW: Fedora-Rawhide-20220827.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 40 Dropped packages:0 Upgraded packages: 240 Downgraded packages: 1 Size of added packages: 242.90 MiB Size of dropped packages:0 B Size of upgraded packages: 3.31 GiB Size of downgraded packages: 624.66 KiB Size change of upgraded packages: 22.79 MiB Size change of downgraded packages: -13.56 KiB = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20220826.n.0.s390x.tar.xz = ADDED PACKAGES = Package: cinfo-0.4.8-1.fc38 Summary: Fast and minimal system information tool RPMs:cinfo Size:124.08 KiB Package: fts-rest-client-3.12.0-1.fc38 Summary: File Transfer Service (FTS) -- Python3 Client and CLI RPMs:fts-rest-client Size:94.92 KiB Package: galera-26.4.11-2.module_f38+15004+97703afd Summary: Synchronous multi-master wsrep provider (replication engine) RPMs:galera Size:4.37 MiB Package: kseexpr-4.0.4.0-1.fc38 Summary: The embeddable expression engine fork for Krita RPMs:kseexpr kseexpr-devel Size:2.02 MiB Package: mariadb-3:10.8.3-1.module_f38+15004+97703afd Summary: A very fast and robust SQL database server RPMs:mariadb mariadb-backup mariadb-common mariadb-connect-engine mariadb-cracklib-password-check mariadb-devel mariadb-embedded mariadb-embedded-devel mariadb-errmsg mariadb-gssapi-server mariadb-oqgraph-engine mariadb-pam mariadb-rocksdb-engine mariadb-s3-engine mariadb-server mariadb-server-galera mariadb-server-utils mariadb-sphinx-engine mariadb-test Size:231.28 MiB Package: perl-App-cpanminus-1.7045-1.module_f38+15314+7f10ee5a Summary: Get, unpack, build and install CPAN modules RPMs:perl-App-cpanminus Size:172.30 KiB Package: perl-CPAN-Meta-Check-0.014-18.module_f38+15314+7f10ee5a Summary: Verify requirements in a CPAN::Meta object RPMs:perl-CPAN-Meta-Check Size:40.44 KiB Package: perl-Clone-0.45-9.module_f38+15291+3f9fe644 Summary: Recursively copy perl data types RPMs:perl-Clone Size:88.64 KiB Package: perl-Data-Dump-1.25-5.module_f38+15291+3f9fe644 Summary: Pretty printing of data structures RPMs:perl-Data-Dump Size:33.59 KiB Package: perl-Date-Manip-6.86-1.module_f38+15305+a606e09c Summary: Date manipulation routines RPMs:perl-Date-Manip Size:2.04 MiB Package: perl-Digest-HMAC-1.04-6.module_f38+15291+3f9fe644 Summary: Keyed-Hashing for Message Authentication RPMs:perl-Digest-HMAC perl-Digest-HMAC-tests Size:35.62 KiB Package: perl-Encode-Locale-1.05-24.module_f38+15291+3f9fe644 Summary: Determine the locale encoding RPMs:perl-Encode-Locale Size:18.92 KiB Package: perl-File-Listing-6.15-3.module_f38+15291+3f9fe644 Summary: Parse directory listing RPMs:perl-File-Listing perl-File-Listing-tests Size:58.55 KiB Package: perl-File-pushd-1.016-12.module_f38+15314+810389bf Summary: Change directory temporarily for a limited scope RPMs:perl-File-pushd Size:47.02 KiB Package: perl-HTML-Parser-3.78-3.module_f38+15291+3f9fe644 Summary: Perl module for parsing HTML RPMs:perl-HTML-Parser Size:482.20 KiB Package: perl-HTML-Tagset-3.20-52.module_f38+15291+3f9fe644 Summary: HTML::Tagset - data tables useful in parsing HTML RPMs:perl-HTML-Tagset Size:18.62 KiB Package: perl-HTTP-Cookies-6.10-7.module_f38+15291+3f9fe644 Summary: HTTP cookie jars RPMs:perl-HTTP-Cookies Size:37.72 KiB Package: perl-HTTP-Date-6.05-10.module_f38+15291+3f9fe644 Summary: Date conversion routines RPMs:perl-HTTP-Date Size:23.95 KiB Package: perl-HTTP-Message-6.37-1.module_f38+15291+3f9fe644 Summary: HTTP style message RPMs:perl-HTTP-Message Size:97.32 KiB Package: perl-HTTP-Negotiate-6.01-33.module_f38+15291+3f9fe644 Summary: Choose a variant to serve RPMs:perl-HTTP-Negotiate Size:19.78 KiB Package: perl-IO-Compress-Brotli-0.004001-6.module_f38+15291+3f9fe644 Summary: Perl bindings for Brotli compression RPMs:perl-IO-Compress-Brotli Size:108.21 KiB Package: perl-IO-HTML-1.004-7.module_f38+15291+3f9fe644 Summary: Open an HTML file with automatic character set detection RPMs:perl-IO-HTML Size:27.93 KiB Package: perl-IO-stringy-2.113-10.module_f38+15322+92594bc1 Summary: I/O on in-core objects like strings and arrays for Perl RPMs:perl-IO-stringy Size:128.04 KiB Package: perl-LWP-MediaTypes-6.04-12.module_f38+15291+3f9fe644 Summary: Guess media type for a file or a URL RPMs:perl-LWP-MediaTypes Size:33.16 KiB Package: perl-LWP-Protocol-https-6.10-7.module_f38+15291+3f9fe644 Summary: Provide HTTPS support for LWP::UserAgent RPMs:perl-LWP-Protocol-https Size:21.30 KiB Package: perl-Module-CPANfile-1.1004-12.module_f38+15314+7f10ee5a Summary: Parse cpanfile RPMs:perl-Module-CPANfile Size:80.18 KiB Package: perl-Mozilla-CA-20211001
Re: Check out the Fedora Packager Dashboard!
Miro Hrončok kirjoitti 25.8.2022 klo 11.32: Hello folks, this is just a reminder that there is a Fedora Packager Dashboard that you might not know about: Go to https://packager-dashboard.fedoraproject.org/ I agree with others, this is a great and very useful service. In attempt to make it better known, I just proposed it to be linked from the Package Maintainer Docs: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/85 If anybody knows more useful services that are not visible those docs, please let me know so we can add those, too. ___ 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: Confused about what to do about a ticket
Jarek Prokop kirjoitti 26.8.2022 klo 17.50: Hi, Usually for Rawhide updates CLOSED RAWHIDE + add NVR into `fixed in version` if only Rawhide fixes that bug (e.g., a new software version), that should be enough. But it seems auto updates can take care of the tickets if you specify the bugs via the `Resolves: rhbz#1234` references as noted by Vít. A webpage… Depends what you plan on doing, I use this if I am unsure in the bug status workflow: https://docs.fedoraproject.org/en-US/package-maintainers/bug_status/ Regarding how updates work in different branches, see Package Update Guide [1]. Rawhide is covered in section "Rawhide and early Branched". [1]: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/ ___ 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: percona-xtrabackup bundling the kitchen sink in static libs
Sven Lankes kirjoitti 26.8.2022 klo 0.03: Non-responsive maintainer policy [2]. This package has CVE bugs open [3], There was _one_ CVE bug and that was for the old version of xtrabackup that is not shipped for fedora. I have just closed that bug. The other CVEs are for EPEL builds - while I am in theory interested in fixing epel as well I won't touch it until the fedora branch is in a better state. Thank you for correcting me, and for updating bug statuses. I apologize for not checking on those bugs more closely before writing here. I had to go back and check how I ended up pasting a link that contains EPEL bugs as well. The reason: If you click on package's "Bugs" link at Fedora Packages site, you get bugs for Fedora only. If you click "Bug Reports" at Fedora Package Sources, you get bug for Fedora *and* EPEL. I must have used the latter this time. ___ 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: Users with commit rights in src.fp.o but no more in packager group
Il 26/08/22 19:00, Kevin Fenzi ha scritto: > On Wed, Aug 24, 2022 at 05:30:35PM +, Mattia Verga via devel wrote: >> ... >> >> With the exclusion of *-team, *-sig and *-maint, I think packaging >> rights should be removed from those users. > I think these are users who manually removed themselves from the > packager group, but didn't remove all their acls first. (and legit > groups/sigs). Is it possible for users to remove themselves from the packager group? I've looked into fedora accounts interface, but I didn't found how. >> Also, as per my comment linked above, I think there should be some check >> to prevent users removed from packager group to maintain commit rights. >> No idea where/how to implement that. > I don't think it happens too often. We could make a script that checks > it from time to time tho. Might be a good cadidate for a toddler ( > https://pagure.io/toddlers) I'll try to write one. I suppose we just want to be notified of a list of users, rather than automatically remove users permissions? > > In the mean time I agree we should remove the non team/sig/maint users > above. > Should I file a ticket to releng? Or to fedora-infra? 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
