Arch Linux User Repository

Sure, and I got another wonderful surprise over the weekend because allan accepted my fix for the gcc8 warnings. :D

Hi, could you drop support-file-5.33-pie-executable.patch? It's landed as https://git.archlinux.org/pacman.git/commit/?id=03272ad57142a1c7dacf1d9933d52650d3936225

--enable-debug enables -Werror in addition to #define PACMAN_DEBUG

This causes issues because gcc8 has new warnings. I've been waiting to see if Allan can write a patch over the weekend that fixes these, in which case the issue will naturally disappear.

It is currently not possible to build the package. makepkg output:

cc1: all warnings being treated as errors
make[3]: *** [Makefile:825: libalpm_la-remove.lo] Error 1
make[2]: *** [Makefile:928: all-recursive] Error 1
make[1]: *** [Makefile:984: all-recursive] Error 1
make: *** [Makefile:893: all] Error 2

@Eschwartz - Fair enough. Thank you for all your work. - I wasnt aware that they were using package signing right now. Ill switch my repos to signed. thank you for that info as well.

(P.S. - Gosh those edits are so clean. Amazing work.)

I've asked on their IRC channel, and they were sort of vague about why they wanted the sync patch but admitted it "may not be needed as much anymore with most installations shipping with initramfs".

The stdin patch reverts https://git.archlinux.org/pacman.git/commit/?id=e374e6829cea3512f0b4a4069c5a6168f0f8d8a0 which we added to pacman for good reason, and they indicated that while some packages prompt the user in the install script to e.g. flash the u-boot images, their install scripts know how to handle lack of stdin. I see no reason to revert this, since the user can very well follow the fallback prompts and this "feature" is broken in many cases.

For the signature checking I was told "it's up to the user to initialize their keys". I have even less than zero interest in supporting this use case.

I'm uploading a new version which adds the necessary CARCH support and uses pacman.conf.arm configured with their repositories. This seems sufficient to me.

@Eschwartz - "Split contrib" Ahh, sorry for the confusion. - I was unaware of that, as its not something i have any interest in normally.

"Stock Configurations" - ^_^ makes sense, ty for clarifying.

"signature checking completely disabled" - While I do agree on that, it is the way their repositories are set up (https://archlinuxarm.org/packages/armv7h/pacman/files/pacman.conf). I don't know who currently maintaining packages, but I don't believe they are currently signed. Thats something I would ask Kevin Mihelich kevin@archlinuxarm.org about. But, I would recommend you did, as I am not very familiar with arch repos and packaging security. it's typically not my concern, as in, not a packager.

patches -

0001-Sychronize-filesystem.patch From what I can tell Sync was added to prevent data loss. As a precaution on slow-writing mediums(Or poor flash media) - As I was just raising compliance, in my GitHub version of this package and not focused on reasons for its use.(as its just harmless sync() before starting package operations.) In the patch-notes dating back to 2014, it states ###[Since many problems arise from improper flushing of the filesystem, particularly package installations followed by a reboot very shortly after, this will perform a sync() after installations and removals to ensure a consistent filesystem state after package operations.]###

0002-Revert-close-stdin-before-running-install-scripts.patch Specifically, on ArchlinuxArm, closing stdin can be an issue during install/remove scripts and some other functions. But again I am not a developer and this function seems harmless, although could potentially be an issue for security if done on the archlinux-x86 platforms as there is no cleanup process. As Taken from the notes.

[This reverts commit e374e6829cea3512f0b4a4069c5a6168f0f8d8a0.

Arch Linux ARM packages have use cases for this feature, such as prompting the user to flash a new kernel to a bare partition. Removing this feature will undoubtedly cause more problems than it intends to solve.]### - If you want me to ask I can ask them for clarification?

0003-Revert-alpm_run_chroot-always-connect-parent2child-p.patch - This is no longer required, as these changes have already occurred upstream. As such I've removed it.

Regarding contrib, the Arch package version did not "supply it as part of its package", the contrib stuff was simply included in the pacman codebase and therefore enabled. Current development versions have split it out again, which is why it is a separate package, but it hasn't been decided whether to make it mandatory...

Stock configurations won't work, they assume pacman can be run by any consumer and don't contain the necessary options... like configured repository names.

But these ARM changes look sort of fishy to me, why is signature checking completely disabled with references to something that was changed in arch, 6 years ago, why is libalpm patched to add some questionable feature and remove another one, why is makepkg.conf only modified in order to remove -mtune=generic?

@Eschwartz: "Potentially incorrect what?" - Upstream changes that dont find their way back into the static configurations. (Which i experienced last year, when a option was not documented. Although, i cannot recall what it was, offhand). //// "There's a reason the repo package also provides its own non-stock configurations." - Im confused, why is that? //// "I'm unmotivated to support the arm pacman.conf" - i already have a local version of this package with all the patches, etc. converted. if you were interested (https://github.com/EndlessEden/pacman-all-git) //// "pacman-contrib is already ... why it should be a hard dependency" - The Arch Package Version, has supplied this as part of its package since commit "b41b136a3"@2013-04-04 / Inclusion of it just makes more sense to me. But this i think is personal. I apologize if my opinion seems inaccurate.

Potentially incorrect what? There's a reason the repo package also provides its own non-stock configurations.

I'm unmotivated to support the arm pacman.conf, but feel free to submit PRs here: https://github.com/eli-schwartz/pkgbuilds -- I won't hunt down the necessary conf files myself, for a system I don't use.

pacman-contrib is already an optdepends, I don't see why it should be a hard dependency especially given it would be a circular dependency.