Re: LibreOffice packages

On Sat, Jun 3 2023 at 09:56:40 AM +0200, Vitaly Zaitsev via devel wrote: Yes, Fedora is dying. Slow, but imminent. IBM doesn't want to keep it in a good condition, so they fired a lot of good engineers. It's very sad. I have been using it for years. I'm not going to defend callous layoffs

Re: LibreOffice packages

On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos wrote: Hello, While i completely understand why you do this i do think that it is important for desktop/workstation oriented devices to have some optional access to Office directly from the image file. Have you considered shipping

Re: OpenCOLLADA need a little c++ help

This is case in point for why you should not use -Werror when building packages. Instead of adding pragmas in various places, I would track down where the -Werror gets added and patch that out instead. (Exception: it does make sense to use -Werror=format-security,

Re: ppc64le builds taking ages

On Fri, May 19 2023 at 04:54:42 PM +0200, Dan Horák wrote: seems the build got restarted, perhaps due OOM on the builder, and actual build time was 12h, perhaps the builder or the vmhost were overloaded. Do you see the long build times in recent builds too? Both examples are from March. I've

Re: Update on Changes/PortingToModernC

Wow, good job. Looks like that was a huge effort. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)

On Wed, Apr 26 2023 at 08:50:51 AM +0200, Vitaly Zaitsev via devel wrote: If needed by Steam or Wine, they should provide a .conf file instead rather than changing this setting system wide. Problem is this doesn't work for containers ___ devel

Re: It’s time to transform the Fedora devel list into something new

On Tue, Apr 25 2023 at 11:32:14 AM +0200, Florian Weimer wrote: This option has been disabled in the Fedora instance, though. There should be “Mailing list mode“ and “Enable mailing list mode” at the end of this page:

Re: It’s time to transform the Fedora devel list into something new

On Sun, Apr 23 2023 at 05:01:53 PM +0200, Björn Persson wrote: But some people in this thread talk as if it's possible to get the actual messages by email. I even see some hints that a proper tree view might be possible. But many others say the email features of Discourse are no good. The

Re: default bash history (non)preservation

On Tue, Apr 11 2023 at 08:38:39 PM -0400, Todd Zullinger wrote: Indeed. I think that setting PROMPT_COMMAND as an array in the default configuration would be the place to start. Then packages which enable such functionality can be added with more granularity. If the desktop working group

Re: default bash history (non)preservation

On Tue, Apr 11 2023 at 12:18:58 PM -0500, Chris Adams wrote: I wouldn't do that part; that's additional disk I/O for every prompt. Especially when the system might be having issues, users (especially root) don't need something interfering with every command. This would mean an NFS home would

Re: Future of encryption in Fedora

There are a couple more disadvantages to using Discourse: * Several of the replies are lower-quality and are not contributing to the conversation. * There is no threading like we have with emails, so these replies are more disruptive and the discussion is less organized.

Re: Future of encryption in Fedora

On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane wrote: This seems like exactly the kind of discussion that belongs on the devel list, not on a website that I have to remember to visit for updates. There is a notification bell in the right sidebar. Click it. ;)

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

On Tue, Mar 14 2023 at 10:01:06 AM -0400, David Cantrell wrote: And as part of the US Executive Order on Cybersecurity, we need to start using SPDX identifiers in software we package and provide so that our downstream users are in compliance: If you rely on this then you're up a creek,

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

On Tue, Mar 14 2023 at 09:37:25 AM -0400, David Cantrell wrote: There may be longer examples. Uh, yeah. texlive's is bad enough but I'm skeptical that that's close to a worst-case. Proponents of this style of license tag should try this exercise for WebKitGTK, Chromium, Firefox,

Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

On Fri, Mar 10 2023 at 04:17:13 PM -0500, Matthew Miller wrote: Yeah, this is a change from previous guidance. Instead of trying to calculate the effect, just state what's there. Even if it makes the expression kind of long and unwieldy. Just for avoidance of doubt: this guidance is

Re: webkitgtk6.0 soname bump season

On Thu, Feb 23 2023 at 03:13:28 PM -0600, Michael Catanzaro wrote: Quick update here. We are approaching the end of soname bump season! \o/ There will be one or (less likely) two additional soname bumps within the next three weeks, and then when WebKitGTK 2.40.0 is released alongside GNOME 44

