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

[Milan Crha]

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 thread 4820 of process 4640 (/usr/bin/evolution)
>   owned by '1000' RT at priority 5.

in the journal make more sense now.

Thank you all for the help on this.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 not great ;)

Nonetheless, I though I'll give it a try and will trigger the oom, to
see what it does. I wrote a little app to allocate gigabytes of memory
(until malloc() returns NULL) and one process was not enough, thus I
ran second and then third and then I've been notified by a gnome-shell
bubble telling me "Virtual Terminal Stopped" with a reason that memory
is almost full. Looking on the terminals the second process I ran had
been killed and the `dmesg` shows a reason:

[ 1712.960372] oom-
kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0
,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/ap
p.slice/app-org.gnome.Terminal.slice/vte-spawn-7f4b1469-38d1-498f-b363-
1c8311d2fcff.scope,task=alloc-too-much,pid=3323,uid=1000

[ 1712.960389] Out of memory: Killed process 3323 (alloc-too-much)
total-vm:137300925912kB, anon-rss:128kB, file-rss:1280kB, shmem-
rss:0kB, UID:1000 pgtables:1544608kB oom_score_adj:200

The journal contains similar information, plus a lot of debugging
information from kernel, starting with:

Feb 01 08:45:47 localhost.localdomain kernel: alloc-too-much invoked
oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP),
order=0,...

The kernel tracing log for sig==9 shows:

gnome-terminal--2924[002] dN.2.  2520.462889: signal_generate:
sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0

There is no such thing (apart of the tracing log) when Evolution is
suddenly killed, the logs are muted. That makes me believe it's not the
OOM killer whom kills the application. I'm back at square 1; or maybe
square 2, as I know possibly kernel sends it, but not why.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 been more lines involving bwrap and WebKitWebProcess, if I
recall correctly (I closed the machine already and did not save the
full log, I'm sorry). The above lines were those directly involving the
evolution process. I did not want to spam the list with a too long log.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 to clean up after itself.

Evo itself doesn't use any seccomp or such, these things can be used by
the WebKitGTK. A quick grep revealed:

https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp#L258

but that code does not seem to be called at this time (or my debug code
was wrong, it's possible).


There was an update on the bug #2253099 that also liferea is affected,
thus at least evo is not alone. There is suspect that either glib2 or
kernel update caused it, but who knows.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 "b kill" \
--ex "b exit" \
--ex "b __kill" \
--ex "b _kill" \
--ex "b _exit" \
--ex "b pidfd_send_signal" \
--ex "b tkill if sig==9" \
--ex r

and it did not catch any of these. The last lines are:

   [Thread 0x7fffd92006c0 (LWP 3086) exited]
   [New process 3080]

   Program terminated with signal SIGKILL, Killed.
   The program no longer exists.
   (gdb)

which may or may not mean it is sent by a different function, I guess.
I cannot tell how much time was between the kill signal and the "[New
process 3080]" line.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 killed itself (the first three bwrap-s are
probably unrelated, it could be when I opened and closed a composer,
which let WebKitGTK create a new WebKitWebProcess; the last line might
be when WebKitGTK cleans up after itself, or all the bwraps are at last
created by the WebKitGTK):

  bwrap-3756 [002] d..2.   341.677197: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3757 grp=1 res=1
  bwrap-3753 [000] d..2.   341.677296: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3754 grp=1 res=1
  bwrap-3856 [002] d..2.   345.231590: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3857 grp=1 res=1
  evolution-3211 [003] d..1.   355.904404: signal_generate: sig=9 errno=0 
code=128 comm=evolution pid=3211 grp=1 res=0
  evolution-3211 [003] d..2.   355.904450: signal_generate: sig=9 errno=0 
code=0 comm=bwrap pid=3257 grp=1 res=0

In such case, I might be able to catch this in gdb, right? Maybe with a
breakpoint in the `kill` function, and any other? These things are very
low-level for me, I'm sorry.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Figure out what killed an app (rhbz#2253099)

[Milan Crha]

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 "randomly", on various
occasions.

I did search the internet, but they usually expect the killer is the
OOM service, which logs about the action either in the dmesg or in the
journal, but in this case there is no sign about whom killed it in
either of these logs.

The evolution terminal just says:

   Killed

and the `dmesg | grep -i kill` only shows:

   [3.435200] systemd[1]: Listening on systemd-oomd.socket - Userspace
  Out-Of-Memory (OOM) Killer Socket.
   [6.051242] rfkill: input handler disabled
   [   22.579276] rfkill: input handler enabled
   [   23.539350] rfkill: input handler disabled

and `journalctl -xb | grep -i kill` doesn't reveal anything useful. The
`journalctl -xb | grep -i evolution` has as its last line:

   Jan 31 10:49:22 localhost.localdomain rtkit-daemon[826]:
   Successfully made thread 4820 of process 4640 (/usr/bin/evolution)
   owned by '1000' RT at priority 5.

