[prev in list] [next in list] [prev in thread] [next in thread]
List: openembedded-core
Subject: Re: [OE-Core][PATCH v11][master-next 1/5] package_ipk.bbclass: add support for ACLs and xattr
From: Piotr Łobacz <p.lobacz () welotec ! com>
Date: 2023-07-31 21:23:56
Message-ID: AM6PR04MB53686D49B46380144CB447829105A () AM6PR04MB5368 ! eurprd04 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Big thx for quick response Richard.
I will look into it.
BR
Piotr
________________________________
Od: Richard Purdie <richard.purdie@linuxfoundation.org>
Wysłane: Monday, July 31, 2023 11:19:39 PM
Do: Joshua Watt <JPEWhacker@gmail.com>; Piotr Łobacz <p.lobacz@welotec.com>
DW: Alexandre Belloni <alexandre.belloni@bootlin.com>; \
openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>; \
Alex Stewart <alex.stewart@ni.com>
Temat: Re: [OE-Core][PATCH v11][master-next 1/5] package_ipk.bbclass: add support for \
ACLs and xattr
On Mon, 2023-07-31 at 14:25 -0600, Joshua Watt wrote:
> On Mon, Jul 31, 2023 at 1:10 PM Piotr Łobacz <p.lobacz@welotec.com> wrote:
> >
> > I'm sorry for splitting this message but it has happend by accident…
> >
> > Returning to the topic my assumption is that for some reason in reproducibleA, \
> > these miliseconds are cutted and in case of reproducibleB they are not.
> > This was obviously working for opkg-build in case of gnu format which is cutting \
> > it also but for posix format it stores and thus error occurs.
> > My question is where can I find the code responsible for moving/coping data into \
> > these packages-split directories?
>
> I suspect this is because reproducibleA is allowed to restore from
> sstate where the milliseconds are not preserved, while reproducibleB
> doesn't restore from sstate.
>
> I'm not sure how you would store the milliseconds in sstate and make
> sure it was consistent, but that is probably where you need to look.
> Start in sstate.bbclass
What is likely happening is that we have two cases:
a) do_package is run and do_package_write_ipk uses the files directly
from disk which has the millisecond data. do_package writes an sstate
tarball using tar in non-posix mode.
b) do_package_setscene runs instead of do_package. This restores the
tarball written into sstate in a). The millisecond data is therefore
lost. do_package_write_ipk would then be written without it.
I'd guess you need to make the sstate archives of do_package store the
acl and extended attribute data and when that is done, the millisecond
timestamp data will probably be saved too? I'm not sure this is going
to be a generally useful thing in the general case though and zeroing
the millisecond portion would really be easier in general if we could.
Certainly, SOURCE_DATE_EPOCH doesn't have millisecond precision.
Cheers,
Richard
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">
<div></div>
<div>
<div><span dir="ltr" style="text-decoration:none">Big thx for quick response \
Richard.</span> <div dir="ltr" style="text-decoration:none"><br>
</div>
<div dir="ltr" style="text-decoration:none">I will look into it.</div>
<div id="ms-outlook-mobile-signature" dir="ltr" style="text-decoration:none">
<div><br>
</div>
<div dir="ltr">BR</div>
<span dir="ltr">Piotr</span></div>
</div>
<div id="ms-outlook-mobile-signature" dir="ltr"></div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" \
style="font-size:11pt" color="#000000"><b>Od:</b> Richard Purdie \
<richard.purdie@linuxfoundation.org><br> <b>Wysłane:</b> Monday, July 31, 2023 \
11:19:39 PM<br> <b>Do:</b> Joshua Watt <JPEWhacker@gmail.com>; Piotr Łobacz \
<p.lobacz@welotec.com><br> <b>DW:</b> Alexandre Belloni \
<alexandre.belloni@bootlin.com>; openembedded-core@lists.openembedded.org \
<openembedded-core@lists.openembedded.org>; Alex Stewart \
<alex.stewart@ni.com><br> <b>Temat:</b> Re: [OE-Core][PATCH v11][master-next \
1/5] package_ipk.bbclass: add support for ACLs and xattr</font> <div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Mon, 2023-07-31 at 14:25 -0600, Joshua Watt wrote:<br>
> On Mon, Jul 31, 2023 at 1:10 PM Piotr Łobacz <p.lobacz@welotec.com> \
wrote:<br> > > <br>
> > I'm sorry for splitting this message but it has happend by accident…<br>
> > <br>
> > Returning to the topic my assumption is that for some reason in \
reproducibleA, these miliseconds are cutted and in case of reproducibleB they are \
not.<br> > > <br>
> > This was obviously working for opkg-build in case of gnu format which is \
cutting it also but for posix format it stores and thus error occurs.<br> > > \
<br> > > My question is where can I find the code responsible for moving/coping \
data into these packages-split directories?<br> > <br>
> I suspect this is because reproducibleA is allowed to restore from<br>
> sstate where the milliseconds are not preserved, while reproducibleB<br>
> doesn't restore from sstate.<br>
> <br>
> I'm not sure how you would store the milliseconds in sstate and make<br>
> sure it was consistent, but that is probably where you need to look.<br>
> Start in sstate.bbclass<br>
<br>
What is likely happening is that we have two cases:<br>
<br>
a) do_package is run and do_package_write_ipk uses the files directly<br>
from disk which has the millisecond data. do_package writes an sstate<br>
tarball using tar in non-posix mode.<br>
<br>
b) do_package_setscene runs instead of do_package. This restores the<br>
tarball written into sstate in a). The millisecond data is therefore<br>
lost. do_package_write_ipk would then be written without it.<br>
<br>
I'd guess you need to make the sstate archives of do_package store the<br>
acl and extended attribute data and when that is done, the millisecond<br>
timestamp data will probably be saved too? I'm not sure this is going<br>
to be a generally useful thing in the general case though and zeroing<br>
the millisecond portion would really be easier in general if we could.<br>
Certainly, SOURCE_DATE_EPOCH doesn't have millisecond precision.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185172): https://lists.openembedded.org/g/openembedded-core/message/185172
Mute This Topic: https://lists.openembedded.org/mt/100468421/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-
--mqST4SMU9YArCUmvetol--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic