qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
felixi has quit [Ping timeout: 272 seconds]
felixi has joined #yocto
<halstead>
Anyone with devtool experience willing to help me with some AB test issues?
wing0 has quit [Quit: WeeChat 3.1]
hpsy1 has quit [Ping timeout: 272 seconds]
jwillikers has quit [Remote host closed the connection]
Ad0 has quit [Ping timeout: 252 seconds]
Ad0 has joined #yocto
sakoman has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
camus has quit [Remote host closed the connection]
camus has joined #yocto
paulg has joined #yocto
amitk has joined #yocto
paulg has quit [Ping timeout: 248 seconds]
Tokamak has quit [Ping timeout: 258 seconds]
Guest48 has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
camus has quit [Remote host closed the connection]
camus1 has joined #yocto
camus1 is now known as camus
prabhakarlad has quit [Quit: Client closed]
mihai- has joined #yocto
mihai has quit [Ping timeout: 248 seconds]
Guest68 has joined #yocto
Guest68 has quit [Client Quit]
goliath has joined #yocto
fray has quit [Ping timeout: 240 seconds]
fray has joined #yocto
mihai- is now known as mihai
wing0 has joined #yocto
rob_w has joined #yocto
<mihai>
yo
leon-anavi has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
sbach has quit [Read error: Connection reset by peer]
frieder has joined #yocto
sbach has joined #yocto
frieder_ has joined #yocto
bps has joined #yocto
bps has joined #yocto
goliath has quit [Quit: SIGSEGV]
frieder_ has quit [Quit: Leaving]
zpfvo has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudX
tp43_ has joined #yocto
wing0 has quit [Quit: WeeChat 3.1]
dev1990 has quit [Quit: Konversation terminated!]
bps has quit [Ping timeout: 248 seconds]
<mihai>
if I'm using file://* in SRC_URI, should pseudo aborts surprise me? :)
<LetoThe2nd>
mihai: actually it should, yes.
<LetoThe2nd>
mihai: AIUI the pseudo aborts are mostly caused by, lets call it "unwanted/unexpected things" happening to sstate/tmp. SRC_URI should be completely unproblematic
<mihai>
I've been getting some in the last couple of days, but figured it's because of my SRC_URIs
<LetoThe2nd>
mihai: and what is so special about that SRC_URI?
<LetoThe2nd>
sounds like those are... "tricky".
<mihai>
well I vaguely remember something about staying away from it
<mihai>
but I can't remember the reason
<LetoThe2nd>
a hardcoded, constant file:// SRC_URI should be perfectly unproblematic. those must be used in thousands in oe-core alone. however, if you tried to do something "clever" there, things might be different.
<mihai>
not helping with "constant" :)
<mihai>
I did mention: file://*
<LetoThe2nd>
?
<LetoThe2nd>
ah that "*" was not a placeholder? you actually did use globbing in there?
<mihai>
yes :D
<LetoThe2nd>
go away.
<mihai>
:)))
<LetoThe2nd>
yup, thats gonna give you headaches.
<mihai>
cool
<manuel_>
Talking about file:// SRC_URIs, I'm thinking about storing the source tree of some packages directly in the meta-layer. Has anyone any hints on that?
<manuel_>
Little helper packages with just a few LOC
<LetoThe2nd>
manuel_: it can have advantages for really, really small things, like a small helper script or such, yes.
<manuel_>
I think it would make sense to tell Bitbake not to do any package versioning on them but just build them. Build doesn't take more than a few seconds anyway.
<LetoThe2nd>
manuel_: for anything that extends beyond one source file, i personally suggest to do otherwise.
<manuel_>
LetoThe2nd: Agree.
florian_kc has joined #yocto
<manuel_>
How do I tell bitbake that the package needs to be rebuilt?
<LetoThe2nd>
manuel_: and bitbake always does version your stuff. you can force rebuilds every time per recipe, but thats definitively discouraged.
<LetoThe2nd>
bitbake -c clean :)
<manuel_>
So should I bump the version part of the recipe filename everytime I change something in my source tree? Or set {PV} in the recipe?
<LetoThe2nd>
good question. however i think thats more of a philosophical question - do you really expect that script to change that often?
<manuel_>
Or can I have bitbake check the time stamp of the files in the files/ subdir next to recipe?
<LetoThe2nd>
nope, that makes the build non-deterministic. not all VCS keep timestamps.
<manuel_>
Ok I see
<manuel_>
VCS interaction is still a bit unclear to me
<manuel_>
When my recipe follows a git branch, does bitbake poke the remote repo at every build for new commits?
<manuel_>
Things like that
<LetoThe2nd>
nope. it checks if it already has the version that you have set in SRCREV. if it has, it builds. if it doesn't have, it gets that version, then builds.
<manuel_>
I see. And what if SRCREV=${AUTOREV}?
<LetoThe2nd>
for the script recipe, it *think* setting do_build as nostamp might do the trick. its not exactly pretty, but if it works well enough for the given case, then so be it.
<qschulz>
mihai: globbing does not work in SRC_URI
<qschulz>
you think it does, but it does not. do not use it
<LetoThe2nd>
AUTOREV makes it poke the repo on each build. and completely breaks determinism, as well as builds from download cache. avaoid.
<qschulz>
give a full directory to it or list every file you want to include
<mihai>
qschulz: exactly, I think it does :) ok, I'll stay away from it
<qschulz>
go for the latter if there's a chance one of the files can be overridden
<manuel_>
LetoThe2nd: Super, thanks for your insight.
<qschulz>
so... go for the latter :p
<LetoThe2nd>
manuel_: have fun
<qschulz>
mihai: basically, the most obvious issue is that file changes aren't watched, so any change to your files won't trigger a rebuild
<manuel_>
qschulz: Didn't know Bitbake does that
<qschulz>
michaelo: I just need to create commits for yocto-docs override change and I will send them
<LetoThe2nd>
manuel_: it bakes bits. isn't that obvious?!?
<qschulz>
found a thing or two to fix meanwhile (at least those I noted :) )
camus1 has joined #yocto
<qschulz>
RP: is there a place to note all variables that looks like they're using overrides but aren't?
<qschulz>
A wiki page maybe or something?
<manuel_>
LetoThe2nd: But doesn't what qschulz contradict you?
bps has joined #yocto
bps has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus1 is now known as camus
<qschulz>
I found a few more occurrences yesterday while going through the doc
<manuel_>
He said file changes are not gonna watched if SRC_URI=file://*
<manuel_>
and you said checking the timestamp of the files in files/ subdir would make the build non-deterministic
<qschulz>
manuel_: also breaks file overrides in other layers and do not fetch newer files IIRC
<LetoThe2nd>
manuel_: why would it contradict?
* mihai
feels sorry about mentioning file globbing
<manuel_>
Arent you talking about the same set of files here?
florian_kc has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
manuel_: i think thats different aspects here.
<manuel_>
recipes-test/test_1.0.0.bb and then recipes-test/files/THIS-FILES-HERE
goliath has joined #yocto
<LetoThe2nd>
but granted, its not one of the things i use on a regular basis
<LetoThe2nd>
i mean, timestamp != file content.
tp43_ has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
qschulz: this is where my knowledge gets shaky. are files that are directly referenced in SRC_URI checked for modifications? i actually don't think so, just that SRC_URI goes into the dig.
<LetoThe2nd>
s/dig/sig/
<qschulz>
LetoThe2nd: they are checked
<qschulz>
you can check with bitbake-dumpsig of the fetch task
<qschulz>
you can see a checksum per included file
<LetoThe2nd>
qschulz: they are? interesing.
<LetoThe2nd>
manuel_: in that case, please mentally eradicate my mention of nostamp quickly!
<LetoThe2nd>
qschulz: i don't look at dumpsig usually
<qschulz>
LetoThe2nd: well... it's usually what you have a look at when something should be rebuilt and isn't or the opposite
<manuel_>
Super, now it all makes sense. Thanks qschulz and LetoThe2nd!
<qschulz>
and since I had a few issues like that in my previous company, I unfortunately had to deal with it
<qschulz>
and that's how I discovered the SRC_URI globbing thing being brokenb
<LetoThe2nd>
qschulz: interesting technique. when i see something build or not build, i usually jsut start over, find me a beer and find everything done when i've finished drinking.
zeddii has quit [Ping timeout: 248 seconds]
zeddii has joined #yocto
<mihai>
LetoThe2nd: your technique sounds better :D
<LetoThe2nd>
i know. thats why i employ it.
<RP>
qschulz: we probably should start something
<LetoThe2nd>
RP: like, drinking?
<LetoThe2nd>
but on a more serious note. couldn't a glob in SRC_URI trigger a QA note?
<LetoThe2nd>
then, if somebody really really wants to use it, they would at least have to willingly skip the check and therefore be notified that it is problematic.
<qschulz>
LetoThe2nd: I think something's been done in more recent releases
<LetoThe2nd>
qschulz: ah yeah, thats a good step. but i'm thinking of going beyond that, so the build actually doesn't run until you really for it to. or what happens when i put a * into there in gatesgarth?
<qschulz>
LetoThe2nd: I haven't checked but I assume no file will be fetched
<qschulz>
LetoThe2nd: "and error to the user if they have"
<qschulz>
such urls.
<qschulz>
so... mihai... update to 3.2+ release :p
<qschulz>
and you would know this is bad :p
<LetoThe2nd>
yep
<mihai>
or backport to dunfell? :D
<LetoThe2nd>
mihai: that would be the obivous thing, but actually would break the "somewhat working" state, and such contradicts the LTS thinking.
<mihai>
right
<mihai>
true
<RP>
LetoThe2nd: doesn't it error on that now?
<RP>
ah, yes. Thought we made it do that
<qschulz>
RP: just not cherry-picked in bitbake used on Dunfell I guess
<RP>
qschulz: probably too invasive for an LTS
<LetoThe2nd>
RP: way too invasive.
<qschulz>
yeah I'm torn... it's "fixing" something that does not work
<qschulz>
but eh, if Dunfell is EOL soon, might not have to care that much about it :p
prabhakarlad has joined #yocto
<prabhakarlad>
Hi all, I am seeing the below issues when I try and build wic image
<prabhakarlad>
("The artifact that couldn't be found was %s:\n %s", 'rootfs-dir', '/builds/0/meta-rzg2/build-scripts/build/build/tmp/work/smarc_rzg2l-poky-linux/core-image-minimal/1.0-r0/rootfs')
<prabhakarlad>
any pointers for the above ? bitbake core-image-minimal works as expected.
<Guest48>
Can you post what you setup in you local.conf ?
<prabhakarlad>
# Enable multilib to support 32-bits applications.
<lukma>
RP: Maybe a bit strange question - is it also required (after bitbake override syntax) to also convert idioms like: "RDEPENDS_${PN}-devel" to "RDEPENDS:${PN}-devel" ?
<qschulz>
lukma: yes
<lukma>
qschulz: Ok thanks for the info ....
<lukma>
BTW: What was the rationale for this change? To use the C++ scope ':' operator to make the code looking more clean?
<lukma>
Or it was clumsy to use the '_' as it would look like the part of the variable name ?
<rburton>
the latter
<qschulz>
especially since some overrides could have _ in their name too
<rburton>
and overrides are arbitrary, so you might call a variable foo_bar but then bar becomes an override in a new BSP
<qschulz>
it could probably bring parsing speed improvement too, since it'll probably be a "dumb" split on : instead of trying to figure out if the _ is part of the variable/override or if it's the override separator
<qschulz>
rburton: hence why variables should be uppercase :p
<LetoThe2nd>
we should just get rid of variables altogether and rewrite everything functional style. and i'm not talking haskell, thats way too real life. maybe lisp
<LetoThe2nd>
or for the sh*** and giggles, lets go for f#, procedural extensions in cobol.
davidinux has quit [Ping timeout: 248 seconds]
<rburton>
LetoThe2nd: sounds like you want to use guix
<LetoThe2nd>
rburton: but only with hurd. otherwise its way too real life.
davidinux has joined #yocto
<lukma>
:-)
<lukma>
I would opt for having everything in python ....
<lukma>
if not - then +1 for Lisp
<lukma>
Emacs cannot be wrong .... :D
leon-anavi has quit [Quit: Leaving]
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Guest48 has quit [Quit: Client closed]
Guest48 has joined #yocto
jwillikers has joined #yocto
leon-anavi has joined #yocto
paulg has joined #yocto
<michaelo>
Hey. With the latest (master) Poky, BitBake refuses to run: ERROR: Variable PACKAGECONFIG_append_pn-qemu-system-native contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.
<marex>
michaelo: PACKAGECONFIG:append:pn-......
<marex>
michaelo: s@_@:@g
<michaelo>
Any tips for finding the code that needs fixing?
<michaelo>
marex: yes, I know, but struggling to find the bad code
<marex>
git grep ?
<michaelo>
marex: already tried, but didn't find "PACKAGECONFIG_append_pn-qemu-system-native", and even looking for "PACKAGECONFIG_append" doesn't help
<qschulz>
michaelo: local.conf or sample conf file somewhere
<lukma>
michaelo: There was some kind of script, which was supposed to facilitate the conversion ....
<qschulz>
it was discussed yesterday on this channel
Chep has joined #yocto
<michaelo>
Good idea to check my local.conf
<michaelo>
qschulz: good catch, it was a line that was left unchanged in local.conf. That's why I couldn't find it with git grep :)
<michaelo>
qschulz: thanks!
<michaelo>
lukma, marex: thanks too
<Chep>
Hi, I need some python code to fetch some sources. As I need it in several recipes, I want to create a tool for the host and use it in do_fetch functions. I tried to create a recipe mytool-native.bb and add DEPENDS_${PN} = "mytool-native" in my recipe but in do_fetch, I can't import my python code and I can't find the source code in package's sysroot or any other folder. How can I do that?
<marex>
qschulz: you beat me to it, I was also about to suggest to check bitbake -e output
<marex>
michaelo: ^
<qschulz>
marex: probably won't work since I assume this error happens during parsing, so it'll fail before bitbake -e can output anything
<qschulz>
Chep: DEPENDS = "mytool-native"
otavio_ has joined #yocto
<Chep>
qschulz: that only works when I use my tool in do_build function
<Chep>
it seems like the dependencies are not available when fetching
<qschulz>
Chep: my bad, misread. Why do you want it in the do_fetch? What are you going to do with this tool?
nerdboy_ has joined #yocto
<michaelo>
marex: right, "bitbake -e" was failing too for the same reaons
<Chep>
qschulz: I need to fetch data from an artifactory server
<Chep>
and use its api
nerdboy has quit [Ping timeout: 258 seconds]
<LetoThe2nd>
Chep: sounds more like you want to write a custom fetcher for it.
<Chep>
LetoThe2nd: exactly
<LetoThe2nd>
Chep: but then you're on the wrong track. custom fetchers are not supposed to be implemented in the recipes per so, but to be triggered by the SRC_URI. something like "artifactory://xxxxx"
<qschulz>
Chep: lib/bb/fetch2 in bitbake git repo to check how fetchers are done :)
<LetoThe2nd>
Chep: i think you can look at examples for custom fetchers in layers that bring language support, like rust or scala
<Chep>
thanks
<Chep>
that sounds great
<Chep>
And can I tell bitbake that the fetcher is in my layer?
<LetoThe2nd>
Chep: like i said, take a look at such a layer
rob_w has quit [Remote host closed the connection]
sakoman has joined #yocto
leon-anavi has quit [Quit: Leaving]
xmn has joined #yocto
flynn378 has joined #yocto
leon-anavi has joined #yocto
xmn has quit [Ping timeout: 276 seconds]
vd has joined #yocto
Fulgo has joined #yocto
<Fulgo>
Hello everyone. I am working on a minimal YOCTO image. This image is basically the core-image-minimal. The point here is that after analyzing the build history, I am noticing that udev-hwdb is pretty big (6664 KiB). I am doing some research and I found out I can disable it by using BAD_RECOMMENDATIONS += "udev-hwdb", but I did not found any
<Fulgo>
resource explaining if I can reduce its size without removing it or what impact can cause if it is removed. Thanks in advance.
<Fulgo>
All the resources I found speaks about how to update the hwdb, that it is a key value database and that it is used by udev, but I have no clue about if it is interesing to have it, if it impacts on the performance.... :/
<qschulz>
Fulgo: FWIW, my previous company removed it and the product was working just fine
<JPEW>
Fulgo: IIRC it might affect what tags udev adds to a device and thus might prevent something like and input device from being handled properly
<Fulgo>
I have seen how other people use it for key remapping
<JPEW>
Fulgo: Ya it probably can do that too. If you have a closed set of devices you need it to support and you've validated they all work, it's probably optional.
<Fulgo>
The problem is that compared to the other packages this is pretty big, and for sure most part of the hwdb is not being used. So, I was wondering if it is possible to reduce it (how to do it could be a secret :/ ) or just to disable it
<JPEW>
but, if you need to for example, "support any USB input device the user might plug in" than you want it
<rburton>
you can likely delete chunks if you know you'll never need them
* rfs613
nods
<rburton>
like all the mouse/touchpad stuff if you know you're not going to plug in input devices
<Fulgo>
Yes, I see somethin in /sources/poky/meta/recipes-core/systemd/systemd_244.3.bb
<Fulgo>
So, it is not recommended that I remove it XD
<rburton>
depends on your use case really
<JPEW>
Just depends on the requirements you have. I would not remove it if the user is allowed to plug in arbitrary USB devices and have them "work"
<JPEW>
Or any device (not just USB) for that matter
<Fulgo>
Ok. The requirements are minimal, so I should not require any of this. But what really worries me is that there should be a way of managing what should be in the database
<qschulz>
or devices that are already on the system but whose drivers are modules and can be probed later for example
xmn has joined #yocto
<Fulgo>
Ok... But nobody knows if it is possible to customize those databases as the image is created or how this is usually handled
<rburton>
i believe its not usually customised
<Fulgo>
At least there is no info about it
<rfs613>
Fulgo: well, take the 70-mouse.hwdb for example... primarily it contains the DPI settings for a few hundred different mice, identified by their vid/pid numeric codes. Would you want to manually enable/disable each one of these, just to reduce the database size a bit? On most desktop systems where this gets used, the driver is gigabytes, so the database is insignificant.
<Fulgo>
It is just commented that it is a database but nothing elase
<rfs613>
s/driver/disk drive/
mattsm has quit [Read error: Connection reset by peer]
<Fulgo>
rfs613 yes, that is true. I know they are about 7MB, but when you need a minimal rootfs... every byte counts. Obviosly, if the effort required is insane, I discard the idea
mattsm has joined #yocto
<rfs613>
on an embedded system where storage space is much more constrained, you usually don't have anywhere as wide of a range of devices that might be plugged in, so you can just skip the database entirely in most cases. For mouse it will just mean the sensitivity (DPI) may be wrong.
<Fulgo>
But it could be something like the kernel: enable/disable for example the suppor for the mouses, and that is all XD
<LetoThe2nd>
Fulgo: send patches :)
<rfs613>
There's a similar problem for kernel device drivers... do you fine-tune the configuration to have just the drivers you need, or do you build them all (or most of them) and accept the extra space it takes up? These days most people seem to take the 2nd option.
<Fulgo>
For a desktop image ok, but for an embedded one... It should be the smaller the better
<LetoThe2nd>
Fulgo: you're essentially doing the learning stage "anybody can build a raspi image with 500MB to run some script. but to make a real, productizable thing, it requires knowledge and effort"
<Fulgo>
Obviosly, after analyzing this, the next step will be.... attacking the kernel XD
<LetoThe2nd>
and most of us have been there some time too
<Fulgo>
I agree with you LetoThe2nd. But normally, people learns from documentation or others work, to invent something new is pretty hard, that is why I am asking
<Fulgo>
I am just trying to learn and only after doing some research I ask :(
<Fulgo>
But if the official documentation says that it is a database and no much more... It does not even say about what happend if the udev-hwdb is disabled.
<LetoThe2nd>
Fulgo: those are areas where most people do not easily ahre with outsiders anymore, as it is often considered internal knowhow, i'm sorry.
<Fulgo>
Understood :( sorry for asking then
fury has left #yocto [#yocto]
<LetoThe2nd>
no need to be sorry, its good to ask. just explaining why documentation is rare then. if more people would *really* care about it, they could become YP members, invest money and say "hey, this is what we want and care about".
<LetoThe2nd>
as long as that doesn't happen... it will stay the way it is.
<Fulgo>
Ok
<Fulgo>
It is matter of money then XD
<qschulz>
Also, size and boot time reduction heavily depends on your platform, the devices that are connected to it, your rootfs, the app you're running on it, etc...
<qschulz>
there's no "one size fit all"
goliath has quit [Quit: SIGSEGV]
<Fulgo>
Yes. If the product has those constraints, they are hard to handle also, qschulz
<Fulgo>
But nothing about this in the Mastering embedded Linux programming 3rd edition book XD
<Fulgo>
But LetoThe2nd just to know if it is possible or not, or if it makes sense... the udev-hwdb should be reduced or disabled? I guess this is not an answer with copyright :P
<Fulgo>
I do not want to take part in the Infinite Wars :/
roussinm has joined #yocto
Tokamak has joined #yocto
<rfs613>
Fulgo: the title of that book is misleading... I've been doing embedded linux for at least 25 years, and I'm still nowhere near "mastering" it ;-)
<Fulgo>
Hahaha, I am jokin meeen XD
<rfs613>
Me too (but I really have been using Linux that long, mostly embedded...)
bps has quit [Ping timeout: 248 seconds]
<rfs613>
the point is you can never master it, there's just too much, and it all keeps changing...
<Fulgo>
I am more focused on bare metal or using RTOS, but with YOCTO I am suffering a bit XD
<Fulgo>
Yes, I agree
<Fulgo>
I think I understand how to do it anyway. Easy peasy lemon squeezy
<Fulgo>
And there are not so much things to remove. It is just to decide what to put from the sources downloaded. That is all. If you do not need usb keyboards... OUT XD. That is all
<rfs613>
btw have you looked at how big all the systemd stuff is? If your needs are modest, and you want a smaller image, I'd suggest trying good old sysvinit instead.
<Fulgo>
Yes, but the list of mice for example, it is all gathered in one file. If you are not going to connect a mouse, do not include 70-mouse.hwdb and that is all
<rfs613>
exactly!
<Fulgo>
You can do it with a bbappend of the recipe that is on charge of doing that
<Fulgo>
Nothing else
<Fulgo>
Easier than I thought
ant__ has joined #yocto
Tokamak has quit [Ping timeout: 258 seconds]
Tokamak has joined #yocto
<qschulz>
also, might want to use mdev if your size constraint is extreme. and yes, sysv vs systemd is a good choice when size's involved
xmn has quit [Quit: ZZZzzz…]
aleblanc has joined #yocto
xmn has joined #yocto
sakoman has quit [Read error: Connection reset by peer]
zpfvo has quit [Remote host closed the connection]
* paulg
idly wonders how we'd ever know if anyone is using yaffs2 in Yocto vs. an "in mainline" fs solution...
<ant__>
"a choice between mainlining it and not continuing to make a living"
<ant__>
project dead :/
<ant__>
see, for these legacy linux devices ubifs was already a gigantc leap
sakoman has joined #yocto
<paulg>
I kinda was finding myself thinking in the same direction, but I'm always one to lean towards cutting bait and moving on ; even on crap I've written myself.
florian has quit [Quit: Ex-Chat]
Fulgo has quit [Quit: Client closed]
xmn has quit [Ping timeout: 245 seconds]
<marex>
paulg: yaffs is yet another forgotten file system ?
goliath has joined #yocto
xmn has joined #yocto
<ant__>
marex: nasty
<ant__>
marex: you are still guilty, you should have ported u-boot to pxa Z at least
<ant__>
I had to spend 10yrs on kexecboot to circumvent your lazyness :)
<ant__>
..but I learned a lot about MTD, thanks !
frieder has quit [Remote host closed the connection]
<paulg>
I'd eye any unqualified context free autobuilder link with suspicion. Smells like work.
* paulg
had no idea we had a connection cache.
<RP>
paulg: rburton has broken the build with patches
nerdboy_ is now known as nerdboy
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<paulg>
RP, see? I knew it smelled like a to-do work item.
<paulg>
Check-in and run is a time honoured tradition.
<RP>
paulg: patches aren't merged, I can just reject ;-)
perdmann has quit [Quit: leaving]
florian_kc has joined #yocto
<RP>
rburton: I have a fix on the branch for it
<tlwoerner>
is there a wiki page or blog post on how to integrate the sanitizers into a yocto build? i'm guessing there's a simple flag we can enable in a recipe file or local.conf?
<RP>
tlwoerner: I think you may get to write it!
<tlwoerner>
w00t!
<LetoThe2nd>
hand sanitizers?
amitk has quit [Ping timeout: 248 seconds]
florian_kc has quit [Ping timeout: 268 seconds]
<paulg>
tlwoerner, be careful - RP will draw you in and *then* tell you they have to be alcohol-free.
<tlwoerner>
he just wants what's best for the project, so if that means alcohol-free sanitizers, then so be it!
goliath has quit [Quit: SIGSEGV]
florian_kc has joined #yocto
<Xagen_>
i'm really at the end of my investigative path with this error i'm seeing in Toaster
<Xagen_>
the packages that it's complaining about at the end are built
<Xagen_>
but it doesn't find them
<Xagen_>
i can't seem to figure out how to fix this
Xagen_ is now known as Xagen
tp43_ has joined #yocto
<rburton>
RP: damnit!
florian_kc has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
Tokamak has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
goliath has joined #yocto
jmiehe has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has quit [Read error: Connection reset by peer]
tp43_ has quit [Ping timeout: 272 seconds]
florian_kc has quit [Ping timeout: 268 seconds]
Tokamak has joined #yocto
<vmeson>
Xagen: what branch / commit-id is that? Can you reproduce it with poky ? How about outside of toaster ?
<RP>
paulg: its nearly as if you're thinking of some past trauma? :)
<vmeson>
Xagen: I'm going to break for dinner but will likely check later. We're short on people to fix YP bugs but if you open a defect in the YP bugzilla, someone might look at it.
<paulg>
well, trying to hack on the fetcher is pretty traumatic ; I don't care who you are.