Re: Degradated modules support

On Thu, Mar 9 2023 at 09:48:11 AM +, Zbigniew Jędrzejewski-Szmek wrote: Naive question: how does the approach with flatpak-builder would compare to the current one with modularity? Well it would certainly look different, but I did not suggest that we would use flatpak-builder. Maybe Owen

Re: Degradated modules support

On Wed, Mar 8 2023 at 04:10:15 PM +0100, Petr Pisar wrote: That could also affect seemingly unrelated parts of Fedora like Flatpaks whose build process is based on modularity. I can address this. We intend to stop depending on modularity so that we can reliably build Flatpaks even when

Re: gnutls time_t breakage on i686

On Fri, Mar 3 2023 at 03:21:33 PM +0100, Florian Weimer wrote: Is Valve already maintaining a 32-bit distribution? If not, where would their Flatpak get the builds from? There is already a Steam flatpak based on freedesktop-sdk, which builds just enough i686 stuff for Steam to work.

Re: gnutls time_t breakage on i686

On Fri, Mar 3 2023 at 12:03:12 PM +, Daniel P. Berrangé wrote: Yes, this whole episode makes me want to kill off i686 builds of everything I maintain, even when its not a leaf package. I only spent time investigating the root cause in gnutls because I saw valgrind warnings and wanted to

Re: Proposal: drop delta rpms (for real this time)

On Fri, Feb 24 2023 at 11:42:17 AM -0400, Robert Marcano via devel wrote: Does DNF on RHEL for example do something different when --security is involved? Because the RHEL documentation talks about it as a feature to use. Is a lack of metadata for previous updates the problem or the

Re: Proposal: drop delta rpms (for real this time)

On Fri, Feb 24 2023 at 12:00:40 AM +0100, Björn Persson wrote: There are also other dangers with installing only security fixes. If a bugfix is released and packaged, and later it's discovered that the bug had security implications, then no security update will be made because the fix is

Re: webkitgtk6.0 soname bump season

On Thu, Jan 19 2023 at 06:02:53 PM -0600, Michael Catanzaro wrote: The webkitgtk6.0 package (for GTK 4, not GTK 3) will be doing several soname bumps over the next two months in preparation for stabilizing the GTK 4 API. I won't announce individual bumps since they will be frequent. I

Re: Fedora Linux 38 blocker status summary

As a browser maintainer itself, I'm very supportive of the Falkon project. I consider it to be KDE's equivalent of Epiphany, sort of a sister project, more or less. On Tue, Feb 14 2023 at 03:44:06 AM +0100, Kevin Kofler via devel wrote: Even Qt 5 QtWebEngine (considered obsolete by Qt) still

Re: Will dnf5 be ready by F39?

