<LetoThe2nd>
kranzo: its very well possible that largefile is deprecated, respectively a leftover. are there any references/checks to it?
<kranzo>
found a patch from 2011, seems correlated with busybox's largefilesupport (not sure what this is) but i can google for it now, i was just unsure why its not covered in the manual :)
mseeber has joined #yocto
dtometzki has quit [Ping timeout: 248 seconds]
<rburton>
largefile is pretty historical
<kranzo>
i just dropped it for now
<rburton>
RP: was the only failure caused by my patch in the selftests?
<kranzo>
is there a proper way of recovering from an pseudoerror without cleansstate?
<rburton>
rm tmp is a lot easer :)
<rburton>
depends what the pseudo error is of course
<kranzo>
its a path mismatch, cleansstate for the recipe and rebuilding is resolving it so im not sure how to remove tmp only for the specific recipe
<rburton>
just wipe all of tmp, often faster than iterating a large sstate
camus has quit [Ping timeout: 245 seconds]
mranostaj has quit [Ping timeout: 256 seconds]
camus has joined #yocto
mranostaj has joined #yocto
otavio has quit [Remote host closed the connection]
paulg has joined #yocto
otavio has joined #yocto
<tlwoerner>
kranzo: there was a time where if you wanted to work with a single file that was more than 2GB in size, your kernel, c library, and user-space had to have "largefile" support enabled
* Tartarus
passes both pages along to his customer for now
<qschulz>
Tartarus: could you please give us the exact text and the page where it can be found because I couldn't find it using the string you sent
<Tartarus>
Ah sorry, I was summarizing
<Tartarus>
The last line of that section is "Using the immediate expansion assignment operator := is important because of the reference to THISDIR. The trailing colon character is important as it ensures that items in the list remain colon-separated."
<Tartarus>
Now, looking at the layer, it's because the pi layer is just overriding a single file there with it's own
<Tartarus>
Which would be good to exlpain, in the docs, that is what it's doing.
prabhakarlad has quit [Quit: Client closed]
<Tartarus>
A sentence about "Now the `machconfig` file found in meta-raspberrypi will be used instead of the one in the core layer." would finish the explanation.
sakoman has joined #yocto
marc1 has quit [Quit: WeeChat 3.2]
<vmeson>
halstead: anyone, is it just me or is the layers.openembedded.org site having clock problems: Firefox detected an issue and did not continue to layers.openembedded.org. The website is either misconfigured or your computer clock is set to the wrong time.
<vmeson>
ah: -> The certificate for layers.openembedded.org expired on 2021-08-12.
d0ku has joined #yocto
prabhakarlad has joined #yocto
<paulg>
vmeson, do you have TZ set to New Zealand? It doesn't complain at me.
<paulg>
It is supposed to be set to where you are, not where you want to be. :-P
<Tartarus>
paulg: I see someone else internally is noting the cert problem, and they're in EU
kranzo has quit [Ping timeout: 246 seconds]
<Tartarus>
lofc it's also mad here, in the east coast us :)
<qschulz>
Tartarus: please send a patch, this addition makes sense to me :)
<Tartarus>
qschulz: Sure, point me at the doc repo :)
<Tartarus>
Or is that still git://git.yoctoproject.org/yocto-docs ?
<qschulz>
yup
<Tartarus>
Only been 4 years since my last pull, ok, moment
<qschulz>
hehehe :)
<qschulz>
much changed since then
Tokamak has joined #yocto
<qschulz>
we're using restructedText now :)
<Tartarus>
Before or after the note section
<Tartarus>
?
<vmeson>
paulg: no and it works now after failure at least twice earlier.
<vmeson>
This winter, it would be nice to set my TZ to NZ!
<qschulz>
Tartarus: I'd personally have it after, let's see what other will say on the ML :)
Guest858 has joined #yocto
goliath has quit [Quit: SIGSEGV]
<d0ku>
I've started using extensible SDK (on gatesgarth) and wonder if the host packages I need to install can be installed "in runtime" or do they have to be prebuilt into SDK installer?
<d0ku>
Also in this case should I still use `nativesdk-` or `-native` is also fine?
frieder has quit [Ping timeout: 245 seconds]
frieder has joined #yocto
<Tartarus>
... well, at least one can pip install pipenv :)
Chep` has joined #yocto
Chep has quit [Ping timeout: 252 seconds]
Chep` is now known as Chep
<Tartarus>
qschulz: OK, It'll be a little bit before I post since I'm gonna go fix what I complained about being missing too, which means a bit more of a re-org to this section.
<qschulz>
Tartarus: :) Don't hesitate to make multiple commits if the changes are logically different :)
<qschulz>
vmeson: IIRC, we used to specify when it's community maintained
<qschulz>
so probably no-one is actively maintaining any on the official git repo
<vmeson>
qschulz: yeah, I remember that. I can update my note if you like.
<vmeson>
my angle was clearly to point out that OSVs are happy to do longer term support! ;-)
<vmeson>
to save people the time, I have: EOL means some community support as well as OS Vendor support for some releases.
<qschulz>
"community support" is a bit amibuguous. We technically do support here on IRC or sometimes by mail, but there won't be any patch if the branch is EOL
Guest48 has joined #yocto
<qschulz>
as opposed to "real" community support of a release, where the branch continues to live with some backports and fixes, without any dot release
Guest858 is now known as mfe
vd has joined #yocto
leon-anavi has joined #yocto
<vmeson>
qschulz: updated to say: EOL means some community support on email lists but no commit updates in the repos. There is also OS Vendor support for some Yocto EOL releases.
<halstead>
vmeson: I've forced the cert to reload on layers so the expiration is fixed. I also checked for clockskew. It was off by 0.002685 seconds which shouldn't have caused trouble.
<paulg>
<tinfoil_hat>must be those negative leap seconds...</tinfoil_hat>
<halstead>
Must be. I'll figure out why the cert isn't reloading automatically next week. I'm on vacation today.
goliath has joined #yocto
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 272 seconds]
tp43_ has quit [Ping timeout: 256 seconds]
Tokamak has quit [Ping timeout: 258 seconds]
Tokamak has joined #yocto
Xagen has quit [Ping timeout: 258 seconds]
Xagen has joined #yocto
florian has quit [Quit: Ex-Chat]
<rburton>
ah joy, looks like buildhistory is broken with the new overrides
<smurray>
doh!
tp43_ has joined #yocto
<rburton>
hm no maybe its been broken a while :)
wing0 has joined #yocto
* rburton
provisionally blames fray
Tokamak has quit [Ping timeout: 258 seconds]
roussinm has joined #yocto
hpsy has quit [Quit: Leaving.]
leonanavi has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
mranostaj has quit [Ping timeout: 248 seconds]
Tokamak has joined #yocto
<tp43_>
anyone using yocto for sierra wireless hardware or legato dev platform in here?
mranostaj has joined #yocto
Ad0 has quit [Ping timeout: 248 seconds]
Ad0 has joined #yocto
mseeber_ has joined #yocto
mseeber_ has quit [Remote host closed the connection]
mseeber has quit [Ping timeout: 248 seconds]
jmiehe has quit [Quit: jmiehe]
<smurray>
JPEW: were you planning to submit your bitbake change wrt moving asyncio loop creation into the child processes? or should I pick it up for the PR server patchset?
<manuel_>
Hi all! When doing runqemu without `nographic`, I get the following error: Failed to run qemu: Could not initialize SDL(x11 not available)
<manuel_>
Didn't find a solution yet. I'm all ears if someone has come across this.
<LetoThe2nd>
manuel_: in which kind of environment?
<LetoThe2nd>
cocoJoe: very good!
<manuel_>
On the build machine, x86_64
<manuel_>
Build is not dockerized
<cocoJoe>
what about ssh or tmux?
<manuel_>
cocoJoe? Was that directed at me?
<cocoJoe>
manuel_yea sorry
<smurray>
manuel_: if you're logging into a machine and don't have remote X11 set up, you'll get that
<LetoThe2nd>
manuel_: well, two obvious things to check: screen/tmux/ssh, obviously, and libsdl1.2 being installed and working
<smurray>
manuel_: these days I use the VNC support instead, that's activated by passing publicvnc to runqemu
<manuel_>
I assumed when I do runqemu without 'nographic' it will just open an X11 window with the output?
<LetoThe2nd>
smurray: i was just about to suggest vnc, +1 for the perfect hint!
<manuel_>
I think thats what qemu did when I ran it manually years ago with my handmade image (no yocto, just debootstrap and loopback devices)
<smurray>
manuel_: if you're doing it on a local machine with X11, yes. If you're sshing into a machine and running runqemu, then you'll need to get remote X displayt working
<cocoJoe>
manuel_ what does "echo $DISPLAY" print?
<manuel_>
smurray: I'm on a local machine with X11.
<smurray>
manuel_: as cocoJoe suggested, check what DISPLAY is set to
<manuel_>
cocoJoe: I think you're onto something. In that kas-created shell where I do runqemu, echo $DISPLAY returns just a newline. On the host it's ":0", which is the right thing I assume
<smurray>
manuel_: next step would be try running another X app (e.g. xeyes) from your build environment to make sure anything will come up
<LetoThe2nd>
manuel_: kas usually wants to (and also does) put you into a docker
<manuel_>
cocoJoe: It works now. All I had to do was a "export DISPLAY=:0" inside the kas shell
<LetoThe2nd>
hm, so it seems to open a clean sub shell
<manuel_>
LetoThe2nd: I'm currently only using the kas pip3 package, not the docker container
<cocoJoe>
manuel_ was just about to suggest that :-D
<manuel_>
LetoThe2nd: Yepp I think you have to allow that var to go through in kas .yml file
<LetoThe2nd>
manuel_: sounds sensible
<manuel_>
cocoJoe: That was the logical next step :) Your guess was right. Thanks
<manuel_>
Next step: Get X11 to work on my Raspberry Pi 4. I'm building my thing for both machines.
<cocoJoe>
manuel_ you are welcome :-D
Guest0 has joined #yocto
Guest0 has quit [Client Quit]
<manuel_>
LetoThe2nd: Getting kvm running inside kas-docker-container is a bit tricky
<LetoThe2nd>
manuel_: yeah. but i am so old that my brain consequently interprets kvm as "keyboard-video-mouse"
<cocoJoe>
manuel_ if you can make kas pass in the --privileged flag it should be able to access KVM
<cocoJoe>
but if you are emulating ARM it will not work
<manuel_>
cocoJoe: Yeah, I assumed but didn't try out. Thanks to know that works. Will need to find a way around --privileged, though.
<cocoJoe>
manuel_ I normally make a VM in libvirt and use the output from yocto as disk image, but it can be a bit more tedious, but it works over ssh
<manuel_>
Ok that's tricky. I'm on my Raspi know. Something is starting a process "xinit /etc/X11/X11session -- /usr/bin/Xorg :0 -br -pn" every few seconds
<manuel_>
That process lives for a few seconds only, so I can't check it's environment, but I assume it's lacking the DISPLAY=:0
<manuel_>
Who is starting that process?
<manuel_>
It has forked off, so in htop shows up as child of pid 1
Tokamak has quit [Ping timeout: 258 seconds]
<manuel_>
Hmm, the Xorg log tells me "Failed to load module "fbdev""
rob_w has quit [Read error: Connection reset by peer]
jmiehe has quit [Quit: jmiehe]
<marex>
manuel_: do you actually care about the video output from the runqemu or can it be sent e.g. to Xvfb and ignored ?
<manuel_>
marex: I do actually care
<marex>
ok, then VNC it is
<manuel_>
marex: No need, when I runqemu without "nographic" now, it just pops up a windows. That's perfect.
<manuel_>
Still a bit slow, though, altough runqemu runs with kvm.
<tp43_>
I just spent 4hrs reading yocto docs. I started from the top and now I am at 3.4 Git Workflows and the Yocto Project. I regret to say, I did not learn anything more than I got from the quick start guide.
<tp43_>
If anyone wouldn't mind mentioning the hardware they are working on please. And if you have a link so I do not have to google would be bonus. Regards.
<manuel_>
tp43_: I'm working on a Raspberry Pi 4. How is that of interest to you?
<tp43_>
manuel_, I am thinking of what to buy. What are advantages to using Yocto over the images at the R pi website?
<manuel_>
That you have a tailormade linux system? That's what Yocto is all about I guess.
<tp43_>
manuel_, true
<paulg>
tp43_, it depends what you are trying to do. Are you looking for a cheap platform just to learn Yocto on, or do you have a specific embedded project in mind, or .... ?
<tp43_>
manuel_, no missing drivers?
<tp43_>
paulg, cheap to learn
<paulg>
If you can share a bit more on what your overall goal is, people might be able to give more guided help.
<tp43_>
paulg, learn to use Yocto
<marex>
qemu ?
<manuel_>
tp43: The meta-raspberrypi layer comes with some example images I think, so it should get you started very qicklly
florian has quit [Ping timeout: 248 seconds]
<tp43_>
marex, hmm, I did quick build. I can run qemu. So just play around with it, run commands, try to do stuff eh?
<marex>
well, yes, it costs nothing, the drivers are all there in the kernel ... so ... why not
<tp43_>
marex, yes of course.
<marex>
also, shipping time is the speed of your internet connectivity
<marex>
or are you looking for something tangible (board) ?
<tp43_>
marex I mean if I got out and buy one, the only difference is going to be that I had to flash it or otherwise install the image. And then ssh in. Then back to the same point as with qemu.
<tp43_>
marex, well it would be a real world experience then.
<marex>
tp43_: what do you hope to learn with that ? the part where every hardware has unique problems ? :)
<paulg>
yes, with r-pi, you'd be putting stuff (broadcomm firmware, u-boot etc) on an u-SD card and learing r-pi board specifics, but if you have no interest in the hardware specifics, then that doesn't help you much.
<paulg>
if you are just looking to change packages in a root filesystem image and change userspace contents etc - then qemu will do just fine and you won't be wasting time on board specifics you don't really care about.
<tp43_>
paulg, I am interested in the hardware specifics. But I guess I should start with learning just yocto for now and wait to get the hardware work.
<marex>
but if you buy e.g. a board which is poorly supported and suffer with it a long time to get it properly supported, it could be a good learning experience
<tp43_>
I have a wp76xx board from sierra wireless. But I can not do anything with it. But I see pi is there in the index. I'm not sure if it is in the reviewed index. But it might help me do some things, so then when I got back to the more challenging situation with sierrawireless, the easier parts won't be a problem.
<paulg>
there is also nothing stopping you from installing yocto on that 10 year old PC in your cousin Bob's basement that he never threw out yet (using generic-x86/common-pc target)
<tp43_>
marex, I am thinking of buying r pi 4 cortex(arm v8). I have a wp76xx arm v4
<tp43_>
paulg, that would be a better start. you are correct. I can make a bootable usb/cd?
<marex>
that armv4 might be easier to get started with -- simpler hardware which one can actually comprehend
<marex>
start with basic stuff, add complexity once you understand the basics
<tp43_>
yeah but I do not see any sierrawireless or legato in the index. I have to go to the vendor and I am not sure how to do. It is an industry device. Where as r pi is a hobby device with many blogs and what not for tutorials. So I thought R Pi would be easier.
<tp43_>
Although docs say going to the vendor is the best route.
<marex>
tp43_: so, roll your own layer for that board ?
<tp43_>
They do compilicated stuff, the instruction at for wp76xx. Like move to opt, take ownership, give back ownership. I mean no big deal, but so many things like that that do not make sense to me as of yet.
<marex>
pocketbeagle might also be a good platform, or some of the beagleboards
<tp43_>
marex. ok. cool yeah, I will start with learning how to roll out my own layer. Then for that board. But later, when I try to work on the wp76xx. I need to use the layers provided; all the drivers provided by the vendor.
<marex>
it is old and reasonably simple hardware
<marex>
tp43_: you could try and learn kernel work while at it
<tp43_>
marex, like what. what is kernel work. I saw one video. Hello world linux driver that just prints to kernel log.
<tp43_>
manuel_, Also, I want to know all the options. Like if I learn Yocto, all the various hardware options that open up to me. There is R Pi and Beagle bone. Then sierra wireless.
<tp43_>
XILINK
<tp43_>
*XILINx
<tp43_>
thx guys for the advice
<JPEW>
Hmm, apparently circular RDEPENDS are an allowed thing?
florian has joined #yocto
<marex>
not xilinx if possible
<marex>
that has extra complications due to the vivado/vitis
dev1990 has quit [Quit: Konversation terminated!]
jwillikers has quit [Remote host closed the connection]
<tp43_>
marex, thx
d0ku has quit [Ping timeout: 246 seconds]
camus has quit [Ping timeout: 272 seconds]
camus has joined #yocto
<tlwoerner>
tp43_: if you visit http://layers.openembedded.org/layerindex/branch/master/layers/, select your branch (e.g. master, dunfell) then, on the right, click "Filter layers" and only choose "Machine (BSP)" you'll get a list of BSP layers that will give you an idea of what devices are supported
<tlwoerner>
note, however, that the quality can vary, so just because you find something there, doesn't mean it'll be painless to use
<tlwoerner>
take note of the last commit to a given layer to get an idea of which ones are more currently supported
<tlwoerner>
also, if you've selected a board, before buying, try doing a build for that MACHINE to see how well it goes :-D
<tp43_>
tlwoerner, I can do bitbake core-image-minimal for the qemuxarm and x86, both 64 bit versions np. But you mean, not the qemu version, but actual hardware version right?
<tp43_>
I am thinking of buy R PI 4 which is arm v8 cortex
<tlwoerner>
tp43_: yes, i take it you're interested in trying yocto out on different physical devices (e.g. rpi etc) so i recommend doing a build before you buy, just to make sure the layer is usable :-)
<tlwoerner>
oh yea, the rpi4 will work fine
<tp43_>
They have it at local electronics shop here in my town for $80. But then I guess I have to get the usb to uart at 3.3v converter cable too.
<tlwoerner>
you can choose between 32-bit or 64-bit
<tlwoerner>
yes, console cables are good. i've got a stack of them
<tlwoerner>
(most of us probably do)
<tp43_>
tlwoerner, why/how do you have so many/
<tp43_>
Maybe I do too then.
<tp43_>
I can just cut any old usb cable? and solder those single pin connectors?
<tp43_>
Just looks like a regular usb cable with those single pin connectors.
<tlwoerner>
whatever works for you :-)
<tp43_>
tlwoerner, so it is just a usb cable right? There is nothing special in there to doing conversion or setting voltages
<JPEW>
tp43_: it's not a regular USB cable. There is a usb-uart adaptor chip in the plug
<tp43_>
JPEW, thx
<tp43_>
JPEW, do you know where else to buy them, like in person instead of waiting for the mail?
<JPEW>
Any USB UART adaptor that can operate at 3.3v should work
<JPEW>
I always buy mine on Amazon
<tp43_>
JPEW I never heard of UART before recent
<JPEW>
Ah. It's pretty common in embedded... It's simple enough that it almost always works so it's good for debugging
<tp43_>
JPEW had advantage over ssh/telnet of allowing you to read boot and kernel log
florian has quit [Ping timeout: 248 seconds]
<JPEW>
Correct. You can init it really early in the boot (bootloader or earlier even)
<tlwoerner>
oh right, yea there's the converter. like i said, most of us have a bunch of them. console cables are pretty common in embedded. it's either that, or blinking an LED (lol)
<JPEW>
There comes a point in most of my microcontroller projects where I seriously consider writing a printf() that does Morse code on an LED...
<tp43_>
JPEW lol
<moto-timo>
JPEW: thank you for the packagedata patch, you beat me to it
<JPEW>
moto-timo: was it actually breaking something?
<moto-timo>
RP: not sure about FILER*LIST needing override change in patch I just sent, but FILERPROVIDES and FILERDEPENDS are definitely needed or packagedata isn’t populated
<moto-timo>
JPEW: my Perl-rodeos WIP
<moto-timo>
Errr. perl-rdeps
<JPEW>
moto-timo: rodeo seems appropriate
<moto-timo>
JPEW: very. Lots of loops and I think there is a clown in a barrel
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<tp43_>
how do I do $runqemu -nographic qemux86-64, you know what I mean, cause that there what I entered did not work.
<tp43_>
cause the gui is for touch and the mouse dissapears in the window.
<tp43_>
Nevermind, I got it. instead you just do $qemu qemux86-64 core-image-minial
<tp43_>
or core-image-sato, but it boots sato by default
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
goliath has quit [Quit: SIGSEGV]
shoragan|m has quit [Ping timeout: 252 seconds]
barath has quit [Ping timeout: 252 seconds]
moto_timo[m] has quit [Ping timeout: 252 seconds]
cody has quit [Ping timeout: 240 seconds]
Emantor[m] has quit [Ping timeout: 256 seconds]
Spectrejan[m] has quit [Ping timeout: 256 seconds]
rostam98[m] has quit [Ping timeout: 256 seconds]
meck[m] has quit [Ping timeout: 240 seconds]
m1kr0[m] has quit [Ping timeout: 240 seconds]
lexano[m] has quit [Ping timeout: 252 seconds]
halstead[m] has quit [Ping timeout: 245 seconds]
shoragan[m] has quit [Ping timeout: 268 seconds]
SamuelDolt[m] has quit [Ping timeout: 268 seconds]
kayterina[m] has quit [Ping timeout: 268 seconds]
jwillikers[m] has quit [Ping timeout: 276 seconds]
jordemort has quit [Ping timeout: 276 seconds]
t_unix[m] has quit [Ping timeout: 276 seconds]
jonesv[m] has quit [Ping timeout: 276 seconds]
tokamak[m] has quit [Ping timeout: 276 seconds]
PascalBach[m] has quit [Ping timeout: 272 seconds]
ejoerns[m] has quit [Ping timeout: 272 seconds]
dwagenk has quit [Ping timeout: 240 seconds]
Alban[m] has quit [Ping timeout: 240 seconds]
berton[m] has quit [Ping timeout: 272 seconds]
Pierre-jeanTexie has quit [Ping timeout: 272 seconds]