Monday, 2022-03-21

*** Tokamak <Tokamak!~Tokamak@> has joined #yocto00:13
*** kuzz_ <kuzz_!> has joined #yocto00:44
*** kuzz <kuzz!> has quit IRC (Ping timeout: 260 seconds)00:44
*** xantoz <xantoz!> has quit IRC (Ping timeout: 240 seconds)00:45
*** xantoz <xantoz!> has joined #yocto00:45
*** camus <camus!~Instantbi@2409:8a1e:911f:3780:480d:16c9:c84b:277b> has quit IRC (Remote host closed the connection)01:25
*** MWelchUK7 <MWelchUK7!> has joined #yocto01:35
*** MWelchUK <MWelchUK!> has quit IRC (Ping timeout: 240 seconds)01:37
*** MWelchUK7 is now known as MWelchUK01:37
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)01:45
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto01:45
*** camus <camus!~Instantbi@> has joined #yocto01:51
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)02:01
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)02:02
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)02:09
*** shebang <shebang!> has joined #yocto02:12
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:18
*** starblue <starblue!> has joined #yocto02:19
*** camus <camus!~Instantbi@> has joined #yocto02:22
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)02:28
*** camus <camus!~Instantbi@> has joined #yocto02:29
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)03:35
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto03:40
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)03:55
*** amitk <amitk!~amit@> has joined #yocto04:12
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto04:43
*** florian_kc <florian_kc!> has joined #yocto06:27
*** florian_kc is now known as florian06:40
*** davidinux <davidinux!> has quit IRC (Ping timeout: 240 seconds)06:59
*** davidinux <davidinux!~davidinux@> has joined #yocto07:00
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:02
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)07:03
*** rob_w <rob_w!> has joined #yocto07:16
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:18
*** frieder <frieder!> has joined #yocto07:42
*** mckoan_ is now known as mckoan07:57
mckoangood morning07:58
*** xantoz <xantoz!> has quit IRC (Ping timeout: 268 seconds)08:01
*** xantoz <xantoz!> has joined #yocto08:01
*** grma <grma!~gruberm@> has joined #yocto08:03
*** rfuentess <rfuentess!> has joined #yocto08:04
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:16
michaeloHi qschulz : thanks for the notification about your +yocto disappearing when I reply. I'll double check.08:27
*** dvorkindmitry <dvorkindmitry!~dv@> has quit IRC (Quit: KVIrc 5.0.0 Aria
michaeloqschulz: I see no issue with my latest reply to you (date 09:54 CET).08:55
qschulzmichaelo: the message is sent to two addresses, foss (to) and foss+yocto (cc)09:03
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto09:09
michaeloqschulz: yes, because your "From" address is different from the "cc" one you used in your original e-mail. I'll be happy to manually remove "foss" and keep only "foss+yocto" if you prefer.09:28
qschulzmichaelo: it isn't the From actually09:35
qschulzit's the "Received: (Authenticated sender: foss@"09:36
qschulzthe From is correct\09:36
qschulzthe received too technically, it's just that your mail client takes the Received instead of the From09:36
*** rber|res <rber|res!~rber|> has joined #yocto09:38
*** RobertBerger <RobertBerger!~rber|> has joined #yocto09:38
qschulzFWIW, Thunderbird picks the From correctly09:38
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Client Quit)09:39
*** rber|res <rber|res!~rber|> has quit IRC (Client Quit)09:39
michaeloqschulz: weird. I'm using Thunderbird, and the "From" field is "Quentin Schulz" <>09:48
RPmichaelo: thanks for the review. I suspect I'd better wait and see if qschulz or ndec have comments before merging :)10:08
ndechey RP , i looked at the patches. of course using the git data helps. of course some of the patches are 'weird'.. I admit that this has been an issue since the very beginning, and we've never made any attempt to fix the situation..10:10
ndecas it is it breaks the build from a tarball (we still produce release tarballs). should we worry about that?10:11
RPndec: we don't really have release tarballs as such any more, just snapshots of the codebase10:12
RPndec: I suspect the benefits outweigh that cornercase?10:12
ndeci think i agree.. it probably does not make sense to have release tarballs anyways these days10:13
RPndec: I've been pushing to move us away from them10:13
ndecRP: i was wondering if we should split yocto-docs into a tree that 'builds' a flavor of the docs, and a tree that builds the website (e.g. switcher, transition, ..). it's all very much convoluted10:17
RPndec: maybe, although I'm not sure it would change much in reality :/10:18
RPit is all intertwined10:18
ndecagreed.. it would be nice to be able to easily build the whole website with 'one' tool..10:19
michaeloYes, starting from infos from the yocto-docs repository looks like a way to keeps things in sync10:30
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto10:38
qschulzRP: will have a look as soon as I can. Been busy with release days/weeks for a while. Last Friday was weirdly not too busy hence the doc patches10:41
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving)10:41
manuel1985AFAIK Rust is first class citizen of the yocto project now, but also for dunfell?10:44
manuel1985qschulz: That means no support on Dunfell? Am I reading you correctly?10:51
qschulzmanuel1985: seems about right, no rust recipe seems to indicate it's not first citizen10:52
qschulzmanuel1985: FWIW, kirkstone will be out in about a month or so, and it'll be LTS for as long as dunfell is (at least with current situation)10:53
qschulzso instead of backporting rust support to dunfell, upgrading to kirkstone might not be the worst idea :)10:53
RPqschulz: sorry to ask but do you have a rough idea the timescale? Just to explain why I ask, if it were this week, I'd probably hold the patches and wait. If it were in the next few weeks I'd probably lean to merging and then we'll handle any issues with follow up patches. Not trying to put any pressure, it just helps me to know the timescale10:59
manuel1985qschulz: Depends wether our BSP and OTA solution will also see kirkstone support.10:59
kanavin_halstead, downloading from is very slow, is the link saturated somehow? I'm getting 100K/s speeds10:59
*** starblue <starblue!> has quit IRC (Ping timeout: 268 seconds)11:04
*** starblue <starblue!> has joined #yocto11:06
kanavin_wget in particular11:08
qschulzkanavin_: there was something done last week to prioritize against sstate.yoctoproject.org11:14
qschulz(at least that's what was said)11:15
kanavin_qschulz, I'm not entirely sure if that's on my side, but I tested it with my home machine, and a company server (that's on the other side of Germany), and they both get the slow speed11:15
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)11:17
qschulzkanavin_: oscillate between 100-300KBps in Austria, /me shrugs11:19
RPkanavin_: michael commented he needed to prioritise the traffic, I'm not sure if he did that yet or not11:20
* zeddii is back from vacation. oof.11:22
RPzeddii: welcome back11:23
RPzeddii: I wonder how much we broke when you weren't looking? :)11:25
zeddiiit's about 20 degrees (c) colder now, that will at least keep me indoors to figure it out :)11:25
zeddiiI was watching the python chaos, or skimming would be a closer description.11:26
zeddiiI'll have to rebase and test my queues as the first bit of effort today.11:26
RPI'm seriously thinking I should merge the libtool upgrade too11:26
RPthe pseudo breakage there worries me a bit11:27
zeddiithe 2.4.7 one ? I'd agree it would be nice to get the release.11:27
RPzeddii: yes, been years since 2.4.6 but 2.4.7 doesn't contain that much11:28
zeddiiis the pseudo breakage on the list ? I missed that.11:28
RPsomething is passing crazy shell pipelines as filenames to libc11:29
zeddiiRP: yah, I always tend to take those releases. even if late. Support is easier, and it needs an even closer look after release, so nice to get it done.11:30
zeddii6000+ wow.11:30
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)11:31
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto11:33
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:73e9:dfeb:8f6e:fb3e> has joined #yocto11:33
pasherringHello people! I've been experiencing some really slow git fetches, topping around 255kBps, but consistenytly at 85 kBps. The same repo I can manually git clone with 4MBps+. Any ideas on what could I have wrong here on my setup?11:37
frosteyesHey folks. Just noticed my local mirror of poky ( had stopped syncing, because master had diverged. It seems they was 3 commits related to poky.yaml. Now removed and is on master-next. Guess it was just an error they where pushed to master.11:39
kanavin_pasherring, it's using the yocto mirror, and it's slow. we've alerted halstead to the issue.11:51
rburtonset PREMIRRORS="" in your local.conf and it will go straight to the upstream source11:52
*** chep <chep!> has quit IRC (Read error: Connection reset by peer)11:56
pasherringAh, I see. Thanks kanavin_ , rburton !11:59
qschulzRP: I'll do it this week. How much I hate certification processes...12:10
rburtonRP: cherrypicking the tiff CVEs now12:11
RPrburton: great, thanks12:23
*** kuzz_ <kuzz_!> has quit IRC (Remote host closed the connection)12:24
*** kuzz_ <kuzz_!> has joined #yocto12:27
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)13:03
*** davidinux <davidinux!> has joined #yocto13:05
*** rber|res <rber|res!~rber|> has joined #yocto13:07
*** davidinux <davidinux!> has quit IRC (Ping timeout: 256 seconds)13:11
*** davidinux <davidinux!~davidinux@> has joined #yocto13:11
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has joined #yocto13:14
*** LocutusOfBorg <LocutusOfBorg!~locutusof@user/locutusofborg> has quit IRC (Remote host closed the connection)13:24
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto13:27
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto13:30
*** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto13:31
landgrafwhere (and how) devtool-source.class is inherited? my grep foo didn't help :(13:37
*** troth <troth!> has quit IRC (Quit: Leaving.)13:38
landgrafnvm. found it :)13:39
*** sakoman <sakoman!> has joined #yocto13:43
RPqschulz: cool, thanks13:47
*** angolini <angolini!> has quit IRC (Quit: Connection closed for inactivity)13:54
*** troth <troth!> has joined #yocto13:59
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto14:03
*** pgowda_ <pgowda_!> has joined #yocto14:07
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto14:10
*** codavi <codavi!~akiCA@user/akica> has joined #yocto14:11
*** marc3 <marc3!> has quit IRC (Ping timeout: 272 seconds)14:13
*** marc3 <marc3!> has joined #yocto14:14
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)14:15
kanavin_zeddii, is there a correct procedure for swapping linux-xlnx with linux-yocto? I have a customer request to provide 5.15 linux-yocto for zynqmp - I have set PREFERRED_PROVIDER, and wondering if something else should be done.14:23
*** Guest11 <Guest11!> has joined #yocto14:26
*** Guest11 <Guest11!> has quit IRC (Quit: Client closed)14:32
rfs613where does setuptools_build_meta.bbclass come from?14:45
rfs613I see a reference to it in documentation/ref-manual/classes.rst but not the .bbclass file14:47
manuel1985Has anyone an idea what linux should be doing after the "sd 0:0:0:0: [sda] Attached SCSI removable disk" line? I suppose it's the linux kernel whose output I see here.
qschulzmanuel1985: very likely unrelated except if you're booting from USB? Try to get logs before the USB subsystem messages14:48
manuel1985qschulz: I'm booting from USB.14:49
rfs613oh, setuptools_build_meta now has a python_ prefix added.14:56
rburtonrfs613: the doc update is queued but not yet merged :)14:59
*** xmn <xmn!> has joined #yocto15:01
RPrburton: I'm not sure the meta-oe piece made it in yet15:09
rburtonthey did15:10
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)15:11
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 256 seconds)15:17
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto15:17
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)15:18
manuel1985After dropping 'LICENSE_CREATE_PACKAGE = "1"' into the local.conf, `oe-pkgdata-util list-pkgs` should list quite a few *-lic packages, right? Don't get it to work here...15:22
*** SSmoogen is now known as Ebeneezer_Smooge15:24
RPmanuel1985: did you rebuild things?15:28
manuel1985RP: I did a `bitbake -e <my-image>` so it would re-parse the local.conf15:28
RPmanuel1985: you need to actually run the build to generate packages15:29
manuel1985RP: Ok, will try. Does this var need to go in the local.conf, or is the image definition alright as well? Because I had it in the image definition first, and the build aborted due to gstreamer1.0-lic not being provided anywhere.15:30
RPmanuel1985: needs to be in a global config15:31
RPmanuel1985: local.conf is global as is distro15:31
manuel1985RP: ok thanks. That still something I haven't understood yet -- what needs to be on global level, and what I can put into the image definition too. COPY_LIC_MANIFEST and COPY_LIC_DIRS worked on the image level too.15:33
qschulzmanuel1985: recipes are in their own context and cannot impact other recipes15:34
qschulzconf files are global, so anything set in them will make it to any recipe15:34
manuel1985qschulz: ok and COPY_LIC_MANIFEST COPY_LIC_DIRS do work on the image level as they don't influence other recipes but only take what's already there, kind of? Hmmm I see15:36
*** florian_kc <florian_kc!> has joined #yocto15:44
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)15:44
*** florian__ <florian__!> has joined #yocto15:45
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)15:49
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: Textual IRC Client:
zeddiikanavin_: you'd need to set the KBRANCH variable, if you want the contributed BSP patches on v5.15/standard/xilinx-zynqmp, but other than that the linux-yocto process will find the BSP definition and configuration entry point in the kernel-cache automatically assuming the machine is xilinx-zynqmp15:56
*** jclsn73 <jclsn73!> has joined #yocto16:02
moto-timosmurray: thank you for the removal patches for recently moved to core python recipes16:07
smurraymoto-timo: no worries, figured I'd be hard-pressed to screw up the patches to help clean it up ;)16:13
*** prabhakarlad <prabhakarlad!> has joined #yocto16:57
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)17:05
cb5rIf I see correctly, maliit-framework and maliit-plugins (keyboard) have been removed from meta-oe many years ago. Has this been moved somewhere else? - because I cannot find it anywhere 😕17:08
rburtongit repo last touched 2015, so i'd be stepping away17:13
rburtonah the keyboard repo is maintained, its the plugins one which isn't17:13
*** mckoan is now known as mckoan|away17:13
cb5rrburton:  Thanks for the link - I didn't know this search engine existed. Good to know! 🙂17:14
rburtonit's essential17:14
qschulzRP: got a bit confused with patches order, also not sure I reviewed them all, so don't hesitate to ping me if I missed on17:15
cb5rI figure 😛17:15
moto-timoWe should probably add it to the conf-notes.txt17:16
cb5rrburton: Looks to me as if meta-kde uses maliit sources that are actively maintained or am I wrong?17:16
RPqschulz: is the one I'm not sure you've seen17:16
qschulzRP: I did not17:16
RPqschulz: basically my patches are on the top of master-next in poky17:17
RPqschulz: there is also the transitions patch
qschulzRP: +        if i in bitbake_mapping: should be if branch in bitbake_mapping I think17:21
qschulz(the second one17:21
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)17:24
RPqschulz: yes, well spotted17:29
qschulzRP: since patches are in master-next now and there's a pull request waiting for you, how do you want to proceed actually? Seems like review is a bit late (and I'm reviewing old versions apparently.... I hate Thunderbird)17:30
*** danielt <danielt!~danielt@2001:470:69fc:105::34d8> has joined #yocto17:31
qschulzI guess, the code-unrelated changes can be discussed, otherwise we'll just send patches to fix what we see or make some improvements?17:31
qschulzgotta go now, will read your answer tmrw. have a nice evening folks17:32
RPqschulz: You're not reviewing old versions as such, just that there were follow on patches on the list and michaelo staged some of them17:34
RPqschulz: I've tweaked a couple of things based on your review so far and will resend the patches17:34
*** chep <chep!> has joined #yocto17:42
*** chep <chep!> has quit IRC (Client Quit)17:44
kanavin_zeddii, thanks, the machine is zynqmp-generic from meta-xilinx-core17:44
RPqschulz: I've sent a v2 of the series to try and ease review17:45
*** chep <chep!> has joined #yocto17:45
RPqschulz: if there is no huge disagreement with things I can merge and we can them work on incremental improvements17:46
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:49
zeddiikanavin_: ok. in that case, where ever you set KBRANCH (a bbappend presumably), you'd also set KMACHINE:zynqmp-generic = xilinx-zynqmp, since if you don't set it KMACHINE == MACHINE and it won't find that BSP definition in the kernel meta-data.18:16
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)18:16
kanavin_zeddii, right, I was wondering why there's a bunch of configcheck warnings printed about not found symbols, including some fairly important ones like CONFIG_XILINX_PHY18:18
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:400e:f472:d685:3df9> has joined #yocto18:23
*** goliath <goliath!~goliath@user/goliath> has joined #yocto18:23
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)18:23
Guest79Our build system (based on Yocto) has two levels of sstate caching,  global and local.18:25
Guest79My question:18:25
Guest79Could we copy artifacts of a locally build package from the local sstate-cache (e.g. build/sstate-cache) to the global sstate cache?18:25
Guest79Using a method like this:18:25
Guest79cd /path/to/local/cache18:25
Guest79find * -name "*:my-package*" | xargs -n1 -I {} rsync --verbose --archive --relative {} /path/to/global/cache18:25
Guest79We have tested this and seems it works, but I am worried about side-effects.18:25
kanavin_Guest79, it's better to mount the global cache as r/w nfs18:26
Guest79kanavin_ ok, but the way we are copying the artifacts would is that okay?18:27
kanavin_Guest79, I think not, if partially copied artifacts can be seen by other users of the global cache18:28
kanavin_it needs to be completely atomic18:28
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:73e9:dfeb:8f6e:fb3e> has quit IRC (Quit: Leaving)18:39
rburtondoesn't rsync write to hidden files and rename?18:39
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto18:41
Guest79rburton I am sorry I did not understood your comment, if yu could please expand on it..18:43
rburtonother users won't see partially copied artifacts18:43
Guest79But we have tested it, and it appears it works ... Or at least our nightly build seems it works...18:44
kanavin_Guest79, if rsync runs while something else is accessing the cache that something may see and fetch a cache artifact that isn't completely copied18:45
kanavin_Guest79, mounting the global cache directly with nfs would avoid that18:45
Guest79kanavin_ thanks understood.18:47
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto18:49
*** Qorin <Qorin!> has quit IRC (Ping timeout: 245 seconds)18:53
*** Tokamak_ <Tokamak_!~Tokamak@> has joined #yocto18:57
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)18:59
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)19:02
*** tcdiem <tcdiem!> has joined #yocto19:21
*** florian__ <florian__!> has quit IRC (Read error: Connection reset by peer)19:21
*** florian__ <florian__!> has joined #yocto19:21
kanavin_zeddii, seems like upstream 5.15 isn't quite ready for consumption on zynqmp and I'm going back to 'evil vendor kernel' - linux-xlnx does have a 5.15 branch fortunately19:23
*** Tokamak_ <Tokamak_!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)19:29
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:32
*** qrsBRWNanyall[m] <qrsBRWNanyall[m]!~qrsbrwnth@2001:470:69fc:105::1:e19e> has joined #yocto19:51
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Quit: Leaving)19:53
zeddiiupstream 5.15 is relatively feature complete, but yah, the vendor tree queue continues to be "not small"19:54
LetoThe2ndwhat is a neat way to err out if a layer is being parsed? like bb.fatal in a recipe, but for layer.conf?19:57
paulgmeta-security layer has an annoying misfeature where it nags you if it is being included but not enabled.  I haven't looked at how it does it, but maybe you can steal from what it does?19:59
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:400e:f472:d685:3df9> has quit IRC (Quit: Client closed)20:00
moto-timoso although the PCIe 4.0 drive did seem to speed up some tasks, the overall build time was the same... we are really compute bound on rust-native :/20:05
moto-timoJaMa: any idea when meta-ros will start moving to kirkstone?20:06
LetoThe2ndpaulg: ah yeah, found it, thanks. too bad i need it in ~20 layers, and no common one that I can rely on :(20:09
moto-timometa-virtualization has the same feature20:10
LetoThe2ndyeah but c&p-ing a class into 20 layers feels outight wrong.20:11
moto-timohmmm... generalized common class but with a per layer variable for what it nags about? not sure if it would work...20:12
moto-timocommon class in some base layer20:12
moto-timostill annoying to do the per layer config though ;)20:12
LetoThe2ndthanks for the input!20:16
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 -
khemmanuel1985: looking at your logs it seems you have some storage attached to USB ?20:36
khemmanuel1985: if so, then it seems there is not enough power supplied to the system unless the USB disk is externally powered20:37
*** wyre <wyre!~wyre@user/wyre> has joined #yocto20:37
moto-timoThat will definitely be a problem20:59
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)20:59
vmesonLetoThe2nd:  moto-timo if somone makes it easier for a layer to nag users, please also provide a mechanism to have the layer stop nagging!21:00
moto-timovmeson: meta-virt at least has that knob21:01
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:02
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:03
*** florian__ <florian__!> has quit IRC (Ping timeout: 240 seconds)21:04
vmesonmoto-timo: ah, I did notice that until now. It's in the README even:   SKIP_META_VIRT_SANITY_CHECK = 121:08
vmeson*did NOT21:08
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)21:08
khemactually having layers to be inert is best practice but it may not be possible all the time.21:10
khemsuch layers are better of by nagging then silently spewing stuff into your builds21:10
*** florian__ <florian__!> has joined #yocto21:16
vmesonkhem: all the nagging layers that I know of are inert and nag about it by default. Turns out they also have a SKIP_<layer-name>_SANITY_CHECK -- some of them for years!!21:19
sielickiwould you guys accept a patch that allows people to not fatally error on `LAYERSERIES_COMPAT` mismatches?21:23
RPvmeson: YP compat requirement, at least the inert bit21:23
vmesonRP, yep, inert is the only sensible default. It was the constant nagging that was bothering me but now I know that it can be and will be turned off! Phew!21:31
moto-timosielicki: you are better off forking or working with upstream to add release of interest. You will not get any traction to allow it to float.21:34
RPsielicki: it really wouldn't encourage any behaviour that would be overall good for the project21:35
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:45
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:45
*** florian__ <florian__!> has quit IRC (Ping timeout: 240 seconds)21:52
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)22:15
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)22:37
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:400e:f472:d685:3df9> has joined #yocto22:38
*** sakoman <sakoman!> has quit IRC (Ping timeout: 250 seconds)22:39
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto22:39
*** sakoman <sakoman!> has joined #yocto22:53
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 256 seconds)22:55
*** florian__ <florian__!> has joined #yocto23:08
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:25
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 240 seconds)23:25
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto23:28
sielickiThe problem that I'm trying to solve is that i started at a place in november, they've been on thud for years. They target both TI and Xilinx, so I need meta-ti and meta-xilinx. I want to move them to a non-EOL release.... (full message at
*** florian__ <florian__!> has quit IRC (Ping timeout: 240 seconds)23:38
*** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection)23:53
*** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto23:54
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)23:58
*** Guest79 <Guest79!~Guest79@2601:644:8102:f530:400e:f472:d685:3df9> has quit IRC (Quit: Client closed)23:58
*** dev1990 <dev1990!> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!