Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days

his 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 unsu

Re: Retire unused nose plugins?

On Gibl 21, 2020 aig 05:47:17f +0200, sgrìobh Miro Hrončok: > On 21. 04. 20 17:41, Mairi Dulaney wrote: > > On Gibl 21, 2020 aig 12:55:05f +0200, sgrìobh Miro Hrončok: > > > Hello. > > > > > > Given https://fedoraproject.org/wiki/Changes/DeprecateNose woul

Re: Retire unused nose plugins?

shows no dependencies in Rawhide. -- Tapadh leabh, Mairi Dulaney. ___ 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.fed

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

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 --

Re: Tackling cert bundling with install-time symlink maps?

On Fri, Dec 23, 2016 at 05:37:51PM +1000, Nick Coghlan wrote: > I filed that idea on the pip issue tracker at > https://github.com/pypa/pip/issues/4197 but figured I should raise it here > as well, as if something like this was added, then Fedora could be updated > to use a standard symlink map

Re: What to do with fedora-qa (fedorahosted is dying)

On Fri, Sep 09, 2016 at 05:51:55PM -0700, Adam Williamson wrote: > We still have a few miscellaneous things hosted in: > > https://git.fedorahosted.org/cgit/fedora-qa.git > > since fedorahosted is dying next February, what should we do with them? > Is this the point where we should finally

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:

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

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

[EPEL-devel] Re: Owncloud updates

> Date: Tue, 15 Mar 2016 08:18:36 + > From: james.hoga...@gmail.com > To: epel-devel@lists.fedoraproject.org > Subject: [EPEL-devel] Owncloud updates > > > Hi all, > > A situation has come up similar to the nginx one. > > Owncloud 7.0 has reached

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: Testcase namespacing - adding structure to result reporting

On Mon, 8 Feb 2016 06:54:17 -0500 (EST) Josef Skladanka wrote: > > == Namespace structure == > > We'll be providing some top-level namespaces (list not yet final): > * app > * fedoraqa > * package > * scratch (?) > > These will the further split to facilitate

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,

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

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

[EPEL-devel] Re: Improving EPEL updates process

> Date: Sun, 13 Dec 2015 02:34:33 + > From: pbrobin...@gmail.com > To: epel-devel@lists.fedoraproject.org > Subject: [EPEL-devel] Improving EPEL updates process > > Hi All, > > So one thing I noticed when doing the ppc64le bootstrap is that > there's a

[EPEL-devel]Re: python2-setuptools metapackage

> > Would it be easier to request the RHEL packages to add a virtual > Provides for the python2-* name? That is, python-setuptools in RHEL > could provide python2-setuptools. > Probably. https://bugzilla.redhat.com/show_bug.cgi?id=1284754 John.

[EPEL-devel]python2-setuptools metapackage

Since Fedora is now requiring python2 packages have a buildrequires of python2-setuptools, I put together a quick metapackage(0)(1) that in turn requires python-setuptools.  This will make packaging for Fedora and epel to be somewhat easier. What are your thoughts on this, and should we include

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

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

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

[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

[Maniphest] [Created] T40: Make depcheck mk2 a taskotron runnable task

jdulaney created this task. jdulaney claimed this task. jdulaney added subscribers: jdulaney, qa-devel. jdulaney added a project: depcheck mk 2 TASK DESCRIPTION Task to be completed once depcheck scenarios are all passed; TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T40 To:

[Maniphest] [Changed CC] T12: Create comprehensive functional tests for package level checks

jdulaney added a subscriber: jdulaney. TASK DETAIL https://phab.qadevel.cloud.fedoraproject.org/T12 To: jdulaney Cc: qa-devel, tflink, jdulaney ___ qa-devel mailing list qa-devel@lists.fedoraproject.org

[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

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

[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

Fedora 17 Test Days

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

Re: [Test-Announce] Fedora 17 Test Days

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

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

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

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

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