Discussion:
asp checkout issue
Add Reply
Ralf Mardorf
2017-10-07 10:44:13 UTC
Reply
Permalink
Raw Message
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.

[***@archlinux ~]$ pacman -Q asp
asp 2-1
[***@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]
[***@archlinux ~]$ pkill -9 evolution
[***@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
[***@archlinux ~]$ cd /tmp/
[***@archlinux tmp]$ asp checkout evolution
[***@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/
Eli Schwartz
2017-10-08 05:44:53 UTC
Reply
Permalink
Raw Message
Post by Ralf Mardorf
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.
Post by Ralf Mardorf
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.)
Post by Ralf Mardorf
However, seemingly I found another bug or at least a sync issue for asp.
asp 2-1
[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]
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
[...]

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
Ralf Mardorf
2017-10-08 06:00:45 UTC
Reply
Permalink
Raw Message
Post by Eli Schwartz
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?
Ralf Mardorf
2017-10-08 06:09:11 UTC
Reply
Permalink
Raw Message
Post by Ralf Mardorf
Post by Eli Schwartz
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.

[***@archlinux tmp]$ asp checkout evolution
Cloning into '/tmp/evolution'...
done.
[***@archlinux tmp]$ grep _commit= evolution/trunk/PKGBUILD
_commit=8acce30a4c862690b3e84107d598c61671acb54c # tags/EVOLUTION_3_24_5^0
[***@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
[***@archlinux tmp]$ rm -r evolution/
[***@archlinux tmp]$ asp checkout evolution
Cloning into '/tmp/evolution'...
done.
[***@archlinux tmp]$ grep _commit= evolution/trunk/PKGBUILD
_commit=0e2e5a895434b8a671a59c5a14260877ac4b1f77 # tags/EVOLUTION_3_26_1^0
Loading...