On Sat, Feb 4 2023 at 02:05:16 PM -0800, Gordon Messmer wrote: Are there any plans to provide the gstreamer or gtk plugins that automatically install codecs and fonts that are missing? (https://github.com/PackageKit/PackageKit/tree/main/contrib) Or are those features just going away? I

Re: Will dnf5 be ready by F39?

On Wed, Feb 1 2023 at 08:41:55 PM -0800, Gordon Messmer wrote: Is the current plan to support the PackageKit API in the dnf daemon, or to port packagekit's dnf backend to the dnf5 API? Red Hat is currently planning to port everything we care about that uses PackageKit to use dnfdaemon's

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, Jan 26 2023 at 03:49:55 PM -, Patrick Griffis via devel wrote: How is an orphan package a good service to users? It will just become outdated and degrade over time. Either (a) somebody else will take the package after it has been orphaned, or else (b) the package will be retired

Re: Retiring Bottles in favor of Flatpak provided by upstream

Maybe we can start by filtering out the most outrageous applications: anything that uses --filesystem=home, --filesystem=host, or unfiltered session bus access. That still leaves plenty of possible sandbox holes, but it's better than nothing. We could do this just in GNOME Software and KDE

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, Jan 26 2023 at 09:23:35 AM -0500, Neal Gompa wrote: But we know that people don't read those. We also know that ISVs cannot generally be trusted with regards to the permissions they set for their own apps. This is literally why Android and iOS changed their model. If you want to

Re: [Test-Announce] Heads up: testing requested for significant PackageKit update

On Mon, Jan 23 2023 at 09:27:08 PM -0800, Gordon Messmer wrote: Time will tell if that's credit or blame. LOL. Sincerely, though, I know I'm not the first person to work on tackling this, and I can't take all of the credit. Good, since I fear it's going to be blame. :D I have

Re: [Test-Announce] Heads up: testing requested for significant PackageKit update

On Mon, Jan 23 2023 at 04:28:27 PM -0800, Adam Williamson wrote: This feature has been turned on and off and on and off again a few times before because it was found to cause problems. This time, a few folks have done some diligent work trying to ensure all the previously- encountered

Re: systemd-resolved package overwrite /etc/resolv.conf again

This is only supposed to happen if (a) upgrading from systemd < 246.1-1, which you're not doing, or (b) installing systemd for the first time, which you're not doing. Must be a bug in the package scriptlets. ___ devel mailing list --

Re: Gnome-online-accounts can no longer keep fedora kerberos tickets valid?

On Sat, Jan 21 2023 at 11:33:48 AM +0100, Julian Sikorski wrote: This is getting annoying. Is this a known problem/limitation? Thanks. Yes indeed. Please test: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e966905644 ___ devel mailing list

webkitgtk6.0 soname bump season

Hi, The webkitgtk6.0 package (for GTK 4, not GTK 3) will be doing several soname bumps over the next two months in preparation for stabilizing the GTK 4 API. I won't announce individual bumps since they will be frequent. I will handle rebuilds of the impacted packages: gnome-initial-setup,

Re: Improving Fedora boot time when libvirt is installed

On Wed, Jan 18 2023 at 08:27:02 PM +0100, Fabio Valentini wrote: Suggests are useful for the case where multiple packages (let's say packages A and B) provide "foo", a package C depends on something that provides "foo" (i.e. works with both A and B), but C prefers A over B if neither of them

Re: Improving Fedora boot time when libvirt is installed

On Wed, Jan 18 2023 at 10:19:24 AM -0800, Gordon Messmer wrote: Several people suggested using a weak dependency (Suggests:) on the iscsi driver, but I don't think that would solve the problem for most users because weak dependencies are installed by default and nothing really communicates to

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Jan 12 2023 at 08:31:33 PM +, Jonathan Wakely wrote: IIUC the difficulty is finding out which ones are being slow, but that could be solved by changing the signal to SIGABRT, right? Well we still have to end with SIGKILL because SIGABRT is ignorable, so the new proposed behavior

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Wed, Jan 11 2023 at 11:48:27 AM -0800, Kevin Fenzi wrote: I do appreciate the change to do an abort on these units. Will that get reported via abrt? It should, yes, the same as any other crash. ___ devel mailing list --

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

On Wed, Jan 11 2023 at 05:19:03 PM +0100, Alexander Ploumistos wrote: Thanks Michael, what a headache. So for RPM Fusion to be included, it would have to change its scope/definition and host a more "varied" suit of packages? Well I can't be certain what Fedora Legal will or won't accept, but

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

On Wed, Jan 11 2023 at 03:47:41 PM +, DJ Chase wrote: True, but it was my understanding that “our Flathub offering” in “This change would remove the filtering from our Flathub offering” refers to Fedora Flatpaks, which is enabled by default, not the filtered view of Flathub that can be

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

On Wed, Jan 11 2023 at 02:44:01 AM +0100, Alexander Ploumistos wrote: Flathub carries programs like VLC, mpv, yt-dlp, bundled versions of ffmpeg and so on. Why is it ok now to get these from flathub, but not from RPM Fusion? Hi, it's because RPM Fusion is explicitly designed to provide extra

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Tue, Jan 10 2023 at 06:00:59 PM -0600, Michael Catanzaro wrote: I'm going to amend this proposal to specify TimeoutStopFailureMode=abort as well, so we can get crash dumps and bug reports when programs fail to quit properly. By the way, the goal with this is to surface bugs and dodge any

Re: F38 proposal: Unfiltered Flathub (System-Wide Change proposal)

On Wed, Jan 11 2023 at 01:33:18 AM +0100, Fabio Valentini wrote: Also, given that it is now apparently considered "allowed" to enable unfiltered flathub with the "Enable third-party repositories" switch, I wonder if that reasoning also applies to the equivalent situation for RPMFusion repos?

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Tue, Jan 10 2023 at 03:19:10 PM -0800, Kevin Fenzi wrote: Is there something wrong with that approach that I am not understanding? No, I don't think you're missing anything. That should work fine for PackageKit. But of course it won't do a thing to help with for other services that are

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Tue, Jan 10 2023 at 01:12:35 AM +0100, Kevin Kofler via devel wrote: For speed: https://valgrind.org/info/tools.html#cachegrind or https://valgrind.org/info/tools.html#callgrind with (in both cases) https://apps.kde.org/kcachegrind/ For memory (RAM) usage:

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

On Mon, Jan 9 2023 at 06:54:09 PM +0100, Florian Weimer wrote: No one spoke out when the tools team was called untrustworthy on the FESCo ticket. That was one of my comments. [1] I should have worded that more carefully, but didn't because I was very frustrated. I apologize. What I meant

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Mon, Jan 9 2023 at 11:04:11 AM +0100, Lennart Poettering wrote: That said: dumping core is potentially extremely expensive (web browsers have gigabytes of virtual memory that we might end up processing and compressing). Quite often the stuff that is slow when exiting is also the stuff that

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Fri, Jan 6 2023 at 11:06:26 AM -0600, Michael Catanzaro wrote: (a) Specific services want longer timeouts. This can already be configured via existing configuration mechanisms, so I think it's safe enough to ignore this problem. E.g. if a quick shutdown will brick your Pinephone modem

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Fri, Jan 6 2023 at 09:47:29 AM -0500, Matthias Clasen wrote: On my Silverblue system, the main offender for this is podman. As soon as I have a toolbox running, conmon holds up the reboot for a very long time because it refuses to shutdown properly. Maybe instead of SIGKILL, we should

Re: TeXLive 2022 landing in rawhide today

On Wed, Jan 4 2023 at 11:46:26 PM -0500, Tom Callaway wrote: Despite the size, I don't think TL updates have ever gone through that process before. Not opposed to doing it though, do we need to revert those builds from rawhide? Seems excessive to use the change process for "Update component

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Wed, Jan 4 2023 at 11:10:54 PM -0500, Frank Ch. Eigler wrote: If I understood it correctly, the claim was that enabling this distro-user-penalizing option would make it back in terms of performance optimizations. Of course, but the benefit is to fix performance bugs in applications or

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Wed, Jan 4 2023 at 03:42:43 PM -0500, Frank Ch. Eigler wrote: Then perhaps the Change could have had a dead-man-switch built in: unless performance improvements due to this profiling change do not in fact appear by F39 or F40, the Change should be automatically reverted. Question is how

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Wed, Jan 4 2023 at 02:49:30 PM +0100, Vitaly Zaitsev via devel wrote: . Only a few big corporations will get benefit Please, stop saying this. It's just not true. All Fedora users will benefit from the performance improvements that we're able to make using sysprof. Right now desktop

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Fri, Dec 30 2022 at 10:42:29 AM +0100, Peter Boy wrote: But the **default* values must provide the most safe operation possible and not require any intervention from the system administrator to achieve that. I think we need to find some way for Workstation to have different defaults than

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson wrote: Could we not go for 30 seconds? Personally I think 30 seconds is way too long for desktop users. But it's a lot better than 2 minutes, so if that's what we settle on, I won't complain. libvirtd should probably take an

Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

> On 15/12/2022 13:34, Neal Gompa wrote: > > It should be fixed then. Please report this issue to dnf component. Using weak deps was our original plan, but problem is it broke due to https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect and we surely do not want to revert that.

Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

> On Thu, 2022-12-15 at 00:11 +0000, Michael Catanzaro via devel wrote: > > Well, except that we ship Firefox in the default OS image and to make > that play video, overlaying openh264 is *exactly* what's needed. Ah, drat... well there's not a lot of great options, then. We ca

Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

> One solution to reduce the time taken by client side layering and those > issues mentioned > above is to move the package overrides back to the server side by using a > layering > approach similar to the one used to build containers. This is the goal of > this change: >

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

> Anyway, the effort that > went into that change proposal has established new expectations for any > change that will > impact system performance: the new flags should be benchmarked in an > environment where all > Fedora packages have been rebuilt with the new flags, so we can critique the >

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

No. He probably doesn't even know about this proposal yet, since it was just published yesterday. This is not the sort of thing that matters for desktop performance, where we care about orders of magnitude rather than a few percent improvement here or there. Even if extra bounds checking makes

Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)

Red Hat's desktop performance engineer has repeatedly rejected use of DWARF as impractical and outlandish, including on this mailing list [1] and most recently at [2]. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UV65DSMPINEE6KWNI5MBH3MBQ26JHNNJ/ [2]

Re: webkit2gtk5.0 -> webkitgtk6.0

On Sat, Nov 12 2022 at 01:50:28 PM +0100, Vitaly Zaitsev via devel wrote: Thanks for the information. Switched to webkit2gtk4.1: https://github.com/rpmfusion/telegram-desktop/commit/f7faaf463172ee60e04598bd681957ae98be082f OK, thanks, that should be good. For now, this API change will only

Re: webkit2gtk5.0 -> webkitgtk6.0

On Fri, Nov 11 2022 at 09:49:29 PM +0100, Vitaly Zaitsev via devel wrote: What about webkit2gtk4.0? Telegram Desktop can use 4.0, 4.1 and 5.0. Maybe it will be better to switch to webkit2gtk4.x? Better to use -4.1. That is stable and should be safe to depend on. The -4.0 is the obsolete

Re: webkit2gtk5.0 -> webkitgtk6.0

On Fri, Nov 11 2022 at 10:02:39 PM +0100, Fabio Valentini wrote: Have you considered bumping to 5.1, 5.2, 5.3 ... for the continuously expected ABI / soname bumps? Jumping by a major version number every time kind of pollutes the namespace upwards unnecessarily, doesn't it? Hi, there are no

Re: webkit2gtk5.0 -> webkitgtk6.0

OK, I think telegram-desktop will actually be fine with no changes. When webkit2gtk-5.0 disappears, it should just fall back to using the stable GTK 3 version instead of the unstable GTK 4 version, which is probably a good idea for now. If you really want to use the GTK 4 API before it's

Re: webkit2gtk5.0 -> webkitgtk6.0

On Fri, Nov 11 2022 at 05:10:03 PM +0100, Vitaly Zaitsev via devel wrote: What about packages that use dlopen() like Telegram Desktop? Uh-oh, I didn't know about this... I did a repoquery and thought only GNOME was using it. :/ I guess this will require more coordination after all. I found

webkit2gtk5.0 -> webkitgtk6.0

Hi, The webkit2gtk5.0 package in rawhide will be removed and replaced by webkitgtk6.0. Affected packages that will need to be patched to use the new API version and rebuilt are: evolution-data-server, gnome-builder, gnome-initial-setup. My plan is to handle all of these builds in a side

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel wrote: According to tests, this will slow down your system to 2.5%+, which is unacceptable for a general purpose distribution. Of course, without the frame pointers, profiling software is impossible and performance engineers

Update on libsoup 3 migration

Hi developers, An update on the libsoup 3 migration change proposal. I had previously proposed: https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_Two This proposal was rejected by FESCo, and I've decided not to put forth any alternate proposal. Accordingly, we're done with downstream

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

On Thu, Sep 29 2022 at 09:41:07 AM -0400, Demi Marie Obenour wrote: Could OpenH264 be hooked up to hardware acceleration somehow? A very interesting possibility. ;) It would certainly be nice to see OpenH264 get more development attention, to improve quality and implement new features like

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

