Arch Linux User Repository

I've now removed the keys from the PKGBUILD.

@jplatte Ah, yes, that's a leftover from the official Nautilus package. AFAIK the idea was to verify the Git tag signature (Nautilus <47.1 used to have a ?signed#tag in the Git URL), but I'm not sure whether the signature check was ever actually implemented in makepkg (#edit: further research: it is implemented).

In any case, validpgpkeys isn't used for neither the official nautilus package nor our nautilus-typeahead. Both the config and the keys/ folder can be removed, they serve no purpose right now. They only confuse AUR helpers, which prompt users to import keys even though makepkg doesn't make use of them (which is why neither of us saw it before, it's something your AUR helper does, not makepkg). If prompted, it's safe to decline importing those keys until the PKGBUILD was updated, it won't cause any issues.

As of recently, I can no longer build this package since two new signing keys are not found by gpg (I've tried a couple keyservers to no avail): 6B211753AC950672287226800538577822AE4B17 550660707A6F40376B9B9F8D504A78811E6160CC

Anybody know what's up?

Thanks a lot, @albertvaka!

Since you mentioned that you haven't used GNOME in quite a long time, it might indeed be a good idea to offer some help here. That said, I'm probably not the best-suited candidate for co-maintainership, as I'm not a C dev. I am a senior dev, so I understand the basics of C and can fix minor issues like the ones we encountered when updating the patch to Nautilus 50, but anything more complex than that is beyond me.

Given that, it might make more sense for @prurigro to take on the role instead. That said, @prurigro, @albertvaka - if you'd still like me to help out and take on co-maintainership, I'm happy to do so. Just let me know what you think is best; I'm fine either way.

@PhrozenBytes and @prurigro thanks for your patch(es) :D

The reason for keeping the fork instead of patch files was because it required less effort. I haven't used Gnome in more than 5 years, so I'm not scratching my own itch with this package anymore and I want to keep the maintenance burden to a minimum.

Said that, given @PhrozenBytes literally did the work of updating the PKGBUILD to use patch files, I've reused that (after bumping the version to 50.1 and re-adding some optdepends that are missing in the upstream package but I think should be there).

Also, if you guys want to be co-maintainers of this package I'm happy to add you so you can update it yourselves in the future.

@PhrozenByte: Oh man, I'm clearly blind haha- I didn't read far enough down your post to see that you'd actually created your own updated package, my bad! Definitely would have saved myself a bit of time there.

I see you went with TRUE as well :) and yea, your approach with format-patch is better.

@prurigro: What's "not as ideal" about it, we use the exact same approach? There are just two minor differences:

1. You also build the libnautilus-extension-docs package, which isn't necessary because it's identical to the official package anyway.
2. You don't use git format-patch to create the patchset, making it a little harder to maintain. My goal was that @albertvaka can keep using his Nautilus fork.

It's identical otherwise? I mean, even the diff is basically the same? Just my Blueprint adaptation of the settings UI is a little closer to the original; they are functionally identical.

I've updated my patch set from the 49 release to work with 50 (including rebasing against the upstream package). There was one big change (the settings UI is done differently), and you now need to set an auto_selection boolean when running nautilus_files_view_set_selection- I tested both TRUE and FALSE, and both seemed to work correctly for its usage with typeahead so I stuck with TRUE.

https://git.darkcloud.ca/kevin/nautilus-typeahead

@albertvaka: Feel free to pull the changes into yours.

@PhrozenBytes: Not as ideal as looking at this package's own diffs, but you can look at the changelog for the three typeahead patches in my repo to see what changed just in this patchset.

@albertvaka, regarding our prior discussion about this package's patching strategy: I fully understand that maintaining a fork of GNOME's GitLab repo is more convenient. However, this approach makes it significantly harder to see what changes are applied on top of upstream - and more importantly, whether the patchset itself has changed.

As it stands, each update effectively requires reviewing the entire diff against upstream, rather than just incremental changes to the patchset (which in most cases may not even exist).

A more conventional (in terms of "closer to how official packages are maintained") and transparent approach would be to use the official upstream repo as the primary source in the PKGBUILD and include the typeahead modifications as explicit .patch files committed to the AUR package repo. This makes the delta to upstream immediately visible and allows changes to be audited much more easily.

The GitLab fork can still be retained as the development repo. Generating patches from it is straightforward with Git. For example, assuming a local typeahead branch based on upstream/gnome-50, the patch series can be generated with:

git format-patch -o /path/to/aur-package-repo/ upstream/gnome-50..typeahead

Additionally, it may be worth aligning the AUR package more closely with the official Arch package. Over time, some minor differences have accumulated. Basing this package on the official one makes it easier to merge upstream packaging changes regularly and reduce maintenance effort. If the patchset itself does not require modifications (i.e., most of the time), updating nautilus-typeahead is as simple as pulling the AUR package repo and verifying that Nautilus still builds.

This keeps the convenience of maintaining a forked GNOME GitLab repo while significantly improving transparency and reviewability for AUR users.

I used this approach to prototype Nautilus 49.5 and later updated it to Nautilus 50.0: https://gitlab.archlinux.org/phrozenbyte/nautilus-typeahead

You'll also find the typeahead patch updated for Nautilus 50.0 there (it required some changes). I don't follow Nautilus' development, so the updates I made are more like trial & error than actual knowledge, but they seem to work. You can apply the updated patchset to your GitLab fork using git am (starting from upstream/gnome-50). Note that next to updating the patch for Nautilus 50.0, I also took the freedom to add all authors (including myself) to the commit message as co-authors.

Thanks again for your continued work on this!

@PhrozenByte: So the original patchset came from the same source as this repo was using, by pulling out commits here https://gitlab.gnome.org/xclaesse/nautilus/-/compare/gnome-48...type-ahead (his changes vs Nautilus 48). I ended up having to modify them to follow new upstream conventions, but xclaesse's commits were GPL-3.0 because they were made against the upstream repo, and my changes were to his commits (making them GPL-3.0 as well).

As for the PKGBUILD, yes, it's just upstream Arch package + the patches and minus the check (the check was failing for me on the archive test, which has nothing to do with what was changed and which I've tested as working on the resulting package).

@albertvaka: No need to make me co-maintainer (unless you're looking for help), you seem quite active here :) I appreciate all the work you've put in keeping this going over the years on that note! I didn't flag this as out of date because I wasn't sure if you'd be willing to accept an "unofficial" update, but I'll do that next time if we're in the same situation again (and after reading the last post in the typeahead thread, it seems like we might be unless upstream is willing to pull in xclaesse's changes).

Also, thanks for the attribution :)