which does not explain anything. Grepping for the 4640 (evo's PID)
didn't show anything either.

That being said, is there a way to figure out what killed the app,
please?

Thanks and bye,
Milan

P.S.: the above-pasted journalctl line is followed by these three,
which look suspicious, but maybe they are unrelated. I even do not know
whether they had been added immediately after the app was killed or
before it. At least the terminal should not matter, because evo is
killed when being started from the GUI too. Three log lines follow:

Jan 31 10:49:23 localhost.localdomain xdg-desktop-por[2697]: Realtime
error: Could not map pid: Could not determine pid namespace: Could not
find instance-id in process's /.flatpak-info

Jan 31 10:50:46 localhost.localdomain gnome-terminal-[2939]: void
terminal_screen_shell_preexec(VteTerminal*): assertion
 '!priv->between_preexec_and_precmd' failed

Jan 31 10:50:49 localhost.localdomain gnome-terminal-[2939]: void
terminal_screen_shell_preexec(VteTerminal*): assertion
 '!priv->between_preexec_and_precmd' failed
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gtk3 update breaks multiple packages

[Milan Crha]

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. My fault.
Bye,
Milan

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gtk3 update breaks multiple packages

[Milan Crha]

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 you pick a wrong commit? What was
the commit supposed to proof, please?

Bye,
Milan

P.S.: opening three threads for a single thing with identical text is
not nice. It can confuse archive readers, not finding answers they
might be looking for. Try to avoid that in the future, please.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 available in the build roots, then it
> should be fine to rebuild.

Hi,
Frantisek sorted it out, I verified the gnome-shell had been built
against the mutter version you mentioned above. The update also landed
in rawhide shortly afterwards.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 anything. I can rebuild
gnome-shell 46.alpha in the eds side tag and refresh the update.
Bye,
Milan


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 promptly rebuild of the left dependencies. As
they all are done now, I filled the update:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-d3219fb3da

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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:

   elementary-calendar
   evolution-chime (which is part of pidgin-chime)
   gnome-panel
   phosh

Any help appreciated.

Thanks and bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 the function.

According to `dnf repoquery --whatrequires libecal-2.0.so* --alldeps`
these are the affected packages:

  almanah
  bijiben
  elementary-calendar
  evolution
  evolution-chime
  evolution-data-server-devel
  evolution-data-server-tests
  evolution-ews
  evolution-mapi
  evolution-pst
  evolution-rspam
  gnome-calendar
  gnome-panel
  gnome-shell
  gnome-todo
  phosh
  syncevolution-libs

I'll handle those I've commit rights for, which is most of them.

I created a side tag f40-build-side-80962, where the data server is
built. You can use:

   fedpkg build --target=f40-build-side-80962

to build your packages in it too. I plan to merge the side tag in
a week or so.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 it
that way.

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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-separated, not as a ;-list
> (https://cmake.org/cmake/help/latest/module/CheckCSourceCompiles.html
> ), so that should probably be fixed in EDS to see if the problem
> stays or if it goes away.

Hi,
thank you for the analyzes. I checked it's used incorrectly on other
places too. This also had been addressed long ago [1], but it strikes
back because I forgot of this and did not pay attention to the CMake
documentation.

Doing a similar change as in the [1] fixes the build problem.

Thanks and bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=773659
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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-repo f39-build --build evolution-data-server-3.50.3-1.fc39
nvr evolution-data-server-3.50.3-1.fc39 is not current in tag f39-build
  latest build in f39-build is evolution-data-server-3.50.2-1.fc39


$ koji latest-pkg f39-build evolution-data-server
Build Tag   Built by
    --
evolution-data-server-3.50.2-1.fc39   f39-updates   mcrha


$ koji latest-pkg f39-updates-candidate evolution-data-server
Build Tag   Built by
  - --
evolution-data-server-3.50.3-1.fc39   f39-updates-candidate  mcrha


What can I do make it work, please? Or is chain-build supported only on
the side tags these days? I'm pretty sure it worked fine a month ago.

I do not see any f39 repo-rebuild related task between current active
tasks on koji [2].
Bye,
Milan

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411
[2] https://koji.fedoraproject.org/koji/tasks
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 does not reference
anything related to the zlib in this test, from which I suppose one of
these four .pc files bring the WITH_GZFILEOP in the list.

In any case, if there's anything the eds code or the .spec file should
do, just let me know (not that I think it's eds' fault, neither the
latest change uncovering any error in the eds CMake file, but I can be
wrong).

Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

CMake's check-compiles fails to parse WITH_GZFILEOP

[Milan Crha]

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=value
   CMake Error at 
/usr/share/cmake/Modules/Internal/CheckSourceCompiles.cmake:101 (try_compile):
 Failed to configure test project build system.
   Call Stack (most recent call first):
 /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:52 
(cmake_check_source_compiles)
 CMakeLists.txt:916 (CHECK_C_SOURCE_COMPILES)

I checked the sources and there is no reference to WITH_GZFILEOP,
neither in the .spec file, thus it comes from some other project.

Exactly the same test [1] passes fine in f39.

Does this sound familiar to anyone? Maybe the library or what, which
exposes it, should be corrected?

Thanks and bye,
Milan

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321151
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=111321411
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Milan Crha]

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 an error, but it does not alter the outcome of this check
> because there already is another error (and the current GCC
> instrumentation is able to detect this an not flag the
> -Wincompatible-pointer-types issue).

I've been afraid you might "cancel" the whole build due to this, I
kinda expected it, because you also mentioned errors from the configure
time, but as you said it will not happen, the build can continue when a
function check fails, thus no problem so far.

Thank you for the clarification.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Milan Crha]

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 are incompatible types passed to the function. Both are
> > claimed by gcc. The second is due to the first. The result of this
> > "source compiles" test is correct, the function does not have five
> > arguments.
> 
> I don't see this.  The evolution-data-server-3.50.2-1.fc39 and
> evolution-data-server-3.50.2-1.fc40 have this:
> 
> -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
> -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Success
> 
> While my test build has:
> 
> -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
> -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Failed
> 
> So the test outcome is altered by the new error.

Hi,
the HAVE_I_CAL_EMAIL_PARAMETER is the b) from the above, aka the
changes uncovered a bug in the configure-time code-compiles check.

The a), an expected failure, is this one:
 .../TryCompile-0C2YRH/src.c: In function ‘main’:
 .../TryCompile-0C2YRH/src.c:11:37: warning: redundant redeclaration of 
‘__h_errno_location’ [-Wredundant-decls]
11 | int h_errno;
   | ^~~
 /usr/include/netdb.h:59:13: note: previous declaration of 
‘__h_errno_location’ with type ‘int *(void)’
59 | extern int *__h_errno_location (void) __THROW __attribute__ 
((__const__));
   | ^~
 .../TryCompile-0C2YRH/src.c:12:111: warning: passing argument 7 of 
‘gethostbyaddr_r’ from incompatible pointer type [-Wincompatible-pointer-types]
12 | (void)gethostbyaddr_r 
("www.ximian.com", 14, AF_INET, , buffer, bufsize, _errno);
   |
   ^
   |
   |
   |
   int *
 /usr/include/netdb.h:174:57: note: expected ‘struct hostent ** restrict’ 
but argument is of type ‘int *’
   174 | struct hostent **__restrict __result,
   | ^~~~
 .../TryCompile-0C2YRH/src.c:12:39: error: too few arguments to function 
‘gethostbyaddr_r’
12 | (void)gethostbyaddr_r 
("www.ximian.com", 14, AF_INET, , buffer, bufsize, _errno);
   |   ^~~
 /usr/include/netdb.h:170:12: note: declared here
   170 | extern int gethostbyaddr_r (const void *__restrict __addr, 
__socklen_t __len,
   |^~~
 gmake[1]: *** [CMakeFiles/cmTC_3133a.dir/build.make:78: 
CMakeFiles/cmTC_3133a.dir/src.c.o] Error 1
 gmake[1]: Leaving directory '.../TryCompile-0C2YRH'
 gmake: *** [Makefile:127: cmTC_3133a/fast] Error 2

Note the `too few arguments to function ‘gethostbyaddr_r’` error
follows the `incompatible pointer type` warning, which is going to be
an error after the proposed change.
Bye,
Milan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Milan Crha]

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.

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 are incompatible types passed to the function. Both are
claimed by gcc. The second is due to the first. The result of this
"source compiles" test is correct, the function does not have five
arguments.

Another "configure" check used incorrect arguments in error. I
corrected it for the development version [1], which should be released
at the beginning of the next year.

I can workaround the first problem by doing the check only when needed,
but I do not think tests like these are supposed to not break.

Bye,
Milan

[1] 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/8d3c23e68aada59c5deb59a664aea263f075
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 it, but this feels kinda bizarre.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 have

   Requires: appstream%{?_isa} >= %{appstream_version}

adding the tilde only here and not into:

   BuildRequires: pkgconfig(appstream) >= %{appstream_version}

will lead to a problem in the future (at least for me, I'll forget
about it very soon).

