19:06:38 <misc> #startmeeting
19:06:38 <Inigo_Montoya> Meeting started Wed May 18 19:06:38 2011 UTC.  The chair is misc. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:38 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:39 <erzulie> [ MeetBot - Debian Wiki ]
19:06:49 <misc> #chair misc ennael Nanar
19:06:49 <Inigo_Montoya> Current chairs: Nanar ennael misc
19:07:04 <misc> so, the agenda was sent on the ml
19:07:32 <misc> so let's start with the beginning
19:07:39 <misc> #topic release blocker bugs
19:07:57 <misc> so we have a bug for that
19:08:04 <saispo> number 908 :)
19:08:14 <misc> 908 is for security
19:08:18 <misc> there is another one
19:08:46 <misc> ( that of course I cannot find )
19:08:59 <Nanar> about?
19:09:19 <misc> about release blocker bug
19:09:31 <Nanar> bug is about ?
19:09:33 <misc> in fact, we do not have, we just have 3 bugs left :
19:09:47 <misc> 56 : https://bugs.mageia.org/show_bug.cgi?id=56
19:09:49 <erzulie> [ Bug 56 - [TRACKER] tracker report for upgrade issues ]
19:09:57 <misc> https://bugs.mageia.org/show_bug.cgi?id=1326
19:09:59 <erzulie> [ Bug 1326 - Oops when lvm scans device with unionfs ]
19:10:15 <misc> https://bugs.mageia.org/show_bug.cgi?id=908
19:10:17 <erzulie> [ Bug 908 - [TRACKER] rollup bug for security related issues blocking release of Mageia 1 ]
19:10:18 <leuhmanu> 338 ?
19:10:32 <misc> 1326 is the bug that prevent at the moment the creation of the livecd
19:10:36 <shikamaru> 1117 is a joke :-)
19:11:04 <misc> shikamaru: no, there is several cve to fix
19:11:08 <Nanar> one bug is missing, about ethernet card
19:11:33 <ennael> about sec bugs it was decided with stew to stop it at the end of this week
19:11:46 <ahmad78> Nanar: laptop-mode-tools?
19:12:01 <misc> #info security update must been finished by the end of the week
19:12:03 <ahmad78> (there's a fix, pm-utils should conflict with laptop-mode-tools)
19:12:23 <ennael> about that specific bug would be nice to decide what to do
19:12:23 <Nanar> ahmad78: yes
19:12:32 <ennael> if it's ok then ahmad78 can fix it
19:12:32 <saispo> ennael, misc : the sec bug about php is hard to resolve because it integrate regression :x
19:12:52 <misc> shikamaru: as i said in the bug, the regression have been resolved
19:12:59 <misc> s/shikamaru/saispo/
19:13:15 <misc> https://bugs.mageia.org/show_bug.cgi?id=1117#c3
19:13:17 <erzulie> [ Bug 1117 - PHP Multiple vulnerability ]
19:13:22 <saispo> ok, hard work for php :x
19:14:39 <misc> anyway, the meeting is not to discuss bugs, but to remind to people to look at them, and if there is anything that could not be fixed after with a update, or that would prevent update ( like the problem mentioned by nanar ) to mark this as release critical
19:14:39 <Kharec> :x
19:14:50 <misc> we are still in track for releasing in time
19:14:57 <pterjan> a lot of them are already fixed
19:14:59 <pterjan> (php)
19:15:03 <spturtle> 1157 can be fixed by symlinking /etc/mtab to /proc/self/mounts but that is a significant change
19:15:20 <spturtle> misc: but some bugs have been ignored for a long time
19:15:21 <tmb> the end of this week, is it work week or sunday?
19:15:35 <ennael> sunday
19:15:42 <misc> spturtle: yes but if ignoring bugs make them disappear, we would have noticed :)
19:16:03 <pterjan> http://svnweb.mageia.org/packages?view=revision&revision=87292
19:16:03 <erzulie> [ [packages] Revision 87292 ]
19:16:08 * spturtle closed one of them as invalid :P
19:16:09 * pterjan adds a comment
19:16:39 <misc> I would also add that bug 56 is also a tracker bug
19:17:46 <misc> and for exemple, this one should be maybe lowered : https://bugs.mageia.org/show_bug.cgi?id=701
19:17:48 <erzulie> [ Bug 701 - Update of package speech_tools blocked by package libspeech_tools1-1 ]
19:18:14 <ennael> Anssi told me he should have a look on it this week
19:18:15 <ahmad78> I agree
19:18:30 <misc> this one is a enhancement : https://bugs.mageia.org/show_bug.cgi?id=652 so I do not understand why it block upgrade :/
19:18:32 <erzulie> [ Bug 652 - timezone and crountry setting ]
19:18:49 <ahmad78> I got tired of uncoupling bugs from 56
19:18:57 <ahmad78> so at some point I just gave up on it
19:19:35 <misc> well, I guess people were to proactively setting release blocker :)
19:19:53 <misc> anyway, any questions on the various currents bug to fix ?
19:20:15 <ennael> working at the moment on unionfs one
19:20:24 <ennael> rtp and possibly tmb
19:20:31 <ennael> this is blocker for live cds
19:21:38 <ahmad78> misc: (not release blockers, just 56)
19:21:44 <anaselli> ennael: you mean timezone and country settings?
19:21:49 <misc> they could change the status to "assigned"
19:22:15 <misc> anaselli: https://bugs.mageia.org/show_bug.cgi?id=1326 this one
19:22:16 <erzulie> [ Bug 1326 - Oops when lvm scans device with unionfs ]
19:22:45 <misc> also, if people ask for the livecd, you can point them to the bug report ( as people will likely ask )
19:22:53 <anaselli> can't help there :/
19:23:18 <misc> anaselli: well, you can help triaging or testing the rc :)
19:23:37 <misc> so speaking of that, next topic
19:23:44 <misc> #topic planning to stable release
19:23:58 <misc> as we plan to release in 2 weeks
19:24:09 <anaselli> misc: not in the week-end unfortunately (for you, luckily for me :) )
19:24:22 <misc> ennael wrote a page on the wiki about the remaining action
19:24:34 <misc> http://mageia.org/wiki/doku.php?id=iso1:countdown#technical_countdown
19:24:35 <erzulie> [ iso1:countdown [Mageia temporary wiki] ]
19:25:20 <misc> while most stuff are for sysadmin to do, there is some task for packagers
19:26:24 <misc> so first, have people some question about the list ? ( like f something is not clear, do not hesitate to ask, the goal is to make sure the list is useful )
19:27:10 <anaselli> remove .svn entries in the repository ?
19:27:29 <misc> anaselli: clean mirrors directory if we do have so .svn
19:27:51 <misc> but I think that's likely not to happen, or at least, this should be automated ( ie, using svn export )
19:28:11 <anaselli> ah pacakge repositories then... and how about contrib background?
19:28:12 <shikamaru> fork svn ?
19:28:26 <shikamaru> what’s the difference between the item just below ?
19:28:43 <boklm> branch svn for packages
19:28:49 <boklm> the item below is on mirrors
19:28:54 <boklm> the tree on mirrors
19:29:37 * misc clarified the list
19:29:41 <shikamaru> ah I see
19:29:44 <anaselli> \o/
19:30:11 <shikamaru> what help can we packagers bring for these items ?
19:30:46 <misc> well, there is various things to check
19:31:09 <misc> making sure that meta-task is up to date, as well as mageia-release
19:31:25 <misc> but indeed, there isn't much specifically for packagers
19:31:32 <misc> regarding the planning, we are in rc
19:31:47 <misc> this mean that 1) we will soon completly block all uploads
19:31:52 <anaselli> misc:  maybe "check errata text"
19:31:57 <misc> likely at the end of the week
19:32:20 <ennael> also release notes are important
19:32:20 <misc> anaselli: we need to write this, indeed , but let me finish :)
19:32:26 <ennael> as we need to add it in installer
19:32:37 <misc> so in the end of the week, people will still be able to commit to svn
19:32:46 <saispo> ennael: you miss 'seed' :)
19:32:48 <misc> but no upload, unless there is a very very good reason
19:33:12 <saispo> ennael: for seed i maybe neeed some artwork
19:33:30 <ennael> saispo: just send specifications as soon as possible
19:33:35 <misc> after that, we will create iso, test them, prepare the release ( the whole check list ), prepare the non technical bits
19:33:44 <anaselli> misc: if funda is not going to have a massive commits after... i can wait :D
19:33:45 <misc> and release
19:34:39 <misc> once release, we reopen upload, and people can then update, and we will start to discuss of all issues that were postponed to the first release ( like release cycle, etc )
19:34:53 <misc> #info total freeze for the end of the week
19:35:01 <misc> #info no upload permitted
19:35:08 <saispo> ennael: ok let me see tomorrow and i will send you my request
19:35:32 <misc> #info svn still working, cauldron reopened after the release is officialy out
19:35:49 <misc> so as said by ennael, something that we must do is taking care of the release note
19:36:35 <misc> http://mageia.org/wiki/doku.php?id=iso1:mageia1_release_notes
19:36:36 <erzulie> [ iso1:mageia1_release_notes [Mageia temporary wiki] ]
19:36:58 <misc> so that's where people can help, by making sure the note are accurate
19:37:03 <obgr_seneca> so at the end of the week, there will be also i18n freeze?
19:37:22 <obgr_seneca> I mean for fixing translation bugs?
19:37:44 <misc> obgr_seneca: yes, but we can always update packages later, like any bug
19:37:52 <saispo> misc: for sponsoring and introducing newbie packer, will see after the release no ? i think it's the most appropriate
19:38:01 <misc> saispo: yes
19:38:08 <saispo> ok
19:38:14 <obgr_seneca> all but installer
19:38:21 <misc> obgr_seneca: yup
19:38:35 <misc> now, we didn't changed installer, so any bug would be a old one
19:39:23 <misc> ( so likely not blocking, unless I am wrong )
19:39:36 <obgr_seneca> yep
19:39:37 <misc> along with releases notes, we do have errata : http://mageia.org/wiki/doku.php?id=mageia1:errata
19:39:39 <erzulie> [ mageia1:errata [Mageia temporary wiki] ]
19:39:52 <misc> that's the same, we must try to complete them with issues
19:40:20 <ahmad78> I am flagging bug reports that should be in the errata in the Whiteboard with "Errata"
19:40:21 <misc> #action complete release notes http://mageia.org/wiki/doku.php?id=iso1:mageia1_release_notes
19:40:22 <erzulie> [ iso1:mageia1_release_notes [Mageia temporary wiki] ]
19:40:34 <misc> #action complete errata http://mageia.org/wiki/doku.php?id=mageia1:errata
19:40:35 <erzulie> [ mageia1:errata [Mageia temporary wiki] ]
19:40:55 <misc> ahmad78: you have a query for hat ?
19:41:16 <ahmad78> misc: no, will do it later
19:41:33 <ahmad78> (there's something to do that in the advanced search form)
19:41:34 <misc> https://bugs.mageia.org/buglist.cgi?status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=Errata&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
19:41:36 <erzulie> [ Bug List ]
19:41:45 <misc> there is 1 bug :/
19:42:11 <ahmad78> misc: yes, for now
19:42:38 <misc> #info ahmad78 flagged bug with Errata flag if they should be added to eratas
19:42:51 <misc> #info take care of adding link to bug reports in errata
19:42:58 <misc> any questions ?
19:43:44 <saispo> nothing, a lot of work are pending ;)
19:44:31 <misc> ok so 3rd topic
19:44:42 <misc> #topic svn management for stable
19:45:10 <misc> so, in mdv, and as said in the todo list, we used to do a copy of svn , like a tag/branch
19:46:22 <misc> now, we are using 2 repositories
19:46:33 <misc> 1 for binaries, 1 for specs
19:47:10 <misc> and the question is "how do we adapt the process for that new setup"
19:47:12 <misc> boklm: ?
19:47:25 <boklm> yes
19:47:34 <boklm> so in mandriva we did :
19:48:01 <boklm> svn cp packages/cooker packages/updates/[release]
19:48:26 <spturtle> so what happens wich changes in svn that were not submitted?
19:48:38 <misc> spturtle: that's the first issue
19:48:39 <boklm> something else we could do is :
19:48:39 <spturtle> with
19:49:05 <boklm> svn cp packages/cauldron/[package]/pristine packages/cauldron/[package]/branches/[release]
19:49:17 <boklm> for each package
19:49:29 <AL13N> (and similar for binrepos?)
19:49:32 <boklm> yes
19:50:02 <misc> spturtle: but in practice, it didn't matter much, as no one committed stuff without submitting
19:50:12 <saispo> svn lack of branch :x
19:50:36 <boklm> for committed changes not submitted, we could check if there are any with a diff between pristine and current
19:51:06 <Nanar> does mgarepo will be able to handle package for stable release ?
19:51:42 <misc> Nanar: we kinda hope, yes :)
19:52:01 <misc> but that's right we should also make sure this work fine
19:52:01 <boklm> for now it handles the old way with packages/updates/[release], but it requires some changes to handle packages/cauldron/[package]/branches/[release]
19:52:53 <Nanar> misc: are you sure everything commited has been submitted ?
19:53:14 <shikamaru> mmh then why not just packages/[package]/ instead of packages/cauldron ?
19:53:17 <Nanar> it's not easy to check, and I am preetty sure some did
19:53:18 <spturtle> Nanar: he isn't, I have some changes not submitted
19:53:26 <Nanar> ok ;
19:53:26 <AL13N> afaik the changelogs have revision numbers
19:53:28 <Nanar> ;)
19:53:37 <tmb> I'd go for copying pristine
19:53:42 <AL13N> we could put that in the script that makes branch
19:53:47 <spturtle> what is pristine?
19:54:00 <misc> Nanar: I am sure that not everything was submitted, hence the proposal of boklm to copy one fo the directory
19:54:03 <boklm> pristine is last submitted version
19:54:20 <ahmad78> spturtle: http://svnweb.mageia.org/packages/cauldron/gtk-chtheme/
19:54:21 <erzulie> [ [packages] Index of /cauldron/gtk-chtheme ]
19:54:25 * misc would also propose to rename the various directory one day /o\
19:54:26 <Nanar> using pristine seems ok
19:54:27 <ahmad78> for example
19:54:34 <spturtle> then I think that's a very good idea, also good to have everything in the package dir
19:54:48 <Nanar> but the current svn structure seems to not be appropritae
19:55:25 <Nanar> eg having one pristine/ by package
19:55:32 <misc> yes
19:55:36 <AL13N> we could easily find the last packages revision number in changelog and use that revision to branch off for each package
19:56:18 <boklm> Nanar: you mean having only one pristine for all cauldron and stable releases ?
19:56:55 <misc> that's why we have branch
19:57:36 <Nanar> boklm: no, something like DIST/{pristine,current}/package instead [DIST]/package/{pristine,current}
19:58:04 <ahmad78> that change happens now? too late in the cycle... maybe for mga2?
19:58:06 * Nanar don't especially want to rethink svn to night
19:58:24 <misc> well, yes, the goal is just to know what we do for now
19:58:28 <Nanar> ahmad78: I do agree
19:58:44 <misc> I would prefer to avoid a 2nd "let's decide the layout of mirrors" thread :)
19:58:48 <misc> at least, not now
19:59:01 <ahmad78> yes, wait for mga2 to ask the questions :)
20:00:00 <AL13N> agreed
20:00:23 <misc> ok so for svn , how do we manage the switch to stable ?
20:00:27 <misc> ( and why )
20:00:46 <Nanar> then go for copy package/pristine
20:01:07 <Nanar> will be only what has been submitted
20:01:09 <AL13N> does package/pristine gives the latest commit or the latest submit revision?
20:01:25 <misc> AL13N: latest submit , current is the lastest commit
20:01:38 <ahmad78> yeah, pristine is best, means the changes are already on the mirrors, i.e. hopefully tested
20:02:02 <spturtle> http://svnweb.mageia.org/packages/cauldron/firefox/pristine/SPECS/firefox.spec?view=log
20:02:03 <erzulie> [ [packages] Log of /cauldron/firefox/pristine/SPECS/firefox.spec ]
20:02:06 <AL13N> ah
20:02:21 <AL13N> agreed
20:02:48 <AL13N> how long would something like this kind of branching take?
20:03:12 <AL13N> and would this new way likely have less impact on used storage?
20:03:27 <misc> #info copy /pristine  : svn cp packages/cauldron/[package]/pristine packages/cauldron/[package]/branches/[release]
20:03:38 <misc> AL13N: the impact on storage is the same, that's svn
20:03:47 <AL13N> ah yes, of course
20:03:49 <misc> a copy is just a pointer to the history
20:03:56 <AL13N> so it shouldn't take long either
20:04:05 <AL13N> what happens if someone commits during this?
20:04:05 <misc> regarding the branch, we will see
20:04:17 <AL13N> no effect? cause of pristine?
20:04:23 <boklm> nobody commits on pristine
20:04:26 <misc> #action try to measure how long the branch will take
20:04:29 <spturtle> so someone needs to adapt mgarepo and submit an update for null?
20:04:36 <boklm> yes
20:04:50 <misc> spturtle: ?
20:05:06 <boklm> mgarepo needs to be adapted to use packages/cauldron/[package]/branches/[release]
20:05:31 <misc> so would mdvsys or others
20:05:51 <misc> ( now, indeed prefixing it with cauldron wouldn't make much sense :/ )
20:06:10 <boklm> yes, cauldron directory should be changed, one day
20:07:06 <misc> #action adapt mgarepo to the future structure
20:07:47 <spturtle> back to 1st question, binaries repository
20:07:54 <misc> yup
20:08:13 <misc> one of the goal of binrepos was to be able to clean it more easily
20:08:16 <boklm> the same needs to be done on binrepo I think
20:09:40 <boklm> binrepos is currently 45G
20:09:49 <misc> #info same treatement for binrepos
20:10:15 <pterjan> binrepos can be cleaned up
20:10:22 <pterjan> oops
20:10:31 * pterjan had missed some part of the discussion
20:10:54 <pterjan> I think we can recreate it with only latest version
20:11:02 <boklm> yes, we can do this
20:11:07 <Umeaboy> pterjan, misc, boklm, spturtle, AL13N: Hi!
20:11:24 <boklm> but as it's only 45G now, it's not really needed
20:11:40 <misc> when will it be needed ?
20:11:43 <pterjan> Umeaboy: Hi
20:11:56 <AL13N> Umeaboy: we are currently in meeting, so please wait until after meeting
20:11:58 <pterjan> boklm: well we can drop cauldron versions at each release I think
20:11:59 <boklm> misc: when we think it's too big and we want to save space
20:12:20 <Umeaboy> Okey.
20:12:30 <pterjan> boklm: when we will not have enough space to create new one ? :)
20:12:37 <boklm> :)
20:12:45 <AL13N> doesn't svn make sure there is no double storage for this?
20:12:53 <boklm> ok, so we can do it to check it can be done
20:13:13 <AL13N> i thought there was no double storage when branching off binaries
20:13:19 <misc> boklm: we can even do it on a specific copy, while we have enough space for several copy
20:13:37 <misc> AL13N: the goal is to remove old bnary so it doesn't grow
20:13:43 <misc> ie, remove history of svn
20:13:46 <boklm> so we can prepare the script to do it, and run it
20:14:36 <ahmad78> (I think it should be done before each release... but that depends on how much time it takes)
20:14:50 <AL13N> misc: what if the binaries stay the same during several releases?
20:15:09 <AL13N> misc: won't removing/reuploading actually do make doubles?
20:15:38 <misc> AL13N: I hink you may now have understood the issue
20:16:00 <misc> AL13N: we take the svn, we erase it and we repopulate it with the latest checkout
20:16:16 <misc> ( or something like that )
20:16:19 <boklm> we keep only last revision
20:16:19 <AL13N> oh, you mean completely removing it?
20:16:56 <misc> yes
20:17:04 <boklm> something like this: http://robmayhew.com/delete-parts-of-subversion-history/
20:17:06 <erzulie> [ Delete parts of subversion history | Rob Mayhew ]
20:17:29 <shikamaru> some kind of svn rebase -i ? :-)
20:18:24 <misc> ok so I propose to postpone this to the complete freeze or after ?
20:18:44 <ennael> well we may have to update packages in last minute
20:19:00 <ennael> in fact until final isos are done
20:19:11 <misc> so after
20:19:13 <ennael> that's the fun part of release
20:19:25 <boklm> we can do this at the same time as we branch svn
20:19:52 <Saleem> hello
20:20:03 <ennael> Saleem: please meeting in progress
20:20:07 <ennael> wait for end of it
20:20:42 <misc> if we decide to support 2 releases, would it mean we need to keep the binary of the older releases too ?
20:21:09 <AL13N> misc: i think yes
20:21:12 <Saleem> sure i can wait ennael , thank you for your concern
20:21:58 <saispo> why versionning binaries ?
20:22:07 <boklm> misc: yes, binaries in svn://svn.mageia.org/svn/binrepos/cauldron/[package]/branches/[release]
20:22:25 <misc> boklm: so that mean we will carry forever the binary of every release ?
20:22:33 <anaselli> but only in branch though
20:22:42 <boklm> misc: until we decide to remove them
20:22:50 <anaselli> old binaries can be removed from trunk or not?
20:22:57 <boklm> when cleaning binrepos, we also need to remove svn://svn.mageia.org/svn/binrepos/cauldron/[package]/releases
20:23:08 <misc> but let's say
20:23:28 <misc> we release, for revision 10, we branch
20:23:37 <misc> then we drop revision 1 to 9
20:23:49 <misc> later, we release, we drop 10 to 19
20:24:01 <misc> will revision 20 still old the binary ?
20:24:10 <boklm> which binary ?
20:24:31 <misc> one that was committed in , let's say 5, and later copied at revision 10
20:24:40 <boklm> yes, if the directory still exists and was not removed
20:24:55 <anaselli> well misc in branch it should
20:24:59 <AL13N> misc you should drop 11 to 19, so 10 is still there
20:25:13 <misc> AL13N: but that's not how thing work afaik
20:25:14 <AL13N> if 10 and 20 are equal, it'll not take any extra space
20:25:31 <misc> ie, you cannot say "I drop this part and this part of the history"
20:25:38 <AL13N> misc: but how can we do update against release-2
20:26:28 <AL13N> maybe we should not have used svn for binrepos? and just used a <package>/<release> directory?
20:26:45 <boklm> AL13N: I think you don't understand something
20:27:01 <AL13N> boklm: likely
20:27:12 <misc> anyway, let's do some test and see how it goes
20:27:49 <misc> #action do test after the release , keep in mind potential issues with multiple releases
20:27:54 <misc> #undo
20:27:54 <Inigo_Montoya> Removing item from minutes: <MeetBot.items.Action object at 0x828fc6c>
20:28:24 <misc> #action do test of svn cleaning on a copy of binrepos, real cleaning should be done _after_ the release , keep in mind potential issues with multiple releases
20:28:29 <saispo> or other idea is to implement in rpm (or other tools) a wrapper to download need tarball for building and push them into a repo ?
20:29:05 <misc> saispo: can we see that later ?
20:29:17 <misc> the goal is not to rewrok the system in a 2 weeks timeframe
20:29:22 <anaselli> saispo: if url changes... that does not work
20:29:24 <saispo> and see a soluton for automatically cleaning ans separate the repos in releasemgaversion/binaries
20:29:27 <saispo> misc: ok :)
20:29:49 <saispo> anaselli: the packager must use rpmlint and check their specs before pushing :)
20:29:59 <misc> anyway, i guess we can fnish with secteam review
20:30:05 <saispo> anaselli: a copy is done on a mageai server since the lifetime of the release
20:30:06 <misc> #topic secteam review
20:30:16 <anaselli> misc: you can do some test by adding fake packages and removing binaries also... that should not make any breakage...
20:31:00 <misc> ok so last week ( I know that I had something to do )
20:31:06 <misc> http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-05-04-19.06.html
20:31:07 <erzulie> [ #mageia-dev Meeting ]
20:31:20 <anaselli> saispo: i thought you meant downloading from their sites :)
20:31:22 <misc> so, as seen before, there is still some bug to fix ( php, etc )
20:32:14 <misc> saispo wrote some ressources on : http://www.mageia.org/wiki/doku.php?id=security&s[]=security
20:32:14 <erzulie> [ security [Mageia temporary wiki] ]
20:32:55 <misc> and I didn't sent the mail for starting discuss, but stew did
20:33:33 <misc> https://www.mageia.org/pipermail/mageia-dev/20110516/004708.html
20:33:34 <erzulie> [ [Mageia-dev] Security Update Process ]
20:34:10 <misc> so if people didn't read the mail, I would suggest to do so and send comments to the list
20:37:24 <misc> any question about that ?
20:38:07 <saispo> nothing for me , i respond to the mail
20:38:29 <misc> ok so any other topic ?
20:38:44 <saispo> for mageia seed i see with ennael
20:39:00 <saispo> a release will comme for test since next week
20:39:10 <saispo> s/since/for/g
20:39:24 <misc> #topic others
20:39:49 <misc> saispo: for monday ?
20:40:55 <saispo> wednesday i prefer
20:41:07 <saispo> one week for releasing a good stuff
20:41:14 <saispo> and submit for testing
20:41:16 <misc> #info saispo will do a release of seed for testing purpose on next wenesday
20:43:15 <misc> ok so nothing to add ?
20:44:03 <Anssi> what about /tainted for mga1?
20:44:33 <misc> pterjan: ?
20:45:35 <Anssi> I guess we could do a temporary workaround for now (i.e. submit to tainted/release with tainted manually enabled in .spec)
20:46:19 <obgr_seneca> I think releasing without tainted stuff will be a major drawback
20:46:34 <misc> I would also be in favor of the workaround
20:46:43 * AL13N agrees with obgr_seneca
20:46:47 <Anssi> also, should we disable all the MPEG2/MPEG4/H.264/MP3 from the core/release versions of ffmpeg/mplayer/xine etc? since they are "clearly" patented and licensing programs exist
20:46:49 <obgr_seneca> people will not use Mga if they are not able to play their musinc/videos and so on
20:47:24 <pterjan> we need something for the workaround to work
20:47:29 <Nanar> a lot of people were using mdv because plf
20:47:33 <Anssi> for now they have been enabled as that is what mdv did, but there is no actual reason behind it
20:47:45 <spturtle> Anssi: that still requires changing the check for existing package in different section, and agreement on how to differentiate core from tainted package
20:47:45 <pterjan> if the distsuffix is not changed youri will reject upload
20:47:52 <pterjan> so at least that part is needed
20:48:03 <spturtle> ah with different suffix it will be accepted?
20:48:18 <pterjan> yes it will be higher than the one in core I think
20:48:21 <Anssi> spturtle: right
20:48:25 <obgr_seneca> perhaps add a ".1" manually for releases in tainted so they will update things from core?
20:48:30 <misc> we could have different suffix accepted in tainted for the time being, and change later
20:48:41 <spturtle> that can be done in the specfile as workaround (like plf)
20:48:53 <pterjan> indeed
20:49:03 <pterjan> we just need to define some macro when building
20:49:11 <pterjan> to say which media are enabled
20:49:34 <pterjan> actually, which media we are building for
20:49:38 <misc> Anssi: I would disable mp3 encoding on mplayer, yes, not for decoding as thompson said t would be ok (iirc last time I checked )
20:49:48 <misc> Anssi: for mpeg2, etc, I am not sure
20:50:07 <spturtle> pterjan: now you're talking about implementation, not workarounds (fine) - what are the problems currently?
20:50:33 <misc> now, given the fact we are in rc, I would also maybe not change much _now_ and postpone to later
20:51:04 <Anssi> misc: Thomson has a licensing program which charges per every software decoder: http://mp3licensing.com/royalty/
20:51:05 <erzulie> [ mp3licensing.com - Royalty Rates ]
20:51:06 <pterjan> we can just have iurt to be aware of that info and define something
20:51:10 <AL13N> can we release as-is? or is that not good?
20:51:35 <Anssi> and MPEG LA has a licensing program for MPEG-2, MPEG-4, H.264, VC-1
20:51:41 <AL13N> because all this change  needs to be tested too
20:51:44 <misc> Anssi: mhh, they changed their license then :/
20:51:50 <pterjan> spturtle: problem is mostly time :)
20:52:01 <ahmad78> one more issue, binary dkms packages aren't supported/built yet
20:52:40 <spturtle> misc: security updates will be a little annoying with that workaround AFAICT: one has to check in fix, upload for core, check in tainted config, upload for tainted
20:52:57 <AL13N> pterjan: how about we define macro for media: %media(core) \n %media(tainted,%mp2 %h261) or something
20:53:01 <misc> spturtle: yes , that's the whole point of automating everything
20:53:16 <Anssi> personally I don't care how do we determine if a codec belongs to tainted, but it should be *consistent*
20:54:05 <Anssi> currently we have random patented codecs in tainted and random ones in core, with no actual rule
20:54:37 <misc> Anssi: well, I guess that mp3 should be moved to tainted then
20:55:25 <misc> anyway, unless we decide in 6 minutes, the meeting is not the proper place ( or at least, I do not intend to discuss this during the whole night
20:55:25 <AL13N> perhaps someone who know about this stuff can start a draft on tainted policy
20:55:47 <AL13N> but it's not much use if we have no way to do tainted
20:55:48 <boklm> maybe we can keep as it is now for release 1, and improve later for next release
20:56:01 * AL13N kinda agrees with boklm for this
20:56:57 <Anssi> that's kind of ok as well, as long as this is not forgotten, I hate these inconsistencies (both with the non-free firmware we have in core and this some-codecs-in-tainted-some-in-core)
20:56:57 <spturtle> boklm: you mean upload the 'plf' packages to tainted after fixing distsuffix, without other changes in core or tainted packages?
20:57:14 <misc> Anssi: yup, you are right
20:57:58 <Anssi> .. and as long as we implement the workaround to have the current pkgs in /tainted
20:58:05 <spturtle> Anssi: you can start filing bugs and target them at Mageia 2 if you are worried it will be forgotten
20:58:32 <boklm> spturtle: I mean keeping patented software like mp3 in core for release one, even if that's not right, and fix it for release 2
20:58:35 <AL13N> perhaps just have the tainted ones an extra release
20:58:41 <AL13N> mkrel+1
20:58:47 <misc> #action postpone moving firmware and tainted codecs for the start of next developpement cycle
20:58:51 <Anssi> spturtle: probably better to do that later, more important things to do now  for mga1 I think :)
20:58:51 <AL13N> so, always build the core first
20:59:08 <spturtle> there are codecs missing right now
20:59:40 <Anssi> yes, AAC and AMR are disabled in core
20:59:41 <AL13N> can someone send email to #mageia-dev on current policy with tainted?
20:59:43 <Anssi> for example
20:59:46 <boklm> for missing codecs, maybe we can push them as updates in tainted after fixing distsuffix
20:59:47 <AL13N> so people know about this?
20:59:48 <Anssi> and MP3 encoding, H.264 encoding
20:59:53 <misc> AL13N: I think you can, yes
20:59:56 <spturtle> dts decoding support in ffmpeg
21:00:09 <Anssi> spturtle: hm?
21:00:10 <misc> #action AL13N send mail on -dev about tainted
21:00:11 <AL13N> misc: i don't fully understand the idea
21:00:22 <AL13N> misc: i don't want to send email on something i don't understand
21:00:23 <misc> AL13N: then ask to people to clarify it
21:00:32 <Anssi> spturtle: it is enabled
21:00:35 <AL13N> so, what exactly is decided?
21:00:53 <AL13N> will we just mkrel+1 or change distsuffix?
21:00:57 <AL13N> and how can we do that?
21:01:00 <AL13N> i have no idea?
21:01:01 <misc> AL13N: in fact, that's perfect, ask to explain until this is clear, so we will be sure it will be clear for people whereit was not clear before
21:01:09 <AL13N> ok
21:01:12 <AL13N> in this meeting?
21:01:15 <Anssi> we keep the current (mdv) codecs division, and submit pkgs in tainted/ by changing distsuffix ..  I think
21:01:16 <misc> I would say "change distsuffix"
21:01:25 <misc> AL13N: no, after
21:01:42 <AL13N> how is distsuffix changed?
21:01:45 <misc> using mkrel+1 is just asking for trouble, IMHO
21:02:00 <Anssi> yep
21:02:02 <misc> as this will have likely bad side effect on youri
21:02:03 <AL13N> what about key signature?
21:02:17 <AL13N> does it have to be different?
21:02:20 <misc> AL13N: that's the same keys
21:02:23 <AL13N> ok
21:02:45 <AL13N> what is the commands used to submit to tainted?
21:02:53 <AL13N> and change distsuffix?
21:02:57 <spturtle> --define section=tainted/release
21:03:05 <AL13N> or is distsuffix changed in spec file?
21:03:09 <spturtle> distsuff -> change in specfile, then change back for core
21:03:18 <AL13N> so commit and commit again
21:03:20 <AL13N> :-(
21:03:25 <AL13N> sounds like a bad workaround to me
21:03:30 <pterjan> we can probably easily do better
21:03:36 <AL13N> pterjan: how so?
21:03:56 <pterjan> defining the distsuffix depending on the target media
21:03:57 <AL13N> pterjan: how about iurt changing it, when tainted is specified?
21:04:02 <AL13N> ah yes
21:04:13 <AL13N> pterjan: can this be done in time, also with testing?
21:04:42 <pterjan> well it is a matter of defining target media during build, which is quite easy to test
21:04:55 <misc> ok, can you discuss technical details later, at least the time to finish the meeting ?
21:05:01 <pterjan> k
21:05:03 <AL13N> #action pterjan modify BS to automagically change distsuffix if submitted to tainted
21:05:08 <AL13N> :-D
21:05:23 * AL13N is not chair
21:05:25 <misc> anything to add on another topic ?
21:05:51 <AL13N> no
21:05:58 <obgr_seneca> no
21:06:53 <misc> good, so I can finish the meeting
21:07:01 <misc> thanks for coming, do not forget that release is near
21:07:06 <misc> #endmeetng
21:07:09 <misc> #endmeeting