15:59:41 <jcajka> #startmeeting Go SIG meeting
15:59:42 <zodbot> Meeting started Tue Apr 16 15:59:41 2019 UTC.
15:59:42 <zodbot> This meeting is logged and archived in a public location.
15:59:42 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:42 <zodbot> The meeting name has been set to 'go_sig_meeting'
15:59:51 <jcajka> #topic Roll Call
16:00:07 <jcajka> Hello and welcome everybody
16:00:49 <eclipseo> .hello2
16:00:49 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:00:56 <jcajka> #chair eclipseo
16:00:56 <zodbot> Current chairs: eclipseo jcajka
16:01:45 <eclipseo> nim nim QuLogic ?
16:02:15 <jcajka> Pharaoh_Atem
16:05:19 <nim_> .hello2
16:05:20 <zodbot> nim_: Sorry, but you don't exist
16:06:08 <eclipseo> #chair nim
16:06:08 <zodbot> Current chairs: eclipseo jcajka nim
16:07:07 <eclipseo> QuLogic: you there?
16:11:17 <jcajka> let's move to the tagged topic
16:11:26 <jcajka> #topic https://pagure.io/GoSIG/go-sig/issue/20
16:12:17 <jcajka> nim I guess this is yours, and might be left over from Dec
16:13:09 <nim> jcajka, that's the whole migration plan
16:13:18 <eclipseo> Point 1: has not moved yet
16:13:29 <eclipseo> we need Tibbs to review apparently
16:13:38 <nim> point 1 is not seing a lot of progress that sucks :(
16:14:02 <nim> the next stages are simulated in the copr I posted last week
16:14:11 <eclipseo> Point 2: can be done immediatily, as I can review packages ASAP. Thouq
16:14:23 <eclipseo> Though it might depens on 1
16:14:36 <jcajka> yeah, that has been my impression and it is going fairly well based on the las week meeting and all the proposals, right
16:14:40 <jcajka> ?
16:15:06 <eclipseo> Point 3: i have done a PR to Packaging Committee and it will be discussed in their next meeting
16:15:10 <nim> you can review the packages, those are the one in the copr, but they won't work without the last handful of redhat-rpm-config changes in #1
16:15:44 <eclipseo> nim ok then I'll send a mail to Tibbs to see if this could be speed up
16:15:45 <nim> eclipseo, if you want changes to the packages in the copr I will do them with or without review
16:15:51 <QuLogic> .hello qulogic
16:15:52 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:15:59 <jcajka> #chair QuLogic
16:15:59 <zodbot> Current chairs: QuLogic eclipseo jcajka nim
16:16:07 <decathorpe> hi guys, sorry for being late. (my IRC client kept crashing)
16:16:17 <decathorpe> .hello2
16:16:20 <zodbot> decathorpe: decathorpe 'None' <decathorpe@gmail.com>
16:16:21 <jcajka> #chair decathorpe
16:16:21 <zodbot> Current chairs: QuLogic decathorpe eclipseo jcajka nim
16:16:41 <eclipseo> nim: I need you to detail me the latest charge on generate buildrequires to update the Guidelines
16:17:19 <decathorpe> also, WRT packaging committee stuff, I hope to be able to help with that
16:17:24 <nim> eclipseo, it's just a genbr rename because upstream rpm decided to use the long generate_buildrequires bit
16:17:49 <nim> eclipseo, in a %generate_buildrequires section because that's how rpm upstream wants to name it
16:18:24 <nim> so gogenbr becomes go_generate_buildrequires and loses some options in the process
16:18:56 <eclipseo> ok
16:19:06 <jcajka> eclipseo: I will review the guidelines on this (for me long eastern) weekend and open some PRs, etc.
16:21:13 <nim> eclipseo, you have a capture of it working on a real go package here
16:21:13 <nim> https://github.com/rpm-software-management/rpm/pull/593#issuecomment-483029345
16:22:36 <nim> decathorpe, there are also some stuck bits in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
16:22:52 <nim> that may or may not be linked to FPC decisions
16:22:55 <eclipseo> nim: gow are we supposed to deal with cyclic deps with generate buildrequires?
16:23:09 <nim> with redhat-rpm-config it's not always easy to make the distinction
16:23:50 <nim> eclipseo, either you patch your sources in %prep
16:24:12 <nim> to have a cut-down source with no cycles
16:24:55 <nim> or you filter the go_generate_buildrequires output with | grep -v baddep
16:25:00 <eclipseo> that's dirty
16:25:01 <nim> to lie to rpm
16:25:16 <eclipseo> ok
16:25:27 <nim> I don't advise lying to rpm, doing prep correctly will cause less problems
16:26:37 <nim> basically, the build generator only report the state of sources to rpm, if the state is cycly the best solution is to change the state
16:27:03 <eclipseo> point 5/6/9: that's in your purview jcajka Can
16:28:50 <eclipseo> jcajka: Can you do 5/6 now? I don't believe anything prior is blocking
16:30:35 <jcajka> eclipseo:  I guess I can merge 5, 6 only when I will see where it will be owned
16:31:38 <nim> 5 has no risk, that's just putting tjhe golist binary in a separate subpackage
16:31:51 <jcajka> it seems to be blocked on having all package up to the latest standard
16:32:00 <jcajka> ...packages...
16:32:18 <nim> 6 will leave some directories unowned, it really should be done at the last minute just before the new macro package rebuild
16:32:23 <eclipseo> 6 depends on having all packages to the standard??
16:33:29 <eclipseo> there's 775 packages to edit and rebuild then
16:34:24 <nim> nope
16:34:29 <jcajka> so we avoid un-owned directories
16:34:37 <jcajka> how we avoid?
16:34:39 <nim> everything you've been building for months will be fine
16:34:45 <eclipseo> I'd like to be able to start on that (I have on COPR) but then we need to move a bit more quickly to get the new macros in
16:35:10 <nim> you'll only have unowned directories for very very old specs that have not been using goinstall
16:35:13 <nim> for a yeart
16:35:16 <nim> year
16:36:04 <nim> it needs to be done at the last minute because it releases /usr/share/gocode that will be picked up by go-filesystem in the new macros
16:36:20 <jcajka> still IMHO we need to find way forward so it is not happening or at least documented it
16:36:58 <nim> so the correct way to do it is release in golang / build the new macros
16:37:14 <jcajka> and push them as one update, right?
16:37:47 <nim> and push as one update
16:37:57 <jcajka> :)
16:38:54 <nim> actually if you want to be complete it's release in golang/build the new macros/build golist using the new macros/deprecate go-compiler and old macro package/push as one update
16:39:17 <eclipseo> All right, so for my part, I have written the Change Proposal: https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines If you need to add or remove things please tell me
16:39:23 <nim> the only thing in here that takes a lot of time building is golang
16:39:43 <jcajka> nim: relatively speaking
16:39:54 <nim> relatively speaking
16:40:03 <nim> it's hard to build as fast as a macro package
16:40:12 <jcajka> yeah :)
16:41:12 <eclipseo> jcajka wanted to make it a SystemWideChange but I don't see that as covered by what we do
16:42:22 <jcajka> eclipseo: IMHO part of the change that is not listed there is making all the packages up to date to the standard
16:42:43 <jcajka> and IMO this is pretty much example definition of system wide change
16:43:43 <decathorpe> well, it's "self contained" in the sense that it does only affect golang packages 😂️
16:44:14 <jcajka> yeah nearly all of them, same as gcc/glibc rebase :D
16:44:22 <eclipseo> jcajka: it's listed
16:44:49 <eclipseo> In Scope: Port existing Go packages to the new macros (it probably won't be finished by Fedora 31)
16:45:49 <jcajka> eclipseo: sorry miss than...
16:46:15 <jcajka> but then it is missing from work needed from other packagers
16:46:33 <jcajka> IIRC
16:46:37 <eclipseo> jcajka: and it's slightly out of the scope of the change, the change is adopt new guidelines, refactoring all the specs is a consequences, but since it's backward compatible, we have time
16:46:52 <eclipseo> jcajka: what other packagers? It's the sig work
16:47:22 <nim> eclipseo, we've done a lot of testing to check it is backwards compatible
16:48:06 <nim> eclipseo, but it' still possible that some specs do such weird things with the previous stuff they won't work as-is
16:48:38 <nim> eclipseo, though, you won't see it before the next rebuild since the produced packages are compatible with one another
16:49:07 <nim> so there is a slight rebuild risk
16:49:45 <jcajka> eclipseo, nim: but the "2nd" party packager(non-SIG) will have to deal with that, unless you will fix up all the packages as part of the change
16:49:54 <jcajka> or am I missing something
16:50:44 <jcajka> ?
16:50:45 <nim> with the current build farm and manpower capabilities it's not possible to check without a mass rebuild
16:51:13 <nim> and that takes so long, by the time you've finished many packages have changed
16:51:26 <eclipseo> jcajka: if there are still packages not in the SIG purview, this need to be fixed by asking maintainer for commit rights
16:51:31 <nim> so at one point, it's press the button and stop waiting for perfection
16:51:51 <jcajka> nim: seems that mass-rebuild(side tag rebuild) is hard requirement for this change
16:52:29 <nim> jcajka, if someone can get the cpu cycles
16:52:34 <eclipseo> why a mass rebuild? mass rebuild implies that we update all the SPEC beforehand, this is not possible
16:52:34 <jcajka> nim: I don't expect perfection, I'm content with just sanity
16:53:16 <nim> eclipseo, no, just mass rebuild to check existing specs build in backwards-compatible mode
16:53:41 <jcajka> nim, eclipseo: side tag rebuild is run in koji, after you have built all packages you "merge(as rpm repo)" them back in to the main tag
16:53:51 <nim> they should, we've tested enough of them, but packagers can be inventive
16:53:53 <eclipseo> beside we will have lots of failures due to the discrepency between old specs and new specs
16:54:25 <nim> actually, I think a mass rebuild will find a lot of failures not due to macro changes at all
16:54:46 <eclipseo> nim yes that what I think
16:54:53 <nim> just because some other package will have been bumped to a new version with slightly different API
16:55:05 <eclipseo> nim just look at Koschei to detect that
16:55:23 <jcajka> nim: it finds many things this is one of them
16:55:23 <eclipseo> but we don't have the manpower to fix them all
16:55:55 <eclipseo> not only that, many packager are left rotting and are not updated upstream to fix the non building parts
16:56:13 <jcajka> eclipseo: IMO having at least sliver of that manpower is requirement for change of this extend
16:56:34 <jcajka> eclipseo: they will be eventually retired based on the FTBFS policy
16:56:38 <nim> yes, that's why I feel that even if some specs do not like the macro changes, there are a lot more of them already broken for other reasons
16:57:19 <nim> jcajka, the aim of the tooling work is to decrease the amount of work to update a spec, to reduce manpower needs over time
16:57:33 <nim> so less things fall by the side
16:58:20 <nim> but, it won't make up for past lacks of manpower in one operation
16:59:40 <nim> things like dynamic buildrequires will help packaging good upstream code with less effort
17:00:00 <nim> but they will also move bad code from semi broken to definitively broken state
17:00:37 <eclipseo> I got to go :(
17:00:49 <eclipseo> I wanted to tark about Fedora Modules too
17:01:09 <eclipseo> how can wemake use of them to build our binary packages like they do in Rust
17:01:36 <decathorpe> I'm not sure that's a good solution, but we can explore it
17:01:48 <eclipseo> that's why I'm trying to track down our cyclic deps
17:02:00 <eclipseo> decathorpe: why?
17:02:03 <jcajka> I also have some reservation towards the Fedora modules
17:02:15 <eclipseo> one codebase, many distro
17:02:38 <nim> eclipseo, I can give you a list of the specs we needed to bootstrap to decycle in the past
17:02:43 <eclipseo> we would only have to maintain the stuff in Rawhide, make sure nothing break
17:02:52 <decathorpe> modularity still has a lot of issues and combining the problematic go packaging with problematic modularity stuff isn't going to make things easier IMO
17:02:58 <eclipseo> nim, if you have that send me a mail
17:03:24 <nim> I'm not sure the module way of bootstrapping is robust enough to scale to the whole Go package set
17:04:03 <nim> I'll answer your thread on the devel list
17:04:19 <jcajka> decathorpe: same here + we will probably have to some how solve how to handle compiler, especially as modules are not parallely installable
17:04:47 <decathorpe> would it help if golist wasn't implemented in go?
17:05:03 <nim> decathorpe, nope
17:05:24 <nim> decathorpe, golist is quite small and easy compared to all the other problems
17:05:26 <jcajka> decathorpe: i would expect that, it should be fairly simple from dep perspective
17:05:35 <jcajka> ...I would not...
17:05:48 <eclipseo> speaking of Golist, have we solve waht we talked last time, about making installed file noarch?
17:06:13 <nim> I made it noarch in the macros as decided
17:06:13 <QuLogic> I've opened a pr for listing all files, need to test it more
17:06:30 <nim> but the actual noarchness depends on golist
17:06:33 <eclipseo> ok
17:07:02 <eclipseo> I got to go now, bbl
17:07:07 <QuLogic> the output made sense for the limited set I had been testing with already
17:07:10 <nim> thanks
17:07:17 <nim> just one more bit
17:07:40 <nim> please read and comment on the issues here https://gist.github.com/nim-nim/9f72827d7cba9637dfe1492364ad9adf
17:07:59 <nim> eclipseo, some of those deal with cycles in Go module mode
17:08:14 <nim> QuLogic, great!
17:08:47 <nim> QuLogic, the redhat-rpm-config in https://copr.fedorainfracloud.org/coprs/nim/macros-ng/builds/
17:08:59 <nim> knows how to download commits from pagure
17:09:31 <nim> so you can take the last building golist spec, bump the commit, and it will rebuild as a new rpm
17:09:39 <nim> you can test other specs against
17:10:13 <nim> ie https://copr.fedorainfracloud.org/coprs/nim/macros-ng/build/881743/
17:10:35 <nim> the next golist build fails because it needs the new rpm with dynamic buildrequires
17:11:56 <nim> Anyway, I wrote for eclipseo but please read, comment and support the issues in https://gist.github.com/nim-nim/9f72827d7cba9637dfe1492364ad9adf
17:12:06 <nim> unless you see a way to do without
17:12:44 <nim> I don't feel go upstream very motivated in fixing things so go modules are usable in a copr/koji/OBS environment
17:13:07 <nim> they'll be even less motivated if I'm the only one arguing about it
17:14:15 <jcajka> nim: they usually expect some participation and code for features, and they are happy to provide guideline and mentoring at least in my experience
17:14:46 <jcajka> i.e. approaching them in constructive manner
17:15:23 <nim> jcajka, my level of go is not up to the task of contributing upstream, and if i spend my time on this who is going to write the macro glue that is also needed?
17:16:00 <nim> jcajka, not to mention, a lot of it is linked to Go modules internal code
17:16:17 <nim> thay don't want to expose that code which I understand
17:17:02 <nim> but that also means they're the only ones who can write the shell interfacing those internal with the rest of the world
17:17:34 <jcajka> nim: I would disagree here, but yeah
17:17:46 <jcajka> I guess we are well on top of the hour
17:18:05 <jcajka> what about to meet ad-hoc next week in the same slot?
17:18:49 <QuLogic> wfm, if we need it
17:19:22 <decathorpe> I'll try to make it as well
17:19:32 <nim> jcajka, anyway, you've a higher level of Go knowledge than me, can you take a look at the issues and at the toy implementation in modist, you'll probably have a better idea than me on what is doable or not without upstream
17:20:01 <nim> I'll try to be available too if needed
17:20:05 <nim> and useful
17:20:47 <jcajka> nim: your issues seemed to be too high level for me, at least the few that I have took a look at, i.e. without any actionable items, thing to implement directly
17:20:59 <nim> modist code is pretty ugly, I learnt things while coding it
17:21:28 <jcajka> but I will probably will no have enough free cycles to lead/code the implementation of these
17:21:37 <jcajka> not have
17:21:57 <jcajka> I will have to go at half past
17:22:07 <nim> jcajka, they're high level because all the low level things were dismissed in the past as "not needed" or "not for you to design" so I just filled the functional requirements koji needs
17:22:59 <nim> and let it up to upstream how it wants to fit them in its design
17:23:21 <eclipseo> i'm back
17:23:34 <jcajka> decathorpe, QuLogic: ack, see you next week
17:23:36 <nim> eclipseo, welcome, we're closing :)
17:23:46 <eclipseo> upstream doesn't really listen to our needs sadly
17:24:05 <eclipseo> they don't seem to care about distribution integration
17:24:23 <eclipseo> I wonder how they do in Debian or OpenSUSE
17:24:32 <eclipseo> next week
17:24:40 <nim> eclipseo, ask Pharaoh_Atem
17:24:54 <decathorpe> 👋️
17:24:55 <eclipseo> I'll send a mail to tibbs hopefully he's not too busy
17:24:56 <nim> eclipseo, he does not seem to have any more magic than us
17:25:10 <jcajka> eclipseo: IMO approach the nim initially took has rather hurt us in their eyes
17:25:49 <jcajka> eclipseo, nim: it would be awesome if you would post/cc what are you doing to the opensuse Go list
17:26:06 <jcajka> I can dig it somewhere
17:26:43 <nim> jcajka, then please do it some other way. Would be happy to let upstream handling to you. The needs are documented now
17:26:54 <nim> jcajka, it only took two months of work
17:27:31 <jcajka> nim: I really don't know what you are missing, but I will try my best
17:27:52 <nim> jcajka, thanks
17:28:11 * Pharaoh_Atem waves
17:28:24 <Pharaoh_Atem> .hello ngompa
17:28:27 <zodbot> Pharaoh_Atem: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:28:33 <nim> Pharaoh_Atem, hello
17:28:50 <Pharaoh_Atem> openSUSE is a complete mess right now
17:28:59 <nim> Pharaoh_Atem, we were wondering if suse of mageia had cracked the go module nut
17:29:02 <Pharaoh_Atem> nope
17:29:07 <Pharaoh_Atem> Mageia uses our stuff generally
17:29:13 <jcajka> #chair Pharaoh_Atem
17:29:13 <zodbot> Current chairs: Pharaoh_Atem QuLogic decathorpe eclipseo jcajka nim
17:29:13 <Pharaoh_Atem> openSUSE has their own tooling, hold on a sec
17:29:48 <nim> Pharaoh_Atem, can you get the suse or mageia guys to look at https://gist.github.com/nim-nim/9f72827d7cba9637dfe1492364ad9adf
17:29:59 <Pharaoh_Atem> openSUSE stuff: https://github.com/openSUSE/golang-packaging
17:30:07 <nim> and tell us if they see another way to integrate go modules in an rpm distro?
17:30:56 <nim> debian is separate, dep format is so loosely specified it seems to me the debian guys are trying to create a go-specific deb subvariant
17:30:58 * jcajka will try to hand around for another 30mins as we have full attendance
17:32:16 <Pharaoh_Atem> nim: one of the former openSUSE golang packaging designers made this version: https://github.com/marguerite/golang-packaging
17:32:33 <nim> Pharaoh_Atem, Latest commit f08bb01 on 11 Jun 2018
17:34:36 <nim> Pharaoh_Atem, the marguerite fork is less ancient
17:34:48 <nim> Pharaoh_Atem, but it seems to do code inspection
17:34:52 <nim> like golist
17:34:57 <Pharaoh_Atem> yeah
17:35:10 <nim> really not the kind of thing you want to do with modules
17:35:11 <Pharaoh_Atem> k8s and friends aren't using modules yet
17:35:39 <nim> Pharaoh_Atem, they told upstream go their module plans were nuts
17:35:51 <nim> Pharaoh_Atem, in much less nicer words than us
17:36:08 <nim> Pharaoh_Atem, but, google + k8s, they could afford to
17:36:58 <nim> we need to convince upstream to make go modules and go module tooling usable for rpm
17:36:59 <eclipseo> nim I've read https://gist.github.com/nim-nim/9f72827d7cba9637dfe1492364ad9adf but I'm not intimate enough with the different partof the process to comment on the issues
17:37:36 <nim> or we'll end up rewriting a code inspection engine in parallel to the official one in modules
17:37:51 <nim> eclipseo, don't worry about the high-level context
17:38:01 <nim> eclipseo, just look at the individual issues and
17:38:15 <nim> how you could use them or not while packaging go code
17:38:38 <nim> you don't need the high-level context, you're living it
17:39:46 <nim> anyway, that was all I had to contribute for today, read the issues, comment, find other solutions, Pharaoh_Atem please relay were useful too
17:39:53 <eclipseo> nim there's an error in a link it should be https://github.com/golang/go/issues/29452
17:39:54 <nim> where
17:40:16 <Pharaoh_Atem> nim: there was a small discussion last fall on opensuse-go ML about Go modules: https://lists.opensuse.org/opensuse-go/2018-11/msg00005.html
17:40:24 <Pharaoh_Atem> but it doesn't seem like much came out of it?
17:41:04 <nim> Pharaoh_Atem, thanks for the link, I'll read it
17:41:47 <Pharaoh_Atem> nim: you might want to talk to the folks in #kubic (as they're the primary openSUSE golang folks now)
17:42:06 <Pharaoh_Atem> and they do have an interest in working with us on developing next-gen Go tooling
17:42:37 <nim> Pharaoh_Atem, ok
17:42:54 <nim> Pharaoh_Atem, you should droop by in SIg meetings more often!
17:43:08 <Pharaoh_Atem> I'll try
17:43:23 <jcajka> Pharaoh_Atem: do you think that sending them the nim's proposal, new packaging guildelines would interest them?
17:43:24 <Pharaoh_Atem> the main thing is that now it doesn't conflict with my lunch hour anymore
17:43:28 <Pharaoh_Atem> jcajka: I think so
17:43:45 <Pharaoh_Atem> jcajka: do you want to try sending to the opensuse-go ML an update on our progress?
17:43:51 <Pharaoh_Atem> I know you're signed up there too
17:44:49 <jcajka> Pharaoh_Atem: I can try , but nim and eclipseo are actually doing it and have more intimate knowledge about it
17:45:08 <Pharaoh_Atem> well, I don't know anything unfortunately :(
17:45:20 <Pharaoh_Atem> I've been busy with burning Python 2 at the stake in Fedora :P
17:45:28 <jcajka> :D
17:45:39 <jcajka> fun
17:45:43 <jcajka> I guess
17:45:55 <nim> Pharaoh_Atem, it's all described in the packaging guidelines eclipseo has been writing
17:46:10 <Pharaoh_Atem> got a link somewhere?
17:46:29 <eclipseo> Pharaoh_Atem: https://eclipseo.fedorapeople.org/guidelines/packaging-guidelines/Golang/
17:46:37 <jcajka> nim: if that it is, I can send the link&co and ask for feedback and collaboration
17:46:44 <nim> and then there is the documented code in https://pagure.io/go-rpm-macros
17:46:55 <nim> and https://pagure.io/golist
17:47:06 <nim> and https://pagure.io/modist
17:47:12 <Pharaoh_Atem> nim: why do we force everything lowercase?
17:47:35 <nim> Pharaoh_Atem, because it all ends up in rpm file names
17:47:47 <nim> and filenames end up on case-insensitive mirrors
17:48:05 <Pharaoh_Atem> does it at least have sensitive Provides?
17:48:16 <nim> IIRC suse has been lowercasing package names consistently way before Fedora acknowledged the problem
17:48:19 <Pharaoh_Atem> because import paths are case sensitive
17:48:25 <decathorpe> (but GitHub URLs are case insentitive too)
17:48:26 <Pharaoh_Atem> nim: actually no
17:48:33 <Pharaoh_Atem> they do the opposite
17:48:39 <Pharaoh_Atem> SUSE mandates case sensitivity
17:48:43 <nim> Pharaoh_Atem, there's not problem in provides
17:48:48 <nim> Pharaoh_Atem, and requires
17:48:57 <Pharaoh_Atem> Mageia (and Mandriva before it) forced lowercasing
17:48:57 <nim> only in package names and versions
17:49:15 <Pharaoh_Atem> decathorpe: not all servers work like github
17:49:17 <nim> Pharaoh_Atem, sorry, I mixed up them
17:49:38 <nim> Pharaoh_Atem, casing in URLs is a huge problem
17:49:48 <Pharaoh_Atem> nim: that's fine, it's just I'm concerned if we make provides lowercased, because bad things happen when mapping back and forth
17:50:06 <nim> the spec says urls should be case sensitive, but many systems do not obey the spec
17:50:44 <Pharaoh_Atem> we've done case sensitive for Perl forever, so I'm not sure why it was a problem to keep doing it
17:52:08 <nim> Pharaoh_Atem it's much nicer not to have to worry about the casing package names use today
17:52:17 * Pharaoh_Atem shrugs
17:52:30 <nim> as opposed to yesteday
17:52:33 <Pharaoh_Atem> I just don't want to be bitten because import paths are case sensitive, and we're naming based on them
17:52:37 <nim> yesterday
17:52:49 <nim> we keep their casing
17:53:09 <eclipseo> Pharaoh_Atem: import path are not concerned, only packages names
17:53:21 <nim> so you get to have all the breakage of upstreams that changed opinion on the way they wanted to be cased over time
17:53:27 <eclipseo> and since we Requires pby import path this is not a problem
17:54:22 <nim> Anyway can you relay our work suse/mageia sida
17:54:24 <nim> side?
17:54:41 <nim> ecliseo and me will answer questions if needed
17:54:56 <Pharaoh_Atem> nim: sure
17:55:37 <eclipseo> man that donkt look very active: https://lists.opensuse.org/opensuse-go/ No message since November :/
17:56:02 <nim> the most important things are eclipseo's packaging guidelines, the modist experiment and the rfe I wrote upstream
17:56:14 <nim> eclipseo, our ML archives are not that full either
17:56:37 <nim> Pharaoh_Atem, thanks!
17:57:40 <Pharaoh_Atem> eclipseo: they've not really done anything since marguerite was kicked out of maintaining it in openSUSE
17:57:54 <Pharaoh_Atem> they just rewrote it from ruby to bash and killed most of its functionality
17:58:00 <Pharaoh_Atem> it's just enough for building k8s and docker
17:59:51 <jcajka> Pharaoh_Atem: cool , so you will do it?
18:00:05 <Pharaoh_Atem> the message, sure
18:00:25 <eclipseo> nice
18:01:45 <jcajka> Pharaoh_Atem: awesome thanks, would you please mind to cc the golang ML list
18:01:56 <Pharaoh_Atem> sure
18:02:10 <jcajka> we are on top of another hour I guess we should end it now :)
18:02:20 <jcajka> any last notes?
18:02:40 <nim> jcajka, thanks for staying!
18:04:36 <jcajka> np :)
18:04:47 <jcajka> #endmeeting