What about removing that `Requires`? There is added un-versioned
dependency on libappstream.so.5()(64bit) anyway, which may work, as
long as the .soname versions are properly bumped on API/ABI changes,
right? I understand these `Requires` as "to be on a safe side" only.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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:  Error: 
DEBUG util.py:446:   Problem: package flatpak-devel-1.15.4-4.fc40.x86_64 from 
build requires flatpak(x86-64) = 1.15.4-4.fc40, but none of the providers can 
be installed
DEBUG util.py:446:- conflicting requests
DEBUG util.py:446:- nothing provides appstream(x86-64) >= 1.0.0 needed by 
flatpak-1.15.4-4.fc40.x86_64 from build

You can see the build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=108705408

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 sorry for a late response, I forgot of this. I tried to build
gnome-software in your side tag, but it fails due to the appstream
packages cannot be installed together:

Error: Transaction test error:
DEBUG util.py:446:file /usr/lib64/girepository-1.0/AppStream-
1.0.typelib conflicts between attempted installs of appstream0.16-
0.16.3-1.fc40.x86_64 and appstream-1.0.0~git20231102.d88ed03-
1.fc40.x86_64

Thus I guess the dependencies need to be built in certain order, to not
pull in old and new appstream packages or there's some problem with
packaging of the two.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Disabling rawhide builds during branching

[Milan Crha]

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 returned by the PackageKit (in this case), thus
giving a clue what failed, please?
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 bumped for
whatever reason. That's the only reason why the variables are part of
the .pc file, to have correct D-Bus service name provided, not hard-
coded.

In any case, I understand these are not obstacles, not the big one, if
the runtime change for the D-Bus service names will be possible. Feel
free to file an upstream bug against the evolution-data-server, thus
it's tracked (and not forgotten).

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 from the system, inside the sandbox;
b) they can be started without any additional effort on the Flatpak
   configuration side (because the services share the app's D-Bus
   prefix).

I briefly grepped the evolution-data-server sources and it seems that
most of the places in the .c files can be changed in runtime, but there
are places where the things can break, like the `evolution-data-
server.pc` file or the D-Bus .service files, which both reference the
D-Bus name from the compile time and those .service files are also
named by the service (otherwise there's a runtime warning in the
journal about the file not matching the service name). Those might not
be show stoppers, I guess.

By the way, when people install Evolution flatpak, they have
preinstalled evolution-ews inside it. How will they install it after
this change?

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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_services_prefix org.gnome.Evolution
> 
> This will need to be redone so that evolution-data-services doesn't
> need recompilation
> and the prefixing can be done by changing configuration files at
> container build time.

Hi,
I cannot speak for the tracker-miners, but in case of the Evolution, it
runs in its own sandbox, separated from the host system, with bundled
evolution-data-server (eds) services, thus when the user installs the
Flatpak version, he/she gets the expected Evolution and eds versions,
independent of what the host system has installed. Advantage: the user
gets all fixes, not only client-side (Evolution) fixes. It's important,
from my point of view.

> In many cases, this should consist of just a few minor changes to
> container.yaml.

Do you mean the `evolution.yaml` is gone with this change and the
dependencies are taken directly from the .spec file? The eds dependency
is a problem here, as you noted, not talking that not everything from
the .spec file requires a rebuild for the flatpak (most dependencies
are part of the runtime).

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to migrate database format during package update?

[Milan Crha]

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 conditionally (in the .spec
file) build the migration tool using static libdb, thus no pull in of
the libdb package itself. Something similar is used in the cyrus-sasl
Alexander pointed me to. It's much cleaner solution and it also lefts
everything under the user's control, which is for good.

I do not think there can be done the conversion on-the-fly, the
bogofilter is build with one or other DB engine, not with multiple.
Having wrapper scripts to convert the format is something I'd like to
avoid.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to migrate database format during package update?

[Milan Crha]

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(-static)
dependency optional (no migration tool without it).
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

How to migrate database format during package update?

[Milan Crha]

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 specific, the libdb package is going to be removed [1] sooner or
later, and one of the packages which still use it is Bogofilter [2].
It's easy to just switch from libdb to SQLite in the .spec file, the
problem is that the years of user's training of the Bogofilter spam/ham
data would be lost by such change. The SQLite version cannot read the
libdb data and vice versa (obviously), thus there needs to be done some
manual migration by the users. The worst, the users may need to export
their wordlist data before the update/upgrade and import it back after
the update/upgrade. Also, when the bogofilter is run with the other
format of the wordlist database, it simply errors out and expects
manual intervention. It's also good, the old data is not completely
lost, after all, and the user is aware something changed.

My idea was to help the users with the migration in a way that the
export of the libdb data could be done during the package update, in
the %pre stage. A very nasty way I came with is to traverse the /home/
directories and if there exists the old database, then export it and
rename the old file, thus the new bogofilter can run, even with an
empty database. The thing is that the exported data is ready in such
case, no need to downgrade the package or install old Fedora or any
such thing just to recover the wordlist. It's the only advantage, while
there are many disadvantages:
- it's a nasty approach, the package should not touch users' home
- it works only if the user uses the default/expected setting; saving
  the database into a different place voids this best-effort approach
- the exported file is owned by root/admin, which requires change of
  the attributes thus the user can get rid of it
- the package cannot tell to the user what to do next, to restore
  the exported data.

I'm sure you might find more disadvantages, these are just the top
four.

That being said, any such change surely deserves release notes, with
the commands what to do to export and then back import the wordlist.
There should be filled a corresponding Change too, I guess.

Still, how does other packages migrate their data, or at least help the
users with the migration? Is there any way?

Thanks and bye,
Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1778802
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1788486
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: updating cmark to 0.30

[Milan Crha]

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 possibly F36 if needed
> afterwards.

I do not think you should change API/soname version in stable releases,
that can lead to trouble (for example for 3rd-party packages).
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned gtkhtml3

[Milan Crha]

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

[1] https://src.fedoraproject.org/rpms/gtkhtml3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 the right way to test, which I did
not in time of writing the previous mail. I know it now.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 of them (there are a lot of messages in this thread). My fault.

I used your hints and addressed couple problems in my projects/packages
upstream.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 tons of related warning/error lines generated by gcc.

Hi again,
I just figured that compiling with:

   gcc -std=c99 -Wall -Wextra -D_DEFAULT_SOURCE=1 test.c -o test -ldb

makes it work. I've no idea where I should add that define, CFLAGS
feels too brutal for it.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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-4.fc37.x86_64
libdb-5.3.28-53.fc37.x86_64

When I try to compile this simple program:

  #include 
  int main(void) { db_create(NULL, NULL, 0); return 0; }

(which is part of the project's "can build" test to verify the thing is
properly installed in the system) using:

   gcc -Wall -Wextra test.c -o test -ldb

then it doesn't claim anything and succeeds, but 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 tons of related warning/error lines generated by gcc.

Looking into the db.h file, it has there a comment that it can add the
`u_int`, when the system doesn't provide it, but that related block is
empty in Fedora. More interestingly, even when I add `#define
__USE_MISC 1` at the very top of the program, thus the
/usr/include/sys/types.h should declare also `typedef __u_int u_int;`,
the type is still unknown and the compilation aborts. Something
declares __u_char_defined before the sys/types.h gets to it, it seems.

