<rburton>
just rebuilding now, obviously new gcc needs to build
<RP>
rburton: these changes are painful, yes :(
<RP>
rburton: oh, which filesystem btw?
<rburton>
ext4
<RP>
same here
<RP>
rburton: relatime ?
<rburton>
/dev/md0 on /yocto type ext4 (rw,relatime,stripe=256)
<RP>
/dev/sdc1 on /media/build1 type ext4 (rw,relatime,errors=remount-ro)
<RP>
rburton: I changed the SDE code so I've a heavy rebuild going too
<rburton>
heading to the office, gcc will be well done when i've arrived
warthog9 has quit [Remote host closed the connection]
<LetoThe2nd>
rburton: moving from kitchen to basement, or what? ;-)
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
warthog9 has joined #yocto
<RP>
rburton: SDE change fixes it. 2 minute difference in SDE
<RP>
rburton: just worried about why you can't reproduce or why my patch exposes it
perdmann has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
perdmann has joined #yocto
<glembo[m]>
I know the option `do_compile[nostamp] = "1"` . Is there a more elegant way to only rebuild a recipe when another has been updated?
<ptsneves>
@glembo DEPENDS = "<the recipe you want to depend on">
<glembo[m]>
So easy?
<qschulz>
glembo[m]: any dependency triggers a rebuild
<qschulz>
if you need a recipe to be rebuilt if another is rebuilt, this means there is a dependency somewhere that needs to be explicit
<qschulz>
usually that is through DEPENDS or RDEPENDS (depending when you need this depedendency, build time or runtime)
<qschulz>
glembo[m]: what exactly is the relationship between the two recipes?
barometz has quit [Quit: you can't fire me!]
barometz has joined #yocto
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
perdmann has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
perdmann has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
<rburton>
LetoThe2nd: the actual office, madness i know
<rburton>
glembo[m]: nostamp=1 means "don't look at the task stamps to decide if this recipe needs to be rebuild, always rebuild if asked", so I suspect doesn't do what you think
<rburton>
RP: can't make it break with current master-next, no...
xmn has quit [Ping timeout: 240 seconds]
perdmann has quit [Ping timeout: 276 seconds]
perdmann has joined #yocto
<rburton>
RP: my sde.txt is the same as yours
<RP>
rburton: I just came up with a theory that it was finding source files it wasn't prior to my patch
<RP>
rburton: but if you can't reproduce :/
<RP>
rburton: does usr/src/ in the package/ directory contain scan.c ?
<vmeson>
RP quote: "We were running on a satellite around Mars, too." :-)
<JPEW>
Ya, I saw that article too. Very cool
perdmann has joined #yocto
<ptsneves>
"Windows Subsystem Linux (WSL) is built by Yocto Project," Wow did not know
<RP>
vmeson: heh
mckoan|away is now known as mckoan
<mckoan>
ptsneves: Yocto Project is ubiquitous !
<ptsneves>
@mckoan, indeed. It is heartwarming though :)
Guest27 has quit [Remote host closed the connection]
<ptsneves>
a lot more press goes to more front end things and i find myself not knowing how to tell lay people what a build system is
Guest27 has joined #yocto
<ptsneves>
i resorted to say i am work in something that assembles software from several parts just like hardware is assembled in factories. People get factories
perdmann has quit [Ping timeout: 272 seconds]
Schlumpf has quit [Ping timeout: 252 seconds]
perdmann has joined #yocto
zpfvo has quit [Read error: Connection reset by peer]
<jonmason>
vmeson: I need some help with rust-cross.inc. It's not compiling for qemuamv5 :(
<jonmason>
I _think_ it is trivial to fix, but I don't understand fully how this file is doing things and need a little hand holding
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
<jonmason>
on a different note, qemuriscv32 sato builds are failing in gdk-pixbuf-2.42.8-r0. If anyone cares, I can link them to a failure but it is 100% reproducible
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
Tokamak has quit [Ping timeout: 244 seconds]
GNUmoon has joined #yocto
<RP>
jonmason: do the patches for rust in master-next change anything?
Tokamak has joined #yocto
<jonmason>
RP: let me check
seninha has joined #yocto
* RP
realises there is another debug source issue with relative patsh
<jonmason>
vmeson: is it as simple as adding that to match the other entries in the inc file?
<vmeson>
jonmason: I guess you could open a defect and I could have someone take a look but it would seem to me that depending on the problem, one of our co-workers might be required to help.
<vmeson>
jonmason: I don't know off-hand. It's not a target arch that I use or support.
<jonmason>
vmeson: I'll try the trivial change and see if it magically works
<vmeson>
jonmason: sure, let me know if it works
<jonmason>
vmeson, RP: master-next seems to have it working (just took forever for it to build and test). So, disregard
xmn has joined #yocto
<jonmason>
seeing if qemuriscv32 is working now
<vmeson>
jonmason: okay. thanks.
<RP>
jonmason: that is helpful as it means I should probably merge those patches even if things are still totally wrong
perdmann has quit [Ping timeout: 260 seconds]
<jonmason>
qemuarmv5 with sato passed the minimal testimage, if that helps at all
<jonmason>
I should probably expand my testimage to actually cover more stuff, but just add all the X stuff seemed to make everything unhappy for me :)
perdmann has joined #yocto
<jonmason>
RP: I'm in favor or master-next being pushed, as meta-arm needs a patch in there to be green again :)
<jonmason>
then I can add the default sato testing to our CI and be green-er
<jonmason>
I mean, with the energy usage of the CI, less green...but you get the idea
<RP>
jonmason: the rust stuff is still broken, the requests to backport it will come in and nobody will actually sort the rust recipes out properly :/
Tokamak has quit [Ping timeout: 255 seconds]
* RP
is trying to work that out locally but it is eating days of time
Tokamak has joined #yocto
zpfvo has joined #yocto
<jonmason>
RP: I can verify the first patch in master-next is the magical one, if you want (as that looks like it's the one I need)
<RP>
jonmason: it will only be one of two there and that isn't really my point :/
<RP>
jonmason: only one of them has arm bits in
denisoft81 has quit [Quit: Leaving]
<jonmason>
RP: I understand your point, but not much I can do to help with it
<RP>
jonmason: I've been waiting for many months for someone to sort the rust issues. Nobody is going to are they? :(
<RP>
to be fair I don't know how to sort them so perhaps I shouldn't expect anyone else to either :/
<RP>
jonmason: I'm just depressed since I don't know how we get out of this
<jonmason>
I tried asking Ross for help and he told me to ask Randy :)
<zeddii>
yah. I had sync'd the version to avoid the other error. but if now it doesn't like the matching version. I'll just have to do the fork, with rconflicting packages and hope it all works out :)
<rburton>
zeddii: why does meta-virt have a recipe at all?
<rburton>
LetoThe2nd: siemens have something that does both
<RP>
zeddii: I think I found the magic to make userspace match the kernel pain
<zeddii>
oh ? I was just pondering that!
jmiehe has quit [Quit: jmiehe]
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
seninha has quit [Quit: Leaving]
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
<vvn>
is there a way to inject the image name/version into the rootfs?
perdmann has quit [Ping timeout: 276 seconds]
<JPEW>
vnn: Set the BUILDNAME variable and it will show up in /etc/version
<JPEW>
^^ vvn
perdmann has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
jmiehe has joined #yocto
vladest has joined #yocto
florian_kc has joined #yocto
Dracos-Carazza has quit [Ping timeout: 244 seconds]
Dracos-Carazza has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
<vvn>
JPEW: thanks
ram54 has joined #yocto
perdmann has quit [Ping timeout: 260 seconds]
perdmann has joined #yocto
<ram54>
Hi all, I'm trying to read a netrc file for passing to the internal server location mentioned under SOURCE_MIRROR_URL. How do I read the netrc file from the recipe?
silbe has quit [Ping timeout: 276 seconds]
nsbdfl has joined #yocto
pabigot has quit [Remote host closed the connection]
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
pabigot has joined #yocto
fitzsim has quit [Remote host closed the connection]
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
ram54 has quit [Quit: Ping timeout (120 seconds)]
perdmann has quit [Ping timeout: 255 seconds]
perdmann has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
perdmann has quit [Ping timeout: 268 seconds]
<khem>
Short answer is - you dont
<khem>
SOURCE_MIRROR_URL is set explicitly in config metadata