On Thu, Sep 29 2022 at 08:12:10 AM -, James bond wrote: I mean, what's next? - Remove all torrent software, because it can be used to download... Juridiction=IANAL, Possibility - Use LibreKernel because... Juridiction = IANAL, Possibility - ... The difference is Fedora Legal is OK with

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

On Wed, Sep 28 2022 at 06:49:42 AM +, Tommy Nguyen wrote: With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice

Re: WebKitGTK package naming

Note I'm following the pkg-config version, *not* the soname. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: WebKitGTK package naming

OK, thanks for the heads-up. I didn't notice this because I was looking at the GNOME build rules, where evolution-data-server does not yet depend on it. We'll need to coordinate with you to ensure the 2.38 -> 2.40 update goes smoothly, then. I don't expect this to be difficult: it should be

Re: WebKitGTK package naming

On Tue, Sep 20 2022 at 08:24:32 AM -0500, Michael Catanzaro wrote: Being different than other distros is most confusing of all! BTW part of the confusion here might be that you're used to the Fedora package name, webkit2gtk3. But all other distros just called it webkit2gtk. I want to avoid

Re: WebKitGTK package naming

On Thu, Sep 15 2022 at 08:49:39 AM -0500, Michael Catanzaro wrote: I had a pet idea to change the API version to -4.5, so that we could sync up with GTK 5 with -5.0, but this didn't seem popular upstream. So now I'm toying with changing to -5.1 or -6.0 just to avoid confusion caused

