Wednesday, 2017-02-08

*** mrpelotazo <mrpelotazo!> has quit IRC00:04
*** brrm <brrm!> has quit IRC00:04
*** lamego <lamego!~jose@> has quit IRC00:05
*** mrpelotazo <mrpelotazo!> has joined #yocto00:07
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:07
*** brrm <brrm!> has joined #yocto00:12
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC00:12
*** lumag <lumag!~lumag@> has joined #yocto00:13
*** lumag_ <lumag_!~lumag@> has joined #yocto00:16
*** lumag <lumag!~lumag@> has quit IRC00:19
*** spierepf <spierepf!18de02de@gateway/web/freenode/ip.> has quit IRC00:26
*** agust <agust!> has quit IRC00:47
*** paulg <paulg!> has quit IRC01:03
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC01:04
*** nighty <nighty!> has joined #yocto01:06
*** bavery_fn <bavery_fn!bavery@nat/intel/x-wcrkoxfizoskoftp> has quit IRC01:07
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto01:08
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC01:17
*** phoo1234567 <phoo1234567!> has quit IRC01:22
*** Bunio_FH <Bunio_FH!> has quit IRC01:29
*** trollkarlen <trollkarlen!~trollkarl@unaffiliated/trollkarlen> has joined #yocto01:30
*** john2 <john2!> has joined #yocto01:46
*** chep <chep!> has quit IRC01:53
*** t0mmy <t0mmy!> has joined #yocto01:56
*** trollkarlen <trollkarlen!~trollkarl@unaffiliated/trollkarlen> has left #yocto02:02
*** chep <chep!> has joined #yocto02:02
*** morphis__ <morphis__!> has joined #yocto02:09
*** morphis_ <morphis_!> has quit IRC02:12
*** ftonello <ftonello!> has quit IRC02:17
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC02:20
*** john2 <john2!> has quit IRC02:35
*** john1 <john1!> has joined #yocto02:36
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC02:40
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC02:50
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto02:57
*** armpit <armpit!> has quit IRC02:59
*** chep <chep!> has quit IRC03:01
*** chep <chep!> has joined #yocto03:08
*** stephano <stephano!~stephano@> has quit IRC03:19
*** manuel___ <manuel___!> has quit IRC03:22
*** fischerm <fischerm!> has quit IRC03:25
*** fischerm <fischerm!> has joined #yocto03:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:43
-YoctoAutoBuilder- build #701 of nightly-mips64 is complete: Failure [failed Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #1075 of nightly-multilib is complete: Failure [failed BuildImages_4 Running Sanity Tests_4] Build details are at
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC03:47
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC03:50
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:53
*** gnac <gnac!> has quit IRC03:56
-YoctoAutoBuilder- build #1057 of nightly-mips is complete: Failure [failed Running Sanity Tests] Build details are at
*** gnac <gnac!> has joined #yocto04:03
*** Bunio_FH <Bunio_FH!> has joined #yocto04:11
-YoctoAutoBuilder- build #1058 of nightly-non-gpl3 is complete: Failure [failed BuildImages] Build details are at
*** neabax <neabax!~neabax@> has joined #yocto04:32
-YoctoAutoBuilder- build #1080 of nightly-x86 is complete: Success [build successful] Build details are at
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC05:39
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto05:43
*** JordonWu <JordonWu!~quassel@> has quit IRC05:43
*** JordonWu <JordonWu!~quassel@> has joined #yocto05:47
*** jwessel <jwessel!~jwessel@> has quit IRC05:52
*** jwessel <jwessel!~jwessel@> has joined #yocto06:00
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto06:03
*** AndersD <AndersD!~anders@> has joined #yocto06:14
*** parrot <parrot!~chankit@> has quit IRC06:15
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC06:36
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto06:37
*** qt-x <qt-x!~Thunderbi@> has joined #yocto06:37
*** m4ho <m4ho!~m4ho@unaffiliated/m4ho> has quit IRC06:42
*** m4ho <m4ho!~m4ho@unaffiliated/m4ho> has joined #yocto06:46
*** bananadev <bananadev!~onlyester@> has joined #yocto06:48
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:52
-YoctoAutoBuilder- build #1085 of nightly-arm is complete: Failure [failed BuildImages_3 Running ESDK Sanity Tests] Build details are at
*** ahmet__ <ahmet__!58cabad9@gateway/web/freenode/ip.> has joined #yocto07:09
ahmet__hi all,07:09
ahmet__I do not want to include "qtimageformats" when compiling yocto in qt, how can I get rid of it.07:09
*** pohly <pohly!> has joined #yocto07:10
*** agust <agust!> has joined #yocto07:16
*** hamis <hamis!~irfan@> has joined #yocto07:22
*** manuel___ <manuel___!> has joined #yocto07:31
*** frsc <frsc!> has joined #yocto07:40
*** rajm <rajm!> has joined #yocto07:52
*** fl0v0 <fl0v0!> has joined #yocto07:55
*** ant_work <ant_work!> has joined #yocto08:02
*** open-nandra <open-nandra!> has joined #yocto08:04
*** jakek_ <jakek_!c39c4de2@gateway/web/freenode/ip.> has quit IRC08:05
*** manuel___ <manuel___!> has quit IRC08:11
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto08:14
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:14
*** mckoan|away is now known as mckoan08:14
*** fl0v0 <fl0v0!> has quit IRC08:15
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:15
*** fl0v0 <fl0v0!> has joined #yocto08:16
*** lukma <lukma!> has joined #yocto08:18
lukmaDear All,08:18
*** florian__ <florian__!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:19
lukmaCan somebody point me the "correct" way of managing the defconfig file for linux-custom recipe08:19
lukmaUp till now I do use the "defconfig" file (which is a simple copy of .config)08:19
lukmait all works but is clumsy to maintain08:19
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has quit IRC08:20
lukmainstead there are also <project-name>. cfg files08:20
lukmawhich looks like a better place for customization08:21
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC08:21
*** jku <jku!~jku@> has joined #yocto08:22
lukmaIs there a way to tell the kernel to use only the "defconfig" (output from make saveconfig) ?08:22
*** Ramose <Ramose!c05e2222@gateway/web/freenode/ip.> has joined #yocto08:23
RamoseSeeing this error message while building gdb , ERROR: gdb was skipped: incompatible with license GPLv2 & GPLv3 & LGPLv2 & LGPLv308:23
lukmaor shall I use some standard defconfig (e.g. /arch/arm/configs/omap2plus_defconfig) ?08:25
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto08:26
*** el_robin <el_robin!> has quit IRC08:27
*** Kakounet <Kakounet!> has joined #yocto08:29
mckoangood morning08:29
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC08:29
*** csanchezdll <csanchezdll!> has joined #yocto08:30
*** el_robin <el_robin!> has joined #yocto08:30
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto08:36
*** joshuagl <joshuagl!~joshuagl@> has joined #yocto08:39
*** phatina <phatina!> has joined #yocto08:41
*** rburton <rburton!> has joined #yocto08:43
*** florian__ is now known as florian08:51
quiteHow feasible would it be to have bitbake/devtool infer BUILDDIR by look for conf/bblayers.conf in cwd or somewhere above cwd? (the way git looks for .git)08:52
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:53
ant_workRP: hi. You helped with klcc.cross. Recipe seems having survived to RSS. Could you pls. check and spot eventual changes to do?
RPant_work: Why does it need eventual changes?08:57
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto08:57
ant_workI've spotted some sysroot preprocess patches08:58
ant_workflowing in the list08:58
RPant_work: a quick glance at what you shared looks like it should be ok08:58
ant_workall seems fine, was just wondering. Thanks :)08:59
ant_workbtw, the issue was that klcc-cross is built per arch but contained machine-specific paths.09:00
ant_workso we did want it to rebuild for each machine09:00
bluelightningquite: at one point it did do something like that, I'm not sure when it broke09:01
bluelightningit was a while ago I suspect09:01
bluelightningquite: devtool should be runnable while not located in BUILDDIR though - are you seeing otherwise?09:02
RPant_work: with rss it has to relocate for each recipe that uses it. Making it machine specific would not serve any purpose really09:03
RPant_work: it will now contain recipe specific paths...09:04
ant_workright..maybe that mangling is not necessary anymore09:04
ant_workit started when we got machine specific sysroot09:05
RPant_work: you probably will need the mangling to change it between the recipe paths09:05
RPant_work: but the good news is the old mangling should work for rss just as well09:05
*** t0mmy <t0mmy!> has quit IRC09:06
ant_workit seems it does indeed09:06
ant_workthe build problems of 4-5 days ago are gone09:06
ant_workI'll do some tests, thanks again09:07
*** dreyna__ <dreyna__!> has quit IRC09:12
rburtonsomething really weird going on with glibc09:13
*** JordonWu <JordonWu!~quassel@> has quit IRC09:13
*** sameo <sameo!~samuel@> has joined #yocto09:15
RPrburton: :(. Widespread or just occasional issues?09:15
rburtonbut i've seen occasional things here too09:16
RPrburton: and you suspect my locale change?09:16
rburtonlike glibc-locale changing its contents dramatically between builds09:16
*** JordonWu <JordonWu!~quassel@> has joined #yocto09:17
*** t0mmy <t0mmy!~tprrt@> has joined #yocto09:18
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto09:20
*** JordonWu <JordonWu!~quassel@> has quit IRC09:20
RPrburton: taking specifically, its odd as if you read, do_stash_locale is added after do_install and before do_package and contains a line to move the gconv files. How do the files therefore still exist at do_package?09:21
rburtonno idea09:21
*** JordonWu <JordonWu!~quassel@> has joined #yocto09:22
*** egavinc <egavinc!> has joined #yocto09:23
nrossianyone know if it is possible to have bitbake handle modifying a tasks depends based on the fetched source?09:34
*** nslu2-log_ <nslu2-log_!~nslu2-log@> has joined #yocto09:36
*** zeddii_home_ <zeddii_home_!> has joined #yocto09:37
*** ZubairLK1 <ZubairLK1!~Thunderbi@unaffiliated/zubairlk> has joined #yocto09:37
*** qt-x1 <qt-x1!~Thunderbi@> has joined #yocto09:37
*** grma <grma!~gruberm@> has joined #yocto09:37
*** tripzero <tripzero!~tripzero@> has joined #yocto09:37
*** justanotherboy1 <justanotherboy1!~mlopezva@> has joined #yocto09:38
*** dl9pf_ <dl9pf_!> has joined #yocto09:38
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC09:39
*** denix0 <denix0!> has joined #yocto09:39
*** joseppc <joseppc!> has joined #yocto09:39
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto09:39
*** radzy_ <radzy_!> has joined #yocto09:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto09:39
*** cordlandwehr <cordlandwehr!~cordlandw@> has joined #yocto09:39
*** reanguia1o <reanguia1o!> has joined #yocto09:40
*** zumbi_ <zumbi_!> has joined #yocto09:40
*** zeenix <zeenix!~zeenix@> has joined #yocto09:40
*** JEEB_ <JEEB_!> has joined #yocto09:41
*** clement_ <clement_!> has joined #yocto09:41
*** mfischer_ <mfischer_!> has joined #yocto09:44
*** smferris_ <smferris_!~smferris@> has joined #yocto09:44
*** mattsm <mattsm!~mattsm@2605:6000:1019:e0:4f9d:12d0:9da7:f27c> has joined #yocto09:44
*** JoiF <JoiF!~jofr@> has joined #yocto09:44
*** chep` <chep`!> has joined #yocto09:44
*** frsc <frsc!> has quit IRC09:45
*** qt-x <qt-x!~Thunderbi@> has quit IRC09:45
*** fischerm <fischerm!> has quit IRC09:45
*** chep <chep!> has quit IRC09:45
*** CoLa|work <CoLa|work!~cordlandw@> has quit IRC09:45
*** clement <clement!> has quit IRC09:45
*** mattsm_ <mattsm_!> has quit IRC09:45
*** zeddii_home <zeddii_home!> has quit IRC09:45
*** radzy <radzy!> has quit IRC09:45
*** smferris <smferris!~smferris@> has quit IRC09:45
*** JEEB <JEEB!~jeeb@unaffiliated/jeeb> has quit IRC09:45
*** justanotherboy <justanotherboy!~mlopezva@> has quit IRC09:45
*** viengelm <viengelm!viengelm@nat/digia/x-sfhcmvptseflmgau> has quit IRC09:45
*** tripzero_ <tripzero_!~tripzero@> has quit IRC09:45
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC09:45
*** ZubairLK <ZubairLK!~Thunderbi@unaffiliated/zubairlk> has quit IRC09:45
*** adelcast <adelcast!~adelcast@> has quit IRC09:45
*** Hauke <Hauke!> has quit IRC09:45
*** zumbi <zumbi!> has quit IRC09:45
*** reanguiano <reanguiano!> has quit IRC09:45
*** denix <denix!> has quit IRC09:45
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC09:45
*** chep` is now known as chep09:45
*** qt-x1 is now known as qt-x09:45
*** denix0 is now known as denix09:45
*** zeddii_home_ is now known as zeddii_home09:45
*** clement_ is now known as clement09:45
*** ZubairLK1 is now known as ZubairLK09:45
*** nslu2-log_ is now known as nslu2-log09:46
*** ed21 <ed21!~Adium@> has joined #yocto09:47
bluelightningnrossi: that would be challenging... we can't adjust task dependencies at the stage where we're actually running tasks, it has to be done beforehand09:49
*** ed21 is now known as ed209:50
bluelightningnrossi: if you can determine what you need to know earlier (e.g. in anonymous python) you might be able to do such a thing, but of course that means fetching during parsing which is ugly09:50
*** nighty <nighty!> has quit IRC09:50
*** Hauke <Hauke!> has joined #yocto09:52
*** frsc <frsc!> has joined #yocto09:52
*** adelcast <adelcast!~adelcast@> has joined #yocto09:53
*** toscalix <toscalix!> has joined #yocto09:54
*** radzy_ <radzy_!> has quit IRC09:58
*** radzy_ <radzy_!> has joined #yocto09:59
*** Ramose_ <Ramose_!c05e2222@gateway/web/freenode/ip.> has joined #yocto09:59
Ramose_How can one compile QT with debug symbols in Yocto ?10:00
*** toanju <toanju!~toanju@> has joined #yocto10:05
*** ahmet__ <ahmet__!58cabad9@gateway/web/freenode/ip.> has quit IRC10:06
*** geoffrey_l <geoffrey_l!> has joined #yocto10:07
*** ahmet_ <ahmet_!58cabad9@gateway/web/freenode/ip.> has quit IRC10:08
*** viengelm <viengelm!viengelm@nat/digia/x-ynrinajpjvyhmjso> has joined #yocto10:27
*** cordlandwehr is now known as CoLa|work10:31
ed2rburton: hi, did you try to merge Kristian's exclude-path patchset? Any problems with it?10:35
*** neabax <neabax!~neabax@> has quit IRC10:35
*** nighty <nighty!> has joined #yocto10:36
RPnrossi: that is indeed challenging and has some determinism issues10:39
*** Ramose_ <Ramose_!c05e2222@gateway/web/freenode/ip.> has quit IRC10:42
*** Ramose <Ramose!c05e2222@gateway/web/freenode/ip.> has quit IRC10:43
RPrburton: ah, there is nothing which says do_package has to run after do_stash_locale10:49
RPrburton: you know, this could even explain the mystery pseudo permissions in the locales10:49
*** present <present!> has joined #yocto10:50
RPrburton: well, there is actually a depends but it also depends on whether it comes from sstate now10:51
iontehi. wonder if someone could help me with a uboot problem:10:58
*** manuel___ <manuel___!> has joined #yocto10:58
iontei've always been building my custom yocto distro in debian and there is no problem with booting10:58
iontebut today i've built the distro on a fedora machine and there was no problems building it. but it fails to boot: it does not find /boot/zimage.10:59
*** ed2 <ed2!~Adium@> has quit IRC10:59
ionteso i entered the uboot console and listed the files on that partition, and it says "unrecognized filesystem type"10:59
*** mythi <mythi!> has joined #yocto10:59
iontethe partition type is "Linux" and filesystem type is ext4.11:01
ionteno problem reading it on my fedora workstation, and the other partition is detected correctly (w95 fat).11:02
*** caiortp <caiortp!~inatel@> has joined #yocto11:03
*** joshuagl <joshuagl!~joshuagl@> has quit IRC11:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:06
*** CTtpollard <CTtpollard!> has quit IRC11:11
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC11:13
*** xulfer <xulfer!> has quit IRC11:14
*** Biliogadafr <Biliogadafr!> has joined #yocto11:15
*** xulfer <xulfer!> has joined #yocto11:17
*** joshuagl <joshuagl!joshuagl@nat/intel/x-wjwevrpkjrkzifxc> has joined #yocto11:18
iontechanging to ext2 worked, but i have no idea why it worked with ext4 when built on debian....11:22
*** Anticom <Anticom!~quassel@> has joined #yocto11:22
*** ed2 <ed2!~Adium@> has joined #yocto11:26
mckoanhow can I get rid of this annoying message: root@beaglebone:~# random: sshd: uninitialized urandom read11:28
mckoanPoky (Yocto Project Reference Distro) 2.1.2 beaglebone /dev/ttyO011:29
rburtonwhat bit?11:36
*** JoiF <JoiF!~jofr@> has left #yocto11:39
*** JoiF <JoiF!~jofr@> has joined #yocto11:40
*** Kakounet <Kakounet!> has quit IRC11:40
*** Xabier <Xabier!c21e5946@gateway/web/freenode/ip.> has joined #yocto11:47
XabierHello everyone11:48
*** Snert <Snert!> has quit IRC11:49
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.> has joined #yocto11:49
*** Snert <Snert!> has joined #yocto11:49
*** bananadev <bananadev!~onlyester@> has quit IRC11:51
*** toanju <toanju!~toanju@> has quit IRC11:56
*** rajm <rajm!> has quit IRC12:01
*** JEEB_ <JEEB_!> has quit IRC12:02
*** JEEB_ <JEEB_!~jeeb@unaffiliated/jeeb> has joined #yocto12:02
*** JEEB_ is now known as JEEB12:02
*** berton <berton!~berton@> has joined #yocto12:06
*** lumag_ <lumag_!~lumag@> has quit IRC12:08
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:08
*** toanju <toanju!~toanju@> has joined #yocto12:09
*** quite <quite!quite@unaffiliated/quite> has quit IRC12:09
*** frsc <frsc!> has quit IRC12:11
*** open-nandra <open-nandra!> has quit IRC12:11
*** quite <quite!> has joined #yocto12:12
*** quite <quite!quite@unaffiliated/quite> has joined #yocto12:12
*** JordonWu_ <JordonWu_!~quassel@> has joined #yocto12:14
*** JordonWu <JordonWu!~quassel@> has quit IRC12:15
*** toanju <toanju!~toanju@> has quit IRC12:28
*** qt-x <qt-x!~Thunderbi@> has quit IRC12:28
*** present <present!> has quit IRC12:32
RPrburton: - I think this might help. Not sure if its everything12:33
*** istarilucky <istarilucky!~rlucca@> has joined #yocto12:35
ant_workrburton: I have a little patch in queue since 25.1. Is the queue so big?12:35
ant_workPatch ID: 136438  It keeps the same typo as the ancestor ;)12:37
rburtonant_work: i tend to hope zedd will review kernel stuff too, but i've just tagged that for merge12:39
*** toanju <toanju!~toanju@> has joined #yocto12:40
ant_workI was before abusing of KERNEL_OUTPUT but today KERNEL_OUTPUT_DIR does not allow that12:41
*** JordonWu_ <JordonWu_!~quassel@> has quit IRC12:47
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC12:48
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto12:48
*** JordonWu <JordonWu!~quassel@> has joined #yocto12:52
*** lumag <lumag!~lumag@> has joined #yocto12:56
*** JordonWu <JordonWu!~quassel@> has quit IRC12:59
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto12:59
*** JordonWu <JordonWu!~quassel@> has joined #yocto13:00
*** Kakounet <Kakounet!> has joined #yocto13:20
-YoctoAutoBuilder- build #454 of nightly-checkuri is complete: Failure [failed BuildImages] Build details are at
jkuhow do I describe a dependency where e.g. openssl:do_cve_check() needs cve-check-tool to be in the recipe-sysroot-native, but I don't want to use DEPENDS (since configure/compile shouldn't need cve-check-tool)13:27
jkuor is that not possible?13:28
joshuaglyou can add a depends to a task13:29
rburtonbut you need to get the recipe sysroot populated13:29
rburtonand a depends won't do that13:29
joshuagloh, I guess all of my oe-core fu is outdated with the addition of rss :-(13:29
rburtonsame here13:29
rburtonRP ^13:29
rburtonalso see mariano's insane.bbclass patch from last night13:30
rburtonwhich has the same problem13:30
joshuagltoo busy to track oe-core :-(13:30
Crofton|workhmm, today need to prepare insane patch checking for which13:30
*** frsc <frsc!> has joined #yocto13:32
RPjku, rburton, joshuagl: do_cve_check[depends] += " cve-check-tool:do_populate_sysroot" ?13:33
joshuaglRP: exactly what I was trying to suggest13:33
rburtonafaik it already does that13:34
jkuno, it's different :)13:34
rburtoni should pay attention more13:34
joshuaglmake me doubt myself rburton, ugh!13:34
jkuI thought I tried that though -- let me retry, it's kind of complex13:34
jkuhuh, it does populate recipe-sysroot-native -- of course I now get a different backtrace but that's something else. Thanks!13:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto13:41
*** JosePerez1 <JosePerez1!~jgperezc@> has joined #yocto13:41
*** JosePerez1 <JosePerez1!~jgperezc@> has quit IRC13:44
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC13:45
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto13:46
*** rajm <rajm!> has joined #yocto13:49
*** aratiu <aratiu!~adi@> has quit IRC13:55
*** AndersD <AndersD!~anders@> has quit IRC13:59
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC13:59
*** soltys <soltys!> has joined #yocto14:00
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:03
*** hamis <hamis!~irfan@> has quit IRC14:03
*** istarilucky <istarilucky!~rlucca@> has quit IRC14:05
*** paulg__ <paulg__!> has joined #yocto14:10
*** lumag <lumag!~lumag@> has quit IRC14:10
*** marka <marka!> has joined #yocto14:10
*** lumag <lumag!~lumag@> has joined #yocto14:11
*** paulg__ is now known as paulg14:13
*** Grynium <Grynium!> has quit IRC14:14
*** Grynium <Grynium!> has joined #yocto14:14
*** istarilucky <istarilucky!~rlucca@> has joined #yocto14:17
*** vmesons <vmesons!> has quit IRC14:19
-YoctoAutoBuilder- build #1059 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** graphiqs <graphiqs!> has joined #yocto14:25
jkurburton:now it fails to dlopen modules (because of course it needs to have loadable modules) from the wrong sysroot. Is there a best practice for this situation?14:27
*** graphiqs <graphiqs!> has quit IRC14:27
jkuI mean, I could add support for a env variable CVE_CHECK_MODULE_DIR ... but is there a way to have this Just Work?14:28
ipuustinjku: compile a static binary ;-)14:29
ipuustinjku: seriously, I think this is actually a pretty common pattern, which many analysis tools might follow.14:29
rburtonjku: there's a bug to let us mark strings in the binary as needing relocation, but it's non-trivial14:30
jkuah right14:30
rburtonjku: add support for an env var, then use create_wrapper14:30
*** lamego <lamego!~jose@> has joined #yocto14:31
jkuyeah I see that in gdk-pixbuf-native... let's see14:31
*** istarilucky <istarilucky!~rlucca@> has quit IRC14:31
rburtonthe relocation thing is neat, but i need to finish my rewrite of the elf parser14:33
rburton(or just copy-paste pyelf into oe core)14:34
*** themikenicholson <themikenicholson!~nic47222@> has quit IRC14:35
*** aV_V <aV_V!~aV_V@> has joined #yocto14:36
pohlyjku: yesterday I asked about a dangling symlink in the sysroot, something with OpenSSL. RP said you had a bug open for that. Do you have the bug number for me?14:37
yoctiBug 10976: normal, High, 2.3 M3, richard.purdie, ACCEPTED , Broken openssl-native symlinks14:38
*** stephano <stephano!~stephano@> has joined #yocto14:39
pohlyjku: yes, that looks like what I ran into.14:40
RPpohly: is a fix14:41
kanavin1rburton: I wonder how desktop distros do the 'cve check' thing14:41
*** ed2 <ed2!~Adium@> has quit IRC14:42
kanavin1maybe they have a human that follows some mailing list, and creates a queue of tasks14:42
*** ed2 <ed2!~Adium@> has joined #yocto14:42
*** istarilucky <istarilucky!~rlucca@> has joined #yocto14:46
*** aratiu <aratiu!~adi@> has joined #yocto14:48
joshuaglhumans + community ( + tools14:50
kanavin1joshuagl: what are the tools?14:52
joshuaglkanavin1: distro specific i.e.
joshuagl"Twice a day a cron job runs that pulls down the latest full CVE lists from MITRE, automatically checks that in into data/CVE/list, and also syncs that file with other lists like data/DSA/list and data/DTSA/list."14:55
rburtonwhich is then manually processed to evaluate what impacts debian14:55
*** berton <berton!~berton@> has quit IRC14:55
kanavin1joshuagl: more importantly, "Processing TODO entries means checking if the problem affects Debian and if so which packages, as well as evaluate their severity. This information is based on research and not just in the CVE description in order to prevent integrating false positives or incorrect data in the security tracker."14:55
kanavin1research, meaning, manual work by a human14:56
*** AndersD <AndersD!> has joined #yocto14:56
joshuaglI put humans first for a reason14:57
kanavin1perhaps we should abandon any kind of automatic check attempts, and do it similarly14:57
RPkanavin1: I don't think we'll escape the need for humans but we can make their work much easier14:58
*** nbigaouette <nbigaouette!> has quit IRC14:58
joshuaglwe don't have as many humans as Debian, either14:59
joshuaglso we need tools to help us as much as possible14:59
kanavin1I wonder who pays the salary of Debian's humans. Canonical?15:00
rburtonthe security team is likely partially canonical employees and partially volunteers15:00
joshuaglan awful lot of DD's are volunteers, aiui15:00
*** nbigaouette <nbigaouette!> has joined #yocto15:00
joshuaglrburton: any idea of numbers and split?15:01
kanavin1rburton: checking CVEs sounds like a job no volunteer would want tbh :)15:01
*** jku <jku!~jku@> has quit IRC15:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:02
sveinseI'm looking at the TipsAndTricks list on the Wiki. Is there a tool in yocto to view specific logs? E.g. to view do_compile from recipe xyz? I find I do a lot of "directory-dancing" to look at specific log and run files?15:02
rburtonjoshuagl: a random security team minutes mail has 8 attendees15:02
rburtonsveinse: i use 'bb' but i think its still broken thanks to tinfoil215:02
rburtonsveinse: 'bb log xyz compile'15:02
*** _Ben <_Ben!81612d46@gateway/web/freenode/ip.> has joined #yocto15:03
sveinserburton: thanks. Otherwise that would be a great contribution to yocto IMHO15:04
rburtonbb is awesome15:05
rburtonkergoth needs to fix it :)15:05
*** berton <berton!~berton@> has joined #yocto15:08
*** bavery_fn <bavery_fn!bavery@nat/intel/x-miykalmjrkoplvvj> has joined #yocto15:14
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:18
kergothrburton: My current thought, though not yet set in stone, is to prototype a new command that's an actual bitbake UI, and implement the commands as proper internal bitbake commands, and ideally move it into the bitbake repo.15:20
kergothbeen meaning for its bits to go upstream for years, this is a good excuse to do something about it..15:20
kergothneed to start a discussion thread on the architecture list15:21
*** berton <berton!~berton@> has quit IRC15:21
*** ed2 <ed2!~Adium@> has quit IRC15:21
*** armpit <armpit!~akuster@2601:202:4001:9ea0:3c4a:f1ac:8237:eb56> has joined #yocto15:22
*** vmeson <vmeson!~rmacleod@> has joined #yocto15:23
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:24
*** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.> has quit IRC15:24
sveinsepity, bb is too new for my krogoth release it seems :( ..or, I've got a poky/bitbake/lib/bb directory. I wonder how I can access it from shell15:26
kergothsveinse: krogoth branch in the bb repo....15:27
kergothnot particularly hard to find15:27
kergothlib/bb is the bb python package used by bitbake, completely different than the tool15:27
sveinseah, sorry, yes15:27
*** ed2 <ed2!Adium@nat/intel/x-dphtjiaeeqneuvel> has joined #yocto15:30
sveinseSorry for asking stupid questions, but how is the bb repo related to the poky repo? Because it contains bb doesn't it?15:30
*** ed21 <ed21!Adium@nat/intel/x-jxyitpqlxfwrkgzo> has joined #yocto15:32
*** ed2 <ed2!Adium@nat/intel/x-dphtjiaeeqneuvel> has quit IRC15:33
*** ed21 is now known as ed215:34
*** berton <berton!~berton@> has joined #yocto15:34
kanavin1sveinse: poky repo is made from several repositories put together, including bb and oe-core repos15:34
kanavin1sveinse: think of poky as a gigantic example of how to make a distribution using bitbake and oe-core15:35
rburtonsveinse: kergoth's bb is entirely unrelated (kergoth/bb on github)15:38
kergothindeed, completely serperate utility, outside of bitbake15:38
sveinseBTW are there any yocto-based distros that don't rely on poky? My impression is that the SoC vendors all tag on to Poky in some form or another (and thus as a user of these SoC package, so are we)15:40
rburtoni'd say that impression is wrong15:41
rburtonpoky is literally oe-core + bitbake + very little anyway15:42
sveinsequite possible15:42
kanavin1rburton: I remember someone on the list saying they're not using poky (was it Philip?)15:43
pohlyOstro OS was not using Poky.15:44
sveinsein our product's imx6 sources we have poky, meta-openembedded, meta-fsl-arm and som machine specific layers15:44
*** ftonello <ftonello!> has joined #yocto15:45
kanavin1rburton: what is the purpose of meta-yocto-bsp?15:47
sveinseBut as na "application product developer"-ish, the lines between yocto, poky and bitbake and the machine layers appears quite blurry. A steep learning curve. I've been doing this for a year on and off, and I still feel I have no firm overview :D15:47
kanavin1rburton: I mean, why is it separate from meta-poky?15:48
kergothdistro and bsp/machine should always be maintained separately15:49
*** JaMa <JaMa!~martin@> has quit IRC15:49
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:51
*** AndersD <AndersD!> has quit IRC15:51
kergothsveinse: yocto is just an umbrella project used for companies to collaborate on bitbake, oe-core, and other components used as the core of their products. poky is an example distro, and also a repository that encompasses the other projects for convenient testing. most distros should *copy* contents from poky if appropriate rather than basing upon it, though some do.15:51
sveinseBut, the bsp/machine binds the distro somehow. At least for the HW architectures we use. E.g. we've wanted krogoth for a long time, but the HW vendor did not support it yet, so we were stuck on jethro.15:51
kergothdistro, machine, and image are key orthogonal axes of the build. if your distro doesnt' work witha ny arbitrary machine, then your distro is broken15:52
rburtonsveinse: that's version, not distro15:52
kergothany machine should work with any distro which should work with any image, generally15:52
kergothsee also, which i wrote a long time ago, and could probably use some updating, but covers this15:52
* kergoth also isn't much of a writer15:53
sveinsegenerally, but it doesn't turn out that pretty all the time. I mean, we are depending on the Yocto version released by the HW vendor, because we don't have the resources to take on the detailed Yocto work15:53
seebsi would say that's pretty well-written, kergoth.15:54
kergothI don't see what using vendor content instead of upstream has to do with machine vs distro15:54
sveinseI visited Electronica this year and asked around HW vendors for Yocto support and for Krogoth. And many answered that they does not support every Yocto release, as Freescale (now NXP) does not release for every Yocto release15:54
kergoththey're two different things, and good vendors maintain that separation15:54
kergothyocto version is a different question, as rburton indicates15:55
*** jku <jku!> has joined #yocto15:55
rburtonsveinse: vendors may not want to track the six monthly releases, that's fine.15:55
rburtonsucks to be a customer if you want a release they don't support, but there's only two choices then15:56
rburton1) use their product anyway 2) don't use their product citing that as a reason15:56
*** dreyna__ <dreyna__!> has joined #yocto15:57
sveinserburton: I'm not a end-user thou. We're making a custom embedded product, in which we use Yocto to build the software. But we're dependent on bsp layers from other vendors15:57
*** jairglez <jairglez!jairdeje@nat/intel/x-tfcndyjxvzsycehq> has joined #yocto15:58
frayevery 6 months for most semi's and board vendors and even customers is too often.. which is why we've got  1 year release cadence..15:58
fraybut what they are telling you is correct.  If the vendor is too old, tell them and go elsewhere.. it is the ONLY way to get themt o change..15:58
fray(WR's release is always on the fall version)15:59
*** zeenix <zeenix!~zeenix@> has quit IRC15:59
fraymorty, jethro, dizzy, dora, danny...15:59
sveinseI'm not complaing per se, I'm just elaborating on the binding between Yocto versions and BSP availability. But as kergoth points out, I'm mixing poky and release versions.16:00
rburtonsure, there's binding between releases and what the BSP vendors support.16:01
fraybut kergoth is 100% correct.. for a particular version.. BSP, distro and image recipes are all orthogonal..  I do often see though BSPs making distribution changes... or adding packages to an image type..16:02
kergothOnly slightly related, but as an OSV, manually determining the delta between the public layers from the hardware vendors and the layers they shipped in their own release BSPs is rather painful16:02
fraythese are all things that should be discouraged..16:02
rburtonBSPs making distro changes is explicitly forbidden by the compliance guidelines16:02
fraykergoth -- in general, we ignore the semi vendor BSP layers as 'less then useful'.16:02
sveinseBut admitedly, and being the Yocto responsible in our company, its hard to distinguish even for me working some time on this. Lots of details.16:02
frayrburton only recently were those guidelines updated.. and a lot of BSPs I've seen still do it16:03
khemrburton: Can you sent more details on glibc issue you are seeing ?16:04
khemrburton: an example that I could reproduce16:05
rburtonkhem: wish i could reproduce :/16:05
sveinseOur HW vendor (which is a custom design), heavily modifies poky and meta-openembedded. And yes, this should not happen in an ideal world, many often take the easy way out and do it still. We as the customer, generally don't care about the intricate detals of how things are solved in yocto. Until it does not work... And it's not easy to police16:05
rburtonkhem: has more failures16:05
fraythe YP compliance guidelines (if followed) can be used as a hammer in those cases..16:05
*** joshuagl <joshuagl!joshuagl@nat/intel/x-wjwevrpkjrkzifxc> has quit IRC16:06
frayrequiring the vendor to adhere to them, and then making them fix it when they don't is a reasonable approach -- and one I often recommend even to our own customers..16:06
kergoththat reminds me, i just noticed a recipe file in our distro layer, need to move that..16:06
fraywe have recipes in our distro -- but they are distribution specific and can be proven to only modify the behavior of the recipes if the distro is enabled..16:07
fray(unfortunately they do change checksums just by being there, but don't change behavior)16:07
fray[we very much limit that behavior, but sometimes it's needed]16:07
khemfray OSVs and OEMs are different set of needs16:07
khemOSVs are benefitted immensely by following the structure since they support many different machines16:07
frayif the guidelines are flawed, lets get them fixed..  there should be no difference in behavior between OSV and OEM (when the OEM is playign OSV)16:08
khemOEMs however supports only a few. there is no clear advantage for them16:08
khemor perceived16:08
kergothit's worth noting that the yocto compliance guidelines aren't just to make sure people are following conventions, they make it easier for *them* to maintain16:08
frayjust to be clear, I'm not saying an OEM needs to do everything an OSV does.. but they do need to follow the guidelines or they're going to causing trouble for their own custoemrs16:08
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto16:09
khemif they are not being followed then either this is not communicated properly or people did not find the advantage as promised16:09
fray(I regularly talk to different OEMs about this, and often times they don't even know what their developers are doing since their external contractors.. which makes it difficult for them to even police them..  mention the compliance guidelines and it helps them reign in their own developers16:09
frayin the cases I know of, "they don't care"  or worse.. they see it as a strategic 'lockin' to NOT follow the rules16:09
fray"if I make the changes here, it will be harder for my customer to move to a different hardware platform"16:10
fray(and yes, I have had an OEM tell me exactly that in the last year)16:10
sveinseI think the difficulties are that we want to get away with as little efforts in Yocto as possible. Our objective is to make our products and care very little in how the lower ends (e.g. Yocto) are implemented. I mean, my resources spendage on Yocto is challenged, because that is not our core competency.16:10
khemthat does happen, however OEMs are getting more aware and want to own the platform16:10
frayproblem is they want to own the platform and put in minimal effort to do that..  competition in this case is good...  locking in customers annoys everyone16:11
khemsveinse: thats right. however you still need to figure out the best use16:11
khemto meet your needs.16:11
*** joshuagl <joshuagl!joshuagl@nat/intel/x-truknmrbksekqymc> has joined #yocto16:11
sveinseIf this is the general attitude, then vendors do get away with non YP compliant editions as long as the end product works16:12
khemsmartly, otherwise it will come in the way, I guess guidelines help with keeping that barrier16:12
sveinseIt not until now, very late in the project, we realize that we should have had quality statements about Yocto16:12
khemalthough they may not be perfect and meet all needs16:12
fraysveinse the whole point of the Yocto Project, compliance guidelines and ecosystem is so you do NOT have to be an expert, but can be a developer user16:12
sveinseBecause we don't have the necessary competency16:12
khemsveinse: if you can enforce compliance as prerequisite e.g. then you can get some work done16:13
frayI think this is something the YP (org) should be promoting.. the compliance is easy to get, and why it's so damned important for everyone to follow the rules16:13
khemin the quality segment. but then for own layers you have to do it yourself16:13
khemfray: again its about communicaton16:14
khemyou can never shove things down anyone's throat16:14
*** zeenix <zeenix!~zeenix@> has joined #yocto16:14
khemthere are compelling alternatives16:14
khemyou have to have a story they can relate their pains to16:14
sveinsekhem: well you can. sort of. In contract engineering it can be set as a requirement16:14
frayno.. but if you tell ODMs to require their OEMs to be Yocto Project compliant.. and the ODMs to tell their OSVs to require it as well.. in the contract16:15
*** JoiF <JoiF!~jofr@> has quit IRC16:15
fraynow the ODM has leverage to make sure everyone follows the basic rules.. (distro/bsp/image being ortogonal)16:15
*** Bunio_FH <Bunio_FH!> has quit IRC16:15
fraywithout people requiring this in a contract the compliance is a nice to have and useful -- but people get burned.. thats the bit that YP (org) should be promoting16:15
*** ed2 <ed2!Adium@nat/intel/x-jxyitpqlxfwrkgzo> has quit IRC16:17
sveinseActually, when I read about distros in Yocto, I start to think that our product should be a distro of its own16:18
*** aV_V <aV_V!~aV_V@> has quit IRC16:19
rburtonsveinse: yes, it should16:19
sveinsehowever that is step 7. I still have to fix this pesky taskhash issue thing first...16:20
khemrburton: I would need to be able to reproduce the glibc issue with locale16:20
khemrburton: if you can tell me look at x ipk, it has this content before and is empty after16:20
khemthen I would be able to help. We need to move to release from snapshot16:21
khemfray: the traditional OSV/ODM/OEM model is also flattened with yocto. many put together their own distros, so there is no one chain16:23
fraybut if the pieces all follow the rules, the problems of conflicts are significantly reduced..16:24
fray(again we're all talking aobut a simple set of rules, not a complex set)...  so there really should not be a burden from the individual developers who produce 'YP compliant components'16:24
khemsveinse: yes, unless you want to hook into pregenerated feeds e.g. say angstrom, you essentially are your own distro16:24
*** Bunio_FH <Bunio_FH!> has joined #yocto16:26
*** frsc <frsc!> has quit IRC16:31
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:34
*** frsc <frsc!> has joined #yocto16:36
*** toanju <toanju!~toanju@> has quit IRC16:36
*** sjolley <sjolley!~sjolley@> has quit IRC16:37
kanavin1RP: should rpm4 use nss or beecrypt?16:39
kanavin1RP: the question came up because nss-native breaks test_sstate_32_64_same_hash, badly16:40
rburtonwell thats a bug16:41
kanavin1rburton: there's some host-specific magic in nss recipe which I didn't look at in detail yet16:41
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC16:42
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto16:42
*** smferris_ <smferris_!~smferris@> has left #yocto16:44
*** smferris <smferris!~smferris@> has joined #yocto16:46
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC16:47
*** rajm <rajm!> has quit IRC16:52
kanavin1rburton: the nss recipe is doing this in do_compile:16:52
kanavin1    make -C ./nss CCC="${CXX} -g" \16:52
kanavin1        OS_TEST=${OS_TEST} \16:52
kanavin1        RPATH="${RPATH}"16:52
kanavin1where OS_TEST is set from TARGET_ARCH16:52
kanavin1any hints how to debug this properly?17:00
*** neabax <neabax!~neabax@> has joined #yocto17:01
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-ruzsmrutgwpvehdk> has joined #yocto17:01
rburtonkanavin1: i must be missing something - how does the test work for any native where the target_arch will be different17:06
rburtoni'd expect natives to be different if the host is different17:06
kanavin1rburton: I would expect this as well, but the test was written by RP himself :)17:07
*** mckoan is now known as mckoan|away17:07
kanavin1rburton: and the comment clearly says: "        The sstate checksums for both native and target should not vary whether17:07
kanavin1        they're built on a 32 or 64 bit system."17:07
rburtonand it passes17:07
* rburton is doing confused face17:08
* kanavin1 is ready for tea+bun17:08
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC17:10
*** armpit <armpit!~akuster@2601:202:4001:9ea0:3c4a:f1ac:8237:eb56> has quit IRC17:11
*** Kakounet <Kakounet!> has quit IRC17:12
khemnative checksum will depend on bitness of build host isnt it17:12
khemnativesdk and target may be not17:13
rburtonexactly, which is why its odd this test appears to work :)17:13
kanavin1RP, where art thou17:13
kanavin1the confusion is spreading17:13
khemrburton: I see that report unpackaged locale files17:15
RPkanavin1: sorry, here now. What was the question?17:15
khemrburton: I wonder how thats happening17:15
*** sjolley <sjolley!sjolley@nat/intel/x-tusnprqlalypcuuw> has joined #yocto17:15
kanavin1RP: please read beginning from "should rpm4 use nss or beecrypt?"17:15
kanavin1RP: I have to run now unfortunately, will be available in an hour or so17:16
rburtonRP:  short version: how does the sstate_32_64 test work when surely native recipes will change if the build host arch changes17:16
RPkanavin1: so the first answer is nss, not beecrypt17:17
kanavin1RP: additionally, how does one debug a recipe that fails to be same (nss-native)?17:17
RPrburton, kanavin1: native sstate checksums are actually BUILD_ARCH independent17:17
*** zeenix <zeenix!~zeenix@> has quit IRC17:17
RPWe account for BUILD_ARCH in the actual locations and filenames, not the checksums17:18
RPThis means we have one native checksum which represents all BUILD_ARCHs and therefore target arch checksums don't change depending on BUILD_ARCH17:18
rburtonbut nss uses BUILD_ARCH directly in the do_compile to pass arguments to make17:18
RPso we just need to whitelist this from the checksum basically17:19
RPsince the filename will in fact catch it17:19
RPwe don't do this globally since we really do want to be careful about this17:19
RPkanavin1: debugging the difference is via bitbake-diffsigs17:20
RPkanavin1: which is basically what that test actually does in many ways17:20
rburtonright fun times17:20
RPkanavin1: If I were debugging it I'd use the test but stop it wiping the tmp stamps directories and then run bitbake-diffsigs on nss-native's two differing stamp files17:21
rburtonwell do_compile just directly uses TARGET_ARCH so in native builds that's BUILD_ARCH, so i guess it just needs a whitelist17:21
RPrburton: BUILD_ARCH is in the base whitelist17:22
RPare you sure its TARGET_ARCH ?17:24
rburton    if [ "${TARGET_ARCH}" = "powerpc" ]; then17:24
rburton    if [ "${SITEINFO_BITS}" = "64" ]; then17:24
RPare you sure its TARGET_ARCH breaking the test?17:24
RPI suspect SITEINFO17:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto17:25
*** ant_work <ant_work!> has quit IRC17:26
*** frsc <frsc!> has quit IRC17:31
*** lumag <lumag!~lumag@> has quit IRC17:37
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:39
*** ed2 <ed2!~Adium@> has joined #yocto17:48
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto17:48
RPkanavin1: so, I hacked the test:, then oe-selftest -r sstatetests.SStateTests.test_sstate_32_64_same_hash, which fails as expected, then $ bitbake-diffsigs tmp-sstatesamehash*/stamps/*/nss-native/3.27.1-r0.do_compile.sigdata.*17:49
RPbasehash changed from 944cc4554a823ba966aeda0ac3d33b79 to 2475db3659c248d81d0e4dadb3c1b4cd17:49
RPVariable SITEINFO_BITS value changed from '32' to '64'17:49
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:50
RPkanavin1: to figure out the dependency chain you can the run bitbake-diffsigs on a single hash to see that its do_compile which has the dependency and do_compile[vardepsexclude] += "SITEINFO_BITS" should fix it17:55
RPrburton: ^^^17:55
*** seanvk <seanvk!~quassel@> has joined #yocto17:58
RPit then breaks in do_install :)17:58
RP(which needs the same fix)17:59
RPafter adding the do_install change, the test passes18:00
*** geoffrey_l <geoffrey_l!> has quit IRC18:01
jkridnercall for participation in #beagle-gsoc:
*** Anticom <Anticom!~quassel@> has quit IRC18:06
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-ruzsmrutgwpvehdk> has quit IRC18:09
*** vmeson <vmeson!~rmacleod@> has quit IRC18:12
*** Bunio_FH <Bunio_FH!> has quit IRC18:15
*** neabax <neabax!~neabax@> has quit IRC18:16
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto18:18
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC18:18
*** jku <jku!> has quit IRC18:21
*** dreyna__ <dreyna__!> has quit IRC18:27
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto18:31
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto18:32
*** TundraMan <TundraMan!~masselst@> has joined #yocto18:33
*** marka <marka!> has quit IRC18:33
*** grma <grma!~gruberm@> has quit IRC18:35
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC18:35
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC18:35
*** robsta <robsta!sid195711@gateway/web/> has quit IRC18:35
*** cmos_dev_ <cmos_dev_!sid200148@gateway/web/> has quit IRC18:35
*** ernstp <ernstp!uid168075@gateway/web/> has quit IRC18:37
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/> has quit IRC18:37
*** smurray <smurray!sid98062@gateway/web/> has quit IRC18:37
*** miceopede <miceopede!sid140053@gateway/web/> has quit IRC18:37
*** paulg <paulg!> has quit IRC18:37
*** Snert <Snert!> has quit IRC18:40
*** tgraydon <tgraydon!~tgraydon@> has joined #yocto18:42
*** jonmason <jonmason!sid36602@gateway/web/> has quit IRC18:45
*** bbhoss <bbhoss!sid18216@gateway/web/> has quit IRC18:45
*** paulg <paulg!> has joined #yocto18:50
*** TundraMan is now known as marka18:53
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC18:54
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto18:54
*** jonmason <jonmason!sid36602@gateway/web/> has joined #yocto18:56
*** toscalix <toscalix!> has quit IRC18:57
*** neabax <neabax!> has joined #yocto19:01
sveinsekergoth: I think your document is great. It describes an overview from the system builder's POV. Gave me a few ideas. Thanks19:05
*** bluelightning <bluelightning!~paul@> has joined #yocto19:05
*** bluelightning <bluelightning!~paul@> has quit IRC19:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:05
*** fl0v0 <fl0v0!> has quit IRC19:09
*** TundraMan <TundraMan!> has joined #yocto19:12
*** vmeson <vmeson!> has joined #yocto19:13
*** jonmason <jonmason!sid36602@gateway/web/> has quit IRC19:14
*** marka <marka!~masselst@> has quit IRC19:15
*** TundraMan is now known as marka19:17
*** dv_ <dv_!> has quit IRC19:17
*** dv_ <dv_!~quassel@> has joined #yocto19:19
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC19:20
*** neabax <neabax!> has quit IRC19:21
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC19:21
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC19:21
*** neabax <neabax!> has joined #yocto19:21
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:23
*** ed2 <ed2!~Adium@> has quit IRC19:23
*** bbhoss <bbhoss!sid18216@gateway/web/> has joined #yocto19:24
sveinseWhat does it imply to be YP compatible? And I'm not refering to the branding aspects, but rather the technical implications19:24
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto19:25
sveinseA test suite? Best pratices? Peer review?19:25
kanavin_homeRP: thanks, will you make a patch?19:25
kanavin_homeRP: what does do_compile[vardepsexclude] do?19:26
*** neabax <neabax!> has quit IRC19:26
sveinsekanavin_home: I believe it excludes the listed variabled from being included in the sstate cache signature calculations, such as DATETIME.19:27
kanavin_homesveinse: not exactly obvious :-/19:28
sveinseI'm trying to fix a problem where this probably will be the remedy19:28
sveinsekanavin_home: my explanation or the naming of the variable?19:31
kanavin_homesveinse: the naming of the variable :)19:32
*** jonmason <jonmason!sid36602@gateway/web/> has joined #yocto19:34
*** neabax <neabax!> has joined #yocto19:34
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto19:36
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto19:39
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto19:40
kergoththe compatible registration has a list of acceptance criteria19:41
kergothi.e. "Are all your publicly accessible layers listed in the OpenEmbedded Layers index (", "Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements?", etc19:42
kergothkanavin_home: vardeps is a list of dependent variables, vardepsexclude is a list of vars to exclude from the list of dependent variables19:43
kergothseems pretty clear to me19:43
* kergoth shrugs19:43
kergothmetadata checksumming uses variable dependency tracking to do the checksum, and the checksum is used in sstate19:44
sveinsekergoth: Is that registration questionare it?19:44
kergothadmittedly it's a pretty low level variable name, but what it does *is* low level, it just affects other layers19:44
kergoth(where layer here refers to concept, not yocto layers :)19:44
*** Snert_ <Snert_!~snert_@> has quit IRC19:44
*** Snert_ <Snert_!~snert_@> has joined #yocto19:45
*** dreyna_ <dreyna_!> has joined #yocto19:50
kanavin_homekergoth: is the variable dependency tracking used somewhere else than in checksumming?19:52
kergothNo, but checksumming is used for more than just sstate.19:52
kanavin_homekergoth: then it could mention 'checksum' in the name19:53
kanavin_homekergoth: as it is, it looks as though compile step itself is affected19:53
kergothi don't see how it's posible to misunderstand 'vardepsexclude' to mean anything other than exclusions from variable dependencies19:53
kergothit's literally the name19:53
kanavin_homekergoth: it's not obvious what 'variable dependencies' are19:54
kergothwhat else would a variable depend on but another variable?19:54
kanavin_homecould be made more clear that it's really for checksumming19:54
kergothmaking a flag name into a sentence really doesn't seem like a great idea for usability, to me19:55
kergothbut by all means submit a bug19:55
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto19:55
kergothit's worth noting that info could well be used for more than just checksumming, it just doesn't happen to do so right now19:55
bluelightningthe other usage is when writing out shell scripts - we need to write out all that will be called19:56
kergothi.e. to enhance how variable expansion works, or limit what varaibles are allowed to be accessed from it19:56
kergothgood point, forgot about that19:56
kergothdetermines what shell fucntions get emitted19:56
kergothand vars19:56
kergoththough the vars are generally covered by exports19:56
kergothflags should indicate precisely what they describe, not necessarily how they're used. it's declarative (ideally) metadata, it's up to bitbake what to do with that..19:57
sveinseI tend to support kanavin_home on this. It is not plainly obvious what it does. You need to be pretty deep into the inner workings of Yocto to understand what it does. For my part this translates to: This is what you have to write to fix tasksel issues...20:01
sveinse*taskhash mismatch issues20:02
*** ant_home <ant_home!> has joined #yocto20:02
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC20:02
bluelightningdealing with taskhash mismatch issues is definitely painful20:02
bluelightningI don't think terminology is the main issue though20:02
sveinseyeah, I'm not out of the woods yet20:02
*** smurray <smurray!sid98062@gateway/web/> has joined #yocto20:03
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto20:03
kergothI'd really like to prototype plugging into bitbake wrappers around the data store which limit access only to the variables bitbake's dependency tracking knows about. then an attempt to access anything else would immediately fail. would at least ensure we don't miss anything. doesn't help with cases where too much is included, but ..20:03
kanavin_homekergoth: the problem is that this stuff ends up in recipes, and someone, somewhere might need to understand what it's there for, often years away from the moment this was placed into the recipe20:04
kergoththat's exactly why it shouldn't refer to specific detaisl of how bitbake uses the info. it's an argument for keeping it as is, IMO. it's info about what variables depend on what. how bitbake uses that 10 years from now might or might not be the same as today20:05
bluelightningkanavin_home: arguably, that's what detailed commit messages (and code comments) are for20:06
*** paulg <paulg!> has quit IRC20:06
kanavin_homebluelightning: more often than not, those do not happen (especially further in the history of oe)20:07
kergothI'd also like to try revamping the checksumming to use expanded values, not unexpanded values. would allow vardep exclusions to propogate through the dependency graph, and better yet, it'd make sure only the results matter, not how we got there20:07
kanavin_homeusually, I just throw away the entire recipe when there's too much undocumented cruft in it, and write a new, simple one, dealing with issues as they occur20:08
bluelightningkergoth: that does sound useful20:08
*** miceopede <miceopede!sid140053@gateway/web/> has joined #yocto20:08
kergothbluelightning: the fact that FOO = "${A}{B}" with A="1" and B="2" results in a different checksum than FOO = "12", when only FOO is referenced, bugs the crap out of me20:08
sveinseI try to comment extensively in the recipe to why a statement is needed. Because in our company, Yocto knowlegde is slim, and the objective for devs to touch recipes is *only* to add support of some piece of software.20:09
kanavin_homesveinse: when I did gobject introspection, I commented pretty much every line and block, because it's a very delicate thing that depends on a lot of things being exactly right20:10
*** armpit <armpit!> has joined #yocto20:10
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto20:12
*** rob-oi-ma <rob-oi-ma!sid155560@gateway/web/> has joined #yocto20:12
kanavin_homehere's an example of how to NOT write a recipe:
*** john1 <john1!> has quit IRC20:14
*** istarilucky <istarilucky!~rlucca@> has left #yocto20:15
*** ernstp <ernstp!sid168075@gateway/web/> has joined #yocto20:15
bluelightningkanavin_home: agreed, that recipe is a mess :(20:15
kanavin_homebluelightning: that's why for openssl 1.1 I'm throwing away all of that and starting from scratch20:16
kanavin_homethe only sane way20:16
sveinseMy favourite is this: -- it's wrond, and we need it in our application20:16
*** present <present!> has joined #yocto20:17
sveinseI started on fixing it, but it turned out the rabbit hole was simply too deep20:17
kergothkanavin_home: ditch the make -e while you're at it, if you would, please :)20:18
kanavin_homesveinse: don't fix, write your own :)20:18
*** Bunio_FH <Bunio_FH!> has joined #yocto20:18
kergothi wonder why the os/arch mapping was done in shell rather than via a bitbake function, that's odd20:18
kergothsad part is it was probably me that wrote that..20:19
rburtonkergoth: ah the wisdom of age20:19
sveinsekanavin_home: I made a small emergency patch, so that it works the way it needs to, but the rest is still not pretty20:19
rburtonkergoth: that's the big downside of working on a project for a decade isn't it20:19
kergothevery time i look at the bitbake codebase it reminds me of how shitty i was at python when we started. thankfully it's evolved a long way since then, but there are still remnants :)20:20
kanavin_homekergoth: make -e?20:20
kergothkanavin_home: see EXTRA_OEMAKE. -e makes env vars override the makefile. it's relying on the fact that vars like CFLAGS are exported into the shell environment rather than passing them in explicitly20:20
kanavin_homekergoth: like I said, openssl 1.1 will not be based on this mess at all20:21
kanavin_homea clean rewrite from nothing20:21
*** pthomas <pthomas!32eb2986@gateway/web/freenode/ip.> has joined #yocto20:21
*** robsta <robsta!sid195711@gateway/web/> has joined #yocto20:21
kergothi know, just a reminder to explicitly pass the variables instead, rather than taking the easy route :)20:21
kergothwas such a mistake doing that.. at the time i just wanted to make most recipes Just Work(™) without needing to explicitly pass things, but that just made it easy for people to stay ignorant of what the underlying makefiles were doing20:22
sveinsekergoth: we all have that, don't we. I found some pieces of code in a build system which I wrote 6 years ago, and I go: What? What stupid &%#.. git blame... Oh, right.20:22
pthomaswhere can I find the build directory for a given package?20:23
*** paulg <paulg!> has joined #yocto20:23
pthomasI'm trying to see what the configure options for strongswan are20:23
*** cmos_dev_ <cmos_dev_!sid200148@gateway/web/> has joined #yocto20:24
rburtonpthomas: tmp/work/[machine tune]/strongswan/[version]20:24
*** caiortp <caiortp!~inatel@> has quit IRC20:25
pthomasyeah I see that, but I don't see any source files or source structure20:26
pthomasdoes this get cleaned up?20:26
kergothpthomas: sources are only extracted if they're needed. that's how all tasks are done.20:26
kanavin_homepthomas: if the build outputs are available from sstate cache, then there will be no unpacked source there20:26
kergothbitbake -c patch or -c configure or whatever if you want to get things populated20:27
kanavin_homedo a bitbake -c clean_sstate strongswan, followed by bitbake strongswan, then you'll have the source, the binaries, the packages, and logs for every step20:28
pthomasI want to see if it's configured with --enable-eap-tls, it's not in the .bb file, but I wasn't sure if it might be default20:30
sveinsewhat is the difference between clean_sstate and cleanall?20:32
bluelightningsveinse: cleanall additionally removes downloaded source20:32
bluelightningdevtool modify recipename followed by devtool configure-help recipename is one way to get the configure options20:33
bluelightning(both the help and what options are currently specified)20:33
lsandovbluelightning: ping20:34
*** paulg <paulg!> has quit IRC20:36
kergothkanavin_home: fyi, cleansstate doesn't guarantee a non-sstate build if sstate mirrors are enabled. it'll just delete the fetched file and re-download it :)20:38
kergothannoying behavior20:39
kergothcan always -C fetch to force the matter instead, though then you'd want to clean first20:39
*** jairglez <jairglez!jairdeje@nat/intel/x-tfcndyjxvzsycehq> has quit IRC20:40
*** berton <berton!~berton@> has quit IRC20:41
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto20:42
*** jairglez <jairglez!~jairdeje@> has joined #yocto20:42
*** alimon <alimon!~alimon@> has quit IRC20:43
*** alimon <alimon!~alimon@> has joined #yocto20:43
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC20:45
*** lsandov <lsandov!~lsandov1@> has quit IRC20:51
*** lsandov <lsandov!lsandov1@nat/intel/x-nufawhcziguitwyk> has joined #yocto20:53
sveinsewhen I use bitbake-diffsigs and get some/other/ with hash xxx changed to yyy, this implies I need to follow the change backward to find the originating difference, right?20:54
kergothmost likely, yes20:55
kergotheasier to use -S printdiff if it's workable for your case20:55
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC20:55
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC20:56
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:00
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto21:05
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC21:06
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC21:07
*** joseppc <joseppc!> has joined #yocto21:09
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto21:09
*** paulg <paulg!> has joined #yocto21:16
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC21:16
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto21:16
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC21:24
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC21:25
*** voltbit <voltbit!> has joined #yocto21:27
sveinsekergoth: os -S printdiff supposed to print anything?21:27
sveinse(wiping tmp and starting over...)21:28
*** lumag <lumag!~lumag@> has joined #yocto21:35
*** lumag_ <lumag_!~lumag@> has joined #yocto21:39
*** lumag <lumag!~lumag@> has quit IRC21:42
sveinseNow I can't seem to get the taskhash failed failure at all...21:43
*** neabax <neabax!> has quit IRC21:59
*** neabax <neabax!> has joined #yocto22:00
*** mattsm <mattsm!~mattsm@2605:6000:1019:e0:4f9d:12d0:9da7:f27c> has quit IRC22:01
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto22:01
*** mattsm <mattsm!> has joined #yocto22:03
sveinseI noticed something when using bitbake-diffsigs, that the paths for the recipes have changed. It uses a path which is not local to this build, but belongs to another build. I've verified that the configuration has no cross links. Leakage somehow via the sstate?22:04
*** pohly <pohly!> has quit IRC22:04
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto22:05
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC22:05
bluelightningsveinse: is bitbake-diffsigs actually reporting that as a difference, or is it just incidental in the output?22:07
*** clsulliv <clsulliv!~clsulliv@> has quit IRC22:08
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC22:09
sveinsebluelightning: Its like /path/to/ with hash xxxx changed to /antother/path/ with hash yyyy22:09
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto22:09
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC22:10
sveinseI ran two consecutive runs of bitbake. Both successful. And still bitbake-diffsigs reports this22:10
bluelightningsveinse: the function's hash should not depend on the recipe path - is that really all it's saying or is there more to the message?22:11
sveinsebluelightning: its quite extensive:
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto22:14
bluelightninghmm, there's some magling of the paths there I see22:16
bluelightningwhat about the diff for do_rootfs?22:17
sveinseYeah, and the path on line 2 does not belong to this build, line 4 is22:17
bluelightningsure... I'd ignore that part for now, it seems to be indicating that it's the do_rootfs task as actually having changed22:18
sveinsebluelightning: The thing is that I am chaining images, initrd into image, image into installer image, so it very probably some DATETIME thing which leaks. Its just very hard to find. Here is a small snippet of the setup:
sveinseIn this paste, it is always and only c-image.do_rootfs_wicenv that fails iirc22:25
*** joshuagl <joshuagl!joshuagl@nat/intel/x-truknmrbksekqymc> has quit IRC22:25
*** voltbit <voltbit!> has quit IRC22:29
MarexHi! I ran into an issue with poky 2.2.1 when building for aarch64 with multilib22:30
Marexusing the 32bit toolchain, if I prepare a C file which includes <signal.h> , the kernel's sigcontext.h is pulled in , but that contains __uint128_t type which the 32bit compiler doesn't support22:31
bluelightningsveinse: hmm, can't see anything immediately wrong with that...22:31
Marexanyone saw that before ?22:31
*** present <present!> has quit IRC22:42
sveinsebluelightning: just parsed and diffed the long list of packages that diffsigs claims changed, and they are equal!22:43
*** Biliogadafr <Biliogadafr!> has quit IRC22:44
*** neabax <neabax!> has quit IRC22:44
*** lamego <lamego!~jose@> has quit IRC22:48
sveinseI wish I could inspect the temp/ (the logs) directory of the objects fetched from the sstate cache22:50
*** sjolley <sjolley!sjolley@nat/intel/x-tusnprqlalypcuuw> has quit IRC23:00
*** bfederau <bfederau!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto23:01
*** bfederau <bfederau!> has joined #yocto23:01
*** marka <marka!> has quit IRC23:03
*** dreyna_ <dreyna_!> has quit IRC23:12
*** dreyna_ <dreyna_!> has joined #yocto23:16
*** groleo <groleo!> has quit IRC23:22
*** rburton <rburton!> has quit IRC23:23
*** groleo <groleo!> has joined #yocto23:28
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC23:33
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto23:37
*** nighty <nighty!> has quit IRC23:41
*** trollkarlen <trollkarlen!~trollkarl@> has joined #yocto23:41
*** trollkarlen <trollkarlen!~trollkarl@> has quit IRC23:43
*** trollkarlen <trollkarlen!~trollkarl@unaffiliated/trollkarlen> has joined #yocto23:43
*** sjolley <sjolley!~sjolley@> has joined #yocto23:46
*** sjolley1 <sjolley1!~sjolley@> has joined #yocto23:47
*** paulg <paulg!> has quit IRC23:47
*** sjolley <sjolley!~sjolley@> has quit IRC23:50
*** seanvk <seanvk!~quassel@> has quit IRC23:54
*** ant_home <ant_home!> has quit IRC23:54

Generated by 2.11.0 by Marius Gedminas - find it at!