I did the same SRCREV bump locally and can confirm that
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 pseudo: Incorrect
UID/GID in packaged files
is still reproducible:
ERROR: glibc-locale-2.24-r0 do_package_qa: QA Issue: glibc-locale:
Wired: I've just sent a patch to update oe-core to use the current
HEAD of pseudo.
Tired: WARNING: glibc-locale-2.28-r0 do_package_qa: QA Issue:
glibc-locale:
/glibc-binary-localedata-en-za.iso-8859-1/usr/lib/locale/en_ZA.ISO-8859-1/LC_PAPER
is owned by uid 1000, which is the same as the user
Nice catch. Merged a patch that applies this also.
-s
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On Thu, 20 Sep 2018 20:41:02 +
wrote:
> Okay, so I found the problem, and I have a patch for it. Throughout
> the pseudo_db.c code, the handling of the msg->ino objects is not
> consistent. Many get passed to the sqlite3_bind_int64 function, but
> NOT ALL. 9 instances in the code,
Dell - Internal Use - Confidential
> On Wed, 19 Sep 2018 12:33:37 +0100
> "Burton, Ross" wrote:
>
> > Is anyone actually writing a patch?
>
> I have a tentative fix for this checked into master, I don't know
> whether it actually works because I don't have any inodes over 2^63.
>
> It doesn't
On Wed, 19 Sep 2018 12:33:37 +0100
"Burton, Ross" wrote:
> Is anyone actually writing a patch?
I have a tentative fix for this checked into master, I don't know
whether it actually works because I don't have any inodes over 2^63.
It doesn't seem to have *broken* anything, though in casual
Dell - Internal Use - Confidential
> On Wed, 19 Sep 2018 12:33:37 +0100
> "Burton, Ross" wrote:
>
> > On Tue, 18 Sep 2018 at 22:21, Seebs wrote:
> > > > Are the databases supposed to be shareable between different build
> > > > machines? IIRC, the answer is no. Could you store the native
On Wed, 19 Sep 2018 12:33:37 +0100
"Burton, Ross" wrote:
> On Tue, 18 Sep 2018 at 22:21, Seebs wrote:
> > > Are the databases supposed to be shareable between different build
> > > machines? IIRC, the answer is no. Could you store the native inode
> > > type as a sqlite BLOB? Not necessarily a
On Tue, 18 Sep 2018 at 22:21, Seebs wrote:
> > Are the databases supposed to be shareable between different build
> > machines? IIRC, the answer is no. Could you store the native inode
> > type as a sqlite BLOB? Not necessarily a good idea Just an idea.
>
> I think coercing the values into
On Tue, 18 Sep 2018 16:16:22 -0500
Joshua Watt wrote:
> Are the databases supposed to be shareable between different build
> machines? IIRC, the answer is no. Could you store the native inode
> type as a sqlite BLOB? Not necessarily a good idea Just an idea.
I think coercing the values into
On Tue, Sep 18, 2018, 16:09 Seebs wrote:
> On Tue, 18 Sep 2018 20:26:59 +
> wrote:
>
> > SO... any suggestions how to make the inodes in the database an
> > UNSIGNED value?
>
> We probably *can't* -- sqlite doesn't support that! They cap out at 8
> byte integer values, and are always
On Tue, 18 Sep 2018 20:26:59 +
wrote:
> SO... any suggestions how to make the inodes in the database an
> UNSIGNED value?
We probably *can't* -- sqlite doesn't support that! They cap out at 8
byte integer values, and are always signed. I don't know of a way to
fix this. We might be able to
> > On Wed, 2018-08-22 at 14:54 +, jack.f...@dell.com wrote:
> > > So failure mode is the target filesystem is devoid of SELinux file
> > > contexts, all files are unlabeled_t, which pretty much breaks
> > > everything in enforcing mode. So whatever the corruption
> > > cause/effect in the
On Wed, 22 Aug 2018 14:54:02 +
wrote:
> So failure mode is the target filesystem is devoid of SELinux file
> contexts, all files are unlabeled_t, which pretty much breaks
> everything in enforcing mode. So whatever the corruption
> cause/effect in the Psuedo database, the end result is when
> On Wed, 2018-08-22 at 14:54 +, jack.f...@dell.com wrote:
> > So failure mode is the target filesystem is devoid of SELinux file
> > contexts, all files are unlabeled_t, which pretty much breaks
> > everything in enforcing mode. So whatever the corruption cause/effect
> > in the Psuedo
On Wed, 2018-08-22 at 14:54 +, jack.f...@dell.com wrote:
> So failure mode is the target filesystem is devoid of SELinux file
> contexts, all files are unlabeled_t, which pretty much breaks
> everything in enforcing mode. So whatever the corruption
> cause/effect in the Psuedo database, the
Dell - Internal Use - Confidential
> Dell - Internal Use - Confidential
>
> > 2018-08-20 20:45 GMT+02:00 :
> > > We are encountering a build problem after migrating to Poky 2.3
> > > and Pseudo 1.8.1, and need help to resolve this.
> > > It is hampering our development efforts, forcing us to
2018-08-22 15:58 GMT+02:00 :
> I should add that the same problem exists in Poky 2.5, and top of Pseudo git
> repo. The problem was introduced, best I can tell, was when the entire
> Pseudo database structure was rewritten. As a result of the major overhaul
> messing with patches is
On Wed, 2018-08-22 at 13:58 +, jack.f...@dell.com wrote:
> Dell - Internal Use - Confidential
>
> > 2018-08-20 20:45 GMT+02:00 :
> > > We are encountering a build problem after migrating to Poky 2.3
> > > and Pseudo 1.8.1, and need help to resolve this.
> > > It is hampering our
Dell - Internal Use - Confidential
> 2018-08-20 20:45 GMT+02:00 :
>> We are encountering a build problem after migrating to Poky 2.3 and Pseudo
>> 1.8.1, and need help to resolve this.
>> It is hampering our development efforts, forcing us to rebuild images
>> frequently.
>>
>> Background:
2018-08-20 20:45 GMT+02:00 :
> We are encountering a build problem after migrating to Poky 2.3 and Pseudo
> 1.8.1, and need help to resolve this.
> It is hampering our development efforts, forcing us to rebuild images
> frequently.
>
> Background:
> Our build applies SELinux file contexts,
We are encountering a build problem after migrating to Poky 2.3 and Pseudo
1.8.1, and need help to resolve this.
It is hampering our development efforts, forcing us to rebuild images
frequently.
Background:
Our build applies SELinux file contexts, during build time since our rootfs is
22 matches
Mail list logo
