Pacman

Roadmap for version 5.2.2 Expand all | Collapse all

58% of 6 tasks completed. 4 open tasks:

FS#64648 - file:// sources not extracted automatically anymore Expand Collapse
makepkg used to automatically extract 7z archives in the source array, but it does not anymore. Looking at the git repository, it is unclear to me which change could have caused this, but it seems rather recent, since I was able to build https://aur.archlinux.org/packages/pianoteq-stage/ (where this was reported to me) on the 16th of October with pacman 5.1.3-1 and libarchive 3.4.0-2.
FS#65197 - Increase database size limit Expand Collapse
Description: After adding the chaotic-aur repository to /etc/pacman.conf, and receiving and signing the keys, pacman -Fy refuses to get the file list:

sudo pacman -Fy --verbose
--verbose
[sudo] password for matt:
Root : /
Conf File : /etc/pacman.conf
DB Path : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/ /etc/pacman.d/hooks/
Lock File : /var/lib/pacman/db.lck
Log File : /var/log/pacman.log
GPG Dir : /etc/pacman.d/gnupg/
Targets : None
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
multilib is up to date
valveaur is up to date
error: failed retrieving file 'chaotic-aur.files' from lonewolf-builder.duckdns.org : Maximum file size exceeded
error: failed retrieving file 'chaotic-aur.files' from chaotic.bangl.de : Maximum file size exceeded
error: failed retrieving file 'chaotic-aur.files' from chaotic.bangl.de : Maximum file size exceeded
error: failed retrieving file 'chaotic-aur.files' from repo.kitsuna.net : Maximum file size exceeded
error: failed to update chaotic-aur (download library error)
error: failed to synchronize all databases


I opened an issue on the chaotic-aur github page, and pedrohlc, the maintainer, thought it might be because he needed rebuild the repo, but after doing that he discovered that he ran into the same issue, and suggested that this must be a problem with Arch and that we need to file a bug report. I have a Manjaro installation on this same PC, and the repo works just fine in Manjaro with zero issues. After he rebuilt the repo, I tried again just in case, and the issue persists. If I download chaotic-aur.files myself and place it in /var/lib/pacman/sync, then it all works fine. Since the actual process of adding the repo to pacman.conf and receiving and signing the keys (as instructed on the arch wiki) works fine in Manjaro, this is upstream from that, and since Arch is responsible for pacman bugs and there's nothing upstream of Arch for pacman, this bug would fall under Arch's responsibility as per the Arch wiki. I'm more than happy to provide any needed info from either my Arch or Manjaro (in case you need to compare for some reason) installations. From what I read on the how to file a bug report article on the wiki, I figured this should be categorized as a Medium-level bug (non-essential broken function), however I apologize if I categorized it wrong.



Additional info:
* package version(s)
5.2.1-4

* config and/or log files etc.
will attach /etc/pacman.conf


Steps to reproduce:

Add the following to /etc/pacman.conf:
[chaotic-aur]
Server = http://lonewolf-builder.duckdns.org/$repo/x86_64
Server = http://chaotic.bangl.de/chaotic-aur/x86_64
Server = http://chaotic.bangl.de/$repo/x86_64
Server = https://repo.kitsuna.net/x86_64

Run the following:
sudo pacman-key --keyserver keys.mozilla.org -r 3056513887B78AEB
sudo pacman-key --lsign-key 3056513887B78AEB


Run:
sudo pacman -Syy

After which, run:

sudo pacman -Fy
..to get the package database. At that point, it will fail with the errors listed above. If, however, you add chaotic-aur.files to /var/lib/pacman/sync after it fails, and run it again, it will succeed.

Here is the link to the github issue page, if anyone needs it. Also, pedrohlc said that arch's own repo-add tool generated the db files in the first place. Anyhow, here's the github, and I'm more than happy to help however I can https://github.com/PedroHLC/chaotic-aur/issues/36

FS#66254 - Typo in pacman manpage Expand Collapse
Description:

Typo in pacman manpage:

