Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On Sep 27, 2023 aig 11:56:01AM +0200, sgrìobh Miro Hrončok: > Hello packagers, > here is the list of packages that still need a Python 3.12 rebuild for Fedora > 39+. > supervisor in fedora 39 is 4.2.2 but the version that supports python 3.12 is 4.2.5. I filed Bug 2239529 about this and have received no response. The package does not run at all under python 3.12 and if the maintainer will not update it it should probably be orphaned. -- Tapadh leabh, Mairi Dulaney. ___ 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
Dropping python2-xcffib
Hey, y'all. As far as I know, qtile is the only package that depends on python3-xcffib, and nothing depends on the python2- subpackage. Accordingly, I am have dropped the python2-subpackage in Rawhide. -- Dulaney. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Elasticsearch dependency tree trim?
The dependency tree for Elasticsearch is way huge, even bringing in parts of the X stack. Do you reckon folks could work together to trim this a bit? Thanks! -- John. signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
> Date: Wed, 1 Jun 2016 15:48:04 +0200 > From: Lennart Poettering > Subject: Re: systemd 230 change - KillUserProcesses defaults to yes > To: Development discussions related to Fedora > > Message-ID: <20160601134804.GB21606@gardel-login> > Content-Type: text/plain; charset=us-ascii > > On Wed, 01.06.16 12:19, Howard Chu (h...@symas.com) wrote: > > > This is still looking at the problem back-asswards. The problem isn't that > > screen and tmux are special cases. The problem is that some handful of > > programs that got spawned in a GUI desktop environment are special cases, > > not exiting when they should. > > > > Fix the broken programs, don't force every well-behaved program in the > > universe to change to accommodate your broken GUI environment. This is > > Programming 101. > > Again, this isn't just work-arounds around broken programs. It's a > security thing. It's privileged code (logind, PID 1) that enforces a > clear life-cycle on unprivileged programs. > > Any scheme that relies on unprivileged programs "being nice" doesn't > fix the inherent security problem: after logout a user should not be > able consume further runtime resources on the system, regardless if he > does that because of a bug or on purpose. > Sure, having this as an option to be enabled in specific situations is nice, but, it ignores how Linux is admined and used in the real world 90% of the time. If you're going to enable this by default, you enable something that may be needed 10% of the time but break the other 90% of use cases. A sane default does not break the majority use. John. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
You know, it seems to me that systemd doing this to work around a Gnome problem (and a problem I have not seen outside of Gnome), is sort of like glibc working around a bug in Firefox and at the same time breaking bash. We're taking a bug in the Gnome stack and putting a 'fix' in systemd that breaks all sorts of applications. In turn, the 'fix' to those breakages is to add new, systemd specific code. I fail to see how this is even acceptable. I know right off that projects such as Mediagoblin are going to refuse to include such code, and rightfully so. There are distros, such as Void, that exist specifically to avoid systemd. While obviously the systemd developers do not care about such distros, it is really not cool to force dependencies that they would rather avoid on them. Here's an idea. How about Gnome fix their broken crap, and let's not enable this missfeature in systemd? All these problems (including the true, root problem!) go away. Alas, this seems to be too difficult a solution. John. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Takng guile-lib
Hey, y'all I'm taking ownership of guile-lib post-orphaning. Thanks much John. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Large number of packages to be orphaned on Feb 26
I can take lilypond, linode-cli, jwm, mopac7, and mscore John. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
RE: devel Digest, Vol 144, Issue 7
> I'll admit that I'm guilty of this when I craft packages targeting > Fedora. For the most part, it's because I don't have a good reason to > care about the soversion (aside from making sure it exists). When I'm > making packages targeting Mageia or openSUSE, I do actually care about > it, because the library package is supposed to include the soversion > in the name. Fedora's guidelines don't require the soversion to be > part of the package name (which I like), but at the same time, it's a > bit disconcerting that our repository policies and the way Yum/DNF > work do not allow us to take advantage of RPM's capability to parallel > install multiple versions of a package with the same name. Provided > that they don't have file conflicts, I don't see why this isn't > supported in Yum/DNF. I do understand it adds a bit of burden onto > Fedora to maintain a multitude of library package versions, but it's > rather bizarre that Fedora is the only major distribution I know of > that doesn't have a consistent policy on dealing with cases where > multiple versions of the same library package must exist (either > temporarily or permanently). I've seen different conventions used > across the board, which makes things very confusing... > > This is a can of worms I don't even want to think about. Also, Fedora does have such a policy, please read the guidelines for compat packages. John. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
RE: Unannounced soname bump: libpsl
>
> This is the hazard of using %{_libdir}/*.so.* in %files. Is there any
> reason why such a syntax should NOT be formally discouraged in the
> packaging guidelines?
>
It hasn't been actively discouraged, and I have, in fact seen it encouraged
during package reviews.
John..
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unresponsive Maintainer: brouhaha
The maintainer for python-cairocffi has been non-responsive for some time. For example, I opened 1249821 in early August; never received a response; adamw finally did the deed for me. I opened 1273567 in October, and have still not received a single response. 1288627 was opened in early December by someone else, and has not received a response. In October, I requested commit acls to the package so as to resolve these outstanding issues and possibly move things forward in the future. I have not received a response. I opened 1299042 for unresponsive maintainer, and still have not received a response. John. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On running gui applications as root
Recently, I filed a bug (1274451) about running virt-manager on Wayland. As it turns out that this is applicable to running gui applications as root on Wayland in general, the scope was changed (see Cole's comments). As Halfline points out, the decision needs to be made whether to allow gui applications to be run as root. I figured I'd bring this up for discussion in the hopes that a decision may be made whether or not to allow this. In the instance that the decision is made to not allow gui applications root access, then we will also need to figure out a sane way to have applications that require more than the usual set of user priviledges to continue to work across multiple compositors and window managers that may or may not have the necessary authentication agents built-in. John. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RE: remedy for depcheck inferior architecture issue
> Date: Thu, 9 Apr 2015 04:39:59 -0400 > From: kpa...@redhat.com > To: qa-de...@lists.fedoraproject.org > Subject: remedy for depcheck inferior architecture issue > > I see people asking on #fedora-devel or #fedora-admin about depcheck inferior > architecture issue [1] quite often. Most of them are very confused. Last time > I saw someone asking about this was tonight [2]. > > We're not able fix this easily, but I think we should finally at least put > some temporary measures to "work around" this issue and stop confusing people > that much, or least start explaining better what this is and what it means. I > have the following ideas: > > 1. In depcheck, detect if the output has "inferior architecture" substring > and add an explanatory note, like this: > > not ok - depcheck for Bodhi update xforms-1.2.4-2.fc22 # FAIL > --- > arch: x86_64 > details: > output: |- > Build xforms-1.2.4-2.fc22 failed depcheck > package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = > 1.2.4-2.fc22, but none of the providers can be installed > xforms-1.2.4-2.fc22.i686 has inferior architecture > xforms-1.2.4-2.fc22.i686 has inferior architecture > package xforms-devel-1.2.4-2.fc22.i686 requires xforms(x86-32) = > 1.2.4-2.fc22, but none of the providers can be installed > xforms-1.2.4-2.fc22.i686 has inferior architecture > xforms-1.2.4-2.fc22.i686 has inferior architecture > PLEASE NOTE : This failure is most probably invalid, caused by a bug > we weren't able to fix yet: https://phab.qadevel.cloud.fedoraproject.org/T366 > . Please test you package dependencies manually and if everything looks > correct, ignore this error. We're sorry for this inconvenience. > item: xforms-1.2.4-2.fc22 > outcome: FAILED > summary: xforms-1.2.4-2.fc22 into F22 testing > type: bodhi_update > ... > > > 2. Do not submit this result (I'm mostly concerned about Bodhi, but there's > no easy way to disconnect ResultsDB reporting from Bodhi reporting, so it > would affect both systems). That can be done by filtering out "inferior > architecture" CheckDetails at the end of the depcheck run, before the final > TAP is generated. We would print these CheckDetails to stdout instead, so > that the results would still be visible in the log. > > > 3. Alternatively to 2), Josef proposed setting these results to ABORTED > instead of FAILED. They would still show up in ResultsDB, and they would be > easy to search for (we'll need to fix T458, but we'll need to fix that > anyway). I've went through bodhi_comment_directive, and I believe it will > report the ABORTED outcome to Bodhi the same way as any other outcome. I'd > prefer either not to report ABORTED at all, or least not send emails for > them. But either way, saying ABORTED is a bit less confusing than FAILED. And > if we add the explanatory note as suggested in 1), it could be a substantial > improvement. I think I prefer this to 2). > > > What do you think? Any better suggestions? I'm with 3 plus the note from 1. John. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
RE: Proposal for integration tests infrastructure
Some thoughts: >> Where to keep tests? a/ in current dist-git for related components >> (problem with sharing parts of code, problem where to keep tests >> related for more components) b/ in separate git with similar >> functionality as dist-git (needs new infrastructure, components are >> not directly connected with tests, won't make mess in current >> dist-git) c/ in current dist-git but as ordinary components (no new >> infrastructure needed but components are not directly connected >> with tests) >> >> How to deliver tests? a/ just use them directly from git (we need >> to keep some metadata for dependencies anyway) b/ package them as >> RPMs (we can keep metadata there; e.g. Taskotron will run only >> tests that have "Provides: ci-tests(mariadb)" after mariadb is >> built; we also might automate packaging tests to RPMs) To answer both of these, the plan is to keep taskotron tasks in their own git repo; currently this is at (0). To run the tasks, taskotron sets up a disposable task client and then git clones the task to be run. This solves the issue of delivery and allows a continuous integration-like solution. >> Structure for tests? a/ similar to what components use (branches >> for Fedora versions) b/ only one branch Test maintainers should be >> allowed to behave the same as package maintainers do -- one likes >> keeping branches the same and uses "%if %fedora" macros, someone >> else likes specs clean and rather maintain more different branches) >> -- we won't find one structure that would fit all, so allowing both >> ways seems better. This is something we'll need to figure out, but, I suspect git branches will be involved. >> Which framework to use? People have no time to learn new things, so >> we should let them to write the tests in any language and just >> define some conventions how to run them. You'll need to at least define the task in a yaml file, and output will need to be TAP. The example task is at (1). > TAP (Test Anything Protocol) FTW. It really makes sense when you're > trying to combine tests from multiple different languages, testing > frameworks, etc. > > Stef > Indeed, which is why we settled on it. John. (0) https://bitbucket.org/fedoraqa (1) https://bitbucket.org/fedoraqa/task-rpmlint -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Maniphest] [Closed] T20: Use config files to point to repodata locations in depcheck mk 2
jdulaney closed this task as "Resolved". TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T20 To: jdulaney Cc: qa-devel ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[Maniphest] [Commented On] T20: Use config files to point to repodata locations in depcheck mk 2
jdulaney added a comment. Done, pushed to git. TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T20 To: jdulaney Cc: qa-devel ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[Maniphest] [Created] T20: Use config files to point to repodata locations in depcheck mk 2
jdulaney created this task. jdulaney claimed this task. jdulaney added a subscriber: qa-devel. jdulaney added a project: depcheck mk 2 TASK DESCRIPTION Currently, depcheck mk 2 uses essentially hard coded links to repodata; better solution is to put these into a config file. Use yum.repos style so that yum configs can be copied in. TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T20 To: jdulaney Cc: qa-devel ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: RFC: Feature process improvements
I would suggest that we create a clear SOP for fall back planning in case a feature, especially a crit path feature, is not ready for prime time. Obviously, if a feature is not %100 by feature freeze, then it needs to be dropped. I would even venture to suggest that we include in the SOP something along the lines of "If feature is not 80% by point X (X being two weeks prior to freeze), then FESCo should at that point evaluate enacting the fall back." John. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Test Day: USB 3.0
Shiver me timbers! It's time for another Beefy Test Day, Argh! Tomorrow, 13 March, is the USB 3.0 Test Day! https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0 Testing is easy; just use your favourite up-to-date Fedora 17 image (Live or Install); everything is included! The testing will require that you have some sort of USB 3.0 hardware to plug into your box. The Wiki page delves deeper into how and what to test. The maintainers and some of the usual crew will be hanging out in #fedora-test-day and #fedora-qa. Ping anyone in either of those channels if you require assistance. To recap for those of you too busy trying to deliver the pizza before the Ninjas: What: USB 3.0 https://fedoraproject.org/wiki/Test_Day:2012-03-13_USB_3.0 When: All day 03/13 Where: #fedora-test-day Captain John. ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 17 Test Days
Greetings, y’all! This release cycle I am the Test Day Coordinator. That means it is my job to help you, my fellow Fedorians, to set up test days for your packages/projects. We have about two and a half months until Alpha release (1). The sooner I receive test day proposals, the easier my life will be, and we all know that making my life easier is a Good Thing. The test day schedule can be found at https://fedoraproject.org/wiki/QA/Fedora_17_test_days. Proposing a test day is very easy. There is a guide at https://fedoraproject.org/wiki/QA/Test_Days/Create for proposing test days, as well as https://fedoraproject.org/wiki/QA/SOP_Test_Day_management for helping with creating the associated Wiki page and actually running the test day. If you need any help, feel free to email me at jdula...@fedoraproject.org. Thanks much John Dulaney (1) https://fedoraproject.org/wiki/Releases/17/Schedule ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 Test Days
Greetings, y’all! This release cycle I am the Test Day Coordinator. That means it is my job to help you, my fellow Fedorians, to set up test days for your packages/projects. We have about two and a half months until Alpha release (1). The sooner I receive test day proposals, the easier my life will be, and we all know that making my life easier is a Good Thing. The test day schedule can be found at https://fedoraproject.org/wiki/QA/Fedora_17_test_days. Proposing a test day is very easy. There is a guide at https://fedoraproject.org/wiki/QA/Test_Days/Create for proposing test days, as well as https://fedoraproject.org/wiki/QA/SOP_Test_Day_management for helping with creating the associated Wiki page and actually running the test day. If you need any help, feel free to email me at jdula...@fedoraproject.org. Thanks much John Dulaney (1) https://fedoraproject.org/wiki/Releases/17/Schedule -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS: The Good, The Bad and The Ugly
On Wed, Jul 13, 2011 at 10:06 PM, Reindl Harald wrote: > > > Am 14.07.2011 03:57, schrieb Eric Sandeen: >>> bleeeding edge / modern technology is not the same as dangerous defaults >>> unstable / unfinsihed packages should never be default in GA nor replace >>> existing and over a long time well working things - never! >> >> You might have said the same thing about ext4 in F >> and yet, here we are, shipping it as default for many releases now, with >> little trouble. > > ext4 is not written from scratch and it is a hughe difference > if we are speaking from a improvement of ext2/ext3 with many > years history on all sorts of setups (desktop, server, notebook) > > the troubles of lost kde settings was enough on crashes and yes > i had the luck of a system-disk hangig some times exactly as > this was discussed in a way "POSIX do not say what exactly > happens after that, it says only the FS must be clean and > not what data are there or not" > > virtual machines this time are really a normal thing and if > there are hughe troubles now a FS should NOT be DEFAULT in a > few months - why everytime this hurry? jesus one of the biggest > benefits of open source is that there ar eno marketing idiots > with release plans which forcing a release without enough testing > > so why do we not need this benefits and fire out permanently > new technologies in a not understandable hurry? > Dude, what's with always being so negative? All this negative energy almost makes one think that you're using a Microsoft product to compose your emails, and that's just not groovy, man. Fedora doesn't flow with long stable technologies, it embraces the new. And, if you cannot embrace the new with Fedora (whether it be systemd or btrfs) then why not go with something archaic, like CentOS? At least expunge all that negativity, ya know? If you don't like all the new cool in Fedora, don't go say that things are 'being shoved down our throats' like you said about systemd. That's just not happening, man. And, when it comes down to it, you can go join the Cool Cats over at Slackware; Patrick Volkerding is one very, very cool dude. Then again, they might not dig the negatrons that you seem to extrude from every bit of your soul. Peace, brah John. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SYSTEMD: Give us a option for upstart
> Am 13.06.2011 00:04, schrieb John Dulaney: > >> PLEASE give us a option for systems upgraded with yum > >> NOT USING "systemd" and force "upstart" as before > > > > No one is stopping you from packaging upstart (assuming someone hasn't done > > so) for F15. > > it is in the repos > and it is replaced by "systemd" via yum dist-upgrade > this is bullshit and should never happen by an upgrade No, it does happen with upgrade. systemd is supposed to replace upstart whenever an upgrade from F15 is installed. It is explicitly stated that systemd is the default feature, and, as such, it will be installed by default. Therefore, it should happen, and the fact that it does mean that it is working. Essentially, if you do not want systemd, don't use Fedora 15. It is that simple. > >> * the system is running since years > >> * every dist-upgrade via yum was no problem > >> * now see screenshot > >> * WTF is there to relabel if started with "selinux=0"-kernel-param > >> > >> WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE > >> THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER > >> ON UPDATES > > > > No one is forcing you to use F15 > > not today but in some months How so? How is it that in 'some months' you will be forced to use systemd? Are the Chinese going to torture you until you make the switch? Why not go with another distro that does not use systemd, rather than complaining on here and mommicking the rest of us? It really seems that Fedora is not the distribution that fits your application. John Dulaney -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: SYSTEMD: Give us a option for upstart
> PLEASE give us a option for systems upgraded with yum > NOT USING "systemd" and force "upstart" as before No one is stopping you from packaging upstart (assuming someone hasn't done so) for F15. > * the system is running since years > * every dist-upgrade via yum was no problem > * now see screenshot > * WTF is there to relabel if started with "selinux=0"-kernel-param > > WHY IN THE WORLD ARE USERS FORCED TO USE SYSTEMD ONLY BECAUSE > THEY UPGRAD TO F15? DO THIS FOR NEW INSTALLATIONS BUT NEVER > ON UPDATES No one is forcing you to use F15 > I DO NOT NEED SYSTEMD ON 20 SERVERS HERE BECAUSE THEY ARE STARTING > FAST ENOUGH AND I NEED NO MAGIC WHICH THINKS KNOWS WHAT TO START > IN WHICH ORDER SINCE I KNOW WHAT IS RUNNING ON MY SYSTEMS If you're running that many servers, then why are you running Fedora? Considering that Fedora has a stated mission to be the first to introduce new software and that releases are only supported for thirteen months, would it not be wise to go with a distribution that has a) more mature code and b) longer support? John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
It was for me until this morning. Virtual box killed it (beware of vb). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Web frontend for ResultsDB
All, I shall be working on some web frontends for ResultsDB, and I have been told that y'all already have some mock-ups/ideas for such a beast. If so, could y'all point me in the right direction. Thanks John Dulaney -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
