dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
cengiz_io has joined #yocto
goliath has quit [Quit: SIGSEGV]
Ad0 has quit [Ping timeout: 250 seconds]
Ad0 has joined #yocto
ssajal has joined #yocto
camus has joined #yocto
tp43_ has quit [Ping timeout: 258 seconds]
jwillikers has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
amitk has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
vd has quit [Quit: Client closed]
paulg has quit [Ping timeout: 240 seconds]
erbo_ has joined #yocto
beneth has quit [*.net *.split]
Dracos-Carazza has quit [*.net *.split]
matthewcroughan has quit [*.net *.split]
erbo has quit [*.net *.split]
frosteyes1 has quit [*.net *.split]
Dracos-Carazza_ has joined #yocto
frosteyes1 has joined #yocto
ad__ has quit [*.net *.split]
bunk_ has quit [*.net *.split]
dv_ has quit [*.net *.split]
mckoan|away has quit [*.net *.split]
Gaffel has quit [*.net *.split]
ad__ has joined #yocto
mckoan|away has joined #yocto
bunk has joined #yocto
dv_ has joined #yocto
wooosaii has quit [Quit: Leaving]
Gaffel has joined #yocto
Dracos-Carazza_ is now known as Dracos-Carazza
beneth has joined #yocto
dlan has quit [Quit: leaving]
dlan has joined #yocto
rob_w has joined #yocto
<wCPO> annoying bug I reported. https://bugzilla.yoctoproject.org/show_bug.cgi?id=14520 . Is there anyway I can run a function in a class with bitbake?
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
frieder has joined #yocto
mihai- is now known as mihai
zpfvo has joined #yocto
zyga has joined #yocto
goliath has joined #yocto
LetoThe2nd has joined #yocto
leon-anavi has joined #yocto
tre has joined #yocto
florian has joined #yocto
<RP> kanavin_: quite the upgrade series, thanks! :)
<LetoThe2nd> yo dudX
<kanavin_> RP: cheers :) my pre-testing on the AB does make it smooth doesn't it :)
<RP> kanavin_: yes, definitely :)
<kanavin_> RP: is there still time for additional upgrades?
<RP> kanavin_: the main issue left is rust. That series isn't ready, it doesn't even build locally for me. The time left really depends what I decide to do with that
<kanavin_> RP: I mean, if I have more fully tested version updates, when is the last good day to send them in?
<LetoThe2nd> RP: i want the above quote out of context
<RP> kanavin_: technically, today is the feature freeze. I suspect I'm going to give things a few days though. There is also the pseudo/glibc 2.34 issue I need to figure out
<kanavin_> I couldn't resist making a dig at nvidia by the way, I really don't like how they treat nouveau (intentionally cripple) and their own blob (refusing to play along with what everyone else is using)
<RP> kanavin_: it isn't good :(
<kanavin_> halstead, is it possible/easy to provision 'modprobe vgem' to all the AB workers? There's a test around qemu and graphics that would be enabled by that.
<kanavin_> RP: ^^^
<kanavin_> halstead, if you rememember we talked a while ago about updating graphical HW on the workers, with the above it's no longer an issue
d0ku has joined #yocto
<RP> kanavin_: given the range of distros I suspect that isn't straightforward :/
o_ndra has joined #yocto
<kanavin_> RP: right, systemd has a unified way of doing it though, via /etc/modules-load.d/
xmn has joined #yocto
grma has joined #yocto
<wCPO> tlwoerner: wouldn't be it be better to use ext4 without the journal than ext2 for your zram patch?
linkliu60 has quit [Quit: leaving]
linkliu59 has joined #yocto
linkliu59 has quit [Client Quit]
linkliu59 has joined #yocto
linkliu59 has quit [Client Quit]
linkliu59 has joined #yocto
kayterina has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
jmiehe has joined #yocto
tnovotny has joined #yocto
xmn has quit [Quit: xmn]
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
goliath has quit [Quit: SIGSEGV]
<prabhakarlad> Hi All, any reasons why the utilities are removed from coreutils package http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/coreutils/coreutils_8.9.bb?h=1.1_M1#n64
JaMa has joined #yocto
fleg has joined #yocto
<rburton> prabhakarlad: that's the prerm package manager script, so that's removing the alternatives when it is *removing* the package
<rburton> if you're still trying to figure out where timeout is, have you checked the configure log yet? timeout is only built if a specific signal name could be found.
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
zyga has quit [Remote host closed the connection]
jwillikers has joined #yocto
<prabhakarlad> rburton: I can see timeout is compiled https://paste.debian.net/plain/1208684
<prabhakarlad> but during do_package its been removed, update-alternatives --remove timeout /usr/bin/timeout.coreutils
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
thekappe has joined #yocto
goliath has joined #yocto
zyga has joined #yocto
<wCPO> hmm, it looks like CONFIG_SCSI_VIRTIO=y is silently dropped with linux-yocto 5.10, hmm
<rburton> prabhakarlad: that's just a debug note telling you what it is setting as postinst/prerm scripts
<rburton> prabhakarlad: "oe-pkgdata-util list-pkg-files coreutils" will show you if coreutils contains /usr/bin/timeout.coreutils, which it does here
<rburton> on install, a symlink for /usr/bin/timeout will be created (unless you've done something to disable alternative generation)
<yates_home> in my core-image-minimal build of elfutils, there are duplicate files for crti.o: one in recipe-sysroot/usr/lib/crti.o and one in recipe-sysroot/usr/lib/csky-poky-linux/10.3.0/crti.o
<yates_home> which one is correct?
<yates_home> they are different files - different lengths
<yates_home> (lengths == sizes)
<yates_home> it looks like the environment is setup to point to recipe-sysroot/usr/lib: http://paste.ubuntu.com/p/5DkVtbVysx/
<prabhakarlad> rburton: I see the below when I run "oe-pkgdata-util list-pkg-files coreutils"
<prabhakarlad> oe-pkgdata-util list-pkg-files coreutils
<prabhakarlad> coreutils:
<prabhakarlad> coreutils is in the RPROVIDES of target-sdk-provides-dummy:
rsalveti has joined #yocto
<d0ku> Hi, anyone with extensible SDK experience here? I want to generate an eSDK and then use `sdk-install` to add the required `-native` tools, but it seems that the PATH is not extended automatically (e.g. binaries in <native sysroot>/bin/perl-native are not visible unless PATH is manually modified). Did I miss something or my use-case is not supported?
<cengiz_io> hello. I have changed the value of my MACHINE_OVERRIDES in my layer and how can I verify that that change actually took place in my image?
<tlwoerner> wCPO: is there much of a benefit to ext4 without a journal vs ext2?
<tlwoerner> wCPO: i guess it could be configurable
<wCPO> tlwoerner: ext3 without a journal is basically ext2, but ext4 has some features neither ext2 nor ext3 has https://kernelnewbies.org/Ext4 . I'm unsure if it matters when fs is in memory
<tlwoerner> wCPO: in any case it would be best if i made it configurable, then people could make their own choice :-)
paulg has joined #yocto
<wCPO> tlwoerner: agree. In the end I think either choice is good-enough
<tlwoerner> although that could get messy with having to coordinate with kernel configs
<RP> tlwoerner: extents in ext4 are nice FWIW
<RP> paulg: morning!
rperier has joined #yocto
<RP> paulg: I was looking at ppc serial interrupt handler backtraces and thinking of you :)
<paulg> uh oh. I was just wondering --- What did I break, or am being volunteered to fix....
<paulg> Suppose it wouldn't do me much good to lie and say I've never touched ppc serial code, would it?
<RP> paulg: you could try but I'd take some convincing ;-)
FO has quit [Remote host closed the connection]
<RP> paulg: seriously, if you did have any ideas I'm open to them, the serial ports do seem unstable on that platform :(
FO has joined #yocto
<paulg> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9deaa53ac7 <--- my ppc serial hacking was like a decade ago ; but I'll take a look at the log file.
<paulg> That might be one of the few remaining drivers in the kernel that I wrote that I haven't yet deleted. :-P
<paulg> do we know if it is 100% reproducible, or intermittent?
<RP> paulg: intermittent :(
<RP> paulg: I did at least capture the logs this time and write the bug so we can track the thing
<paulg> I'd have to go learn whether qemu-ppc tries to do any early serial kind of thing like in a real machine u-boot handoff
<qschulz> cengiz_io: bitbake -e some-recipe | grep "^MACHINEOVERRIDES"
<paulg> it kinda smells like a race between completing driver init and having data come in.
<cengiz_io> qschulz: thanks. that should at least verify that it propagated
<qschulz> what did you put in your MACHINEOVERRIDES and in which file?
<paulg> (i.e. request_irq is too late, or never happens for some odd reason...)
<paulg> RP, in theory a generic vanilla master build for qemu-ppc should get me similar to that? So I can have one local churning in the bkgd?
<RP> paulg: that is a standard qemuppc build, yes. I suspect usage of the serial port will reproduce, we don't use it much...
<paulg> I have NFI what serial driver qemu fakes ; assuming 16550. Will set a build and see what .config says and what .o it creates and go from there.
<RP> paulg: we previously turned off serial console log messages iirc which helped by removing one of the sources of problems
<paulg> Awesome. So "problem solved. Didn't see it - didn't happen." :-)
<cengiz_io> qschulz: it's actually automotive grade linux, which has a template mechanism for including fragments into local.conf
<cengiz_io> qschulz: my goal is to use mainline kernel with meta-freescale, which seems to be toggled with this `MACHINEOVERRIDES .= ":use-mainline-bsp"` (not sure though)
<qschulz> cengiz_io: IIRC, this enables etnaviv instead of vivante too
<qschulz> but you're probbaly on the right track
<cengiz_io> qschulz: yeah. etnaviv is what I want :)
sakoman has joined #yocto
troth has joined #yocto
<rburton> prabhakarlad: yeah i see that if i'd build a sdk. blow away tmp and try again, it works fine. should fix that bug.
rob_w has quit [Quit: Leaving]
<rburton> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14523 filed to make sure nobody forgets
ssajal has quit [Quit: Konversation terminated!]
ssajal has joined #yocto
mihai has quit [Read error: Connection reset by peer]
mihai has joined #yocto
paulg has quit [Ping timeout: 252 seconds]
vd has joined #yocto
zyga has quit [Quit: Leaving]
paulg has joined #yocto
kayterina has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
<prabhakarlad> rburton: deleting tmp (and rebuilding) , oe-pkgdata-util list-pkg-files coreutils does list /usr/bin/timeout.coreutils
jwessel has left #yocto [#yocto]
<rburton> deleting tmp won't cause a rebuild unless you put sstate in it, which is a bad idea
florian has quit [Quit: Ex-Chat]
<prabhakarlad> but built image still has timeout utility missing.
<prabhakarlad> >[4:30:38 PM] <rburton> deleting tmp won't cause a rebuild unless you put sstate in it, which is a bad idea
<prabhakarlad> agreed.
tnovotny has quit [Quit: Leaving]
otavio_ has quit [Read error: Connection reset by peer]
otavio has joined #yocto
<tlwoerner> anyone seen something like this before?
<tlwoerner> Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS:tune-mips32r2el-24kc} qemumips) for DEFAULTTUNE (mips32r2el-24kc) does not contain TUNE_PKGARCH (${MIPSPKGSFX_VARIANT:tune-mips32r2el-24kc}-nf).Toolchain tunings invalid
<tlwoerner> if something is listed in AVAILTUNES it's available to use?
frieder has quit [Remote host closed the connection]
otavio__ has quit [Quit: leaving]
dev1990 has joined #yocto
alimon has joined #yocto
ssajal has quit [Ping timeout: 240 seconds]
tre has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
sethfoster has joined #yocto
<sethfoster> Hey all. Last week I was asking about kind of hacking together a fetcher for google's gclient in a recipe; qschultz super helpfully pointed me at their meta-rust custom fetcher, which was great. One thing I was wondering though - is there a way to deduplicate files between DL_DIR and the source area? Because the source for this is like 25G and therefore will take a while to copy and also take a bunch of
<sethfoster> space
goliath has joined #yocto
<halstead> kanavin_: vgem is loaded on all the workers except centos8*. I need to build the module there.
<kanavin_> halstead, thanks! not sure why centos doesn't have it, if it's available in e.g. fedora
ant__ has joined #yocto
<halstead> True. Fedora workers are ready.
<kanavin_> halstead, any progress on the AUH emails?
o_ndra has quit [Quit: Client closed]
<halstead> kanavin_: I made some progress. I've gathered debugging info and made contact with support. It's not solved yet.
alejandrohs has joined #yocto
<kanavin_> halstead, thanks again :)
fleg has quit [Remote host closed the connection]
tp43_ has joined #yocto
<kanavin_> RP: and here it is in action:
<kanavin_> 2021-08-23 17:23:57,348 - oe-selftest - INFO - runtime_test.TestImage.test_testimage_virgl_headless (subunit.RemotedTestCase)
<kanavin_> 2021-08-23 17:23:57,348 - oe-selftest - INFO - 12: 20/20 342/439 (85.53s) (runtime_test.TestImage.test_testimage_virgl_headless)
<kanavin_> 2021-08-23 17:23:57,348 - oe-selftest - INFO - ... ok
<kanavin_> halstead, ^^^
<kanavin_> \0/
<kanavin_> no need to get rid of those trusty G200s :)
jsbronder has quit [Remote host closed the connection]
jsbronder has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<sethfoster> How bad an idea do you folks think it would be to symlink a source dir to a dl cache
<sethfoster> pretty bad right
<manuel1985> sethfoster: No idea, but I also though about keeping the code for some little applications next to the bitbake recipe in the meta-layer.
<sethfoster> yeah i have too many dang repos
<sethfoster> problem here is the source is like 25 gigs so i'd like to not have to have it twice or copy it around
<manuel1985> One could have files/src dir which is actually a git submodule
<manuel1985> sethfoster: Oh, ok. Well, that's bad.
<sethfoster> yeah it's not my favorite thing in the world
alejandrohs has quit [Ping timeout: 240 seconds]
<bantu> Hello everyone. I am trying to add rxtx to my image. I'm seeing ./gnu_io_CommPortIdentifier.h:3:10: fatal error: jni.h: No such file or directory
amitk has joined #yocto
alejandrohs has joined #yocto
amitk_ has quit [Ping timeout: 252 seconds]
<smurray> JPEW: I'm curious if you're planning to go to the OpenChain/SPDX mini-summit the day after ELC? Trying to figure out if it's worthwhile registering for it
amitk_ has joined #yocto
<JPEW> I did not see it. I'll look into it
amitk has quit [Ping timeout: 250 seconds]
sakoman has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
<jonmason> RP: today's mesa update is causing build breaks for qemuarmv5. I'm looking into it (something about neon and softfp), but wanted to make you aware
amitk has joined #yocto
amitk_ has quit [Ping timeout: 250 seconds]
bantu has quit [Ping timeout: 268 seconds]
bantu has joined #yocto
<kanavin_> jonmason, how come AB didn't catch it?
<jonmason> kanavin_: I don't believe the AB builds qemuarmv5, which is why we do in our CI :)
<kanavin_> jonmason, it builds 32 bit arm but that's not the same?
<kanavin_> qemuarm
<jonmason> no, there is 2 32bit arm machines: qemuarm (ARMv7) and qemuarmv5 (ARMv5)
<kanavin_> if upstream doesn't test it, things are likely to break
<kanavin_> mesa upstream
sakoman has quit [Ping timeout: 250 seconds]
sakoman has joined #yocto
florian has joined #yocto
<jonmason> there was a request to keep ARMv5 around when I updated qemuarm to be ARMv7, but it really only is for ancient machines (like the first gen RasPi in age)
<jonmason> I have it in our nightly CI, and we run (a subset of )testimage. So we'll find it when it breaks
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<sakoman> A company has contacted me looking for some full time help in "fixing" a sub-optimal rocko based image build -- boot time, package content, and build infrastructure. Ping me if you are interested (or know someone who might be)
amitk has quit [Ping timeout: 240 seconds]
<manuel1985> Why do some recipes have functions with only a colon as content? do_install () {\n :\n }
<manuel1985> \n are newlines obviously
<vmeson> manuel1985: where are you seeing that do_install rule ? What does the git blame/log say about it?
<manuel1985> I had devtool autocreate a recipe for git://github.com/brettviren/pygst-tutorial-org.git
<manuel1985> It put a comment in the recipe saying that it couldn't find a Makefile and I'd need to fill in the function bodies myself
sakoman has quit [Read error: Connection reset by peer]
<manuel1985> for do_configure, do_compile and do_install
<vmeson> manuel1985: devtool can be helpful but it does not perform magic. As the warning stated, you'll have to look at the docs and other python recipes to figure out what to do.
sakoman has joined #yocto
<manuel1985> vmeson: Yeah okay, but that still doesn't tell me the purpose of the colons. I mean, why a colon, not a $ or * or ^.
<manuel1985> I don't speak Python I should add.
<vmeson> manuel1985: What's the exact comment in the recipe ?
<smurray> a single colon like that is basically a placeholder in Bash, look at the "SHELL BUILTIN COMMANDS" section in the bash man page, it's the first entry
<vmeson> smurray: that's what I expected, it would seem like a better choice to have that stage fail but I guess it depends on what the goal is with devtool.
<smurray> vmeson: it expects you to put something in there per the mentioned comment
<manuel1985> vmeson: The exact comment in the recipe is "NOTE: no Makefile found, unable to determine what needs to be done"
<manuel1985> smurray: Thanks, that explains things. Would never have thought that : is shell language. But makes sense. The commeands in put in do_install are shell commands after all.
Guest90 has joined #yocto
Guest90 has quit [Client Quit]
<vmeson> manuel1985: smurray has explained the syntax and intent. If you're interested here's the commit: https://git.openembedded.org/openembedded-core/commit/?id=fa07ada1cd0750f9aa6bcc31f8236205edf6b4ed
<vmeson> recipetool and devtool are useful but they could probably use some polishing based on user feedback.
<smurray> looking at https://github.com/brettviren/pygst-tutorial-org it looks like documentation source, it's not something "buildable" that I can see
<smurray> if there's a script in there that's desired, disabling do_compile and cp'ing the script in do_install is likely what'd you want to do
Guest56 has joined #yocto
Guest56 has quit [Client Quit]
<paulg> RP, no wonder that turd catches fire. Check out all the flapping and flailing that takes place at 16s when the driver takes over -- this is with debug enabled and IRQ request/free printk added. https://paste.debian.net/1208754/
<paulg> looks like you and zeddii were poking at this crapfest back in May. https://lists.openembedded.org/g/openembedded-core/message/151329
<paulg> ideally qemu ppc should target a decade old 83xx or 85xx processor with 16550 and u-boot, and not some pre-y2k 7400 with zilog ttyS.... :-/
<manuel1985> When I'm building my image, I see do_image_ext3 and do_image_tar tasks executed. I don't need the .tar, because I'm loopback-mounting the .ext3 and netbooting my device. Can I disable creation of the .tar?
<paulg> obviously if we gut the stupidity of all the up/down up/down up/down nonsense and grab/keep the IRQ at probe, I'm sure zilog ttyS<n> will magically stop blowing up.
sethfoster has quit [Quit: leaving]
camus1 has joined #yocto
leon-anavi has quit [Quit: Leaving]
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
d0ku has quit [Ping timeout: 248 seconds]
<RP> paulg: that does look rather crazy :/
<RP> paulg: back in may was when we disabled the serial console logs which seemed to "help"
<RP> paulg: if you wanted to suggest a different config for qemuppc we could try it...
<paulg> hacking together a fix that moves irq request up some lines ; should fix the steaming POS.
<paulg> not going to get involved in filtering out all its flapping and flailing if I don't ahve to.
<RP> paulg: fair enough, thanks :)
<RP> it'd be nice to have one less set of weird failures
<paulg> you all get to test it after it passes my "doesn't splat" high standards.
<RP> vmeson: speaking of weird failures, I'll just say publicly that I'm doubtful about rust at this point
<paulg> I'll send it onwards to mainline in case there are other necro serial driver afficionados out there.
<yates_home> RP: pray tell why.
<RP> vmeson: I have no idea how to try and fix the uninative breakage, other than perhaps trying to merge the rust-llvm and rust recipes, or add an intermediate task the doesn't use sstate
<RP> yates_home: because it doesn't build/work in too many situations
<RP> vmeson: if I don't merge it now, I will not be merging it until some of these issues get fixed though, it won't just "merge after we branch"
<RP> khem: do you have any interest/time to look at rust?
<vmeson> RP: That's fine with me, better to fix it over the next month in meta-rust or my contrib branch than mess up the release.
<RP> vmeson: it is a shame as the AB is just showing failures in the reproducibility targets but those failures look hard. If we could resolve that one...
<RP> vmeson: did we have rsvg and the python crypto module building with this?
<RP> smurray, paulbarker: I did merge the prserv changes finally, thanks!
<vmeson> RP: I _had_ librsvg building in Feb but I haven't gotten back to it. I"m not sure if tgamblin has gotten python-cryptography updated.
<smurray> RP: saw that, thanks!
<RP> vmeson: fair enough, I just wondered if it actually worked for our intended use
<paulg> ok. who is the wiseguy who broke kernel devshell ?
<RP> smurray: I'm jumpy every time I see a build taking a long time
<paulg> kernel-source#git show
<paulg> kernel-source#
<paulg> fatal: bad object HEAD
<moto-timo> I know tgamblin was looking at py-crypto last week
<moto-timo> RP: sounds like you would like to see us build it with the rust branch?
<RP> moto-timo: would show the thing actually does something useful ;-)
<moto-timo> RP: fair enough!
<RP> Such a patch could be queued in this changeset
<vmeson> py-crypto lives in meta-oe right now, of course we could move it...
<RP> vmeson: ah, we need the librsvg example then :)
<vmeson> RP: I can work on that this evening / tomorrow.
<RP> vmeson: I guess it comes down to the uninative issue - is there any chance we can resolve this in a few days, e.g. this week?
<vmeson> RP - I have no idea what the uninative issue is off-hand so I cant' say. Let me look at your commit logs...
dev1990 has quit [Quit: Konversation terminated!]
<RP> vmeson: it is this: it is easy to reproduce, you just bitbake rust-native on a
<RP> vmeson: which is bitbake rust-native on an older system with no sstate present and uninative enabled
<RP> error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/pokybuild/yocto-worker/reproducible-debian/build/build-st/reproducibleA/tmp/work/x86_64-linux/rust-native/1.54.0-r0/rustc-1.54.0-src/build/bootstrap/debug/deps/libproc_macro_error_attr-9c7a09885c50c72e.so)
<manuel1985> vmeson: Thanks for the IMAGE_FSTYPES link
<vmeson> manuel1985: there's lots of documentation, you just need to find the right keyword to search for it.
* paulg does "echo ref:v5.13/standard/qemuppc > .git/HEAD" and carries on with writing a commit log
<paulg> someone else can fix devshell being headless.
<vmeson> paulg: JoeS changed something about devshell recently, could you ask him to check on the kernel devshell ?
<paulg> vmeson, this is on vanilla yocto/poky ; so I'm guessing JoeS didn't change anything there.
<vmeson> RP, I'll give it a go on 18.04/ glibc-2.27
<vmeson> paulg: 49ae4a23d8 terminal.bbclass: force bash for devshell -- joeS, Aug 12.
<vmeson> 2021 even!
alejandrohs has quit [Ping timeout: 250 seconds]
<RP> vmeson: looking at my "fix", I made a small mistake with override syntax
<RP> if only I paid attention to these kinds of changes
<vmeson> RP - oh, how small...
* vmeson googles for uninative instructions and adds 2 lines to his local.conf : https://www.yoctoproject.org/pipermail/yocto/2016-November/033134.html
<vmeson> require conf/distro/include/yocto-uninative.inc
<RP> vmeson: should use poky :)
<vmeson> INHERIT += "uninative"
<vmeson> RP I am . I didn't see it in the default local.conf
<RP> vmeson: I think poky enables it by default
<RP> vmeson: FWIW my 20.04 box showed issues too. Just not sure how that patch worked in my testing :(
<vmeson> kk, well belt and suspenders so I'm going to start a'bitbake rust-native" on this 18.04 box and go have dinner.
* RP notes that doesn't translate so well across the pond :)
<RP> (braces here)
<vmeson> heh
<RP> vmeson: I'll try another build overnight on the AB
jwillikers has quit [Remote host closed the connection]
d0ku has joined #yocto
florian has quit [Ping timeout: 250 seconds]
d0ku has quit [Ping timeout: 240 seconds]
<vmeson> RP: as you suggested: WARNING: Duplicate inclusion for /ala-lpggp31/rmacleod/src/distro/yocto/poky.git/meta/conf/distro/include/yocto-uninative.inc in /ala-lpggp31/rmacleod/src/distro/yocto/poky.git/meta-poky/conf/distro/poky.conf
<vmeson> but "bitbake rust-native" builds fine!
<vmeson> That's on master-next on an ubu-18.04.3 distro.
sakoman has quit [Read error: Connection reset by peer]
vd has quit [Quit: Client closed]
<moto-timo> vmeson: for py-crypto, which requires rust compiler, do you think I should ‘inherit rust’?
<moto-timo> Or DEPENDS ‘rust-native’
sgw has joined #yocto
sakoman has joined #yocto
<vmeson> moto-timo: rust-hello-world just has 'inherit cargo', as does suricata in meta-security.
<moto-timo> vmeson: I’ll have to look at setup.py and see what it is calling
shoragan has quit [Ping timeout: 255 seconds]
shoragan has joined #yocto
goliath has quit [Quit: SIGSEGV]
dev1990 has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
* vmeson gets a debian-8 container setup enough to start the build of rust-native on poky/master-next and calls it a day.
<paulg> hateful thing will be forever off in any config I use.
<paulg> mucking with /proc/version is just evil. I want to know I've booted what I just built.
<paulg> esp. when I'm expecting debug statements and don't get them. Why is on the default anyway?
d0ku has joined #yocto
jmiehe has quit [Quit: jmiehe]