All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] cairo: fix QA Issue
@ 2017-07-03 12:34 Gordan Markuš
  2017-07-03 13:56 ` Burton, Ross
  0 siblings, 1 reply; 5+ messages in thread
From: Gordan Markuš @ 2017-07-03 12:34 UTC (permalink / raw)
  To: openembedded-core; +Cc: Gordan Markuš

QA Issue: cairo: Files/directories were installed but not shipped in any
package: /usr/lib/cairo

Signed-off-by: Gordan Markuš <gordan.markus@pelagicore.com>
---
 meta/recipes-graphics/cairo/cairo_1.14.8.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cairo/cairo_1.14.8.bb b/meta/recipes-graphics/cairo/cairo_1.14.8.bb
index af6be56..9460191 100644
--- a/meta/recipes-graphics/cairo/cairo_1.14.8.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.14.8.bb
@@ -31,7 +31,7 @@ to replay rendering."
 DESCRIPTION_cairo-perf-utils = "The Cairo library performance utilities"
 
 FILES_${PN} = "${libdir}/libcairo.so.*"
-FILES_${PN}-dev += "${libdir}/cairo/*.so"
+FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
 FILES_${PN}-gobject = "${libdir}/libcairo-gobject.so.*"
 FILES_${PN}-script-interpreter = "${libdir}/libcairo-script-interpreter.so.*"
 FILES_${PN}-perf-utils = "${bindir}/cairo-trace ${libdir}/cairo/*.la ${libdir}/cairo/libcairo-trace.so.*"
-- 
2.9.3



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] cairo: fix QA Issue
  2017-07-03 12:34 [PATCH] cairo: fix QA Issue Gordan Markuš
@ 2017-07-03 13:56 ` Burton, Ross
  2017-07-04  7:36   ` Gordan Markuš
  0 siblings, 1 reply; 5+ messages in thread
From: Burton, Ross @ 2017-07-03 13:56 UTC (permalink / raw)
  To: Gordan Markuš; +Cc: OE-core

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On 3 July 2017 at 13:34, Gordan Markuš <gordan.markus@pelagicore.com> wrote:

> -FILES_${PN}-dev += "${libdir}/cairo/*.so"
> +FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
>

I just spent five minutes working out *why* this fixes the QA issue you
were getting.

A better fix would be to delete ${libdir}/cairo using:

  rmdir ${libdir}/cairo || :

or

  rmdir --ignore-fail-on-non-empty ${libdir}/cairo

(former is POSIX compliant, but I can't think of a situation where that is
only a hypothetical problem)

Then in the commit message you can say that the directory is always created
but it only has content if you disable cairo-trace.  At least, I hope you
are explicitly disabling cairo-trace as there's no other way I can see for
you go get this.

Ross

[-- Attachment #2: Type: text/html, Size: 1738 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cairo: fix QA Issue
  2017-07-03 13:56 ` Burton, Ross
@ 2017-07-04  7:36   ` Gordan Markuš
  2017-07-04 11:10     ` Burton, Ross
  0 siblings, 1 reply; 5+ messages in thread
From: Gordan Markuš @ 2017-07-04  7:36 UTC (permalink / raw)
  To: Burton, Ross; +Cc: OE-core

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

On 2017-07-03 15:56, Burton, Ross wrote:
>
> On 3 July 2017 at 13:34, Gordan Markuš <gordan.markus@pelagicore.com 
> <mailto:gordan.markus@pelagicore.com>> wrote:
>
>     -FILES_${PN}-dev += "${libdir}/cairo/*.so"
>     +FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
>
>
> I just spent five minutes working out *why* this fixes the QA issue 
> you were getting.
>
> A better fix would be to delete ${libdir}/cairo using:
>
>   rmdir ${libdir}/cairo || :
>
> or
>
>   rmdir --ignore-fail-on-non-empty ${libdir}/cairo
>
> (former is POSIX compliant, but I can't think of a situation where 
> that is only a hypothetical problem)
>
> Then in the commit message you can say that the directory is always 
> created but it only has content if you disable cairo-trace.  At least, 
> I hope you are explicitly disabling cairo-trace as there's no other 
> way I can see for you go get this.
>
> Ross
Thanks for the suggestion Ross, and you are right this only happens if 
there is a bbappend that removes the 'cairo-perf-utils' package. An 
example of this is the meta-ivi layer.
Experimenting a bit it seems to me that even by adding the directory 
removal, in case it is empty, the do_package step still fails. By 
inspecting further I can observe that the directory is in fact not being 
removed but left empty which is quite puzzling.
After doing some thinking I believe it might be better to add the 
removal of the directory and the package files in the bbappend, do you 
agree with this? Here is the PR to meta-ivi that does that 
https://github.com/GENIVI/meta-ivi/pull/45.

