Arch Linux

pacman-db-upgrade broke packages whose 'files' (file) contains %BACKUP%
for example %BACKUP% is right on the next line after %FILES% as if some kind of sorting happened. And this causes pacman -Qo and -Ql to not see any files and thus attempting to upgrade/downgrade those affected packages causes `exists in filesystem` for each file.
This happened after I upgraded from commit d9cf14ff1d69ac8834b84015c7971f55ce77645b
to commit(latest currently): 7ee01c86669327b2af63c8ed9390bcbf071cdac5

Ok someone(demize) just notified me of this:
https://lists.archlinux.org/pipermail/pacman-dev/2014-October/019422.html

but may be worth to know if someone else if about to update from this

that pacman-git bug is tracked here: https://bugs.archlinux.org/task/41862

Looks like noextract option inside PKGBUILD prevents that file from being softlinked into ${srcdir} and thus the need to use ${SRCDEST} to access it.
As an example of this try chromium-dev package.
Tested with: Pacman v4.1.2-406-g3e19-dirty - libalpm v8.0.2
Without noextract it is symlinked, with noextract it isn't.

Pacman 4.1.0 in [testing] since today.

@maggie: I believe Allan was targeting the Easter weekend for 4.1's release but likely to [testing]. I took a stab at a PKGBUILD for pacman-git that will work with the current 4.0.3 series:

https://gist.github.com/graysky2/5281746

Dave - feel free to check my math :p

@j - That needs to be captured in the PKGBUILD somehow, versioned dependency or at the very least, a comment.

@graysky: May I guess? 1) This is AUR and a GIT PKGBUILD is development-based; 2) Once you install pacman-git, eventual PKGBUILD updates will require the current format, otherwise will fail; -- anyway, one just have to follow the migration task using Allan's pkg tarball and it is all done.

@dave - why would you post a PKGBUILD that depends on development software to the AUR if what the previous poster said is true?

@maggie: Are you trying to install this package with pacman 4.0.3 ? I had this problem too and @RunningDroid's answer helped me - you need 4.1.0rc installed to support urls from VCS, like GIT.

I get errors when building: ==> ERROR: pkgver is not allowed to contain colons, hyphens or whitespace.

When I change the pkgver to remove the -32: ==> ERROR: There is no agent set up to handle git URLs. Check /etc/makepkg.conf.

@falconindy Can you please make this package build latest git rather than point to a static tarball? I do not know enough about it to do it myself. Your commands are different from standard git packages. Thank you.

@josephgbr You should use one of the packages here to add the features you need to install pacman-git: http://allanmcrae.com/2013/03/pacman-4-1-0rc1/

@falconindy Can you add fakechroot as a checkdepends, enough tests fail without it that makepkg --check fails.

Can someone please point me out how to get over the current lack of GIT download agent for this package?

I'm translating pacman and, therefore, willing to test the translations. I'm not normally a user of this package, so I'm not following changes here, but I understand and read about changes in download methods, and now it fails to build as expected. Please help me on this subject?

If you depend on http access:
source=('git+http://projects.archlinux.org/git/pacman.git')

Bleh, yeah. Fixed. Didn't want to clobber my existing clone when testing.

The repo is cloned to "pman", not "pacman". This is a typo, no?

You're welcome. Please don't mark this out of date because the provides array is "wrong".

Thanks for the update

Please, as RetroX mentions, do add the version to the provides array

Please change the "provides" option in the PKGBUILD for the pacman-git package to pacman=4.0.

This isn't the place for such reports. Bring this to the bug tracker.

I have a problem.
On 64 bit everything still works fine but on my 32 bit netbook I got a problem with installing or upgrading packages.

"pacman -Suu --debug" ("pacman -S" too) gives
http://aur.pastebin.com/1AEGeR4K

I am pretty sure that I am not "out of memory"...

Here the culprit got introduced:
http://mailman.archlinux.org/pipermail/pacman-dev/2011-February/012402.html

I don't know the code of pacman but there seems to be another reason that _alpm_pkghash_create(est_count * 2) returns NULL. Before that commit (03.02.2011) it worked fine, after the commit (08.02.2011) it doesn't, though I have not checked yet if _alpm_pkghash_create returned NULL before.

Expected behavior. Please subscribe to pacman-dev if you are to be using this package.

Some of the repos have only <repo-name>.db.tar.gz and no <repo-name>.db . pacman-git does not recognize those repos (see https://bbs.archlinux.org/viewtopic.php?pid=878575#p878575 ). Is this a bug or a design change in the pacman git version?

Please make sure you run pacman-db-upgrade to update your local DB to the new pacman 3.5 format, otherwise your local DB will not be recognized properly.

Well, there's a bigger issue with the db-upgrade script -- you put in a check to see if pacman is running. If this is intended to be run as part of an install scriptlet, there's going to be a lot of broken databases. Pulling it out for now.

I'm not sure the vercmp line in your install script works... comparing the version to 3.5.0 will not work for the git package.

You might also want to add "--enable-git-version" to the configure line.