The following packages showed up on the orphan list (for being FTBFS).
We use and should take these over:
pam_url python-robosignatory reg
Any objections to having infra-sig take them? (I couldn't figure out how to do this in the pagure web interface tho)
Then at least we need folks to fix them so they build.
kevin
Il 09/04/20 02:50, Kevin Fenzi ha scritto:
The following packages showed up on the orphan list (for being FTBFS).
We use and should take these over:
pam_url python-robosignatory reg
Any objections to having infra-sig take them? (I couldn't figure out how to do this in the pagure web interface tho)
Then at least we need folks to fix them so they build.
kevin _______________________________________________
I'd taken pam_url and robosignatory and added infra-sig group as admin to both.
I already had fixed python-robosignatory (currently built in rawhide, rebuilding in f32), but I don't have time today to look to pam_url... I will do tomorrow, if someone doesn't anticipate me.
I haven't found package "reg" in pagure...
Mattia
On Thu, Apr 09, 2020 at 04:54:37PM +0000, Mattia Verga wrote:
Il 09/04/20 18:49, Mattia Verga ha scritto:
I haven't found package "reg" in pagure...
Ah, I see "docker-reg" has been obsoleted by docker-distribution...
It's this one:
https://src.fedoraproject.org/rpms/reg
And many thanks for dealing with this. ;)
kevin
Il 09/04/20 20:48, Kevin Fenzi ha scritto:
It's this one:
https://src.fedoraproject.org/rpms/reg
And many thanks for dealing with this. ;)
kevin
Oh, ok... for some reasons, searching "reg" in pagure didn't show that result.
About pam_url, the spec file points the sources to https://fedorahosted.org/pam_url which doesn't exist anymore. I assume we can use https://github.com/mricon/pam_url ? But there's no release there and master branch has been recently updated (last release was 0.3.3 seven years ago...). Should I package a git snapshot?
mattia
On Fri, Apr 10, 2020 at 06:16:00AM +0000, Mattia Verga wrote:
Il 09/04/20 20:48, Kevin Fenzi ha scritto:
It's this one:
https://src.fedoraproject.org/rpms/reg
And many thanks for dealing with this. ;)
kevin
Oh, ok... for some reasons, searching "reg" in pagure didn't show that result.
huh. ok.
About pam_url, the spec file points the sources to https://fedorahosted.org/pam_url which doesn't exist anymore. I assume we can use https://github.com/mricon/pam_url ? But there's no release there and master branch has been recently updated (last release was 0.3.3 seven years ago...). Should I package a git snapshot?
Yeah, I suppose that would be best...
we only will still need this until we move off fas2.
kevin
Il 13/04/20 01:06, Kevin Fenzi ha scritto:
About pam_url, the spec file points the sources to https://fedorahosted.org/pam_url which doesn't exist anymore. I assume we can use https://github.com/mricon/pam_url ? But there's no release there and master branch has been recently updated (last release was 0.3.3 seven years ago...). Should I package a git snapshot?
Yeah, I suppose that would be best...
we only will still need this until we move off fas2.
kevin _______________________________________________
I finally managed to have it fixed, I've rebuilt an updated pam_url snapshot in Rawhide only, let me know if you need it in F32 also. I had to enable _legacy_common_support because it seems it's incompatible with GCC10, I've filed a bug upstream, but I think it will hardly be fixed (upstream seems unmaintained).
Now the only package that still needs to be fixed is reg.
Mattia
On Mon, Apr 13, 2020 at 02:46:56PM +0000, Mattia Verga wrote:
Il 13/04/20 01:06, Kevin Fenzi ha scritto:
About pam_url, the spec file points the sources to https://fedorahosted.org/pam_url which doesn't exist anymore. I assume we can use https://github.com/mricon/pam_url ? But there's no release there and master branch has been recently updated (last release was 0.3.3 seven years ago...). Should I package a git snapshot?
Yeah, I suppose that would be best...
we only will still need this until we move off fas2.
kevin _______________________________________________
I finally managed to have it fixed, I've rebuilt an updated pam_url snapshot in Rawhide only, let me know if you need it in F32 also. I had
Rawhide is probibly ok for now.
to enable _legacy_common_support because it seems it's incompatible with GCC10, I've filed a bug upstream, but I think it will hardly be fixed (upstream seems unmaintained).
Yeah. ;(
Now the only package that still needs to be fixed is reg.
We may need the go sig help there... I tried, but it bundles so much stuff that it's hard to package. ;(
kevin
Il 15/04/20 00:57, Kevin Fenzi ha scritto:
Now the only package that still needs to be fixed is reg.
We may need the go sig help there... I tried, but it bundles so much stuff that it's hard to package. ;(
Thanks to Go sig [1] I've fixed reg build... for the moment. The version packaged is outdated and reg probably needs to be completely repackaged and renamed to follow current packaging guidelines.
However, I'm totally unfamiliar with Go stuff and I don't understand how bundles work, so if no one with golang skills is willing to take care of it, you should consider to switch services using it to some other more easily maintainable alternative.
Mattia
On Thu, Apr 23, 2020 at 07:23:09AM +0000, Mattia Verga wrote:
Il 15/04/20 00:57, Kevin Fenzi ha scritto:
Now the only package that still needs to be fixed is reg.
We may need the go sig help there... I tried, but it bundles so much stuff that it's hard to package. ;(
Thanks to Go sig [1] I've fixed reg build... for the moment. The version packaged is outdated and reg probably needs to be completely repackaged and renamed to follow current packaging guidelines.
Thanks for fixing it!
However, I'm totally unfamiliar with Go stuff and I don't understand how bundles work, so if no one with golang skills is willing to take care of it, you should consider to switch services using it to some other more easily maintainable alternative.
Alas, there's not such a thing that I know of. ;(
I guess the hope is that we can move our stuff to quay.io and retire our registry at some point.
kevin
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Mattia Verga