Wednesday, 2015-05-20

*** abelloni <abelloni!> has joined #yocto00:01
*** pidge <pidge!~pidge@2a02:8084:0:3000:2544:9cc2:c13c:7e79> has quit IRC00:10
*** sjolley <sjolley!~sjolley@> has joined #yocto00:17
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC00:25
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto00:26
*** neur0Fuzzy <neur0Fuzzy!> has joined #yocto00:34
*** Jefro <Jefro!> has quit IRC00:37
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto00:44
*** timsche <timsche!> has joined #yocto00:51
*** bavery <bavery!c066d101@gateway/web/freenode/ip.> has quit IRC01:09
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC01:09
*** vmeson <vmeson!> has quit IRC01:11
*** vmeson <vmeson!> has joined #yocto01:22
*** vmesons <vmesons!> has joined #yocto01:22
*** vmeson <vmeson!> has quit IRC01:26
*** Jefro <Jefro!> has joined #yocto01:29
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC01:34
*** sjolley <sjolley!~sjolley@> has quit IRC01:55
*** varibull <varibull!> has quit IRC02:04
*** varibull <varibull!> has joined #yocto02:05
*** varibull <varibull!> has joined #yocto02:06
*** sjolley <sjolley!sjolley@nat/intel/x-uqfnfbxiyhgvimqu> has joined #yocto02:10
*** chankit <chankit!chankitx@nat/intel/x-yhyvffdcnzkflyrk> has joined #yocto02:20
*** timsche_ <timsche_!> has joined #yocto02:30
*** timsche <timsche!> has quit IRC02:33
*** timsche_ <timsche_!> has quit IRC02:37
*** Jefro <Jefro!> has quit IRC02:43
*** zeddii_home <zeddii_home!> has quit IRC03:17
*** pidge <pidge!~pidge@2a02:8084:0:3000:e557:2f7e:d4ed:92eb> has joined #yocto03:19
*** Jefro <Jefro!> has joined #yocto03:24
*** Jefro <Jefro!> has joined #yocto03:36
*** hamis <hamis!~irfan@> has joined #yocto03:58
*** pohly1 <pohly1!> has joined #yocto03:58
*** pohly <pohly!> has quit IRC04:01
*** pidge <pidge!~pidge@2a02:8084:0:3000:e557:2f7e:d4ed:92eb> has quit IRC04:07
*** sg-fn <sg-fn!> has quit IRC04:47
*** Jefro <Jefro!> has quit IRC04:54
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto04:56
*** grma <grma!> has joined #yocto05:06
*** e8johan <e8johan!> has joined #yocto05:08
*** akhandav <akhandav!~arun@> has left #yocto05:18
*** AndersD <AndersD!> has joined #yocto05:20
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC05:38
*** limotec-dev <limotec-dev!d5b5327c@gateway/web/freenode/ip.> has joined #yocto06:07
*** wadim_ <wadim_!> has joined #yocto06:15
*** hitlin37 <hitlin37!uid16371@gateway/web/> has joined #yocto06:18
*** [Sno] <[Sno]!> has quit IRC06:21
*** frsc <frsc!~frsc@> has joined #yocto06:22
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto06:40
*** egavin <egavin!> has quit IRC06:44
*** jimBaxter <jimBaxter!> has joined #yocto06:52
*** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/> has joined #yocto06:56
*** jbrianceau_away is now known as jbrianceau06:56
*** varibull <varibull!> has quit IRC06:58
*** varibull <varibull!> has joined #yocto06:58
*** [Sno] <[Sno]!> has joined #yocto07:05
*** mago_ <mago_!~mago@> has joined #yocto07:05
*** elmi82 <elmi82!> has joined #yocto07:06
woah_dudehi all!07:07
woah_dudei'm trying to add qt to the edison yocto image, i downloaded meta-qt5 from git and add this layer to the bblayers.conf, but when i'm selecting machine from the list in hob, i'm getting this error
woah_dudeanybody can advice?07:08
woah_dudeif i delete this file, i can start building process but the fail on do_configure in qt_base package07:10
woah_dudesorry for my english07:10
*** ant_work <ant_work!> has joined #yocto07:11
*** ntl <ntl!> has quit IRC07:14
LetoThe2ndwoah_dude: on a first guess, have you checked that you're using the right branch of meta-qt5, e.g. the one that targets the release of yocto that your edison build is also on?07:15
LetoThe2ndwoah_dude: and *hint*: just deleting things is way more likely to break stuff even further instead of tfixing them magically.07:16
woah_dudei know) but i need only 3 packages from qt, not all07:16
LetoThe2ndthat doesn't mean that the build process doesn't need some other, less obvious files implicitly07:17
*** jku <jku!jku@nat/intel/x-nasdxwuiawyuaqiy> has joined #yocto07:18
woah_dudehow can i understand which branch of meta-qt i need for edison?07:19
woah_dudein terminal: poky git:(c4f1f0f)07:22
*** noraply <noraply!> has joined #yocto07:25
woah_dudeok, i google it, it seems like daisy branch) i get daisy branch from qt git, and error is gone!07:25
woah_dudeLetoThe2nd thanks for your helps07:26
*** ntl <ntl!> has joined #yocto07:28
*** mckoan|away is now known as mckoan07:28
mckoangood morning07:28
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC07:30
LetoThe2ndwoah_dude: sry, i'm not here all the time. IRC is rather asynchronous07:32
LetoThe2ndwoah_dude: basically, check the documentation of your edison stuff (where did you get it from? what git branch are you on there?) and then select the corresponding one in the qt5 layer07:33
woah_dudenonono, your advice actually fixed this error)07:33
LetoThe2ndah ok? nice!07:33
woah_dudeyeah) thanks)07:33
LetoThe2ndwoah_dude: basically be aware of the fact that the layer mix-n-match mechanism doesn't work too well across different releases07:33
*** ant___ <ant___!> has joined #yocto07:33
woah_dudeok, i'll be07:34
*** ant_work <ant_work!> has quit IRC07:34
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:39
*** rburton <rburton!> has joined #yocto07:45
*** rburton1 <rburton1!> has quit IRC07:47
*** zwerch <zwerch!> has joined #yocto07:50
zwerchHello together. Can anyone tell me how I can load some wifi-drivers at boot?07:51
*** nighty^ <nighty^!> has joined #yocto07:55
*** TobSnyder <TobSnyder!> has joined #yocto07:57
mckoanzwerch: take a look at linux-firmware*.bb07:59
*** ddom <ddom!> has joined #yocto08:00
*** blitz00 <blitz00!stefans@nat/intel/x-xgelsqrclurjgcuo> has joined #yocto08:01
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto08:01
zwerchmckoan: Yeah, I found that, but they're installed at /lib/modules/[kernel_version]/kernel/drivers/net/wireless and I couldn't find any recipe / script that installs them there.08:01
mckoanzwerch: the proper driver knows where to get them08:01
zwerchzwerch: And how do I load some of them at boot time?08:02
zwerchOops. I meant mckoan :D08:02
mckoanzwerch: add your driver to the kernel image or add the kernel module08:03
zwerchAh, okay08:03
mckoanzwerch: yw08:03
*** chris_____ <chris_____!56bcece2@gateway/web/freenode/ip.> has joined #yocto08:08
zwerchIs there a way to write a bbappend for all linux-${MACHINE}_%? Via a wildcard? So I don't need to write an append for every machine.08:16
zwerchOr is this considered bad practice?08:16
*** jimBaxter <jimBaxter!> has joined #yocto08:20
*** adelcast <adelcast!~adelcast@> has quit IRC08:23
nrossizwerch: that sounds like an odd use-case, why is there a kernel for each machine?08:25
nrossizwerch: However you could dod "linux-%.bbappend, and have an annoymous method that checks PN and does a SkipPackage bit like:
*** belen <belen!Adium@nat/intel/x-ydgcfxkvfihffxls> has joined #yocto08:27
ant___zwerch: why don't you write a single append and use overrides in it?08:28
zwerchMaybe I wasn't clear enough: We have a few different machines, and some use different kernel recipes. What I need is a bbappend that matches all of them and appends some stuff to it.08:29
*** egavin <egavin!> has joined #yocto08:30
nrossizwerch: does it matter if you append to a kernel that you are not using?08:31
ant___the normal way would be a .bbappend for each recipe / kernel-type08:32
zwerchnrossi: I don't think so? :D08:32
zwerchant: okay08:32
nrossizwerch: as long as you are using machine overrides i see no issues with ant___'s suggestion08:32
ant___see this:
ant___that's standalone, the old 3.14 was done with .bbappend08:34
zwerchSo, I would do a .inc with my code for all machines, and then a bbappend for each machine, like "linux-imx_%.bbappend" and "linux-rpi_%.bbappend"? Or just one and declare all my machines in it?08:36
ant___remember that the .bbappend will be parsed by anyone having your layer in .conf so even i.e. qemu would get the customization if it isn't done per-machine with override08:36
zwerchOkay, so my suggestion would be working, but is bad practice?08:37
ant___I don't get it yet...what's PREFERRED_PROVIDER_virtual/kernel for your machines?08:37
zwerchI don't know :O08:38
ant___I lost the crystal ball :/08:39
hitlin37Hi, is it possible to read lvds screen vendor from cmdline? i'm using mxc/ldb.c driver on imx608:43
zwerchSorry, I think I don't understand the system completely yet. Just started working with it. I guess I try some things out, thanks to you all anyway.08:43
* nrossi hears the crystal ball smash the ground spilly the magic everywhere08:44
* LetoThe2nd hands nrossi a vacuum cleaner08:44
*** dvhart_ <dvhart_!~dvhart@> has joined #yocto08:58
*** belen1 <belen1!Adium@nat/intel/x-klpsaxhxuiqhpwdo> has joined #yocto09:00
*** belen <belen!Adium@nat/intel/x-ydgcfxkvfihffxls> has quit IRC09:01
*** adelcast <adelcast!~adelcast@> has joined #yocto09:03
-YoctoAutoBuilder- build #310 of nightly-fsl-arm-lsb is complete: Failure [failed BuildImages BuildImages_1 BuildImages_2 UploadToasterEventlog] Build details are at
*** cristianiorga <cristianiorga!~cristiani@> has joined #yocto09:18
*** belen1 <belen1!Adium@nat/intel/x-klpsaxhxuiqhpwdo> has quit IRC09:18
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC09:21
*** belen <belen!Adium@nat/intel/x-jratqxogbcokjvjf> has joined #yocto09:32
*** [w00t] <[w00t]!88a32c66@gateway/web/cgi-irc/> has quit IRC09:33
*** dvhart__ <dvhart__!~dvhart@> has joined #yocto09:35
*** belen <belen!Adium@nat/intel/x-jratqxogbcokjvjf> has quit IRC09:37
*** dvhart__ <dvhart__!~dvhart@> has quit IRC09:37
*** dvhart_ <dvhart_!~dvhart@> has quit IRC09:39
*** belen <belen!Adium@nat/intel/x-lvmyjvapukvizmxd> has joined #yocto09:39
*** vdehors <vdehors!~vdehors@> has joined #yocto09:44
*** zwerch <zwerch!> has left #yocto09:45
*** belen1 <belen1!Adium@nat/intel/x-guxpiziqvalczihb> has joined #yocto09:52
*** rburton <rburton!> has quit IRC09:53
*** belen <belen!Adium@nat/intel/x-lvmyjvapukvizmxd> has quit IRC09:54
*** rburton <rburton!> has joined #yocto09:57
*** dvhart_ <dvhart_!~dvhart@> has joined #yocto09:58
*** dvhart_ <dvhart_!~dvhart@> has quit IRC09:59
*** rburton <rburton!> has quit IRC10:06
*** rburton <rburton!> has joined #yocto10:06
woah_dudeanyone knows how to build Qt 5.4 for Edison?10:10
woah_dudeWhen building stuff like qtdeclarative, qtquick, qtwebkit, make sure that10:11
woah_dudeyou have required PACKAGECONFIG options enabled in qtbase build, see qtbase.inc10:11
woah_dudefor detail.10:11
woah_dudeon the qt meta git i see thus10:11
woah_dudewhat should i do with PACKAGECONFIG?10:11
*** ericbutters <ericbutters!~eric@> has quit IRC10:28
*** JaMa <JaMa!> has joined #yocto10:28
*** ericbutters <ericbutters!~eric@> has joined #yocto10:32
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC10:47
*** nerdboy <nerdboy!> has joined #yocto10:52
*** belen <belen!Adium@nat/intel/x-qrophwiaqqwqlici> has joined #yocto11:01
*** belen1 <belen1!Adium@nat/intel/x-guxpiziqvalczihb> has quit IRC11:02
*** nighty^ <nighty^!> has quit IRC11:08
*** fray <fray!~mhatle@> has quit IRC11:22
*** fray <fray!~mhatle@> has joined #yocto11:22
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto11:36
lpappgood morning11:36
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC11:38
*** CromFr <CromFr!~CromFr@> has quit IRC11:40
lpappI am a bit confused why busybox passwd does not work with daisy. It used to work with dylan.11:43
lpapppasswd: applet not found - is something wrong with the busybox maintainer script?11:43
lpappbusybox pwd for instance works fine.11:44
lpappbut using other applets like that, too.11:44
lpappand this does not seem to be in the migration guide either, so I presume that I am doing something wrong, but what exactly?11:46
lpappbusybox passwd works just fine on my desktop, too.11:46
lpappto be complete, "passwd" does work (without the busybox prefix), but that is not what I am aiming for. I am always trying to be explicit because I always want to use busybox's applet, no matter what.11:47
-YoctoAutoBuilder- build #303 of nightly-ipk is complete: Failure [failed BuildImages Running Sanity Tests_2] Build details are at
*** richb__ <richb__!~richb@> has joined #yocto11:58
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:59
*** woah_dude <woah_dude!~valentin@> has quit IRC12:00
*** limotec-dev <limotec-dev!d5b5327c@gateway/web/freenode/ip.> has quit IRC12:03
*** vmesons <vmesons!> has quit IRC12:03
*** CromFr <CromFr!~CromFr@> has joined #yocto12:07
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC12:15
*** CromFr <CromFr!~CromFr@> has quit IRC12:16
*** CromFr <CromFr!~CromFr@> has joined #yocto12:16
*** nighty^ <nighty^!> has joined #yocto12:26
*** mimetonbo <mimetonbo!ca5311d2@gateway/web/freenode/ip.> has joined #yocto12:27
*** pidge <pidge!~pidge@2a02:8084:0:3000:e557:2f7e:d4ed:92eb> has joined #yocto12:35
*** hamis <hamis!~irfan@> has quit IRC12:36
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto12:36
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:51
-YoctoAutoBuilder- build #298 of nightly-deb is complete: Failure [failed BuildImages Running Sanity Tests_2] Build details are at
hitlin37anyone had a chance to look into the book : ?12:56
hitlin37was interested to read some sample chapter or review before buying12:56
*** mimetonbo <mimetonbo!ca5311d2@gateway/web/freenode/ip.> has quit IRC13:03
mckoanhitlin37: nope, but I suggest this
hitlin37hmm..from the same publisher. btw, the ebook there is more expensive than book13:06
mckoanhitlin37: or if you are interested to BBB rather than Yocto,
mckoanhitlin37: Derek uses Debian though :-(13:07
hitlin37i use debian as well :)13:07
mckoanhitlin37: so this is more than a book, is a complete encyclopedia ;-D13:08
hitlin37its just the software changes so fast that these manual are hard to keep track of updated code.13:09
hitlin37the way you compile yocto 6 months back is probably different than how you would do now...13:10
*** [Sno] <[Sno]!> has quit IRC13:10
*** ncgs <ncgs!> has joined #yocto13:11
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto13:22
*** mago_ <mago_!~mago@> has quit IRC13:23
*** nighty^ <nighty^!> has quit IRC13:33
*** varibull <varibull!> has quit IRC13:36
*** varibull <varibull!> has joined #yocto13:36
*** frsc <frsc!~frsc@> has quit IRC13:42
*** mago_ <mago_!> has joined #yocto13:47
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC13:50
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto13:51
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto13:51
*** mago_ <mago_!> has quit IRC13:55
*** frsc <frsc!~frsc@> has joined #yocto13:55
*** mago_ <mago_!> has joined #yocto13:55
*** wadim_ <wadim_!> has quit IRC13:57
*** AndersD <AndersD!> has quit IRC13:59
*** sm0ketst <sm0ketst!54c63c29@gateway/web/freenode/ip.> has joined #yocto14:01
sm0ketsthi all14:01
*** jku <jku!jku@nat/intel/x-nasdxwuiawyuaqiy> has quit IRC14:01
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC14:04
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-tiozzvppuwrrjvjl> has joined #yocto14:05
*** [Sno] <[Sno]!> has joined #yocto14:06
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto14:08
sm0ketstis it possible to generate the sdk (populate_sdk) with kvm/qemu enabled instead the built qemu? is it better to run kvm in the host with the created rootfs outside the SDK?14:08
*** mago_ <mago_!> has quit IRC14:12
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:15
belenhere is a random question for you all. In the output of bitbake -e, do you ever look at the pre-expansion value of a variable? If so, what for?14:15
*** frsc <frsc!~frsc@> has quit IRC14:16
*** ddom <ddom!> has quit IRC14:22
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC14:22
neverpanicyes, to see how a value ended up in a variable (e.g. via a different variable, etc)14:23
*** vdehors <vdehors!~vdehors@> has quit IRC14:24
*** vdehors <vdehors!> has joined #yocto14:24
*** madisox <madisox!> has joined #yocto14:25
rburtonbelen: see, it's not just me and RP :)14:25
belenneverpanic: good to know. Thanks!14:26
joshuaglbelen: absolutely, yes - same usecase as neverpanic14:26
belenthanks joshuagl14:26
*** mago_ <mago_!~mago@> has joined #yocto14:26
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has joined #yocto14:26
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209> has quit IRC14:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:26
belenrburton: fine, you win ;)14:27
*** milan_ <milan_!~lsb_teste@> has joined #yocto14:29
milan_bluelightning: My bitbake build has compilation error for samhain-server. I see a strange Warning all through [[ "cc1: warning: include location "/usr/include" is unsafe for cross-compilation]]14:31
milan_Any idea why it is picking "/usr/include/sys/socket.h" from system path instead14:32
*** sg-fn <sg-fn!> has joined #yocto14:32
RPbelen: so we're not that strange? :)14:33
belenRP: I wouldn't push it … ;)14:33
RPbelen: ;-)14:36
-YoctoAutoBuilder- build #31 of nightly-world-lsb is complete: Failure [failed BuildImages] Build details are at
*** mago_ <mago_!~mago@> has quit IRC14:38
bluelightningmilan_: it'll be specific to the samhain build system - if it has a configure script, maybe there is a missing argument14:38
bluelightningmilan_: or alternatively it may need patching to use the proper sysroot14:38
*** berton <berton!~fabio@> has joined #yocto14:39
*** munch_ <munch_!> has joined #yocto14:39
*** munch_ is now known as Guest4507314:40
* lpapp is sad:
*** sm0ketst <sm0ketst!54c63c29@gateway/web/freenode/ip.> has quit IRC14:45
*** lamego <lamego!~lamego@> has joined #yocto14:45
*** happycat <happycat!6dbe7afa@gateway/web/freenode/ip.> has joined #yocto14:47
happycatHello !14:47
kergothlpapp: i'm curious, why run busybox directly rather than the symlink?14:48
* kergoth yawns, morning all14:48
*** Jefro <Jefro!> has joined #yocto14:49
happycatI have a question, i am trying to build mplayer2 with directFB support to stream the video into a framebuffer but the sources of directFB are not found, i added the dependancies and enabled directFB in the mplayer2 recipe , am i missing somehing ? like telling where to find the directFB sources ? sorry i am new to yocto i don't know a lot and i didn't find the solution on my own, hope you can help me , thanks !14:50
lpappkergoth: I have just answered that on the mailing list.14:50
kergothah, k14:51
happycatnobody ? :/14:56
AlexVaduvahappycat: well for starters you will need to check the existence of framebuffer support in kernel14:58
AlexVaduvafrom what I know directfb uses it :D14:58
*** belen <belen!Adium@nat/intel/x-qrophwiaqqwqlici> has quit IRC14:58
*** belen <belen!Adium@nat/intel/x-ccwjayrkfbpcguvf> has joined #yocto14:59
*** neur0Fuzzy <neur0Fuzzy!> has quit IRC14:59
happycatHi, yes i made a driver creating three framebuffers, they are working , but then a DMA allow a FPGA to read them and send the output via HDMI port, i know for sure framebuffer are enabled in kernel, (i can run a Qt app and output it to my framebuffer) the problem now is for a video :/ i just need mplayer with directFB support from yocto :/15:00
AlexVaduvaso you have omapfb driver inserted15:01
happycati'm working on a Xilinx board , the framebufferDriver is the one from Xilinx but maybe that's not what you are talking about ?15:01
AlexVaduvaand if you write something from /dev/urandom to /dev/fb* an output appears on your screen?15:01
*** benjamirc <benjamirc!besquive@nat/intel/x-yrgsbbdabpqwuyzo> has joined #yocto15:02
*** Jefro <Jefro!> has quit IRC15:02
happycati can display raw images or start Qt4embeded  applications inside it15:03
AlexVaduvait may only be a mplayer2 problem or a yocto misconfiguration15:03
*** kanavin <kanavin!ak@nat/intel/x-jgxbwhvvahepvaph> has quit IRC15:04
AlexVaduvabut I am not sure15:04
AlexVaduvadid you checked the tasks source code run.do_compile for example or some of the log files?15:04
lpappkergoth: I would very much like the idea of dropping privileges for undedicated applets instead.15:05
kergothyeah.. busybox has that capability built in, not sure why we're not using it, unless its paranoia :)15:06
lpappit is also more future proof as some processes may gain access and then yocto will get in the way.15:06
happycati know mplayer2 has no directFB support on my build (mplayer -vo help list the available outputs but there is no fbdev) , i am trying to build it with directFB but now after 3 days i'm a little lost :/ , yes after enabling directFB support in mplayer2 recipe i have an error ,  the task do_configure executes perfectly but the compile fail because it cannot find directFB sources :/15:06
kergothi know at one point folks used busybox with the separate tinylogin project when they didn't want to use busybox priv dropping, but of course tinylogin is pretty much unmaintained, so i can see why they changed it15:06
kergothstill, you'd htink the split would be a PACKAGECONFIG15:06
AlexVaduvasorry I will be out of office for the rest of the day, but maybe the other guys could help15:07
lpappwell, dropping privileges properly does not sound complex to me.15:07
lpappnot sure what maintenance exactly it requires, but for the time being, I cannot see it a complex patch15:07
happycatOk, thanks for your time :)15:07
lpappof course, this needs to be maintained over time, so is it in Yocto anyway; now it is just IMHO maintained in the wrong place.15:07
*** berton <berton!~fabio@> has quit IRC15:08
AlexVaduvaif you think it would be useful I could take a look in private15:08
AlexVaduvaeither a private chat or an email to vaduva.jan.alexandru@gmail.com15:09
AlexVaduvabut I do not guarantee it :D15:09
kergothlpapp: busybox upstream already supports dropping privs, so it'd just be a matter of teaching the recipe to use it in a single binary rather than two when the user wants that. no patches necessary, other than to the recipe15:09
lpappkergoth: so why is that not done then?15:10
happycatOk i'll mail you tomorow , thanks a lot :)15:10
rburtondoes the splitting predate the priv dropping logic?15:11
rburtonthe splitting logic was merged two years ago now15:11
kergothlpapp: i haven o idea :)15:11
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto15:11
kergothrburton: nope, it's been there for many years15:12
* rburton shrugs15:12
rburtonpatches welcome!15:12
*** happycat <happycat!6dbe7afa@gateway/web/freenode/ip.> has quit IRC15:12
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto15:13
kergothi don't remember why we never used it, i suspect it was just paranoia about making busybox suid15:13
* kergoth shrugs15:13
lpappwell, if it is so, I guess it is just the matter of looking into distros' busybox to see how they implemented it?15:13
lpappI am sure distros like debian looked into it if it is so.15:13
*** benjamirc <benjamirc!besquive@nat/intel/x-yrgsbbdabpqwuyzo> has quit IRC15:14
-YoctoAutoBuilder- build #308 of nightly-multilib is complete: Failure [failed BuildImages_4] Build details are at
*** kanavin <kanavin!ak@nat/intel/x-ikkedfswraaztone> has joined #yocto15:18
*** milan_ <milan_!~lsb_teste@> has quit IRC15:19
*** ddom <ddom!> has joined #yocto15:22
*** nerdboy <nerdboy!> has quit IRC15:22
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto15:22
* nerdboy gets ready for wed gsoc mtg15:24
*** mtetreault <mtetreault!> has joined #yocto15:25
*** benjamirc <benjamirc!~besquive@> has joined #yocto15:27
*** ddom <ddom!> has quit IRC15:28
*** benjamirc <benjamirc!~besquive@> has quit IRC15:31
mtetreaultHi, I'm using the meta-qt5 layer and I am doing a patch (in my own layer using a bbappend) that applies over a meta-qt5 patch. My patch tries to apply before  the meta-qt5 layer's patch therefore, when yocto run my patch it cannot find the file that needs to be patched since it doesn't exist yet. meta-qt5 is a priority 7 and my layer is priority 8. Any idea how I could fix that?15:32
*** ddom <ddom!> has joined #yocto15:36
*** woah_dude <woah_dude!~valentin@> has joined #yocto15:37
*** jc_ <jc_!414d442a@gateway/web/freenode/ip.> has joined #yocto15:38
*** sjolley <sjolley!sjolley@nat/intel/x-uqfnfbxiyhgvimqu> has quit IRC15:39
*** woah_dude <woah_dude!~valentin@> has quit IRC15:41
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:42
*** belen <belen!Adium@nat/intel/x-ccwjayrkfbpcguvf> has quit IRC15:45
*** jchonig <jchonig!> has quit IRC15:46
*** jchonig <jchonig!> has joined #yocto15:48
*** sg-fn <sg-fn!> has quit IRC15:51
*** ddom <ddom!> has quit IRC15:51
*** belen <belen!Adium@nat/intel/x-nhhtpsfjtosbpkau> has joined #yocto15:52
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-tiozzvppuwrrjvjl> has quit IRC15:53
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto15:54
*** mckoan is now known as mckoan|away16:01
*** ant___ <ant___!> has quit IRC16:03
*** TobSnyder <TobSnyder!> has quit IRC16:05
*** benjamirc <benjamirc!~besquive@> has joined #yocto16:05
*** benjamirc <benjamirc!~besquive@> has quit IRC16:05
*** benjamirc <benjamirc!~besquive@> has joined #yocto16:05
*** Jefro <Jefro!> has joined #yocto16:06
*** sjolley <sjolley!sjolley@nat/intel/x-wcmsxzfzhccxgyep> has joined #yocto16:07
*** elmi82 <elmi82!> has quit IRC16:13
gabrbeddDo I file bugs for 'core' on Yocto bugzilla?16:17
gabrbeddor somewhere else?16:17
lpappgabrbedd: you mean openembedded-core?16:18
lpappmeta/, etc?16:18
gabrbeddRight. meta/conf/layer.conf names the layer "core". I found a FTBFS in oprofileui-server_git.bb16:19
lpappyes, that is Yocto bugzilla material, I would say.16:19
gabrbeddlpapp: ok, thanks.16:19
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC16:29
*** belen2 <belen2!Adium@nat/intel/x-ryybhuchkxmvjrxn> has joined #yocto16:29
-YoctoAutoBuilder- build #312 of nightly-world is complete: Failure [failed BuildImages] Build details are at
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto16:30
*** belen <belen!Adium@nat/intel/x-nhhtpsfjtosbpkau> has quit IRC16:31
*** Pixionus <Pixionus!~quassel@unaffiliated/pixionus> has quit IRC16:32
*** Pixionus <Pixionus!> has joined #yocto16:32
*** Pixionus <Pixionus!~quassel@unaffiliated/pixionus> has joined #yocto16:32
*** onoffon <onoffon!~khem@unaffiliated/khem> has joined #yocto16:34
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC16:35
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:36
*** Jefro <Jefro!> has quit IRC16:38
*** Jefro <Jefro!> has joined #yocto16:39
*** dmoseley <dmoseley!> has joined #yocto16:42
*** dmoseley <dmoseley!> has quit IRC16:42
kergothRP: tmp/work/x86_64-linux/opkg-native/1_0.2.2-r0/temp/run.sysroot_stage_all.23387: line 109: sysroot_stage_dirs: command not found — ever seen this? we've seen it in the past, with this or other variables, but have never managed to nail it down. this particular case is dizzy, though.16:45
* kergoth digs through bitbake logs to see if it was fixed at some point16:46
RPkergoth: I just closed a bug about this16:48
RPkergoth: I have a suspicion about where the problem is but no more than that16:49
RPkergoth: have a read of
yoctiBug 6477: normal, Medium, 1.9, richard.purdie, RESOLVED FIXED, do_populate_sysroot failed: sysroot_stage_dir: command not found16:50
RPkergoth: Personally, I think backporting the later codeparser changes may well fix it16:51
*** tsramos <tsramos!tsramos@nat/intel/x-glxydtbwfbreimdm> has joined #yocto16:51
RPkergoth: I think I hit something like this once I started using frozenset so if you wanted to test on the existing code, thats how I'd do it16:51
*** JaMa <JaMa!> has quit IRC16:51
kergothokay, thanks, will try that16:52
RPkergoth: could be something else entirely too, thats just my best guess. I couldn't make it reproduce on master16:54
*** belen2 <belen2!Adium@nat/intel/x-ryybhuchkxmvjrxn> has quit IRC16:59
*** noraply <noraply!> has left #yocto17:01
*** belen <belen!Adium@nat/intel/x-gstcbmtmgceguzmh> has joined #yocto17:01
*** sg-fn <sg-fn!> has joined #yocto17:07
*** sg-fn <sg-fn!> has quit IRC17:11
*** armpit <armpit!~akuster@2601:c:a700:3ba7:256b:16fc:c06a:3641> has joined #yocto17:19
*** woah_dude <woah_dude!~valentin@> has joined #yocto17:26
*** belen <belen!Adium@nat/intel/x-gstcbmtmgceguzmh> has quit IRC17:26
lpapphmm, /sbin is no longer in the PATH by default?17:29
lpappmy executable used to be in /sbin and it was enough to type myfoo with dylan, apparently not with daisy?17:29
kergothshould be for root17:30
*** woah_dude <woah_dude!~valentin@> has quit IRC17:30
lpappit is for root, but not for a regular user like before. Is this expected?17:31
lpappI cannot see it in the migration section.17:31
*** hitlin37 <hitlin37!uid16371@gateway/web/> has quit IRC17:32
*** hitlin37 <hitlin37!uid16371@gateway/web/> has joined #yocto17:32
kergothevery linux distro i've ever used, since 1996, has had the sbin dirs in root's PATH only, not the user, and i end up having to add it to it in  my user's profile17:33
* kergoth shrugs17:33
lpappArchlinux is different, but my concern is breaking compatibility with documenting it.17:34
lpappbut let me put the dylan image back for a quick test.17:34
kergothyeah, that's definitely a concern, compatibility breaks need to be documented somewhere17:39
* kergoth wonders how much work it'd take to get an arch install back to non-systemd again like it was17:40
*** jimBaxter <jimBaxter!> has quit IRC17:43
*** pohly1 <pohly1!> has quit IRC17:44
lpappso I wonder if it is best to extend my exec_exists function with /sbin as fallback that currently check an executable name against the PATH ... or I should extend PATH explicitly.17:47
lpappperhaps the former would leave the system more vanilla.17:47
lpappor would that be bad practice? It is not a yocto question though ^_^17:47
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC17:49
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC18:08
*** anselmolsm_ <anselmolsm_!anselmolsm@nat/intel/x-qgmzqshcmvsxrofo> has joined #yocto18:08
*** RzR <RzR!~RzR@> has quit IRC18:11
*** berton <berton!~fabio@> has joined #yocto18:11
*** jc_ <jc_!414d442a@gateway/web/freenode/ip.> has quit IRC18:12
*** Pixionus is now known as Tejeev18:14
*** Tejeev is now known as Pixionus18:14
*** onoffon <onoffon!~khem@unaffiliated/khem> has quit IRC18:14
*** RzR <RzR!~RzR@> has joined #yocto18:16
*** Jefro <Jefro!> has quit IRC18:18
*** jku <jku!> has joined #yocto18:18
*** richb__ <richb__!~richb@> has quit IRC18:24
denixshould PR server handle AUTOREV-ed packages properly? I'm seeing "Package version went backwards" QA issue and the only change is in git hash AUTOINC+abcdef1234.0, the newer being lower of course18:35
*** belen <belen!> has joined #yocto18:36
*** belen <belen!> has quit IRC18:39
*** belen <belen!> has joined #yocto18:39
*** RzR <RzR!~RzR@> has quit IRC18:41
*** belen <belen!> has joined #yocto18:44
kergothdenix: the AUTOINC is part of SRCPV, which is part of PV, which should be way before the pkgr which the pr server increments, so afaik you'd be best off looking into the autoinc number coming from fetch rather than the pr server, but i may be missing something18:46
denixkergoth: full message - Package version for package ltp-ddt went backwards which would break package feeds from (0:1.0.0-r2+gitrAUTOINC+586d320b13.0 to 0:1.0.0-r2+gitrAUTOINC+2ab12eafbc.0)18:48
*** RzR <RzR!~RzR@> has joined #yocto18:48
denixkergoth: so, yes, pkgr is not the problem - .0 in both cases. but why would it choke to detect lower hash as newer?18:48
*** jbrianceau <jbrianceau!uid10952@gateway/web/> has quit IRC18:49
kergothit shouldn't even get to that point18:49
kergothautoinc should be replaced with an integer, no?18:50
kergothat which point the rest of hte version won't matter, one will be newer earlier on in the ersion string18:50
* kergoth shrugs18:50
*** challinan <challinan!> has quit IRC18:52
* kergoth grumbles18:55
*** Jefro <Jefro!> has joined #yocto18:57
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto18:59
*** belen <belen!> has quit IRC19:01
seebsSo I was trying to debug a thing, and I found a fascinating interaction-of-things.19:11
seebsImagine, if you will, an RPM postinstall script which does something idiomatic like "if [ -n "$D" ] then; exit 1; fi"19:11
seebsNow, what happens if you put "set -x" at the top of the postinstall script?19:11
seebsThe answer is that do_rootfs fails because it sees "exit 1" in the log file output.19:11
denixkergoth: it seems prrserv.bbclass is require for that, though is not mandatory for PR server per se...19:13
rburtonotavio: does libepoxy build on fsl-arm?19:14
kergothhuh, that's interesting. without the autoinc replacement, there'd be no sane upgrade handling for git recipes, you can't tell which commit hash is newer..19:14
kergothseebs: haha, that's amusing. i guess it shoudl be exluding lines with the expected prefix from a set -x19:14
*** woah_dude <woah_dude!~valentin@> has joined #yocto19:15
*** jku <jku!> has quit IRC19:15
*** limbrik <limbrik!~textual@> has joined #yocto19:15
kergothdamnit, how do i get the depends out of an rpm? -qi doesn't seem to show tha tinfo19:16
* kergoth checks the man page19:16
kergothah, -R19:18
*** woah_dude <woah_dude!~valentin@> has quit IRC19:19
*** sg-fn <sg-fn!> has joined #yocto19:21
*** challinan <challinan!> has joined #yocto19:26
*** mtetreault <mtetreault!> has quit IRC19:28
seebsOh, hey. That's a really good idea.19:38
seebsI bet I can make that.19:38
seebswhoops, foot brushed cat by accident, now I must spend an hour comforting her since she is hurt and betrayed.19:38
seebsrpm --qp --requires or something like that?19:38
seebsI look it up periodically.19:39
kergothi have a console-image failing for rpm indicating something is trying to pull in 'libgcc', not 'libgcc-s1', but it doesn't tell me which freaking package wants it19:40
* kergoth find . -name \*.rpm | while read i; do rpm -qRp "$i" | grep -v libgcc.s | grep libgcc && printf "%s\n" "$i"; done19:40
*** hitlin37 <hitlin37!uid16371@gateway/web/> has quit IRC19:42
*** Guest45073 <Guest45073!> has quit IRC19:53
*** Jefro <Jefro!> has quit IRC20:03
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC20:07
denixkergoth: huh, not even INHERIT+=prserv replaces AUTOINC in resulting ipks... what am I missing?20:13
otaviorburton: not yet20:15
otaviorburton: people is working in a fix20:15
rburtonotavio: ok, glad that's known20:15
kergothdenix: not sure. looks like the PR server *is* what replaces it under normal circumstances, but if the pr server isn't used, it should be replaced by package.bbclass, so AUTOINC should never end up in the binary package, PKGV should have it replaced one way or the other, but i could be remembering wrong20:16
RPseebs: don't suppose you had any more thoughts on the  reading hardlinked files created outside pseudo problem?20:16
kergothsadly not very familiar with that code20:16
RPdenix: are you using pr server or not? As kergoth says, AUTOINC shouldn't make it into the final packages20:17
denixkergoth: as I see from package.bbclass, it supposed to replace AUTOINC retrieved from PR server, but I still get packages with AUTOINC in the name/version20:17
seebsBeen thinking about it some. I suppose in theory if we don't care whether we get the database values, we could just not be running under pseudo to begin with, since it's presumably not very relevant.20:17
seebsWe could turn off that warning, but it's fairly often useful as a diagnostic in cases where something is actually wrong.20:18
RPseebs: not true, we care about some set of files, we don't care about some other set20:18
denixRP: I had PRSERV_HOST="localhost:0" only, then added INHERIT+="prserv" too, as I see that code referenced from package.bbclass20:18
RPseebs: the only way I can see to avoid this is to have some kind of path whitelist/blacklist20:18
RPdenix: package.bbclass inherits prserv20:19
*** e8johan <e8johan!> has quit IRC20:20
RPdenix: dizzy again?20:20
denixRP: ok, missed that. explains why nothing changed :) doesn't explain why AUTOINC is not replaced20:20
denixRP: no, not that ancient :) it's daisy20:20
seebsoh, hmm.20:21
seebsWell, my canonical answer would be "if the files are expected to be accessed under pseudo, and are linked to files that pseudo knows about, they should probably be created under pseudo so there's a way to be sure it's not database corruption20:21
denixRP: I do get .X suffix incremented on rebuilds from PR server20:21
seebsBut that would be sort of expensive. Hmm.20:21
seebsAlthough it might actually be cheaper overall because the "wait, that's suspicious" code is sort of expensive too.20:22
RPdenix: ?20:22
RPseebs: I really don't want to mark do_packageinfo as needing to run under pseudo :(20:23
*** benjamirc <benjamirc!~besquive@> has quit IRC20:23
seebsI suppose you could do it for just one recipe, but probably expensive. Why does that recipe have to make hard links to a bunch of pseudo-managed files, and then access the hard links instead of the originals?20:23
RPseebs: its the generic sstate installation code which makes hardlinks as its faster and uses less diskspace20:24
*** [Sno] <[Sno]!> has quit IRC20:24
*** [Sno] <[Sno]!> has joined #yocto20:24
RPseebs: its not so much one recipe as needing to do this for that task in all recipes20:24
seebsI may need to look at the actual specific case to understand this.20:25
denixRP: thanks!! I must move to the latest code base ASAP - tired of stepping on already fixed issues... :)20:25
kergothwhat the hell. i have libgcc in IMAGE_INSTALL, and the libgcc-external recipe has RPROVIDES_${PN} += "libgcc". the resulting libgcc-s1 rpm does provide libgcc. yet an attempt to build the image fails saying it can't find libgcc.20:26
kergothbut only with rpm20:26
seebsSo as I understand it, we have a lot of files which are managed by pseudo. We make hardlinks to those files. Then we end up, running under pseudo, accessing the hardlinks, but we don't care about the ownership-or-mode of the hardlinks, so it'd be fine if pseudo just didn't recognize them?20:26
kergothopkg works fine20:26
RPkergoth: debian.bbclass renaming not being accounted for?20:27
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:27
RPseebs: yes20:27
kergothit's not a mapping / renaming issue, it's not obeying RPROVIDES20:27
seebsWhat are we accessing them for?20:27
kergothit was renamed from libgcc-external to libgcc-s1, but renamed or not, it still rprovides libgcc20:28
seebsAlternatively: What's the smallest/least-dependency recipe that hits this?20:28
RPseebs: we don't care abuout the ownership/mode of them at all ever. There are other files we do want to track under pseudo though20:28
RPkergoth: master? I think there is an open bug about that :(20:28
seebsOhhh, so even the originals, we don't actually care about these particular files?20:28
RPseebs: right20:28
kergothmaster, yeah, just with rpm20:28
kergothk, will check the bugzilla, thanks20:28
kergothverifying with pure upstream without mel now, to check sanity20:29
seebsAny reason not to delete the original links (under pseudo) before people start looking at the hardlinks?20:29
seebsThe only reason it's coming up is that pseudo knows about those inodes under a different path name. If it didn't know, it wouldn't care.20:29
kergothah, right,
yoctiBug 5024: normal, Medium, 1.9 M4, hongxu.jia, IN PROGRESS REVIEW , RPM backend cannot handle RPROVIDES in IMAGE_INSTALL20:29
RPseebs: yes, several good ones20:29
*** berton <berton!~fabio@> has quit IRC20:32
seebsWell, the sanity-checking could definitely be cleaned up some.20:33
*** vmeson <vmeson!~rmacleod@> has quit IRC20:34
seebsAnd it might make sense to have a "careless mode" where some of the database integrity stuff gets skipped.20:35
RPseebs: another option is that we could run some code to tell pseudo "wipe files matching this expression from the db"20:35
seebsOh, hey, that's a thought.20:36
seebsHuh, that's odd.20:36
seebsWhy do I have both -r and -R for chroot?20:36
seebsI am thinking something like20:37
seebspseudo -r /path => drop everything in the database with '/path%' as its path.20:37
RPseebs: we could certainly make that work I think20:37
seebs*pondering* Might make sense to have some kind of 'ignore this' setting, too. Will ponder.20:37
*** rburton <rburton!> has quit IRC20:38
seebsIt wouldn't be horrible, probably, to change the pseudo_diag message there to pseudo_debug(PDBGF_FILE20:38
seebsAFK a bit, will be back later.20:39
*** ant_home <ant_home!> has joined #yocto20:44
denixRP: I also needed this from dizzy -
RPdenix: right, makes sense20:47
*** jkridner|work <jkridner|work!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto20:54
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:55
*** jkridner|work is now known as jkridner20:55
*** benjamirc <benjamirc!~besquive@> has joined #yocto20:56
*** rburton <rburton!> has joined #yocto21:03
*** woah_dude <woah_dude!~valentin@> has joined #yocto21:04
*** rburton <rburton!> has quit IRC21:04
*** j8 <j8!~IceChat9@> has joined #yocto21:06
*** woah_dude <woah_dude!~valentin@> has quit IRC21:08
*** benjamirc <benjamirc!~besquive@> has quit IRC21:29
*** sg-fn <sg-fn!> has quit IRC21:31
*** benjamirc <benjamirc!~besquive@> has joined #yocto21:41
-YoctoAutoBuilder- build #319 of eclipse-plugin-kepler is complete: Failure [failed Building Eclipse Plugin Publishing Artifacts] Build details are at
*** benjamirc <benjamirc!~besquive@> has quit IRC21:49
*** Jefro <Jefro!> has joined #yocto21:59
*** ant_home <ant_home!> has quit IRC22:01
*** benjamirc <benjamirc!~besquive@> has joined #yocto22:04
*** benjamirc <benjamirc!~besquive@> has quit IRC22:07
*** benjamirc <benjamirc!~besquive@> has joined #yocto22:07
*** anselmolsm_ <anselmolsm_!anselmolsm@nat/intel/x-qgmzqshcmvsxrofo> has quit IRC22:18
*** rburton <rburton!> has joined #yocto22:24
*** Jefro <Jefro!> has quit IRC22:35
*** rburton <rburton!> has quit IRC22:37
*** scottrif <scottrif!~scottrif@> has joined #yocto22:38
*** timsche <timsche!> has joined #yocto22:51
*** sjolley <sjolley!sjolley@nat/intel/x-wcmsxzfzhccxgyep> has quit IRC22:51
*** woah_dude <woah_dude!~valentin@> has joined #yocto22:52
*** woah_dude <woah_dude!~valentin@> has quit IRC22:57
*** ntl <ntl!> has quit IRC23:00
*** lamego <lamego!~lamego@> has quit IRC23:06
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto23:06
*** benjamirc <benjamirc!~besquive@> has quit IRC23:10
*** tsramos <tsramos!tsramos@nat/intel/x-glxydtbwfbreimdm> has quit IRC23:12
*** tsramos <tsramos!~tsramos@> has joined #yocto23:13
*** ntl <ntl!> has joined #yocto23:14
*** scottrif <scottrif!~scottrif@> has left #yocto23:16
*** tsramos <tsramos!~tsramos@> has quit IRC23:17
*** sjolley <sjolley!sjolley@nat/intel/x-fcuahzwgomwrnrtf> has joined #yocto23:23
*** nicktick <nicktick!~john@unaffiliated/nicktick> has quit IRC23:26
*** nicktick <nicktick!~john@unaffiliated/nicktick> has joined #yocto23:47
*** madisox <madisox!> has quit IRC23:50
*** Jefro <Jefro!> has joined #yocto23:52
*** sg-fn <sg-fn!> has joined #yocto23:54
*** CoRfr <CoRfr!> has joined #yocto23:55
CoRfrHi, does anyone has an idea on how to prevent a package to end up in sstate ?23:56
CoRfrI have this recipe that generates a file that summarize versions of layers / kernel / ,,, and it's not updated everytime my build runs.23:57
*** ipuustin <ipuustin!~ipuustin@2001:14b8:100:83a6:c23f:d5ff:fe68:ad9a> has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!