ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
sakoman has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
jclsn1007 has joined #yocto
Circuitsoft has joined #yocto
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
troth has quit [Ping timeout: 260 seconds]
troth has joined #yocto
<rfs613> seeing a pile of errors from setscene about "do_package in both covered and notcovered".
troth has quit [Ping timeout: 260 seconds]
jclsn1007 has quit [Ping timeout: 252 seconds]
jclsn1007 has joined #yocto
troth has joined #yocto
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
<rfs613> only happened once; subsequent build seemed normal.
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
troth has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
camus has quit [Ping timeout: 246 seconds]
jclsn1007 has quit [Ping timeout: 246 seconds]
camus has joined #yocto
troth has joined #yocto
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
zwelch has joined #yocto
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
jclsn1007 has joined #yocto
bonalais has joined #yocto
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
amitk has joined #yocto
camus has joined #yocto
sakoman has quit [Quit: Leaving.]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
michalkotyla has quit [Quit: michalkotyla]
michalkotyla has joined #yocto
amatilu has joined #yocto
rfuentess has joined #yocto
<LetoThe2nd> yo dudX
amatilu has quit [Quit: Leaving]
mckoan|away is now known as mckoan
<mckoan> good morning
Wouter0100 has quit [Ping timeout: 260 seconds]
Wouter0100 has joined #yocto
kuzz_ has quit [Quit: Konversation terminated!]
kroon has joined #yocto
Wouter0100 has quit [Ping timeout: 260 seconds]
bonalais has quit [Quit: Connection closed for inactivity]
mojuser has quit [Quit: Client closed]
xmn has quit [Ping timeout: 256 seconds]
gsalazar has joined #yocto
Schlumpf has joined #yocto
mvlad has joined #yocto
<RP> abelloni: depends on whether we do something like our own version of make
<RP> rfs613: any idea of how to reproduce it? Was it with master?
dev1990 has joined #yocto
kz69 has joined #yocto
kz69 has quit [Client Quit]
ramos has joined #yocto
lexano_ has quit [Ping timeout: 240 seconds]
ramos has left #yocto [#yocto]
smrf has joined #yocto
dacav has joined #yocto
manuel has joined #yocto
<smrf> Hi o/
<manuel> I have `file` on my image, but `oe-pkgdata-util find-path /usr/bin/file` is unable to find any package producing that path. Anyone know why?
<smrf> is there possibility to debug sstate-cache server in devtool from eSDK? In bitbake I was able to add -DDD option but with devtool I see only -d which doesn't provide  SState data.
lucaceresoli1 has joined #yocto
lucaceresoli has quit [Quit: Leaving]
<LetoThe2nd> manuel: is it an actual file, or only a symlink?
<abelloni> RP: isn't your master-next stuck too ? :)
manuel1985 has joined #yocto
<RP> abelloni: yes, looks like it :(
selff has joined #yocto
<kroon> manuel, maybe try "oe-pkgdata-util find-path */file" first
florian has joined #yocto
<manuel> LetoThe2nd: You are right, it's a symlink. If I use the symlink target it works. Thanks!
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
blahblah has joined #yocto
blahblah is now known as tomzy_0
tomzy_0 is now known as tomzy
tomzy is now known as TomaszAIR
TomaszAIR is now known as tomzy_0
tomzy_0 has quit [Quit: Client closed]
tomzy_0 has joined #yocto
tomzy_0 has quit [Client Quit]
tomzy_0 has joined #yocto
leon-anavi has joined #yocto
kranzo has joined #yocto
<Saur[m]> RP: Why is `ERROR_QA` included in `BB_HASHEXCLUDE_COMMON`? If I add a new QA test to `ERROR_QA`, I would expect `package_qa` to be rerun and catch any offenders of the new test.
<rburton> from memory, it's a tricky one. if the package's output depends on the qa tests then changing the tests means sstate can't be reused
Circuitsoft has quit [Quit: Connection closed for inactivity]
<RP> Saur[m]: I think ERROR_QA isn't just used by package_qa
<RP> https://justus.science/blog/2015/04/19/sys.modules-is-dangerous.html makes for interesting and depressing reading
kroon has quit [Ping timeout: 260 seconds]
<amahnui[m]> Hello everyone, I am currently following the instructions on docs.yoctoproject.org/brief-yoctoprojectqs/index.html and I'm currently stuck on the "source oe-init-build-env" command where I get the error "No such file or directory"
<amahnui[m]> Please how can I get around this
<rburton> did you cd into the poky directory?
<kranzo> Hi there i'm on dunfell and search for the proper way to eliminate insane[file-rdeps] for a nativesdk- package. TOOLCHAIN_HOST_TASK_append = " nativesdk-python3" breaks the python3 interpreter in the esdk and RDEPENDS_${PN} = "python3" on package level just does nothing. Any advice?
<rburton> kranzo: whats the error?
<amahnui[m]> > did you cd into the poky directory?
<amahnui[m]> Yes I did
<rburton> then there should be a file called oe-init-build-env in there
<rburton> oh, are you on bsd?
lucaceresoli1 has quit [Quit: Leaving]
<Saur[m]> @rp
<kranzo> rburton  do_package_qa: QA Issue: <path/to/script>.py contained in package nativesdk-<package> requires /usr/bin/python3, but no providers found in RDEPENDS_nativesdk-<package>? [file-rdeps]
<rburton> kranzo: change path/to/script.py to do '/usr/bin/env python3'
<amahnui[m]> > oh, are you on bsd?
<amahnui[m]> But I succeeded to install freebsd though I don't have a gui there yet but it is working well on the text console.
<amahnui[m]> And there is indeed a file called oe-init-build-env
<amahnui[m]> No I'm on Ubuntu
<rburton> sounds like you're using a non-bash shell
<rburton> change source to .
<rburton> so $ . oe-init-build-env
<smrf> is there possibility to debug sstate-cache server in devtool from eSDK? In bitbake I was able to add -DDD option but with devtool I see only -d which doesn't provide  SState data.
<smrf> also is there psosibility to check variables with devtool in eSDK like in bitbake with -e option ?
<kranzo> rburton wow way to obvious ..  thx. anyway is it known that TOOLCHAIN_HOST_TASK_append = " nativesdk-python3" leads to a "no such file or directory" error when calling python3 from the esdk?
<rburton> not without live-debugging
<rburton> pretty sure we've a test for that
<rburton> as buildtools has the same base, and ships python
<RP> Saur[m]: did you mean to add something there?
<amahnui[m]> rburton: I get "bash: /home/prodib/Desktop/project: No such file or directory" when I run . oe-init-build-env"
<Saur[m]> Well, I started writing, but accidentally hit Return. I'm currently doing some more testing and I'll get back to you...
<RP> Saur[m]: the commit where it was added may have info
<rburton> amahnui[m]: something went very wrong. what is this project directory?
<RP> Saur[m]: I seem to remember not being happy about it but didn't see another option
<RP> rburton: https://bugs.python.org/issue43546 seems close but still doesn't help :/
<amahnui[m]> rburton: Its in /Desktop/project folder/poky
<rburton> oh
<rburton> don't use spaces
<amahnui[m]> Maybe I see the issue now
<rburton> linux doesn't like spaces in directories
<Saur[m]> @rp, rburton : Seems Ross is to blame: "I discovered bitbake rebuilding packages because WARN_QA had changed. These variables don't influence the output, so add them to the whitelist." While that is true for `WARN_QA`, I do not agree when it comes to `ERROR_QA`.
* rburton runs
<amahnui[m]> rburton: Yea let me change the folder name
<amahnui[m]> Thanks
<qschulz> amahnui[m]: yeah, most programs aren't tested with paths with spaces in them, just use _ or - to separate words in directory or file names
manuel1985 has quit [Ping timeout: 240 seconds]
<rburton> RP: never seen anything like that before
<amahnui[m]> qschulz: I will use separators from now on
<RP> I just don't see how a thread can be stuck in the same import in two places
<amahnui[m]> <qschulz> "amahnui: yeah, most programs..." <- Is there a way we could make yocto project to use "" for all directories so that in such cases it will just take it as a single directory and not two different words
<qschulz> amahnui[m]: it's not that simple. most of Yocto is python-based and some things are split by spaces
<qschulz> so having quotes around the variables won't help with the space splitting in that case
<qschulz> that being said, I don't know how much is broken by spaces in paths in Yocto. I know externalsrc does not like it don't know about more conventional use
<rburton> the problem isn't yocto itself, but the vast amount of software it builds
<qschulz> amahnui[m]: that being said, you can send a patch to have double quotes around variables in the oe-init-buildenv script, that's for sure
<rburton> we'd have to guarantee that all of that was safe with spaces too
<rburton> yes, oe-init-build-env should work, but i'm fairly certain the actual build will fail for reasons out of our control
<RP> when you get further in I think bitbake will tell you we can't build with spaces in the pahs
<RP> paths
<qschulz> rburton: maybe we could add a check in it to say that it's not supported
<rburton> RP: yeah me too
<rburton> so we should let oe-init-build-env work so bibake can tell you nicely :)
troth has quit [Ping timeout: 246 seconds]
<qschulz> RP: wouldn't be surprised since builds in specific directories are forbidden too :)
<qschulz> -too
<RP> I think autotools doesn't work with spaces and when I discovered that, I gave up on the idea of supporting it
<Saur[m]> RP: I tried removing `ERROR_QA` from `BB_HASHEXCLUDE_COMMON`, and it does give me the behavior I want, i.e., `do_package_qa` ir rerun. However, it rebuilds a lot more than I expected, which is due to `do_qa_patch` (which checks `ERROR_QA` to see if it should error out on patch fuzz). While it is unfortunate, I still think it is the right thing to do....
<rburton> i'd say a deal-breaker is sstate not being reusable if error_qa is different, so check that use-case
<Saur[m]> rburton: How do you mean?
<rburton> i honestly believe that the final sstate shouldn't depend on the amount of QA being used
<rburton> presumably hashequiv mitigates that
<amahnui[m]> <qschulz> "rburton: maybe we could add a..." <- How can we do this please
<rburton> amahnui[m]: easiest is to just add quotes as needed to oe-init-build-env
<rburton> so it works, and then later bitbake will error out with its more comprehensive path name restrictions
<Saur[m]> rburton: But if you add a completely new QA test to `ERROR_QA`, how can you say the build is successful unless you actually rerun the QA tests?
<RP> Saur[m]: It means all sstate is invalidated when you change ERROR_QA
<RP> Saur[m]: ideally we should fix do_qa_patch to a contains reference, then it might not
<amahnui[m]> rburton: Okay thanks
<amahnui[m]> Please I need pointers to the files so I can comence with chages
<rburton> amahnui[m]: oe-init-build-env and whatever it then calls (which is at least one, maybe two, other scripts). Add quotes around the path names as needed.
<Saur[m]> RP: What do you mean with a "contains reference"?
<RP> Saur[m]: use the same magic as we use to stop changing DISTRO_FEATURES from triggering world rebuilds
<rburton> ewww do_qa_patch doesn't even split()
<RP> the magic that probably isn't even in the manuals :(
<RP> rburton: I now just don't want to look
<amahnui[m]> rburton: Okay I understand now. I thought I was doing it in the code base
<amahnui[m]> I had changed the directory to have just a single name
<rburton> amahnui[m]: fixing it properly is a code change
<rburton> renaming your build directory is needed, but we can give a nice error instead of aborting
* qschulz hears magic and docs in the same sentence thus runs away
<rburton> coward!
<amahnui[m]> rburton: Yes thats what I meant.
<amahnui[m]> I wish to ask if I could work on adding the error message with help from you
<qschulz> amahnui[m]: we believe the error message will just show itself once you try to build something with bitbake
<qschulz> but you need to reach this moment
<qschulz> therefore, fixing the oe-init-buildenv script (and possibly other scripts it calls during its sourcing) is the first step
<amahnui[m]> I also wish to ask where I can get good first issues for beginners so I can work on
<qschulz> amahnui[m]: this one is a good task actually, it'll help you familiarize with the submission process
Schlumpf has quit [Ping timeout: 250 seconds]
<qschulz> amahnui[m]: https://docs.yoctoproject.org/ref-manual/resources.html for how to contribute
<qschulz> amahnui[m]: we have newcomers bugs, let me find a link for you
<rburton> the newcomer list isn't great, i glance at it last week
troth has joined #yocto
<qschulz> i'll refrain to point to it then :)
<qschulz> rburton: but.. you just said it isn't great
<rburton> sure but the page is still useful
<amahnui[m]> <qschulz> "amahnui: https://docs.yoctoproje..." <- Thanks for this
<amahnui[m]> thanks I'll go through it
<qschulz> amahnui[m]: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve
<amahnui[m]> > amahnui: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve
<amahnui[m]> qschulz I will do just that
<rburton> hm i wonder why my build isn't pulling rust-native from the ab's sstate :(
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
dtometzki has joined #yocto
manuel1985 has joined #yocto
<RP> rburton: I wish we could query this better :/
kroon has joined #yocto
goliath has joined #yocto
lexano has joined #yocto
zen_coder has joined #yocto
<RP> you know the day is going to go well when you have to compile your own copy of the python interpreter for debugging :(
<qschulz> RP: at that point, let's just rewrite everything in rust
* qschulz runs for his life
JaMa has quit [Quit: reboot]
michalkotyla has quit [Read error: Connection reset by peer]
<rfs613> RP: unfortunately no, it only happened once. It was on dunfell branch, and I had previously built it. I did "git pull --rebase" (I had my CVE fix for bluez5 on top). Then I ran bitbake again and got 600x this strange error. Did the same steps again and no more error.
<rfs613> the 'git pull' in this case brought in perhaps 1-2 days of changes.
<rfs613> if it happens again I will try to investigate further.
michalkotyla has joined #yocto
JaMa has joined #yocto
Schlumpf has joined #yocto
<selff> hi, im trying to create  wlan1 interface with "iw dev wlan0 interface add wlan1 type managed" but im getting this error : command failed: Device or resource busy (-16)
manuel1985 has quit [Ping timeout: 260 seconds]
selff has quit [Quit: Client closed]
Guest11 has joined #yocto
<Guest11> Anddd I'm back
<Guest11> Nvidia's mirrors are down
<Guest11> rburton 🙈
<qschulz> Guest11: if you have a local copy somewhere, just create a PREMIRROR for it and you're good to go
<rburton> if you have a local copy, you can put it directly into DL_DIR (and touch a corresponding .done file)
<rburton> not sure what else we're meant to do about nvidia's servers being offline
tomzy_0 has quit [Quit: Client closed]
<amahnui[m]> > amahnui: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve
<amahnui[m]> https://docs.yoctoproject.org/singleindex.html#:~:text=To%20use%20such%20mirrors%2C%20uncomment%20the%20below%20lines%20in%20your%20local.conf%20file%20in%20the%20Build%20Directory%3A
<amahnui[m]> * > amahnui: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve
<amahnui[m]> My build folder is not visible, I don't Know why but I manually searched for the folder before seeing it and also the local.conf is under the conf folder.
<amahnui[m]> https://docs.yoctoproject.org/singleindex.html#:~:text=To%20use%20such%20mirrors%2C%20uncomment%20the%20below%20lines%20in%20your%20local.conf%20file%20in%20the%20Build%20Directory%3A
<JaMa> anyone seen python3-setuptools-native failing with ValueError: ZIP does not support timestamps before 1980 ?
kroon has quit [Quit: Leaving]
<qschulz> amahnui[m]: could you elaborate about the "my build folder is not visible" ?
<qschulz> amahnui[m]: for local.conf replacement by conf/local.conf, please send us a patch to fix this. https://git.yoctoproject.org/yocto-docs is where the sources of the documentation are.
<qschulz> amahnui[m]: https://docs.yoctoproject.org/singleindex.html#term-Build-Directory explains where the build directory is
<amahnui[m]> > amahnui: could you elaborate about the "my build folder is not visible" ?
<amahnui[m]> When I search using the search bar, I can see it among the results, when I right click and select open item in location, it takes me to the poky directory but still the build folder is not showing there
<amahnui[m]> There is the build folder in poky but as shown in this screenshot there is no build folder
<qschulz> is this schrödinger's build folder :)? both present and absent
<qschulz> amahnui[m]: what's the exact command you used to source oe-init-buildenv?
<qschulz> your seach bar seems to be doing a recursive search
manuel1985 has joined #yocto
<amahnui[m]> I don't actually know, but the local.conf folder is found in /build/conf/local.conf
<amahnui[m]> > is this schrödinger's build folder :)? both present and absent
<amahnui[m]> > amahnui: what's the exact command you used to source oe-init-buildenv?
<amahnui[m]> source oe-init-build-env
<qschulz> amahnui[m]: from which directory?
<qschulz> amahnui[m]: mmmm, was this the same terminal from where you tried to source o-einit-build-env when you had a space in the path?
<qschulz> if that is the case, i'd suggest starting a new terminal and source from there
<amahnui[m]> > amahnui: mmmm, was this the same terminal from where you tried to source o-einit-build-env when you had a space in the path?
<amahnui[m]> yes it is but I restarted the whole processes as you said in the next message
Piraty is now known as ping
ping is now known as Piraty
<amahnui[m]> but the bitbake command is running well
amitk has quit [Ping timeout: 256 seconds]
Schlumpf has quit [Quit: Client closed]
<qschulz> amahnui[m]: bitbake -e busybox | grep "^BUILDDIR" to know where your build directory is
<qschulz> but from a brand new terminal (type "exit" and then start terminal again), from poky directory, source o-einit-build-env should create a build directory in the poky directory
amitk has joined #yocto
kranzo has quit [Quit: Client closed]
<amahnui[m]> > but from a brand new terminal (type "exit" and then start terminal again), from poky directory, source o-einit-build-env should create a build directory in the poky directory
<amahnui[m]> Now the build folder is visible
<amahnui[m]> this worked
codavi has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
Guest11 has quit [Quit: Connection closed]
kranzo has joined #yocto
kranzo has quit [Client Quit]
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
hcg has joined #yocto
<amahnui[m]> Hello qschulz I did the change on my local repository and used the command git send-email -1 --to docs@lists.yoctoproject.org. Please is there something else I had to do? I new to using git directly
<qschulz> amahnui[m]: you need to be subscribed to the mailing list first
<qschulz> amahnui[m]: https://lists.yoctoproject.org/
<qschulz> https://lists.yoctoproject.org/g/docs/join this one specifically
<qschulz> and you'll need to subscribe to another mailing list for sending patches to bitbake, openembedded-core or poky but that'll come later :)
<qschulz> to know if your mail made it to the public, you can check it appears in the archives: https://lists.yoctoproject.org/g/docs/messages (wait a few minutes before thinking there's a problem with your setup)
<amahnui[m]> okay thank you so much🙏
<amahnui[m]> I am currently signing up for them
<qschulz> amahnui[m]: looking forward to your patch!
<qschulz> +receiving
<amahnui[m]> > amahnui: looking forward to your patch!
<amahnui[m]> Please I wish to ask if the command git send-email -1 --to docs@lists.yoctoproject.org is enough to send the patch after doing the changes
<qschulz> amahnui[m]: mmm I always use git format-patch first to create a patch file and then pass this filename to the git send-email command
<amahnui[m]> Please I wish to ask if the command "git send-email -1 --to docs@lists.yoctoproject.org" is enough to send the patch after doing the changes after subscribing to the mailing list
<rburton> yes
<qschulz> amahnui[m]: but you can test yourself if your whole setup is correctly configured by modifying the --to to point to your personal address
<amahnui[m]> okay I will test it out now
<rburton> you'll need to register at lists.yoctoproject.org too i think, otherwise you'll be in a moderate queue and that might take a while
smrf has quit [Ping timeout: 250 seconds]
<amahnui[m]> > you'll need to register at lists.yoctoproject.org too i think, otherwise you'll be in a moderate queue and that might take a while
<amahnui[m]> I just checked the link out and my subscription was approved.
<amahnui[m]> The command "git send-email -1 --to docs@lists.yoctoproject.org" gives me the error message "git: 'send-email' is not a git command."
<rburton> you need to install git-send-email,
<amahnui[m]> > you need to install git-send-email,
<amahnui[m]> Thanks I'm on it
Minvera has joined #yocto
<amahnui[m]> Please I wish ask if it is normal to have this screen
xmn has joined #yocto
<rburton> amahnui[m]: you're not posting your commit
hcg has quit [Quit: Client closed]
<rburton> its going to post michael's migration guide commit there
<rburton> amahnui[m]: did you git commit your change first?
<rburton> you didn't save anything then
<amahnui[m]> Even though I did some changes
<rburton> git can't see them, so you either didn't save, or you're in the wrong directory
<amahnui[m]> Okay I will clone the repository again with the current git settings
goliath has quit [Quit: SIGSEGV]
<rburton> no need, just look where you saved the changes and be sure its in the same clone that your terminal is in
<amahnui[m]> Okay I will do that
rfuentess has quit [Remote host closed the connection]
florian_kc has joined #yocto
Tibor has joined #yocto
<Tibor> Hello Yocto Community, I am not sure that I am using the right forum, so please bare with me. I have a question about how I can create multiple partitions with multiple file systems in one Yocto build. Is this right place to ask for any idea?
<qschulz> Tibor: have a look at wks files which are config files for wic and use IMAGE_FSTYPES wic for your image
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@dynamic-093-133-086-069.93.133.pool.telefonica.de))]
florian_kc is now known as florian
florian_kc has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<amahnui[m]> > no need, just look where you saved the changes and be sure its in the same clone that your terminal is in
<amahnui[m]> I think I'm in the right directory because I did some changes in the README.md just to see if "git status" will show that there are changes and it acknowledged the changes in the README but it does not do same for index.html
<amahnui[m]> I also checked gitignore to see if index.html has been added to it but I wasn't
<rburton> what index.html?
<rburton> in the documentation?
<rburton> that's generated, you want to edit the .rst files
<amahnui[m]> yes that in documentation
<amahnui[m]> /yocto-docs/documentation/_build/html/brief-yoctoprojectqs/index.html
<Tibor> Thank you, qschulz. What is not clear how I can preserve the file permissions. Here is some detail: I want to put a few files with a special owner into a separate partition. In the do_install step, I use chown, and if I do not move these files into a separate partition, all work fine. However, if I followed this instruction
<Tibor> https://stackoverflow.com/questions/56187209/yocto-create-and-populate-a-separate-home-partition the files are properly moved into the other partition, but I loose the ownership settings.
<rburton> amahnui[m]: edit documentation/brief-yoctoprojectqs/index.rst, that's the source file
<amahnui[m]> rburton: thanks I'm on it
leon-anavi has quit [Quit: Leaving]
gsalazar has quit [Ping timeout: 260 seconds]
mckoan is now known as mckoan|away
<amahnui[m]> > amahnui: edit documentation/brief-yoctoprojectqs/index.rst, that's the source file
<amahnui[m]> I had some issues with SMPT: "Unable to initialize SMTP properly." but it's finally working now
<amahnui[m]> I sent the patch.
florian has quit [Ping timeout: 240 seconds]
bonalais has joined #yocto
artie1977 has joined #yocto
<artie1977> Hello everyone. I'm having difficulties building yocto recipe that uses rust+gtk3 project. I did successfully manage to create recipe for c++ and gtk3 as well as my own custom image, but the rust+gtk3 is simply not happening. I'm on poky branch master-next.
<artie1977> I just want to add that the project rust+gtk3 is building and running successfully on host machine
artie1977 has quit [Client Quit]
artie1977 has joined #yocto
artie1977 has quit [Client Quit]
artie1977 has joined #yocto
artie1977 has left #yocto [#yocto]
artie1977 has joined #yocto
artie1977 has quit [Quit: Client closed]
roussinm has joined #yocto
Tibor has quit [Ping timeout: 250 seconds]
mvlad has quit [Remote host closed the connection]
<kergoth> Huh, I forgot https://github.com/kergoth/dotfiles/blob/master/bitbake/scripts/oeclone existed. Clones a layer by querying layer index and filtering with fzf to prompt for selection if it finds multiple matching the query. i.e. oeclone meta-clang, or the like. handy
<kergoth> well, scraping really. do we have an official mechanism to do that?
<kergoth> oh, righ,t there's a bitbake-layers command, but would require from a build dir
amitk has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
<manuel1985> Which bitbake command do I have to run if I want to clean `build/tmp/deploy/images/<machine>`?
bonalais has quit [Quit: Connection closed for inactivity]
<kergoth> RP: we're importing in base.bbclass with __import__, not import, and adding to context, not sys.modules, so i tihnk we don't need to restore sys.modules, but we might need to think about how to go about invalidating old imports that reside in bb.utils._context. Do we clear it out entirely every time we reparse the config? Do we do that already? anyway, i think sys.path is probably the most important part right now
<kergoth> I also think we'll be able to do something like https://gist.github.com/kergoth/33c11ac5aa0b130e095743d5405e6fd2 to avoid modifiying and then restoring sys.path in the long term, after adding the layer.conf mechanism.
<RP> kergoth: I think __import__ will update sys.modules though
<RP> kergoth: We do already clear bb.utils._context and sys.path wasn't enough
<kergoth> Hmm, okay, interesting. I'll have to read the importlib code
<RP> kergoth: I have spent the day staring at it as I have an interesting reproducer for what I think is a bug in python itself :/
<kergoth> wonder if importlib.import_module has the same side-effect. i think that's what wer'e supposed to be doing nowadays anyway
<kergoth> yikes
<RP> kergoth: see what you make of https://bpa.st/5CVA
<RP> kergoth: note that I'm hacking importlib so you may need to make aquire() match your python but the code hasn't changed much recently
* moto-timo needs a week off to catch up with “what we’re supposed to be doing nowadays”
<moto-timo> 2014 is calling and wants your old Python knowledge back.
<moto-timo> (Last timeframe I was going deep Internals)
<moto-timo> s/going/doing/
<RP> I'm open to opinions from anyone on the above "reproducer"
<RP> it is the only real way I can imagine that code breaking in the way we've seen it break but what the interrupt is in our runtime case, I don't know
<RP> I mocked it up with an alarm signal just to prove it is possible
<kergoth> Ah, so they both set _blocking_on and then both try to delete it from there, but only one of those succeeds
<kergoth> Interesting
<kergoth> I can't imagine we'd be trying to import in a signal handler, though
<RP> kergoth: I can't see where we are, but one of the python libs might be?
<RP> kergoth: I decided to file https://bugs.python.org/issue47195
<RP> kergoth: it might also not be a signal handler, although I don't know what else it could be
<kergoth> Clearly the keyerror is a bug, it should error out more cleanly even if it's doing something that's not allowed
<kergoth> I wonder how we can avoid the situation, though
<RP> kergoth: All I could think of was hooking acquire and checking in advance but that would be horribly hardcoded :/
<RP> kergoth: if we make it traceback at the start we'd at least know which code is causing it
<kergoth> Yeah, we need that traceback for sure, the one we have doesn't show the actual import line?
<RP> kergoth: we know the second import but never the first
<kergoth> ah, of course
<kergoth> since that one doesn't fail
<RP> kergoth: right, you can argue about which is first and second but yes, we only know the not useful one
<JaMa> rburton: opkg is failing with "nothing provides python3-cryptography-vectors = 36.0.2 needed by python3-cryptography-ptest-36.0.2-r0.0.qemux86_64" even when I do have python3-cryptography-vectors_36.0.2-r0.0_qemux86_64.ipk and python3-cryptography-ptest_36.0.2-r0.0_qemux86_64.ipk
<Saur[m]> RP: Would it make sense to add `do_devshell[network] = "1"`?
<RP> Saur[m]: that is a tough call
<Saur[m]> Yeah, it is not obvious which is correct...
<JaMa> rburton: is rpm parsing the version differently or is the issue somewhere else
<JaMa> rburton: I guess forcing identical EXTENDPKGV between python3-cryptography and python3-cryptography-vectors would be too much as well for people with PRserv
<Saur[m]> For the record, I've just had the most bizarre experience for the last couple of hours. All of a sudden my build started to fail when running `do_patch` for one of our recipes, due to it failing to do `git ls-remote` using ssh. It failed with an error about ssh considering the ownership of a file in `/etc/ssh/ssh_config.d/` to be incorrect. A lot of googling and bisecting later I finally figured it was due to the use of unshare, which causes the
<Saur[m]> files owned by root to show up as owned by nobody when unshared, and that triggers ssh to not accept them. While trying to figure this out I used devshell, which failed the same way when I tried to run ssh in it. So in this case it was lucky for me that devshell doesn't have network enabled. And eventually, of course, the build started to work again by itself...
<RP> Saur[m]: it could be the revision is in the cache now so you don't see the error any more?
<RP> Saur[m]: we're supposed to only be changing the network situation with the unshare call
<Saur[m]> RP: Definitely likely.
<Saur[m]> I think the problem started when I ran `bitbake --runall=package_qa <some packagegroup>`, something I normally don't do.
sakoman has quit [Quit: Leaving.]
YuktiSharma[m] has joined #yocto
Minvera has quit [Remote host closed the connection]
<Saur[m]> RP: Btw, based on the discussion we had earlier today about ERROR_QA, I changed the code in do_qa_patch() to check whether "patch-fuzz" is set in ERROR_QA using bb-utils.filter(). That solved both the problem to make it depend only changes to patch-fuzz in ERROR_QA and not unrelated QA tests, and the lack of splitting the value of ERROR_QA before looking for patch-fuzz in it.
<RP> Saur[m]: sounds good
<Saur[m]> Turned out I made the right thing regarding contains when I added bb.utils.filter() many years ago. :)
<RP> JPEW, kergoth: I wonder if asyncio could be making an import instead of a signal handler to trigger this?
<moto-timo> JaMa: we might have to bite the bullet and merge python3-cryptography and python3-cryptography-vectors into one recipe. They absolutely MUST be kept in lock step.
sakoman has joined #yocto
florian has joined #yocto
<RP> kergoth: not sure I'll catch anything but trying https://git.yoctoproject.org/poky/commit/?h=master-next&id=6fa79a80e812c20b6be21a2ea21728902e053f19 in master-next...
zen_coder has quit [Ping timeout: 240 seconds]
ar__ has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 260 seconds]
* JPEW reads back to catch up
<JPEW> I don't think it would be asyncio. Async behaves like "normal" python Ingles unless it's an explicit async call, and in don't think there is an 'async import'... It wouldn't really make sense to have one since it's imports shouldn't be blocking
goliath has joined #yocto