Re: Proven to be sickened
On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto wrote: > Maybe we should have a flag in the src.fp.o package for the maintainer > to request a PR before committing to have a window for review, or like > me, the maintainer would like to not be bothered with things that > proven package can do by itself . > > Another thing is some proven packager which wants force the move to > autothings , which I don't like use it, ATM, because in my opinion > still have many problems . I think there is a difference between changes that have a formal change proposal (I am thinking something like removing make from the buildroot, which required many packages to add a BR: make, and for which PP's did a lot of the work for some packages), for which packagers were given a sufficient period of time to make the change on their own, and "philosophical"/"syntactical sugar" changes, such as the current "autothings", for which there is not an approved change for all packages (FD: I would object to making the "autothings" mandatory). If a proven packager changes the syntactical sugar without agreement by the current packager via a PR they have exceeded their mandate, and should be (first) asked to revert and formally apologize, and if they repeat such, removed from the PP list (fool me once, shame on you, fool me twice shame on me). FTBFS issues are, admittedly, complicated, but such updates SHOULD be via a PR. If a PP wants to claim they cannot follow that process, they need to demonstrate that a particular packager is not responsive (there is a process for that) rather then just deciding themselves it is too much trouble. -- ___ 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
Self Introduction: Rafel Amer
Hi, my name is Rafel Amer and I'm professor at the Technical University of Catalonia https:/www.upc.edu. I teach Maths and I use sagemath for my classes. After the sagemath package is orphandend, I would like to be a maintainer or co-maintainer this package. I have successfully build sagemath 10.1 packages for Fedora 38 in x86_64 and aarch64 architectures, so I think that I could maintain this package. I started using Linux in 1995 with Slackware and I have administered server with Debian and CentOS. At house and for my classes I use Fedora 28. Regards, Rafel Amer -- ___ 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: Proven to be sickened
On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote: > On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer > wrote: > > Asking individual maintainers for trivial changes does not scale. > > The > > alternative would be not to address FTBFS and other build issues, > > maybe > > file bugs, and rely on active maintainers instead. > > The alternative we want to achieve is: > (1) write useful commit messages, so the reasons and goal of the > proven package's commit would be clear > and > (2) give the maintainers the possibility to react. E.g. with a PR. > No one responded to the PR in a week? Force merge it with proven > packager rights. > TL;DR; Maybe we should have a flag in the src.fp.o package for the maintainer to request a PR before committing to have a window for review, or like me, the maintainer would like to not be bothered with things that proven package can do by itself . Another thing is some proven packager which wants force the move to autothings , which I don't like use it, ATM, because in my opinion still have many problems . > Even though I would want a longer time window and multiple iterations > of trying to contact the maintainer, > putting the PR up just for a week would make the current situation > considerably better than it is. > > I would expect the maintainers to only react on PRs in three general > ways: > (1) asking for more information = likely means you haven't explained > the commit or the problem well > that marks problem on your side > (2) rejecting the PR for a good reason = likely means there's a > problem with the implementation of your solution. > that marks problem on your side > (3) coming up with an alternative solution = likely means you haven't > thought of package specific approaches > You might find out the packager has a better idea how to solve the > problem in general. > Or you just collaborated nicely. > > Each way leads to a valuable end, I believe. > > There may be more ways to react (e.g. not react at all), but for now > let's assume they are not significant, as you'd end up anyway using > the proven packagers rights to force merge. > > Michal > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > > On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer > wrote: > > > > * Kevin Kofler via devel: > > > > > Michael J Gruber wrote: > > > > I am sick of this. Really. I am so sick of this way of stomping > > > > on each > > > > others' feet. > > > > > > My pet peeve is provenpackagers or comaintainers who add unwanted > > > automagic (autorelease, autosetup, autochangelog) to my packages. > > > I do > > > not want any of that in my packages, it just makes my work harder > > > (or > > > in practice, just wastes my time for the revert that I am > > > inevitably > > > going to do). > > > > If the package does not contain any patches yet, it's not really > > possible to infer the maintainer intentions. %setup vs %autosetup > > doesn't matter much in that case, so it doesn't really tell us > > anything. > > Likewise if the package uses %autosetup, but without -p1, and there > > are > > no patches. Does the maintainer really prefer those awkarward -p- > > less > > patches? We don't know. > > > > Asking individual maintainers for trivial changes does not scale. > > The > > alternative would be not to address FTBFS and other build issues, > > maybe > > file bugs, and rely on active maintainers instead. But I don't > > think > > that can work for Fedora, practically speaking. Fedora lacks > > Debian's > > ban on forcing packagers to do certain work. In the past, FESCo > > has > > used that to order that certain packagers must keep carrying out > > certain > > work they do not want to do, but I think that only means anything > > if the > > victim packager is a Red Hatter on certain teams, I think. Others > > will > > just quit if they disagree. > > > > Thanks, > > Florian > > -- > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > 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-infrast
Re: Change of cronie and crontabs CIS compliance
On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote: > The main effect of the permissions change on these files is that non-root > users can't see any env variables set against the commands scheduled to run. > The actual command lines are still all visible in the proces listing when > the command runs. I think this part alone is worthwhile in a general distro like Fedora, irrespective of any CIS requirements. Env vars can contain secret data and they are no longer readble by all users in process lists, so changing permissions on cron files fixes a real potential information leak. Also, it is hard to keep file and directory permissions changed from how they are packaged. The files will become exposed during package updates until some other script comes by and fixes them again. So it is worthwhile to fix this in the packaging. I agree that the correct middle ground is to fix the permissions, but leave the other parts about cron.allow/cron.deny alone. -- ___ 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: 20231210.n.0 changes
OLD: Fedora-Rawhide-20231209.n.0 NEW: Fedora-Rawhide-20231210.n.0 = SUMMARY = Added images:0 Dropped images: 4 Added packages: 1 Dropped packages:0 Upgraded packages: 112 Downgraded packages: 0 Size of added packages: 588.45 KiB Size of dropped packages:0 B Size of upgraded packages: 16.00 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.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-20231209.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231209.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231209.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231209.n.0.iso = ADDED PACKAGES = Package: ptl-2.3.3-1.20230707gitf892a93.fc40 Summary: Lightweight C++11 mutilthreading tasking system RPMs:ptl ptl-devel Size:588.45 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: bandit-1.7.6-1.fc40 Old package: bandit-1.7.5-4.fc39 Summary: A framework for performing security analysis of Python source code RPMs: bandit Size: 306.24 KiB Size change: 1.70 KiB Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - 1.7.6-1 - Update to 1.7.6 - Closes rhbz#2253734 Package: bodhi-client-8.0.0-1.fc40 Old package: bodhi-client-7.2.2-1.fc40 Summary: Bodhi client RPMs: bodhi-client Size: 89.71 KiB Size change: 401 B Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: bodhi-messages-8.0.0-1.fc40 Old package: bodhi-messages-7.2.2-1.fc40 Summary: JSON schema for messages sent by Bodhi RPMs: python3-bodhi-messages Size: 50.39 KiB Size change: 1.02 KiB Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: bodhi-server-8.0.0-1.fc40 Old package: bodhi-server-7.2.2-1.fc40 Summary: Bodhi server RPMs: bodhi-composer bodhi-server Size: 4.62 MiB Size change: -139.27 KiB Changelog: * Sat Dec 09 2023 Mattia Verga - 8.0.0-1 - Update to 8.0.0 Package: doctl-1.101.0-2.fc40 Old package: doctl-1.100.0-1.fc40 Summary: The official command line interface for the DigitalOcean API RPMs: doctl golang-github-digitalocean-doctl-devel Size: 25.39 MiB Size change: 63.84 KiB Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - Update to 1.101.0 - Closes rhbz#2253730 rhbz#2248265 Package: gnome-control-center-45.2-1.fc40 Old package: gnome-control-center-45.1-2.fc40 Summary: Utilities to configure the GNOME desktop RPMs: gnome-control-center gnome-control-center-filesystem Size: 26.90 MiB Size change: -26.44 KiB Changelog: * Sat Dec 09 2023 Kalev Lember - 45.2-1 - Update to 45.2 Package: golang-github-digitalocean-godo-1.107.0-1.fc40 Old package: golang-github-digitalocean-godo-1.105.0-1.fc40 Summary: DigitalOcean Go API client RPMs: golang-github-digitalocean-godo-devel Size: 173.43 KiB Size change: -824 B Changelog: * Sat Dec 09 2023 Mikel Olasagasti Uranga - 1.107.0-1 - Update to 1.107.0 - Closes rhbz#2248648 Package: guacamole-server-1.5.4-1.fc40 Old package: guacamole-server-1.5.3-1.fc39 Summary: Server-side native components that form the Guacamole proxy RPMs: guacd libguac libguac-client-kubernetes libguac-client-rdp libguac-client-ssh libguac-client-telnet libguac-client-vnc libguac-devel Size: 3.89 MiB Size change: 130.48 KiB Changelog: * Sat Dec 09 2023 Robert Scheck - 1.5.4-1 - Update to 1.5.4 (#2223510) Package: guestfs-tools-1.51.6-2.fc40 Old package: guestfs-tools-1.51.5-2.fc40 Summary: Tools to access and modify virtual machine disk images RPMs: guestfs-tools guestfs-tools-bash-completion guestfs-tools-man-pages-ja guestfs-tools-man-pages-uk virt-win-reg Size: 18.19 MiB Size change: -30.01 KiB Changelog: * Sat Dec 09 2023 Richard W.M. Jones - 1.51.6-2 - New development version 1.51.6 Package: java-1.8.0-openjdk-1:1.8.0.392.b08-5.fc40 Old package: java-1.8.0-openjdk-1:1.8.0.392.b08-4.fc40 Summary: OpenJDK 8 Runtime Environment RPMs: java-1.8.0-openjdk java-1.8.0-openjdk-demo java-1.8.0-openjdk-demo-fastdebug java-1.8.0-openjdk-demo-slowdebug java-1.8.0-openjdk-devel java-1.8.0-openjdk-devel-fastdebug java-1.8.0-openjdk-devel-slowdebug java-1.8.0-openjdk-fastdebug java-1.8.0-openjdk-headless java-1.8.0-openjdk-headless-fastdebug java-1.8.0-openjdk-headless-slowdebug java-1.8.0-openjdk-javadoc java-1.8.0-openjdk-javadoc-zip java-1.8.0-openjdk-openjfx java-1.8.0-openjdk-openjfx-devel java-1.8.0-openjdk-openjfx
Re: Change of cronie and crontabs CIS compliance
Generally, CIS Benchmarks are only prescriptive and getting near/total
compliance with the benchmark is mainly for those who have host
fleets under some SCAP compliance regime. Nonetheless, picking on the low
hanging fruit such as cron compliance isn't going to drastically improve
the security posture of the host, you still need to follow through with all
the other recommendations in the benchmark.
Also worth noting is that the CIS Benchmarks evolve along the latest
security practices/thinking and are subject to constant change, which may
not sit comfortably with a typical OS release whose selling point is ease
of providing more functionality, features and flexibility.
Hardening an OS usually has its place as a service finalisation activity
i.e. it occurs well after installation, and the CIS Benchmarks remain a
useful tool for doing this.
On Thu, 7 Dec 2023 at 00:21, Ondrej Pohorelsky wrote:
>
>
> On Wed, Dec 6, 2023 at 1:19 PM Daniel P. Berrangé
> wrote:
>
>> On Wed, Dec 06, 2023 at 11:16:44AM +0100, Ondrej Pohorelsky wrote:
>> > Hi everyone,
>> >
>> > For F40 I would like to change file permissions of few files that are
>> > provided by cronie and crontabs and swap deny list for allow list. I'm
>> not
>> > really sure if I should make a change proposal. I figured I'll send an
>> > email first and see the feedback.
>> >
>> > The driving force of this change is feedback from RHEL customers, that
>> they
>> > would like to have cronie and crontabs CIS compliant out of the box.
>> Which
>> > means changing some of the file permissions and swapping `cron.deny` for
>> > `cron.allow`. As it stands now, they have to run their own scripts or
>> dnf
>> > plugin (post-transaction-actions) to ensure that each update doesn't
>> > overwrite the file permissions they manually set.
>>
>> This CIS compliance problem is not something that is limited to cron.
>> Their
>> list of hardening steps covers a wide variety of software. IOW, even if
>> cron
>> were changed, presuambly such customers will need need their own scripts /
>> dnf plugin to fix all the other apps listed in the CIS compliance guide.
>>
>> IOW, I feel like the real question here is whether the distro *as a
>> whole*,
>> not cron, wants/needs to be CIS compliant out of the box, or whether it
>> should be explicitly an admin deployment task to enable compliance via a
>> plugin / script.
>>
>>
> I'm doing this only in the scope of cronie and crontabs. Basically
> reacting on a few customers tickets that would welcome this change,
> which I wouldn't like to introduce downstream.
>
> On a distro level, this really doesn't make sense. Especially for Fedora.
> For RHEL? Maybe, I don't know. I'm definitely not the right person
> to answer this question.
>
> > `cron.d` permission change (755 → 700)
>> > `cron.hourly` permission change (755 → 700)
>> >
>> > *crontabs* changes:
>> > `crontab` permission change (644 → 600)
>> > `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)
>>
>> The main effect of the permissions change on these files is that non-root
>> users can't see any env variables set against the commands scheduled to
>> run.
>> The actual command lines are still all visible in the proces listing when
>> the command runs.
>>
>>
>
> Which I think shouldn't be a problem if we don't use cron.allow default,
> as I wrote in my previous mail.
>
> --
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat
>
> opoho...@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, 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
[Test-Announce] 2023-12-11 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2023-12-11 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org Greetings testers! It's time for the last QA meeting of the year! We're going to try moving back to Fedora Chat (Matrix) for this meeting, as the bot should be working there now. Remember, the IRC bridge is out of commission, so you'll really have to be on Matrix to join the meeting. You can log in with your Fedora account. 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 40 check-in 3. Communications overhaul: Discourse and Matrix? 4. Test Day / community event status 5. 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
