<Etheryon>
Morning, I am back again to annoy you. I've enabled a module in the kernel CONFIG_RTL8821AE=m, but it doesn't show up with lsmod. I also did IMAGE_INSTALL += "linux-firmware-rtl8821". Not sure what I'm doing wrong
<GillesM>
hello I use honister and bitbake-layers create-layer remove python do_display_banner() remove _ and asdd a comment #addtask display_banner before do_build
<GillesM>
<GillesM>
where Do I need to add task ?
goliath has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
lucaceresoli has joined #yocto
rfuentess has joined #yocto
<qschulz>
Etheryon: you're installing the firmware and not the driver. You also need the kernel module
<qschulz>
Etheryon: kernel-module-something. If you know the name of the .ko, you can find the name of the package to install with: oe-pkgdata-util find-path '*kofilename*'
<qschulz>
Etheryon: otherwise, I think oe-pkgdata-util list-pkgs <kernel-recipe> should list all packages built by the recipe
<qschulz>
GillesM: Can you rephrase? I didn't understand the question/issue
AKN has quit [Ping timeout: 252 seconds]
oobitots43 has quit [Ping timeout: 256 seconds]
<qschulz>
moto-timo: first, you could run unpack for all recipes at once, that should help with parsing+fetching times
<Etheryon>
If I can't find a kernel-module-* what are my options?
<qschulz>
Etheryon: cry
<qschulz>
Etheryon: :D
<qschulz>
It likely means that your defconfig or config fragment wasn't picked up?
<qschulz>
and your module wasn't built
<qschulz>
or that you did the change manually to the defconfig and it's an invalid configruation now
dev1990 has joined #yocto
<Etheryon>
bare with me, I'm new to all this. I did a menuconfig virtual/kernel, enabled the module I'm interested in and it got set to M
<Etheryon>
which as far as I understood mean it's installable
<Etheryon>
?
gsalazar has joined #yocto
<Etheryon>
then I did savedefconfig virtual/kernel
<Etheryon>
thanks for the tip! that does look better
leon-anavi has joined #yocto
gsalazar has quit [Ping timeout: 272 seconds]
<Etheryon>
anyway I can reset it to default?
<Etheryon>
the kernel config I mean
<GillesM>
qschulz: I made a receipe with bitbake-layers create-layer and I got bitbake-layers create-layer meta-unexemple
<GillesM>
bitbake-layers add-layer and I got python do_display_banner() without _
<GillesM>
and a comment at the end of receipe : #addtask display_banner before do_build
<GillesM>
oups _ are not shown i geany ... sorry
<GillesM>
qschulz: but now when I bitbake receipe I don't see the message ...
<qschulz>
GillesM: I assume you are using a bb.warn or something like that in your do_display_banner task
<qschulz>
and you don't see this printed on the console when running bitbake
<qschulz>
your recipe needs to be built for starters, if it's not, it won't appear
<qschulz>
2) the do_display_banner needs to be in the task dependency tree of the task that is going to be run
<qschulz>
a task which is added only with an "after", won't get executed except explicitly asked
<qschulz>
therefore, if you want it to run all the time, you need a "before" in the addtask call
<qschulz>
without knowing more abuot this task or its use case, at least addtask before do_build would print it at some point in time
<qschulz>
though, once it is run, it'll be taken from sstate-cache for the next bitbake runs and won't be shown
<qschulz>
so, to fully answer your question: 1) what do you want to do exactly? 2) when do you want it to happen? 3) where did you put this python task? etc..
<GillesM>
qschulz: before Honister this example worked fine when I use bitbake receipe now I don't the text displayed
<GillesM>
I don't see
<mckoan>
GillesM: did you add addtask display_banner before do_build ?
<Etheryon_>
which led me to search for a rtlwifi module
<Etheryon_>
and found kernel-module-rtlwifi
<Etheryon_>
which I suppose is what I need
<qschulz>
Etheryon_: it's not included in the kernel if it's built as module, that's the whole point
<Etheryon_>
ok, and it gets built if it's marked as a module in the kernel config, as part of building the kernel
<Etheryon_>
kernel config^
<ederibaucourt>
rootfs slot was reported to be B.
<ederibaucourt>
Hi, I've set-up a dual-slot rootfs on meta-tegra's Nvidia Xavier NX devkit and I've got a problematic rollback on the kernel partition. I updated partition kernel_b with an incorrectly signed kernel and set rootfs slot b as active bootable. cboot refused to boot this kernel partition, but fell back to using the other kernel slot, while reporting successful boot on the B slot. The rootfs from the A slot was also mounted, w
<ederibaucourt>
Aside from that, I could successfully set-up dual-bank rootfs and bootloader by setting PARTITION_LAYOUT_TEMPLATE and SMD_CFG in my machine.conf. Is there any interest that we add this feature or document how to set-up dual-bank in meta-tegra or the Wiki? I could take some time to upstream this if desired.
<ederibaucourt>
I would expect cboot to fall back to slot A, while reporting slot B as unbootable, as slot A as active. Would someone have any insights on what could have happened ? I wonder if bad boot.img signatures are not properly handled in the dual-slot logic of cboot, or if I didn't configure the smd_info.rootfs_AB.cfg properly. madisox maybe ?
<Etheryon_>
and then it's up to me to include it in the image. If they would have been marked with y then they would come by default
AKN has quit [Ping timeout: 272 seconds]
<Etheryon_>
I guess the tricky part was to find the kernel module name for the feature I enabled
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
TurBoss has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
JrmeCarretero[m] has quit [Quit: Bridge terminating on SIGTERM]
gpanders has quit [Quit: Bridge terminating on SIGTERM]
Lcvette[m] has quit [Quit: Bridge terminating on SIGTERM]
zyga[m] has quit [Quit: Bridge terminating on SIGTERM]
cperon has quit [Quit: Bridge terminating on SIGTERM]
NishanthMenon[m] has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX[m] has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
suy|m has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
Dhruvag2000[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
Alistair[m] has quit [Quit: Bridge terminating on SIGTERM]
jclsn[m] has quit [Quit: Bridge terminating on SIGTERM]
expert[m] has quit [Quit: Bridge terminating on SIGTERM]
Portia[m] has quit [Quit: Bridge terminating on SIGTERM]
blauskaerm[m] has quit [Quit: Bridge terminating on SIGTERM]
asconcepcion[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
grembeter[m] has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
Perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
FredericOuellet[ has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
alvaropg[m] has quit [Quit: Bridge terminating on SIGTERM]
DasChaos[m] has quit [Quit: Bridge terminating on SIGTERM]
doquiros[m] has quit [Quit: Bridge terminating on SIGTERM]
booboo1212[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
halstead[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
zagor has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
jqua[m] has quit [Quit: Bridge terminating on SIGTERM]
StayLearning[m] has quit [Quit: Bridge terminating on SIGTERM]
howard[m] has quit [Quit: Bridge terminating on SIGTERM]
aleblanc[m] has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
<Etheryon_>
I'm guessing I don't actually need to install the firmware?
Spectrejan[m] has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
jordemort has joined #yocto
<Etheryon_>
should user settings go in distro.conf?
lexano[m] has joined #yocto
Emantor[m] has joined #yocto
kayterina[m] has joined #yocto
gpanders has joined #yocto
zyga[m] has joined #yocto
khem has joined #yocto
NishanthMenon[m] has joined #yocto
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
moto_timo[m] has joined #yocto
dwagenk has joined #yocto
jonesv[m] has joined #yocto
Portia[m] has joined #yocto
Alistair[m] has joined #yocto
PascalBach[m] has joined #yocto
zagor has joined #yocto
DasChaos[m] has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
blauskaerm[m] has joined #yocto
hmw[m] has joined #yocto
FredericOuellet[ has joined #yocto
berton[m] has joined #yocto
suy|m has joined #yocto
ericson2314 has joined #yocto
expert[m] has joined #yocto
Tartarus has joined #yocto
Perceval[m] has joined #yocto
alvaropg[m] has joined #yocto
cperon has joined #yocto
booboo1212[m] has joined #yocto
T_UNIX[m] has joined #yocto
Saur[m] has joined #yocto
doquiros[m] has joined #yocto
Lcvette[m] has joined #yocto
TurBoss has joined #yocto
Dhruvag2000[m] has joined #yocto
JrmeCarretero[m] has joined #yocto
StayLearning[m] has joined #yocto
jqua[m] has joined #yocto
howard[m] has joined #yocto
grembeter[m] has joined #yocto
jclsn[m] has joined #yocto
fabatera[m] has joined #yocto
asconcepcion[m] has joined #yocto
halstead[m] has joined #yocto
falk0n[m] has joined #yocto
aleblanc[m] has joined #yocto
agherzan has joined #yocto
AKN has joined #yocto
oobitots has quit [Quit: Client closed]
<qschulz>
Etheryon_: if driver=y in defconfig, then they are built-in and they will come in the kernel binary directly. driver=m => you need to install the packages containing the driver module (.ko file(s)) into your image itherwise it won't make it. You can also add kernel-modules package which installs ALL driver modules in your image
<qschulz>
Etheryon_: wifi modules almost always have firmware, so you'll probably need it too actually
<qschulz>
Etheryon_: define "user settings"
<Etheryon_>
new users/ user pass
<qschulz>
not sure you can setup new users in a configuration file, I think it needs to be done in a recipe
smsm has joined #yocto
<jclsn[m]>
`ERROR: ParseError in configuration INHERITs: Could not inherit file classes/image-mklibs.bbclass`
<Etheryon>
qschulz: hey man you've been so helpful, thanks! Where can I buy you a beer?
<qschulz>
Etheryon: my pleasure :)
goliath has quit [Quit: SIGSEGV]
Vonter has quit [Ping timeout: 240 seconds]
Passenger1 has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
<Etheryon>
shouldn't running python -c 'import crypt; print(crypt.crypt("mypass", crypt.METHOD_SHA256))' multiple times produce the same output?
<Etheryon>
seems like the second argument is a salt
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
Schlumpf has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
davidinux1 has joined #yocto
<JaMa>
agherzan: are you aware that meta-raspberrypi sync from github to git.yoctoproject probably stopped working again? e.g. honister is missing "linux-raspberrypi: Upgrade to 5.10.83" commit now and 11 commits are missing in master branch
<agherzan>
JaMa: Yes - Am am aware. I'm currently looking at it but it needs some SSH keys updates. Didn't have time to look into it but I hope to have it done by Monday.
<JaMa>
ok, thanks
<JaMa>
I'll switch builds to use github as it's more reliable and primary source
AKN has quit [Ping timeout: 272 seconds]
AKN has joined #yocto
goliath has joined #yocto
sakoman has joined #yocto
camus has quit [Quit: camus]
codavi has joined #yocto
Qorin has joined #yocto
ar__ has joined #yocto
oobitots has quit [Quit: Client closed]
oobitots76 has joined #yocto
<Etheryon>
Where can I suggest an edit on the yocto wiki?
<qschulz>
Etheryon: request an account, wait for the sysadmin to confirm and then you'll be able to edit
<qschulz>
or tell us here and we'll edit it if it's not too much work :)
<qschulz>
So I'm more leaning towards removing this Wiki and point to the docs
pgowda_ has quit [Quit: Connection closed for inactivity]
<qschulz>
the wiki is not maintained and technically not verified
GNUmoon has quit [Ping timeout: 240 seconds]
AKN has quit [Ping timeout: 256 seconds]
<Etheryon>
fair enough
Thorn has quit [Ping timeout: 252 seconds]
Thorn has joined #yocto
GNUmoon has joined #yocto
<Etheryon>
When I log in it's asking me to change the password - any way I can disable this? If I try to change it it doesn't work, I'm guessing because fs is read-only
<RP>
qschulz: the idea was generally to move things into the docs over time
<qschulz>
RP: yup, perfect example of something we should remove (or put a link to the docs :) )
<qschulz>
i'll try to do something about that :)
marc1 has quit [Ping timeout: 240 seconds]
marc1 has joined #yocto
AKN has joined #yocto
davidinux1 has quit [Ping timeout: 240 seconds]
davidinux1 has joined #yocto
Schlumpf has quit [Quit: Client closed]
<zyga[m]>
hello, is there any contribution process that does not involve the mailing list?
AKN has quit [Read error: Connection reset by peer]
xmn has joined #yocto
<qschulz>
zyga[m]: no, some layers use Github, such as meta-raspberrypi but core stuff is only via mailing list
<zyga[m]>
I see, oh well
* zyga[m]
is not very fond of email workflow
<qschulz>
zyga[m]: any particular issue with the workflow?
Vonter has quit [Ping timeout: 272 seconds]
<qschulz>
I mean, setting it up
<zyga[m]>
I just hate it
<zyga[m]>
it's tedious
<zyga[m]>
and annoying
<zyga[m]>
I don't use email for anything
<zyga[m]>
(and nothing I worked on ever used that workflow)
<qschulz>
zyga[m]: there'll always be someone who won't like a specific workflow :)
<zyga[m]>
well, yeah but that's not just that :)
<zyga[m]>
email is rare nowadays
<JPEW>
zyga[m]: Depends on the community
<zyga[m]>
oh for sure
<zyga[m]>
but the numbers are unforgiving :)
<qschulz>
zyga[m]: I won't start the discussion because it's always going south really fast :)
<zyga[m]>
don't get me wrong, I didn't come to argue, I was just curious if I missed something
<zyga[m]>
there's the github repo but PRs there seem to be stuck
<qschulz>
a mail was sent recently-ish, tyring to find it so you have the whole debate and we don't need to restart it :)
<qschulz>
zyga[m]: it's a mirror, for convenience only
<zyga[m]>
right
<qschulz>
we cannot disable pull requests on Github so it's the best we can do right now
paulbarker has quit [Read error: Connection reset by peer]
shivamurthy has quit [Read error: Connection reset by peer]
<zyga[m]>
qschulz: I read the mail you've posted and I hope at some point in the future a bolder decision is taken. I'm a total nobody but I think the process is so hostile that I just don't wan't to participate due to process alone. My contributions might be tiny but if it wasn't for the requirement to adopt a process I never worked with before, that requires custom tooling, setup and care, I would have sent a few patches last night, as I kept finding
<zyga[m]>
simple typos in comments for the bbclasses I was reading. I was planning on working on the go mod support earlier but I will most likely ask my colleague, who is an existing contributor, to take this task over entirely, as I would not be able to collaborate with the project this way.
* zeddii
chuckles
<qschulz>
zyga[m]: Sorry to hear that, we hope you'll change your mind and we hope to see some of your contributions land on the mailing lists one day.
<zyga[m]>
I may develop the mod support since I really need it but ask agherzan[m] to upstream it
xmn has quit [Ping timeout: 256 seconds]
<RP>
zyga[m]: just keep in mind that you're saying our current community is pretty worthless and the world should change so you don't have to do a small amount of work
<zyga[m]>
That was certainly not my goal, I'm just trying to make sure voices like mine are not lost among "all is fine" support for mailing lists. Nothing I said implies the community is worthless, at least not to me. I was trying to say that having a custom process (like send-patches-to-ml in 2022 is) has some cost, namely that of a drive-by-contributions
<zyga[m]>
I'm sure some people are just fine with email, some big projects keep using it
<zeddii>
and since go mod is directly from hell, there will be a lot of discussions, which won't happen buried in pull requests. more likely on the architecture mailing list where they have started.
<RP>
zyga[m]: this is effectively the cost of changing though, alienating our existing developers :(
<zyga[m]>
RP long vs short term benefits
<zyga[m]>
zeddii: I was thinking about go.workspace as a way to make packaging go much better for distribution-like systems which try to deduplicate libraries and versions
<RP>
zyga[m]: if we did that, we'd not have a project making it into the long term
<qschulz>
long unknown (maybe?) benefits vs short term very certain losses
<RP>
but what do I know :/
Minvera has joined #yocto
<zyga[m]>
qschulz: are you saying that if a non-ml workflow was adopted then existing people would leave?
<qschulz>
zyga[m]: yes
<qschulz>
or contribute MUCH less
<zeddii>
de-duplication of anything isn't really the signficant issue for what I support, it's the crazy fetching and lack of integration into the rest of the build.
<zeddii>
but unfortunately, I have about 30 cms of snow to shovel, so have to step away
<zyga[m]>
I think this is FUD a little, I don't recall any project that suffered something like this
<RP>
zyga[m]: github works where you have a single reviewer for a change. We have *many* reviewers and the model doesn't work
<zyga[m]>
zeddii: good luck
<zyga[m]>
RP: that's entirely false, not sure why you say that
<qschulz>
zeddii: with the all the heat that'll spur from the discussion, just put the computer in front of the entrnace :D
<zyga[m]>
RP: there can be many reviewers required, you have CODEOWNERS, you have commiters vs reviewers
smsm has quit [Ping timeout: 256 seconds]
<qschulz>
zyga[m]: we've discussed this a few months ago and I linked the mails
<qschulz>
RP already answered on this
<zyga[m]>
okay, let's end this topic then
<qschulz>
I and other contributors also answered, we cannot rediscuss this all the time
doquiros[m] has quit [Quit: You have been kicked for being idle]
sstiller has joined #yocto
sstiller has quit [Client Quit]
<Perceval[m]>
Hello all? I have a little problem trying to build my image based on poky. When I create a new user using "EXTRA_USERS_PARAMS_append" parameter, the user is correctly created but the home folder in the resulting image is owned by root, not by the user I created.
<Perceval[m]>
And the files present in etc/skel are not copied in the home folder
<agherzan>
JaMa: I'll improve the mirror job now as I'm migrating to GitHub actions
<agherzan>
It definitely going to be better
<Perceval[m]>
Do you have any idea on where it could come from?
rfuentess has quit [Remote host closed the connection]
<qschulz>
Perceval[m]: the content of your EXTRA_USERS_PARAMS_append would help for starters :)
<vd>
is having an initramfs or bundled initramfs a machine choice or a distro choice? (:
* vd
cries a little
goliath has quit [Quit: SIGSEGV]
<qschulz>
vd: IMO distro
<qschulz>
the question to ask is: why do I need an initramfs?
<qschulz>
it could also be an image choice too BTW
<vd>
qschulz: an image choice would be better but you can't to that
<vd>
s/to/do/
<zyga[m]>
zeddii: when you are back I would love to exchange ideas on how you see go mod support going forward
<zyga[m]>
zeddii: specifically around the fetcher
<zyga[m]>
zeddii: I was leaning to just asking go to fetch the dependencies and use a go-mod project@version string instead of git+revision in the recipe
<zyga[m]>
what wasn't clear if each recipe should have a separate GOMODCACHE or not
<qschulz>
RP: Etheryon: updated the Wiki page to point to the documentation (for changing root password and all)
marc1 has quit [Ping timeout: 272 seconds]
<RP>
qschulz: thanks!
marc1 has joined #yocto
florian has quit [Quit: Ex-Chat]
<sgw>
RP: Morning, I had some random 3am thoughts, about EXCLUDE_LICENSE_FROM_IMAGE (instead of INCOMPATIBLE_LICENSE) with EXCLUDE_PACAKGE_FROM_IMAGE, but this morning I was reminded that we have both a LICENSE_EXCLUSION-<pkg> and PACKAGE_EXCLUDE. So that would not work.
<sgw>
RP: I also saw your email
<vd>
are there native packages deploying files in DEPLOY_DIR_IMAGE?
<RP>
vd: no
<RP>
sgw: This is a bit of a messy situation, I'm worried we can't solve every problem right now. I tried to summarise my thoughts in my email in case it was helpful
florian_kc has quit [Ping timeout: 272 seconds]
<RP>
The bit I really really dislike is the _<license> bit of the current variable
<RP>
I think the package vs recipe also needs resolving
marc1 has quit [Ping timeout: 256 seconds]
GillesM has joined #yocto
GillesM has quit [Client Quit]
marc1 has joined #yocto
<sgw>
RP, yeah the LICENSE_EXCLUSION-<pkg> is also problematic like the _<license> variable. I think I will send something later today with your suggestion which merges the 2 variables
<sgw>
I don't think we can remove the PACKAGE_EXCLUDE as it has different meaning.
<RP>
sgw: which is LICENSE_EXCLUSION problematic ?
<RP>
er, why, not which
<smurray>
fwiw, I lean towards package focused for the exceptions, as it seems more sensible with the possible intersection with recipes that have packages with different licenses
<sgw>
It's also a constructed variable and I think the I_L_EXCPETION can be used since it has both the package and license
<sgw>
LICENSE_EXCLUSION-<pkg> contains the original excluded license, just as your new variable contains
<RP>
sgw: I'd argue that LICENSE_EXCLUSION is effectively just an internal variable and whilst it is constructed, pkg is something we can iterate PACKAGES for and know about
<RP>
knowing which license to append to a variable is much much harder
<sgw>
Yes, I agree, I was looking to clean up the namespace it it was possible by using the new I_L_EXCEPTIONS
<khem>
perhaps related to latest logging changes ?
<sgw>
that you proposed.
<RP>
khem: not the recent ones, I think I broke that a while ago :(
<sgw>
We can keep the LICENSE_EXCLUSION-<pkg> if you feel strongly that way.
<RP>
sgw: I think the hope was not to have the processing in base.bbclass repeated in package.bbclass
<RP>
sgw: I suspect the variable should be renamed to make it clear it is an internal implementation variable and not for public use
<RP>
sgw: there is an efficiency issue buried here too in that we don't want multiple sets of parsing of this data. I think it has to be done in base.bbclass so the user gets failures at parsing rather than failures at packaging
<RP>
khem: I assume you mean the newlines issue?
<sgw>
That I can do. I will write things up to make it a clear proposal and sent it out by noon'ish, i will also work on the implementation changes later today.
<RP>
sgw: if you can see a way to clean this up I'm definitely interested btw, just trying to explain why I think it does what it does
<RP>
sgw: From memory I think it was also done like this so there aren't two pieces of code coming to two different conclusions
* RP
wonders what people's thoughts on the license remapping script are
sakoman has quit [Remote host closed the connection]
sakoman has joined #yocto
florian_kc has joined #yocto
<khem>
RP: yes newlines issues
dev1990 has quit [Quit: Konversation terminated!]
<smurray>
RP: I'm for it, since using the SPDX identifiers seems to have been accepted in a lot of projects now, and it makes for more of a 1-to-1 with what seem likely to be standardish SBOM desires
<RP>
smurray: we've talked about it for long enough, I just decided to go ahead and script it...
<RP>
btw, I confirmed that (c) on my list of issues *is* broken, parsing errors don't stop the build for the renamed vars
<smurray>
is there a special circumstance, could have sworn I tried it with master-next at one point and it seemed like it did
<RP>
smurray: it needs to be a recipe error, not a base config error
<RP>
so BB_STAMP_POLICY = "1" into the bash recipe does it
<smurray>
ah, true, I was more focused on the variables from BitBake, so didn't hit that
<smurray>
is it more of a case of the check not occurring in the right spot atm or the exception not getting picked up?
<RP>
smurray: the latter I think, not 100% sure
goliath has joined #yocto
leon-anavi has quit [Quit: Leaving]
mixfix41 has joined #yocto
<JPEW>
khem: I'm not quite sure why you pinged me on that one?
<JPEW>
Oh, the logging changes
<JPEW>
I'm not quite sure why you think the logging changes are related to that error?
florian_kc is now known as florian
<JPEW>
RP: I like the idea of switching to SPDX license... since we're breaking things anyway seems like a good time :)
<JPEW>
Is the conversion script all that's needed there or is there more work?
manuel1985 has joined #yocto
florian has quit [Ping timeout: 272 seconds]
MikeJD has joined #yocto
behanw has quit [Quit: Connection closed for inactivity]
<JPEW>
MikeJD: I don't have familaritly with devtool, but a traditional SDK can be built with e.g. `bitbake core-image-minimal -c populate_sdk`
<sgw>
MikeJD: when using devtool build-sdk it will create a derivative eSDK, not SDK.
florian has joined #yocto
behanw has joined #yocto
Minvera has quit [Remote host closed the connection]
amitk has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
amitk has quit [Ping timeout: 240 seconds]
florian has quit [Ping timeout: 256 seconds]
<RP>
JPEW: The script gets us most of the way there. I guess we could make it warn if there was use of a non SPDX license?
<RP>
JPEW: does seem like a good time...
<JPEW>
We have the license database in JSON, so we should be able to validate somehow
xmn has quit [Quit: ZZZzzz…]
otavio_ has joined #yocto
otavio has quit [Read error: Connection reset by peer]
<MikeJD>
JPEW Yes that seems to work but we want to create a SDK using the eSDK
<MikeJD>
sgw: thanks for the reply, ok so we get confused reading the docs
Tokamak has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
MikeJD has quit [Quit: Client closed]
florian has joined #yocto
xmn has joined #yocto
mvlad has quit [Remote host closed the connection]
florian has quit [Ping timeout: 240 seconds]
rob_w has quit [Read error: Connection reset by peer]
ar__ has quit [Ping timeout: 256 seconds]
florian has joined #yocto
<moto-timo>
I think I have the path forward in PEP-517 packaging well in hand, finally. We will bootstrap a very limited number of -native packages and all the rest will be new standard tooling to build wheels and install with pip. As upstream has intended since 2019.
<moto-timo>
Say goodbye to eggs and hello to wheels!
<moto-timo>
You have probably been ignoring the fact that ‘setup.py install’ has been emitting deprecation warnings, since they haven’t been that obnoxious.
<JPEW>
moto-timo: \o/
<RP>
moto-timo: sounds promising! :)
<RP>
moto-timo: thanks for persevering with it!
<RP>
JPEW: script turns out to have had a couple of issues, I'll need to bug fix it a little :)
* RP
notes a few warnings on the autobuilder
<Saur[m]>
RP and sgw: I sent a wall of text your way regarding the licensing variables, and how I would like to see them redesigned.