dbscripts issueshttps://gitlab.archlinux.org/archlinux/dbscripts/-/issues2024-01-01T11:12:59Zhttps://gitlab.archlinux.org/archlinux/dbscripts/-/issues/51"No such file or directory" error on db update2024-01-01T11:12:59ZChristian Heusel"No such file or directory" error on db updateThe update went through regardless, but either there is a wrong code path or the error message should be suppressed:
```
$ pkgctl db update
realpath: /srv/repos/pkg-cache/openmpi/.git/dbscripts.lock: No such file or directory
Fro...The update went through regardless, but either there is a wrong code path or the error message should be suppressed:
```
$ pkgctl db update
realpath: /srv/repos/pkg-cache/openmpi/.git/dbscripts.lock: No such file or directory
From https://gitlab.archlinux.org/archlinux/packaging/packages/openmpi
fea2f1a..30aa794 main -> main
* [new ref] refs/merge-requests/1/head -> refs/merge-requests/1/head
* [new ref] refs/merge-requests/1/merge -> refs/merge-requests/1/merge
* [new ref] refs/merge-requests/2/head -> refs/merge-requests/2/head
* [new ref] refs/merge-requests/2/merge -> refs/merge-requests/2/merge
* [new tag] 4.1.6-1 -> 4.1.6-1
==> Updating [extra-testing]...
-> openmpi-4.1.6-1-x86_64.pkg.tar.zst (x86_64)
-> openmpi-debug-4.1.6-1-x86_64.pkg.tar.zst (x86_64)
[main f9b1ff683e] update openmpi to 4.1.6-1 in extra-testing-x86_64
1 file changed, 1 insertion(+)
create mode 100644 extra-testing-x86_64/openmpi
```https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/50repos in package cache missing group permissions2023-12-11T09:49:42ZChristian Heuselrepos in package cache missing group permissionsToday it was reported that db update fails because of a permission error:
```
09:32 felixonmars | any idea what went wrong with my db-update?
09:32 felixonmars | error: cannot open 'FETCH_HEAD': Permission denied
09:32 felixonmars | ==> ...Today it was reported that db update fails because of a permission error:
```
09:32 felixonmars | any idea what went wrong with my db-update?
09:32 felixonmars | error: cannot open 'FETCH_HEAD': Permission denied
09:32 felixonmars | ==> ERROR: Couldn't find package nodejs-lts-iron in git!
```
It turns out this most likely is because missing group permissions to update the package repo in the package cache (`/srv/repos/pkg-cache/nodejs-lts-iron`):
```
-rw-r--r-- 1 jelle users 441 Nov 22 18:33 FETCH_HEAD
```
I have also checked since when this seems to happen so its maybe easier to find the root cause of the bug:
```
$ find . -perm 644 -name FETCH_HEAD -print | xargs stat --print="%w %n\n" | sort
2023-10-25 17:37:29.043251287 +0000 ./zix/FETCH_HEAD
2023-10-28 19:27:29.735538204 +0000 ./apprise/FETCH_HEAD
2023-10-29 14:29:55.417919112 +0000 ./goverlay/FETCH_HEAD
2023-10-30 16:09:27.823707185 +0000 ./gitleaks/FETCH_HEAD
2023-10-31 10:11:26.522466459 +0000 ./bcachefs-tools/FETCH_HEAD
2023-11-01 10:48:33.764486260 +0000 ./kirigami-addons5/FETCH_HEAD
2023-11-10 09:38:51.854762032 +0000 ./kgamma/FETCH_HEAD
2023-11-10 09:38:51.961428993 +0000 ./kglobalacceld/FETCH_HEAD
2023-11-10 09:38:54.021434691 +0000 ./ocean-sound-theme/FETCH_HEAD
2023-11-10 09:38:56.164773952 +0000 ./plasma5support/FETCH_HEAD
2023-11-10 09:38:57.058109756 +0000 ./wacomtablet/FETCH_HEAD
2023-11-11 19:00:35.868140547 +0000 ./monaspace-font/FETCH_HEAD
2023-11-12 17:15:34.777408692 +0000 ./haskell-attoparsec-aeson/FETCH_HEAD
2023-11-13 21:40:14.180351014 +0000 ./ollama-cuda/FETCH_HEAD
2023-11-14 00:20:31.717840277 +0000 ./materialx/FETCH_HEAD
2023-11-15 17:26:40.382571814 +0000 ./mirro-rs/FETCH_HEAD
2023-11-15 20:37:13.735232865 +0000 ./analitza5/FETCH_HEAD
2023-11-15 20:56:11.865410143 +0000 ./python-openai/FETCH_HEAD
2023-11-16 23:52:17.459694970 +0000 ./fast_float/FETCH_HEAD
2023-11-18 13:26:25.336611154 +0000 ./python-jsonschema-path/FETCH_HEAD
2023-11-20 01:35:50.994965763 +0000 ./usd/FETCH_HEAD
2023-11-20 06:23:44.411885916 +0000 ./deepin-desktop-theme/FETCH_HEAD
2023-11-22 16:21:47.439397215 +0000 ./rdfind/FETCH_HEAD
2023-11-22 17:20:04.078106662 +0000 ./wlroots0.16/FETCH_HEAD
2023-11-23 15:51:56.196217188 +0000 ./python-simple-term-menu/FETCH_HEAD
2023-11-23 21:47:11.702677062 +0000 ./jupyterlab-pygments/FETCH_HEAD
2023-11-24 23:42:20.110601381 +0000 ./toot/FETCH_HEAD
2023-11-25 23:08:50.876727118 +0000 ./libakonadi5/FETCH_HEAD
2023-11-26 13:05:21.673141994 +0000 ./grantleetheme5/FETCH_HEAD
2023-11-26 13:08:08.600383663 +0000 ./akonadi-contacts5/FETCH_HEAD
2023-11-26 13:09:41.714037351 +0000 ./akonadi-notes5/FETCH_HEAD
2023-11-26 13:12:06.314534414 +0000 ./kpimtextedit5/FETCH_HEAD
2023-11-26 13:13:52.884900485 +0000 ./kmime5/FETCH_HEAD
2023-11-26 13:15:10.885165425 +0000 ./kontactinterface5/FETCH_HEAD
2023-11-26 17:18:41.758236858 +0000 ./python-nethsm-sdk-py/FETCH_HEAD
2023-11-28 02:39:49.649037609 +0000 ./esbonio/FETCH_HEAD
2023-11-29 00:20:54.748686893 +0000 ./js80p/FETCH_HEAD
2023-11-29 01:23:14.593773377 +0000 ./go-task/FETCH_HEAD
2023-11-29 19:45:55.549878741 +0000 ./libplasma/FETCH_HEAD
2023-11-29 19:45:56.586549268 +0000 ./plasma-activities/FETCH_HEAD
2023-11-29 19:45:56.679882949 +0000 ./plasma-activities-stats/FETCH_HEAD
2023-11-30 07:11:44.607084898 +0000 ./isoimagewriter/FETCH_HEAD
2023-11-30 07:12:53.464013607 +0000 ./mimetreeparser/FETCH_HEAD
2023-11-30 16:59:21.473707816 +0000 ./kunifiedpush/FETCH_HEAD
2023-11-30 23:20:48.299276357 +0000 ./kidentitymanagement5/FETCH_HEAD
2023-12-01 07:54:09.167608636 +0000 ./ot-urchin/FETCH_HEAD
2023-12-01 21:56:14.971799424 +0000 ./talosctl/FETCH_HEAD
```
---
cc @felixonmarshttps://gitlab.archlinux.org/archlinux/dbscripts/-/issues/47do not treat any packages specially2023-10-23T23:24:45ZLevente Polyakanthraxx@archlinux.orgdo not treat any packages speciallySomething like `any` does not exist in the concept of pacman repositories as they are linked to all binary repos. The current implementation of having specific `any` directories in the state repo creates more havoc and implementation com...Something like `any` does not exist in the concept of pacman repositories as they are linked to all binary repos. The current implementation of having specific `any` directories in the state repo creates more havoc and implementation complexity while not gaining much with this distinction - and even loosing the overview in the state repo where exactly any packages are or aren't.
Remove `any` directories and just keep track of multiple entries like native packages.https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/46track all split pkgname in state repo2024-02-29T15:23:06ZLevente Polyakanthraxx@archlinux.orgtrack all split pkgname in state repoThis is a suboptimal implementation currently to only track the pkgbase. We should instead track all current pkgname so we can detect changes (like removed pkgname from a split package).This is a suboptimal implementation currently to only track the pkgbase. We should instead track all current pkgname so we can detect changes (like removed pkgname from a split package).https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/41db-foo: Permanently adding bash -x tracing2023-07-25T22:44:25ZMantas Mikulėnasdb-foo: Permanently adding bash -x tracingRelated to the "db-move crashed halfway" issue in IRC yesterday:
`14:43 (anthraxx|M) grawity: can you open an issue and dump the info in there.`
Instead of "hold on let me reproduce with bash -x", the `-x` tracing could be permanently ...Related to the "db-move crashed halfway" issue in IRC yesterday:
`14:43 (anthraxx|M) grawity: can you open an issue and dump the info in there.`
Instead of "hold on let me reproduce with bash -x", the `-x` tracing could be permanently enabled and redirected to a file using `BASH_XTRACEFD` so that it will not clutter stderr during normal operation, but still leaves trace files in case the script dies unexpectedly.
1. Open a file descriptor for the log file, set `BASH_XTRACEFD` to its fd number:
```bash
exec {BASH_XTRACEFD}>> "$HOME/dbscripts.trace"
```
or with a hand-picked fd number:
```bash
exec 42>> ~/dbscripts.trace
BASH_XTRACEFD=42
```
(My original idea was to deliberately keep writing to the same trace file, so that if one script invokes another the result will be a linear trace instead of several split files, but OTOH that might be undesirable. Still, `mktemp` randomization seems unnecessary, `$HOME/dbscripts-$$.trace` should do the job.)
2. Also have the scripts set their `PS4` to something fancy, in order to log not just the command but also the origin file:line:function.
```bash
PS4='+\e[34m${BASH_SOURCE:--}:\e[1m$LINENO\e[m:${FUNCNAME:+\e[33m$FUNCNAME()\e[m} '
```
3. Actually enable tracing:
```bash
set -x
```
Foxboron's patch from yesterday:
```diff
diff --git a/db-functions b/db-functions
index 35f080c..18f6f78 100644
--- a/db-functions
+++ b/db-functions
@@ -547,3 +547,9 @@ check_reproducible() {
}
. "$(dirname "$(readlink -e "${BASH_SOURCE[0]}")")/db-functions-${VCS}"
+
+if ((DBSCRIPTS_TRACE)); then
+ PS4='+\e[34m${BASH_SOURCE:--}:\e[1m$LINENO\e[m:${FUNCNAME:+\e[33m$FUNCNAME\e[m} '
+ exec {BASH_XTRACEFD}>>"/tmp/dbtrace-$USER.trace"
+ set -x
+fi
```https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/33db-update sometimes exits successfully without really updating anything while...2023-10-21T15:12:59ZFelix Yanfelixonmars@archlinux.orgdb-update sometimes exits successfully without really updating anything while uploading something else to staging folderI used to add a local lock for this so that I don't run multiple db-update instances at the same time myself. But after git migration it seems reproducible (very rarely) even with the lock.
I'll try to remove the lock again and supply s...I used to add a local lock for this so that I don't run multiple db-update instances at the same time myself. But after git migration it seems reproducible (very rarely) even with the lock.
I'll try to remove the lock again and supply some logs when I encounter this again.https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/25Ensure unsafe checksum algorithms can't be commited to the repository2022-11-14T21:32:19ZMorten Linderudfoxboron@archlinux.orgEnsure unsafe checksum algorithms can't be commited to the repositoryThis list should contain a couple:
- `md5sums`This list should contain a couple:
- `md5sums`https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/24Add a test case for python-flask-debug package2021-12-17T12:45:06ZJelle van der WaaAdd a test case for python-flask-debug packageMake sure that the `python-flask-debug-debug` package is handled as debug package while the python-flask-debug package is not.Make sure that the `python-flask-debug-debug` package is handled as debug package while the python-flask-debug package is not.https://gitlab.archlinux.org/archlinux/dbscripts/-/issues/23Cleanup debug packages2021-12-17T08:17:53ZJelle van der WaaCleanup debug packagesIf you update a package *without* debug symbols the old debug package will stay there.If you update a package *without* debug symbols the old debug package will stay there.