Re: Donate 1 minute of your time to test upgrades from F36 to F37

On Mon, Sep 19 2022 at 04:29:22 PM +0200, Kalev Lember wrote: I would guess it happened because the F36 webkitgtk version number was ahead of the F37 webkitgtk version, so the versioned obsoletes that the F37 webkitgtk packages have didn't match. Oh, OK then. Good catch!

Re: Donate 1 minute of your time to test upgrades from F36 to F37

I see a similar report here: https://bugzilla.redhat.com/show_bug.cgi?id=2127841 which reveals a packaging bug. But that one is slightly different because there is an additional conflict with webkit2gtk5.0 as well, which is a bug (only one of the F37 packages should provide the file

Re: Donate 1 minute of your time to test upgrades from F36 to F37

On Mon, Sep 19 2022 at 12:08:10 AM +0200, Robert-André Mauchin wrote: Error: Transaction test error: file /usr/bin/WebKitWebDriver from install of webkit2gtk4.1-2.37.91-1.fc37.x86_64 conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64 This problem would go away if

Re: WebKitGTK package naming

Thing is, it's confusing for every distro to use different names for the same thing, like we did for webkit2gtk-4.0. But we seem to have all standardized on using the pkg-config version for the package name now. Consistency with other distros is worth a lot. On Thu, Sep 15 2022 at 03:33:12 PM

