Monday, 2022-04-04

*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)00:07
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)00:16
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto00:22
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds)00:29
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto00:34
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)00:39
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto00:45
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:55
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)00:57
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:03
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds)01:09
*** starblue <starblue!~juergen@dslb-094-221-182-149.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 246 seconds)01:14
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:15
*** starblue <starblue!~juergen@dslb-088-078-108-004.088.078.pools.vodafone-ip.de> has joined #yocto01:16
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)01:20
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:25
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds))01:32
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:33
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds)01:41
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:47
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds)01:53
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:57
*** agrue <agrue!~agrue@035-133-169-019.res.spectrum.com> has quit IRC (Ping timeout: 250 seconds)02:00
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)02:02
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 246 seconds)02:06
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto02:06
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:08
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto02:11
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:14
*** jclsn1007 <jclsn1007!~jclsn@149.224.193.180.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)02:16
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)02:21
*** amitk <amitk!~amit@103.208.69.126> has joined #yocto02:22
amahnui[m]<vmeson> "amahnui: it depends on what..." <- What i run is bitbake core-image-sato02:24
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:28
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)02:37
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:42
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds)02:48
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:52
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds))03:02
*** jclsn10074 <jclsn10074!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto03:03
amahnui[m]I succeeded to install freebsd and its de finally 🥳03:12
*** Guest82 <Guest82!~Guest82@tel3187175.lnk.telstra.net> has joined #yocto04:21
*** Portia[m] is now known as PortiaOld[m]04:29
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)04:34
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto04:48
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit)04:49
amahnui[m]I'm currently working from there04:50
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto05:10
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds)05:13
*** rob_w <rob_w!~rob@2001:a61:60c9:601:1dc7:3566:940e:e217> has joined #yocto05:53
*** mtaluca <mtaluca!~mtaluca@37.159.78.98> has joined #yocto06:23
hmw[m]Hi when i run a qt application with gdb conneted i get a sigill on starting a mysql db connection when i don´t connect gdb the application runs fine ( with mysql connection)06:26
*** mtaluca <mtaluca!~mtaluca@37.159.78.98> has quit IRC (Ping timeout: 260 seconds)06:28
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto06:28
*** mckoan|away is now known as mckoan06:35
mckoangood morning06:35
LetoThe2ndyo dudX, yo mckoan06:35
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (*.net *.split)06:39
*** fullstop <fullstop!~fullstop@user/fullstop> has quit IRC (*.net *.split)06:39
*** Ebeneezer_Smooge <Ebeneezer_Smooge!~Smooge@centos/qa/smooge> has quit IRC (*.net *.split)06:39
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (*.net *.split)06:39
*** sotaoverride <sotaoverride!~ubuntu@ec2-3-140-186-148.us-east-2.compute.amazonaws.com> has quit IRC (*.net *.split)06:39
*** LetoThe2nd <LetoThe2nd!~Josef_Hol@ec2-52-29-15-71.eu-central-1.compute.amazonaws.com> has quit IRC (*.net *.split)06:39
*** flynn378 <flynn378!sid63564@2a03:5180:f:3::f84c> has quit IRC (*.net *.split)06:39
*** jonmason <jonmason!sid36602@2a03:5180:f:2::8efa> has quit IRC (*.net *.split)06:39
*** Shaun <Shaun!~shaun@user/shaun> has quit IRC (*.net *.split)06:39
*** flynn378 <flynn378!sid63564@id-63564.ilkley.irccloud.com> has joined #yocto06:39
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto06:39
*** Shaun <Shaun!~shaun@mail.oneil.me.uk> has joined #yocto06:39
*** SSmoogen <SSmoogen!~Smooge@centos/qa/smooge> has joined #yocto06:40
*** jonmason <jonmason!sid36602@2a03:5180:f:2::8efa> has joined #yocto06:40
*** fullstop <fullstop!~fullstop@user/fullstop> has joined #yocto06:41
*** LetoThe2nd <LetoThe2nd!~Josef_Hol@ec2-52-29-15-71.eu-central-1.compute.amazonaws.com> has joined #yocto06:41
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto06:42
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC (*.net *.split)06:43
*** Habbie <Habbie!peter@lorentz.7bits.nl> has quit IRC (*.net *.split)06:43
*** zeddii <zeddii!~zeddii@173.34.88.218> has quit IRC (*.net *.split)06:43
*** erbo <erbo!~erik@linode.unixshell.se> has quit IRC (*.net *.split)06:43
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has quit IRC (*.net *.split)06:43
*** smurray <smurray!sid98062@id-98062.hampstead.irccloud.com> has quit IRC (*.net *.split)06:43
*** mischief <mischief!~mischief@wopr.sciops.net> has quit IRC (*.net *.split)06:43
*** svuorela <svuorela!~svuorela@ssh.killmulehill.net> has quit IRC (*.net *.split)06:43
*** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has quit IRC (*.net *.split)06:43
*** erbo <erbo!~erik@linode.unixshell.se> has joined #yocto06:43
*** zeddii <zeddii!~zeddii@173.34.88.218> has joined #yocto06:43
*** smurray <smurray!sid98062@id-98062.hampstead.irccloud.com> has joined #yocto06:43
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has joined #yocto06:43
*** svuorela <svuorela!~svuorela@ssh.killmulehill.net> has joined #yocto06:43
*** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto06:43
*** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto06:43
*** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #yocto06:43
*** sotaoverride <sotaoverride!~ubuntu@ec2-3-140-186-148.us-east-2.compute.amazonaws.com> has joined #yocto06:44
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto06:50
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto06:56
*** davidinux <davidinux!~davidinux@217.138.219.172> has joined #yocto07:01
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto07:03
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Read error: Connection reset by peer)07:10
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto07:10
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Read error: Connection reset by peer)07:12
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has joined #yocto07:12
*** gsalazar <gsalazar!~gsalazar@132.120.90.149.rev.vodafone.pt> has joined #yocto07:13
*** sstiller <sstiller!~sstiller@p200300f07f136c00da52e5339fdd8442.dip0.t-ipconnect.de> has joined #yocto07:14
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:18
*** dacav <dacav!~dacav@h94-245-9-203.cust.a3fiber.se> has quit IRC (Remote host closed the connection)07:21
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto07:22
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto07:23
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto07:31
*** sstiller <sstiller!~sstiller@p200300f07f136c00da52e5339fdd8442.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer)07:37
*** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto07:55
*** zeddii <zeddii!~zeddii@173.34.88.218> has quit IRC (Ping timeout: 246 seconds)08:03
*** zeddii <zeddii!~zeddii@173.34.88.218> has joined #yocto08:03
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto08:12
qschulzo/08:13
LetoThe2ndqschulz: \o08:25
*** willo <willo!~quassel@60-241-162-73.static.tpgi.com.au> has quit IRC (Ping timeout: 240 seconds)08:29
*** willo <willo!~quassel@60-241-162-73.static.tpgi.com.au> has joined #yocto08:29
kanavin_here's a question I don't know an answer for. Where does the convention for PASS/FAIL test markers come from?08:41
*** florian_kc is now known as florian08:43
RPkanavin_: I think we used something existing as a basis for our ptest standard, maybe from autoconf's tests?08:52
kanavin_RP: right, I'm now trying to find where in auto-land those markers are actually defined :)08:53
kanavin_libxml upstream is asking that as somehow it's not obvious to them in my patch submission - "08:53
kanavin_tests: print PASS/FAIL for the tests08:53
kanavin_"08:53
kanavin_found it https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html09:02
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto09:12
Saur[m]RP: If you add `ROOTFS_POSTPROCESS_COMMAND:remove = "foobar"` to your configuration, parsing will fail. This is due to an error introduced in bitbake commit 6aecc2fe where you add an argument to a call to handle_remove() which should not be there.09:19
Saur[m]What I do not understand is why `ROOTFS_POSTPROCESS_COMMAND` triggers that code path, as it is supposed to be for shell functions.09:20
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)09:23
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 246 seconds)09:32
*** ghp <ghp!~ghp@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Ping timeout: 250 seconds)09:34
LetoThe2ndIs there a way to get MACHINE from bitbake -e? I just was surprised that its not included as-is.09:35
RPLetoThe2nd: how are you trying to grep it?09:36
LetoThe2ndRP: the classic - ^/MACHINE09:36
RPLetoThe2nd: it is listed as unexport MACHINE I suspect09:37
LetoThe2ndRP: no, can't confirm. bitbake-getvar also is kinda unhelpful.09:37
RPLetoThe2nd: well, I suspect meta/conf/bitbake.conf:MACHINE[unexport] = "1" is the issue09:38
LetoThe2ndRP: is there a deeper reason for this?09:39
RPLetoThe2nd: there was some major piece of software which broke if you had MACHINE set in it's build environment09:39
RPnowadays we'd just put this in the specific recipe but at the time...09:39
LetoThe2ndRP: yeah the comment says binutils. hm.09:40
Saur[m]RP: But shouldn't it still be in `bitbake -e` even if it is unexported?09:40
LetoThe2ndthe value shows up indirectly, in the line above "unset MACHINE"09:41
LetoThe2ndbut it's kinda ugly to get it out of there.09:41
qschulzLetoThe2nd: remove the unexport line and watch the whole world burn :)09:42
LetoThe2ndqschulz: if anything, then i'll set the universe on fire! https://youtu.be/gXzMD065HEk09:43
RPLetoThe2nd: I did that in 2006: https://git.yoctoproject.org/poky/commit/meta/classes/base.bbclass?id=e4bb4ba86be48108552e8aa8895e1dac25a6770a :/09:45
LetoThe2ndRP: thanks!09:45
Saur[m]But still, unexport != unset09:46
RPSaur[m]: in the context of something readable to bash shell it is09:48
RPLetoThe2nd: https://git.yoctoproject.org/poky/commit/meta/classes/base.bbclass?id=1a59c52aec5f98c73541e9475d69cfe705bd978a was the move from inline python to specific syntax and it moved from base.bbclass to bitbake.conf later09:48
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto09:48
RPLetoThe2nd: I'd be in favour of moving this to the binutils recipes now FWIW09:48
RPSaur[m]: it specifically does unset as the user may have done MACHINE=XXX bitbake  Y09:49
LetoThe2ndRP: technically agreed, but might cause fallout (gut feeling)09:49
RPLetoThe2nd: welcome to the world of making improvements/cleanups :)09:49
RPit may not even be an issue for binutils now09:50
Saur[m]Hmm, ok. I guess it is the same code that generates the run.do_... files that generates the output for `bitbake -e`?09:50
LetoThe2ndRP: yeah, sure. but I wouldn't bet on it at this stage of the release.09:50
Saur[m]RP: Did you see my problem with `ROOTFS_POSTPROCESS_COMMAND:remove` above?09:51
RPSaur[m]: exactly the same code, yes. bitbake -e was meant for use by a shell, not human grepping09:51
RPSaur[m]: I did, I'm trying to get to an environment where I can try it09:52
Saur[m]Figures. Then it is much more understabdable why it does unset.09:52
Saur[m]Ok, good. But I cannot figure out why `ROOTFS_POSTPROCESS_COMMAND[func] == 1`. That is just weird.09:52
RPSaur[m]: fix pushed10:00
Saur[m]Found it. It was in `image.bbclass`. Interesting, I thought [func] was only for  python/shell functions declared in bitbake files, but I guess it is used for variables that take shell like values as well...10:01
RPSaur[m]: I think we did that so we had better dependency handling within those cars10:04
RPvars10:04
Saur[m]Ok.10:04
Saur[m]Well, at least it found that error. ;)10:05
RPclearly a corner case in the tests :(10:05
Saur[m]RP: On to something completely different:10:07
Saur[m]I know we have somewhat different opinions on the UI, but I have given it a lot of thought and I had an idea yesterday that I want to run by you. So please, bear with me.10:08
Saur[m]How about we move the setscene line to after the main progress line, then add a progress bar and finally make the line only show when there are setscene tasks running?10:08
Saur[m]That way we keep the main status line at the top as it has always been, and the setscene line behaves much like the other subtasks below, i.e., it only shows when there is active work going on at which times it shows the progress.10:08
Saur[m]I have implemented it and I think it works very well.10:08
*** starblue <starblue!~juergen@dslb-088-078-108-004.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds)10:13
RPSaur[m]: the trouble is the ordering. setscene in a user's mind is before the tasks and I'm not keen on a UI which reverses that. I'm also not keen on a UI which shows and hides information depending on where things are at. If hash equiv shows matches, it would mean the bar appearing and disappearing which I think would confuse more than it help10:14
*** starblue <starblue!~juergen@dslb-088-078-108-004.088.078.pools.vodafone-ip.de> has joined #yocto10:15
Saur[m]RP: But that is exactly how the other tasks below behaves. They come and go as they are being worked.10:15
RPLetoThe2nd: looks like ld uses MACHINE in linker scripts. I'm not sure if that is or isn't safe from the environment now :/10:15
RPSaur[m]: but setscene progress isn't just an individual task10:16
Saur[m]The setscene tasks are just a subset of the total work done, ie covered by the main progress line.10:16
RPSaur[m]: which is an argument for not having one for setscene tasks in my view10:17
RPSaur[m]: I'm not adding a setscene progress bar, much as you may want one10:18
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto10:18
RPSaur[m]: I was wondering about a patch to remove more of the progress bars as they really annoyed me yesterday, hiding information about how long the task had been running in favour of some progress information I wasn't interested in ;-)10:21
RPSaur[m]: I didn't write it but it just illustrates the different expectations people have from the UI10:22
Saur[m]I can relate to the absence of how long time the task has taken. However, I would prefer to add that time, rather than remove the progress bar.10:23
Saur[m]They both serve different purposes.10:24
RPright, the progress bars are also making me feel ill. Not often I do a fetch with no local sources :/10:24
RPThey were broken as the linux-yocto one restarted from 0% about three different times. I do know why but it isn't a good user experience10:25
Saur[m]RP: Hmm, if the problem, in your eyes, are the progress bars themselves, maybe the solution would be to add a `--progress-bar` option to bitbake, and those who wants the bars (like me) can have them, and those who are annoyed by them (like you) can just forget about them?10:28
RPSaur[m]: I still think the setscene progress bar is just going to mislead and confuse people though as people don't understand what it represents. We need the information in the UI somewhere but we need to focus the user on the correct "overall progress" indicator10:29
RPYes, I personally despise the progress bars but even then I don't believe we should mislead users on the UI and the setscene one will do that.10:30
Saur[m]Which is why I thought my latest idea was in line with that. I.e., the main progress is there all the time, and while the setscene tasks run (and the main progress typically don't update) the setscene progress bar shows what is happening.10:31
RPSaur[m]: part of the trouble is that it can go backwards as new potential build paths are discovered by hashequiv10:31
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed)10:32
Saur[m]Well, if it isn't shown when there are no setscene tasks running, it isn't really going backwards, it is just a "new" bar showing up.10:32
Saur[m]Anyway, I have to run to get lunch now.10:32
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 240 seconds)10:41
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto10:43
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has joined #yocto10:46
RPLetoThe2nd: a quick test locally seems to suggest MACHINE being set doesn't cause issues10:56
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 248 seconds)10:56
RPLetoThe2nd: hang on, unexports are totally pointless now since we tightly control the execution environment and don't take random variables from the parent shell anyway?11:09
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto11:11
*** rhadye <rhadye!sid217449@id-217449.tinside.irccloud.com> has joined #yocto11:25
rburtonwasn't unexport to stop exporting things that were exported initially?11:33
RPrburton: right, but with the "modern" design, even if in the original env, they wouldn't be in the task env11:51
RPThe big question now, what else needs to be done before we build rc111:53
*** ilunev <ilunev!~koolkhel@80.72.17.178> has joined #yocto12:02
rburtoni mean if bitbake.conf does export FOO, but that breaks a specific recipe12:08
rburtonisn't that what unexport is for?12:08
RPrburton: yes, it does help that. I'm not aware of anything exporting TARGET_ARCH, DISTRO or MACHINE though?12:08
rburtoni was thinking in the abstract sense and not really paying attention to the thread, sorry12:09
RPrburton: this is bitbake.conf doing an unexport which seems unneeded now12:10
rburtonyeah that does seem pointless12:10
RPrburton: made sense when it was added 15 years ago :)12:11
Saur[m]RP:  Since we seem to be in agreement that we always want the elapsed time of a build task, I sent a patch for that.12:12
Saur[m]Bah, to the wrong list of course...12:12
RPSaur[m]: doing this at the point we're trying to build rc1 isn't probably a great idea12:13
Saur[m]RP: I'll leave that for you to decide. It can just as well be applied later.12:14
Saur[m]RP: Btw, I assume there was a reason you left the unexport of SHELL in bitbake.conf?12:19
RPSaur[m]: does that code break the length of progress bars for task numbers greater than a single digit? :/12:19
RPSaur[m]: yes, SHELL is a much more recent addition and I think there are subtleties around that12:20
Saur[m]RP: Shouldn't be any difference compared to before.12:20
Saur[m]OK.12:20
Saur[m]The code that updates the progress bar is the same as before.12:21
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto12:21
RPhttps://git.yoctoproject.org/poky/commit/meta/conf/bitbake.conf?id=83ac732923f8618f410c033e6f82243fb04f629512:21
RPSaur[m]: I'm not saying your change breaks it, I'm just wondering if it is broken12:21
RP(where 2015 is 'much more recent' than 2006)12:22
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Client Quit)12:22
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto12:22
Saur[m]I have never noticed any such problem with two digit tasks, but I can run some tests and verify it.12:22
*** guysoft42 <guysoft42!~guysoft@2a0d:6fc1:2:1f00:4bb9:fd30:a0a2:c605> has joined #yocto12:30
*** BignauxRonan[m] <BignauxRonan[m]!~rbignauxm@2001:470:69fc:105::e3e4> has joined #yocto12:37
Saur[m]RP: No need to worry. The progress bars work as intended regardless of the number of digits in the task number.12:38
amahnui[m]> amahnui: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve12:38
BignauxRonan[m]Hi, i've some issue configuring my machine, here i'm https://github.com/bignaux/meta-playstation2/blob/main/conf/machine/tune-r5900.inc but still have qemu-mipsel: unable to find CPU model 'R5900'  on some task.12:39
RPSaur[m]: I'm not sure how though :/12:40
amahnui[m]> amahnui: anything that isn't clear first read should be modified, so feel free to give any feedback on things we could improve12:41
amahnui[m]https://docs.yoctoproject.org/dev-manual/common-tasks.html#:~:text=Be%20sure%20to%20include%20a%20%E2%80%9CSigned%2Doff%2Dby%3A%E2%80%9D%20line%20in%20the%20same%20style%20as%20required%20by%20the%20Linux%20kernel.12:41
amahnui[m]I think we could add the git command that will accomplish this task of signing it off.12:41
rburtonBignauxRonan[m]: khem most likely knows about qemu/mips but he's not awake yet12:41
BignauxRonan[m]perhaps i could disable sanity check12:42
rburtonBignauxRonan[m]: showing the actual error would be helpful12:42
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... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6c93c3a0e0f4afdf6becd4e829584d6b40eb9c53)12:42
Saur[m]RP: The pbar.setmessage() call in updateFooter() handles it. The length of the message can change as much as you like, it will still show the line with the progress bar add correctly.12:42
BignauxRonan[m]https://pastebin.com/QEw8aYNU12:43
qschulzamahnui[m]: agreed. Since you've your whole configuration correctly set up now, one more patch you can send :)12:43
Saur[m]I tested by adding randint(0, 1000000) to tasknum for each update and it showed just fine.12:44
qschulzamahnui[m]: BTW, for small changes, there's no need to ask for permission, you can send a patch and if someone disagrees the discussion can happen by mail :)12:44
RPSaur[m]: ah, right. I knew there had to be something12:44
amahnui[m]> amahnui: agreed. Since you've your whole configuration correctly set up now, one more patch you can send :)12:45
amahnui[m]I will do that right away12:45
amahnui[m]> amahnui: BTW, for small changes, there's no need to ask for permission, you can send a patch and if someone disagrees the discussion can happen by mail :)12:45
amahnui[m]Alright I understand12:45
qschulz(I mean, you never need to ask for permission, it's just that for big changes, you might want to discuss it first to not spend too much time on something that is not desired, but nothing prevents you from doing it and sending a patch anyway :) )12:47
RPBignauxRonan[m]: I'm guessing that is from qemu as you have gobject-introspection turned on. You could turn that off if you don't need/use it12:47
RPBignauxRonan[m]: the other option would be to figure out the correct qemu params12:48
BignauxRonan[m]RP: i was trying second option but don't find right options for now.12:48
RPBignauxRonan[m]: something like DISTRO_FEATURES:remove = "gobject-introspection-data"12:49
RPBignauxRonan[m]: sorry, I misread that. I don't know what the qemu options are for that arch or if it is supported12:50
BignauxRonan[m]that's not a supported CPU option, but it has support, could be work12:50
*** guysoft[m] <guysoft[m]!~guysoftma@2001:470:69fc:105::1:daa6> has joined #yocto12:54
amahnui[m]> (I mean, you never need to ask for permission, it's just that for big changes, you might want to discuss it first to not spend too much time on something that is not desired, but nothing prevents you from doing it and sending a patch anyway :) )12:56
amahnui[m]Thanks a lot for the clarification 🙏12:56
amahnui[m]I also wish to say my freebsd OSis functioning well now12:58
RPBignauxRonan[m]: I'm not seeing r5900 cpu support in qemu so the only option may be to find something close :/13:01
BignauxRonan[m]there are some support since the author of linux 5.x port would like to compile natively gentoo ...13:02
BignauxRonan[m]i try some QB_CPU = "-cpu 34Kf" to look13:02
BignauxRonan[m]it doesn't take the variable.13:02
*** guysoft42 <guysoft42!~guysoft@2a0d:6fc1:2:1f00:4bb9:fd30:a0a2:c605> has quit IRC (Remote host closed the connection)13:03
amahnui[m]> amahnui: that being said, you can send a patch to have double quotes around variables in the oe-init-buildenv script, that's for sure13:03
amahnui[m]Hello qschulz rburton Please I wish to ask if you could help me pointers to work on this13:03
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto13:04
qschulzamahnui[m]: git clone poky in a directory with a space and modify oe-init-build-env until it works13:05
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13:05
amahnui[m]Okay thanks I'm on it13:06
qschulzamahnui[m]: the issue is that in shell, most of the time, you should use a variable directly but use it with quotes13:06
qschulzc.f. https://github.com/koalaman/shellcheck/wiki/SC208613:07
qschulz(you can also fix other shellcheck warnings if there are others, but one logical change per commit please)13:07
amahnui[m]qschulz:  Alright I will start working on it right away13:09
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 246 seconds)13:09
*** argonautx <argonautx!~argonautx@i5E8672F6.versanet.de> has joined #yocto13:22
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)13:41
*** jclsn10074 is now known as jclsn13:51
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:51
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto13:56
*** simonew <simonew!~simonew@2a01:c23:bda6:3200:897d:86ea:ca1f:11a7> has joined #yocto13:57
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)14:40
kergothRP: iirc the SHELL thing is most obvious if you use a non-posix compliant shell. Try a bitbake build with “export SHELL=fish” or something to make things blow up14:47
*** amitk <amitk!~amit@103.208.69.126> has quit IRC (Ping timeout: 260 seconds)14:58
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has joined #yocto14:59
RPkergoth: I noticed that we do have SHELL mentioned for special handling in bb.utils, I wonder if that shouldn't be there...15:01
RPkergoth: I also wondered if we did the environment cleaning when you added SHELL back in 2015...15:01
kergothIt’s a good question15:06
*** ilunev <ilunev!~koolkhel@80.72.17.178> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)15:13
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto15:26
*** argonautx <argonautx!~argonautx@i5E8672F6.versanet.de> has quit IRC (Quit: Leaving)15:30
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed)15:53
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)15:56
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 245 seconds)16:01
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Remote host closed the connection)16:06
*** mckoan is now known as mckoan|away16:13
*** frieder <frieder!~frieder@i4DF677E2.static.tripleplugandplay.com> has quit IRC (Remote host closed the connection)16:18
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)16:18
*** amitk <amitk!~amit@103.208.69.126> has joined #yocto16:29
*** jclsn <jclsn!~jclsn@149.233.159.3.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds)16:39
vvnhi there -- if layers are split correctly, you end up with BSP layers (where machine configurations reside), Distro layers (where distro configurations reside), and Application layers (where software packages reside). What about images though, do you guys consider images part of an application layer, or would you consider a fourth "integration" layer type containing image recipes?16:50
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has joined #yocto16:50
rburtonimages can be considered distro17:06
rburtondistro is the integration point17:07
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 272 seconds)17:08
vvnrburton: let's say that for your company product you use the "beaglebone" machine from meta-ti and meta-arago for the distribution. I guess you add a meta-<company> layer with your software packages and images, maybe stronger policies via multiconfig or a custom distro requiring a base one. Would you consider such proprietary layer a "distro" layer?17:16
rburtonyes17:16
rburtonits your distro layer17:16
vvndamn you read fast :]17:16
rburtona distro layer is the integration point17:17
rburtondepends on layers for software or bsps, defines how they're configured (distro) and built (images)17:18
vvngot it. If sharing is needed, then a distro layer can be split to extract software packages in an application layer, like meta-qt5 for example.17:19
rburtonyeah, if you end up with a load of recipes for open source software then either create a new layer, or contribute them to an existing one17:20
vvnrburton: isn't it weird if a distro layer depends on bsp layers?17:31
vvnI guess it kinda makes sense for a proprietary distro layer, to describe all the supported BSPs.17:33
vvnThe term distro is confusing when you think about it as a generic Linux distro, while in fact it's really about build policies and integration point.17:38
*** jclsn <jclsn!~jclsn@84.46.1.174.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto17:39
*** GLumen <GLumen!~GLumen@97-113-136-61.tukw.qwest.net> has joined #yocto17:40
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has joined #yocto17:45
*** GLumen <GLumen!~GLumen@97-113-136-61.tukw.qwest.net> has quit IRC (Quit: Konversation terminated!)17:46
*** GLumen <GLumen!~Gregory@97-113-136-61.tukw.qwest.net> has joined #yocto18:16
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-35-74-12-165-208.dsl.bell.ca> has joined #yocto18:30
*** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has joined #yocto18:36
*** amitk <amitk!~amit@103.208.69.126> has quit IRC (Ping timeout: 246 seconds)18:42
amahnui[m]Hello qschulz I added double quotes to the variable ($OEROOT) and ran shellcheck and it never pointed  ```  ^-----^ SC2086: Double quote to prevent globbing and word splitting.``` that it was giving when there were no quotes. But when i run "source oe-init-build-env" it gives me the error ```/home/abongwa/Desktop/projects/test repo/poky/scripts/oe-setup-builddir: 45: .: Can't open /home/abongwa/Desktop/projects/test```19:12
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)19:13
amahnui[m]Instead of the normal ```bash: /home/abongwa/Desktop/projects/test: No such file or directory``` error.19:14
*** agrue <agrue!~agrue@035-133-169-019.res.spectrum.com> has joined #yocto19:15
amahnui[m]I thought of a way of implementing a recursive function which grabs each name and  puts it in double quotes but I'm still facing difficulties implementing it as the directory is dynamic depending on user's preference.19:19
*** agrue <agrue!~agrue@035-133-169-019.res.spectrum.com> has quit IRC (Remote host closed the connection)19:30
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)19:35
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)19:37
*** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has quit IRC (Quit: Client closed)19:38
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has joined #yocto19:49
*** Guest82 <Guest82!~Guest82@tel3187175.lnk.telstra.net> has quit IRC (Quit: Client closed)19:57
*** simonew <simonew!~simonew@2a01:c23:bda6:3200:897d:86ea:ca1f:11a7> has quit IRC (Quit: Client closed)19:57
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)20:21
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto20:25
*** rob_w <rob_w!~rob@2001:a61:60c9:601:1dc7:3566:940e:e217> has quit IRC (Read error: Connection reset by peer)20:30
*** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (Read error: Connection reset by peer)20:38
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)20:40
*** callum <callum!~callum@107-179-233-64.cpe.teksavvy.com> has joined #yocto20:55
*** tomzy_0 <tomzy_0!~tomzy_0@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed)20:59
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Ping timeout: 240 seconds)21:00
*** callum <callum!~callum@107-179-233-64.cpe.teksavvy.com> has quit IRC (Quit: Client closed)21:13
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto21:16
*** florian_kc <florian_kc!~florian@dynamic-093-132-037-091.93.132.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)21:29
cambrian_invaderis it possible to keep Linux build output between build runs?21:32
cambrian_invaderit seems like every time I make a configuration change *everything* gets recompiled21:32
cambrian_invaderwhich takes around 10m, vs perhaps 15s for an incremental build21:33
*** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (Ping timeout: 260 seconds)21:40
RPcambrian_invader: a lot depends on what you change and where/how21:46
cambrian_invaderI did a menuconfig and enabled/disabled a few drivers21:46
cambrian_invaderand then everything was recompiled21:46
cambrian_invaderwhereas if I had been using a bare source, I would have expected maybe 30 files recompiled21:47
RPcambrian_invader: I'd guess that is as the system is trying to track the config change and package the output21:47
cambrian_invaderright, but it seems like someone is running "make clean"21:47
cambrian_invaderor something equivalent21:48
RPcambrian_invader: a new config is probably making it decide to build from scratch just to be sure. There are ways to just rebuild your changes but not when using menuconfig so easily21:49
cambrian_invaderugh21:49
cambrian_invaderbitbake is really terrible if you are actually developing software21:49
RPcambrian_invader: yes and no. It is being careful about capturing your config which under different circumstances, you might worry about21:50
cambrian_invadersure, but Linux has a great build system already21:50
RPI do wish we had people to work on these workflows :/21:50
cambrian_invaderand it can determine what needs to be recompiled and what doesn't21:50
RPcambrian_invader: there is more to a linux image than just the kernel21:51
cambrian_invaderright, so re-run do_compile and the parts after that21:52
cambrian_invaderbut do_compile should turn into "make" and no more21:52
RPcambrian_invader: I suspect the problem is configure, not compile as compile effectively does just that21:53
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)21:54
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto21:56
*** Guest82 <Guest82!~Guest82@tel3187236.lnk.telstra.net> has joined #yocto21:57
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)22:05
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto22:05
*** leonanavi <leonanavi!~Leon@46.55.231.62> has joined #yocto22:05
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection)22:06
*** Guest82 <Guest82!~Guest82@tel3187236.lnk.telstra.net> has quit IRC (Quit: Client closed)22:52
GLumencambrian_invader: Have you tried running `bitbake-whatchanged` after menuconfig but before building? It might give you some insight in to why bitbake decided to re-run more tasks that you expected.22:58
*** Guest82 <Guest82!~Guest82@tel3187236.lnk.telstra.net> has joined #yocto23:01
*** Guest82 <Guest82!~Guest82@tel3187236.lnk.telstra.net> has quit IRC (Client Quit)23:01
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 246 seconds)23:29
*** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has joined #yocto23:35
*** GLumen <GLumen!~Gregory@97-113-136-61.tukw.qwest.net> has quit IRC (Ping timeout: 260 seconds)23:37
*** GLumen <GLumen!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto23:39
*** leonanavi <leonanavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)23:52
*** GLumen <GLumen!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 248 seconds)23:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!