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

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

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

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

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

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

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

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

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: elem

[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

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

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

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.

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:

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

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.

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 --

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

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

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

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

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

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

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

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: | >    

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

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

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

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

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

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

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

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

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 --

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

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

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,

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/...

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

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

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

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 --

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

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

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

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

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

[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

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

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 >

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. I have o

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

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 create two

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

[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

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.

Re: Fedora 34 Mass Rebuild

On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote: > Fedora 34 mass rebuild of rpms is done Hi, I just noticed that syncevolution built just fine on the January 30th, but it is failing to build right now, using the same sources as releng. I opened [1] for it. It kind of scares me, I

Re: mesa 21.0.0-rc3 making rawhide really unstable?

On Fri, 2021-02-05 at 16:17 +1000, David Airlie wrote: > Has anyone got a backtrace they could put in a bug? I'm not seeing a > crash with X.org here in my test VMs. Hi, I do not see any crash as such, Xorg simply fails to start with: Fatal server error: [32.661] (EE) no screens

Re: mesa 21.0.0-rc3 making rawhide really unstable?

On Wed, 2021-02-03 at 15:26 +1000, David Airlie wrote: > Please test: > > mesa-21.0.0~rc3-2.fc34 > > which I just built for rawhide. Hi, for what it's worth, it helped me with gdm, it opens now, but I cannot log in to "GNOME on Xorg", I'm immediately returned back to the gdm. Logging to

Re: Thunderbird with mail.corp.redhat.com does not work on Fedora 33

On Thu, 2020-10-01 at 15:28 +0800, Harish Pillay wrote: > Same thing applies to mutt. I've filed this bz: >    https://bugzilla.redhat.com/show_bug.cgi?id=1883976 Hi, every application which uses library which complies to system crypto policies is "affected". For more information:

evolution-ews license change

Hello, the upstream license for evolution-ews had been LGPL-2.1-or-later, but the sources didn't reflect it properly, thus it had been corrected upstream. The distgit in Fedora will correct the version as well, from LGPLv2 to LGPLv2+, together with the 3.37.90 release. Bye,

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

On Tue, 2020-07-07 at 13:12 +0200, Fabio Valentini wrote: > If you need help with building other packages, feel free to ping me. Hi, thanks. I'm currently working on a patch for syncevolution and I started a build of ekiga few minutes ago. According to: $ repoquery --whatrequires

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

On Tue, 2020-07-07 at 09:05 +0200, Milan Crha wrote: > Right, I saw that too and didn't understand why that single test > fails. When I built folks locally it passed with no problem, using > the same evolution-data-server. I'd surely rebuild the three I have > commits right for if the

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

On Sat, 2020-07-04 at 15:27 -0700, Kevin Fenzi wrote: > On Sat, Jul 04, 2020 at 09:48:04AM -0700, Kevin Fenzi wrote: > > On Sat, Jul 04, 2020 at 06:37:09PM +0200, Fabio Valentini wrote: > > > I don't understand the rush. Hi, there had been some major issues with the previous release,

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

Hello, I'm sorry for a late notice, the 3.37.3 release (will be done today) of the evolution-data-server has a soname version bump on the libedataserver library. It has a change on an EWebDAVSession API, which I do not think is used by many components, if any other than evolution itself at

Re: Fedora 33 System-Wide Change proposal: swap on zram

On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote: > ... The memory used is not preallocated. It's > dynamically allocated and deallocated, on demand. ... > > The system will use RAM normally up until it's full, and then start > paging out to swap-on-zram, same as a conventional

Re: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

On Sat, 2020-05-02 at 10:19 -0700, Kevin Fenzi wrote: > > As-is, everyone is blocking on waiting for the new gcc build to > complete > > (that koji estimates is another ~6 hours away). > > > > Personally, this morning was my primary chance to get a significant > amount > > of work done for the

Re: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support

On Wed, 2020-04-08 at 21:18 +0200, Dominic Hopf via devel wrote: > ``` > %if 0%{?rhel} > BuildRequires: webkitgtk4-devel > %else > BuildRequires: webkit2gtk3-devel > %endif > ``` Hi, this is an off topic for this thread, but maybe you'll find it useful. You can use this (pick the one,

Re: Unannounced soname bump with samba 4.12~rc1

On Sun, 2020-01-26 at 00:12 +0100, Fabio Valentini wrote: > - evolution-mapi > - openchange(-client) Hi, the above two are rebuilt too. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an

Re: Ideas for better development processes when maintaining hundreds of packages

On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Hi, the answer for the above is just your following point: > * commit groups of packages together aka the dependencies.

Re: Git Forge Requirements: Please see the Community Blog

On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote: > they all picked GitLab CE. Hi, I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly.

Re: [HEADS UP] Unannounced soname bump of qrencode

Hi, On Wed, 2019-06-26 at 11:11 +0200, Miro Hrončok wrote: > $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort > > rpm-specs/evolution.spec that's a false positive, the only occurrence of ".so*" in that file is in the %changelog section, namely: * Tue May 17 2011 x -

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

Hello, next week's 3.33.2 release of evolution-data-server, on 2019-05-20, will contain soname version bumps in libecal, libedata-cal, libebook and libedata-book. At least unless anything bad happens. The main change on the calendar part is that there will be used libical-glib instead of

Re: PSA: Bodhi cannot associate bugs with updates right now

On Tue, 2019-02-19 at 18:32 -0500, Randy Barlow wrote: > Bodhi 3.13.2 has been deployed to production just now, which should > address the above issue. You should again be able to associate bugs > with updates. Apologies for the issue! Hi, I've been affected of this, even I didn't know

Re: [HEADS UP] Meson 0.48.0

On Tue, 2018-09-25 at 08:43 +0200, Igor Gnatenko wrote: > new meson release is out (release notes) which removes tools which > are deprecated for quite long time: > * mesonconf > * mesonintrospect > * mesontest > * wraptool Hi, having installed meson-0.48.1-1.fc29.noarch and trying to

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

Hello, next week's 3.31.2 release of evolution-data-server (on 2018-11-12) will contain soname version bump of libedataserver due to removal of some semi-private API (e-gdbus-templates). I expect that most of the packages can be just rebuilt, because it was never meant to be used outside

Re: Packages with compiled python files outside of /usr/lib*/python8

On Mon, 2018-06-18 at 11:19 +0200, Miro Hrončok wrote: > What Python are those files for actually? Are they imported or > executed? Hi, I do not speak pythonish, I'm sorry, but from what I recall they had been added as some sort of unit tests. I think they are meant to be executed only,

Re: Packages with compiled python files outside of /usr/lib*/python8

Hi, On Mon, 2018-06-18 at 10:46 +0200, Miro Hrončok wrote: > evolution-tests: oh, I see, I do not build/install them locally, thus I didn't notice them in my $PREFIX. I'll update the evolution package spec file. Thanks and bye, Milan

Re: Packages with compiled python files outside of /usr/lib*/python8

On Fri, 2018-06-15 at 18:38 -0500, Jason L Tibbitts III wrote: > evolutionalexl caillon caolanm mbarnes mcrha rhughes > rstrode ssp tpopela Hi, could I ask how evolution had got into the list, please? Having installed evolution-3.29.2-1.fc29.x86_64 and running: $ rpm -ql

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

Hello, next week's 3.29.3 release of evolution-data-server (on 2018-06-18) will contain soname version bumps of libcamel and libedata-cal. I expect that most of the packages can be just rebuilt. I cannot provide the complete list of affected packages, because dnf is inaccurate [1].

Re: plan to update brotli to 1.0.4 in Rawhide

On Sun, 2018-04-15 at 00:48 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 14 April 2018 at 03:30, po...@pouar.net wrote: > > golang-github-dsnet-compress > > httpd > > php-pecl-http > > python-httpbin > > webkit2gtk3 > > woff2 > > > > > > So I just announce that I'm updating the

Re: Gating packages in Rawhide

On Mon, 2018-03-12 at 17:27 +0100, Pierre-Yves Chibon wrote: > Does that sound right? Hi, yes, it does. Thanks. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Gating packages in Rawhide

Hi, On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote: > On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote: > > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote: > > > Sure, with this proposal you would: > > > > > > * requ

Re: Gating packages in Rawhide

On Mon, 2018-03-12 at 12:12 +0100, Kalev Lember wrote: > On 03/12/2018 11:33 AM, Milan Crha wrote: > > I wanted to try whether chain-build with --target would make the > > trick, it also used to work. > > It should work if you use '--target f28-gnome' Hi, yes, I kno

Re: Gating packages in Rawhide

Hi, On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote: > Sure, with this proposal you would: > > * request a side tag > * build a, wait for it to be added to the repo, build b, etc. > You would not need to file overrides, just build them in the right > order with wait-repo between

Re: Gating packages in Rawhide

On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote: > * CI/automated tests run on it, and if all is ok goes out in the next > rawhide compose. > * If not ok, you could wave the results or build more things/edit the > update until it passes. Hi, so it looks like you are going to remove

Re: Appstream metadata compose failures

On Fri, 2018-03-02 at 11:28 +0100, Kalev Lember wrote: > https://dl.fedoraproject.org/pub/alt/screenshots/f29/failed.html > > Would be awesome if maintainers could have a look and see if they can > make their packages pass! Hi, even not a maintainer, why is evolution-rss in the list,

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

Hello, the next week release (2018-02-05) of evolution-data-server, version 3.27.90, will contain a soname version bump of libcamel, libedataserver and libedataserverui. It contains some backward incompatible changes, though I expect minimal impact on other packages, because that API was

Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib

On Mon, 2017-11-13 at 10:01 -0800, Kevin Fenzi wrote: > Orage (the Xfce calendar app) is also broken if you have time to take a > look: > > https://bugzilla.redhat.com/show_bug.cgi?id=1512302 > https://bugzilla.xfce.org/show_bug.cgi?id=13997 Hi, sure, I'll reply on the Red Hat bug.

Re: [Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib

On Tue, 2017-11-14 at 01:36 +0100, Michael Schwendt wrote: > Dunno yet what's the reason. Haven't had a look at it except for unpacking > libical-devel in hope that its %doc section would contain a file that sums > up the API changes. No such file in there. And the "Using Libical" guide > claims

  1   2   >