Re: Inactive packagers to be removed after the F37 release

TLS client certificates is actually not a terrible idea. They're not very popular anymore, but they're supported by all major browsers (I think?) and they work. On Wed, Sep 14 2022 at 02:08:32 PM +0200, Vitaly Zaitsev via devel wrote: On 14/09/2022 10:01, Demi Marie Obenour wrote: Still,

Re: Inactive packagers to be removed after the F37 release

On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen wrote: I'm not entirely convinced. See this paper: https://eprint.iacr.org/2020/1298.pdf I only read the abstract of this paper, but looks like the researchers have found that FIDO is indeed unphishable. Seems their attack relies on

Re: WebKitGTK package naming

On Mon, Sep 12 2022 at 08:34:46 AM -0500, Michael Catanzaro wrote: Debian hasn't packaged -5.0 yet Actually I was only looking in unstable, but in experimental they do have it: libwebkit2gtk-5.0-0 ___ devel mailing list -- devel

Re: WebKitGTK package naming

I fear there's no non-confusing way to name these packages. The theory behind the current naming was to stick as close as possible to the upstream pkg-config versions, which are: webkit2gtk-4.0 (GTK 3, libsoup 2) webkit2gtk-4.1 (GTK 3, libsoup 3) webkitgtk-5.0 (GTK 4, libsoup 3)

Re: Inactive packagers to be removed after the F37 release

On Tue, Sep 6 2022 at 10:53:03 PM -0500, Maxwell G wrote: I have 2FA set up on my account and it works okay. You'd use `fkinit` instead of `kinit` that requires special setup[1] to work with 2FA. It doesn't work with the GOA kerberos integration. When authenticating with Fedora online

Re: Inactive packagers to be removed after the F37 release

On Tue, Sep 6 2022 at 10:11:54 AM -0700, Adam Williamson wrote: i.e. it was specifically about moving away from allowing "simple TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which Vitaly's points are I believe accurate. Yes indeed. That said, I *think* it could be done

Re: Inactive packagers to be removed after the F37 release

On Sun, Sep 4 2022 at 04:48:10 PM +, Gary Buhrmaster wrote: However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*). You don't have to be a provenpackager to

