19:08:55 <boklm> #startmeeting 19:08:55 <Inigo_Montoya> Meeting started Wed Jul 4 19:08:55 2012 UTC. The chair is boklm. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:08:55 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:08:56 <erzulie> [ MeetBot - Debian Wiki ] 19:09:00 <AL13N> (anaselli: otoh, i think your idea would be quicker, but tuxta at least is working on it) 19:09:05 <boklm> hello 19:09:09 <AL13N> hi 19:09:10 <sebsebseb> hi 19:09:11 <rindolf> Hi 19:09:27 <boklm> #topic Mageia 3 Features review 19:09:28 <anaselli> hi 19:09:42 <boklm> so first topic is about Mageia 3 features review 19:10:02 <boklm> did everybody read the mails about features review ? 19:10:20 <rindolf> I did. 19:10:20 <anaselli> hmm no :/ 19:10:23 <AL13N> i did too 19:10:42 <AL13N> perhaps a reference link? 19:11:08 <boklm> #link http://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html 19:11:41 <anaselli> ah yes that one 19:11:42 <boklm> you can see the review of all proposed features on this page: https://wiki.mageia.org/en/FeatureMageia3_Review 19:11:43 <erzulie> [ FeatureMageia3 Review - Mageia wiki ] 19:12:18 <boklm> some of the features needs some modifications, or more people to help 19:12:34 <boklm> is there questions about the process ? 19:13:12 <AL13N> i'd like to know if the features that needed modifications, taht if those modification were enough 19:13:24 <AL13N> iow: if they are also now valid for the next phase 19:14:22 <boklm> for Feature:DiskDrakeRedesign, it needs people to work on it 19:15:02 <AL13N> boklm: well, i though the current phase was to ask for people? 19:15:13 <AL13N> or am i reading the policy wrong? 19:16:01 <boklm> yes, so some people should say that they are interested to work on that feature for that feature to be accepted 19:16:06 <AL13N> ok 19:16:29 <AL13N> also, at the start, it was also said that partial features were ok, that has stuff for mga3 and more stuff for mga4 19:16:47 <AL13N> that particular feature is also such a feature, so as such, it'll need less resources 19:16:51 <boklm> in that case, planning should say what is done for mga3, and what is done for mga4 19:16:58 <AL13N> i wonder if the policy will take this into account 19:17:07 <AL13N> doesn't it? 19:17:13 * AL13N goes to reread 19:17:59 <AL13N> but ok, that's if for my questions 19:18:24 <AL13N> *that's it 19:18:26 <boklm> it needs to say exactly what is planned for mageia 3 19:18:37 <AL13N> yes, i'll go modify some more 19:19:09 <boklm> other questions about features ? 19:20:09 <boklm> anaselli: did you see about merging Feature:DrakXtoolsReview and Feature:UiAbstraction4mcc features ? 19:20:19 <anaselli> boklm: yes 19:20:40 <anaselli> but there's no so much to merge they start from a different point 19:20:54 <neoclust> anaselli: for Feature:UiAbstraction4mcc why a new toolkit ? perl-qt4 would be simpler i think 19:20:58 <neoclust> or perl-kde4 19:21:19 <anaselli> neoclust: not that simple i believe i found some blocking issue 19:21:32 <boklm> anaselli: both features have the same goal, so it's useless to do both 19:21:34 <anaselli> but i'm wiating for a real plan from steven 19:21:46 <anaselli> then we can take a decision 19:21:58 <anaselli> i'm looking to perl-qt anyway 19:22:06 <neoclust> anaselli: yes but perl-kde4 will allow to use real kde features, the real kde windows, ... 19:22:13 <AL13N> i'm also looking into it a small bit 19:22:20 <anaselli> as blino, pasmatt and AL13N already know :) 19:22:52 <boklm> ok 19:22:55 <anaselli> neoclust: i think it's not that different using perl-kde after 19:23:01 <AL13N> steven seems to do work on that new feature; but i think perl-qt4 or perl-kde4 will be easier to accomplish 19:23:26 <neoclust> anaselli: yes i speak of both because doing interactive::qt or interactive::kde shouldn't differ a lot 19:23:34 <anaselli> AL13N: neoclust I wonder why nobody has already done it? 19:23:39 <AL13N> neoclust: do you have some time to spare for implementing interactive.pm with perl-kde4 ? 19:23:41 <anaselli> if it's easy :p 19:23:50 <neoclust> AL13N: i don't code in perl 19:24:14 <AL13N> neoclust: perhaps as an advisor to qt4 or kde4 processes? 19:24:24 <neoclust> AL13N: why not 19:24:42 <AL13N> great, you can enlist yourself as advisor on that feature then 19:24:45 <neoclust> blino can give advices in the perl part ( i don't tell he will work on it ;) ) 19:24:49 <neoclust> AL13N: NO 19:24:51 <neoclust> AL13N: i can help a little 19:24:59 <rindolf> neoclust: I know Perl too. 19:25:01 <neoclust> but i can't be officially on this 19:25:13 <AL13N> oic 19:25:16 <anaselli> neoclust: i see :) 19:25:22 <neoclust> AL13N: i may have to much work and not be available some weeks 19:25:28 <AL13N> well, it's be easier to accept this feature if there's enough people listed on it 19:25:34 <AL13N> but i understand 19:25:38 <AL13N> it's just a suggestion 19:25:48 <neoclust> AL13N: note me in with a note: may be away some times 19:25:49 <neoclust> ;) 19:25:57 <anaselli> AL13N: but i don't code in perl either... 19:25:59 <AL13N> :-) 19:26:13 <anaselli> so my contribution is liiiitttttle 19:26:16 <AL13N> well, real coders don't matter what language 19:26:22 <AL13N> and i don't code much in perl either 19:26:25 <AL13N> but sometimes i do 19:26:50 <AL13N> otoh, this isn't my most priority feature 19:26:55 <boklm> ok, so other questions or comments about features ? 19:27:03 <boklm> or can we move to next topic ? 19:27:06 <AL13N> yes 19:27:11 <anaselli> ok 19:27:16 <anaselli> AL13N: i knoe :) 19:27:19 <anaselli> know 19:27:31 <anaselli> s odo i 19:27:45 <neoclust> boklm: i told all i had 19:27:52 * anaselli does not use a keyborad well today :( 19:28:00 <boklm> #topic Stable updates and regression testing policy 19:28:12 <boklm> is there anyone from QA team ? 19:28:20 <MrsB> yessir 19:28:39 <neoclust> "sir yes sir" :) 19:28:45 <MrsB> :) 19:29:06 <boklm> so this topic is about the policy for testing and validating updates, and what should be done when bug unrelated to the update are found 19:29:33 <MrsB> our current policy is to use common sense. 19:29:49 <boklm> common sense means different things for different people 19:30:04 <MrsB> yep, but it means there is no blanket solution 19:31:16 <boklm> in my opinion, for security updates, the priority should be to release the update as soon as possible 19:31:32 <MrsB> it is, but not the exclusive one 19:31:36 <boklm> and the goal of testing the update, is to find regressions 19:32:13 <MrsB> You have to realise that security updates are often the first time QA get their hands on a package. No real QA is performed on cauldron. 19:32:14 <AL13N> i think the policy should state that if they find a bug unrelated that was likely there before, to validate it, and file a new bug report 19:32:15 <boklm> if some unrelated problems are found, they can be fixed at the same time, if packager has time to do it, but should not block the update 19:32:37 <MrsB> unrelated means different things to dofferent people 19:32:41 <ennael> hi all sorry for the delay 19:32:42 <MrsB> =o+i 19:32:57 <MrsB> hi anne 19:33:27 <Stormi> boklm: sometimes we do not block the update but the packager gets angry because we "dare" propose to fix the bug in the same update 19:33:28 <MrsB> there is also the problem of creating another update through passing over a bug which could easily be fixed and the extra work that bring to QA 19:33:30 <AL13N> MrsB: unrelated means not related to the bug or security fix or not a regression 19:33:45 <MrsB> thats what it means to you AL13N yes 19:33:52 <rindolf> ennael: hi. 19:34:00 <AL13N> MrsB: i wonder if anyone has a diff interpretation 19:34:11 <MrsB> clearly they do :) 19:34:17 <Luigi12_lappy> we have too many packages and not enough packagers. Lots of packages are updated by packagers that don't use them, because that's how it needs to happen, otherwise the whole distro would bitrot away. QA is the first chance to find problems with these packages if users don't report the issues. Fixing the problems they find is the only way I can think of to maintain any kind of quality in the distro. 19:34:22 <AL13N> well, maybe in QA team, but i haven't seen it yet 19:34:29 <sebsebseb> hi ennael :) 19:34:56 <AL13N> Luigi12_lappy: still, especially for that issue you had lately, fix mga2 first, that takes priority 19:35:00 <ryoshu> ennael: hi 19:35:05 <AL13N> that's my opinion on it 19:35:06 <MrsB> stormi also has a good point ^^ 19:35:15 <Luigi12_lappy> sure, so it'll never get fixed in mga3 and that will ship with the security hole 19:35:23 <AL13N> upgrade to next version is important,; but upgrade to cauldron is less so 19:35:36 <Luigi12_lappy> I'm not the maintainer of that package and I don't think there really is one. It doesn't get fixed now, it probably never will. 19:35:39 <AL13N> Luigi12_lappy: don't say that 19:36:00 <MrsB> We have also been bitten in the past with creating separate bug for 'unrelated' issues and validating the update, the bugs don't tend to get fixed. 19:36:00 <AL13N> Luigi12_lappy: in the main time, we can fix in mga2 and decide to drop in mga3 19:36:07 <AL13N> (before mga3) 19:36:11 <MrsB> anybody remember sectool and msec? 19:36:28 <Luigi12_lappy> still on my bugs list (which is now up to 100) 19:36:37 <boklm> in my opinion, most of the work should be done on cauldron, and stable release updates should only be for fixing major issues 19:36:45 <AL13N> i still think we can't wait 3 extra months to have this security but shipped in mga2... 19:37:03 <Luigi12_lappy> boklm: and who is qualified to classify things as major vs. not major, and then take the time to look at all possible updates and make the determination????? 19:37:07 <MrsB> that doesn't leave much hope for users of stable tho boklm 19:37:24 <MrsB> it doesn't make it particularly stable either 19:37:30 <boklm> we don't have resources to fix every bugs on stable releases 19:37:44 * AL13N agrees with boklm on that 19:37:47 <Luigi12_lappy> then we don't have resources to support the packages we claim to support 19:37:57 <MrsB> we'd hope in QA that the bugs we find count for something 19:38:01 <AL13N> Luigi12_lappy: that's why they are unmaintained 19:38:03 <MrsB> or we're wasting our time 19:38:25 <Luigi12_lappy> and me too, for trying to get security updates for 1000 unmaintained packages that nobody cares about or will help with 19:38:29 <Stormi> I think we at QA can't (and don't much) block security updates for non-regression bugs. But it would be good for our mental health to see the bugs we find fixed whenever possible in the same update (not mandatory but advised, less testing, better quality of update), and if not to see them really fixed afterwards 19:38:41 <boklm> MrsB: you can open bugs on cauldron when you find bugs 19:38:44 <Stormi> otherwise we're testing for nothing sometimes 19:38:51 <MrsB> boklm: we don't use cauldron 19:39:25 <Stormi> if we don't have the ressources to fix bugs, let's stop working on mageia 3 for a while 19:39:31 <Luigi12_lappy> seriously 19:39:34 <MrsB> or drop support for mageia 1 19:39:39 <Luigi12_lappy> no :o( 19:39:52 <Stormi> I know I'm being provocative, but support is important 19:39:58 * MrsB agrees 19:40:22 <AL13N> it is, but we can't be expected to fix every little bug 19:40:29 <Luigi12_lappy> I know it's more "fun" to update new stuff in Cauldron, but if we're gonna claim to support stuff, we need to at least try 19:40:45 <AL13N> thing is 19:40:51 <Luigi12_lappy> otherwise our reputation goes out the window and we'll have no users 19:40:54 <MrsB> I don't think thats what we're saying AL13N, we're saying to use common sense, it's the rule we work to in QA. 19:41:11 <Stormi> a comma in a description can wait for mga3 19:41:16 <Stormi> :) 19:41:18 <AL13N> if you want to choose to have a better current or better future release... if we try to fix the current, we could be ship a worse future release 19:41:29 <Luigi12_lappy> I get that it's frustrating when QA blocks an update (I want these pushed as much as anyone, I know it's frustrating), but I don't think they're being unreasonable 19:41:35 <Stormi> AL13N: I don't think so, most fixes "jump" to the next release 19:41:38 <AL13N> i guess common sense here is an adept enough expression for this, though 19:41:39 <Stormi> so do bugs 19:42:23 <AL13N> but, security and major bugs are important, it shouldn't be on hold, because the package doesn't build on cauldron 19:42:34 <MrsB> I can give a list of bugs we've created to allow updates to be validated which have never been fixed if needs be. 19:42:37 <Luigi12_lappy> that's a different issue AL13N 19:42:51 <AL13N> Luigi12_lappy: it's still part of update policy 19:42:57 <Stormi> (which means we already allow updates to pass through QA even with bugs) 19:43:22 * Luigi12_lappy understands why Oden at mdv gave up working on Cooker for a few months 19:43:54 <boklm> the goal of updates testing is to avoid regressions, not to find all bugs 19:44:04 <Stormi> boklm: we know that already 19:44:18 <Stormi> do you think QA functions differently? 19:44:42 <Luigi12_lappy> boklm: it sounds like you're just FUDing the QA team without really knowing what they do 19:44:47 <Stormi> I think we're probably debating of 2 or 3 updates out of a lot 19:45:08 <MrsB> walk a mile in our shoes ;) (please :D) 19:45:19 <AL13N> i would suggest that: "for major and security bugs, the stable versions take priority; while for minor bugs, don't take any priority; if they can be fixed at the same time, ok, if not, too bad; and deciding major/minor is common sense of QA team" 19:45:37 <AL13N> is this a good enough policy update? 19:45:40 * sebsebseb agree's with AL13N 19:45:43 <Stormi> ok with that AL13N, I think this is already what we do 19:45:57 <Luigi12_lappy> AL13N: the QA team doesn't block things because of Cauldron, that's the packagers' responsibility 19:46:01 <ryoshu> from a user point of view, most PL users complain for bad stability (random hangs etc) - I know there are many new technologies like systemd, kernel3.. but it could be fixed a bit.. :) 19:46:37 <ryoshu> so people move to Fedora 19:46:58 <ryoshu> (or other distros) 19:47:02 <Stormi> ryoshu: this is a bit out of topic 19:47:04 <Luigi12_lappy> can we please stay on topic? 19:47:18 <ryoshu> ok, sorry 19:47:37 <Stormi> about security updates, minor bugs are not the problem 19:47:45 <Stormi> it's when we find that a major functionality is broken 19:47:51 <Stormi> if not the whole usability of the package 19:48:05 <Stormi> that's when QA is reluctant to push the update 19:48:27 <Stormi> we shouldn't have to do that in the first place because the packages should work when we release a new distro of course, but it happens 19:48:42 <Stormi> in that situation we ask for fixes 19:48:47 <MrsB> it's just common sense 19:48:51 <Stormi> but if the packager insists we could push anyways 19:49:04 <Stormi> just keeping a bad taste in our mouths 19:49:21 <Stormi> (if that means anything :)) 19:49:27 <Luigi12_lappy> and when we're trying to find more people to do QA, discouraging the ones who are already doing it seems like a bad idea 19:49:35 <Stormi> true 19:49:40 <sebsebseb> indeed at that 19:49:42 <boklm> that's not discouraging 19:49:46 <Stormi> true also for packagers who do updates though :) 19:49:59 <Stormi> having an update hold 19:50:05 <MrsB> we just have to realise we're all on the same side, with a common goal. 19:50:06 <Stormi> held* 19:50:11 <Luigi12_lappy> MrsB: amen to that 19:50:57 <Stormi> why are we discussing this topic in the first place, were there major problems in the way security updates have been handled lately ? 19:51:05 <Stormi> (genuine question) 19:51:06 <AL13N> so, what exactly was the problem that warranted this topic? 19:51:10 <AL13N> ah yes 19:51:13 <AL13N> sort of same question 19:51:15 <Stormi> yep 19:51:16 <Luigi12_lappy> yes, can someone point out a specific update QA has held unreasonably? 19:51:21 <boklm> https://bugs.mageia.org/show_bug.cgi?id=6544 19:51:24 <erzulie> [ Bug 6544 - tftp missing fix for security issue CVE-2011-2199 ] 19:51:27 <Stormi> I can think of 1 or 2 19:51:39 <Luigi12_lappy> yes, I was gonna say 6544 19:51:50 <boklm> but maybe this is an exception 19:52:00 <MrsB> in that case the package description specifically stated that the sevice was disabled by default, where in fact it actualyl wasn't 19:52:00 <Luigi12_lappy> yes, that was unfortunate 19:52:17 <AL13N> hmm 19:52:19 <Luigi12_lappy> things got heated and out of control 19:52:36 <Stormi> yes, that was not a question of policy but rather of working together 19:52:40 <AL13N> i think QA team will bear final responsibility, but it should be open to packagers reasons 19:52:50 <Stormi> we are 19:53:13 <AL13N> ok, so then there's no real problem? 19:53:13 <Stormi> comments from the packager were not from the highest diplomacy here 19:53:16 <MrsB> if it says it's disabled but isn't then imho that is an issues, and especially where it took 2 mins to fix and 30 mins to fight about. 19:53:28 <Luigi12_lappy> and people need to remember QA doesn't always come into these bug reports already being experts on the package 19:53:37 <AL13N> MrsB: and a topic on packaging meeting 19:53:38 <MrsB> common sense on both sides of the fence ;) 19:54:03 <Luigi12_lappy> and neither do I, trying to get these security updates done 19:54:17 <AL13N> ok, so i think we've already lots enough time on this bug, let's just agree to respect each others feelings and standpoints and go to next topic 19:54:24 <Luigi12_lappy> sounds good 19:54:44 <Stormi> yes 19:54:51 <boklm> so everybody agree that minor unrelated bugs should not block an update, even if it's better to have it fixed ? 19:54:55 <Stormi> yes 19:55:06 <Stormi> but packagers have to agree that we try to get them fixed 19:55:15 <Stormi> without being angry if we ask if it's possible 19:55:20 <MrsB> it's important also to realise that where we find and report bugs, packagers know they are sensible and will be followed up. Not necessarily the case if bugs are allowed to reach our users. 19:55:26 <Stormi> we test, we find bugs, we report them 19:55:36 <sebsebseb> yep get the major security bugs fixed :) even if it means not fixing some minor other bugs whilst at it, I guess 19:55:42 <AL13N> ok, can anyone put this in an #info thing? 19:56:58 <Stormi> I propose : "unrelated bugs do not block updates, but when fix is easy it's better to fix in the same update to lower QA work and ship better updates" 19:57:05 <Stormi> oops, forgot security word 19:57:08 <boklm> ok 19:57:14 <AL13N> good enough 19:57:18 <boklm> everybody agree with this ? 19:57:18 <Luigi12_lappy> yep 19:57:31 * sebsebseb agree's with Stormi 19:57:32 <MrsB> common sense should be applied, there is no blanket right and wrong 19:58:32 <sebsebseb> yep 19:59:12 <boklm> common sense is too vague 19:59:35 <AL13N> boklm: but i don't think there's a strict answer to this 19:59:45 <MrsB> well at the same time this is not really the place to agree QA policy 20:00:15 <Luigi12_lappy> if there's a time in the future QA is being unreasonable, that would be a better time to discuss this. Let's move on please. 20:00:18 <boklm> so you don't agree that "unrelated bugs do not block updates, but when fix is easy it's better to fix in the same update to lower QA work and ship better updates" ? 20:00:35 <MrsB> Isn't that what we already do? 20:00:49 <boklm> MrsB: this is not the question 20:00:55 <ennael> we can write it in wiki in policy 20:00:58 <ennael> it does not hurt 20:01:05 <AL13N> ok 20:01:06 <ennael> and may help new comers 20:01:07 <Stormi> I agree to state it again, but maybe add in info that it was already the case, it's just so that things are clear 20:01:27 <ennael> a policy is often something already done and stated :) 20:01:40 <Luigi12_lappy> the QA team has already been the process recently of cleaning up the wiki pages and making sure policies and procedures are clear 20:02:05 <ennael> policies are not one team exclusive 20:02:05 <MrsB> i'd just like to see both sides agree to use common sense and recognise that we are both teams working towards the same goal. 20:02:14 <ennael> it's a result from discussion 20:02:27 <ennael> and haveing cross teams work is always better 20:02:36 <boklm> use common sense doesn't mean anything, nobody will say they don't use common sense 20:02:40 <ennael> nothing more nothing less 20:03:00 <Luigi12_lappy> I guess packagers that have been trying to help QA with all of this already don't count 20:03:21 <boklm> everybody think what they do is common sense 20:03:25 <ennael> :) 20:03:47 <ryoshu> ok, next topic? 20:03:59 <boklm> ok 20:04:08 <boklm> anything else to say on this topic ? 20:04:12 <Luigi12_lappy> no 20:04:13 <sebsebseb> nope 20:04:15 <MrsB> nope 20:04:46 <boklm> #topic ARM build system 20:04:52 <ennael> rtp ! 20:04:53 <ennael> oups 20:05:42 <boklm> so this is an update about the status of the ARM build system 20:06:10 <boklm> we have an ARM server in the datacenter that can be used to rebuild packages on ARM 20:06:23 <boklm> what is missing is integration of ARM build node in the build system 20:07:17 <boklm> for this, we need to add support for non-blocking architectures, because ARM build is slow, and we don't want to slow down the build system for i586 and x86_64 20:07:43 <boklm> so rtp started working on a script to rebuild late packages on an other architecture 20:08:20 <blino> outch 20:08:21 <boklm> and for testing his script, he is testing a rebuild of x86_64 repository 20:08:22 <blino> why that? 20:08:52 <boklm> blino: why what ? 20:08:55 <blino> 1) such a script already exists, and was used at the beginning of the x86_64 port at Mandriva; it is called iurt 20:09:26 <blino> 2) it would be better to have real integration of non-blocking architectures in the schedulers (ulri/emi) 20:09:32 <blino> and pretty easy I guess 20:10:30 <boklm> I think rtp is using iurt 20:10:49 <blino> why would you need a script then? 20:11:01 <blino> iurt already has all the builtin features to do what you want 20:11:17 <blino> you would just need a very tiny wrapper or one-liner to add in a crontab 20:11:31 <boklm> a script to find the packages that are late, and launch the build in iurt 20:11:45 <boklm> blino: iurt can already find the packages that are late ? 20:11:59 <blino> yes 20:12:29 <blino> this even was its initial purpose, IIRC 20:12:42 <boklm> blino: can you send more infos about this to rtp ? 20:13:04 <AL13N> so, i have a slightly related questions 20:13:10 <AL13N> *question 20:13:50 <boklm> AL13N: what is the question ? 20:13:58 <AL13N> there's quite some people who seem to be getting raspberry pi; and ask if current state works for it, or if it will 20:14:10 <AL13N> i'd like to answer something to such people, but i don't know much 20:14:18 <AL13N> is there a wiki page regarding ARM info? 20:14:20 <boklm> rtp: ? 20:14:35 <AL13N> it would be nice to let those people know something 20:14:52 <ennael> if I'm not wrong I remember rtp was saying it's not possible for now 20:15:13 <AL13N> due to architecture changes? or drivers? or anything? 20:15:13 <ennael> because of proprietary drivers 20:15:15 <AL13N> oic 20:15:23 <AL13N> :-( 20:15:33 <AL13N> but ok, thanks for letting me know 20:15:33 <ennael> but we will ask rtp to confirm 20:15:37 <AL13N> k 20:15:48 <AL13N> some kind of blog post on this might be nice too 20:16:00 <ennael> when we have more things to announce 20:16:00 <AL13N> ARM in general i mea 20:16:08 <AL13N> k 20:16:10 <ennael> to avoid vaporware effect :) 20:16:38 <blino> boklm: I'll try to find out any archives about this iurt behavior 20:16:48 <boklm> blino: ok, thanks 20:17:17 <blino> ennael: well, even a non-graphical system on raspberry pi would be a start 20:17:34 <neoclust> blino: with KDE or nothing :) 20:17:42 <blino> boklm: what kind of ARM board do you have for the build system? what kind of storage? 20:18:12 <ennael> blino: I'm just trying to remember, I'm not saying it is 20:19:14 <boklm> blino: we have freescale iMX53 20:19:41 <boklm> we a sata disk 20:19:59 <boklm> we have 2 boards, but one of them have a hard disk problem, so we need to replace the disk 20:20:54 <blino> boklm: are they the ref design boards from Freescale or some box from Genesis? 20:21:19 <boklm> blino: this is this one: http://fr.mouser.com/ProductDetail/Freescale-Semiconductor/MCIMX53-START/?qs=sGAEpiMZZMspbelMIdDJdKswmyqRD7aG 20:21:20 <erzulie> [ MCIMX53-START Freescale Semiconductor | Mouser ] 20:21:42 <AL13N> is this still related to the meeting? can we go to next topic? 20:21:47 <blino> boklm : rtp : it seems the crontabs at Mandriva looked this way for the automated x86_64 packages rebuild 20:21:50 <blino> #45 * * * * /usr/local/bin/iurt2.sh --clean mandrake -r cooker x86_64 -m main --cache -u --upload --chrooted-urpmi http://192.168.2.6/dis/ 20:21:53 <blino> #15 * * * * /usr/local/bin/iurt2.sh -r cooker x86_64 -m contrib --cache -u --upload --chrooted-urpmi http://192.168.2.6/dis/ 20:22:25 <boklm> ok, thanks 20:22:28 <boklm> so we need to look at this 20:23:01 <boklm> anything else to say about arm build system ? 20:24:07 <AL13N> no 20:24:45 <boklm> ok 20:25:07 <boklm> so last topic 20:25:09 <boklm> #topic Security bugs review 20:25:23 <boklm> Luigi12_lappy: do you want to say something about security bugs ? 20:25:47 <Luigi12_lappy> I think I've said plenty in my mails to the -dev list, but I'm more than willing to answer any questions anyone has 20:26:06 <boklm> can you add links to the mails ? 20:26:20 <Luigi12_lappy> no, gmane web interface is 3 days out of date on the -dev list 20:26:28 <ennael> mailman 20:26:56 <Luigi12_lappy> ok looking now 20:27:21 <Luigi12_lappy> https://www.mageia.org/pipermail/mageia-dev/2012-July/017145.html is the most up to date 20:27:36 <boklm> ok 20:27:57 <boklm> so anyone has questions or comments ? 20:28:41 <AL13N> (i have one more question on features and one more small topic, but not on this) 20:29:40 <boklm> AL13N: what is your question/topic ? 20:30:47 <AL13N> regarding features, can someone in wiki page reorder so that modified ones who only need resources, be listed with the others, and the ones that have enough resources be in a separate section? 20:31:29 * boklm doesn't understand 20:31:35 <boklm> how do you want to reorder ? 20:31:41 <AL13N> well 20:31:47 <Luigi12_lappy> right now there's accepted and rejected. How about accepted, conditionally accepted, and rejected. 20:31:56 <Luigi12_lappy> conditionally accepted is the ones whos only fault is missing resources 20:32:00 <AL13N> for example, i and some other people modified their feature page, 20:32:16 <AL13N> they might be accepted now (pending resources) 20:32:28 <AL13N> the features which have enough resources could then be in a separate section 20:32:39 <Luigi12_lappy> accepted :o) 20:33:15 <AL13N> boklm: sort of what Luigi12_lappy is saying 20:33:37 * ryoshu has one topic short for the ending 20:34:06 <AL13N> boklm: is that ok? 20:34:28 <boklm> some of the rejected one could become accepted if the reason for rejecting them is fixed 20:34:52 <AL13N> i'm just asking that the wiki page be a reflection of that 20:34:57 <AL13N> at some point 20:35:18 <AL13N> (my extra small topic is regarding backports and the mail i've sent; i'd like it for each part of necessary actions for backports, to have a responsible person) 20:35:32 <AL13N> (essentially, a call to action of sorts) 20:35:49 <ennael> well it seem resources are not filled 20:35:52 <Luigi12_lappy> sounds like backports is a feature with not enough resources 20:35:55 * Luigi12_lappy hides 20:36:19 <AL13N> ennael: iinm, that wiki page, has some proposals listed up top, while still not enough resources 20:36:34 <AL13N> Luigi12_lappy: indeed it is 20:36:47 <AL13N> can't find the wiki page now 20:37:03 <AL13N> trying to find link -( 20:38:34 <AL13N> https://wiki.mageia.org/en/FeatureMageia3_Review 20:38:36 <erzulie> [ FeatureMageia3 Review - Mageia wiki ] 20:38:51 <AL13N> some of the accepted features still need resources or have other comments 20:39:10 <boklm> which ones ? 20:39:58 <AL13N> almost all of them 20:40:07 <AL13N> have some kind of comment about needing modification 20:40:07 <ryoshu> my feautre is updated, and the comments are still there :) 20:40:25 <boklm> ryoshu: which feature ? 20:40:28 <ennael> can you please fill wiki page ? 20:40:35 <AL13N> like thist: https://wiki.mageia.org/en/Feature:Wider_Python_3_support 20:40:36 <erzulie> [ Feature:Wider Python 3 support - Mageia wiki ] 20:40:42 <AL13N> or https://wiki.mageia.org/en/Feature:UpdatesCanUseDependenciesFromOtherRepos 20:40:44 <erzulie> [ Feature:UpdatesCanUseDependenciesFromOtherRepos - Mageia wiki ] 20:40:52 <ryoshu> boklm: https://wiki.mageia.org/en/Feature:Wider_Python_3_support 20:40:53 <erzulie> [ Feature:Wider Python 3 support - Mageia wiki ] 20:40:56 <AL13N> ennael: what should we fix in wiki page? 20:41:29 <AL13N> like this one https://wiki.mageia.org/en/Feature:DiskDrakeRedesign at page https://wiki.mageia.org/en/FeatureMageia3_Review 20:41:32 <erzulie> [ Feature:DiskDrakeRedesign - Mageia wiki ] [ FeatureMageia3 Review - Mageia wiki ] 20:41:35 <AL13N> it still says unclear or messy 20:41:37 <AL13N> is it? 20:41:47 <AL13N> i don't know, in my opinion, it's clear 20:42:10 <AL13N> i don't know if it's right for me to modify this wiki age: https://wiki.mageia.org/en/FeatureMageia3_Review 20:42:11 <erzulie> [ FeatureMageia3 Review - Mageia wiki ] 20:43:38 <boklm> some accepted features have some comments, but not enought to be rejected 20:44:14 <AL13N> ok, so i wonder if the ones that are not yet accepted, be reviewed and put above if wanted, or given some extra or new comment to say so? 20:44:23 <AL13N> at least the ones that are modified 20:44:52 <AL13N> that was my question, which i can't seem to explain clearly 20:44:52 <ennael> let us have a look tomorrow ok ? 20:45:02 <AL13N> it' doesn't have to be tomorrow, it can be later 20:45:23 <ennael> no this have to be cleared as soon as possible so that you can start work on it :) 20:45:28 <AL13N> heh 20:45:36 <AL13N> i see your point 20:46:17 <boklm> ok, so we can close meeting ? 20:46:27 <Luigi12_lappy> ryoshu: you had something to say? 20:46:27 <rindolf> Fine by me. 20:46:29 <AL13N> my requested topic (even though most people are asleep now), is about backports, and the requesting of volunteers for each of the necessary points 20:46:55 <ryoshu> Luigi12_lappy: yes 20:46:55 <Luigi12_lappy> and more volunteers to help with security updates and QA too :o) 20:46:57 <AL13N> i've sent email on this 20:47:05 <ryoshu> just small question 20:47:27 <boklm> AL13N: do you want to say something more on that topic that has not been said yet ? 20:47:47 <AL13N> just to ask for a call of attention, if we want backports, someone will have to do the actual work 20:47:55 <AL13N> i can give link to email 20:48:35 <boklm> ok 20:48:48 <boklm> ryoshu: what is your question ? 20:48:50 <ryoshu> I think there should be a wiki page with quick links for overloaded people, for developers: 1) mageia-dev 2) mageia-discuss 3) latest bugs 4) rpm policy 5) link to the directory with IRC meetings 6) planning 7) dates.. it could be very useful for those who have limited time 20:49:00 <AL13N> #link https://www.mageia.org/pipermail/mageia-dev/2012-June/016948.html 20:49:26 <ryoshu> something that is accessible with 3 clicks from mageia.org :) 20:49:26 <Luigi12_lappy> #link https://www.mageia.org/pipermail/mageia-dev/2012-July/017145.html 20:49:44 <Luigi12_lappy> anyone can edit the wiki :o) 20:49:53 * AL13N agrees 20:50:10 <boklm> ryoshu: there is some links on https://wiki.mageia.org/en/Packagers_Team 20:50:11 <erzulie> [ Packagers Team portal - Mageia wiki ] 20:50:34 <boklm> but more can be added 20:51:13 <ennael> feel free to add 20:51:17 <ennael> it's a wiki :) 20:51:30 <boklm> can we close meeting ? 20:51:37 <Luigi12_lappy> yep 20:51:38 <ryoshu> boklm: a few are useful for this :) 20:51:40 <AL13N> oàk 20:51:44 <ennael> yep 20:51:46 <boklm> #endmeeting