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