**** BEGIN LOGGING AT Wed Sep 06 03:00:01 2017
Sep 06 10:34:43 <bubu> xx
Sep 06 10:34:47 <TT2> cc
Sep 06 16:04:28 <fray> Hmm.. just found a .specfile generation bug..  build libmtp  and somehow it generates -two- 'mtp-tools' sections.. which causes RPM to fail
Sep 06 16:06:33 <fray> debian rename class renamed 'libmtp-bin to 'mtp-tools'  which collided with an -existing- mtp-tools..
Sep 06 16:07:16 <kergoth> interesting
Sep 06 16:07:36 <fray> PACKAGES="libmtp-common libmtp-runtime mtp-tools libmtp-dbg libmtp-staticdev libmtp-dev libmtp-doc libmtp-locale libmtp-bin libmtp"
Sep 06 16:07:47 <fray> in the generated spec file, it produced: (or well tried to)
Sep 06 16:08:13 <rburton> ERROR: gst-player-0.0.1+gitAUTOINC+ee3c226c82-r0 do_prepare_recipe_sysroot: The file /usr/lib64/gstreamer-1.0/libgstrawparse.so is installed by both gstreamer1.0-plugins-bad and gstreamer1.0-plugins-base, aborting
Sep 06 16:08:15 <rburton> \o/
Sep 06 16:08:48 <fray> libmtp-common libmtp-runtime mtp-tools libmtp-dbg libmtp-staticdev libmtp-dev libmtp-doc libmtp-locale mtp-tools libmtp9
Sep 06 16:09:12 <fray> so if you line them up, debian rename broke it
Sep 06 16:09:42 <fray> ...so what is the right behehavior here?  debian renmae detects this and aborts the rename if it matches an existing 'PACKAGES' entry?
Sep 06 16:09:47 <fray> or do we merge the entries?
Sep 06 16:11:26 <fray> wait.. no it's NOT debian rename!
Sep 06 16:11:30 <fray> PKG_${PN}-bin = "mtp-tools"
Sep 06 16:11:38 <fray> it is a recipe bug.. never mind.. (should have looked there first
Sep 06 16:11:53 <dv_> rburton: seems like a mix of 1.10 and 1.12
Sep 06 16:12:10 <dv_> IIRC rawparse was moved to -base in 1.12
Sep 06 16:12:11 <rburton> dv_: yes.  the \o/ is because a message was printed, and not a stack trace
Sep 06 16:12:17 <dv_> oh!
Sep 06 16:12:20 <dv_> then:
Sep 06 16:12:21 <dv_> \o/
Sep 06 16:12:22 <dv_> :)
Sep 06 16:12:46 <rburton> kept on hitting that during the 1.12 upgrade testing as files moved around and had to play "guess where the file went"
Sep 06 16:18:47 <kergoth> fray: maybe we should have a sanity check when PKG_ is applied to prevent clashes with existing packages entries in general, whether PKG is set by debian rename or manually..
Sep 06 16:19:32 <fray> ya.. I was thinking the same, not sure where to put it.. package qa maybe?  (not sure when the debian rename runs)
Sep 06 16:23:30 <kergoth> yeah, package qa seems reasonable
Sep 06 16:23:35 <kergoth> looks like runtime_mapping_rename adjusts rdepends/etc to match, but the actual package name usage is in the do_package_write_ functions for each packaging method
Sep 06 16:23:53 <kergoth> iirc qa runs after do_package and before the write
Sep 06 16:24:26 <fray> I'm not going to have any time over the next few weeks to implement the check.. but I do think we need it to stop these types of things
Sep 06 16:24:30 <kergoth> course this is more metadata than anything, could technically warn about it earlier on with a very early packagefunc
Sep 06 16:24:42 <kergoth> yeah, open a bug for tracking?
Sep 06 16:24:52 <kergoth> kind of surprise thi shasn't bitten us before
Sep 06 16:25:01 <kergoth> but i feel that way about half the bugs that come up, i swear
Sep 06 16:25:20 <fray> check should be easy.. for each in PACKAGES ; create a translated list..  check if the translated name shows up more then once
Sep 06 16:25:31 <fray> (translated == PKG_..)
Sep 06 16:41:27 <fray> kergoth bugzilla 12060 if you care..
Sep 07 02:30:17 * armpit scratches head over pyro meta-or
**** ENDING LOGGING AT Thu Sep 07 03:00:00 2017