Re: Announce: Group projects in Copr
Wow, I was about to request this since I was about to start a shared COPR. You're always one step ahead of me Miroslav! Thank you. On Thu, Oct 15, 2015 at 10:34 AM, Miroslav Suchý <msu...@redhat.com> wrote: > It is my pleasure to announce new version of Copr. > https://copr.fedoraproject.org/ > > What's new? Group projects! > > When you log in. You can see in right column link "My Groups". There you > can see list of your FAS groups and you can > activate them. In fact, you actually create alias for them. E.g. FAS group > "gitmock" can be named "mock" in Copr. > You can click on Copr group in right column. That navigate you to url in > format: > > https://copr.fedoraproject.org/groups/g/mock/coprs/ > > Where are listed all projects of this group. And you can create new group > project there too. > Every member of that FAS group can administer it and build there. Due to > the OpenID limitations, you have to > log-out/log-in to see your groups (or whenever you join new group in FAS). > > Since copr-cli-1.45 (in updates-testing right now) you can submit package > to group project like: > copr-cli build @GROUP/PROJECT > e.g > copr-cli build @mock/mock-dev > > Creation of group project is not possible from command line right now due > OpenID restriction and you have to use WebUI. > This may change in near future. > > There is no API method in APIv1. But we provide APIv2 > http://copr-rest-api.readthedocs.org/en/latest/ > which has methods to manipulate with groups. > > To create new group in FAS, just follow: > https://admin.fedoraproject.org/accounts/group/new > > If you have some personal project and you want to change it to group > project, then please let me know and we change it > manually. > -- > Miroslav Suchy, RHCA > 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 -- Alberto Ruiz Engineering Supervisor - Desktop Management Tools Red Hat -- 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: Changing default configuration
On Tue, 2015-02-10 at 14:38 +0100, Marek Skalický wrote: Matthew Miller píše v Út 10. 02. 2015 v 06:19 -0500: On Tue, Feb 10, 2015 at 12:12:15PM +0100, Marek Skalický wrote: does someone know what are Fedora Guidelines (or something similar) saying about this bug https://bugzilla.redhat.com/show_bug.cgi?id=1077369 ? Is is possible to change default configuration file depending on available free space? Generally, making such a decision at install time is bad, because that might not reflect _runtime_. For example, in the cloud image, we use a / filesystem as small as Anaconda will allow, but that grows to fill available storage when the image is booted. Is there a way to make this decision when mongodb runs? It should be possible to code this into sysv init script. But I am not sure if it is possible to do the same in systemd service...? My question was also about whether this should be done by mongoDB? Or there should be default configuration and user can easily change it in configuration file? It should be done by MongoDB, I would get in touch with the upstream and discuss the problem with them. Marek -- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc. -- 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: FESCo Elections results
Hello Kevin, Could you please elaborate on what's your concern? Am I supposed to refrain myself from trying to become a FESCo member because I am (among many other things) a GNOME developer? On Thu, 2015-02-05 at 14:52 +0100, Kevin Kofler wrote: Jaroslav Reznik wrote: # votes | name - +-- 1427 | Kevin Fenzi 1247 | Adam Jackson 919 | Tomas Hozza 818 | Parag Nemade 617 | Debarshi Ray ← GNOME developer - +-- 540 | Alberto Ruiz ← GNOME developer 441 | David King ← GNOME developer What does this tell you? :-) Kevin Kofler -- Greetings, Alberto Ruiz Engineering Manager - Desktop Applications Team Red Hat, Inc. -- 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: OpenH264 in Fedora
On Wed, 2013-11-06 at 16:15 +0100, Reindl Harald wrote: It's only a nightmare because we've steadfastly refused to build the tools to a) track library bundling inside app-bundles b) automate bundle rebuilds c) force replacement of bundle contents either by sysadmin action or by policy. Let's not confuse the current state of the world with the world we'd like to build. if you are doing all the above statet you re-invent the wheel currently existing with the name RPM or DEB. Hey Reindl, Quite the contrary, a bundle should not modify the operating system or compromise its integrity, think about it, if a user installs Chrome in Fedora today (and if we render the default Firefox experience unusable for WebRTC, people will) he gets a new Yum repo in its system without any notice... If the RPM repo breaks, yum will stop working... (if some repo fails to answer yum will quit with an error) so with the current model you are encouraging third parties to push for ways to shoot yourself in the foot. Think about it for a moment, we are encouraging third party apps to mess with our entire system just because we don't have any other channel to deliver end user applications or third party extensions (codecs, fonts, ...) than the system wide channel where all the system critical stuff goes to. As I mentioned in another thread, you can deliver those bundles as rpms if we wanted, but they have to be scriptless (pre/postinstall etc) and they need to live in a different yum reposet and rpmdb than the things we consider integral parts of the operating system. -- Cheers, Alberto Ruiz -- 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: OpenH264 in Fedora
On Sat, 2013-11-02 at 21:29 +0100, Björn Persson wrote: Fedora mustn't have third-party repositories like RPM Fusion enabled by default. Users must consciously configure them. Therefore Fedora mustn't download Cisco's binaries by default. It will have to be something that users must consciously configure. It can ask the user whether he wants to opt-in/out for the plugin installation, removing this mechanism at all won't help the users. So what's the big deal? If Cisco goes through with this, then there will be one more free but patent-encumbered implementation. Another implementation doesn't hurt, but I don't see how it solves any fundamental problems. It solves a fundamental problem, you have to pay MPEG-LA a license to distribute binaries, so now we have a source that is willing to produce binaries for as many architectures as we need that are licensed by MPEG-LA. So now any user is one click away from being able to access content widely available in the web (which is sadly going through the HTML5 spec). We still have a problem with MP3, but it does solve a fundamental problem. The only news is that Cisco will hand out blobs with gratis patent licenses for some time. Establishing a standard based on the assumption that Cisco will continue doing that indefinitely seems like a bad idea. Is better than nothing, we can always fall back to what we do now once they stop doing that. -- Cheers, Alberto Ruiz -- 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: OpenH264 in Fedora
On Sat, 2013-11-02 at 18:36 +0100, Kevin Kofler wrote: Michael Catanzaro wrote: Another important point is that future versions of Firefox will download and install (I'm not quite sure where) the binary from Cisco's website, unless some about:config setting is disabled. I imagine this could possibly mean H.264 will work only in Firefox but not other browsers, which would suck. IMHO, having such a setting enabled by default in Fedora is unacceptable. A browser must not go and download binaries which are effectively non-Free wherever the patent holds (because exercising your right to modification under the copyright license voids your patent license) behind the user's back. While I agree that we shouldn't silently install non-free software (and I'm sure Mozilla doesn't want to either), saying that they are effectively non-free is a bit inaccurate, the _binaries_ are not re-distributable under US jurisdiction, access to the source code is granted, which makes them non-US, the software is free (the source license does grant 4 freedoms). There are plenty of countries where software patents are not valid making it perfectly fine. Mind though, there's pretty much no line of code that is not potentially covered by some US patent owned by someone these days. So I'd say that what is broken here is the US patent system not the code, and we have to deal with it. Strictly speaking, we wouldn't be promoting non-free software here, but circumventing a policy that is broken (not so different to what the GPL does). It's a trade off, would you rather have users not being able to play a hugely widespread codec that happens to be free software or would you rather make the default experience in Fedora and Firefox better for our users? I think we should _inform_ users of what's going on when the codec is being downloaded and let them opt-in/out depending on their criteria. There's plenty of people who just want to play a video and do _not want_ to understand the licensing implications, or how to opt-in for a yum repository, or to understand what a yum repository is at all. Passed the point where we made an effort to inform the user I don't think we should design our software in a way that makes it particularly hard to make a choice about how much you care about freedom, after all, you can just go to rpmfusion and/or other repositories and get all sorts of non-us and non-free software if you chose to, it's just harder to do that. The problem is that the people who do not have a grasp on how the underlying system works have a hard time figuring these things out, which takes their away their freedom to make a choice. Otherwise, the perception of people is going to be this: heck, I can't watch videos on Firefox/Fedora and I don't know what to do about it, hence, Firefox/Fedora is pretty bad. So while trying to preserve freedom, you are in fact, harming the perception of the quality of our software and the ability of people to get their stuff done. So my suggestion is that we wait for Mozilla to come up with an actual mechanism to install this, we review it, and we make up our minds about how to preserve freedom of choice while letting the user make an informed decision. -- Cheers, Alberto Ruiz -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 19:00 +0100, Kevin Kofler wrote: Bastien Nocera wrote: As an application developer, I'd sure be happy if I didn't have to wait 6 months for my app to show up in the distribution I use, and for that application to be usable on all compatible distributions. That's a problem with the distribution's update policies, not with the concept of a repository. Sure, that's why an application container would allow for application specific repositories (a.k.a. stores) where apps can reviewed as apps instead of system-wide swappable components. Then you can have a policy that is more suitable to apps with a different cadence than the system-wide (rpm/deb/...) repository, in fact you may not need a cadence at all. It is outrageous that it's 2013 and I still have to upgrade my whole system just to get the latest LibreOffice version to name an example. Kevin Kofler -- Cheers, Alberto Ruiz -- 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: OpenH264 in Fedora
On Mon, 2013-11-04 at 11:28 -0600, Bruno Wolff III wrote: On Mon, Nov 04, 2013 at 15:46:07 +0100, Alberto Ruiz ar...@redhat.com wrote: While I agree that we shouldn't silently install non-free software (and I'm sure Mozilla doesn't want to either), saying that they are effectively non-free is a bit inaccurate, the _binaries_ are not re-distributable under US jurisdiction, access to the source code is granted, which makes them non-US, the software is free (the source license does grant 4 freedoms). There are plenty of countries where software patents are not valid making it perfectly fine. If you don't need to worry about the patents, then x264 (available from RPMFusion) is going to be better code to use for handling h.264. How is the code from RPMFusion any better? And if getting it through RPMFusion is acceptable, why is it suddenly unacceptable to do it trough other means? I don't care about the quality of the code, I just care that my video is decoded. The issue for RTC is that we could be using a royalty free codec, such as VP8 instead. Accepting the binary makes it more likely that h.264 will be made mandatory to implement, which means any company not wanting to implement VP8 can always point to h.264 being mandatory as an excuse not to support VP8. Google gave up on that battle, Mozilla gave up on that battle, and somehow you expect that the Fedora community can somehow turn the tides? There are better ways to push for improvements in this effort (like the Daala codec). The only thing you will achieve by actively pushing this codec out is making the life of the Fedora users more miserable. Nobody cares about the open web more than the Mozilla organization, I'd say their criteria (while subject to review and criticism) should be taken into consideration. Another thing to worry about is how the binary is licensed. Accepting that license (even in places where software patents don't apply) could potentially cause issues. I haven't read the license for it yet, but most likely it will be a typcial consumer license that only covers non-commercial use (similar to what people get when they buy digital movie cameras). Again, the people who have been fighting for open source media Xiph.org and the Mozilla organization have already acknowledge that while this situation is not ideal, is an improvement over the current situation, I'd say we should trust these guys a little when it comes to these things, don't you think? -- Cheers, Alberto Ruiz -- 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: Draft Product Description for Fedora Workstation
On Mon, 2013-11-04 at 12:56 -0500, Matthew Miller wrote: On Mon, Nov 04, 2013 at 06:39:54PM +0100, Kevin Kofler wrote: The reason we are so strongly opposed to app stores is that we are fairly convinced that the mere fact of having them available WILL: * reduce the number of applications actually available in our repositories (because some upstreams will just upload a bundle and tell you to use that, and nobody will want to do the work of actually getting the package through Fedora review), If they're easily available to our users, and work just as nicely or better, why is this a problem? In fact, it kind of sounds like everyone wins! to me. Indeed, this is a relief to the distro community, suddenly you don't have the burden of maintaining all these apps in your system image, avoiding any potential problems on upgrades. It also removes the pressure for the user to have to upgrade his/her whole system just because they want the latest version of an app. It also allows for parallel versions of an app, which means that to test a beta version of, say, LibreOffice, you don't need the beta version of your whole operating system. And the application developer suddenly gains back control on how and when his app gets delivered to users. The only downside is that we are going to have to rewire our brains to stop using yum/dnf to browse/install/remove end user desktop apps. (This, I think, is why this idea gets so much pushback from the distro communities) And, by the way, we've been supporting this kind of model with pip and gem already, so I really don't get why all the fuss when suddenly we want to do it with the desktop applications. -- Cheers, Alberto Ruiz -- 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: OpenH264 in Fedora
On Mon, 2013-11-04 at 18:31 +0100, Kevin Kofler wrote: Alberto Ruiz wrote: We still have a problem with MP3, but it does solve a fundamental problem. We had the same type of solution (just with a different binary producer, Fluendo) offered for MP3. We rejected it, due to both political (effectively unmodifiable binary) and technical (interoperability problems, e.g. with SELinux, that could not be fixed because it was a binary blob) reasons. The compromise that was originally implemented (Codeina, also known as the Codec Buddy, which worked pretty much as you propose) was dropped soon afterwards because the users did NOT like it. (They wanted the libmad plugin rather than the flump3 one, and they also wanted all the other codecs in RPM Fusion for which Codeina either had no alternative or only an expensive paid one. So Codeina just confused them and made it no easier for them to actually get what they wanted. So now we have the PackageKit-based GStreamer codec installer which requires rpmfusion-free-release to be installed to be useful, but then actually offers the codecs that users want.) A user who actually cares about a certain codec implementation and rpm package is presumably a user who is perfectly capable of setting up its own repository (hopefully a fair assumption). They can reject the codec if they're asked, problem solved. At that point the current solution doesn't really help to someone who doesn't know (and I'd go as far as saying, shouldn't know) how to do that. As per other technical/political details, Cisco is not Fluendo, they have shown interest in working with the downstreams on providing binaries for any given platform that they're asked (it's in their interest that this codec works well and is widely available), so we could reach out to them to see if we can solve these problems before rejecting the idea altogether? I seriously don't understand why we want to keep playing media files THIS hard on Fedora. It is the only reason I use RPM fusion. We want to fight the current situation? Let's endorse the EFF as an organization and help them spreading the word on their campaigns to reform US policy. Let's endorse and promote the Daala development to achieve a patent-free techinically superior codec. In the meantime we have to be practical, if Mozilla+Google have failed to push for VP8 and accepted that for now H264 is the way to go, I am afraid that the reality is that by making it hard to get H264 decoding in Fedora for users the only thing we are going to achieve is scaring users away and diminishing the quality perception of Fedora. That is a net loss for free software. Asking people to include an extra repository is no fix, it's not the first nor the second time that my Fedora upgrades break because the rpmfusion packages (specifically GStreamer ones) suddenly has the ability to install any sort of software in my system and mess with the integrity of my rpm database. A media codec should not be a system wide component (I'd go as far as saying it should not be user-session wide, but application bundled). -- Cheers, Alberto Ruiz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