A fix might be done on the libdb's db.h or elsewhere?

I may face more similar or totally different issues while I progress
with my compilation attempt (until I give up), and I'm not going to
spam this list with it. I do understand these things need to be
addressed individually, which makes perfect sense. Where it would be is
harder to guess for me.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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'

when tagging the build.

Who's in charge for such error, please? Or am I supposed to do anything
and if so, what that is precisely, please?

Another build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=93236471
, ran less than a minute after the broken one, worked with no problem.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: WebKitGTK package naming

[Milan Crha]

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(webkit2gtk-5.0)"

Thus some upstream changes will be needed there too. The transition
will be painful, if the upstream is supposed to support both naming-s.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

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 quite confusing.

Hi,
the current COPR builds for early testers conflict on the libdnf5-devel
package:

  - package libdnf5-devel-5.0.0-20220826011404.2.g05e0c2c0.fc37.x86_64
conflicts with libdnf-devel < 5 provided by libdnf-devel-0.68.0-
1.fc37.x86_64

Is that going to be solved anyhow, or it's expected? The
library/executable files can be installed in parallel, it seems, or at
least those I tried, but having the devel files for both is not
possible at the moment. It would be useful to not conflict the files,
thus one can build on one machine for both versions, not replace the
devel files constantly, if the two are supposed to live together for
some time.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is system upgrade automatic or not?

[Milan Crha]

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
gigabytes of data to be downloaded, then even more gigabytes of data to
do the update. The update itself takes its time too (you do not have
always enough battery, or whatever).

At least the gnome-software notifies about new major upgrades, when
they are available. It does not install them automatically and I hope
it never will.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Milan Crha]

> "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, there is used 
GUri instead. For that reason the ESourceWebdav has replaced the property with 
the "uri" property, using the GUri structure.
   Bye,
   Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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/... libsoup3:
https://copr.fedorainfracloud.org/coprs/mcrha/evo-soup3/
It replaces core packages (which might get obsolete by regular f36
updates eventually) as much that it includes also gnome-shell and
others. The libsoup3 version there uses branch:
https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283
which is important for the evolution-data-server and the other
evolution packages (to be tested in action soon).

Other packages have included (or enabled) their changes from a porting
tracker bug on the libsoup side:
https://gitlab.gnome.org/GNOME/libsoup/-/issues/218

I did not cover all the packages from the default Workstation install,
I skipped gnome-boxes (Vala, huh), gnome-photos and gnome-maps. With
these removed one can replace the GNOME to the libsoup3 version.

The grilo-plugins package is just hacked to remove the libsoup parts,
because it doesn't have any proposed porting patch. There might be more
hacks in the packages, I do not recall what I tweaked where precisely.

That being said, if anyone wants to do any early testing of their
project(s), then this can be a good starting point. I can add more
packages, if anyone throws a source rpm at me (not by mail, just a link
to it).
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

How to find out whether a package is used

[Milan Crha]

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 whether anyone will cry it's missing.

My idea is to remove the evolution-mapi package. It is kept alive
upstream for users connecting to very old Microsoft Exchange servers in
the Evolution. A more modern replacement is evolution-ews, which works
with Exchange 2007 servers and newer (it is the version the Microsoft
introduced the Exchange Web Services (EWS) protocol, thus 15 years
ago).

The evolution-mapi depends on the openchange package, which has (for
several years) no upstream. According to `dnf repoquery --whatrequires
libmapi-openchange.so* --alldeps` only evolution-mapi requires it, thus
removing the evolution-mapi can also remove the openchange package,
but I'd like to not cause any regression to anybody using the
evolution-mapi, hence I'd like to know whether it's used at all or not.
For the completeness, the openchange package depend son samba and
whenever samba is updated (and its soname versions), the openchange and
evolution-mapi needs to be rebuilt against it.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Final blocker status summary

[Milan Crha]

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.

Hi,
it's not really fixed in the gnome-software, that version only contains
a workaround, which has certain visual side effects. That bug is still
awaiting a proper fix on the gtk4 side.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 it's worth, the "dialog-question" is part of the
specification, still the console snippet Philip pasted in his mail
shows an abort on it:

> self._question_icon = icon_theme.load_icon("dialog-question", 48, 0)
> gi.repository.GLib.GError: gtk-icon-theme-error-quark: Icon 'dialog-
> question' not present in theme Adwaita (0)


Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 invoking fedora-third-party in some cases. There's no
hard require for it in the .spec file.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 evolution-data-server and evolution are already built there, thus
you can run the build of the pidgin-chime whenever you find time.
Thanks again and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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.

Thank you for your help with patching the package.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 updates also the m4 macros. I left
autotools usage years ago.

I think adding the python-unversioned-command into the BuildRequires
can avoid similar issues in the future. Whether it's correct or not I
do not know.
Bye,
Milan

[1] in specific, it runs:

   autoreconf -fiv
   %configure --enable-libpst-shared \
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 of
the libpst at all, neither I've any idea about its internals. A simple
revert of the orphan would be the best choice, from my point of view,
because the orphan was kind of mistake, due to no problem with the
package itself. I do not know why it had been missed earlier. It
happens. If there's no other choice, I can take it temporarily.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 still  references only up to version 3.9 (and there's no
`python` binary during the libpst build, because not installing also
python-unversioned-command). Note the libpst does run autoreconf. Maybe
more packages using autoconf are affected by this.

Should anyone update the autoconf-archive and then rebuild the affected
packages? I cannot do it myself, I do not have enough powers.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 these affected packages:

   evolution-0:3.41.1-2.fc35.x86_64
   evolution-bogofilter-0:3.41.1-2.fc35.x86_64
   evolution-chime-0:1.3-11.fc35.x86_64
   evolution-data-server-devel-0:3.41.1-2.fc35.i686
   evolution-data-server-devel-0:3.41.1-2.fc35.x86_64
   evolution-ews-0:3.41.1-2.fc35.x86_64
   evolution-mapi-0:3.41.1-3.fc35.x86_64
   evolution-pst-0:3.41.1-2.fc35.x86_64
   evolution-rspam-0:0.6.0-33.fc35.x86_64
   evolution-rss-1:0.3.96-7.fc35.x86_64
   evolution-spamassassin-0:3.41.1-2.fc35.x86_64

I have commit rights for all but the evolution-chime, which comes from
pidgin-chime package.

I'll create a side tag once the upstream release is done and I'll build
the packages there. Then I'll send it to this thread. I'd appreciate a
help with the pidgin-chime rebuild, to be able to merge the side tag
soon.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 mass rebuild is finished

[Milan Crha]

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 wrong search term.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 mass rebuild is finished

[Milan Crha]

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.org/mass-rebuild/f35-need-rebuild.html

Hi,
looking on the libical build break [1], it looks like the ppc64le build
doesn't use _target_platform properly in the CMake macros, because, if
I read the build.log correctly, the build is done into
`redhat-linux-build`, while the `_target_platform` evaluates to
`ppc64le-redhat-linux-gnu` (it's used in the `make test` call in the
libical.spec file). The i686 also builds into `redhat-linux-build`, not
the i686 target platform directory. I did not look on other arches.

