01:32 <tealbird> I think the xz github project just got taken down and it's going to be necessary to update the xz recipe somewhere else.

01:32 <tealbird> words. I have them.

01:32 <tealbird> point to somewhere else.

01:32 <ente> https://boehs.org/node/everything-i-know-about-the-xz-backdoor here?

01:32 <ente> or maybe here https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html

01:35 <ente> I know the guy, we used to chat on irc. makes me sad that a lot of FOSS maintenance is shouldered by overworked, unpaid, burnt-out and depressed people

01:40 <tealbird> ente: is definitely a problem. I'm dealing with that in a non-FOSS context, volunteering is often thankless and people get mad at you when you do it wrong.

01:40 <tealbird> What I'm saying is https://git.yoctoproject.org/poky/tree/meta/recipes-extended/xz/xz_5.4.6.bb points to https://github.com/tukaani-project/xz/releases/download/ and that has been disabled.

01:41 <marex> tealbird: isnt it in YP download cache ?

01:41 <marex> there was some fallback for tarballs, wasnt there ?

01:42 <tealbird> Is that enough? I don't know

01:42 <marex> tealbird: possibly, as a stopgap measure until things really settle

01:44 <tealbird> Definitely mirrored at https://downloads.yoctoproject.org/mirror/sources/ Looks like 5.6.1 is there, I'm going to look at that to confirm but maybe it should get taken down?

01:46 <marex> tealbird: as long as it isnt referenced by recipes ... there are so many mirrors already anyway ...

01:50 <tealbird> Looks like not yet https://patchwork.yoctoproject.org/project/oe-core/patch/1710313714-12541-36-git-send-email-wangmy@fujitsu.com/

08:33 <RP> With the xz issue, we also autoreconf which I think puts us in a better position

08:46 <landgraf> RP: and we haven't updated it yet which is even better in this case :-)

08:46 <landgraf> Opensuse banned Epochs in spec files and as the result: Retrieving: liblzma5-5.6.1.revertto5.4-3.2.x86_64 (Main Update Repository)

08:50 <landgraf> RP: according to (another) Richard autoreconf is not sufficient to mitigate this CVE. -disable-ifunc is needed

09:53 <RP> landgraf: fair enough, I did wonder how we got a failure when we pulled in that upgrade

14:50 <lefty> Can I INSANE_SKIP the "Missing Upstream-Status in patch" QA check? I have a patch which adds some custom behavior to u-boot, it's neither fixing a bug nor is it particularly relevant to anybody else in the community - but "INSANE_SKIP:${PN} += "patch-status patch-status-core patch-status-noncore" doesn't relieve me of this QA error.

14:52 <JaMa> lefty: why don't you just add Upstream-Status in the patch?

14:52 <lefty> JaMa I can, but none of the available options for Upstream-Status seem relevant to my use case.

14:53 <rbox> lefty: i've used 'Inappropriate'

14:53 <JaMa> Inappropriate [neither fixing a bug nor is it particularly relevant to anybody else in the community]

14:54 <JaMa> Inappropriate [custom behavior relevant only to lefty]

14:55 <lefty> Makes sense, I was reading the documentation very literally which says "the only reasons to mark patches as inappropriate are" oe specific and upstream ticket, neither of which applies.

14:56 <lefty> Still curious why my INSANE_SKIP doesn't work - is this a QA check which is intentionally impossible to skip or is this a bitbake bug?

14:56 <lefty> Or is my syntax wrong...

14:57 <JaMa> this qa check isn't in insane.bbclass so it probably doesn't look at INSANE_SKIP variable (and patches aren't related to ${PN} package as well)

14:59 <JaMa> sorry it is in insane.bbclass

14:59 <lefty> I tried without ${PN} appended as well with the same result.

14:59 <JaMa> patch-status-core patch-status-noncore aren't used since https://git.openembedded.org/openembedded-core/commit/meta/classes-global/insane.bbclass?h=scarthgap&id=61a881fdbe8b5a21c6276b8a5d06cc30486b1eb3 you didn't say which release you're using

15:01 <lefty> JaMa using Scarthgap. Does this mean "ERROR_QA:meta-my-layer:remove = "patch-status"" would remove this QA check for any patches in meta-my-layer?

15:03 <JaMa> it's currently enabled only for oe-core by default, so you don't need to remove it for scarthgap, but I would prefer to get it enabled for all layers (as in https://lists.openembedded.org/g/openembedded-core/message/197098) as Upstream-Status is useful and easy to add (especially for new patches where the contributor is much more likely to know the correct status)

15:07 <lefty> I guess, but if I develop a layer for a custom one-off board for instance, none of the patches in that layer are likely to be relevant to the community - so I think there's a use case for disabling this QA check for a given layer.

15:07 <marex> JaMa: please enable it for everyone, Upstream-Status is effing awesome

15:08 <JaMa> marex: reply to that thread please

15:08 <marex> the more info about origin of random patches there is, the better

15:08 <JaMa> lefty: and Upstream-Status is the best variable where you can indicate that you think it's not relevant for anyone else

15:09 <marex> JaMa: can I actually do that if I wasnt on CC originally and am not subscribed to oe-devel ?

15:09 <marex> (or, I am subscribed, bt with delivery off)

15:10 <rbox> lefty: its that hard to add a single line?

15:10 <JaMa> marex: if you use the right subject and Message-Id than it will end in the right thread, but a bit more work for you, but I think you can reply through a web ui as well

15:11 <lefty> rbox no, but if you're dealing with a bunch of patches that are all one-offs then every single patch has to have an identical line explaining that they're not relevant. Seems better to do it at a layer level in my opinion.

15:11 <JaMa> you can use "Upstream-Status: Inappropriate [I'm too lazy]" to indicate the quality of your layers :0

15:11 <rbox> lefty: you say something like that if its something difficult to do... its just typing a few extra letters

15:12 <JaMa> and it will work for 2 .patch exceptions which aren't useless for anyone else and you might even submit them to upstream and indicate where

15:13 <JaMa> while if you disable it for whole layer you'll probably forget to add it in these 2 exceptions as well

15:16 <marex> JaMa: OK, I'll add this into the todo ...

15:17 <JaMa> 134. Click "Reply" button; 155. Type "I agree it should be enabled"; 389. Click "Sent" :)

15:18 <JaMa> GTD rule "Things which takes less than minute, shouldn't go to TODO list"

15:19 <marex> JaMa: there is no reply button on that page

15:19 <marex> just a sec, got preempted

15:26 <JaMa> marex: maybe you need to login first? I can see it at the bottom

15:27 <moto-timo> Interesting thread on the xz backdoor: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IJRW6X34BBJQLAQ64G53S7XPRU35U7KN/

17:44 <khem> RP: with opkg backend I see ptest errors in meta-perl and other layers where a needed perl module or python module is missing it gets fixed if its added to rdep but I see the meta package to include all perl modules in image is already in rdeps, I wonder why default yocto ptest images do not hit this error on AB. maybe rpm has some other behavior ?

17:45 <khem> FAIL: t/00-load

17:45 <khem> Can't locate Test/More.pm in @INC (you may need to install the Test::More module)

18:04 <RP> khem: It could be the rpm automatic deps? We should try and fix the opkg backend, it may be worth a bug for it