16:00:58 <geppetto> #startmeeting fpc
16:00:58 <zodbot> Meeting started Thu Apr 19 16:00:58 2018 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:58 <zodbot> The meeting name has been set to 'fpc'
16:00:58 <geppetto> #meetingname fpc
16:00:58 <zodbot> The meeting name has been set to 'fpc'
16:00:58 <geppetto> #topic Roll Call
16:01:01 <zodbot> ignatenkobrain: In #fedora-diversity is Diversity Team meeting (starting in 20 hours)
16:01:07 <mbooth> Hi
16:01:12 <geppetto> #chair mbooth
16:01:12 <zodbot> Current chairs: geppetto mbooth
16:01:14 <tibbs> Hey, folks.
16:01:18 <geppetto> #chair ignatenkobrain
16:01:18 <zodbot> Current chairs: geppetto ignatenkobrain mbooth
16:01:20 <geppetto> #chair tibbs
16:01:20 <zodbot> Current chairs: geppetto ignatenkobrain mbooth tibbs
16:01:26 <mhroncok> hi
16:01:45 <geppetto> #chair mhroncok
16:01:45 <zodbot> Current chairs: geppetto ignatenkobrain mbooth mhroncok tibbs
16:01:50 <redi> hi all
16:01:52 <decathorpe> hi everybody
16:01:54 <geppetto> #chair redi
16:01:54 <zodbot> Current chairs: geppetto ignatenkobrain mbooth mhroncok redi tibbs
16:02:39 <ignatenkobrain_> .hello2
16:02:40 <zodbot> ignatenkobrain_: Sorry, but you don't exist
16:02:55 <mbooth> ignatenkobrain_: Sad news from zodbot :-p
16:03:00 <geppetto> :)
16:03:15 <ignatenkobrain_> ;)
16:03:20 * decathorpe waves
16:03:39 <geppetto> #chair decathorpe
16:03:39 <zodbot> Current chairs: decathorpe geppetto ignatenkobrain mbooth mhroncok redi tibbs
16:03:50 <ignatenkobrain> .hello2
16:03:51 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:04:38 <geppetto> .hello2
16:04:39 <zodbot> geppetto: geppetto 'Gep Petto' <geppetto.muc@gmail.com>
16:04:43 <geppetto> haha
16:04:55 <geppetto> that is not me
16:05:02 * geppetto blames ignatenkobrain
16:05:08 <mbooth> .hello2
16:05:09 <zodbot> mbooth: mbooth 'Mat Booth' <mat.booth@redhat.com>
16:05:32 <mbooth> .hello
16:05:32 <zodbot> mbooth: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:05:39 <ignatenkobrain_> .hello james
16:05:40 <zodbot> ignatenkobrain_: james 'James Antill' <james.antill@redhat.com>
16:06:06 * geppetto bows
16:06:19 <redi> .hello2
16:06:20 <zodbot> redi: redi 'Ladislav Ezr' <ladislav@ezr.cz>
16:06:22 <redi> ^^ also not me
16:06:33 <mhroncok> .hello2
16:06:34 <zodbot> mhroncok: Sorry, but you don't exist
16:06:37 <geppetto> Ok, we have 7! … so let's start before everyone introduces themselves as other people :)
16:06:38 <mhroncok> :D
16:06:44 <geppetto> #topic Schedule
16:06:51 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/GYPAAFI5USF4RULRGGZYHQTVKCHJFKXI/
16:07:02 <geppetto> #topic #754 Should py3-foo obsolete py2-foo (when py2-foo is removed)?
16:07:08 <geppetto> .fpc 754
16:07:11 <zodbot> geppetto: Issue #754: Should python3-foo obsolete python2-foo (when python2-foo is removed)? - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/754
16:07:52 <geppetto> mhroncok: This seems like you :)
16:08:19 <ignatenkobrain_> my take on this is that py3 package should not obsolete py2 one
16:08:43 <decathorpe> would this be a use case for fedora-obsolete-packages?
16:09:08 <ignatenkobrain_> I would say that we should not touch those packages
16:09:18 <mhroncok> touch? what packages?
16:09:19 <ignatenkobrain_> because py2 and py3 package usually doesn't have to be in sync
16:09:28 <ignatenkobrain_> so ppl could keep py2 packages on their systems
16:09:43 <mhroncok> oh, touch as in nothing should obsolete them?
16:09:44 <ignatenkobrain_> once py2 interpreter is being removed, they would have to use --allowerasing in any way
16:09:54 <ignatenkobrain_> mhroncok, yes
16:10:14 <mhroncok> I think keeping releases old ptython2 packages on people systems is bad design
16:10:14 <tibbs> I agree; it wouldn't be appropriate for the python3-X package to obsolete python2-X.
16:11:03 <tibbs> I think removing things from systems is bad design unless leaving those things on the systems breaks upgrades.
16:11:12 <mhroncok> I think it has to be obsoleted by something, or it stays there, laying dead
16:11:14 <tibbs> We do not know where the python2 packages come from.
16:11:15 <geppetto> decathorpe: yeh, probably … AIUI this is mostly a cleanup … not a functionality thing, because if you needed the functionality then you'd have the py3 version anyway
16:11:18 <ignatenkobrain_> problem is that if people would like to install py2 packages (for some reason), after us adding Obsoletes they would not be able to... at all
16:11:50 <ignatenkobrain_> if nothing requires py2 package, then it would be `dnf autoremove`'d
16:11:53 <tibbs> If I want to pull a package out of koji and install it, I should be able to do that where the dependencies allow it.  Lying about a python3 package replacing a python2 one is just bad form.
16:11:57 <ignatenkobrain_> so that should not be concern
16:12:04 <redi> yes, it seems like forbidding people from installing py2 packages is bad
16:12:13 <ignatenkobrain_> but if person explicitly installed py2 package, he probably would like to deal with it himself
16:12:15 <decathorpe> I think obsoleting the packages could be optional. however, there are some cases where py3 and py2 modules share common data, which may be incompatible between versions. those have to be handled explicitly
16:12:16 <redi> they'll just rename them to py-foo-two or something
16:12:20 <geppetto> mhroncok: Can you think of any cases where the py3 package wouldn't be installed anyway?
16:12:45 <geppetto> redi: Well newer versions than the obsoletes are fine, so they don't need to rename … but they'll need to rebuild.
16:12:51 <mhroncok> geppetto: I don't understand the question, sorry
16:13:12 <ignatenkobrain_> geppetto, usually, we would add Obsoletes: … < %{version}-%{release}
16:13:18 <ignatenkobrain_> which would be problematic
16:13:57 <geppetto> mhroncok: For instance in the example with python2-django-ajax-selects … I'd expect python3-django-ajax-selects to already be installed for the user, as they still need that dep. … or are there leaf type packages here where they need to move to py3?
16:14:48 <geppetto> ignatenkobrain: yeh, the draft and example do that, right?
16:14:50 <mhroncok> mostly those are either some crap things nothing depends on, honestly
16:15:07 <mhroncok> or a dependency that has been added for a tool that is long on python3
16:15:16 * geppetto nods … so the obsoletes are just a cleanup thing?
16:15:20 <mhroncok> yes
16:15:32 <mhroncok> not to make those python2 packages rod there in the system forever
16:15:38 <decathorpe> I guess it's a non-issue for leaf packages?
16:15:50 <ignatenkobrain_> if package has been installed as dependency and is not required anymore, then `dnf autoremove` will remove it automatically
16:15:52 <mhroncok> we only remove leaf packages
16:15:57 <ignatenkobrain_> or, actually, any `dnf remove ...`
16:16:22 <geppetto> ignatenkobrain: is autoremove still on al the time in dnf?
16:16:43 <ignatenkobrain_> geppetto, not during `dnf install`, but `dnf remove` + `dnf autoremove` yes
16:16:53 <geppetto> ahh
16:16:59 <mhroncok> will that happen when upgrading to new fedora?
16:17:08 <mhroncok> or with a normal update
16:17:09 <geppetto> no
16:17:14 <mhroncok> foo 1 needs python2-bar
16:17:21 <mhroncok> but foo 1.1 needs python3-bar
16:17:30 <mhroncok> will python2-bar get removed when i update foo?
16:17:50 <mhroncok> if not, we need obsoletes
16:18:17 <geppetto> we only need it if leaving py2-bar around causes problems.
16:18:20 <ignatenkobrain_> mhroncok, … or enable removal of unneeded deps during update too (as openSUSE does in zypper, for instance)
16:18:23 <ignatenkobrain_> geppetto, +1
16:18:53 <mhroncok> http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
16:19:23 <mhroncok> While not strictly part of the process, please consider what will happen to systems which have the now-retired packages installed. Generally such packages will simply remain on the system as it is updated, becoming increasingly outdated.
16:19:39 <mhroncok> Please follow relevant packaging guidelines here if another package will be providing similar or identical functionality to the retired package
16:19:53 <mhroncok> python3-foo provides similar functionality as python2-foo
16:20:26 <ignatenkobrain_> I think we need some definition of "similar functionality" ;)
16:20:55 <ignatenkobrain_> for me, python-bunch → python-munch is similar functionality... but python2 → python3 isn't
16:21:06 <ignatenkobrain_> just my 5Kč
16:21:37 <geppetto> I can see the desire to cleanup where it's very very likely that nobody will ever want to py2 version again
16:22:07 <geppetto> On the other hand … it makes it really painful if that isn't true, and the cleanup is pretty minor.
16:22:34 <tibbs> We have no way at all of knowing what code on the system might need the python2 library.
16:22:35 <mhroncok> I just don't understand why would anyone want to reintroduce a python2 subpackage for a library used only for anaconda
16:22:38 <mhroncok> or similar
16:22:39 <ignatenkobrain_> once we drop python2 interpreter, people would have to remove all those packages anyway... but if people decide to maintain it themselves, then we probably should leave path
16:23:16 <tibbs> If we didn't position ourselves as a distro for people doing development, I might take a different view.  But we should expect that there is plenty of code on the system that we didn't put there.
16:23:49 <geppetto> mhroncok: yeh, and if anaconda really is the only user then I agree … might as well obsolete it. But if someone else is using it too (even outside Fedora, as tibbs says) … that it just creates pain.
16:24:05 <geppetto> And the upside isn't that bad … it's just running yum autoremove for the user.
16:24:11 <mhroncok> ok
16:24:22 <mhroncok> I agree that causing pain is bad
16:24:45 <mhroncok> yet I still think not adding the obsoletes will kick us in the future with broken upgrades once we drop python2
16:24:45 <tibbs> As for us needing a better definition of "similar functionality"... the rules surrounding this are more geared towards applications.
16:25:05 <tibbs> So the worst that happens with an application is that you have to learn to click a new icon to start something that has similar functionality.
16:25:25 <ignatenkobrain_> tibbs, as in "xchat vs hexchat" ?
16:25:27 <tibbs> For a library, the worst that happens is some code somewhere breaks.
16:25:44 <tibbs> ignatenkobrain: I believe that's the point.
16:26:22 <geppetto> As a personal experience I know that on F28 I'm been using both the py3 and py2 versions oif dnf.
16:26:40 <geppetto> So if py3 dnf obsoleted py2-dnf I'd have to blame ignatenkobrain ;)
16:27:11 <mhroncok> OK, so we agree that the obsoletes don't have to be added
16:27:42 <mhroncok> now is it up to the maintainer? what should they consider when deciding?
16:27:51 <mhroncok> or is it forbidden?
16:28:25 <geppetto> I think I'm fine with leaving it up the maintainer
16:28:37 <geppetto> tibbs: ?
16:28:38 <decathorpe> I think it should be up to the maintainer. they probably know best where / if the python2 package is used somewhere
16:30:40 <tibbs> I think it's completely impossible for the maintainer to know that.
16:30:53 <mhroncok> to we need a writeup for this or we just say in the ticket that the obsoletes are optional and be done with it?
16:31:08 <decathorpe> tibbs: who would know better?
16:31:24 <tibbs> I think categorically the python3 package simply does not provide sufficiently similar functionality to the python2 package and thus there should never be an obsoletes in this case.
16:31:50 <tibbs> And note that we don't want Obsoletes: without Provides: and I think we can all agree that having a Provides: for this would be a bald-faced lie.
16:31:51 <ignatenkobrain_> tibbs, +1
16:32:36 <geppetto> tibbs: I kind of understand that reasoning … but there are probably a few cases where the dep. is very closely tied to the app. using it, and it's very unlikely that anything else does.
16:32:46 <mhroncok> we don't want Obsoletes: without Provides:?
16:33:21 <tibbs> There's FESCo policy (not packaging guidelines) which dictates that.
16:34:08 <geppetto> Fair enough … we probably shouldn't even encourage it then.
16:34:11 <tibbs> Or at least all of the existing policy talks about using Obsoletes: and Provides: in concert.
16:34:14 <ignatenkobrain_> why don't we say to discuss it case-by-case?
16:34:14 <mhroncok> oh, didn't know that
16:34:15 <mhroncok> If a package supersedes/replaces an existing package without being a sufficiently compatible replacement as defined above, use only the Obsoletes: line from the above example.
16:34:21 <mhroncok> becasue that what the guidelines say
16:34:27 <mhroncok> http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
16:34:47 <tibbs> mhroncok: You're right.
16:34:51 <tibbs> I am misremembering.
16:35:07 <tibbs> Please ignore me.
16:35:11 <decathorpe> yes, but that's for replacements. python3-foo can't replace python2-foo
16:35:24 <decathorpe> (at least not directly)
16:35:36 <mhroncok> it can supersede it
16:35:43 <tibbs> Note that some of this is bound up on what yum/dnf would do in particular circumstances, not necessarily what makes sense.
16:36:10 <mhroncok> I've been bit in the past by not obsoleting removed packages
16:36:36 <decathorpe> would adding applicable python2-foo packages to fedora-obsolete-packages be a better solution than adding the obsoletes to the python3-foo package?
16:36:37 <mhroncok> users are reportuing bugs to long gone things, becasue they have ....fc24... installed on their system and suprise suprise it doesn't work any more
16:36:53 <tibbs> As a distro, what we care about is that dnf update and dnf system-upgrade work.
16:36:55 <mhroncok> decathorpe: it would briong all the other problems here
16:37:03 <mhroncok> sorry, all the mentioned problems
16:37:11 <mhroncok> except it will be less maintainable
16:37:13 <tibbs> To make sure that dnf system-upgrade doesn't have dependency problems, we have fedora-obsolete-packages.
16:37:48 <tibbs> So please remember that there are other ways to get rid of python2 packages that actually cause problems besides having the python3 packages obsolete them.
16:37:50 <mhroncok> so once we drop python2, we will add 3000 obsoletes lines to fedora-obsolete-packages?
16:38:06 <tibbs> Only if having those python2 packages on a system will cause dependency problems.
16:38:36 <decathorpe> I could argue that could be decided case by case. if python2-foo has to be nuked, add it to fedora-obsolete-packages. if you want users to get the python3 version instead, add the obsoletes to the python3 package
16:38:40 <mhroncok> like they require python2 and python2 was removed so it isn't build for the new libraries and thus has unmet dependencies?
16:38:42 <ignatenkobrain_> --allowerasing should solve all such problems
16:38:47 <tibbs> I'm just against cleaning up python2 stuff just because having the packages there looks less pleasant when someone does rpm -qa.
16:38:48 <ignatenkobrain_> and IMO should be default behavior of dnf
16:39:14 <geppetto> ignatenkobrain: I'd disagree with the later, and when it's not then it doesn't help the upgrade case.
16:39:25 <geppetto> ignatenkobrain: Although maybe it should be the default for system upgrade.
16:40:01 <geppetto> tibbs: mhroncok: How do you feel about that … letting dnf system-upgrade use --allowerasing ?
16:40:28 <tibbs> That seems like a decision which is not up to us.
16:40:30 <mhroncok> for this case, thta works for me, however what if it starts removing pakcages people actually use/want to keep?
16:40:36 <tibbs> I have no idea what the implications would be.
16:40:44 <mhroncok> exactly
16:41:15 <geppetto> tibbs: It let's dnf remove "unrelated" packages to the upgrade, if that helps the upgrade.
16:41:17 <tibbs> I would in general prefer to be told before doing dnf system-upgrade reboot that there is some dependency problem and being given the choice of how to deal with it.
16:41:29 <ignatenkobrain_> tibbs, that's what it does now
16:41:38 <ignatenkobrain_> and shows that you could solve problem by passing --allowerasing
16:41:56 <mhroncok> we are stuck on this for 40 minutes not having any conclusion. can we postpone it for next week maybe, let it settle in us?
16:42:36 <tibbs> Well, I think it's relatively obvious that there isn't support for categorically adding obsoletes into python3 packages.
16:42:41 <geppetto> mhroncok: Sure … although this is the only new ticket, and IIRC there is only one older one that needs a look.
16:42:56 <geppetto> tibbs: yeh, even mhroncok agreed with that.
16:42:59 <tibbs> There are other options which have been proposed, and those should make it into the ticket so that everyone can read up.
16:43:16 <geppetto> Fair enough.
16:43:29 <mhroncok> tibbs: that has been obvious
16:43:29 <mhroncok> so should we ban it, should we say it's optional?
16:43:40 <mhroncok> and if we say it's optional, what should be considered form the packaging perspective?
16:44:21 <tibbs> I think the current guidelines cover the situation and indicate that obsoletes should not be added in any case.  But certainly fleshed out proposals should be added to the ticket.
16:45:06 <ignatenkobrain_> yeah, let's move on
16:45:19 <geppetto> #action People to add new proposals to the ticket, mainly on if we should ban it or allow it (and how/when).
16:45:41 <geppetto> #topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
16:45:44 <geppetto> .fpc 743
16:45:46 <zodbot> geppetto: Issue #743: Add link to C/C++ build flag documentation in redhat-rpm-config - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/743
16:46:03 <geppetto> So I think this was mbooth's action item … but I tab completed wrong?
16:46:39 <mbooth> geppetto: It was -- sorry I'll try and get it written up for next time
16:46:43 <mhroncok> I think all that has to be said is the following: (give me a minute to type it)
16:46:52 <mhroncok> If a package supersedes/replaces an existing package without being a sufficiently compatible replacement as defined above, use only the Obsoletes: line from the above example. (Note that a Python 3 version of a library does not generally supersede the Python 2 version of such.)
16:47:02 <geppetto> mboddu: Ok, did you want any help from some new people?
16:47:22 <ignatenkobrain_> geppetto, mbooth ;)
16:47:33 <tibbs> fweimer's comment there is completely correct; the RPMMacros page is a mess and I never could quite come up with anything better.
16:47:57 <geppetto> mhroncok: Sure, that seems like an ok proposal … to me.
16:48:29 <ignatenkobrain_> mbooth, if you would have any questions regarding all those new flags / docs - I could help
16:48:45 <mbooth> ignatenkobrain_: Thanks :-)
16:48:48 <tibbs> What I was working on last year is at https://fedoraproject.org/wiki/User:Tibbs/RPMMacros
16:49:21 <tibbs> I'm not a particularly good person to do that kind of thing because I abhor using macros for paths when there is no need to do so.
16:51:43 * geppetto nods
16:51:56 <geppetto> #topic Open Floor
16:52:25 <tibbs> We got a ticket thanking us in #760.
16:52:30 <tibbs> .fpc 760
16:52:31 <zodbot> tibbs: Issue #760: NotABug, a Kudos - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/760
16:52:49 <tibbs> I figure I would mention it before closing it.
16:52:53 <geppetto> ha :)
16:53:11 <tibbs> And I will close out 763 as well since I think we're done.
16:53:17 <tibbs> .fpc 763
16:53:19 <zodbot> tibbs: Issue #763: New member bureaucracy - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/763
16:53:21 <geppetto> .fpc 710
16:53:24 <zodbot> geppetto: Issue #710: Ruby packaging guidelines update - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/710
16:53:40 <tibbs> Oh, yeah, we really do need to deal with the ruby thing.
16:53:47 <tibbs> It's been sitting for far too long.
16:54:00 <geppetto> I'm not sure what needs to be done
16:54:10 <mhroncok> me neither
16:54:19 <mhroncok> was there a problem with this being applicable on f28+ only?
16:54:43 <ignatenkobrain_> I think just replacing existing guidelines with vondruch ones
16:54:56 <geppetto> I _think_ the problem was we want it to go live for F28 … but not be used for F27 or earlier
16:55:13 <decathorpe> why is that a problem?
16:55:16 <tibbs> I think this turned into a big mess about whether the guidelines covered rawhide, or all supported Fedora versions, or Fedora and EPEL, or something else.
16:55:34 <tibbs> But that question was resolved in a separate ticket.
16:55:47 <geppetto> decathorpe: because F28 isn't live yet … so someone wants to do a new ruby package a month ago looking at the guidelines wouldn't be able to get that into F27
16:56:02 <tibbs> (To say that the guidelines cover all supported Fedora versions, and will indicate specifically when there are packaging differences between those releases.)
16:56:16 <decathorpe> gepetto: ah, I understand what you mean
16:56:44 <tibbs> Note that at the time the ticket was filed, F28 was still quite a ways off.
16:56:48 <decathorpe> but then this can never move forward, because old fedora will never support the new stuff?
16:56:53 <tibbs> Six months later, F28 is a real thing.
16:56:54 <mhroncok> why cannot we add the new guidelines and add a warning box that says: This only applies to 28+, if you targed somehting older, see the Older_Ruby_guidelines here
16:57:03 <geppetto> tibbs: So are we good here … just need an "F28+" label somewhere?
16:57:05 <tibbs> mhroncok: That's what we do, in general.
16:57:06 <decathorpe> mhroncok: exactly
16:57:27 <ignatenkobrain_> so let's just put this in and add a warning ;)
16:57:33 <tibbs> But the issue is that some things are so early that there just isn't much point in making it look like that's the proper way to do it.
16:57:43 <geppetto> #topic #710 Ruby packaging guidelines update
16:58:07 <geppetto> Ok, so everyone want to vote? … with the proviso it needs to be labeled F28+
16:58:07 <tibbs> And that draft starts with mention of Fedora 19, which.... is probably off.
16:58:31 <tibbs> Sadly I don't have enough context swapped in to be able to vote now.
16:58:46 <tibbs> And there's the question of where you go to get guidelines which work on F27.
16:58:52 <ignatenkobrain_> actually
16:58:53 <ignatenkobrain_> it's F27+
16:58:56 <geppetto> Yeh, I'm mainly going off the fact I'm sure I thought it was fine at the time.
16:59:09 <tibbs> Right, there's a block about F26 or older.
16:59:12 <ignatenkobrain_> yep
16:59:17 <ignatenkobrain_> and F26 is.... almost dead
16:59:31 <decathorpe> so  ...it's even less of an issue?
16:59:35 <tibbs> Yes, it should be OK to have F27+ only things in the guidelines now.
16:59:40 <geppetto> yeh
16:59:41 <tibbs> Six months ago, that was tougher.
16:59:53 <mhroncok> it shouldn't have been
16:59:56 <ignatenkobrain_> proposal: fix minor issues and put new guidelines in place
17:00:05 <mhroncok> it should be normal to add new rawhide only stuff to the guidelines
17:00:08 <tibbs> But what are the minor issues?
17:00:24 <tibbs> I seem to recall that I was happy with these ages ago.
17:00:41 <ignatenkobrain_> I can take task in reviewing them once more and then write all things I found in ticket
17:01:01 <tibbs> If you haven't gone over them already, it would be good if you did.
17:01:26 <tibbs> I can just barely remember things from six months ago.
17:01:31 <geppetto> #action ignatenkobrain will review guidelines and write summary in the ticket.
17:01:35 <mhroncok> I haven't read this either, so count me in to read that as well
17:01:57 <geppetto> cool.
17:02:04 <geppetto> #topic Open Floor
17:02:04 <mhroncok> #action mhroncok will review guidelines and write summary in the ticket as well
17:02:17 <geppetto> Ok, so we are only 2 minutes over this week … getting better :)
17:02:23 <geppetto> Anything quick before I close the meeting?
17:02:29 <ignatenkobrain_> I have one thing
17:02:55 <ignatenkobrain_> .fpc 727
17:02:57 <zodbot> ignatenkobrain_: Issue #727: convert guidelines to git and restructured text - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/727
17:03:00 <ignatenkobrain_> just small announcement
17:03:08 <ignatenkobrain_> I'm going to work on this tomorrow with bex
17:03:19 <ignatenkobrain_> and will try to come up with something for next meeting
17:03:25 <tibbs> This time slot gives us two hours so we should feel free to go long if we're getting something done.
17:03:47 <tibbs> I would certainly like to look at how things come out after conversion to asciidoc.
17:03:56 <decathorpe> I think next week it's only one hour
17:03:59 <geppetto> tibbs: the when is good still only had an hour … so I don't want to intentionally go long
17:04:14 <tibbs> Both the formatted documents and the source which I'll have to learn to live in.
17:04:54 <tibbs> Also, my phone is doing odd things with the ical file.
17:05:19 <tibbs> Every other meeting shows up twice; is anyone else seeing that?
17:05:33 <tibbs> (You can get an ical feed from the Fedora calendar.)
17:06:23 <mbooth> ignatenkobrain_: I look forward to seeing this :-)
17:06:29 <geppetto> tibbs: yeh, I see it
17:06:34 <tibbs> I think it's actually the calendar itself, because https://apps.fedoraproject.org/calendar/packaging/2018/4/23/ shows the meeting oddly.
17:06:48 <decathorpe> sorry, I have to leave now to catch a bus. until next week!
17:06:57 <tibbs> Take care.
17:07:29 <tibbs> Let me see if I can fix the calendar page.
17:07:58 <geppetto> yeh, all of the entries seem to be for the same time/etc.
17:08:07 <geppetto> I might have confused it when I changed to the new time.
17:08:15 <tibbs> The problem was that there were two entries set to reoccur every 14 days.
17:08:30 <geppetto> ahh
17:08:43 <tibbs> Then one of the meetings was set to reoccur every 7 days, and the other was left in place.  I just deleted one of them and it looks correct now.
17:09:02 <tibbs> Or at least it has a meeting every week at 1600.
17:09:11 <geppetto> cool :)
17:09:13 <geppetto> 👍
17:09:24 <tibbs> I'm glad to be past that time/day shift thing.  Even though I think it was my idea.
17:09:40 <mbooth> tibbs: Live and learn :-)
17:09:51 <tibbs> Just refreshed my phone and everything looks good now.
17:10:12 <geppetto> tibbs: yeh, it was way more painful than I thought it'd be
17:10:37 <tibbs> I certainly know now how much a creature of habit I really am.
17:11:14 * geppetto nods
17:11:23 <tibbs> Anyway, thanks for all of this.  I have most of today blocked off to do writeups and stuff so I'll get back to that.
17:11:34 <ignatenkobrain_> enjoy ;)
17:11:48 <geppetto> Ok, cool. :)
17:11:58 <geppetto> Ending now :)
17:12:01 <geppetto> #endmeeting