"--asexplicit <package>
Mark a package as explicitly installed; in other words, set their install reason to be explicitly installed. This is useful it you want to keep a package installed even when it was initially installed as a dependency of another package."

The first it should be changed to if.

Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

FS#66680 - The Tratitional Chinese translation in makepkg uses unsupported Expand Collapse
Summary and Info:
The Traditional Chinese translation in makepkg uses unsupported printf format string.
In the zh_TW translation file of makepkg, some translations uses "%1$s" format to re-order the arguments, which isn't supported by bash's (5.0.16) builtin printf command.
For example, in scripts/po/zh_TW.po:

#: scripts/libmakepkg/source/file.sh.in:130
msgid "Extracting %s with %s"
msgstr "正在使用 %2$s 解壓縮 %1$s"

Steps to Reproduce:
Using pacman's PKGBUILD as example
$ export LC_ALL=zh_TW.UTF-8
$ makepkg -o
...
==> 正在解開來源...
/usr/share/makepkg/util/message.sh: line 67: printf: `$': invalid format character
-> 正在使用 ==> 正在啟動 prepare()...
...

Roadmap for version 6.0.0 Expand all | Collapse all

16% of 32 tasks completed. 27 open tasks:

FS#9694 - Universal transaction Expand Collapse
I mentioned this several times on ML, this task is a reminder and a place to discuss it.

So briefly, it would be nice if user could do the following in ONE command (== in one transaction):
* select some packages to install (-A/U)
* select some packages to remove (-R)
* select some packages to sync (-S)
* apply dependency/conflict resolving and replaces checking on request

Note: the current -S can already do all of these (except  FS#9088 ), so this is mainly a code refactoring request.

+ automatically  FS#9088 ,  FS#5798  and  FS#3492 
+ currently manual replaces is quite hackish: '-Rd foo then -U/S bar' is dangerous; '-S/U var then -R foo' doesn't work always (foo and bar doesn't conflict, but fileconflict) and isn't intuitive at all; doing this cleanly in one transaction is nice
+ we could focus to one transaction instead of three type of them (and the hard-to-follow transaction branch in case of sync)
- getopt() limitation

FS#12536 - pacman should report package versions when conflicts are detecte Expand Collapse
Description:

When a repository package conflicts with a local one, it would be very helpful if pacman would report both the versions instead of just reporting the conflict. For example I have libdrm-git installed and today another package requested libdrm to be installed from the repository upon -Syu (Which is a bit odd just like that anyways as libdrm-git is supposed to provide libdrm)

[root@Tachychineta | 14:25:48] # pacman -Syu
:: Synchronising package databases...
(...)
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
:: libdrm conflicts with libdrm-git. Remove libdrm-git? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: libdrm: conflicts with libdrm-git
[root@Tachychineta | 14:25:56] #

Problems with this output:
1.) I don't get to know WHY libdrm should be installed (pacman should report why it's a dependency all of a sudden)
2.) I don't get to know which VERSION of libdrm will be installed in contrary to which version my local package is providing (of course I can pacman -Ss libdrm to find this one out)

In my case, "something" needs libdrm to be installed for some unknown reason (as my libdrm-git package provides libdrm libdrm-git libdrm>=2.3.0 libdrm>=2.3.1 libdrm>=2.3 while the libdrm package is 2.3.1-2 and my git package would be perfectly fine.) Knowing which version of the original libdrm pacman wants and to install and which local package is already providing a (maybe) lower version would speed up the problem solving process.


FS#18193 - Pacman failed to find unused dependencies Expand Collapse
Linux linux 2.6.32-ice #1 SMP PREEMPT Mon Jan 11 04:50:15 CET 2010 i686 Intel(R) Pentium(R) M processor 1.73GHz GenuineIntel GNU/Linux
Pacman v3.3.3 - libalpm v4.0.3

pacman -Qdt returns too many false positives. (please look at attachment)


[mete@linux ~]$ pacman -Qm
gtkpod-git 20100119-1
ifuse 0.9.5-1
kotaci 0.6-1
libflashsupport-pulse 0-3
libgpod-kmaglione-git 20100119-1
libiphone 0.9.5-1
libplist 0.16-1
limewire 5.4.6-1
mplayer-svn 30226-1
shorewall 4.4.5-1
subtitlecomposer 0.5.3-2
usbmuxd 1.0.0-2
xine-lib-pulse 1.1.17-1

FS#20056 - [pacman] implement parallel transfers Expand Collapse
Summary and Info:
i'd like to see parallel transfers implemented directly in pacman. we can download two or more packages at the same time and we can also download each package from different mirror. we can also -Sy repo indexeses from all repositories parallely.

i know that there are some wrappers like powerpill, etc... but i don't like them much and i think that such feature should be implemented directly in pacman. pacman can use 3rd party binaries ("XferCommand") to download the packages and other files, so i believe that such commands can be run on background...

but clean output of pacman should be also preserved... eg.: apt-get is able to process more files parallely, but it looks like vomiting 50 litres of some ugly sh*t into the terminal. there should be some nice progress bar showing overall process and not leaving mess on screen or maybe there can be multiple progressbars (one for each running process). anyway the clean look of pacman output should be definitely preserved, but parallel transfers are really usefull feature...

peace
FS#21853 - cb_dl_progress cannot be initialized properly when resuming a fi Expand Collapse
dload.c does
handle->dlcb(filename, 0, ust.size);
even when we are resuming a file at a given offset, because that's the only way to tell cb_dl_progress to re-initialize its counters when we are starting a file download.

There are probably many ways to fix this, just unsure which one to choose :
1) track last filename in cb_dl_progress to detect new files and reset counters
2) add a parameter or abuse existing parameters (e.g. filename == NULL) to tell cb_dl_progress to reset
3) add a new callback function to reset or init a new file download at a given offset
FS#30286 - pacman-key --init hangs at "gpg: Generating pacman keychain mast Expand Collapse
Description:
After running pacman-key --init, the terminal will hang at
gpg: Generating pacman keychain master key
indefinitely with no output to the user.

In this forum post
https://bbs.archlinux.org/viewtopic.php?id=138684
many users confirm this happening, and a fix being "generating entropy" via running ls -R / in another terminal or by connecting and moving around a mouse while pacman-key --init is hanging. This input should be automated or it should be surfaced to the user that it is required.


Additional info:
* core/pacman 4.0.3-2 (base)


Steps to reproduce:
* with a fresh install of arch, run pacman-key --init
* notice that it hangs after the following output:

[root@(none) ~]# pacman-key --init
gpg:generating pacman keychain master key...


FS#31551 - Allow specifying paths without root prefix for -Qo Expand Collapse
Summary and Info:

When using testing ownership of a file inside an alternative root:
pacman -r /dir -Qo /path/to/file

it is requires that the full path - including the root prefix - is specified. Thus, this will not work:

pacman -r /root -Qo /etc/pacman.conf

We should test if the file is in the root and if not add the directory prefix.
FS#33076 - Misleading message: "Errors occurred, no packages were upgraded" Expand Collapse
When pacman aborts part way through a transation, it print this message, but some packages have been upgraded...
FS#33105 - All conflicts are reported as "conflicting dependencies" Expand Collapse
> pacman -S pacman
resolving dependencies...
looking for inter-conflicts...
:: pacman and pacman-git are in conflict. Remove pacman-git? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: pacman and pacman-git are in conflict


Not a dependency in site...
FS#34741 - Improve signature "failure" output Expand Collapse
e.g. with "SigLevel = Required" and an unsigned database:

error: failed to update xorg113 (invalid or corrupted database (PGP signature))
FS#38990 - Clarify IgnorePkg description Expand Collapse
Things not clear from the manual:
- space delimited
- can be specified multiple times
FS#43484 - Symbolic usernames in package Expand Collapse
Summary and Info:

Since you are checking file owners and mode setted in the packet agains the files installed on disk you should provide a way for symbolic username packing in PKGBUILD. I found a couple of packets which raise 'warning: directory ownership differs on ...' when updated (e.g. murmur, 16. JAN 2015). This happens when a user gets created on post_install() and direcotires in the packet (workdirs) are chown'ed to the newly created user. In this case the PKGBUILD can not know the exact uuid of the user on the target system but only a symbolic name. For further reading see attached chatlog.

Steps to Reproduce:

sudo pacman -S murmur
sudo pacman -S murmur



FS#45774 - pacman testsuite fails when /tmp is mounted noexec Expand Collapse
We require various things to run during testsuite. /tmp mounted noexec prevents this.
FS#46077 - [pacman] doesn't always tell which package is the one you own Expand Collapse
Summary and Info:

I just got this:

  resolving dependencies...
  looking for conflicting packages...
  error: unresolvable package conflicts detected
  error: failed to prepare transaction (conflicting dependencies)
  :: akonadi-qt4 and akonadi are in conflict

..which is great, but it never tells me which one is the new package (akonadi-qt4), and which is the one I have (akonadi).

Is it the same message when both are installed?
FS#47627 - pacman's 'import key' prompt does not stop installation from fai Expand Collapse
Summary and Info:

When installing a package with a never-imported key, pacman (uh, well, libalpm _alpm_key_import) will ask the user if the key should be imported. However, it still does not trust the imported key which (according to quininer (via tox tunnel) at #archlinux-cn@freenode.net) is responsible for a following "'<FILENAME>': invalid or corrupt package (PGP sig)" error.

If this is really caused by the key being untrusted, then pacman should use another message like `Signature from untrusted key blah blah .. continue?' instead of telling the user the package is broken.

