16:03:23 <jcajka> #startmeeting Go SIG meeting
16:03:23 <zodbot> Meeting started Wed Mar 20 16:03:23 2019 UTC.
16:03:23 <zodbot> This meeting is logged and archived in a public location.
16:03:23 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:23 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:03:33 <jcajka> #topic Roll Call
16:03:57 <jcajka> hello, everybody, let's get it going :)
16:04:59 <eclipseo> .hello2
16:05:00 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:05:02 <jcajka> #chair eclipseo
16:05:02 <zodbot> Current chairs: eclipseo jcajka
16:05:03 <QuLogic> .hello2
16:05:04 <zodbot> QuLogic: Sorry, but you don't exist
16:05:13 <QuLogic> .hello2 qulogic
16:05:14 <zodbot> QuLogic: Sorry, but you don't exist
16:05:21 <jcajka> #chair QuLogic
16:05:21 <zodbot> Current chairs: QuLogic eclipseo jcajka
16:05:33 <eclipseo> should be  ( .hello qulogic )
16:06:13 <jcajka> eclipseo: do you know if/when nim will come?
16:06:38 <eclipseo> no, but since he insisted on that meeting he should be there
16:07:11 <eclipseo> I hope he will come soon as most of the topic is about his refactoring of the macros
16:07:55 <jcajka> I would wait for a bit as I guess only topic in the tracker is his and I would guess that he will/wants to bring up the macros on open floor
16:08:17 <jcajka> any other topics that you want to discuss?
16:09:14 <eclipseo> yeah golist / gofed
16:09:18 <QuLogic> someone please review golist prs ;)
16:09:23 <eclipseo> and their future
16:09:28 <QuLogic> though I expect nim will want to drop it entirely
16:09:34 <eclipseo> QuLogic: tested PR17 looks good
16:10:48 <jcajka> QuLogic: do you have a link?
16:10:55 <QuLogic> that's good; I think it worked for most cases I tried
16:11:21 <eclipseo> QuLogic: wanted to ask you if you could do more on Gofed if you have the cycles. As jchaloup is MIA, we have no one to look over the code, and it seems you understand Go, which is more than me. Basically if you could seer the project toward what nim or the SIG needs.
16:11:21 <QuLogic> https://pagure.io/golist/pull-request/16 and https://pagure.io/golist/pull-request/17
16:11:41 <jcajka> QuLogic: thanks
16:11:56 <QuLogic> eclipseo: gofed is Python, isn't it?
16:11:56 <jcajka> eclipseo: IIRC gofed is python
16:12:02 <jcajka> :)
16:14:11 <eclipseo> https://pagure.io/fork/eclipseo/packaging-committee/blob/implement_golang_guidelines/f/guidelines/modules/ROOT/pages/Golang.adoc
16:14:21 <QuLogic> 2-to-3 stuff is generally pretty easy
16:14:23 <eclipseo> gofed is Python **2**
16:14:38 <eclipseo> gofed is also overly complicated for our use
16:15:10 <eclipseo> there's tons of functions I don't think we need and some of them don't work as well
16:15:24 <eclipseo> the codebase hasn't been touched since early 2018
16:15:46 <jcajka> eclipseo: I wouldn't say so, at least not on the ideas behind it, it is next step to the packaging automation, getting rid of the "manual" packaging labor
16:15:52 <QuLogic> I don't know what happens under the hood or for other functions; I only ever run **2spec
16:16:07 <eclipseo> me too
16:16:50 <eclipseo> but with the new dependency generator, we probably won't even need it to discover BR
16:17:29 <QuLogic> I suppose that depends on how the rpm side of things goes though
16:19:14 <jcajka> eclipseo: I would say that is question that nobody knows answer to yet, it will depend on what upstream GC will do, there is lengthy thread on it, and how many "legacy" packages we will need to carry to provide what we want to provide
16:20:42 <eclipseo> upstream GC? whire's that thread?
16:22:59 <jcajka> eclipseo: https://groups.google.com/forum/#!topic/golang-dev/DD88cds-LuI%5B1-25%5D I hope it points to it
16:23:15 <jcajka> google groups UI is not the most intuitive one
16:23:41 <eclipseo> ah that issue, I haven't yet read all my mail about it.
16:23:59 <eclipseo> I don't know how that will affect us
16:24:06 <jcajka> It started with the post that I have CC in to the fedora's golang list, IMO it is now less about the notary, but more about the modules
16:24:32 <jcajka> with heavy nim's presence
16:24:43 <eclipseo> Do we care about what versions are specified in the Go.mod file, since we always try to have the latest version packaged
16:25:10 <eclipseo> and we do not really have "compat" packages for old versionr
16:25:50 <eclipseo> we are always assuming "it will work with newer versions / git master"
16:26:02 <jcajka> it is more, if the tooling will need constant internet access or some complex work around we care about that
16:27:38 <jcajka> eclipseo: IMHO it is more we want the most recent that works for us across the board, but I haven't done much hands on leave/deps Go packaging, mostly just sticking to the GC itself
16:27:52 <jcajka> leaf...
16:29:42 <QuLogic> if packages truly follow semver and go versioning, they should not break downstreams without bumping the major version
16:29:56 <eclipseo> i'm the hand on packaging. the problem is that Go upstream assumes all is connected to the internet and you can fetch whatever you need. That doesn't work in a mock context.
16:29:56 <jcajka> nim is here :)
16:30:05 <eclipseo> yeahhhh
16:30:35 <nim> I'm here !
16:30:42 <jcajka> let's start with
16:31:02 <jcajka> #topic Migrate Fedora to packages based on the new pagure repositories https://pagure.io/GoSIG/go-sig/issue/20
16:31:06 <eclipseo> #chair nim
16:31:06 <zodbot> Current chairs: QuLogic eclipseo jcajka nim
16:31:28 <jcajka> that is only issue marked for the meeting
16:32:18 <nim> sorry I noted down the meeting end hour, not the start hour :(
16:32:18 <jcajka> after reading last post that is AFAIK edited by nim, although posted by me, it is probably topic for him
16:32:39 <eclipseo> yes, so I have tested the macros and I'm pretty please with them
16:32:44 <nim> jcajka, thanks
16:32:49 <jcajka> nim: np, there is 3(4 including you so we waited)
16:33:31 <eclipseo> What are the current blocking issues?
16:33:41 <nim> basically the plan I posted in the sig pagure space calls
16:33:45 <eclipseo> the documontation? i started working on guideliner
16:33:56 <nim> to put each bit of our packaging tooling in its own package
16:33:59 <eclipseo> See https://pagure.io/fork/eclipseo/packaging-committee/blob/implement_golang_guidelines/f/guidelines/modules/ROOT/pages/Golang.adoc
16:34:02 <nim> with its own maintainer
16:34:23 <nim> so one project/package for the shell + lua glue
16:34:34 <nim> one project/package for golist
16:34:36 <nim> and so on
16:34:44 <jcajka> nim: "sig pagure space calls"?
16:34:51 <jcajka> can we stay on the topic?
16:35:49 <eclipseo> I saw the split on your COPR
16:35:53 <nim> so we make as many srpm packages as we have tooling projects
16:35:53 <eclipseo> jooks good to me
16:35:59 <jcajka> nim: "sig pagure space calls"?
16:36:09 <jcajka> can we stay on the topic?  https://pagure.io/GoSIG/go-sig/issue/20
16:36:23 <jcajka> or do you want to jump right in to the macros?
16:37:12 <nim> and https://pagure.io/GoSIG/go-sig/issue/20 is just a detailed plan and how to get to a point where we have a clean tooling package layout
16:37:19 <nim> and everything is maintained
16:37:59 <nim> and we do not have the current "we have bugs" and "we have fixes" but "we don't know how to get the result in Fedora without jchaloup"
16:38:31 <jcajka> I wouldn't be that strong and absolute on the conclusions
16:38:54 <nim> jcajka, I simplify to make it quick, feel free to expand if you want to
16:39:05 <eclipseo> the split is fine, but not sure who should be the maintainers for Golist for example
16:39:24 <eclipseo> who has the technical expertise to do so?
16:39:37 <jcajka> how do you want to achieve the "everything is maintained"?
16:40:01 <nim> so I'm willing to maintain the macro part
16:40:22 <nim> it would be nice if someone stepped up to do the golist part for as long as we need golist
16:40:34 <nim> hint hint nudge nudg Qulogic
16:41:05 <nim> right now the only one of us that demonstrated ability and wilingless to look at the code is Qulogic
16:41:08 <QuLogic> golist is "simple"; I can maintain it mostly, I think
16:41:17 <nim> so if he wants the part, I would support him
16:41:17 <eclipseo> QuLogic: excellent
16:41:55 <eclipseo> What others issaues are we facing in order to move forward?
16:42:24 <jcajka> eclipseo: change proposal?
16:42:37 <nim> do anyone else want to deal with the golist or macro part?
16:42:59 <jcajka> as it stands currently, no
16:43:03 <eclipseo> Don't know programming in Lua nor Go
16:43:22 <jcajka> when it will be accepted and in place, possibly
16:43:29 <nim> eclipseo, well I didn't know either, I had to learn to make things work ;)
16:43:59 <eclipseo> If i have an issue i StackOverflow it
16:44:16 <nim> if everyone agrees the taget is to get to the point where we have a golist srpm package maintained by Qulogic, and a macro srpm package maintained by me
16:44:31 <eclipseo> agree
16:44:34 <nim> there is just the matter of administrative stuff like change proposal
16:44:57 <nim> and deciding what bugs we want to be fixed before making the switch
16:45:29 <nim> and documenting where people feel documenting is needed
16:45:43 <nim> I'm definitely not volunteering to wirte more doc
16:45:44 <eclipseo> what bugs are you thinking of?
16:45:55 <jcajka> nim: what about gofed and system wide switch of the packages to new standard?
16:46:02 <eclipseo> I'm into wrising the docc posted a link above
16:46:18 <nim> but I'll answer any question people have about the macro code if something needs documenting and is not clear from existing material
16:46:29 <eclipseo> I'd need to ask some questions regarding some macros though
16:46:53 <eclipseo> nim I'd need to ask some questions regarding some macros though
16:47:41 <nim> eclipseo, if you're ready to document things I'll answer all the things you need clarification on
16:47:42 <eclipseo> nim not clear about goipaths / goaltipaths distinctions
16:47:54 <eclipseo> will ask you about that later
16:47:58 <nim> sure
16:48:11 <eclipseo> let's get on with the topic at hand
16:48:31 <eclipseo> so we agree about the split packages and their owner
16:48:37 <eclipseo> what about the rest
16:48:43 <nim> so just to be clear on the bugs that still require some decision on
16:48:54 <jcajka> eclipseo: what is the split?
16:49:25 <nim> we have the infamous "golist generates arch specific code"
16:49:31 <eclipseo> what about the rest i mean
16:50:17 <nim> so we need to decide before the switch if we continue to pack go code in /usr/share, and hope qulogic finds the bug in golist
16:50:17 <eclipseo> nim I had raised that question a while ago but jchaloup said it was working as expected
16:50:28 <eclipseo> I on't understand the rationales though
16:50:47 <nim> or if we accept that golist generates arch specific code, and put the result in lbdir somewhere
16:51:07 <eclipseo> jcajka: the split I mean: golist → QuLogic gomacros → nim
16:51:14 <QuLogic> possibly fixable, though I have not tried anything
16:51:24 <nim> Qulogic: do you have any opinion there?
16:51:42 <jcajka> nim: if we do that we will stray very far away from upstream and I'm against that
16:52:08 <eclipseo> Upstream said anything about that?
16:52:20 <QuLogic> internal go search only picks up files with relevant tags (i.e., arch, os, etc.)
16:52:38 <nim> jcajka, i have basically no opinion, except that if we produce arch-specific things in norach packages, things are going to break sooner or later
16:52:57 <jcajka> QuLogic: that is my understanding of the core of the issue
16:53:18 <jcajka> nim: they are broken ;)
16:53:26 <QuLogic> there is another field of tags and ignored files that may result in the full list from a checkout/tarball
16:53:36 <nim> QuLogic, the core problem is that go has not strong separation between arch and other build tags
16:53:37 <eclipseo> But what difference does it make to have all files available on all arches, it doesn't break anything
16:54:06 <QuLogic> but I have not looked at what they contain or whether it will work
16:54:14 <nim> so if we do fine filtering like Jchaloup did, we lose some files
16:54:27 <jcajka> eclipseo: it make local system "devel" packages that are not inter change able with upstream code
16:54:55 <jcajka> nim: AFAIK that did upstream Go compiler devs not jchaloup
16:54:56 <nim> (and conversely if we do not do any filtering, we do not lose files but we get freebsd and windows support files in the mix, with their associated deps)
16:55:51 <jcajka> as they don't (yet) cover this use case in build package
16:55:52 <nim> jcajka, upstream devs separated things in "code useful for this system and this arch and this build tag" and "other go code"
16:56:01 <QuLogic> yes, filtering comes from upstream, because golist calls upstream code for everything
16:56:07 <nim> jchaloup chose to not include "other go code" in golist
16:56:42 <jcajka> nim: then it is easy fix
16:56:57 <jcajka> if I'm not mistaken
16:57:10 <nim> so basically, unless Qulogic wants to code some filtering upstream did not code, he has the choice between "everything" and "just this arch like jchaloup"
16:57:33 <jcajka> nim: what is the issue with everything?
16:57:50 <QuLogic> well, I guess I don't see a problem with everything either
16:58:26 <nim> jcajka, the only problem I see is that we will pick up files intended for other systems
16:58:41 <jcajka> nim: that is not an issue
16:58:51 <jcajka> that is a feature of Go
16:58:55 <nim> jcajka, so if there are windows support files that call twenty other packages
16:59:06 <nim> we get to package those twenty other packages to satisfy deps
16:59:08 <eclipseo> nim we don't want that
16:59:17 <eclipseo> nim so we keep the filtering
16:59:23 <jcajka> nim: we do support only $arch/linux
16:59:48 <jcajka> I still don't see the issue
16:59:51 <eclipseo> nim the problem is then how to detect if the devel package is noarch or arched?
16:59:51 <nim> so packaging "everything" has drawbaks
17:00:03 <jcajka> nim: I don't see any
17:00:12 <nim> but conversely, if we do just for system/arch
17:00:25 <nim> we need to move things to libdir
17:00:29 <jcajka> then we have broken devel packages...
17:00:37 <nim> wich is doable, if annoying
17:01:03 <QuLogic> the downsides are a bit theoretical
17:01:10 <nim> but the upstream Go code will also filter out all the support files that use other build tags
17:01:21 <nim> not just other arch builkd tags
17:01:26 <QuLogic> if we're using golist for dependencies, then they will be from the filtered list
17:01:31 <jcajka> nim: do you use that list for something, in the macro magic?
17:01:39 <nim> so if you have a project with, say, selinux support
17:01:41 <jcajka> apart from install
17:01:59 <nim> if you forget to specify the selinux build tag
17:02:09 <nim> nothing can build with your devel package with selinux
17:02:27 <nim> jcajka, the macro code does not care one way or another
17:02:29 <jcajka> nim: precisly my point, broken devel packages
17:02:42 <nim> jcajka, it packages the file lists produced by golist
17:02:43 <jcajka> nim: then we have no issue
17:02:59 <nim> jcajka, it has no opinion on what files golists selects or not
17:03:01 <jcajka> we can ship upstream files as is
17:03:56 <nim> jcajka, the least broken mode as things stand is to package "everything"
17:04:08 <nim> but that means packaging windows deps too
17:04:10 <jcajka> and only produce filtered output if necessary(with CLI flag) BR tools not for the %install
17:04:20 <nim> which sucks for packagers like eclipseo
17:04:32 <jcajka> nim: why? we support only $arch/linux
17:05:20 <nim> because for go $arch/linux is different from $arch/linux+selinux, etc
17:05:22 <eclipseo> you don't understand each other
17:05:52 <eclipseo> filtered: we get only linux file but we might exclude other specific tags
17:06:00 <jcajka> nim: I know that, I don't know what is the issue(in your opinion) for the packagers/deps?
17:06:07 <eclipseo> non-filtered we get everything but also windows file
17:06:38 <jcajka> eclipseo: if they are non-binary it is fine
17:06:48 <QuLogic> yea, but does that actually mean golist will add windows deps?
17:07:09 <nim> QuLogic I think it will
17:07:21 <nim> QuLogic, in module mode the go tools definitely will
17:07:26 <jcajka> QuLogic: nim said he is using the output only for %install, not dependency generation
17:07:50 <jcajka> QuLogic: currently for $arch/linux not
17:07:58 <nim> jcajka, the resulting files are  processed later by golist to output the corresponding deps
17:08:05 <QuLogic> golist output was for -devel deps too, no?
17:08:15 <eclipseo> yes
17:08:39 <eclipseo> I don't want no Windows dep
17:09:15 <QuLogic> I need a concrete example; I know there are  some, but I've already nuked packages from GOPATH that we provide
17:09:16 <jcajka> nim: ok, thanks for the clarification then we need to modes of operation for the golist one for %install and other for all supported arches for dep generation
17:09:22 <nim> the optimal solution would be for golist to output linux-everything files
17:09:33 <QuLogic> the ones I have don't have any extra deps for windows
17:09:52 <jcajka> QuLogic: this will be that case as I'm proposing
17:09:56 <nim> QuLogic, you're not seing them right now because golist filters them all
17:10:15 <QuLogic> again, my GOPATH, not our packages
17:10:28 <nim> QuLogic, sure
17:10:34 <nim> sorry :)
17:11:37 <nim> I advise against trying to patch over golist dep logic, because the go tools will have the same behaviour in module mode: if a file is included its deps are pulled in
17:12:09 <nim> so we'll have the exact same problem: need to filter source files to get a linux+everything result
17:12:19 <jcajka> nim: then we need to work with upstream
17:12:38 <eclipseo> QuLogic golang-github-shirou-gopsutil has windows deps for ex
17:13:11 <nim> jcajka, it's very hard for upstream to undertsand deps are not free, and we need to limit them to the minimum
17:13:39 <QuLogic> eclipseo: thanks
17:13:41 <nim> jcajka, you've seen how much time I spent lately explaining them things, and we didn't even get to this point
17:13:42 <jcajka> nim: I guess,  then we need to work with upstream, I'm not saying it is free and easy
17:13:52 <eclipseo> Ok so we agree we keep filtered output for Golist
17:14:03 <jcajka> eclipseo: no
17:14:54 <eclipseo> why no, i thought you were ok with it
17:15:37 <nim> I'll abstain for now :) I'll just code macro side whatever the SIG wants
17:15:38 <jcajka> eclipseo: my proposal is two modes of operation for the golist one for %install and other for all supported arches for dep generation(*/linux only) and work with upstream on go modules
17:15:49 <nim> the hard part is Qulogic-side if the SIG wnats to filter
17:16:41 <nim> jcajka, it's the same code upstream for module and non-modules, that's why I am able to explain it today
17:16:48 <QuLogic> ok, I'm still not seeing the problem
17:17:03 <QuLogic> go get github.com/shirou/gopsutil; golist --imported --package-path github.com/shirou/gopsutil
17:17:14 <QuLogic> does not list golang.org/x/sys/windows, for example
17:17:39 <nim> QuLogic: basically if you package everything, you get associated deps in golist and modules, including windows things
17:17:53 <QuLogic> (and since this is go get to my GOPATH, it's _all_ files)
17:18:30 <jcajka> nim: maybe in go modules(little hands on time), but it is no issue for current GOPATH
17:18:32 <eclipseo> QuLogic: yes the current output is filtered
17:18:50 <QuLogic> eclipseo: yes, exactly, so there's nothing to worry about
17:19:35 <nim> I'm pretty sure we have packages container side broken right now because the golist filtering also removes selinux support hwne it should not
17:19:42 <jcajka> QuLogic: broken devel packages?
17:20:00 <eclipseo> jcajka: how is that broken?
17:20:05 <QuLogic> no, we're confusing two things here
17:20:10 <jcajka> straying aways from upstream?
17:20:18 <QuLogic> filtering on deps and filtering on files
17:20:39 <jcajka> QuLogic: yes it seem to me... :/
17:20:54 <jcajka> QuLogic: so what about my proposal?
17:20:56 <QuLogic> I'm saying we should disable filtering on files; filtering on deps is orthogonal and not affected by what files we install
17:21:22 <jcajka> QuLogic: I'm saying that all the time
17:21:52 <eclipseo> QuLogic: Seems reasonable
17:22:04 <QuLogic> nim originally asserted that installed files affects deps earlier, which confused things a bit
17:22:19 <QuLogic> but I've just tested it and it doesn't
17:22:32 <eclipseo> So we don't filter files but we filter deps
17:22:39 <jcajka> QuLogic: nim seemed confused to me and unnecessarily defensive
17:22:48 <jcajka> on this topic
17:22:49 <eclipseo> is it easy to implement?
17:22:58 <nim> QuLogic: you need to find a project with non-arch build tags and test here
17:23:54 <QuLogic> nim: github.com/shirou/gopsutil has _windows.go files that import golang.org/x/arch/windows; that import does not appear in golist output
17:24:07 <eclipseo> nim I never seen such a project in the wild do you have an example?
17:24:16 <jcajka> QuLogic: go list or your golist?
17:24:25 <QuLogic> current golist
17:24:41 <jcajka> QuLogic: nim noted that it is know issue
17:25:02 <nim> but, I'll be delighted if just disabling filtering file-side produces something that works with golist
17:25:08 <eclipseo> QuLogic: can you change golist to impjement it?
17:25:15 <QuLogic> jcajka: but this is what we want, so it's not an issue?
17:25:56 <QuLogic> eclipseo: from documentation, I think; in actual fact, I would have to try it and see
17:27:04 <eclipseo> So we agree: we filter deps, we don't filter files.
17:27:20 <QuLogic> makes sense to
17:27:21 <eclipseo> so we have noarch packages
17:27:26 <QuLogic> to me*
17:27:33 <jcajka> eclipseo: yes that is my take away and what I have been trying to push from the start
17:27:38 <nim> if we agree golist will produce arch-agnostic file lists and linux-only dep lists I can wrap it directy in the macros and install the result in /usr/share like now
17:27:40 <eclipseo> and no mess with jibdir
17:27:55 <eclipseo> perfect then
17:27:56 <jcajka> yup
17:28:18 <QuLogic> jcajka: to be clear, I never disagreed with you, earlier; I just found more reasons to agree with you
17:28:43 <nim> it's quite easy to keep things in /usr/share, I just need to remove the code I wrote to make sure I would be able to move to libdir if necessary
17:28:48 <jcajka> QuLogic: I have never seen that, that way
17:29:04 <eclipseo> ok next topic then?
17:29:16 <eclipseo> or first topic actually
17:29:31 <nim> then it's just QuLogic making its final tweaking in golist
17:29:44 <nim> me making the final tweaking in go macros
17:30:18 <jcajka> so the issue https://pagure.io/GoSIG/go-sig/issue/20 is exhausted?
17:30:18 <QuLogic> if you could make a list of any packages that you come across that have files like this, that would be helpful to test
17:30:35 <nim> telling redhat-rpm-config peopel we'd really like the last small bits of code included (or I'll put then in the go macro code)
17:30:42 <jcajka> QuLogic: golang in fedora have build tags
17:30:50 <eclipseo> Can we move each point of issae 20 fodward? so that we can actually use the new macros?
17:30:57 <eclipseo> *issue 2
17:31:00 <eclipseo> 20
17:31:05 <nim> and just do every step in https://pagure.io/GoSIG/go-sig/issue/20 one after the other
17:31:13 <nim> if everyone agrees
17:31:27 <nim> and probably add a change page step if the SIG wants it
17:31:30 <eclipseo> get the last generic (non Go-specific) macro additions and fixes merged in redhat-rpm-config? nim can you do that?
17:31:50 <jcajka> nim: I don't agree with the proposal as it stands currently
17:32:04 <jcajka> nim: change page is required by Fedora not by any sig
17:32:08 <nim> do you see things in https://pagure.io/GoSIG/go-sig/issue/20 that you don't want to do or do some other way?
17:32:11 <eclipseo> get the required new packages reviewed and approved → I can do the reviewsc jist send thhe Review Request
17:32:47 <eclipseo> get the required new packages reviewed and approved → I can do the reviews just send the Review Request
17:33:32 <nim> sorry freenode is not stable for me today :(
17:33:41 <eclipseo> I have ro issaue with the plan in 20, I just want it to go forward, what are the current objections to it?
17:33:44 <jcajka> nim: I have voiced my concerns many times and I will bring them up at FESCO if they are not addressed in the final change proposal
17:33:47 <eclipseo> jcajka?
17:34:06 <eclipseo> jcajka: what are your concerns?
17:34:23 <nim> I currently agree with my own plan :)
17:34:42 <eclipseo> it looks like it is not backwards compatible → Semms to work with the packages I got form nam COPR
17:34:59 <jcajka> eclipseo: nim knows, they are noted in many public places, I don't fell I need to repeat myself again
17:35:04 <eclipseo> This doesn't include any docs →_I'm writing the docs
17:35:49 <eclipseo> please I haven't read all your interactions with nim to know what the issues are
17:37:00 <jcajka> eclipseo:I'm sorry, I don't keep any private list, they are scattered across the MLs issue trackers and meeting logs
17:37:54 <jcajka> eclipseo:IIRC one of the were docs other is the noarch devel packages and maybe some more
17:38:08 <jcajka> I don't remember atm
17:38:39 <eclipseo> The docs: I'm on it. The noarch devej: We've jist agreed on it. What's remaining?
17:38:48 <jcajka> I don't remember
17:38:52 <eclipseo> I don't want this to stay in the limbo forever
17:39:01 <jcajka> me neither
17:40:09 <eclipseo> In the meantimec I'm warry of making package update knowing our macros might change next months, and thus having to redo them again.
17:40:25 <eclipseo> we also have backward compatibility
17:40:25 <jcajka> but as nim proposed it, it was not IMHO ready for Fedora and any feedback that I have provided to him has been perceived by him as my personal attack or at least it seemed to me from his reactions
17:41:02 <eclipseo> let's not make this a people issue, let's focus on the actual technical merits
17:42:15 <jcajka> eclipseo: unfortunately it is people's issue... not to my liking too
17:43:05 <jcajka> I'm only waiting for the technical issue to be resolved before I will endorse this change
17:43:36 <nim> I mostly objected to upping the bar every time, before doing anything, while turning a blind eye to all the quick dirty and non maintainable stuff that was done by others than me
17:43:44 <jcajka> eclipseo: IMO with you and QuLogic stepping in you are on the right track to get it done :)
17:44:26 <jcajka> eclipseo++ and QuLogic++
17:44:26 <zodbot> jcajka: Karma for qulogic changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:44:35 <jcajka> QuLogic++
17:44:49 <jcajka> qulogic++
17:45:01 <jcajka> QuLogic: sorry no cookies...
17:45:47 <jcajka> eclipseo++
17:45:51 <eclipseo> I'm okay with the current proposal provided that I write the correct documentation
17:46:38 <eclipseo> I just wannt us to push every point forward with the appropriate people: FPC and so on
17:47:38 <jcajka> eclipseo: I will see when I will see the "System wide change proposal", but as I have said with you and QuLogic you are on the right track
17:49:24 <jcajka> can we move to open floor now?
17:49:41 <nim> eclipseo, can you write the proposal as part of the doc, whatever I do won't be any good
17:49:43 <nim> ?
17:49:59 <eclipseo> nim i'm on it iposted a link earlier
17:50:08 <eclipseo> See https://pagure.io/fork/eclipseo/packaging-committee/blob/implement_golang_guidelines/f/guidelines/modules/ROOT/pages/Golang.adoc
17:50:14 <QuLogic> to be honest, I have not seen much of the new macros (or the old ones, for that matter), so I have no strong opinions on that part of the plan, but I agree with the rest of it
17:50:41 <eclipseo> I don't have much time left
17:51:00 <jcajka> #topic Open floor
17:51:01 <jcajka> then
17:51:02 <QuLogic> and if they work well for eclipseo as far as compat, then that's good enough for me
17:51:08 <eclipseo> QuLogic: do you think you'd be able to modify golist to match nim needs?
17:51:21 <jcajka> We are well over the hour
17:51:45 <QuLogic> nim: iirc, that's mostly output formatting change, no?
17:52:07 <eclipseo> I suppose
17:52:08 <nim> QuLogic, the output formatting does not need any change
17:52:27 <eclipseo> i had another thing to discuss but I forgot -_-
17:52:35 <nim> QuLogic, the content of the file (or dep) lists need changing that's all
17:52:50 <QuLogic> ah, we've discussed that already
17:52:54 <nim> eclipseo, we need to talk about modules, but probably not today
17:53:14 <eclipseo> yeah modules but it will be too long
17:53:39 <eclipseo> ha yes modules but Fedora ones
17:53:50 <jcajka> eclipseo: I would suggest to leave them out for now and get the current stuff in
17:54:00 <nim> just for the information of the SIG
17:54:08 <eclipseo> See, the Rust guys only cares about their packages on Rawhide
17:54:26 <eclipseo> and then build their binaries like ripqrep in modules
17:54:40 <eclipseo> I wonder if we couldn't do the same
17:54:41 <nim> I started working on a utility to produce module files and translate module constrains into rpm constrains
17:54:50 <eclipseo> maintain our packages in Rawhide only
17:54:59 <eclipseo> build ouur binaries in modules
17:55:14 <QuLogic> I'm not totally convinced that it helps
17:55:18 <jcajka> nim, eclipseo: can we leave it for other meeting/after the meeting? I have one more topic to bring up
17:55:37 <eclipseo> jcajka: I need to go at 19:00CET
17:55:42 <eclipseo> so yes
17:55:58 <eclipseo> jcajka: what is your topic?
17:55:58 <nim> yes sure I'm finished
17:56:36 <jcajka> I want to start search for new time slot for this meeting so we have higher odds to get together and possibly to also accommodate deparker in PST
17:56:43 <jcajka> are you ok with that?
17:56:48 <eclipseo> yeah
17:56:58 <eclipseo> PST means later
17:57:22 <eclipseo> what timeslot are you proposing?
17:57:24 <jcajka> hopefully he will be able to do some compromise for us in CET ;)
17:57:34 <eclipseo> still on Wesnesday?
17:58:01 <jcajka> I will do the same search/poll as last time staring will all days
17:58:13 <eclipseo> has deparker a preference?
17:58:15 <nim> current time is not ideal for me, it's too late for working hours, and too erly to avoid comlmuting time
17:58:34 <nim> like today
17:58:49 <jcajka> if there is not dissent I will do ahead with that and will send out email tomorrow
17:58:57 <eclipseo> ok
17:59:24 <QuLogic> sounds like we've all got problems with it already, so ok
17:59:50 <jcajka> ack, thank you all for coming
17:59:54 <jcajka> today
18:00:07 <jcajka> hopefully next time we will be under 2h :)
18:00:12 <nim> ok
18:00:16 <jcajka> #endmeeting