**** BEGIN LOGGING AT Thu Jul 06 03:00:03 2017 Jul 06 11:30:24 does anyone *actually* use the gnome2 recipes in meta-gnome? Jul 06 12:24:56 I'd say that you can check in the downloads.yoctoproject.org logs Jul 06 12:25:17 many people are using poky Jul 06 13:57:58 rburton: we only use a few pkgs from meta-gnome: dconf evince gtksourceview gvfs libgnome libgtop libwnck libwnck libxklavier metacity Jul 06 13:58:25 vmeson: i was thinking about ripping out all the old gnome2 bits to a meta-gnome2 layer Jul 06 13:58:35 which i can then throw in the bin, i mean find a maintainer for. Jul 06 13:58:58 meta-oe is getting huuuuge and its not helped by maintaining recipes for decade-old DEs Jul 06 14:12:22 rburton: works for me. Jul 06 14:13:12 rburton: have you been building target packages with meson in oe yet or is the meson support mainly for devtool Jul 06 14:14:47 for those who may not have heard: systemd, Xorg, other projects have plans to ditch autotools for meson. Jul 06 14:16:12 * vmeson searches the lists for meson and actually reads the commit logs Jul 06 14:33:16 vmeson: for target Jul 06 14:33:22 no gi or gtkdoc working yet Jul 06 14:35:06 anything replacing autotools would be an impovement Jul 06 14:37:28 well you say that Jul 06 14:37:36 meson's gtkdoc and g-i support doesn't like cross yet Jul 06 14:38:36 me for one doesn't hold any grudge against autotools. they're far from being perfect, sure - but they work for my cases. Jul 06 14:39:26 the major problem with make/autotools is rather that too many people hardcode stuff into them Jul 06 14:40:24 LetoThe2nd that means you have yet seen how autotools are used in different packages Jul 06 14:40:55 I have wasted good amount of my life in chasing autotools files to find stupidities especially in cross builds Jul 06 14:41:14 its an AI system designed ahead of its time Jul 06 14:43:22 onoffon: i totally agree that its easy to get things wrong Jul 06 14:44:24 but my personal opinion is that its just like any advanced technology. easily misused and then blamed where the error actually is the user. Jul 06 14:44:31 (think C++) :-) Jul 06 14:44:36 in OE we spend good 30% time in doing autoconf stuff in autotooled packages Jul 06 14:45:15 so if we have a lot of autotooled packages and use something else we can also improve build times Jul 06 14:45:31 moving gettext to meson would be amazing for build performance Jul 06 14:45:56 rburton what do we do about webkitgtk :) Jul 06 14:46:02 burn it to the ground Jul 06 14:46:42 YAY LETS GO BURN SOMETHING! Jul 06 14:47:37 * onoffon plans bike today - burn some fat Jul 06 14:48:13 onoffon: that was my morning after last nights epic burger :) Jul 06 14:50:30 good deal Jul 06 14:52:53 not sure i did enough Jul 06 14:54:50 I better do it before sun gets red in anger Jul 06 14:59:20 rburton: do we run testimage for musl on AB yet ? Jul 06 14:59:48 rburton: with my latest pull, it should work well for musl too. for core-image-sato Jul 06 15:00:20 rburton: if we dont do it then I would suggest to add it to verification tasks for musl as well after this pull Jul 06 15:19:19 khem: https://autobuilder.yocto.io/builders/nightly-musl/builds/327 says yes Jul 06 16:15:30 rburton: do we build core-image-sato ? Jul 06 16:15:42 rburton: we should change that to core-image-sato-sdk please Jul 06 16:15:49 so we build more stuff Jul 06 16:17:26 the iptables test issue I found was during core-image-sato-sdk -ctestimage Jul 06 16:42:32 khem: can you file a bug? off for a bit now Jul 06 20:26:45 khem: trying out devtool on dart kernel :-) Jul 06 20:38:33 cbrake: cool Jul 06 21:10:47 * cbrake wonders how devtool knows when to build (sources have changed ...) Jul 06 21:18:56 somehow, devtool build seems to be detecting when I've made changes in the workspace/sources/ directory and runs do_compile .... Jul 06 21:19:03 wonder how it does that ???? Jul 06 21:22:34 cbrake: it's not devtool exactly, but it's the externalsrc class it's using, and iirc it checksums the source tree Jul 06 21:22:40 check the class for details Jul 06 21:29:09 thats right Jul 06 21:33:30 hi, I'm trying to build an image for an intel i5 using morty and MACHINE=intel-core2-32. I dd'ed the resulting core-image-full-cmdline.hddimg to a pendrive and tried booting from it. I get grub's menu but regardless what I choose the box reboots itself. are there premade images or a public toaster I could use for testing if it's something on my build? Jul 06 21:46:17 mnemoc: did you use https://www.yoctoproject.org/downloads/bsps/morty22/intel-core2-32-0 Jul 06 21:50:54 khem: from git Jul 06 21:56:50 Try release Jul 06 21:57:13 ok Jul 06 22:06:33 it looks like srctree hashes some stuff from git if a .git dir exists, so that is probably pretty efficient. Pretty neat! Jul 06 22:07:14 yes, how did you set the tree up ? Jul 06 22:07:24 did you use devtool modify -x ? Jul 06 22:08:11 I wrote a little repo manifest Jul 06 22:08:40 sorry that was a question for cbrake Jul 06 22:08:58 aaaaaaarg! the image from the release reboots my box :-/ Jul 06 22:09:05 too* Jul 06 22:09:58 khem: devtool modify -s --keep-temp virtual/kernel Jul 06 22:10:04 -x is the default I think Jul 06 22:10:22 -s builds in SRC tree, so makes things easier for kernel dev Jul 06 22:10:32 I have two different intel-based industrial computers here and both get rebooted :-/ Jul 06 22:10:41 not sure what --keep-temp does, but thought it looked like a good thing :-) Jul 06 22:11:22 good stuff! Jul 06 22:12:53 khem: is there automation for capturing the changes in the workspace tree as patches? Jul 06 22:15:53 yes, devtool update-recipe or finish Jul 06 22:15:56 afaik anyway Jul 06 22:16:02 see devtool —help for its command list Jul 06 22:20:07 cbrake: right -x is default now Jul 06 22:21:07 thanks -- will resume this tomorrow Jul 06 22:37:35 khem: for the records, the images from https://www.yoctoproject.org/downloads/bsps/morty22/intel-core2-32-0 immediately reboot my target after grub's menu. genericx86 otoh works fine. I had the same issues building genericx86 with meta-intel enabled, I'll kill that layer and test again Jul 06 23:26:31 mnemoc: ok **** ENDING LOGGING AT Fri Jul 07 03:00:02 2017