Re: LibreOffice packages
On Fri, Jun 2, 2023 at 9:40 AM Peter Robinson wrote: > On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen > wrote: > > > > > > > > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen wrote: > >> > >> Lets not make this a drama. > >> > >> Package maintenance changes have never gone through change proposals. > >> > > > > I am sorry, but this was made into a drama by the way this was > executed. Surprise is the opposite of engagement and dropping a ton of > packages and their dependencies and then announcing it is absolute surprise. > > > > This isn't just package maintenance. This is a major change in what is > expected to be included in the next workstation editions with the removal > of expected functionality. If the packages are not picked up within a > certain amount of time or can be rebuilt it means many packages will need > to be edited. Those changes need to be researched, announced, and pushed > through. > > > > It is also drama because people in the community have no idea what else > will take place? When uncertainty and doubt are allowed into the > conversation, people jump to the extremes so they can feel ready to deal > with it. > > > > Could we try something different for future changes? > > 1. Announce that Red Hat will be moving from owning said packages and > dependencies on X date. > > 2. Let people grieve about things for a short while but make it clear > its happening. See if community members or other companies will take up the > burden > > 3. Do the orphan or hand over of packages to the new group. > > > > Instead of 3,1,2? > > That may not always be possible, sometimes it involves departure or > changes of roles for people and those can be delicate and are not > always notifiable. I'm not sure that is the case here but I do know, > from a blog post [1], that the previous maintainer is no longer at Red > Hat. > > Peter > > [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html Yeah, Matthias posting this email was us trying to give the community proper notice. Caolan leaving accelerated things a lot here and also since we felt it correct to inform people about how our plans around RHEL informed this decision in Fedora we needed to spend some time getting internal approval for that, as engineers we don't have the authority to share what could be seen as Red Hat product plans publicly. So while I understand that people like things to be announced with longer horizons it is simply not always possible. We got this message out as soon as we could. Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
Yes, sorry about that meant now of course 😃 On Thu, Jun 1, 2023, 6:45 PM Demi Marie Obenour wrote: > On 6/1/23 15:59, Christian Schaller wrote: > > On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour > > > wrote: > >> Why is a Flatpak a better choice for LibreOffice? > > > > There are a lot of ways to answer this, but from any upstream the > advantage > > of Flatpak is that it means package once and then deploy everywhere. So > it > > saves them work. > > > > From a Fedora perspective there is of course nobody telling anyone to not > > maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but > even > > if nobody does we have a good option available in the Flathub package, > > especially with the Flathub package not being verified as the official > > package of upstream LibreOffice. > > Did you mean “now”? “not” seems like the opposite of your intended > meaning. > > > Having things as Flatpaks is also of value for us to enable long term > > efforts such as Fedora Silverblue. > > > > Hope this answers your question. > > > > Christian-- > Sincerely, > Demi Marie Obenour (she/her/hers) > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour wrote: > > > Why is a Flatpak a better choice for LibreOffice? > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > There are a lot of ways to answer this, but from any upstream the advantage of Flatpak is that it means package once and then deploy everywhere. So it saves them work. >From a Fedora perspective there is of course nobody telling anyone to not maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even if nobody does we have a good option available in the Flathub package, especially with the Flathub package not being verified as the official package of upstream LibreOffice. Having things as Flatpaks is also of value for us to enable long term efforts such as Fedora Silverblue. Hope this answers your question. Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Announcement: fdk-aac
For those interested the bugzilla request for adding this module is here: https://bugzilla.redhat.com/show_bug.cgi?id=1501522 - Original Message - > From: "Tom Callaway" > To: "Development discussions related to Fedora" > , le...@lists.fedoraproject.org > Sent: Thursday, October 12, 2017 12:05:01 PM > Subject: Announcement: fdk-aac > > Hi Fedorans! > > Today, a Third-Party Modified Version of the Fraunhofer FDK AAC Codec > Library for Android has been cleared for inclusion in Fedora. This > specific library has been modified to be useful with Linux and > gstreamer, and provides some support for encoding and decoding of the > AAC digital audio codec. > > The package containing this library is called "fdk-aac". > > No other AAC implementations (regardless of copyright license) are > permitted in Fedora at this time. > > Thanks, > > Tom Callaway > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 System Wide Change: Graphical Applications as Flatpaks
I think this email from Owen summarizes what we need to keep in mind here. Containers have caught on due to solving some important problems and thus people are looking at models for what the future operating system would look like where containers are the primary content delivery mechanism. In Fedora we have efforts arounds Docker/OCI containers and Flatpak containers and we are looking at image based OS installs with the Atomic and Atomic Workstation effort. The fact that we are developing stuff like this in Fedora is a good thing as it means that if it does turn out to be a better model we are well positioned to take advantage of the shift in the market. And if the scepticism some people have about containers turns out to be well founded we still have our RPM based OS to fall back on. So in the long term maybe we will start only shipping containers, if nothing else that is a worthwhile goal for the efforts as it informs the design decisions we take for this like Project Atomic. But having that as a effort goal and it actually becoming the reality is two very different things. If the model works really well, yes maybe we at some point (years) into the future decide to stop doing RPMS (at least as an end user artifact), but in the meantime nobody should feel threatened by the efforts done around containers or modularity. And who knows maybe the future ends up being a bit of a hybrid, Colin Walters is doing great work around rpm-ostree for instance. Christian - Original Message - > From: "Owen Taylor" > To: "Development discussions related to Fedora" > > Sent: Tuesday, July 18, 2017 10:15:12 AM > Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks > > On Tue, 2017-07-18 at 08:35 +0200, nicolas.mail...@laposte.net wrote: > > > > Even if it eventually succeeds crash-landing it in Fedora while > > > > half > > > > the security and management tools are lacking is a great way for > > > > the > > > > distribution to get an awful reputation, while others will rip > > > > the > > > > fruits of this work some years later. > > > I'm entirely puzzled about how you think we could possibly land > > > Flatpak > > > support in Fedora well integrated with our infrastructure, and our > > > security and management tools without starting to work on it, which > > > is > > > essentially what this change proposal is about > > > > Working on it is fine. Improving it is fine. Proposing Fedora- > > generated Flatpacks outside of Fedora is fine. > > If Fedora community members are using Fedora infrastructure to build > Flatpaks that's really by definition part of the Fedora project, isn't > it? > > > Planning to ship stuff as Flatpack only when basic questions such as > > inter-component dependencies, automated deployment (kickstarts), > > actual network and disk use (chromebooks), actual user adoption, > > actual convenience of the security model, etc are not resolved is > > not. > > I think it's important to think ahead and be transparent about what we > are thinking about, so in that sense we're "planning" to ship things > Flatpak only. But I want to be clear that there is no *proposal* on the > table to ship things Flatpak only, and *no proposed timescale*. And > there won't be until we know how the tools work out for packagers, how > Flatpak usage works out for users, and we have a significant body of > Fedora packages built as Flatpaks to look at things like installed size > and network usage. > > These are things we can only get to by building out the infrastructure > so that packagers can start trying building Flatpaks and users can > start trying installing them. > > > That's the hard and tedious stuff most people on this list care about > > and GUI app writers, not a lot. That's the point of no easy return > > where Flatpack is forced on users be it ready or not. > > > There is not a vast amount of trust given past history and the way > > some Flatpack proponents clearly intend to shaft the methods that > > built Fedora (and its userbase) to jumpstart something else. > > It's perfectly fine to be skeptical, it's perfectly fine to ask hard > questions about areas you think need more work. > > But the only way that we get to something that is an evolution of how > Fedora currently works, that pays attention to the needs of current > Fedora users, and builds on the strengths of the Fedora infrastructure > and the people doing all the work in the Fedora community is to work on > it within Fedora. > > Your earlier mail could definitely be taken to mean that we should go > off and work on Flatpak elsewhere, and when we have a fully working > ecosystem elsewhere, and have (on our own, without any engagement) > fully met all the needs of Fedora users, then we can look at > integrating that into Fedora. That sounds hard to distinguish from > ignoring Fedora and starting something else. :-) > > Owen > ___ > devel mailing list
Re: F27 System Wide Change: Graphical Applications as Flatpaks
One major reason is that it enables us to move towards having the Atomic Workstation version be the primary one and maybe in the (very) long run be the only one. A bit more detail about that can be found here: https://fedoraproject.org/wiki/Workstation/AtomicWorkstation Or this talk from FLOCK by Patrick Uiterwijk: https://www.youtube.com/watch?v=zduGfpfwHz4 Christian - Original Message - > From: "Richard W.M. Jones" > To: "Development discussions related to Fedora" > > Sent: Friday, July 14, 2017 4:44:18 AM > Subject: Re: F27 System Wide Change: Graphical Applications as Flatpaks > > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote: > > F29: packagers (of graphical applications) must create Flatpaks of > > their applications if possible. They *may* keep standard RPM > > packaging. > > At least we see where this is going. > > If RPMs of the graphical application work fine now, what on earth is > the point of forcing packagers to make Flatpaks? Sandboxing isn't one > of them - as already explained, sandboxing is orthogonal to packaging. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mp3 encoding now ok
Hi, not sure why Spot hasn't chimed in, but yes this has been run through legal. Tom and I where on the same email thread with the laywers. Of course on top of that the fact that they shut down the mp3licensing operation is a pretty strong sign :) Christian - Original Message - > From: "Jon" > To: "Development discussions related to Fedora" > > Sent: Wednesday, May 3, 2017 4:57:18 PM > Subject: Re: mp3 encoding now ok > > Normally Spot would revel these kind of topics. > > Where are you Spot? > > Have you run this topic through RH legal? > > Presumably one does not need legal sign-off when patents legally > expire, but this topic is significant. > > We can now package mp3 encoding software. > > That is a big thing. > > --Jon > > On Wed, May 3, 2017 at 3:13 PM, Christian Schaller > wrote: > > Thanks, hadn't seen that. Ok, well I guess they do deserve some credit for > > owning up to > > their patents having expired. I am sure there are others out there who > > would keep > > claiming they still had IP in the hope of creating enough uncertainty to > > get at least > > some people to keep paying. > > > > Christian > > > > > > > > - Original Message - > >> From: "Jon" > >> To: "Development discussions related to Fedora" > >> > >> Sent: Wednesday, May 3, 2017 2:59:32 PM > >> Subject: Re: mp3 encoding now ok > >> > >> From the source: > >> > >> """ > >> On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 > >> related patents and software of Technicolor and Fraunhofer IIS has > >> been terminated. > >> """ > >> > >> https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html > >> > >> --Jon > >> > >> On Wed, May 3, 2017 at 1:29 PM, Denise Dumas wrote: > >> > Congratulations!!! > >> > > >> >> On May 3, 2017, at 1:45 PM, Christian Schaller > >> >> wrote: > >> >> > >> >> Hi, > >> >> So just wanted everyone to know that we now have the go ahead to ship > >> >> mp3 > >> >> encoding in Fedora too. So anyone involved with packaging > >> >> mp3 encoders can now start migrating them to the Fedora repositories. > >> >> We > >> >> are still in the process of evaluating other codecs. > >> >> > >> >> Christian > >> >> ___ > >> >> devel mailing list -- devel@lists.fedoraproject.org > >> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> > ___ > >> > devel mailing list -- devel@lists.fedoraproject.org > >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> > >> > >> > >> -- > >> > >> -Jon Disnard > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > > -Jon Disnard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mp3 encoding now ok
Thanks, hadn't seen that. Ok, well I guess they do deserve some credit for owning up to their patents having expired. I am sure there are others out there who would keep claiming they still had IP in the hope of creating enough uncertainty to get at least some people to keep paying. Christian - Original Message - > From: "Jon" > To: "Development discussions related to Fedora" > > Sent: Wednesday, May 3, 2017 2:59:32 PM > Subject: Re: mp3 encoding now ok > > From the source: > > """ > On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 > related patents and software of Technicolor and Fraunhofer IIS has > been terminated. > """ > > https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html > > --Jon > > On Wed, May 3, 2017 at 1:29 PM, Denise Dumas wrote: > > Congratulations!!! > > > >> On May 3, 2017, at 1:45 PM, Christian Schaller > >> wrote: > >> > >> Hi, > >> So just wanted everyone to know that we now have the go ahead to ship mp3 > >> encoding in Fedora too. So anyone involved with packaging > >> mp3 encoders can now start migrating them to the Fedora repositories. We > >> are still in the process of evaluating other codecs. > >> > >> Christian > >> ___ > >> devel mailing list -- devel@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > > -Jon Disnard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
mp3 encoding now ok
Hi, So just wanted everyone to know that we now have the go ahead to ship mp3 encoding in Fedora too. So anyone involved with packaging mp3 encoders can now start migrating them to the Fedora repositories. We are still in the process of evaluating other codecs. Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: YAST for Fedora?
Actually isn't Cockpit our 'YAST', I mean it is not a 1to1 thing, but for a lot of things Cockpit provides the featureset a sysadmin would want. Christian - Original Message - > From: "Adam Williamson" > To: "Development discussions related to Fedora" > > Sent: Thursday, April 13, 2017 2:02:57 AM > Subject: Re: YAST for Fedora? > > On Thu, 2017-04-13 at 04:05 +, Farhad Mohammadi Majd wrote: > > Hello, SUSE distributions have a system control panel that can configure > > many aspects of the system. It is the best feature I saw in SUSE, it is > > very interesting, useful and beneficial for all users. > > > > * Why Fedora does not have such tool? > > Because we think it's fundamentally a wrong approach. Several years > ago, Fedora decided it really wasn't the right approach for > distributions to build unique layers of configuration tools, and we've > been systematically *removing* the tools we used to provide along those > lines (system-config-*) in favour of: > > i) just getting things right so we don't need a giant pile of > configuration tools > ii) tools written at more appropriate layers, mainly desktop > environments > > > * How much money is need to develop such tool from scratch or port it from > > SUSE to Fedora/RHEL? > > It's not really a question of resources, but of not thinking this is > the correct approach. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The glvnd + mesa update for F25
- Original Message - > From: "Rich Mattes" > To: "Development discussions related to Fedora" > > Sent: Tuesday, February 7, 2017 12:33:45 PM > Subject: Re: The glvnd + mesa update for F25 > > On Tue, Feb 7, 2017 at 6:00 AM, Hans de Goede wrote: > > Hi, > > > > On 06-02-17 23:01, Jan Pokorný wrote: > >> > >> On 06/02/17 15:13 -0500, Christian Schaller wrote: > >>> > >>> There has been a lot of discussions for the last few years about glvnd on > >>> the mesa-devel list and at XDC. This is not Fedora specific technology, > >>> but > >>> a change in how Mesa will work everywhere and thus there has not been a > >>> lot > >>> of discussions about it here on Fedora-devel. But that is true for most > >>> stuff, > >>> we do not discuss major new kernel features here that much either as one > >>> example. > >> > >> > >> I don't think that's a fair point. If there was an artificial > >> intermediate level put in front of libc that would only be to > >> solve issues with some hardware component, and it would be forcibly > >> implanted into Fedora unnecessarily for all audience, then it would > >> be comparable. > >> > >> But even then, I doubt it would happen without questioning such > >> aspects. > >> > >> Forcing glvnd for all is Fedora specific, as far as I can tell. > > > > > > I just got asked a bunch of question by the Debian X / mesa > > maintainer about glvnd since he is working on moving Debian over > > to this too. Really there is nothing Fedora specific about this. > > > > The change to mesa isn't fedora specific. How and when we test and > integrate that change (and other large, potentially breaking changes) > with the rest of the software in the distribution is what's fedora > specific. That's what needs to be discussed on the list, and it's why > the change process exists. I fully agree, but my response was not to an email arguing about timing, but one questioning the legitimacy of the change and the level of community vetting it had seen. > Kernel changes are a bad example to prove your point, for a number of > reasons. The kernel is specifically exempted from the stable update > guidelines, and can be updated at any time. Kernel upstream has a > policy about not breaking userspace, so most changes that aren't bugs > are just extended functionality. That said, the kernel team has been > emailing the devel list lately with their plans for when major kernel > releases will hit each branch. > > Rich > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The glvnd + mesa update for F25
There has been a lot of discussions for the last few years about glvnd on the mesa-devel list and at XDC. This is not Fedora specific technology, but a change in how Mesa will work everywhere and thus there has not been a lot of discussions about it here on Fedora-devel. But that is true for most stuff, we do not discuss major new kernel features here that much either as one example. Christian - Original Message - > From: "Jan Pokorný" > To: devel@lists.fedoraproject.org > Sent: Monday, February 6, 2017 2:32:35 PM > Subject: Re: The glvnd + mesa update for F25 > > On 06/02/17 05:06 +0100, Kevin Kofler wrote: > > Hans de Goede wrote: > >> libglvnd is a solution for this it is a vendor neutral > >> implementation of libGL.so.1 which acts as a dispatcher > >> to one or more glvnd enabled libGL implementations > >> installed on the systems. > > > > By doing so, it decreases performance for all the users of the Mesa > > drivers by adding an unnecessary layer of indirection. I do not see > > performance being addressed at all in any of your communication, did > > you even try to measure the impact of the added indirection layer? > > These are the thoughts that crossed my mind as well, I'll admit. > > Do we have any sort of measurements or at least the related theoretical > backgrounds, such as "indirection will impose a small slowdown, but > only at the very initial phase of execution till all the necessary > symbols are resolved, no effect since then"? Is it in fact worse? > > The fact there was no serious discussion about the change is rather > unsettling, IMHO. > > -- > Jan (Poki) > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The glvnd + mesa update for F25
- Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Sunday, February 5, 2017 11:06:36 PM > Subject: Re: The glvnd + mesa update for F25 > > Hans de Goede wrote: > > First the what: ever since AMD and NVIDIA started shipping > > their own Linux drivers we have had multiple competing > > implementations of libGL.so.1 (and friends) where the way > > the linker works means that there can be only one. > > This has made installing AMD or NVIDIA's drivers harder > > then it has any rights to be and this has been hurting > > out users, some of which want to use the vendor supplied > > drivers. It often causes broken systems and makes > > switching between drivers unnecessarily hard. > > Whoever wants to use proprietary blobs that do not make use of the driver > infrastructure in the distribution is on their own. All the drivers we ship > in Fedora use the Mesa libGL, so there is no need for any "dispatcher". Sorry, the real world doesn't work this way. Since we have a goal for Fedora Workstation to actually have users we want to try solve the problems our users actually have rather than just pontificate to the five people who failed to leave the room quick enough. > If only the time wasted on making this work had been spent on making Nouveau > better instead… Or in other words if people like yourself actually bothered contributing to Nouveau instead of wasting their time other projects. If you want Nouveau to be more widely used then the way to make that happen it to work with us making Nouveau better. Bitching that the people already putting a ton of resources into Nouveau are not putting even more resources into it is just coming across as a someone lacking any kind of self awareness, who condemns others for failing to live up to a measurement he fails to living up to himself. Christian Christia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 25 defaults to X instead of wayland
My guess is that you have a system with hybrid graphics, we made it default to X since the support for hybrid graphics is not available fully in Wayland yet. We hope to land that for F26. Christian - Original Message - > From: "Timothy Ward" > To: devel@lists.fedoraproject.org > Sent: Sunday, February 5, 2017 5:40:33 AM > Subject: Fedora 25 defaults to X instead of wayland > > Just wanted the links to more information on what will cause gdm and > session manager to default to X instead of wayland. > > Have a laptop and desktop with fully updated system with debug package > repos active and both systems default to X and will not start on > wayland. > > This was not he case with Fedora 24 where you could select in the gdm > login screen and end up with the chosen session. > > At the moment both gdm and and session default to X under gnome. > > Gdm debug log confirm the fallback but does not provide descriptive > error messages why. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
While most desktop applications have migrated to 64 bit at this point there are still many that hasn't. Steam for instance is still 32-bit afaict. So doing a clean cutover like this feel a bit to drastic to me and I am not sure we have the market power to 'force' vendors to quickly migrate to containers. Christian - Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Thursday, January 5, 2017 11:03:50 AM > Subject: Proposal: Rethink Fedora multilib support > > # Overview > > For many years, Fedora has supported multilib by carrying > parallel-installable > libraries in /usr/lib[64]. This was necessary for a very long time in order > to > support 32-bit applications running on a 64-bit deployment. However, in > today's > new container world, there is a whole new option. > > I'd like to propose that we consider moving away from our traditional > approach > to multilib in favor of recommending the use of a 32-bit container runtime > when > needed on a 64-bit host. > > > ## Advantages > > * Simplification of build-tree creation. We wouldn't have to maintain the > lists > and hacks that are required to make sure that multilib packages land in the > correct repositories. > > * Less duplication of content in the mirror networks. > > * It will be simpler to create module content without having to reimplement > all > the multilib hacks of above. This is directly relevant to the Base Runtime > module, whose prototype is today intentionally limited to the primary > architecture (no multilib). > > * Requires us to maintain and keep up-to-date the 32-bit container base > images. > > > ## Disadvantages > > * If we eliminate multilib entirely, all applications that use 32-bit libs > will > have to either install a 32-bit host OS or install into a container. This may > be > a difficult transition for some users. > * Mitigation: develop and maintain tools to ease this transition. > > * It is unlikely that any clean upgrade path would exist. (We could make it > *technically* possible, but likely not without breaking 32-bit software not > installed by RPM. > > * Requires us to maintain and keep up-to-date the 32-bit container base > images. > (Yes, this is both an advantage and disadvantage.) > > > ## Open Questions (non-exhaustive): > > * Can SSSD and systemd's 32-bit name-service modules work from within a > container, talking to their host's service? Without that, 32-bit containers > won't be able to resolve users, groups or hostnames. > > * Can we have 32-bit containers communicate with other local system APIs such > as > D-BUS on the host? > > * Do we need to care about 32-bit GUI applications on a 64-bit system? Should > we > decide that flatpak is the official answer for such cases? > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GSequencer upstream wants to package for fedora
That is a lot of different things mashed into one here, and while I can not even begin to understand how you can bash our commitment to Free Software and at the same time be an argent backer of Shuttleworths Snappy is beyond me, but I am sure is somehow makes sense to you. Also I don't think it is true in any way or form that the Working Group is discouraging people from making RPMS, in fact I have personally talked to a lot of different companies and people over the last year encouraging to them to make RPMS. And Bastien Nocera who was the one on this thread encouraging making a Flatpak is not a Working Group member, in fact he is just a community member doing what he has every right to do, which is to advocate the solution he thinks is best for the problem at hand. And you of course have every right to advocate for a different approach, but I don't see why you think slagging the Workstation Working Group somehow is the correct response. The proposals you misrepresent so wonderfully was a general issue of how do we deal with the same application being available in multiple formats, which is not even limited to RPM and Flatpak. Offering users 10 versions of the same application at the same version number with the only difference being the package technology used is confusing and stupid. And we need to have a policy for dealing with it and dealing with the fact that the recommended packaged version of an application might change their package format over time. This could go both ways, but of course since we have mostly RPMS these days the likelyhood is that at least in the beginning the most common case will mostly be away from RPMS. And to be clear the working group isn't spending time trying to figure out how we can offer the Gimp as a Flatpak for example, just because it is not a very interesting problem to solve, since we already have the Gimp as an RPM. Instead we are focusing on using Flatpaks as a method for bringing new applications to the Fedora ecosystem. Christian - Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Sent: Wednesday, December 14, 2016 10:52:37 AM > Subject: Re: GSequencer upstream wants to package for fedora > > On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller > wrote: > > That is not 100% correct. You can make a non-sandboxed Flatpak and > > it would work just as well as an RPM in terms of hardware access. > > Enabling sandboxing however would need some thought and development > > for a lot of such applications, but we are slowly but surely working > > on it through things like the PulseAudio and Pinos work that Wim Taymans > > is doing, and through the work that Alex Larsson has been doing with > > OpenGL. > > There's also the fact that the runtimes provided also crash on most of > my computers, but hey, that's just a small thing, right? > > Speaking with my Fedora and Mageia hats, there's nothing that stops > ANYONE from making portable RPMs (I've done it fairly easily myself). > Flatpak, AppImage, Snappy, etc. do not provide any material advantages > without some sandboxing. In fact, they just make applications more > bloated for little to no benefit at that point. > > IMO, the only reason that we're starting to see this is because we're > increasingly giving up on Free Software (note capital letters). These > systems primarily benefit nonfree/proprietary software developers. > > Speaking with my Snappy hat on, the concept of making it possible for > people to make applications that work everywhere and anywhere is a > very nice dream. But it's important to realize that the integration > work has to happen somewhere. Flatpak is moving too slowly in this > regard, and while Snappy has this functionality in spades, it requires > much deeper integration into the distribution than Flatpak does. The > main things keeping snaps from being a first class citizen on Fedora > are the inability to produce snaps based on a Fedora base and Fedora > packages (that's being worked on) and the lack of SELinux integration > (also being worked on). > > I've personally been working on these things for the Snappy system, > but the Flatpak guys seem to be doing *nothing* about it. I'm very > disappointed in the progress of the Flatpak system. > > To date, it is still not possible to install Flatpaks through Plasma > Discover like it is through GNOME Software. It is not possible to > build Flatpaks from RPMs in such a manner where Fedora-based runtimes > could power software. (Hint: both GNOME and KDE app stores support > Snappy!) There is no evangelism from the people working on Flatpak to > demonstrate the technology and drive any useful interest. The > sa
Re: GSequencer upstream wants to package for fedora
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL. Christian - Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Sent: Wednesday, December 14, 2016 10:21:32 AM > Subject: Re: GSequencer upstream wants to package for fedora > > On Wed, Dec 14, 2016 at 10:17 AM, Bastien Nocera wrote: > > You're right, it's better :) > > > > Not really. Flatpak is incredibly limited in its abilities. > Applications that interface with hardware directly are out of the > question, for example. That means lots of pro-AV applications simply > won't work properly in that environment. > > > > -- > 真実はいつも一つ!/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora captive portal page changed output :(
Actually, I was told that Debarshi committed a fix for the TLS error in captive portal just last week and has pushed a fix for it. Christian - Original Message - > From: "Michael Catanzaro" > To: "Development discussions related to Fedora" > > Sent: Monday, December 5, 2016 1:16:08 PM > Subject: Re: Fedora captive portal page changed output :( > > On Mon, 2016-12-05 at 09:59 -0500, Paul Wouters wrote: > > Right now, the situation leads me to having to close the gnome window > > which only displays "TLS certificate invalid" or some text like that, > > and still use my firefox and a new tab/window to get through the > > captive portal. > > Good point. I guess ignoring TLS errors might mean better overall > safety here. :/ At least for the next couple of years. > > Ideally we would fix this bug before making any changes to that: > > https://bugzilla.gnome.org/show_bug.cgi?id=749197 > > It's assigned to me, which means I'll do it eventually for some value > of eventually; help always welcome > > > In which case we are exposing the full firefox with > > all my privacy settings and cookies to the captive portal, instead of > > (what I hope to be) some "private window" gnome web browser that has > > no access to any of my personal data. So I'd rather see the gnome > > window ignoring the TLS error and proceeding. > > Unfortunately you hoped too much, looks like it's using default WebKit > data directories. I think it probably can't read your cookies from > other apps as cookies work a bit differently, but it is getting > everything else from the default WebKit data dirs. It really should use > a private data dir, which is very easy to fix; then that would avoid > any concerns about caching as well. Modified bug report: > > https://bugzilla.gnome.org/show_bug.cgi?id=775639 > > BTW, full portal helper bug list: > > https://bugzilla.gnome.org/buglist.cgi?quicksearch=component:portal-helper%20product:"gnome-shell"%20&list_id=173288 > > Michael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: wayland in rawhide
- Original Message - > From: "Josh Boyer" > To: "Development discussions related to Fedora" > > Sent: Wednesday, November 11, 2015 8:05:27 PM > Subject: Re: wayland in rawhide > > On Wed, Nov 11, 2015 at 7:58 PM, David Airlie wrote: > > > >> That's fine. I don't have a problem adding "GNOME on Xorg" option to > >> the session > >> menu in the interim. I'll do it tomorrow. > > > > This is what the feature page said would happen in the first place. So > > I'm also confused why you didn't just do that. > > > >> > >> I will say you're coming off (to me anyway) as somewhat combative. We're > >> on > >> the same team here. Let's keep it constructive and friendly? > > > > Okay, I'll try and be a little less pissed off at disabling features users > > use, that we've spent years implementing in X/GNOME. > > > > The fact you are requesting wayland by default while we still have the > > following list: > > > > Close all remaining feature parity gaps between the Wayland and the X11 > > session: > > > > input methods > > on-screen keyboard > > hi-dpi support > > clipboard proxy for xwayland > > attached modal dialogs > > tablet support > > startup notification > > touch proxy for xwayland > > accessibility features > > output rotation > > > > These are just the missing features (never mind dialog boxes in wierd > > places bugs) > > and it doesn't even contain the USB output hotplugging, or secondary GPU > > output use cases. > > > > So maybe I'm getting old, but I thought we were over shoving half-baked > > onto users now, > > Maybe implement all those features, get them into the non-default wayland > > session, > > then go lobby for enabling the wayland session by default, otherwise I feel > > you are > > putting the cart before the horse. > > Is the concern mostly about switching to it by default and then > somehow users won't know how to switch back to X to get their missing > features? > > I'll admit that given some of the target audience we've pushed for > where they expect things to "just work", that might be a valid > concern. If they log into an F24 Gnome session and the above things > don't work, they won't view it as "oh Wayland." They'll view it as > "oh, regression" and likely not look at "X/Gnome" as a choice to fix > all of it. > > There is definitely a degree of lower-level understanding required to > get back to a "normal" state in that case. And it isn't like people > are going to use many of those features in GDM heavily enough that > they'd edit the conf file to switch GDM itself to X. > > I have no idea if it's possible to detect usage of the above features > in existing installs and not default to Wayland in that case. Or if > it's possible to switch to X if a user turns on one of the features on > a new install. We do expect to get all of these resolved during the Fedora 23 lifecycle, the reason we are switching Rawhide is to push more people to get involved with finding and fixing the issues we do not know about yet. This is a major change for us as a project and we need to take collective ownership of it, if we expect to be able to sit back and let a few dedicated people pull the load alone here we are setting ourselves up for failure. And let it be clearly said if we do not get these items resolved in time for Fedora 24 we will not switch to Wayland as default in Fedora 24. There are some items, like binary driver support, that are not likely to be resolved for Fedora 24, but for those the automatic X fallback should kick inn. Christian -- 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: fedup for F23 and beyond
Sounds great, I know Allan and Richard has some mockups for how they want to do upgrades in GNOME Software, so hopefully this will make it even easier to implement. Christian - Original Message - From: "Will Woods" To: devel@lists.fedoraproject.org Sent: Thursday, May 28, 2015 11:42:56 AM Subject: fedup for F23 and beyond [tl;dr: fedup is going away and should be re-implemented by the system packaging tools.] Hey all, F22 is the fifth release we've handled with fedup. A lot has changed since F17, and we've learned some valuable lessons about how upgrades work (and how they fail). We've come to the conclusion that the current design is unsupportable, mostly due to upgrade.img, which turns out to cause more problems than it solves[1]. So! For F23, fedup needs to be redesigned. Here's how it should work: 1) Download packages for the new system 2) Use the systemd Offline Updates[2] facility to install packages This is really simple - simple enough that it should probably be provided by the system packaging tools themselves. As a proof-of-concept, I've implemented it as a DNF plugin, which you can see here[3]: https://github.com/wgwoods/dnf-plugin-fedup This behavior could also be implemented by PackageKit, which would make it easy to write a proper GUI. So that's the plan: drop upgrade.img, move upgrade support into the system packaging tools. Sometimes simpler is better. -w [1] For example, here are three F22 release-blockers, all caused by upgrade.img: https://bugzilla.redhat.com/show_bug.cgi?id=1185604 https://bugzilla.redhat.com/show_bug.cgi?id=1209941 https://bugzilla.redhat.com/show_bug.cgi?id=1207251 That first one is a nasty crash inside systemd, which led to a mailing-list discussion[1a] where Lennart concludes that the double-switchroot thing we're doing with upgrade.img is just not supportable[1b]. And I totally agree. [1a] http://lists.freedesktop.org/archives/systemd-devel/2015-March/029030.html [1b] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031013.html [2] http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ [3] It works just fine in F21, if you're feeling brave.. -- 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: Testing request: gdm-on-Wayland on hybrid graphics laptops (esp. Macbooks)
Hi William, please add yourself to the bug and of course provide any information you can provide. We need to know more about the scope of this to be able to determine if its a blocker or not. Of course our challenge is that until we have a way to reproduce on a system our devs can look at or get logs that helps us understand what is happening it is hard to fix. Christian - Original Message - > From: "William" > To: devel@lists.fedoraproject.org > Sent: Thursday, May 14, 2015 7:39:10 PM > Subject: Re: Testing request: gdm-on-Wayland on hybrid graphics laptops > (esp. Macbooks) > > On Thu, 2015-05-14 at 13:01 -0700, Adam Williamson wrote: > > Hi folks! > > > > We have a somewhat-worrying proposed blocker for F22: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1218787 > > > > it appears that after a successful installation of Workstation on the > > affected system, GDM-on-Wayland fails to start correctly but also > > does > > not fall through (as it should) to GDM-on-X, leaving the user with a > > black screen and no obvious way to proceed. This is obviously a bad > > bug, but so far it has only been observed on one test system (a > > Macbook > > Pro 8,2) by one tester. A few other testers have tried to reproduce > > on > > other hybrid graphics systems, but have not been able to. > > > This has affected my MacbookPro 8,2 for about a year. I want to see > this as a blocker, so that it is taken seriously as the issue has gone > otherwise ignored. This affects straight Xorg, not just Wayland. > > -- > William > -- > 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: "Workstation" Product defaults to wide-open firewall
- Original Message - > From: "Reindl Harald" > To: devel@lists.fedoraproject.org > Sent: Tuesday, December 9, 2014 10:04:46 AM > Subject: Re: "Workstation" Product defaults to wide-open firewall > > > Am 09.12.2014 um 15:57 schrieb Christian Schaller: > > Well I think it is hard for anyone to guess what would be reasonable > > defaults for > > you specifically, any default is by its nature just targeting an generic > > person, which might or might not be a lot like you. > > > > But if you are aware and understand the finer details here then it isn't > > that > > big a job to change it, you should be able to go into the network manager, > > choose your > > connection, choose 'identity' (should probably be moved to be under > > security?) and change > > the zone for your network to whatever suits you better. > > and why can't you do the same if you want it open instead start > wide-open and expect from people to secure their system I think the part of the sentence you probably missed was "if you are aware and understand the finer details here", because for anyone who doesn't understand the finer details here you are suggesting we default the system to 'broken'. > how long do you think does it take until someone is so audacious and > installs mysql and apache with the intention just to develop some > webscripts on his workstation *beause* he want only play around with it > not imaging that his mysqld is open to the world and not just localhost? > > the same applies for *any* other service in /etc/services with a port > number above 1024 - ship unsecure defaults and expect users to secure > their machines is pervert - that won't happen, sooner or later damage > will happen and nobody feels responsible -- 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: "Workstation" Product defaults to wide-open firewall
- Original Message - > From: "Gerd Hoffmann" > To: "Development discussions related to Fedora" > > Sent: Tuesday, December 9, 2014 10:22:01 AM > Subject: Re: "Workstation" Product defaults to wide-open firewall > > On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote: > > > > - Original Message - > > > On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: > > > > Why we can't have something like this? And if you don't want a popup > > > > asking, have something in the NetworkManager applet menu, where people > > > > can easily find the switch without having to search for it? A "[x] > > > > allow sharing" checkbox? A firewall zone selector? > > > > > > We can — we just need someone to design and write it. > > > > A design for something that we don't want to implement. This was one of the > > options when implementing the feature, one that we didn't pursue. We chose > > instead to use "user intent" as a way to do this. > > > > If you start sharing something on a network, then we consider it safe to > > share. > > If you connect to a public unencrypted Wi-Fi, you won't have the option to. > > If > > you connect to an encrypted Wi-Fi where sharing your holiday photos isn't > > acceptable > > then it won't, because you didn't ask it to in the first place. > > That assumes all applications behave that way. Which simply isn't true, > there is a world outside gnome. You apparently choose to ignore that, > which is a bad idea IMO. Well we are not shipping by default anything which doesn't conform to this, and if you go out of your way to install something I don't think it is far fetched to assume you want that thing to work. Christian -- 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: "Workstation" Product defaults to wide-open firewall
- Original Message - > From: "Brian Wheeler" > To: devel@lists.fedoraproject.org > Sent: Tuesday, December 9, 2014 9:18:47 AM > Subject: Re: "Workstation" Product defaults to wide-open firewall > > On 12/09/2014 08:50 AM, Richard Hughes wrote: > > > > On 9 December 2014 at 13:39, Michael Catanzaro wrote: > > > > So your challenge is to find an alternative default that > supports it. > I'd go even further. I don't think the people writing the vast number > of lengthy posts on this thread actually want to *use* workstation, > with the possible exception of Bastien who's having to defend > something he shouldn't have to. Reindl probably should just use the > server spin, or be prepared to actually configure his box to do what > he wants to be 100% paranoid and unusable for anything less than a > technical user. If you don't like what workstation has decided to do, > use another target, or a different distro entirely (like CentOS). If > you want to change how workstation is designed, join the working group > and please actually talk to people there. I think it's misguided to > think that hurling insults here is going to achieve change. > > I think a lot of people also need to remember that workstation isn't > built for them, and that's okay. If you know how to configure iptables > then that's fine, but I'm happy to admit I don't, and normally just > switch off the firewall entirely so I can get stuff done. F21 will be > more secure for me, not less. > > Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use > Fedora on my desktop & laptop. I expect the firewall to be on so when I > evaluate a new piece of software or do a bit of network development I don't > inadvertently increase my exposure. I also expect things to work with the > minimum amount of fuss. > > So it looks like my choices boil down to: > * Use the workstation project and spend a bunch of time locking it down to > what would be reasonable default for the networks I use -- and hope I don't > miss anything. Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. Christian > * Use the server product and manually configure all of the workstation stuff > so I get a usable system > > Neither of those choices seem reasonable to me, especially compared to the > status quo: a fully configured workstation where I open new ports as I > increase functionality. > > > > -- > 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: "Workstation" Product defaults to wide-open firewall
- Original Message - > From: "Robert Marcano" > To: "Development discussions related to Fedora" > > Sent: Tuesday, December 9, 2014 8:57:51 AM > Subject: Re: "Workstation" Product defaults to wide-open firewall > > On 12/09/2014 08:53 AM, Reindl Harald wrote: > > > > > > Am 09.12.2014 um 14:16 schrieb Bastien Nocera: > >>> On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: > Why we can't have something like this? And if you don't want a popup > asking, have something in the NetworkManager applet menu, where people > can easily find the switch without having to search for it? A "[x] > allow sharing" checkbox? A firewall zone selector? > >>> > >>> We can — we just need someone to design and write it. > >> > >> A design for something that we don't want to implement. > > > > and that is the point - you do not want and care because you seem to > > think users are too stupid to make their own decisions - you know what > > Linus said to that in direction of GNOME? > > > >> This was one of the > >> options when implementing the feature, one that we didn't pursue. We > >> chose > >> instead to use "user intent" as a way to do this. > >> > >> If you start sharing something on a network, then we consider it safe > >> to share. > > > > the problem is that you don't know *who* or *what* opened the port > > Exactly, I think some people think we already reached the utopic world, > when everyone install FLOSS applications from the repositories, and no > one uses closed source applications, or worse where all sharing is done > using GNOME control panel, and there isn't applications that doesn't > take into account the GNOME way of doing things. > > What I see frequently are applications that are installed from outside > the Fedora repositories, that can be forced to behave like Fedora > packaging rules, with secure defaults before sharing, being installed > and the user that don't know much about firewall settings but understand > that the firewall is active, then think: I feel "secure" because I know > the firewall is blocking external requests. Speaking from personal experience my thoughts was never 'I feel so safe', instead I just felt annoyed that for the gazilliont time things didn't work due to the firewall blocking the application or service or I was trying to run. And after trying to Google and only finding Ubuntu specific commands that never seemed to work or commands which was only relevant to Fedora 12, I tended to disable the firewall while asking myself while after all these years things still sucked as much. Christian > and then in that utopic world things fail, for example, Fedora packaging > rules prefer that packages are installed with sensitive defaults, I > reported a bug about all cron email output being sent by default and it > was discarded as a security bug (pulled by an update) > > https://bugzilla.redhat.com/show_bug.cgi?id=1157727 > https://bugzilla.redhat.com/show_bug.cgi?id=1158493 > https://lists.fedoraproject.org/pipermail/devel/2014-October/203781.html > > This is no open port, but shows that packages can have bugs and > something that is closed by default today, can in the future be pulled > as an update and start sharing things. Those are bugs, true, but the > idea of opening the firewall entirely defeats the measure of defense > already in place. To me it sounds like disabling SELinux on workstation > because people find it difficult and decide to disable it instead. > > The problem that is being tried to "solve" is that people choose to > disable the firewall, Why not add a simple option to the GNOME sharing > tools to change the firewall zone to this one where ports >1024 are open > when the user decide to share something. with the possibility to > selecting no for those people that only want to open the only the needed > ports? > > Note: I hope to not be called a troll here (joke, someone will understand) > > > > >> If you connect to a public unencrypted Wi-Fi, you won't have the > >> option to. If > >> you connect to an encrypted Wi-Fi where sharing your holiday photos > >> isn't acceptable > >> then it won't, because you didn't ask it to in the first place > > > > besides suspend / move machine > > > > a sane firewall design (sadly Windows has that in the meantime) is that > > if i open a port in my homenetwork, supsend the machine and wake it up > > in a foreign network ports are closed until i decide to open them there > > too, but Fedora goes the easy way "who cares how and why as long things > > appear to work" > > > > *who* told you that people don't share things *unintentional* by a wrong > > click which is *not* a problem until you decide to open ports > > > > > > > > -- > 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://adm
Tasklist for the Fedora Workstation
Hi everyone, As we are ramping up the development effort around the workstation we wanted to help increase transparency and enable more community participation in the Fedora Workstation effort by providing a more detailed view of the various tasks underway as derived from the more high level PRD and Technical Specification documents. You can find the current version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but we hope to expand on it in the coming days and weeks to be even more comprehensive and also include more explanations around the motivation for each task. The list enumerates the various efforts that is being undertaken around the Fedora Workstation effort and also puts a name next to many of the items. If you are interested in helping out with any of these efforts please get in touch by reaching out either to the Working group board members or to the people listed next to the tasks in question. For those of you not familiar with the working group we have contact information and board membership information available on this page: http://fedoraproject.org/wiki/Workstation If you are getting this email you probably already know about the mailing list, but the working group can also be reached on IRC on #fedora-workstation on freenode. Looking forward to discussing our plans with both new and old contributors to the workstation product effort. Feel free to ask questions about the various tasks as I realize that the list is quite low on detail atm., and not all items might be self explanatory and as mentioned we do hope to add more detailed information to each item in the next few days. Sincerely, Christian Schaller -- 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: The Forgotten "F": A Tale of Fedora's Foundations
- Original Message - > From: "Stephen John Smoogen" > To: "Development discussions related to Fedora" > > Sent: Thursday, April 24, 2014 6:46:03 PM > Subject: Re: The Forgotten "F": A Tale of Fedora's Foundations > > > > > On 24 April 2014 09:56, Stephen Gallagher < sgall...@redhat.com > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/24/2014 11:01 AM, Stephen John Smoogen wrote: > > > > > > > > On 24 April 2014 02:49, Christian Schaller < cscha...@redhat.com > > > wrote: > > > > Well my point is I spoke to Red Hat legal before I even posted the > > original proposal to open up to more 3rd party repositories some > > Months ago. There are a lot of repositories that it is perfectly > > fine for Fedora to include from a legal perspective. But they will > > need to be reviewed by legal on a case to case basis, going to > > legal up front and saying 'hey can I include a hypothetical > > repository' will only yield you the answer 'depends on the > > repository'. > > > > > > OK cool. What is the plan for when repositories change what they > > are carrying and add stuff that may be legal for them but not for > > others? Will there be periodic reviews to make sure that this > > hasn't happened or some way that we roll back what repositories we > > recommend? > > > > > At the risk of being glib: What's the plan for periodically > re-reviewing every package in Fedora to make sure that its sources > always remain legal? > > It's the same problem and it can only realistically be dealt with by > "If someone notices, deal with it then." > > There are a couple of differences. If we find that dvdcss was added to a > package, we can rip out that package, put an update in the repository and > people who do updates get a package without dvdcss. A third party repository > is one we don't have any control over. If code that the 3rd party has no > legal right to ship or fill in problem here, what is our remediation to our > users? Are we in contributary infringement because we gave the users a way > access to pirated software that we never intended in the first place? Is > there an agreement between us and the third party that they are to be > offering X, that they are legally able to offer X, and that if they are not > they are to take all liability of offering X? > > These were things that people were wondering when this came up in the past. Once again this is becoming a debate about hypotheticals which rarely leads anywhere constructive. To take a concrete case instead. Are you really worried about Google starting to ship dvdcss as part of their Chrome repository? Do you really think that is a question keeping our lawyers up at night? Are there repositories out there where we can not trust the person or company behind it enough to include it by default for legal reasons? Sure there is, but you can't say that just because we would not want to risk shipping the rpm-warez.tor.net repo by default all 3rd party repos are high risk and something our lawyers would be concerned about. Because that is the argument you in practice is making when you are posing hypothetical questions about the risk of 3rd party repos. Christian -- 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: The Forgotten "F": A Tale of Fedora's Foundations
Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. So decisions need to be general to allow us to look for a variety of options to fulfill them. Lets say Fedora decided we want to make it easier for our users to get more multimedia codecs. We would not get the go ahead from legal to include a repository which contains ffmpeg for instance, but legal would probably be perfectly fine with including a repository containing the Cisco H264 package or the Fluendo Mp3 plugin. So in the end this is not a legal question which needs the involvement of the lawyers at this point, but a question of the overall goals and values of Fedora, and how we best achieve those goals and values. Basically we first need to agree on the 'design' before distracting ourselves with 'implementation'. Christian - Original Message - > From: "drago01" > To: "Development discussions related to Fedora" > > Sent: Wednesday, April 23, 2014 4:37:40 PM > Subject: Re: The Forgotten "F": A Tale of Fedora's Foundations > > On Wed, Apr 23, 2014 at 4:24 PM, Stephen John Smoogen > wrote: > > > > > > > > On 23 April 2014 02:29, Christian Schaller wrote: > >> > >> Hi Mairin, > >> Not sure exactly where you are coming from in terms of wanting legal > >> to weigh in, but in general I don't think legals opinion is very relevant > >> and this point. The first step here should always be us as a project > >> deciding what > >> user experience we want to offer our users, then once that is done go to > >> legal > >> and try to work with them to figure out how it can be done. > >> > > > > The reason was that Legal was the big reason the rules are in place in the > > first place. They are not just in place because of software patents. They > > are in place because of different national laws on copyright, what is > > considered to be infringement or redistribution by even linking, trademark > > use (also dependent on nation etc), competition rules, and a probably > > another dozen other factors. > > All of this applies to any software regardless whether it is free or > not (as I said in the other mail). > Copyright law does not differentiate between free and non free software. > -- > 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: The Forgotten "F": A Tale of Fedora's Foundations
Hi Mairin, Not sure exactly where you are coming from in terms of wanting legal to weigh in, but in general I don't think legals opinion is very relevant and this point. The first step here should always be us as a project deciding what user experience we want to offer our users, then once that is done go to legal and try to work with them to figure out how it can be done. A lawyers job is to worry, so if we make lawyers not being worried at all a pre-requisite to even thinking about something we should probably not be doing software at all. The brokenness of the US patent system combined with more brokenness in how the US legal system handles software patents probably means a lawyer would advice you to not be involved with software making at all due to the legal risks :) Christian - Original Message - > From: "Máirín Duffy" > To: "Stephen Gallagher" , devel@lists.fedoraproject.org > Sent: Tuesday, April 22, 2014 4:10:49 PM > Subject: Re: The Forgotten "F": A Tale of Fedora's Foundations > > On 04/22/2014 09:13 AM, Stephen Gallagher wrote: > > So one of the key questions here is whether the current policy on > > essentially hiding (protecting?) the user from these external software > > sources is truly in keeping with our Foundations, Mission and general > > project health. > > To be honest, I'm fairly uncomfortable discussing this without Fedora > Legal weighing in. I don't see any problem with re-visiting the > decisions made along this path, but I also am pretty confident the folks > who decided things had to be this way are really smart and had good > reasons. > > ~m > -- > 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - > From: "Stephen Gallagher" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 22, 2014 1:40:05 PM > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/22/2014 05:43 AM, Christian Schaller wrote: > > > > > > > > > > - Original Message - > >> From: "Thomas Woerner" To: > >> devel@lists.fedoraproject.org Sent: Tuesday, April 22, 2014 > >> 11:23:46 AM Subject: Re: F21 System Wide Change: Workstation: > >> Disable firewall > >> > >> On 04/21/2014 12:22 AM, drago01 wrote: > >>> On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald > >>> wrote: > >>> > >>>> * there are network services enabled by default > >>> > >>> Again that's a bug and a viloation of the guidelines. Which > >>> services are you talking about? Please file bugs. > >>> > >>>> * avahi is one of them > >>> > >>> You keep listing this as an example but avahi is not only > >>> installed and enabled by default but also allowed configured to > >>> work in the default firewall setup since F18 [1] ... > >>> > >>> So the current default firewall won't protect you against avahi > >>> flaws. > >>> > >> This has been added only because of a FESCo decision: > >> > >> https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop > >> > > > > Thank you for digging that ticket up Thomas. I think that ticket > > mentions something maybe a bit overlooked in this thread so far, > > "Real world security". I recommend everyone following this thread > > to watch this video of a talk by Russ Doty from Red Hat at this > > years DevConf in Brno. His talk is about real world security, > > especially in the context of enterprise computing, but the issues > > he articulate forms the underlaying challenges of this thread too. > > > > I think if everyone here see this talk we could hopefully move this > > thread into a more constructive format. > > > Since you missed the link: https://www.youtube.com/watch?v=jYGgVUYjXQ8 oops, thanks for that, I had the link ready to be pasted, but forgot to actually paste it :) Christian -- 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: The Forgotten "F": A Tale of Fedora's Foundations
- Original Message - > From: "Nikos Roussos" > There is also a third group, somewhere in between, who believe that's ok > to ship Free Software that connects and interops with proprietary > services (gtalk, aws, etc), but it's not ok to ship proprietary > software, metadata about proprietary software or advertise proprietary > services through our main UI tools. > > You should also keep in mind that "Functional" is very subjective and I > don't see how it can walk through such debates. People will still align > the "Functional" foundation to align with their point of view ;) > So this group believes it is ok to ship an open source twitter client in Fedora as long as the client doesn't know how to connect to twitter or has any metadata mentioning it can be used to connect to twitter? ;) Christian -- 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - > From: "Thomas Woerner" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 22, 2014 11:23:46 AM > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > On 04/21/2014 12:22 AM, drago01 wrote: > > On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald > > wrote: > > > >> * there are network services enabled by default > > > > Again that's a bug and a viloation of the guidelines. Which services > > are you talking about? > > Please file bugs. > > > >> * avahi is one of them > > > > You keep listing this as an example but avahi is not only installed > > and enabled by default > > but also allowed configured to work in the default firewall setup > > since F18 [1] ... > > > > So the current default firewall won't protect you against avahi flaws. > > > This has been added only because of a FESCo decision: > > https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop > Thank you for digging that ticket up Thomas. I think that ticket mentions something maybe a bit overlooked in this thread so far, "Real world security". I recommend everyone following this thread to watch this video of a talk by Russ Doty from Red Hat at this years DevConf in Brno. His talk is about real world security, especially in the context of enterprise computing, but the issues he articulate forms the underlaying challenges of this thread too. I think if everyone here see this talk we could hopefully move this thread into a more constructive format. Christian -- 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - > From: "Liam" > To: "Development discussions related to Fedora" > > Sent: Monday, April 21, 2014 10:10:13 PM > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > > > > On Apr 21, 2014 4:32 AM, "drago01" < drag...@gmail.com > wrote: > > > > On Mon, Apr 21, 2014 at 3:49 AM, Liam < l...@fightingcrane.com > wrote: > > > Sent from mYphone > > > > > > > > > On Apr 20, 2014 7:02 PM, "drago01" < drag...@gmail.com > wrote: > > >> > > >> On Mon, Apr 21, 2014 at 12:39 AM, Reindl Harald < h.rei...@thelounge.net > > >> > > > >> wrote: > > >> > > >> >> There have been other suggestions in this thread that are helpful > > >> >> like > > >> >> the network zones thing (but we still have too many zones) or > > >> >> enabling > > >> >> services should make them work i.e > > >> >> just enable the firewall rules. > > >> > > > >> > which make sense > > >> > > >> Oh finally you seem to understand what this is all about (a few mails > > >> ago this was supposed to be "strongly prohibited" ...) > > >> Now please goolge for "Psychological Acceptability and Security" you > > >> will find tons of scientific papers (read them) explaining about why > > >> it is wrong to silently break stuff or ask "yes / no" question or > > >> arguing with "this is not a blackbox the user should learn" nonsense. > > >> > > >> There is difference between a software developer, a sysadmin and a > > >> user that simply wants to share his music with his family. The latter > > >> should not have to learn about computer security to do it, > > >> while for the former it does not matter that much as you said because > > >> they ought to know what to do or where to get that information from. > > >> > > > The later isn't the target for Workstation, I don't believe. > > > > Not the *primary* target but still one see the "Other users" section in the > > PRD. > > -- > That's fine, but that's not who we need to be optimizing the experience for. > We need to be focusing on our primary target. After that others can be > considered. > A developer can handle this if it is presented well, but we shouldn't let > secondary users harm, at all, the experience of the primary user. If we do, > then this reorganization isn't working, IMHO. I think this is a misunderstanding of who a developer might be and why they choose a system. Those of my friends and acquaintances, who are developers and who over the years have decided to switch their development laptops from Linux to predominantly MacOS X, has not done so because they had things they wanted to do that was 'impossible' to do with Linux or that they thought they could not figure out how to do with linux. Instead they moved because they got tired of spending time trying to make their system 'work'. This is in no way limited to dealing with the challenges of a firewall, but if we want to attract developers or any kind of user to our system we need to make it usable without needing daily google searches to figure out how you can do something and make parts of your system work. As a sidenote, there has been a lot of discussions on this an other Fedora lists over the last few Months where people have loudly come out against what they see as infringements on the Freedom part of the four F's. Having seen this thread I am disappointed to see that nobody has come out in defense of the Friends part of the four F's, because the language and tone used by some people on this thread has been beyond pale, accusing the other participants in the thread of stupidity, incompetence and general maliciousness. If this doesn't change maybe the time has come for a board ticket to change that F from Friends to Flames? Christian -- 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - > From: "Simo Sorce" > To: "Development discussions related to Fedora" > > Sent: Tuesday, April 15, 2014 4:37:38 PM > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > On Tue, 2014-04-15 at 10:28 -0400, Christian Schaller wrote: > > - Original Message - > > > From: "Reindl Harald" > > > To: devel@lists.fedoraproject.org > > > Sent: Tuesday, April 15, 2014 11:40:20 AM > > > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > > > > > > > > Am 15.04.2014 11:32, schrieb drago01: > > > > On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald > > > > > > > > wrote: > > > > > allow any random application to open a unprivlieged > > > port which is reachable from outside is dangerous > > > > > We already allow that and have for a long while. Any application bothering > > to support the firewalld dbus interface can open any port > > they wish to. > > > > There was a long thread about this on the desktop mailing list, and I was > > not in the 'disable the firewall' camp in that discussion, > > but nobody in that thread or here have articulated how the firewall exactly > > enhance security in the situation where we at the > > same time need to allow each user to have any port they desire opened for > > traffic to make sure things like DLNA or Chromecast works. > > > > The thread discussing this ended up with mostly being a discussion if the > > firewall would be a useful way to help users from accidentally > > oversharing on a public network. Which is important and something we want > > to work on, but a lot less so than security issues. > > There is plenty of prior art here. > What you need is clearly different "zones" that the user can configure > and associate to networks, with the default being that you trust nothing > and everything is firewalled when you roam a new network. > > firewalld should grow a NetworkManager plugin so that configuration can > be changed on the fly based on which network NM tells firewalld a > specific interface is connected to. > > Applications need to be prevented from being able to arbitrarily open > ports, that should be allowed only for a "trusted" zone. User > intervention should be needed to mark a zone as trusted, in all other > zones the user will have to select explicitly what applications are > allowed. > > So the big work here is in the UI you need to build to present these > configurations to the user. > > Until then you can present a very simplified UI that just has a big > button/switch that turns everything from "untrusted" to "trusted", with > the default being "untrusted" of course. All of this are points I actually made myself in the corresponding thread on the desktop list. I suggest you read that to see the prior discussion on the subject here. The thread starts here: https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html Christian -- 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: F21 System Wide Change: Workstation: Disable firewall
- Original Message - > From: "Reindl Harald" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 15, 2014 11:40:20 AM > Subject: Re: F21 System Wide Change: Workstation: Disable firewall > > > Am 15.04.2014 11:32, schrieb drago01: > > On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald > > wrote: > allow any random application to open a unprivlieged > port which is reachable from outside is dangerous > We already allow that and have for a long while. Any application bothering to support the firewalld dbus interface can open any port they wish to. There was a long thread about this on the desktop mailing list, and I was not in the 'disable the firewall' camp in that discussion, but nobody in that thread or here have articulated how the firewall exactly enhance security in the situation where we at the same time need to allow each user to have any port they desire opened for traffic to make sure things like DLNA or Chromecast works. The thread discussing this ended up with mostly being a discussion if the firewall would be a useful way to help users from accidentally oversharing on a public network. Which is important and something we want to work on, but a lot less so than security issues. Christian -- 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: F21 Self Contained Change: Playground repository
To chime in here, we have been doing something like this in GStreamer for a long while. There is 'plugins-base' and 'plugins-good' plugins which is comparable to the current core Fedora repository. Any plugin going into base or good need to conform to certain coding standards, licensing standards and documentation standards. Then there is 'plugins-ugly' which is more like rpmfusion. It still has the coding and documentation standards, but licensing can be of a wider variety. (Not just 'non-free' as GStreamer do not accept GPL plugins into the base or good repositories either due to being a LGPL toolkit). Finally there is plugins-bad, which is a bit more like what I think Playground will be. It is a repository with plugins which for a variety of reasons are not ready for any of the other ones yet. This could be that they are not of a high enough coding quality yet or lack documentation, but they still 'work'. And what we found over the years, is that while it is good to have high standards for these plugins to stretch towards in order to get included in one of the other modules, having 'bad' available is crucial as a way to get access to plugins that might be critical to their usecase even if they are not up to our technical standards yet. So while it can be frustrating that some plugins end up lingering in bad for a long time, it is still a much better scenario than people deciding GStreamer is useless for them and move somewhere else. Christian - Original Message - > From: "Stephen Gallagher" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 8, 2014 7:04:54 PM > Subject: Re: F21 Self Contained Change: Playground repository > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/08/2014 12:24 PM, Michael Cronenworth wrote: > > Jaroslav Reznik wrote: > >> For now the Playground repository contains both packages that are > >> destined for eventual inclusion into the main Fedora repository > >> and *packages that are never going to make it there.* > > > > This sounds like a problem and not a feature. Why would packages > > never make it to Fedora, yet be available in this new repository? > > > > My intent here is to be constructive so my question is genuine. I > > don't believe Fedora should start down the path of a fragmented > > repository structure. It makes sense for RHEL and its software > > channels it can sell support for, but Fedora is different. > > RPMFusion being an exception as it is a legal necessity. > > My interpretation here is that there exists plenty of genuinely > open-source software out there for which it will likely never be > possible to package fully according to Fedora's packaging guidelines > due to bundling or similar issues (the obvious example being the > oft-requested Chromium). > > Similarly, there are a great many useful Ruby libraries and > applications out there for which unbundling them would be an exercise > in futility. Ask yourself which is more important to most users: > 1) My OS is perfectly maintainable by engineers. > or > 2) My OS lets me install the software I need without hassle. > > Offering users a slightly-less stringent repository such as this makes > sense. > > Also "packages that are never going to make it there" should probably > have been phrased more politically: "Even if the reality of the > situation is that perfect adherence to the Fedora packaging guidelines > is infeasible". > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma > wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg > =IzBI > -END PGP SIGNATURE- > -- > 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
- Original Message - > From: "Matthew Miller" > To: "Development discussions related to Fedora" > > Sent: Friday, March 21, 2014 12:59:01 PM > Subject: Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next > > On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote: > > I agree with Jaroslav. I was looking forward to have a fourth > > product to those three. KDE can help define what is needed for new > > product, what must be done by all teams, how much work it will be > > ... I guess we should speak more about addition of new product and > > don't kill the idea at the start. > > Like I said, I'm skeptical, but listening. :) > While opinions differ on if we should 'ever' have more than 3 products, personally am very skeptical to the idea of product proliferation, I think that as a minimum common sense measure we should not even consider any further products before we have the current 3 products released and our infrastructure updated to handle them. Christian -- 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: Heads up; F22 will require applications to ship appdata to be listed in software center
- Original Message - > From: "Przemek Klosowski" > To: devel@lists.fedoraproject.org > Sent: Friday, February 14, 2014 10:43:16 PM > Subject: Re: Heads up; F22 will require applications to ship appdata to be > listed in software center > > On 02/14/2014 01:41 PM, Adam Williamson wrote: > > > > On Fri, 2014-02-14 at 13:02 -0500, Przemek Klosowski wrote: > > > > On 01/28/2014 03:12 PM, Richard Hughes wrote: > > > > On 28 January 2014 18:43, Przemek Klosowski > wrote: > > > > There are two separate issues here: 'abandonment', and 'GUIness'. As to the > latter, I think it's a mistake to have a primary application installation > tool that only deals with GUI apps, because it relegates text-based tools, > such as 'units', to a second-class status of being hard to find and to > install. > That's not the tool we've designed and built. We've built a GUI > application installer, not a package installer. > While it's not the fault of the installer, I am concerned about that > distinction. For better or worse, a lot of useful tools seem to be out > of scope for a 'GUI application installer'. GCC, perl, git, octave, R, > units, mysql/sqlite3, this kind of thing. > Do you actually want to use a tool like Software to install gcc? > > I just can't see why you would. You know gcc is what you want. You don't > need a shiny description and some screenshots and user reviews on a 1-5 > star scale. 'yum install gcc' seems a massively better fit. Who would it > benefit to have something like gcc in Software? > I see what you mean, but how do you install it, and other examples I > provided? It's not just gcc: > it's gcc-gfortran, gcc-arm, mingw64-gcc, msp430-gcc, etc. > Well with GCC we are assuming people will read docs and figure out the command line parameters needed to use gcc. So expecting people to read the docs on how to use yum or 'yum search' is not expecting to much in my opinion. That said we should list the Developer Assistant in the Software center (or even have it installed by default) and that should be the tool IMHO to install these and other developer tools. Christian -- 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: Fedora.NEXT Products and the fate of Spins
I can do better, I can provide you with one of these people to look at. If you send me your postal address I will send you a mirror :) Christian - Original Message - > From: "Jóhann B. Guðmundsson" > To: devel@lists.fedoraproject.org > Sent: Thursday, January 30, 2014 1:39:11 PM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > > On 01/30/2014 12:08 PM, Christian Schaller wrote: > > My statements was directly targeted at the often repeated attitude on this > > list which > > seems to be that Red Hat should shut up and pay for whatever the given > > poster think should be payed > > for without having any expectations or requirements of the Fedora community > > in return. > > Care to reference to what you get at here in you futile attempt of > damage control? > > By all means point me to the post and the places where our community > members are demanding anything from Red Hat. > > JBG > -- > 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: Fedora.NEXT Products and the fate of Spins
- Original Message - > From: "Jaroslav Reznik" > To: "Development discussions related to Fedora" > > Sent: Thursday, January 30, 2014 1:34:45 PM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > - Original Message - > > My statements was directly targeted at the often repeated attitude on this > > list which > > seems to be that Red Hat should shut up and pay for whatever the given > > poster > > think should be payed > > for without having any expectations or requirements of the Fedora community > > in return. > > > > The relationship between Red Hat and Fedora is very different from that of > > for instance Debian and Ubuntu, > > with Red Hat being a lot more directly involved in both contributing to > > Fedora and paying for the > > general upkeep of Fedora. Personally I always felt that this symbiotic > > relationship was a big part of > > what made Fedora interesting. > > +1 and I still think it works pretty well - Red Hat has a nice space to > do work on the future RHELs in open way (not like other so called open > companies), community can contribute where there's interest. > > Btw. I'm not saying there are no issues, or sometimes more misunderstandings > that always could be resolved. > > > So in regards to the spins, which my original response didn't really try to > > address, I think they should all become remixes > > and I think we should try to build an infrastructure where doing a remix is > > as easy as possible. > > For example, in theory I think the Fedora project could provide some kind > > of > > web hosting space for the remixes, to reduce the burden/threshold > > for remix maintainers > > And we call these spins now. Not exactly, to be clear what I was talking about here was fedora providing hosting for someone to point their 'SuperDuperLinux.org' domain to. So that the remixes wouldn't need to find separate web hosting. But as I think you also refer to in your response, if we do that then there are probably similar legal restrictions put on the remixes as are currently put on the spins. > > > , but I do also see that there are legal and > > administrative reasons for why that could be a bad idea, but I am sure that > > with > > some discussion and investigation there are solutions that can be found to > > these practical challenges. > > That's one idea behind remixes - make it as easy as possible to remix Fedora > outside of Fedora space to avoid legal issues. > > Jaroslav > > > > > Christian > > > > > > - Original Message - > > > From: "piruthiviraj natarajan" > > > To: "Development discussions related to Fedora" > > > > > > Sent: Thursday, January 30, 2014 12:29:43 PM > > > Subject: Re: Fedora.NEXT Products and the fate of Spins > > > > > > > > > On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller < cscha...@redhat.com > > > > > > > wrote: > > > > > > > > > > > > What I mean to say is that Red Hat has a business motive to support the > > > Fedora community, > > > if supporting Fedora was a pure act of charity then I think organizations > > > like the Red Cross > > > or Unicef would have a much better chance of getting the money. > > > > > > So if the Fedora community wants to not care about why Red Hat invests in > > > Fedora they are of course free to do so, > > > but it becomes quite disingenuous to later be surprised if Red Hat loses > > > interest in Fedora. > > > > > > well this kind of strategy towards the community is not very inspiring > > > for > > > the new contributors, is it? > > > I think there is interest in the fedora community for Gnome as well as > > > other > > > DE which RHEL doesn't ship. > > > But since this thread has been moving in a direction where the Fedora > > > spins > > > are under threat to exist in the repos doesn't bode well for the packages > > > that is not of interest to 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 > > -- > > 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 -- 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: Fedora.NEXT Products and the fate of Spins
- Original Message - > From: "Jaroslav Reznik" > To: "Development discussions related to Fedora" > > Sent: Thursday, January 30, 2014 1:25:10 PM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > - Original Message - > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Apologies for the slightly alarmist $SUBJECT, but I want to make sure > > that this gets read by the appropriate groups. > > > > During today's FESCo meeting, there was the start of a discussion on > > how to approve new Products into the Fedora family. As part of this, > > it naturally strayed into discussion of what we do about Spins as they > > currently exist. > > > > Several ideas were raised (which I'll go through below), but we didn't > > feel that this was something that FESCo should answer on its own. We'd > > prefer community input on how to handle spins going forward. > > > > So, in no particular order (because it's difficult to say which > > questions are the most important): > > > > 1) Are Spins useful as they currently exist? There are many problems > > that have been noted in the Spins process, most notably that it is > > very difficult to get a Spin approved and then has no ongoing > > maintenance requiring it to remain functional. We've had Spins at > > times go through entire Fedora release cycles without ever being > > functional. > > Spins are useful especially as they makes our community inclusive, > one thing we should be proud about (and sometimes it was harder, could > cause issues but everything is solvable). > > For spins quality - it differs, it will differ but recent changes to > process were for good, more updates are still needed. Long time ago > we released what was build, I like how big step we did last few years. > It's not reason it wasn't functional before to ban spins. > > If there's interest in spins like product, someone is willing to lead > this effort, I think in some way, it can stay. > > > 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. > > The effect here would be that Spins are no longer an official part of > > The Fedora Project but are instead projects unto themselves which are > > permitted to consume (possibly large) portions of our tools, packages > > and ecosystem. Maintenance and upkeep of these spins then becomes > > entirely the responsibility of the downstream community that > > constructs them and has no mandatory draw on Fedora's marketing, > > ambassadors or quality assurance resources. > > It's possible but much more resource hungry. The way how spins are set > helps these sub-projects deliver interesting piece of software. > > But there are two questions: > - does every single spin makes sense as standalone spin? I really liked > the idea of Fedora Formulas, it's exactly the way we should go. If for > some reason formulas would not be enough for desired use case -> remix. > > aka products + add-ons as formulas = spin > > For people who missed it https://fedoraproject.org/wiki/Fedora_formulas Well I think this idea is interesting and we have discussed something along these lines in the Workstation working group. I mean at the end of the day we all want as much software as possible packaged for Fedora/Product. The question to me lies in the details of how this is done. For instance the idea we hope to explore are we develop the technical specification for the workstation is what kind of rules should apply to these potential 'formulas'. There are some obvious ones like, you can't for instance in a 'formula' to replace a package that would break the core product for instance due to replacing a version of a package with one that got a different ABI. (This specific idea is quite well covered in existing Fedora guidelines, but I wanted to avoid derailing this discussion by choosing an example that I hope would generate discussion in itself :) > - or we could go even further and ask ourselves, do we want to call > products Fedora? Or do we want products as remixes too? Based on > underlying Fedora infrastructure? This could for example solve issues > with our values - 3rd party repos etc. Using the Fedora brand to only define a set of 'white box' packagesets is an option, but in some sense it means the end of 'Fedora' as a user facing brand. > > 3) Should Spins be considered Products-in-development? In other words, > > should we only approve Spins that are targeted or destined for > > "promotion" to a fully-supported Fedora Product? This is a nuanced > > question, as it means different things for different Spins, for > > example Spins focusing on a target-audience (Security Spin, Design > > Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz > > Spin). > > For target audience spins, see above Formulas. And once we have this, > I think spins as we know them right now could go then. > > I'd like to avoid calling LXDE/MATE other tech spins as products in > development but we w
Re: Fedora.NEXT Products and the fate of Spins
My statements was directly targeted at the often repeated attitude on this list which seems to be that Red Hat should shut up and pay for whatever the given poster think should be payed for without having any expectations or requirements of the Fedora community in return. The relationship between Red Hat and Fedora is very different from that of for instance Debian and Ubuntu, with Red Hat being a lot more directly involved in both contributing to Fedora and paying for the general upkeep of Fedora. Personally I always felt that this symbiotic relationship was a big part of what made Fedora interesting. So in regards to the spins, which my original response didn't really try to address, I think they should all become remixes and I think we should try to build an infrastructure where doing a remix is as easy as possible. For example, in theory I think the Fedora project could provide some kind of web hosting space for the remixes, to reduce the burden/threshold for remix maintainers, but I do also see that there are legal and administrative reasons for why that could be a bad idea, but I am sure that with some discussion and investigation there are solutions that can be found to these practical challenges. Christian - Original Message - > From: "piruthiviraj natarajan" > To: "Development discussions related to Fedora" > > Sent: Thursday, January 30, 2014 12:29:43 PM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > > On Thu, Jan 30, 2014 at 4:21 PM, Christian Schaller < cscha...@redhat.com > > wrote: > > > > What I mean to say is that Red Hat has a business motive to support the > Fedora community, > if supporting Fedora was a pure act of charity then I think organizations > like the Red Cross > or Unicef would have a much better chance of getting the money. > > So if the Fedora community wants to not care about why Red Hat invests in > Fedora they are of course free to do so, > but it becomes quite disingenuous to later be surprised if Red Hat loses > interest in Fedora. > > well this kind of strategy towards the community is not very inspiring for > the new contributors, is it? > I think there is interest in the fedora community for Gnome as well as other > DE which RHEL doesn't ship. > But since this thread has been moving in a direction where the Fedora spins > are under threat to exist in the repos doesn't bode well for the packages > that is not of interest to 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 -- 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: Fedora.NEXT Products and the fate of Spins
- Original Message - > From: "piruthiviraj natarajan" > To: "Development discussions related to Fedora" > > Sent: Thursday, January 30, 2014 11:45:51 AM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > > On Thu, Jan 30, 2014 at 4:10 PM, Christian Schaller < cscha...@redhat.com > > wrote: > > > > The difference here is that the resources for GNOME (or anything else Red Hat > needs for future versions of RHEL) are > provided by Red Hat. So if you want the spins to the logically the same in > terms of resources we should start demanding > that any spin set up needs to provide an annual monetary contribution to help > pay for the Fedora infrastructure and team. > > So you mean to say the software(already existing in the repos) which is not > of interest for red hat should pay to stay for fedora infrastructure and > Team to stay in the fedora repos? > > This looks like clear business motive and no point in calling it a community > project at all. > What I mean to say is that Red Hat has a business motive to support the Fedora community, if supporting Fedora was a pure act of charity then I think organizations like the Red Cross or Unicef would have a much better chance of getting the money. So if the Fedora community wants to not care about why Red Hat invests in Fedora they are of course free to do so, but it becomes quite disingenuous to later be surprised if Red Hat loses interest in Fedora. Christian -- 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: Fedora.NEXT Products and the fate of Spins
The difference here is that the resources for GNOME (or anything else Red Hat needs for future versions of RHEL) are provided by Red Hat. So if you want the spins to the logically the same in terms of resources we should start demanding that any spin set up needs to provide an annual monetary contribution to help pay for the Fedora infrastructure and team. Christian - Original Message - > From: "Frank Murphy" > To: devel@lists.fedoraproject.org > Sent: Thursday, January 30, 2014 9:06:24 AM > Subject: Re: Fedora.NEXT Products and the fate of Spins > > On Wed, 29 Jan 2014 18:58:22 -0500 > Josh Boyer wrote: > > > I consider myself squarely in the middle of those two camps. I think > > they have value to people. I think they fill a niche, however large > > or small it might be. I also think they can be done by the people > > wishing to provide them without relying on Fedora resources for > > hosting and creation (outside of leveraging existing packages and > > repositories). > > That doesn't sound right, > logically below would also be true. > Gnome is a fairly big Spin, > and can eat up quite a lot of resources. > Maybe it should be outsourced. > > > ___ > Regards, > Frank > www.frankly3d.com > > -- > 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
Workstation PRD summary and next steps
Hi everyone, So on behalf of the Workstation Working Group I would like to say thank you to everyone who has taken the time so far to chime in. There has been a lot of passionate discussion happening and that is the way we like it. So while we might not have been able to respond to each and every message, myself and the other working group members have read every message sent so far. We will now take that feedback with us into the next working group meeting and come up with a second PRD draft, trying to incorporate the suggestions we have gotten so far when possible. The next update of the PRD will be posted to the fedora-desktop list as that is the designated 'home' of the working group and product and we want to avoid cluttering up the general Fedora-devel list with product specific further discussion. The other product working groups have mostly kept themselves to their own mailing list so we will try to do the same, and leave the general devel list to the -base group. Also for those of you who might end up feeling that the updated PRD do not address you raised concerns, all I can say is that we do take all feedback seriously, and will try to keep the points made in mind as we go forward, but of course there is no perfect solutions here that will make absolutely everyone 110% content. Christian -- 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: unaccessability
Ok, so I guess the solution would be for the launcher to do something like this: gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx --name "bitchX IRC" --title "BitchX IRC" That said Ray mentioned that this is probably not supported yet in the Shell launcher. Anyway, as Richard says, we should have a proper design discussion around this and not just add a ton of .desktop files without thinking through the presentation and how it will work. But feel free to file some bug reports to kick of a discussion. Christian - Original Message - From: "Richard Hughes" To: "Development discussions related to Fedora" Sent: Thursday, November 7, 2013 4:02:07 PM Subject: Re: unaccessability On 7 Nov 2013 17:13, "Richard Vickery" < richard.vicker...@gmail.com > wrote > Is / was a rather political decision to make BitchX unavailable through this > app-market / Software GUI thing? How do you launch bitchx from gnome-shell? If it's just a random binary without any desktop or appdata file, it isn't an application as far as gnome-software is concerned. If that needs to change, it needs to be discussed and properly designed in #gnome-design. 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 -- 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: unaccessability
Well the installer is work in progress and there are a lot of features missing still, and there are still questions that we need to figure out the answer to in terms of installing various things. We are trying to nail down the core design first before adding support for 'everything', but there will be the need for a .desktop file and an appdata file for anything that wants to be in. Maybe long term we want to filter terminal applications into a separate 'tab' or similar, but regardless of long term presentation if you maintain a package with a terminal application and want it to show up in the installer the solution is to create a .desktop file and a appdata file for it. Christian - Original Message - > From: "Rahul Sundaram" > To: "Development discussions related to Fedora" > > Sent: Thursday, November 7, 2013 1:09:19 PM > Subject: Re: unaccessability > > Hi > > > On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner < fmuell...@gnome.org > > wrote: > > > > > I guess the main obstacle here is that there isn't really a good > criterion which is as clear-cut as "installs a (non-NoDisplay) > .desktop file" => "this is a user-visible gui application" for gui > applications - mutt certainly is a user application, sshd clearly is > not, zsh ... maybe? > > Why do you want to differentiate between Mutt and sshd? If a user wants to > install a specific piece of software, they search for it within a gui and if > it matches, they install it and move on. If you really need some way to > differentiate, you can have some form of tagging via fedora tagger or > appdata which you can include in more than just gui packages. > > When I want some software, say Epiphany and Mutt, if I can only use the > installer for the Epiphany but I have to use yum for Mutt, I rather just use > yum for both where I don't have to switch between two different ways of > getting it. I don't mind the focus on gui applications but leaving out > command line tools altogether forces me to think about whether say htop > would be considered a application by the installer or not which is not the > level I want to differentiate at all. When I search for something within the > installer and it returns nothing, is it because there is genuinely nothing > that matches what I want within the repositories or is the installer just > excluding it based on implementation level details like desktop files and > appdata? How would I know? It is just too complex. > > 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 -- 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: unaccessability
Hi, The core principle of the installer is that it operates on an application level and not a package level. The current way it determines if something is an application is by looking for a .desktop file. So in theory you could put a bitchx.desktop file into the bitchx package and it would appear in the installer. That said I don't think it is generally a bad idea if command line/terminal applications are installed from the command line, but there is no hard policy blocking such applications from making themselves available in the installer. Christian - Original Message - From: "Richard Vickery" To: "Development discussions related to Fedora" , "Community support for Fedora users" Sent: Thursday, November 7, 2013 12:13:25 PM Subject: unaccessability Is / was a rather political decision to make BitchX unavailable through this app-market / Software GUI thing? Since having to yum install it, I am beginning to have a negative feeling toward the app market idea; the thought being: what else is being left out? Regards, 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 -- 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
Hi Frank, They will, although in some sense I am the wrong person to ask this question as it will be up to the people developing and packaging these DE's just like it is now. The difference from today here though will be that there will be some requirements for being available for the workstation as the PRD states. The main one here that I foresee is that you can't conflict in terms of library requirements or binary names with the standard desktop of the workstation. I don't think that has been a big problem historically so it will likely have minimal impact, but it is now going to be a formal requirement as the PRD currently stands. I expect there will be other requirements defined too, but I want to make it clear that the goals of these requirements is not to make it impossible or even hard to package alternative DEs for the workstation. But what it will mean is that for instance it will be 100% clear that the responsibility to stay available rests on the alternative DEs packagers and developers and not on the core product developers. Of course with this also comes extra responsibility of the Workstation working group to ensure that development plans are shared as early as possible, to give everyone a chance to port over in time (ref. the recent Bluez discussion). But it all comes back to what I mentioned in an earlier email. The 3 products is a attempt at moving from primarily packaging upstream projects, to having concrete independent development targets for each product and to have engineers work on those independently of upstream priorities. So in some sense when people install alternative DEs that will to some degree mean that they are no longer using the Workstation as at least a subset of the features developed and announced as the big new features of a given release will not be available simply because they where features implemented or bugs fixed in the primary desktop. That is of course not specific to the Workstation product. Christian - Original Message - > From: "Frank Murphy" > To: devel@lists.fedoraproject.org > Sent: Thursday, November 7, 2013 4:16:58 AM > Subject: Re: Draft Product Description for Fedora Workstation > > On Fri, 01 Nov 2013 10:24:20 -0400 > Christian Fredrik Kalager Schaller wrote: > > Will the other DE's still exist after "workstation" > Will a dev be able to use Xfce, Lxde as graphical choice. > > What would encourage say an xubuntu dev //* devs are still users */ > working on foo, to switch to "Fedora Workstation"? > > > -- > Regards, > Frank > www.frankly3d.com > > -- > 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: Draft Product Description for Fedora Workstation
> > I would actually like to go a little further, and make it easy to enable > > 'clean' third-party repositories. If we imagine a future where e.g. > > valve is hosting a repository with their steam client, or say, the > > chromium web browser is available from the a fedora people page, I would > > really like it if searching for 'steam' or 'chromium' in gnome-software > > would bring up a text that said something like: The software you are > > looking for is available from a third-party repository. Do you want to > > enable it ? > > That was how I understood the original proposal. And that's the > conversation that needs to happen at a higher level outside of the WG > before it can really be a reality. > I don't think we need to push these decisions to be Fedora generic. There is no reason why the 3 products can't have different rule sets. Just because a policy would work for the cloud image for instance doesn't mean it is the right one for the Workstation and vice versa. Christian -- 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
> >> So sure, we can have software that will pull things in if the user has > >> done some manual intervention. We just cant, currently, do that thing > >> for them. > > > > Right, that's exactly what I was saying. I just think this is all the > > _original poster_ was talking about, not any kind of automatic > > configuration of such repositories. (Or at least, you can read it that > > way). > > OK. I guess that's fine, but it seems like a non-goal to me. I mean, > it already works that way. All adding it to the PRD would do would > make an easy thing to check off the list as "met". >I suppose we should go back to the OP and ask for clarification of >exactly what the idea was, at this point :) So there are 3 different cases here 1) Packaging non-free/semi-free software in Fedora - I don't think anyone is advocating that - ref recent openh264 thread 2) Enabling 3rd party repositories with packages that have an unclear legal status is major jurisdictions - This is not what the PRD was referring too, and we have a solution for that already 3) Easily enabling 3rd party repositories containing software that is without any legal uncertainty, but which contains software which might not meet the Fedora guidelines for stuff we would include. So it is item 3 that the PRD is addressing. An example here would be Google Chrome. Google provides a yum repo for Google Chrome for Fedora and Google stands behind Chrome legally, so if they also do the work of putting in an appdata file there we should figure out a simple way for users to install Chrome from the GNOME Software application. The exact details of how we do that enablement can and should be discussed, but it should be something simpler than how we currently enable the (2) option, yet at the same time we probably don't want to give them equal billing to the Fedora packaged and 100% open source stuff we make available in the Fedora repository. As a sidenote, as we delve into the details a bit more here maybe it is time to move these discussions to the product specific mailing list to not spam the general devel list? Christian -- 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
Hi Ryan, I been discussing the possibilities of doing some surveys with Langdon White, so hopefully yes. We just need to rustle up the budget first :) Christian - Original Message - From: "Ryan Lerch" To: "Discussions about development for the Fedora desktop" , devel@lists.fedoraproject.org Sent: Monday, November 4, 2013 11:14:21 AM Subject: Re: Draft Product Description for Fedora Workstation On 01/11/13 10:24, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Also in the name of openness, before I sent this here, I showed the PRD draft to key stakeholders and decision makers inside Red Hat, to ensure that we have the necessary support for these plans to get the kind of engineering resources allocated from Red Hat we will need to pull this off. Sincerely, Christian F.K. Schaller P.S. I am celebrating both our wedding anniversary and my wifes birthday this weekend so I will not be able to be online a lot. That said I will make the time to go online to check my email from time to time so that I can respond to any questions that has come in, just don't expect immediate answers from me this weekend :) Although i am not sure if the PRD is the place for it, But should we also think about conducting some user surveys to help define our target audience further? Also, some User testing on what we have already would also be useful for a baseline to check against in the future when we start implementing changes. cheers, ryanlerch -- 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: Draft Product Description for Fedora Workstation
The term 'Power user' is not meaningless if you use it to refer to users of Fedora on IBM Power architecture ;) But apart from that I do agree that the term as generally used doesn't provide a very clear target for development. Christian - Original Message - > From: "drago01" > To: "Development discussions related to Fedora" > > Sent: Tuesday, November 5, 2013 6:53:15 AM > Subject: Re: Draft Product Description for Fedora Workstation > > On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot > wrote: > > > > Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : > > > >> The problem is not to get code in the hands of developers. You don't need > >> distros for that. The problem is to get the code to end-users and > >> developers spend more time fighting the constrains it involves than trying > >> to understand this problem-space. > >> > >> Of course the aim might not be to reach end users but to push code from > >> developpers to other developers. > > > > And if that is the case, there is a huge disconnect between GNOME goals > > and Fedora Workstation goals. GNOME speakers repeat all year round their > > software is not aimed at "power users", but developers are the über power > > user. > > Depends on what you mean by "power user" (I hate this meaningless > term) if it means "software developer" then > yes. If it means "someone that spends his whole day in config dialogs" then > no. > -- > 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: Draft Product Description for Fedora Workstation
Funnily enough I had a discussion last week where it turned out the disagreement wasn't so much a disagreement, but a different contextualisation of the word 'support'. And I think that will be the crux here too. To me the main part of 'supporting' something here will be in handling our ABI story better, not about writing custom work arounds for various 3rd party software. There are of course many aspects to the ABI story, but one technology I think will be an important part of improving this is the LinuxApps proposal from Lennart Poettering. He did a talk about it at GUADEC which you can find here: http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome (The talk is not only about ABI for applications, but it is part of the talk, and despite the talk title it is not GNOME specific in any way.) Christian - Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Saturday, November 2, 2013 12:20:30 PM > Subject: Re: Draft Product Description for Fedora Workstation > > Christian Fredrik Kalager Schaller wrote: > > Attached is the draft PRD for the Workstation working group. > > Quoting from the draft: > > Ability to play 3D games from commercial publishers distributing games for > > Linux > and later: > > 3rd party software > > Fedora Workstation will work with partners and ISVs to ensure that their > > software can be easily installed on the system after installation. This > > work will for instance include working with for instance hardware partners > > to ensure users can install needed drivers directly from these vendors. > > Fedora will not include any non-free software by default or host any non- > > free software in our repositories. > > I think it is a very bad idea to try to explicitly and officially support > third-party software, especially proprietary third-party software. We have > no control over that software, its quality, the obsolete APIs and ABIs it > uses etc. Supporting them officially: > * puts us in a position where we need to try to fix issues with software we > cannot actually fix, > * opens the door to really crappy workarounds degrading the quality of > Fedora (and possibly negatively affecting other applications, even our > own) just to make some proprietary program work (e.g., just look at all > the ugly "make Flash work" workarounds that have been shipped by various > distributions and upstreams), > * may require shipping loads of compatibility libraries (with old sonames) > that nothing in Fedora would need (e.g., do you really want to install qt3 > by default? The current LSB 4.1 still requires it, next to Qt 4 which is > also in the process of becoming legacy. And some other legacy libraries > that proprietary software requires would not even have to be packaged > otherwise), > * may lock us into outdated versions of core software (kernel, X11 etc.) > just so some third-party driver (or even application, but the drivers are > routine offenders) keeps working, defeating one of Fedora's strongest > points (being First) and making it worse (also by delaying Features) for > everyone who does NOT use the offending third-party driver(s). > > 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 -- 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
The PRD avoids these questions by design. To often open source discussions end up being discussions about the merits of the means as opposed to the actual goals. It should be a sobering notion that for all the years when the community discussed if the a successful desktop should be implemented in C or C++ we ended up having our collective thunder stolen by a desktop written in Objective-C. There are some lessons to be learned from that (and to be clear I don't think the lesson is that Objective-C is a 'better' language). So while of course there does come a point for drilling down into implementation detail, the suggestion I got from various FeSCO members, and which I thought very sensible, was to avoid that being the starting point. Christian - Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Saturday, November 2, 2013 1:14:15 PM > Subject: Re: Draft Product Description for Fedora Workstation > > Bill Nottingham wrote: > > Something that doesn't seem specified here is any sort of a design style > > or guide for how apps used in the Workstation should generally be built > > and function. Is there intended to be that sort of standard? > > Indeed, the document carefully eschews this question, which goes hand in > hand with the question of WHAT desktop environment(s) the Workstation is > supposed to include. If the goal is (and I think it should be, because > that's what users expect) a traditional desktop with a panel (containing at > least the standard items: menu button, task bar, system tray, digital > clock), a menu (popping up from the menu button in the panel), and a desktop > displaying the xdg-user-dir for DESKTOP in some place (spread over the > entire desktop or in a widget, Plasma can do either as desired), then it is > clear that gnome-shell does NOT qualify. > > 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 -- 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
Hi Bill, It is a good question. It does seem a bit more detailed than the level I tried to put this document on, so maybe should a style guide would be part of second stage working group output. But what probably would belong in this document would be a paragraph saying we intend to come up with such a sub-document. Christian - Original Message - From: "Bill Nottingham" To: "Development discussions related to Fedora" Cc: desk...@lists.fedoraproject.org Sent: Friday, November 1, 2013 2:43:37 PM Subject: Re: Draft Product Description for Fedora Workstation Christian Fredrik Kalager Schaller (cscha...@redhat.com) said: > Hi everyone, > Attached is the draft PRD for the Workstation working group. The > proposal tries to be relatively high level and focus on goals and > principles, but I have included some concrete examples at times to try > to provide some clarity on how the goals and principles could play out > in practice. > > I hope the community at large will take the time to read through it and > provide feedback so that when the working group meet next we can use > that feedback to start tuning in on the final form of the PRD. > > Also in the name of openness, before I sent this here, I showed the PRD > draft to key stakeholders and decision makers inside Red Hat, to ensure > that we have the necessary support for these plans to get the kind of > engineering resources allocated from Red Hat we will need to pull this > off. Something that doesn't seem specified here is any sort of a design style or guide for how apps used in the Workstation should generally be built and function. Is there intended to be that sort of standard? Bill -- 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: Draft Product Description for Fedora Workstation
- Original Message - > > > > It looks like it is designed only for developers by developers. > > > > What about graphic designers, musicians, document writers, etc.? They > > all are not mentioned as target audience. > > Per this document, those would fall into the "Other users" section. > > The software for much of those use cases is available in the wider > Fedora repository, so one could install them if needed. > > josh > -- In general I hope to see a lot of users of the workstation product, including the almost cliché usecase of the 'grandparents'. Focusing on a specific set of usecases doesn't need to mean we should actively make the product unattractive to anyone else. A lot of the core things we need to get right is equally important to almost any type of user we can think of, I mean regardless of if you are what we call a technical user or close to a computer illiterate you are very likely to prefer an operating system that doesn't crash over one that does, to make a very obvious example. But what having these usecases here mean is that they do become an active tool for development prioritisation and to some degree packaging prioritization and I think that will likely end up being the biggest change that these new products enact in Fedora. Red Hat's contribution to Fedora is getting re-focused as part of this and these PRDs are meant to be a tool that managers such as myself will use to help prioritize what we focus our development resources on. So lets say I had to prioritize development time between improving terminal stacking for developers or polishing the GNOME Shell teatime extension to make sure our grandparent users get optimal tea. The PRD makes it clear that focus should go on terminal stacking. (Ok, a silly example, but hopefully still useful as an explanation :) So just like all the other distributions out there we should as a community continue to try to have as many applications as possible available for our users, but the PRD should talk to where we are going to put resources intro trying to differentiate and be the leader. And every usecase we add means we dilute our efforts a little more and thus make it less likely we achieve the goal. Of course once we succeed with our initial goals we should revisit the PRDs and see if there are new groups or areas we can and should target to continue growing without risking losing the gains we made. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct