Re: Java Dev Group and Fedora Quality
On 1/25/20 9:25 PM, Bill Chatfield via devel wrote: I think that by applying basic engineering techniques like user testing we can weed out ideologies that don't provide any value to users. Do the testing and let the results decide.The principles of ISO 9000 can be applied to improve products. There are also metrics that can measure how good a user interface is, like how many clicks does it take to perform a specific task. If these kinds of techniques were being applied to Gnome, we'd be able to more impartially measure how good Gnome is and also improve it. We'd be able to make more informed decisions and get better results. And if the Gnome guys actually had information like this, they'd be forced to deal with it. Maybe they'd be forced to admit that they care more about their ideology than helping their users be more productive. Or maybe the results would support the Gnome ideology. Until someone takes a scientific/engineering approach to measuring it, the issue can't really be resolved. My problem with Gnome is that they just do whatever they feel like instead of applying well-established engineering or software engineering quality processes. Except that they have actually done user testing and metrics like you're suggesting. Maybe you personally don't like their choices, but many others do. ___ 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: Java Dev Group and Fedora Quality
I appreciate the sensibility of your suggestion but I'm afraid that I enjoy the aggravation of my love/hate relationship with Gnome too much. You got me thinking though. ___ 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: Java Dev Group and Fedora Quality
On 1/26/20 8:25 AM, Bill Chatfield via devel wrote: I think that by applying basic engineering techniques like user testing we can weed out ideologies that don't provide any value to users. Do the testing and let the results decide.The principles of ISO 9000 can be applied to improve products. There are also metrics that can measure how good a user interface is, like how many clicks does it take to perform a specific task. If these kinds of techniques were being applied to Gnome, we'd be able to more impartially measure how good Gnome is and also improve it. We'd be able to make more informed decisions and get better results. And if the Gnome guys actually had information like this, they'd be forced to deal with it. Maybe they'd be forced to admit that they care more about their ideology than helping their users be more productive. Or maybe the results would support the Gnome ideology. Until someone takes a scientific/engineering approach to measuring it, the issue can't really be resolved. My problem with Gnome is that they just do whatever they feel like instead of applying well-established engineering or software engineering quality processes. Desktop change can be done from terminal [0],[1],[2] (though not in software center which may be helpful for some users): sudo dnf -y group install "KDE Plasma Workspaces" Not sure if any of the available desktops takes the above measurement approach. Many linux users value privacy, but some data collection would be helpful. [0] https://computingforgeeks.com/install-kde-plasma-environment-on-fedora/ [1] https://computingforgeeks.com/how-to-install-deepin-desktop-environment-on-fedora/ [2] https://www.tecmint.com/install-and-switch-desktop-environments-in-fedora/ ___ 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: Java Dev Group and Fedora Quality
I think that by applying basic engineering techniques like user testing we can weed out ideologies that don't provide any value to users. Do the testing and let the results decide.The principles of ISO 9000 can be applied to improve products. There are also metrics that can measure how good a user interface is, like how many clicks does it take to perform a specific task. If these kinds of techniques were being applied to Gnome, we'd be able to more impartially measure how good Gnome is and also improve it. We'd be able to make more informed decisions and get better results. And if the Gnome guys actually had information like this, they'd be forced to deal with it. Maybe they'd be forced to admit that they care more about their ideology than helping their users be more productive. Or maybe the results would support the Gnome ideology. Until someone takes a scientific/engineering approach to measuring it, the issue can't really be resolved. My problem with Gnome is that they just do whatever they feel like instead of applying well-established engineering or software engineering quality processes. ___ 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: Java Dev Group and Fedora Quality
No problem. I like hearing peoples' opinions. I will look for a package that might be a good starting point. ___ 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: Java Dev Group and Fedora Quality
Hello Bill, And sorry for digressing. On Sun, Jan 26, 2020 at 1:10 AM Bill Chatfield via devel wrote: > > That's a very sad story. I had no idea. So it sounds like you mainly need > maintainers for Java packages. I have worked on building RPMs but I have > never been a package maintainer. However I have 20 years of experience as a > Java developer, so I'm pretty confident I can be helpful. How should I go > forward? Is there a particular package that would be good to start with? You should start here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ As for which package you should tackle first, since you're a Java programmer, you are the most qualified to identify what you think is missing or malfunctioning and work your way (up the dependency chain) from there. I hope this helps. ___ 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: Java Dev Group and Fedora Quality
On 1/25/20 7:30 PM, Alexander Ploumistos wrote: Hello Ty, On Sun, Jan 26, 2020 at 1:42 AM Ty Young wrote: The unfortunate reality is that none of what you describe will likely change in any significant way, at least not with the standard Linux distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology based(GNU, among other political ideologies) instead of just making the best software/platform possible, which pushes away people who would like to contribute and use Linux software. There is little, if any, compromises by those who believe in these ideologies. They are willing to stand by their beliefs until the very end. How you conduct yourself in your everyday life, whether you realize it or not, not only reflects your political beliefs, it is in itself politics. Someone volunteering a portion of their finite time to a project that benefits many, but does not result in direct compensation for them, is a deeply political act. Without ideologists willing to fight for their beliefs and stand their ground, we'd all be worshiping god-kings, who'd hold an absolute power over the life or death of their subjects. In a much narrower scope, over the last thirty years or so, had there not been ideologists promoting and defending the precious idea of Free Software, we'd all be doomed to run windows and browse a Microsoft-defined web using internet explorer. This is an assumption being masqueraded as a fact. Firefox is open source and uses DRM(For better or for worse). There are more colors than black and white. There are also ways for Open Source developers to be compensated for their work. Elementary has a donate button IIRC in their package manager. Some developers also use Patron or Librepay(I think it's called?). Fedora doesn't offer users the option via Gnome Software. Of course there is a difference between donations and paying for software, but if you're complaining about developers not being "thanked" then Fedora is in part responsible for that. You choose not to have the option right front and center. Your own post, is indeed political and it is quite telling. I do not know what your particular beef with GNOME is and frankly I don't care. Bill here had one of the healthiest reactions to the situation he was facing. He actually offered to do something about it, instead of whining. That should serve as an example. The desire to help was expressed and what was it. Not downplaying the importance of it per se but rather putting it into perspective. Fedora in particular utilizes a lot of in-house tools and systems. Many of those seem to have some kind of issue or another that frustrates even long time packagers and developers. The Java SIG all quit in part IIRC because packaging Java stuff was too hard in Fedora. And lets not even get into the modular mess. I've been subscribed to this list long enough to know how much everyone "loves" modules. It's best not to bring up any such issues, especially in Fedora/Gnome home turf. They have "Code of Conduct" nukes that are used to silence any discussion they don't agree with. Just take a look at the Gnome subreddit, wherein the moderators have been caught and continue to issue thread/comment locks and temp bans for (nicely) pointing out bugs in Gnome. It's scary stuff, and is only getting worse with Gnome's Code of Conduct allowing racism. They will deny it endlessly that this is the intent but have publicly fought against revising it to clear up the intent after public outcry. The Code of Conduct is decided by people participating in the project. Among its objectives, is to protect those doing actual and often thankless work from the demoralizing abuse of ungrateful and entitled egoists, hiding behind a computer screen and a handle. Ah, allowing racism is to somehow protect developers and the majority of Gnome is OK with it. Got it. The Code of Conduct is not set in stone and those participating in the project may at any time choose to alter it. Participation is the operative word here and under no circumstance does griping count as participation. Neal already covered the other points I wanted to make. TL;DR: Only the opinions of those that are part of the clubhouse matter. (Sadly the only way to be apart of the clubhouse is by agreeing with the existing clubhouse members. Darn.) ___ 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:/
Re: Java Dev Group and Fedora Quality
Hello Ty, On Sun, Jan 26, 2020 at 1:42 AM Ty Young wrote: > > The unfortunate reality is that none of what you describe will likely > change in any significant way, at least not with the standard Linux > distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology > based(GNU, among other political ideologies) instead of just making the > best software/platform possible, which pushes away people who would like > to contribute and use Linux software. There is little, if any, > compromises by those who believe in these ideologies. They are willing > to stand by their beliefs until the very end. How you conduct yourself in your everyday life, whether you realize it or not, not only reflects your political beliefs, it is in itself politics. Someone volunteering a portion of their finite time to a project that benefits many, but does not result in direct compensation for them, is a deeply political act. Without ideologists willing to fight for their beliefs and stand their ground, we'd all be worshiping god-kings, who'd hold an absolute power over the life or death of their subjects. In a much narrower scope, over the last thirty years or so, had there not been ideologists promoting and defending the precious idea of Free Software, we'd all be doomed to run windows and browse a Microsoft-defined web using internet explorer. Your own post, is indeed political and it is quite telling. I do not know what your particular beef with GNOME is and frankly I don't care. Bill here had one of the healthiest reactions to the situation he was facing. He actually offered to do something about it, instead of whining. That should serve as an example. > It's best not to bring up any such issues, especially in Fedora/Gnome > home turf. They have "Code of Conduct" nukes that are used to silence > any discussion they don't agree with. Just take a look at the Gnome > subreddit, wherein the moderators have been caught and continue to issue > thread/comment locks and temp bans for (nicely) pointing out bugs in > Gnome. It's scary stuff, and is only getting worse with Gnome's Code of > Conduct allowing racism. They will deny it endlessly that this is the > intent but have publicly fought against revising it to clear up the > intent after public outcry. The Code of Conduct is decided by people participating in the project. Among its objectives, is to protect those doing actual and often thankless work from the demoralizing abuse of ungrateful and entitled egoists, hiding behind a computer screen and a handle. The Code of Conduct is not set in stone and those participating in the project may at any time choose to alter it. Participation is the operative word here and under no circumstance does griping count as participation. Neal already covered the other points I wanted to make. ___ 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: Java Dev Group and Fedora Quality
On 1/25/20 7:12 PM, Neal Gompa wrote: On Sat, Jan 25, 2020 at 7:42 PM Ty Young wrote: You miss the point of how FOSS projects work. Read up on some history and get some understanding of the cultural background before you blithely say that ideology and passion are what is killing Linux distros. People who are passionate about FOSS and develop their platforms work to produce quality software because they care for it. High quality software is an effect of the process, not the deliberate goal. And this means that sometimes FOSS *isn't* the highest quality it could be, because the person working on it as a passion cannot do so alone. That's the opportunity for you to step up and help make it better. That, in itself, is the core difference between FOSS and proprietary software. FOSS is full of passion and possibility, while proprietary software is defined only by its usefulness and restrictions. You say this as if everything is black and white; that things like "passion" can't possibly hurt you. Anyway, getting off topic. I don't mind personally but I don't want any excuses to nuke this off the face of the planet. It's best not to bring up any such issues, especially in Fedora/Gnome home turf. They have "Code of Conduct" nukes that are used to silence any discussion they don't agree with. Just take a look at the Gnome subreddit, wherein the moderators have been caught and continue to issue thread/comment locks and temp bans for (nicely) pointing out bugs in Gnome. It's scary stuff, and is only getting worse with Gnome's Code of Conduct allowing racism. They will deny it endlessly that this is the intent but have publicly fought against revising it to clear up the intent after public outcry. Be silent and fall in line, or be sent to the gulag. This is very rude and definitely a huge misrepresentation of the Fedora community. While it is true that Fedora Workstation is GNOME centric, Fedora is one of a select few that contains virtually every major desktop environment and window manager, as well as several minor ones. We have Lumina, Xfce, MATE, KDE (my favorite and what I personally run), Cinnamon, Deepin, Pantheon (from elementary OS!), and many others. We support several desktop environments quite well, and offer spins for most of them at https://spins.fedoraproject.org. Most of these have official teams (Special Interest Groups) that support these environments. If you're interested in one, join one of them. Not calling out anyone who isn't aware of or agrees with Fedora and/or Gnome's tendencies to nuke discussions into orbit(or their Code of Conducts). I guess I should have been more clear on that. Apologies. I don't know anything about the GNOME subreddit, nor do I really care. GNOME is not Fedora. And Fedora itself is not defined by GNOME. We are a separate, larger entity that does quite a bit more and has a much more diverse audience. While that's true, it's well known that Gnome and Fedora have a very incestuous relationship. So much so that people point to Fedora as the "premium" Gnome 3 experience. Whether or not that is actually true is neither here nor there, point is that there is a lot of developers that are apart of both(which is why people say that). Like all good communities, respectful discourse is permitted, but being belligerent, hateful, and condescending is unnecessary and unwanted. Let's be excellent to each other. Be good to your fellow human. This isn't a universally shared way of thinking, sadly. ___ 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: Java Dev Group and Fedora Quality
On Sat, Jan 25, 2020 at 7:42 PM Ty Young wrote: > > > Hi Bill, > > > Not an average Fedora user but I've used several Linux > distributions(including Fedora and versions there of) over the years. > What you are bringing up is 100% valid and isn't new or specific to > Fedora. It's been a known and valid complaint that there isn't enough > software in distro X or that the quality of what does exist in distro X > is poor. > > > The unfortunate reality is that none of what you describe will likely > change in any significant way, at least not with the standard Linux > distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology > based(GNU, among other political ideologies) instead of just making the > best software/platform possible, which pushes away people who would like > to contribute and use Linux software. There is little, if any, > compromises by those who believe in these ideologies. They are willing > to stand by their beliefs until the very end. > > > This, sadly, results in the situation where we are now: lots of Linux > distributions and/or desktop shells that are either of poor quality or > abandoned. Software developers don't want to support half or dozen(or > more!) Linux distributions, so they either don't support Linux or only > target a specific distribution. That makes users mad and leave so > developers don't bother targeting those distributions... and well, yeah, > you get the idea. > > You miss the point of how FOSS projects work. Read up on some history and get some understanding of the cultural background before you blithely say that ideology and passion are what is killing Linux distros. People who are passionate about FOSS and develop their platforms work to produce quality software because they care for it. High quality software is an effect of the process, not the deliberate goal. And this means that sometimes FOSS *isn't* the highest quality it could be, because the person working on it as a passion cannot do so alone. That's the opportunity for you to step up and help make it better. That, in itself, is the core difference between FOSS and proprietary software. FOSS is full of passion and possibility, while proprietary software is defined only by its usefulness and restrictions. > It's best not to bring up any such issues, especially in Fedora/Gnome > home turf. They have "Code of Conduct" nukes that are used to silence > any discussion they don't agree with. Just take a look at the Gnome > subreddit, wherein the moderators have been caught and continue to issue > thread/comment locks and temp bans for (nicely) pointing out bugs in > Gnome. It's scary stuff, and is only getting worse with Gnome's Code of > Conduct allowing racism. They will deny it endlessly that this is the > intent but have publicly fought against revising it to clear up the > intent after public outcry. > > > Be silent and fall in line, or be sent to the gulag. > This is very rude and definitely a huge misrepresentation of the Fedora community. While it is true that Fedora Workstation is GNOME centric, Fedora is one of a select few that contains virtually every major desktop environment and window manager, as well as several minor ones. We have Lumina, Xfce, MATE, KDE (my favorite and what I personally run), Cinnamon, Deepin, Pantheon (from elementary OS!), and many others. We support several desktop environments quite well, and offer spins for most of them at https://spins.fedoraproject.org. Most of these have official teams (Special Interest Groups) that support these environments. If you're interested in one, join one of them. I don't know anything about the GNOME subreddit, nor do I really care. GNOME is not Fedora. And Fedora itself is not defined by GNOME. We are a separate, larger entity that does quite a bit more and has a much more diverse audience. Like all good communities, respectful discourse is permitted, but being belligerent, hateful, and condescending is unnecessary and unwanted. Let's be excellent to each other. Be good to your fellow human. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Java Dev Group and Fedora Quality
Hi Bill, Not an average Fedora user but I've used several Linux distributions(including Fedora and versions there of) over the years. What you are bringing up is 100% valid and isn't new or specific to Fedora. It's been a known and valid complaint that there isn't enough software in distro X or that the quality of what does exist in distro X is poor. The unfortunate reality is that none of what you describe will likely change in any significant way, at least not with the standard Linux distros(Ubuntu, Fedora, Debian, Arch) etc. Too much of Linux is ideology based(GNU, among other political ideologies) instead of just making the best software/platform possible, which pushes away people who would like to contribute and use Linux software. There is little, if any, compromises by those who believe in these ideologies. They are willing to stand by their beliefs until the very end. This, sadly, results in the situation where we are now: lots of Linux distributions and/or desktop shells that are either of poor quality or abandoned. Software developers don't want to support half or dozen(or more!) Linux distributions, so they either don't support Linux or only target a specific distribution. That makes users mad and leave so developers don't bother targeting those distributions... and well, yeah, you get the idea. It's best not to bring up any such issues, especially in Fedora/Gnome home turf. They have "Code of Conduct" nukes that are used to silence any discussion they don't agree with. Just take a look at the Gnome subreddit, wherein the moderators have been caught and continue to issue thread/comment locks and temp bans for (nicely) pointing out bugs in Gnome. It's scary stuff, and is only getting worse with Gnome's Code of Conduct allowing racism. They will deny it endlessly that this is the intent but have publicly fought against revising it to clear up the intent after public outcry. Be silent and fall in line, or be sent to the gulag. Hope this helps. ___ 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: Java Dev Group and Fedora Quality
That's a very sad story. I had no idea. So it sounds like you mainly need maintainers for Java packages. I have worked on building RPMs but I have never been a package maintainer. However I have 20 years of experience as a Java developer, so I'm pretty confident I can be helpful. How should I go forward? Is there a particular package that would be good to start with? ___ 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: Update: AAA replacement login Initiative
On Sat, Jan 25, 2020 at 1:48 AM Adam Williamson wrote: > On Fri, 2020-01-17 at 13:29 -0700, Jerry James wrote: > > On Fri, Jan 17, 2020 at 12:52 PM Andrew Lutomirski wrote: > > > And I have a user story: Andy wants to use a password manager to store > > > his password for an account in the Online Accounts list. When it’s > > > time to log in, Andy clicks the account and a system modal dialog > > > appears asking for a password. Andy would like to click the account in > > > the password manager and copy the password, but he can’t, because the > > > dialog is system modal. So instead, Andy grumbles, dismisses the > > > dialog, copies the password, and then tries to get the dialog to > > > reappear before the copied password is auto-cleared from the > > > clipboard. Andy also wonders why the system modal dialog is not > > > visually consistent with the Online Accounts application at all. > > > > It isn't just you. I HATE that modal dialog. I actively dislike > > modal dialogs in general, but that particular one has tripped me up so > > many times > > So do I, but it has nothing at all to do with this. That's a GNOME UI > choice. The authentication system GNOME is talking to has no control > over it at all. > > There has been a GNOME bug open on it approximately forever, btw: > > https://bugzilla.gnome.org/show_bug.cgi?id=688434 > And this, which I just commented on: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1410 I would argue that having gnome-online-accounts blame gnome-shell for this is actually a bit inappropriate. The behavior of whatever GTK or GNOME API is being used by gnome-online-accounts is simply so poor that gnome-online-accounts should stop using it. ___ 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: Java Dev Group and Fedora Quality
On Sun, Jan 26, 2020 at 12:24 AM Bill Chatfield via devel wrote: > > > As has been discussed time and time again on this mailing list, the last > > member of the Java SIG left it at the end of 2018, leaving the group emptIy. > I'd be willing to work on that if I can figure out how to recreate the group. > Can you point me in the right direction? I think you'll be interested to read this post I wrote two months ago: https://discussion.fedoraproject.org/t/whats-the-state-of-the-java-sig/11714 The problem is that almost none (between zero and one) of the original Java package maintainers in fedora are still actively maintaining any Java packages. Most have either just left, or have jumped ship for the shiny new world of Modularity, leaving users out in the rain. Since early 2019, there's been an ongoing effort to try to keep things from exploding, led by the Stewardship SIG, but it's not a permanent solution, since it's not a replacement for "real" maintainers for Java packages. TL;DR: We've been trying to keep things working as best as we can - but with severely limited manpower, it's basically maintenance on a best-effort basis for almost the entire Java stack. Fabio > > There are several FAS groups with 'java' in their name but non that start > > with the letter 'J'. I'm not sure why you would expect this to be the > > case... > > Because Java starts with "J". ;-) > ___ > 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: Java Dev Group and Fedora Quality
> As has been discussed time and time again on this mailing list, the last > member of the Java SIG left it at the end of 2018, leaving the group emptIy. I'd be willing to work on that if I can figure out how to recreate the group. Can you point me in the right direction? > There are several FAS groups with 'java' in their name but non that start > with the letter 'J'. I'm not sure why you would expect this to be the case... Because Java starts with "J". ;-) ___ 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
Unannounced soname bump with samba 4.12~rc1
Hi everybody, Yesterday's samba update bumped the soname of a library included in samba-client-libs, from libndr.so.0 to libndr.so.1. This was not announced, and dependent packages were not rebuilt. This affects at least the following packages, which need rebuilds: - evolution-mapi - freeipa(-server)(-trust-ad) - openchange(-client) samba also does not follow the Packaging Guidelines regarding the %files listing of shared libraries, and globs away all library versions (which enables this kind of accidental bumps). See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files Fabio ___ 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
Unannounced soname bump with botan2-2.13.0
Hi everybody, libbotan-2.so bumped its soname from libbotan-2.so.12 to libbotan-2.so.13 with yesterday's update to 2.13.0. This was not announced, and dependent packages were not rebuilt. At least the following three packages need a rebuild and are now broken in rawhide: - corectrl - daggy - qownnotes botan2 also does not adhere to the Packaging Guidelines, since it globs the shared library version away in %files: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files Fabio ___ 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: Java Dev Group and Fedora Quality
* Bill Chatfield via devel [25/01/2020 22:06] : > > I'm trying to find out what's going on with Java in Fedora. Fedora 31 was > released with a broken Eclipse. I subscribe to the java-devel mailing list > but there is no traffic there. As has been discussed time and time again on this mailing list, the last member of the Java SIG left it at the end of 2018, leaving the group empty. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YFUXS7ZX6UDEMEKJWONKFMVDTSBABZID/ > If I go to "Join a Group" and click on "J" there is simply nothing there... There are several FAS groups with 'java' in their name but non that start with the letter 'J'. I'm not sure why you would expect this to be the case... Emmanuel ___ 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
Java Dev Group and Fedora Quality
I'm trying to find out what's going on with Java in Fedora. Fedora 31 was released with a broken Eclipse. I subscribe to the java-devel mailing list but there is no traffic there. If I go to "Join a Group" and click on "J" there is simply nothing there... https://admin.fedoraproject.org/accounts/group/list/J*?_csrf_token=d8baf5dd81fbb8289de644963217177eddc13278 Please take an example from the recent Boeing failures where management pushed the engineers to cut corners to meet release dates instead of taking the time to test and fix problems. Anyone who has worked in an office can see that is what happened. I don't know if it's management that is the problem with Fedora since open source works a bit differently than your typical corporation. But there is a problem and it's resulting in a low quality product. You need automated tests. You need a suit of manual tests. For every package. And you need to take the time to fix problems when they're discovered. Software Engineering isn't just about writing code. It's about creating a product that works for your end user. Your end-user has to be your priority and that means quality has to be a priority. The poor quality of Fedora in general and the poor support for Java is basically forcing me to use Ubuntu just so that I can get a system that actually works. I've been using Fedora for a long time and I hate to switch away from it. But, I do actually have to get work done. Between gnome shell crashes, long periods of the whole system being unresponsive, core Java programs that I can't even install, mysterious network failures in nfs, avahi, sshd and submitting bug reports that almost always end up failing to submit after spending 15 minutes collecting data...I can't get any work done. I think the main problem is that you are not spending enough time on testing and fixing problems before you release. Maybe 6 months is too short of a cycle for the number of people you have. You can't cut a buggy release and depend on your users to find the bugs for you. If you do, you are going to lose all your users. As much as I love Linux and Fedora, I have to admit that the quality of Fedora is about equal to that of Windows 95. There were a few releases where quality was pretty good but 31 is in the gutter. The reason I use Linux is to get a better quality system than Windows. But, that just isn't happening with Fedora. I really apologize for being an a-hole here but I'm saying these things because I REALLY care about Fedora and they really need to be said. Things need to change...quality needs to be the highest priority. And I'm willing to help but I have tried to join projects several times with no responses. The Java project doesn't even seem to exist. Being that Java is the most popular programming language in the industry by multiple metrics, most corporations use it, a large part of Red Hat's business is Java, Hadoop is written in Java, I'd expect to see much better support for it in Fedora. But, it's like a second-class citizen. Python, the slowest language ever created (except for Ruby), is about the only thing people care about. Python is part of the problem with Fedora as it is a big part of what makes Fedora slow. Anyone who has compared the performance of dnf versus apt can see that dnf sucks...bad. Apt is extremely fast and dnf is extremely slow. There is no room for argument there. It's just the truth. I'm not saying that to be mean. I'm trying to point out a serious problem that needs to be addressed. It does not matter now nice a language is to program in. What matters is the user experience. Programs that are integral to the operating system should not be written in Python or Java. They need to be written in an memory and CPU efficient language like C/C++ or Ada. If you could get better performance out of Python, that could be an option too, like maybe running Python programs in pypy instead of regular python. The important thing is getting the right user experience. By that I mean that the program has to run fast and not take up large amounts of memory on the user's machine so that other programs don't have enough room to run. These issues apply to Gnome, Python and Java. As a Java programmer I understand that Java uses massive amounts of memory. It's not an appropriate implementation language for operating system level components because of that. If you have 15 Java programs running on an end-user machine, the machine is going to run out of memory. It is fine to run 1 or 2 application-level programs on an end-user machine. And Java is great on the server where you can have a large amount of memory. Python has the same problem but in addition it is also slow. If you think Java is slow you need to re-educate yourself, because it is not. You can test this yourself by writing some equivalent Java and Python programs and timing them. I'm not saying anything here you can't verify on your own. Gno
swap-on-ZRAM by default
Question and (pre)proposal: Can Fedora converge on a single swap-on-ZRAM implementation, and if so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by default in Fedora 33, and the working group needs to pick something soon. I think it should be zram-generator. It's the most lightweight, can be included by default distro wide. Without a configuration file, it doesn't run. Thus, each edition/spin, and even the install environment, can have their own configuration file, to setup it up however they want, or not set it up. I also suspect it's the only one that could be upstreamed to systemd proper, and just included like many other generators. Background story and references: Fedora IoT enables swap-on-ZRAM by default for a long time, and have no issues. Fedora Workstation WG has been evaluating it for some time, and wants to enable it by default in Fedora 33. Prior discussions [1] (Details will be in a future feature proposal.) Swap is a basic function, and swap-on-ZRAM is an optimization of a basic function. Basic things should be understandable by users, without having different configuration files, and systemd units to look for, depending on what edition/spin they use, or whether they're booting installation media, or an installed system. It's confusing. And they don't co-exist gracefully. There are three implementations in Fedora [2]. Installation media (DVD, netinstall, Live) use Anaconda's when the install media is booted; Live installations include it, but it's disabled. Fedora IoT has its own variant enabled by default, similar in design and function to Anaconda's, but differently named systemd unit, configuration file, and bash scripts used by the systemd unit. There's nothing wrong with these, but in my estimation they have no chance of being upstreamed to systemd proper. And there's zram-generator. It works much like any other of the basic generators for this sort of thing: the gpt-auto-generator, the fstab-generator, and the cryptsetup-generator. I'm not sure who would argue we need multiple implementations of these things, with separate configuration files, in the same distribution. [1] https://pagure.io/fedora-workstation/issue/98 https://pagure.io/fedora-workstation/issue/120 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ https://lists.fedoraproject.org/archives/list/i...@lists.fedoraproject.org/thread/OPCNQE547MED7CKFWCRYXS35ZOTJYKWU/ [2] zram-generator-0.1.2-1.fc32.x86_64 https://github.com/systemd/zram-generator https://src.fedoraproject.org/rpms/rust-zram-generator zram-0.4-1.fc31.noarch https://src.fedoraproject.org/rpms/zram Provides zram-swap.service anaconda-32.20-1.fc32.x86_64 https://github.com/rhinstaller/anaconda Provides zram.service -- Chris Murphy ___ 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: Bubblemail: looking for package maintainer
Nice job, thanks a lot ! And besides, I always merge things that fix my typos and mistakes, so you're welcome to do so ;) I'm currently working on the gnome shell extension part, where improvements are clearly needed before a proper packaging, then I'll inform here and hope for a same success. Best regards On Sat, 2020-01-25 at 18:35 +0100, Robert-André Mauchin wrote: > On Sunday, 19 January 2020 17:45:17 CET razer raz wrote: > > Hi, > > > > I'm the author of Bubblemail, a mail notification service providing > > a D-Bus > > interface : > > http://bubblemail.free.fr > > > > Git Repo : > > https://framagit.org/razer/bubblemail > > > > It's a brand new project coming from the fork of the mailnag > > project, with > > first goal to get it running on python3. Since then, I have > > rewritten > > almost all the code in a more modern and simplest way, get it pep8 > > compliant, improve stability, features and tests, and build a more > > modern > > gtk3 interface on it. > > > On top of that, I make the same work on the gnome-shell extension, > > already > > available on the gnome-shell extension website : > > https://extensions.gnome.org/extension/2458/bubblemail/ > > https://framagit.org/razer/bubblemail-gnome-shell > > > > I currently maintain myself rpm and deb packages, and I'm looking > > for > > someone for the rpm part of the task, hopping for proper Fedora > > integration. > > It's almost pure python3 code using setuptools, I suppose it > > should be easy to build and maintain an rpm package for someone > > used with > > the task. > > Please contact me: razerraz AT free DOT fr > > Packaged: https://src.fedoraproject.org/rpms/bubblemail > > Will be shortly available in Fedora 30 and 31 after the testing > period: > https://bodhi.fedoraproject.org/updates/?packages=bubblemail > > I suggest you take a look at the SPEC file for your own RPM > generation: > https://src.fedoraproject.org/rpms/bubblemail/blob/master/f/bubblemail.spec > > Thanks for approving last night merge requests. > > Best regards, > > Robert-André > > > > > ___ 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: Bubblemail: looking for package maintainer
On Sunday, 19 January 2020 17:45:17 CET razer raz wrote: > Hi, > > I'm the author of Bubblemail, a mail notification service providing a D-Bus > interface : > http://bubblemail.free.fr > > Git Repo : > https://framagit.org/razer/bubblemail > > It's a brand new project coming from the fork of the mailnag project, with > first goal to get it running on python3. Since then, I have rewritten > almost all the code in a more modern and simplest way, get it pep8 > compliant, improve stability, features and tests, and build a more modern > gtk3 interface on it. > On top of that, I make the same work on the gnome-shell extension, already > available on the gnome-shell extension website : > https://extensions.gnome.org/extension/2458/bubblemail/ > https://framagit.org/razer/bubblemail-gnome-shell > > I currently maintain myself rpm and deb packages, and I'm looking for > someone for the rpm part of the task, hopping for proper Fedora > integration. > It's almost pure python3 code using setuptools, I suppose it > should be easy to build and maintain an rpm package for someone used with > the task. > Please contact me: razerraz AT free DOT fr Packaged: https://src.fedoraproject.org/rpms/bubblemail Will be shortly available in Fedora 30 and 31 after the testing period: https://bodhi.fedoraproject.org/updates/?packages=bubblemail I suggest you take a look at the SPEC file for your own RPM generation: https://src.fedoraproject.org/rpms/bubblemail/blob/master/f/bubblemail.spec Thanks for approving last night merge requests. Best regards, Robert-André ___ 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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
Hello, I opened a request to anaconda team with a draft patch to use unsquashfs instead of rsync: https://github.com/rhinstaller/anaconda/pull/2292. That should lower the installation time from Live media. Adjustments should be made to make this patch work, I was not able to install the image using this patch. Anaconda installer crashes. Chris, > Could this be read amplification? > That's probably mitigated with unsquashfs. That could be read amplification, it will be mitigated with unsquashfs. The memory usage should not be a problem: xz (1) manual page, states that 2 MiB of memory required to decompress an archive with 1MiB block size. My previous observations found that the squashfs is currently decompressed in single thread. I welcome additional testing, but I think the memory limit will not be a problem. > If image size is a significant consideration, then evaluation of erofs > seems indicated. It promises both significant compression and CPU > performance. The intended use case is for Android device read-only > partitions with both limited storage and CPU/power capacity. I briefly reviewed the document and found that LZ4 is the only supported algorithm in EROFS, even if EROFS has perfect layout of the filesystem, it's to good to be true it can outperform the XZ in compression ratio tests. The difference for SquashFS LZ4hc 1M vs XZ 1M is >40%. On Fri, Jan 24, 2020 at 2:17 AM Chris Murphy wrote: > On Mon, Jan 20, 2020 at 1:38 AM Bohdan Khomutskyi > wrote: > > > > In my previous message, I mentioned that CPU is underutilized during > installation. I haven't investigated further why, but I suspect it's due to > the inefficiency caused by the usage of the loop device and/or inefficiency > in the rsync itself. > > Could this be read amplification? > > This paper on erofs suggests read amplification can be a significant > side effect with squashfs. It could be exacerbated with random reads, > and I expect it gets worse with larger block size. That's probably > mitigated with unsquashfs. > > Specifically page 4, 2nd paragraph. > https://www.usenix.org/system/files/atc19-gao.pdf > > This also makes me wonder about the memory consumption effect of a 1M > block size, especially for Fedora ARM where it looks like Raspberry Pi > 2B > > Most of the ARM images are raw.xz but some are bootable ISOs, dvd and > netinstall. And those contain a squashfs sysroot. Even if there's no > out of memory problem, it could result in paging. All ISOs setup > swap-on-ZRAM these days, lives, DVD, and netinstall. I think the ARM > case needs testing before committing to 1M block size across all ISOs, > or implementing changes in Fedora release engineering. > > > -- > Chris Murphy > > -- Bohdan Khomutskyi, RHCE Release configuration management engineer, PnT DevOps Red Hat Czech s.r.o T: +420532270289 IRC: bkhomuts ___ 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
Fedora-Rawhide-20200125.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 5 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 34/158 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200123.n.0): ID: 513353 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/513353 ID: 513355 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/513355 ID: 513362 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/513362 ID: 513370 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/513370 ID: 513374 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/513374 ID: 513375 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/513375 ID: 513377 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/513377 ID: 513378 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/513378 ID: 513380 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/513380 ID: 513381 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/513381 ID: 513382 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/513382 ID: 513385 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/513385 ID: 513386 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/513386 ID: 513387 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/513387 ID: 513408 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/513408 ID: 513430 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/513430 ID: 513431 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/513431 ID: 513434 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/513434 ID: 513439 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/513439 ID: 513455 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/513455 ID: 513456 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/513456 ID: 513476 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/513476 ID: 513483 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/513483 ID: 513492 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/513492 ID: 513493 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/513493 ID: 513499 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/513499 ID: 513501 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/513501 Old failures (same test failed in Fedora-Rawhide-20200123.n.0): ID: 513354 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/513354 ID: 513361 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/513361 ID: 513403 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/513403 ID: 513409 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/513409 ID: 513411 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/513411 ID: 513415 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/513415 ID: 513420 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/513420 ID: 513498 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/513498 Soft failed openQA tests: 10/158 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200123.n.0): ID: 513346 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/513346 ID: 513351 Test: x86_64 Server-dvd-iso install_default@uefi
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 12:41:24PM +0100, Miro Hrončok wrote: > ocaml I just did a scratch build of OCaml in Rawhide and it seems fine. I guess it may have FTBFS at that time for some other reason, but without seeing the logs it's hard to tell. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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: Update: AAA replacement login Initiative
On Fri, 2020-01-17 at 13:29 -0700, Jerry James wrote: > On Fri, Jan 17, 2020 at 12:52 PM Andrew Lutomirski wrote: > > And I have a user story: Andy wants to use a password manager to store > > his password for an account in the Online Accounts list. When it’s > > time to log in, Andy clicks the account and a system modal dialog > > appears asking for a password. Andy would like to click the account in > > the password manager and copy the password, but he can’t, because the > > dialog is system modal. So instead, Andy grumbles, dismisses the > > dialog, copies the password, and then tries to get the dialog to > > reappear before the copied password is auto-cleared from the > > clipboard. Andy also wonders why the system modal dialog is not > > visually consistent with the Online Accounts application at all. > > It isn't just you. I HATE that modal dialog. I actively dislike > modal dialogs in general, but that particular one has tripped me up so > many times So do I, but it has nothing at all to do with this. That's a GNOME UI choice. The authentication system GNOME is talking to has no control over it at all. There has been a GNOME bug open on it approximately forever, btw: https://bugzilla.gnome.org/show_bug.cgi?id=688434 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ 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
Fedora-Cloud-31-20200125.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Please help review these packages (swaps)
>- Bubblemail, an extensible mail notification service > https://bugzilla.redhat.com/show_bug.cgi?id=bubblemail Done. > I am at your disposal for any review you may need in exchange. You have prepaid with past reviews :-) > Best regards, > > Robert-André ___ 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
