Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Tue, 2025-04-29 at 19:08 +0200, Adam Williamson wrote: > I don't know why we didn't catch this in pre-testing; Hi, no problem, good the change in behavior was discovered. It's not a bad thing per se, but it's also true the gnome-software can prepare updates in the background, at least d

Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Mon, 2025-04-14 at 10:02 +0200, Milan Crha wrote: > I'll wait for two weeks and unless some strong objection is arose here > I'll do the switch to the dnf5 plugin in rawhide, for the Fedora 43. Hi, I just made an update for the rawhide [1] to do the switch, the gnome

Re: Fedora on Raspberry Pi

On Sat, 2025-04-19 at 18:38 +0200, Peter Robinson wrote: > You don't say which image you use, an image like XFCE would be more > suited to a device with 2Gb of RAM than say Workstation. Hi, you are right, it was the Workstation (the rpi 5 did not get to the gdm either). The Raspberry OS u

Re: Fedora on Raspberry Pi

On Wed, 2025-04-16 at 14:50 +0200, Stephen Smoogen wrote: > They do a lot of special work in everything from kernel patches, > kernel tuning, and compile time flags for many applications. Hi, I see, that makes sense now. Thank you both for the answer. Bye, Milan -- _

Re: F42 Change Proposal: CMake drop non-standard variables (system-wide)

On Wed, 2025-04-16 at 13:58 +0200, Richard Shaw wrote: > While I agree with the general premise of this change, I don't think > it's practical for all affected packagers to browse through over 2300 > builds to look for their packages. Hi, sort the table by the Status column, it's easier to

Fedora on Raspberry Pi

Hi, just out of interest, I tried Fedora 42 Beta image on Raspberry Pi 4 with 2GB RAM and it was, well, more than sluggish. Their OS based on the Debian Bookworm was lightning fast, using the same SD card and all the hardware for both images. Then I thought Raspberry Pi 5 with 8GB RAM woul

Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Tue, 2025-04-15 at 11:28 +0200, Hans de Goede wrote: > So is this using the dnf5-daemon over dbus, or is this > directly invoking dnf5 ? Hi, it's using the D-Bus API, calling the dnf5daemon-server under the hood. Bye, Milan -- __

Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Mon, 2025-04-14 at 18:19 +0200, Neal Gompa wrote: > It definitely is. Ah, I see, you are right, the dnf4 has a history entry from the pkcon. Nice. Bye, Milan -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Mon, 2025-04-14 at 16:48 +0200, Neal Gompa wrote: > Common history was always a thing. Hi, are you sure? The `pkcon update` is not part of the `dnf4 history`, is it? I cannot imagine how that could be, but it's a long time I looked on any such thing, thus I could be wrong. Bye,

Re: Switch gnome-software to use a dnf5 plugin in rawhide

On Mon, 2025-04-14 at 16:30 +0200, Vít Ondruch wrote: > Does it mean we will finally have common history for DNF5 and G-S? Hi, yes, it means both the history and the cache will be common between the two. No more disk space wasting. Bye, Milan -- _

Re: Orphaned libsoup

On Mon, 2025-04-14 at 09:07 +0200, Dominic Hopf via devel wrote: > the list of `dnf repoquery --whatrequires=libsoup` Hi, I see I'm dull and did not include the list, even I should. Let me correct it now (see below). Bye, Milan $ dnf repoquery --whatrequires=libsoup Updati

Switch gnome-software to use a dnf5 plugin in rawhide

Hi, I'd like to switch gnome-software in rawhide to use a dnf5 plugin, to move away from its dependency on the PackageKit. This had been announced together with the dnf5 change proposal some time ago [1], but due to some missing work on the gnome-software side it had been postponed. As the

Orphaned libsoup