I am not quite an Archlinux user, and some extra verification should be used on this report to make sure both quininer and I aren't wrong. @LastAvengers (via telegram tunnel) reported this error to quininer in #archlinux-cn@freenode.net, so you might be able to get extra info from them.

Steps to Reproduce:

1. Install a random package from third-party sources like archlinux-cn's. In this case the package filename appears to be 'ydcv-rs-git-0.3.1.55-1-x86_64.pkg.tar.xz'.
- In this case, the imported key wasn't able to get enough trust from the Web of Trust. A prompt should be added anyway.
2. Pacman should now ask you if you want to import the key. Y.
3. BOOM.

FS#49349 - [pacman] --hookdir should have more precedence over HookDir Expand Collapse
Currently in pacman-5.0.1, if HookDir is set in pacman.conf it takes more precedence over --hookdir option. I guess is a more expected bahavior if reverse this.
FS#51496 - The makepkg-template testsuite does not run under "make distchec Expand Collapse
SKIP: test/scripts/makepkg-template_test.sh
===========================================

cp: cannot stat '../../test/scripts/makepkg-template-tests': No such file or directory
find: ‘./makepkg-template-tests’: No such file or directory
1..0
SKIP: test/scripts/makepkg-template_test.sh
# All 0 tests successfully run.
FS#53770 - emptydirs runs too early Expand Collapse
Summary and Info:

