Re: [arch-dev-public] Hooks!

[Christian Hesse]

Allan McRae  on Sat, 2016/04/23 17:03:
> According to the news announcement, today is the day we can start using
> hooks!  (as long as you live in the future like me - those of you in the
> past will need to catch up a day).
> 
> I have started a wiki page to discuss which hooks to add [1]. 
> [...]
>
> [1] https://wiki.archlinux.org/index.php/DeveloperWiki:Pacman_Hooks

I can not edit the wiki page, so discussing here.

How about a hook that rebuilds kernel initramfs images? Something like:

[Trigger]
Type = File
Operation = Install
Operation = Upgrade
Target = boot/vmlinuz-linux
Target = usr/lib/initcpio/*

[Action]
Description = Updating Arch Linux initramfs image
When = PostTransaction
Exec = /usr/bin/mkinitcpio -p linux
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpbAXWqrQ4CJ.pgp
Description: OpenPGP digital signature

Re: [arch-dev-public] Hooks rebuild #1

[Sergej Pupykin]

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.

Re: [arch-dev-public] Hooks rebuild #1

[Andrew Gregory]

On 04/28/16 at 09:52am, Anatol Pomozov wrote:
> Hi
> 
> On Thu, Apr 28, 2016 at 9:38 AM, Doug Newgard  wrote:
> > On Thu, 28 Apr 2016 09:29:49 -0700
> > Anatol Pomozov  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-icon-cache.install?h=packages/gtk3

Re: [arch-dev-public] Hooks rebuild #1

[Balló György]

2016-04-28 18:29 GMT+02:00 Anatol Pomozov :

> Hi
>
> On Wed, Apr 27, 2016 at 11:36 PM, Balló György 
> wrote:
> > 2016-04-28 6:28 GMT+02:00 keenerd :
> >
> >> 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ó

Re: [arch-dev-public] Hooks rebuild #1

[Anatol Pomozov]

Hi

On Thu, Apr 28, 2016 at 9:38 AM, Doug Newgard  wrote:
> On Thu, 28 Apr 2016 09:29:49 -0700
> Anatol Pomozov  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-icon-cache.install?h=packages/gtk3

Re: [arch-dev-public] Hooks rebuild #1

[Doug Newgard]

On Thu, 28 Apr 2016 09:29:49 -0700
Anatol Pomozov  wrote:

> Hi
> 
> On Wed, Apr 27, 2016 at 11:36 PM, Balló György  wrote:
> > 2016-04-28 6:28 GMT+02:00 keenerd :
> >  
> >> 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.

Re: [arch-dev-public] Hooks rebuild #1

[Anatol Pomozov]

Hi

On Wed, Apr 27, 2016 at 11:36 PM, Balló György  wrote:
> 2016-04-28 6:28 GMT+02:00 keenerd :
>
>> 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.

Re: [arch-dev-public] Hooks rebuild #1

[keenerd]

On 4/28/16, Balló György  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

Re: [arch-dev-public] Hooks rebuild #1

[Allan McRae]

On 28/04/16 21:47, Antonio Rojas wrote:
> Allan McRae wrote:
>>
>> You have obviously figured it out so who cares...
> 
> Yeah but there could be more packages affected
> 

That can be dealt with once the rebuild is done.  Then it will be super
easy to find missed packages in ABS.

Re: [arch-dev-public] Hooks rebuild #1

[Antonio Rojas]

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

Re: [arch-dev-public] Hooks rebuild #1

[Allan McRae]

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

Re: [arch-dev-public] Hooks rebuild #1

[Antonio Rojas]

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.

Re: [arch-dev-public] Hooks rebuild #1

[Allan McRae]

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?

Re: [arch-dev-public] Hooks rebuild #1

[Jan Alexander Steffens]

On Apr 27, 2016 2:36 PM, "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!

It seems libvirt just lost its systemd-tmpfiles call even though it's not
on the list. Were any other packages similarly affected?

Re: [arch-dev-public] Hooks rebuild #1

[Antonio Rojas]

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.

[arch-dev-public] Signoff report for [testing]

[Arch Website Notification]

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 17 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 5 fully signed off packages
* 83 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (17 total) ==

* gnutls-3.4.11-2 (i686)
* libgcrypt-1.7.0-2 (i686)
* libgpg-error-1.21-2 (i686)
* libtasn1-4.8-2 (i686)
* nano-2.5.3-2 (i686)
* nettle-3.2-2 (i686)
* gnutls-3.4.11-2 (x86_64)
* libgcrypt-1.7.0-2 (x86_64)
* libgpg-error-1.21-2 (x86_64)
* libtasn1-4.8-2 (x86_64)
* nano-2.5.3-2 (x86_64)
* nettle-3.2-2 (x86_64)
* firefox-i18n-46.0-1 (any)
* grantlee-qt5-5.1.0-2 (i686)
* pyqt5-5.6-1 (i686)
* grantlee-qt5-5.1.0-2 (x86_64)
* pyqt5-5.6-1 (x86_64)


== Incomplete signoffs for [core] (25 total) ==

* dhcpcd-6.10.3-1 (i686)
0/1 signoffs
* gnutls-3.4.11-2 (i686)
0/1 signoffs
* krb5-1.13.4-1 (i686)
0/1 signoffs
* libgcrypt-1.7.0-2 (i686)
0/1 signoffs
* libgpg-error-1.21-2 (i686)
0/1 signoffs
* libseccomp-2.3.0-1 (i686)
0/1 signoffs
* libtasn1-4.8-2 (i686)
0/1 signoffs
* linux-4.5.2-1 (i686)
0/1 signoffs
* lvm2-2.02.150-1 (i686)
0/1 signoffs
* nano-2.5.3-2 (i686)
0/1 signoffs
* net-tools-1.60.20160215git-1 (i686)
0/1 signoffs
* nettle-3.2-2 (i686)
0/1 signoffs
* xfsprogs-4.5.0-1 (i686)
0/1 signoffs
* dhcpcd-6.10.3-1 (x86_64)
1/2 signoffs
* file-5.26-2 (x86_64)
1/2 signoffs
* gnutls-3.4.11-2 (x86_64)
0/2 signoffs
* gzip-1.8-1 (x86_64)
1/2 signoffs
* libgcrypt-1.7.0-2 (x86_64)
0/2 signoffs
* libgpg-error-1.21-2 (x86_64)
0/2 signoffs
* libseccomp-2.3.0-1 (x86_64)
1/2 signoffs
* libtasn1-4.8-2 (x86_64)
0/2 signoffs
* lvm2-2.02.150-1 (x86_64)
1/2 signoffs
* nano-2.5.3-2 (x86_64)
0/2 signoffs
* nettle-3.2-2 (x86_64)
0/2 signoffs
* xfsprogs-4.5.0-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (58 total) ==

* firefox-i18n-46.0-1 (any)
0/2 signoffs
* seabios-1.9.2-1 (any)
0/2 signoffs
* dhcp-4.3.4-2 (i686)
0/1 signoffs
* firefox-46.0-1 (i686)
0/1 signoffs
* grantlee-qt5-5.1.0-2 (i686)
0/1 signoffs
* hdf5-1.10.0-1 (i686)
0/1 signoffs
* hdf5-cpp-fortran-1.10.0-1 (i686)
0/1 signoffs
* hdf5-openmpi-1.10.0-1 (i686)
0/1 signoffs
* hwloc-1.11.3-1 (i686)
0/1 signoffs
* linux-zen-4.5.2-1 (i686)
0/1 signoffs
* netcdf-4.4.1rc1-1 (i686)
0/1 signoffs
* netcdf-cxx-4.2-4 (i686)
0/1 signoffs
* netcdf-fortran-4.4.2-1 (i686)
0/1 signoffs
* network-manager-applet-1.2.0-1 (i686)
0/1 signoffs
* networkmanager-1.2.0-3 (i686)
0/1 signoffs
* networkmanager-openconnect-1.2.0-1 (i686)
0/1 signoffs
* networkmanager-openvpn-1.2.0-1 (i686)
0/1 signoffs
* networkmanager-pptp-1.2.0-1 (i686)
0/1 signoffs
* networkmanager-vpnc-1.2.0-1 (i686)
0/1 signoffs
* nghttp2-1.10.0-1 (i686)
0/1 signoffs
* nvidia-364.19-2 (i686)
0/1 signoffs
* nvidia-304xx-304.131-12 (i686)
0/1 signoffs
* nvidia-340xx-340.96-11 (i686)
0/1 signoffs
* octave-4.0.1-4 (i686)
0/1 signoffs
* pyqt5-5.6-1 (i686)
0/1 signoffs
* python-cffi-1.6.0-1 (i686)
0/1 signoffs
* qemu-2.5.1-1 (i686)
0/1 signoffs
* ruby-2.3.1-1 (i686)
0/1 signoffs
* vigra-1.11.0-2 (i686)
0/1 signoffs
* xf86-input-synaptics-1.8.3-3 (i686)
0/1 signoffs
* dhcp-4.3.4-2 (x86_64)
0/2 signoffs
* firefox-46.0-1 (x86_64)
0/2 signoffs
* grantlee-qt5-5.1.0-2 (x86_64)
0/2 signoffs
* hdf5-1.10.0-1 (x86_64)
0/2 signoffs
* hdf5-cpp-fortran-1.10.0-1 (x86_64)
0/2 signoffs
* hdf5-openmpi-1.10.0-1 (x86_64)
0/2 signoffs
* hwloc-1.11.3-1 (x86_64)
0/2 signoffs
* linux-zen-4.5.2-1 (x86_64)
0/2 signoffs
* netcdf-4.4.1rc1-1 (x86_64)
0/2 signoffs
* netcdf-cxx-4.2-4 (x86_64)
0/2 signoffs
* netcdf-fortran-4.4.2-1 (x86_64)
0/2 signoffs
* network-manager-applet-1.2.0-1 (x86_64)
1/2 signoffs
* networkmanager-1.2.0-3 (x86_64)
0/2 signoffs
* networkmanager-openconnect-1.2.0-1 (x86_64)
0/2 signoffs
* networkmanager-openvpn-1.2.0-1 (x86_64)
0/2 signoffs
* networkmanager-pptp-1.2.0-1 (x86_64)
0/2 signoffs
* networkmanager-vpnc-1.2.0-1 (x86_64)
1/2 signoffs
* nghttp2-1.10.0-1 (x86_64)
0/2 signoffs
* nvidia-364.19-2 (x86_64)
0/2 signoffs
* nvidia-304xx-304.131-12 (x86_64)
0/2 signoffs
* nvidia-340xx-340.96-11 (x86_64)
0/2 signoffs
* octave-4.0.1-4 (x86_64)
0/2 signoffs
* pyqt5-5.6-1 (x86_64)
0/2 signoffs
* python-cffi-1.6.0-1 (x86_64)
0/2 signoffs
* qemu-2.5.1-1 (x86_64)
0/2 signoffs
* ruby-2.3.1-1 (x86_64)
0/2 signoffs
* vigra-1.11.0-2 (x86_64)
0/2 signoffs
* xf86-input-synaptics-1.8.3-3 (x86_64)
0/2 signoffs


== Completed signoffs (5 total) ==

* file-5.26-2 (i686)
* 

Re: [arch-dev-public] Hooks rebuild #1

[Balló György]

2016-04-28 6:28 GMT+02:00 keenerd :

> 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ó

Re: [arch-dev-public] Hooks rebuild #1

[Balló György]

2016-04-28 7:12 GMT+02:00 Jan Alexander Steffens :

> On Thu, Apr 28, 2016 at 12:09 AM, Anatol Pomozov
>  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ó