Re: AppArmor support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 9/28/18 9:36 AM, Geo Kozey via arch-general wrote:
>> ----------------------------------------
>> From: David Runge <dave@xxxxxxxxxxx>
>> Sent: Thu Sep 27 23:49:16 CEST 2018
>> To: Geo Kozey <geokozey@xxxxxxxxxxxxx>
>> Cc: General Discussion about Arch Linux <arch-general@xxxxxxxxxxxxx>
>> Subject: Re:  AppArmor support
>>
>>> BTW: every interaction with PKGBUILD spits: 
>>>
>>> find: ‘etc/apparmor.d/’: No such file or directory
>> Hm, not for me. Are you using devtools to build in a clean chroot
>> environment?
>>
>> Best,
>> David
>>
>> -- 
> 
> Yes, but I think it occurs before actual chrooting:
> 
> $ extra-x86_64-build -- -T -l /var/build/chroot
> :: Synchronizing package databases...
>  core is up to date
>  extra is up to date
>  community is up to date
> :: Starting full system upgrade...
>  there is nothing to do
> ==> Building in chroot for [extra] (x86_64)...
> ==> Synchronizing chroot copy [/var/lib/archbuild/extra-x86_64/root] -> [/var/build/chroot]...done
> find: 'etc/apparmor.d/': No such file or directory
> ==> Making package: apparmor 2.13.0-8
> ==> Retrieving sources...
>   -> Found apparmor-2.13.tar.gz
>   -> Found apparmor-2.13.tar.gz.asc
>   -> Found binmerge.patch
> ==> Validating source files with sha512sums...
> 
> 
> Maybe it's something specific to my system, no idea.
> 
> Other than that everything looks good to me. Great job!
> 
> Yours sincerely

That happens because the PKGBUILD dynamically re-evaluates the contents
of the "backup" metadata variable, and lint_pkgbuild attempts to
recalculate this but fails because it only works *during* package.

I mentioned this on IRC, I believe...

This means the resulting output is rather confusing when running makepkg
without an existing "etc" directory next to the PKGBUILD... which due to
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/apparmor&id=0cc1589dcb541f3a4b5f45e860dbf04109f3d65e
will always be true.

A workaround for this is to delay evaluation by using:
mapfile -td '' -O "${#backup[@]}" backup < <(find ... -print0)

since the internal extract_function_variable() makepkg function does not
detect this (it only handles direct foo=var or foo+=var assignments).

Alternatively, one could play with find "${startpoint}" -path
"${startpoint}/etc/apparmor.d/*" -printf '%P\n' which will successfully
run during lint_pkgbuild and --printsrcinfo, but will still print errors
if startpoint is unreadable (if that's pkgdir, it probably will be?),
doesn't properly handle paths with spaces or newlines in them, and also
spends a lot of time searching the whole directory tree instead of only
searching the given subpath.

I favor option one. :)

Also, PKGBUILDs with complex metadata assignments are annoying to do
correctly, which is probably a reminder that we should all strive to
avoid them!

*glares at https://bugs.archlinux.org/task/58776 and sighs*

-- 
Eli Schwartz
Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux