19:07:20 <ennael> #startmeeting 19:07:20 <Inigo_Montoya> Meeting started Mon Jul 23 19:07:20 2012 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:07:20 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:07:44 <ennael> ok hi all 19:07:53 <MrsB> hiya 19:08:20 <ennael> as a reminder before starting 19:08:21 <ennael> https://wiki.mageia.org/en/Absent 19:08:30 <ennael> you can add your name here 19:09:20 <ennael> this may help people in some cases 19:09:49 <ennael> #topic blog posts 19:10:31 <ennael> ok so as a reminder here is the page to propose blog posts https://wiki.mageia.org/en/Blog_articles_planning 19:11:22 <ennael> so next one is about features. I should start it in a notepad and then ask for comments 19:12:16 <ennael> if you have any idea please feel free to add some in list 19:13:25 <ennael> outch are you all dead ? 19:13:38 * MrsB was adding they make Mageia ennael 19:13:51 <DavidWHodgins> Just have no ideas for blog posts for now. 19:13:57 * ennael is not responsible and leaving country very fast 19:14:32 <Max__> There was a brief thread in -atelier ML, but it died with little results. 19:14:47 <JohnR> ennael: s/outch/ouch remember :-) 19:14:55 <ennael> DavidWHodgins: what about writting something like "updates for dummies" ? 19:15:08 <ennael> would be nice to explain the real work behind mgaapplet 19:15:21 <Max__> Step 1: watch mgaaplet. Step 2: click update. 19:15:29 <MrsB> a tech series might be a nice idea 19:15:35 <DavidWHodgins> I'll think about it. 19:15:36 <ennael> I mean behind the curtains 19:15:54 <ennael> I plan to make one about isos release 19:15:57 <DavidWHodgins> It'll be a lot simpler once 2317 is done. 19:16:22 <leuhmanu> that will not change in mga3 (the updates) 19:16:22 <ennael> it's good to explain how much complex things are so that people understand why it takes times and resources 19:16:41 <ennael> ok 2317 topic is later :) 19:16:47 <leuhmanu> ah updates vs upgrades /me should go sleeping.. 19:16:53 <ennael> I plan to make one about isos release:) 19:16:54 <MrsB> we can do one on qa testing isos before the alpha 19:16:56 <ennael> argh 19:17:09 <ennael> just add your ideas 19:17:27 <MrsB> yeah, we need to decide how we're doing it yet tho 19:17:31 <ennael> please add also your name in front so that we know who we have to ping to plan all this 19:17:39 <MrsB> (the testing i mean) 19:19:18 <ennael> ok next topic 19:19:31 <ennael> #topic Mageia 3 features 19:19:37 <ennael> this is just a reminder 19:20:06 <ennael> https://wiki.mageia.org/en/FeatureMageia3_Review 19:20:40 <ennael> it was explained during last packagers meeting where QA was also attending 19:20:47 <ennael> we have now 4 sections in this page 19:21:02 <ennael> the one all complete and so accepted 19:21:09 <ennael> the one missing resources 19:21:21 <ennael> the one needing more information 19:21:26 <ennael> and finally the one refused 19:21:52 <ennael> features can move from one section to another if information are added for this 19:22:23 <ennael> provided it can be implemented during alpha stages of development 19:22:49 <ennael> (I speak too much) 19:22:55 <ennael> questions ? comments ? 19:23:17 <MrsB> none here 19:23:18 <DavidWHodgins> Nope. 19:23:53 <ennael> #topic Working on teams review 19:24:00 <ennael> ok next quick topic 19:24:06 <ennael> can we fix a deadline for this 19:24:07 <ennael> ? 19:24:13 <MrsB> what is it? 19:24:31 <ennael> a global report as we made during general assembly 19:24:41 <MrsB> ahh ok 19:24:52 <ennael> each team gives big facts happening since february 19:25:09 <MrsB> that should be easy! 19:25:27 <leuhmanu> too easy ? :D 19:25:46 <ennael> well vacation coming so what about having all reports for 20/08 19:25:55 <ennael> no need to be sarcastic 19:26:00 <MrsB> deadline is ok for me, do you want it emailed or on the wiki somewhere or on ML etc? 19:26:12 <ennael> mmm maybe on council ML first 19:26:23 <ennael> and we will put it all together in pad or wiki 19:26:35 <MrsB> ok np 19:26:46 <ennael> #action deadline for teams review is 20/08 19:27:23 <ennael> ok 19:27:51 <ennael> #topic communication over the years with some developers in relation to EN string corrections 19:27:56 <ennael> JohnR: your turn then :) 19:29:17 <JohnR> This is a little difficult :-) We seems (on docteam) to have a little difficulty persuading tv to help us with string fixes 19:30:16 <ennael> can you give concrete example ? 19:30:29 <JohnR> For me, it's a historical problem which goes back many years, so I don't want to over emphasize it into a personality conflict :-) 19:30:46 <ennael> not speaking about people :) 19:30:54 <ennael> but example of string 19:31:56 <JohnR> NMain example is to fix EN strings in rpmdrake "Softwares Packages" It should be "Software packages) because software is already plural - there are other bad strings in the utility as well. 19:32:43 <ennael> what is the reason for reverting this? 19:32:45 <JohnR> I've spent a many hours with misc in May 2001 fixing these strings which were promptly reverted - how to resolve this one? 19:33:35 <ennael> what was the reason for reverting these commits ? 19:33:37 <JohnR> I didn't get a response, but misc said it was because "It would be too much work for the translators" 19:33:53 <ennael> humpf 19:33:56 <ennael> ok 19:33:59 <tmb> JohnR was the fixes done in perl code or in .pot files ? 19:34:14 <JohnR> These bad strings have been there since way back - 2003 or so 19:34:34 <JohnR> tmb in the code, the en strings are hard-coded 19:34:54 <JohnR> tmb: other languages are in .pot 19:34:58 <MrsB> en_US i guess /o\ 19:35:07 * ennael slaps MrsB :) 19:35:22 <JohnR> MrsB: yes, but that variety of en isn't important 19:35:25 <tmb> JohnR: I know that, I just wanted to be sure what we are talking about :) 19:35:39 <JohnR> tmb: ok :-) 19:35:46 <ennael> JohnR: I don't see any pb as it's made in the beginning of release 19:35:55 <ennael> translators have lots of time to fix this 19:36:12 <Stormi> yes, I guess may 2011 was not a good time for it, so close from Mageia 1 19:36:30 <JohnR> ennael: nor do I, My experience says it's probably less thaan a hours for each language 19:36:33 <ennael> well such modifications cannot be done near release 19:36:47 <ennael> JohnR: yes but looking for all translators can take time 19:37:02 <JohnR> ennael: yes, understood 19:37:22 <ennael> so I guess we can apply this again and mail i18n on this 19:37:40 <JohnR> ennael: That would be good 19:37:47 <JohnR> @nd part 19:37:52 <JohnR> 2nd .. 19:37:55 <MrsB> I can volunteer an en_GB translation if it helps. I subscribed to the i18n ML's today. Not sure how yet though. 19:38:31 <JohnR> MrsB: there's no need for en_GB - it's simply spelling and sentance reconstruction 19:38:46 <MrsB> hmm thats not really so though 19:38:51 <Max__> Clearly somebody hasn't read his mail recently. 19:39:12 <ennael> #action JohnR will apply now some fixes on spelling and mail i18n so that it can be translated on time 19:39:31 <ennael> JohnR: 2d part ? 19:39:40 <JohnR> ennael: ok will do, except - I'm not a coder :-(( 19:40:01 <ennael> ok I can give a hand 19:40:28 <ennael> #info ennael will help on this 19:41:40 <JohnR> @nd part, unfortunately similar problem: Doc teams needed to know where anchors were for drakx-installer, dev was asked to assist - no response, We starting to doc the drak tools, we need coperation from the primary dev for similar anchors .... 19:42:04 <ennael> do you have a list of needed one ? 19:42:16 * JohnR is tired - typing is rubbish - sorry ... 19:42:23 <ennael> no pb 19:42:44 <JohnR> ennael: no not as yet, I would like to forestall a problem if possible 19:42:58 <ennael> forestall ? 19:43:11 <DavidWHodgins> forestall == prevent 19:43:12 <ennael> oh ok 19:43:13 <MrsB> prevent one in the future 19:43:14 <JohnR> stop it before it starts :-) 19:43:32 <ennael> so what do you need exactly ? 19:44:14 <JohnR> One again it's a hard-coded string issue as far as I can see and there are eighty-eight utilities with drak in their names :-))))) 19:44:36 <ennael> so you need a complete list of anchors ? 19:44:47 <ennael> (sorry I may be tired also :) ) 19:44:48 <JohnR> ennael: basically yes 19:45:22 <ennael> ok :) 19:45:49 <JohnR> Is this a request which should be pointed at -dev list - we (docteam) need advose 19:45:58 <ennael> yep sure 19:46:14 <ennael> tv knows installer but some other guys also 19:47:18 <JohnR> ennael: It's pretty much the entire MCC suite and possibly a lot of other "inhouse" tools 19:47:30 <ennael> can you mail -dev on this, I will follow this also and ping guys if no answer 19:47:45 <JohnR> ennael: ok 19:47:55 <ennael> thanks 19:48:24 <JohnR> I'm done 19:48:35 <ennael> #action JohnR will mail -dev to ask for a list of anchors in all drakx* so that docteam can work on doc for these tools 19:48:46 <ennael> thanks for attending early meeting :) 19:49:03 <JohnR> 25 hours and counting :-) 19:49:11 <ennael> :) 19:49:19 <MrsB> beddyboes time JohnR 19:49:21 <ennael> can we switch to next topic ? 19:49:42 <JohnR> go 19:49:48 <ennael> ok 19:50:02 <ennael> the bloody hurting killing one 19:50:16 <ennael> #topic Solve bug #2317 19:50:18 * MrsB has no idea 19:52:25 <coincoin> blino: please sweety <3 19:53:29 <blino> salut les filles 19:53:40 <ennael> in english please :) 19:54:17 <ennael> ok guys now we need to find a solution 19:54:48 <ennael> this is an endless story and it looks like it needs some decision or we will never solve it 19:55:30 <ennael> a solution has been proposed now we need to move on 19:55:54 <ennael> I asked blino to be around as he knows that part also 19:57:23 <blino> did you get tv's opinion on this? 19:57:50 <ennael> yes basically too hard to be implemented or no time and pb with speed 19:58:25 <ennael> https://bugs.mageia.org/show_bug.cgi?id=2317#c6 19:59:14 <ennael> on the other had current situation has to be solved 19:59:36 <blino> yes, but now we have a patch proposal 19:59:49 <ennael> yes we have 20:00:15 <ennael> but it seems some people here do not agree on behaviour 20:00:26 <blino> and I think we all agree that the full media set from network should be configured by default when adding update, and that we should never have updates media alone 20:00:42 <ennael> I think so 20:00:48 <DavidWHodgins> Agreed. 20:00:50 <ennael> (people, please speak now or never) 20:00:52 <MrsB> yep 20:00:52 <tmb> yep 20:02:44 <ennael> so ? 20:03:17 <blino> so, we still need a patch for the installer 20:03:59 <ennael> wait it seems current patch does not satisfy everybody due to backports management 20:04:10 <Stormi> (and 3rd party) 20:04:15 <ennael> I would like us to solve this and move on 20:05:10 <ennael> guys please if nobody speaks we are going nowhere 20:05:29 <MrsB> what are the issues with the current patch? 20:06:03 <Stormi> it pulls dependencies from any active media, be it backports or a 3rd party media 20:06:18 <MrsB> even if they are disabled? 20:06:22 <DavidWHodgins> I don't see that as a problem. 20:06:23 <ennael> no 20:06:28 <Stormi> no, only activated 20:06:31 <ennael> on my side this is not a pb. 20:06:44 <ennael> if people do activate a media it's at their own "risks" 20:06:57 <ennael> we cannot prevent everything that could happen 20:07:00 <tmb> well, I dont think the behaviour should change in MageiaUpdate (meaning it should still match the way it work now with linking) 20:07:34 <DavidWHodgins> If the applet doesn't change, the problem 2317 causes doesn't go away. 20:07:34 <blino> ennael: but that's not what we meant by backports in Mandriva, backports were cherry-picked in the interface, but not pulled or updated by default from deps of other packages 20:08:13 <blino> this allows to have a selective control of which backports are installed 20:08:19 <ennael> Mandriva not Mageia 20:08:24 <boklm> blino: rpmdrake can cherrypick backports from disabled backports media 20:08:32 <ennael> what is decided in Mageia ? 20:09:00 <MrsB> I see tmb's last comment on the bug, that could be a potential problem. If mgaapplet ran while somebody was selecting a backport it would report incorrect updates. If I'm understanding correctly. 20:09:09 <DavidWHodgins> We can warn people of change from Mandriva behaviour, when we announce backports opening. 20:09:17 <tmb> DavidWHodgins: I mean the behaviour should match... (linked packages from release -> updates vs pulling deps from release if updates is not selfcontained) 20:09:49 <Stormi> I guess the option to flag release media as updates media is not envisioned? (would allow to keep the same behaviour, but at a performance cost) 20:10:08 <Stormi> and solves the "after an upgrade I still have packages to update from release media" 20:10:24 <Stormi> ( DavidWHodgins should know what i'm talking about ) 20:10:25 <DavidWHodgins> My testing shows no performance hit, but we don't yet have a patch to do that. 20:10:34 <blino> boklm: but disabled media are not updated (I mean hdlists) automatically 20:11:17 <Stormi> after you upgrade your system, MageiaUpdate currently doesn't know it can upgrade old mga1 packages with those in release media, because of the missing update flag 20:11:27 <Stormi> adding the update flag solves both this and bug 2317 20:11:30 <boklm> blino: that could be changed in a separate update to add support for backports medias in rpmdrake/urpmi 20:12:41 <DavidWHodgins> I'm ok with either solution, as long as it gets done real soon. 20:13:11 <MrsB> it isn't the updates themselves which are the problem it is added requires which mean it must look in other medias. It's also requires of added suggests. 20:13:26 <MrsB> recursive 20:14:13 <boklm> blino: we could flag backports medias as backports and automatically update hdlists for medias flagged as backports, while keeping them disabled 20:16:01 <ennael> blino: wdyt ? 20:16:55 <tmb> boklm: wont that be the same problem as current media.cfg already have "update_for" flag, that we dont use either... 20:17:19 <boklm> tmb: that's not the same as update_for 20:18:41 <boklm> backports keyword could have some clear meaning 20:18:45 <blino> boklm: how would we disable them totally then? 20:18:58 <boklm> blino: removing backports flag 20:19:08 <blino> anyway, this can be handled separately 20:19:16 <blino> boklm: that's not a consistent behavior :/ 20:19:18 <tmb> - this info is only available in media.cfg, and not everybody is using 20:19:18 <tmb> media.cfg to add their medias 20:19:32 <tmb> boklm: I mean the comment in https://bugs.mageia.org/show_bug.cgi?id=2317#c67 20:19:43 <boklm> tmb: I'm talking about adding backports keyword to urpmi.cfg 20:20:13 <tmb> boklm: ok 20:20:45 <tmb> but that is still read from media.cfg at media add time ... 20:20:46 <boklm> but keeping backports media enabled is a wrong solution anyway, because urpmi and rpmdrake are pulling from all active medias 20:21:42 * Stormi thought of --use-backports switch for urpmi but that's OT 20:22:12 <boklm> tmb: yes, read it from media.cfg when adding medias, and add it in urpmi.cfg 20:23:01 <tmb> boklm: but then the "updates_for" could be used likevise during media add... 20:23:02 <boklm> Stormi: we could have --backport option, like the --update option, as a shortcut for --seachmedia 'backports medias' 20:23:33 <Stormi> anyway, aren't we going a bit too far from bug 2317 here? 20:23:43 <boklm> tmb: for handling dependencies between medias ? 20:24:03 <ennael> Stormi: nope if can find a solution at least agree on the way to solve it let's take time for it 20:25:05 <tmb> boklm: well, isn't that the idea with that flag to suggest it should search for deps ? 20:26:25 <boklm> I think handling dependencies between medias would be more complexe 20:29:13 <ennael> how can we move on this? boklm, can you propose a scheme to solve this and maybe some code for it? 20:30:41 <boklm> I think we should fix MageiaUpdate by pulling deps from all active medias, say that backports medias should be kept disabled, and improve backports support later by adding backports keyword to urpmi.cfg and media.cfg 20:31:19 <ennael> comments on this ? 20:31:39 <MrsB> it solves the immediate problem, does it create one for later? 20:32:14 <DavidWHodgins> I'm fine with the idea. 20:32:36 <ennael> MrsB: well the pb is quite complex and we have priorities to manage 20:33:05 <ennael> it may not be perfect but at least we start solving it using 2 or 3 steps for it 20:33:08 <MrsB> yes, anything which solves it now is good. We can deal with any bugs as they arise. 20:33:41 <MrsB> can we commit to not just forget about this though if we do find problems? 20:33:42 <tmb> if we ignore 3rdparty repos (wich people use at their own risk anyway), could we block backports media by default even if it would happend to be enabled (maybe a config/menu option to remove blocking) 20:34:41 <tmb> (I mean block it in mageiaupdate) 20:34:45 <DavidWHodgins> I don't consider pulling deps from backports (if enabled) to be a problem. 20:35:42 <tmb> DavidWHodgins: well, it means it will be pulling combos QA is not testing/validating, and will pull full backports for users not planning it... 20:36:12 <tmb> I'd like some way to minimize potential damage... 20:36:14 <DavidWHodgins> Only if they leave backports enabled. We can tell them "Don't do that". 20:36:53 <MrsB> what would happen if mgaapplet updated hdlists whilst bp were briefly enabled? 20:36:55 <boklm> we can add a warning to prevent enabling backports 20:37:17 <MrsB> Also, does this allow for nonfree BP's having free BP deps? 20:37:17 <tmb> DavidWHodgins: well we are back to the "MageiaUpdate happends to run when they temporarily enable backports" 20:37:37 <boklm> tmb: they will have the same damage if instead of using MageiaUpdate, they use rpmdrake or urpmi to install a package 20:37:47 <DavidWHodgins> We can warn users not to run the "install updates", while backports are enabled. 20:38:32 <boklm> and we can change rpmdrake to update hdlists for backports automatically, so there is no reason to enable backports media 20:38:51 <MrsB> does this allow for nonfree BP's having free BP deps? 20:39:07 <MrsB> or tainted 20:39:23 <tmb> boklm: well, using rpmdrake & urpmi is "out of scope" of the MageiaUpdate applet, wich is meant to make sure it will install stuff coming through /updates only 20:40:23 <boklm> tmb: but they will have the same problem when using rpmdrake & urpmi, so they should not enable backports 20:40:24 <tmb> I mean endusers expect MageiaUpdate to deliver safe updates as it always has... 20:40:45 <DavidWHodgins> Also, some users will want to treat backports as an updates repository, so if a new version of firefox shows up, mgaapplet should install it. 20:41:16 <ennael> so back to boklm proposal 20:41:17 <ennael> 22:30 < boklm> I think we should fix MageiaUpdate by pulling deps from all active medias, say that backports medias should be kept disabled, and improve backports support later by adding backports keyword to urpmi.cfg and media.cfg 20:41:23 <ennael> so 2 steps 20:41:23 <MrsB> does this allow for nonfree BP's having free BP deps? 20:41:37 <ennael> what about adding a warning for now when backports are enabled ? 20:41:58 <DavidWHodgins> With a "don't show me again switch". 20:42:07 <ennael> sure 20:43:12 <boklm> we can add a warning in media manager when someone activate a backports media 20:43:19 * MrsB is invisible 20:44:01 <tmb> MrsB: yep 20:44:13 <MrsB> thankyou tmb 20:44:37 <boklm> we can also list disabled backports medias in the "Update media" menu so they can update them easily 20:44:38 <ennael> oups 20:47:57 <ennael> ping * 20:48:11 <ennael> more comments? suggestions? 20:49:24 <MrsB> none here, only to say thankyou on behalf of QA team for fixing this bug which has made QA difficult for so long 20:49:47 <ennael> boklm: are you ok to work on this? 20:49:55 <boklm> ok 20:50:05 <ennael> great 20:50:08 <boklm> ok for doing this: 20:50:16 <DavidWHodgins> Which solution will be done? 20:50:44 <boklm> - update MageiaUpdate to pull deps from all active medias 20:50:51 <boklm> - add warning when enabling backports media 20:51:19 <boklm> - add disabled backport medias is the "update media" menu in rpmdrake so they can be updated easily even when disabled 20:52:02 <DavidWHodgins> Any timeframe? :-) 20:52:05 <boklm> - later: add support for backports keyword in urpmi.cfg and media.cfg to flag backports medias, and automatically update hdlists for backports 20:52:30 <boklm> first 3 items can be done quickly 20:52:38 <MrsB> this is great news 20:53:10 <DavidWHodgins> tmb: Are you ok with this? 20:53:18 <MrsB> we mustn't forget the installer too 20:55:28 <ennael> boklm: maybe we could add this as a feature ? with all these steps 20:56:04 <DavidWHodgins> I think the installer should be changed to do a full "urpmi --auto-select", after adding the online media. 20:56:05 <boklm> first 3 items can be done as an update for mageia 2, maybe the last one would be for mageia 3 20:56:17 <ennael> ok 20:56:41 <tmb> Well, I must honestly say I dont really like the idea of unleashing MageiaUpdate on all active medias out of quality concerns and breakages that will follow, but seems everyone else wants it, so I wont stand in the way... 20:57:44 <ennael> one thing we can think about it is 3 first items will be implemented quickly 20:57:51 <boklm> tmb: you think a warning when enabling backports media is not enough ? 20:57:57 <ennael> backports will be open soon 20:58:11 <ennael> and it should not grow that much as they need also to be tested 20:58:22 <ennael> so it leaves some time for 4th item 20:58:58 <ennael> it may not be all perfect but it's a way to find a solution 20:59:06 <ennael> well imho of course :) 20:59:12 <Stormi> tmb: I agree with you but it seems too that the common direction is towards what was decide 20:59:22 <boklm> tmb: if warning is not enough, we can disable enabling backports in gui, and tell people to use urpmi.update --no-ignore if they really want to enable backport medias 20:59:24 <tmb> boklm: well "the ordinary enduser" only click ok on popuos without reading... 21:00:21 <DavidWHodgins> I think the risk of pulling dependencies from backports, is less risky than qa possibly missing a 2317 dep, like happened a few days ago with libreoffice. 21:00:44 <DavidWHodgins> That really confused my non-tech users. 21:01:13 <MrsB> it may see it in backports when mgaapplet updated but wouldn't it actually install from Release when they are disabled again? 21:03:28 <tmb> MrsB: that need to be tested.. as mgaapplet has run it knows new rpms and their location... 21:03:40 <boklm> most people should not need to enable backports media, so this could be disabled from gui, if we think people will click ok without reading 21:04:03 <tmb> MrsB: so it would take until nexy mgaapplet run to remove the rpms in backports from the list of updates 21:04:10 <tmb> next* 21:04:30 <MrsB> Is that true though or does it just know the package name as a dependency? 21:05:17 <tmb> We had a similar bug some years ago in mdv where rpmdrake installed rpm from disabled media since it knew about them... 21:05:55 <tmb> and mgaapplet has not been tested in this scenario, so we must test that wey thoroughly 21:07:14 <MrsB> I'd hate for us at this stage to call it fixed only to have to work around the fix as that would defeat the object of doing it. If this method creates new issues for us to work around then it's not the right fix. 21:07:47 <tmb> But I guess to get on with this problem, we need the suggested fixes coded so we can start testing.... 21:07:51 <boklm> what new issues ? 21:08:07 <ennael> is QA ok to work on testing ? :) 21:08:16 <MrsB> Yes absolutely. 21:08:19 <DavidWHodgins> Yes! 21:08:42 <MrsB> can we create a dummy package to test it with? 21:08:47 <tmb> we just need to put some newer packages in backports to test the deps 21:08:54 <ennael> yep 21:09:05 <DavidWHodgins> Easy to create dummy backport repository locally. 21:09:33 <DavidWHodgins> Then test mgaapplet with/without it enabled. 21:09:47 <MrsB> it'll need a package with added deps and ideally one with added suggests which have deps 21:10:14 <DavidWHodgins> Easy to set up using rpm -e --nodeps on existing dependency. 21:10:30 <ennael> boklm: can you open a wiki page on this 21:10:36 <boklm> ok 21:10:39 <ennael> then test process can be added also 21:10:44 <DavidWHodgins> I.E. Treat existing dep as a new dep, for testing. 21:10:49 <MrsB> we can work on a procedure for testing 21:11:36 <DavidWHodgins> I'm clear on the testing needed, and will write procedure. 21:11:42 <ennael> when it's all ready and tests are done we can speak again together, review all this 21:11:42 <MrsB> great :) 21:11:49 <ennael> and take decision about pushing it or not 21:11:52 <ennael> is that ok ? 21:11:59 <DavidWHodgins> Fine with me. 21:12:02 <MrsB> more than ok yes 21:12:06 <boklm> ok 21:12:10 <tmb> yep 21:12:17 <ennael> thanks boklm for taking it anyway 21:12:42 <ennael> and let's hope we are on the good way to have this fixed 21:12:50 <MrsB> thankyou guys 21:13:11 <ennael> I will add meeting logs url in the bug report 21:13:20 <tmb> boklm: btw, I think the update should ship with a README.update.uprmi to notify all users 21:13:31 <boklm> tmb: ok 21:13:44 <ennael> anything else to add on this ? 21:14:00 <DavidWHodgins> Not here. 21:14:04 <tmb> nope 21:14:09 <boklm> not for me 21:14:49 <ennael> ok... long last topic but hopefully constructive one 21:14:53 <ennael> thanks all for attending 21:15:12 <MrsB> thankyou ennael 21:15:12 <DavidWHodgins> Thanks everyone. It'll be nice to finally close 2317! 21:15:16 <ennael> #endmeeting