<vmeson>
I started manualy wget'ing the opencv tarball. It's 1.9 GB and downloading on my lowly home connection is going to take almost an hour! Speed is varying b/w 250 KB/s and 1.2 MB/s. I think I'll make a graph of it!
<vmeson>
There: Not so shocking that YP dlds are much slower than github downloads: https://postimg.cc/94H4zQ6p
jclsn has quit [Ping timeout: 260 seconds]
<vmeson>
halstead: the variation in dl speed does seem larger than expected but I honestly haven't been making enough graphs of t-put variation recently to know if this is expected.
jclsn has joined #yocto
* vmeson
notes frequent TCP "Errors" in the dl from YP but decides to use the bandwidth for Netflix rather than more tests.
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
sakoman has quit [Quit: Leaving.]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
jclsn has quit [Client Quit]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
Tokamak has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
Tokamak has joined #yocto
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 240 seconds]
sakoman has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
jclsn1 has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn1 has quit [Ping timeout: 256 seconds]
Tokamak has quit [Ping timeout: 240 seconds]
jclsn1 has joined #yocto
Tokamak has joined #yocto
jclsn1 has quit [Ping timeout: 272 seconds]
jclsn1 has joined #yocto
jclsn1 has quit [Ping timeout: 272 seconds]
jclsn1 has joined #yocto
amitk has joined #yocto
amitk has quit [Quit: leaving]
amitk has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
<halstead>
that server is on AWS euro network I believe. Let's run some tests in the morning.
<halstead>
git.yoctoproject.org is anyway. Seeing the IP would help since there are multiple. downloads.yoxtoproject.org is in Portland Oregon USA.
sakoman has quit [Quit: Leaving.]
sstiller has joined #yocto
<dirtyflag>
hi working porting an old BSP (Mentor) to dunfell, i gat this error
<dirtyflag>
hmw[m]: thanks, i have found a "nativesdk-packagegroup-qt5-toolchain-host"
<dirtyflag>
that seems ok for my case.
<dirtyflag>
anyway, it brings in perl too, that gives a new romantic error "maximum shebang size exceeded, the maximum size is 128"
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
mckoan|away is now known as mckoan
lucaceresoli has joined #yocto
<hmw[m]>
shebang is the first line of a script that starts with !# that may not be longer as 128
rfuentess has joined #yocto
GNUmoon has joined #yocto
dev1990 has joined #yocto
matthewcroughan has quit [Remote host closed the connection]
matthewcroughan has joined #yocto
iokill_ has quit [Ping timeout: 240 seconds]
iokill has joined #yocto
alex_b has joined #yocto
prabhakarlad has joined #yocto
goliath has joined #yocto
kroon has joined #yocto
kroon_ has joined #yocto
kroon has quit [Ping timeout: 252 seconds]
florian has joined #yocto
camus has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<LetoThe2nd>
yo dudX
pasherring has joined #yocto
<hmw[m]>
how do i force debug compile when compiling applications whit an yocto sdk
<kroon_>
hmw[m], what build system is your application using ?
<kroon_>
cause i would it say, it depends on the build system used
<hmw[m]>
qmake
<kroon_>
I don't know much about qmake, but I would assume the same tricks apply even when building with a yocto sdk as when doing a native build with the host compiler
<hmw[m]>
my code crashes on call x when i have something that is "not executed yet " if i comment the newly added line way below it is not crashing
jmiehe has joined #yocto
florian_kc has joined #yocto
prabhakarlad has joined #yocto
jmiehe has quit [Quit: jmiehe]
<wyre>
should the .dtb filename in the dts/Makefile match exactly the filename of your custom .dts file? 🤔
<wyre>
I mean ... I've got this inside meta-mylayer/recipes-kernel/linux folder https://bpa.st/2JLA
<wyre>
and I'm not sure if I'm patching properly the Makefile, as my dts is actually called imx6ull-microgea-joifi.dts 🤔
<wyre>
so I'm not sure if I should patch the kernel Makefile with `imx6ull-microgea-joifi.dtb`
leon-anavi has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
alex_b has quit [Quit: Client closed]
<mckoan>
wyre: the names have to be identical
<pasherring>
Hey yoctoers! I have a quirky make based project, in which the Makefile is not in the root dir. Is there a proper way to append the do_compile[dirs] variable from the recipe itself?
<pasherring>
tried do_compile[dirs] =+ " ${B}/path/to/Makefile" to no avail
prabhakarlad has quit [Quit: Client closed]
<qschulz>
pasherring: just set B variable accordingly?
<ilunev>
Hello! Is there a way to enable pretty-print support for gcc@yocto? So that gdb prints std::vector etc nicely? I found some gdb scripts but they are really slow
<rburton>
Guest11: known infra problems. set PREMIRRORS="" to not use it.
<ilunev>
ah, looks like I can just use python for this
rob_w has quit [Remote host closed the connection]
<wyre>
would it be possible to include a custom U-Boot env in the .wic image file? 🤔 I'm not sure if I should do also a .bbappend for the u-boot recipe ..
kroon_ has quit [Remote host closed the connection]
kroon_ has joined #yocto
cambrian_invader has quit [Ping timeout: 252 seconds]
<Guest11>
rburton Thank you for confirming! I PREMIRROR and MIRROR set to "" 🙇
alex_b has joined #yocto
alex_b has quit [Quit: Client closed]
<hmw[m]>
how do i add libmysqlclient.so to my target ?
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
cambrian_invader has joined #yocto
leon-anavi has quit [Quit: Leaving]
nerdboy has quit [Ping timeout: 240 seconds]
<vvn>
Shouldn't we include packagegroup-machine-base in INITRAMFS_SCRIPTS by default?
<vvn>
like if a machine has an encrypted rootfs partition, one would likely add cryptsetup to MACHINE_EXTRA_RDEPENDS if they follow the guidelines
<khem>
that will suck-in all kernel modules etc. which might be too much for a initramfs kernel
<vvn>
khem: only the modules described by the machine as necessary to boot such critical partitions
<vvn>
that you do want in the initramfs
<vvn>
if I have a luks2+btrfs rootfs, I am supposed to set MACHINE_EXTRA_RDEPENDS = "cryptsetup" MACHINE_EXTRA_RRECOMMENDS = "kernel-module-btrfs", these are part of packagegroup-machine-base and I do need to duplicate that in the initramfs
<vvn>
one could argue that this is a distro choice, but it becomes critical to successfully boot a system
pasherring has quit [Remote host closed the connection]
pasherring has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
geoffhp has quit [Remote host closed the connection]
<khem>
you want those called out explicitly in initramfs image with PACKAGE_INSTALL
<khem>
these images should be minimal
<khem>
its easy to build ground up.
amitk has quit [Ping timeout: 240 seconds]
<vvn>
khem: I think what's missing is DISTRO_ESSENTIAL_EXTRA_RDEPENDS/RRECOMMENDS and have packagegroup-core-boot depends on split packagegroup-machine-boot and packagegroup-distro-boot.
<khem>
introducing another abstraction and variable does need to have some benefits. So If I can blindly build a common initramfs image that will boot every board and is lean and mean, I do see benefits but I think we are not there
<smurray>
there's also room for some potential for wackiness with vendor BSPs throwing piles of stuff into MACHINE_EXTRA* that you might not want in an initramfs
<smurray>
s/potential for/potential/
<vvn>
I see
<vvn>
that ends up being a distro configuration in fact
<vvn>
and thus only packagegroup-distro-base may be safe to rely on, if the distro wants to add it to INITRAMFS_SCRIPTS
<vvn>
The confusing part is that most of the packagegroup-*base* groups are in fact machine specific
<vvn>
or packagegroup-machine-base, assuming the distro carefully control what the BSP layer put in there
kevinrowland has joined #yocto
rfuentess has quit [Remote host closed the connection]
<smurray>
vvn: the choice of luks2+btrfs is not a machine thing in my mind, so tying it to the distro somehow would be the way to go
<vvn>
smurray: definitely
<vvn>
I think I'm trying to hard to rely on a well configured distro in order to simply build core-image-minimal-initramfs and core-image-base for my machines, but it looks like explicit images are always preferred.
<vvn>
But specific image recipes tend to introduce machine-specific bits and I don't like this much
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
mckoan is now known as mckoan|away
<smurray>
vvn: poky is an example/sample, at some point defining your own packagegroups for your own distro is perfectly reasonable. I suspect there a lot of downstream distros that don't use core-base and its packagroups
<alejandrohs>
I got someone asking me about running the mount command inside a bitbake task, which returns some permission error, my guess is its because of pseudo, the only thing I can think of is sort of removing pseudo from the environment and run sudo, which sounds like a bad idea, Does anyone have any good ideas on how to achieve something like that?
<rburton>
i'm terrified to ask why you'd mount in a task
<rburton>
remember even if you call sudo you can't enter a password
<fray>
Ya, equally terrified
peoliye has joined #yocto
<fray>
you can avoid pseudo in specific tasks.. but mounting a disk requires specific permissions, ones that you really shouldn't trust in the build environment
<peoliye>
also tried giving explicit KBUILD_EXTRA_SYMBOLS to the exact path of Module.symvers but that didn't help either.
<peoliye>
It is failing during MODPOST.
paulg has quit [Ping timeout: 240 seconds]
<rburton>
alejandrohs: and pseudo isn't enabled so is basically passthrough in most tasks, so it shouldn't get in the way if the user has rights to mount without any ACLs involved
<RP>
Anyone around who fancies talking through a parser multiprocessing deadlock?
<vvn>
smurray: really? wouldn't that seem weird to reinvent the wheel and define your own base package groups? Like the init manager, all modules, etc.
<Saur[m]>
RP: Happy to listen, but not sure how much help I can be.
rsalveti has joined #yocto
<alejandrohs>
hahaha believ me I dont like it either
<alejandrohs>
thanks rburton fray
<smurray>
vvn: sttuf like that is in core-boot. It's the base/base-extended packagegroups that I suspect are perhaps not widely used. e.g. we don't use them in AGL
<vvn>
alejandrohs: what are you trying to achieve with mount exactly?
<alejandrohs>
vvn: not sure what theyre trying to do tbh, I think they want to mount an image and modify it in some way
<vvn>
alejandrohs: you should ask, because you might actually be able to add the tweak before of after depending on the tool, filesystem type, etc.
<RP>
Saur[m]: There is basically a race/hang in the parsing code if there is any kind of unclean shutdown (i.e. force=True in the code). The reason is the lock for the event pipe to the event handlers since the parsing processes write directly to the UIs
<vvn>
smurray: I see. So basically your AGL image recipes have IMAGE_INSTALL = "packagegroup-core-boot packagegroup-agl-foo packagegroup-agl-bar" I presume
<RP>
Saur[m]: the issue is the self.wlock in ConnectionWriter. If we call .terminate on a parsing process that happens to be in the log writer, game over, everything hangs
<RP>
We can remove the terminate codepath but then we can't Ctrl+C out of parsing
<smurray>
vvn: yep
<fray>
Is there any way to make the lock 'clear' on exit (of the process that holds the lock)?
<smurray>
vvn: though there are a couple of image's that are included to act as a base. It's on my todo list to redo some of it to have an e.g. agl-image.bbclass
<alejandrohs>
RP: does that mean that cntrl+c wont have an immediate effect while parsing? or that cntrl+c would just be ignored?
<RP>
alejandrohs: at the moment the UI sees it and sends commands to the server to say "stop parsing"
<fray>
Or is the issue the process trying to exit holds the lock already?
<RP>
fray: given the locks python is using, even if the processes are totally gone, the lock is locked
<RP>
and even if we could unlock it, the pipe would have corruption potentially
<fray>
any way for the terminating process to clear the lock just before exit (if held by itself)?
<RP>
fray: the worry is if it is in the middle of a write
<fray>
anyway to declare something a critical section, not permit (ctrl-c) termination during a _short_ window?
prabhakarlad has quit [Quit: Client closed]
<fray>
something like a signal handler, catch teh sigint, and if a 'critical seciton' bit is selected, return back to the code -- otherwise complete the exit.. then inside the program set/clear the flag (quickly)?
prabhakarlad has joined #yocto
<RP>
fray: I'm wondering if we can do the opposite. Rewire SIGINT so that breaks out the parse but would be deferred in the locked section
<RP>
(and then send SIGINT to the child parsers if we need to shutdown)
<fray>
ok
<RP>
The trouble is we only want this behaviour in the parsing child processes which makes things ugly code wise
Minvera2 has joined #yocto
Minvera has quit [Remote host closed the connection]
<RP>
all that does is puts a really slow event at the end of parsing
<RP>
so the slow events + parsing error == hang
<RP>
out the box there are a load of zombies but even with that cleaned up, the lock isn't freed and still game over
<Saur[m]>
RP: Is the problem that the ConnectionWriter.close() method closes the pipe under the .send() method? I.e., shouldn't the .close() method take the wlock before doing the close?
<Saur[m]>
(I have absolutely no idea how the multiprocessing class works, so just ignore if it is too stupid a question.)
<RP>
Saur[m]: closing it should be fine, you shouldn't need a lock for that
<Saur[m]>
Ok.
<RP>
the lock is just stopping writes being interleaved on the pipe
<vvn>
smurray: you mean that you have agl-image-base.bb and agl-image-foo.bb which require agl-image-base.bb?
<smurray>
vvn: sort of, we have a agl-image-minimal.bb and agl-image-weston.bb that are used as the base of the more featured agl-demo-*bb images
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<vvn>
smurray: I'm pretty sure an agl.bbclass with IMAGE_CLASSES += "agl" would be more than enough to pull in packagegroups via agl-* image features, like agl-ui.
<smurray>
vvn: we had a lot of packagegroups for various profiles and functionality things, but we've started reducing those as they weren't really providing enough value
<smurray>
vvn: yeah, we'll likely end up with a bbclass, but it's somewhat of a low priority just atm. Downstream use by AGL members is pretty opaque to us, my current assumption is they all build their own images up, so we can be wasting our time trying to overbuild packagegroups
<vvn>
smurray: true, so far the packagegroup seems nice just to centralize the view of your complete software stack in a simple packagegroup-foo.bb file, and eventually making it easy to pull them in and declare conflicts with image features.
<fray>
Looking for an idea. I've got a package (lm_sensors) that I want the systemd service enabled by default on _one_ board, but not another.. and I'd rather not make the package machine specific. Is there any standard way (in the machine) to enable a service by default?
<smurray>
vvn: yeah, that seems a reasonable take
pasherring_ has joined #yocto
pasherring has quit [Remote host closed the connection]
<Saur[m]>
fray: ROOTFS_POSTPROCESS_COMMAND?
<fray>
I wasn't aware of a way to use a rootfs postprocess toc ontrol a service..
<smurray>
rm the preset file?
<smurray>
or change it to say disabled
<fray>
ya, service file is disabled by default... so all the boards, except one should have it that way..
<smurray>
it might be possible to drop in an override for the systemd presets under /etc/systemd, could do that for the different machine
<fray>
which is why I'm struggling for the one board where I want it enabled
<Saur[m]>
I haven't tried it myself, but I think it should be possible to run the native systemctl from a postprocess for the board you want.
<Saur[m]>
Or what smurray said.
<smurray>
perhaps easier to just make the symlink in the rootfs postprocess
<fray>
I'll see if I can do it on the rootfs side.. thanks
<smurray>
fray: another option that comes to mind, though likely a bit messy, would be to enable the service by default, but split the bit(s?) for that out via an extra package
argonautx has quit [Quit: Leaving]
goliath has joined #yocto
paulg has joined #yocto
pasherring_ has quit [Quit: Leaving]
Mike23 has joined #yocto
geoffhp has joined #yocto
sgw has quit [Remote host closed the connection]
Mike23 has quit [Quit: Client closed]
florian_kc has joined #yocto
<vvn>
fray: the less hacky is indeed SYSTEMD_AUTO_ENABLE:${PN}:machinefoo = "enable", or as Saur[m] suggested, maybe make it image specific with a ${IMAGE_ROOTFS}/etc/systemd/system/default.target.wants/lm_sensors.service -> /usr/lib/systemd/system/lm_sensors.service symlink via ROOTFS_POSTPROCESS_COMMAND.
<vvn>
fray: you might as well append the lm_sensors package to add a drop-in file to make the service run conditionally on the presence of a kernel command line or whatever can identity your machine, then enable the service by default
<vvn>
e.g. ConditionKernelCommandLine=foobar in the [Unit] section or ExecCondition=/some/id-script in the [Service] section.
<vvn>
this way you don't make the package machine-specific, but you make the service "smarter" to run under your conditions
<fray>
I'm losing my mind, where is the systemctl binary that is used to enable things? If I try to use the qemu_wrapper_cmdline in the ROOTFS_POSTPROCESS_COMMAND function, it fails every time
<fray>
complains that it can't get root for a chroot?!
<fray>
So my question, how do I run 'systemctl enable fancontrol.service' in a ROOTFS_POSTPROCESS_COMMAND properly? (Premably I need --root=${IMAGE_ROOTFS} as well
<fray>
I can't figure out how this even works in the package installs
<vvn>
fray: you don't. systemctl is for runtime, for compile time systemd is file based, just do a standard symlink. You might prefer to add a drop-in file in the package to run the service conditionally. Read the documentation for SYSTEMD_AUTO_ENABLE and maybe man systemd.unit as well.
<fray>
No systemctl _IS_ available, it's used by postinstall scriptlets
<fray>
I think I have ti working now.. I've no idea what I did wrong the first time, but now just calling systemctl --root=${IMAGE_ROOTFS} enable fancontrol.service is working fine
<vvn>
whatever suits you, it's essentially doing the same thing
<zeddii>
It's always better to not poke directly at systemd's symlinks if possible. chaos and madness.
Minvera2 has quit [Remote host closed the connection]
behanw has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 240 seconds]
goliath has quit [Quit: SIGSEGV]
florian_kc has joined #yocto
goliath has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
grma has joined #yocto
otavio has quit [Remote host closed the connection]