The tidy_remove hooks are run in sorted-filename order. This means that, several other remove hooks are run after tidy_emptydirs (namely, tidy_libtools, tidy_purge, and tidy_staticlibs). Each of these may remove files, making a directory empty; and tidy_emptydirs would like to be able to remove them.

Steps to Reproduce:

Make the 'perl-mldbm' package from AUR. Note that despite the '!emptydirs' being included in options, that there are several empty directories under '/usr/lib'. This is because with the default PURGE_TARGETS value, tidy_purge wipes out every file that perl-mldbm places under '/usr/lib' ('.packlist', and '*.pod')

The obvious solution would be to put "NN-" prefixes on the tidy hook filenames, and give emptydirs.sh a high NN.
FS#59595 - failed to initialise alpm library: misleading error Expand Collapse
Summary and Info:

When failing to initialise alpm, pacman seems to always generate the message:

error: failed to initialise alpm library
(could not find or read directory: <dbpath>)

This happens even if the dbpath is unrelated to the error

Steps to Reproduce:

pacman --root /does/not/exist --dbpath /var/lib/pacman/

FS#61497 - Add a timestamp file to repos Expand Collapse
Even with signed repos (come on Arch!), people could delay updates to keep vulnerabilities from being fixed.

Our repos should contain a .TIMESTAMP file, that pacman reads. Then a config option that gives the maximum amount of time a repo is considered valid for.
FS#64394 - Switch to meson for buildsystem Expand Collapse
This bug is to record the current state of switching to meson for our build system.

