FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

LinkBack Thread Tools
Old 10-03-2012, 06:25 PM
Marcela Mašláňová
Default Summary/Minutes for today's FESCo meeting (2013-10-02)

#fedora-meeting: FESCO (2012-10-03)

Meeting started by mmaslano at 17:00:24 UTC. The full logs are available

Meeting summary
* init process (mmaslano, 17:00:44)

* #946 Tracking of new upgrade functionality for F-18 (mmaslano,
* AGREED: short special meeting monday (2012-10-08) at 17utc about
#946 (those that cannot attend vote in ticket). (mmaslano,
* ACTION: jreznik will take care about ticket and minutes from Monday
meeting (mmaslano, 17:17:56)

* #956 become co-maintainer on gradle (mmaslano, 17:18:23)

(limburgher, 17:22:16)
* AGREED: limburgher will handle reassignment of gradle. The list of
other packages will be sent to -devel (mmaslano, 17:27:29)

* #950 Cleanup of the default enabled services list (mmaslano,
* AGREED: those who have strong opinions will prepare list of
services. The next discussion will be at 17 oct meeting (mmaslano,

* #953 Fedora i386 releases aren't really "i386" (mmaslano, 17:48:47)
* AGREED: close this ticket with: sorry, this is right, sorry if it's
confusing, help us improve docs. (mmaslano, 17:55:35)

* #954 Need to plan and perform Fedora 18 C++ packages mass rebuild due
to gcc fix for CVE-2002-2439 (mmaslano, 17:55:49)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=850911 (nirik,
* AGREED: Get the gcc with fix in f18, but do no mass rebuild. Only
packages with specific vulnerability should be rebuild. (mmaslano,

* Next week's chair (mmaslano, 18:06:25)
* ACTION: nirik will chair next meeting (mmaslano, 18:08:04)

* Open Floor (mmaslano, 18:08:14)

Meeting ended at 18:24:16 UTC.

Action Items
* jreznik will take care about ticket and minutes from Monday meeting
* nirik will chair next meeting

Action Items, by person
* jreznik
* jreznik will take care about ticket and minutes from Monday meeting
* nirik
* nirik will chair next meeting
* (none)

People Present (lines said)
* mmaslano (76)
* nirik (74)
* limburgher (40)
* pjones (37)
* notting (35)
* jwb (22)
* jreznik (18)
* abadger1999 (17)
* mjg59 (16)
* adamw (14)
* zodbot (11)
* drago01 (8)
* jlk (8)
* tflink (2)
* Martix (1)
* wwoods (1)
* rsc (1)
* mitr (0)
* t8m (0)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

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
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

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

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

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
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>

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,

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

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:

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

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 -

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
17:50:22 <limburgher> I say keep it until we drop 32-bit, which I'm not

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 -

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

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
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

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

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
devel mailing list

Thread Tools

All times are GMT. The time now is 10:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org