Is this change intentional or it's a bug in the build process/CMake
macros?

I searched for the "_target_platform" here and the latest discussion
mentioning it was almost a year ago.
Bye,
Milan

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=72392998
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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
ongoing builds of the other packages from the list the repoquery
returned (in the initial message of this thread), the only left are:

elementary-calendar
elementary-planner
evolution-chime
gnome-panel
wingpanel-indicator-datetime

I see the gnome-calendar failed due to libgweather changes. The chain
build of the packages I covered is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61818854

I'll restart the builds (pity it cancels parallel builds when one of
them fails).

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Milan Crha]

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 any issue. I surely do
not have commit rights for all the dependencies, but I'll see which
those are when I get to it, as some packages had been orphaned
recently. I'll left the two packages you mentioned up to you.

As promised, I'll update this thread once I've the side tags ready,
with compiled evolution-data-server.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 side tags, one for
the rawhide and one for the f34 branch? I guess I should. It'll double
the work, somehow, but that's just due to a bad timing of the change.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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?

The API changes are on the WebDAV related code, namely functions
e_webdav_discover_content_get_selected(), e_webdav_resource_new().
The ABI changes will work just by a rebuild. I guess only a few
projects use either of the two functions (the former uses Evolution).
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 tag and I'll merge it possibly in the middle of the next week,
depending how things will go.

I'll create the side tag on Friday, after the evolution core packages
are released upstream and ready for the build in rawhide, and post its
name here, thus others can run their rebuilds.

The affected packages:

$ dnf repoquery --whatrequires libedataserver-1.2.so* --alldeps
almanah-0:0.12.0-6.fc34.x86_64
bijiben-0:3.38.0-2.fc34.x86_64
elementary-calendar-0:5.1.1-2.fc34.x86_64
elementary-planner-1:2.6.7-2.fc34.x86_64
evolution-0:3.39.1-2.fc34.x86_64
evolution-chime-0:1.3-9.fc34.x86_64
evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
evolution-data-server-tests-0:3.39.1-3.fc34.x86_64
evolution-ews-0:3.39.1-2.fc34.x86_64
evolution-mapi-0:3.39.1-2.fc34.x86_64
evolution-pst-0:3.39.1-2.fc34.x86_64
evolution-rspam-0:0.6.0-31.fc34.x86_64
evolution-rss-1:0.3.96-5.fc34.x86_64
evolution-spamassassin-0:3.39.1-2.fc34.x86_64
folks-1:0.14.0-6.fc34.x86_64
glabels-0:3.4.1-13.fc34.x86_64
gnome-calendar-0:3.38.2-1.fc34.x86_64
gnome-contacts-0:3.38.1-2.fc34.x86_64
gnome-panel-0:3.38.0-2.fc34.x86_64
gnome-phone-manager-0:0.69-34.fc34.x86_64
gnome-shell-0:40.0~alpha.1.1-4.20210202git9ce666ac1.fc34.x86_64
gnome-todo-0:3.28.1-11.fc34.x86_64
syncevolution-libs-1:1.5.3-16.fc34.x86_64
wingpanel-indicator-datetime-0:2.2.5-3.fc34.x86_64

$ dnf repoquery --whatrequires libedataserverui-1.2.so* --alldeps
elementary-calendar-0:5.1.1-2.fc34.x86_64
evolution-0:3.39.1-2.fc34.x86_64
evolution-chime-0:1.3-9.fc34.x86_64
evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
evolution-ews-0:3.39.1-2.fc34.x86_64
evolution-mapi-0:3.39.1-2.fc34.x86_64
evolution-rspam-0:0.6.0-31.fc34.x86_64
evolution-rss-1:0.3.96-5.fc34.x86_64
gnome-calendar-0:3.38.2-1.fc34.x86_64
gnome-contacts-0:3.38.1-2.fc34.x86_64
gnome-todo-0:3.28.1-11.fc34.x86_64

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Mass Rebuild

[Milan Crha]

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.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Mass Rebuild

[Milan Crha]

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 do not know how to decipher it. Is it that the
mass rebuild was not done against proper packages?
Bye,
Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1926239
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Milan Crha]

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 found(EE) 

I opened the following bug for further tracking:
https://bugzilla.redhat.com/show_bug.cgi?id=1925423

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mesa 21.0.0-rc3 making rawhide really unstable?

[Milan Crha]

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 "GNOME" (aka Wayland) works.

I also noticed a huge CPU spike after confirming my password (when
logging into the Wayland), but it's probably unrelated to this thing.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Also see the "Upgrade/compatibility impact" section there.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

evolution-ews license change

[Milan Crha]

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 libedataserver-1.2.so* --alldeps
there lefts elementary-planner, evolution-chime and gnome-panel, to
which I do not have commit rights. I can wait until Friday and tag the
things to rawhide later, thus the maintainers have more time to even
notice the change.

I'm sorry I caused this mess.

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 folks could work.

Hi,
I currently use the f33-build-side-25060 sidetag.

I managed to find the cause of the test failure in folks [1], I'll
backport the change into the sidetag for the time being and I'll build
what I can there as well.

Fabio, could you move/build your packages into that sidetag too,
please? The updated folks might be in the sidetag within an hour or so,
depending on koji speed.
Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/folks/-/merge_requests/40
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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, which I
didn't want to delay for another week.

> > 
> I looked a bit and it didn't seem easy to fix the test failure in
> folks...

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 folks could work.

> so in the interest of not having rawhide broken all
> weekend/until we can sort that out I went and untagged that set of
> packages: 

Okay, thanks. I didn't expect causing such a problem. I'm sorry about
that.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 all. I'll take care of the rebuilds for the packages I've the
commit rights for.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 swap-on-drive

Hi,
I confess I've absolutely no idea about this, I mean how that works in
practice, but when you tell me "we do not allocate on start, we
allocate on demand, when the memory is full", then, I hope a logic
question is, where do you allocate, when the memory is already full? If
there's some threshold, then it's quite the same as preallocate the
memory.

Let aside how the compression itself works. Does it mean, that the
actual outcome will be quicker response (than when using swap on disk)
for a price of higher requirements on the CPU (thus it can
compress/decompress in a timely manner), thus eventually higher power
consumption, thus shorter up time, before the battery is down? I know I
can easily misunderstand things, but it feels like a side effect of the
compression.

Virtual machines. I usually do not give it access to the all host
system resources, I give it like 1 or 2 CPUs (sometimes more, but only
when I know I want to do something expensive there), and like 2GB of
memory (I used to give it one, but since Fedora begun to require at
least 2, I increased it). With this swap to RAM on, should I give it
even more memory (and eventually CPU), thus Fedora can boot and work
reasonably well?

