Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Thu, Apr 30, 2020 at 7:34 PM Kevin Fenzi wrote: > > On Thu, Apr 30, 2020 at 01:58:43PM +0200, Fabio Valentini wrote: > > On Mon, Apr 20, 2020 at 1:45 PM Fabio Valentini > > wrote: > > > > > > Hi everybody, > > > > > > I took over python-lockfile some time ago because it was FTBFS in > > > fedora / orphaned at the time, but it's a dependency of some of my > > > packages. > > > > > > However, I have zero interest in maintaining the EPEL branches of that > > > package, because I have no packages in EPEL myself, and it seems I > > > can't even figure out how to determine which EPEL packages require > > > python*-lockfile. > > > > So, with the help from Miro and Neal, I've determined the dependent > > packages: > > > > EPEL7: > > - python(2)-lockfile: atomicapp, bugwarrior, duplicity, pungi, > > python-daemon, python-fedora > > > > EPEL8: > > - python(2)-lockfile: pungi-legacy, python2-pungi > > - python3-lockfile: duplicity, python-fedora > > > > I've now CCd the maintaniers of those packages since I don't want to > > break them by retiring the EPEL8 branches of lockfile. > > If you maintain one of those packages and need python-lockfile on > > EPEL, please step forward and I'll add you as comaintainer. > > I don't really want to, but I'll take it for python-fedora and pungi > (although we should really switch to python3 for pungi, at least in > epel8) > > So, go ahead and add me and I can look at the PR's (possibly this > weekend if not sooner). > > kevin Great, thank you! I've added you to python-lockfile with admin access. 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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Thu, Apr 30, 2020 at 01:58:43PM +0200, Fabio Valentini wrote: > On Mon, Apr 20, 2020 at 1:45 PM Fabio Valentini wrote: > > > > Hi everybody, > > > > I took over python-lockfile some time ago because it was FTBFS in > > fedora / orphaned at the time, but it's a dependency of some of my > > packages. > > > > However, I have zero interest in maintaining the EPEL branches of that > > package, because I have no packages in EPEL myself, and it seems I > > can't even figure out how to determine which EPEL packages require > > python*-lockfile. > > So, with the help from Miro and Neal, I've determined the dependent packages: > > EPEL7: > - python(2)-lockfile: atomicapp, bugwarrior, duplicity, pungi, > python-daemon, python-fedora > > EPEL8: > - python(2)-lockfile: pungi-legacy, python2-pungi > - python3-lockfile: duplicity, python-fedora > > I've now CCd the maintaniers of those packages since I don't want to > break them by retiring the EPEL8 branches of lockfile. > If you maintain one of those packages and need python-lockfile on > EPEL, please step forward and I'll add you as comaintainer. I don't really want to, but I'll take it for python-fedora and pungi (although we should really switch to python3 for pungi, at least in epel8) So, go ahead and add me and I can look at the PR's (possibly this weekend if not sooner). kevin 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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Mon, Apr 20, 2020 at 1:45 PM Fabio Valentini wrote: > > Hi everybody, > > I took over python-lockfile some time ago because it was FTBFS in > fedora / orphaned at the time, but it's a dependency of some of my > packages. > > However, I have zero interest in maintaining the EPEL branches of that > package, because I have no packages in EPEL myself, and it seems I > can't even figure out how to determine which EPEL packages require > python*-lockfile. So, with the help from Miro and Neal, I've determined the dependent packages: EPEL7: - python(2)-lockfile: atomicapp, bugwarrior, duplicity, pungi, python-daemon, python-fedora EPEL8: - python(2)-lockfile: pungi-legacy, python2-pungi - python3-lockfile: duplicity, python-fedora I've now CCd the maintaniers of those packages since I don't want to break them by retiring the EPEL8 branches of lockfile. If you maintain one of those packages and need python-lockfile on EPEL, please step forward and I'll add you as comaintainer. Fabio > I have received two PRs for the epel7 branch already, and I don't even > know if they're fine or not, so any help would be appreciated. > > If nobody steps up within the next two weeks, I will probably retire > the epel7 and epel8 branches of python-lockfile. > > 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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally
> enable
> them with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>
I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery
It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...
--
真実はいつも一つ！/ Always, there's only one truth!
___
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
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally
> enable
> them with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>
I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery
It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...
--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally
> enable
> them with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>
I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery
It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...
--
真実はいつも一つ！/ 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
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 13:45, Fabio Valentini wrote:
and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.
Take the attached repo files.
They are good for repoquery, adapted from epel-release.
They don't have -testing repos, but -testingx, so you don't accidentally enable
them with dnf --enablerepo=\*-testing.
Usage:
$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-testingx]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel7-testingx-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel8]
name=Extra Packages for Enterprise Linux 8 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-8=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-testingx]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel8=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-source]
name=Extra Packages for Enterprise Linux 8 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-8=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
[epel8-testingx-source]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel8=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 13:45, Fabio Valentini wrote:
and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.
Take the attached repo files.
They are good for repoquery, adapted from epel-release.
They don't have -testing repos, but -testingx, so you don't accidentally enable
them with dnf --enablerepo=\*-testing.
Usage:
$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-testingx]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel7-testingx-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel8]
name=Extra Packages for Enterprise Linux 8 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-8=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-testingx]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel8=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-source]
name=Extra Packages for Enterprise Linux 8 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-8=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
[epel8-testingx-source]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel8=$basearch=$infra=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
___
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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 15:24, Troy Dawson wrote:
On a RHEL8 machine, doing a
dnf repoquery --whatrequires python3-lockfile
dnf repoquery --whatrequires python2-lockfile
Shows that the following depend on it
duplicity
python3-fedora
pungi-legacy
I haven't checked EPEL7 yet.
$ repoquery --repo=epel7{,-source} --whatrequires python3-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python2-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python-lockfile
atomicapp-0:0.6.3-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.src
duplicity-0:0.7.19-1.el7.x86_64
pungi-0:3.12-3.el7.1.noarch
python-daemon-0:1.6-4.el7.noarch
python-daemon-0:1.6-4.el7.src
python-fedora-0:0.10.0-1.el7.src
python2-fedora-0:0.10.0-1.el7.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 15:24, Troy Dawson wrote:
On a RHEL8 machine, doing a
dnf repoquery --whatrequires python3-lockfile
dnf repoquery --whatrequires python2-lockfile
Shows that the following depend on it
duplicity
python3-fedora
pungi-legacy
I haven't checked EPEL7 yet.
$ repoquery --repo=epel7{,-source} --whatrequires python3-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python2-lockfile
(nada)
$ repoquery --repo=epel7{,-source} --whatrequires python-lockfile
atomicapp-0:0.6.3-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.noarch
bugwarrior-0:1.4.0-1.el7.src
duplicity-0:0.7.19-1.el7.x86_64
pungi-0:3.12-3.el7.1.noarch
python-daemon-0:1.6-4.el7.noarch
python-daemon-0:1.6-4.el7.src
python-fedora-0:0.10.0-1.el7.src
python2-fedora-0:0.10.0-1.el7.noarch
--
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
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On a RHEL8 machine, doing a dnf repoquery --whatrequires python3-lockfile dnf repoquery --whatrequires python2-lockfile Shows that the following depend on it duplicity python3-fedora pungi-legacy I haven't checked EPEL7 yet. On Mon, Apr 20, 2020 at 4:46 AM Fabio Valentini wrote: > > Hi everybody, > > I took over python-lockfile some time ago because it was FTBFS in > fedora / orphaned at the time, but it's a dependency of some of my > packages. > > However, I have zero interest in maintaining the EPEL branches of that > package, because I have no packages in EPEL myself, and it seems I > can't even figure out how to determine which EPEL packages require > python*-lockfile. > > I have received two PRs for the epel7 branch already, and I don't even > know if they're fine or not, so any help would be appreciated. > > If nobody steps up within the next two weeks, I will probably retire > the epel7 and epel8 branches of python-lockfile. > > 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 ___ 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
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On a RHEL8 machine, doing a dnf repoquery --whatrequires python3-lockfile dnf repoquery --whatrequires python2-lockfile Shows that the following depend on it duplicity python3-fedora pungi-legacy I haven't checked EPEL7 yet. On Mon, Apr 20, 2020 at 4:46 AM Fabio Valentini wrote: > > Hi everybody, > > I took over python-lockfile some time ago because it was FTBFS in > fedora / orphaned at the time, but it's a dependency of some of my > packages. > > However, I have zero interest in maintaining the EPEL branches of that > package, because I have no packages in EPEL myself, and it seems I > can't even figure out how to determine which EPEL packages require > python*-lockfile. > > I have received two PRs for the epel7 branch already, and I don't even > know if they're fine or not, so any help would be appreciated. > > If nobody steps up within the next two weeks, I will probably retire > the epel7 and epel8 branches of python-lockfile. > > Fabio > ___ > devel mailing list -- de...@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/de...@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Co-Maintainers wanted for python-lockfile EPEL branches
Hi everybody, I took over python-lockfile some time ago because it was FTBFS in fedora / orphaned at the time, but it's a dependency of some of my packages. However, I have zero interest in maintaining the EPEL branches of that package, because I have no packages in EPEL myself, and it seems I can't even figure out how to determine which EPEL packages require python*-lockfile. I have received two PRs for the epel7 branch already, and I don't even know if they're fine or not, so any help would be appreciated. If nobody steps up within the next two weeks, I will probably retire the epel7 and epel8 branches of python-lockfile. 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
Re: Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)
Hey Alain, I've been trying to help with pantheon de on Fedora as well.Nice to know someone who has experience with vala /gtk helping , I've started to learn Vala but wil take some time to get to a stage where I can help with the apps themselves. Looking forward to working together . Thanks for helping, Harsh On Wed, Feb 12, 2020 at 11:29 PM Alain Vigne wrote: > Hello Fabio > > I am not very active, and not a software engineer, but Vala/GTK > applications are kind of my hobby, and I had the opportunity to take a look > at elementary applications (code wise too). > You are maintaining much more packages I can ever pretend to maintain, so > this will be a little help. > But I am ready to lend a hand, if I can get some guidance, milestones, and > if we can work together... ? > > I am CET time zone based. Do you work from the USA ? > > My FAS is: avigne. > Keep me posted. > BR, Alain > > > On Fri, Jan 31, 2020 at 9:30 PM Fabio Valentini > wrote: > >> Hi everybody, >> >> With more responsibilities (FPC, Stewardship SIG, FESCo) and the >> ever-growing number of packages I maintain, I don't have as much time >> for the things I originally started my contributions to fedora with - >> the Pantheon desktop and the accompanying elementary applications. >> >> What makes things worse is that I am not particularly proficient with >> Vala or C/GObject, other than including upstream patches or doing >> simple backports. That means some issues are punted until upstream >> projects get around to fixing them (and if these issues are only >> affecting "third-party" distros like fedora, that can take a while). >> >> Also, the fact that GNOME frequently (almost with every new major >> stable release, which means with almost every fedora release) breaks >> something - either subtly or not - does not help. >> gnome-settings-daemon changes its DBus interfaces almost every >> release. mutter makes sweeping API changes almost every release. Both >> gala and the elementary LightDM greeter can't keep up with upstream >> mutter, and are basically still stuck on mutter 3.28 support (which is >> why there is a mutter328 compat package) ... >> >> Overall, this results in the quality of all these packages not being >> as high as I would like it to be (though it's still pretty good, all >> things considered). In particular, there are some components that are >> more "crashy" than the rest, and I don't have the time and skill to >> get deep into debugging the issue in most cases: >> >> - wingpanel (the panel for Pantheon); issues in individual indicators >> also crash the whole app because they are just dlopen()ed >> - switchboard (the settings application); issues in individual >> settings panels also crash the whole app because they are just >> dlopen()ed >> - gala (the window manager): obviously bad if the WM crashes, though >> not as bad because it's still an Xorg session >> - plank (the dock); also optionally used on XFCE (I think) >> - sequeler (third-party SQL client developed for Pantheon) >> >> I would greatly appreciate if somebody who knows their GObject-fu >> could help me out here. >> >> The elementaryOS upstream developers are usually helpful and accept >> patches - even for things that are not a problem on elementaryOS, so >> long as they can be switched on/off with e.g. conditional compilation. >> But reported issues - that only affect fedora - without attached >> patches / PRs are obviously low priority for them, and often sit >> untouched for months or years. >> >> In general, I manage to keep the packages for Pantheon / elementary >> projects up-to-date. Having set up "nightly" builds on COPR a few >> years ago really helps to catch potential issues early. >> >> If anybody is interested, here are some pointers: >> >> - all packages are tracked in koschei, in the decathorpe/elementary group: >> https://koschei.fedoraproject.org/groups/decathorpe/elementary >> >> - nightly builds are done on COPR: >> https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/ >> >> Thanks, >> 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 >> > > > -- > Alain V. > ___ > 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 >
Re: Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)
Hello Fabio I am not very active, and not a software engineer, but Vala/GTK applications are kind of my hobby, and I had the opportunity to take a look at elementary applications (code wise too). You are maintaining much more packages I can ever pretend to maintain, so this will be a little help. But I am ready to lend a hand, if I can get some guidance, milestones, and if we can work together... ? I am CET time zone based. Do you work from the USA ? My FAS is: avigne. Keep me posted. BR, Alain On Fri, Jan 31, 2020 at 9:30 PM Fabio Valentini wrote: > Hi everybody, > > With more responsibilities (FPC, Stewardship SIG, FESCo) and the > ever-growing number of packages I maintain, I don't have as much time > for the things I originally started my contributions to fedora with - > the Pantheon desktop and the accompanying elementary applications. > > What makes things worse is that I am not particularly proficient with > Vala or C/GObject, other than including upstream patches or doing > simple backports. That means some issues are punted until upstream > projects get around to fixing them (and if these issues are only > affecting "third-party" distros like fedora, that can take a while). > > Also, the fact that GNOME frequently (almost with every new major > stable release, which means with almost every fedora release) breaks > something - either subtly or not - does not help. > gnome-settings-daemon changes its DBus interfaces almost every > release. mutter makes sweeping API changes almost every release. Both > gala and the elementary LightDM greeter can't keep up with upstream > mutter, and are basically still stuck on mutter 3.28 support (which is > why there is a mutter328 compat package) ... > > Overall, this results in the quality of all these packages not being > as high as I would like it to be (though it's still pretty good, all > things considered). In particular, there are some components that are > more "crashy" than the rest, and I don't have the time and skill to > get deep into debugging the issue in most cases: > > - wingpanel (the panel for Pantheon); issues in individual indicators > also crash the whole app because they are just dlopen()ed > - switchboard (the settings application); issues in individual > settings panels also crash the whole app because they are just > dlopen()ed > - gala (the window manager): obviously bad if the WM crashes, though > not as bad because it's still an Xorg session > - plank (the dock); also optionally used on XFCE (I think) > - sequeler (third-party SQL client developed for Pantheon) > > I would greatly appreciate if somebody who knows their GObject-fu > could help me out here. > > The elementaryOS upstream developers are usually helpful and accept > patches - even for things that are not a problem on elementaryOS, so > long as they can be switched on/off with e.g. conditional compilation. > But reported issues - that only affect fedora - without attached > patches / PRs are obviously low priority for them, and often sit > untouched for months or years. > > In general, I manage to keep the packages for Pantheon / elementary > projects up-to-date. Having set up "nightly" builds on COPR a few > years ago really helps to catch potential issues early. > > If anybody is interested, here are some pointers: > > - all packages are tracked in koschei, in the decathorpe/elementary group: > https://koschei.fedoraproject.org/groups/decathorpe/elementary > > - nightly builds are done on COPR: > https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/ > > Thanks, > 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 > -- Alain V. ___ 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
Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)
Hi everybody, With more responsibilities (FPC, Stewardship SIG, FESCo) and the ever-growing number of packages I maintain, I don't have as much time for the things I originally started my contributions to fedora with - the Pantheon desktop and the accompanying elementary applications. What makes things worse is that I am not particularly proficient with Vala or C/GObject, other than including upstream patches or doing simple backports. That means some issues are punted until upstream projects get around to fixing them (and if these issues are only affecting "third-party" distros like fedora, that can take a while). Also, the fact that GNOME frequently (almost with every new major stable release, which means with almost every fedora release) breaks something - either subtly or not - does not help. gnome-settings-daemon changes its DBus interfaces almost every release. mutter makes sweeping API changes almost every release. Both gala and the elementary LightDM greeter can't keep up with upstream mutter, and are basically still stuck on mutter 3.28 support (which is why there is a mutter328 compat package) ... Overall, this results in the quality of all these packages not being as high as I would like it to be (though it's still pretty good, all things considered). In particular, there are some components that are more "crashy" than the rest, and I don't have the time and skill to get deep into debugging the issue in most cases: - wingpanel (the panel for Pantheon); issues in individual indicators also crash the whole app because they are just dlopen()ed - switchboard (the settings application); issues in individual settings panels also crash the whole app because they are just dlopen()ed - gala (the window manager): obviously bad if the WM crashes, though not as bad because it's still an Xorg session - plank (the dock); also optionally used on XFCE (I think) - sequeler (third-party SQL client developed for Pantheon) I would greatly appreciate if somebody who knows their GObject-fu could help me out here. The elementaryOS upstream developers are usually helpful and accept patches - even for things that are not a problem on elementaryOS, so long as they can be switched on/off with e.g. conditional compilation. But reported issues - that only affect fedora - without attached patches / PRs are obviously low priority for them, and often sit untouched for months or years. In general, I manage to keep the packages for Pantheon / elementary projects up-to-date. Having set up "nightly" builds on COPR a few years ago really helps to catch potential issues early. If anybody is interested, here are some pointers: - all packages are tracked in koschei, in the decathorpe/elementary group: https://koschei.fedoraproject.org/groups/decathorpe/elementary - nightly builds are done on COPR: https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/ Thanks, 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
Co-maintainers wanted
Hi all, I need co-maintainers for my packages.. Primarily for the i3 desktop family. Version 4.0.1 is out. My Packages: https://admin.fedoraproject.org/pkgdb/users/packages/cassmodiah i3: http://www.i3wm.org -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://fedoraproject.org/wiki/User:Cassmodiah 2.6.38.2-9.fc15.i686 Today is Boomtime, the 71st day of Confusion in the YOLD 3177 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Co-maintainers wanted
On Fri, Aug 05, 2011 at 19:08:24 GMT, Simon Wesp wrote: I need co-maintainers for my packages.. Primarily for the i3 desktop family. Version 4.0.1 is out. My Packages: https://admin.fedoraproject.org/pkgdb/users/packages/cassmodiah I use dmenu pretty heavily. Applied for comaintainership. -- Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Co-maintainers wanted
This looks like a very interesting project mate. I'm very interested in becoming a co-maintainer. ;-) *Cheers, Chris Jones** * * * “Oh, so they have internet on computers now?” — Homer Simpson * * Signature powered by http://r1.wisestamp.com/r/landing?promo=4dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_4 WiseStamphttp://r1.wisestamp.com/r/landing?promo=4dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Co-maintainers wanted
Ok Sent from my iPad On Aug 5, 2011, at 3:08 PM, Simon Wesp cassmod...@fedoraproject.org wrote: Hi all, I need co-maintainers for my packages.. Primarily for the i3 desktop family. Version 4.0.1 is out. My Packages: https://admin.fedoraproject.org/pkgdb/users/packages/cassmodiah i3: http://www.i3wm.org -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://fedoraproject.org/wiki/User:Cassmodiah 2.6.38.2-9.fc15.i686 Today is Boomtime, the 71st day of Confusion in the YOLD 3177 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
