16:00:22 <geppetto> #startmeeting fpc
16:00:22 <zodbot> Meeting started Thu Mar 15 16:00:22 2018 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:22 <zodbot> The meeting name has been set to 'fpc'
16:00:22 <geppetto> #meetingname fpc
16:00:23 <geppetto> #topic Roll Call
16:00:23 <zodbot> The meeting name has been set to 'fpc'
16:00:31 <orionp> hello
16:00:35 <geppetto> #chair orionp
16:00:35 <zodbot> Current chairs: geppetto orionp
16:00:39 <tibbs> Morning.
16:00:43 <mbooth> Hola
16:00:47 <geppetto> #chair tibbs
16:00:47 <zodbot> Current chairs: geppetto orionp tibbs
16:00:51 <geppetto> #chair mbooth
16:00:51 <zodbot> Current chairs: geppetto mbooth orionp tibbs
16:01:13 <tibbs> Timezones and whatnot really have me thrown off yet again.
16:01:42 <geppetto> yeh, same ... although the meeting follows the US but everything else is still pain.
16:05:38 * limburgher here
16:06:54 <geppetto> hey
16:06:57 <geppetto> #chair limburgher
16:06:57 <zodbot> Current chairs: geppetto limburgher mbooth orionp tibbs
16:06:59 <mbooth> Huh, I didn't even notice it was an hour earlier than usual :-)
16:07:26 <geppetto> that's the fab. five!
16:07:40 * limburgher is so fab you can't even
16:07:47 * geppetto does the quorum dance
16:07:59 <limburgher> :mirror_ball:
16:08:33 <geppetto> 👍
16:08:48 <geppetto> #topic Schedule
16:08:50 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/S6JJRBPNBWM5QJXEXWITCDBOBPOE5GJB/
16:09:02 <geppetto> #topic #738 Mangling shebangs
16:09:10 <geppetto> .fpc 738
16:09:12 <zodbot> geppetto: Issue #738: Mangling shebangs - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/738
16:10:19 <limburgher> I personally love that in the title for Option C, the word mangling is itself mangled.
16:10:51 <tibbs> The actual draft is in https://pagure.io/packaging-committee/issue/738#comment-490276
16:11:28 <limburgher> Ah, right.
16:11:40 <tibbs> It's just adding mention of the automatic mangling to the main guidelines page, and documentating how to turn it off if necessary.
16:12:12 <tibbs> And then adding a bit to the python guidelines mentioning the special treatment of ambiguous python shebangs.
16:12:21 <limburgher> https://pagure.io/packaging-committee/issue/738#comment-490366 actually.
16:12:34 <limburgher> Looks ok from here.
16:13:00 <tibbs> You're right, though he edited both.  It does get overly confusing.
16:13:35 <tibbs> But in any case, this has all been live for a while in F28+.  The guidelines bit is just documentation.
16:14:20 <limburgher> So I've observed.
16:14:39 <limburgher> Maybe we should do this in a wiki.
16:14:40 * limburgher ducks
16:15:27 <geppetto> Ok, I'm +1
16:15:31 <tibbs> +1
16:15:36 <limburgher> +1
16:15:42 <mbooth> Yeah +1
16:16:16 <geppetto> orionp: vote?
16:16:28 <orionp> +1
16:16:41 <geppetto> #action Mangling shebangs (+1:5, 0:0, -1:0)
16:16:45 <geppetto> Ok, done
16:16:52 <geppetto> #topic #750 Add note about `__brp_mangle_shebangs_exclude(_from)?
16:16:55 <geppetto> .fpc 750
16:16:59 <zodbot> geppetto: Issue #750: Add note about `__brp_mangle_shebangs_exclude(_from)?` - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/750
16:17:20 <tibbs> I think this is rolled into the one we just did.
16:17:26 <limburgher> Yes.
16:17:27 <geppetto> tibbs: Do you know why this is it's own ticket?
16:17:30 <geppetto> Ok, cool
16:17:48 <geppetto> #info Was dealt with as part of 738, closed.
16:17:58 <tibbs> Basically because we took too long to get to these, and people don't like waiting for us.
16:18:10 <limburgher> *cough*694*cough*
16:18:26 <geppetto> #topic #751 Packaging:Guidelines#Noarch_with_Unported... is outdated
16:18:31 <geppetto> .fpc 751
16:18:32 <zodbot> geppetto: Issue #751: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_Unported_Dependencies is outdated - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/751
16:19:22 <geppetto> So I believe rattan is happy with this now ... and he was the only objection before
16:19:28 <geppetto> So ... +1
16:19:46 <limburgher> +1
16:19:58 <tibbs> +1 though I still don't understand why adding noarch makes any difference.
16:20:23 <orionp> koji weirdness +1
16:20:27 <tibbs> (In my tests, it did not make any difference, and nobody I asked seems to understand what difference it could actually make.)
16:21:08 <geppetto> mbooth: vote?
16:21:25 <mbooth> Sure +1
16:21:29 <mbooth> Sorry, distracted
16:21:33 <geppetto> #action 751 Packaging:Guidelines#Noarch_with_Unported_Dependencies is outdated (+1:5, 0:0, -1:0)
16:21:39 <geppetto> no problem
16:21:57 <geppetto> #topic Open floor
16:22:02 <limburgher> 694?
16:22:11 <geppetto> Ok, so we have a bunch of open tickets ... but afaik none have updated
16:22:21 <geppetto> limburgher: is there anything to discuss on it?
16:22:54 <limburgher> geppetto, it doesn't seem that we're waiting on anything from the submitter.
16:23:02 <geppetto> Hmm, weird how have we not discussed this since the meeting tag was added???
16:23:16 <geppetto> #topic #694 Packaging guidelines for application independence
16:23:24 <geppetto> .fpc 694
16:23:26 <zodbot> geppetto: Issue #694: Packaging guidelines for application independence - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/694
16:23:26 <limburgher> geppetto: My thoughts exactly.
16:24:26 <tibbs> I honestly don't get this.
16:24:49 <tibbs> Gnome software is deficient, so we should discourage something.
16:25:38 <tibbs> If an application has some dependency then it has that dependency, doesn't it?
16:26:13 <geppetto> I read it as "we'd like to tweak the wording so that packagers split packages into sub-packages more often ... as that is better"
16:26:18 <geppetto> which I'm fine with.
16:26:29 <tibbs> I read it as the opposite.
16:26:55 <tibbs> They don't want one graphical application depending on another graphical application.
16:26:58 <limburgher> It's all shoulds, so we're still free to ignore it if necessary.
16:27:10 <limburgher> geppetto, tibbs: I think it's both.
16:27:18 <limburgher> One in pursuit of the other.
16:27:20 <tibbs> But the thing is, it's not up for us to decide this.
16:27:35 <geppetto> who then?
16:27:35 <limburgher> tibbs: And I agree with you.
16:27:39 <limburgher> Packager.
16:27:52 <tibbs> If I am packaging something that wants to call, say, an external document previewer, then... that's what it does.
16:28:02 <geppetto> Sure, but we can tell them "XYZ works better"
16:28:03 <limburgher> Basically if you think a package overrequires, file a BZ or a PR.
16:28:32 <limburgher> Like, inkscape pulls in a &%*^%(()*^(*ton of stuff because it needs it.
16:28:47 <geppetto> I think the reason for this is that when you file that BZ you'd like something to point to saying why they should change.
16:29:04 <tibbs> But if it needs it, then it needs it, right?  So what point does this have besides verbiage?
16:29:16 <geppetto> This is specifically about "applications"
16:29:31 <tibbs> Sure, but that doesn't change anything that I've said.
16:29:45 <geppetto> Basically even if two applications share 99% of their code, they want the application bits to be installable separately.
16:29:48 <limburgher> geppetto, which fortunately is a 100% unambiguous term. :)
16:30:02 <sgallagh> Might I make an alternative suggestion? We add an automatic Provides feature that notices every package that carries a desktop file. GNOME Software can then inspect the transaction for a virtual `Provides: x-desktop-file(<name>)` beyond the one they tried to install and opt to prompt the user for confirmation
16:30:14 <tibbs> Well we do have a bit about the difference between an application and a library, so at leat that should be relatively clear.
16:30:23 <sgallagh> Their primary concern is applications appearing without express permission, which I can understand
16:30:23 <geppetto> limburgher: Don't make me type out "the BS xml format for graphical apps. that gnome-software misdesigned" every time, or I might hurt you
16:30:37 <limburgher> prompt? Breaks non-interactivity.
16:30:54 <sgallagh> limburgher: Well, maybe the prompt happens only when running interactively, then
16:31:02 <sgallagh> I'm throwing out a straw-person here
16:31:04 <tibbs> I think if you're installing through gnome softwre then non-interactivity isn't relevant, though.
16:31:19 <limburgher> Right, so put the code there, and skip the guideline.
16:31:31 <tibbs> I've never seen or had any occasion to interact with gnome software, so I don't even know what it does.
16:31:31 <geppetto> sgallagh: If gnome-software wants that I'm happy to do it ... but the ticket says they are solving it anyway ... and from past experience they like to always download the file lists anyway, so probably happy to just use that
16:31:43 * sgallagh shrugs
16:31:46 <tibbs> Or why we would need to add guidelines to cope with something it can't do.
16:32:09 <geppetto> It can workaround it now, from what I read in the ticket ... it's just better UI to have the split.
16:32:13 <sgallagh> tibbs: It basically front-ends PackageKit to show only those things that are desktop apps or plugins for same
16:32:26 <sgallagh> So it's fundamentally an app-store without the financial bits
16:33:17 <geppetto> All this boils down to "splitting packages up is better when it's possible" ... which I thought we'd all agree on.
16:33:22 <tibbs> So there are basically two things here.
16:33:53 <tibbs> One is "split apps and libraries when possible" which... OK.  That overlaps and potentially conflicts with something we already have.
16:34:41 <tibbs> And the other is "graphical apps shouldn't depend on other graphical apps because gnome software doesn't understand that" which seems an unfortunate thing to write into the guidelines.
16:35:05 <limburgher> Right.
16:35:09 <limburgher> To both.
16:35:16 <tibbs> So if we accepted the first part, it would conflict with https://fedoraproject.org/wiki/Packaging:Guidelines#Libraries_and_Applications
16:35:35 <geppetto> tibbs: The second is now "graphical apps. shouldn't depend on other graphical apps. because it'd bad UI/UX"
16:35:36 <tibbs> Right now all we care about is dependencies.
16:36:05 <limburgher> I feel like -1 to this and a software center patch is a good path forward.
16:36:10 <tibbs> I really don't want to get into telling people to avoid bad UI in packaging guidelines.
16:36:30 <limburgher> tibbs: nods
16:36:38 <sgallagh> Not that I have a vote, but I agree with tibbs and limburgher here
16:36:39 <tibbs> And honestly I like what we currently say about splitting libs from apps in the section I linked.
16:36:59 <tibbs> In fact, I think that section almost always already covers that section.
16:37:08 <sgallagh> Which is why I was suggesting an alternative approach that might make it easier for GNOME Software to work around it
16:37:10 <geppetto> tibbs: I don't see how it conflicts ... all the cases they care about are mixed use packages, and they want to suggest people do #1.
16:38:23 <tibbs> The conflict is that you can read the Libraries and Applications section, think you're cool with your decision not to split the package, and then someone points out this other unrelated section which tells you you're wrong.
16:39:31 <tibbs> But really, in most cases, the requirement to split for dependency minimization is almost always going to imply that you would split a library out of a UI front end, because the UI is going to have the X toolkit dependencies and such.
16:40:37 <tibbs> So my point is that we basically already say what they want us to say.
16:41:02 <geppetto> Do you want to reword their draft to point to the generic section?
16:41:24 <tibbs> I don't personally, because I don't agree with their draft at all.
16:43:14 <geppetto> But you would agree with it if they pointed back to the generic wording, right?
16:44:09 <geppetto> Like "Here is the guidelines on splitting apps/libs. ... and it'd probably better for the user experience if you treat "X" apps. as the mixed case"
16:45:10 <tibbs> Having trouble phrasing it.
16:45:49 <tibbs> Is "the user experience" how one paticular aplication (which I've never used, so I can't really comment on it) chooses to handle something?
16:46:04 <hughsie> I've just read the backlog of this meeting and I'm sorry to say a few people have some things they should be ashamed about
16:46:11 <tibbs> Or are you saying that graphical applications which spawn other graphical applications bad _in general_?
16:46:30 <sgallagh> hughsie: Just for the record, that's a poor opener if you want to change minds.
16:47:15 <limburgher> tibbs: I feel like they're targeting Jane and Joe GUI, which is a totally valid use case.
16:48:30 <geppetto> tibbs: The user experience here is more like "I don't like FOO, so I want to get rid of it ... but it tries to get rid of BAR, which I want."
16:48:50 <geppetto> tibbs: Or "I want to install FOO, but it brings in BAR which confuses me"
16:48:58 <hughsie> sgallagh, fair point, but i'm pretty disappointed. One other person told me they don't want to participate in the meeting due to the language used
16:49:34 <limburgher> A GUI option to say why would be cool but I'm not sure of a good way to implement other than Because FOO Needs Bar.
16:51:25 <tibbs> I'm really straining to come up with any strong or difficult language used in this discussion.
16:51:33 <mcatanzaro> Hi, I was just pointed to this discussion! It looks like the primary concern is the interaction between my proposed new section of the guidelines and https://fedoraproject.org/wiki/Packaging:Guidelines#Libraries_and_Applications?
16:51:43 <limburgher> I see an abbreviation and my Perl one-liner. . .
16:52:17 <tibbs> mcatanzaro: That's one of my concerns, but not the primary one.
16:52:22 <mcatanzaro> Perhaps I could rework the proposal a bit to make it a subpoint of Libraries and Applications?
16:52:29 <hughsie> tibbs, does "the BS xml format for graphical apps" count?
16:52:49 <limburgher> And I complained about inkscape packaging, but I know the maintainer, she is me, and I took no offence.
16:53:12 <geppetto> tibbs: Pro tip: If house is complaining, it's my fault :)
16:54:00 <mcatanzaro> tibbs: The other concern I saw seemed like a complaint that Software does not expose packages, but that doesn't seem like a valid concern because Software is our graphical software installer, and that's a done deal for several years now. I don't think it would be wise to pretend that Software does not exist when maintaining the packaging guidelines
16:54:01 <mcatanzaro> . Do I misunderstand this concern?
16:54:01 <zodbot> mcatanzaro: Error: You don't have the do capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
16:54:20 <mcatanzaro> zodbot: do do do
16:54:20 <zodbot> mcatanzaro: Error: You don't have the do capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
16:54:29 <geppetto> hughsie: But, I apologize for denigrating your work. It was meant in fun, due to the confusing use of the word applications ... but I can see how you'd not appreciate it.
16:55:43 <hughsie> thanks
16:55:44 <tibbs> mcatanzaro: So I did try to articulate this already, but let me try a different tack.
16:56:24 <geppetto> Anyway ... we have 5 minutes left, so can we give feedback that the draft should point back to Packaging:Guidelines#Libraries_and_Applications with wording about treating graphical apps. as mixed case?
16:56:38 <geppetto> Then we can discuss whatever new wording they come up with?
16:56:48 <tibbs> First issue is that we do already have the bit about when you need to split libraries out of an application, and so it would be good to link the draft under consideration in with that.
16:57:23 <tibbs> The second is that I personally fundamentally disagree that it's a bad thing for one graphical application to depend on and call out to another graphical application.
16:58:09 <tibbs> I mean, if I was writing something and needed a PDF preview or something, I'd ceratinly start with just calling the previewer directly.
16:58:13 <geppetto> I think there are cases where that's true ... but they are the exception and not the rule
16:58:50 <tibbs> Well I certainly still believe in the "collection of independent tools" concept.
16:59:16 <mcatanzaro> tibbs: Yes, there are some valid cases where one graphical app really needs to depend on another. That's why we watered down the proposal by changing all the MUSTs to SHOULDs, for instance. An earlier draft included some more discussion on this, but I wound up cutting it down to minimize size. I could add some text about this if you want.
16:59:20 <tibbs> But even if it's not about me, it's about reality.
16:59:29 <geppetto> Right, and I'm saying that the graphical people nudging packagers toward splitting isn't a bad thing.
16:59:36 <mcatanzaro> The canonical example we've been using is a video game level editor: it doesn't make any sense without the video game installed.
17:00:21 <mcatanzaro> Our goal is more to discourage *unnecessary* dependencies, like dependencies on the Java control panel, rather than actual useful dependencies. So some work in Software is required to handle graphical dependencies properly regardless.
17:00:24 <tibbs> But here's the thing: If I'm packaging something, and it shells out to xdvi, then.... that's what it does.
17:00:52 <tibbs> SHOULD, MUST, it makes no difference.  I'm not going to rewrite the thing to include an embedded DVI previewer.
17:00:54 <mcatanzaro> tibbs: But you don't need or want the xdvi desktop file installed in that case.
17:01:26 <tibbs> So... you're saying that xdvi itself should have the .desktop file subpackaged?
17:01:37 <mcatanzaro> Actually, I guess you do, because shell application tracking won't work without it. So maybe I'm wrong here.
17:01:39 <tibbs> Or did I completely misunderstand what you meant.
17:01:51 <mcatanzaro> I think I wrote hastily. ;)
17:02:22 <tibbs> Well, ignore for a second the concept of shell application tracking.  ANd try to forget that I mentioned the hideous xdvi for a second.
17:03:01 <tibbs> Would putting just the .desktop file in a separate package actually resolve the gnome software issue?
17:03:14 <tibbs> Not that I'm proposing that; I'm just trying to understand the underlying problem better.
17:03:14 <mcatanzaro> Yes, but that wouldn't be the right solution in this case.
17:03:30 <mcatanzaro> I think the right solution would be to use a tool like xdg-open to decide the best application to use for opening the DVI
17:03:42 <mclasen> xdg-open is never the right answer
17:03:48 <mcatanzaro> E.g. on a GNOME desktop, the user would probably much prefer to use evince for that. Or maybe the user likes Okular instead.
17:04:19 <mcatanzaro> There are APIs in GIO and Qt that do what xdg-open does without using xdg-open; that's just for sake of example.
17:04:53 <mcatanzaro> So I think this is indeed a case of a dependency that should be discouraged. I would not want to use this application at all if it cannot open files in my preferred document viewer.
17:05:18 <mcatanzaro> tibbs: Does that make sense? It's hard to compress that thinking into a short amount of packaging guideline space, though. :(
17:05:32 <tibbs> But that basically says "don't package something that we don't think provides a good user experience".
17:05:51 <mcatanzaro> Or, better: "fix it"
17:06:02 <limburgher> tibbs: Which is a gateway to a KDE/GNOME flamewar.
17:06:10 <geppetto> #chair racor
17:06:10 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor tibbs
17:06:36 <mcatanzaro> We can provide SHOULDs to nudge packagers into encouraging upstreams to improve their software, IMO.
17:06:50 <geppetto> limburgher: Even if true, having some words saying what the best practice is to have a nice UX seems fine.
17:07:41 <mcatanzaro> tibbs: Do you disagree that installing some application and seeing it pull in xdvi is undesirable? I think many Fedora users are rather fussy about the software installed on their computers; I would be frankly offended if I saw an application that I did not want suddenly installed.
17:08:05 <tibbs> I don't think that valid dependencies are a problem.
17:08:06 <limburgher> T-shirt: texlive and live with it.
17:08:56 <mcatanzaro> And I agree that GNOME Software should change to warn about that in advance, but that doesn't fix the underlying problem of the unnecessary dependency. I would not call it a valid dependency at all, I'd call it a design failure. But you're right in that, if shelling out to xdvi is what the application does, it certainly has to be specified, or it w
17:08:56 <mcatanzaro> on't work.
17:08:59 <tibbs> We certainly do want to limit dependencies to the extent possible for completely technical reasons.
17:09:55 <tibbs> But to get into subjective things about "good UI" or "it looks better in one of the various software installers" in a technical document like packaging guidelines is really tough.
17:10:02 <limburgher> Right, but aren't unneccessary dependencies already considered BZworthy?
17:11:22 <mcatanzaro> tibbs: It's a guideline on how to package the package, seems like the right place? :)
17:12:34 <tibbs> limburgher: Yes, certainly. So if that needs to be reinforced in a separate place where people might be looking for it, I certainly don't object.
17:12:37 <geppetto> tibbs: So you'd be happy with wording more like "splitting graphical packages into sub-packages to avoid dependencies is generally preferred due to their nature/size?"
17:13:10 <tibbs> Well we already say that in a more general way.
17:13:43 <tibbs> But if we need to point to that to make it more obvious, then I don't see why we wouldn't.
17:14:02 <geppetto> I'm pretty sure that's what mcatanzaro wants.
17:14:28 <tibbs> I'm pretty sure that's part of it, yes.
17:14:44 <tibbs> All I'm saying is that's not the part which was problematic.
17:15:45 <geppetto> Ok, I'm just trying to work out what feedback we can give so they can change their draft and everyone will be happy
17:16:05 <geppetto> Because their intent seems fine, to me
17:16:53 <mcatanzaro> I think what I most want the guideline to convey is: packagers should think hard about the implications of graphical dependencies, and, in particular, graphical dependencies that are unnecessary. I don't want the guideline to ban creating dependencies where necessary, but we also want to really strongly discourage dependencies that don't make sense
17:16:54 <mcatanzaro> . E.g. libraries that install a developer application, like Java control panel, or the old tracker preferences, or libgda database viewer, should definitely be packaged separately.
17:16:55 <tibbs> To me it the intent seems to come down to a judgement call about what makes good UI, and how upstream choices may interact with one of the various software installers we have.
17:18:03 <tibbs> mcatanzaro: Your comments came through exactly the same time as what I was typing, and it seems that if I had a chance to read what you had written, I wouldn't have sent what I just wrote.
17:18:32 <mcatanzaro> tibbs: Your xdvi example was not quite the best example here, because in that case the dependency, while misguided IMO, is unquestionably needed, given the current behavior of the application. But in many cases, the dependency is more clearly unneeded and unreasonable, and we've had trouble in the past convincing packagers that this is bad.
17:19:04 <tibbs> I would really love to see an example of that, if you know of one off the top of your head.
17:19:16 <mcatanzaro> I'd definitely be receptive to suggestions to change the wording and iterate on the feedback.
17:19:36 <tibbs> Having a concrete example would go a long way towards getting some comprehension into my brain parts.
17:19:59 <tibbs> But what you just wrote three minutes ago makes great sense.
17:20:57 <mclasen> one example from the past is those hp printer drivers that would add menuitems for some config tool
17:21:06 <mcatanzaro> tibbs: Java has been problematic in the past. Let me look for the old Bugzilla... something was pulling in OpenJDK control panel and log4j log viewer, and the package maintainer did not want to split them into subpackages because they were packaged together upstream. Actually, I think it was LibreOffice.
17:21:13 <mcatanzaro> Yes, HP printer drivers too
17:22:10 <mcatanzaro> There are more in Arch Linux, which doesn't use subpackages as often as Fedora packagers do. E.g. libgda, GNOME database library, has a database viewer tool that you really don't want to be forced to install just because an application uses the library.
17:22:30 <mcatanzaro> But Arch packages them together; that should be discouraged in Fedora, it's unnecessary
17:22:48 <tibbs> I can't disagree with that.
17:23:00 <mcatanzaro> I don't think that should be controversial. Let's focus on the uncontroversial cases, and then adjust the text of guideline as needed.
17:23:17 <kalev> one thing that hasn't been brought up is app removal
17:23:51 <kalev> let's say that there's two graphical apps depending on each other
17:24:33 <tibbs> I wonder which of these examples aren't already covered by the clause which requires you to split the package for dependencies.
17:24:49 <mcatanzaro> tibbs: Could you point me to that clause?
17:25:05 <kalev> if you uninstall the one at the top of the dep chain, and have automatic unnecessary dep removal turned on that's on by default in dnf, then removing one uninstalls the other one as well
17:25:53 <kalev> and that's very confusing to have another app disappearing suddenly when you uninstall something seemingly unrelated
17:26:09 <kalev> we haven't been able to turn on automatic dep cleanup in in packagekit because of that
17:27:20 <tibbs> mcatanzaro: https://fedoraproject.org/wiki/Packaging:Guidelines#Libraries_and_Applications
17:27:44 <Rathann> hi, sorry for being late
17:27:49 <tibbs> Th last paragraph in that sections requires splitting to elinimate dependencies.
17:28:06 <tibbs> Rathann: We're 87 minutes in at this point.
17:28:41 <Rathann> oh, right, DST in the US
17:28:56 <Rathann> and my calendar reminder is in local time
17:29:13 <tibbs> DST is one of humankind's stupidest inventions.
17:29:17 <Rathann> which has switches to summer time in 1.5weeks
17:29:25 <Rathann> s/has//
17:29:33 <Rathann> agreed
17:29:39 <tibbs> I get the calendar from the Fedora server and it's in UTC.
17:30:27 <mcatanzaro> Fedora's calendar app handles DST wrong, though. I shows meetings at the wrong UTC time. There's a bug report somewhere. Really really bad that a calendar can't get the time right.
17:30:58 <racor> tibbs: You announced 17:00 UTC, 30 mins ago
17:31:29 <geppetto> We really need to close at this point, tibbs is there any wording you want to put in an action or info for this ticket?
17:31:37 <Rathann> I'm +1 to #694 FWIW
17:32:01 <mcatanzaro> tibbs: Perhaps I should work on a proposal to merge some of my proposed text into this existing libraries and applications section? Some of the wording here is a bit unclear. "it SHOULD be packaged as an application", "it is considered a library and MUST be packaged as such", doesn't really hint at the desktop file splitting guidance I'm trying to
17:32:01 <mcatanzaro> get at here.
17:33:17 <tibbs> I think that would be a reasonable thing to do.
17:33:20 <geppetto> #action mcatanzaro to work on merging draft with Packaging:Guidelines#Libraries_and_Applications
17:33:27 <geppetto> Ok, done :)
17:33:31 <limburgher> WFM
17:33:39 <geppetto> #topic Open floor
17:33:42 <tibbs> Getting that section to the point it's in took a lot of effort but I have no illusions that it's complete.
17:33:50 <geppetto> Anything to talk about in 0.1 seconds? ;)
17:34:01 <limburgher> I actuNO_CARRIER
17:34:17 <tibbs> Not from me; I'm super late to something else already but I think this was an important discussion.
17:34:28 * geppetto nods
17:34:29 <x3mboy> .hello2
17:34:30 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
17:34:32 <geppetto> Me too, and me too
17:34:35 <geppetto> #endmeeting