When you've a machine with 4GB RAM and 1TB HDD and 1.6GHz CPU, it's
much cheaper to use swap on disk than to waste RAM, which should be
used for other things (it's even not fully usable 4GB, because some of
that can use integrated graphics card). I guess this will penalize such
low cost machines, though it needs testing to know for sure. There are
devices with a lot less resources (there had been mentioned IoT, under
which, I suppose, belong also toys like Raspberry PI, which do not have
a lot of RAM (not counting Raspberry PI 4B)), where it might (or might
not) hurt even more.

My main machine has 16GB RAM. When I run compilation of some bigger
projects (like WebKitGTK in my case, but I do not want to even think of
giants like LibreOffice), then I face memory pressures, also depending
on the target type (debug/release) and how many cores I give to it. It
happens from time to time that the whole system freezes (keyboard/mouse
doesn't react, neither Caps Lock/Num Lock), with high CPU usage. I
suppose it tries to compile, but I never left it run that long, I just
turn off the machine and start again, where the new run eventually
survives. Should this swap to RAM help anyhow in such situation?

> [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to
> discover edge cases, and tweak the default configuration if necessary
> to establish a good one-size-fits all approach.

The developer usage and average (office) user usage are very different.
I'm afraid you cannot find any number, which will fit to all.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 coming week... lost.  :(
> 
> I just untagged it. It should be out in the next newrepo. 
> 
> Sorry for not doing it sooner. 

Hi,
out of the interest (no offense meant), would this not be caught by the
rawhide gating? I'd expect that this is something what the rawhide
gating would avoid. Of course, it expects reasonably good gating tests
for the package(s), there's no doubt, but in this particular case,
where hundreds of packages failed to build, even for a single
architecture...

I guess it would be a nice proof of concept for the rawhide gating, if
caught by it.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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, which is truly needed, or both):

BuildRequires: pkgconfig(webkit2gtk-4.0)
BuildRequires: pkgconfig(webkit2gtk-web-extension-4.0)

and it'll work in all EPEL7, EPEL8 and Fedora. No need for conditionals
for the 'rhel' variable. This is how for example Evolution looks for
WebKitGTK+ development files. There was not needed any change in the
.spec file when the WebKitGTK+ package had been renamed.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unannounced soname bump with samba 4.12~rc1

[Milan Crha]

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 email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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. Sometimes you want a special side tag, sometimes
it's not needed. The way I do it right now (it's only about 4 packages
depending on each other, not hundreds), is that I commit to master,
then to stable, then the second package to master, to stable, then
third and finally to the fourth and then I ran a chain-build as this:
"a : b : c " in package 'd', (which builds 'c' and 'd' in parallel,
once 'a' and 'b' are built in serial). Then I just refresh the koji
build page from time to time and verify that the build still runs
and/.or it finished successfully. I can run chain-build in stable too,
it only needs a bit more intervention, to define overrides for 'a' and
'b' in bodhi, to be able to build them.

I'm afraid fully automating such things might be a challenge. In other
words, properly solving dependencies is problematic. Having yet another
syntax to describe it, or the groups you suggest, scares me a bit. And
we are not talking about inter-package dependencies, with packages you
are not maintaining.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

[Milan Crha]

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. I filled a
bug upstream [1]. Being able to reliably search in issues is rather
essential function, from my point of view. I'm wondering how they can
search for anything when they've filled 10k+ issues.

Anyway, if you think this doesn't belong to this thread then I
apologize.
Bye,
Milan

[1] https://gitlab.com/gitlab-org/gitlab/issues/35611
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Unannounced soname bump of qrencode

[Milan Crha]

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  - 3.1.1-3
   - Keep libevolution-mail-settings.so* from the previous change,
 it is still used by other parts of evolution.

Just saying.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 libical, which allows automatic gobject
introspection generation. That turned to be as significant change as it
worth the calendar API change from version 1.2 to 2.0.

The other change on the address book and the calendar parts was about
adding a new argument into some methods, which touches both the C API
and the D-Bus API, thus there is a version bump on the D-Bus service
names as well. [1]

Below is the list of affected packages in Fedora, divided into four
sections:

* Those, which require patching:
almanah
bijiben (aka gnome-notes)
evolution
evolution-ews
evolution-mapi
folks
gnome-calendar
gnome-shell
gnome-todo
libopensync
libreoffice
pidgin-chime
syncevolution

* Those, which require only rebuild:
ekiga
evolution-rspam
evolution-rss
glabels
gnome-contacts
gnome-phone-manager
sflphone

* Those, which require patching, but are already retired:
california
ffgtk

* Those, which require work:
elementary-calendar
wingpanel-indicator-datetime

Any existing patches can be found through [3], which contains also
links to respective merge requests and bugs, filled to let know the
maintainers beforehand.

I will rebuild/apply patches to the packages I've commit rights for.
I'd need help with others. Especially those two elementary-related
packages won't work easily, because they use vala bindings, which they
bundle in the sources, thus there is needed a lot of work. One of the
elementary developers promised me to look on it once the eds is
released.

If you find more packages to be ported and you'd like to help with it,
just let me know.
Bye,
Milan

[1] This may cause trouble to Flatpak applications, which compile
against some version of the evolution-data-server (eds) and then
rely on the host system eds D-Bus services (that applies both
ways, it won't help to compile against older eds, because the
Flatpak application won't work on systems with the new eds). Such
applications can run their own eds services, as shown here [2].
The advantage of it is to receive also backend-specific fixes in
their Flatpak application, not only client-side fixes. The
disadvantage is that the data won't be shared between the
applications.

[2] 
https://gitlab.gnome.org/GNOME/evolution/blob/master/flatpak/org.gnome.Evolution-stable.json#L258

[3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 what happened, because
the web UI didn't show any error message or a clue what was wrong. The
'Submit' button just spin for few seconds and then nothing happened,
which had been quite frustrating.

Could the web UI be changed to claim all errors when it encounters any,
instead of being just quiet and broken with no reason given?
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS UP] Meson 0.48.0

[Milan Crha]

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 build
geocode-glib 3.26.0 (the latest upstream release 
https://download.gnome.org/sources/geocode-glib/ as of now), it fails
to build due to missing mesontest:

  =
  Building module geocode-glib in /home/user/fp/.flatpak-
  builder/build/geocode-glib-2
  =
  ERROR: Command 'mesontest' not found

> F28 and EPEL7 won't get update because of this incompatibility,
> but if you need it for building updates -- let me know and I will
> consider pushing it even there.

From the above I believe you should not add this to the stable releases
"if anyone needs it", unless you do some proof that it won't break more
than the geocode-glib (and/or fix the breakage at the same time).

I mean this just as a notice/confirmation that there are packages which
can be broken with this change, as you pointed out.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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 of evolution-data-server.

According to:

   $ dnf repoquery --whatrequires pkgconfig\(libedataserver-1.2\) \
--alldeps --enablerepo=fedora-source

the affected packages are:

   almanah
   elementary-calendar
   evolution
   folks
   gnome-calendar
   gnome-todo
   wingpanel-indicator-datetime

I'll rebuild the packages I've commit rights for. Let me know if you
face any issue with the other packages, I can help to correct it (which
would be to copy the old code from eds, but I really do not expect
anything using the e-gdbus-templates).
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Milan Crha]

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, but I do not know how they are used by 3rd-parties, if
at all. The corresponding .test files execute them using `behave`:

  [Test]
  Type=session-exclusive
  Exec=behave /usr/libexec/evolution/installed-tests -t view_shortcuts -k -f 
html -o view_shortcuts.html -f plain

Hope it helps.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UBXUJG6IO2ESSAYAL55MYP66ESVWE2PM/

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

[Milan Crha]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GC6YNVRVTGMMXV5NGSMCYTBZZ2JFZHN4/

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

[Milan Crha]

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 evolution | grep py

returns only folder-copy.png and mail-copy.png, both at
/usr/share/evolution/icons/hicolor/16x16/actions/ directory.

Trying with

   $ rpm -ql evolution | grep -c "\.py"

returns 0, while

   $ rpm -ql evolution | grep -c ".py"

returns 2, but those are the .png files named above.

The evolution package doesn't even require python for anything, neither
for build.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AUFUR4JQU2BYHHJ7CTCDZMB6SJLC4QS7/

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

[Milan Crha]

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]. There's definitely no need to rebuild everything what
requires evolution-data-server, the less indirectly, as long as it's
not statically linked, which I doubt.