[-- Attachment #2: Type: text/html, Size: 3601 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cairo: fix QA Issue
  2017-07-04  7:36   ` Gordan Markuš
@ 2017-07-04 11:10     ` Burton, Ross
  2017-07-05  8:52       ` Gordan Markuš
  0 siblings, 1 reply; 5+ messages in thread
From: Burton, Ross @ 2017-07-04 11:10 UTC (permalink / raw)
  To: Gordan Markuš; +Cc: OE-core

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

Yes, the bbappend is breaking the packaging so should fix its own mess.

Ross

On 4 July 2017 at 08:36, Gordan Markuš <gordan.markus@pelagicore.com> wrote:

> On 2017-07-03 15:56, Burton, Ross wrote:
>
>
> On 3 July 2017 at 13:34, Gordan Markuš <gordan.markus@pelagicore.com>
>  wrote:
>
>> -FILES_${PN}-dev += "${libdir}/cairo/*.so"
>> +FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
>>
>
> I just spent five minutes working out *why* this fixes the QA issue you
> were getting.
>
> A better fix would be to delete ${libdir}/cairo using:
>
>   rmdir ${libdir}/cairo || :
>
> or
>
>   rmdir --ignore-fail-on-non-empty ${libdir}/cairo
>
> (former is POSIX compliant, but I can't think of a situation where that is
> only a hypothetical problem)
>
> Then in the commit message you can say that the directory is always
> created but it only has content if you disable cairo-trace.  At least, I
> hope you are explicitly disabling cairo-trace as there's no other way I can
> see for you go get this.
>
> Ross
>
> Thanks for the suggestion Ross, and you are right this only happens if
> there is a bbappend that removes the 'cairo-perf-utils' package. An example
> of this is the meta-ivi layer.
> Experimenting a bit it seems to me that even by adding the directory
> removal, in case it is empty, the do_package step still fails. By
> inspecting further I can observe that the directory is in fact not being
> removed but left empty which is quite puzzling.
> After doing some thinking I believe it might be better to add the removal
> of the directory and the package files in the bbappend, do you agree with
> this? Here is the PR to meta-ivi that does that https://github.com/GENIVI/
> meta-ivi/pull/45.
>

[-- Attachment #2: Type: text/html, Size: 3969 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] cairo: fix QA Issue
  2017-07-04 11:10     ` Burton, Ross
@ 2017-07-05  8:52       ` Gordan Markuš
  0 siblings, 0 replies; 5+ messages in thread
From: Gordan Markuš @ 2017-07-05  8:52 UTC (permalink / raw)
  To: Burton, Ross; +Cc: OE-core

Acknowledged. Thanks Ross.

On 2017-07-04 13:10, Burton, Ross wrote:
> Yes, the bbappend is breaking the packaging so should fix its own mess.
> 
> Ross
> 
> On 4 July 2017 at 08:36, Gordan Markuš <gordan.markus@pelagicore.com 
> <mailto:gordan.markus@pelagicore.com>> wrote:
> 
>     On 2017-07-03 15:56, Burton, Ross wrote:
>>
>>     On 3 July 2017 at 13:34, Gordan Markuš
>>     <gordan.markus@pelagicore.com
>>     <mailto:gordan.markus@pelagicore.com>> wrote:
>>
>>         -FILES_${PN}-dev += "${libdir}/cairo/*.so"
>>         +FILES_${PN}-dev += "${libdir}/cairo ${libdir}/cairo/*.so"
>>
>>
>>     I just spent five minutes working out *why* this fixes the QA
>>     issue you were getting.
>>
>>     A better fix would be to delete ${libdir}/cairo using:
>>
>>       rmdir ${libdir}/cairo || :
>>
>>     or
>>
>>       rmdir --ignore-fail-on-non-empty ${libdir}/cairo
>>
>>     (former is POSIX compliant, but I can't think of a situation where
>>     that is only a hypothetical problem)
>>
>>     Then in the commit message you can say that the directory is
>>     always created but it only has content if you disable
>>     cairo-trace.  At least, I hope you are explicitly disabling
>>     cairo-trace as there's no other way I can see for you go get this.
>>
>>     Ross
>     Thanks for the suggestion Ross, and you are right this only happens
>     if there is a bbappend that removes the 'cairo-perf-utils' package.
>     An example of this is the meta-ivi layer.
>     Experimenting a bit it seems to me that even by adding the directory
>     removal, in case it is empty, the do_package step still fails. By
>     inspecting further I can observe that the directory is in fact not
>     being removed but left empty which is quite puzzling.
>     After doing some thinking I believe it might be better to add the
>     removal of the directory and the package files in the bbappend, do
>     you agree with this? Here is the PR to meta-ivi that does that
>     https://github.com/GENIVI/meta-ivi/pull/45
>     <https://github.com/GENIVI/meta-ivi/pull/45>.
> 
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-07-05  8:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-03 12:34 [PATCH] cairo: fix QA Issue Gordan Markuš
2017-07-03 13:56 ` Burton, Ross
2017-07-04  7:36   ` Gordan Markuš
2017-07-04 11:10     ` Burton, Ross
2017-07-05  8:52       ` Gordan Markuš

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.