Re: F22 Self Contained Change: Disabled Repositories Support
On 2015-03-17, 15:51 GMT, Richard Hughes wrote: On 17 March 2015 at 15:35, Miloslav Trmač m...@redhat.com wrote: Wait, the metadata download and search code is not shared? What would it take to make it so? No. The dnf code is in python and the libhif code is in C. Sorry, I am just a stupid idiot writing in one of those hated interpreted languages, but what in the world has format of data to do with the language the program which consumes them is written in? /me wonders how many unicorns and kittens will have to die before we get rid of all this dupli^Wtriplication. rantPerhaps, when we stop writing low level tools with specific latency requirements in interpreted languages... ? Or perhaps when the rising sea overflows the city of Venice? What’s the realtionship between the interpreted languages and said duplication? (Not mentioning of course that substantial part of dnf uses C libraries underneath) Completely confused Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Science is meaningless because it gives no answer to our question, the only question important to us: ``What shall we do and how shall we live?'' -- Lev Nikolaevich Tolstoy -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/19/2015 07:18 PM, Adam Jackson wrote: On Wed, 2015-03-18 at 00:36 +0100, Kevin Kofler wrote: Richard Hughes wrote: rantPerhaps, when we stop writing low level tools with specific latency requirements in interpreted languages... +1 In fact, IMHO, we should stop writing ANYTHING in interpreted languages. I look forward to your patches to drop bash and make from the OS then. You'd be surprised. There is apparently work under way, in the larger Fedora ecosystem, on scriptless booting, in the name of security (eventually making Android-style locked bootloaders). -- Florian Weimer / Red Hat Product Security -- 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: F22 Self Contained Change: Disabled Repositories Support
On 20 March 2015 at 08:59, Matěj Cepl mc...@cepl.eu wrote: Sorry, I am just a stupid idiot writing in one of those hated interpreted languages Nobody said anything of the sort. I write stuff in python all the time. What’s the realtionship between the interpreted languages and said duplication? Okay, here's a little example. Try to write a python program that can return exit code 0 if /etc/resolve.conf exists, the catch being that it has to return within 10ms on hardware 3 years old. The deal breaker is the time of the python interpretor to startup, and the time to interpret the file. Now imagine you're trying to write a command-not-found implementation that uses python to load yum. The Yum codebase is pretty huge, and by the time the 50ms user needs results now timer expires we're not even at loading metadata let alone returning results. Python is awesome for prototyping and for little scripts. It's just not awesome at everything. Richard. -- 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: F22 Self Contained Change: Disabled Repositories Support
Hi On Fri, Mar 20, 2015 at 5:01 AM, Florian Weimer wrote: You'd be surprised. There is apparently work under way, in the larger Fedora ecosystem, on scriptless booting, in the name of securinity (eventually making Android-style locked bootloaders). Eliminating scripting from boot doesn't eliminate it for countless other things it is used for Rahul -- 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: F22 Self Contained Change: Disabled Repositories Support
On 2015-03-20, 14:28 GMT, Richard Hughes wrote: Now imagine you're trying to write a command-not-found implementation that uses python to load yum. The Yum codebase is pretty huge, and by the time the 50ms user needs results now timer expires we're not even at loading metadata let alone returning results. Use right tool for the right job. Premise that this obviously rather time-sensitive application cannot be written in Python (which might be true) doesn’t lead to conclusion that no system application should be written in it. If you mean that libsolv and libcomps should be written in C, and that for this (rather specialized and not absolutely necessary) weird application core of yum being written in Python was too slow, I would agree. Python is awesome for prototyping and for little scripts. It's just not awesome at everything. Not it is not awesome for everything, but something tiny like for example Google Website, or some other tiny little scripts https://www.python.org/about/success/ it does pretty well. Matěj -- 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: F22 Self Contained Change: Disabled Repositories Support
- Original Message - On 03/18/2015 12:55 PM, Peter Robinson wrote: How are disabled repositories going to be approved for inclusion? While you likely meant political meaning of how, I would like share how it will be done technically. Approximately 6 months ago EnvStack wanted to have Playground repository, which would be set of Copr repositories. Something guaranteed to meet legal requirements, something with sufficient quality. Copr already have this attribute for every project and admins of Copr can set/unset this flag. You can already enable those repositories by: dnf playground enable if you have dnf-plugins-core. Unfortunately this set is currently empty :) Half a year ago the blocker for EnvStack was that Copr can not sign packages. Copr can do that for few weeks now and I notified EnvStack so they can continue on they work on Playground repository. This is IMO ideal candidate for disabled repositories with enabled metadata. Yep, I raised it on the Council meeting and these two proposals work pretty well together! Jaroslav I am not sure how to deliver those disable repositories though. But that is likely for different discussion. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F22 Self Contained Change: Disabled Repositories Support
- Original Message - On 03/18/2015 05:46 PM, Rahul Sundaram wrote: Hi On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton wrote: What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. I don't think of it as a endorsement. I see them as a means of discouraging people from packaging for Fedora: Ask yourself: Why should I package a package properly, when I can get off 'cheap'? - msuchy's rationale is along this line. It is making them more easily discoverable but there is going to be a prompt of some sort that warns them of the nature of such software and users get to choose whether they are willing to accept that tradeoff for immediate access. One might choose to use say, Chromium regardless of the bundling issues for example. There are many more ways why a package not to be eligible for Fedora than bundling: - Illegal/patent-encumbered in the US, but legal to distribute in other countries. - Legal to distribute binaries, repackaged for packager lazyness, (e.g. Java) or complexity (foreign arch binaries needed to support cross-toolchains). - Content-only packages (Videos, Audiofiles). - Packages with ethical/political controversial contents. ... In other words, if you are really serious about this plan, you need some authority to continuously review the packages in such endorsed repos, technically, legally and politically. And that's what Council agreed on. The process is not yet set but it may end up on Council's table. By the way, for non-good stuff you mentioned above - it's already not allowed to do it in Coprs - https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr So for Copr, I'm in support of this proposal as it perfectly fits with the idea of Playground repository I helped to draft. Copr is part of Fedora project (and I even would like it more integral part as part of Koji). For repositories outside Fedora Project, I stated on the Council meeting, that I'd require opt-in/opt-out consent from user before even search for such disabled repository is allowed. But it would be one dialog with ack/nack and explanation what does it mean. Jaroslav Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F22 Self Contained Change: Disabled Repositories Support
2015-03-18 18:51 GMT+01:00 Ralf Corsepius rc040...@freenet.de: On 03/18/2015 05:46 PM, Rahul Sundaram wrote: Hi On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton wrote: What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. I don't think of it as a endorsement. I see them as a means of discouraging people from packaging for Fedora: Ask yourself: Why should I package a package properly, when I can get off 'cheap'? - msuchy's rationale is along this line. It is making them more easily discoverable but there is going to be a prompt of some sort that warns them of the nature of such software and users get to choose whether they are willing to accept that tradeoff for immediate access. One might choose to use say, Chromium regardless of the bundling issues for example. There are many more ways why a package not to be eligible for Fedora than bundling: - Illegal/patent-encumbered in the US, but legal to distribute in other countries. - Legal to distribute binaries, repackaged for packager lazyness, (e.g. Java) or complexity (foreign arch binaries needed to support cross-toolchains). - Content-only packages (Videos, Audiofiles). - Packages with ethical/political controversial contents. ... In other words, if you are really serious about this plan, you need some authority to continuously review the packages in such endorsed repos, technically, legally and politically. The idea of use disabled-third-party-repos to ship non free software has been discused in the desktop list, this for example https://lists.fedoraproject.org/pipermail/desktop/2015-February/011634.html In fact, in the last meeting of the Workstation WG, one of the action items is: * Third party repositories (stickster, 15:41:18) * LINK: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table is interesting. (stickster, 15:48:12) * LINK: https://repos.fedorapeople.org/repos/spot/chromium/ , F21 last updated in january (kalev, 16:08:47) * LINK: https://copr.fedoraproject.org/coprs/churchyard/chromium-russianfedora/ is the other i was thinking of (jwb, 16:09:29) * AGREED: Go for Chrome next (stickster, 16:15:39) * ACTION: cschalle stickster work up justification for Council and review gnome-software text for an appropriate warning to suggest (stickster, 16:16:12) **Go for Chrome next.** Here is the full text. https://lists.fedoraproject.org/pipermail/desktop/2015-March/011722.html I said in my first message that the purpose of the Change is to help people to install non-free software. Probably I was wrong and there are legitimate uses. Anyway what is true is that *some people* wants to use this Change to make it easy to install non-free software. Sergio -- 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: F22 Self Contained Change: Disabled Repositories Support
On Wed, 2015-03-18 at 00:36 +0100, Kevin Kofler wrote: Richard Hughes wrote: rantPerhaps, when we stop writing low level tools with specific latency requirements in interpreted languages... +1 In fact, IMHO, we should stop writing ANYTHING in interpreted languages. I look forward to your patches to drop bash and make from the OS then. - ajax -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/16/2015 06:48 PM, Mike Pinkerton wrote: If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Another example - I have two projects in Copr: * spark-cli - command line interface for Spark Core * nanoblogger - blog with just static pages generated by bash sript I have no intention to get them into main Fedora. Mostly because I am not willing to fix bugs. I just packaged it for myself. It works for me and it may work most people. Therefore I assume that it may be useful for somebody out there. We (as Fedora) simply could not package and maintain everything with the same quality. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/18/2015 12:55 PM, Peter Robinson wrote: How are disabled repositories going to be approved for inclusion? While you likely meant political meaning of how, I would like share how it will be done technically. Approximately 6 months ago EnvStack wanted to have Playground repository, which would be set of Copr repositories. Something guaranteed to meet legal requirements, something with sufficient quality. Copr already have this attribute for every project and admins of Copr can set/unset this flag. You can already enable those repositories by: dnf playground enable if you have dnf-plugins-core. Unfortunately this set is currently empty :) Half a year ago the blocker for EnvStack was that Copr can not sign packages. Copr can do that for few weeks now and I notified EnvStack so they can continue on they work on Playground repository. This is IMO ideal candidate for disabled repositories with enabled metadata. I am not sure how to deliver those disable repositories though. But that is likely for different discussion. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: F22 Self Contained Change: Disabled Repositories Support
On Wed, 2015-03-18 at 11:55 +, Peter Robinson wrote: 2015-03-16 15:52 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Disabled Repositories Support sounds better than Help People Install Non-Free Software in Fedora, but the result is the same. Personally, I don't like it That's not all it is potentially usable for. For example, at last Wednesday's FESCo meeting, we gave GNOME Software permission to use this functionality to point at a curated set of COPR repositories. These are all free software, just with a lower standard of packaging. That's a perfectly sound use of this feature, I would say. How are disabled repositories going to be approved for inclusion? That was left officially unresolved in the Council meeting this week, but the implication is that someone will have to petition the Council with justification on why the specific repository (or really, the piece of software that it provides) would be a benefit to the Fedora Project. signature.asc Description: This is a digitally signed message part -- 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: F22 Self Contained Change: Disabled Repositories Support
2015-03-16 15:52 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Disabled Repositories Support sounds better than Help People Install Non-Free Software in Fedora, but the result is the same. Personally, I don't like it That's not all it is potentially usable for. For example, at last Wednesday's FESCo meeting, we gave GNOME Software permission to use this functionality to point at a curated set of COPR repositories. These are all free software, just with a lower standard of packaging. That's a perfectly sound use of this feature, I would say. How are disabled repositories going to be approved for inclusion? -- 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: F22 Self Contained Change: Disabled Repositories Support
- Original Message - On Mar 17, 2015 5:18 AM, Jan Zelený jzel...@redhat.com wrote: On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Change owner(s): Richard Hughes rhughes at redhat dot com The Software tool and PackageKit now support disabled repositories to help users locate software in additional repositories which are not meant to be enabled by default. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. When Software (via PackageKit) queries a repo definition that contains the line enabled_metadata=1, even if the repo is disabled, it will download repodata. This feature allows a user to locate software in response to a search. If the user wants to install the software, she receives a dialog with information that the repo must be enabled to satisfy the request, and if relevant, information about the nature of the software (for instance, if it is non- libre). N.B. This feature does not currently operate in Fedora, since no such repo definitions are currently shipped. However, the feature could be used by remixers, and in the future in Fedora in the event of a policy change. == Scope == * Proposal owners: Include enhancements in gnome-software/PackageKit (done) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires an additional *- release-extra package to ship disabled repo definition * Policies and guidelines: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires clearer approval from FESCo and the Council I wonder, are there any implications for dnf in terms of being consistent with the new behavior of Gnome Software? I realize that people using dnf have more options than people using Gnome Software (--enablerepo for instance) but this sounds like the beginning of the end of disabled repositories. Personally, I don't like the semantics of these semi-disabled repos. It beats the purpose of disabling the repos in the first place, doesn't it? I mean I don't get why user would specify enabled_metadata=1 when he can achieve almost the same result with disabled=0 (the only difference I can see is one additional popup dialog). Or is there something I'm missing? Thanks Jan -- As I understand it, the intent is to provide the user with the experience of third party software being included in Fedora, while still complying with the third party repository policy and communicating to the user that it comes from somewhere else. As I understand it, the council stance is that each repo must be a self-contained piece of software, and each individual repo must have explicit council approval to be included, with a mandate for furthering Fedora's mission and an expectation of permissive licensing. In that context, I guess I'm ok with the compromise. jreznik, what about cycling these approvals through the Change process, but instead of going to Fesco, the tickets go to the council? That would allow a sufficient amount of community scrutiny and signal, IMO. The Change template would only need to be modified slightly, probably not more than current interpretations do. That's one of future goals to use Change process not only for Changes that has to go through FESCo but WGs, for this case Council. Actually, the new process was initially designed this way :). It will require some change in template but it's doable and it can help coordination with other parts of Fedora as we do for example for Release Notes. So, count me in :). Jaroslav --Pete -- 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: F22 Self Contained Change: Disabled Repositories Support
On 18 Mar 2015, at 08:40, Miroslav Suchý wrote: On 03/16/2015 06:48 PM, Mike Pinkerton wrote: If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Another example - I have two projects in Copr: * spark-cli - command line interface for Spark Core * nanoblogger - blog with just static pages generated by bash sript I have no intention to get them into main Fedora. Mostly because I am not willing to fix bugs. I just packaged it for myself. It works for me and it may work most people. Therefore I assume that it may be useful for somebody out there. We (as Fedora) simply could not package and maintain everything with the same quality. I understand the usefulness of copr for software in development, experimental builds, personal projects, work in progress, etc. I even understand making software there discoverable via a web-based search page -- which you already have. What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. -- Mike -- 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: F22 Self Contained Change: Disabled Repositories Support
Hi On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton wrote: What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. I don't think of it as a endorsement. It is making them more easily discoverable but there is going to be a prompt of some sort that warns them of the nature of such software and users get to choose whether they are willing to accept that tradeoff for immediate access. One might choose to use say, Chromium regardless of the bundling issues for example. Rahul -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/18/2015 05:46 PM, Rahul Sundaram wrote: Hi On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton wrote: What I don't understand is the wisdom of an official Fedora product endorsing a copr when either the software or packaging (or both) is not of sufficient quality to make it into the official Fedora repo. I don't think of it as a endorsement. I see them as a means of discouraging people from packaging for Fedora: Ask yourself: Why should I package a package properly, when I can get off 'cheap'? - msuchy's rationale is along this line. It is making them more easily discoverable but there is going to be a prompt of some sort that warns them of the nature of such software and users get to choose whether they are willing to accept that tradeoff for immediate access. One might choose to use say, Chromium regardless of the bundling issues for example. There are many more ways why a package not to be eligible for Fedora than bundling: - Illegal/patent-encumbered in the US, but legal to distribute in other countries. - Legal to distribute binaries, repackaged for packager lazyness, (e.g. Java) or complexity (foreign arch binaries needed to support cross-toolchains). - Content-only packages (Videos, Audiofiles). - Packages with ethical/political controversial contents. ... In other words, if you are really serious about this plan, you need some authority to continuously review the packages in such endorsed repos, technically, legally and politically. Ralf -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mon, 2015-03-16 at 16:11 -0500, Michael Catanzaro wrote: On Mon, 2015-03-16 at 15:25 -0400, Stephen Gallagher wrote: Other examples might be preview releases of certain software that are not yet stable enough to be in Fedora proper or whose installation might be too disruptive during a stable lifecycle. Like for example the recent GNOME 3.12 repositories for Fedora 20 users since we had the long cycle. This is a bad example IMO. We are not set up to handle coprs that include essential system packages. If you try to remove the gnome- 3.12 copr with gnome-software, it just uninstalls your desktop environment and leaves you with a broken computer. Good point. I forgot to account for the lack of a way to back out of it when I listed that. Installing a single application that's not in Fedora from a copr is one thing, or a newer version of an application, but not if they are core system packages. signature.asc Description: This is a digitally signed message part -- 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: F22 Self Contained Change: Disabled Repositories Support
On 17 March 2015 at 11:18, Jan Zelený jzel...@redhat.com wrote: Personally, I don't like the semantics of these semi-disabled repos. It beats the purpose of disabling the repos in the first place, doesn't it? disabled=0 means don't download packages or metadata which means if we search for chromium nothing is displayed. semi-disabled means download metadata only which allows us to show search results but with a prompt of some sort before enabling the repo properly so we can install from it. Richard -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mar 17, 2015 5:18 AM, Jan Zelený jzel...@redhat.com wrote: On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Change owner(s): Richard Hughes rhughes at redhat dot com The Software tool and PackageKit now support disabled repositories to help users locate software in additional repositories which are not meant to be enabled by default. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. When Software (via PackageKit) queries a repo definition that contains the line enabled_metadata=1, even if the repo is disabled, it will download repodata. This feature allows a user to locate software in response to a search. If the user wants to install the software, she receives a dialog with information that the repo must be enabled to satisfy the request, and if relevant, information about the nature of the software (for instance, if it is non- libre). N.B. This feature does not currently operate in Fedora, since no such repo definitions are currently shipped. However, the feature could be used by remixers, and in the future in Fedora in the event of a policy change. == Scope == * Proposal owners: Include enhancements in gnome-software/PackageKit (done) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires an additional *- release-extra package to ship disabled repo definition * Policies and guidelines: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires clearer approval from FESCo and the Council I wonder, are there any implications for dnf in terms of being consistent with the new behavior of Gnome Software? I realize that people using dnf have more options than people using Gnome Software (--enablerepo for instance) but this sounds like the beginning of the end of disabled repositories. Personally, I don't like the semantics of these semi-disabled repos. It beats the purpose of disabling the repos in the first place, doesn't it? I mean I don't get why user would specify enabled_metadata=1 when he can achieve almost the same result with disabled=0 (the only difference I can see is one additional popup dialog). Or is there something I'm missing? Thanks Jan -- As I understand it, the intent is to provide the user with the experience of third party software being included in Fedora, while still complying with the third party repository policy and communicating to the user that it comes from somewhere else. As I understand it, the council stance is that each repo must be a self-contained piece of software, and each individual repo must have explicit council approval to be included, with a mandate for furthering Fedora's mission and an expectation of permissive licensing. In that context, I guess I'm ok with the compromise. jreznik, what about cycling these approvals through the Change process, but instead of going to Fesco, the tickets go to the council? That would allow a sufficient amount of community scrutiny and signal, IMO. The Change template would only need to be modified slightly, probably not more than current interpretations do. --Pete -- 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: F22 Self Contained Change: Disabled Repositories Support
I wonder, are there any implications for dnf in terms of being consistent with the new behavior of Gnome Software? Wait, the metadata download and search code is not shared? What would it take to make it so? /me wonders how many unicorns and kittens will have to die before we get rid of all this dupli^Wtriplication. Mirek -- 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: F22 Self Contained Change: Disabled Repositories Support
Richard Hughes wrote: rantPerhaps, when we stop writing low level tools with specific latency requirements in interpreted languages... +1 In fact, IMHO, we should stop writing ANYTHING in interpreted languages. Kevin Kofler -- 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: F22 Self Contained Change: Disabled Repositories Support
On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Change owner(s): Richard Hughes rhughes at redhat dot com The Software tool and PackageKit now support disabled repositories to help users locate software in additional repositories which are not meant to be enabled by default. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. When Software (via PackageKit) queries a repo definition that contains the line enabled_metadata=1, even if the repo is disabled, it will download repodata. This feature allows a user to locate software in response to a search. If the user wants to install the software, she receives a dialog with information that the repo must be enabled to satisfy the request, and if relevant, information about the nature of the software (for instance, if it is non- libre). N.B. This feature does not currently operate in Fedora, since no such repo definitions are currently shipped. However, the feature could be used by remixers, and in the future in Fedora in the event of a policy change. == Scope == * Proposal owners: Include enhancements in gnome-software/PackageKit (done) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires an additional *- release-extra package to ship disabled repo definition * Policies and guidelines: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires clearer approval from FESCo and the Council I wonder, are there any implications for dnf in terms of being consistent with the new behavior of Gnome Software? I realize that people using dnf have more options than people using Gnome Software (--enablerepo for instance) but this sounds like the beginning of the end of disabled repositories. Personally, I don't like the semantics of these semi-disabled repos. It beats the purpose of disabling the repos in the first place, doesn't it? I mean I don't get why user would specify enabled_metadata=1 when he can achieve almost the same result with disabled=0 (the only difference I can see is one additional popup dialog). Or is there something I'm missing? Thanks Jan -- 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: F22 Self Contained Change: Disabled Repositories Support
On 17 March 2015 at 15:35, Miloslav Trmač m...@redhat.com wrote: Wait, the metadata download and search code is not shared? What would it take to make it so? No. The dnf code is in python and the libhif code is in C. /me wonders how many unicorns and kittens will have to die before we get rid of all this dupli^Wtriplication. rantPerhaps, when we stop writing low level tools with specific latency requirements in interpreted languages... Richard -- 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: F22 Self Contained Change: Disabled Repositories Support
One representative example would be software that is extremely useful to a large group of people but whose packaging is a nightmare. For example, a great many people enjoy the Chromium repository in COPR. Probably Brackets [1] is a good candidate too. And Atom [2]. Both already are in the COPRs. [1] http://brackets.io/ [2] https://atom.io/ --- Additionally: maybe move all (and/or add new) games to a dedicated COPR could be useful too. Could serve as a testing ground for separation of repos and policies, and as a incentive to have new games packaged for Fedora. The cool thing about this is that it seems like a simple and automatic implementation of the Rings thing discussed in another thread. If above is successful, in a longer term thing: maybe move all the (graphical?) apps to a Fedora Apps COPR which uses the libs from the Official Fedora Repos to kinda mold and prepare Fedora for the Runtime/Sandbox/Apps future? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 Self Contained Change: Disabled Repositories Support
= Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Change owner(s): Richard Hughes rhughes at redhat dot com The Software tool and PackageKit now support disabled repositories to help users locate software in additional repositories which are not meant to be enabled by default. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. When Software (via PackageKit) queries a repo definition that contains the line enabled_metadata=1, even if the repo is disabled, it will download repodata. This feature allows a user to locate software in response to a search. If the user wants to install the software, she receives a dialog with information that the repo must be enabled to satisfy the request, and if relevant, information about the nature of the software (for instance, if it is non- libre). N.B. This feature does not currently operate in Fedora, since no such repo definitions are currently shipped. However, the feature could be used by remixers, and in the future in Fedora in the event of a policy change. == Scope == * Proposal owners: Include enhancements in gnome-software/PackageKit (done) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires an additional *- release-extra package to ship disabled repo definition * Policies and guidelines: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires clearer approval from FESCo and the Council ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/16/2015 04:49 PM, Dennis Gilmore wrote: On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote: On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf No that is not going to happen, the repos in Question are copr repos OK, in this case, I do not see any sense in this request - It's a waste of time and resources. Ralf -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/16/2015 05:26 PM, Josh Boyer wrote: On Mar 16, 2015 12:23 PM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: On 03/16/2015 04:49 PM, Dennis Gilmore wrote: On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote: On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf No that is not going to happen, the repos in Question are copr repos OK, in this case, I do not see any sense in this request - It's a waste of time and resources. The work is already done and has no impact on the wider package maintainer set. This only means you already wasted time and resources. The Change is simply informational. a) This change impacts users, while these COPRs are not useful to them. b) According to Mr. Gallagher, these COPRs and this change serve to establish his vision of a 2-class society - Sorry, but you don't really want to know what I think of this. -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mar 16, 2015 12:23 PM, Ralf Corsepius rc040...@freenet.de wrote: On 03/16/2015 04:49 PM, Dennis Gilmore wrote: On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote: On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf No that is not going to happen, the repos in Question are copr repos OK, in this case, I do not see any sense in this request - It's a waste of time and resources. The work is already done and has no impact on the wider package maintainer set. The Change is simply informational. josh -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mon, Mar 16, 2015 at 12:50 PM, Ralf Corsepius rc040...@freenet.de wrote: On 03/16/2015 05:26 PM, Josh Boyer wrote: On Mar 16, 2015 12:23 PM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: On 03/16/2015 04:49 PM, Dennis Gilmore wrote: On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote: On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf No that is not going to happen, the repos in Question are copr repos OK, in this case, I do not see any sense in this request - It's a waste of time and resources. The work is already done and has no impact on the wider package maintainer set. This only means you already wasted time and resources. That is your opinion. The opinion of the people that did the work differs. The Change is simply informational. a) This change impacts users, while these COPRs are not useful to them. There are no COPR repo files that are installed by default today, which means none of them use this mechanism yet. Which means there is literally no change for any user at this time. As I said, the Change is informational. If such repo files are installed by default, it will be at the discretion of the various Working Groups not the Change proposer. b) According to Mr. Gallagher, these COPRs and this change serve to establish his vision of a 2-class society - Sorry, but you don't really want to know what I think of this. Stephen isn't the Change proposer, nor did he request the Change to be developed. However, you are correct in that I don't want to know what you think of this. josh -- 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: F22 Self Contained Change: Disabled Repositories Support
On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 Self Contained Change: Disabled Repositories Support
= Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Change owner(s): Richard Hughes rhughes at redhat dot com The Software tool and PackageKit now support disabled repositories to help users locate software in additional repositories which are not meant to be enabled by default. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. When Software (via PackageKit) queries a repo definition that contains the line enabled_metadata=1, even if the repo is disabled, it will download repodata. This feature allows a user to locate software in response to a search. If the user wants to install the software, she receives a dialog with information that the repo must be enabled to satisfy the request, and if relevant, information about the nature of the software (for instance, if it is non- libre). N.B. This feature does not currently operate in Fedora, since no such repo definitions are currently shipped. However, the feature could be used by remixers, and in the future in Fedora in the event of a policy change. == Scope == * Proposal owners: Include enhancements in gnome-software/PackageKit (done) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires an additional *- release-extra package to ship disabled repo definition * Policies and guidelines: N/A (not a System Wide Change) ** Note: For this feature to be used in Fedora requires clearer approval from FESCo and the Council ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: F22 Self Contained Change: Disabled Repositories Support
On Monday, March 16, 2015 04:36:40 PM Ralf Corsepius wrote: On 03/16/2015 03:52 PM, Jaroslav Reznik wrote: This feature aims to reduce the technical hurdles for users and developers to locate software packaged for a distribution, but which needs to be clearly identified as not officially included (or possibly sanctioned) by that distribution. Does this mean Fedora is going to ship repository configs for these unpronounceable repos. In the past we had been told this wasn't possible for legal reasons. Ralf No that is not going to happen, the repos in Question are copr repos Dennis -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mon, 2015-03-16 at 16:22 +0100, Sergio Pascual wrote: 2015-03-16 15:52 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Disabled Repositories Support sounds better than Help People Install Non-Free Software in Fedora, but the result is the same. Personally, I don't like it That's not all it is potentially usable for. For example, at last Wednesday's FESCo meeting, we gave GNOME Software permission to use this functionality to point at a curated set of COPR repositories. These are all free software, just with a lower standard of packaging. That's a perfectly sound use of this feature, I would say. signature.asc Description: This is a digitally signed message part -- 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: F22 Self Contained Change: Disabled Repositories Support
2015-03-16 15:52 GMT+01:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: Disabled Repositories Support = https://fedoraproject.org/wiki/Changes/DisabledRepoSupport Disabled Repositories Support sounds better than Help People Install Non-Free Software in Fedora, but the result is the same. Personally, I don't like it -- 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: F22 Self Contained Change: Disabled Repositories Support
On 16 Mar 2015, at 12:57, Josh Boyer wrote: a) This change impacts users, while these COPRs are not useful to them. There are no COPR repo files that are installed by default today, which means none of them use this mechanism yet. Which means there is literally no change for any user at this time. As I said, the Change is informational. If such repo files are installed by default, it will be at the discretion of the various Working Groups not the Change proposer. Why would an official product want to endorse unofficial repos? If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Just asking what the thinking is here ... -- Mike -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mon, 2015-03-16 at 15:25 -0400, Stephen Gallagher wrote: Other examples might be preview releases of certain software that are not yet stable enough to be in Fedora proper or whose installation might be too disruptive during a stable lifecycle. Like for example the recent GNOME 3.12 repositories for Fedora 20 users since we had the long cycle. This is a bad example IMO. We are not set up to handle coprs that include essential system packages. If you try to remove the gnome-3.12 copr with gnome-software, it just uninstalls your desktop environment and leaves you with a broken computer. Installing a single application that's not in Fedora from a copr is one thing, or a newer version of an application, but not if they are core system packages. -- 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: F22 Self Contained Change: Disabled Repositories Support
On Mon, 2015-03-16 at 13:48 -0400, Mike Pinkerton wrote: On 16 Mar 2015, at 12:57, Josh Boyer wrote: a) This change impacts users, while these COPRs are not useful to them. There are no COPR repo files that are installed by default today, which means none of them use this mechanism yet. Which means there is literally no change for any user at this time. As I said, the Change is informational. If such repo files are installed by default, it will be at the discretion of the various Working Groups not the Change proposer. Why would an official product want to endorse unofficial repos? If the working group deems the software to be that useful, wouldn't it be better to bring its packaging up to the quality of the official Fedora repo, and make it more easily discoverable by all Fedora users, regardless of whether they choose to use that product or a spin or a non-product install of Fedora? Just asking what the thinking is here ... One representative example would be software that is extremely useful to a large group of people but whose packaging is a nightmare. For example, a great many people enjoy the Chromium repository in COPR. Due to Google's upstream practices, it's basically impossible to get it to meet Fedora's packaging policies. However, Google as an upstream is at least responsive enough that it can be trusted to close security issues in a timely basis. With that in mind, is it worth introducing barriers to our users from installing Chromium simply because of packaging problems? I'd say this is a fair case. Other examples might be preview releases of certain software that are not yet stable enough to be in Fedora proper or whose installation might be too disruptive during a stable lifecycle. Like for example the recent GNOME 3.12 repositories for Fedora 20 users since we had the long cycle. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
