<alejandrohs>
kanavin: saw your post, Im very tempted to buy one haha
mvlad has joined #yocto
zpfvo has joined #yocto
rfuentess has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
Vonter has joined #yocto
<kanavin>
alejandrohs, there's a 90 day trial period
goliath has joined #yocto
leon-anavi has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
tnovotny has joined #yocto
dev1990 has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
mckoan|away is now known as mckoan
Guest21 has joined #yocto
goliath has quit [Quit: SIGSEGV]
<Guest21>
If a custom yocto based system is currently in the future (3 nov 2103) what is the best way to bring back the system to the kernel build date ?
<amitk>
Guest21: change the date on your system to the present and then touch all built files recursively? find . -type f -exec touch {} +
<Guest21>
amitk thx for repply but i would like to do it inside yocto directly
rgov[m] has quit [Quit: You have been kicked for being idle]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
superdupond has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
lucaceresoli has quit [Quit: Leaving]
goliath has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
florian has joined #yocto
manuel1985 has joined #yocto
manuel has joined #yocto
manuel has quit [Client Quit]
manuel has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Guest21 has quit [Ping timeout: 256 seconds]
manuel has quit [Quit: Leaving]
Etheryon has joined #yocto
GillesM has quit [Remote host closed the connection]
GillesM has joined #yocto
* RP
heads afk for food etc after starting an ab test run
<vd>
qschulz: do I need to bitbake something first? bitbake complains about no pkgdata directory
akiCA has quit [Ping timeout: 272 seconds]
<qschulz>
vd: yes
<qschulz>
otavio: see question from jclsn[m] above. I assume the answer is no, since 8 commits and nothing since 2015 :)
<jclsn[m]>
I guess
<jclsn[m]>
Is there not alternative?
<jclsn[m]>
*no
<vd>
qschulz: I meant bitbake something specific for oe-pkgdata, because my project is built already
davidinux has joined #yocto
<qschulz>
vd: I remember it didn't work if I had cleaned my tmpdir, so you probably need to make sure you have built something after cleaning your tmpdir to repopulate some dir it depends on
goliath has quit [Quit: SIGSEGV]
<otavio>
qschulz: jclsn[m]: which question?
<otavio>
about Electron?
<otavio>
sure not
<qschulz>
otavio: yup, about Electron
tnovotny has joined #yocto
<RP>
JPEW: master-next and put BB_STAMP_POLICY = "1" in local.conf
<JPEW>
K
<RP>
michaelo: around on irc>?
<JPEW>
RP: Interesting: `bitbake core-image-minimal` only shows the message once, `bitbake core-image-minimal | cat` shows it twice
<JPEW>
Must be some problem with non-interactive stdio
<RP>
JPEW: hmm, I was just seeing twice with bitbake -p
<JPEW>
Ya, I see that now
<JPEW>
Ah, those messages are reported before we set a logger. Hang on, I think we can re-arrange knotty to fix that
rfuentess has quit [Remote host closed the connection]
<RP>
JPEW: we have to be careful since we can't lose early init messages about failures
<JPEW>
ya
<Saur>
RP: I have figured out the case when the logs go missing now. It is when Python code calls bb.build.exec_func() with a shell function that fails. I have added a test case for it (and a complementary test case for calling bb.build.exec_func() with a Python function that fails). However, I have no good idea on how to correct the code so the logs are added in this case without affecting any of the other cases...
<RP>
Saur: Understanding the issue and having a test case is a good first step!
<RP>
Saur: I can't promise when I'll look but I can try and see if I can work something out at some point
<JPEW>
Ah, actually a really simple solution
<JPEW>
I like those
<RP>
JPEW: I do too!
<Saur>
I want a simple solution too. :(
<RP>
JPEW: hand off of state between the handlers?
<JPEW>
RP: even easier. bb.msg.create_logger() needs the filter
<JPEW>
Sent a patch
<JPEW>
Err, bb.msg.logger_create() :)
<JPEW>
RP: Feel free to squash that into the other logging patch if you want
florian has quit [Quit: Ex-Chat]
mckoan is now known as mckoan|away
<alejandrohs>
rburton: did you manage to sort out that python cryptography +openssl issue?
frieder has quit [Remote host closed the connection]
goliath has joined #yocto
<sgw>
RP: smurray: moto-timo: I will reply to the email, I have some changes for the conversion script that I will send shortly, and I will start reworking the WHITELIST_<license> changes.
<RP>
JPEW: thanks, patch looks good
<Saur>
RP: I sent the added test cases I made to the oe-core list so that you have them, in case you actually do find some time to look at the problem with the missing logs.
<RP>
sgw: I wish I had a better idea of a plan for that license issue :/
<RP>
Saur: having the tests is certainly a good start, thanks
<sgw>
RP: I am going to stare at the code for a while and hope for the best ;-)
<RP>
sgw: my only tip would be to step back and think about what users really need/want and the right API for that
<RP>
sgw: Saur did point at some discussion he previous had on the topic too
<sgw>
Yup, that's what I am going to go back to.
gsalazar has quit [Ping timeout: 272 seconds]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
tnovotny has quit [Quit: Leaving]
<smurray>
RP: per your comment about follow up patches, are you okay with patches to poky master-next split along bitbake/oe-core/etc. lines, or do you want them for the separate repos?
mvlad has quit [Quit: Leaving]
Vonter has quit [Ping timeout: 252 seconds]
<sgw>
smurray: I think they need to be split to the "upstream" repos from poky since that where they need to land ultimately, it might make RP's workflow easier (just a guess)
<smurray>
sgw: I was doing that, but then it wasn't clear what was in poky master-next vs the split out repos. Looking now it seems at least oe-core master-next is up to date
<smurray>
sgw: I'll rejig my setup back again
amitk_ has quit [Ping timeout: 272 seconds]
<landgraf>
I changed KERNEL_IMAGEDEST value (put new value into linux-yocto.inc) but resulted images still uses default one (boot). how to "trigger" that change?
<landgraf>
tried -c cleanall yocto-linux and it didn't help :(
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<landgraf>
the spec file contains the change but resulted rpm doesn't :(
Tokamak has joined #yocto
<RP>
smurray: all the master-nexts in core, bitbake, meta-yocto etc should all be up to date. poky master-next is constructed from them
<smurray>
RP: yeah, I see that now, I'm shifting my patches around
<RP>
smurray: thanks. I'm sure I can work out whatever is needed, I'm kind of used to it
behanw has joined #yocto
Thorn has quit [Ping timeout: 240 seconds]
Thorn has joined #yocto
ecdhe has joined #yocto
<vd>
if I want my distro to bundle all kernel modules, should I add kernel-modules to DISTRO_EXTRA_RDEPENDS or DISTRO_EXTRA_RRECOMMENDS?
ecdhe_ has quit [Ping timeout: 256 seconds]
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mdp has quit [Read error: Connection reset by peer]
mdp has joined #yocto
paulbarker has quit [Ping timeout: 240 seconds]
ndec has quit [Read error: Connection reset by peer]
jamestperk has quit [Read error: Connection reset by peer]
jamestperk has joined #yocto
ndec has joined #yocto
ernstp has quit [Read error: Connection reset by peer]
ernstp has joined #yocto
thierryE has quit [Read error: Connection reset by peer]
paulbarker has joined #yocto
thierryE has joined #yocto
rmmr has quit [Ping timeout: 252 seconds]
rmmr has joined #yocto
superdupond has quit [Quit: Leaving]
<RP>
sgw, smurray: FWIW I queued master-next branches for meta-mingw and meta-gplv2
<smurray>
RP: I'm waiting for some selftests to finish, will send some patches after that
<RP>
smurray: cool
<sgw>
RP: is now the time to re-write the INCOMPATIBLE_LICENSE code vs after 3.5? Asking for a friend ;-) I think I need to write up a proposal first especially if we want to take into account Saur's input
<RP>
sgw: I hate the current interface enough I'd say yes. It does need a proposal and discussion but I'm hoping it wouldn't be so much change it couldn;t be relatively quick?
<RP>
or am I dreaming?
<sgw>
not dreaming, but I try to get something written up, but maybe by monday.
<moto-timo>
I have a python do_compile() task that works and properly sets a variable d.setVar('PYPA_WHEEL', wheel) ... I can read it with d.getVar('PYPA_WHEEL') in the do_compile task... then I try to read the same variable in do_install with ${@d.getVar('PYPA_WHEEL')} and the value is None... really scratching my head on this one
<RP>
sgw: Should I try and take a look tomorrow?
howard[m] has joined #yocto
<sgw>
Nope, give me a day to work in it, you have enough, it's more about getting it written up and then reviewed. I want to consider the impact of adding a COMPATIBLE_LICENSES variable.
<RP>
sgw: ok. I do think it is worth trying to sort some of this out, or just remove some of the functionality
<moto-timo>
what I am trying to do is make the compile and install tasks less hard coded...
<moto-timo>
for the backend classes (flit_core and setuptools_build_meta)
codavi has quit [Ping timeout: 256 seconds]
<smurray>
RP: I've fired off patches to bitbake-devel, oe-core, and yocto for the various bits (later are for BB_DISKMON_DIRS local.conf.sample tweaks)
<smurray>
RP: I've not done the yocto-docs tweak, but will if no one else beats me to it
<vd>
is it a problem is a layer provide a bbappend file for a recipe that no layer provide? (i.e. you don't have the layer providing the base recipe in your BBLAYERS)
<smurray>
you'll get a warning unless you set a variable that disables those
<RP>
smurray: thanks, I was reviewing them as they came in and that look good. master-next updated
<RP>
smurray: I updated autobuilder-helper to match in -next
<smurray>
vd: or maybe it's an error, I forget right off
<smurray>
RP: okay, thanks
<RP>
smurray: meta-yocto technically has patches to the poky list but I doubt it matters much. I missed it at first!
<vd>
smurray: ha. let's say your machine or distro layer configures qt is a certain way. But you use qt in your application layer. Where do you place the qt* bbappends?
<smurray>
RP: ah, sorry, I thought meta-yocto went to the yocto list
<vd>
smurray: I understand that you're supposed to add the bbappends in your application layer with FOO:append:machine:distro I presume?
GNUmoon has joined #yocto
<smurray>
vd: the application layer is also changing the Qt configuration, is that what you mean? I'm not really following
<vd>
smurray: it shouldn't, but the application layer is what provides image recipes with qt applications in them. The qt configuration is mostly for hardware graphics (eglfs) support, input, etc.
<smurray>
vd: there are no hard and fast rules at the end of the day
<vd>
But it feels wrong to add qt5-layer to LAYERDEPENDS_my_machine_layer, just because it enables eglfs support for example
<vd>
same for the distro layer
<smurray>
see the BBFILES_DYNAMIC doc I linked, there's some potential there. meta-freescale has some stuff like that
<moto-timo>
meta-intel uses dynamic-layers also
<smurray>
I'm on the fence, as a BSP consumer I'd almost prefer that not be in the main BSP layer, as the more tweaks like that are in it, the more it can complicate things for people who just want kernel + bootloader
<vd>
ok
* moto-timo
tries a build of my crazy pyprojecttoml branch on qemuarm64 to see how bad it blows up
<vd>
smurray: true. I'm reorganizing the conf for the machine/distro/image tweaks that my product needs, I wanted to split them in bsp/distro/app layers because it felt wrong to have a common meta-myproduct including machine, distro and image variants, but splitting them all kinda complicates things a little and make them not very intuitive.
<smurray>
vd: the Yocto compatible layer guidelines might be helpful to you, though I don't have a pointer right off
<vd>
smurray: it'
* vd
stops there
<RP>
hmm, I look at a few things and suddenly master-next has 70 patches pending again
<moto-timo>
RP: AUH consistently finds 50 recipe upgrades for meta-python :/ no matter how many patches have already landed
<moto-timo>
whack-a-mole
GillesM has quit [Quit: Leaving]
lucaceresoli has quit [Ping timeout: 272 seconds]
florian_kc has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
<zeddii>
moto-timo: I feel that way with the go 'fetcher' things I'm trying
<zeddii>
I've been heads down on it for almost a week, only slightly closer to having something workable for my upgrades.
<moto-timo>
It doesn't help that I had some health issues for about 3 weeks that sucked my energy
<moto-timo>
now I need to figure out WTF the wheel has no version... and pray it isn't fixed in a later setuptools that we can't move to because numpy has reasons
<zeddii>
k3s seems to have about 150 sub fetches / dependencies that I'm attempting to fetch and create a working vendor/ dir
<zeddii>
and this kids, is why we can't let go just fetch whatever it wants during build
<RP>
zeddii: the more you know about what it is really doing, the scarier it gets. Bit like the kernel :)
<RP>
or runqueue
<smurray>
heh
sakoman has quit [Quit: Leaving.]
<moto-timo>
go needs to be in a cage at all times
<zeddii>
I have a script now, that can chase down all of the dependencies, and generate git:// fetch lines. it's crazy how they figure out what to build, and there's some invalid specs, etc
<zeddii>
so yah. VERY crazy.
<moto-timo>
so at some point I wrote a (slow) script to figure out what python3 recipes had pyproject.toml and now I have NO IDEA where it is... wtf... I only use two build machines
<zeddii>
:)
<moto-timo>
maybe IRC history will be my savior (looking at you tgamblin)
<zeddii>
I thought I oom'd my machine trying to do a test k3s build last night, I'm not sure the fetcher likes ~ 200 git:// references
<zeddii>
but that's a problem for another day.
<zeddii>
I need to see it *BUILD* first.
<moto-timo>
ha... I shared the script with tgamblin so irccloud is indeed my cache
<moto-timo>
it was attrociously inefficient... but I also shared the results so \o/