[arch-dev-public] Hooks rebuild #1
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks: update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules Each rebuild requires the install file updated to remove these commands. No need to use staging/testing for this rebuild (except [core] packages). GO!
Allan McRae <allan@archlinux.org> on Wed, 2016/04/27 22:36:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource
This one fails. You need to install /usr/share/libalpm/scripts/gtk-update-icon-cache with execute permission.
gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 27.04.2016 14:36, Allan McRae wrote:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
Why is lib32-openssl on that list? -- Pierre Schmitz, https://pierre-schmitz.com
On 28/04/16 02:59, Pierre Schmitz wrote:
On 27.04.2016 14:36, Allan McRae wrote:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
Why is lib32-openssl on that list?
No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done. A
Allan McRae wrote:
No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.
A
It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.
On 28/04/16 21:18, Antonio Rojas wrote:
Allan McRae wrote:
No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.
A
It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.
Is the base package there?
Allan McRae wrote:
On 28/04/16 21:18, Antonio Rojas wrote:
Allan McRae wrote:
No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.
A
It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.
Is the base package there?
No, neither the base package nor any of its subpackages.
On 28/04/16 21:28, Antonio Rojas wrote:
Allan McRae wrote:
On 28/04/16 21:18, Antonio Rojas wrote:
Allan McRae wrote:
No idea... I generated the list via a quick grep, so there are false positives (more than I expected...). Just mark them as done.
A
It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.
Is the base package there?
No, neither the base package nor any of its subpackages.
Hrm... it was on the list I uploaded. $ grep kdepim rebuild.txt kdepim kdepimlibs kdepimlibs4 kdepim-runtime You have obviously figured it out so who cares... A
Allan McRae wrote:
Hrm... it was on the list I uploaded.
$ grep kdepim rebuild.txt kdepim kdepimlibs kdepimlibs4 kdepim-runtime
Ah, so the issue is todo lists not accepting pkgbases as input
You have obviously figured it out so who cares...
Yeah but there could be more packages affected
Hi On Wed, Apr 27, 2016 at 5:36 AM, Allan McRae <allan@archlinux.org> wrote:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
namcap expects that gtk-update-icon-cache is explicitly called E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache Remy, could you please look at it and update namcap?
Hi And another related question: are we going to have hooks for systemd-sysusers and systemd-tmpfiles? Quite a lot of packages packages use systemd-tmpfiles and it sounds like a good idea to move it to hooks.
On 28/04/16 04:40, Anatol Pomozov wrote:
Hi
And another related question: are we going to have hooks for systemd-sysusers and systemd-tmpfiles?
Quite a lot of packages packages use systemd-tmpfiles and it sounds like a good idea to move it to hooks.
They are listed on the wiki page [1] and this rebuild was labelled as "#1", so you could concluded there will be another rebuild... [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook. All it needs is a dev to update the package. My aplogies for not following things more closely and not having it ready in advance. -Kyle
On 04/28/2016 12:28 PM, keenerd wrote:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
All it needs is a dev to update the package.
Updated. Tested with some of my rebuilds and it works nicely. Thanks! -- Regards, Felix Yan
2016-04-28 6:28 GMT+02:00 keenerd <keenerd@gmail.com>:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them. -- György Balló
On 4/28/16, Balló György <ballogyor@gmail.com> wrote:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.
My bad! They were mixed together with the .INSTALL tests. Restored and massively refactored. No update for this one since the issue only created a few largely harmless false negatives, and I imagine there will be another update soon enough for rebuild #2. -Kyle
Hi On Wed, Apr 27, 2016 at 11:36 PM, Balló György <ballogyor@gmail.com> wrote:
2016-04-28 6:28 GMT+02:00 keenerd <keenerd@gmail.com>:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.
I disagree. Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files. It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.
On Thu, 28 Apr 2016 09:29:49 -0700 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi
On Wed, Apr 27, 2016 at 11:36 PM, Balló György <ballogyor@gmail.com> wrote:
2016-04-28 6:28 GMT+02:00 keenerd <keenerd@gmail.com>:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.
I disagree.
Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.
It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.
While I agree completely, Allan brought up the case of installing the tool after the fact, which won't necessarily trigger the hook. In the example you gave, the desktop mime cache wouldn't be created until you install something else with a .desktop file. More things would need the desktop mime cache, though, such as xdg-utils. This would pull it in on many more systems.
Hi On Thu, Apr 28, 2016 at 9:38 AM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 28 Apr 2016 09:29:49 -0700 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.
It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.
While I agree completely, Allan brought up the case of installing the tool after the fact, which won't necessarily trigger the hook. In the example you gave, the desktop mime cache wouldn't be created until you install something else with a .desktop file.
I think it makes sense to enhance the hook system to make sure hook is run when it is installed. But if it cannot be done then "update cache" should be run in post_install() of desktop-file-utils similar to what gtk-update-icon-cache package does [1].
More things would need the desktop mime cache, though, such as xdg-utils. This would pull it in on many more systems.
I agree that xdg-utils uses desktop mime cache and it should depend on desktop-file-utils. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gtk-update-i...
On 04/28/16 at 09:52am, Anatol Pomozov wrote:
Hi
On Thu, Apr 28, 2016 at 9:38 AM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 28 Apr 2016 09:29:49 -0700 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.
It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.
While I agree completely, Allan brought up the case of installing the tool after the fact, which won't necessarily trigger the hook. In the example you gave, the desktop mime cache wouldn't be created until you install something else with a .desktop file.
I think it makes sense to enhance the hook system to make sure hook is run when it is installed. But if it cannot be done then "update cache" should be run in post_install() of desktop-file-utils similar to what gtk-update-icon-cache package does [1].
Hooks already run during the transaction that installs them if something in the transaction triggers them. Running them on installation even when they're *not* triggered, makes no sense. If the process requires the list of new/updated/removed files, the post_install script needs to scan the filesystem and build the initial cache; the hook can then manage updates to it. If the list of files is not needed you can either build the initial cache from the post_install script or just have the hook trigger itself.
More things would need the desktop mime cache, though, such as xdg-utils. This would pull it in on many more systems.
I agree that xdg-utils uses desktop mime cache and it should depend on desktop-file-utils.
[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gtk-update-i...
2016-04-28 18:29 GMT+02:00 Anatol Pomozov <anatol.pomozov@gmail.com>:
Hi
On Wed, Apr 27, 2016 at 11:36 PM, Balló György <ballogyor@gmail.com> wrote:
2016-04-28 6:28 GMT+02:00 keenerd <keenerd@gmail.com>:
Namcap 3.2.7 is released. It removes the old .install warnings and adds a new one if the .install does anything covered by a hook.
Note that checks for shared-mime-info and desktop-file-utils dependencies are still needed. Please restore them.
I disagree.
Dependencies like gtk-update-icon-cache/desktop-file-utils should be installed by those who *needs* the tool functionality. Not by the packages that *provide* icons/desktop files.
It this case desktop environment should depend on desktop-file-utils that maintains the cache up-to-date. And if a user has no UI (headless setup) then no point in updating this cache.
This would mean that shared-mime-info and desktop-file-utils should be added as dependency to the glib2 package, because the generated cache files are used by its gio library: https://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c#n902 https://git.gnome.org/browse/glib/tree/gio/xdgmime/xdgmime.c#n346 For gtk-update-icon-cache, I think it's fine to add it as dependency only to gtk2 and gtk3, if the icon cache files are generated/removed, when gtk-update-icon-cache package is installed/removed. -- György Balló
Hi On Wed, Apr 27, 2016 at 5:36 AM, Allan McRae <allan@archlinux.org> wrote:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
And one more note: there are a lot of packages that have a dependency to "desktop-file-utils/gtk-update-icon-cache/..." package because the tools were used in *.install file. With the hook these dependencies are needed anymore. Please look at the dependency list of the packages you update and clean it up if needed.
On Thu, Apr 28, 2016 at 12:09 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:>
And one more note: there are a lot of packages that have a dependency to "desktop-file-utils/gtk-update-icon-cache/..." package because the tools were used in *.install file. With the hook these dependencies are needed anymore. Please look at the dependency list of the packages you update and clean it up if needed.
No, dependencies ensure the hook is available.
2016-04-28 7:12 GMT+02:00 Jan Alexander Steffens <jan.steffens@gmail.com>:
On Thu, Apr 28, 2016 at 12:09 AM, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:>
And one more note: there are a lot of packages that have a dependency to "desktop-file-utils/gtk-update-icon-cache/..." package because the tools were used in *.install file. With the hook these dependencies are needed anymore. Please look at the dependency list of the packages you update and clean it up if needed.
No, dependencies ensure the hook is available.
+1 Only xdg-utils should be replaced with gtk-update-icon-cache when it's used by the install script to run 'xdg-icon-resource forceupdate'. I recommend to add gtk-update-icon-cache as dependency to hicolor-icon-theme, since if a package uses the hicolor theme hierarchy, then it should update its icon cache too. -- György Balló
On Apr 27, 2016 2:36 PM, "Allan McRae" <allan@archlinux.org> wrote:
We are ready to start the first hooks rebuild. This rebuild covers packages using these hooks:
update-desktop-database update-mime-database install-info glib-compile-schemes gtk-update-icon-cacne/xdg-icon-resource gconf gio-querymodules
Each rebuild requires the install file updated to remove these commands.
No need to use staging/testing for this rebuild (except [core] packages).
GO!
It seems libvirt just lost its systemd-tmpfiles call even though it's not on the list. Were any other packages similarly affected?
On Thu, 28 Apr 2016 14:23:27 +0300, Jan Alexander Steffens wrote:
It seems libvirt just lost its systemd-tmpfiles call even though it's not on the list. Were any other packages similarly affected?
+ motion and apcupsd from my packages.
participants (12)
-
Allan McRae
-
Anatol Pomozov
-
Andrew Gregory
-
Antonio Rojas
-
Balló György
-
Christian Hesse
-
Doug Newgard
-
Felix Yan
-
Jan Alexander Steffens
-
keenerd
-
Pierre Schmitz
-
Sergej Pupykin