Hello, I realized I maintain the libsoup package, but everything else I maintain and what used to use the libsoup had been ported to libsoup3 long time ago, thus it does not make much sense to me to maintain the package I do not use, neither depend on. There are sill plenty of users of it (

Re: %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error

On Wed, 2025-03-12 at 00:11 +0100, Miro Hrončok via devel-announce wrote: > This change will land to rawhide first and later to all stable > releases as well. Hi, are you really going to intentionally break all the stable releases? I thought there is a strict policy, and a big no-no, to _n

Re: [Need help] Issue Authorizing fedpkg push in a Container.

On Tue, 2025-02-18 at 09:32 +0100, Hangbin Liu wrote: > Is there any other way to push my new code to the RPM repository? Hi, I usually run: kinit u...@fedoraproject.org before using any fedpkg command which requires the user credentials and then it works fine. I do not know whether i

Re: Intent to orphan evolution-mapi and openchange packages for f43

On Mon, 2025-02-10 at 10:36 +0100, Milan Crha wrote: > I believe it's time to retire the MAPI protocol in Fedora. I'll wait > with the orphan for one week. Hi, as announced the last week, I just orphaned evolution-mapi and openchange packages in the Fedora (I clicked the

Re: Where to fill bugs for fedora-kickstarts?

On Mon, 2025-02-10 at 18:10 +0100, David Duncan wrote: > We would be happy to assist you with building using the kiwi > descriptions for them we are using now. Hi, should the Wiki page [3] be updated then? It looks recent, it mentions `f42`. Updating the wiki, anyone can benefit, not only

Re: Intent to orphan evolution-mapi and openchange packages for f43

On Mon, 2025-02-10 at 11:58 +0100, Alexander Bokovoy wrote: > Could you please rebuild them in f43-build-side-105065 and f42-build- > side-105181? Hi, sure, I can do it. Bye, Milan -- ___ devel mailing list -- devel@lists.fedora

Re: Intent to orphan evolution-mapi and openchange packages for f43

On Mon, 2025-02-10 at 11:10 +0100, Peter Robinson wrote: > It might be better off to directly retire them rather than orphan > them if no one expresses a requirement for them. Hi, sure, I'm not against it, though when I looked into https://src.fedoraproject.org/rpms/openchange it offered m

Intent to orphan evolution-mapi and openchange packages for f43

Hello, I'd like to orphan the evolution-mapi and openchange packages for the Fedora 43. Both are for the Microsoft's MAPI protocol. The OpenChange lost its upstream many years ago. The Microsoft released the first version of an Exchange Web Services (EWS) protocol in 2007, with an intent t

Where to fill bugs for fedora-kickstarts?

Hi, I cannot find a place where to fill a bug against fedora-kickstarts. The page [1] says it's bugzilla [2], but when I try it, the bugzilla rejects me with "The component value 'spin-kickstarts' is not active.". The report I tried to fill is [3]. Bye, Milan [1] https://pa

Re: Unannounced .so version bump in gtest 1.15.2 [was Re: Fedora Linux f42 Mass Rebuild is finished]

On Thu, 2025-01-23 at 16:51 +0100, Ben Beasley wrote: > These tests finally passed after re-triggering them twice, and > the update[1] is now in Rawhide. Hi, you are right, I already rebuilt the evolution-data-server, this time successfully (with added upstream patch). Things are good for

Re: Unannounced .so version bump in gtest 1.15.2 [was Re: Fedora Linux f42 Mass Rebuild is finished]

On Wed, 2025-01-22 at 21:35 +0100, Ben Beasley wrote: > I just merged the side tag as: > > https://bodhi.fedoraproject.org/updates/FEDORA-2025-7d2ef14400 Hi, thank you for stepping in so quickly. The update is "stuck", I guess due to the rpminspect discovering some ABI changes in the abse

Re: Fedora Linux f42 Mass Rebuild is finished

On Tue, 2025-01-21 at 19:18 +0100, Samyak Jain via devel-announce wrote: > there are 1875 failed builds > that need to be addressed by the package maintainers. Hi, am I trying to rebuild my packages too early, maybe in some middle time of the merge of the rebuild tag into the rawhide? The

Re: Dealing with installation of langpacks

On Thu, 2024-12-19 at 13:30 +0100, Alexey Lunev wrote: > there is no way to install langpacks from GUI Hi, the gnome-software has a plugin to install the langpacks: https://gitlab.gnome.org/GNOME/gnome-software/-/blob/b41883c9e329342c2888ca863b5f641a477e9ea2/plugins/fedora-langpacks/gs-plu

Re: Applications with AppData and not visible in the software center

On Thu, 2024-10-17 at 09:37 +0200, Dominik 'Rathann' Mierzejewski wrote: >   org.mozilla.firefox.desktop Hi, the references the app [1], thus as long as the Firefox has its without the ".desktop" suffix... You can specify the multiple times, as the [1] claims. Bye, Mila

Re: Applications with AppData and not visible in the software center

On Thu, 2024-10-17 at 09:01 +0200, Dominik 'Rathann' Mierzejewski wrote: > we had that issue with all packaged Firefox extensions when Firefox > ID was changed to org.mozilla.firefox . Hi, I recall that. The Firefox is kinda special: the Fedora Flatpak says: org.mozilla.Firefox the RPM

Re: Applications with AppData and not visible in the software center

On Thu, 2024-10-17 at 09:04 +0200, Vít Ondruch wrote: > Where is the reviews data stored actually? Hi, it's on the ODRS server. The option gsettings get org.gnome.software review-server defaults to: https://odrs.gnome.org/1.0/reviews/api How much "editable" the data stored there

Re: Applications with AppData and not visible in the software center

On Wed, 2024-10-16 at 18:53 +0200, Vít Ondruch wrote: > Maybe changing the .desktop file is harmless and good thing after > all. Hi, if I'm not mistaken, changing the .desktop filename is not a problem, as long as all the appstream data is properly updated. Changing the in the appstream d

Re: dnf transaction with a command line?

On Mon, 2024-07-01 at 12:48 +0200, Neal Gompa wrote: > Yes, when a non command-line action occurs, it is blank. Notably, > when PackageKit or DNF Daemon are used. Hi, I guess it's PackageKit, because: ``` $ dnf5 history list ID Command line Date and time Act

Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

On Wed, 2024-06-19 at 17:38 +0200, Leigh Scott wrote: > I don't see the security issue, gnome-software does require admin > rights to install packages? Hi, gnome-software currently uses PackageKit to install packages. The PackageKit has some polkit rules when to ask for the admin password

Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

On Wed, 2024-06-19 at 14:39 +0200, Daniel P. Berrangé wrote: > the default software installation tool promoting this is a > recommended solution to users. The latter is blessing this is a > preferred feature of the distro. Hi, does there exist any other way to make the drivers work, withou

Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

On Wed, 2024-06-19 at 13:10 +0200, Daniel P. Berrangé wrote: > While the implementation is in gnome-software, since this > is semi-automating enrollment of a new SecureBoot MOK, with the > private key strored locally, it has security impact on the distro > as a whole. Hi, you are right, it

Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

On Mon, 2024-06-17 at 17:44 +0200, Leigh Scott wrote: > I wont be re-adding the AppStream metadata into the Nvidia driver > repo until someone files a proper request  at rpmfusion. Hi, here you are: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6976 If there's anything I can help with, j

Re: Figure out what killed an app (rhbz#2253099)

On Sun, 2024-02-04 at 14:03 +0200, Yanko Kaneti wrote: > The kernel killing the main evolution process which was set as having > rt priority by some webkit coincidence. Hi, there it is then. I see those: > Jan 31 10:49:22 localhost.localdomain rtkit-daemon[826]: > Successfully made th

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 13:40 -0500, Paul Grosu wrote: > 2) Or you can completely disable it: Hi, I do not want to disable the oom service. Remember, it does that on user machines, not only on mine. Telling people: "you want to use app a, b, c, then disable oom" as a new Fedora 40 feature is

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 16:24 +0100, Petr Pisar wrote: > A possible explanation is that the signals are procecessed > asychnously and evolution manages to dispatch the signal to bwrap > before kernel > termites evolution because of the first signal. Or I misinterpret the > log. Hi, there had

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 08:31 -0600, Michael Catanzaro wrote: > Maybe it could also be sent by mutter if a program > is unresponsive? Hi, the app is perfectly responsive. I click on a widget and the app is killed immediately. There is no freeze of the app. > WebKitGTK doesn't use SIGKILL t

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 13:07 +0100, Milan Crha wrote: > In such case, I might be able to catch this in gdb, right? Maybe with > a breakpoint in the `kill` function, and any other? Okay, I tried with the following (more variants, just in case): gdb evolution \ --ex &

Re: Figure out what killed an app (rhbz#2253099)

On Wed, 2024-01-31 at 12:19 +0100, Petr Pisar wrote: > This procedure works for me > . > The tracefs file system has a nice log. Hi, that works pretty well, thank you. Funny enough, if I read it correctly, it says evo

Figure out what killed an app (rhbz#2253099)

Hi, I tried to investigate a rawhide bug: https://bugzilla.redhat.com/show_bug.cgi?id=2253099 which is about Evolution being killed "by something". That's the thing, I do not know what killed it, thus even why it had been killed. It's even not killed after certain steps, it's killed "random

Re: gtk3 update breaks multiple packages

On Wed, 2024-01-24 at 12:53 +0100, Michael J Gruber wrote: > You missed reading the first NEWS entry ("* Fix a crash introduced in > the X11 changes in 3.24.40") and quoted the third only. Hi, you are right. That's quite embarrassing. I'm sorry about that. No idea how I could overlook it.

Re: gtk3 update breaks multiple packages

On Wed, 2024-01-24 at 11:34 +0100, Leigh Scott wrote: > see > https://github.com/GNOME/gtk/commit/77ebdd85091833a7869ece48c3114fa6d9966321 Hi, all the bugs you referenced crash in X11 code. The above NEWS file commit specifically says it's for Wayland. What am I missing here, please? Did

Re: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

On Tue, 2024-01-09 at 19:01 +0100, Kalev Lember wrote: > The gnome-shell update just landed in rawhide, so it needs a few > minutes before the build roots are regenerated. If you can do 'koji > wait-repo f40-build-side-80962 --build mutter-46~alpha-2.fc40' first > to make sure new mutter is availab

Re: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

On Tue, 2024-01-09 at 18:36 +0100, Kalev Lember wrote: > Looks like this has a bit of a mid air collision with gnome-shell > 46.alpha that's in a different bodhi update: > https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7b40ac758 Hi, that's a pita. Let me know if I can help with anyth

Re: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

On Mon, 2024-01-08 at 18:40 -0800, kevin wrote: > On Mon, Jan 08, 2024 at 11:05:33AM +0100, Milan Crha wrote: > >    elementary-calendar > >    evolution-chime (which is part of pidgin-chime) > >    gnome-panel > >    phosh Hi, thank you all for the p

Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

On Mon, 2024-01-08 at 10:34 +0100, Milan Crha wrote: > I'll handle those I've commit rights for, which is most of them. > > ... > >fedpkg build --target=f40-build-side-80962 Hi, the leftover packages to be done, for which I do not have commit rights, are

[heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

Hi, the 3.51.1 release of the evolution-data-server contains a soname version bump of a libecal-2.0 library, due to an API change in one function. I do not think it affects the dependencies, thus only a simple rebuild should be needed, otherwise a new parameter will be added to the call of

Re: f39-candidate ~> f39-build stuck or something?

On Fri, 2024-01-05 at 15:15 +0100, Kalev Lember wrote: > So my suggestion would be to use a self service side tag for rawhide > as well, not just F39. Hi, thanks for the confirmation. It means more manual work to be done (and not be forgotten), but I see it has also its advantages. I'll do

Re: CMake's check-compiles fails to parse WITH_GZFILEOP

On Fri, 2024-01-05 at 12:50 +0100, Ian McInerney via devel wrote: > An interesting thing to note about that is that it is using ;-list > formatting in CMake for this call, but according to the docs for > CheckCSourceCompiles, these CMAKE_REQUIRED_<> variables should have > the values space-separate

f39-candidate ~> f39-build stuck or something?

Hi again, with the problem on the rawhide, I managed to build evolution-data- server update for F39 with no problem, but the chain-build [1] to wait for the f39-build refresh/update to have the new eds. It waited for 2 hours, which is quite a lot of time. For what it's worth: $ koji wait-

Re: CMake's check-compiles fails to parse WITH_GZFILEOP

Hi, On Fri, 2024-01-05 at 10:35 +0100, Honza Horak wrote: > Not sure whether it's a regression in zlib-ng or something to be > changed in evolution-data-server though Neither do I. The eds check uses information from pkg-config output for gio-2.0 gmodule-2.0 libxml-2.0 and libsoup-3.0. It

CMake's check-compiles fails to parse WITH_GZFILEOP

Hi, this is new to me. I'm trying to build evolution-data-server in a side tag for rawhide and the build [1] fails in the CMake phase with error: -- Performing Test HAVE_GPOWERPROFILEMONITOR CMake Error: Parse error in command line argument: WITH_GZFILEOP Should be: VAR:type=valu

Re: Update on the Modern C initiative

On Mon, 2023-12-04 at 09:01 +0100, Florian Weimer wrote: > No, that's actually not changing, this is already an error and will > remain an error. Hi, right, the "check-compile" test is supposed to fail, thus it's fine. > Only the -Wincompatible-pointer-types warning above is > upgraded to

Re: Update on the Modern C initiative

On Sat, 2023-12-02 at 17:33 +0100, Florian Weimer wrote: > > Specifically, one "configure" (there is used CMake) check tries to > > figure out whether gethostbyname_r() has five arguments. It does > > not in > > Fedora, thus a) there are passed no enough arguments to the > > function; > > b) there

Re: Update on the Modern C initiative

On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote: > Again, some of these are false positives.  Hi, I think the errors from the configure time of the script are not always problems, are they? At least in the case of the evolution-data-server, it's half a problem and half expected. S

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

On Tue, 2023-11-07 at 12:43 -0500, Neal Gompa wrote: > It works because 1.0.0~ < 1.0.0. Hmm, odd. Anyway, a rebuild of flatpak is needed (I do not have commit rights for it). Thanks and bye, Milan ___ devel mailing list -- devel@lists.f

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

On Tue, 2023-11-07 at 12:37 -0500, Neal Gompa wrote: > Yes. So your %appstream_version macro should have "1.0.0~". That would break the: > >BuildRequires: pkgconfig(appstream) >= %{appstream_version} because appstream-devel Provides: pkgconfig(appstream) = 1.0.0 no? I know, I can try i

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

On Tue, 2023-11-07 at 10:58 -0500, Neal Gompa wrote: > It needs to be "appstream%{?_isa} >= 1.0.0~". Hi, I'm sorry, I do not follow. Do you mean "1.0.0" is higher than "1.0.0~git20231102.d88ed03-1.fc40", but lower than "1.0.0-2.fc40"? That sounds odd to me. Both flatpak and gnome-software

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

On Tue, 2023-11-07 at 12:12 +0100, Kalev Lember wrote: > Can you do 'koji wait-repo f40-build-side-76936 --build > appstream0.16-0.16.3-2.fc40' and try building gnome-software again > once it says that the package is available in the repo? Hi, it changed the problem to: DEBUG util.py:446:

Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)

On Mon, 2023-11-06 at 22:33 -0500, Neal Gompa wrote: > * Flatpak has an upstream change that needs backporting[1] or a new > release. > * GNOME Software has a merge request open[2]. > * libadwaita has an upstream change that needs backporting[3]. > * malcontent needs work done. Hi, I'm sor

Re: Disabling rawhide builds during branching

On Tue, 2023-08-08 at 00:08 -0700, Adam Williamson wrote: > I'm not sure what's causing that, but it doesn't look good. Hi, would it be possible to somehow detect the "More Information" button on the screen and click it before calling the test failed, which will open a dialog with an error

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

Hi, On Wed, 2023-05-17 at 12:23 -0400, Owen Taylor wrote: > You use it in to fix bus names in flatpak-evolution-wrapper.sh - > those could just be hardcoded since the bus name will be always the > same for the Evolution Flatpak It will work unless the version of the D-Bus service is bumpe

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

On Wed, 2023-05-10 at 09:30 -0400, Owen Taylor wrote: > Does that sound workable? Are there better ways we could do it? Hi, if I recall correctly, using the custom D-Bus prefix is there to match application's D-Bus prefix defined for the flatpak, thus: a) the services run independently fro

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote: > Additionally a couple of packages (evolution-data-services and > tracker-miners) are set up so they can be > built with an application-specific D-Bus prefix. Evolution has: > >   buildopts: >     rpms: >   macros: | >     %_eds_dbus

Re: How to migrate database format during package update?

On Wed, 2023-02-01 at 10:12 -0800, Kevin Fenzi wrote: > Is there any way to pull the functionaly into the process itself? > ie, the first time it's called, it converts the db? Hi, the idea is to not depend on the libdb at all, neither in the build time. I reworked the proposed change to c

Re: How to migrate database format during package update?

On Wed, 2023-02-01 at 14:15 +0100, Alexander Sosedkin wrote: > cyrus-sasl ships a migration tool for some transition period > and suggests the user to manually invoke it: Hi, aha, I see, that's much saner idea than what I came up with. I'll try to cook something similar, making the libdb(

How to migrate database format during package update?

Hi, this is a query for an opinion and a best-practice experience for a case when a package needs to change its internal database format between versions, in an environment, which does not allow real migration, aka the app cannot read both formats, it can use one or the other. To be specif

Re: updating cmark to 0.30

On Tue, 2023-01-17 at 13:55 +0800, Jens-Ulrik Petersen wrote: > So I plan to go ahead with this rebase and rebuilding these packages > after the mass rebuild if that's okay. Hi, does the new version change any API and/or soname version? > We can consider whether to backport to F37 and pos

Orphaned gtkhtml3

Hi there, I just orphaned gtkhtml3 [1]. It used to be used by Evolution many years ago. It's unmaintained and archived upstream since Evolution moved to the WebKitGTK. The only user of it is xiphos, whose maintainer I added to the CC. They can take it, if they want to. Bye,

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

Hi, On Mon, 2022-10-31 at 11:46 +0100, Jonathan Wakely wrote: > Never ever do that. The __USE_xxx macros are internal, for glibc to > use. You should not ever check them or define them. right, right, it was only a hackish dirty quick attempt to make it compile. I won't do it, if I knew th

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

On Wed, 2022-10-26 at 13:59 +0100, Daniel P. Berrangé wrote: > Note that in an earlier message in this thread replying to my > question, Florian pointed out that using -std is not actually > the way to test this. Hi, I see. I did read several messages in this thread, but definitely not all

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

On Wed, 2022-10-26 at 14:18 +0200, Milan Crha wrote: > when I compile it as: > >    gcc -std=c99 -Wall -Wextra test.c -o test -ldb > > I get an error: > >    In file included from test.c:1: >    /usr/include/db.h:1098:9: error: unknown type name ‘u_int’ > > and

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

On Wed, 2022-10-26 at 11:09 +0200, Florian Weimer wrote: > There will be a few generic issues in build tools that when address > fix multiple packages Hi, I've been interested in a check of a project I maintain and I stopped very soon on Fedora 37 with gcc-12.2.1-2.fc37.x86_64 glibc-2.36-

Koji issue: tagBuild failed: OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'

Hi, I searched for tagBuild mails here and one was from January, but it's a) a long time ago; b) about something else. This build: https://koji.fedoraproject.org/koji/taskinfo?taskID=93236447 from today failed with: OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/6716'

Re: WebKitGTK package naming

Hi, On Tue, 2022-09-20 at 08:24 -0500, Michael Catanzaro wrote: >  For now it's required by Builder and gnome-initial-setup ... and evolution-data-server, according to: dnf repoquery --alldeps --whatrequires "webkit2gtk5.0" and dnf repoquery --alldeps --whatrequires "pkgconfig(we

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

On Thu, 2022-09-08 at 08:39 -0400, Nico Kadel-Garcia wrote: > installing parallel versions of the same development tools Hi, Jaroslav said they are not the same, hence I asked. Bye, Milan ___ devel mailing list -- devel@lists.fedo

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

On Thu, 2022-09-08 at 12:20 +0200, Jaroslav Mracek wrote: > DNF5 is completely a different component. It does not depend like > microdnf on Python. DNF plugins are not compatible with DNF5. There > will be changes in commands, options, outputs and so on therefore > selling it as an update will be q

Re: Is system upgrade automatic or not?

On Mon, 2022-08-15 at 10:20 +0200, Vít Ondruch wrote: > I don't think that Fedora should allow to keep the system outdated > and without updates. Hi, Fedora is not a rolling distro. Najor version updates often change behaviour of the apps or the system itself, not talking that there are gi

Re: Heads-up: evolution-data-server soname bumps

> "error: The name `soup_uri' does not exist in the context of > `E.SourceWebdav' (libedataserver-1.2)" > Is this an expected API change, and if so, do I need to poke upstream > to help me port it to the latest e-d-s version? Hi, yes, it's expected, the SoupURI structure is gone in libsoup3, t

Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)

On Thu, 2022-05-26 at 14:37 -0500, Michael Catanzaro wrote: > Still, hopefully we can manage this transition without applications > winding up broken in stable Fedoras. Hi, for what it's worth, I have a COPR repo for Fedora 36, which includes several packages to use/build with/... libsoup

How to find out whether a package is used

Hi, is there a way to figure out whether a package is used by any user? I know with mirrors it's basically impossible to know whether it had been downloaded at all, but I do not know whether there can be involved other techniques to figure it out, batter than dropping a package and wait whe

Re: F36 Final blocker status summary

On Fri, 2022-03-25 at 16:06 -0400, Ben Cotton wrote: > 2. gtk4 — https://bugzilla.redhat.com/show_bug.cgi?id=2043335 — > VERIFIED > gtk_widget_measure: assertion 'for_size >= -1' failed > > Searching for applications in Software resulted in a hang. Fixed in > gnome-software-42~beta-2.fc36.

Re: Icon issues in a number of applications - f36 and rawhide

On Sun, 2022-03-13 at 11:30 -0500, Michael Catanzaro wrote: > Recommendation: Third-party applications should limit themselves to > depending on standard icon names listed at > https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html >   > only. Hi, for what i

Re: CVE-2021-4034: why is pkexec still a thing?

On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote: > There are still over a dozen packages in the distro that > require it: Hi, the gnome-software also calls pkexec is some occasions, once when external appstream data is used (not a thing in Fedora, as far as I know) and when invoki

Re: [heads-up] evolution-data-server soname version bump in rawhide

On Fri, 2021-08-13 at 12:52 +0200, Björn 'besser82' Esser wrote: > Both builds are finished already.  [1,2] Hi, thanks, I created updates in bodhi for both of them (f35/rawhide). Bye, Milan ___ devel mailing list -- devel@lists.fe

Re: [heads-up] evolution-data-server soname version bump in rawhide

On Thu, 2021-08-05 at 16:05 +0200, Björn 'besser82' Esser wrote: > Just give me short heads up, and I'll rebuild pidgin-chime using my > proven-packager powers. Hi, thanks for the offer. There are two side tags, due to the f35 branching: f35-build-side-44568 f36-build-side-44566 Both evo

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote: > at least in the meantime, do you want to take it now that it's > building again? Hi, I took it for the time being, thus the package does not vanish from Fedora. I'll pass the ownership to the original owners once they let me know

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

On Thu, 2021-08-05 at 09:41 -0700, Adam Williamson wrote: > I don't think autoconf-archive is usually actually used in builds, the > package sources generally contain the macros. Hi, that's why I mentioned the libpst runs autoreconf [1]. I can be wrong though, I thought the autoreconf upda

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote: > The former owner appears to also be the upstream, so they might be > back, but at least in the meantime, do you want to take it now that > it's building again? Hi, I'm not sure I'm the best person, I do not follow the development

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

On Thu, 2021-08-05 at 14:00 +0200, Miro Hrončok wrote: > libpst Hi, I do not own the package, only one from my pool depends on it, but looking into the build failure, the autoconf failed to find python binary. Digging deeper, in the autoconf-archive-2021.02.19-2.fc35, the ax_python.m4 stil

[heads-up] evolution-data-server soname version bump in rawhide

Hi, the upcoming 3.41.2 release of the evolution-data-server next week will contain a soname version bump of a libcamel library due to ABI changes. A simple rebuild should be enough for the other packages. According to `dnf repoquery --whatrequires libcamel-1.2.so* --alldeps` there are the

Re: F35 mass rebuild is finished

On Fri, 2021-07-30 at 09:50 -0400, Neal Gompa wrote: > As the %_vpath_builddir macro is what you're supposed to use _anyway_ > when monkeying around with build directories with CMake and Meson... Hi, that fixed it. Thanks for the hint. I did not find it myself, possibly due to using a wron

Re: F35 mass rebuild is finished

On Tue, 2021-07-27 at 16:23 +0200, Tomas Hrcka wrote: > The mass rebuild was done in a side tag (f35-rebuild) and moved over to > f35. > > Failures can be seen > https://kojipkgs.fedoraproject.org/mass-rebuild/f35-failures.html > > Things still needing rebuilding > https://kojipkgs.fedoraproject.

Re: [heads-up] soname version bump for evolution-data-server in rawhide

On Wed, 2021-02-10 at 17:57 +0100, Milan Crha wrote: > I'll update this thread once I've the side tags ready, > with compiled evolution-data-server. Hi, the side tags are named f35-gnome and f34-gnome and the evolution-data-server and evolution are already built in them

Re: [heads-up] soname version bump for evolution-data-server in rawhide

On Wed, 2021-02-10 at 17:48 +0100, Fabio Valentini wrote: > Yes, you'll need two side tags and build everything twice. f34 and > f35/rawhide are separate now. > I can also use my provenpackager powers to help you with that, if > needed. Hi, okay, thanks a lot. I'll let you know if I face a

Re: [heads-up] soname version bump for evolution-data-server in rawhide

On Wed, 2021-02-10 at 15:53 +0100, Fabio Valentini wrote: > On Wed, Feb 10, 2021 at 3:32 PM Milan Crha wrote: > > I'll create the side tag on Friday, ... Hi, this might be a stupid question, but I'll ask anyway: since there are f34 branches created already, should I c

Re: [heads-up] soname version bump for evolution-data-server in rawhide

On Wed, 2021-02-10 at 15:53 +0100, Fabio Valentini wrote: > I'll build elementary-calendar + wingpanel-indicator-datetime once > the side tag is ready, if you want. Hi, it'll help, yes. Thanks. > Do you expect any of the listed packages to break because of the > aforementioned API changes

[heads-up] soname version bump for evolution-data-server in rawhide

Hello, the upcoming 3.39.2 release of the evolution-data-server contains a soname version bump for its libedataserver-1.2 and libedataserverui-1.2 libraries due to API and ABI changes. The release is planned for this Friday. I'll build as many packages as I have commit rights to in a side t

Re: Fedora 34 Mass Rebuild

On Mon, 2021-02-08 at 23:17 +0100, Jonathan Wakely wrote: > No, it's simply that glib2 was changed a few days ago, after the mass > rebuild. The syncevolution sources didn't change, but some of the > headers it depends on did change. Hi, you are right, it was just a good timing thing.

  1   2   3   >