17:00:24 <mmaslano> #startmeeting FESCO (2012-10-03)
17:00:24 <zodbot> Meeting started Wed Oct  3 17:00:24 2012 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:31 <mmaslano> #meetingname fesco
17:00:31 <zodbot> The meeting name has been set to 'fesco'
17:00:37 <mmaslano> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:00:37 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:00:40 <pjones> morning.
17:00:42 * limburgher here
17:00:44 <mmaslano> #topic init process
17:00:45 <nirik> morning everyone.
17:01:00 <mmaslano> hi, t8m and mitr can't attend today
17:01:12 <adamw> i'm around to rep qa for #946 when we hit it, but splitting attention with blocker meeting, so ping me if i'm needed
17:01:22 <mmaslano> adamw: thanks, I'll do
17:01:23 <jwb> hi, i'm here
17:02:21 * jreznik is around for 946, conflict with another meeting... asking anaconda guys to join in
17:02:41 <mmaslano> notting: ?
17:02:43 <mmaslano> mjg59: ?
17:02:53 <mmaslano> well we have 5 people here, so we can start
17:03:58 * notting is here
17:04:01 <notting> sorry about that
17:04:05 <mmaslano> #topic #946 Tracking of new upgrade functionality for F-18
17:04:10 <mmaslano> .fesco 946
17:04:12 <zodbot> mmaslano: #946 (Tracking of new upgrade functionality for F-18) – FESCo - https://fedorahosted.org/fesco/ticket/946
17:04:21 <mmaslano> adamw: ping
17:05:22 <nirik> so code exists... but not sure it's usable state yet. (Last I heard)
17:05:42 <nirik> wwoods: you around for a status update on fedup?
17:05:42 <drago01> wwoods: ^^
17:05:42 <jreznik> for upgrades, yes, there should be some code, at least the cli one
17:05:43 <adamw> yo
17:05:58 <adamw> other qa folks also following.
17:06:03 <jreznik> there's also partitioning part as it's requirement for beta
17:06:41 <notting> partitioning part of ... upgade?
17:06:48 <jreznik> I was able to collect the status from anaconda work list -> pls take a look for an overview what's going to be in anaconda for f18
17:06:49 * Martix is here
17:06:53 <adamw> it looks like anaconda 18.12 ought to cover the partitioning requirements when it hits, from bugzilla (the main bug we're worried about is https://bugzilla.redhat.com/show_bug.cgi?id=855976 )
17:06:54 <jwb> notting, yeah, makes no sense
17:06:54 <pjones> yeah, I don't see how that's related.
17:07:07 <jreznik> notting: no, but it's one of the release criteria for beta - so the same issue as with upgrades
17:07:11 <adamw> partitioning in general, not partitioning of upgrades.
17:07:20 <jlk> this ticket became a pile-on ticket apparently
17:07:31 <notting> ah, ok. two separate new-functionality-for-beta features.
17:08:03 <jreznik> notting: that beta depends on
17:08:09 <jwb> well, the ticket title is "Tracking of new upgrade functionality for F-18) so i'm just going to ignore everythign unrelated to upgrade.
17:08:25 <adamw> right, partitioning and upgrade are the two big areas where current code in the f18 repositories does not cover the beta release requirements.
17:08:41 <mmaslano> imho the question is if we slip or not (again)
17:08:54 <nirik> so, the question here really is: Are we ready for going into freeze for F18Beta, or should we slip a week up front if things aren't in a ready state.
17:09:02 <jreznik> yep - before we freeze to avoid long freezes
17:09:15 <jlk> we'd have a better answer to that after a test compose with .12
17:09:16 <nirik> but it's not really until next tuesday that we need to determine this. Can we just visit it on monday?
17:09:30 <jreznik> nirik: I'd say so
17:09:57 <adamw> +1, as things stand we're not ready, but there is a high chance we may be by 10-08.
17:10:01 <nirik> proposal: special pre-freeze meeting monday next week to visit this.
17:10:08 <jlk> well a test cmpose with .12 and with wwoods' new code
17:10:10 <limburgher> +1 nirik
17:10:14 <pjones> nirik: +1
17:10:14 <mmaslano> nirik: no way
17:10:15 <drago01> do we even have it in the repos yet?
17:10:24 <mmaslano> mmaslano: could we just vote in ticket?
17:10:25 <tflink> drago01: I don't see anything in koji yet
17:10:28 <mmaslano> nirik: ^
17:10:32 <adamw> drago01: afaik all anyone except wwoods has is the git repo.
17:10:36 <jreznik> drago01: the code is in git only now
17:10:46 <drago01> ok
17:10:47 <nirik> mmaslano: we could, but in the past we have had horrible luck doing that.
17:10:53 <mjg59> Hey sorry I'm here
17:11:05 <jlk> so wait, I'm a bit confused
17:11:11 <limburgher> mjg59: we're not.
17:11:12 <jlk> what is fesco voting on?
17:11:16 <drago01> honestly I don't expect that this could go without a slip
17:11:25 <pjones> jlk: not arguing about this right now
17:11:32 <mmaslano> nirik: let's propose what must be done to pass the criteria
17:11:41 <mmaslano> are we speaking about one feature or more?
17:11:46 <jreznik> jlk: when we should decide the slip is needed - we'd like to give you more time before the decision
17:11:46 <nirik> jlk: the idea that if we are not yet ready for beta, going into freeze is a bad idea and we should just slip up front.
17:12:06 <jlk> I see.  ok.
17:12:06 <nirik> to avoid freezing everyone
17:12:12 <adamw> the basis i've been more or less operating on is that we shouldn't freeze until code is present to cover the major beta release requirements.
17:12:15 <pjones> nirik: and furthermore that we should decide that when it's important to decide it, not most of a week beforehand
17:12:27 <adamw> it doesn't have to be _100% working_ - that's what we test in the RCs - but it has to be _present_.
17:12:33 <jlk> yeah, I'd think you want results from a .12 build and test, as well as the blocker meeting that's currently ongoing, to have a better idea of the blocker scene
17:12:33 <tflink> and testable
17:12:55 <nirik> pjones: right.
17:13:05 <jreznik> jlk: yep, so we'd like to do final decision on monday
17:13:36 <jlk> worksforme
17:13:51 <drago01> jlk: .12 ? i.e anaconda?
17:14:00 <mmaslano> do you want to move the regular meeting to Monday?
17:14:02 <drago01> jlk: wheren't we talking about fedup?
17:14:02 <notting> do i think we'll end up slipping? history says 'probably'. that being said, i'd rather make that decision on the date when stuff needs to land by, *unless* the anaconda devs are specifically saying now that they'd need more
17:14:03 <nirik> folks who don't want to meet could vote in ticket?
17:14:05 * drago01 is confused
17:14:08 <jreznik> mmaslano: no, one special
17:14:17 <pjones> no, we're not talking about a regular fesco meeting.
17:14:18 <jreznik> quick one...
17:14:27 <nirik> it shouldn't take long.
17:14:27 <mmaslano> pjones: some are
17:14:28 <adamw> drago01: 18.12 will cover the partitioning requirements.
17:14:31 <adamw> drago01: 18.11 does not.
17:14:35 <pjones> mmaslano: who?  nobody so far.
17:14:38 <limburgher> for one issue.
17:14:39 * jwb sighs
17:14:46 <drago01> adamw: ok so we are still mixing both issues ok
17:14:55 <jwb> then rename the damn ticket
17:15:09 <jwb> or create another one to cover anaconda
17:15:11 <jreznik> jwb: yep, it's now more generic topic
17:15:12 <limburgher> We're arguing about whether or not to argue and about the issue itself.
17:15:37 <pjones> limburgher: if you're trying to say that this is tedious...
17:15:39 <adamw> jwb: will do.
17:15:50 <nirik> proposal: short special meeting monday (2012-10-08) at 17utc (those that cannot attend vote in ticket).
17:16:02 <limburgher> pjones:  Not at all.
17:16:06 <jreznik> nirik: +1
17:16:09 <limburgher> nirik: +1
17:16:12 <mmaslano> +
17:16:14 <pjones> nirik: +1 (still)
17:16:14 <mmaslano> +1
17:16:27 <mjg59> +1
17:16:29 * jreznik can own the meeting if fesco wishes :)
17:16:36 <pjones> sure, that's fine.
17:16:40 <jwb> +1
17:16:52 <mmaslano> #agreed short special meeting monday (2012-10-08) at 17utc about #946 (those that cannot attend vote in ticket).
17:17:21 <mmaslano> who will do the meeting (minutes) from Monday?
17:17:27 <notting> +1
17:17:28 <jreznik> mmaslano: I'll do
17:17:35 <nirik> jreznik: if you want to thats fine with me. ;)
17:17:45 <adamw> jwb: ticket summary changed and comment added.
17:17:49 <jwb> thank you
17:17:55 <jreznik> nirik: as it's more scheduling/pgm stuff, I can help here :)
17:17:56 <mmaslano> #action jreznik will take care about ticket and minutes from Monday meeting
17:18:13 <nirik> cool.
17:18:19 <mmaslano> jreznik: adamw: thanks
17:18:23 <mmaslano> #topic #956 become co-maintainer on gradle
17:18:28 <mmaslano> .fesco 956
17:18:29 <zodbot> mmaslano: An error has occurred and has been logged. Please contact this bot's administrator for more information.
17:18:53 <nirik> so, no answer still here. I'm surely +1 to adding them as co-maintainer, but do we also orphan all the maintainers other packages?
17:19:05 <jwb> yes
17:19:24 <nirik> ok, it will be a pretty vast pile. ;)
17:19:38 <limburgher> Who is it, and what's the ticket number?
17:19:43 <mmaslano> .fesco 956
17:19:44 <zodbot> mmaslano: An error has occurred and has been logged. Please contact this bot's administrator for more information.
17:19:57 <mmaslano> nirik: you are probably admin of bot? :)
17:20:06 <limburgher> 956 isn't there.
17:20:07 <pjones> nirik: hrm.  I'm not so sure what we gain by that?
17:20:19 <nirik> mmaslano: I can look...
17:20:22 <limburgher> 952
17:20:23 <mmaslano> .fesco 952
17:20:24 <zodbot> mmaslano: #952 (become co-maintainer on gradle) – FESCo - https://fedorahosted.org/fesco/ticket/952
17:20:27 <nirik> ah, thats it.
17:20:28 <pjones> nirik: might be better to just say they're "stalled" in the orphan process until somebody comes asking to help with them?
17:20:35 <nirik> pjones: more active people maintaining those packages?
17:20:48 <nirik> all 274 of them
17:20:53 <notting> wheeeeeeeee
17:20:54 <limburgher> Oh jeez. . .
17:20:57 <notting> how many of them have comaintainers?
17:21:09 <limburgher> I'll take some, I've been working with him in the past on many of them. . .
17:21:20 <nirik> not sure off hand.
17:22:16 <limburgher> https://admin.fedoraproject.org/pkgdb/users/packages/lkundrak?acls=owner
17:22:20 <limburgher> It's only really 236.
17:23:08 <nirik> well, I think we do need to revamp our inactive maintainer process...
17:23:11 <limburgher> What do we want to do?
17:23:32 <notting> we've had issues with him being nonresponsive-or-close-to-it in the past, yes?
17:23:36 <limburgher> Deal with gradle now, put out a request for owners for the rest?
17:23:37 <jwb> yes
17:23:37 <limburgher> yes
17:23:52 <mmaslano> sounds fine
17:23:54 <limburgher> I have my eye on a few I need or do most of the work on. . .
17:23:57 <nirik> ok.
17:24:04 <pjones> limburgher: yeah, that's what I'd say
17:24:11 * nirik will try and find time to come up with a proposed better inactive maintainer process.
17:24:16 <jwb> i think pjones is just trying to avoid outright owning grub2
17:24:26 <mmaslano> yeah
17:24:28 <notting> limburgher: +1 to that
17:24:29 <pjones> jwb: heh.  I had forgotten that he was still on that, actually.
17:24:30 <limburgher> jwb: WOuldnt you?
17:24:30 <nirik> ha
17:25:01 <limburgher> Ok, anyone object to my handling the reassignment of gradle, taking a few, and sending the email to -devel?
17:25:14 <mmaslano> limburgher: please, do so
17:25:16 <nirik> no objection here.
17:25:25 <jwb> i guess no
17:25:37 <limburgher> Makes me a bit sad, he's great when he's active.
17:25:50 <nirik> yeah, hope he's ok
17:26:10 <mmaslano> I didn't catch him, but he's probably ok
17:26:11 <notting> limburgher: please do so
17:26:21 <limburgher> Ok.  I'll get to it today.
17:26:30 <pjones> limburgher: you can assign grub2 to me while you're at it, I guess.
17:26:34 <limburgher> nirik:  Me too, isn't he in the Brno RH office?
17:26:50 <mmaslano> limburgher: no, but he works in Brno
17:26:50 <nirik> limburgher: dunno. I think he doesn't work for rh anymore...
17:26:52 <limburgher> pjones:  Will do.
17:26:56 <limburgher> OIC
17:27:25 <pjones> nirik: he hasn't for quite some time
17:27:29 <mmaslano> #agreed limburgher will handle reassignment of gradle. The list of other packages will be sent to -devel
17:28:09 <mmaslano> #topic #950 Cleanup of the default enabled services list
17:28:13 <mmaslano> .fesco 950
17:28:14 <zodbot> mmaslano: #950 (Cleanup of the default enabled services list) – FESCo - https://fedorahosted.org/fesco/ticket/950
17:28:45 <mmaslano> this ticket is old, but nothing happend there
17:29:01 * nirik re-reads it.
17:29:25 <jwb> i'm going to guess he wants more than just a wiki change here
17:29:38 <mmaslano> the presets
17:31:09 <mmaslano> I guess we should define what must maintainer do if he has service
17:31:12 <nirik> so, currently it looks like the list is the way he wants it... which seems kinda not very nice.
17:32:24 <notting> not nice in what way?
17:32:31 <nirik> I guess the two ways forward here are: do each service one at a time and vote, or have folks make proposals and vote on those with amendments.
17:32:47 <nirik> notting: asking fesco to change the list, but then just doing it while waiting to hear back?
17:34:06 <mmaslano> nirik: I would do "each service at a time and vote", then we can hear comments on what we did wrong a fix it
17:35:03 <nirik> ok. I'd prefer a bit of time to review this... I didn't do any prep work on this ticket before the meeting. ;)
17:35:10 <nirik> can we all look and revisit next week?
17:35:16 <limburgher> Ditto, and it could have huge effects.
17:35:21 <notting> next week's pretty busy, but sure
17:35:35 * wwoods lurks
17:36:00 <nirik> perhaps we could all come up with lists and all the ones that are on all the lists just get +1ed... then votes on the rest or something.
17:36:39 <mmaslano> nirik: I did this few years ago, it could take a lot of time, but yes that would be great
17:36:47 <nirik> yeah.
17:36:52 * mmaslano hopes at least someone will prepare list
17:37:12 <jwb> nirik, you want us to prepare a list of services enabled by default?
17:37:25 <notting> the list itself is a little odd now - it lists nfs-utils, which ships ~10 services, some of which might make sense but most of which don't
17:37:38 <nirik> jwb: per the wiki page, yeah: https://fedoraproject.org/wiki/Starting_services_by_default
17:37:51 <nirik> yeah, dropping dbus is fine, IMHO
17:38:06 <nirik> adding syslog-ng is probibly fine since we had the other 2 in there already
17:39:20 <mmaslano> proposal: everyone will try to prepare a list of services, which should be enabled by default
17:39:22 <nirik> a number of other ones in the systemd preset are covered by general clauses and shouldn't be listed
17:40:40 <notting> nirik: shouldn't be listed at all? seems wrong.
17:41:18 <nirik> well, see mitr's comment about libvirtd...
17:41:28 <nirik> or iptables (example of 'one shot')
17:41:57 <notting> i think likely the whole policy needs some rethink
17:42:08 <nirik> could be
17:42:29 <limburgher> probably holdovers from RHL
17:42:30 <notting> but the goal (IMO) should be to get the policy out of the packages, so the packagers don't have to worry about it period
17:42:47 <pjones> notting: yes, absolutely.
17:43:07 <nirik> well, with presets it should be moved out? (although to systemd which I don't know if thats ideal)
17:43:12 <mmaslano> yeah, I would put it on agenda for 17 oct (next week after review of features)
17:43:38 * jwb steps away for a second
17:43:43 <pjones> nirik: moving to one place is a good start.  It'll probably be worth emulating the tzdata split at a later date.
17:44:00 <notting> nirik: we could put it somewhere else; that's just a start. in any case... +1 to discuss at 17 oct meeting
17:44:19 <nirik> yeah, having to update systemd to change it seems excessive... but yeah.
17:44:22 <mmaslano> +1 to my proposal
17:44:30 <nirik> sure, +1... come with proposals or lists. ;)
17:44:31 <limburgher> probably holdovers from RHL+1
17:45:06 <mmaslano> more votes?
17:46:11 <rsc> nirik: if libvirtd is not started by default, the rhn-virtualization-foo packages must be fixed. Their poller.py jells every few minutes, if libvirtd is not running... ;-)
17:46:36 <pjones> meh.  Not really sure everybody doing it is the best use of time.  (Or any more likely to work out than everybody voting in tickets does...)
17:47:08 <mmaslano> pjones: do you have counter proposal?
17:47:10 <pjones> rsc: sounds like it needs to be fixed anyway
17:47:12 <nirik> rsc: sure
17:47:29 <pjones> mmaslano: those that have strong opinions can make a list...
17:47:51 <mmaslano> ok, so I postpone this ticket
17:48:31 <mmaslano> #agreed those who have strong opinions will prepare list of services. The next discussion will be at 17 oct meeting
17:48:44 <mmaslano> new business
17:48:47 <mmaslano> #topic #953 Fedora i386 releases aren't really "i386"
17:48:52 <mmaslano> .fesco 953
17:48:53 <zodbot> mmaslano: #953 (Fedora i386 releases aren't really "i386"... they should be called "i686") – FESCo - https://fedorahosted.org/fesco/ticket/953
17:48:56 <nirik> wheee
17:49:07 <jwb> just no
17:49:23 <pjones> closed->ohnonotagain
17:49:31 <mmaslano> +1
17:49:35 <nirik> i386 confuses people.
17:49:44 <nirik> but then... anything confuses people
17:49:57 <limburgher> #bikshed
17:49:58 <limburgher> e
17:50:02 <notting> wasn't there a ticket about this already?
17:50:07 <pjones> If we change it, we should strongly consider changing it to "don't do 32-bit"
17:50:08 <notting> that's waiting on some releng work?
17:50:15 <nirik> notting: yeah, and thats where we changed it to use i386. ;)
17:50:22 <limburgher> I say keep it until we drop 32-bit, which I'm not advocating.
17:50:31 <nirik> proposal: drop 32bit intel. </joke> :)
17:50:36 <jwb> limburgher, spoil sport
17:50:41 <limburgher> :)
17:50:42 <notting> pjones: 31-bit only!  wait, no, never that.
17:50:53 <pjones> notting: doing it wrong
17:50:54 <limburgher> notting: Splitter!
17:51:33 <nirik> we could change it to x86_32. But that would require changes in at least: rpm, yum, our repos, mash, bodhi, mirror scripts, etc etc.
17:51:45 <mmaslano> um
17:51:47 <mjg59> And be confused with x32
17:51:50 <nirik> yeah
17:51:54 <mjg59> So, no
17:51:54 <mmaslano> I'd rather wait for end of 32b :)
17:52:22 <notting> if you are intentionally trying to run anything we produce these days on hardware that is i386-ish instead of i686-ish, i admire your commitment to retrocomputing, and posit that you already Know Enough To Figure Things Out
17:52:28 <nirik> so, I fear: proposal: close this ticket with: sorry, this is right, sorry if it's confusing, help us improve docs.
17:52:44 <mmaslano> +1
17:53:33 <mjg59> +1
17:53:34 <pjones> notting: atom is retrocomputing?  neat.
17:53:39 <pjones> nirik: +1
17:53:41 <notting> pjones: atom works.
17:53:43 <mjg59> pjones: Atom is i686
17:53:47 <pjones> oh right.
17:54:01 <notting> the lowest supported CPU is original gen OLPC
17:54:06 <pjones> yes.
17:54:12 <notting> which is i586-and-a-half, or something
17:54:20 <mjg59> notting: It's i686 enough to have cmov
17:54:23 <pjones> charitable.
17:54:34 <pjones> yeah, it meets gcc's definition but that's about it.
17:54:38 <mjg59> It just doesn't have one of the other optional features
17:54:47 <notting> nirik: +1
17:54:48 <limburgher> +1
17:55:25 <notting> i am curious as to who is both confused by the i386 naming, and actually has i3/4/586s they're trying to run with it
17:55:35 <mmaslano> #agreed close this ticket with: sorry, this is right, sorry if it's confusing, help us improve docs.
17:55:49 <mmaslano> #topic #954 Need to plan and perform Fedora 18 C++ packages mass rebuild due to gcc fix for CVE-2002-2439
17:55:50 <jwb> notting, i am violently not curious about that at all
17:55:56 <mmaslano> .fesco 954
17:55:58 <zodbot> mmaslano: #954 (Need to plan and perform Fedora 18 C++ packages mass rebuild due to gcc fix for CVE-2002-2439) – FESCo - https://fedorahosted.org/fesco/ticket/954
17:56:22 <mmaslano> I was told the gcc fix is not in F-18
17:56:25 <mmaslano> yet
17:56:30 <notting> jwb: i'd say 'here's a nickel, get a better computer.' but they can scrap gold it themselves and get far more than an nickel
17:56:33 <nirik> so, do we really need a mass rebuild here? whats the ill effect?
17:56:51 * nirik looks again
17:57:08 <jwb> nirik, the original reporter was worried about RHEL7, not fedora.
17:57:12 <limburgher> Seems late for a mass rebuild.
17:57:17 <jwb> i take it we're ignoring that aspect of the ticket
17:57:20 <mjg59> We only need a mass rebuild if we care about this CVE
17:57:34 <mjg59> Which, it should be noted, dates from 2002
17:57:34 <nirik> or ones like it I guess is the implication.
17:57:42 <pjones> jwb: seems like the original reporter can deal with RHEL release engineering instead of fesco then...
17:57:43 <notting> nirik: it 's a bug in handling of the new[] operator, so it ends up in compiled code, not linked in code
17:57:48 <jwb> pjones, indeed.
17:58:06 <mjg59> I think this is arguably a feature rather than a bug
17:58:23 <mjg59> A rebuild would block certain vulnerabilities
17:58:25 <nirik> there were security bugs related to this in 2009/2010/2011 too
17:58:44 <limburgher> Sounds like a good reason to rebuild.
17:58:47 <mjg59> So would we take a mass rebuild to enable some new gcc feature that blocked certain vulnerabilities?
17:58:56 <mjg59> I think at this point, the answer would be no
17:59:15 <mjg59> And the only reason a fesco ticket was filed at all was because the submitter thought that RHEL took Fedora binaries
18:00:07 <notting> i mean, we obviously would take maintainer-done rebuilds; it's a matter of whether we want to do it as a project at this stage
18:00:15 <nirik> right, so I would propose we try and get the gcc with fix in f18, but do no mass rebuild... only rebuild as those packages need to unless a specific vulnerability is found.
18:00:30 <mmaslano> nirik: +1
18:00:33 <pjones> nirik: +1
18:00:44 <mjg59> +1
18:00:51 <nirik> oh, hum.
18:00:52 <jwb> +1
18:01:21 <limburgher> +1 ok.
18:01:40 <nirik> reading the bug, it seems the 'fix' in gcc just spews warnings for this? or is it error...
18:02:18 <notting> nirik: where are you seeing this?
18:02:28 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=850911
18:02:35 <nirik> the actual gcc bug
18:03:10 * nirik wonders how many fedora maintainers ever look at build warnings.
18:03:46 <nirik> I bet it's very low. ;)
18:04:02 * limburgher sheepishly raises one nerdy hand
18:04:46 <nirik> anyhow, I'm still fine with the above...
18:05:56 <mmaslano> #agreed Get the gcc with fix in f18, but do no mass rebuild. Only packages with specific vulnerability should be rebuild.
18:06:25 <mmaslano> #topic Next week's chair
18:06:27 <notting> nirik: i think that's only part of the fix - the warnign is for the cases where it can't check at runtime
18:07:02 <nirik> yeah, it's not clear, but that sounds likely
18:07:30 <nirik> I can do next week if no one else wants to
18:08:04 <mmaslano> #action nirik will chair next meeting
18:08:12 <mmaslano> thanks
18:08:14 <mmaslano> #topic Open Floor
18:10:53 * nirik has nothing
18:11:09 <abadger1999> In today's FPC meeting we briefly discussed a security issue with libiberty
18:11:21 <abadger1999> which was granted an exception to bundle back in the mists of time
18:11:45 <pjones> abadger1999: because that is how it's designed to be use.
18:11:47 <pjones> used
18:11:49 <abadger1999> I'll open a fesco ticket if we're out of time today but the gist of it will be
18:12:14 <abadger1999> someone needs to audit our package set and find all the places that are bundling libiberty
18:12:20 <abadger1999> update the bundled copy
18:12:33 <abadger1999> and also add the Provides: bundled(libiberty)
18:12:43 <abadger1999> so that we can find them more easily next time.
18:12:50 <pjones> maybe we should change the bundling policy so that there's a wiki page that needs to be kept up to date listing which libraries are bundled where.
18:13:02 <pjones> so we don't have to play hunt-the-wumpus every time this happens.
18:13:09 <abadger1999> pjones: that'll just get out of date... Virtual Provides are better.
18:13:18 <pjones> Eh, fair enough.
18:13:46 <abadger1999> It's just that when ajax looked through the package set for the bundled copies, nobody then followed through and actually added the Virtual Provides once they were identified.
18:14:28 <nirik> also, it has no version right? so checking for the bug would have to be mostly manual?
18:14:47 <abadger1999> there's currently two packages with the virtual provides.
18:14:53 <notting> that seems low
18:15:25 <notting> nirik: the version is whatever version they pulled out of the massive gnu source control archive, right? i don't think they have a good versioning to put in the provide
18:15:25 <abadger1999> it's definitely not a reflection of the reality.
18:15:33 <abadger1999> ajax had found 24 in f13 I think
18:15:52 <nirik> right, and I think they specifically say "No, we never put versions on this"
18:16:45 <abadger1999> If we can put even a date of checkout on the virtual provide that would help for the future.
18:17:14 <mmaslano> abadger1999: could you prepare a proposal and create a ticket for it?
18:17:15 <abadger1999> or, you know, just getting the virtual provide would be a help :-)
18:17:53 <abadger1999> mmaslano: I will -- warning though, it's a request for help/fesco to give a cattle call rather than a request with someone lined up to do the work :-(
18:18:13 <mmaslano> abadger1999: sure
18:18:31 <abadger1999> cool.
18:18:49 <abadger1999> I'lll have it ticketed for your next meeting.
18:19:15 <mmaslano> thanks
18:19:20 <mmaslano> anything else?
18:20:10 <mmaslano> I'll close the meeting in 3 minutes!
18:20:57 <limburgher> nothing here
18:21:05 <nirik> thanks for running things mmaslano
18:22:56 <limburgher> Thanks!
18:23:07 <notting> thanks all
18:24:16 <mmaslano> #endmeeting