16:00:27 <geppetto> #startmeeting fpc
16:00:27 <zodbot> Meeting started Thu Oct  6 16:00:27 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:27 <zodbot> The meeting name has been set to 'fpc'
16:00:28 <geppetto> #meetingname fpc
16:00:28 <geppetto> #topic Roll Call
16:00:28 <zodbot> The meeting name has been set to 'fpc'
16:00:33 <orionp> brb - have to swap a disk and kick off an install...
16:00:44 <geppetto> ok
16:01:15 <geppetto> racor: hey
16:01:17 <moto-timo> .hello ttorling
16:01:17 <mbooth> Hi
16:01:18 <zodbot> moto-timo: ttorling 'None' <TicoTimo@gmail.com>
16:01:21 <tibbs> Howdy.
16:01:27 <geppetto> #chair mbooth
16:01:27 <zodbot> Current chairs: geppetto mbooth
16:01:28 <racor> hi
16:01:30 <geppetto> #chair tibbs
16:01:30 <zodbot> Current chairs: geppetto mbooth tibbs
16:01:31 <mbooth> I'm here, but I only have 1 hour today
16:01:32 <geppetto> #chair racor
16:01:32 <zodbot> Current chairs: geppetto mbooth racor tibbs
16:01:38 * geppetto nods
16:03:25 <Rathann> hi
16:03:35 <geppetto> #chair Rathann
16:03:35 <zodbot> Current chairs: Rathann geppetto mbooth racor tibbs
16:04:32 * limburgher rushes in, sits down
16:04:43 <geppetto> #chair limburgher
16:04:43 <zodbot> Current chairs: Rathann geppetto limburgher mbooth racor tibbs
16:05:44 <geppetto> #chair orionp
16:05:44 <zodbot> Current chairs: Rathann geppetto limburgher mbooth orionp racor tibbs
16:06:30 <geppetto> Ok
16:06:34 <geppetto> #topic Schedule
16:06:37 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/FWTWDBBMVBU75XTDMC5IEI3XJR7FMYBK/
16:06:52 <geppetto> #topic #650  Alternate Python Interpreters
16:06:56 <geppetto> .fpc 650
16:06:58 <zodbot> geppetto: #650 (Suggested Change for Python Guidelines about Alternate Python Interpreters) – fpc - https://fedorahosted.org/fpc/ticket/650
16:07:09 <tibbs> I just added a proposal to that ticket.
16:08:30 <geppetto> I don't mind your proposal, but I'm not sure how we check that
16:09:44 <geppetto> We'd want changes in dnf, in their version of compare providers to downvote packages which have unsupported(*) in their provides, too.
16:10:06 <tibbs> I don't see why.
16:10:20 <tibbs> I mean, we have a rule that says "don't depend on these".
16:10:43 <geppetto> Yeh, but things will depend on the generic things that those packages provide
16:10:48 <tibbs> And then occasionally you run a script that does a big "whatprovides", takes the list of packages, and does a --whatrequires.
16:11:24 <geppetto> So are we saying that these packages won't have any auto provides?
16:11:27 <tibbs> Unless dnf still hasn't managed to get that right, it should be pretty easy to find all of these.
16:11:46 <mbooth> Yeah I don't mind the guideline as proposed in the diff -- i.e. it formalises something that packagers should (not) be doing as a matter of course
16:11:49 <tibbs> I'm not saying that, no, although I guess that could be something else.
16:12:18 <tibbs> My assertion is simply that this has nothing to do with python.
16:12:53 <tibbs> So make it general.  And make it so that we don't keep having to update the python guideline page whenever they decide to put out another of these packages.
16:13:02 <mbooth> Fair
16:13:28 <geppetto> Yeh, I don't mind the proposal ... or your addition, just worry about the implication that this is easy to check.
16:13:34 <tibbs> It might be reasonable to require that such packages not have any autogenerated provides.
16:13:38 <Rathann> meh
16:14:02 <tibbs> Well, change "easy" to "possible".
16:14:18 * geppetto nods
16:14:25 <Rathann> packages of EOL software with known security bugs should not make it into Fedora as new packages
16:14:29 <tibbs> The original proposal didn't give us anything at all which can be checked.
16:14:43 <tibbs> Rathann: I think that's not the business of this committee.
16:14:53 <geppetto> Could maybe be a little more lenient and say that these packages can't provide anything that a supported package does
16:15:14 <Rathann> tibbs: I'll take it to FESCo, then
16:15:33 <tibbs> geppetto: To be fair, though, if nothing will ever depend on these packages, then... maybe they should have no automatic Provides: at all.
16:16:04 <geppetto> Sure, that's fair
16:16:14 <tibbs> Rathann: The question if "what to package" has long been a FESCo thing.  I find it makes this committee easier to handle if we stick to "how to package".
16:16:36 <tibbs> And, yes, it's certainly a valid question.
16:17:03 <tibbs> geppetto: So, what's the easiest way to say "no automatic Provides:"?
16:17:18 <tibbs> Obviously autoreqprov:0 does a bit too much.
16:17:33 <geppetto> I guess something like "These packages should only ever provide their name and unsupported(*)"
16:17:46 <geppetto> tibbs: What else does it do?
16:17:58 <tibbs> Turns off auto Requires: as well.
16:18:02 <geppetto> Oh, you mean the auto requires go too?
16:18:04 * geppetto nods
16:18:13 <tibbs> We do have dependency filters, though.
16:18:17 <geppetto> I thought there was a way to turn one off but not the other
16:18:18 <tibbs> Should actually be easy to use them.
16:18:44 * Rathann finds this whole idea distasteful
16:19:09 <tibbs> Rathann: Try to separate "what to package" from "how to package".
16:19:46 <Rathann> tibbs: I understand, but if we did't have anything like this to package, we wouldn't even be discussing this
16:19:57 <Rathann> hence I'm going to try and stop it at the source
16:20:08 <tibbs> I'm perfectly happy to not think about this again until the "what" question gets back from FESCo.
16:20:19 <tibbs> But I do think these pacakges serve a purpose.
16:20:30 <Rathann> ah, cstratak
16:20:36 <limburgher> agreed.  If "what" != NULL, then "how" is a valid question.
16:20:37 <Rathann> the man who approved python33 into Fedora
16:20:41 <geppetto> Yeh, and I do think it's very likely we'll have a few things like this over the next year or so
16:21:01 <tibbs> And, really, if someone is willing to do the work to package something, I personally don't want to tell them that we don't want their effort.
16:21:03 <geppetto> where like this == other versions of core packages
16:21:10 <cstratak> Rathann, yes?
16:21:12 <tibbs> Well, it's not just "other versions".
16:21:22 <Rathann> geppetto: other still supported versions and I'm with you
16:21:32 <tibbs> It's "packaging old and unsupported versions on purpose".
16:21:33 <Rathann> but NOT other versions which are EOL
16:21:46 <tibbs> It's a service to the people who want to do development and test that their stuff works.
16:22:00 <limburgher> Like, say, linux24-2.4.8.i386.fc24? :_)
16:22:10 <tibbs> But extend the argument and you get "I want to package firefox 12 so web devs can see if their pages work".
16:22:11 <Rathann> or gcc-2.95?
16:22:27 <tibbs> gcc 2.95 has significant value.
16:22:28 <limburgher> 2.96. ;)
16:22:45 <geppetto> Rathann: I'm not sure there's a huge distinction ... some upstreams want to EOL what we've shipped in 24 because they released a new version, and we don't want to move to it if we don't have to
16:22:51 <geppetto> This is kind of the same thing
16:22:57 <tibbs> After all, compat-gcc-34 exists.  And there's a good reason for it, too.
16:23:08 <tibbs> But, aargh, now I'm getting dragged into "what to package".
16:23:15 <Rathann> cstratak: never mind - I'm a bit upset that python33 and python26 exist in current Fedora, but this is not the place to discuss
16:23:18 <tibbs> Proposal: table until fesco gets to talk about it.
16:23:19 <geppetto> If it all works out, everyone is happy ... if it doesn't then users will have to force be migrated to get security updates etc.
16:23:23 <limburgher> +1
16:23:39 <geppetto> tibbs: Sure
16:23:52 <tibbs> Since there's no point in us spending our time worrying about it when it may not happen.
16:23:59 <Rathann> geppetto: ... EOL with known security bugs, how about that?
16:24:24 <tibbs> As long as fesco knows that we have a proposal in the wings for packaging these things "properly" and tracking their use.
16:24:34 <tibbs> Or non-use, specifically.
16:25:05 <tibbs> And, really, I do think we have a bunch of stuff to actually get to today.
16:25:08 <geppetto> #action We'll table this until FESCo has made some decisions on what to package
16:25:20 <geppetto> Rathann: that seems like a terrible idea
16:25:35 <limburgher> We could always hit violators with the fedora-obsolete-all-the-things package.
16:25:43 <geppetto> limburgher: ha
16:25:57 <cstratak> Rathann, how are these packages different than other software packaged in Fedora that is EOL upstream?
16:26:24 <tibbs> I'd hit violators by updating the packages to contain no content at all, honestly.
16:26:26 <geppetto> cstratak: He seems specifically worrid about people packaging old versions of something that have known secury bugs
16:26:44 <Rathann> exactly
16:27:17 <geppetto> So if FESCo can/will ban that, I'm guessing Rathann will be a lot happier
16:27:31 <cstratak> geppetto, yes but my question is still valid. There is a bunch of packaged software in Fedora where upstream is EOL. So how the python interpreters which are documented what their use is, be treated differently?
16:27:52 <Rathann> cstratak: I have nothing against python interpreters in particular
16:27:58 <orionp> And that's a great question for FESCO to answer...
16:28:04 <geppetto> I'd kind of hope that nobody would try, but I don't mind bans there too
16:28:39 <Rathann> it's a general idea which I got just now when we started discussing the alternate python intepreters guidelines
16:29:35 <geppetto> Anyway .... tabling
16:29:37 <geppetto> #topic #651  Guidelines for new Github source format
16:29:40 <geppetto> .fpc 651
16:29:42 <zodbot> geppetto: #651 (Guidelines should suggest downloading source from Github in correct format instead of renaming it) – fpc - https://fedorahosted.org/fpc/ticket/651
16:29:54 <Rathann> cstratak: I was riled by the description: "No security fixes will be applied."
16:30:03 <Rathann> that's... just wrong
16:30:10 <tibbs> So did github change yet again?
16:30:18 <tibbs> I've never actually tried to keep track.
16:30:27 <limburgher> I maintain lots of long-dead stuff but I'm more than willing to apply fixes when they come.
16:30:31 <orionp> well, the propose form works
16:30:35 <moto-timo> Damn you Will Weaton s/Will Weaton/Github/
16:30:39 <geppetto> I'd guess that they either added something to make this possible, or someone worked out how to use their features this way to make what we want easier
16:30:57 <geppetto> I'm happy to +1 it and assume it'll continue to work
16:31:16 <Rathann> yeah, it's definitely better solely on the basis of being shorter
16:31:18 <orionp> me too +1
16:31:19 <tibbs> It's certainly simpler, and I'm a big fan of simpler.
16:31:24 <tibbs> +1 assuming it works.
16:31:45 <geppetto> mbooth: limburgher: Vote?
16:31:53 <limburgher> +1
16:31:55 <mbooth> Sure +1
16:32:02 <tibbs> 505 existing source URLs matching 'github.com.*#'
16:32:29 <geppetto> racor: vote?
16:32:33 <geppetto> I think that'll be everyone
16:32:35 <tibbs> 505 existing source URLs matching 'github.com.*#'
16:32:45 <Rathann> works for me, +1
16:33:09 <tibbs> grep -i 'source.*github.com.*archive.*#' rpm-specs/* says 498; I guess that's more accurate.
16:33:40 <tibbs> I keep thinking about macrotizing this, but it's probably not possible to do anything general.
16:34:24 <geppetto> You'd have to specify the owner
16:34:29 * limburgher Read that as necrotizing.
16:34:37 <moto-timo> lol
16:34:39 <geppetto> limburgher: :)
16:34:55 <geppetto> #action Guidelines for new Github source format (+1:6, 0:0, -1:0)
16:34:56 <racor> 0 ... I just tried on one package (it worked), but without conformation, I do not want to vote
16:35:02 <geppetto> #undo
16:35:02 <zodbot> Removing item from minutes: ACTION by geppetto at 16:34:55 : Guidelines for new Github source format (+1:6, 0:0, -1:0)
16:35:13 <geppetto> #action Guidelines for new Github source format (+1:6, 0:1, -1:0)
16:35:34 <geppetto> #topic #652  Strictify "Tags" and "File Permissions" sections
16:35:37 <cstratak> Rathann, ok that might be misleading as I guess it implies we will not take care of the package (python33 or python26) which is not true. What it means basically is that upstream is EOL, nothing more or less. Again I see no difference between these cases and other dead upstream packages, if any, we took steps to ensure that the packages are used correctly in the context described.
16:35:41 <geppetto> .fpc 652
16:35:42 <zodbot> geppetto: #652 (Strictify "Tags and Sections" and "File Permissions" sections) – fpc - https://fedorahosted.org/fpc/ticket/652
16:36:00 <mbooth> Oh I already voted on this one
16:36:07 <cstratak> Anyway no need to pollute the meeting more about it, it can be discussed elsewhere
16:36:25 <limburgher> I
16:36:28 <limburgher> ',
16:36:31 <limburgher> Stupid CRs
16:36:36 <limburgher> am +1
16:36:43 <tibbs> +1 to my own proposal.
16:36:50 <geppetto> +1
16:38:10 <geppetto> orionp: racor: Rathann: vote?
16:38:19 <racor> +1
16:39:11 <Rathann> +1
16:39:49 <tibbs> mbooth was +1 in the ticket.
16:40:07 <geppetto> #action Strictify "Tags and Sections" and "File Permissions" sections (+1:6, 0:0, -1:0)
16:40:09 <tibbs> of course, mbooth already said that while I wasn't looking.
16:40:11 <geppetto> yeh, he's counted
16:40:20 <geppetto> was waiting for orionp
16:40:23 <geppetto> but it's cool
16:40:33 <geppetto> #topic #653  Explicit approval for inclusion of fedora-rpm-macros
16:40:37 <geppetto> .fpc 653
16:40:38 <zodbot> geppetto: #653 (Explicit approval for inclusion of fedora-rpm-macros) – fpc - https://fedorahosted.org/fpc/ticket/653
16:41:06 <orionp> sorry - working with a user...
16:41:06 <geppetto> +1
16:41:11 <geppetto> orionp: No problem
16:41:57 <Pharaoh_Atem> not an FPC member, but I don't really see a problem with this
16:42:04 <geppetto> tibbs: I assume the experimental thing wouldn't be brought in by default?
16:42:16 <tibbs> geppetto: Oh, hell no.
16:42:19 <geppetto> :)
16:42:40 <Rathann> +1 from me
16:42:42 <geppetto> Just checking ... I mean it might be fine to have it as a suggests too, which then would be there by default
16:42:58 <Pharaoh_Atem> Suggests would be okay, just not Recommends
16:43:03 <tibbs> I just didn't want to let the accusation that we weren't being transparent stand.
16:43:08 <Pharaoh_Atem> mrrgh
16:43:23 <Pharaoh_Atem> this is probably the most transparent process I've had the fortune to work with
16:43:36 <tibbs> I mean, I talked about this as part of doing the gpg stuff, because I really didn't want to draw the ire of someone by poking at redhat-rpm-config too much.
16:43:40 <geppetto> I can never remember which is which ... should have called them weak-requires and info-requires, le sigh
16:43:56 <Pharaoh_Atem> geppetto: there's also Requires(missingok) and a such
16:44:08 <Pharaoh_Atem> but it gets really stupid once you have too many qualifiers
16:44:32 <geppetto> Does Requires(missingok) work?
16:44:36 <limburgher> Requires(butonlyifyoufeellikeit)
16:44:38 <geppetto> Does anything use it?
16:44:49 <limburgher> Suggests(passiveagressively)
16:45:00 <Pharaoh_Atem> geppetto: it's supported in rpm as a compat for rpm5 (who uses it in place of Recommends)
16:45:02 <limburgher> Looks sensible to me.
16:45:25 <tibbs> As I understand it, it's not really _supported_ in RPM.
16:45:43 <tibbs> It's jsut that there's no %missingok section, so Requires(missingok) has no effect.
16:45:45 <geppetto> wow rpm5 compat.
16:46:16 <tibbs> Since a scriptlet dependency for a scriptlet which doesn't exist has no effect.
16:46:22 <geppetto> So, I think we are only at 3 for 653
16:46:24 <Pharaoh_Atem> our xz support was backported from rpm5 as well
16:46:38 <Pharaoh_Atem> err side ported
16:46:44 <Rathann> sorry, have to step away for a while
16:46:49 <geppetto> yeh, I thought the same author did both patches
16:46:51 <Rathann> something urgent came up at home
16:46:53 <geppetto> maybe even you
16:46:57 <tibbs> Rathann: Take care.
16:47:06 <tibbs> And yeah, can we finish the vote on 653?
16:47:13 <limburgher> Rathann: Good thoughts incoming.
16:47:20 <limburgher> +1
16:47:21 <Pharaoh_Atem> geppetto: it was Panu who did it, I think
16:47:28 <Pharaoh_Atem> originally authored by jbj for rpm5
16:47:45 * geppetto nods
16:47:58 <geppetto> mbooth: orionp: racor: Vote on 653?
16:47:59 <Pharaoh_Atem> that's why the rpmlib() dependency mentions v5.2
16:48:06 <Pharaoh_Atem> because that's when it was introduced in rpm5
16:48:25 <orionp> I'm +1
16:49:33 <racor> I'm not comfortable with having a "fedora-rpm-macros" package at all
16:49:43 * moto-timo wonders if rpm5 and rpm4 will ever reconverge
16:49:50 <Pharaoh_Atem> one can only hope
16:50:02 <tibbs> racor: OK, why?
16:50:26 <geppetto> racor: are you comfortable with redhat-rpm-config?
16:50:45 <tibbs> I gave a pretty good list of reasons why it makes work easier for me (i.e the person doing the work on this at the moment).
16:51:05 <racor> IMHO, there should be only one such package "redhat-rpm-config" or "fedora-rpm-config".
16:51:07 <tibbs> So it would be nice to have a refutation of that if you think I'm wrong.
16:51:29 <tibbs> OK, so, what about the other *rpm-macros packages?
16:51:32 <geppetto> racor: We already have a bunch of macro packages that redhat-rpm-config depends on
16:51:35 <limburgher> I thought tibbs' rationale for the split was rational.
16:51:55 <tibbs> And the fact that redhat-rpm-config itself spits out one *rpm-macros subpackage.
16:51:56 <geppetto> racor: Do you just not like the name? Maybe fedora-fpc-macros?
16:52:09 <tibbs> "fpc" is overloaded in this context, sadly.
16:52:13 <racor> i do not say you're wrong. I only think this is confusing.
16:52:28 <tibbs> I wish that the existing redhat-rpm-macros wasn't confusing.
16:52:42 <geppetto> +1
16:52:43 * moto-timo nods
16:52:51 <Pharaoh_Atem> the big issue with redhat-rpm-macros is that it's not managed like other upstream/downstream things
16:52:58 <racor> tibbs: You don't want to know my real opinion on  redhat-rpm-macros ;)
16:52:58 <tibbs> And I do agree that it's not the best situation.
16:53:19 <mbooth> Personally I would like to like to see the big reason for this "Complexity of maintenance of redhat-rpm-config" disappear over time, such that fedora-rpm-macros and redhat-rpm-macros could eventually be merged... Do you think this is a thing that will happen?
16:53:21 <tibbs> It's relatively easy to move things back and forth, as long as I keep things organizationally clean.
16:53:33 <Pharaoh_Atem> I like how rpm-mageia-setup is done, but we don't do it that way for redhat-rpm-config for some reason
16:53:56 <tibbs> mbooth: I think we can move towards that.
16:54:01 <mbooth> Bear in mind, I never looked in redhat-rpm-macros before now...
16:54:15 <tibbs> But a lot of stuff in redhat-rpm-macros is basically "black magic" coupled with "history".
16:54:40 <tibbs> I think if you've seen any of the rpm macro work I've done, you'll see how I try to be overly generous with the documentation.
16:55:02 <geppetto> black magic covers pretty much everything to do with rpm macros
16:55:27 <tibbs> I can't disagree, but at least my black magic has comments.
16:55:38 <geppetto> yeh
16:55:41 <tibbs> Note that I will make changes to redhat-rpm-config when necessary.
16:55:45 <moto-timo> or macros in general lol
16:55:46 * geppetto nods
16:55:56 <tibbs> I have no intention of having fedora-rpm-macros override anything in redhat-rpm-config.
16:56:08 <tibbs> Even though redhat-rpm-config overrides things in rpm.
16:56:59 <tibbs> I also have no intention of making life difficult for Red Hat, so if they want something moved into "their" package, it's trivial to do so.
16:57:08 * geppetto nods
16:57:29 <geppetto> mbooth: racor: Just you two left to vote
16:58:51 <racor> 0
17:00:13 <geppetto> #action  Explicit approval for inclusion of fedora-rpm-macros (+1:5, 0:1, -1:0)
17:00:20 <mbooth> I think I am ±0 too.
17:00:22 <mbooth> Sorry
17:00:27 <mbooth> I kept re-typing
17:00:28 <geppetto> #undo
17:00:29 <zodbot> Removing item from minutes: ACTION by geppetto at 17:00:13 : Explicit approval for inclusion of fedora-rpm-macros (+1:5, 0:1, -1:0)
17:00:32 <geppetto> #action  Explicit approval for inclusion of fedora-rpm-macros (+1:5, 0:2, -1:0)
17:00:37 <tibbs> Interesting.
17:00:55 <geppetto> #topic #654  glibc file triggers
17:01:00 <geppetto> .fpc 654
17:01:05 <zodbot> geppetto: #654 (glibc file triggers) – fpc - https://fedorahosted.org/fpc/ticket/654
17:01:14 <geppetto> As I said in the comment, I'm pretty sure you can just do this as a transaction level thing
17:01:18 <tibbs> mbooth: After we're done I'd honestly like to hear your opinion on that.
17:01:31 <tibbs> I don't think there's much for us to _do_ here.
17:01:41 <tibbs> I just wanted to make everyone aware of it.
17:01:56 <mbooth> tibbs: I'm afraid I have run out of time and have to leave -- but sure, I will get back to you about it :-)
17:02:07 <Pharaoh_Atem> tibbs: and this is why I'm here today :)
17:02:11 <tibbs> We can all celebrate that texlive list 110K lines by implementing triggers.
17:02:15 <Pharaoh_Atem> :D
17:02:21 <geppetto> :)
17:02:23 <Pharaoh_Atem> might be something for us to pull into Mageia, too
17:02:25 <tibbs> But glibc, well, I filed the ticket because someone needed to.
17:02:47 <limburgher> tibbs: <highfive>
17:02:47 <tibbs> And I'm really not the best person to be mounting any kind of defense of file triggers.
17:03:07 <tibbs> From my end, I just want packagers to not have to care about those scriptlets.
17:03:16 * geppetto nods
17:03:17 <tibbs> But if it's this enormous pain in the rear, then I don't know.
17:03:31 <Pharaoh_Atem> speaking from experience in Mageia, I can tell you a bit about why we do the triggers the way we do
17:04:05 <tibbs> Pharaoh_Atem: I'm not entirely sure the meeting is the best venue for that, though don't let me stop you.
17:04:20 <Pharaoh_Atem> well, whenever you want it, I can tell you
17:04:43 <tibbs> The bugzilla ticket against glibc really needs to get that info regardless.
17:05:16 <tibbs> I do get the feeling that the glibc maintainers would rather not do this.
17:06:51 <Pharaoh_Atem> that's really strange
17:06:55 <geppetto> interesting
17:07:07 <Pharaoh_Atem> as it's been extremely useful in Mageia and OpenMandriva
17:07:28 <tibbs> To be fair, I see it saving exactly two lines of specfile line noise in specs which include libraries.
17:07:29 <Pharaoh_Atem> hell, I think it was one of the reasons why file triggers was invented by Mandriva
17:07:48 <tibbs> It's also the example specifically given in RPM's documentation on file triggers.
17:07:59 <tibbs> But I've received various arguments against:
17:08:21 <tibbs> Performance issues with calling ldconfig unnecessarily (if using %filetriggerin/postun).
17:08:55 <tibbs> Performance issues with calling grep to avoid calling ldconfig unnecessarily.  (Can't win.)
17:09:20 <tibbs> Big packaging changes needed to call ldconfig at the end of the transaction (via %transfiletriggerin/postun).
17:09:37 <Pharaoh_Atem> that... seems weird
17:09:57 <tibbs> Well, I'm actually not sure how "big" that is, but it sounds like it's more than the two lines that you'd save by dropping the scriptlets.
17:10:23 <geppetto> as I said, I'm 95% sure no changes are needed for transaction filetrigger usage
17:10:39 <tibbs> I also got the feeling that at least some of glibc developers were not aware that this facility existed, or that other distros were indeed using it.
17:11:02 <Pharaoh_Atem> whenever we've ported over packages from Fedora, it's been routine to just delete the ldconfig calls and everything is fine
17:11:05 <tibbs> But anyway, I don't think anyone here intends to _force_ anything on the glibc maintainers.
17:11:08 <geppetto> yeh, I wouldn't be shocked by that
17:11:29 <tibbs> But it would be good to have a refutation of there assertions that packaging changes are needed to avoid breakage.
17:11:37 <tibbs> "their", sorry.
17:11:48 <Pharaoh_Atem> to date, I haven't encountered a package that breaks in such a way
17:11:49 <tibbs> And I don't know how to do that.
17:12:32 <tibbs> This may be a case where you could theoretically construct such a package, and therefore some would say that we can never make the change.
17:12:34 <limburgher> tibbs: Thank you. :)
17:12:55 <Pharaoh_Atem> tibbs: I think that's the case
17:14:03 <tibbs> Anyway, really I'd just appreciate it if people who know what they're saying could contribute usefully to that buzgilla ticket so I can stop talking out of my ass.
17:14:14 <tibbs> https://bugzilla.redhat.com/show_bug.cgi?id=1380878
17:14:40 * geppetto nods
17:14:49 <geppetto> #action Need to convince glibc devs.
17:15:04 <geppetto> #topic Open Floor
17:15:33 <Pharaoh_Atem> tibbs: did you get a chance to take a look at the version draft?
17:15:37 <tibbs> I fear that any progress is going to get lost in confusion about the difference between %filetriggerin and %transfiletriggerin, and in mostly meaningless discussion about performance.
17:16:01 <Pharaoh_Atem> :/
17:16:03 <tibbs> Pharaoh_Atem: Well, I looked at it.  But I haven't had time yet to clean up the current versioning guidelines in the way we talked about last week.
17:16:33 <tibbs> I will probably try to revise them in parallel.
17:17:42 <tibbs> Sorry for clogging up everyone with tickets this week.
17:18:01 <tibbs> Every time I do one thing I run into three other things that also need doing.
17:18:16 * geppetto nods ... n/p
17:18:49 <tibbs> I have a separate list for fpc stuff now so hopefully I won't keep losing things.
17:19:53 <limburgher> Nature of the beast,
17:20:55 <tibbs> Of a packaging-related note, someone asked if we could start passing --disable-silent-rules as part of the %configure macro in order to increase the default build verbosity for some packages.
17:21:12 <geppetto> huh
17:21:45 <tibbs> After probably annoying Panu, he told me that we actually used to do this back in 2011, but after a few months it was backed out.
17:21:56 <tibbs> Because it broke... something.
17:22:03 <geppetto> :)
17:22:10 <Pharaoh_Atem> non autotools-based configure scripts don't handle it well
17:22:27 <tibbs> non autotools-based configure scripts should never be called using %configure.
17:22:51 <tibbs> Or, if that just so happens to work by pure luck, you certainly can't depend on it working forever.
17:23:03 <tibbs> But in any case, I added it back in, conditionally.
17:23:22 <tibbs> If %_configure_disable_silent_rules is defined, then --disable-silent-rules will be passed.
17:23:33 <geppetto> ok
17:23:36 <tibbs> That's not currently defined, but at some point we could flip it on.
17:23:45 <tibbs> And packages which break could flip it back off.
17:23:47 <racor> tibbs: No. It's just that --disable-silent-rules is not supported by ancient autoconf-based scripts
17:24:30 <tibbs> Yes, it's unsupported by "old" autoconf scripts which don't also ignore unknown arguments.
17:24:31 <racor> tibbs: I do not see any sense in  %_configure_disable_silent_rules.
17:24:44 <tibbs> I don't know how old "old" actually is.
17:25:01 <tibbs> And I don't have any idea of what would actually break.
17:25:05 <racor> IIRC, ... > 10 years
17:25:31 <tibbs> But anyway, it's all in rawhide already.
17:25:51 <tibbs> Obviously currently there is zero functional change.
17:25:53 <racor> tibbs: <sigh> ... another non-transparent change.
17:26:34 <geppetto> .... that does nothing
17:26:39 * geppetto shrugs
17:26:39 <tibbs> Next time I change a comment somewhere, I'm sure someome will tell me I'm not being transparent.
17:26:47 <racor> to put that straight: I consider  %_configure_disable_silent_rules to be non-helpful featuritis.
17:26:56 <tibbs> Glad to hear it.
17:27:11 <geppetto> I don't even remember what it does
17:27:22 <tibbs> It increases the build verbosity.
17:27:43 <tibbs> Anyway, the foundation is there for someone to have the discussion about it if that's what someone wants to do.
17:27:55 <racor> geppetto: I haven't heard about  %_configure_disable_silent_rules until 5 minutes ago
17:27:57 <tibbs> And to enable easy testing for breakage.
17:28:24 <racor> Anyway, folks, I need to quit now ;)
17:28:50 <tibbs> Maybe I just should have left it there and pretended it was there all along.
17:29:31 <tibbs> Just not said anything for a year and then said, Oh, by the way, this thing exists, perhaps we should consider using it.
17:29:48 <tibbs> But at this point I'm convinced that ever changing or adding anything is featuritis to someone.
17:30:12 <limburgher> GUIs, for example.
17:30:21 <tibbs> I just saw it as laying the foundation to actually having a discussion.  It should have been made conditional when it was originally added.
17:30:33 <tibbs> Then it wouldn't have needed to be backed out.
17:31:22 <geppetto> yeh/me nods
17:31:49 <tibbs> Anyway, sometimes you just have to make a one liner zero functionality change and then take the heat.
17:32:04 <geppetto> haha
17:32:15 <tibbs> I will eventually do a mass rebuild with it on and see what breaks.
17:32:35 <geppetto> ᕕ( ᐛ )ᕗ
17:32:50 <tibbs> If for no other reason than it helps us figure out which packages have really ancient and probably fragile configure scripts.
17:32:59 <tibbs> And then we can go from there.
17:33:18 <tibbs> And I guess I have one more thing to throw out there.
17:34:26 <tibbs> I'm wondering if anyone else sees it as problematic that we'd work through anything as big as the version/release change proposal without having the whole committee involved.
17:35:49 <geppetto> What do you mean?
17:36:19 <limburgher> tibbs: What proportion participated?
17:36:41 <geppetto> I think we had 7 for at least one of them
17:36:54 <tibbs> Well, basically, I was thinking about drumming up comments by sending some emails, but then I don't want that to be seen as trying to drum up support for something that I'd like to see passed.
17:37:27 <geppetto> I think it's fine, we've lready spent at least 3 hours discussing it in meetings
17:37:32 <tibbs> Frankly I would like to know Thomas and Xavier's opinions on the while thing.
17:37:37 <geppetto> If we can do some stuff async via. email that's fine
17:37:42 <limburgher> I think that would be warranted; it doesn't imply endorsement, just significance.
17:38:00 <limburgher> I think everyone should have at least a sliver of opinion on it.
17:38:08 <tibbs> Yeah, basically I think it's one of the more significant changes (by magnitude) we've considered in quite some time.
17:38:16 <limburgher> For sure.
17:38:37 <tibbs> But we need five votes for anything to pass regardless of who comments, so in the end it doesn't make much difference.
17:38:43 <limburgher> By analogy, it's a bill that should be on CNN as well as just C-SPAN.
17:39:11 <moto-timo> lol
17:39:37 <limburgher> But I agree that we should take Thomas and Xavier's temperatures on this, it's a big deal.
17:39:47 <tibbs> Still, I don't think it's going to pass and so I'm not sure it's worth spending too much more time on it.
17:40:29 <orionp> I tried it out of a test package locally - one annoyance was needing to muck with %{version} elsewhere in the spec
17:41:17 <tibbs> Might want to toss a diff into trac.
17:41:22 <limburgher> orionp: That has the potential to get super ugly.  Many specs use it with the assumption that the format won't change, or won't change much.
17:42:11 <orionp> it leads to needing to define something like %ver that has just the base version
17:42:11 <tibbs> We do need a list of negatives in the ticket.  I keep meaning to add one but all I really came up with is the large number of packages it touches.
17:42:34 <Rathann> ok I'm back
17:42:40 * Rathann scans the backlog
17:42:43 <tibbs> Hope all is OK.
17:42:53 <limburgher> THIS^
17:42:56 <Rathann> yeah, all is fine
17:43:01 <Rathann> thanks :)
17:43:01 <limburgher> Good.
17:43:11 <tibbs> Rathann: You didn't miss any votes.
17:43:28 <limburgher> orionp: And that's sort of gross.
17:44:38 <tibbs> I'm not able to visualize how you'd need to adapt to the changed %version format.  You mean in terms of tarball names and such?
17:45:23 <tibbs> I guess anything that does a checkout and relates %version and the name of the tarball would have to redo all of that.
17:45:54 <limburgher> Or setup -qn %{version}-%{release} might break.
17:45:55 <tibbs> I kind of wish we had better tools for actually doing the git checkouts and tarball creation.  There shouldn't be any need for a packager to do that manually.
17:46:21 <limburgher> I wrote my own tool for that. . .
17:46:31 <tibbs> Right, though that's just basically changing the already arbitrary name chosen for the directory.
17:46:40 <tibbs> Which is certainly nonzero work and must be considered.
17:46:44 <limburgher> For sure.
17:47:09 <tibbs> Really fedpkg should have a way to just do that for you.
17:47:26 <moto-timo> +1
17:47:27 <tibbs> If only Red Hat would just employ me to do all of this packaging work.
17:47:34 <tibbs> Sadly fedpkg is a mess.
17:47:37 <limburgher> I agree.  Sometimes I use my tool for my own releases, since it doesn't do the clone.
17:48:08 <tibbs> Because it's really an interface to a library that can't easily be changed because internal Red Hat process relies upon it.
17:48:17 <tibbs> As far as I've been able to tell, at least.
17:48:39 <geppetto> I think it should be fine to add new commands
17:49:05 <geppetto> Or even get the old commands to do it, if there is a specific config. enabled ... but that might be harder
17:49:17 <tibbs> I honestly haven't looked into it because I was warned off of trying to do so at Flock in Rochester.
17:49:23 <geppetto> ahh
17:49:33 <limburgher> Is there something to get new upstreams, like if the current is 1.2 and the new is 1.3 where you run fedpkg getstuff 1.3 and it gets the new tarballs?
17:49:38 <orionp> here's an example - http://paste.fedoraproject.org/445070/57761601/
17:49:58 <limburgher> Ick.
17:50:22 <orionp> mainly because there is work translating 0.10a1 -> 0.10~a1 and back
17:50:33 <tibbs> Obviously there's a few unrelated changes in there.
17:50:58 <tibbs> But I think I see the interesting point.
17:51:12 * limburgher needs some air
17:51:36 <tibbs> A prerelease tarball for, say, 1.0, s probably going to unpack into a "foo-1.0" directory, not a "foo-1.0~pre1" directory.
17:51:57 <tibbs> In fact, we can pretty much assume that it will _never_ unpack into a directory named with a tilde.
17:52:07 <tibbs> So there's always going to be some work there.
17:52:24 <tibbs> I'll note that in the "negative" column.
17:52:38 <limburgher> Note that "some" might be yuge.
17:52:47 <tibbs> However, a couple of convenience macros could hide some of the pain.
17:53:14 <tibbs> One to strip just the tilde, one to strip the tilde and everything after.
17:53:23 <limburgher> Convenience macros:  The first one's free. ;)
17:53:48 <geppetto> ha
17:54:17 <tibbs> Oh, hell, I'll give you as many as you want.
17:54:41 <tibbs> I'm not trying to get you hooked, I'm trying to get you into the van.
17:54:44 * limburgher ties rubber strap around text editor
17:55:01 <moto-timo> is the van down by the river?
17:55:14 <tibbs> Yeah, that one went off the rails pretty quickly.
17:55:22 <moto-timo> :)
17:55:28 <limburgher> I just assumed you were the friendly stranger in the black sedan.
17:55:34 <tibbs> Anyway, that's pretty much two hours.
17:55:43 <moto-timo> with candy
17:56:08 * geppetto nods
17:56:46 <limburgher> Ides of March FTW
17:58:20 <limburgher> We should wrap this up before it gets all Tom Jones or Milk and Sugar.
17:58:31 <moto-timo> too late
17:59:18 <geppetto> ok, thanks for coming ... and scaring any children :-o
17:59:29 <limburgher> :)
17:59:30 <geppetto> #endmeeting