Monday, 2021-02-22

*** hpsy <hpsy!~hpsy@> has quit IRC00:00
*** minimaxwell <minimaxwell!> has quit IRC00:06
*** minimaxwell <minimaxwell!> has joined #yocto00:08
*** fray <fray!> has quit IRC00:10
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto00:16
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC00:51
*** kpo <kpo!> has quit IRC00:51
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto00:52
*** kpo <kpo!> has joined #yocto00:52
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC01:21
*** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:9c1d:445e:2303:5fc6> has joined #yocto01:34
*** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:9c1d:445e:2303:5fc6> has joined #yocto01:34
*** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:9c1d:445e:2303:5fc6> has quit IRC01:42
*** blauskaerm <blauskaerm!blauskaerm@gateway/vpn/mullvad/blauskaerm> has quit IRC01:51
*** blauskaerm <blauskaerm!blauskaerm@gateway/vpn/mullvad/blauskaerm> has joined #yocto01:53
*** kpo_ <kpo_!> has quit IRC01:55
JPEWRP: We can run diffoscope on local files if that would help02:00
JPEWRP: Yes, our concept of "reproducible" is a little stricter than in some ways, so we end up with a few gnarly things. I suspect they are mostly path related patches?02:01
*** blauskaerm <blauskaerm!blauskaerm@gateway/vpn/mullvad/blauskaerm> has quit IRC02:02
*** blauskaerm <blauskaerm!blauskaerm@gateway/vpn/mullvad/blauskaerm> has joined #yocto02:04
*** fray <fray!> has joined #yocto02:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:12
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:7916:53ac:39bb:e34c> has joined #yocto02:43
*** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:7916:53ac:39bb:e34c> has quit IRC02:48
*** sakoman <sakoman!> has quit IRC02:51
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto02:52
*** aquijoule__ <aquijoule__!> has joined #yocto03:00
*** aquijoule_ <aquijoule_!> has quit IRC03:02
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC03:04
*** ahadi <ahadi!~ahadi@> has quit IRC03:05
*** ahadi <ahadi!~ahadi@> has joined #yocto03:08
*** camus <camus!~Instantbi@> has joined #yocto03:12
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto03:13
*** kaspter <kaspter!~Instantbi@> has quit IRC03:14
*** camus is now known as kaspter03:14
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:e5db:d652:2b6d:d298> has joined #yocto03:18
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC03:21
khemzeddii:  I have updated the patch at now keyboard/mouse work too03:52
zeddiiI can have a look at it on Monday.  I'll pull in the config, and let you know.03:54
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto04:02
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC04:21
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto04:29
*** goliath <goliath!> has quit IRC04:35
*** Kyubi <Kyubi!~Kyubi@> has quit IRC04:52
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC04:54
*** goliath <goliath!> has joined #yocto05:01
*** wooosaiii <wooosaiii!> has joined #yocto05:01
*** wooosaii <wooosaii!> has quit IRC05:03
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto05:09
*** linums <linums!~linums@> has quit IRC05:35
*** linums <linums!> has joined #yocto05:35
*** sbach <sbach!~sbachmatr@> has joined #yocto05:36
*** linums <linums!> has quit IRC05:56
*** jobroe <jobroe!> has joined #yocto05:56
*** linums <linums!~linums@> has joined #yocto05:57
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:a821:120d:f822:bb01> has joined #yocto06:20
*** linums <linums!~linums@> has quit IRC06:34
*** linums <linums!> has joined #yocto06:36
*** linums <linums!> has quit IRC06:39
*** linums <linums!~linums@> has joined #yocto06:40
*** AndersD <AndersD!> has joined #yocto06:45
*** beneth` <beneth`!> has joined #yocto06:45
*** AndersD_ <AndersD_!> has joined #yocto06:47
*** AndersD <AndersD!> has quit IRC06:49
*** agust <agust!> has joined #yocto06:55
*** w00die_ <w00die_!~w00die@> has quit IRC07:01
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:02
*** w00die_ <w00die_!~w00die@> has joined #yocto07:04
*** jobroe <jobroe!> has quit IRC07:07
*** jobroe <jobroe!> has joined #yocto07:11
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:17
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:42
*** thekappe <thekappe!c65a42b1@> has joined #yocto07:46
*** jobroe <jobroe!> has quit IRC07:49
*** camus <camus!~Instantbi@> has joined #yocto07:53
LetoThe2ndyo dudX07:53
*** kaspter <kaspter!~Instantbi@> has quit IRC07:54
*** camus is now known as kaspter07:54
*** dleppich <dleppich!~Thunderbi@> has joined #yocto07:56
*** fl0v0 <fl0v0!> has joined #yocto07:57
*** xroumegue <xroumegue!~roumegue@2a01:cb1d:3f5:3900:d0b5:57c9:f681:d61f> has quit IRC07:58
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:58
*** jobroe <jobroe!> has joined #yocto08:01
*** aquijoule__ <aquijoule__!> has quit IRC08:02
*** mckoan|away is now known as mckoan08:03
*** xroumegue <xroumegue!~roumegue@2a01:cb1d:3f5:3900:fd88:2eb2:8463:8658> has joined #yocto08:09
* mckoan is preparing for a YP training week08:10
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:16
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8e1:8c0f:8c00:9696> has quit IRC08:18
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8e1:8c0f:8c00:9696> has joined #yocto08:22
thekappehello guys !08:24
thekappewhich is the best place to put some entries in /etc/modprobe.d ? Is it the kernel recipe ?08:25
*** kyanres <kyanres!> has joined #yocto08:30
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:46e1:3435:9ae8:d4e> has joined #yocto08:38
*** mbulut <mbulut!> has joined #yocto08:43
*** gillesm <gillesm!> has joined #yocto08:57
mbulutgood morning gents, is anyone aware of a global bitbake flag similar to gcc's -Werror ?08:58
gillesmhello when I add user in local.conf I relaunch bitbake core-image-base but it doesn't regenerate  image wic.bz208:59
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC08:59
mbulutwe want our daily build pipeline to fail if the yocto build spits out any warnings during the whole build09:00
*** zeddii <zeddii!> has quit IRC09:03
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:e5db:d652:2b6d:d298> has quit IRC09:03
*** zeddii <zeddii!> has joined #yocto09:06
*** Bunio_FH <Bunio_FH!> has joined #yocto09:12
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto09:12
*** Bunio_FH <Bunio_FH!> has quit IRC09:18
*** Bunio_FH <Bunio_FH!> has joined #yocto09:18
RPmbulut: I'm not sure there is one. If you look at the code in lib/bb/ui/ at the end, the "if warnings", it would be easy to add though09:26
RPmckoan: have fun! :)09:27
*** Bunio_FH1 <Bunio_FH1!> has joined #yocto09:30
*** Bunio_FH <Bunio_FH!> has quit IRC09:30
LetoThe2ndgillesm: "when i add user"?09:30
*** Bunio_FH1 <Bunio_FH1!> has quit IRC09:39
*** Bunio_FH <Bunio_FH!> has joined #yocto09:39
*** Bunio_FH <Bunio_FH!> has joined #yocto09:40
*** yannholo <yannholo!> has joined #yocto09:44
*** Bunio_FH <Bunio_FH!> has quit IRC09:44
*** Bunio_FH <Bunio_FH!> has joined #yocto09:45
gillesmLetoThe2nd, yes or when I customize the image without compilation need ...09:53
gillesmbut with image regeneration need09:53
LetoThe2ndgillesm: well i guess you're messing up yocto chant #1. recipe data is local, config data is global.09:54
LetoThe2ndgillesm: so: users shall be added through recipes. there are examples for that, start with those. and: an image recipe cannot affect other recipes, hence the "customization" might or might not work as you expect.09:55
gillesmmy question is how can I regnerate the image ?09:56
LetoThe2ndgillesm: bitbake image :)09:56
LetoThe2ndgillesm: if that does not trigger the rebuild, then you've done something wrong.09:56
gillesmit doesnt generae wic.nz2 ...09:56
LetoThe2ndthen find out why it doesn't.09:57
RPgillesm: what exactly are you changing to add this user?09:57
gillesmthe local.conf file09:57
RPgillesm: right, but how, which variables?09:57
gillesmINHERIT += "extrausers"09:59
gillesmEXTRA_USERS_PARAMS += "useradd  -P totototo  guest;"09:59
LetoThe2ndgillesm: see
*** Bunio_FH <Bunio_FH!> has quit IRC09:59
*** Bunio_FH <Bunio_FH!> has joined #yocto09:59
gillesmok I understand .. I need to make a receipe...10:01
*** Bunio_FH <Bunio_FH!> has quit IRC10:01
*** hpsy <hpsy!~hpsy@> has joined #yocto10:01
*** Bunio_FH <Bunio_FH!> has joined #yocto10:04
* LetoThe2nd resists the urge to give the nervous look and say "Where?"10:05
*** Bunio_FH <Bunio_FH!> has quit IRC10:05
*** Bunio_FH <Bunio_FH!> has joined #yocto10:05
*** Bunio_FH <Bunio_FH!> has quit IRC10:09
*** Bunio_FH <Bunio_FH!> has joined #yocto10:09
mbulutRP: thx!10:13
*** Bunio_FH <Bunio_FH!> has quit IRC10:16
*** hpsy <hpsy!~hpsy@> has quit IRC10:19
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC10:20
*** Bunio_FH <Bunio_FH!> has joined #yocto10:21
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto10:30
dl9pfRP: looking ... haven't see that one yet in my builds. Reading the recipes nothing catches my eye.10:31
*** kpo <kpo!> has quit IRC10:33
RPdl9pf: I don't understand the warnings, its very strange10:37
*** kpo <kpo!> has joined #yocto10:37
dl9pfok, will try a build for these two packages10:39
*** camus <camus!~Instantbi@> has joined #yocto10:40
*** kaspter <kaspter!~Instantbi@> has quit IRC10:40
*** camus is now known as kaspter10:40
*** Bunio_FH <Bunio_FH!> has quit IRC10:41
*** Bunio_FH <Bunio_FH!> has joined #yocto10:41
RPdl9pf: I'm seeing locally with different recipes :(10:45
RPtexinfo-dummy-native, gettext-minimal-native, base-files, dwarfsrcfiles, initscripts, shadow-sysroot, shadow-securetty10:45
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto10:46
dl9pfhmm, thats random.10:46
*** Bunio_FH <Bunio_FH!> has quit IRC10:47
*** Bunio_FH <Bunio_FH!> has joined #yocto10:47
*** camus <camus!~Instantbi@> has joined #yocto10:49
*** kaspter <kaspter!~Instantbi@> has quit IRC10:49
*** camus is now known as kaspter10:49
*** ptsneves <ptsneves!b0dd7824@> has quit IRC10:51
*** Bunio_FH <Bunio_FH!> has quit IRC10:53
*** Bunio_FH <Bunio_FH!> has joined #yocto10:53
LetoThe2nddl9pf: you mean 4?10:54
dl9pf42 actually10:55
LetoThe2nd*nope, even. see:
*** Bunio_FH <Bunio_FH!> has quit IRC10:58
*** Bunio_FH <Bunio_FH!> has joined #yocto10:58
*** Bunio_FH <Bunio_FH!> has quit IRC11:03
*** sno <sno!> has quit IRC11:03
*** Bunio_FH <Bunio_FH!> has joined #yocto11:04
*** minimaxwell <minimaxwell!> has quit IRC11:09
*** Bunio_FH <Bunio_FH!> has quit IRC11:12
*** minimaxwell <minimaxwell!> has joined #yocto11:35
*** Bunio_FH <Bunio_FH!> has joined #yocto11:39
*** mckoan is now known as mckoan|away11:39
*** Bunio_FH <Bunio_FH!> has quit IRC11:43
*** Bunio_FH <Bunio_FH!> has joined #yocto11:44
*** Bunio_FH <Bunio_FH!> has quit IRC11:47
*** Bunio_FH <Bunio_FH!> has joined #yocto11:47
*** thekappe <thekappe!c65a42b1@> has quit IRC11:47
*** dreyna <dreyna!> has joined #yocto11:59
*** dreyna <dreyna!> has quit IRC12:04
RPJust when you think you've fixed a reproducibility issue, it turns out there is more than one :(12:09
*** mattsm <mattsm!> has quit IRC12:10
*** mattsm <mattsm!> has joined #yocto12:11
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC12:12
*** minimaxwell <minimaxwell!> has quit IRC12:17
LetoThe2ndRP: believe it or not, i'm currently kind of getting hooked on TDD12:19
RPLetoThe2nd: the game?12:20
LetoThe2ndRP: Test Driven Development12:20
LetoThe2ndRP: btw, current cpu availability crazyness: had to order 2x7752s for build server instead of 2x7702s12:22
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto12:22
*** wooosaiii <wooosaiii!> has quit IRC12:23
RPLetoThe2nd: the testing stuff does make a big difference after a while12:23
RPLetoThe2nd: nice cpus :)12:24
LetoThe2ndRP: yeah hopefully. the problem with the approaches that the cool kids use these days are though that they require a somewhat short round trip12:24
*** minimaxwell <minimaxwell!> has joined #yocto12:37
*** Bunio_FH <Bunio_FH!> has quit IRC12:42
*** minimaxwell <minimaxwell!> has quit IRC12:43
*** minimaxwell <minimaxwell!> has joined #yocto12:45
*** sno <sno!> has joined #yocto12:46
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:46
*** bps <bps!> has joined #yocto12:47
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto12:55
*** Bunio_FH <Bunio_FH!> has joined #yocto13:03
*** Bunio_FH <Bunio_FH!> has quit IRC13:04
*** hpsy <hpsy!~hpsy@> has joined #yocto13:06
*** camus <camus!~Instantbi@> has joined #yocto13:09
*** kaspter <kaspter!~Instantbi@> has quit IRC13:11
*** camus is now known as kaspter13:11
*** aleblanc <aleblanc!> has joined #yocto13:19
*** linums <linums!~linums@> has quit IRC13:27
*** linums <linums!> has joined #yocto13:27
*** linums <linums!> has quit IRC13:40
*** linums <linums!> has joined #yocto13:43
*** oberstet <oberstet!~oberstet@> has joined #yocto13:44
*** sakoman <sakoman!> has joined #yocto13:56
rburtonwoop woop13:58
RPdl9pf: I have partial insight into that warning,  bb.warn("SOURCE_DATE_EPOCH value from sstate '%s' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '%s'" % (s, SOURCE_DATE_EPOCH_FALLBACK))13:59
RPdl9pf: "NameError: name 'SOURCE_DATE_EPOCH_FALLBACK' is not defined" is definitely true there, there is a bug in that line13:59
RPrburton: nice :)13:59
rburtonmad props to dorinda for getting debuginfod to work14:00
RPrburton: looking forward to seeing it in action!14:00
RPdorinda: nice work!14:00
LetoThe2nddorinda: \m/14:00
rburton a couple of PACKAGECONFIG tweaks and DEBUGINFO_URLS= in local.conf and your qemu will automatically grab the symbols from the host14:00
smurrayvery nice14:00
dorinda:) thank you all, with great support from Ross.14:01
rburtonProof that it worked
RPrburton: experimental feature for 3.3? :)14:02
rburtonyeah should be able to land the last few bits14:02
dl9pfRP: aah ... d.getVar missing ...14:03
dl9pfyou read that 10 times and don't see the issue14:04
LetoThe2nddl9pf: nah never happend to me. i can't read.14:05
RPdl9pf: indeed, I was trying to trace back the code until I realised14:06
RPdl9pf: of course the question next is why is SDE 0 for those recipes14:10
RPdl9pf: but at least that is a more specific question14:10
RPdl9pf: looks like the SDE file is coming from sstate so perhaps its a cache invalidation issue14:12
dl9pfRP: the SDE 0 is b/c the SDE txt file was retrieved from existing sstate-cache with 014:14
dl9pfwe either need to invalidate (essentially all old sstate) or replace the 014:15
RPdl9pf: I'm wondering why we don't see more sstate coming in like that14:16
dl9pfgood question14:16
dl9pfi don't know the answer14:16
dl9pfi expected it to be a lot when using the AB sstate ... thus the replacement, b/c we might not want to invalidate all sstate (or at least that task).14:17
jonesv[m]Can I .bbappend a recipe that is already .bbappended by somebody else? Or is it undefined behavior? Say my bsp uses yocto-linux by appending it, and in my image layer I want to .bbappend it again, e.g. to set `KERNEL_MODULE_AUTOLOAD`. Can I do that?14:17
LetoThe2ndjonesv[m]: you can do multiple appends.14:18
RPjonesv[m]: appends stack in a defined order14:18
LetoThe2ndRP: ... which kind of leaves out the fun.14:18
RPLetoThe2nd: we can do without that kind of fun ;-)14:18
* RP remembers the build determinism issues based on order of files on disk14:19
LetoThe2ndRP: hum, if your build is deterministic even with randomized append order then its a sign of properly laid out metadata. lets do this!14:19
jonesv[m]How is the order defined?14:23
JPEWRP, dl9pf IIRC SOURCE_DATE_EPOCH is excluded from sstate hash calculation14:24
jonesv[m]<jonesv[m] "How is the order defined?"> Is it related to the order in which the layers are declared? I guess there cannot be two .bbappends for the same recipe in the same layer, can it?14:25
JPEWThe idea is that one SOURCE_DATE_EPOCH is as good as another, so don't make it part of the hash (which, obviously is not true for rpm SDE=0)14:25
JPEWRP, LetoThe2nd:
LetoThe2ndsee, i knew it :)14:26
RPJPEW: its interesting as it does find SOURCE_DATE_EPOCH_FALLBACK so the hash should have changed. I think its a weird effect of hashequiv which is preserving the SDE=0 file even when its using the fallback14:28
dl9pfwe still read back 0, just change it when found. don't know whats the best strategy w/o invalidating  task hashes14:30
*** jobroe <jobroe!> has quit IRC14:30
JPEWI'm a little suprised it didn't already invalidate all the hashes since you did "export" on SOURCE_DATE_EPOCH_FALLBACK.... but that's probably where hashequiv comes in14:31
JPEWLetoThe2nd: I *suspect* we already get some metadata ordering testing just by testing on multiple build hosts14:33
JPEWAs least on the AB14:33
JPEWI have patches to add disorderfs support... but we'd need to be careful that it doesn't slow down the build14:33
RPJPEW: I am a bit worried about the side effects from hashequiv like this :/14:38
RPjonesv[m]: BBFILES and layer priorities determine the order. You can have multiple appends in a single layer potentially although you'd have to wonder why you'd do that14:39
RPJPEW: with metadata bitbake is quite careful internally about doing things in a specific order and to be deterministic about it14:40
qschulzRP: wondering if the order in whcih bbappends from the same layer are applied is deterministic?14:40
RPqschulz: I remember working on it to ensure it is14:41
LetoThe2ndJPEW: already wrote earlier - i'm currently lookinto into the TDD approach for dayjob application development, and its an interesting take on things. can't help wondering how knowledge could be transferred to the YP world.14:41
JPEWLetoThe2nd: Ya! I'm all about automated tests. I've been working on doing CI + on-target tests with labgrid14:44
LetoThe2ndJPEW: :)14:44
JPEWI currently have it setup so that I can build the latest master of all the layers I care about for my Pi-like boards and do CI testing on them14:45
JPEWMy tests right now are pretty trivial "does it boot" tests, but even those have already found a few bugs :)14:45
*** champagneg <champagneg!> has joined #yocto14:47
LetoThe2ndI'm actually more examining the mindset. e.g. 1) write failing test 2) make test pass 3) refactor 4) go to 1)14:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:48
*** yifan <yifan!~yifan@> has joined #yocto14:49
LetoThe2ndbut that really works if you can do try-test cycles real quick, in a couple of seconds.14:49
JPEWLetoThe2nd: Ya, that can be really hard with on-target testing14:50
JPEWLetoThe2nd: Maybe I'm weird, but I get *really* happy when there is a patch with more test code changes than the actual bug took to fix :)14:51
LetoThe2ndJPEW: then i'm probably weirder because i envy those who can properly document and write tests. its kind of a thing i've never learned properly and now its backfiring.14:52
rburtonHm who was asking about Arm workstations last week...14:52
rburton is graviton2-speed14:52
RPJPEW: the "does it boot test" is key, I remember the job when we had YP do that automatically14:53
*** linums <linums!> has quit IRC15:03
*** linums <linums!~linums@> has joined #yocto15:04
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto15:13
*** hpsy <hpsy!~hpsy@> has quit IRC15:14
*** minimaxwell <minimaxwell!> has quit IRC15:16
gillesmcan you tell me if the skeleton recipe have to be inherit or copied and modified ?15:17
kayterinahello.I have some bash scripts and systemd services I want to install in my image. How do I make the correct structure so to add them with devtool add <git:repo>?15:17
kayterinamaybe  the question is how do I make a correctly structered tarball out of my git repo?15:19
sakomanIs anyone aware of a layer to support Android style read only rootfs (i.e symlinking core package state files from /etc to /data/etc) ?15:27
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC15:32
qschulzkayterina: not sure to understand the question exactly. What's wrong with `devtool add <git:repo>`? it supports git repos15:34
*** minimaxwell <minimaxwell!> has joined #yocto15:38
*** berton <berton!> has joined #yocto15:39
LetoThe2ndgillesm: copied15:41
JPEWsakoman: Not a layer, but we do that ad-hoc with tmpfiles15:42
sakomanJPEW: ah, so any changes are wiped on next boot?15:43
JPEWNo, bind mount or symlinks to a persistent partition15:44
JPEWWell, depends on the file I guess, some are temporary15:44
sakomanJPEW: indeed, lots of special cases.  is any of that work public?15:45
sakomanI hate re-inventing the wheel :-)15:45
JPEWsakoman: No, sorry. It's pretty layout specific so it wouldn't be too much help anyway15:45
kayterinayes it supports, but with my repo it didn't put aything in /workspace/sources like it does if I add for example faad2.we have a private git where I upload my code. I did devtool add </home/localgitfolder>15:46
sakomanJPEW: I was afraid of that!15:46
qschulzkayterina: for tarballs, best practices dictate there is only one directory at the root of the tarball which is named ${PN}-${PV}, which then contains the whole source code15:49
qschulzyou have the option to name it the way you want, but ${PN}-${PV} is a good name because it is what `S` defaults to so you don't have to change it15:50
JPEWsakoman: Ya, sorry. Not much help other than "yes this is possible!". We run a R/O squashfs as our root file system :)15:50
sakomanJPEW: This client has quite a complex image with many layers, so this is going to be quite tedious :-(15:51
*** lsg <lsg!uid488839@gateway/web/> has joined #yocto15:54
*** berton <berton!> has quit IRC15:56
*** berton <berton!> has joined #yocto15:57
*** codysch[m] <codysch[m]!codyschmat@gateway/shell/> has quit IRC16:00
*** alessioigor <alessioigor!> has joined #yocto16:02
yatesis any of yocto based on linaro?16:05
*** minimaxwell <minimaxwell!> has quit IRC16:06
*** alessioigor <alessioigor!> has quit IRC16:06
mcfriskhmm many layers, I have one project with 62 though most have just one/two recipes and so many due to git repo permission scheme...16:07
mcfrisksigh, gerrit16:08
*** mbulut <mbulut!> has quit IRC16:10
*** alessioigor <alessioigor!> has joined #yocto16:12
*** alessioigor <alessioigor!> has quit IRC16:14
*** bps <bps!> has quit IRC16:25
smurraysakoman: the painful thing with the symlink approach is needing to patch various things that explicitly use O_NOFOLLOW on open.  mount binding or using overlayfs is more appealing to me now just because it avoids that16:27
kergothsmurray: the volatile-binds recipe sets up services for a specified list of bind mounts to make certian areas writable, with a variable to control that, and if the path being mounted over already contains files and the writable path doesn't, it'll copy the existing contents over16:34
kergothof course, there are other options, such as overlay filesystems, too16:34
smurraykergoth: right, I've even used that before ;)16:36
kergothcan easily tweak a .wks to add a user data partition and then mount to that rather than volatile paths. *shrug*16:38
kergothi agree symlinks suck though :)16:38
kergothan overlay fs is more convenient, but historically they haven't always been well supported16:38
smurraythat changed once all the container stuff needed it16:39
*** AndersD_ <AndersD_!> has quit IRC16:43
*** w00die_ <w00die_!~w00die@> has quit IRC16:50
*** NiniC0c0 <NiniC0c0!> has joined #yocto16:50
*** w00die_ <w00die_!~w00die@> has joined #yocto16:52
sakomansmurray:  kergoth: I'm trying to convince them that symlinks aren't the best option :-)16:52
kergothsakoman: good luck :)16:53
sakomankergoth: and to make matters more interesting they want to switch to a read-only rootfs just a few days before a release!16:54
smurraysakoman: lol16:57
*** jbaxter <jbaxter!> has quit IRC16:57
*** bps <bps!~bps@> has joined #yocto16:57
*** JPEW <JPEW!~JPEW@2605:a601:ac3d:c100:e3e8:d9:3a56:e27d> has quit IRC16:58
*** JPEW <JPEW!~JPEW@2605:a601:ac3d:c100:e3e8:d9:3a56:e27d> has joined #yocto16:58
fraylol and read-only rootfs needs to be weeks or months before release.. not a few days..16:58
*** bps <bps!~bps@> has quit IRC16:59
kergothyeah, r/o is a lot of drudgery. recipe A breaks on r/o, add a bind, recipe B breaks on r/o, tweak a config file, rinse, repeat16:59
yateskergoth: i am interested in generating my own linux sdk for a special processor. does yocto provide any of the low-level source code (e.g., usb drivers) or must i provide them from something like linaro?17:07
yatesassume the processor is arm-based17:07
kergoththe linux kernel has a ton of drivers built in, and that's what we build. whether the stock upstream kernel will work or whether you need to use a bsp layer provided by someone else or by the manufacturer will depend on you rhardware17:08
kergothsee the layer index17:08
qschulzanyone to tell me if FILES_lib${PN} is a good idea or not wrt multilib and other fun kinds of BBCLASSEXTEND for example??17:11
*** fl0v0 <fl0v0!> has quit IRC17:11
qschulzRP: maybe ^?17:12
*** yifan <yifan!~yifan@> has quit IRC17:13
*** jbaxter <jbaxter!> has joined #yocto17:13
*** linums <linums!~linums@> has quit IRC17:15
kergothah yes, the "where exactly do i need to shove ${MLPREFIX}?" question..17:15
*** linums <linums!> has joined #yocto17:15
qschulzkergoth: I don't know exactly when ${PN} is expanded and gets its prefix :/17:16
qschulzand I remember there were issues with that (that was fixed by RP in dunfell IIRC)17:16
* RP has blanks that from memory17:17
qschulzsorry for bringing up those multilib nightmares again :D17:18
*** linums <linums!> has quit IRC17:20
*** linums <linums!~linums@> has joined #yocto17:20
RPqschulz: I think expansion happens after PN is changed so its probably a bad idea17:21
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto17:21
fraylib${PN} is a bad idea.. you want lib${BPN}.. I think17:22
kergothif you use bpn instead of pn you'll probably also need ${MLPREFIX} in that case17:22
fray${PN} is modified fairly early to: ${MLPREFIX}=${BPN}17:22
kergoth${MLPREFIX}lib${BPN} or something17:22
kergothunless i'm missing something, which is possible17:22
kergothi never remember that processing order..17:23
fraykergoth, thats the part I can't remember, if you need to handle the mlprefix yourself or if it gets added automatically17:23
RPkergoth: we've changed it several times17:23
fraykergoth and ya, if it's not automatic -- what you had is the right format17:23
kergothqschulz: i'd just test it and use bitbake -e to make sure things are what you expect in each context..17:23
kergothget a multilib configured qemux86-64 and add bbclassextend and test all 3 variants17:24
qschulzkergoth: yeah but sometimes you forget corner cases and it's for a recipe for inclusion in meta-oe IIUC my colleague :)17:24
qschulzthanks all :)17:24
kergothtrue. have fun :)17:24
*** sgw <sgw!> has left #yocto17:26
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:27
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC17:28
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto17:29
*** vineela <vineela!~vtummala@> has joined #yocto17:29
zeddiikhem: if you bump your meta SRCREV to this; you should still be able to build and boot your ppc64 qemu.17:42
*** yannholo <yannholo!> has quit IRC17:51
*** sgw <sgw!> has joined #yocto17:54
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:55
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto17:55
manuel1985Is there some magic variable which allows me to add kernel arguments to /boot/extlinux/extlinux.conf?17:57
*** linums <linums!~linums@> has quit IRC17:57
*** linums <linums!> has joined #yocto17:58
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto17:59
smurraymanuel1985: that's one of those "it depends" questions.  If you're using the support from uboot-extlinux-config.bbclass, UBOOT_EXTLINUX_KERNEL_ARGS would do it.  If you're using the extlinux.conf generation in wic, AFAIK you need to do it in the .wks file17:59
manuel1985smurray: Thanks! Will try it.18:01
*** richbridger <richbridger!> has joined #yocto18:08
*** linums <linums!> has quit IRC18:15
*** linums <linums!> has joined #yocto18:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:23
vdlmanuel1985: UBOOT_EXTLINUX_KERNEL_ARGS += from the machine definition works fine (but not from an image recipe, be careful)18:25
manuel1985vdl: in my case, the machine configuration file requires an .inc file which requires another .inc file which sets it with "UBOOT_EXTLINUX_KERNEL_ARGS ?=". So I should rather use UBOOT_EXTLINUX_KERNEL_ARGS_append rather than UBOOT_EXTLINUX_KERNEL_ARGS += from my local.conf, shouldn't I?18:28
vdlmanuel1985: you'll have to try this, I'm always confused about _append = " foo" vs += "foo", sorry.18:30
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:30
manuel1985vdl: I'm fairly sure this is why they initially came up with the whole _append concept. Will try. Thanks in any case!18:31
Saurmanuel1985: If you want to keep the values that are set using UBOOT_EXTLINUX_KERNEL_ARGS ?= "...", then you should use UBOOT_EXTLINUX_KERNEL_ARGS_append. Using UBOOT_EXTLINUX_KERNEL_ARGS += would ignore any values set using ?=18:31
manuel1985Saur: Great, good to have it confirmed. :) Thanks!18:32
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:46e1:3435:9ae8:d4e> has quit IRC18:32
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:cb25:132:724:97a4> has joined #yocto18:32
*** linums <linums!> has quit IRC18:33
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:34
*** linums <linums!> has joined #yocto18:34
RPzeddii: - looks new - scheduling while atomic too :/18:36
*** f3ddischson <f3ddischson!> has joined #yocto18:38
*** linums <linums!> has quit IRC18:38
*** linums <linums!> has joined #yocto18:39
*** linums <linums!> has joined #yocto18:40
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC18:42
zeddiiRP: I can start a qemux86-64 build here and see if I get the same thing.18:42
*** linums <linums!> has quit IRC18:44
*** linums <linums!> has joined #yocto18:44
RPzeddii: I doubt it reproduces as there were other builds active. Just unusual to see scheduling while atomic18:46
RPthat is bad18:46
RPand makes a change from rcu timeouts18:46
zeddiiyah. that's harder to trigger. since it really stalled for a long time, or some race was exposed.18:49
zeddiiI fixed that warning on qemux86 boot though. i'll send it along tomorrow with some other minor changes.18:49
*** risca <risca!~quassel@> has joined #yocto18:51
paulgzeddii just introduces random sleeping-while-atomic issues to see if anyone is paying attention.19:00
zeddiithe worst part, is I can't even bisect to see if anything has been done in particular with that locking. Altough, from my poking at MSI interrupts to fix the 32bit boot, there's a LOT of tweaking in the code you'd expect to not change much.19:08
frayzeddii do you still include the Intel, knee cap the kernel in 48 hours patch?19:12
zeddiifray: removed it May 2020.19:15
frayHAHAHA couldn't find a maintainer?19:16
frayThe patch written for a lawyer.. lol19:16
yateskergoth: i see - thank you.19:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:18
yatesso the "bsp" (board support package) contains drivers that either aren't provided by the kernel or which need to be replaced (e.g., due to custom processor/peripherals)?19:19
yatesdoes the kernal include u-boot, or is that provided by the bsp?19:19
JPEWyates: The BSP19:19
yatesJPEW: ok, good19:19
vdlis there something to get kind of a "diff" between two images?19:25
JPEWvdl: diffoscope?19:27
yannbuildhistory ?19:31
vdlJPEW: let say you want to build an overlayfs image or btrfs or something containing just the diff files. e.g. image A contains a+b, image B contains a+b+c, the "diff image" would only contain "c" files.19:31
JPEWvdl: Ah, I don't know of any way to do that (short of actually constructing the file system that way "live" using overlayfs)19:36
vdlJPEW: that'd be neat actually to provide custom small updates mechanism19:42
aleblancvdl JPEW, would  populating an image by hand using the pkg viable ?19:46
JPEWI have no idea19:46
vdlaleblanc: it would be mostly error-prone.19:50
aleblancvdl maybe19:51
*** linums <linums!> has quit IRC19:58
*** linums <linums!> has joined #yocto19:58
khemzeddii: cool. Updated the recipe locally, lets see. btw I was seeing a warning about CONFIG_POWER4 option not being recognised. I think it should be removed from defconfig for qemuppc6420:05
zeddiiI can take a peek at that.20:06
zeddiiI can't figure out why I'm the only person not able to build btrfs-tools right now, so I can't actually assemble an image to test anything20:06
khemcool. right now I have core-image-minimal passing -ctestimage and also core-image-sato building and booting, there is one issue with diplay where fonts are garbled but otherwise its looking ok20:07
smurrayvdl: I believe there's some stuff in non-core layers for generating the difference between two images for ostree based updaters, but it likely would take some rework to do what you describe20:15
khemzeddii:  here is exact msg
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8e1:8c0f:8c00:9696> has quit IRC20:24
*** f3ddischson <f3ddischson!> has quit IRC20:27
*** zeddii <zeddii!> has quit IRC20:29
*** zeddii <zeddii!> has joined #yocto20:29
gillesmhi how can I set a root password by recipe?20:32
Saurgillesm: You probably want to look at the extrausers bbclass.20:34
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8e1:8c0f:8c00:9696> has joined #yocto20:37
gillesmsaur ok thanks:)20:40
*** jbaxter <jbaxter!> has quit IRC20:43
Saurgillesm: For example, you can use something like this after you inherit extrausers in an image recipe: EXTRA_USERS_PARAMS += "usermod -p '<encrypted password>' root; "20:45
gillesmSaur yes I know that in local.conf but I am learning how to put it in recipe ...20:46
*** goliath <goliath!> has quit IRC20:57
*** jbaxter <jbaxter!> has joined #yocto21:00
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:a821:120d:f822:bb01> has quit IRC21:01
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has joined #yocto21:02
*** pbb <pbb!> has quit IRC21:03
*** pbb <pbb!> has joined #yocto21:03
*** manuel1985 <manuel1985!~manuel198@> has quit IRC21:05
*** pbb <pbb!> has joined #yocto21:05
*** JaBen <JaBen!~Thunderbi@2a02:8109:86c0:1c58:bd52:f0ef:80f0:e69e> has quit IRC21:07
*** om26er <om26er!6e260b11@ubuntu/member/om26er> has joined #yocto21:10
*** berton <berton!> has quit IRC21:17
*** sbach <sbach!~sbachmatr@> has quit IRC21:19
*** xtron <xtron!~xtron@> has joined #yocto21:19
*** TalleyHo <TalleyHo!c71b740f@> has joined #yocto21:19
*** sbach <sbach!~sbachmatr@> has joined #yocto21:19
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:21
TalleyHoI've been fighting w/ kernel-fitimage the last couple of days on dunfell w/ i.mx8 and a flavor of the community version.  It seems to me that if INITRAMFS_IMAGE_BUNDLE = "1", that the fitImage should _not_ contain a separate ramdisk entry?  Ie, do_assemble_fitimage_initramfs() should call fitimage_assemble w/ a 0 instead of 1 (ramdisk count)21:22
TalleyHootherwise, the boot hangs at Starting Kernel... but if if boot the fitImage (non-ramdisk version)  the kernel boots fine -- so I know the kernel is good.21:23
*** jbaxter <jbaxter!> has quit IRC21:24
RPJPEW: any idea why RPM would seem to hang diffoscope? :/21:32
JPEWRP: Nope. Do you know if it's I/O bound, CPU bound, or just stuck?21:36
frayis it trying to extract and inspect the contents?  some of the diff tools have enough understanding to extract the cpio and compare the contents21:36
RPJPEW: its using 100% cpu of a single core and never seems to complete21:36
JPEWRP: Weird21:37
RP55124 pokybui+  20   0  409428  78116   7900 R 100.0  0.1 738:02.39 nativepython321:38
JPEWRP: Hmm, should not take 12 hours for 2 packages21:38
RPJPEW: right :/21:38
RPJPEW: its looping in python somewhere, strace shows nothing, gdb shows its in python21:40
* RP doesn't have py-bt on that host21:40
JPEWRP: Can you grab the packages? We can run diffoscope locally to see if it reproduces21:41
JPEWfray: Ya, diffoscope is supposed to be able to do that21:41
RPJPEW: :)21:41
JPEWI suspect rpm diffing with diffoscope may not be getting terribly much attention since Fedora kinda (temporarily?) gave up reproducible builds21:42
RPJPEW: I have a patch in master-next for that difference btw so I know the cause21:42
*** hpsy1 <hpsy1!~hpsy@> has quit IRC21:44
*** kpo_ <kpo_!> has joined #yocto21:45
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto21:45
JPEWRP: Well, it seems to be reproducible21:46
RPJPEW: our diffoscope or a local different one?21:48
JPEWThe one on my desktop21:48
RPJPEW: nice to have something which is reproducibile for a change :D21:48
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC21:53
*** linums <linums!> has quit IRC21:58
*** linums <linums!> has joined #yocto21:59
dl9pfdiff [A/B]rsync.rpm worked locally with diffoscope v15421:59
dl9pfit does go into readelf and objdump to diff the 2 ...22:01
JPEWHmm, it looks like it's getting hung up with the HTML output specifically22:01
RPdl9pf: I think the SDE stuff is getting hung up as you're not writing the fallback value into the SDE file22:03
JPEWYa, it's a *huge* diff, and I'm guessing the HTML output is triggering some pathological case22:03
RPdl9pf: combine this with hashequiv and I can see how it would get confused22:03
dl9pfon diffoscope ?22:03
dl9pfnow I'm confused ...22:04
JPEWdl9pf: Ah.. I wonder if we need the python rpm module22:04
dl9pfok, then how should we deal with the 'old' (aka wrong) value being extracted from sstate-cache ?22:04
RPdl9pf: I'm talking crossed porpoises, sorry :)22:04
JPEWMy diffoscope is only comparing the rpms in can't go into them (probably like the AB)22:04
RPdl9pf: I have a tweak to your patch in mind22:04
*** linums <linums!> has quit IRC22:05
vdlwhoops, wic --fstype doesn't support f2fs22:05
*** linums <linums!> has joined #yocto22:06
*** xtron <xtron!~xtron@> has quit IRC22:09
dl9pfJPEW: yeah, got python3-rpm installed locally ... so the desktop-diffoscope has it22:10
dl9pfmight want that for the autobuilder as well22:11
JPEWdl9pf, RP: Yep, just verified that it works once python3-rpm is installed22:12
JPEWNeed to figure out how to package that in OE22:12
* JPEW has to go cook supper22:12
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:16
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto22:17
*** td23 <td23!> has joined #yocto22:20
*** td <td!> has joined #yocto22:20
RPJPEW, dl9pf: In the interests of getting the working for now, I think I may add --exclude *.rpm22:21
*** td23 <td23!> has quit IRC22:21
dl9pfpython3-rpm is part of the rpm package22:21
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:24
tdhello, is scissors line supported in patch submitting on oe-core?22:24
dl9pfso we'd need python3-rpm-native ?  give it a shot before we exclude maybe ?22:25
JPEWdl9pf, RP: Yep. Got it. Patch coming22:39
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto22:40
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto22:42
*** ctlnwr <ctlnwr!~catalin@> has quit IRC22:44
*** kpo <kpo!> has quit IRC22:46
*** kpo <kpo!> has joined #yocto22:47
*** td <td!> has quit IRC22:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:51
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto22:53
*** zeddii <zeddii!> has quit IRC22:57
*** agust <agust!> has quit IRC22:58
*** zeddii <zeddii!> has joined #yocto23:00
RPJPEW: thanks, beat me to it. Thanks for the debugging, I really wasn't getting my mind onto that one today23:03
RPJPEW, dl9pf: is what I'm thinking may fix SDE23:04
zeddiican anyone think of anything more than sstate that could corrupt a build of btrfs tools ? I switched from qemux86 in debugging the warning on boot, to qemux86-64 and btrfs tools blows up in a way that can't possibly be anything but something broken on my machine.23:11
zeddiiI've been broken all afternoon and am out of ideas. The only touch on the package is anuj's minor version bump, and reverting that was a no-op.23:11
zeddiisetuptools has been, and still is, in the depends, etc.23:12
RPzeddii: I'm sure I saw this23:14
zeddiiI've searched the native sysroot, and I can't find any trace of setuptools, but I may not be looking for it properly.23:15
RPzeddii: oh, but it was caused by insanity locally which you couldn't have. You don't have any of my t222 branch I assume?23:15
*** ctlnwr__ <ctlnwr__!~catalin@> has joined #yocto23:15
zeddiino. but I have my own fair share of local insanity, but none that should cause this.23:15
RPzeddii: in my case I had some code go crazy and it was deleting the contents of the sysroot so python3-setuptools-native was empty in the sysroot23:16
zeddiiahah. nasty. I looked for *setuptools* in the recipe sysroot and found nothing.23:16
RPzeddii: have a look at what python3-setuptools-native's contents is23:17
RPzeddii: sysroot-components/ is a good place to look23:17
*** ctlnwr_ <ctlnwr_!~catalin@> has quit IRC23:19
zeddiiand that's right in the recipe-sysroot-native, right ? I see no sign of any of it. which of course leads to that error. Maybe I should be doing a cleanall on python-native, it may have been somehow corrupted. I had some horrible networking and other issues today.23:19
* zeddii tries that23:20
*** kpo_ <kpo_!> has quit IRC23:21
*** kpo_ <kpo_!> has joined #yocto23:21
RPzeddii: TMPDIR/sysroot-components/x86_64/python3-setuptools-native23:22
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC23:25
zeddiihah. I'm not sure how I didn't know about that.23:25
zeddiiand that directory is empty. hmm.23:25
zeddiicleaning that specifically. something very wrong has happened.23:27
RPzeddii: that sounds very suspicious...23:27
RPzeddii: sysroot-components is where everything is hardlinked from to for recipe-sysroot and recipe-sysroot-native23:28
RPIts nice nobody actually has to care about the details, maybe I got something right :)23:28
zeddiiindeed. The list of things that have broken, that shouldn't be possible, today is shocking. And I don't mean oe/yocto build related. Everything from wifi dying, to DNS being wrong on half my machines, to a server in the office going nuts (and now I have to go in) .. so none of this is surprising to me now.23:29
zeddiiI got zero progress on anything, I just debugged "stuff that shouldn't break" and infrastructure.23:29
zeddiiahhhh. Monday.23:29
RPzeddii: I'm also having one of those days :/23:30
*** linums <linums!> has quit IRC23:32
*** mrpelotazo <mrpelotazo!> has quit IRC23:33
*** linums <linums!~linums@> has joined #yocto23:33
zeddiiand it's late for you! I have a bit more time to be annoyed. I cleaned the -native and rebuilt it, I see it in the provider now. but it still went boom in btrfs-tools. None of this is normal, I'll just rm -rf it overnight.23:34
*** kpo__ <kpo__!> has joined #yocto23:43
*** kpo_ <kpo_!> has quit IRC23:43
*** RzR <RzR!~rzr@unaffiliated/rzr> has quit IRC23:46
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:cb25:132:724:97a4> has quit IRC23:47
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:52

Generated by 2.17.2 by Marius Gedminas - find it at!