Re: LibreOffice packages
Michael Catanzaro píše v St 07. 06. 2023 v 08:15 -0500: > > Ideally all bundled dependencies should be hooked up to some sort of > automation that notices when there are upstream updates available, > comparable to upstream release monitoring. On Flathub this is done by > flathub-external-data-checker [1], but using it is optional and it's > not useful if it's not used. For Fedora Flatpaks, I don't think any > comparable mechanism exists, but it should be as simple as "update > whenever any component RPM is updated." > > [1] https://github.com/flathub/flatpak-external-data-checker > I used that for flatpaks I maintain for a while, but then removed it because it was rather adding work than reducing it. But it could be just my workflow. I recommend anyone use https://release-monitoring.org/ which can send you notifications of new versions of specified projects. Could be used for any component maintenance including RPMs. I get notified and then it's up to me when and how I act on it. You can build automation based on it, too. My biggest flatpak has 15 modules. Maybe if it had dozens like LibreOffice I'd appreciate more automation. Jiri > ___ > 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: Retiring Bottles in favor of Flatpak provided by upstream
Vít Ondruch píše v Čt 26. 01. 2023 v 15:37 +0100: > > Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a): > > Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > > > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > > > > > wrote: > > > > > > > I am not user of Bottles so I won't complain about this > > > > > > > particular case, > > > > > > > but the push towards (upstream) Flatpaks is unfortunate > > > > > > > :/ > > > > > > Can you elaborate on why you feel that way? > > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow > > > > > any > > > > > standard > > > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so > > > > I > > > > can > > > > compare. The review to get an app to Flathub was as thorough as > > > > Fedora > > > > package review. In some ways even stricter. It's not like "it > > > > builds, > > > > it runs, you're good to go". They care about some standards, > > > > about > > > > builds being verifiable etc. > > > That doesn't seems to be enforced because many builds scripts > > > just > > > download binaries built by other projects, for example; > > > > > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > > > > > Note: building the entire pandoc and TeX toolchain is very hard > > > and I > > > understand this example packager decision, but It doesn't make > > > more > > > trustful that version that one on Fedora. > > > Yes, this is good example. I cannot imagine anybody would do the > reviews > for the 3rd party libraries. That is the main difference to Fedora, > because there are no 3rd party libraries there. But let's not pretend it doesn't happen in Fedora at all. Yes, unlike on Flathub guidelines rule it out, but in the reality I've seen quite a few packages with (unacknowledged) bundled libraries in Fedora repos. The package goes through the initial review, a new version introduces a new dependency which is not available in the Fedora repo, you don't want to go through the hassle of introducing and maintaining a new package, you quietly bundle it. No source is pristine. It's always a compromise. Flathub is more flexible in what you can include in the flatpak, but Flatpak mitigates it by isolation (although it may not be set strict enough for some apps). Jiri > ___ 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: Retiring Bottles in favor of Flatpak provided by upstream
Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > wrote: > > > > > I am not user of Bottles so I won't complain about this > > > > > particular case, > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > Can you elaborate on why you feel that way? > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > standard > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > can > > compare. The review to get an app to Flathub was as thorough as > > Fedora > > package review. In some ways even stricter. It's not like "it > > builds, > > it runs, you're good to go". They care about some standards, about > > builds being verifiable etc. > > That doesn't seems to be enforced because many builds scripts just > download binaries built by other projects, for example; > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > Note: building the entire pandoc and TeX toolchain is very hard and I > understand this example packager decision, but It doesn't make more > trustful that version that one on Fedora. > > Flathub is definitely more flexible at that. I was involved in the deal with Mozilla which was not willing to do special builds in Flathub infra since from their point of view it was more secure to use builds done in their infra and just upload them to Flathub. We still found having official builds from Mozilla and Mozilla officially endorsing Flathub more beneficial than having Firefox rebuilt by a 3rd party in Flathub infra. But Flathub is still a curated repo. If you want to deviate from standards you have to justify it, if you're doing something fishy your flatpak may be taken out. But ultimetaly you have to trust the author, but that applies to Fedora, too, just to lesser extend. Jiri > ___ 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: Retiring Bottles in favor of Flatpak provided by upstream
Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500: > On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann > wrote: > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > wrote: > > > > > I am not user of Bottles so I won't complain about this > > > > > particular case, > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > Can you elaborate on why you feel that way? > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > standard > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > can > > compare. The review to get an app to Flathub was as thorough as > > Fedora > > package review. In some ways even stricter. It's not like "it > > builds, > > it runs, you're good to go". They care about some standards, about > > builds being verifiable etc. > > The Flathub CI seems to be more extensive than what we have in > > Fedora. > > > > All of that is optional in Flathub too. That makes it inherently > weaker. Firefox doesn't go through that, nor does OBS Studio. > > > > And I don't like Flatpacks, because their main advantage (their > > > isolation) is also their biggest disadvantage. There can't be > > > both > > > without making compromises. If I am not mistaken, the isolation > > > is > > > also > > > mostly myth, because it is disabled in most cases. > > > > Why? Apps come with permissions they require (which you can > > override > > btw). Just because some apps require access to your whole > > filesystem > > doesn't mean the isolation is a myth. You know the permissions, you > > may > > decide not to use such an app. None of the flatpaks maintained by > > me > > require this kind of access and are well isolated. > > > > How are people supposed to figure out you can change app permissions? > It's described precisely nowhere. For GNOME in particular, there's no > way to review and update app permissions (either to open them up or > close them further). KDE Plasma is getting this capability with KDE > Plasma 5.27. I mentioned overriding the permissions only as a side note. I don't think it's something that necessarily has to be advertised to users, simply because it can break apps. However, any user can review the permission beforehand and decide whether they're OK with them or not. That's well advertised in GNOME Software and KDE Discover already. Jiri ___ 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: Retiring Bottles in favor of Flatpak provided by upstream
Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > wrote: > > > I am not user of Bottles so I won't complain about this > > > particular case, > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > Can you elaborate on why you feel that way? > > > I don't trust upstream Flatpacks. I don't trust they follow any > standard > except standard of their authors. I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. The Flathub CI seems to be more extensive than what we have in Fedora. > And I don't like Flatpacks, because their main advantage (their > isolation) is also their biggest disadvantage. There can't be both > without making compromises. If I am not mistaken, the isolation is > also > mostly myth, because it is disabled in most cases. Why? Apps come with permissions they require (which you can override btw). Just because some apps require access to your whole filesystem doesn't mean the isolation is a myth. You know the permissions, you may decide not to use such an app. None of the flatpaks maintained by me require this kind of access and are well isolated. Jiri ___ 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: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
vvs vvs píše v Po 09. 09. 2019 v 15:44 +: > I'm happy with any support no matter how it is defined. In fact I > didn't get very much support from Fedora either over more than 20 > years, so my expectations are quite low. You seem to have a rather narrow view of support. It's not just someone waiting for your email/phone call to help you with your issues, that's just a small part of software support, it's mostly making sure that bugs and primarily security issues get fixed and delivered to you (and believe me it's not such a sure thing among Linux distros), and if you've been using Fedora for 20 years, you have received a lot of that. And you fail to understand it's something the Fedora Project is currently not quite capable to deliver for x86. If you expect the Fedora Project to just build packages for x86 and throw them over the wall on users, then I'm sorry to disappoint you, but that's not how Fedora has ever worked and I hope it never will. So as others already suggested: if you want the x86 architecture back, revive the x86 SIG, gather enough volunteers, make sure you can meet expectations of support at least at the level of secondary architectures, create a proposal backed by enough committed volunteers, submit it to FESCo, and I'm pretty sure you'll have your beloved architecture back. Jiri ___ 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
Re: Fedora Workstation and disabled by default firewall
Adam Williamson píše v Út 27. 08. 2019 v 16:01 -0700: > On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote: > > mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300: > > > On Tue, Aug 27, 2019 at 4:22 AM, John Harris < > > > joh...@splentity.com> > > > wrote: > > > > No, that is not how this works, at all. First, let's go ahead > > > > and > > > > address the > > > > idea that "if the firewall blocks it, the app breaks, so it's > > > > the > > > > firewall's > > > > fault": It's not. If the firewall has not been opened, that > > > > just > > > > means it > > > > can't be accessed by remote systems until you EXPLICITLY open > > > > that > > > > port, with > > > > the correct protocol, on your firewall. That's FINE. That's how > > > > it's designed > > > > to work. There's nothing wrong with that. > > > > > > > > This means that the system administrator (or owner, if this is > > > > some > > > > individual's personal system) must allow the port to be > > > > accessed > > > > remotely, > > > > before the app can be reached remotely, increasing the security > > > > of > > > > the system. > > > > > > You've already lost me here. Sorry, but we do not and will not > > > install a firewall GUI that exposes complex technical details > > > like > > > port numbers. Expecting users to edit firewall rules to use their > > > apps is ridiculous and I'm not really interested in debating it. > > > > Yeah, when you ask users questions they're not qualified to answer, > > you're just creating bad design. > > I always imagine my mom (who BTW has been a Fedora user for years) > > how > > she'd deal with that and I can't really imagine her opening/closing > > firewall ports. She'd be puzzled even by "Do you trust this > > network?" > > and would probably just click "Yes" to make it go away. No > > additional > > security, just annoying UX. > > However, Fedora Workstation is an edition. Which means it has a > *policy-defined* target audience. That target audience is defined > here: > https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience > > Case 1: "Engineering/CS student" > Case 2: "Independent Developer" > Case 3: "Small Company Developer" > Case 4: "Developer in a Large Organization" > > Are those people we believe do not understand the concepts associated > with firewalls? And the same document says: "While our focus is on creating a top-class developer workstation, our developer focus will not compromise the aforementioned goal to be a polished and user friendly system that appeals to a wide general audience." Having a target audience in mind doesn't mean we have to make bad design for everyone else. In addition their preferences could be actually the same. Just look at macOS, it's made easy for our moms and dads and very popular with developers at the same time. Jiri ___ 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
Re: Fedora Workstation and disabled by default firewall
Iñaki Ucar píše v Út 27. 08. 2019 v 16:17 +0200: > On Tue, 27 Aug 2019 at 14:20, wrote: > > The main competitor of Fedora Workstation is Ubuntu. Ubuntu ships > > without a firewall enabled and nobody considers this a critical > > vulnerability. Now: why is that...? > > 1. Ubuntu Server ships without a firewall enabled. Do you think > that's > a good policy? Should we turn off the firewall in Fedora Server > because Ubuntu Server does so? > > 2. Are you sure that nobody considers that critical? > > "There is a lot of existing information about firewalls - along with > **a long-term raging debate on the need of a firewall on Ubuntu**. We > recommend you enable it because you have ports open if you are > reading > this page." > > Source: https://wiki.ubuntu.com/BasicSecurity#Firewall > > So it's not critical, it's not enabled by default, and still they > recommend you to enable it (!). Who is them? 'haqking-deactivatedaccount' who was the last one editing the wiki page? I could go and create such a page on Fedora wiki without any authority as well. Jiri ___ 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
Re: Fedora Workstation and disabled by default firewall
IMHO surprisingly many. Just in my family there may be as many as 10 of them. They just never go to the Fedora mailing lists to represent themselves. And when you have a range of users from newbies to experts, you don't really design desktop software the way only the experts can deal with. Jiri Dan Book píše v Út 27. 08. 2019 v 09:13 -0400: > I guess it should not be surprising, Gnome has made it clear for many > years now their only target audience is infants and grandmothers. How > many of these users do you think Fedora really has? > > -Dan > > On Tue, Aug 27, 2019 at 9:12 AM Igor Gnatenko < > ignatenkobr...@fedoraproject.org> wrote: > > Red Hat is written as two separate words. So you can put some work > > into learning that :) > > > > Anyhow, why does user need to learn what port is? Can you imagine > > your > > grandma / grandfather learning how to open some port on the > > firewall? > > > > On Tue, Aug 27, 2019 at 3:05 PM Dan Book wrote: > > > > > > On Tue, Aug 27, 2019 at 8:10 AM wrote: > > >> > > >> On Tue, Aug 27, 2019 at 4:22 AM, John Harris < > > joh...@splentity.com> wrote: > > >> > > >> No, that is not how this works, at all. First, let's go ahead > > and address the idea that "if the firewall blocks it, the app > > breaks, so it's the firewall's fault": It's not. If the firewall > > has not been opened, that just means it can't be accessed by remote > > systems until you EXPLICITLY open that port, with the correct > > protocol, on your firewall. That's FINE. That's how it's designed > > to work. There's nothing wrong with that. This means that the > > system administrator (or owner, if this is some individual's > > personal system) must allow the port to be accessed remotely, > > before the app can be reached remotely, increasing the security of > > the system. > > >> > > >> > > >> You've already lost me here. Sorry, but we do not and will not > > install a firewall GUI that exposes complex technical details like > > port numbers. Expecting users to edit firewall rules to use their > > apps is ridiculous and I'm not really interested in debating it. > > >> > > >> If the user is capable of editing firewall rules and wants to do > > so, that user can surely also change the policy to not open all > > these ports. Yes? > > > > > > > > > That Gnome is intentionally sabotaging users and thinks they are > > too stupid to understand a port number associated with a service is > > just another example why I wish that Fedora and Redhat would put > > work into alternative desktops. > > > > > > -Dan > > > ___ > > > 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 > > ___ > > 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 > > ___ > 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 ___ 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
Re: Fedora Workstation and disabled by default firewall
mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300: > On Tue, Aug 27, 2019 at 4:22 AM, John Harris > wrote: > > No, that is not how this works, at all. First, let's go ahead and > > address the > > idea that "if the firewall blocks it, the app breaks, so it's the > > firewall's > > fault": It's not. If the firewall has not been opened, that just > > means it > > can't be accessed by remote systems until you EXPLICITLY open that > > port, with > > the correct protocol, on your firewall. That's FINE. That's how > > it's designed > > to work. There's nothing wrong with that. > > > > This means that the system administrator (or owner, if this is > > some > > individual's personal system) must allow the port to be accessed > > remotely, > > before the app can be reached remotely, increasing the security of > > the system. > > You've already lost me here. Sorry, but we do not and will not > install a firewall GUI that exposes complex technical details like > port numbers. Expecting users to edit firewall rules to use their > apps is ridiculous and I'm not really interested in debating it. Yeah, when you ask users questions they're not qualified to answer, you're just creating bad design. I always imagine my mom (who BTW has been a Fedora user for years) how she'd deal with that and I can't really imagine her opening/closing firewall ports. She'd be puzzled even by "Do you trust this network?" and would probably just click "Yes" to make it go away. No additional security, just annoying UX. Jiri ___ 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
Re: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
Kamil Paral píše v St 24. 07. 2019 v 13:37 +0200: > On Tue, Jul 23, 2019 at 7:44 PM Ben Cotton > wrote: > > https://fedoraproject.org/wiki/Changes/Anaconda_Reclaim_Disk_Space > > > > The Manual Partitioning screen supports all actions of the Resize > > Disk > > Space dialog, so it doesn't make sense to have two user interfaces > > with the same functionality. > > The manual partitioning screen is also much more complex and > therefore more difficult to use. For the common use case of > installing Fedora alongside Windows (where you need to shrink the > Windows partition), the simple dialog is/was great. Linux novice > users might not be able to accomplish that in the manual partitioning > screen. > > Just my personal opinion, I'm not trying to convince you to revert > your plan. I second Kamil here. I've introduced hundreds of people to Fedora and "I've got Windows on the disk and need to reclaim space" is by far the most common scenario among Fedora novices and instead of giving them a simple dialog we're sending them to the manual setup which I as a Linux user for 15 years have problems to get oriented in. Is it really such engineering overhead to keep that dialog there? Jiri ___ 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
Re: Fedora Lifecycles: imagine longer-term possibilities
mcatanz...@gnome.org píše v Čt 15. 11. 2018 v 19:00 -0600: > On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller > wrote: > > But there are some good cases for a longer lifecycle. For one > > thing, > > this has been a really big blocker for getting Fedora shipped on > > hardware. Second, there are people who really could be happily > > running > > Fedora but since we don't check the tickbox, they don't even look > > at > > us > > seriously. I'd love to change these things. To do that, we need > > something that lasts for 36-48 months. > > "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years" > > https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lts-linux-support-to-10-years.html > > I just don't see how we're going to be able to compete with that, > not > unless our Fedora LTS is just CentOS with different branding. As I understand it the intend is not to compete with Ubuntu who has a longer support, but to have long enough support to be a viable option for hardware vendor etc. IMHO anything above 5 years doesn't matter much on desktop, especially laptops. So Ubuntu could have 15 years of support, but it wouldn't mean that Fedora with 3-4 years couldn't compete with it. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Neal Gompa píše v St 14. 11. 2018 v 07:54 -0500: > On Wed, Nov 14, 2018 at 7:49 AM Kalev Lember > wrote: > > On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote: > > > If Fedora had longer life cycles, and more streams maintained in > > > parallel, then I think the result would be that I end up doing > > > rebases for everything I maintain rather than trying to backport > > > anything. Admittedly this would somewhat negate the supposed > > > benefit > > > of having stable long life releases, but its either that or the > > > releases bitrot accumulating more & more bugs & security flaws. > > > > I agree, this would lead to too much workload on the maintainers if > > we > > just add a new long-lived branch. There's already rawhide, F29, > > F28, F27 > > which is already quite a lot of branches to maintain. > > > > However, I think this could work if we change how long we maintain > > the > > non-LTS branches. > > > > If we reduce the non-LTS supported time from 13 months to, let's > > say, 7 > > months (2 months overlap to allow for time to upgrade) then perhaps > > it > > could work? And then add a LTS branch that's supported for 3 years? > > We'd > > have the same number of branches as now, just that one is LTS. > > > > That's basically the Ubuntu model. They do 9 months for regular > releases, and 5 years (originally 3 years) for LTS releases. > > However, what could also work would be something along the lines of > openSUSE Evergreen[1] model (prior to the shift to openSUSE Leap + > Tumbleweed), where the community decides on a version to stabilize > and > maintain for bugfixes for an extended period of time. If we wanted to > talk about having extended lifecycles, I think this would be a > workable model. This would be similar to the original Fedora Legacy > project (if anyone remembers that!). That's my thinking, too. Having releases supported for 7 months is not really worth it, let's rather switch to a stable rolling release for those who want the latest and greatest. LTS will be there for the rest. And the rolling release version can also serve as a stream of apps for LTS releases. We can build the latest Firefox with the latest stable Fedora bits and provide it on LTS releases as a flatpak. A single build for all releases. The model may actually even be easier for maintainers. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500: > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote: > > > I understand this argument, but I think more and more desktop users > > are being trained that updates happen on a schedule they didn't > > choose > > and are hard to avoid. This is how most mobile operating systems > > function. > > iOS prompts you for the yearly updates, and it can be avoided if you > really want. > > macOS requires you to specifically choose the yearly update, though > they may have changed with Mojave. > > Not sure about Android, but the fact that Google has had to twist > things into a knot to try and get updates out to users indicates that > upgrades to Android aren't being pushed out for the most part. > > Windows is the only one forcing upgrades, and it is perhaps one of > the > reasons that hardware vendors are showing more interest in Linux as > people are now more willing to consider anything other than Windows. > > Really, the only place where forced upgrades are happening, are > accepted, and seem to actually work are on the application side and > that is because, demonstrated by the web browsers, frequent updates > can be done unobtrusively and reliably. And with the named examples are you gonna get any support and updates if you decide to hold off an upgrade to a newer OS? I doubt. I can certainly hold off upgrade to Android 9 on my phone, but that doesn't mean I'm gonna get any further updates for Android 8 from the phone vendor. There is a huuuge difference between "not forcing upgrades" and "providing supported and secure way to stay on the current release". Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Lifecycles: imagine longer-term possibilities
Matthew Miller píše v Út 13. 11. 2018 v 18:36 -0500: > Hi everyone! Let's talk about something new and exciting. Since its > first release fifteen years ago, Fedora has had a 13-month lifecycle > (give or take). That works awesomely for many cases (like, hey, we're > all here), but not for everyone. Let's talk about how we might > address > some of the users and use cases we're missing out on. > > When I talk to people about this, I often get "hey, you should do LTS > or go to rolling releases.” As I've said before, on the surface > that's > a weird thing to say, since the actual user impact of those two > different things is mostly _opposite_. So, digging in, it often > really > means "I don't want the pain and fear of big OS upgrades". > > We've addressed that in several ways: first, making upgrades better. > (Thanks everyone who has worked on that.) A Fedora release-to-release > update is normally not much more trouble than you might get some > random > Tuesday with a rolling release. Second, we have some things like > Fedora > Atomic Host and upcoming Fedora CoreOS and IoT which both implement a > rolling stream on top of the Fedora release base. And finally, > there's > the coming-someday plans for gating Rawhide, making that a better > proposition for people who really want to live on the edge. > > But there are some good cases for a longer lifecycle. For one thing, > this has been a really big blocker for getting Fedora shipped on > hardware. Second, there are people who really could be happily > running > Fedora but since we don't check the tickbox, they don't even look at > us > seriously. I'd love to change these things. To do that, we need > something that lasts for 36-48 months. > > So, what would this look like? I have some ideas, but, really, there > are many possibilities. That's what this thread is for. Let's figure > it > out. How would we structure repositories? How would we make sure > we're > not overworked? How would we balance this with getting people new > stuff > fast as well? We've done a really good job stabilizing Fedora, but based on observations and conversations with users I think the model has been getting to its limit in terms of userbase. There are simply too many deplyoments which require a different kind of stability than the current Fedora can offer (things may not break, but they still change and change often). That's why I think LTS is an opportunity for us to grow. If we want to have an LTS I think we have to give up something. It'd be really difficult to do it on the top of the 6-month releases. An idea I've been entertaining recently is something like this: - unstable rolling release (Rawhide) - stable rolling release (basically gated Rawhide with stable versions of components) - for the early adopters who want the latest and greatest - LTS It would definitely need multiple groups with different treatment: Ring 1 - kernel+base user space, stability is the highest priority, if any rebases, then very well tested. Ring 2 - e.g. desktop environments, rebases allowed, but well tested and planned, perhaps aligned with some minor releases of Fedora LTS (.1, .2,...). Ring 3 - rolling release components, those can be based on the stable rolling release Fedora and shipped via Flatpak/modules... maintainers can then only support one version for all releases of Fedora, this can be a viable mode for most desktop apps. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire recordmydesktop
Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800: > On 11/5/18 12:47 PM, Adam Williamson wrote: > > On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote: > > > I don't know about the other bugs, but not working on Wayland > > > can't be > > > held against it. Nothing works to record the desktop on Wayland > > > since > > > that isn't supported yet. > > > > GNOME's inbuilt screen recorder does it fine. > > Does that use a Gnome shell-specific API or does Wayland have > support > for that now? You can either use Mutter API (several utilities can do that, not only the built-in tool) or newly PipeWire. Works both on Wayland and Xorg. Screen recording (or more precisely providing apps with screen frames) is not something Wayland as a protocol covers and plans to cover. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CVE-2018-14665 : Xorg X Server Vulnerabilities
Chris Adams píše v Čt 01. 11. 2018 v 09:53 -0500: > Once upon a time, Cătălin George Feștilă > said: > > Thank you! > > > > On Thu, Nov 1, 2018 at 4:38 PM Reindl Harald < > > h.rei...@thelounge.net> wrote: > > > > > > > > Am 01.11.18 um 15:33 schrieb Cătălin George Feștilă: > > > > https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html > > > > > > https://fedoraproject.org/wiki/Features/RemoveSETUID > > > Targeted release: Fedora 15 > > > > > > ls -la /usr/bin/Xorg > > > -rwxr-xr-x 1 root root 273 2018-04-23 20:16 /usr/bin/Xorg > > That means nothing... that's just a shell script that calls: > > $ ls -l /usr/libexec/Xorg.wrap > -rwsr-xr-x. 1 root root 11376 Apr 12 2018 /usr/libexec/Xorg.wrap > > which is where the problem lies. I think SELinux should help > (because > it should stop writes to lots of things), but I haven't seen a bug or > statement from Fedora about vulnerability. I wonder if Fedora has even been affected. I was not able to reproduce the exploit on Fedora 29 Workstation (with Xorg older than the one fixing the issue). Jiri > > Chris Adams > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Media Writer for macOS, is not signed?
Chris Murphy píše v Pá 11. 05. 2018 v 16:42 -0600: > Hi, > > The Fedora Media Writer for macOS at getfedora.org is not signed. I > filed this bug a couple weeks ago but somehow lost track of it, and > also it's possibly not the right location for the bug report as it > relates to what's offered on getfedora.org > > As I mention in the bug, it's not a big deal to use the work around > for unsigned binaries when testing. But today I tested both the macOS > and Windows versions available on getfedora.org, the macOS version is > not signed, the Windows version is signed by Red Hat Inc. > > https://github.com/FedoraQt/MediaWriter/issues/163 > > Is this this a releng issue I should file a separate bug for? Yes, this is a releng issue, the developer (Martin Bříza) doesn't sign the binaries. He only provides the code and it's built and signed by Fedora releng. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is Pagure slow for you too?
Kevin Fenzi píše v St 29. 03. 2017 v 13:01 -0600: > On 03/27/2017 11:35 PM, Adam Williamson wrote: > > > > It never used to be like that, it's probably just load as more and > > more > > stuff is moved to it. > > yeah. Note that I mentioned upthread that we had been working on > performance improvements of late. We just rolled out a new version > this > morning that has a number of them. > > For those that were seeing things be slow: Any improvement? > > (There is of course more work to be done...) > > kevin It seems much faster today. I've never seen Pagure being so fast before. Thank you for the work! Jiri signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is Pagure slow for you too?
Michael Catanzaro píše v Po 27. 03. 2017 v 08:17 -0500: > On Thu, 2017-03-23 at 11:14 +0100, Jiri Eischmann wrote: > > Hi, > > I wonder if it's just me or others also have problems with > > performance > > of Pagure. Pagure is always slower for me than e.g. Github, but > > it's > > bearable. However, there are times when I have to wait easily 30-60 > > sec > > to load a page which makes Pagure almost impossible to work with. > > > > Jiri > > To answer the original question: yes, Pagure is absurdly slow for me. > 30-60 second range. And you're located in the US, so it's not because of the distance as some suggested. As I said it's usually pretty slow for me (up to 5s) which can be explained by distance, but 30-60s lags must be some performance issues in peak times. I observed that Pagure is fastest for me during weekend which would be pointing to performance issues, too. Jiri signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Is Pagure slow for you too?
Hi, I wonder if it's just me or others also have problems with performance of Pagure. Pagure is always slower for me than e.g. Github, but it's bearable. However, there are times when I have to wait easily 30-60 sec to load a page which makes Pagure almost impossible to work with. Jiri signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Firefox 52.0.1: CVE-2017-5428
Pavel Valena píše v St 22. 03. 2017 v 04:36 -0400: > - Original Message - > > From: "Greg Evenden" > > To: devel@lists.fedoraproject.org > > Sent: Wednesday, March 22, 2017 3:26:48 AM > > Subject: Re: Firefox 52.0.1: CVE-2017-5428 > > > > > Does anyone know whether the fix for this problem is already in > > > F25 > > > builds of FF or should a new build be prepared and pushed to fix > > > this? > > > > > > See: https://bugzilla.redhat.com/show_bug.cgi?id=1433819 > > > > might as well use Google-Chrome , Least one doesnt have to WAIT a > > year or so > > for a Update to a security Bug thats pretty serious, an ya wonder > > why more > > users use UBUNTU > > You can try copr: > https://copr.fedorainfracloud.org/coprs/jackgreiner/firefox-trunk/ > > I did not test it thoroughly, but the trunk/nightly version seems to > work fine. I'd like to point out that the last build was done on Sept 20. Yes, 7 months ago. So it has probably its own fair share of unfixed CVEs and thus it should really not be recommended to use. If you'd like to have the latest Firefox immediately, you can use our Flatpak repo where we really build Firefox Nightly every single day: https://firefox-flatpak.mojefedora.cz/ Jiri signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Firefox 52.0.1: CVE-2017-5428
Greg Evenden píše v St 22. 03. 2017 v 02:26 +: > might as well use Google-Chrome , Least one doesnt have to WAIT a > year or so for a Update to a security Bug thats pretty serious, an ya > wonder why more users use UBUNTU Sure, someone who can't wait a couple of days for a fix (I'm not saying it's not a valid concern) will use Ubuntu with thousands of unmaintained packages in universe with tons of unfixed security issues :) I don't think security is the reason why people choose it over other distributions. Jiri signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Nautilus usability
Michael Schwendt píše v Ne 27. 11. 2016 v 00:53 +0100: > This is about F25 and F24, but likely applies to older releases, too, > since I haven't noticed any improvements about it. > > Have you ever made Nautilus copy/move a huge directory tree and then > started a similar task for other directories while Nautilus was still > working on the first task? > > What happens here is that there is this small progress icon, and if > you > click on it, a tiny window pops up showing the progress of each > Nautilus > task. It's tiny window that cannot be made larger. Try to scroll > down, but > Nautilus interferes and jumps to the top again frequently. Have you > ever... No, probably not the developers of Nautilus. That should > answer > the question raised above. > > And how to remove completed tasks or empty that window? Impossible > while > Nautilus is busy working on tasks. There only is a 'X' button to > cancel > running tasks and a non-clickable icon for completed and cancelled > tasks. Not helpful. Worse, cancelled tasks remain in the list, too. > > What am I missing? I'm missing a link to a bug report here. JE signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora development of Snap packages
Michael Catanzaro píše v St 22. 06. 2016 v 10:22 -0500: > On Wed, 2016-06-22 at 15:43 +0200, Vít Ondruch wrote: > > Eric, > > > > So how about similar article about Flatpack? I'd be interested to > > see > > the comparison between these two ... > > > > > > Vít > > FWIW, I saw some blog last week about how they used a debug build of > LibreOffice to build the snap, which is what accounted for the huge > size. They managed to get it down to 287 MB. LO for Flatpak is 160 MB + ~150 MB is the GNOME runtime. But the GNOME runtime can be shared with many other apps. So in terms of size, flatpak installations are slightly bigger in worst scenarios (you use the runtime just for one app) and significantly smaller in real life scenarios. But it's just because of the architecture with shared runtimes. Otherwise there is no reason for size differences, both package the same apps and same dependencies. Both technologies also support deduplication, which may have a significant impact on size if you have, for instance, installed several versions of the same app. But I assume its efficiency is roughly the same. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
Alexander Larsson píše v Čt 16. 06. 2016 v 21:11 +0200: > On Thu, 2016-06-16 at 14:24 -0400, Ben Rosser wrote: > > On Thu, Jun 16, 2016 at 1:30 PM, Matthew Miller > ct.org> wrote: > > > On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote: > > > > ship pip, npm, etc? Where I become uncomfortable, and the > > > reason I chimed > > > > in on this thread initially, is with the idea that these new > > > containerized > > > > packaging systems are in some way *superior* to traditional > > > packaging. Or > > > > at least that's what I read between the lines of the proposal > > > to allow > > > > upstreams to ask for their flatpaks or whatever to be shipped > > > in place of > > > > RPMs. > > > > > > I think that once the full sandboxing / portal system is in > > > place, > > > there _will_ be a tangible reason to prefer Flatpak. > > > > > > > > > > Well, assuming that turns out to be the case, should our packaging > > guidelines eventually become "do not make RPM packages of end-user > > applications but instead make a downstream flatpak package"? I'd > > probably have mixed feelings about this, too, and it's not what the > > Workstation proposal suggests at the moment, either, but it seems > > to be where we're eventually leading here. > > > > Or, we could have tooling to turn a RPM into a flatpak, perhaps (I > > know there's a script to do this for AppImages), and use this in > > our build infrastructure? > > For atomic workstation, this is the goal. We even need that, because > in that setup the OS (/usr) would be a read-only image (based on > rpms), so we could not install new rpms. Instead we'd take our > existing rpms and create flatpaks from them. It's useful for upstream projects, too. For instance, we decided not to include Java in the upstream LibreOffice flatpak because it's a big burden to maintain (checking for updates, rebuilding,...) the whole Java stack because of minor functionality. But then it's not a drop-in replacement for current official installation files and it will probably be required eventually. Then it's probably best to hook the flatpak building to some distribution, take the bundled components from RPMs and let the distro maintainers do the maintenance. An update of a distro RPM triggers an automated rebuild of the flatpak. Packages are IMHO far from being obsoleted. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
Gerald B. Cox píše v Čt 16. 06. 2016 v 11:45 -0300: > > On Tue, Jun 14, 2016 at 4:32 PM, Michael Catanzaro org> wrote: > > Challenge for the marketing folks: can we get these tech journalism > > sites writing about Flatpak instead? About GNOME Software's new > > support > > for displaying and installing Flatpaks in F24? Otherwise, I see > > upstreams adopting Snappy and not Flatpak. > > > > I've seen lots of articles about Snappy and didn't even know that > Flatpak existed. Granted I don't follow Gnome development and am > more interested in KDE and LxQT - but that said, I'm not particularly > interested in Ubuntu either. If the idea behind flatpak is to make > more packages available, it ain't going to work if people don't know > about it. Most people will just choose snappy or flatpak, ,and since > both work - just use the snappy format. It's like Beta and VHS or > more recently HD DVD and Blu-ray. If you have a universal format, > one will become dominant - and for better or worse, it's not > necessarily about which one is better, it has to do with marketing. > -- KDE has been interested in Flatpak for over a year. They even have a KDE runtime and a couple of KDE apps packaged: https://community.kde.org/Flatpak Yes, Snappy is better known because it's marketed by Canonical itself while Flatpak is still mostly pushed by the community, but I still believe Flatpak is better positioned to be a multidistro standard. Snappy has been developed with Ubuntu in mind only, just recently they made it work on other distributions (with a lot of shortcomings mentioned in this thread), the only reasonable way to distribute snaps is through Canonical's servers now, they require the unpopular CLA to contribute,... Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
James Hogarth píše v Čt 16. 06. 2016 v 15:57 +0100: > > On Tue, Jun 14, 2016 at 4:32 PM, Michael Catanzaro > e.org> wrote: > > > Challenge for the marketing folks: can we get these tech > > > journalism > > > sites writing about Flatpak instead? About GNOME Software's new > > > support > > > for displaying and installing Flatpaks in F24? Otherwise, I see > > > upstreams adopting Snappy and not Flatpak. > > > > > > > > > Isn't flatpak in gnome-software pushed back to F25 ? It partly supports Flatpak in F24. You can manage already installed apps, but you still need to use flatpak command to install them. In F25, you will be able to just download .flatpak file, double-click it and Software will install it and set its repo. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Tomas Orsava
Tomas Orsava píše v Út 16. 02. 2016 v 15:35 +: > Hi, I'm a new Red Hatter working in python-maintenance. > > I have submitted my first review-request: https://bugzilla.redhat.com > /show_bug.cgi?id=1308956 > It is the last missing dependency for a keyboard-driven, vim-like > browser called qutebrowser, which I hope to package next: > http://www.qutebrowser.org/ > > PGP public key 3FBEC9A9. > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org Hi, do you know if upstream is planning to port to QtWebEngine soon? QtWebKit has not been maintained for quite a long time and has many unfixed CVEs (>100), not sure if it's something that should be included in Fedora in the current state. For security reasons. We already have quite a few packages based on dead versions of WebKit to deal with in Fedora. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: LiveUserCreator as Primary Downloadable
Josh Boyer píše v St 27. 01. 2016 v 08:43 -0500: > On Wed, Jan 27, 2016 at 8:40 AM, Martin Bříza > wrote: > > On Wed, 27 Jan 2016 14:35:56 +0100, Josh Boyer > ct.org> > > wrote: > > > > > On Wed, Jan 27, 2016 at 8:30 AM, Jan Kurik > > > wrote: > > > > > > > > The correct name for this Change is "LiveUSBCreator as Primary > > > > Downloadable" instead of "LiveUserCreator as Primary > > > > Downloadable". I > > > > am sorry for the typo. The name has been fixed on the Wiki page > > > > as > > > > well. > > > > > > > > > I believe this Change is also Workstation specific, > > > correct? There is > > > nothing to indicate that in the email or wiki page, but I do not > > > believe this is targeted at Cloud or Server or any spin other > > > than > > > Workstation. > > > > Well the tool offers and allows you to write every Product/Spin/Lab > > Fedora > > has to offer (except Cloud) so it is relevant to almost everyone. > > True, however the website changes discussed are only for Workstation > from what I understand. The Change is mostly about the default > delivery of the tool, not what the tool is capable of doing. > > Put another way, if the Change proposers wish this to be the default > for all non-Cloud spins, they might want to at least start by pinging > the Server WG directly. Hi Josh, I'm planning to do so. We had been planning to introduce the new LUC for quite a while, but making it the primary download option was proposed just last week and the deadline for changes was Tuesday, so I didn't have time to discuss it properly with all potential stakeholders. Yes, we want it for Workstation and it makes total sense there. It makes sense for Server IMHO, too, but it's up to them. I'm not so sure about the spins because the tool is designed to give the prominent positions to the official flavors. If someone skips the default options on the website and goes directly to an alternative of their choice I'm not sure if they want to go through the same in LUC again. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Any Alpine and Claws Mail users here?
Hi, I'm writing an article on 6 most popular email clients in Fedora for Fedora Magazine. For each client I'd like to have a quote from a Fedora contributor why he/she is using that particular client. I'm missing representatives of Alpine and Claws Mail. If you happen to use them, can you please send me (off-list) a couple of sentences why? Those clients are mostly popular among technical people which is why I'm trying devel list. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Appdata files template for Fedora Workstation
Mattia Verga píše v Ne 17. 01. 2016 v 20:51 +0100: > Il 17/01/2016 18:58, Richard Hughes ha scritto: > > Are you using non-breaking UTF-8 spaces perhaps? Have a look in > > vim > > and see if it has lots of control chars showing. At the moment > > even > > xmllint won't validate it. Richard. > Thanks, yes. That was the problem. > Using validate-relax now is ok. > > Do also addons metainfo.xml files need to be validated in .spec file? > I > can't find anything about that on Packaging Guidelines. > Mattia Although the validation section [1] doesn't specifically mention metainfo files, I think it applies both to appdata and metainfo files. I myself add the validation in %check in all packages that ship any sort of AppStream metadata files. Jiri [1] https://fedoraproject.org/wiki/Packaging:AppData#app-data-validate_ usage signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Let's write metadata about add-ons
- Original Message - > From: "jens" > To: "Development discussions related to Fedora" > > Sent: Monday, December 21, 2015 11:47:47 AM > Subject: Re: Let's write metadata about add-ons > > Am 2015-12-21 11:36, schrieb Jiri Eischmann: > > Hi, > > due to previous efforts we have a pretty good appdata coverage of apps > > themselves, but add-ons (plugins, extensions,...) lag far behind. > > There are dozens of useful GUI app add-ons in Fedora repositories > > which don't have metadata files and are not exposed to users in GNOME > > Software. Let's focus on them. > > > > The goal of this iniciative is to have a metadata file for every > > useful add-on (for a GUI app) that is in Fedora repositories, so that > > those add-ons appear in app profiles in Software and are easily > > discoverable and installable for users. > > > > For more information visit > > https://fedoraproject.org/wiki/Workstation/AddonAppdata > > > > Jiri > > What about gnome-shell-extensions ? Hi Jens, the plan is to integrate GNOME Shell extensions in Software (all, not only the ones that are packaged) because Mozilla is going to discontinue support for NPAPI plugins which will also affect the GNOME Shell Integration plugin and make it impossible to install extensions via extensions.gnome.org. There is some initial discussion about it, but it's a different inicitiave because it requires more than just writing metafiles and GNOME Shell extensions are not app add-ons. Jiri -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Let's write metadata about add-ons
Hi, due to previous efforts we have a pretty good appdata coverage of apps themselves, but add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app add-ons in Fedora repositories which don't have metadata files and are not exposed to users in GNOME Software. Let's focus on them. The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI app) that is in Fedora repositories, so that those add-ons appear in app profiles in Software and are easily discoverable and installable for users. For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata Jiri -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: REMINDER: FESCo, Council, FAmSCo elections
Chris Murphy píše v Pá 11. 12. 2015 v 11:11 -0700: > On Fri, Dec 11, 2015 at 4:58 AM, Jan Kurik wrote: > > Hello everyone! > > > > I just want to remind you about the running Elections for FESCo, > > Council, FAmSCo. The voting period in now open and you can vote for > > your favourite candidate. The voting period closes promptly at > > 23:59:00 UTC on December 14th. > > > > If you have not voted yet, please do so: > > Should a reminder go to users@ and maybe on Fedora Forums? Those are IMHO primarily for users and users cannot vote AFAIK. I think this messages should go to channels that are primarily for contributors. Sending it to general audience would cause confusion. Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
Paul Wouters píše v St 09. 12. 2015 v 13:37 -0500: > On 12/09/2015 01:04 PM, Debarshi Ray wrote: > > On Mon, Dec 07, 2015 at 10:48:55AM +0100, Tomas Hozza wrote: > > > On 04.12.2015 15:57, Lennart Poettering wrote: > > > > How do other popular desktop/consumer OSes deal with this? > > > > Windows, MacOS, iOS, Android, ChromeOS? Does any of them do > > > > client-side DNSSEC validation by > > > > default and how are they dealing with this issue? > > > > > > I'm not able to answer this question. > > > > That is troubling. :( > > > > Since this is likely to break networking on a lot of client-side > > systems, I would have expected you to do this research before > > submitting it as a System > > Wide Change. > > We did. We are the First at undertaking this at an OS level. If the > others > proceed they will run in the exact same issue. The problem of broken > and > badly designed DNS setups is, is that they only go away when it > finally > breaks down. I'm glad to see Fedora being a pioneer in network security among OSes, but I'm not sure if pioneering something that will bring a lot of disruption into lives of our users is something Fedora can afford. Yes, insecure local DNS servers is a problem, but it's the kind of problem only market leaders can effectively crack. If Windows or Android stopped working with those DNS servers there would be complains from users, but there would also be enough pressure to fix it. Fedora is not relevant enough to make such pressure, and I don't think we're relevant enough to motivate the "big guys" to jump on the wagon right after us. So my worry is that we would be an OS which is more secure than others, but doesn't work in many networks. You can bet what the users would decide for... Jiri signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Is it time to allow Chromium in Fedora?
Gerald B. Cox píše v Út 11. 08. 2015 v 11:25 -0700: > There has been a lively discussion within KDE regarding the Konqueror > browser; and subsequently it has been decided that a non-KDE, GTK > browser will be the default for the spin. > > Why, because Firefox is the only choice for Fedora, Chromium is not > allowed. And how would Chromium make this particular situation better? It looks even less integrated in KDE than Firefox. Nevertheless, it looks like we will need to find a solution to this because Qt developers have decided to replace Qt WebKit with Qt Web Engine which is nothing, but a bundled Chromium. So if we want Qt apps in Fedora to draw HTML in the future, we probably won't have a lot of choice. Jiri On Tue, Aug 11, 2015 at 9:56 AM, Dan Mossor wrote: > > The correct avenue here, in light of the news from the upstream > > products, is to keep the status quo regardless of the lack of > > usability. When we finally get a fully-featured Qt based browser, > > that is when we switch. We DO NOT switch to a GTk based browser > > that has zero integration with the Plasma desktop - single click > > selection of files and directories within Firefox doesn't even > > work, let alone the theming and other issues. Ironically, those two > > items, as well as integration with kWallet, work fine with Google > > Chrome (which is not a choice in this discussion). > Tom Calloway has been working on Chromium - and his copr is up-to > -date for anyone who wants to try it. > https://copr.fedoraproject.org/coprs/spot/chromium/ > > It's been a slow slog working through the issues keeping it from the > official repository, but progress > has been made: > https://code.google.com/p/chromium/issues/detail?id=28287 > > Things have also changed over the years, and Chrome/Chromium's > popularity has continued to grow and is now packaged in Ubuntu, > Debian and Suse. Firefox has exceptions mainly because it is deemed > "to popular" to keep out of the distribution. I think it is obvious > to everyone that Chrome/Chromium is "at least" as popular than > Firefox. > > I realize we have our guidelines and we're not Debian, Suse or > Ubuntu... and that's a good thing. But, if we're making exceptions > for Firefox because of it's popularity shouldn't we do the same for > Chromium. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: LiveUSB Creator Revamped
Michael Catanzaro píše v Čt 28. 05. 2015 v 07:55 -0500: > On Thu, 2015-05-28 at 14:31 +0200, Martin Bříza wrote: > > Also, to see it without actually installing it, there's just a > > little > > bit > > outdated screencap: > > https://mbriza.fedorapeople.org/liveusb-6.ogv > > That looks quite good! > > I have just one comment: the < Back, Write to USB disk, Cancel, and > Write to disk buttons belong in a header bar, at least when running > in > GNOME. It's written in QML and I don't think something like header bar and CSD is possible there. Jiri -- 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: Rapid release for security updates
Reindl Harald píše v Út 19. 05. 2015 v 10:45 +0200: > > Am 19.05.2015 um 10:38 schrieb Martin Stransky: > > Hi guys, > > > > is there any mechanism how to speed up release of critical security > > fixes by Fedora update system? > > > > For instance Firefox packages are released *week* after official > > Mozilla > > release which is really bad. > > > > Any idea here? > > and that is *really* a Fedora problem because for CentOS you get > critical security updates instantly while the same packages are > waiting > for days in Fedora I don't think it's a fair comparison. CentOS gets updates from RHEL which has an army of paid testers. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Invitation to DevConf.cz 2015
Hi, let me invite you to DevConf.cz 2015 [1] which will take place in Brno, Czech Republic on Feb 6-8. The third day of the conference will again be Fedora Day with a lot of Fedora-focused talks and discussions (and also with a lot of Fedora contributors around). You can find the list of Fedora-focused talks and workshops at [2]. There are, of course, much more talks on Fedora-related technologies, just check the schedule [3]. Jiri [1] http://devconf.cz/ [2] https://eischmann.wordpress.com/2015/01/13/fedora-at-devconf-cz-2015/ [3] http://devconf.cz/schedule -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 Self Contained Change: Gnome Shell - New Notifications
Jaroslav Reznik píše v St 14. 01. 2015 v 13:00 +0100: > = Proposed Self Contained Change: Gnome Shell - New Notifications = > https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications > > Change owner(s): Florian Müllner > > Redesign the way in which notifications are shown and kept available in gnome- > shell. > > == Detailed Description == > The message tray is one of the remaining weaker points of the original gnome- > shell design. This change will replace it with a new implementation of > notifications that avoids the problems of the current implementation. > > == Scope == > * Proposal owners: > ** Implement the new design > ** Get the changes reviewed and merged upstream > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > > == Contingency Plan == > N/A (not a System Wide Change) What is still not very clear to me is if IM will still be somehow integrated into the Shell. I know I will be able to reply directly in the notification, but now if I miss the notification I can always go back to the contact in the message tray and see the conversation there. It's been a killer feature for me and many people around me and since Empathy itself is not very usable in GNOME 3 it'd be a pity to lose the integration. What about app icons for the notification area (Dropbox, Pidgin,...), where will they go? Jiri -- 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: Enable tapping by default
Mustafa Muhammad píše v Po 17. 11. 2014 v 14:27 +0300: > Hi, I am testing Fedora 21 beta and -like all previous versions- click > by tapping is off by default. > Several bug reports concerning this were closed as NOTABUG, but > tapping is useful for us (people who use it), I don't think it bothers > the others that much, and is on by default in most operating systems > and Linux distributions. > > What can we do to make this happen? If you're talking about Workstation, then you should probably propose it to their working group on the desktop mailing list. The working groups are supposed to do such decisions now. If you're talking about one of other spins (KDE, Xfce,...), then you should go to the respective SIG. Jiri -- 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: Enable tapping by default
Peter Hutterer píše v Út 18. 11. 2014 v 14:55 +1000: > On Tue, Nov 18, 2014 at 12:16:26AM +0200, Nikos Roussos wrote: > > On 11/18/2014 12:12 AM, Peter Hutterer wrote: > > > On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote: > > >> Hi, I am testing Fedora 21 beta and -like all previous versions- click > > >> by tapping is off by default. > > >> Several bug reports concerning this were closed as NOTABUG, but > > >> tapping is useful for us (people who use it), I don't think it bothers > > >> the others that much, and is on by default in most operating systems > > >> and Linux distributions. > > >> > > >> What can we do to make this happen? > > > > > > This comes up every couple of versions, so here is the reasoning for > > > disabled by default: > > > > > > * if you don't know that tapping is a thing (or enabled by default), you > > > get > > > spurious button events that make the desktop feel buggy. > > > * if you do know what tapping is and you want it, you usually know where > > > to > > > enable it, or at least you can search for it. > > > > Well, in practice most users just think it's broken. > > and you have references for "most"? We introduced Fedora to several hundred new computer science students at the local university and "How do I enable clicking by tapping?" was by far the most frequent question from those who had tried Fedora and come to us with questions. People just expect this to be enabled. Jiri -- 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: Join to Mozilla Location Service in Fedora
Sudhir Khanger píše v Čt 06. 11. 2014 v 19:33 +0530: > On Thursday, November 06, 2014 01:16:20 PM Martin Stransky wrote: > > I'd like to ask you to join the project, install the Mozilla Stumbler > > application [3] and help to improve the location accuracy. > > How do I benefit from broadcasting my location? Well, it depends how sensitive about your privacy you are. IMHO most people appreciate if they start e.g. GNOME Maps and the app shows right away where they are even on normal computers that don't have a GPS module. Or that you let Anaconda set system language, keyboard etc. based on their location. Such a database allows open source projects to have such a functionality. It's usually opt-in, so you don't have to use it and don't use it by default. This is at least designed as anonymous while Google tracks all Android users and saves their personal location data by default. I've been using Mozilla Stumbler for a few days and due to that my home laptop can be accurately localized when I want to use such a service. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EMEA sponsorship program for Flock
Hi, the EMEA regional community decided yesterday to organize a small sponsorship program for EMEA contributors who would like to attend Flock 2014 that is going to take place in Prague on Aug 6-9 and haven't received (and will not receive) any sponsorship as speakers. The overall amount of money allocated to the program is $2000. The funding limit per contributor is $200. The number of sponsored people is not limited and we will satisfy funding requests until we hit the limit of $2000. Candidates that have been actively contributing to the Project in the last year and have some work agenda for Flock (meeting team mates, organizing a "do" session,...) will be given a priority. The program is funded from the EMEA budget and is intended for contributors from this region. Other regions are assessing their budget situation and might come up with a similar program for their contributors. If you'd like to ask for a sponsorship, please file a ticket in the EMEA trac [1], mention your recent contributions to the Project and reasons why you want to attend Flock, and specify how much money you need (remember the limit is $200). The deadline is June 24 (12am UTC). The EMEA community has delegated the decision making to FAmSCo, so FAmSCo will then pick the best candidates if there are more requests than the available funding. Jiri [1] https://fedorahosted.org/emea-swag-tracking/ -- 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: Slipping F21
Reindl Harald píše v St 11. 06. 2014 v 17:44 +0200: > Am 11.06.2014 17:41, schrieb Jiri Eischmann: > > +1, we've already skipped one release and we just can't delay > > significantly more. Fedora is known as a fast-moving distribution. A > > large portion of our user base is using Fedora just for that reason. Do > > we really want to make even more of them switch to Arch? > > um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice > and so on - what are you missing that justifies "move move, go on move!" Well... where do I start? For example the whole default desktop platform? Yes, we have GNOME 3.12 Copr, but it brings practical problems. The whole graphics stack also cannot be completely rebased (it would require new LLVM which would be too significant change within one release) to benefit from all the great work Valve's initiative brought in the last months. So Fedora is not very appealing gaming platform these days. I guess everyone can pick something that they care about and that has become old since the freeze of F20. Jiri -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
Kalev Lember píše v St 11. 06. 2014 v 16:56 +0200: > On 06/11/2014 04:37 PM, Stephen Gallagher wrote: > > I forgot to open a ticket over the last week, but the Server WG has > > identified that completion of its core task (the Server Role API) is > > likely to need a little extra time. This is a blocker to release, so > > we figured it would be best to ask FESCo to modify the schedule in > > advance, rather than forcing a slip at the end. > > > > I'll bring this up in Open Floor, unless you want to add it to the > > formal agenda. > > How much time do you think you'd need to complete the Server Role API? If it's more than a month, then I don't agree with the slip of the whole release. > With my Workstation WG hat on, I'd very much like to avoid pushing back > the schedule. We already skipped one whole release; if we slip F21 it's > going to negatively impact how users perceive the Workstation, and make > it harder for Workstation developers to work on the code upstream. > > At the very least, please don't do a quick decision on today's IRC > meeting and allow some time to discuss this with other WGs. +1, this is an important decision that can't be done after a short discussion over a ticket that came last minute. > An alternative to slipping would also be to skip Server this release > cycle if it's not ready. Could try again in 6 months. +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? Release early, release often. We can't wait forever. If one of the products can't make it this release they can jump on train next release. There won't be any regression for server users compared to F20. Jiri -- 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: Copr and Playground plugin part of dnf-plugins-core?
Miroslav Suchý píše v Čt 24. 04. 2014 v 11:29 +0200: > In https://bugzilla.redhat.com/show_bug.cgi?id=1090516 > Jiri asked for removing Copr (and Playground) DNF plugin out of > dnf-plugins-core. > > Since this is not technical but merely political question I would like to ask > wider audience: > Put your voice here please: > http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05 > If there will be significant votes for one option, I would do what most of > you wish. > Otherwise I will forward it to Fesco for decision. > -- > Miroslav Suchy, RHCE, RHCDS > Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys In the ticket, one of the DNF maintainers said that the target audience of the copr plugin are developers using copr. That's IMHO completely wrong. Ubuntu has had the private repo infrastructure for years and it's used by a wide user base, definitely not only by developers or not even only by experience users. For example the GNOME 3.12 copr repo is used by thousands of users nowadays. Moreover the plugin is IMHO targeted rather at normal users to make adding a new copr repo easier for them. Developers have no problem with the traditional way. If the maintainers don't want to maintain it in dnf-plugins-core, I don't think we can do much about it. The question is if the plugin (whether it's part of dnf-plugins-core or in a separate package) should be preinstalled. And that's something working groups should decide. I'm 100% for having it preinstalled at least in Workstation. Jiri -- 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: Considering GNOME 3.12 as an F20 update
Matthias Clasen píše v Čt 03. 04. 2014 v 10:20 -0400: > Hey, > > so the time has come to consider this - thanks to the great work of > Richard and Kalev on the copr, we have a set of 3.12 packages that have > already received fairly wide testing. > > But we should be careful, so I want to ask for concrete problem reports > with the copr packages, besides dependency problems caused by the > parallel nature of the copr itself. > > Did any of your gnome-shell extensions break ? > > Did you experience crashes or other serious problems with applications ? > > If so, please let us know on the desktop list. If I don't hear of major > problems by next week, I'll file a Fesco ticket to ask for an exception. Hi, I've been using Richard's repo for two weeks. Here are some problems I've encountered: First after the upgrade I didn't even boot to GDM. Too bad I didn't debug it because I had already been considering a clean install, so I did it right away. My setup was not typical, I had been upgrading since F15. But apparently I was not the only one. One guy on the forum complained about a very similar problem. He blames i686 packages and their dependencies which might have been my problem as well because due to Steam I also had a lot from the graphics stack installed in i686 versions. But this is a case of my users and we should look into it because there can't be a worse scenario from user's POV than not booting into UI after updates. I've had quite a lot of problems with GNOME Software. It froze when hitting the Install button quite often. It couldn't find some applications. For example it couldn't find GNOME Photos, so I had to install it in yum. It didn't load the large banner of the picked app on the front page in many occasions. The hiding pointer in GNOME Terminal is pretty annoying. I haven't found a way to set up a connection via bluetooth with a connected device. There is no such option in the bluetooth module in the system settings and the network module or network section in the user menu don't provide such an option either after you set up a connection with a bluetooth device. I find this a significant regression. Otherwise it's been a pleasant experience and this release of GNOME seems to be very solid. But I would rather wait for at least 3.12.1 release and discuss it with Fedora QA because the upgrade should have at least a bit of systematic testing. Jiri -- 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
Rahul Sundaram píše v Čt 30. 01. 2014 v 11:06 -0500: > Hi > > > On Thu, Jan 30, 2014 at 11:01 AM, Stephen Gallagher wrote: > > That being said, as we go forward as Fedora.NEXT, we start to > see more > clearly defined divisions between Products, Spins and Remixes. > Since > these discussions needed to happen, we (FESCo) felt it was > best to try > to move the conversation public. > > > Part of the problem I have with this discussion other than the > alarmist subject is that we are discussing the "fate of spins" before > even coming out with concrete products out of the fedora.next > proposals. That seems premature. +1 I cannot agree more. We still don't have (at least I don't) have a clear idea how basics of Fedora.NEXT will look. So this discussion is really kinda premature. We should clearly define the products first, then we can discuss spins and the border between them and remixes. From bottom up please :) Jiri -- 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
Christian Schaller píše v Čt 30. 01. 2014 v 05:40 -0500: > 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 Well, I think there are not only monetary contributions. There are also non-monetary contributions and we should not forget about them. IMHO spins provide enough non-monetary contributions to Fedora to justify their existence within the Project and consumption of resources that are primarily sponsored by Red Hat. There is not any reliable data of desktop usage among Fedora users, but according to different polls almost half of our user base is using other desktops, hence spins. They are used by many contributors, their users also use, test and file bugs against parts of Fedora that are highly interesting to Red Hat. Getting them out of the Project or placing any financial barriers to entry the Project would mostly harm Red Hat in the end. Although I'm all for having a default spin that is primarily advertised and offered to people new to Linux or Fedora I think we should remain a distribution of choice. Getting spins out of Fedora and offer them the remix status is not the best path to a larger user base. I don't think that remix users report bugs in Fedora bugzilla much, for example. Jiri > - 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
DevConf.cz 2014 schedule is out!
Hi, I'd like to announce that the schedule of Developer Conference 2014, which also includes Fedora Day this year, is out: http://devconf.cz/schedule It features around 100 speakers of almost 20 nationalities that will have 68 talks and 30 workshops and labs. What may be especially interesting to Fedora users and contributors is the third day of the conference - Fedora Day. There will be Fedora-focused talks in the morning and Fedora planning, discussing, and working sessions in the afternoon. Most importantly, we still have some free slots in the afternoon section, so if you'd like to run a Fedora-related session, contact me. See you in Brno, Jiri -- 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: Dracut HostOnly or ConfigurationOnly?
Harald Hoyer píše v Čt 05. 09. 2013 v 16:51 +0200: > On 09/05/2013 04:10 PM, Vratislav Podzimek wrote: > > Hello, everybody, > > I'd like to know your opinion on one issue we have hit on live > > installations due to the DracutHostOnly feature [1]. Long story short: > > 1) Anaconda installs the kernel package > > 2) installation of the kernel package triggers dracut to generate initrd > > 3) dracut now generates so called "host-only" initrd, which, among the > > other things, means, that it contains only one keymap -- the one that > > was set in /etc/vconsole.conf at the time dracut was triggered to run > > 4) Anaconda configures the installed system based on the values set > > during the installation. > > > > The actual result is that if users type in their LUKS password with a > > keyboard layout different from 'us', let's say 'gb' they cannot type the > > password again on boot, because the initrd has only the 'us' keymap (set > > by default in the configuration file), even if there is > > 'vconsole.keymap=gb' as a boot option. > > > > There are two basic approaches how to fix this on the installer side: > > 1) write out keyboard configuration before packages are installed > > 2) regenerate the initrd at the end of the installation > > > > Both these solutions are not ideal from my point of view. And even if > > one of them is accepted and applied, there would still be the problem > > with systems, that have an initrd that blocks functionality of boot > > options (maybe there are more than vconsole.keymap, I don't know). > > > > So, is it a right thing to do to generate 3 MB smaller initrd's (the > > summed up size of all keymaps) not supporting some boot options? Does > > HostOnly mean the initrd works only with a specific host or that it > > works only with a specific configuration of a specific host? I > > understand having firmware for hardware that does not exist in the > > system might be useless, but not supporting boot with a different > > configuration options seems to me as a different thing. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180 > > > > host only means, it only works on that machine (kernel modules) with that disk > layout (including language and keymap for disk passwords). > > https://fedoraproject.org/wiki/Features/DracutHostOnly#Release_Notes > > This Fedora release builds an initramfs tailored especially for your computer > hardware. If you change your machine or partitions or significant hardware, > you > might have to boot with the "Rescue" boot entry and execute "dracut > --regenerate-all". Can this not be done automatically? If the system fails to boot because of significant hardware changes, it's an obvious option to regenerate initramfs. I can't image a normal user go to the rescue mode and run "dracut --regenerate-all". Not that it's difficult to do it, but the discoverability of the solution is bad. Jiri -- 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: Summary of accepted Fedora 20 Changes - week 30
Marcela Mašláňová píše v Pá 26. 07. 2013 v 10:33 +0200: > On 07/26/2013 01:20 AM, Toshio Kuratomi wrote: > > On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: > >> On 25 July 2013 16:59, Billy Crook wrote: > >>> On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera > >>> wrote: > Given the amount of time that he spent on the mailing-list fighting for > those features, then it looks like a waste of time, that work has been > done. > >>> > >>> Unfeatures technically. He wanted to remove features from the Default > >>> spin. Subtracting functionality is not a feature. He wanted an > >>> unfeature. > >>> > >> > >> No he wanted out of the default install. We have a badly defined > >> naming scheme which is causing confusion: > >> > >> default install -> what you get when you put the DVD in and do a click > >> through install. > >> default spin -> The GNOME desktop livecd. > >> > >> Spins are managed by their respective "teams": > >> default has been GNOME and managed by GNOME sig > >> kde is managed by KDE sig > >> xfce is managed by XFCE sig > >> etc etc > >> > >> So I would say that the GNOME team is within its rights in managing > >> its spin. Whether it is named default etc is someone else's problem. > >> > > This has come up before and I think it's just plain unclear :-( > > > > The problem is that the desktop spin and the default spin are kinda two > > different roles but they are occupied by the same Product. In browsing old > > tickets, I see some times when fesco has decided the default spin didn't > > have to do what other other things did and sometimes when fesco said they > > did. AFAICS, there's been no generalized policy put into place in regards > > to this. So it's something that is decided on in every case where it comes > > up. > > > > I don't think anyone thought they were doing anything wrong by making the > > change in the desktop spin but because the desktop spin has more than one > > owner, I've sent it back to FESCo to vote on whether allowing this change > > there is something we intended or not. > > > > (/me notes that if mattdm's Ring 1 was defined, this might be somewhat > > easier to decide upon. If sendmail was in Ring 1 it would be an expected > > part of the Fedora Platform. Anything general purpose and carrying the name > > Fedora would probably have to carry it as well. If sendmail was in Ring 2, > > it probably would be fine to choose whether to install it or not as it > > wasn't a guaranteed part of the BaseOS. [You could also > > s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) > > > > -Toshio > > > > > > > Reverting the change or creating the GNOME spin without rsyslog would be > valid options. FESCo decided to leave rsyslog in standard, which means > it should be installed in the default spin. Default spin is now shipped > with GNOME, so it should use FESCo guidance. > > I wouldn't miss default spin at all. At least in Europe we are giving > multi desktop DVD, so the default lost it's purpose anyway. Note that we're only giving away 4000 multidesktop DVDs in Europe. And that's a really small portion of total installations. The multidesktop live DVD is rather a special edition allowed by circumstances (CD, DVD, and dual-layer DVD are about the same cost to produce) than something we should aim for everywhere. Moreover as we will probably be slowly switching to low-cost USB flash drives with a smaller capacity we probably will have to reduce the selection again. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora as an crowd founded project an additional funding source to our sponsor
"Jóhann B. Guðmundsson" píše v St 24. 07. 2013 v 10:01 +: > On 07/24/2013 07:33 AM, Brendan Jones wrote: > > > On 07/24/2013 03:50 AM, "Jóhann B. Guðmundsson" wrote: > > > Earlier this evening I was asked how I expected Fedora to function > > > in > > > any way similarly to how it does now without the backing of one or > > > more > > > organizations like Red Hat. > > > > > > I gave the quick answer "through donations" since I was not in > > > mood to > > > give the detailed answers ( and taint that thread even further ) > > > however > > > I'm about do it here to certain extent since the questioner > > > probably did > > > not expect me to have actually given this any thought which I > > > actually > > > have although I have not chiselled it into stone, making it the > > > concrete > > > proposal the community demands since it's just a small fraction of > > > a > > > True gifts are largely unregulated and untaxed. > > > larger idea or rather vision I have but I have decide it be the > > > correct > > > time to share that part of that vision of mine with the rest of > > > the > > > community to gather feedback. > > > > > Under the current model I thought it is not possible to make > > monetary donations to Fedora (I remember Jared Smith saying > > something about this at a linuxconf.au a while back) Hardware, > > physical items, consumable media etc is OK though. Something to do > > with US taxes, correct me if I'm wrong. > > I dont think "gift economy" will work for us either because anything > you "give" to the project can be seen as being given with the > anticipation of return or obligations under us laws. > > Anyone from the legal needs to answer the question what the options > are regarding the Fedora trademark and donations ( can it /needs it to > be change from trademark to something else ) and what Red Hat can and > cannot do ( even if it's not willing to do that ) so we can as a > community focus on the options available to us. The legal entity of Fedora is currently Red Hat. So the only way to send money to the Project is to send it to Red Hat. That of course doesn't stop you from paying people directly for working on Fedora or covering some costs that are related to Fedora. But let me add a link to this discussion: http://opensource.com/business/13/7/donations-open-source-projects I think I've got some experience with how open source projects work and there is a lot of truth in that article. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)
Marcela Mašláňová píše v Út 23. 07. 2013 v 18:45 +0200: > On 07/23/2013 06:07 PM, Jiri Eischmann wrote: > > Matthew Miller píše v Po 22. 07. 2013 v 09:38 -0400: > >>Conclusion > >>--- > >> > >>* Refocus Core to provide a better platform for building on > >>* Make room for innovation at the "Ring 2" level > >>* Empower SIGs to create solutions that fit > >>* Won't break what we have > >>* And we can start right now > >> > >> So there we have it. Comments and discussion, please! > > > > The proposal looks frankly very cloud-centric. I have no problem with > > that. What else should a Fedora cloud architect propose? But I'd like to > > know a few things: > > Is the proposal based at least a bit on some kinda of analysis of our > > more successful competitors in the cloud area? Yeah, I'm speaking about > > Ubuntu which currently holds 50 percent of the market. Ubuntu has been > > very successful in the cloud and in the proposal I really don't see a > > lot of things that Ubuntu has/does better and Fedora doesn't have/does > > worse. > > I just want to make sure that we won't turn the whole Fedora upside down > > to make us more successful in the cloud and then find out that something > > completely different was making us unsuccessful and competitors > > successful. IMHO closings gaps between the competitors and us and > > staying excellent in our strong areas would probably be probably a safer > > strategy than turning everything upside down. > > > > BTW speaking of Ubuntu, I think they've got quite different strategy - > > one tightly integrated product across all uses (server, cloud, desktop, > > and now maybe even tablets and phones). To solve the problem of newer > > versions, special interests etc., they've got the ecosystem of PPAs. > > That's where third-party entities can deliver software the way they > > want. And AFAIK it has been widely popular with upstream projects > > because they've got free hands with PPAs. And Ubuntu still has one > > defined product and doesn't have to lower standards for software > > inclusion. > > IMHO it's a better solution than breaking the distribution into several > > parts with different speed of development and different quality > > standards from which you can build all kinds of fragmented products. At > > least from the marketing point of view. As a user, I'd rather use a > > well-defined distribution with one set of quality standards (and if I > > wanted something special, I'd easily enable a third-party repo for that) > > than a distro with well-defined core, but not so well-defined layers of > > grey zone above it. > > > > Just my 2c, > > Jiri > > > I'm not cloud person at all and I like the Rings proposal. Server can be > still based on Ring0 and Ring1, so I don't see how it harm other use-cases. > Same standards for all packages simply didn't work. It can be seen > during every (mass, language) rebuild, which brings many problems for > those running the rebuild. Different people tend to package things > differently, even if there are guidelines. Lowering standards in some > areas and creating packages automatically might give people time to work > on their projects based above these packages. I guess the example with > Hadoop and Jetty is a good one, which can be often seen. > I also believe we need something like PPA. If koji needs new features, > or if new build system would be used, that's another part of the discussion. I admit I look at things maybe too much from the marketing point of view. Whenever I see such a proposal I ask myself how the current users and potential users will receive it and if it meets their needs and expectations. I came from the Debian world and what I've really loved about Fedora are its high standards and very little compromises in the quality of packages (compared to others) and that I can expect that from all packages included in Fedora (at least we aim to this). That makes Fedora a clear and understandable product as a distribution. Reading the proposal I'm getting a feeling that we're losing it a bit. But it depends what particular changes will be implemented. I'm not saying that it's a completely wrong direction. Maybe if we define well the minimal standards for the most outer ring and make a clear line between what is still Fedora what it isn't, it could work. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)
Matthew Miller píše v Po 22. 07. 2013 v 09:38 -0400: > Conclusion > --- > > * Refocus Core to provide a better platform for building on > * Make room for innovation at the "Ring 2" level > * Empower SIGs to create solutions that fit > * Won't break what we have > * And we can start right now > > So there we have it. Comments and discussion, please! The proposal looks frankly very cloud-centric. I have no problem with that. What else should a Fedora cloud architect propose? But I'd like to know a few things: Is the proposal based at least a bit on some kinda of analysis of our more successful competitors in the cloud area? Yeah, I'm speaking about Ubuntu which currently holds 50 percent of the market. Ubuntu has been very successful in the cloud and in the proposal I really don't see a lot of things that Ubuntu has/does better and Fedora doesn't have/does worse. I just want to make sure that we won't turn the whole Fedora upside down to make us more successful in the cloud and then find out that something completely different was making us unsuccessful and competitors successful. IMHO closings gaps between the competitors and us and staying excellent in our strong areas would probably be probably a safer strategy than turning everything upside down. BTW speaking of Ubuntu, I think they've got quite different strategy - one tightly integrated product across all uses (server, cloud, desktop, and now maybe even tablets and phones). To solve the problem of newer versions, special interests etc., they've got the ecosystem of PPAs. That's where third-party entities can deliver software the way they want. And AFAIK it has been widely popular with upstream projects because they've got free hands with PPAs. And Ubuntu still has one defined product and doesn't have to lower standards for software inclusion. IMHO it's a better solution than breaking the distribution into several parts with different speed of development and different quality standards from which you can build all kinds of fragmented products. At least from the marketing point of view. As a user, I'd rather use a well-defined distribution with one set of quality standards (and if I wanted something special, I'd easily enable a third-party repo for that) than a distro with well-defined core, but not so well-defined layers of grey zone above it. Just my 2c, Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: Application Installer
Adam Williamson píše v St 10. 07. 2013 v 14:35 -0700: > On Wed, 2013-07-10 at 09:51 -0600, Kevin Fenzi wrote: > > On Wed, 10 Jul 2013 13:02:24 +0200 > > Jaroslav Reznik wrote: > > > > > = Proposed Self Contained Change: Application Installer = > > > https://fedoraproject.org/wiki/Changes/AppInstaller > > > > > > Change owner(s): Richard Hughes , together with > > > the desktop team > > > > > > We will replace the existing gnome-packagekit frontends > > > (gpk-update-viewer and gpk-application) by a new application. > > > > Would there be any value in keeping those around for a cycle or so for > > folks that prefer package centric updates? Or better to just ask them > > to move to yum/yumex/apper now? > > FWIW, everyone seems to hate gpk-application, so I doubt anyone would > shed any tears over its loss. =) And if gpk-update-viewer has any > committed fans, I ain't met 'em. And AFAIK Yumex is still maintained and in Fedora repositories and IMHO does the job better than gnome-packagekit. So I wouldn't worry about getting rid of it completely either. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Matthew Miller píše v Pá 12. 07. 2013 v 23:24 -0400: > On Thu, Jul 11, 2013 at 12:53:23PM -0700, Adam Williamson wrote: > > "What do we talk about when we talk about Fedora?" :) > > Well, we just did a major release. Go look on news.google.com for > > "Fedora 19", or search for "Fedora 19 review", or just poke through a > > few popular tech sites and forums. > > What do people do when they want to 'try Fedora 19'? They download the > > primary image on the download page, which is the desktop live, and run > > it. This is what they've _always_ done. > > Well, this is partly self-reinforcing, because it's what we clearly tell > people to do. See http://fedoraproject.org/get-fedora, or the Download Now > link on the front page. > > S, speaking of which: > https://fedoraproject.org/wiki/Changes/VisibleCloud I think this is mixing up things together a bit. I don't think no one thinks we can create an ISO that would work perfectly for all uses (desktop, server, cloud,...). IMHO the ideal situation should be: A user interested in Fedora goes to fedoraproject.org and is asked "Do you want to run Fedora as desktop, server or a cloud instance?" and each answer should give them one ISO, the official default product of Fedora Project for that use. But that doesn't mean we should overwhelm them with gazillion options for every use. So it's ok to have a cloud version to download at http://fedoraproject.org/get-fedora but I think we want to offer them just one product for cloud, the one we're focused on the most, we test the most, not all flavours we could possibly have: Matthew's compilation for cloud, Joe's compilation for cloud,... And the same applies to other uses such as desktop. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
"Jóhann B. Guðmundsson" píše v Čt 11. 07. 2013 v 09:17 +: > On 07/10/2013 09:28 PM, Adam Williamson wrote: > > > On Wed, 2013-07-10 at 13:56 +, "Jóhann B. Guðmundsson" wrote: > > > > On 07/10/2013 12:36 AM, Bill Nottingham wrote: > > > > > > > > > > Plus, in relation to this - the llvmpipe issue brings up that one of > > > > > > the 'release blocking desktops' *does not work*. This would, by > > > > > > definition, > > > > > > block the release unless we intend to have different criteria for > > > > > > ARM as a > > > > > > primary arch. > > > > > > > > Then we should remove the default label and "release blocking > > > > desktop(s)" entirely concept with it. > > > > > > > > It's far outdated anyway and relic from the past. > > > > > > > > Each sub-community ( be it spins be it various arch ) should need to > > > > provide the necessary QA/Releng resources from their sub-community > > > > ( if no such thing the relevant party needs to build one ) while we QA > > > > and Releng focus our available resources on the components that > > > > everyone in the whole distribution use and provide the necessary sub > > > > community with the assistance in relation to QA and Releng. > > I'm afraid I can't agree. I like the simplicity of the model you're > > proposing, but from a practical point of view, there is still a commonly > > held perception that there is a 'product' called Fedora which is > > basically composed of what you get if you go to get.fedoraproject.org, > > download one of the things we push at you there, and install it. > > Practically speaking, I believe we have to QA that 'thing called Fedora' > > as a whole. I don't think your model quite matches what people perceive > > Fedora to be. > > What's your definition of what people perceive Fedora to be? > > Regardless of peoples perception or what you think they are there > still would be products however we QA would take care of the installer > + base/core os bits and sub-communities that build upon that base/core > OS like Gnome takes care of QA their own spins. > > Who better are to QA their own spin then the people that a) use it b) > create it c) release it? Have you ever reached to these sub-communities and asked them if they are interested in something like this? Because I'm not sure whether they're and forcing something like this upon them is not the best idea. First I think keeping the QA know-how in one team actually has a lot of benefits. Second I don't think that the sub-communities or spins, if you will, have enough manpower and expertize to run their own QA teams. The current team of Fedora testers is rather small and dividing them into several more teams would lead to a subcritical number of testers to run a functional QA. Third I don't agree with the opinion that people who create the software are the best people to test it. Quite the opposite. Having a QA team independent on spins is actually a very good idea. I have witnessed a lot of situations where developers were too lazy/busy/... to fix serious problems and it was pertinacity of our independent QA team that forced them to fix the problems although it sometimes took an escalation to FESCo. I highly doubt that spin's QA teams would develop into such independent entities. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugzilla.redhat.com vs upstream bug trackers
Emmanuel Seyman píše v Po 17. 06. 2013 v 15:39 +0200: > * "Jóhann B. Guðmundsson" [17/06/2013 12:49] : > > > > It's package maintainers responsibility to act as the liason between > > upstream and Fedora thus reporters only need to report in our > > Bugzilla instance. > > Even when upstream has requested that their bug tracker be the only one used? Well, I think Red Hat Bugzilla should always be the default option. We really can't require users to report in other bugzillas. Of course, if someone is more experienced, more into testing, and want to help developers/packagers, then they can do whatever works better for them. For example, I know that our maintainers of GNOME appreciate bugs reported directly to GNOME bugzilla because there is a little or zero delta between upstream and Fedora. So if it's a bug that doesn't influence Fedora release or something, I report it directly to GNOME bugzilla. If it's something I found during focused testing of Fedora or if it might be a release blocker, I always report it to the Red Hat bugzilla, too. But I do believe that the general rule should be to report bugs in RH bugzilla. And that's what we should advertise among users and what maintainers should be ready for. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does anyone still use system-config-language?
Hi, I wonder if any spin is still using system-config-language. GNOME has its own graphical utility to install language support, but AFAIK there is no counterpart in other environments, right? The problem is that system-config-language is completely broken since F18 (see [1] because it didn't reflect changes in language groups. So if there is no spin using it, we should probably remove it from Fedora because in the current state, it's completely broken and useless. If there is still need for the utility, then it probably should be fixed. BTW what are recommended ways to install language support in e.g. KDE and Xfce? Is there any other graphical way other than system-config-language? Jiri [1] https://bugzilla.redhat.com/show_bug.cgi?id=901831 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Dan Mashal píše v Út 29. 01. 2013 v 04:25 -0800: > I'll tell you what, last time I checked #1 spin is KDE. 1. because the Desktop "spin" is not included in the counter. 2. I doubt those numbers are accurate. Only 54 downloads of Xfce spin for this release? I hope you understand it's completely out of the reality since there have been over 200,000 direct downloads of F18. I think those numbers have been in question several times. Someone even suggested we'd remove them. Polls are not a good way to find out what the majority wants. Because the subset of users that usually participate in such polls don't represent the whole user base. It's just not a statistically representative sample. BTW I've got slightly different stats: http://eischmann.wordpress.com/2012/08/09/what-desktop-environments-are-czech-fedora-users-using/ It may not be a 100% accurate, but it's based on a survey with over 4000 submitted results, so it has some relevance. And please stop all that talk about excluding RHT employees from any decisions. I think we're all equal and one big community. I spend a lot of my free time working for Fedora and this really offends me. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
drago01 píše v Čt 03. 01. 2013 v 14:43 +0100: > On Thu, Jan 3, 2013 at 2:27 PM, Jiri Eischmann wrote: > > drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: > >> On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch > >> wrote: > >> > Jiri Eischmann wrote: > >> >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > >> > > >> > … > >> > > >> >> > 2. If not, do we want to engage in some Messaging around the F18 > >> >> > release > >> >> > to emphasize that we know there are all these issues and we'll try to > >> >> > smooth things out for F19? > >> >> > > >> > > >> > … > >> > > >> >> So yes, these issues are serious, but IMHO rather a long-term problem we > >> >> should focus on after releasing F18. > >> > > >> > +1 > >> > > >> > Let's point out the issues we are seeing with F18 amd get the release > >> > out of > >> > the door so we focus on fixing the stuff for F19. With all the drawbacks > >> > this > >> > solution has (e.g. unpleasant surprise for users with LUKS when they > >> > can't > >> > unlock their partition because of the changed layout ...) > >> > >> There is no point in releasing if we know that it is broken period. > >> We delayed the release already for a very long period why should we > >> rush and ship a broken release now? > >> And those issues are rather serious and affect a lot of users. > > > > Well, happy F18 Final release in 2053! Because that's the year by which > > we might fix completely all bugs in Fedora because if there is a bug > > it's broken period ;) No, I didn't miss it. I just don't agree with it. For example the bug reported by me, which is on the list, too, is not serious at all. And many other bugs are not even regressions in Fedora 18. They're caused by problems that have been in Fedora for some time and our current final releases suffer from them, too. So when the release is almost out of the door we suddenly wake up and decide to solve long-term problems that we were fine with in F17,... especially in the situation when we're already 2 months behind the schedule. It just doesn't feel right to me, that's all. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
drago01 píše v Čt 03. 01. 2013 v 14:13 +0100: > On Thu, Jan 3, 2013 at 12:06 PM, Fabian Deutsch wrote: > > Jiri Eischmann wrote: > >> Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > > > > … > > > >> > 2. If not, do we want to engage in some Messaging around the F18 release > >> > to emphasize that we know there are all these issues and we'll try to > >> > smooth things out for F19? > >> > > > > > … > > > >> So yes, these issues are serious, but IMHO rather a long-term problem we > >> should focus on after releasing F18. > > > > +1 > > > > Let's point out the issues we are seeing with F18 amd get the release out of > > the door so we focus on fixing the stuff for F19. With all the drawbacks > > this > > solution has (e.g. unpleasant surprise for users with LUKS when they can't > > unlock their partition because of the changed layout ...) > > There is no point in releasing if we know that it is broken period. > We delayed the release already for a very long period why should we > rush and ship a broken release now? > And those issues are rather serious and affect a lot of users. Well, happy F18 Final release in 2053! Because that's the year by which we might fix completely all bugs in Fedora because if there is a bug it's broken period ;) Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
"Jóhann B. Guðmundsson" píše v Čt 03. 01. 2013 v 12:40 +: > On 01/03/2013 10:37 AM, Jiri Eischmann wrote: > > So yes, these issues are serious, but IMHO rather a long-term problem we > > should focus on after releasing F18. > > I disagree I think we need to fix those things first. > > Ask yourself this, If the roles where reversed and US keymaps and > translation was broken and on that list, we would ship? I'm using the Czech layout (and I'm even so weird that I'm using QWERTZ) and Czech translations primarily and I haven't found any serious problems for weeks of using Fedora 18. The bug that I reported " that you remove the English keyboard completely in Anaconda and it's still there as a second option in GNOME after installation" is IMHO just a minor problem. And I haven't had any other problem with translations or layouts. Neither has my mother who is an average user and has been using F18 with Czech layout and translations even longer than me. No software will ever be perfect. OSes with a 6-month release cycle are in fact far from perfect. You always find tons of bugs when you dig in. It's about compromises. I always supported more quality in Fedora, but we have to take in account our time frame which is 6 months and we're already way behind it. And if you think that it's OK that a distro, that should be release every 6 months and has "First" as one of its 4 foundations, is released after 12 months, then I think it's not OK. And we also should take into account how much the problems affect people and how many of them. I follow a lot of user forums and discussions and people, who have tried Fedora 18, they're mostly satisfied with it (except for the partitioning in the installer). Look at the retrace server stats. The number of reports from F18 is already almost 1/3 of F17. I really don't want to end up delaying the final release again and again while most users are using it anyway. Still, we're not working for the sake of fixing bugs, we're working for users. > In anycase Adam has provided the necessary info on how utterly broken > these things are which should be sufficiant information for fesco to > take from there and decide if and then when we should release. Yeah, it's up to FESCo to decide. Neither me nor you can make the decision. But we can express our opinions ;) Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 issues with translations and keymaps
Adam Williamson píše v Čt 03. 01. 2013 v 00:03 -0800: > Hey, folks. I'm not really sure how to frame it, but the result of all > my poking about at keyboard layout bugs and related stuff recently is > that I'm pretty sad at the state of support for > anything-but-U.S.-English in Fedora 18. > > Here's the tally: > > * https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd > conversion from xkb to console layouts fails probably more than it > succeeds, when it does, you wind up with U.S. English as your console > layout, not whatever you picked during installation > > * https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda doesn't > seem to manage to offer all the keyboard layouts it could do, and some > of the ones it's missing are somewhat important > > * https://bugzilla.redhat.com/show_bug.cgi?id=891489 - anaconda's > mapping of 'native' layouts to user's chosen install language doesn't > work in all cases > > * https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has a > weird predilection for coming up with the obscure 'Bambara' layout in > user sessions after an install in a non-English language, but not the > correct layout for that language > > * https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME > keyboard layouts revert to U.S. English on upgrade to F18 > > * https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout > testing' in the keyboard spoke doesn't work at all how you'd expect it > to > > * https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact, people > have various problems interacting with and understanding the keyboard > spoke at all, really. Several of the issues discussed in this bug are > 'greatest hits', especially the lack of a default layout switch command, > the fact that anaconda doesn't automatically start using a layout you > promote to the top of the list, and the lack of any kind of indicator in > anaconda as to what layout is in use > > * https://bugzilla.redhat.com/show_bug.cgi?id=859641 - we're picking the > wrong default keyboard for Dutch, apparently > > * https://bugzilla.redhat.com/show_bug.cgi?id=867110 - ...and German > (Switzerland) > > * https://bugzilla.redhat.com/show_bug.cgi?id=885345 - ...and Dutch > (Belgian) > > (there's a few more along those lines which I won't bore anyone with) > > In addition to those bugs, we have fairly significant regressions in the > completeness of anaconda translations between Fedora 16 and Fedora 18 > (the numbers for F17 for some languages are weird - a lot of languages > show 55% completion for F17 but 90-100% for F16, which seems bogus, as > I'm sure things didn't change that much between F16 and F17, so I'm just > using the F16 numbers. I assume there's some weirdness that explains the > odd 55% numbers for F17, but if not, hey, F17 was kinda boned too...): > > Language F16 F18 > Finnish 93% 75% > Indonesian100%33% > Kannada 94% 33% > Oriya 94% 27% > Telugu94% 32% > Bengali (India) 93% 33% > Portuguese100%36% > Persian 95% 27% > Malayalam 78% 20% > NorwegianBokmal 92% 55% > Bengali 93% 33% > Sinhala 93% 27% > Serbian 81% 23% > Serbian(Latin)81% 23% > Hebrew83% 22% > Catalan 68% (98% F17) 25% > Latvian 88% 20% > Greek 68% 21% > Turkish 79% 21% > Maithili 67% 18% > Asturian 85% 24% > > (from https://fedora.transifex.com/projects/p/anaconda/ ) > > There are several others around the 50-70% complete mark for F16, too, I > just cut off at 67%. It's a fairly long list of languages for which we > previously had tolerably complete translation coverage, but we now have > a level which isn't really usable: basically these languages have gone > from 'covered' in at least F16 (probably F17 too) to 'not covered' in > F18. I want to stress I'm not blaming anyone for this: I don't see how > it could be otherwise, the problem is the huge amount of string churn > caused by newUI, I'm actually more amazed at how many languages _do_ > have close-to-100% translations for F18 than how many _don't_, given the > conditions. It's just an unfortunate thing. > > anaconda does not list every available translation for the user to > choose from, but I cannot figure out for the life of me how the decision > about which to display is made: it's not that very incomplete > translations are left out, as plenty of very incomplete translations > (including
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
M. Edward (Ed) Borasky píše v St 07. 11. 2012 v 22:06 -0800: > I've now done half a dozen F18 multi-boot installs and I must say it's > a miracle I haven't over-written something I wanted to keep. The thing > that would make it usable for me would be very simple - just put the > partition names on the labeling so I know what's going to end up > where! The rest of the installer is fine but the partitioner needs > either a user interface redesign or extensive documentation. Yes, I just did partitioning in the current F18 and I must say it's a piece of "art". I had old partitions on the disk and wanted to preserve /home. I don't think I'm an inexperienced user because I've done countless installations of different systems, but I completely failed to do what I wanted to do with the new Anaconda. And even Fedora QA guys, who heavily test it, had hard times to figure out how to do it. We can't expect any miracle improvements in Anaconda for F18, so we'll have to live with what we have now. But we'll need some serious usability testing for F19. And frankly lots of polishing, too, because let's face it, the current Anaconda is not a pleasure for eyes (but that bugs me the least about it right now). Jiri > On Wed, Nov 7, 2012 at 9:31 PM, Kevin Kofler wrote: > > Adam Williamson wrote: > >> The new anaconda UI and related features are more or less entirely the > >> cause of the slip. > > > > This shows that those changes should not have been done, or at least not in > > this way. > > > >> Secure boot support is also not done yet (waiting on the signature for > >> shim to get sorted out by legal), though I don't know whether FESCo yet > >> absolutely decided that has to be in for Beta. > > > > And Restricted Boot support just needs to go away! > > > > Kevin Kofler > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- > Twitter: http://twitter.com/znmeb; Computational Journalism Publishers > Workbench: > http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ > > How the Hell can the lion sleep with all those people singing "A weem > oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
mike cloaked píše v Ne 04. 11. 2012 v 21:44 +: > On Sun, Nov 4, 2012 at 9:07 PM, Jiri Eischmann > wrote: > > > This is a very valid argument. I understand this is a devel > list, so we should stay on the technical level, but if we > discuss such broad changes that affect the whole project, we > should also take into account other aspects. > > Switching to rolling release would have a *huge* negative > impact on marketing! It's releases what makes the fuzz and > their announcements get beyond our current user base. We would > have no release parties, no codenames. We would lose the > product. I wonder what impact it would have on Fedora adoption > by cloud providers. I think it's much more understandable not > only for them, but also for their customers to take Fedora 17 > than some monthly build. > > > > Does anyone have any reliable statistics about the number of users who > feel that release parties and codenames are important to them? Release parties and codenames were just examples. It's about the buzz around releases. You can check Google Trends where you find peaks in number of searches for Fedora after every release. Or fp.org monthly stats. You would lose reviews, that are usually published after releases, because I don't see any reviews of rolling release distributions by main magazines. Etc. BTW this is not just about current Fedora users. Marketing is mainly about potential users. > There will no doubt be some people for whom the idea of running a > particular codenamed release is important - but there will also be > others for whom a high quality established linux distribution that is > reliable and up to date irrespective of its codename is more > important. Marketing feedback if it is possible to give the relative > number of users in each camp would be helpful here? Gathering such > statistics is likely difficult though. > > I personally don't like the whole idea of switching to rolling > release. Although I see some pros, I see a lot of cons that > would outweight the pros. I've come across a few rolling > release distributions (Debian Testing, Arch Linux, Gentoo,...) > and I don't think they work if you want to achieve some level > of stability and predictability. > > > Arch linux is stable and reliable and predictable - I use it every day > - you need to ask users of the other distributions named whether users > feel they are similarly stable and predictable or not for the most > part. Well, as someone has already said here: stability and reliability are relative terms. I used Arch Linux for a while and I didn't find it stable and reliable on the level where I'd like to see Fedora. If you have to read release notes before every update to make sure you know what might break and how to fix it, then you're not using a system that would be appealing to a large number of user. And Fedora has always been aiming much broader audience than Gentoo or Arch. > Does anyone have any relative user stats on the various distros? > > > Do any web sites gather stats which might indicate hit rates coming > from different distros? > > > These data are difficult to get so in the end a clear goal for any > distribution has to be agreed on and then executed - if Fedora wishes > to go to rolling Rawhide but a bit more stable that at present and it > is possible to do that - then developers must agree at least on some > kind of overall vote maybe? In the end the users will guide whether > the route taken is being adopted widespread among the community. You > get some idea of users interested from feedback to the devel list, or > via bodhi I guess? > > > One other question that is hard to answer is whether a particular > change in direction is achievable since it depends on developers > adopting it and agreeing to work on it - inevitably some will not want > to go to any new route - but will the new direction excite other > developers to come on board that were not there before and make up any > loss? > > > The way I see it is that the two routes are a bit like asking if > people like meat or fish for the main course at a meal - there will be > a split opinion - and there are good points about both! Some people > may be allergic to one or other though! > > > Is there an objective list of pros and cons that can be judged without > bias in favour of rolling release or periodic releases so that a > logical weighing of the relative merits of both approaches can be > considered? If that goes in favour of rolling rel
Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))
- Original Message - > From: "Bruno Wolff III" > To: "Kevin Fenzi" > Cc: devel@lists.fedoraproject.org > Sent: Saturday, November 3, 2012 7:37:45 PM > Subject: Re: Rolling release model philosophy (was Re: Anaconda is totally > trashing the F18 schedule (was Re: f18: > how to install into a LVM partitions (or RAID))) > > On Sat, Nov 03, 2012 at 11:11:18 -0600, >Kevin Fenzi wrote: > > > >In any case, I think we do need to look at release cycle changes or > >at > >the very least Feature process revamp. > > And get comments from other than developers. Marketting might have > serious > concerns about the loss of exposure not having releases would result > in. This is a very valid argument. I understand this is a devel list, so we should stay on the technical level, but if we discuss such broad changes that affect the whole project, we should also take into account other aspects. Switching to rolling release would have a *huge* negative impact on marketing! It's releases what makes the fuzz and their announcements get beyond our current user base. We would have no release parties, no codenames. We would lose the product. I wonder what impact it would have on Fedora adoption by cloud providers. I think it's much more understandable not only for them, but also for their customers to take Fedora 17 than some monthly build. I personally don't like the whole idea of switching to rolling release. Although I see some pros, I see a lot of cons that would outweight the pros. I've come across a few rolling release distributions (Debian Testing, Arch Linux, Gentoo,...) and I don't think they work if you want to achieve some level of stability and predictability. I rather see some changes in Rawhide so that it becomes a usable distribution that people more interested in bleeding edge can use. Because now Rawhide does not even serve testing purposes because almost no one is using it. It'd like to see its stability on the level where Fedora branched is now (it's not a smooth experience, you should expect problems, use skip-broken from time to time, but it's usable). Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Tom Lane píše v St 31. 10. 2012 v 11:08 -0400: > Adam Williamson writes: > > ... Practically speaking, for F18, > > though, I think we just need to soldier on with newUI and get it done as > > best we can. Obviously slipping the schedule by a week again and again > > in response to the latest fire isn't the best way to do things, but > > stepping back and taking a wider view, a release that's a month or two > > behind but with a reasonably solid new anaconda wouldn't be a disaster. > > My concern at this point is exactly that we're "slipping a week at a > time", rather than facing up to the *undeniable fact* that anaconda is > not close to being shippable. If we don't have a workable contingency > plan, I think the best thing to do would be to start slipping a month at > a time. That would also definitely help from the PR perspective. Another and another announcement of a slip by one week is starting to be ridiculous. We should finally admit that we've screwed up this release and it would take a significant delay to fix it. I think the community will accept it better than a continuous stream of one-week slips. It's also better for planning to know an honest estimation of the final release of F18. People, who are not familiar with the state of Anaconda, still believe that F18 will be released on the Dec 11th and plan e.g. release parties accordingly. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3D printing in Fedora
- Original Message - > From: "Matthew Miller" > To: "Jiri Eischmann" , "Development discussions related > to Fedora" > > Sent: Monday, October 29, 2012 10:13:20 PM > Subject: Re: 3D printing in Fedora > > On Mon, Oct 29, 2012 at 05:02:17PM -0400, Jiri Eischmann wrote: > > I think the time to discuss if a spin is needed or not hasn't come > > yet. > > Now, the primary goal should be to get all the tool in Fedora. When > > that's > > done, they should probably go for a package group to give users an > > easy > > way to install those tools. And then if the initiative gets a > > traction and > > attracts a lot of people I don't see a reason why they can't have a > > spin. > > I think it's not really a matter of "can't have". It's a matter of > "maybe > not the best use of energy". Take a look at the numbers for the top > spins > this release, over on the right column of this page: > > http://spins.fedoraproject.org/ > > > I don't think this is because KDE or XFCE aren't popular among Fedora > users. > People just don't get the via spins. And that's even more true for > non-desktop spins. Are those numbers correct? They seem ridiculously small even for something people don't use. Isn't it a daily count? Anyway, the desktop spins make sense at least for our multidesktop live DVDs which are very appreciated by users in my experience. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3D printing in Fedora
- Original Message - > From: "Tomas Radej" > To: devel@lists.fedoraproject.org > Sent: Monday, October 29, 2012 7:31:37 PM > Subject: Re: 3D printing in Fedora > > Hi, > > On Mon, 29 Oct 2012 19:15:06 +0100 > Miro Hrončok wrote: > > > > I'm not sure that a separate 3d printing spin makes a lot of > > > sense > > Well, it makes for me. > > Lot's of memebers of our group at university asks me: What Linux > > distro should I grap for 3D printing? > > If we have a 3D printing spin, I could point them directly to that. > > You don't need that. You can just tell them to use Fedora and install > the printrun package (example). If there was a spin for every > activity out there, Fedora would have literally, and i mean it, > thousands of spins. I think the time to discuss if a spin is needed or not hasn't come yet. Now, the primary goal should be to get all the tool in Fedora. When that's done, they should probably go for a package group to give users an easy way to install those tools. And then if the initiative gets a traction and attracts a lot of people I don't see a reason why they can't have a spin. > You just need to watch out for those binary executables and such, > because Fedora Guidelines are quite strict about inclusion of > binary, patented or non-free software. Miro attended our packaging workshop where we went through this, so I think he's aware of that. As I followed his effort to package the tools, I could see that he had difficulties to package some tools because of legal issues. One tool required 23 packages of Perl CPANs and some of them come with no license. That's one of the main challenges this 3D print effort will have to face. > > > I'm wondering what sort of printers people have at the moment, > > > since I > > > believe that it would be very helpful for us to package known > > > configurations for the slicer(s). > > I am not sure, if this is going to work, from my point of view, the > > slicing profiles are very machine and material specific. You can > > get a > > very huge number of profiles. > > Once you get involved, we can work out a way of distributing the > profiles, be it RPM packages or not. Miro didn't mention that, but he has already proposed two packages for review and is waiting for a sponsor/reviewer. Someone willing to sponsor showed up today, but he has already created spec files for 28 packages, so there is a lot to review. It's where he'd definitely appreciate help now :) Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
Reindl Harald píše v Ne 07. 10. 2012 v 20:02 +0200: > Am 07.10.2012 19:55, schrieb drago01: > > Maybe maybe not. The point is that a fancy software shop would result > > into this "old mother" type of user consider to use fedora. > > A user ultimately don't care about packages but about applications. > > Other distritors are moving in this direction while we fall behind. > > We should lead here like we do in other areas. > > why do we need to lead everywehre for every price? > > >> It will be nice if more people uses Fedora, but it not the main target, the > >> greatness of Fedora is not measured but how many user it have, compared to > >> other Linuxes or other os'es. > > > > Well without users (and growth) it will become irrelevant and thus it > > will become harder to achieve anything else. > > nobody says "without users" > but do we really need every noob as user? Why does some of us imply it's about noobs? I know about many experienced Fedora users and contributors who would appreciate it, too. And why are noobs something unwanted? As I said above, most new computer science students at our local technical university are Linux noobs who would appreciate something like this. They have potential to be good contributors in a few years if Fedora hooks them up now. Unfortunately, our competition is more successful at this and it will have an impact on our contributor base in long term. > why have we different operating systems and distributions if all > satisfies the same user-base for every price? there is also a need > for a clean and straight forwarded linux without compromises only > to fetch users better satisfied with OSX or windows How would Software Center hold you from enjoying clean and straight forwarded Linux? It's just an app. Anyone who'd like to would be able to use YUM, YUMEX, Add/Remove, Apper,... Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress in Software Center in Fedora effort?
tim.laurid...@gmail.com píše v Ne 07. 10. 2012 v 18:51 +0200: > > > On Fri, Oct 5, 2012 at 5:19 PM, Jiri Eischmann > wrote: > Hi, > the possibility of Software Center in Fedora has already been > discussed > several times, last time a few month ago. > I read an article about a successful Google Summer of Code > project [1] > whose goal was to make Software Center a distribution > independent > program using PackageKit. > Matthias even made an Ubuntu-independent infrastructure for > AppStream > (additional data about packages/apps). > I wonder if there are still any efforts to get it to Fedora > and what it > would require from our infrastructure. > > If I understand it correctly, there are currently three > options: > 1) Software Center based on PackageKit by Matthias > 2) Light Software Center - a new app based on PackageKit from > the > beginning > 3) Apper already supports AppStream [2] > > I'm asking because I hear from many (not only) beginners that > they would > appreciate something like Ubuntu Software Center in Fedora. I > guess it's > one of the main reasons why many users rather go for Ubuntu > than Fedora. > > Jiri > > [1] > http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html > [2] http://blog.tenstral.net/2012/08/appstream-for-apper.html > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > The ultimate software center is a web application, like Google > playstore. > > > All the rating and commenting and other info, need to be centrally > maintained and it is not a good idea to try to distribute this kind of > metadata. > There shall just be a local installer to install the packages > triggered by the web app. > Another thing is what the users of Fedora and most other linux'es is > not my old mother and most of these users, don't care about a big > fancy software shop. I strongly disagree. Believe me, as a community manager in Red Hat I communicate with community members and normal users on daily basis. And the question "When is Fedora going to have something like Software Center" is one of the most frequent ones. And I also disagree it's about our mums and dads. We went to a local university last week to introduce Fedora to new computer science students. Those are users we're highly interested in. But for most of them, it's the first contact with Linux and questions and opinions like "Where can I search only for app" or "Looking for apps among packages is not very convenient" were very frequent. > So nobody is going to do this great amount of work it takes to make a > great webstore, Ubuntu need it for the same ways as Apple, they want > to earn some money.) As someone already wrote, this is not about money, this is about user experience. Software Center only with free software would be a big improvement over what we have now. > It is an illusion that if we just have a fancy webstore, every body > will start using Fedora IMHO. Nobody simplifies it like this. Software Center is just one of pieces in the puzzle. > It will be nice if more people uses Fedora, but it not the main > target, the greatness of Fedora is not measured but how many user it > have, compared to other Linuxes or other os'es. Yeah, the number of users might not be the main goal for Fedora, but without users, we won't achieve our actual goals. Less users leads in long term to less contributors, for example. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Any progress in Software Center in Fedora effort?
Hi, the possibility of Software Center in Fedora has already been discussed several times, last time a few month ago. I read an article about a successful Google Summer of Code project [1] whose goal was to make Software Center a distribution independent program using PackageKit. Matthias even made an Ubuntu-independent infrastructure for AppStream (additional data about packages/apps). I wonder if there are still any efforts to get it to Fedora and what it would require from our infrastructure. If I understand it correctly, there are currently three options: 1) Software Center based on PackageKit by Matthias 2) Light Software Center - a new app based on PackageKit from the beginning 3) Apper already supports AppStream [2] I'm asking because I hear from many (not only) beginners that they would appreciate something like Ubuntu Software Center in Fedora. I guess it's one of the main reasons why many users rather go for Ubuntu than Fedora. Jiri [1] http://blog.tenstral.net/2012/08/gsoc-appstream-final-report.html [2] http://blog.tenstral.net/2012/08/appstream-for-apper.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora multi-arch
We discussed it in FAmSCo and I also spoke with Fedora QA guys. They're willing to do the testing. It's not particularly difficult. What they would appreciate is building those ISOs for RC so that they can test it before the final release. So far, the multi-arch ISOs have been built only for the final version. Jiri Henrique Junior píše v St 12. 09. 2012 v 23:15 -0300: > I know that the guys in QA have a lot of work to do already, but is > there any chance of multi-arch to receive more attention in the near > future? > > 2012/9/12 Álvaro Castillo > > > On Wed, Sep 12, 2012 at 10:10 PM, Kevin Fenzi > wrote: > These were originally for ambassadors only to use at > events. > > I have no objection to making them more known, > however, I think they > should be tested and produced in the same way other > Fedora images are. > > In the f17 cycle they were not tested by QA at all, > and sadly, the > multi-install iso is broken. This led to useless media > and everything > looking bad. ;( > > so, if we are going to make them, they should get > tested, produced and > distributed (including signed checksums) like every > other image we > produce. IMHO. > > > Yes, please, before release these DVDs, check QA control, DVDs > are money that wasn't unused by these error. I am an > ambassador affected by a little problem. On vmlinuz and > syslinux, has got 0. This 0 both do cannot boot. You need edit > GRUB kernel lines and remove 0 to work > > > -- > Álvaro Castillo > > http://fedoraproject.org/wiki/User:Netsys > Linux user #547784 > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- > Henrique "LonelySpooky" Junior > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Florian Müllner píše v Pá 20. 04. 2012 v 12:27 +0200: > > On Apr 20, 2012 11:55 AM, "Jiri Eischmann" > wrote: > > The notification is nice, but the only job it does is that it says > the > > live system is installable. It really doesn't help the user find out > how > > to install it. > > The notification contains a button which is labeled "Install". I don't > think users will have that much trouble figuring out what it does ... Is the notification gonna persist for the whole session? If not the button is not very helpful. I think the people, for whom Kamil wants to fix this, won't install Fedora right away, they will want to play with it and explore for a while. Meanwhile the notification will disappear and the problem will come back again: where to start the installation process? I just wanted to say that the icon in the systray is even less likely to be discovered that the icon in the dash. I'm pretty sure a lot of people will just reboot to get the notification they saw at the beginning of the session which is more or less our failure to fix this issue. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Kamil Paral píše v Pá 20. 04. 2012 v 03:49 -0400: > > On Thu, 2012-04-19 at 16:24 -0600, Chris Murphy wrote: > > > > > That is obscure UI design, and therefore doesn't resolve the > > > current > > > UI obscurity. So I see very little efficacy in the idea. > > > > To contribute something positive here, I went ahead and implemented > > the > > 'oscurity'. See attached. > > I tried that out. For some reason the notification doesn't pop up after I run > the program, is that intended? You have to open the overview mode to view an > icon in bottom right and then click that icon to see the message. I created a > screenshot gallery here (using time order): > > http://imgur.com/a/3hAEJ > > Currently that is obscure the same way the current dash launcher is. We would > need at least to pop up that notification right after logging in, and then > hide the notification if users clicks on it (outside the Install button). > Ideally it should be clear that the button is still available to the user > even if I dismiss the notification (I'm not sure how to do that). Another > question is what happens if user doesn't dismiss it, what about other > notifications, do they just queue and don't show up? So if I understand it correctly instead of having an icon in the dash we have the same icon, but smaller, in the systray where it is hidden even more. Am I the only one who doesn't see any improvement in this solution? The notification is nice, but the only job it does is that it says the live system is installable. It really doesn't help the user find out how to install it. Users familiar with the concept of GNOME 3 might get a clue and look for it in the systray, but I think we're not fixing this problem for them. We're fixing it for those who are rather new to Fedora and GNOME 3. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
Kamil Paral píše v Út 03. 04. 2012 v 09:26 -0400: > I was quite depressed how hard it can be for a layman to find a way to > install Fedora from LiveCD environment. If you don't recognize the icon in > Gnome Shell Overview mode, it can give you quite some work to find it. Since > OSS philosophy is "if you don't like it, fix it", I did. In the last two days > I have created a Gnome Shell extension that puts a button on the top bar that > says "Install to Hard Drive". It has an icon attached, so it's very visible. > The graphics and the text is taken from anaconda's .desktop file, so > localization should work OOTB. When you click the button, the installation > process starts the same way as if you had run it from the overview. > > You can see it here: > http://kparal.fedorapeople.org/misc/InstallFedoraButton.png > > What do you think? Better than default? > > I personally think it's definitely better than default. I'm sure it can be > improved in many ways, but this was my first GS extension ever and I'm really > lame, so bear with me (patches welcome). The source code is here: > http://kparal.fedorapeople.org/misc/InstallFedoraButton.7z > > How to try out: > 1. boot F17 Beta RC2 Live > 2. extract the extension to /usr/share/gnome-shell/extensions/ > 3. restart gnome-shell (Alt+F2 -> r) > 4. install gnome-tweak-tool and enable this extension > > Future steps if people like it: > a) find out how to include this just on the livecd, but not on the installed > system > b) modify gsettings to have this extension automatically enabled > c) ask anaconda team to include it into their project and maintain it > > Comments welcome. > > Thanks, > Kamil I think this is definitely something we should fix. I don't even remember how many times I've been asked how to install Fedora from the liveCD. The solution proposed by Kamil is definitely better and more obvious than the one we've had so far. If we want to have as default look as possible we might want to change the icon in the dash. Something like adding text in the icon "Install Fedora". I know it probably breaks all icon guidelines, but I don't know any picture that would obviously stand for installation. The way it is now is really more like an easter egg or a contest "who will find a way to install Fedora first". Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
