Hi, it became impossible to use Evolution's search folders. If software is buggy I usually report it to upstream, seldom to the Arch bug tracker. This is always done with a description of the issue and if possible, how to reproduce it. This month I'm very short in time, so after making the below investigation [1], I've got no time to describe the problem any further, let alone to report the issue to a bug tracker. Take a look at https://bugs.archlinux.org/task/53840 , since this is the reason for the investigation. However, seemingly I found another bug or at least a sync issue for asp. [rocketmouse@archlinux ~]$ pacman -Q asp asp 2-1 [rocketmouse@archlinux ~]$ grep evolution /var/log/pacman.log | tail -4 [2017-10-07 07:37] [ALPM] upgraded evolution-data-server (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution-bogofilter (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution-spamassassin (3.24.5-1 -> 3.26.1-1) The update was done nearly 1/4 day before I run asp checkout, so I expected that everything should be in sync. Regards, Ralf [1] [rocketmouse@archlinux ~]$ pkill -9 evolution [rocketmouse@archlinux ~]$ pacman -Q evolution{,-data-server,-bogofilter,-spamassassin} evolution 3.26.1-1 evolution-data-server 3.26.1-1 evolution-bogofilter 3.26.1-1 evolution-spamassassin 3.26.1-1 [rocketmouse@archlinux ~]$ cd /tmp/ [rocketmouse@archlinux tmp]$ asp checkout evolution [rocketmouse@archlinux tmp]$ grep _commit= evolution/trunk/PKGBUILD _commit=8acce30a4c862690b3e84107d598c61671acb54c # tags/EVOLUTION_3_24_5^0 "5 days ago EVOLUTION_3_26_1 Tag 3.26.1 release 0e2e5a8 zip tar.gz [snip] on Aug 7 EVOLUTION_3_24_5 8acce30 zip tar.gz" - https://github.com/GNOME/evolution/releases "Last Updated: 2017-10-06 12:08 UTC" - https://www.archlinux.org/packages/extra/x86_64/evolution/
On 10/07/2017 06:44 AM, Ralf Mardorf wrote:
If software is buggy I usually report it to upstream, seldom to the Arch bug tracker. This is always done with a description of the issue and if possible, how to reproduce it. This month I'm very short in time, so after making the below investigation [1], I've got no time to describe the problem any further, let alone to report the issue to a bug tracker.
So... you had enough time to investigate and draft an email to some at best tangentially related mailing list when you genuinely believe there is a software bug? What, were you hoping someone else will report the bug on your behalf??? Very polite of you.
Take a look at https://bugs.archlinux.org/task/53840 , since this is the reason for the investigation.
But maybe we don't care about researching some random bugtracker ticket just because you appealed to us on the mailing list with some unrelated problem. (I realize that as a Bug Wrangler this is somewhat ironic coming from me. Imagine I'm some other mailing list lurker though.)
However, seemingly I found another bug or at least a sync issue for asp.
[rocketmouse@archlinux ~]$ pacman -Q asp asp 2-1 [rocketmouse@archlinux ~]$ grep evolution /var/log/pacman.log | tail -4 [2017-10-07 07:37] [ALPM] upgraded evolution-data-server (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution-bogofilter (3.24.5-1 -> 3.26.1-1) [2017-10-07 07:37] [ALPM] upgraded evolution-spamassassin (3.24.5-1 -> 3.26.1-1)
The update was done nearly 1/4 day before I run asp checkout, so I expected that everything should be in sync.
Regards, Ralf
[1] [rocketmouse@archlinux ~]$ pkill -9 evolution [rocketmouse@archlinux ~]$ pacman -Q evolution{,-data-server,-bogofilter,-spamassassin} evolution 3.26.1-1 evolution-data-server 3.26.1-1 evolution-bogofilter 3.26.1-1 evolution-spamassassin 3.26.1-1 [rocketmouse@archlinux ~]$ cd /tmp/ [rocketmouse@archlinux tmp]$ asp checkout evolution
[...] I don't see where you actually used `asp update` to pull updates from the server, so I am assuming PEBKAC, aided by the fact that you have previously cached an old version of the evolution pkgbase. `asp update && cd /tmp/evolution && git pull` should do the trick FWIW. Also FWIW as long as you are giving us that nice step-by-step CLI walkthrough of the problem, there is no need to go off-tangent with your l33t pkill skillz (as a running instance of the program will not cause pacman -Q or asp to report different results, which is the usual conclusion when one goes to such efforts to document the usage of pkill to shut down said running instance), nor cross-reference your currently-installed version with your pacman logs with the version you've already asserted is on the website. (Having had it confirmed from three not-really-independent sources, I cannot help but feel pacman -Si would be somewhat more relevant here anyway.) -- Eli Schwartz
On Sun, 8 Oct 2017 01:44:53 -0400, Eli Schwartz wrote:
pacman -Q or asp to report different results
You could assume that I upgraded from official repositories, so if pacman -Q and the Arch website show the same higher version, we should assume to get no lower version by asp. If we run asp checkout in a clean /tmp and you could assume I did that, there should be no reason to run asp update and git pull after that, right?
On Sun, 8 Oct 2017 08:00:45 +0200, Ralf Mardorf wrote:
On Sun, 8 Oct 2017 01:44:53 -0400, Eli Schwartz wrote:
pacman -Q or asp to report different results
You could assume that I upgraded from official repositories, so if pacman -Q and the Arch website show the same higher version, we should assume to get no lower version by asp. If we run asp checkout in a clean /tmp and you could assume I did that, there should be no reason to run asp update and git pull after that, right?
My bad, a misunderstanding. So reading the manpage and a test confirmed it. [rocketmouse@archlinux tmp]$ asp checkout evolution Cloning into '/tmp/evolution'... done. [rocketmouse@archlinux tmp]$ grep _commit= evolution/trunk/PKGBUILD _commit=8acce30a4c862690b3e84107d598c61671acb54c # tags/EVOLUTION_3_24_5^0 [rocketmouse@archlinux tmp]$ asp update ==> updating remote 'packages' remote: Counting objects: 86, done. remote: Compressing objects: 100% (81/81), done. remote: Total 86 (delta 21), reused 50 (delta 3) Unpacking objects: 100% (86/86), done. From git://git.archlinux.org/svntogit/packages * branch packages/ardour -> FETCH_HEAD * branch packages/claws-mail -> FETCH_HEAD * branch packages/evolution -> FETCH_HEAD * branch packages/firefox -> FETCH_HEAD * branch packages/pam -> FETCH_HEAD * branch packages/xorg-xclock -> FETCH_HEAD 20f0c17..c5d5914 packages/ardour -> packages/packages/ardour d2a5c51..7ecc5e3 packages/claws-mail -> packages/packages/claws-mail 7810241..823a902 packages/evolution -> packages/packages/evolution ==> updating remote 'community' remote: Counting objects: 20, done. remote: Compressing objects: 100% (15/15), done. remote: Total 20 (delta 6), reused 14 (delta 3) Unpacking objects: 100% (20/20), done. From git://git.archlinux.org/svntogit/community * branch packages/guitarix2 -> FETCH_HEAD * branch packages/jack2 -> FETCH_HEAD * branch packages/virtualbox -> FETCH_HEAD 67ede2b..00595a9 packages/guitarix2 -> community/packages/guitarix2 [rocketmouse@archlinux tmp]$ rm -r evolution/ [rocketmouse@archlinux tmp]$ asp checkout evolution Cloning into '/tmp/evolution'... done. [rocketmouse@archlinux tmp]$ grep _commit= evolution/trunk/PKGBUILD _commit=0e2e5a895434b8a671a59c5a14260877ac4b1f77 # tags/EVOLUTION_3_26_1^0
participants (2)
-
Eli Schwartz
-
Ralf Mardorf