The main evolution packages (evolution, evolution-ews and evolution-
mapi) will be updated at the same time as evolution-data-server. The
other surely affected are evolution-rss and evolution-rspam.

I'll check what breaks after the update is done and available for
download and I'll rebuild packages I've commit rights for myself,
unless the main maintainer(s) will be quicker.
Bye,
Milan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1589722
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GWQQM4VIPONQHZ35TEM2FJANF6MUHKUC/

Re: plan to update brotli to 1.0.4 in Rawhide

[Milan Crha]

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 package on the day I
> > update it
> > right?

Hi,
yes, you did, Travis. Thanks for it.

> Have you rebuilt all dependent packages successfully beforehand?
> If not, and there are API and/or ABI changes that require porting
> to the new API, you'll be creating unexpected work for the
> maintainers of the above packages.

Well, I'd not call it unexpected. Once you announce API/ABI change it
is expected that at least a rebuild, or also a code change(s), will be
needed. The maintainer of the package which does that API/ABI change
can help with porting to the changes, either with a patch or at least
pointing to upstream guide with the port instructions to the new API,
of course, and it's highly welcome, but it's not always possible.

> Please do test rebuilds in COPR if you haven't
> already and try to fix any issues before actually doing the update.

I'm not sure it's fair to expect everyone doing this. First of all,
Travis doesn't seem to have commit rights to any of the referenced
packages, according to [1], neither he's part of provenpackagers group,
thus his best effort starts with this announcement and can be followed
by a pull-request or bug filling with a proposed change for the other
packages, but even that is sometimes not doable. Second, most/many
package maintainers are volunteers, kind of proxy for upstream work
they may not have any influence on, they just provide something useful
in Fedora for others, to make it easier to use for them. It doesn't
matter how large the package is or how many dependencies it has, from
my point of view. Compare it with something huge, like gcc updates,
mass rebuild(s) due to it and all the work involved around that. That
couldn't be done that smoothly with a group of volunteers "over the
weekend".

I do not know Travis and his position in that what I imply above, I
only try to give my point of view on this. It's always nice to see the
help from the package maintainer, but I do not think you can force it
in general. Not talking that the dependencies can have available
upstream fix already and the other maintainer can be aware of it, thus
the work you want from Travis might be useless and duplicated. Maybe.
It's all about coordination and it starts with these announcements.

Bye,
Milan

[1] https://src.fedoraproject.org/rpms/$RPM
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

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 devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

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:
> > > 
> > > * 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 them.
> > 
> Tooling can be built no? Why do you assume we can't make chain-build
> work with side-tags?

That wasn't my suggestion, that's what Kevin Fenzi suggested and I sort
of questioned it. :)

> Seems to me much more interesting to say: I have a few packages to
> update, let's update them, ok I'm done, could you check if I missed
> any? yes -> fix, no -> merge

Yes, definitely. How that "checked if I missed any" question will be
implemented is important. It's necessary to have it done before merging
the side tag, otherwise there will be no gain in gating at all, right?
The best time is to have done the final check automatically when the
merge of the side tag is requested, if I understand it correctly.

> The idea has been submitted a few times already in this thread,...

Oh, right, I'm sorry for repeating it. My fault.

> The difference is that during that week, we will still be able to
> compose rawhide tomorrow (and thus test all the other changes), while
> we can't today.

I see, that makes perfect sense. Some packages won't stop the rest of
the distribution. I'm only afraid people will care less when the
problem will be in a side tag, rather than in the main stream. 

> Because if the packager want to push their update, they will need to
> investigate why it's not passing the tests, not infra.

Definitely, that's my point too. I'd expect it working that way
already, with or without gating. People should be responsible for
changes they do in their packages (generally speaking, I do not mean
any offense to systemd folks, not talking that I can imagine that
finding such kind of bugs is a nightmare even for the developers of the
software).

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

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 know, that's why I wrote "it also used to work". I also used to
be kicked off when trying chain-build after bodhi activation (something
about "fXX-candidate not deriving from fXX-build", but I do not recall
it precisely), which seems to be accepted right now, except after the
build of the first package the next in the chain would wait "ad
infinity" to have the first package appear in f28-build.

It's only that `koji cancel` doesn't work here (with python3, it does
when using python2), thus it took me longer to find out what to do to
stop the previous chain build, mark the one finished package with
proper tag and start the chain-build in the side tag.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gating packages in Rawhide

[Milan Crha]

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

well, it's not better, it's worse. I could not just run one command and
let the computers do the task on their own, I just check from time to
time whether anything broken, but I'd be supposed to babysit whole
build process with the packages from the "chain-build"? That's truly
worse, needs more of my time, while the koji can do it on its own.
Computers are here to help people, right? :) 

By the way, I just successfully ran chain-build from an f28 branch. 
https://koji.fedoraproject.org/koji/taskinfo?taskID=25654934
That surprised me, I expected to be kicked of, as it used to do, but it
didn't do it (it used to kick me off in the past, especially after
branching/bodhi activation point). I wanted to try whether chain-build
with --target would make the trick, it also used to work.

> I'd like to see a 'no new broken deps' test/check... but we could
> change the tests over time.

Yeah, that's it, without such test you just make obstacles to packagers
with no gain at all (if broken deps are recognized only after pushing
the side tag into the Rawhide, then it's really only about unneeded
obstacles).

> You request a side tag,

Who is going to respond to it? Will it be automated, with no specific
people being involved? Automated side tags sound wrong, from my point
of view. Hunting for people in different timezones to let me do my duty
 sounds even worse.

> build your new package in that, then tell all the dependent package
> maintainers to use that side tag to rebuild all their packages.

Oh, having multi-process synchronization is kind of unsolvable problem
(if I recall my college study properly), how you'd like to synchronize
the process between people in various countries and time zones in
practice, while limiting the delay to a minimum?

