Re: [arch-dev-public] Arch monthly report December 2021
On 7/12/21 04:32, Levente Polyak via arch-dev-public wrote: ## Devtools A new devtools version 20211129 has been released [7]. The new devtools package is waiting in [staging] for the python 3.10 rebuild to finish in order to avoid additional hassle with an already cumbersome rebuild. LTO has additionally been enabled is this release as the issues should be easy to spot and extremely simple to work around by just setting an `options` knob inside the PKGBUILD. I have been using the updated devtools package locally for for a couple of weeks. No issues spotted. Cheers, Allan
Re: [arch-dev-public] Arch monthly report December 2021
On Tue, Dec 21, 2021 at 08:04:18PM +1000, Allan McRae via arch-dev-public wrote: > On 7/12/21 04:32, Levente Polyak via arch-dev-public wrote: > > ## Devtools > > > > A new devtools version 20211129 has been released [7]. The new devtools > > package is waiting in [staging] for the python 3.10 rebuild to finish in > > order to avoid additional hassle with an already cumbersome rebuild. > > > > LTO has additionally been enabled is this release as the issues should > > be easy to spot and extremely simple to work around by just setting an > > `options` knob inside the PKGBUILD. > > I have been using the updated devtools package locally for for a couple of > weeks. No issues spotted. please sign-off it. > Cheers, > Allan -- Sincerely, Alexander | Trusted User signature.asc Description: PGP signature
Re: [arch-dev-public] community.files pacman database corrupt
Hi all,
seems to have happened again: the desc file of lxqt-runner had 0
bytes. I re-added the package. I got the following output. I did not
get the "...was not locked" message when trying again. Maybe our
locking does not work as expected:
==> ERROR: Repo [community] (x86_64) is already locked by
repo-{add,remove} process 2150481
==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
-> Retrying in 10 seconds...
==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
==> WARNING: Repo lock [community] (x86_64) was not locked!
Greetings,
Pierre
On Mon, Aug 30, 2021 at 11:56 PM David Runge wrote:
>
> On 2021-08-30 22:35:39 (+0200), Pierre Schmitz via arch-dev-public wrote:
> > Thanks for looking into this. It's still weird but let's see if it
> > will happen again. I hope it wasn't a memory issue and we can just
> > blame Allan. ;-)
>
> Unfortunately this has happened before.
>
> On 2021-04-06 I noticed the same with python-pytesseract's files db entry
> - a package which had not been touched since February - due to work on
> arch-repo-management (a pipeline started failing on validating the
> package database [1]).
>
> The package was bumped [2] and the corrupted files db entry was
> replaced.
>
> I have uploaded the community.files database with the corrupted entry
> [3] if anyone is interested.
>
>
> [1]
> https://gitlab.archlinux.org/archlinux/arch-repo-management/-/pipelines/6208
> [2]
> https://github.com/archlinux/svntogit-community/commit/0a9473072bc114cfbefe43c92acbf245dccdc980#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a
> [3] https://pkgbuild.com/~dvzrv/bugs/2021/04/community.files
>
> --
> https://sleepmap.de
--
Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] community.files pacman database corrupt
On Tue, Dec 21, 2021 at 05:43:44PM +0100, Pierre Schmitz via arch-dev-public
wrote:
> Hi all,
>
> seems to have happened again: the desc file of lxqt-runner had 0
> bytes. I re-added the package. I got the following output. I did not
> get the "...was not locked" message when trying again. Maybe our
> locking does not work as expected:
>
> ==> ERROR: Repo [community] (x86_64) is already locked by
> repo-{add,remove} process 2150481
> ==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
> -> Retrying in 10 seconds...
> ==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
> ==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
> ==> WARNING: Repo lock [community] (x86_64) was not locked!
So I'm a little bit unsure what is expected behaviour and what isn't.
I have an annotated version of the log with what happens in the above log
output. Note that the tacke on -debug repositories is what was added last week.
* db-repo-add gets ran
* runs `repo_lock` -> `_repo_lock community`, `_ repo_lock community-debug`
==> ERROR: Repo [community] (x86_64) is already locked by repo-{add,remove}
process 2150481
* `_repo_lock` checks if the `community.db.lck` exists.
* this file is created by repo-add/repo-remove.
* `_repo_lock` return 1, this exit code is never checked
* Note that we never locked anything. We returned early.
==> WARNING: Repo [community-debug] (x86_64) is already locked by svenstaro.
-> Retrying in 10 seconds...
* same is done for `community-debug`
* we don't have `community.db.lck` so we continue
* timeout happens because svenstaro is modifying the repository
* we lock `community-debug`
* `_repo_lock` returns 0, exit code is never checked
==> Adding lxqt-runner-1.0.0-1-x86_64.pkg.tar.zst to [community]...
==> WARNING: An entry for 'lxqt-runner-1.0.0-1' already existed
* We continue adding package
* We run `repo_unlock` -> `_repo_unlock community`, `_repo_unlock
community-debug`
==> WARNING: Repo lock [community] (x86_64) was not locked!
* `_repo_unlock` checks if `community` is locked.
* It isn't, return and give warning
* `_repo_unlock` unlocks `community-debug`
* unlocked properly and returns
I'm not sure if this is new behaviour. It seems like most of this workflow was
there before my debug package implementation. But I'm not sure if this is the
actual root of the bug?
Does anyone know if `repo-add` and `repo-remove` maybe doesn't have proper lock
checking? Could there be a race here?
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
[arch-dev-public] News draft: libxml2>=2.9.12-6 update may require manual intervention
The libxml2 package prior to version 2.9.12-6 was missing the compiled python modules. This has been fixed in 2.9.12-6, so the upgrade may need to overwrite any untracked pyc files created. If you get errors like these libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/drv_libxml2.cpython-310.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.opt-1.pyc exists in filesystem libxml2: usr/lib/python3.10/site-packages/__pycache__/libxml2.cpython-310.pyc exists in filesystem when updating, use pacman -Suy --overwrite /usr/lib/python3.10/site-packages/__pycache__/\* to perform the upgrade.
