mvlad has quit [Remote host closed the connection]
LocutusOfBorg has quit [Read error: Connection reset by peer]
LocutusOfBorg has joined #yocto
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
nerdboy has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 260 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
jclsn has joined #yocto
dgriego has quit [Ping timeout: 256 seconds]
dgriego has joined #yocto
cslcm has quit [Read error: Connection reset by peer]
Saur_Home has quit [Quit: Client closed]
cslcm has joined #yocto
Saur_Home has joined #yocto
dgriego has quit [Ping timeout: 276 seconds]
chep has quit [Ping timeout: 246 seconds]
cslcm has quit [Client Quit]
chep has joined #yocto
lthadeus has joined #yocto
PhoenixMage has joined #yocto
<PhoenixMage>
Afternoon all, been a while
dgriego has joined #yocto
<PhoenixMage>
I am trying to build a mainline kernel using meta-intel with a recipe that works for other BSPs but I get a weird error "do_kernel_metadata: Could not locate BSP definition for intel-corei7-64/standard and no defconfig was provided". I can see KCONFIG_DEFCONFIG isnt set for meta-intel like it is for other BSPs but even still linux-yocto will compile
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
simonew has quit [Remote host closed the connection]
lthadeus has quit [Ping timeout: 256 seconds]
lthadeus has joined #yocto
Minvera has quit [Ping timeout: 256 seconds]
Chaser has joined #yocto
jmd has joined #yocto
roussinm has quit [Quit: WeeChat 3.8]
jmd has quit [Remote host closed the connection]
lthadeus has quit [Ping timeout: 256 seconds]
jmd has joined #yocto
lthadeus has joined #yocto
jmd has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
sakman1 has joined #yocto
sakman has quit [Ping timeout: 256 seconds]
sakman1 is now known as sakman
alessioigor has joined #yocto
Guest67 has joined #yocto
frieder has joined #yocto
thomas_34 has joined #yocto
goliath has joined #yocto
manuel_ has joined #yocto
xmn has quit [Ping timeout: 264 seconds]
<thomas_34>
Good morning guys, I have a problem with my recipe. In the build directory "recipe-sysroot-native/usr/bin" the C/C++-Compiler are missing. So the do_compile task fails. However, the compiler shows up at many other recipes
<thomas_34>
As example: ./arago-tmp-default-glibc/work/aarch64-oe-linux/memtester/4.5.1-r0/recipe-sysroot-native/usr/bin/aarch64-oe-linux/aarch64-oe-linux-gcc
<thomas_34>
Do I need to inherit something in my recipe? So that yocto provides the toolchain in recipe-sysroot-native?
rob_w has joined #yocto
Guest99 has joined #yocto
manuel_ has quit [Ping timeout: 268 seconds]
Guest99 has quit [Client Quit]
ngp has joined #yocto
zpfvo has joined #yocto
ngp has quit [Client Quit]
wicki has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
Kubu_work has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
manuel_ has joined #yocto
olani- has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<LetoThe2nd>
yo dudX
Guest67 has quit [Quit: Connection closed]
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
lthadeus has quit [Remote host closed the connection]
lthadeus has joined #yocto
tnovotny has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
lthadeus has quit [Ping timeout: 245 seconds]
flom84 has joined #yocto
prabhakarlad has joined #yocto
lthadeus has joined #yocto
olani- has quit [Ping timeout: 268 seconds]
frieder has quit [Remote host closed the connection]
flom84 has quit [Quit: Leaving]
frieder has joined #yocto
florian has joined #yocto
TheComet has joined #yocto
<TheComet>
I am getting an error for package "libxcrypt": "configure: error: bad value 'all' for --enable-hashes". Can anyone point me where I can get help?
<rburton>
thomas_34: are you looking for usr/bin/aarch64-oe-linux/aarch64-oe-linux-gcc in your sysroot, or usr/bin/gcc?
<thomas_34>
rburton, I would like to have /usr/bin/gcc. I just need some compiler which makes CMake-Compiler-Check happy
<thomas_34>
Better case would be to have x86_64-linux-gnu-gcc but I guess thats even more complicated to achieve
<thomas_34>
Sorry, I meant aarch64-oe-linux-gcc
<rburton>
thomas_34: you won't get 'gcc' because that's the host compiler. cross-compilers are prefixed with the triple. inherit the cmake class and it handles telling cmake where the compilers are.
speeder has joined #yocto
<thomas_34>
Hmm.. my recipe builds isolated from yocto with cmake stuff. At the stage where it fetches its own toolchain (with cmake package) it executes a c_compiler check, which I cannot suppress. I checked the do_compile script of that recipe, which sets CC to "aarch64-oe-linux-gcc". Cmake then internally tries to find the patch to that compiler. However,
<thomas_34>
no directory in PATH provides that.
<thomas_34>
So I would like that yocto provides that recipe just some compiler, which I can give my external CMake at that stage, to make it happy.
<rburton>
if your cmake recipe does horrible things then you need to beat it into submission
<thomas_34>
I have tried to inherit binutils and cmake in that recipe, but still no aarch64-oe-linux-gcc shows up anywhere in recipe-root
<rburton>
it won't
<rburton>
inherit binutils isn't a thing
<rburton>
do you mean depends?
<thomas_34>
Oh sorry. Yes I mean depends
<rburton>
the cross compiler is part of the default DEPENDS
<rburton>
unless you set INHIBIT_DEFAULT_DEPS
<thomas_34>
So default DEPENDS means, I don't need to write any DEPENDS in my recipe, to depend on cross compiler?
<thomas_34>
Ok, I'll check that with bitbake -e
<rburton>
look at any recipe in oe-core: you'll see that almost none depend on gcc
<thomas_34>
Yes, ok
leon-anavi has joined #yocto
Guest42 has joined #yocto
<Guest42>
Has anybody built Yocto on a host machine running Guix?
<rburton>
thomas_34: but PATH gets extended to add the path with the cross-compilers in
<thomas_34>
rburton i'm back in ~30 minutes sorry
<rburton>
Guest42: the "unconventional" file system could make that interesting. you're welcome to report issues but you might get told to use a supported host distro.
<Guest42>
My current problem is that it doesn't find <linux/limits.h>
<Guest42>
But this file seems to be contained withing Yocto's own repository files
<Guest42>
I find it is included in at least one recipe
prabhakarlad has quit [Quit: Client closed]
<Guest42>
Well, two actually. It is included in zstd-native and in the kernel
<Guest42>
So that should not be dependent on the host distro, since the file is contained in Yocto's sources
lthadeus has quit [Quit: Leaving]
<Saur_Home>
Guest42: Everything in linux/ and asm/ comes from the kernel.
<Guest42>
Sure, shouldn't Yocto then use the include files for the kernel it is currently building for, not the kernel of the host machine?
<Saur_Home>
When building for target, it should yes.
<TheComet>
I'm not sure why this patch isn't in my branch though
<Guest42>
Okay, I see. The recipe that is failing to find that file is m4-native, so that makes sense
<rburton>
Guest42: native so host includes
<Saur_Home>
native recipes are built using the host's gcc, and using the host's include files and libraries, unless there are native dependencies that override any of them.
<Guest42>
Any pointers how I can make Yocto find it? I'm not really a C++ dev, so I'm not too familiar with compiler flags and include directories and so on
<rburton>
i can only imagine that guix has put them somewhere interesting and there's a mismatch between how we're using the host compiler and where guix has put stuff
<Saur_Home>
Does /usr/include/linux/limits.h exist on the host?
<rburton>
£10 says no :)
<Saur_Home>
:)
<Guest42>
No, it is somewhere inside the /gnu/store
<Guest42>
But how can I add this path to the compiler's search path?
lthadeus has joined #yocto
<rburton>
we expect the host compiler to know how to find its own paths
<Guest42>
I bet it does
<rburton>
obviously not :)
<Guest42>
In normal cases it does, but Yocto must do something to it
<rburton>
does guix set environment variables to tell gcc where to look?
<rburton>
all we do is purge the environment before starting builds
<Guest42>
Guix has a bunch of different environment variables yes
mvlad has joined #yocto
<rburton>
after you've ran oe-init-build-env, add the name of those magic variables to BB_ENV_PASSTHROUGH_ADDITIONS
ederibaucourt has quit [Ping timeout: 256 seconds]
thomas_34 has quit [Quit: Client closed]
shoragan has quit [Read error: Connection reset by peer]
OnkelUlla has quit [Read error: Connection reset by peer]
thomas_34 has joined #yocto
shoragan has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
paulg has quit [Read error: Connection reset by peer]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
mvlad has quit [Ping timeout: 256 seconds]
wicki has quit [Ping timeout: 256 seconds]
paulg has joined #yocto
<Guest42>
rburton: thanks, I found the variables C_INCLUDE_PATH and CPLUS_INCLUDE_PATH which contains the directory which <linux/limits.h> is in. I added these variables to BB_EN_PASSTHOUGH_ADDITIONS, but I still get the same error. I have looked inside the paths and confirm that the file is actually there
<Guest42>
s/EN_/ENV_/
<Guest42>
Oh wait, I made a stupid mistake. Instead of adding the variable names, I added the variable contents..
<Guest42>
Well, it still doesn't work even after correcting my BB_ENV_PASSTHROUGH_ADDITIONS
<Guest42>
Does Yocto use the variables C_INCLUDE_PATH and CPLUS_INCLUDE_PATH?
tnovotny has quit [Read error: Connection reset by peer]
tnovotny_ has joined #yocto
<Saur_Home>
Guest42: No.
<Guest42>
Then what variable does it use?
tnovotny has joined #yocto
<Saur_Home>
Guest42: That is really up to the build system used by each recipe. Typically, most support CFLAGS, LDFLAGS, etc so those are set by bitbake.
rob_w has quit [Remote host closed the connection]
<Saur_Home>
Guest42: If you write a minimal C-file that includes linux/limits.h and has an empty main() function, and then compile it directly with `gcc`, will that work?
tnovotny_ has quit [Ping timeout: 260 seconds]
<Saur_Home>
Or do you need to specify extra arguments to gcc to make it build?
mvlad has joined #yocto
<rburton>
Guest42: you might need to export in to your local.conf too
<Guest42>
Saur_Home: Yes, it worked
<Guest42>
rburton: How?
<Guest42>
Just add a export VARIABLE_NAME?
<rburton>
Guest42: can you do the same gcc but do 'env -i gcc ...'?
<rburton>
and yes, export C_INCLUDE_PATH if that's what guix gcc listens to
<Guest42>
env: ‘gcc’: No such file or directory
<Guest42>
I'm guessing env -i removes all environment?
ederibaucourt has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
<rburton>
yes
<Guest42>
Then it can't find gcc, since there is a lot of PATH stuff and so on
<rburton>
try env -i PATH=$PATH gcc ...
<rburton>
that will preserve path but wipe everything else
<Guest42>
Then I get the same error as in Yocto
<rburton>
good, problem isolated.
<Guest42>
If I add C_INCLUDE_PATH also, then it finds the limits.h
<rburton>
problem isolated :)
<Guest42>
But why doesn't it work in Yocto when I add that same variable?
<rburton>
you'll need to export it in local.conf too
<Guest42>
I did
<Guest42>
Oh, wait. It is now a different error, so I guess it might have worked
<rburton>
right
<rburton>
it might need a library path too
<Guest42>
| configure: error: cannot run C compiled programs.
<Guest42>
| If you meant to cross compile, use `--host'.
<rburton>
yeah you'll need to figure out why that happens, i guess a library path is missing so it can't find the loader
<Guest42>
Hmm, added LIBRARY_PATH also, but no difference
* rburton
shrugs
<rburton>
guix isn't on the supported distro list, so you get the fun of fixing it
<rburton>
isn't that the point of running an experimental distro anyway?
<Guest42>
Sure, but the specifics of how Yocto works is hardly my responsibility
<Guest42>
More like gcc actually
<Guest42>
I feel the problems are general, just that there are a lot of assumptions on default values of variables
<Guest42>
These variables are set for a reason
<rburton>
we expect "gcc" to work
<Guest42>
gcc does work
<rburton>
if it needs magic variables set then ensure they're set inside the build
<Guest42>
But not inside bitbake
<Guest42>
How can I just pass my whole env?
<rburton>
bitbake explicitly purges the environment so you just need to figure out what variables need preserving
<Saur_Home>
In normal Linux, you do not need to set any environment variables to make `gcc` work, which is what `bitbake` expects.
<Guest42>
I can't really find any more variables that look relevant
zpfvo has joined #yocto
<rburton>
i'd be asking a guix channel as this is their setup
<Guest42>
Well it works everywhere else
<rburton>
yocto's assumption is that 'env -i gcc' builds a binary and `env -i ./a.out` runs it. if that isn't true then you need to identify the variables that need preserving.
<Saur_Home>
Guest42: You also need to be carefull with exporting the variables so that they are only exported for native. You do not want them active when building for target...
<Guest42>
How do I do that?
<rburton>
lets get past "build and run a binary" first :)
<Guest42>
Okay, I asked in #guix which env variables are used by gcc
<rburton>
i suspect you want the runtime loader, not gcc
<Saur_Home>
Honestly, the easiest would probably be to create a wrapper for `gcc` that runs the real `gcc` with the extra environment variables set...
<rburton>
the easiest would be to use a yocto container like crops or kas
<Saur_Home>
True. :)
<Guest42>
I was previously using a docker container to build, but really want to get native to work
<rcw>
I'm looking for any feedback and to gauge interest in whether others are interested in expanding its capabilities.
rm5248 has joined #yocto
<Guest42>
rburton: after spending some time in #guix I'm now convinced that there is nothing more than those variables needed from the Guix side of things. The problem is now all on the Yocto side
<rburton>
Guest42: assuming you mean the error that starts 'please ensure your host's network is configured correctly'
<rburton>
Guest42: if this is work time i'd be considering a supported distro
<Guest42>
Nah, I'm stubborn
<Guest42>
If it is just a wget check then why doesn't it work? I have confirmed that wget is in fact able to access that url
<Guest42>
Aha, it might be a certificate error
jmiehe has quit [Quit: jmiehe]
Minvera has joined #yocto
xmn has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
Guest42 has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
prabhakarlad has joined #yocto
<RP>
Guest4041: probably more envvars
simonew has joined #yocto
<simonew>
Hi together
lthadeus_ has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 264 seconds]
Saur_Home has quit [Quit: Client closed]
zpfvo has joined #yocto
Saur_Home has joined #yocto
<tgamblin>
FYI it seems F39 has shipped Python 3.12.1, so builds should work again
zpfvo has quit [Ping timeout: 276 seconds]
zpfvo has joined #yocto
<RP>
tgamblin: excellent. We should make 3.12.0 error
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
alperak has quit [Quit: Client closed]
alperak has joined #yocto
florian has quit [Quit: Ex-Chat]
<rm5248>
Hi all, I'm trying to get sysvinit working to test something. I set INIT_MANAGER="sysvinit", but busybox fails to install with: "install: cannot create regular file '/home/robert/yocto-testing/poky/build-microchip/tmp/work/core2-64-poky-linux/busybox/1.35.0-r0/image/etc/default/busybox-syslog': No such file or directory". this is using current head of kirkstone. any thoughts as to what might be wrong?
<rm5248>
I do have some custom busybox settings, not sure if that would cause an issue at all
<rburton>
yeah probaby your settings conflicting with what the recipe wants to do
simonew has quit [Ping timeout: 255 seconds]
simonew has joined #yocto
simonew has quit [Remote host closed the connection]
simonew has joined #yocto
alperak has quit [Quit: Client closed]
<simonew>
what is the process to contribute to the wiki? Request an account and then just do? I searched and could not find it.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leon-anavi has quit [Remote host closed the connection]
<rburton>
simonew: yes
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<simonew>
ok, will do so thx
zpfvo has quit [Quit: Leaving.]
simonew has quit [Remote host closed the connection]
croptixboz has joined #yocto
croptixboz has quit [Client Quit]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
<moto-timo>
rcw: do you have a public branch of the error-report-web Django LTS hacks/fixes?
<yudjinn>
this is a fresh environment I'm just trying to test locally on how this will work for my purposes, and immediately trying to login on the admin panel throws a 403 for CSRF verification
<moto-timo>
rcw: and yes, it is begging for a docker-compose.yml
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
<rcw>
moto-timo: Looks good to me
<moto-timo>
rcw: added README.docker for how I am building and running locally
frieder has quit [Remote host closed the connection]
goliath has joined #yocto
<moto-timo>
yudjinn: use the dockersetup.py script to spin up your own layerindex... the problem is populating the data takes a while and hits the layers.openembedded.org server with a lot of requests
pabigot has joined #yocto
Kubu_work has quit [Quit: Leaving.]
<rcw>
moto-timo: README.docker looks good. I had to add this to settings.py for cases where I wasn't running it on the local machine: ALLOWED_HOSTS = ['myworkstation', 'localhost', '127.0.0.1']
tnovotny has quit [Quit: Leaving]
<yudjinn>
moto-timo: I used the dockersetup.py, and I'm running locally; still get the CRSF error
<rcw>
moto-timo: Also, this is how I used send-error-report: send-error-report --no-ssl --server 'myworkstation:5000' tmp-glibc/log/error-report/error_report_20231219115707.txt --name jdoe--email "john.doe@company.com"
<yudjinn>
moto-timo: yeah its hitting this: `Origin checking failed - https://localhost:8081 does not match any trusted origins.`
<moto-timo>
yudjinn: you need to look at dockersetup.py --help and pass in more arguments...
<moto-timo>
yudjinn: I create a local dockersetup.sh script to make it aslightly easier to remember what to pass in. But the exact arguments depend on how you intended to run it and whether you are using email etc.
<yudjinn>
moto-timo: I'm just trying to spin it up locally and poke around the interface for somethings. I dont have a proxy, it defaults to localhost as the HOSTNAME, and the initial portmapping of 8080 is fine; what exactly am I missing?
<moto-timo>
yudjinn: I don't know. It works for me fine, but I do pass --hostname to the dockersetup.py script
<yudjinn>
moto-timo: of what; localhost?
<moto-timo>
yudjinn: you might need to reinstall as perhaps something in docker/settings or docker-compose.yml is out of date
<moto-timo>
yudjinn: no, I use the name of my server which is something.local in my network
<yudjinn>
moto-timo: I've reinstalled multiple times, and today is the first time I've ever cloned this repo. And I'm spinning this up locally on my device, so it doesnt have a FQDN
<moto-timo>
yudjinn: see if the following is in docker/settings.py
<moto-timo>
this is very standard modern Django growing pains... nothing layerindex-web specific
<yudjinn>
moto-timo: yep, those are in there
<yudjinn>
I mean the site mostly works; its just during login that it coughs up on this
<moto-timo>
yudjinn: like I said, it works for me locally... I test this multiple times a week. but I use mdns on my network so my HOSTNAME is not localhost
<moto-timo>
yudjinn: make sure the syntax of CSRF_TRUSTED_ORIGINS is passing in a full https:// url that is correct.. that is new in Django 4.2
<moto-timo>
yudjinn: and if it is redirecting to https://localhost you might need to pass in more than one (it is a list)
<yudjinn>
moto-timo: `CSRF_TRUSTED_ORIGINS = ['https://' + os.getenv('HOSTNAME', 'layers.test')]` I have not changed this at all
<moto-timo>
yudjinn: what EXACTLY is the CSRF error... you may need to set DEBUG = True in docker/setting.py
<yudjinn>
moto-timo: `Origin checking failed - https://localhost:8081 does not match any trusted origins.`
<moto-timo>
yudjinn: what is the output of "echo $HOSTNAME"
<yudjinn>
docker exec
<yudjinn>
oops, wrong screen, one moment
roussinm has joined #yocto
<yudjinn>
`echo $HOSTNAME` in the container returns `localhost`
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<moto-timo>
yudjinn: are you passing a --portmapping 8080:80,8081:443 to dockersetup.py?
<yudjinn>
that is the default, so no
<yudjinn>
and thats not the problem, otherwise I wouldnt be able to access the site at all
<moto-timo>
yudjinn: I'm not sure why the port is being reported by the CSRF error, that is why I am asking.
mattsm has quit [Quit: Ping timeout (120 seconds)]
jsandman has quit [Quit: Ping timeout (120 seconds)]
mattsm has joined #yocto
jsandman has joined #yocto
pbsds has quit [Quit: Ping timeout (120 seconds)]
mort has quit [Quit: Ping timeout (120 seconds)]
Lihis has quit [Quit: Quitting]
ndec has quit [Read error: Connection reset by peer]
rhadye has quit [Read error: Connection reset by peer]
smurray has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
bluelightning has quit [Read error: Connection reset by peer]
shivamurthy has quit [Read error: Connection reset by peer]
Lihis_ is now known as Lihis
wak has joined #yocto
bluelightning has joined #yocto
ardo has joined #yocto
shivamurthy has joined #yocto
mort has joined #yocto
Emantor has joined #yocto
marka has joined #yocto
khazakar has joined #yocto
nohit has joined #yocto
sugarbeet has quit [Ping timeout: 245 seconds]
abelloni has quit [Ping timeout: 245 seconds]
davidinux has quit [Ping timeout: 245 seconds]
Chaser has quit [Quit: Chaser]
abelloni has joined #yocto
davidinux has joined #yocto
sugarbeet has joined #yocto
<moto-timo>
yudjinn: ok, I replicated it locally. I'll add it to the bug list.
<moto-timo>
yudjinn: something about passing in either the --hostname or the --portmapping is affecting things in unexpected ways with the new CSRF_TRUSTED_ORIGINS "fun"
<yudjinn>
please do, what exactly is going on? do I need to pass in both the hostname and portmapping?
<vmeson>
khem, anyone: have you played with predictable network interface names? It's a small change in systemd/eudev but affects other recipes so it seems like a DISTRO_f
<vmeson>
FEATURE.
<khem>
hmm I have disabled renaming in systemd via kernel cmdline
<khem>
many apps assume i/f names
<vmeson>
khem: yeah, we'd have to fix that... haven't most distros moved to PNI ?
<JPEW>
We punted on the whole thing by make a bride interface and adding interfaces to them via udev rule matching :)
<vmeson>
JPEW: bridge interface I assume ...
<khem>
yeah well the userspace has to be cleared
<JPEW>
Ya
<JPEW>
All our apps use the bridge interface; mostly because they can't handle an interface ever being down :/
<vmeson>
(a bride interface would have higher maintenance costs! ;-) )
<yudjinn>
moto-timo: I specified hostname and portmapping `-o localhost -m 8080:80,8081:443` and still hit the same issue; is there something I can change elsewhere to make this happy?
<JPEW>
vmeson: mmm... indeed
<moto-timo>
yudjinn: as I said, I pass the name of my workstation in as --hostname, so perhaps you can try --hostname myworkstation from what you said earlier passed in to dockersettings.py
<moto-timo>
sorry dockersetup.py
<moto-timo>
probably CSRF_TRUSTED_ORIGINS is requiring a FQDN (fully qualified domain name)
<moto-timo>
not our fault, it's a Django thing
<moto-timo>
yudjinn: so I guess try localhost.localdomain?
<moto-timo>
yudjinn: meh. that doesn't work either. it will take longer to figure out the root cause for localhost
<jdiez>
it works as long as I set OEROOT = "..." in my bblayers.conf; I get an image that works and all is good. However, if I try to build the extended sdk (`bitbake core-image-minimal -c populate_sdk_ext`), the build cannot find the patch; the OEROOT variable is undefined
<yudjinn>
moto-timo: also, passing `--no-https` trying to see if that redirect was causing issues completely breaks everything and says that `localhost` is not a part of `ALLOWED_HOSTS` even when I hard set the array to include it?
<moto-timo>
yudjinn: to work around for now can you try `dockersetup.py --reinstall --hostname 101441.lan --portmapping 80:80,443:443` as this should be equivalent to what I am doing locally
<yudjinn>
moto-timo: did that, failed for me, but maybe my browser was caching stuff, lemme try again. This does work, btw: `./dockersetup.py -r -o localhost -m 8080:80,8081:443 --no-https`
<yudjinn>
moto-timo: that did work, using 80:80,443:443; I'm pretty sure the `--hostname 101441.lan --portmapping 8080:80,8081:443` didnt, though
<moto-timo>
I literally meant 80:80,443:443
<moto-timo>
my hunch is the path is getting mangled with the port somewhere in the login code which is not ours
<moto-timo>
yudjinn: somehow the POST which is what the login form does is getting mangled and it will take some time
xmn has quit [Quit: xmn]
agrue_ has quit [Ping timeout: 255 seconds]
agrue has joined #yocto
wicki has joined #yocto
starblue has joined #yocto
<yudjinn>
moto-timo: thanks for your help on this, though! I take it this celery service is how it scrapes for new data?
<moto-timo>
yudjinn: so, it turns out we need the :8081 appended to localhost in the CSRF_TRUSTED_ORIGINS... but currently the dockersetup.py script does not make that change in the docker/settings.py... in other words if you manually set `CSRF_TRUSTED_ORIGINS = ['https://' + os.getenv('HOSTNAME', 'layers.test'), 'https://localhost:8081']` it will work
jmd has quit [Remote host closed the connection]
<moto-timo>
patches welcome ;)
<moto-timo>
yudjinn: celery is a task manager... it does a few different things
<moto-timo>
yudjinn: I need to be doing other things so I should not go into detail
<moto-timo>
FWIW, I actually came across this issue earlier and I just forgot it conveniently ;) once I remembered the issue was how docker-compose.yml and dockersetup.py are interacting it jogged the old grey matter
vladest has quit [Remote host closed the connection]
<rm5248>
Is there a way to list the packages that a recipe will produce? I want to figure out what module(s) are generated from the lighttpd recipe, since I need to install some lighttpd modules
<rburton>
_will_, no
<rburton>
especially lighttpd which generates packages depending on what modules you enable
<rburton>
you can look at the value of PACKAGES to see what packages it will potentially create, but not all of those will be created. also PACKAGES_DYNAMIC is a regex that that matches dynamically created packages.
<rburton>
see the end of the lighttp recipe where it calls do_split_packages. that creates a new package for every module.
<rburton>
there's no static list as it depends on the configuration of the recipe
<rm5248>
well, at least with the list that gives me enough to look for, thanks.
<fray>
the key is this information is only available AFTER you build. You can get hints (see rbuton's comments) but they're only hints.
<rburton>
some build tools demand the package list to be static and known up front. we're more flexible.
<rm5248>
I've already built it, so knowing the modules gets me everything I need(I think)
vladest has joined #yocto
khazakar has quit [Quit: Connection closed for inactivity]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #yocto
alessioigor has quit [Quit: alessioigor]
<khem>
RP: I picked up your 4 patches regarding qemu stuff from master-next and bingo, its working great for my case, its finishing core-image-ptest-fast quicker too