Greetings!
The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it.
This means it has about 7 months before we need to do something about it, or shut it off.
Do we know if it can run on RHEL 7?
On Thu, 24 Oct 2019 at 18:07, Randy Barlow bowlofeggs@fedoraproject.org wrote:
Greetings!
The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it.
This means it has about 7 months before we need to do something about it, or shut it off.
Do we know if it can run on RHEL 7?
The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets ( http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial.
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
On Thu, Oct 24, 2019 at 2:13 PM Clement Verna cverna@fedoraproject.org wrote:
On Thu, 24 Oct 2019 at 18:07, Randy Barlow bowlofeggs@fedoraproject.org wrote:
Greetings!
The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it.
This means it has about 7 months before we need to do something about it, or shut it off.
Do we know if it can run on RHEL 7?
The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets (http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial.
There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng
This version looks like it'll be Python 3 compatible, though it is quite new.
On Thu, 2019-10-24 at 14:33 -0400, Neal Gompa wrote:
There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng
This version looks like it'll be Python 3 compatible, though it is quite new.
We can keep it in mind, thanks for sharing!
Dne 25. 10. 19 v 20:44 Randy Barlow napsal(a):
There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng
This version looks like it'll be Python 3 compatible, though it is quite new.
We can keep it in mind, thanks for sharing!
Yes. Give me few additional week. I should finish it before end of December. It should be drop-in replacement then.
On Wed, Nov 20, 2019 at 09:15:40AM +0100, Miroslav Suchý wrote:
Dne 25. 10. 19 v 20:44 Randy Barlow napsal(a):
There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng
This version looks like it'll be Python 3 compatible, though it is quite new.
We can keep it in mind, thanks for sharing!
Yes. Give me few additional week. I should finish it before end of December. It should be drop-in replacement then.
Thats excellent news!
I hope we can run it in openshift?
kevin
On Fri, Nov 22, 2019 at 10:15:43AM +0100, Miroslav Suchý wrote:
Dne 21. 11. 19 v 23:54 Kevin Fenzi napsal(a):
I hope we can run it in openshift?
Yes. No problem with that.
Hey, any news on this? I guess the problem is as always time.
How far along is it? Could we run a demo/dev version in communishift?
kevin
Dne 28. 03. 20 v 1:09 Kevin Fenzi napsal(a):
Hey, any news on this? I guess the problem is as always time.
How far along is it? Could we run a demo/dev version in communishift?
Yes. Time :( I have this as huge debt. I will try to prepare something.
But still I have "just" the page which shows the package detail. @clement how is the search code doing? I said you will migrate that part.
On Mon, 30 Mar 2020 at 14:00, Miroslav Suchý msuchy@redhat.com wrote:
Dne 28. 03. 20 v 1:09 Kevin Fenzi napsal(a):
Hey, any news on this? I guess the problem is as always time.
How far along is it? Could we run a demo/dev version in communishift?
Yes. Time :( I have this as huge debt. I will try to prepare something.
But still I have "just" the page which shows the package detail. @clement how is the search code doing? I said you will migrate that part.
Yeah I did not have time to look at this, a while back I started fedora-search [0] to look at using Postgresql full text search capabilities but that seemed quite slow compared to what we have with Xapian. One possible quick way forward would be to extract the code that does the indexing and search from the current packages app and give it as simple search endpoint. While I honestly don't think I will be able to lead that effort, if anyone is interested in working on this I ll be more than happy to help with getting started.
[0] - https://github.com/fedora-infra/fedora-search
-- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
Hi,
Jumping in since I saw this at the top of the web list archive. This service is very convenient and I think it would be fairly painful for the community to see it disappear. Since we do not have the capacity to develop + maintain new software, I wonder if the following 'low-tech' approach could work:
* Generate a static page for each package. * Crawl/Index it with existing search solution such as Yacy [1]
We could even extend this search thing to more Fedora websites if it performs well. I think it might be worth a proof-of-concept, which I can try to build if you're willing to allocate me some server/VM space for testing :-)
On Wed, 1 Apr 2020 at 23:20, Timothée Floure timothee.floure@posteo.net wrote:
Hi,
Jumping in since I saw this at the top of the web list archive. This service is very convenient and I think it would be fairly painful for the community to see it disappear. Since we do not have the capacity to develop + maintain new software, I wonder if the following 'low-tech' approach could work:
- Generate a static page for each package.
- Crawl/Index it with existing search solution such as Yacy [1]
I think it is an interesting idea, I don't know about Yacy but I think doing a simple proof-of-concept with maybe a few packages could be interesting.
We could even extend this search thing to more Fedora websites if it performs well. I think it might be worth a proof-of-concept, which I can try to build if you're willing to allocate me some server/VM space for testing :-)
If you are happy with having something running in containers, you can ask to get access to communishift [0] but mind that this will be offline for a little while in the coming months because of the data centre move. Otherwise I think we could get you instance on AWS probably. Either way if you open an infra ticket [1] with what you need or want we can then look at possible solutions :-).
[0] - https://fedoraproject.org/wiki/Infrastructure/Communishift [1] - https://pagure.io/fedora-infrastructure
-- Timothée _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
* Yacy (there might be others to test) running on communityshift: http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org * It's indexed against the 20 first PDC packages: https://fnux.fedorapeople.org/pkgs/
* Example looking for 'disk encryption': http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysea...
Looks good so far. I'm curious how relevant/fast the search would be against 40K packages and ways more details.
On Fri, 3 Apr 2020 at 09:18, Timothée Floure timothee.floure@posteo.net wrote:
- Yacy (there might be others to test) running on communityshift:
http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org
- It's indexed against the 20 first PDC packages:
https://fnux.fedorapeople.org/pkgs/
- Example looking for 'disk encryption':
http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysea...
Hi Timothée, the above link is asking for a username password, but I was able to play around using the first url you provided. I think Yacy can be a cool solution to offer a search service for packages, in particular using the JSON api[0] so anyone could use this service and build some cool application if they wanted too.
How does the indexing works ? And what would it take to add more info for each package ?
[0] - http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysea...
Looks good so far. I'm curious how relevant/fast the search would be against 40K packages and ways more details. _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
Hi,
How does the indexing works ?
You point Yacy to a domain or list of URLs (https://fnux.fedorapeople.org/pkgs/ in this case), and it takes care of everything. There is also an advanced crawler panel in the UI allowing you to filter content (e.g. HTML classes) from pages, which would be useful if we do not want to index everything (e.g. dependencies).
I am not familiar with the maths used by Yacy for indexing.
And what would it take to add more info for each package ?
I wrote a quick script (https://paste.gnugen.ch/raw/4JAC) fetching package metadata from PDC+mdapi for testing, but it is ways too slow to scale to the whole package set.
MDAPI will have to be replaced by local SQLite to increase performance. I think we could generate most of the content from the repositories' metadata (last N Fedora + EPEL) but I need to find where the SQL files lives. A privileged endpoint to dist-get to fetch the package -> maintainer mapping bypassing pagination would be convenient.
We can use Yacy's JSON API to build a sexy fedora-branded search page but I think it's a late-stage optimization.
On Mon, 6 Apr 2020 at 08:58, Timothée Floure timothee.floure@posteo.net wrote:
Hi,
How does the indexing works ?
You point Yacy to a domain or list of URLs (https://fnux.fedorapeople.org/pkgs/ in this case), and it takes care of everything. There is also an advanced crawler panel in the UI allowing you to filter content (e.g. HTML classes) from pages, which would be useful if we do not want to index everything (e.g. dependencies).
I am not familiar with the maths used by Yacy for indexing.
Me neither :D
And what would it take to add more info for each package ?
I wrote a quick script (https://paste.gnugen.ch/raw/4JAC) fetching package metadata from PDC+mdapi for testing, but it is ways too slow to scale to the whole package set.
Cool, yeah the current indexing takes hours (I think around 4-5 hours) there are more than 80 000s packages and sub-packages. I think we can run this once a day so speed is not super super critical I would say.
MDAPI will have to be replaced by local SQLite to increase performance. I think we could generate most of the content from the repositories' metadata (last N Fedora + EPEL) but I need to find where the SQL files lives. A privileged endpoint to dist-get to fetch the package -> maintainer mapping bypassing pagination would be convenient.
You can look at how mdapi grabs these sqllite files ( https://pagure.io/mdapi/blob/master/f/mdapi-get_repo_md). For the maintainer mapping you should be able to find that here --> https://src.fedoraproject.org/extras/
We can use Yacy's JSON API to build a sexy fedora-branded search page but I think it's a late-stage optimization.
+1, would be interesting to see with msuchy if that can be easily integrated with the work he was doing.
-- Timothée _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
I started to work here: https://pagure.io/fedora-packages-static/tree/master
I'll update you once I get something usable.
I still need to handle a few cases (e.g. subpackages) but everything looks good so far. Generating the whole static website is quite fast (minutes including repository metadata sync, seconds otherwise).
Screenshot attached :-)
I should have something usable by next week. If I were to deploy it somewhere, would it be in communityshift (= container)? When is communityshift supposed to come back online?
Would it be possible to allocate the pkg.fedoraproject.org domain for this service?
If there is no server space available due to the datacenter move, I'm pretty sure I can ask $DAYJOB (https://datacenterlight.ch/) to sponsor a VM for the next few months (against a mention in footer or similar).
On Thu, Apr 09, 2020 at 01:39:47PM +0200, Timothée Floure wrote:
I still need to handle a few cases (e.g. subpackages) but everything looks good so far. Generating the whole static website is quite fast (minutes including repository metadata sync, seconds otherwise).
Screenshot attached :-)
Nice. starting to look good. ;)
I should have something usable by next week. If I were to deploy it somewhere, would it be in communityshift (= container)? When is communityshift supposed to come back online?
Yeah, that would be a nice place for it.
It goes down monday and back up in a few weeks (depends on how long it takes to ship and rack up and bring back up).
Would it be possible to allocate the pkg.fedoraproject.org domain for this service?
I think that would be confusing.
We have pkgs.fedoraproject.org (which is the ssh hostname for src.fedoraproject.org), so pkg would be pretty confusing to them.
I think packages is even confusing too. But I'm not sure what (if anything) would be less confusing... debian uses 'packages' also, FWIW.
If there is no server space available due to the datacenter move, I'm pretty sure I can ask $DAYJOB (https://datacenterlight.ch/) to sponsor a VM for the next few months (against a mention in footer or similar).
Cool. Well, communishift should be back before too long...
kevin
Hi,
Took a bit more time than expected due to other and more local priorities on my side. The basic structure is there and usable, and indexing seemed work quite well before CommunityShift (hence yacy) went down.
* Main page: https://fnux.ch/fedpkg/public_html/ * Crawler entrypoint: https://fnux.ch/fedpkg/public_html/crawler-entrypoint.html * Package page: https://fnux.ch/fedpkg/public_html/pkgs/qutebrowser/
Everything lives on https://pagure.io/fedora-packages-static, and contains the TODO-list (epel-8, flatpaks & containers, dependencies, etc.). CommunityShift will be back earlier than I initially thought, and I hope to find some time to complete some of the TODO tasks by then.
Feedback, green light, whether it looks good enough to replace the current app, or anything you think relevant is welcome. The only dependencies are python3-requests and python3-jinja2 and there is no flying parts since it is a static website: we should not hit dead dependency issues ever again (or the package app will be the least of our problems!).
Have a nice day,
On Wed, 22 Apr 2020 at 11:18, Timothée Floure timothee.floure@posteo.net wrote:
Hi,
Took a bit more time than expected due to other and more local priorities on my side. The basic structure is there and usable, and indexing seemed work quite well before CommunityShift (hence yacy) went down.
* Main page: https://fnux.ch/fedpkg/public_html/ * Crawler entrypoint:https://fnux.ch/fedpkg/public_html/crawler-entrypoint.html * Package page: https://fnux.ch/fedpkg/public_html/pkgs/qutebrowser/
Everything lives on https://pagure.io/fedora-packages-static, and contains the TODO-list (epel-8, flatpaks & containers, dependencies, etc.). CommunityShift will be back earlier than I initially thought, and I hope to find some time to complete some of the TODO tasks by then.
This is cool, thanks for working on this. How long does it take for the `make all` command to complete ? ( I am just curious compared to the current solution :-) )
Feedback, green light, whether it looks good enough to replace the current app, or anything you think relevant is welcome. The only dependencies are python3-requests and python3-jinja2 and there is no flying parts since it is a static website: we should not hit dead dependency issues ever again (or the package app will be the least of our problems!).
I think we should look at deploying this service once communishift is back online. Also since the current application will go down during the data center move switching to this service instead of bringing back up the old code base seems to me like an interesting way forward.
Have a nice day,
-- Timothée _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
On 4/1/20 4:13 PM, Timothée Floure wrote:
Hi,
Jumping in since I saw this at the top of the web list archive. This service is very convenient and I think it would be fairly painful for the community to see it disappear. Since we do not have the capacity to develop + maintain new software, I wonder if the following 'low-tech' approach could work:
- Generate a static page for each package.
- Crawl/Index it with existing search solution such as Yacy [1]
We could even extend this search thing to more Fedora websites if it performs well. I think it might be worth a proof-of-concept, which I can try to build if you're willing to allocate me some server/VM space for testing :-)
I like this idea! I used the packages web app heavily when I was learning to package for Fedora. If the search result redirects to a static page and it is possible to limit what data Yacy crawls, then it would be possible to recreate most of the old packages functionality using a JavaScript framework like Vue. I would like to help if there is a need for any web development.
On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets (http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial.
OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app.
However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL.
I think we should do *something* to continue to provide that particular feature to packagers. I have a proposal:
What if we make a fedpkg subcommand that prints that table? I think it could get all the needed data by querying Koji.
I suggest this instead of a webapp or service, because webapps and services increase the burden on the CPE team, and also because creating an entire application just to print a table is a lot of boilerplate.
Adding it to fedpkg feels clean to me, because it seems like a sensible place for such a feature to exist, and because it *should* be simple and easy. Simple is good!
I may be able to find the time to make this happen before April too.
Thoughts?
On Fri, Oct 25, 2019 at 2:43 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets (http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial.
OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app.
However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL.
I think we should do *something* to continue to provide that particular feature to packagers. I have a proposal:
What if we make a fedpkg subcommand that prints that table? I think it could get all the needed data by querying Koji.
I suggest this instead of a webapp or service, because webapps and services increase the burden on the CPE team, and also because creating an entire application just to print a table is a lot of boilerplate.
Adding it to fedpkg feels clean to me, because it seems like a sensible place for such a feature to exist, and because it *should* be simple and easy. Simple is good!
I may be able to find the time to make this happen before April too.
Thoughts?
It's not a bad feature to have in fedpkg, but it fundamentally does not help *other people* discover what we have in the distribution. If anything, the biggest problem with CLI tools over web apps is that there's no intuitive way to discover anything. In my view, it does not replace the purpose of the packages web app.
On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
It's not a bad feature to have in fedpkg, but it fundamentally does not help *other people* discover what we have in the distribution.
Yeah I've discussed this a bit with some people, and I agree. Fedora *users* might use the packages app to find out the same info that packagers want to find out.
However, I think that even though users and packagers are coming to this app for the same purpose, only one of those purposes maps to the CPE team's mission statement: the packager's. If you are a packager, you *need* to know what versions are where at a glance, especially when dealing with something high priority like a CVE.
That's not to say that the end-user story isn't a valuable use case, but our team is overburdened and we need to drop most of what we do right now, and we have to be specific about what our purpose is. This means dropping some valuable use cases.
Of course, this is also my own opinion, and I welcome disagreement.
On Fri, Oct 25, 2019, 21:42 Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
It's not a bad feature to have in fedpkg, but it fundamentally does not help *other people* discover what we have in the distribution.
Yeah I've discussed this a bit with some people, and I agree. Fedora *users* might use the packages app to find out the same info that packagers want to find out.
However, I think that even though users and packagers are coming to this app for the same purpose, only one of those purposes maps to the CPE team's mission statement: the packager's. If you are a packager, you *need* to know what versions are where at a glance, especially when dealing with something high priority like a CVE.
That's not to say that the end-user story isn't a valuable use case, but our team is overburdened and we need to drop most of what we do right now, and we have to be specific about what our purpose is. This means dropping some valuable use cases.
https://pkgs.org/ might be a good replacement for that. Does anybody have used or is using this website ? Any feedback on it ?
Of course, this is also my own opinion, and I welcome disagreement. _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@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/infrastructure@lists.fedorapro...
On Fri, Oct 25, 2019 at 3:48 PM Clement Verna cverna@fedoraproject.org wrote:
On Fri, Oct 25, 2019, 21:42 Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote:
It's not a bad feature to have in fedpkg, but it fundamentally does not help *other people* discover what we have in the distribution.
Yeah I've discussed this a bit with some people, and I agree. Fedora *users* might use the packages app to find out the same info that packagers want to find out.
However, I think that even though users and packagers are coming to this app for the same purpose, only one of those purposes maps to the CPE team's mission statement: the packager's. If you are a packager, you *need* to know what versions are where at a glance, especially when dealing with something high priority like a CVE.
That's not to say that the end-user story isn't a valuable use case, but our team is overburdened and we need to drop most of what we do right now, and we have to be specific about what our purpose is. This means dropping some valuable use cases.
https://pkgs.org/ might be a good replacement for that. Does anybody have used or is using this website ? Any feedback on it ?
Some of the searching is a little awkward. It does let you see stuff across distributions, but a lot of Fedora-specific information isn't present.
Unfortunately, improving pkgs.org is impossible as the author is hard to get ahold of and the software is not FOSS.
On Fri, 2019-10-25 at 21:47 +0200, Clement Verna wrote:
https://pkgs.org/ might be a good replacement for that. Does anybody have used or is using this website ? Any feedback on it ?
I haven't seen this before, but if it does a good job staying up to date then it seems like a good replacement to me, and someone else already did it and even hosts it. Nice.
On Fri, Oct 25, 2019 at 02:42:51PM -0400, Randy Barlow wrote:
On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote:
The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets (http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial.
OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app.
However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL.
I think we should do *something* to continue to provide that particular feature to packagers. I have a proposal:
What if we make a fedpkg subcommand that prints that table? I think it could get all the needed data by querying Koji.
I suggest this instead of a webapp or service, because webapps and services increase the burden on the CPE team, and also because creating an entire application just to print a table is a lot of boilerplate.
Adding it to fedpkg feels clean to me, because it seems like a sensible place for such a feature to exist, and because it *should* be simple and easy. Simple is good!
I may be able to find the time to make this happen before April too.
Thoughts?
Something like https://pagure.io/fedora-ci/general/issue/raw/files/0febd8de2561c4e3e463b221... which is merged in git and will be in the next release?
Pierre
On Fri, Oct 25, 2019 at 8:43 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app.
However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL.
I am planning to deploy Package Version Matrix in communishift [1]. Example how it can look like: [2]
[1] https://pagure.io/fedora-infrastructure/issue/8314 [2] https://koji.kjnet.xyz/kojifiles/versions/
-- Mikolaj Izdebski
On Fri, 2019-10-25 at 21:00 +0200, Mikolaj Izdebski wrote:
I am planning to deploy Package Version Matrix in communishift [1]. Example how it can look like: [2]
[1] https://pagure.io/fedora-infrastructure/issue/8314 [2] https://koji.kjnet.xyz/kojifiles/versions/
Oh that could be a good replacement. Does it support searching, or displaying a particular package rather than the full set (since there are a lot of packages in all of Fedora)? If not, it's probably not hard to add.
infrastructure@lists.fedoraproject.org
-
Brendan Early -
Clement Verna -
Kevin Fenzi -
Mikolaj Izdebski -
Miroslav Suchý -
Neal Gompa -
Pierre-Yves Chibon -
Randy Barlow -
Timothée Floure