alejandrohs has quit [Read error: Connection reset by peer]
alejandrohs has joined #yocto
<zeddii>
strace blew up with the 5.15 headers, but I've fixed it now. testing musl but so far so good. will send the recipes by end of week at this rate.
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
<khem>
RP: much appreciated, I have staged them too
<khem>
and it avoids all slew of warnings that I was seeing locally
akiCA has quit [Read error: Connection reset by peer]
akiCA has joined #yocto
goliath has quit [Quit: SIGSEGV]
qschulz has quit [Quit: qschulz]
qschulz has joined #yocto
camus1 has joined #yocto
camus1 is now known as camus
scott_ has joined #yocto
mranostaj has quit [Quit: Lost terminal]
sakoman has quit [Quit: Leaving.]
Lihis has quit [Remote host closed the connection]
Lihis has joined #yocto
paulg has quit [Ping timeout: 260 seconds]
paulg has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
akiCA has quit [Ping timeout: 268 seconds]
alejandrohs has quit [Ping timeout: 268 seconds]
alejandrohs has joined #yocto
deurzen has quit [Quit: Leaving]
scott_ has joined #yocto
<Ch^W>
~.
lexano has quit [Ping timeout: 260 seconds]
lexano has joined #yocto
locutusofborg has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]
locutusofborg has joined #yocto
rfs613_alt has joined #yocto
rfs613 has quit [Ping timeout: 260 seconds]
fitzsim has quit [Ping timeout: 264 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
pgowda_ has joined #yocto
alessioigor has quit [Client Quit]
GNUmoon has quit [Ping timeout: 276 seconds]
Schlumpf has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
Schlumpf has quit [Client Quit]
Schlumpf has joined #yocto
Schlumpf has quit [Client Quit]
Schlumpf has joined #yocto
bwoods has quit [Ping timeout: 260 seconds]
bwoods has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
zyga-mbp has joined #yocto
GNUmoon has joined #yocto
rob_w has joined #yocto
yocton has quit [Ping timeout: 268 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
mckoan|away is now known as mckoan
<mckoan>
good morning
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
bluelightning has quit [Ping timeout: 264 seconds]
<JosefHolzmayrThe>
yo dudX
rber|res has joined #yocto
rber|res has quit [Client Quit]
kroon has joined #yocto
<kroon>
Is it just me that has been having problems with the default CONNECTIVITY_CHECK_URIS, https://www.example.com/, when starting bitbake this week ?
mvlad has joined #yocto
scott_ has joined #yocto
goliath has joined #yocto
zpfvo has joined #yocto
<mckoan>
kroon: that's a frequent problem therefore I always et in my local.conf CONNECTIVITY_CHECK_URIS = "https://www.google.com"
<mckoan>
s/et/set
<kroon>
yeah thats what I did, maybe worth upstreaming, or even removing the check..
<frosteyes>
zeddii: just FYI regarding my SDK issue with compiling kernel modules out-of-tree. I had some time yesterday and found that the unwinder was set to frame pointer (CONFIG_UNWINDER_FRAME_POINTER=y) and not ORC. So objtool was not part of the kernel delivery and not part of kernel-devsrc.
<kroon>
I don't see any other application that uses the network that does this check
dev1990 has quit [Quit: Konversation terminated!]
Bardon has quit [Ping timeout: 264 seconds]
wwilly has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
<JaMa>
zeddii: there are quite a few warnings for missing protocol=https because of those 'SRC_URI = "git://${PKG_NAME}.git;branch=master"' where PKG_NAME starts with github.com, but the conversion script doesn't parse that far, it's not fixed in master-next, do you want me to send my version or do you have something already locally?
leon-anavi has joined #yocto
<JaMa>
zeddii: sent
manuel1985 has joined #yocto
bps3 has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
scott_ has quit [Ping timeout: 268 seconds]
Herdinger has joined #yocto
<Herdinger>
Hi, I have a very quick question. I am including a custom kernel module and need to ship udev rules with it, what is the correct FILES_ variable for that? I tried FILES_${PN} but that does not included the installed files when the module is installed.
<JosefHolzmayrThe>
Herdinger: on which release?
<Herdinger>
JosefHolzmayrThe: dunfell
<Herdinger>
Apparently the package the kernel module ends up with is something like recipe-kernelversion-board.ipk, I can not really tell what that is derived from.
<JosefHolzmayrThe>
Herdinger: k. so generally, FILES_${PN} should be right. have you inspected its value, as well as the PACKAGES variable as they end up being calculated, via bitbake -e?
<Herdinger>
Yes, and I get a package containing those files but it is not the same package as the kernel module and it does not get installed when the kernel module is installed.
<JosefHolzmayrThe>
have you checked how the name of the module package gets generated?
davidinux has quit [Quit: WeeChat 2.8]
<qschulz>
Herdinger: it does not really make sense to have a udev rule part of a kernel module. You're mixing two things, kernel space and userspace and they are usually separate. So just have an additional package in another recipe which is included in your image (or is added to MACHINE_EXTRA_RDEPENDS or something like that in your machine conf file).
<JosefHolzmayrThe>
qschulz: good point!
davidinux has joined #yocto
<Herdinger>
qschulz: In both cases youre shipping files to rootfs so I do not completly agree. But sure that is a way to solve it.
yocton has joined #yocto
<qschulz>
Herdinger: udev rule is for udev enabled systems which isn't necessarily the case for all systems. some have mdev, some have none, some have udev. I don't remember but there might actually be small differences between udev and eudev too, so there are actually choices, as compared to just a kernel module which isn't impacted by the rootfs choice
camus1 has joined #yocto
<JosefHolzmayrThe>
its a classic "works for me" versus "the right thing" discussion. in a specific environment/product, i'd agree that bundling can be ok. for a solution that gets published as a layer (BSP?), qschulz is right and it should be treated as a seperate instance.
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
<Herdinger>
qschulz: I see your point. I would probably model it to have the functionality with udev and bells and whistles in a seperate recipe and let that depend on the kernel module. The only thing that still would confusing to me are kernel module headers that get shipped, currently I am including them in the kernel module recipe and have a dependency on
<Herdinger>
it for recipes that use those.
<Herdinger>
qschulz: Is there a way were I could depend just on the recipe for the actual functionality and have that transitively included the kernel headers?
<qschulz>
in any case, I assume ${PN} is wrong and should be something like: ${KERNEL_MODULE_PACKAGE_PREFIX}-${@d.getVar("KERNEL_PACKAGE_NAME") or "kernel"}-module-<ko module name>-${KERNEL_MODULE_PACKAGE_SUFFIX}
<qschulz>
Herdinger: why would you need the kernel headers at runtime?
<Herdinger>
qschulz: Thanks for providing an actual answer to the question!
<qschulz>
or run oe-pkgdata-util find-path '*<module>.ko' and replace <module> accordingly
<qschulz>
and hardcode the name
<qschulz>
I do not understand your last question though :/
tre has joined #yocto
<Herdinger>
I would not need them at runtime but for building userspace utilitities that call ioctls for the kernel module device. So currently I just list the kernel module itself as a dependency for that.
<Herdinger>
If there was a package that encompasses the entire feature with kernelmodule and userspace udev rules etc. I would like to just depend on that for the kernel headers instead of the kernel module directly.
<qschulz>
Herdinger: custom kernel headers requires custom handling in Yocto. You need to create a new recipte that provides this additional kernel header and depend on it in your kernel module (I assume it's needed there) and other recipes making use of it
<JosefHolzmayrThe>
qschulz: i sense a documentation opportunity for you :P
<Herdinger>
qschulz: I do not need custom kernel headers, its a header that the kernel module provides. Sorry if that was confusing. Its working as it is right now, I just did not want have to depend on different packages depending on the context.
<qschulz>
JosefHolzmayrThe: what for specificially?
<JosefHolzmayrThe>
qschulz: "how to properly integrate my custom kernel module"
<qschulz>
Herdinger: I'm not sure you have a choice there :/
<Herdinger>
Ok than :(, thanks so much for the advice.
<qschulz>
You can use PACKAGECONFIG to make it a bit more magic but there'll still be a option changed somewhere (in conf file or directly in the recipe which depends on different recipes)
<qschulz>
to select which recipe to depend on
zpfvo has quit [Ping timeout: 260 seconds]
<qschulz>
depending on what exactly your changes imply, it could either be something machien specific or something distro specific
zpfvo has joined #yocto
<qschulz>
also, make sure to use the correct wording. Recipes are metadata used to build packages. A recipe (build) depends on other recipes and packages (runtime) depend on other packages
<qschulz>
I'm not sure which one you meant in the end
<qschulz>
It's a very important notion that is source of much confusion for people, so I'm just making sure this is clear or at least explicit :)
<qschulz>
JosefHolzmayrThe: I think there should already be something about that somewhere in the BSP guide?
<JosefHolzmayrThe>
qschulz: yeah i think there is something.
<Herdinger>
Hm, can't I depend on a package at buildtime? If I list a -dev package as a dependency for example. I though that was the whole stick of RDEPENDS vs DEPENDS.
<Herdinger>
Completly unrelated but since someone who has the power to document is here I had a long long bug search because of the difference of a patch with and without a trailing slash in the SRC_URI. When I asked on IRC I got lots of conflicting and confusing answers.
<qschulz>
Herdinger: trailing slash in SRC_URI means it's a directory so not sure there's something we can do about it?
<qschulz>
I guess it should have told you that it cannot find the directory?
<qschulz>
Herdinger: DEPENDS are on recipes, RDEPENDS are on packages
<qschulz>
no, you cannot DEPENDS on a -dev package
<Herdinger>
The difference is that a trailing slash correctly dependency tracks folder content, i.e. if a file is added or removed changed etc. While it was very very sporadic when things get rebuild without a trailing slash, it has been a while so I do not quite remember.
<qschulz>
but that is more or less what's done by DEPENDS <recipe>
florian has joined #yocto
<qschulz>
Herdinger: ah, yeah that's possible. I can't say, I think there was some fixes in that area in the last few releases.
<qschulz>
also, * is not supported in SRC_URI, just to make sure this was not in play
<Herdinger>
Using a trailing slash if you want to track a directory and its contents was definitly not documented when I looked. I got flat out told it is impossible and I need to explicitly list all files in SRC_URI.
<qschulz>
Herdinger: nah, you can use directories in SRC_URI
<qschulz>
it's just not working well with bbappends
<qschulz>
I think I explained this in the video so you can watch iton youtube somewhere
<qschulz>
Maybe select 0.75x speed :)
<Herdinger>
So if I depend on a recipe I basically get the install of that recipe for my build right? That gets split into multiple packages for the later install on rootfs either through explicit install or RDEPENDS. Also there is some magic that adds shared libraries to RDEPENDS if I recall correctly.
<qschulz>
Herdinger: now if it is actually supported in your Yocto version is another thing but I used that on thud
<qschulz>
Herdinger: you get the content of the directories from ${D} directory (WORKDIR/image, where your do_install installs files) listed in SYSROOT_DIRS
<Herdinger>
qschulz: Thanks I'll work myself through the slides in total later :)
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
dtometzki has joined #yocto
scott_ has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
Herdinger has quit [Quit: Connection closed]
davidinux has joined #yocto
Guest50 has joined #yocto
<Guest50>
Hello, someone here has already use WhiteSource to scan Yocto sources ? there a simple way to get a good report ? I'm pretty sure that scanning the rootfs is not the best way :P
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
simon_ has joined #yocto
<mckoan>
Guest50: AFAIK there is no WhiteSource integration available for Yocto
Guest50 has quit [Ping timeout: 256 seconds]
davidinux has quit [Ping timeout: 260 seconds]
zyga-mbp has joined #yocto
davidinux has joined #yocto
scott_ has quit [Ping timeout: 268 seconds]
dtometzki has quit [Ping timeout: 260 seconds]
<RP>
kanavin: I think I may somehow have lost the perl patch for gdbm during the last test run - did that only break the ptests on the autobuilder?
GillesM has joined #yocto
GillesM has quit [Client Quit]
scott_ has joined #yocto
<JaMa>
RP: the srcuri conversion script works reasonably well, even when there are quite a few false positives in layers which use some variable to provide branch parameter (all layers I maintain :)) and now I have warning free builds again and haven't seen any failure since yesterday (for dunfell-honister as well). Thanks!
<RP>
JaMa: glad it helped :)
<RP>
it was all a bit hacky but it seems good enough to do the bulk of the work
<JaMa>
yes, I think the only reasonable improvement would be to somehow use bitbake parser to parse each recipe SRC_URI before modifying it
<JaMa>
but then it would be difficult to find all the right places where it should be modified (e.g. if there is SRC_URI in .inc file and then overwrite in .bb file and both should get ;protocol=https)
<JaMa>
so it's good-enough and at least it leaves some work for us humans to do:)
<RP>
JaMa: devtool does have code that can do it but yes, it is a lot more work
<RP>
JaMa: I did try sed at first but that got too complex so I went with python :)
<JaMa>
true, I always start with sed and when it gets really complex I wish I didn't but its often too late to switch
<JaMa>
and then we end with some fragile unreadable sed machinery, just because I was too proud to give up and re-write it in something sensible
<JaMa>
at least it's not public usually
xmn has quit [Ping timeout: 260 seconds]
<RP>
JaMa: It became clear fairly quickly that python would be faster :)
nad has joined #yocto
nad has quit [Client Quit]
nadell has joined #yocto
nadell has quit [Client Quit]
nad has joined #yocto
<kanavin>
RP: yes, perl is the only thing that needs fixing with new gdbm.
<RP>
kanavin: ok, thanks. I misunderstood what was going on. Not sure why I missed that patch the first time
<RP>
nad: imported from elsewhere where it was already at r9 ?
<RP>
kanavin: most should rebase out now :)
<nad>
RP: ok I missed it from oe-core thanks
<kanavin>
nad, it's better to configure pieces that pull in readline to disable that, than to add meta-gpl2
<kanavin>
nad, there should be PACKAGECONFIG options for that
<nad>
kanavin: you mean, playing with PACKAGECONFIG_remove_ instead instead of adding meta-gplv2 ?
pgowda_ has quit [Quit: Connection closed for inactivity]
<kanavin>
nad, yes, or 'PACKAGECONFIG_pn-recipename =...' (overriding the recipe)
<kanavin>
meta-gpl2 is something we all want to get rid of, and no one should be using it
<kanavin>
those old versions are a security disaster waiting to happen, and a pain to keep in working condition
<nad>
kanavin: I agree. I wonder how to act in case tools require readline which cannot be inherited because of its license
<kanavin>
nad, you disable readline support in them, often it's done via configure options, or if it isn't you have to write a patch :(
<kanavin>
nad, another option is to package tools in such a way that they don't get added to the product image, only to development/testing images
<kanavin>
quite often only the library is needed in the product, and not the command line tool :)
<kanavin>
or it's stuff like gdb which shouldn't be in a product
<kanavin>
nad, what industry do you work in?
scott_ has quit [Ping timeout: 268 seconds]
<nad>
kanavin: I fully agree to use it for dev purpose only
<RP>
kanavin: it would be nice if we could figure out the bash compatibility piece for busybox such that you can configure busybox to replace bash
<RP>
kanavin: making that configurable would remove a lot of the remaining need to gplv2
<kanavin>
RP: does busybox have a bash compatibility piece? I thought it only provides posix shells?
<RP>
kanavin: it has bash compatible extensions I think. How far those go, not sure
<nad>
kanavin: auto
<kanavin>
nad, of course
<kanavin>
nad, I used to work for Daimler/Mbition until 3 months ago
<zeddii>
JaMa: I hadn't picked up that corner case yet, thanks for the patch!
scott_ has joined #yocto
kiran has joined #yocto
Guest5047 has joined #yocto
<hmw[m]>
hi, probaly wrong plase to complain but i don't know where i should. We use sd-cards as rootfs/boot partition. and our boot partition is fat32 but after a recent os update the arm target is not booting. no u-boot. but if i use a old sdcard ( preformatted) and copy the same u-boot it boots. it seems like my os is not creating the same sort of fat partition
fitzsim has joined #yocto
<Guest5047>
mckoan thx for the info:) I will try to find a workaround
zpfvo has quit [Ping timeout: 260 seconds]
Guest5047 has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
akiCA has joined #yocto
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
<JaMa>
RP: in meta-webosose we configure busybox to provide bash and sofar nothing got broken by using that implementation, only issue is to prevent all other recipes to accidentally pull real bash into the image (whenever bash gets built in the same TMPDIR), so it needs a lot of VIRUTAL-RUNTIME variables everywhere
<kanavin>
JaMa, but that's about something else and is RESOLVED FIXED - I mean a ticket for bash replacement when bash's license is a problem
<RP>
JaMa: I wonder if some systemwide filter mechanism for packages to replace VIRTUAL-RUNTIME would make sense
<JaMa>
it would be definitely easier to maintain, I'm still adding more and more bbappends doing this whenever some typicaly PN-ptest packages is discovered to need bash dependency as well
<RP>
JaMa: I'm certainly open to the idea
<RP>
JaMa: in fact you could do this really easily with a replacement runtime_mapping_rename function
<smurray>
JaMa: nm, looked at that meta-weboose commit you pointed at
vd has quit [Quit: Client closed]
<smurray>
RP: if that were available, I could imagine maybe adding a recipe for replxx and trying to point readline users at it
<RP>
smurray: it would be an interesting test
<RP>
I suspect that patch allows you to do a lot of things that could get you into trouble too
<RP>
but since when did that stop us previously
<smurray>
heh, yes, it occurred to me that it'd be a new footgun to hand people
roussinm has joined #yocto
<JaMa>
smurray: yes VIRTUAL-RUNTIME_bash and VIRTUAL-RUNTIME_stat which needs similar work arounds, but luckily in only a few places
<JaMa>
RP: thanks2 :)
rob_w has quit [Remote host closed the connection]
tre has joined #yocto
kroon has quit [Quit: Leaving]
rfs613_alt has quit [Quit: restart]
rfs613 has joined #yocto
vmeson has quit [Read error: Connection reset by peer]
vmeson has joined #yocto
vd has joined #yocto
camus has joined #yocto
Guest5032 has joined #yocto
alejandrohs has quit [Ping timeout: 260 seconds]
alejandrohs has joined #yocto
<Guest5032>
Hi all, I'm currently searching the best way to export licenses information from a Yocto build. We have configured Yocto to generate image-license.manifest file, There is a way to export SPDX file from Yocto?
<RP>
Guest5032: with honister and master, see the create-spdx class
<Guest5032>
RP I'm stuck with gatesgarth version, thx for tips I will take a look :)
<Guest5032>
RP thank you it's exactly what I need :) do you think it's compatible with older version ?
<rburton>
backporting won't be trivial as it involved some fairly instrusive pkgdata changes
<rburton>
there are standalone layers that do similar though which might backport easier
<qschulz>
if you can get your hands on a BeagleV then that but there are only engineering samples and they won't start production on that one IIRC what drewfustini said on twitter
Bardon has joined #yocto
dev1990 has joined #yocto
leon-anavi has quit [Quit: Leaving]
<smurray>
qschulz: yeah, that's my understanding re Beagle V, they're engaging with some other SoC vendor now instead of J-Star AIUI
<smurray>
there'll probably be a bunch of cheap Allwinner D1s/F133 boards showing up, but that SoC only has 64 MiB onboard RAM, so it's more of an IoT oriented thing
<khem>
D1 is good although the SOC has some incompatible extentions
simon_ has quit [Ping timeout: 268 seconds]
dtometzki has joined #yocto
<sakoman>
qschulz: thanks for the pointer!
<sakoman>
I was asking since BeagleV isn't a good option any longer
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
lucaceresoli has quit [Remote host closed the connection]
<smurray>
with Alibaba open-sourcing their core designs, I expect a bunch more SoCs to pop up
florian_kc has quit [Ping timeout: 268 seconds]
lucaceresoli has joined #yocto
lucaceresoli has quit [Client Quit]
<sakoman>
qschulz: do you know if there is a Yocto bsp for that board?
<qschulz>
sakoman: BeagleV or Allwinner?
<qschulz>
All I know is BeagleV is supported in upstream Buildroot, don't know about Yocto
<qschulz>
and for the allwinner one, I assume not since it's pretty new and I'm not sure with that much RAM it'll be super easy to run Linux without tweaks on it
<sakoman>
qschulz: the allwinner
florian has quit [Quit: Ex-Chat]
<sakoman>
qschulz: the link you provided claims: Memory – 1GB DDR3 memory
<smurray>
the newer D1s has the onboard memory, the full D1 uses external AIUI
<smurray>
if you poke around on alibaba, sipeed claim 1 month delivery for a nezha board, but whether it's worth paying > $100 for it or not is a good question
<sakoman>
smurray: I ordered one, so I'll find out :-)
<JaMa>
hpsy[m]: what was it? do_fetch failure or something else?
xmn has joined #yocto
<jordemort>
has honister changed something about the way packagegroups work? i have one "top level" packagegroup that RDEPENDS on a bunch of other packagegroups that i've been using to build out a package repository, but since cutting over to honister building the top-level packagegroup only seems to result in an RPM for the top-level one, and not RPMs for any of the other packagegroups it RDEPENDS
<jordemort>
i.e. i have `packagegroup-foo-packages` that RDEPENDS on `packagegroup-foo-bar` and `packagegroup-foo-baz`, in dunfell and hardknott building `packagegroup-foo-packages` got me packages for all 3, but in honister it only gets me `packagegroup-foo-packages`
florian_kc has joined #yocto
<JaMa>
hpsy[m]: upgrade ca-certificate on you host, I had slightly older version on 20.04 ubuntu and the root cert of salsa.debian wasn't trusted yet
<JaMa>
khem: yes, persistent on host with older ca-certificates
mvlad has quit [Remote host closed the connection]
<JaMa>
khem: maybe following rebuilds fetched it from some PREMIRROR for you?
nad has joined #yocto
Guest7073 has joined #yocto
<jordemort>
doesn't look like packagegroup.bbclass or packagegroup.py have changed much in years
<jordemort>
if i query RPM that the top-level packagegroup produces it still clearly shows it depending on the other packagegroups, but those just don't get built for some reason