16:00:09 <geppetto> #startmeeting fpc
16:00:09 <zodbot> Meeting started Thu Oct 13 16:00:09 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:09 <zodbot> The meeting name has been set to 'fpc'
16:00:09 <geppetto> #meetingname fpc
16:00:09 <zodbot> The meeting name has been set to 'fpc'
16:00:09 <geppetto> #topic Roll Call
16:00:36 <orionp> hello
16:00:46 <fale> hello
16:01:05 <geppetto> #chair orionp
16:01:05 <zodbot> Current chairs: geppetto orionp
16:01:10 <tibbs> Guys, I'm having some system issues.
16:01:19 <geppetto> #chair tibbs
16:01:19 <zodbot> Current chairs: geppetto orionp tibbs
16:01:22 <geppetto> Ok
16:02:15 * Rathann here
16:02:17 <tibbs> It's working now but X keeps hanging so I might get kicked out.  You won't notice because znc is running on a separate machine but I don't know how much I'll be around.
16:02:30 <geppetto> ok
16:03:06 * limburgher here
16:03:10 <Pharaoh_Atem> hey all
16:03:20 <Pharaoh_Atem> brb ~5 min
16:03:34 <geppetto> #chair limburgher
16:03:34 <zodbot> Current chairs: geppetto limburgher orionp tibbs
16:03:43 <geppetto> #chair Rathann
16:03:43 <zodbot> Current chairs: Rathann geppetto limburgher orionp tibbs
16:04:57 <geppetto> #chair racor
16:04:57 <zodbot> Current chairs: Rathann geppetto limburgher orionp racor tibbs
16:05:17 <geppetto> #topic Schedule
16:05:18 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/WASCNXSJHWVYGM2CZFW4UXLINCRXBCRD/
16:05:34 <geppetto> #topic #655  meson buildsystem guidelines
16:05:39 <geppetto> .fpc 655
16:05:41 <zodbot> geppetto: #655 (meson buildsystem guidelines) – fpc - https://fedorahosted.org/fpc/ticket/655
16:07:36 <geppetto> These seem fine to me
16:08:12 <ignatenkobrain> hey everyone
16:08:18 <geppetto> hey
16:08:22 <limburgher> I concur.
16:08:35 <orionp> so ninja builds constructed with meson need a special arg?  -C %{__builddir}  ?
16:08:55 <ignatenkobrain> orionp: meson is always out-of-tree builds
16:08:57 <orionp> Don't like the %__sourcedir and %__builddir names
16:09:00 <ignatenkobrain> while ninja itself can be anything
16:09:10 <ignatenkobrain> orionp: why?
16:09:21 <orionp> too generic
16:09:26 <tibbs> ignatenkobrain: Sorry, I just didn't have any time to go over these yesterday
16:09:38 <ignatenkobrain> orionp: actually I would like in future to use same for cmake
16:10:06 <ignatenkobrain> because current %make_build/%cmake can be written in better way
16:10:20 <ignatenkobrain> btw, this is what SUSE does
16:10:35 <ignatenkobrain> https://build.opensuse.org/package/view_file/openSUSE:Factory/cmake/cmake.macros?expand=1
16:10:48 <tibbs> I don't have any problem if we want to define generic macros for these, but they probably shouldn't be part of these guidelines.
16:11:04 <ignatenkobrain> tibbs: agree, but at this moment, it's used only in meson
16:11:44 <tibbs> Doesn't mean that it should start there.
16:11:53 <ignatenkobrain> at this moment, don't see any other place where it can be written
16:11:59 * ignatenkobrain is open for suggestions
16:12:24 <tibbs> In the regular guideline page documenting various macros.
16:12:27 <tibbs> I'm not asking you to do it.
16:13:15 <tibbs> I'm just saying that FPC should probably decide if this shoud go in as something meson-specific or if these macros are something that should be used generally.
16:13:36 <tibbs> if the former, they should be renamed.  If the latter then we'll make that happen.
16:13:50 <tibbs> What defines them currently?
16:13:52 <Rathann> to be honest I don't like the redirection
16:13:54 * ignatenkobrain would be happy if it will be generic and used for cmake/meson/whatsoever_we_will_add
16:14:03 <Rathann> meson_build -> ninja_build -C builddir
16:14:06 <ignatenkobrain> tibbs: macros.meson
16:14:12 <ignatenkobrain> Rathann: why?
16:14:22 <ignatenkobrain> you want each packager to write this boilerplate part?
16:14:44 <tibbs> ignatenkobrain: Have a URL for that file?
16:14:52 <ignatenkobrain> tibbs: yup
16:15:03 <ignatenkobrain> tibbs: https://github.com/mesonbuild/meson/blob/master/data/macros.meson
16:15:05 <tibbs> Sorry, I didn't see it in the ticket.
16:15:18 <ignatenkobrain> np
16:15:32 <tibbs> I would not expect to see that upstream.
16:15:34 <Rathann> ignatenkobrain: why are you using %{__builddir} at all?
16:16:16 <tibbs> Personally if these are to be generic, I still wouldn't use __sourcedir and __builddir.  Double underscores should be for internal magic macro stuff.
16:16:30 <racor> ignatenkobrain: I am with Rathann, here. Yes, IMO, this stuff seems simple enough, to not justify macros.
16:16:42 <tibbs> And they really, really look suspiciously like _sourcedir and _builddir.
16:17:00 <ignatenkobrain> tibbs: I'm one of the upstream
16:17:07 <tibbs> To which they have zero relation, and if you mistype them then, well, that's bad.
16:17:46 <Rathann> if I'm reading this correctly, meson_build can be replaced with  %{_bindir}/ninja-build -v %{?_smp_mflags} -C .
16:17:51 <Pharaoh_Atem> back
16:18:16 <ignatenkobrain> Rathann: %ninja_build %{_ninja_opts_common} -C %{_target_platform}
16:18:34 <Rathann> ignatenkobrain: do you foresee complicated stuff to be added into __ninja_opts_common?
16:18:48 <ignatenkobrain> -v %{?_smp_mflags} <-- __ninja_opts_common
16:18:58 <Rathann> if not, then it doesn't justify factoring out two short options
16:19:24 <Rathann> where did _target_platform come from all of a sudden
16:19:40 <ignatenkobrain> Rathann: it's more-or-less unique name for builddirs
16:19:40 <Rathann> it's nowhere to be found under the links you posted
16:19:49 <orionp> I have no problem with the current %ninja_build, etc.  Just like %make_build, %make_install
16:20:28 <Rathann> orionp: at least make_build is shorter than make DESTDIR=... %{?_smp_mflags}
16:20:35 <Rathann> this isn't shorter
16:20:59 <Rathann> so what's the advantage apart from visual consistency?
16:21:13 <ignatenkobrain> Rathann: if you will look at %ninja_install you will see its shorter
16:21:20 <racor> orionp: I also have problems with these. They do not serve any useful purpose. All they to is to obfuscate simple things.
16:21:32 <tibbs> Rathann: Well, if shorter was the only criterion then we certainly wouldn't have %_sysconfdir.
16:21:45 <Rathann> yeah and it will be never defined to something else
16:21:53 <ignatenkobrain> http://pkgs.fedoraproject.org/cgit/rpms/ninja-build.git/tree/macros.ninja
16:21:57 <Rathann> so I've started using /etc directly quite some time ago
16:22:11 <Rathann> *I started
16:22:23 <orionp> heresy! :)
16:22:32 <Rathann> ignatenkobrain: ok, I'll buy the _install macro
16:22:35 <tibbs> Rathann: You may recall I managed to get our guidelines changed to actually allow that.
16:22:44 <ignatenkobrain> I could replace %meson_* stuff with nothing, but then
16:22:50 <ignatenkobrain> in EACH spec you have to:
16:22:55 <ignatenkobrain> 1. create builddir
16:22:58 <ignatenkobrain> 2. change dir
16:23:03 <ignatenkobrain> 3. run %meson ..
16:23:08 <Rathann> but why do you need meson macros to wrap around ninja macros?
16:23:12 <ignatenkobrain> 4. run %ninja_build -C ...
16:23:17 <tibbs> But basically, I have no problem with visual consistency.  I think from a packager standpoint it looks quite nice and comprehensible.
16:23:22 <ignatenkobrain> Rathann: because of -C %{__builddir}
16:23:33 <ignatenkobrain> I don't want users always to pass -C ...
16:23:37 <ignatenkobrain> that's just useless
16:23:50 <Rathann> ok so what's the difference between ninja and meson again?
16:23:52 <tibbs> I assume that -C is mandatory?
16:24:00 <ignatenkobrain> Rathann: ninja is like make
16:24:00 <Rathann> and why would you want to run ninja directly?
16:24:10 <ignatenkobrain> Rathann: meson is like automake
16:24:12 <Rathann> instead of meson, that is
16:24:20 <Rathann> hm
16:24:24 <ignatenkobrain> meson just generates build.ninja
16:24:57 <Rathann> from what I see you don't need 1-3, just 4, at least that's what your macros are doing
16:24:57 <orionp> what if you need multiple, separate build dirs?
16:25:33 <ignatenkobrain> orionp: you redefine %__builddir
16:25:59 <Rathann> ignatenkobrain: a couple of real-world spec examples would be great to make the intended use cases clearer
16:26:14 <ignatenkobrain> Rathann: I showed example spec in the meson guidelines
16:26:33 <ignatenkobrain> Rathann: basically it's taken from real package
16:26:47 <Rathann> and for ninja?
16:27:38 <ignatenkobrain> Rathann: for ninja there is no packages which I maintain. It's hard to maintain ninja files (same for plain Makefile)
16:27:47 <Rathann> if there's none or little real-world usage for ninja then I don't see the need to wrap ninja in macros, just put the direct calls in meson macros
16:28:01 <tibbs> To be completely fair, I wouldn't even bother with __builddir.
16:28:10 <ignatenkobrain> Rathann: GYP (used in chromium) also generates build.ninja
16:28:21 <ignatenkobrain> and there are more buildsystems like meson
16:28:26 <ignatenkobrain> which generate build.ninja
16:28:36 <Rathann> ok so chromium could use these ninja macros?
16:28:36 <ignatenkobrain> and don't provide anything like XXX install
16:28:47 <Rathann> or?
16:28:58 <ignatenkobrain> Rathann: 1) they should use gyp ... 2) then they should use ninja macros, yes
16:29:25 <tibbs> Also, why would one ever change __builddir?
16:29:35 <Rathann> what does %meson do?
16:29:52 <ignatenkobrain> tibbs: only if this directory already exist
16:29:53 <Rathann> ah
16:29:53 <orionp> tibbs: like my question perhaps?  mpi builds...
16:29:54 <tibbs> Rathann: Look at the macro definition he gave.
16:30:06 <tibbs> https://github.com/mesonbuild/meson/blob/master/data/macros.meson
16:30:10 <Rathann> it wasn't in any of the links given, but I found it
16:30:13 <tibbs> Probably easier than an explanation.
16:30:28 <tibbs> He posted it here a few minutes ago when I asked for it.
16:30:40 <ignatenkobrain> this is what chromium does
16:30:42 <ignatenkobrain> ../depot_tools/ninja -C %{target} -vvv chrome chrome_sandbox chromedriver widevinecdmadapter clearkeycdm policy_templates $CHROMIUM_BROWSER_UNIT_TESTS
16:31:06 <ignatenkobrain> so basically: 1) uses bundled ninja 2) doesn't inherit %{?_smp_mflags}
16:31:27 <ignatenkobrain> which can be simplified
16:31:38 <Rathann> *sigh* ok
16:32:10 <ignatenkobrain> so basically I splitted out ninja stuff because it can be (will be) used from different buildsystems
16:32:30 <ignatenkobrain> Ninja's low-level approach makes it perfect for embedding into more featureful build systems; see a list of existing tools.  Ninja is used to build Google Chrome, parts of Android, LLVM, and can be used in many other projects due to CMake's Ninja backend.
16:32:38 <ignatenkobrain> https://github.com/ninja-build/ninja/wiki/List-of-generators-producing-ninja-build-files
16:32:43 <ignatenkobrain> this is the list of existing tools
16:32:44 <Rathann> ignatenkobrain: got it, thanks
16:33:13 <Rathann> I don't like the usage of __builddir, though
16:33:20 <ignatenkobrain> I would like to make sourcedir/builddir to be the global thing for meson/gyp/cmake/whatsoever
16:33:29 <Rathann> because _builddir (single underscore) is already defined
16:33:42 <Rathann> rpm --eval '%_builddir'
16:33:49 <ignatenkobrain> Rathann: that is the top directory of RPM
16:33:50 <Rathann> rpm --eval '%_builddir'
16:34:07 <Rathann> ugh, sorry for the paste
16:34:31 <ignatenkobrain> usually people will not redefine nor __sourcedir neither __builddir
16:34:33 <Rathann> yeah, so introducing a new macro that differs just in the leading underscore and is meson-specific is bad design
16:34:43 <Rathann> as it's typo-prone
16:34:44 <ignatenkobrain> Rathann: it's not meson-specific
16:34:45 <orionp> there's no way we're adopting suse's %cmake w/ %__builddir  - I don't see a way of making it backwards compatible with current usage
16:35:14 <Rathann> ignatenkobrain: it's in meson.macros, so it's meson-specific to me
16:35:23 <Pharaoh_Atem> afaik, suse just makes a "build" dir then runs it
16:35:44 <Pharaoh_Atem> Mageia uses the SUSE variant of the macros, and it does that there
16:35:47 <ignatenkobrain> orionp: probably at some point we can make new macro like %cmake_out_of_tree or smth like this
16:36:23 <ignatenkobrain> Rathann: it's there because currently there is no way to make it system (to be usable *right now*)
16:37:36 <ignatenkobrain> Rathann: as I said, if we agree on making builddir/srcdir system-wide (shared between cmake/gyp/meson/etc.) then it has to be placed in fedora-rpm-macro or something like that
16:37:37 <Rathann> also, __sourcedir in macros.meson is semantically quite different from _sourcedir
16:38:15 <Rathann> as the latter means /builddir/build/SOURCES, i.e. where unpacked SRPM's sources and patches are stored
16:38:24 <ignatenkobrain> Rathann: propose better naming
16:38:58 <tibbs> Yes, __sourcedir and __builddir are basically no-goes for me, sorry.
16:39:16 <orionp> pkg_sourcedir/_builddir ?
16:39:17 <racor> ignatenkobrain: _meson_<xxx>dir
16:39:29 <tibbs> I don't even understand why you need __sourcedir.
16:39:30 <ignatenkobrain> racor: it is not meson specific!
16:39:37 <ignatenkobrain> tibbs: look at angelscript example
16:39:58 <ignatenkobrain> orionp: good names, I'm in
16:40:00 <racor> ignatenkobrain: why?
16:40:03 <Pharaoh_Atem> then call it something like _pkg_srcdir and _pkg_builddir?
16:40:18 <tibbs> What is it with the leading underscores, anyway?
16:40:23 <tibbs> People just like typing them?
16:40:27 <racor> Pharaoh_Atem: no, too general
16:40:29 * Rathann suggests pkg_compiledir
16:40:48 <ignatenkobrain> racor: I explained it above. in my POV it should be generic names for *all* out-of-tree builds
16:40:49 <limburgher> Maybe they represent the learning curves of the requisite build systems?
16:41:14 <Pharaoh_Atem> tibbs: the idea behind the underscores is that they are supposed to be left alone? at least that's how it was explained to me long ago
16:41:17 <ignatenkobrain> and you should be able to redefine them to make in-tree builds
16:41:20 <tibbs> I can go with any of pkg_sourcedir, pkg_compiledir, pkg_builddir.  Though, still, pkg_sourcedir sounds like it would have something else.
16:41:37 <racor> ignatenkobrain: such thing does not exist, because it's technical nonsense
16:41:48 <ignatenkobrain> racor: oh, tell me more
16:42:13 <Rathann> and yeah ignatenkobrain's __sourcedir is really _builddir/%{name}-%{version}-%{release} or whatever is put after %setup -q -n
16:42:13 <tibbs> Of course these _aren't_ supposed to be left alone, in any case.
16:42:30 <ignatenkobrain> Rathann: by default, yes
16:42:37 <tibbs> Rathann: Well, only in the case that you don't have to change it, of course.
16:43:06 <ignatenkobrain> for example, angelscript. They support multiple buildsystems
16:43:15 <ignatenkobrain> make/automake/cmake/meson/..
16:43:18 <ignatenkobrain> a lot of them
16:43:25 <ignatenkobrain> so it's stored somewhere in subdirs
16:43:27 <racor> I think this discussions doesn't lead anywhere.
16:43:42 <tibbs> racor: Now that I agree with.
16:44:15 <racor> I would suggest ignatenkobrain to expand his proposal and us to review it at a later time
16:44:25 <ignatenkobrain> racor: expand to what?
16:44:26 <Rathann> so, __sourcedir is unnecessary (can be saved from $PWD) and __builddir can be replaced with $PWD/%{_target_platform} likewise
16:44:36 <Rathann> s/expand/revise/
16:44:48 <ignatenkobrain> Rathann: sourcedir is not always $PWD
16:44:50 <ignatenkobrain> that's the point
16:45:05 <Rathann> it's not sourcedir, though
16:45:05 <tibbs> I'm no sure how you'd get it from $PWD, but I guess it would be interesting to see.
16:45:23 <ignatenkobrain> Rathann: it's build-definitions-source-dir
16:45:23 <tibbs> That's true, it isn't the directory of the source.
16:45:35 <Rathann> tibbs: after %setup done you end up there
16:45:38 <Rathann> so $PWD
16:45:45 <tibbs> At least in the anglescript example it's most decidedly not the source at all.
16:45:51 <tibbs> So I don't know what you'd call it.
16:45:57 <Rathann> likewise at the beginning of %build and %install
16:46:10 <tibbs> Is there an analogue for cmake or plain old autoconf?
16:46:30 <ignatenkobrain> tibbs: I showed how it can be done with cmake
16:46:40 <ignatenkobrain> currently if you want to do out-of-tree build (which is recommended)
16:46:40 <Pharaoh_Atem> autotools isn't really great at handling out of tree builds
16:46:41 <orionp> wherever the top level CMakeLists/configure file is
16:46:57 <orionp> which is almost always in the top dir
16:47:03 <racor> Pharaoh_Atem: You are dead wrong!!!
16:47:04 <tibbs> I'm just trying to figure out what a good generic name is.
16:47:04 <ignatenkobrain> mkdir build
16:47:04 <ignatenkobrain> pushd build
16:47:04 <ignatenkobrain> %cmake ..
16:47:04 <ignatenkobrain> popd
16:47:05 <ignatenkobrain> %make_build -C build
16:47:06 <ignatenkobrain> %make_install -C build
16:47:29 <Pharaoh_Atem> racor: I've never heard of anyone doing out of source builds with autotools
16:47:32 <tibbs> And so in that example, what's %sourcedir?
16:47:41 <ignatenkobrain> Pharaoh_Atem: GNOME does, but usually it doesn't work =)
16:47:45 <tibbs> Pharaoh_Atem, racor: Really that's completely immatreial to the discussion.
16:47:48 <orionp> Pharaoh_Atem: I do a ton of them
16:48:02 <RemiFedora> Pharaoh_Atem, php.spec does ;)
16:48:06 <Pharaoh_Atem> O.o
16:48:23 <tibbs> I have work to do so I'm going to check out unless this stays on topic.
16:48:26 <Rathann> tibbs: it's the directory where the top of the unpacked source tree is (and contains some config for meson) IIUC
16:48:39 <ignatenkobrain> as you can see, even autofoo can do out-of-tree builds. That's the point why I want to generalize this names
16:48:42 <racor> tibbs: I am tired of having to listen to dumb comments and
16:49:01 <Rathann> ok, can we move this discussion to the mailing list and move on?
16:49:14 <tibbs> Rathann: Yeah, that's what you and I would think %_____sourcedir means.  But that's not what the proposal is using when it refers to %__sourcedir.
16:49:19 <racor> I quit this meeting now.
16:49:38 <Rathann> *sigh*
16:49:38 <tibbs> Wow.
16:49:41 <ignatenkobrain> tibbs: as I said, I'm open for any name
16:49:42 <limburgher> MmmHmm.
16:49:43 <Rathann> that wasn't excellent at all
16:49:47 * Pharaoh_Atem sighs
16:50:04 <Rathann> ignatenkobrain: please start a thread in packaging ML
16:50:15 <Rathann> we won't get anywhere with this today
16:50:21 <ignatenkobrain> I thought point of this meeting to FPC to review and propose changes
16:50:32 <tibbs> Well, I was just trying to comprehend things.
16:50:55 <ignatenkobrain> but apart from orionp's suggestion it was just "this is bad name, change it"
16:51:01 <tibbs> But sometimes things work well over IRC, and some times they don't.
16:51:02 <limburgher> And as a result I don't think there's enough of a consistent conception of this to get to the review/finalize stage.
16:51:27 <tibbs> I understand what's going on. I have no problems with the actual ninja/meson parts of the proposal.
16:51:29 <limburgher> And any sort of consensus is way over there. -------------------------------------------------------->
16:51:46 <ignatenkobrain> tibbs: I will write thread about generalizing build-defs-source-dir / builddir for out-of-tree builds in packaging@
16:52:04 <tibbs> build_defs_dir is an interesting name for it.
16:52:07 <Rathann> ignatenkobrain: yeah, don't try to do two things at the same time
16:52:14 <Rathann> tibbs: +1
16:52:19 <tibbs> Rathann: To be fair, it's not his fault.
16:52:43 <geppetto> yeh, and also +1
16:52:58 <tibbs> He needed a setting and I guess "suse did it" is tempting even though what they did is just absolutely bizarre.
16:53:06 <orionp> My concerns - %__sourcedir/%__builddir names, and I don't think the automatic build dir creation/pushd/popd is a good idea
16:53:18 <Rathann> orionp: +1
16:53:37 <tibbs> orionp: I'm not sure I see any problem with automatically doing out-of-tree builds for buildsystems which support it.
16:53:39 <orionp> otherwise, I'm basically fine
16:53:40 <limburgher> +1: You don't want it obliterating anything. .
16:53:45 <ignatenkobrain> orionp: but then we will endup with boilerplate "-C ..."
16:53:56 <tibbs> ignatenkobrain: Not necessarily.
16:54:01 <orionp> I have to deal with lots of multiple build dir packages
16:54:13 <geppetto> #action ignatenkobrain Will start thread on packaging@ about generalized macros for out-of-tree builds
16:54:20 <ignatenkobrain> geppetto++
16:54:20 <zodbot> ignatenkobrain: Karma for james changed to 6 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:31 <geppetto> #info apart from that everyone seems happy with the proposal
16:54:44 <Rathann> yes, in general it's fine
16:54:56 <limburgher> Agreed.
16:54:56 <tibbs> ignatenkobrain: One other way to do this: have your macros take parameters.  Provide a plain '.' default for -C if no parameter is passed.  Otherwise, use one suplied to the macro.
16:55:15 <geppetto> #topic #650     Alternate Python Interpreters
16:55:28 <geppetto> .fpc 650
16:55:29 <zodbot> geppetto: #650 (Suggested Change for Python Guidelines about Alternate Python Interpreters) – fpc - https://fedorahosted.org/fpc/ticket/650
16:55:53 <ignatenkobrain> tibbs: then we have to do it for each _build/_install/_test which is not good. anyhow I'll write this to the ML and now we go to next topic ;)
16:55:57 <tibbs> Yes, you have to duplicate that option in a couple of places; that does serve to make it obvious and still makes the common case simple.  Or at least I think it does.
16:56:21 <tibbs> I disagree with "is not good".  But in any case, save the value passed to the first %meson call for use in the other macros.  Simple.
16:56:31 <limburgher> I like 650, though it could do with gif flames and a skull, just to be sure.
16:56:36 <tibbs> On 650, I'm behind; did Fesco do something?
16:56:51 <tibbs> I thought we had tabled it until that happened.
16:57:03 <geppetto> I'm not sure, I just noticed it had been updated
16:57:14 <Rathann> FESCo will probably discuss it again tomorrow
16:57:25 <Pharaoh_Atem> FESCo didn't talk about it last week
16:57:27 <Rathann> as there's been some discussion in the ML
16:57:33 <limburgher> Yeah, no changes to the FESCO ticket in 6 days.
16:57:41 <Rathann> right s/again//
16:57:46 <geppetto> ok
16:58:03 <limburgher> So I temporarily rescind my comments, except for the gif bits.
16:58:14 <Rathann> gif bits?
16:58:20 <geppetto> <limburgher> I like 650, though it could do with gif flames and a skull, just to be sure.
16:58:37 <tibbs> He's just joking about how to make such packages really obvious.
16:58:42 <limburgher> Maybe a blink tag.
16:59:01 <Pharaoh_Atem> :S
16:59:03 <limburgher> In fuscia.
16:59:14 <geppetto> tibbs: I assume 654 hasn't changed?
16:59:46 <tibbs> I think from an FPC perspective we have a good idea how to handle 650 thing (or at least I made some proposals of which I'm fond) but no point in spending time on it until fesco does something.
16:59:50 <tibbs> Crap, 654...
17:00:09 <tibbs> glibc file triggers.
17:00:16 <geppetto> indeed
17:00:17 * Pharaoh_Atem groans
17:00:21 <tibbs> Not really much change, but the bugzila ticket is really interesting.
17:00:31 * geppetto nods
17:00:35 <geppetto> #topic Open Floor
17:00:50 <tibbs> Sadly nobody else jumped in, but the glibc folks really did have useful stuff and real live counterexamples.
17:01:29 <tibbs> Basically, the current status is that it's possible to do the %transfiletriggerin/postun thing _if_ you package a certain type of library in a slightly different way.
17:01:34 <orionp> one unfortunate thing about the python packages - in EPEL, python34 is the primary python 3.4 package
17:01:48 <tibbs> And you must also have a %filetriggerin/postun on /etc/ld.so.conf.d
17:01:53 <Rathann> orionp: but... it's EOL already, right?
17:01:59 <Pharaoh_Atem> tibbs: well, the thing is, if things are installed into directories already known by ldd, ldconfig is just a cherry on top
17:02:07 <Rathann> or is someone backporting patches from 3.5?
17:02:08 <tibbs> Pharaoh_Atem: Untrue.
17:02:12 <orionp> Rathann: is it?  no idea
17:02:21 <tibbs> The example given in the source is real.
17:02:26 <tibbs> sorry, the example given in the ticket.
17:02:29 <geppetto> https://bugzilla.redhat.com/show_bug.cgi?id=1380878#c8 onwards, I guess?
17:03:01 <tibbs> geppetto: Yeah, basically the whole thing.
17:03:07 * geppetto nods
17:03:43 <tibbs> There is an overall question of whether two lines removed from library-containing specs is worth it.
17:04:07 <limburgher> Not having ldconfig run when it's needed can be a royal mess.
17:04:08 <tibbs> I think they would like to see tooling for making sure that the distro as a whole complies with any packaging changes required to make this work.
17:04:30 <ignatenkobrain> tibbs: that's the thing which easy to forget
17:04:34 <ignatenkobrain> but that's not all
17:04:39 <ignatenkobrain> filetriggers are ran ONCE
17:04:54 <ignatenkobrain> but normal triggers ran ONCE PER PACKAGE
17:04:59 <tibbs> ignatenkobrain: Depends on which trigger you're talking about.
17:05:03 <ignatenkobrain> so this is speed benefit
17:05:09 <tibbs> And "normal triggers" aren't a thing that we really want.
17:05:20 <tibbs> And, no, it's not really a speed benefit.
17:05:29 <ignatenkobrain> tibbs: %filetriggerin is ran after transaction
17:05:31 <tibbs> I urge you to read the ticket.
17:05:37 <tibbs> ignatenkobrain: No, that is untrue.
17:05:44 <tibbs> %transfiletriggerin is run after the transaction.
17:05:47 <tibbs> Please, read the ticket.
17:06:09 <ignatenkobrain> tibbs: sorry, I'm out for now (but I will read it tomorrow)
17:06:17 <tibbs> Anyway, I'm getting good at typing %transfiletriggerin.
17:06:29 <tibbs> So, otherwise, I'm behind on everything, still.
17:06:46 <tibbs> But there are a couple of meta things I need to bring up.
17:07:15 <tibbs> Well, one is that we need to start working on moving from trac to pagure, but again I'm behind and haven't made the test conversion yet.
17:07:16 <tibbs> So....
17:07:27 <geppetto> yeh
17:07:35 <geppetto> we are probably one of the last using trac
17:07:36 <tibbs> The other is that fale started playing with an idea I've had for a while.
17:07:46 <ignatenkobrain> would be nice if we can bring here RPM developers for such topics
17:07:51 <tibbs> Oh, not nearly.
17:08:09 <geppetto> tibbs: what is fale doing?
17:08:11 <ignatenkobrain> like pmatilai and ffesti
17:08:25 <tibbs> Basically, the wiki sucks.
17:08:29 <tibbs> I hate dealing with it.
17:08:57 <tibbs> I really dislike that at the end of my day it goes offline completely for 45 minutes and I lose my edits if I don't stick around until it comes back.
17:09:34 <tibbs> But we could just put the stuff in pagure and treat them like proper documentation
17:09:49 <limburgher> With diffs and everything.
17:10:02 <Rathann> orionp: huh, apparently py34 is not EOL yet
17:10:13 <tibbs> Well, you do get that with wikis now, but pull requests.  And offline editing.  And speed.  And no wiki.
17:10:20 <limburgher> And then you can grep, sed, find, in the docs.
17:10:45 <limburgher> So not just trac->pagure, but also guidelines->pagure?
17:10:47 <tibbs> The issue is conversion, and he's already converted a bunch of stuff.  It's unthemed, but there's a convenient wiki theme to steal.
17:10:56 <tibbs> limburgher: Well, it's two things.
17:11:07 <tibbs> Both if which just happen to involve pagure.
17:11:12 <limburgher> Right.
17:11:19 <tibbs> No need to do them together or anything like that.
17:11:21 <limburgher> Intriguing.
17:11:47 <tibbs> Anyway, it's not happening soon or anything.  But fale played with it a bit and managed to give us a conversion with history and such.
17:11:53 <limburgher> Wow.
17:12:05 <limburgher> Awesome.  Is there a partial POC somewhere?
17:12:15 <tibbs> I would have to learn to do things in rst instead of wikinoise but it's not really any worse.
17:12:47 <tibbs> https://pagure.io/packaging-guidelines
17:13:01 <tibbs> Sadly he made it in production, and not in his personal namespace.
17:13:48 <tibbs> But you can see basically every edit I've made in the history.
17:13:53 <geppetto> cool
17:14:01 <limburgher> Fascinating.
17:14:10 <tibbs> pull requests for drafts is kind of a nice idea as well.
17:14:22 <tibbs> Anyone can fork and edit if they want to see something changed.
17:14:29 <limburgher> No kidding.
17:14:33 <tibbs> And... it's not in the wiki.
17:15:01 <tibbs> But note that he converted everything in the "Packaging guidelines" category.
17:15:26 <tibbs> Which not only includes a pile of stuff that isn't packaging guidelines, but also doesn't include some of the real guidelines.
17:15:35 <Pharaoh_Atem> tibbs: on another note, I asked folks in Mageia to contribute to the discussion about file triggers in glibc: https://ml.mageia.org/l/arc/rpmstack/2016-10/msg00012.html
17:15:39 <tibbs> Because at some point I didn't even know how to do categories in the wiki.
17:15:39 <limburgher> Obviously there might be a more fine-grained process to it, whitelisting, cleanup beforehand or after, etc.
17:15:44 <Pharaoh_Atem> they're more experienced in it than I am
17:15:46 <limburgher> The bones are good though.
17:16:12 <tibbs> But, yeah, with a theme and everything, we'd have nice documentation that's browsable in multiple different formats.
17:16:27 <geppetto> tibbs: So I assume he has scripts, and if we add the categories properly he can do everything on another pass?
17:16:41 <tibbs> And we could indeed then do releases, which would satisfy another recent request.
17:17:01 <Pharaoh_Atem> I suppose it also means we should ship the guidelines as an RPM, too
17:17:04 <tibbs> geppetto: Yeah, he did another pass over everything in the Packaging: namespace, but then that has all of our pre-møte logs and stuff.
17:17:06 <Pharaoh_Atem> s/should/could/
17:17:33 <limburgher> And rpmlint could grok it. . .someday. . .
17:17:39 <tibbs> Note that it's still missing things which I think are kind of essential.
17:18:12 <tibbs> Things like {{FedoraVersionNumber|previous}} and the nice macros to make bugzilla and trac links and such.
17:18:57 <tibbs> But those can be added.  They won't be live like FedoraVersionNumber but frankly I'll rebuild when necessary to fix that with all of the time I would save not having to wiki.
17:19:11 <tibbs> Sadly fale was here but I guess he had to go.
17:19:29 <tibbs> Anyway, if anyone thinks this is a bad idea, please do let me know before he spends too much time on it.
17:19:30 <limburgher> fale++
17:19:30 <zodbot> limburgher: Karma for fale changed to 10 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:20:01 <geppetto> Yeh, pretty much the opposite of a bad idea
17:20:03 <tibbs> Honestly if anyone does think it to be a bad idea, we could still keep things in the wiki as the output of another build process.
17:20:04 <Pharaoh_Atem> I think it's awesome
17:20:18 <tibbs> Breaking every single link is probably the downside.
17:20:26 <Pharaoh_Atem> it gives us the nice flexibility to offer offline versions of the guidelines, too
17:20:33 <tibbs> Assuming that someone who knows how to make things pretty can actually make them pretty.
17:20:48 <geppetto> We can have redirects in, for the links … or have one of the outputs be the wiki
17:21:30 <Rathann> I took a look earlier, too
17:21:47 <Pharaoh_Atem> maybe just make the wiki another output
17:21:53 <Pharaoh_Atem> that simplifies a lot of things
17:22:04 <Rathann> and I think it's a great idea to have the guidelines in proper version control
17:22:33 <Pharaoh_Atem> yes
17:24:46 <tibbs> Anyway, so that's a thing.
17:25:38 * geppetto nods
17:25:51 <geppetto> Cool … anything else from anyone?
17:25:57 <tibbs> So I'll let folks know about it if anything happens here.
17:25:59 <limburgher> Not I.
17:26:33 <Pharaoh_Atem> tibbs: did you have a chance to look over and clean up the versioning guidelines (current and proposed draft)?
17:26:53 <tibbs> I haven't had a chance to do any guidelines work at all over the past two weeks.
17:27:09 <Pharaoh_Atem> okay
17:28:00 <tibbs> I don't see my available free time increasing measurably in the near future, but I'll continue to do as much as I can do.
17:28:11 * geppetto nods
17:29:18 <Rathann> ok, so if there's nothing else then I'd like to drop off now
17:29:29 <geppetto> Yeh, I'll close ina minute anyway
17:29:38 <Rathann> ok, thanks everyone
17:29:39 <Rathann> bye
17:30:14 <tibbs> Thanks.  I'm buried as always but fortunately I have no new writeups.
17:30:32 <geppetto> #endmeeting