17:00:54 <mitr> #startmeeting FESCO (2012-04-02)
17:00:54 <zodbot> Meeting started Mon Apr  2 17:00:54 2012 UTC.  The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:59 <mitr> #meetingname fesco
17:00:59 <zodbot> The meeting name has been set to 'fesco'
17:01:02 <pjones> hello.
17:01:02 <mitr> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
17:01:02 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
17:01:06 <mitr> #topic init process
17:01:11 * nirik is here
17:01:14 <mmaslano> hi
17:01:46 * notting is here
17:02:02 * limburgher here
17:02:10 <t8m> hello
17:02:12 <mjg59> Here
17:03:28 <mitr> Is sgallagh comming?
17:04:51 <mitr> <sgallagh> I will be on a plane during next week's meeting.
17:04:55 <mitr> OK, let's start.
17:05:02 <mitr> #topic #830 define requirements for secondary arch promotion
17:05:04 <mitr> .fesco 830
17:05:05 <zodbot> mitr: #830 (define requirements for secondary arch promotion) – FESCo - https://fedorahosted.org/fesco/ticket/830
17:05:31 <limburgher> Do we have a link to said wiki page?
17:05:46 <mjg59> http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29
17:05:46 <nirik> http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_(Draft)
17:06:13 <notting> both of those appear blank
17:06:23 <limburgher> First worked for em
17:06:24 <limburgher> me
17:06:26 <mjg59> notting: Looks ok here
17:06:29 <mitr> notting: reload, they were blank once
17:06:40 <notting> ah, caching
17:06:43 <nirik> so, before promotion, all builds must take place on Fedora-maintained build servers? so that would require hardware and infra/rel-eng support before promotion, right?
17:06:46 <mjg59> Software is great
17:07:14 <mjg59> nirik: My thinking here was that once promotion has occured, everything should be working
17:07:33 <mjg59> nirik: So we want to make sure that it works on the Fedora infrastructure /before/ it becomes primary
17:07:40 <mjg59> Otherwise it stops building and everyone's updates stop flowing
17:07:50 <limburgher> Should we define what's required to get each PreReq step down, or is that later?
17:08:16 <mitr> I'm not sure this needs to be made more detailed
17:08:28 <bconoboy> what's the procedure for the arm team to propose changes to the draft? can we edit directly?
17:08:32 <nirik> yeah. Might rephase that as "All builds must be ready to occur on Fedora-maintained build servers" ?
17:08:34 <pjones> yeah, I think more details actually hurt the efficacy of the document.
17:08:44 <limburgher> Ok.
17:08:52 <pjones> nirik: well, the thought is that we flip the build switch and make sure it's working /before/ declaring it primary
17:09:11 <mjg59> nirik: No, I really did intend to mean "All builds must be on Fedora-maintained build servers"
17:09:21 <mitr> What would you think about something to the effect "98% compliance is expected"?  Even the existing primary architectures are often at 100% (in particular "must meet formal release criteria") only a few weeks per year
17:09:23 <nirik> pjones: ok, I just wanted to clarify that means hardware and rel-eng and infra resources have to be in place before promotion.
17:09:29 <limburgher> So with this, how do we handle generation of a list of  'do X, then Y, then Z to get here" for the ARM team, or has that been done?
17:09:30 <mjg59> nirik: once it's primary, it's required for updates
17:09:45 <bconoboy> you can't use the same koji hub for a secondary and a primary so we'd need a second hub to drive builds
17:09:53 <mjg59> nirik: So we have to know it's working before it becomes primary
17:10:02 * nirik doesn't think he's getting his question accross correctly.
17:10:20 <mjg59> bconoboy: Discuss on the list
17:10:42 <bconoboy> mjg59: will you be the point man for all edits to the document then?  IE, who is allowed to edit?
17:10:52 <mjg59> bconoboy: It's a wiki, anyone's allowed to edit
17:11:02 <mitr> mjg59, pjones: Based on last week's discussion, the anaconda requirement might be too strict.  I wouldn't know :)
17:11:06 <mjg59> bconoboy: But editing it without reaching some sort of rough consensus first would probably be a mistake
17:11:11 <bconoboy> mjg59: yes, but if I edit it I could put something in that isn't agreed to
17:11:24 <pjones> mitr: I think that anaconda requirement is fine - if the situation is that a machine shouldn't be using anaconda, it isn't required
17:11:25 <mjg59> Yes, so don't do that :)
17:11:26 <nirik> discuss on list -> consensus -> edit
17:11:31 <bconoboy> Okay, so get consensus on list, then edit.  Which list?
17:11:33 <mitr> pjones: ok
17:11:41 <mitr> bconoboy: devel@
17:11:52 <mjg59> bconoboy: -devel is probably sensible, unless it's an issue that primarily affects one subteam?
17:11:57 <bconoboy> how much consensus is needed?  Some people will just say no, no matter what.
17:12:00 <mjg59> Kernel stuff would be fine discussed on -kernel, I think
17:12:15 <mjg59> bconoboy: If there's a point where people aren't reaching agreement then pushing it to fesco would probably make sense
17:12:22 <bconoboy> okay, thanks
17:12:53 <pjones> consensus also does not necessarily mean unanimous agreement ;)
17:12:55 <bconoboy> mjg59: I haven't had a chance to read the doc yet, but will do so and provide feedback on the list (or lists).  Appreciate you putting something together.
17:13:01 <nirik> should we add a similar point to the kernel one for packages in general? ie, if glibc doesn't build in a 'timely manner' is that a blocker to promotion? libreoffice?
17:13:01 <limburgher> pjones: :)
17:13:03 <mjg59> mitr: Ok, so re: the Anaconda thing - some of these ARM devices are going to look pretty much like normal PCs. The Fedora installation experience should be consistent on them.
17:13:35 <mitr> mjg59: right
17:13:42 <mjg59> mitr: There are other devices where that doesn't make sense, like some which can only boot off one specific piece of media. You'd never be able to do an Anaconda install on those, so it shouldn't be required
17:14:06 * nirik nods. +1 to mjg59's points
17:14:29 <mjg59> And the live-media style install makes sense then
17:14:53 <notting> also the live-media style image creation
17:14:54 <mjg59> But where possible, it would be nice if there's as much overlap between image generation as possible
17:15:07 <pjones> notting: yes
17:15:10 <mjg59> Because did you know that we have three different ways of generating x86 isos?
17:15:23 <pjones> only 3?
17:15:23 <mjg59> I didn't
17:15:29 <mjg59> pjones: Well, three that we use?
17:15:34 <mjg59> netinst, live and dvd
17:15:47 <pjones> yeah
17:15:49 <mjg59> Have I missed some?
17:15:59 <mjg59> Anyway, it's not fun having to fix things in all of them
17:16:07 <nirik> proposal: wait a week for more discussion on list, vote on critera draft?
17:16:40 <t8m> nirik, +1
17:16:41 <mjg59> nirik: +1
17:16:42 <mitr> +1
17:16:46 <mmaslano> +1
17:17:06 <limburgher> +1
17:17:09 <notting> +1
17:17:55 <mitr> pjones: ?
17:18:01 <pjones> +1
17:18:06 <mitr> thanks
17:18:12 <pjones> (though seriously, we don't need everybody to vote if it hits +5)
17:18:27 <mitr> #agreed wait a week for more discussion on list, vote on critera draft
17:18:36 <mitr> #topic #833 Remove provenpackagers access to libvirt related packages
17:18:41 <mitr> .fesco 833
17:18:43 <zodbot> mitr: #833 (Remove provenpackagers access to libvirt related packages) – FESCo - https://fedorahosted.org/fesco/ticket/833
17:18:57 <pjones> removing provenpackagers access seems like /entirely/ the wrong answer here
17:19:15 <mjg59> Especially if some of the problems are ascribed to secondary arch maintainers
17:19:29 <nirik> I'm going to recuse myself here from voting, since I am involved.
17:19:30 <pjones> right; they're not even using the same mechanism
17:19:32 <mjg59> Is the ticket filer here?
17:19:34 <pjones> nirik: fair
17:19:49 <pjones> --- [danpb] idle 08:44:08, signon: Mon Apr  2 04:35:34
17:20:04 <mjg59> Can't be that important, then
17:20:25 <mjg59> I guess there's a wider argument that we should talk about what to do if provenpackagers do behave inappropriately?
17:20:30 <mitr> yeah.  Having good upstream support in Fedora is great, but the whole point of a distribution is to integrate/adapt upstream projects, and spec file edits/patches are the conventional way to do it.
17:20:57 <mitr> mjg59: Reading the current provenpackager policy, I can't see that it is as strong as the ticket presents - it's often expected that PPs will change a package without clearing it with upstream first
17:21:02 <limburgher> At the end of the day both libvirt and secondary arches need to interoperate, and I think pulling PP would hinder that.
17:21:05 <mjg59> In this specific case, while having an upstream QA and release cycle is great, forcing distribution updates to go through that process doesn't seem appropriate
17:21:21 <t8m> mitr, +1
17:21:32 <mitr> Also, even if a PP _did want_ to follow libvirt-specific process, there's no way to find it by looking at the pkgs repo / spec file AFAICS
17:21:41 <mitr> so it's kind of hard to blame PPs
17:21:52 <mjg59> So I'm -1 to the request, but would be happy to talk about whether we need to rethink any aspect of PP
17:22:14 <limburgher> mjg59: <nods>
17:22:54 <pjones> Well, if a PP does something bad to a package, the answer isn't to remove PP access to the package.  It may, depending further on the circumstances, be to remove that contributor's PP bit.
17:23:10 <mitr> mjg59: I'm not sure, did anything go actually wrong here?
17:23:18 <limburgher> pjones: Indeed.
17:23:18 <mjg59> mitr: I don't think so, really
17:23:31 <t8m> I'm -1. If they have concrete problems with breakage introduced by PPs or secondary arch maintainers (not a breakage of their special process but of the packages) they should be resolved individually.
17:23:34 <mjg59> mitr: But I don't think we have a great policy for dealing with the case where something did go wrong
17:23:39 <limburgher> If anything, it should be cause for discussion.
17:23:42 <nirik> I was trying to avoid a beta slip. It tuns out the fix we thought fixed things didn't.. but I don't see it as a big deal.
17:23:47 <mitr> mjg59: "solve it case by case" seems to scale fine right now...
17:23:56 <mjg59> mitr: Yeah, I've no problem with leaving it at that
17:23:57 <pjones> mitr: indeed.
17:23:58 <limburgher> mitr: +1
17:24:04 <mjg59> So maybe we should just vote on this?
17:24:14 <pjones> proposal: deny the request.
17:24:17 <mitr> I think the expectation that Fedora will commit to shipping pristine upstream tarballs is just not reasonable.
17:24:20 <t8m> nirik, it did not introduce a regression, it just did not fix the problem, right?
17:24:31 <nirik> t8m: correct.
17:24:40 <t8m> mitr, +1
17:24:40 <mitr> +1 to proposal == -1 to request from me.
17:24:49 <pjones> mitr: well, certainly not the expectation that we'll ship pristine upstream /spec files/
17:24:53 <nirik> and the update was unpushed... so it could easily be reverted if there was some issue.
17:25:07 <t8m> +1 to deny the request
17:25:12 <mitr> pjones: that especially
17:25:24 <limburgher> +1 to deny.
17:25:30 * pjones also +1 to deny, of course.
17:25:45 <notting> +1 to deny (weird phrasing, that is)
17:26:06 <pjones> yeah, realized afterwords that I should have inverted it.  but then I'd also have seemed like I was for the thing.
17:26:22 <mjg59> +1 to deny
17:26:55 <mmaslano> 0, they might have more problems than the last one, but they didn't mentioned them.
17:26:56 <danpb> rbergeron mentioned my presence was desired
17:27:05 <pjones> mmaslano: isn't that always true?
17:27:44 <mmaslano> pjones: virt team has a good response time, I don't see reason why anyone should write in their packages. That's all
17:28:24 <mmaslano> danpb: I guess you came too late ;-)
17:28:37 <pjones> mmaslano: even good response time is sometimes too long to prevent a slip.
17:28:39 <danpb> FYI, I would not be objecting to provenpackagers making changes,  *if* they ever bothered to try and reach us via email or other channels first
17:28:56 <danpb> in our experience people have not even tried
17:28:59 <mitr> danpb: right now we are at +6 to deny the request... in summary, 1) provenpackagers _are_ expected to sometimes modify packages, 2) there didn't seem to be any harm, 3) distributions do change upstreams from time to time, 4) there is no indication in the spec file / package that special processes are requested
17:29:17 <nirik> danpb: where's the best place to contact the virt team at 11pm on a night when trying to compose a beta rc?
17:29:29 <mitr> s/change upstreams/make changes compared to upstream's tarball/
17:29:32 <danpb> mitr: the Fedora provenpackager docs on the wiki, say they should try to contact the maintainers first, but no one ever seems to
17:30:10 <danpb> nirik: email, irc as usual
17:30:18 <pjones> danpb: two things - 1) you seem to be conflating proven packagers and secondary arch maintainers in the ticket, 2) in general if some PP is doing something wrong, we'd rather deal with that PP individually than remove a package from broader access.
17:30:20 <mitr> danpb: "these things can be fixed directly in the devel branch of Git without contacting the individual maintainers";
17:30:22 <mitr> "small fixes or adjustments for new or modified packaging guidelines can be done directly in Git after being announced some days in advance. "
17:30:30 <t8m> #info Provenpackagers please try to contact the maintainers first (if possible) before you commit changes to a package.
17:30:53 <danpb> mitr: IMHO, they should always contact the maintainer, no matter how small
17:31:39 <nirik> danpb: cool. what irc channel(s)? what email? The problem is that it's hard to know that a particular component has 24x7 maintainers around ready... most will not. I agree more communication is a good thing.
17:32:39 <danpb> pjones: i'd be happy enough, if there was a stronger documented  recommendation/requirement for maintainers to be contacted before making changes, both by provenpackagers & secondary arch maintainers
17:33:04 <danpb> nirik: well every Fedora packager has a registered email alias
17:33:10 <mitr> danpb: I appreciate that the libvirt team has well-defined mantenance processes and strong commitment to Fedora package quality and timeliness; however, that's clearly the minority case here.
17:33:16 <mjg59> danpb: Could you explain why the lack of this requirement causes you problems?
17:33:37 <danpb> mjg59: we try very hard to maintain the exact same RPM spec file across multiple locations
17:33:50 <mjg59> danpb: We upstream or we fedora? Because the latter isn't true.
17:33:57 <danpb> we usually have the exact same spec in upstream, RHEL, Fedora master & Fedora XXX
17:33:59 <nirik> sure... in cases where time is critical it's hard to mail out and wait some unspecified time for a answer... but I agree that situation is in the minority.
17:34:23 <mjg59> danpb: Right, but your upstream preferences aren't really something that we take into consideration in Fedora development
17:34:24 <danpb> having people make unannounced changes to only 1 of those locations makes like more complicated
17:34:50 <mjg59> danpb: Making volunteers jump through extra hoops for the sake of upstream preferences isn't really the way we do things
17:35:02 <danpb> mjg59: i don't see why it is so hard for people to at least send 1 email to the maintainer asking if a change is ok
17:35:10 <mitr> danpb: It seems to me that maintaining a Fedora spec file in a different VCS is Just Wrong
17:35:36 <danpb> mitr: i'm not going to get into a debate about that, in our experiance it is a clear win
17:35:36 <pjones> mitr: or at least not syncing back from fedora before clobbering - but is that actually relevant to this discussion?
17:35:47 <mitr> fair enough
17:36:00 <mmaslano> danpb: do you have any specific problems which we can solve?
17:36:11 <mjg59> danpb: If the problem here is purely the interaction between provenpackager policy and your maintenance policy, provenpackager policy is probably going to win
17:36:28 <mjg59> danpb: Your maintenance policy has to take into account Fedora policy, rather than vice-versa
17:36:30 <mmaslano> danpb: for example announce to proven packagers or secondary arch maintainers, they should be more communicative?
17:36:34 <danpb> mmaslano: as i've just said, i would like a stronger recommendation to contact the maintainer before a provenpackager / secondary arch maintainer makes changes
17:36:51 <mmaslano> could we vote on danpb proposal?
17:37:00 * nirik has no problem with that personally. More communication is good.
17:37:19 <mjg59> We could certainly modify the policy page to make that more obvious
17:37:21 <danpb> mjg59: sure, i'm not asking for fedora to bend to my policy - just for a little more proactive communciation
17:37:38 <danpb> which would have avoid most of this pain
17:37:40 <mitr> danpb: I'd expect a loud comment at the top of the .spec file would help
17:37:48 <t8m> mitr, +1
17:38:06 <mitr> As for a general PP policy change, does anyone want to draft it?
17:38:28 <mmaslano> I could
17:39:19 <mjg59> Sounds good to me
17:39:36 <mitr> So, the ticket was rejected, mmaslano will suggest PP policy changes.  Everyone fine with that?
17:39:47 <mitr> #action mmaslano will draft provenpackager policy changes
17:40:03 <mitr> moving on...
17:40:06 <mitr> #topic #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs
17:40:10 <mitr> .fesco 834
17:40:11 <zodbot> mitr: #834 (F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs) – FESCo - https://fedorahosted.org/fesco/ticket/834
17:40:39 <nirik> +1 from me.
17:40:48 <limburgher> +1 here as well.
17:40:51 <mmaslano> I have questions
17:40:55 <mitr> 1) the benefit is nebulous (is it measurable at all?); anecdotal non-data from asking around is that it's not noticeable
17:41:00 <mitr> 2) No, there were never particular guaranteees about /tmp size, but still this is a change of de-facto conventions (single large / filesystem => small tmpfs).
17:41:02 <mitr> "My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs!
17:41:04 <mitr> The application should be fixed to use /var/tmp."
17:41:06 <mitr> == "My quite correct and working application is now broken" => "That is by design, go change it"
17:41:08 <mitr> The plan "let's change that and let others worry about finding broken things and fixing them" imposes costs on others who don't have a direct say.
17:41:10 <mitr> Yes, there are cases where there is no other way to distribute the work, but I can't see that tmpfs on /tmp is that important (see above re: benefit).
17:41:16 <mitr> 3) "this work has already progressed due to Debian's work" - seems to mostly indicate "bugs were filed".  Still seems pretty controversial, and definitely not "progressed".
17:41:24 <mitr> 4) This Makes the system unreliable / the failure case pretty much kills the system without a way to recover other than reboot
17:41:32 <mitr> 5) If tmpfs use leads to DoS, it needs to be fixed _before_ entrenching it more, not just hoping that someone will magically solve it
17:41:41 <mezcalero> dude copy/paste into irc sucks
17:41:57 <mitr> Right, I didn't have time to look at this last week, sorry.  It would have been on the talk page
17:41:58 <mezcalero> and next time you get a cookie for copy/pasting that into the discussion page first, so that we can prep an answer...
17:42:15 <mitr> 2-5 can be accepted, but without 1) - why?
17:42:34 <pjones> mitr: there's at least 1 solid benefit - if /tmp is its own mountpoint, tmp races with hardlinks won't work.
17:42:58 <mezcalero> mitr, there are actually four reasons we list not just one
17:43:12 <kay> and we want to limit the delta to read-only / to a minimum in the default setup
17:43:19 <limburgher> tmp will be automatically flushed at boot.
17:43:52 <mitr> kay: breaking an unknown number of packages to avoid 5 lines specific to stateless?  doesn't sound like a great bargain
17:44:13 <kay> stuff that breaks gets fixed
17:44:22 <mezcalero> mitr: and you know, we fix and change applications all the time, when we change some of our basics because they are better that way
17:44:27 <kay> but only when we use it, otherwise it will be unknown
17:44:32 <notting> anything that expected /tmp to be persistent was already broken, was it not?
17:44:33 <mezcalero> mitr: example, we made /tmp private by default for many system services
17:44:36 <mjg59> Given the ease of reverting it, I'd hope that a release cycle is enough time to shake out the broken applications
17:44:39 <mezcalero> mitr: this also required fixing some of them
17:44:48 <mitr> notting: This is mostly about things that expect /tmp to be large
17:45:44 <mezcalero> you know, we totally know that this might break some apps
17:45:54 <mezcalero> but instead of some nebulous "we are fearful it might break things"
17:45:58 <mmaslano> mezcalero: do you have plan how to fix for a example gcc, which is making huge file in /tmp during build of libreoffice?
17:46:00 <mezcalero> we suggest to make the change in the devel distro
17:46:04 <mezcalero> then watch, see what breaks
17:46:08 <mezcalero> fix it if we can
17:46:12 <mezcalero> or revert if necessary
17:46:23 <mezcalero> only then we know for *sure* what actually breaks
17:46:23 <mitr> mezcalero: That will get you a distribution where you know that something is probably broken, but you don't know what.
17:46:36 <mezcalero> mmaslano: sure, we will fix whatever needs fixing, that's the idea
17:46:41 <mmaslano> mezcalero: how?
17:46:43 <mezcalero> mmaslano: also see the tracker bug we suggested for that
17:46:50 <mmaslano> mezcalero: do you put files into /var/tmp or where?
17:46:55 <pjones> mitr: and once again, isn't that always true?
17:46:56 <mezcalero> mmaslano: the way we usually do this: prep a patch and ask for inclusion
17:47:04 <mezcalero> mmaslano: yes
17:47:09 <notting> hm. by the fhs standard we could have per-PID /tmp. that could be entertaining.
17:47:20 <mmaslano> mezcalero: one might say it's not good path
17:47:33 <mezcalero> mmaslano: why not?
17:47:34 <t8m> mezcalero, there should be a clear proposal for "large files tmp" as part of the plan - if there isn't such proposal (maybe I just missed it) it is wrong
17:47:47 <mitr> pjones: In general, yes, but that's not a reason to introduce more reasons for it to be true. 1% of broken programs per release compounds...
17:47:50 <mezcalero> (also, there's a dirty interim fix for various apps, i.e. set TMPDIR)
17:47:59 <mezcalero> t8m: there is a proposal
17:48:10 <mitr> And even if we _did_ fix all of them, is there the benefit?  That's still my main problem with this.
17:48:15 <mezcalero> t8m: please refer to the feature page, will find a link there to this: http://0pointer.de/blog/projects/tmp.html
17:48:32 <mjg59> t8m: On-disk tmp continues to be provided by /var/tmp
17:48:38 <t8m> OK
17:48:39 <mezcalero> you know, we are really not on our own with this
17:48:44 <mezcalero> this is not where we are pioneering
17:48:49 <mjg59> mitr: Yes, there are benefits
17:48:53 <mezcalero> this is simply where we are following, debian and commercial unixes
17:49:01 <mezcalero> and ubuntu is doing this too
17:49:16 <mezcalero> this is not an isolated effort
17:49:21 <mjg59> mitr: It reduces disk thrash for files which are purely temporary intermediates. It prevents some set of security attacks.
17:49:28 <kay> i personally run that for many years on all of my boxes with an entry in fstab
17:49:35 <t8m> so if all the various apps start to move to use /var/tmp "just to be sure that they do not break if they need to store something large" - what is again solved by /tmp on tmpfs?
17:49:37 <mezcalero> a lot of work is going into this from many sides of the linux ecosystem
17:49:50 <kay> just like solaris has from the beginning ...
17:49:52 <mitr> mjg59: With ext4 delayed allocation, is that noticeable?
17:49:58 <mmaslano> kay: do you scan huge files? build libreoffice or run oracle?
17:50:01 <mezcalero> t8m: well, about 90% of all files are not actually "huge"
17:50:15 <mjg59> mitr: If the intermediate lies around long enough to be hit by the writeout thread, yes
17:50:17 <pjones> t8m: I don't think there's any reason to believe that'll happen
17:50:23 <mitr> mezcalero: I have seen tickets filed.  I haven't seen many tickets closed - if anything, I have seend Debian maintainer resistance.
17:50:28 <mezcalero> t8m: the candidates are well known, that's mozilla's downloads, gcc's linking and a small number of others
17:50:41 <mezcalero> mitr: yet, the change has been made in debian already
17:50:46 <mezcalero> mitr: yes, people resist
17:50:47 <mitr> mjg59: Looking at my /tmp, I can't really see that this is worth anybody's time
17:51:09 <mezcalero> mitr: but the slightest opposition is not reason to already give up
17:51:17 <t8m> mitr, heh, this was non-argument for other changes :D (although I agree with you)
17:51:21 <kay> mmaslano: i just do my job, that does not involve running oracle. :) but i'm confident that oracle does not use /tmp without dictating how /tmp should look like :)
17:51:40 <mitr> (Note that sockets use in /tmp does not update any file times, so it does not hit the disk)
17:52:02 <mmaslano> kay: I'm only missing what you will do with those apps who store data in /tmp. If you have some plan, where should they store their data
17:52:25 <kay> mmaslano: in /var/tmp like they are required to use on solaris
17:52:34 <notting> mmaslano: there are guidelines on the above-referenced blog post. i'm sure they could be put into the feature documentation
17:52:44 <kay> mmaslano: hence i would not expect oracle to fail over /tmp
17:52:53 <mmaslano> kay: that was only one of examples
17:53:21 <mezcalero> so, let me stress a couple of things: a) we will fix what breaks. b) if it's too much we will revert this before the release. c) people can easily opt-out from this, and we document it
17:53:22 <kay> mmaslano: yeah, stuff will get fixed as needed. it's pretty simple. but we need to know
17:53:27 <mitr> mezcalero: Random google find: "/tmp/OraInstall2012-03-28_09-48-46AM/jdk/jre/bin/java"
17:53:40 <mitr> kay: ^^
17:54:10 <pjones> so what you're saying is that orainstall is terrible software?
17:54:20 <kay> mmaslano: but we need to be able to support stateless boots, and for that it's a must anyway. hence we want it as default at least until we fall over and go back...
17:54:41 <mitr> mezcalero: with a), you won't even _find_ anything that breaks.  It's 4 hours of greping all source code, >1 month of looking at it to see what would break, and you haven't even started fixing it.
17:54:45 * limburgher invoices pjones for new keyboard
17:55:00 <mitr> kay: And what will stateless boots do about /var/tmp ?
17:55:44 <mitr> mezcalero: (been there, tried that wrt crypto)
17:55:49 <notting> mitr: it's tmpfs unless you did something else
17:55:51 <kay> mitr: read only / nothing, stateless probably a tmpfs too. i mean read only / in the snetence above
17:55:55 <mezcalero> you know, since tmpfs was introduced it has always has been an optiont to be mounted on /tmp. That's why it's called tmpfs. So, given that downstreams already could disable this trivially on many distros, this really just boils down to: let's switch the default. not more. Some things that were already incompatible with a few setups will then be incompatible with a few more, but either way, they dserve to be fixed, and to fix them we need to
17:56:02 <mjg59> /var/tmp is required to be stateful
17:56:04 <limburgher> Ok, let's look at it this way.  If this is already the case, and it's a problem for Oracle installs, then no one must be running Oracle on Solaris, right?
17:56:25 <mezcalero> mitr: the same as with /var
17:56:32 <kay> limburgher: or have enough ram or swap :)
17:56:45 <mezcalero> mitr: it needs to be persistant, the same way /var needs to be persistant
17:56:48 <pjones> limburgher: or at least not on machines with too little ram to untar a jre into it
17:57:22 <mitr> limburgher: Solaris might have a different installer, I wouldn't know.
17:57:26 <limburgher> kay, pjones:  I can't imagine either of those is case for very many people.
17:57:55 <limburgher> mitr:  Good point.  How about Debian?
17:58:12 <mitr> limburgher: I take Debian as unknown right now.
17:58:13 * nirik notes 18minutes on this topic so far. ;)
17:58:22 <mezcalero> mitr: you let yourself be held hostage by another company, based on a nebulous fear of yours
17:58:40 <mezcalero> mitr: i'd like to turn this into hard data
17:58:45 <mitr> mezcalero: I don't agree with the cavalier approach to breaking software, but you already know that.  Anyway, my biggest problem is that there
17:58:46 <mezcalero> i.e. let's find out what breaks
17:58:49 <mezcalero> and we can revert
17:58:50 <t8m> mezcalero, I hope you understand that Oracle was just an example
17:58:59 <mezcalero> mitr: you already give up before trying
17:59:01 <mitr> 's nothing to make me want this.  How faster will the system be?
17:59:17 <mezcalero> mitr: 42%!
17:59:21 <mitr> mezcalero: hard data would be good - but before spending the man-weeks
17:59:52 <mezcalero> mitr: yeah, so let's turn it on in the devel distro
17:59:55 <mitr> mezcalero: care to address the "1 month to find out what would break"?
17:59:57 <mezcalero> mitr: then collect hard data of any kind
18:00:41 <mezcalero> mitr: and revert if it turns out to bring nothing but the most horrendous pain mitr can think of
18:00:45 <mitr> "if nobody complains, then it isn't broken" doesn't work for me - not with components that have dozens of bugs, some of them with hundreds of Cced people, and no progress.
18:01:41 <nirik> mitr: do you have these bugs handy?
18:02:25 <mmaslano> mezcalero: do you have some bug tracker already?
18:02:43 <mezcalero> mmaslano: nope, will set a tracker bug up when we have an OK for enabling it
18:03:02 <mezcalero> doesn't make mnuch sense setting that up if people are so in fear about this feature that they don't even try ;-)
18:03:13 <mitr> nirik: Not all of them, most would probably be individual components like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666035
18:03:18 <drago01> mitr: I have been using tmpfs for /tmp for years already (on all of my systems) I yet have to see any breakage
18:03:26 <nirik> we could also go dig thru debian bugs and check against our versions of those packages...
18:03:36 <kay> same here, works for me since years
18:04:14 * nirik waits for that bug to load. slooooow.
18:04:14 <mezcalero> same here
18:04:36 <mitr> mezcalero: just to make sure you understand me - my biggest problem isn't with the breakage (although i DO actively dislike the approach), but with the lack of benefit
18:05:00 <mezcalero> mitr: we listed 4 for you
18:05:10 <mitr> nirik: most related to the option would be http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;package=initscripts , search for tmpfs and RAMTMP
18:05:15 <notting> nirik: maintainer intransigence. *shock*
18:05:51 <nirik> so, it's 'sort' of files larger than memory?
18:06:18 <mitr> nirik: the initscripts list has more relevant examples, just took me longer to get a link
18:06:42 <mitr> mezcalero: 1) speed/SSD: data? 2) flush on boot - doesn't need tmpfs 3) closer to Unixes - non-issue, OTOH futher from old Linux, 4) delta to stateless - you can add 20 lines in an hour, or we all can spend days and weeks changing /tmp to /var/tmp
18:06:51 * nirik nods. the sort thing seems odd... was it broken before for 'sort files larger than available disk space on /'? :)
18:07:03 <brunowolff> tmpfs is backed by swap, so it can be larger than memory
18:07:07 <mitr> mjg59's "/tmp on a separate FS" is somewhat compelling
18:07:14 <kay> tmpfs is fully swapable :)
18:07:20 <mitr> brunowolff: but if it overflows swap, the system is totally killed.
18:08:30 <mitr> nirik: Given that the default install is/long was a single huge / partition...
18:08:46 <mezcalero> mitr: dude, by default it has a limit of half RAM
18:08:53 <mezcalero> mitr: we can lower that even
18:08:59 <mezcalero> mitr: debian does 30% of RAM by default
18:09:09 <mezcalero> which value we pick doesn't really matter
18:09:18 <mezcalero> but there's always an implicit value picked
18:09:23 <nirik> anyhow, I'm still for trying this. I'd suggest rechecking the bug cases from debian against fedora packages and adding them to the tracker when it exists.
18:09:23 <mitr> mezcalero: and 4 other tmpfs systems are already mounted on F16.
18:09:33 <mmaslano> nirik: who will do it?
18:09:35 * nirik notes we are now at 30min on this topic.
18:09:37 <notting> mitr: 1) can not be slower uless you're swapping. if you're swapping, you've already lost. 2) makes flushing on boot trivial, defined, race-free, conflcit free, etc. 3) that's not an argument. 4) having r/o be as similar to r/w as possible makes more sense
18:09:52 <nirik> mmaslano: I would suggest the feature owners. ;)
18:09:54 * notting is +1 to the feature
18:10:16 <mezcalero> mitr: btw, i think even for us in a normal server, it makes sense to provide read-only root easily
18:10:23 <mezcalero> mitr: for security purposes
18:10:36 <mezcalero> mitr: and we are very close to be able to provide that by default
18:11:01 <mezcalero> mitr: by making the root dir read-only you have a very simple way to "seal" off /etc from changes
18:11:04 <mezcalero> which is pretty cool
18:11:41 * mitr is -1 at this point
18:11:53 <mezcalero> surprise, surprise! ;-)
18:11:53 * pjones is +1
18:11:59 <mitr> IIRC that was limburgher +1, nirik+1, notting+1 , si that right?
18:12:00 * t8m is -1
18:12:06 * nirik nods.
18:12:06 <limburgher> Correct, +1
18:12:08 * mmaslano -1
18:12:21 <pjones> so right now we're at +4 -2
18:12:24 <mjg59> +1
18:12:35 <mmaslano> -3
18:12:48 <pjones> the feature appears to have passed.
18:12:52 <mitr> #agreed tmp-on-tmpfs is accepted (+5 -3)
18:12:54 <mezcalero> yay!
18:12:58 <mezcalero> thanks a lot!
18:13:03 <mitr> #topic #835 F18 Feature: GHC 7.4 - https://fedoraproject.org/wiki/Features/GHC74
18:13:03 <kay> can someone break down the votes by country? :)
18:13:06 <mjg59> +1
18:13:10 <mitr> .fesco 835
18:13:18 <zodbot> mitr: #835 (F18 Feature: GHC 7.4 - https://fedoraproject.org/wiki/Features/GHC74) – FESCo - https://fedorahosted.org/fesco/ticket/835
18:13:42 <nirik> +1, sure.
18:13:42 <notting> +1. can we keep the version always an inverse of the gcc version?
18:13:51 <limburgher> +1
18:13:56 <t8m> +1 why not
18:14:01 <mmaslano> +1
18:14:06 <nirik> it's the evil anti gcc. ;)
18:14:08 <pjones> +1
18:14:17 <mitr> +1
18:14:44 <limburgher> nirik:  If you pass your compiler flags backwards, it builds solitaire.exe
18:14:53 <nirik> ha
18:15:13 <mitr> #agreed GHC7.4 is accepted (+7 )
18:15:31 <mitr> #topic Next week's chair
18:15:50 <nirik> I've not done it in a while... I can.
18:16:07 <mjg59> I'm going to be on a plane that lands at 7AM local
18:16:09 <mmaslano> btw I might not be here
18:16:14 <mjg59> So I should be awake for the meeting, but if not...
18:16:21 <mitr> #action nirik will chair next meeting
18:16:26 <mitr> #topic Open Floor
18:16:29 <limburgher> I might not also, but I will if at all possible.
18:16:37 <t8m> I might not make the next week meeting
18:16:48 <notting> i definitely will not
18:17:00 <mjg59> Well maybe we should just skip a week?
18:17:05 <mitr> Seems so
18:17:06 <nirik> well, if we don't have quorum I guess it will be a short meeting. ;)
18:17:07 <t8m> mjg59, +1
18:17:53 <nirik> I'm fine either way. I should be around next week...
18:18:12 <pjones> +1 to skipping a week
18:18:32 <mitr> +1 to skipping a week, that makes 4
18:18:40 <limburgher> I'll show up if I can and if there's no meeting. . . I won't meet.
18:18:44 <mmaslano> +1 skip
18:18:47 <mitr> (if counting mjg59 is right)
18:19:01 <mjg59> +1
18:19:07 <mitr> #agreed the meeting on April 9 is canceled
18:19:28 <mitr> #topic Open Floor
18:19:58 <mitr> Anyone?
18:20:24 <limburgher> Not here.
18:20:35 * mitr will close in 2 minutes
18:20:37 * nirik has nothing.
18:22:03 <rbergeron> /win 3
18:22:26 <mitr> Thanks,e veryone!
18:22:28 <mitr> #endmeeting