Re: Why install rsyslog by default?

On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa wrote: We should remove rsyslog from @standard. Packages in @standard but not in @workstation-product: at crontabs dbus ed (no, really) fprintd-pam irqbalance rsyslog smartmontools util-linux-user Seems like if we remove a few things from

Re: Why install rsyslog by default?

On Thu, Aug 25 2022 at 04:02:25 PM +0100, Barry Scott wrote: I just found that rsyslog is installed and by default Depends on what install media you use. It's part of the @standard comps group. Workstation does not use @standard for exactly this reason: it has extra stuff like this that's

Re: Let's enable Koschei for all packages automatically

On Thu, Aug 25 2022 at 09:53:49 AM +0200, Miro Hrončok wrote: during our Nest FESCo session, we've talked about enabling Koschei [1] for all packages automatically. Yay, this should have been done long ago. ;) ___ devel mailing list --

Re: Security Problem with "PackageKit-command-not-found" package

On Thu, Aug 25 2022 at 11:20:46 AM -, Sandipan Roy wrote: By this vulnerability any wheel user can install any packages without root access or sudo. Hi, this is actually by design and not a vulnerability. The wheel user is definitionally an administrator user, and can escalate from wheel

Re: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

On Tue, Aug 23 2022 at 11:46:26 PM +0200, Fabio Valentini wrote: - elementary-mail: https://github.com/elementary/mail/issues/793 broken because it uses webkit2gtk-4.0, but also evolution-data-server, which has moved to libsoup3 fails to build / install on Fedora 37+ If this one does not

Re: Is system upgrade automatic or not?

On Mon, Aug 15 2022 at 03:37:45 PM +0200, Vít Ondruch wrote: Yes, that is fine. But at the same time, there is no warning like "Your system won't be provided with updates anymore, because it is EOL" followed up with "While there is new version available, your system is too old to be upgraded,

Re: CC0 reclassified as "not allowed" for code (reposted from legal list)

On Sat, Aug 6 2022 at 09:20:14 PM +0200, Kevin Kofler via devel wrote: PS: Especially now that Fedora ships a stripped FFmpeg, there is really no good reason to not do the stripping of encumbered parts of the AAC spec on the LGPL-licensed built-in FFmpeg AAC codec instead. That would also

Re: [rawhide] ICU upgrade to 71.1

WebKitGTK builds have been unreliable for the past few weeks. There is an infrastructure ticket for this here: https://pagure.io/releng/issue/10909 I think processing debuginfo requires somewhere between 12-13 GB of RAM, so the s390x builders are likely right on the threshold where it will

Re: Important changes to software license information in Fedora packages (SPDX and more!)

On Mon, Aug 1 2022 at 12:46:08 PM +0100, Daniel P. Berrangé wrote: I'm not saying a human would literally open each file manually. Tools like 'licensecheck' can automate scanning and reporting from license headers. Packagers should sanity check its output and examine any cases where it

Re: Important changes to software license information in Fedora packages (SPDX and more!)

On Fri, Jul 29 2022 at 11:19:48 AM -0400, Matthew Miller wrote: Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other —

Re: Comaintainer(s) wanted for qt5-qtwebengine

On Wed, Jul 20 2022 at 09:00:28 PM +0200, Kevin Kofler via devel wrote: (The fact that these fixes are not included in the betas, but only dropped into the stable release, also makes the beta testing quite pointless and compromises the stability of the stable releases.) A little feedback

Re: Comaintainer(s) wanted for qt5-qtwebengine

On Wed, Jul 20 2022 at 04:29:40 PM +0200, Kevin Kofler via devel wrote: That is not a reasonable solution. Those applications need embedded HTML in the UI, not a separate browser window. And it does not help at all if the browser that is shelled out to itself uses QtWebEngine. I presume it

Re: Heads-up: nautilus in rawhide is using gtk4 (extensions need porting)

On Wed, Jul 20 2022 at 11:51:49 AM +0200, Fabio Valentini wrote: Do the gnome-terminal / gnome-console plugins for nautilus already support gtk4? I'd rather not have to live without those. Both these applications are still GTK 3. There is a merge request for Console here:

<    1   2   3   4   5   6   7   8   9   10   >