Things I do with autotools that I can't with meson:

Outstanding:
* 'meson dist' does not distribute built manpages. I'm not keen on an asciidoc dep for release tarballs.

(not blockers)
* 'ninja uninstall' leaves behind lots and lots!


Fixed:
* make PY_LOG_FLAGS=--valgrind check
* make update-copyright OLD=2018 NEW=2019
* repo-add does not work in the build tree
* remove-remove does not get created in the build tree
* Expected Fail: 0 (some of our tests do have XFAILs)
FS#65677 - [makepkg] not all source files get included in debug packages Expand Collapse
Summary and Info:

We currently only look at the .debug_info section of readelf's output, finding DW_AT_name/DW_AT_comp_dir pair to grab file names. That gets the main compilation units, but misses header files. Header files can contain small functions, and so would be useful in debugging.

We can additionally look in the .debug_line section. This section has a table of directories that source files come from (which can be filtered to remove system directories), and a file name table with files from each directory. This does not include the files we currently grab.


FS#65951 - pacman search results do not match the manual page for --search Expand Collapse
Description:
There was a discussion at https://bbs.archlinux.org/viewtopic.php?id=253813.
pacman manual page states that --search, both for -Qs and for -Ss, is for names or descriptions that match regexp. Users who know that Name and Description are defined fields for each package might expect that only those fields will be searched in. Which is not the case. I think the manual page should use other words than name and description.

Additional info:
* pacman 5.2.1-4

Steps to reproduce:
for pacman -Qs pan, ncurses is probably one of the results. Even though pacman -Qi ncurses | grep pan shows it is included because of the Provides field. ncurses provides libpanelw.so.
FS#66340 - [pacman] distcc and ccache together break gcc in package() Expand Collapse
Description:
When using both distcc and ccache, PKGBUILDs that execute gcc in package() fail to build with an error from distcc like:

distcc[52016] (main) CRITICAL! distcc seems to have invoked itself recursively!

Additional info:
* The cause is that CCACHE_PREFIX is set to "distcc distcc" instead of just "distcc", which is because buildenv gets set once for build() and a second time for package() and each time it appends "distcc". So ccache invokes "distcc distcc gcc" and that causes distcc to have a fit.
* I posted a patch at https://lists.archlinux.org/pipermail/pacman-dev/2020-January/023949.html but it wasn't taken in. I ran into this again just now so I decided to file a bug.

Steps to reproduce:
* Enable both ccache and distcc in BUILDENV in /etc/makepkg.conf.
* makepkg any package that invokes the compiler in package(), for example ncurses.
* Observe the error during the "make install" command.
FS#66472 - Delete .sig in addtion to package when failing to validate Expand Collapse
Filing this as a reminder for when the new downloader hits master.

Pacman offers to delete packages that fail verification. We should also delete any .sig file that is downloaded too.
FS#66628 - Do not attempt to download db .sig on every mirrors Expand Collapse
Summary and Info:
With the new downloader, when refreshing databases, if the signature download failed, all next mirrors are tried.
It can slightly slow down the process if the mirrorlist contains many mirrors.

Steps to Reproduce:
Use DatabaseOptional or DatabaseRequired on official mirrors which don't provide a signature.
Use --debug option to see that all mirrors are tried.
FS#66828 - strcpy with realloc Expand Collapse
Summary and Info:

Pacman source code:

file src/pacman/util.c line 1241 and 1242:

optstring = realloc(optstring, strlen(optstring) + strlen(status) + 1);
strcpy(optstring + strlen(optstring), status);

No realloc error checking.

Also, using strcpy in pacman/libalpm is not very good sign.


Steps to Reproduce:

None yet but should "work" in low memory conditions.

Text Version