17:01:31 <limburgher> #startmeeting FESCO (2012-06-11)
17:01:31 <zodbot> Meeting started Mon Jun 11 17:01:31 2012 UTC.  The chair is limburgher. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:31 <limburgher> #meetingname fesco
17:01:31 <limburgher> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:01:31 <limburgher> #topic init process
17:01:31 <zodbot> The meeting name has been set to 'fesco'
17:01:31 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:01:39 * jwb is here
17:01:42 <nirik> morning.
17:01:42 * limburgher here
17:01:44 <pjones> hello.
17:01:46 <mmaslano> hi
17:02:30 <t8m> hello
17:02:45 * notting is here
17:02:58 <limburgher> mitr, mjg59?
17:03:56 <pjones> mjg59 is traveling this week, I wouldn't expect him.
17:04:08 <limburgher> Ok, and I don't see mitr, so on with the show.
17:04:11 <limburgher> #topic #857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience
17:04:15 <limburgher> fesco .857
17:04:26 <limburgher> .fesco 857
17:04:28 <zodbot> limburgher: #857 (F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience) – FESCo - https://fedorahosted.org/fesco/ticket/857
17:04:58 <limburgher> Any thoughts?
17:05:22 * mclasen tried to answer some more questions on the talk page, and did some more edits
17:05:44 <nirik> mclasen: did you see the ones on the ticket/mailing list?
17:05:52 <nirik> (although some overlaped with already answered things)
17:06:15 <pjones> Seems like the question about discussing it with the firstboot maintainers wasn't ever answered.
17:06:47 <nirik> mclasen: this would only be installed/set to run on the desktop live media right?
17:07:00 <notting> i distinctly recall sitting in meetings where this was discussed with anaconda/firstboot maintainers
17:07:13 <mclasen> Oh, we have been discussing it with dcantrell, and jasper is currently working with the firstboot maintainers to figure out how to embed 'legacy' firstboot screens that we still need
17:07:15 <jwb> which means firstboot would still exist for non-desktop spins and the install DVD?
17:07:21 <pjones> notting: okay.  But on the talk page the question is asked and not answered.
17:07:28 <pjones> mclasen: alright
17:07:30 <nirik> jwb: yep. thats my understanding
17:07:50 <mclasen> I may have overlooked it - talk pages tend to get somewhat confusing after a  bit of back-and-forth...
17:08:24 <pjones> yeah, totally.
17:08:25 <t8m> basically this is my biggest concern - to ensure that firstboot is not dropped/left unmaintained without adequate replacement for other spins and install DVD
17:08:33 <limburgher> It seems like for Desktop firstboot just wouldn't be used, and the same could be done if this was ever replicated for KDE, XFCE, etc.
17:09:13 <limburgher> t8m:  It looks like that will be the case: "Optionally, show legacy firstboot screens "
17:09:21 <mmaslano> do you mean having different firstboot for every DE?
17:09:33 <jwb> mmaslano, no.  just a different one for the desktop spin
17:09:40 <jwb> sounds like the rest just use firstboot
17:09:50 <t8m> limburgher, some screens maybe, but will the rest of firstboot still be maintained
17:09:50 <limburgher> jwb: That's my take as well.
17:09:50 <notting> ... unless they want to use something else
17:10:04 <limburgher> t8m:  That's what we need answered.
17:10:11 <nirik> anyhow, I'm ok with it generally. I think we should try and provide as much feedback as we can during the cycle, but the general idea seems ok to me.
17:10:11 <mmaslano> would it be firstboot still maintained? and how does it work for anaconda team?
17:10:23 <notting> that's up to the firstboot maintainers, isn't it?
17:10:36 <mclasen> I can't really speak for the firstboot maintainers - I believe the anaconda team would love to not maintain it anymore
17:10:49 <t8m> mclasen, how is the system vs. user specific setup handled?
17:11:19 <mclasen> the design is intentionally blurring that line
17:11:53 <jwb> i'm mostly OK with this as well under the premise that firstboot still exists and is used for non-desktop live spins and the install DVD
17:12:00 <mclasen> based on the assumption that most desktop installations are single-user
17:12:13 <pjones> yeah, I don't think we (anaconda team) are going to mind firstboot getting replaced by something we don't own.
17:12:26 * nirik is with jwb
17:12:30 <jwb> pjones, except it sounds like it's not really being replaced
17:12:31 <limburgher> If it makes things easier for most users, and allows the rest of us to tweak as before, I think it's probably a goo step.
17:12:37 <pjones> jwb: a boy can dream
17:12:46 <t8m> pjones, but it is now clear that this is not a replacement
17:12:54 <jwb> pjones, that's kinda the crux of the issue though
17:12:58 <pjones> well, it's a replacement for /part/ of it.
17:12:58 <jwb> or concern anyway
17:12:58 * limburgher orders pjones a unicorn
17:13:30 <limburgher> I sounds like if the idea takes hold it or equivalents for other DEs could do so eventually.
17:14:05 <limburgher> Do we want to vote now, or await a firmer answer on the firstboot replacement question?
17:14:05 <mclasen> jwb: is it ? I mean, we're shipping 4 complete desktops, why is a bit of duplication in this tool a big deal ?
17:14:18 <mmaslano> pjones: so, anaconda team doesn't have a plan with firstboot and it would be on DE's SIGs?
17:14:25 <limburgher> mclasen: Esp. if they need to be different for each anyway.
17:14:36 <mclasen> I have to run out now unfortunately, but I'm happy to come back again next week
17:14:36 <jwb> mclasen, i'm fine with duplication.  i'm _not_ fine with the desktop spin using this, and firstboot falling on the floor and screwing over the rest of the distro
17:14:53 <mclasen> I think I'll have initial packages by then, so things may be a little clearer
17:14:59 <jwb> i mean, the install DVD is still fairly important
17:15:06 <jwb> and it's not going to use this feature
17:15:10 <jwb> so...
17:15:10 <pjones> mmaslano: I don't know the plan, that doesn't mean there's not one
17:15:29 <mmaslano> thanks
17:15:48 <jwb> should we postpone this until we can get clarification on what is happening with firstboot ?
17:15:50 * nirik is fine with voting now or revisiting next
17:16:10 * limburgher good either way
17:16:14 <notting> i think what is happening with firstboot is orthoganal to this, not required
17:16:14 <mclasen> jwb: I have to admit to have very little exerience with the install dvd - who is designing that experience ?
17:16:36 <pjones> notting: yeah, looks like that to me as well
17:16:40 <jwb> notting, mm... i think the communication part is important
17:16:54 <drago01> jwb: given that the people working on this feature aren't the same as those that work on firstboot ... it shouldn't have much of an effect right?
17:17:13 <t8m> jwb, +1 to postpone to get clarification
17:17:20 * mclasen has to run, sorry - back next week, I'll communicate in the meantime
17:17:56 <jwb> if someone could tell me 'yes, firstboot is going to be around and maintained for f18' i'd be totally fine with it.  but nobody seems to know if that's the case, or those that do know haven't said as much
17:18:14 <limburgher> Let's postpone, then.
17:18:19 <notting> afaik, it will be around
17:18:20 * nirik is pretty sure thats the case, but it can't hurt to make sure.
17:18:26 <notting> no one is removing the package, at least
17:18:52 * jwb writes down 'assign firstboot to notting when it's orphaned'
17:18:54 <jwb> ;)
17:19:13 <jwb> anyway, i'm fine with voting and revisiting if something else comes to light
17:19:16 <limburgher> #action postpone vote until firstboot plan is clarified
17:19:32 <limburgher> #topic #861 Cleanup of maintainers with bugzilla account issues
17:19:37 <limburgher> .fesco 861
17:19:39 <zodbot> limburgher: #861 (Cleanup of maintainers with bugzilla account issues) – FESCo - https://fedorahosted.org/fesco/ticket/861
17:20:00 <nirik> ok, this is something I added. ;)
17:20:08 <limburgher> nirik, do you have a list of what would get orphaned?
17:20:11 <nirik> we have some maintainers with no matching bugzilla accounts.
17:20:32 <notting> you mailed on 06-04? I'd give them another week, at least
17:20:33 <limburgher> Maybe their packages are bug-proof. :)
17:20:35 <nirik> not off hand, but I can generate one.
17:20:43 <jwb> i'm slightly concerned about the second case
17:20:53 <nirik> I'm happy to give more time...
17:20:53 <limburgher> That would be great for the ticket, maybe by user.
17:21:03 <limburgher> I like another week, too.
17:21:06 <jwb> mostly because i did that a while ago, and it got fixed up somehow but i don't recall exactly what abadger1999 did
17:21:15 <t8m> notting, +1
17:21:23 <mmaslano> another week sounds fine
17:21:24 <limburgher> Though I'm surprised that this is an issue after we did the pruning with ssh keys, etc.
17:21:32 <nirik> This started with about 190 issues.
17:21:43 <jwb> ssh keys have nothing to do with bugzilla
17:22:02 <nirik> it's down to 110 now.
17:22:04 <limburgher> right, but people had to touch their FAS accounts.
17:22:26 <nirik> the common case here is someone changing their fas email, but forgetting to change bugzilla.
17:22:34 <drago01> touching FAs account does not imply creating a bugzilla account
17:23:07 <jwb> there's no 'bugzilla account' field in FAS either
17:23:16 <jwb> there's just an assumption that fas email == bugzilla email
17:23:25 <limburgher> True.  Maybe it's just neurotic individuals such as myself who took the opportunity to check everything. :)
17:23:28 <t8m> basically this is a failure of our tools - the FAS and BZ should be automatically interconnected so they cannot get unsynced
17:23:33 <nirik> anyhow, if you like I can note the packages affected in the ticket and actions to be taken next monday and also spam everyone again today.
17:23:38 <jwb> t8m, that would be horrible.
17:23:51 <jwb> nirik, would be nice, yes
17:23:53 <limburgher> nirik:  Perfect.
17:24:13 <limburgher> #agree nirik will re-contact users, and we will address this after giving them one more week.
17:24:17 <pjones> t8m: that wouldn't work well for group-maintained packages or people who want a foo+bugzilla@example.com type emails
17:24:17 <jwb> nirik, we should talk to abadger1999 again and see how he fixed it for a few of us that have distinct emails.  i know there was some conversation on that a while ago
17:24:18 <t8m> jwb, why?
17:24:31 <limburgher> #action nirik will re-contact users, and we will address this after giving them one more week.
17:24:32 <nirik> jwb: is your fas email your @fedoraproject.org address?
17:24:37 <nirik> thats the special case.
17:24:43 <jwb> nirik, nope
17:24:53 <nirik> huh, then not sure what the other case would be.
17:24:56 <limburgher> #topic #862 Review F17 runtime linker location on armhf
17:25:12 <jwb> nirik, my fas account is a gmail address.  my bugzilla account is a redhat one
17:25:29 <nirik> jwb: ah, I see, you want them to be different.
17:25:33 <jwb> nirik, yes.
17:25:51 * nirik has no idea where that is. Must be in pkgdb somewhere.
17:25:53 <pjones> yeah, there are a variety of ways requiring them to be the same wouldn't be great
17:26:01 <jwb> t8m, i don't want 300 kernel bugzilla emails going to my gmail account, and i don't want to have to be on the VPN (or doubly subscribed) to read fedora lsits
17:26:04 <jwb> er, lists
17:26:25 <t8m> jwb, OK, then we should not require bugzilla and FAS emails be connected at all
17:26:56 <t8m> jwb, but that requires having another field in FAS db to fill in the bugzilla e-mail
17:27:03 <nirik> t8m: making them not the same is currently a manual process. I don't know how easy it would be to automate
17:27:16 <tibbs|w> SMOP.
17:28:04 <nirik> in any case, I'm happy to offer that to anyone with current issues. My concern is that we have packages with bugzilla emails going to /dev/null or wrong right now. ;)
17:28:42 <nirik> anyhow, moving on...
17:29:34 <jwb> mjg59, raised the arm linker issue, right?
17:29:54 <limburgher> Yes.  (reading rapidly)
17:30:10 <nirik> my understanding of this is just a miscommunication, and I don't think we need to take any action here unless asked.
17:30:15 <t8m> nirik, +1
17:30:19 <mmaslano> um, I read about it a little. I'm not sure why we should do better decision than ARM SIG
17:30:31 <mmaslano> nirik: yeah :)
17:30:33 <jwb> nirik, i'd tend to agree.  unfortunate, but hopefully f18 gets it sorted out
17:30:44 <limburgher> Esp if ARM goes Primary.
17:30:58 <jwb> i don't see how that matters
17:31:13 <notting> seems a bit stronger than a miscommunication, but i don't know what else we can do other than force the arm release to slip indefinitely
17:31:27 <limburgher> I'd just rather get this settled, and *then* get it in front of a large user base, than change it after.
17:31:38 <jwb> oh, sure
17:31:50 <jwb> notting, yes
17:32:28 <mmaslano> I still don't see why we should handle it. I guess not all of us are following arm meetings closely
17:32:35 <mmaslano> is there anyone from arm?
17:32:45 <limburgher> probinson?
17:32:51 <limburgher> jonmasters?
17:32:55 * pjones summons blc
17:34:56 <jonmasters> the linker issue being discussed?
17:35:01 <jwb> yes
17:35:01 <pjones> yes
17:35:31 <mmaslano> jonmasters: do we need interfere? I'd rather see it decided by arm sig
17:35:35 <jonmasters> So we had agreed on a linker path fix between distros. Mainly because Ubuntu was doing an LTS with a 5 year life and we needed to agree in that timeframe. It was our goal to fix this in 17, but it looks unlikely now
17:35:59 <jonmasters> If it happens in 18 instead, or in an update to 17, that's fine
17:35:59 <limburgher> But it is in the pipeline?
17:36:06 <jonmasters> I don't think you need to take any action
17:36:08 <jwb> wait, in an update for f17?
17:36:26 <jonmasters> The linker path will be changing, but there is a compatibility symlink so nothing breaks
17:36:49 <bconoboy> update for f17 might simply be a reverse symlink to ensure cross compatibility
17:36:52 <jonmasters> it's just so that stuff built in the future to look for a path will agree across all ARM distros folks will be using
17:37:00 <notting> but it means that apps built on f17 GA won't be compatible elsewhere, correct?
17:37:01 <jonmasters> right, might just be a reverse symlink
17:37:31 <jonmasters> notting: it means they won't be compatible with Ubuntu unless it has the compatibility symlink
17:37:34 <jwb> so mjg59's assertion that a compat symlink doesn't work is incorrect?
17:37:35 <bconoboy> ubuntu will support either format for the foreseeable future.  Long term we all want to use the new path.
17:37:46 <jonmasters> notting: I believe Ubuntu is going to have a symlink anyway
17:37:48 <jwb> quoting the ticket: "This results in runtime incompatibility (a compatibility symlink isn't sufficient since glibc has ideas about rtdl paths), and binaries built in this way will have a non-canonical location and may not work on other armhf distributions. "
17:38:15 <jonmasters> who filed the ticket?
17:38:29 <jwb> mjg59
17:38:33 <jwb> https://fedorahosted.org/fesco/ticket/862
17:38:35 <limburgher> mjg59
17:38:44 <jonmasters> mjg59: thanks for pinging us ahead of time
17:38:55 <jwb> he's not present today
17:38:55 <bconoboy> none of us have seen this ticket.
17:39:53 <jonmasters> right so the summary here is we know about this issue, it's sensitive, we've agreed with other distros. We regret very much if we have to ship 17 with the older path because the fix requires a kludge we might not get chance to have our tools guys approve, but it will come out in the wash because 18 will be right, and 17 will likely get fixed post-release
17:40:06 <notting> the options are either 1) do the switch w/compat symlink now (possibly slipping)  b) do the switch in f18, possibly backport it (causing some incompatibility)
17:40:12 <jonmasters> Unfrotunately, the fix requires a kludge to avoid a mass rebuild
17:40:41 <limburgher> How long of a slip are you looking at for f17 if this goes in?
17:41:01 <jwb> i'm still confused between the ticket and what was said on the compat symlink
17:41:13 <jonmasters> notting: if you want to make it a gating factor on release, it could significantly delay us. I think it would be better to focus on the future, and not gate on this. We can get it fixed post-release in an update to a sufficient level of satisfaction prior to 18 having the final fix.
17:41:41 <bconoboy> limburgher: We're not looking for a slip- if the change isn't done when our remaining blockers are solved we plan on going ahead with the release.
17:41:45 <jonmasters> we are not the only distro facing this, others are making accommodations also
17:42:24 <jonmasters> the lesson learned is to discuss and agree on things in advance next time. Debian did multi-arch, none of the distros properly discussed the impacts before this came up on ARM
17:42:27 <limburgher> bconoboy:  It doesn't sound like an update for this on a GA release would be disruptive, is that a fair assessment?
17:42:34 <jonmasters> limburgher: yes
17:42:42 <bconoboy> limburgher: correct
17:42:43 <jonmasters> it's a non-disruptive update
17:43:12 <drago01> if it is "non-disruptive" why can't it be done prior to GA?
17:43:16 <notting> would we eventually drop the reverse symlink?
17:43:23 <jonmasters> because the tools guys want more time to look at it
17:43:24 <drago01> without a "significatant delay"
17:43:29 <bconoboy> drag01: required engineering resources are constrained.
17:43:36 <limburgher> That being the case, and since you're committed to playing nicely with the community and other distros and this is in the pipe, I'm not sure we need to do anything.
17:43:45 <pjones> What exactly do you mean by "non-disruptive"?
17:44:06 <pjones> It seems like you'd need to update glibc to fix the rtld path behavior and everything providing a library
17:44:08 <drago01> bconoboy: ok fair enough
17:44:13 <jonmasters> pjones: won't break anything in Fedora, will be at least as compatible as previous releases, and getting more compatible over time
17:44:55 <jonmasters> pjones: there is a hack that just updates the linker that folks are ok with taking until everything has been rebuilt in the future
17:45:26 <jonmasters> then that bit gets dropped, the linker path remains changed to the new standard, and everything is hunky dory in 18
17:45:51 <pjones> okay, so you're talking about doing a glibc update and then symlinking the directory so it finds the old packages at the new path until all the packages are (eventually) updated in the next distro release?
17:46:23 <limburgher> pjones:  Which should occur at next rebuild, mass or otherwise.
17:46:30 <jonmasters> we might keep the symlink in place - it's just a file and it'll let you run old Fedora ARM binaries. Not really a loss.
17:46:37 <jonmasters> :)
17:46:47 <pjones> limburgher: right, but to me that means we'll wind up doing at least one mass rebuild for this in the F18 timeframe
17:46:54 <pjones> (or for something else if there's one planned)
17:47:08 <jonmasters> or we can keep this in 18 and do a mass rebuild in 19
17:47:13 <limburgher> Exactly, it seem like there's always something. :)
17:47:14 <pjones> jonmasters: well, at some point you'd probably rather have the wrong one as the symlink instead of the right one ;)
17:47:14 <jonmasters> I wouldn't say this forces a mass rebuild
17:47:29 <bconoboy> a mass rebuild would be nice, but is not a requirement
17:47:31 <limburgher> jonmasters:  No, not at all.
17:47:33 <jonmasters> pjones: right, so that's what I mean
17:47:36 <jwb> the symlink isn't a directory, is it?  it's symlinking /lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3
17:47:47 <jonmasters> jwb: right, it's a file link
17:47:52 <pjones> jwb: I was assuming another symlink would be the way to fix the path issue?
17:47:54 <bconoboy> canonical did not mass rebuild, we don't need to either.  It'd be nice, but it's not pressing.
17:47:55 <jonmasters> it's not a multi-arch thing
17:48:00 <limburgher> jonmasters:  I might suggest one if nothing else were likely to need one, but the odds of that are small.
17:48:16 <jonmasters> they do multi-arch, but we agreed to keep the linker in a sane place
17:48:30 <jonmasters> we just encode the arch in the path name instead
17:49:24 <jonmasters> anyway, I'd love to not have this problem, I'd be pulling the Big Red Handle if this were a multi-year RHEL, but it's a 6 month Fedora release where we'll be at least as compatible as previously and by 18 at least the linker paths on all major ARM distros will agree
17:49:53 <jwb> still confused why mjg59 claims the symlink won't work, and everyone else says it will
17:50:12 <jonmasters> jwb: because there's an accompanying linker hack that he probably doesn't know about
17:50:19 <jwb> pointer?
17:50:34 <bconoboy> http://lists.linaro.org/pipermail/cross-distro/2012-April/000263.html
17:50:58 <jonmasters> Adam (Canonical) found this during their switchover. It's a hack, but it's one folks are OK with
17:51:09 <jonmasters> it goes away once everything has been rebuilt, so e.g. next mass rebuild
17:51:39 <bconoboy> well.. it goes away when we're ready to drop support for binaries using the old path
17:52:11 <jwb> erm
17:52:18 <jwb> so that's patching the common linker, right?
17:52:23 <jwb> not an arch-specific one?
17:52:30 <limburgher> We're past the 30 minute mark on this, does anyone think we need to do anything here?
17:52:51 <jonmasters> I think the best people are engaged. The tools guys are actively involved. I don't think you need to do anything.
17:52:59 <pjones> I think it'd be nice if jonmasters or bconoboy could reply to mjg's concerns in the ticket, and we could revisit next week if he's still worried about it
17:53:09 <bconoboy> sounds good.
17:53:11 <jonmasters> that's fair enough
17:53:14 <mmaslano> jonmasters: great. Thank you for your response
17:53:43 <jonmasters> mjg59: thanks for raising this - please ping us ahead next time to let us know, we had no idea this was coming up today and I just got back from Japan last night so I might not have been online
17:53:48 <limburgher> #proposal Leave this issue in ARM team's hands, ARM team will comment in ticket.
17:53:49 <limburgher> +1
17:53:54 <t8m> although I still think this should be rather ARM SIG issue than something for FESCo
17:54:01 <t8m> limburgher, +1
17:54:03 <mmaslano> +1
17:54:19 <jonmasters> thanks guys - anything else comes up, ping us
17:54:24 <nirik> +1
17:55:46 <limburgher> notting, pjones, jwb?
17:55:55 <notting> sure, +1
17:56:07 <jwb> sure
17:56:38 <pjones> +1
17:56:42 <limburgher> #agreed Leave this issue in ARM team's hands, ARM team will comment in ticket. (+:7,-:0,0:0)
17:56:44 <pjones> Since, you know, it was my suggestion.
17:57:00 <limburgher> pjones:  You never know.  ;)
17:57:03 <limburgher> #topic Next week's chair
17:57:26 <pjones> limburgher: I'll let you know when I'm playing devil's advocate - it won't start with declarative statements about my opinion :)
17:57:41 <limburgher> pjones: LOL
17:57:59 <limburgher> Any chair takers?
17:58:12 <nirik> I suppose I could...
17:58:26 <nirik> (I will be gone the following 2 meetings)
17:58:43 <limburgher> #action nirik will chair 2012-06-18
17:58:44 <limburgher> Thanks!
17:58:50 <limburgher> #topic Open Floor
17:58:52 <nirik> no problem
17:59:15 <jwb> we should thank sgallagh for the work during his previous term
17:59:27 <tibbs|w> I pinged the admins of the packager group as requested last week.
17:59:35 <nirik> yes indeed! Thanks sgallagh for all your work...
17:59:43 <limburgher> jwb:  Thoroughly seconded.
17:59:45 <tibbs|w> Two users so far had me remove their admin privs.
17:59:55 <sgallagh> Glad to be a part of this. I intend to rejoin in six months :)
18:00:05 <limburgher> tibbs|w:  Yes, this seems to be going well.
18:00:59 <notting> yes, thx to sgallagh
18:01:14 <tibbs|w> And we did two new sponsor applications without problems.  I finished editing all of the various wiki pages (or at least the ones that I found) and all of the new sponsor procedures are in place.
18:01:20 <tibbs|w> I probably should announce it somewhere.
18:01:45 <limburgher> tibbs|w:  That would be swell, probably -devel.
18:02:11 <limburgher> If no one has anything else, I'll close out in 3.
18:02:42 <t8m> sgallagh, thanks for you work, hopefully you'll rejoin after next elections
18:05:04 <limburgher> #endmeeting