17:00:54 #startmeeting FESCO (2012-04-02) 17:00:54 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:59 #meetingname fesco 17:00:59 The meeting name has been set to 'fesco' 17:01:02 hello. 17:01:02 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 17:01:02 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:06 #topic init process 17:01:11 * nirik is here 17:01:14 hi 17:01:46 * notting is here 17:02:02 * limburgher here 17:02:10 hello 17:02:12 Here 17:03:28 Is sgallagh comming? 17:04:51 I will be on a plane during next week's meeting. 17:04:55 OK, let's start. 17:05:02 #topic #830 define requirements for secondary arch promotion 17:05:04 .fesco 830 17:05:05 mitr: #830 (define requirements for secondary arch promotion) – FESCo - https://fedorahosted.org/fesco/ticket/830 17:05:31 Do we have a link to said wiki page? 17:05:46 http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 17:05:46 http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_(Draft) 17:06:13 both of those appear blank 17:06:23 First worked for em 17:06:24 me 17:06:26 notting: Looks ok here 17:06:29 notting: reload, they were blank once 17:06:40 ah, caching 17:06:43 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 Software is great 17:07:14 nirik: My thinking here was that once promotion has occured, everything should be working 17:07:33 nirik: So we want to make sure that it works on the Fedora infrastructure /before/ it becomes primary 17:07:40 Otherwise it stops building and everyone's updates stop flowing 17:07:50 Should we define what's required to get each PreReq step down, or is that later? 17:08:16 I'm not sure this needs to be made more detailed 17:08:28 what's the procedure for the arm team to propose changes to the draft? can we edit directly? 17:08:32 yeah. Might rephase that as "All builds must be ready to occur on Fedora-maintained build servers" ? 17:08:34 yeah, I think more details actually hurt the efficacy of the document. 17:08:44 Ok. 17:08:52 nirik: well, the thought is that we flip the build switch and make sure it's working /before/ declaring it primary 17:09:11 nirik: No, I really did intend to mean "All builds must be on Fedora-maintained build servers" 17:09:21 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 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 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 nirik: once it's primary, it's required for updates 17:09:45 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 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 bconoboy: Discuss on the list 17:10:42 mjg59: will you be the point man for all edits to the document then? IE, who is allowed to edit? 17:10:52 bconoboy: It's a wiki, anyone's allowed to edit 17:11:02 mjg59, pjones: Based on last week's discussion, the anaconda requirement might be too strict. I wouldn't know :) 17:11:06 bconoboy: But editing it without reaching some sort of rough consensus first would probably be a mistake 17:11:11 mjg59: yes, but if I edit it I could put something in that isn't agreed to 17:11:24 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 Yes, so don't do that :) 17:11:26 discuss on list -> consensus -> edit 17:11:31 Okay, so get consensus on list, then edit. Which list? 17:11:33 pjones: ok 17:11:41 bconoboy: devel@ 17:11:52 bconoboy: -devel is probably sensible, unless it's an issue that primarily affects one subteam? 17:11:57 how much consensus is needed? Some people will just say no, no matter what. 17:12:00 Kernel stuff would be fine discussed on -kernel, I think 17:12:15 bconoboy: If there's a point where people aren't reaching agreement then pushing it to fesco would probably make sense 17:12:22 okay, thanks 17:12:53 consensus also does not necessarily mean unanimous agreement ;) 17:12:55 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 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 pjones: :) 17:13:03 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 mjg59: right 17:13:42 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 And the live-media style install makes sense then 17:14:53 also the live-media style image creation 17:14:54 But where possible, it would be nice if there's as much overlap between image generation as possible 17:15:07 notting: yes 17:15:10 Because did you know that we have three different ways of generating x86 isos? 17:15:23 only 3? 17:15:23 I didn't 17:15:29 pjones: Well, three that we use? 17:15:34 netinst, live and dvd 17:15:47 yeah 17:15:49 Have I missed some? 17:15:59 Anyway, it's not fun having to fix things in all of them 17:16:07 proposal: wait a week for more discussion on list, vote on critera draft? 17:16:40 nirik, +1 17:16:41 nirik: +1 17:16:42 +1 17:16:46 +1 17:17:06 +1 17:17:09 +1 17:17:55 pjones: ? 17:18:01 +1 17:18:06 thanks 17:18:12 (though seriously, we don't need everybody to vote if it hits +5) 17:18:27 #agreed wait a week for more discussion on list, vote on critera draft 17:18:36 #topic #833 Remove provenpackagers access to libvirt related packages 17:18:41 .fesco 833 17:18:43 mitr: #833 (Remove provenpackagers access to libvirt related packages) – FESCo - https://fedorahosted.org/fesco/ticket/833 17:18:57 removing provenpackagers access seems like /entirely/ the wrong answer here 17:19:15 Especially if some of the problems are ascribed to secondary arch maintainers 17:19:29 I'm going to recuse myself here from voting, since I am involved. 17:19:30 right; they're not even using the same mechanism 17:19:32 Is the ticket filer here? 17:19:34 nirik: fair 17:19:49 --- [danpb] idle 08:44:08, signon: Mon Apr 2 04:35:34 17:20:04 Can't be that important, then 17:20:25 I guess there's a wider argument that we should talk about what to do if provenpackagers do behave inappropriately? 17:20:30 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 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 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 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 mitr, +1 17:21:32 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 so it's kind of hard to blame PPs 17:21:52 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 mjg59: 17:22:54 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 mjg59: I'm not sure, did anything go actually wrong here? 17:23:18 pjones: Indeed. 17:23:18 mitr: I don't think so, really 17:23:31 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 mitr: But I don't think we have a great policy for dealing with the case where something did go wrong 17:23:39 If anything, it should be cause for discussion. 17:23:42 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 mjg59: "solve it case by case" seems to scale fine right now... 17:23:56 mitr: Yeah, I've no problem with leaving it at that 17:23:57 mitr: indeed. 17:23:58 mitr: +1 17:24:04 So maybe we should just vote on this? 17:24:14 proposal: deny the request. 17:24:17 I think the expectation that Fedora will commit to shipping pristine upstream tarballs is just not reasonable. 17:24:20 nirik, it did not introduce a regression, it just did not fix the problem, right? 17:24:31 t8m: correct. 17:24:40 mitr, +1 17:24:40 +1 to proposal == -1 to request from me. 17:24:49 mitr: well, certainly not the expectation that we'll ship pristine upstream /spec files/ 17:24:53 and the update was unpushed... so it could easily be reverted if there was some issue. 17:25:07 +1 to deny the request 17:25:12 pjones: that especially 17:25:24 +1 to deny. 17:25:30 * pjones also +1 to deny, of course. 17:25:45 +1 to deny (weird phrasing, that is) 17:26:06 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 +1 to deny 17:26:55 0, they might have more problems than the last one, but they didn't mentioned them. 17:26:56 rbergeron mentioned my presence was desired 17:27:05 mmaslano: isn't that always true? 17:27:44 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 danpb: I guess you came too late ;-) 17:28:37 mmaslano: even good response time is sometimes too long to prevent a slip. 17:28:39 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 in our experience people have not even tried 17:28:59 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 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 s/change upstreams/make changes compared to upstream's tarball/ 17:29:32 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 nirik: email, irc as usual 17:30:18 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 danpb: "these things can be fixed directly in the devel branch of Git without contacting the individual maintainers"; 17:30:22 "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 #info Provenpackagers please try to contact the maintainers first (if possible) before you commit changes to a package. 17:30:53 mitr: IMHO, they should always contact the maintainer, no matter how small 17:31:39 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 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 nirik: well every Fedora packager has a registered email alias 17:33:10 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 danpb: Could you explain why the lack of this requirement causes you problems? 17:33:37 mjg59: we try very hard to maintain the exact same RPM spec file across multiple locations 17:33:50 danpb: We upstream or we fedora? Because the latter isn't true. 17:33:57 we usually have the exact same spec in upstream, RHEL, Fedora master & Fedora XXX 17:33:59 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 danpb: Right, but your upstream preferences aren't really something that we take into consideration in Fedora development 17:34:24 having people make unannounced changes to only 1 of those locations makes like more complicated 17:34:50 danpb: Making volunteers jump through extra hoops for the sake of upstream preferences isn't really the way we do things 17:35:02 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 danpb: It seems to me that maintaining a Fedora spec file in a different VCS is Just Wrong 17:35:36 mitr: i'm not going to get into a debate about that, in our experiance it is a clear win 17:35:36 mitr: or at least not syncing back from fedora before clobbering - but is that actually relevant to this discussion? 17:35:47 fair enough 17:36:00 danpb: do you have any specific problems which we can solve? 17:36:11 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 danpb: Your maintenance policy has to take into account Fedora policy, rather than vice-versa 17:36:30 danpb: for example announce to proven packagers or secondary arch maintainers, they should be more communicative? 17:36:34 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 could we vote on danpb proposal? 17:37:00 * nirik has no problem with that personally. More communication is good. 17:37:19 We could certainly modify the policy page to make that more obvious 17:37:21 mjg59: sure, i'm not asking for fedora to bend to my policy - just for a little more proactive communciation 17:37:38 which would have avoid most of this pain 17:37:40 danpb: I'd expect a loud comment at the top of the .spec file would help 17:37:48 mitr, +1 17:38:06 As for a general PP policy change, does anyone want to draft it? 17:38:28 I could 17:39:19 Sounds good to me 17:39:36 So, the ticket was rejected, mmaslano will suggest PP policy changes. Everyone fine with that? 17:39:47 #action mmaslano will draft provenpackager policy changes 17:40:03 moving on... 17:40:06 #topic #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs 17:40:10 .fesco 834 17:40:11 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 +1 from me. 17:40:48 +1 here as well. 17:40:51 I have questions 17:40:55 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 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 "My CD burning application writes huge .iso files to /tmp, and this breaks on tmpfs! 17:41:04 The application should be fixed to use /var/tmp." 17:41:06 == "My quite correct and working application is now broken" => "That is by design, go change it" 17:41:08 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 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 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 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 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 dude copy/paste into irc sucks 17:41:57 Right, I didn't have time to look at this last week, sorry. It would have been on the talk page 17:41:58 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 2-5 can be accepted, but without 1) - why? 17:42:34 mitr: there's at least 1 solid benefit - if /tmp is its own mountpoint, tmp races with hardlinks won't work. 17:42:58 mitr, there are actually four reasons we list not just one 17:43:12 and we want to limit the delta to read-only / to a minimum in the default setup 17:43:19 tmp will be automatically flushed at boot. 17:43:52 kay: breaking an unknown number of packages to avoid 5 lines specific to stateless? doesn't sound like a great bargain 17:44:13 stuff that breaks gets fixed 17:44:22 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 but only when we use it, otherwise it will be unknown 17:44:32 anything that expected /tmp to be persistent was already broken, was it not? 17:44:33 mitr: example, we made /tmp private by default for many system services 17:44:36 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 mitr: this also required fixing some of them 17:44:48 notting: This is mostly about things that expect /tmp to be large 17:45:44 you know, we totally know that this might break some apps 17:45:54 but instead of some nebulous "we are fearful it might break things" 17:45:58 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 we suggest to make the change in the devel distro 17:46:04 then watch, see what breaks 17:46:08 fix it if we can 17:46:12 or revert if necessary 17:46:23 only then we know for *sure* what actually breaks 17:46:23 mezcalero: That will get you a distribution where you know that something is probably broken, but you don't know what. 17:46:36 mmaslano: sure, we will fix whatever needs fixing, that's the idea 17:46:41 mezcalero: how? 17:46:43 mmaslano: also see the tracker bug we suggested for that 17:46:50 mezcalero: do you put files into /var/tmp or where? 17:46:55 mitr: and once again, isn't that always true? 17:46:56 mmaslano: the way we usually do this: prep a patch and ask for inclusion 17:47:04 mmaslano: yes 17:47:09 hm. by the fhs standard we could have per-PID /tmp. that could be entertaining. 17:47:20 mezcalero: one might say it's not good path 17:47:33 mmaslano: why not? 17:47:34 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 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 (also, there's a dirty interim fix for various apps, i.e. set TMPDIR) 17:47:59 t8m: there is a proposal 17:48:10 And even if we _did_ fix all of them, is there the benefit? That's still my main problem with this. 17:48:15 t8m: please refer to the feature page, will find a link there to this: http://0pointer.de/blog/projects/tmp.html 17:48:32 t8m: On-disk tmp continues to be provided by /var/tmp 17:48:38 OK 17:48:39 you know, we are really not on our own with this 17:48:44 this is not where we are pioneering 17:48:49 mitr: Yes, there are benefits 17:48:53 this is simply where we are following, debian and commercial unixes 17:49:01 and ubuntu is doing this too 17:49:16 this is not an isolated effort 17:49:21 mitr: It reduces disk thrash for files which are purely temporary intermediates. It prevents some set of security attacks. 17:49:28 i personally run that for many years on all of my boxes with an entry in fstab 17:49:35 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 a lot of work is going into this from many sides of the linux ecosystem 17:49:50 just like solaris has from the beginning ... 17:49:52 mjg59: With ext4 delayed allocation, is that noticeable? 17:49:58 kay: do you scan huge files? build libreoffice or run oracle? 17:50:01 t8m: well, about 90% of all files are not actually "huge" 17:50:15 mitr: If the intermediate lies around long enough to be hit by the writeout thread, yes 17:50:17 t8m: I don't think there's any reason to believe that'll happen 17:50:23 mezcalero: I have seen tickets filed. I haven't seen many tickets closed - if anything, I have seend Debian maintainer resistance. 17:50:28 t8m: the candidates are well known, that's mozilla's downloads, gcc's linking and a small number of others 17:50:41 mitr: yet, the change has been made in debian already 17:50:46 mitr: yes, people resist 17:50:47 mjg59: Looking at my /tmp, I can't really see that this is worth anybody's time 17:51:09 mitr: but the slightest opposition is not reason to already give up 17:51:17 mitr, heh, this was non-argument for other changes :D (although I agree with you) 17:51:21 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 (Note that sockets use in /tmp does not update any file times, so it does not hit the disk) 17:52:02 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 mmaslano: in /var/tmp like they are required to use on solaris 17:52:34 mmaslano: there are guidelines on the above-referenced blog post. i'm sure they could be put into the feature documentation 17:52:44 mmaslano: hence i would not expect oracle to fail over /tmp 17:52:53 kay: that was only one of examples 17:53:21 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 mmaslano: yeah, stuff will get fixed as needed. it's pretty simple. but we need to know 17:53:27 mezcalero: Random google find: "/tmp/OraInstall2012-03-28_09-48-46AM/jdk/jre/bin/java" 17:53:40 kay: ^^ 17:54:10 so what you're saying is that orainstall is terrible software? 17:54:20 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 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 kay: And what will stateless boots do about /var/tmp ? 17:55:44 mezcalero: (been there, tried that wrt crypto) 17:55:49 mitr: it's tmpfs unless you did something else 17:55:51 mitr: read only / nothing, stateless probably a tmpfs too. i mean read only / in the snetence above 17:55:55 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 /var/tmp is required to be stateful 17:56:04 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 mitr: the same as with /var 17:56:32 limburgher: or have enough ram or swap :) 17:56:45 mitr: it needs to be persistant, the same way /var needs to be persistant 17:56:48 limburgher: or at least not on machines with too little ram to untar a jre into it 17:57:22 limburgher: Solaris might have a different installer, I wouldn't know. 17:57:26 kay, pjones: I can't imagine either of those is case for very many people. 17:57:55 mitr: Good point. How about Debian? 17:58:12 limburgher: I take Debian as unknown right now. 17:58:13 * nirik notes 18minutes on this topic so far. ;) 17:58:22 mitr: you let yourself be held hostage by another company, based on a nebulous fear of yours 17:58:40 mitr: i'd like to turn this into hard data 17:58:45 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 i.e. let's find out what breaks 17:58:49 and we can revert 17:58:50 mezcalero, I hope you understand that Oracle was just an example 17:58:59 mitr: you already give up before trying 17:59:01 's nothing to make me want this. How faster will the system be? 17:59:17 mitr: 42%! 17:59:21 mezcalero: hard data would be good - but before spending the man-weeks 17:59:52 mitr: yeah, so let's turn it on in the devel distro 17:59:55 mezcalero: care to address the "1 month to find out what would break"? 17:59:57 mitr: then collect hard data of any kind 18:00:41 mitr: and revert if it turns out to bring nothing but the most horrendous pain mitr can think of 18:00:45 "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 mitr: do you have these bugs handy? 18:02:25 mezcalero: do you have some bug tracker already? 18:02:43 mmaslano: nope, will set a tracker bug up when we have an OK for enabling it 18:03:02 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 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 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 we could also go dig thru debian bugs and check against our versions of those packages... 18:03:36 same here, works for me since years 18:04:14 * nirik waits for that bug to load. slooooow. 18:04:14 same here 18:04:36 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 mitr: we listed 4 for you 18:05:10 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 nirik: maintainer intransigence. *shock* 18:05:51 so, it's 'sort' of files larger than memory? 18:06:18 nirik: the initscripts list has more relevant examples, just took me longer to get a link 18:06:42 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 tmpfs is backed by swap, so it can be larger than memory 18:07:07 mjg59's "/tmp on a separate FS" is somewhat compelling 18:07:14 tmpfs is fully swapable :) 18:07:20 brunowolff: but if it overflows swap, the system is totally killed. 18:08:30 nirik: Given that the default install is/long was a single huge / partition... 18:08:46 mitr: dude, by default it has a limit of half RAM 18:08:53 mitr: we can lower that even 18:08:59 mitr: debian does 30% of RAM by default 18:09:09 which value we pick doesn't really matter 18:09:18 but there's always an implicit value picked 18:09:23 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 mezcalero: and 4 other tmpfs systems are already mounted on F16. 18:09:33 nirik: who will do it? 18:09:35 * nirik notes we are now at 30min on this topic. 18:09:37 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 mmaslano: I would suggest the feature owners. ;) 18:09:54 * notting is +1 to the feature 18:10:16 mitr: btw, i think even for us in a normal server, it makes sense to provide read-only root easily 18:10:23 mitr: for security purposes 18:10:36 mitr: and we are very close to be able to provide that by default 18:11:01 mitr: by making the root dir read-only you have a very simple way to "seal" off /etc from changes 18:11:04 which is pretty cool 18:11:41 * mitr is -1 at this point 18:11:53 surprise, surprise! ;-) 18:11:53 * pjones is +1 18:11:59 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 Correct, +1 18:12:08 * mmaslano -1 18:12:21 so right now we're at +4 -2 18:12:24 +1 18:12:35 -3 18:12:48 the feature appears to have passed. 18:12:52 #agreed tmp-on-tmpfs is accepted (+5 -3) 18:12:54 yay! 18:12:58 thanks a lot! 18:13:03 #topic #835 F18 Feature: GHC 7.4 - https://fedoraproject.org/wiki/Features/GHC74 18:13:03 can someone break down the votes by country? :) 18:13:06 +1 18:13:10 .fesco 835 18:13:18 mitr: #835 (F18 Feature: GHC 7.4 - https://fedoraproject.org/wiki/Features/GHC74) – FESCo - https://fedorahosted.org/fesco/ticket/835 18:13:42 +1, sure. 18:13:42 +1. can we keep the version always an inverse of the gcc version? 18:13:51 +1 18:13:56 +1 why not 18:14:01 +1 18:14:06 it's the evil anti gcc. ;) 18:14:08 +1 18:14:17 +1 18:14:44 nirik: If you pass your compiler flags backwards, it builds solitaire.exe 18:14:53 ha 18:15:13 #agreed GHC7.4 is accepted (+7 ) 18:15:31 #topic Next week's chair 18:15:50 I've not done it in a while... I can. 18:16:07 I'm going to be on a plane that lands at 7AM local 18:16:09 btw I might not be here 18:16:14 So I should be awake for the meeting, but if not... 18:16:21 #action nirik will chair next meeting 18:16:26 #topic Open Floor 18:16:29 I might not also, but I will if at all possible. 18:16:37 I might not make the next week meeting 18:16:48 i definitely will not 18:17:00 Well maybe we should just skip a week? 18:17:05 Seems so 18:17:06 well, if we don't have quorum I guess it will be a short meeting. ;) 18:17:07 mjg59, +1 18:17:53 I'm fine either way. I should be around next week... 18:18:12 +1 to skipping a week 18:18:32 +1 to skipping a week, that makes 4 18:18:40 I'll show up if I can and if there's no meeting. . . I won't meet. 18:18:44 +1 skip 18:18:47 (if counting mjg59 is right) 18:19:01 +1 18:19:07 #agreed the meeting on April 9 is canceled 18:19:28 #topic Open Floor 18:19:58 Anyone? 18:20:24 Not here. 18:20:35 * mitr will close in 2 minutes 18:20:37 * nirik has nothing. 18:22:03 /win 3 18:22:26 Thanks,e veryone! 18:22:28 #endmeeting