Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wednesday, 3 April 2024 01:48:47 CEST Kevin Fenzi wrote: > On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote: > > Alright, so a substantial amount of information changed since the original > > submission of the change proposal. We aren't necessarily thinking of > > demoting Gnome. The overall spirit of the CP is that we think KDE, and to > > some extent the other spins too, need a bit more visibility on the > > website. > > At the very least, Gnome and KDE should be up front on the frontpage. > > So, I am far from a web designer, but if you aren't a Linux savvy person > and just decided to try out this Fedora thing because you heard it was > nice and you go to download it and get: > > our website: Want a workstation? > user: yes! > > our website: great! We have Gnome and KDE! > user: what? what does that mean? which one should I get? > > our website: > > Gnome: "Get things done with ease, comfort, and control. > An easy and elegant way to use your computer, > GNOME is designed to help you have the best possible computing experience." > > KDE: "Powerful, multi-platform, and for everyone > Use KDE software to surf the web, keep in touch with colleagues, friends > and family, manage your files, enjoy music and videos; and get creative > and productive at work. The KDE community develops and maintains more > than 200 applications which run on any Linux desktop, and often other > platforms too." > > User: ok, that didn't tell me much, whats the difference? > perhaps I will just keep using windows. > > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple > things, we need some way to describe them to uses who might not know the > history of things and do it in a quick enough way that they won't decide > it's all confusing and go do something else. > > kevin Let's assume that we all agree with what you stated ( and I personally partly do). Why do we promote Workstation (with Gnome) over any other alternative that might arise? (in this case, a Fedora Workstation KDE) I understand that the Change Proposal is about switching the "Workstation" concept to using Plasma KDE and that approach might have been flawed but... how do we challenge the "status quo" where everybody assumes that Fedora's default is Gnome? Because somebody else has mentioned that is unlikely that the KDE Spin can be promoted to an Edition because it "overlaps" with the current Workstation... And I am not arguing for the sake of arguing. I genuinely want to know how to make Fedora's default to be Plasma KDE because I do believe the whole *linux* (and Fedora's) community will benefit from having a major distro like Fedora not defaulting to Gnome. Best regards, Marc PS: thanks for the feedback to everybody :-) -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Saturday, 10 February 2024 01:11:03 CET Kevin Kofler via devel wrote: > By the way, what that link does not mention when it talks about "multiple > packages for the same thing" is browsers / web engines. The Spin ships > several applications using QtWebEngine, e.g., KMail, so that engine is not > going away. But in addition to one or two browsers using that, which add > little to no overhead size-wise, it still ships the duplicate application > Firefox that bundles its own, completely different web engine. See: > https://bugzilla.redhat.com/show_bug.cgi?id=1920298 . (The main argument has > always been market share, which at 2% market share and steadily decreasing > does not sound relevant anymore.) Let's stay on topic. Thanks. -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Friday, 9 February 2024 11:53:01 CET Sérgio Basto wrote: > so you agree that are giving the overhead to us (the people who want > keep X11 as it is ) Yes!!! OF COURSE! If you wanna maintain something you need to handle the overhead! Not the other way around! -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Friday, 9 February 2024 04:15:17 CET Kevin Kofler via devel wrote: > Well, then kwin-x11 will also no longer depend on kwin YE > and your argument > that it is a problem because it introduces a hard version lock will be moot. Well, there would be no argument to be "moot" because there would be no problem, would 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Thursday, 8 February 2024 20:21:19 CET Roy Bekken wrote: > You mean the proposal from kde-sig that they wanted changing to plasma 6 and > dropping X11 because they have no interest of supporting it? > Yes. Interest *and* resources. > Don’t see why that should prevent someone else from supporting it, > especially after multiple people have come forward and said they relay on > X11 to have an functional desktop. The position has been explained already. We start going in circles. -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Thursday, 8 February 2024 12:33:29 CET Sérgio Basto wrote: > you are removing X11 from the builds deliberately , Yes. And the moment this: https://invent.kde.org/plasma/kwin/-/issues/139 gets implemented we will not have to remove anything. (remember that the Change Proposal was approved) > when > many people , members of Fedora on devel mailing list, express that > they want have X11 , in fact we have many people that defend keep X11 . > You have said this on many occasions and no matter how many times you repeat it , it doesn't mean anything different. > you set %bcond to 0 on kwin.spec [1] and plasma-workspace.spec [2] > Yes. We do. That has been explained elsewhere and , if we weren't going to build stuff on a copr , we wouldn't have that. > > you are trying discuss semantic ? > I am saying that words have meaning. > http://languagelog.ldc.upenn.edu/myl/SemanticArgument1.png Really? ¯\_(ツ)_/¯ -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Wednesday, 7 February 2024 13:21:15 CET Peter Boy wrote: > If KDE Sig wants to attract users to Wayland, then the only good strategy is > to make Wayland better than the previous way (i.e. Xorg) and promote that > fact actively. Does something make you think that we do not? > Simply banning or deleting something will only alienate people and they > will switch in frustration to another alternative, i.e. distribution in our > case. We are not banning nor deleting anything. We are not _supporting_ it. > Unfortunately, some Fedora maintainers seem to take their cue from the missionaries and conquistadors of the 16th and 17th centuries and try fire and sword and coercion. A bad strategy in a free world. This kind of comment is completely out of line. Please be considerate to others. It's a bit surprising to me that you wrote this and in the very same message mentioned "alienate people" -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Sunday, 4 February 2024 03:55:42 CET Kevin Kofler via devel wrote: > We (the KDE SIG and me) stopped being Friends when you (the KDE SIG) > unilaterally decided to ban me from all your communication channels, a ban > that has still not been lifted years after the alleged misconduct (on IRC > only, but the ban was extended to the mailing list and even your Pagure > issue trackers!) you accused me of. > I will only say to everybody who is interested that you are only reading Kevin's side of the story. There's another one. > Nevertheless, I am really trying hard to not make this personal That is absolutely true, I have mentioned this several times in our Matrix room. Kudos to you for that. -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Friday, 2 February 2024 00:38:56 CET Kevin Kofler via devel wrote: > To make it clear about the situation of that particular package: The KDE SIG > never notifies me in advance about kdepim bumps. To make it clear about this particular package: - we have _forgotten_ indeed to notify the maintainers on occasions. - why did we forget? because the KDE collection is close to 400 packages and despite our automation, we are humans and this kind of thing happens. - to make it clear that we *bother* (using your own words), I even submitted tickets upstream to help out on the situation: https://invent.kde.org/pim/ pimcommon/-/issues/2 - worth mentioning that despite the kdepim libraries being released as packages, they are *NOT* intended to be consumed externally but as a whole KDE PIM ecosystem - this approach worked for blogilo in the past because it was part ot the KDE PIM ecosystem - worth mentioning that Blogilo has been unmaintained for many years I personally used blogilo in the past and loved the app myself. However, sometimes we need to be pragmatic in life. I will quote one of the main developers of the KDE PIM: " I don't understand why you still continue to release a dead apps from long time..." Link to the *unmaintained* blogilo (not _legacy_): https://invent.kde.org/ unmaintained/blogilo -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Friday, 2 February 2024 00:49:19 CET Kevin Kofler via devel wrote: > This can be solved with communication. > That is dealing with the situation your packages would cause, not solving it. ( I don't mean ill will, it just a statement) > That said, if the KDE SIG does not want to have to coordinate changes with > any third party, not even as far as just notifying us of the impending > changes (Stephen Gallagher's proposal does not even require you to wait for > me or anybody else to reply! Just to asynchronously notify me/us, i.e., drop > a single mail to kwin-x11-owner@….), Nobody wants having to coordinate with others, that makes any process more complicated and resource consuming. > then the easy way would be to just go > back to building those subpackages as part of the respective main package. That is the easy way for what you desire, not _the easy way_. > I.e., let me and/or anyone else who wants Plasma on X11 comaintain the 2 > packages and assign any X11 issues to me/them. That would probably be the > least work for everyone. > One of the main reasons of the Change Proposal was precisely to lower the maintenance. Having to filter through the tickets and assigning them to the relevant person is certainly more costly than not supporting X11 at all. > But the separate packages as I submitted them for review are the next best > solution. That is only your opinion, of course ;-) -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Wednesday, 7 February 2024 05:07:28 CET Garry T. Williams wrote: > I went to compose an E-mail message using kmail and its composer > window and noticed it was broken.[*] I couldn't even find a bug > report about this. I fear it's because many others just ignored the > various bugs and went back to using X11. Thank you for taking a proactive approach Garry! -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Saturday, 3 February 2024 17:52:42 CET Adam Williamson wrote: > Why? This is the part I don't understand. Can you explain it in more > detail? Thanks. If we update plasma-workspace and kwin we are likely gonna break binary compatibility with the proposed packages. They will need to be rebuilt ala soname bump of sorts. I understand this is no different than the aforementioned soname but it is certainly not a "standard" chain of dependencies. Best regards, Marc -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Friday, 2 February 2024 20:56:22 CET Gary Buhrmaster wrote: > regarding tracking (and taking) bugs, and > lack of timely updates, for something as > visible as the entire desktop. Here you are highlighting some of my (I speak for me, not the KDE SIG) main concerns: - If a user decided to install the X11 package and has an issue: who do you think they are going to reach? who is gonna get the "bad publicity" for the issue? ( specially when we are forced to tell them we don't support X11...) - As the packages stand right now, the KDE general updates will have to wait for the proposed packages to be updated by their maintainers or we will have to do the updates ourselves (which defeats completely the point of our change proposal). Best regards, Marc -- ___ 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tuesday, 30 January 2024 15:57:12 CET Steven A. Falco wrote: > I'm delighted that there are like-minded folks who want to maintain X11. > Please allow them to do so. I will just quote you what Stephen said: > This is > misleading, as the move to Wayland is specifically because the > upstream of X11 *itself* is largely unmaintained. These packages are > not maintaining X11, they are adding new dependencies on 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
On Tuesday, 30 January 2024 14:04:29 CET Germano Massullo wrote: > What does it mean that FESCo is applying an injunction? Only that the packages in question are "on hold" until a decision can be taken. The word sounds way worse than what it really is. -- ___ 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: Second call for rebuilding powerdevil and call for help from provenpackagers
On Saturday, 28 October 2023 11:59:55 CEST Marc Deop i Argemí wrote: > > * f40-build-side-76474 > > * f39-build-side-76476 > > * f38-build-side-76478 > > > > > I will take care of this today (2023-10-28) Powerdevil has been rebuilt on the aforementioned sidetags ___ 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: Second call for rebuilding powerdevil and call for help from provenpackagers
On Thursday, 26 October 2023 22:57:28 CEST Qiyu Yan wrote: > Hi all, > > It is nearly a full month since last mail. And seems that koji has > recycled the side tags due to inactivity. I re-created them: > > * f40-build-side-76474 > * f39-build-side-76476 > * f38-build-side-76478 > > Seems that I don't have the permission to push to powerdevil and rebuild > it so maybe any provenpackagers can help? > > Cheers, > Qiyu > > 在 2023/9/29 14:04, Qiyu Yan 写道: > > Hi all, > > > > I am planning to update package ddcutil to latest upstream release > > 2.0.0. This will introduce a soname bump for libddcutil.so from > > libddcutil.4 to libddcutil.5. I checked that the only affected package > > due to this update will be powerdevil. > > > > dnf repoquery --whatrequires "libddcutil.so.4()(64bit)" --release=40 > > ... > > powerdevil-0:5.27.8-1.fc40.x86_64 > > > > I have built ddcutil in following side-tags: > > > > * f38-build-side-74742 > > * f39-build-side-74740 > > * f40-build-side-74738 > > > > If possible, please built powerdevil in those side-tags that we can > > push the update together. > > > > Cheers, > > Qiyu I will take care of this today (2023-10-28) Best regards, Marc Deop ___ 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
Testing Release Upgrades via Discover
Hello, as many of you know, the Fedora KDE spin doesn't have the ability to upgrade to a new stable release in a graphical manner and we always had to resort to using DNF System Upgrade [1] to upgrade to the next stable release. Thanks to the work done by aleasto [2] on this MR [3], discover upstream now supports distribution upgrades via the PackageKitBackend. The @kdesig has created a COPR repository [4] with a backport of the aforementioned MR to the 5.27.X code. We would like to ask for volunteers to test the release upgrade from Fedora 37 to Fedora 38 using Discover and we will welcome any feedback you may have. I wrote a blog post [5] with instructions on how to proceed. Looking forward to your comments here or on our matrix room [6]! [1] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/ [2] https://invent.kde.org/aleasto [3] https://invent.kde.org/plasma/discover/-/merge_requests/500 [4] https://copr.fedorainfracloud.org/coprs/g/kdesig/discover-distro-upgrade/ [5] https://blog.marcdeop.com/?p=267 [6] https://matrix.to/#/#kde:fedoraproject.org Best regards, -- Marc Deop i Argemí System Engineer ___ 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: Unannounced .so version bump (F38/F39): openexr2
On Thursday, 23 February 2023 09:48:36 CET Marc Deop i Argemí wrote: > > - kde-runtime > > - kdebase3 > > - kdelibs I created a side-tag: f39-build-side-63924 and rebuilt kdelibs and kde- runtime. However, it turns out I don't have commit access to kdebase3. I submitted a PR here: https://src.fedoraproject.org/rpms/kdebase3/pull-request/2 Could any kdebase3 maintainer please check it out and build on the aforementioned f39-build-side-63924 site-tag? Best, -- Marc Deop i Argemí System Engineer ___ 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: Unannounced .so version bump (F38/F39): openexr2
On Thursday, 23 February 2023 04:42:34 CET Ben Beasley wrote: > - kde-runtime > - kdebase3 > - kdelibs I can take care of those three. > The package was also updated in F38/Branched, but the build is still only > tagged into f38-updates-candidate, and no Bodhi update has been created. If > the maintainer proceeds with the update for F38, all of the above dependent > packages will need to be rebuilt there, too, once the update reaches > stable. Alternatively, maybe the F38 build could be tagged into a side tag. Could we please create the sidetag and update all the needed packages there? Thanks, -- Marc Deop i Argemí System Engineer ___ 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: libindi upgrade to 2.0.0 and soname bump
On Tuesday, 14 February 2023 19:13:39 CET Mattia Verga wrote: > To the kstars maintainers: I can take care to upgrade the package, if > you want (it's just a simple version bump and upload new sources). > > To the stellarium maintainers: I will wait for a patch from upstream > before pushing the side-tag (I hope before it expires). > > To both kstars and stellarium maintainers: if possible, I'd like the > upgrades to land in f38 also, let me know. No complains from me, you are taking care of everything :-) Best regards, Marc ___ 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 Linux 38 blocker status summary
On Friday, 10 February 2023 15:11:19 CET Marc Deop i Argemí wrote: > On Friday, 10 February 2023 14:47:19 CET Ben Cotton wrote: > > > 3. kwin — kwin_wayland often crashed when used as the sddm Wayland > > compositor and logging out of Plasma resulting in a black screen — NEW > > ACTION: Maintainer to diagnose issue > > > > Does it help if I build Plasma 5.27.0 on a F38 sidetag so we can investigate > if the issue persists? Just for your information, I have built KDE Plasma 5.27.0 (which includes kwin) on sidetag f38-build-side-63172. I am uncertain if I should trigger an update on F38 now. Thoughts? Best regards, Marc Deop ___ 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 Linux 38 blocker status summary
On Friday, 10 February 2023 14:47:19 CET Ben Cotton wrote: > 3. kwin — kwin_wayland often crashed when used as the sddm Wayland > compositor and logging out of Plasma resulting in a black screen — NEW > ACTION: Maintainer to diagnose issue Before spending any significant amount of time on this, it's worth pointing out that version is from the KDE Plasma 5.27.0 Beta. The final version has been built already on Rawhide and the official release from upstream is happening on Tuesday. Does it help if I build Plasma 5.27.0 on a F38 sidetag so we can investigate if the issue persists? Thanks Marc ___ 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: Orphaned packages looking for new maintainers
On Monday, 8 March 2021 11:52:10 CET Miro Hrončok wrote: > nload cicku, fab, fale, orphan 2 weeks > ago I'll take that one :-) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F21 Self Contained Change: Remote Journal Logging
On Tuesday 22 April 2014 06:34:48 Lennart Poettering wrote: On Wed, 16.04.14 12:46, Bill Nottingham (nott...@splat.cc) wrote: Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) said: On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. What's the future of gatewayd if this becomes more widely used? gatewayd works in pull mode. Here I'm proposing a push model, where the client (i.e. machine generating the logs) pushes logs to the server at the time of its own chosing. gatewayd is probably better for some use cases, this for others. I understand the pull vs push distinction ... I'm just not clear why pull would ever be a model you'd want to use. (vs something like a local cockpit agent.) Pull is the only model that scales, since the centralized log infrastructure can schedule when it pulls from where and thus do this according to available resources. THe push model is prone to logging bursts overwhelming log servers if you scale your network up. Push mechanism seems to scale pretty well when we talk about web sites. Specially taking into account that you mentioned that systemd is going to use https protocol, you can take advantage of many existing solutions to scale/load balance your systems. (although that doesn't mean I agree on the election of the protocol) I am pretty sure that a pull model should be the default for everything we do, and push only be done where realtimish behaviour is desired to do live debugging or suchlike. For me it should be precisely the other way around(in syslogging context) I am pretty sure the push model concept is one of the major weaknesses of the BSD syslog protocol. Again I disagree: for me is a strong point :-) -- Marc Deop System Administrator 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: F20 System Wide Change: No Default Syslog
On Wednesday 17 July 2013 03:20:42 Lennart Poettering wrote: As mentioned before, if people run programs that require /var/log/messages they should simply install rsyslog and be done with it. That terribly sounds like my way or the high way. Many people have raised concerns not only about having /var/log/messages in the base installation but about needing/wanting *simple text* logs by default as well. I for one, advocate against having to use a (forced)tool to read log files. Even when you think it's better, many *do not*. Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wednesday 17 July 2013 15:39:23 Lennart Poettering wrote: On Wed, 17.07.13 14:36, Denys Vlasenko (dvlas...@redhat.com) wrote: instead of administrators simply adding rsyslog or syslog-ng manually at install time or to their ks snippets. And this too was answered several times already. The machine in question may be already borked. Our support people will need to figure out - over the phone or email! - what has happened on client's installation, and having traditional grep/sed/awk recipes not working anymore because /var/log/messages is not there anymore is an extremely unwelcome discovery in an emergency. You guys aren't administrators who are dealing with these problems every day. You don't feel the pain you create for other people. Again: cat /var/log/messages becomes journalctl tail -f /var/log/messages becomes journalctl -f tail -n100 /var/log/messages becomes journalctl -n100 grep foobar /var/log/messages becomes journalctl | grep foobar This isn't complex. You can grep/sed/awk as much as you want. You just do it over the output of journalctl rather than teh file. That's not that big a difference. And if you really need it as a file, you can do journalctl /var/log/messages, and have it in a file. And if that doesn't cut it and you want something that is living, then install rsyslog and you got the real /var/log/messages back. and quite frankly administrators that complain about journal have not actually tried it and experienced the flexibility the journactl gives them it truly is not as bad as some people are trying to make it out to be. False argument. People (on this thread) aren't complaining about journactl being a bad thing. They are complaining about /var/log/messages disappearing. It's only disappearing as a file, it is not disappearing as a text format. journalctl has that, and thanks to the power of unix pipelines you can make use of that pretty much in the sam ways in grep/sed/awk as the text file itself. Lennart Again with this? The problem is that we need another tool (journalctl) in the middle of that process. Not to mention the problems (in the form of bugs/incompatibilities) that such tool can introduce in the job ( text files and sed,grep... have decades of refinement). Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Monday 15 July 2013 16:29:08 Thomas Bendler wrote: 2013/7/15 Lennart Poettering mzerq...@0pointer.de [...] Well, assuming that bash is entirely in memory. And also, note that neither cat, nor cp, nor tail are actually bash builtins and will not work. It's pretty hard (though certainly possible) viewing files with just bash builtins. echo $( /var/log/messages) For what it's worth: while read -r line; do echo $line; done /var/log/messages Will do the same and will work line by line instead of putting everything in one *gigantic* single line Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Monday 15 July 2013 13:23:29 Lennart Poettering wrote: Hence, the choice between journal by default + syslog optional and journal optional + syslog by default does not exist. The choice between journal by default + syslog by default and journal by default + syslog optional however does. I would choose journal by default + syslog by default. In fact, I would rather have systemd write text fies... (if binary files are *needed* I would even dare to say that we should write the text version as well) But anyway, I'd still like to hear the technical reasoning for the opinion you expressed. Technical reason? It's been already mentioned on this thread: You can read text files with whatever reader you'd like (or even shell built-ins) rather than relying on a binary reader. I've read the Benefits to Fedora section and I don't think they are significant enough to remove syslog from the default installation. Just my two cents, Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Monday 15 July 2013 17:55:34 Lennart Poettering wrote: On Tue, 16.07.13 00:55, Dan Fruehauf (malko...@gmail.com) wrote: +1 - same here. You're far from being alone. I'm still trying to get used to the new systemd in Fedora and still trying to think why I need it. Altogether for my day to day use I find it as added complexity with no real benefit cerca f15. Unix/Linux for me is the simplicity of text files. If I lose the simplicity of text files I just wonder what is left for me? A bunch of vague files in a binary format I need complex tools to decipher? Might as well just install win7 and utilize my gfx card. Well, there are certain things on Unix that are text files and many things that are not. Binary log files have a long tradition on Unix, for example in wtmp and utmp. We have binary files in /etc, and everywhere else. journalctl is certainly not a complex tool to understand. Command lines usually get shorter by using it rather than the equivalent for /var/log/messages. cat /var/log/messages becomes just journalctl tail -f /var/log/messages becomes journalctl -f tail -n 100 /var/log/messages becomes journalctl -n 100 grep foo /var/log/messages becomes journalctl | grep foo And the outputs of these files are the exact same text streams you are used to. However, enhanced with a lot of niceties that make them more user friendly. For example, you get colors based on the log level, or there's a line drawn between reboots. You get the time zone corrected, and you get unconditional PID data, you can filter very very easy, the data is unfakable and so on. Just think about this: journalctl -b shows you output of the current boot only journalctl --since=today shows you the output of today only journalctl -p notice shows you only notice and error messages (i.e. all the important stuff) journaclctl -u crond shows you only the messages from cron. ... and so on. Now try to think how hard it is to express queries the same way on classic syslog. And how slow they become on larger database because they aren't indexed. journalctl makes a lot of things easier, much easier. If you say it is complex or difficult to use I am pretty sure you never had a closer look at it. (Also, I am not sure what you mean by vague. Please note that the file format is fully documented: http://www.freedesktop.org/wiki/Software/systemd/journal-files/ also, we commited to an API for them and more) Lets try to keep things simple. This is why we use Fedora. This is why I use Fedora. We are certainly making things simpler by introducing nice query tools like journalctl and by reducing the number of packages we install by default, and by removing redundancy. Some may say that you are making things harder by introducing tools (thus new things to learn) that are not really needed on a day to day basis (which is, in fact, what Dan wrote). However, I don't think we are discussing here whether we keep systemd or not rather than syslog, are we? ;-) Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: SDDM as the default KDE DM
On Monday 15 July 2013 13:34:58 Lennart Poettering wrote: On Mon, 15.07.13 13:17, Martin Briza (mbr...@redhat.com) wrote: BTW, I have some more multi-seat hardware to give away to folks who want to add true automatic multi-seat to stuff like display managers. It's a USB box that will give you an VGA/DVI port + audio, plus connectors for kbd/mouse. So you just need to connect a display, mouse and keyboard to it, and then plug it into your existing machine and should have a second seat wihout any configuration. This works out-of-the-box for GNOME/gdm systems. If you guys want to make this work for KDE too, then I can pass you that hardware. It's free, you can keep it, but I'd preferably like to send this to Europe only. It's hardware you can use to implement this stuff: http://www.freedesktop.org/wiki/Software/systemd/multiseat/ (This offer stands for everybody who hacks on things like this, regardless which desktop environment you hack on.) Lennart Thanks for the offer! Even though I'd love to have the device for my personal use, it won't be necessary. I have borrowed one of the devices in our office to write basic multi-seat support for KDM, so you can distribute it to other folks who'd want to add the support to other DMs. Hmm, any chance you can connect me with somebody from the KDE community who might need such a device and would do something nice with it? Somebody who wants to work on some display manager, or maybe on some graphical tool to reconfigure seats or so? I am trying so hard to be nice to the KDE community, but nobody wants my presents! ;-) Lennart Why not contact them directly at: kde-de...@kde.org or at #kde-devel in freenode.net? Regards, Marc Deop -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Tuesday 19 March 2013 09:27:16 Christof Damian wrote: Fixing an apostrophe – no Fixing our UTF-8 handling – definitely yes The issue here is not only about the Fedora's release name rather than fixing our UTF-8 handling. Sounds like an important bug to fix, at least to me Fixing them now will benefit all future releases and all the people living in non pure ASCII countries. Which is pretty much every non-english speaking country Marc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Couldn't we enable 256 colors by default on TERM?
On Thursday 31 May 2012 02:20:26 Pádraig Brady wrote: On 05/30/2012 04:16 PM, Marc Deop wrote: On Wednesday 30 May 2012 10:04:49 Pádraig Brady wrote: I've some notes about 256 colors here: http://www.pixelbeat.org/docs/terminal_colours/#256 That information is mostly fine. There are some errors though (you say you set your TERM variable in your .bashrc...) Yes. If you follow the link to my .bashrc it further clarifies that to handle all cases, the variable should be set earlier in ~/.profile or system wide in /etc/profile.d/... Still wrong in my opinion. This should be set by your terminal emulator (be it konsole, gnome-terminal or whatever) and not in your personal environment. You would end up having to check for *a lot* of things If you restrict yourself to local xterms (of most varieties) you're fine. Nowadays you'll be fine almost everywhere. Your system should not set the TERM variable to xterm or whatever if you are in a virtual terminal (that would happen if you set your TERM variable in your .bashrc for example...) Well that also happens if set in /etc/profile etc. What you need to do I think is guard like: $ cat /etc/profile.d/256color.sh [ $TERM = 'xterm' ] TERM=xterm-256color; export TERM What happens with urxvt or eterm terminals? As said above, .profile or .bashrc or whatever is not a good place to set this things However... 256 color doesn't work correctly on Linux virtual consoles. Totally true Handled with the conditional above That works for VT that use xterm as TERM environment but... what of other ones? Also since your $TERM is propagated to remote systems when you ssh, if they don't support that you'll have issues. For example sshing to debian systems (I've not tried newer releases) will be problematic unless a package in installed there. Also if I ssh to solaris then I need to reset TERM to xterm for man pages to work correctly etc. IMHO this should be the other way around: for old systems where the 256 don't work you should manually set your TERM variable to something that would work and not the other way around This could be contentious. However I notice (from searching the web) is that Mac OS X Terminal's default $TERM value is xterm-256color since Lion 10.7. What I'd do (I will do if you prefer) is to propose the feature at: https://fedoraproject.org/wiki/Releases/18/FeatureList That will both provide a todo list and allow voting on acceptance. That sounds reasonable, +1 for me here! :) Also in the release notes we should have notes for workarounds for older systems where you would have issues. I notice ncurses-term is still 'standard' rather than 'required' in debian. Perhaps we could log a request for that to change? Note that package is 6.6MB installed so maybe the 256 color support could be merged back to ncurses-base ? I just tried ubuntu 12.04 there and it also doesn't install ncurses-term. I did the following to double check: $ TERM=xterm-256colors man ls WARNING: terminal is not fully functional You made a spelling mistake there, try again without the s: xterm-256color There is still further issues to consider locally. screen and vim settings would need to be tweaked also as per: http://www.robmeerman.co.uk/unix/256colours Vim would work just not with all the colors. We could set an environment configuration enabling 256 colors by default as well, couldn't we? As for screen... I don't even remember how to set it, I would need to do some research on it Great discussion Pádraig :) Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
