[arch-projects] [dbscripts] [GIT] Official repo DB scripts branch master updated. 20180603-6-g971181b

2018-10-07 Thread Eli Schwartz via arch-projects
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Official repo DB scripts".

The branch, master has been updated
   via  971181bf94d5e86bd7fce41303b51d1b3befc85b (commit)
   via  a75e4ee5b440a9d571658cd326f29a625320d777 (commit)
   via  e712811bcacd43ee443b98ad8a03347ce3a63b69 (commit)
  from  0b630e25a3181d5228cbd99c9041a04b6514fc81 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 971181bf94d5e86bd7fce41303b51d1b3befc85b
Author: Luke Shumaker 
Date:   Fri Jul 13 11:23:42 2018 -0400

test: checkPackageDB(): Resolve "FIXME: We guess the location of the 
PKGBUILD"

The problem statement:

  checkPackageDB and checkRemovedPackageDB need bit of information on the
  package they're checking: a full list of pkgnames with that pkgbase, the
  list of pkgarches, and (for checkPackageDB only) the full version.  In
  dbscripts itself, we can get that directly from the .db files; however,
  since the test suite is checking the ability of dbscripts to edit those
  .db files, that's obviously not a good solution.

  The current solution is to get this information from the PKGBUILD...
  which we also count on dbscripts to correctly keep track of.  Wait,
  that's skipping ahead, let's back up.

  The current solution is to get this information from the PKGBUILD.  For
  checkRemovedPackageDB, that's easy; we just get it from trunk, as that's
  the most up-to-date information on the package as-it-would-have-existed
  (if that sounded a little hand-wavey, it was).  But for checkPackageDB,
  it's a little trickier, because of 2 factors working together: (1) there
  might be different versions on different repos, and (2) unlike
  checkRemovedPackageDB, checkPackageDB actually cares about pkgver.  So,
  checkPackageDB "guesses" the location in a slightly sloppy way, and is
  tagged with a "FIXME".

What todo about it?

  There are a couple of things to observe:

   - Hidden in the hand-waving in assuming that "trunk" is fine for
 checkRemovedPackageDB is the assumption that neither pkgname=() nor
 arch=() is going to change between versions.  Which is a fine
 assumption, because we don't change those things between versions in
 any of our test cases.
   - We're counting on dbscripts correctly keeping track of which PKGBUILD
 is correct for which repo... which is one of the thing's we're trying
 to test, we shouldn't be counting on it.  That's actually a bigger
 problem than the original "FIXME"!

  So, putting those things together, let's (1) take the code under test out
  of the equation, and (2) remove any suggestion that the version of the
  PKGBUILD makes a difference to pkgnames/pkgarches: Let's have both
  functions that that information from the PKGBUILDs under "fixtures/",
  rather than getting PKGBUILDs from VCS.

  That just leaves one question: How to get the correct pkgver in
  checkPackageDB?  The obvious answer is: Each test case knows what the
  version should be; add it as an argument, and adjust every testcase that
  calls it.

commit a75e4ee5b440a9d571658cd326f29a625320d777
Author: Luke Shumaker 
Date:   Fri Jul 13 18:04:29 2018 -0400

test: Don't use "! cmd" except as the last statement in a function

With BATS setting up error traps, we get used to writing simple `[[ foo ]]`
assertions and not having to check the result.  However, using `!` to
invert the result DOESN'T trigger the trap.  It works OK when it is the
last command in a function, as it still affects the function's return
value, so then the trap triggers in the caller (rather than in the
function).  This means that a check may run successfully when it should
fail.

So, replace all uses of bare `! cmd` with `if cmd; then return 1; fi`,
unless it is the final statement in a function (as it is in
sourceballs.bats:__checkRemovedSourcePackage())

The mistake meant that checkRemovedPackage() was effectively equivalent to
checkRemovedPackageDB().  This meant that no one noticed that db-updates's
"add package with inconsistent name fails" test called checkRemovedPackage
instead of checkRemovedPackageDB.  Fixing the ! issue means that the test
now fails, so change which function it calls.

commit e712811bcacd43ee443b98ad8a03347ce3a63b69
Author: Luke Shumaker 
Date:   Thu Jun 21 22:01:54 2018 -0400

test: db-move: Verify that it works on single-arch packages

---

Summary of ch

[arch-projects] [archweb] [PATCH] Add “rel” attribute to pagination links

2018-10-07 Thread coderkun
Add the “rel” attribute for “prev” and “next” to the pagination links
of news and packages.
---
 templates/news/paginator.html| 4 ++--
 templates/packages/search_paginator.html | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/templates/news/paginator.html b/templates/news/paginator.html
index 57fbeb1..524c666 100644
--- a/templates/news/paginator.html
+++ b/templates/news/paginator.html
@@ -4,7 +4,7 @@
 
 {% if page_obj.has_previous %}
 < Prev
+title="Go to previous page" rel="prev">< Prev
 {% endif %}
 {% for num in paginator.page_range %}
 {% ifequal num page_obj.number %}
@@ -15,7 +15,7 @@
 {% endfor %}
 {% if page_obj.has_next %}
 Next >
+title="Go to next page" rel="next">Next >
 {% endif %}
 
 
diff --git a/templates/packages/search_paginator.html 
b/templates/packages/search_paginator.html
index a748d26..a676626 100644
--- a/templates/packages/search_paginator.html
+++ b/templates/packages/search_paginator.html
@@ -7,7 +7,7 @@
 
 {% if page_obj.has_previous %}
 < Prev
+title="Go to previous page" rel="prev">< Prev
 {% else %}
 < Prev
 {% endif %}
@@ -15,7 +15,7 @@
 
 {% if page_obj.has_next %}
 Next >
+title="Go to next page" rel="next">Next >
 {% else %}
 Next >
 {% endif %}
-- 
2.19.1