> All those people should be watching your package or at
> least easy to communicate to.

Watching a package and/or have commit rights usually brings in tons of
unrelated stuff in your Inbox. Yes, there are settings, but I cannot
decide which changes are relevant to my package and which not unless I
read the info about the change. After some time one can just ignore
most of the messages anyway (people do lack of time, the more those
volunteers in the community).

> > That's also another disadvantage of the gating. I recall seeing
> > broken dependencies messages for package I've no commit rights for
> > for weeks.
> 
> Yep. Or longer.

Definitely, and it's the main point against gating Rawhide. If people
cannot react in the timely manner right now, with already working
infrastructure, how is the gating going to help and address this
problem at the first place?

The gating will help to have buildable composes all the time. That's
its main purpose, right? Then it'll help with what? What is it good for
to have buildable composes, when they are using outdated software? All
the QA work will be wasted on those composes, because of delay of some
package update due to the gating.

> You could ask for commit on those packages you need commit on.
> If those maintainers don't approve it, ask for unresponsive
> maintainer process and you will get commit rights.

Maybe they have a reason why they want to have as less people on the
package as they can. Or they can miss some notification from "pkgdb" (I
know, it's not pkgdb these days) or have it lost in the spam folder...
And it's a bad idea to expect that other people have time to work on
Fedora just at the moment when I decide to push in some giant API
change, not talking that many of the packagers just do "proxies" for
upstream, they possibly never touched the upstream code to be able to
fix anything in the code, thus they rely on response from the upstream,
which can add even more delay in some cases. Not talking that
unresponsive maintainer process should be started only after some time
of inactivity of the package maintainer.

> If they still don't show up, you could look at retiring those
> packages so they drop from the collection and don't bother you
> anymore.

Oh, I'd not like to go that far, for basically the same reasons as in
the previous paragraph.

> It's been a long trail of things that needed to get worked out.
> it has nothing to do with availability. A number of people have been
> spending lots of time fixing things.

I see, that's understandable. How is rawhide gating going to help with
this in practice? (Search for 'outdated software' above.) There will be
still needed some people looking into the issue and spend their time on
it, maybe they will be in less pressure, but I'm afraid it'll be just a
feeling. Nobody should expect infrastructure folks understand each
package (like you mentioned systemd here), at least I 

Re: Gating packages in Rawhide

[Milan Crha]

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 chain-build from fedpkg,
right? It's kind of pain it doesn't work for stable, but if you want to
get rid of it for rawhide too, or add some unnecessary obstacles for
its usage, then it's a downgrade like the kerberos usage (it's a pain
to write my password all the time when I want to do something in
packaging, with compare of once-per-year replace of the certificate,
but that's another story, which only adds to the feeling of making
process more and more painful instead of simpler (I heard some time ago
something like this "security by obscurity", with which I fully
agree)). I chain-build like this "A : B : C D", which means in stable
that I build A, then fill override, then I build B, then fill an
override, the I build C and D and then I fill the update. I hope the
difference in stable and chain-build usage is obvious.

Anyway, could you enlighten what you call "if all is ok"? That's pretty
important measure.

What do I do if it's not ok?

I do maintain a package which is in critpath. I'm not a proven
packager, thus I cannot touch anyone's package (I hesitate to do it
anyway, even there are cases where are not many other options). If my
critpath package changes API and soname versions, then other packages,
for which I do not have commit rights, will be broken by that update,
but the update as such will build and look just fine. What do I do now?
Will I hunt for respective maintainers and co-maintainers kindly asking
them to do something about it? The paper work around this (finding who
it is, their email addresses, writing them a mail) would be a pain on
its own, but more painful would be the delay in the delivery. It will
not be rawhide anymore, from my point of view.

I'd rather prefer to have detected issues in updates early (though it's
understandable that doing API/ABI checks after each package update is
not doable at least due to resource requirements - thus you'd not
detect it with the gating too, right?), or at least like once a day.

I did a soname version bump in one of my packages recently and
announced it, with a list of "possibly affected packages". I know my
work flow is wrong in this regard, but I kind of rely on the
notifications of broken dependencies to rebuild what is really needed
to be rebuilt, because the packages sometimes requires something bigger
in the build time, which is not actually used in the run time (just my
feeling, no prove available). I didn't receive any single notification
of broken dependencies this time. While it's possible someone was just
quicker than me, I believe it's highly unlikely. I also believe I
didn't filter out any such "broken dependencies" mail notifications
from my notification settings, they used to come in the past.

That's also another disadvantage of the gating. I recall seeing broken
dependencies messages for package I've no commit rights for for weeks.
Either the maintainer (or co-maintainer) didn't receive those messages
similar like me, or they just didn't care. How would I force them to
rebuild/correct (I am definitely willing to help to correct the
packages when an API change requires it) their packages, when they
already ignore/filter out broken dependencies notifications? Should I
hunt for a proven packager to move things forward, thus other packages
can rely on the provided change? Proven packagers have their own work
to do to, they cannot be disrupted from their work every other day by
hundreds of packages to help with the packages their update broke.

By the way, why was the compose of rawhide broken for several days?
Corresponding people/packagers not being available? It looks to me that
you just want to move the issue to a slightly upper level, but then
you'll have working rawhide compose, which will not use the
recent/bleeding code. It is, from my point of view, the main credit of
Rawhide, to be on the bleeding edge.

It would be very sad to turn Rawhide from 'package update' to 'people
hunt' task.

Just my opinion.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Milan Crha]

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, please? There
is no "Vetos" section on that page for it, neither I noticed anything
in a scratch build log I ran for rawhide, finished few minutes ago.
https://koji.fedoraproject.org/koji/taskinfo?taskID=25422190

Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Milan Crha]

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 more or less related to evolution itself only.
That means that a simple rebuild of affected packages should be enough,
but in case of any issue feel free to ask me for help.

The list of dependencies according to:
   # dnf repoquery --whatrequires evolution-data-server-devel --alldeps
follows:
   evolution
   folks
   maya-calendar
but it seems surprisingly low number of packages, because I know of
several others (like syncevolution, evolution-ews, evolution-mapi, ...)
which also depend of evolution-data-server.

I'll rebuild packages I've commit rights for myself, unless the main
maintainer(s) will be quicker.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Milan Crha]

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.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Milan Crha]

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 it's from 2001, but comes with a fresh timestamp and doesn't tell
> about the changes either.

Hi,
the sum of changes is part of the release notes, which can be found
here:
https://github.com/libical/libical/releases

> vcal_manager.c: In function 'vcal_manager_event_dump':
> vcal_manager.c:398:30: warning: implicit declaration of function
> 'icaltime_from_timet'; did you mean 'icaltime_as_timet'? [-Wimplicit-
> function-declaration]
>   icalproperty_vanew_dtstamp(icaltime_from_timet(time(NULL), TRUE),
> (void*)0));

In your case replace
   icaltime_from_timet()
with
   icaltime_from_timet_with_zone()
where the last argument, the zone to use, will be NULL.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org