20:03:54 <misc> #startmeeting
20:03:54 <Inigo_Montoya`> Meeting started Wed Mar  9 20:03:54 2011 UTC.  The chair is misc. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:54 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:55 <erzulie> [ MeetBot - Debian Wiki ]
20:04:04 <misc> #chair misc ennael shikamaru
20:04:04 <Inigo_Montoya`> Current chairs: ennael misc shikamaru
20:04:11 <misc> #name Packagers meeting
20:04:29 <misc> so, first topic
20:04:49 <misc> #topic Gnome 3 status
20:05:32 <misc> as people who spend lots of time reading others projects planet, there is currently lots of discussion regarding gnome 3 for Fedora, with lots of change coming
20:06:17 <brianb> hi
20:06:43 <misc> as we try to focus on having a release ready, and as we do not have much dedicated gnome people so far ( ie i have seen blino and pterjan uploading stuff )
20:07:11 <misc> I would suggest that keep gnome 2.30 as a default option for the moment
20:07:26 * Nanar agreed
20:07:26 <andre999> good idea
20:07:27 <shikamaru> sounds sensible
20:07:28 <AL13N> i have no real opinion on that, so i would rather not have something that isn't welltested, so me personal preference is the same
20:07:29 <ahmad78> without a sufficient gnome team, gnome 3 not feasible for now
20:07:42 <AL13N> ok, next topic? :-)
20:07:44 <shikamaru> has anyone bothered trying live gnome3 images ? http://gnome3.org/tryit.html
20:07:45 <erzulie> [ GNOME 3 - Made of Easy ]
20:07:52 <misc> #agreed keep gnome 2.30 for the first release
20:08:02 <Nanar> I think we must focus on having a working distro
20:08:14 <andre999> shikamaru: not yet
20:08:19 <AL13N> well, that was a fast topic :-)
20:08:43 <Nanar> now same question with rpm5 /o\ (I am kidding)
20:08:49 <misc> shikamaru: nope, but I plan to update my laptop to f15 soon
20:08:51 <ahmad78> :)
20:08:56 <shikamaru> #info images for gnome3 testing are available for testing at http://gnome3.org/tryit.html
20:08:56 <erzulie> [ GNOME 3 - Made of Easy ]
20:09:08 <mitya> may sound stupid, but why not 2.32?
20:09:10 <misc> ( made by fcrozat, ex mandriva )
20:09:13 <AL13N> lol @ Nanar
20:09:20 <misc> mitya: i think 2.32 is gnome 3
20:09:44 <misc> but this should indeed be a option if I am wrong
20:09:44 <shikamaru> mmh are you sure ?
20:10:00 <mitya> http://library.gnome.org/misc/release-notes/2.32/
20:10:01 <erzulie> [ GNOME 2.32 Release Notes ]
20:10:05 <shikamaru> I use evolution at work and 2.32 was not that different than 2.30
20:10:23 <misc> indeed, I am wrong 2.32 is the last release
20:10:26 <mitya> the link above refers to the stable release
20:10:33 <misc> mitya: yup
20:10:46 <misc> what version do we have now ?
20:11:06 <ahmad78> evolution-2.32.1-
20:11:08 <shikamaru> 2.32
20:11:10 <misc> ok
20:11:19 <misc> #undo
20:11:19 <Inigo_Montoya`> Removing item from minutes: <MeetBot.items.Link object at 0x82aa26c>
20:11:20 <misc> #undo
20:11:20 <Inigo_Montoya`> Removing item from minutes: <MeetBot.items.Info object at 0x82aadac>
20:11:31 <misc> #agreed keep gnome 2.32 for the first release
20:11:34 <ahmad78> (the gtk3 stuff are all *.9x*, from what I've seen)
20:11:40 <misc> #info images for gnome3 testing are available for testing at http://gnome3.org/tryit.html
20:11:40 <erzulie> [ GNOME 3 - Made of Easy ]
20:11:53 <misc> mitya: thanks for noticing :)
20:11:55 <andre999> agreed
20:12:08 <shikamaru> fine :)
20:12:20 <misc> ok so next topic
20:12:35 <AL13N> k
20:12:37 <misc> #topic review on mentoring sessions
20:12:51 <misc> I guess shikamaru will have something to say ?
20:13:00 <shikamaru> yep
20:13:16 <shikamaru> so, we just made an unformal meeting before the meeting
20:13:29 <shikamaru> the current status of mentoring is the following
20:13:58 <shikamaru> at the moment, trainees are doing a very good job, but still need to be accompanied for quite some time
20:14:39 <shikamaru> some of them might get submission rights, because they are now familiar with the bs, and just need some attention (understand, peer review)
20:14:43 <misc> #info trainees are doing a good job so far
20:15:01 <shikamaru> some new trainees might get mentored too
20:15:28 <shikamaru> I decided to mentor andre999, because he did it very well with his 3 first packages :)
20:15:40 <andre999> :)
20:16:00 <Nanar> can I add somethings ?
20:16:07 <misc> yes
20:16:11 <shikamaru> yep
20:16:19 <Nanar> at time the big work is importing packages
20:16:38 <Nanar> but in real life, the big works on a distro is updating packages
20:16:46 <Nanar> which is different
20:17:00 <Nanar> we must ensure trainees see both side
20:17:07 <shikamaru> you’re right, that’s part of the mentoring process I think
20:17:08 <Nanar> especially the second one
20:17:18 <misc> indeed
20:17:27 <shikamaru> since some of the packages are outdated
20:17:42 <shikamaru> maybe a good exercise for trainees is to import them verbatim in svn
20:17:48 <AL13N> (some of the importing also does updating to new version)
20:17:48 <Nanar> but keeping mageia stable mean less update
20:17:50 <shikamaru> and update them afterwards
20:18:03 <Nanar> yes
20:18:05 <AL13N> (and forwarding patches)
20:18:25 <Nanar> but in same time we try to avoid update because it can break the distro
20:18:48 <andre999> I think that focus on import now will get us to release faster
20:18:55 <Nanar> just pointing this uncommon parts of packaging at time
20:19:03 <andre999> with less pain
20:19:11 <shikamaru> it depends on what update means, if it’s updating to a stable version, I guess that’s not a big deal, it’s part of the process to check dependencies are not broken after the update
20:19:23 <misc> andre999: well, release will happen at the planned date, not because we imported more package
20:20:07 <Nanar> shikamaru: yes of course, but for some packages stable release or not is just a random number ;)
20:20:12 <andre999> misc: ok - I was just thinking of avoiding problematic updates that could cause delays
20:20:13 <misc> #info mentor should take in account maintainence issue for trainee
20:20:14 <shikamaru> but I recall we were talking about appliances with a test vm
20:20:39 <shikamaru> that would be a great idea to help trainees, as well as regular packagers, to test that packages are not broken
20:20:50 <misc> well, afaik, AL13N proposed to do something
20:20:52 <misc> AL13N: ?
20:21:12 <shikamaru> it would boil down to clone the vm, install the packages and some of the dependencies, test, and destroy the clone if it’s ok :)
20:21:34 <AL13N> hmm, i did what?
20:21:44 <AL13N> ah yes
20:21:47 <AL13N> vm appliance
20:22:06 <AL13N> i wanted to have a sort of buildnode in a vm
20:22:20 <AL13N> for people to use for testing purposes
20:22:29 <shikamaru> #info mentors should check their trainees are also able to maintain packages, not only clean them and import them
20:22:32 <stewbintn> imho, that's something that should be installed in new packagers, to actually run what they package and not leave it to the users
20:22:46 <stewbintn> instilled*
20:22:55 <ahmad78> I agree with stewbintn
20:22:57 <misc> AL13N: yes, and so have you worked on it ?
20:23:07 <AL13N> stewbintn: you mean, there are people that have packaged stuff that they don't test?
20:23:08 <ahmad78> (the best maintainer of a package, is a packager who uses it)
20:23:27 <Nanar> AL13N: sure /o\
20:23:30 <stewbintn> AL13N: well, if they carried the tradition from mandriva, I'd say yes
20:23:33 <AL13N> misc: i didn't do any work on it yet, except locally a bit, problem is that i don't know enough of buildsystem to realise
20:23:46 <shikamaru> AL13N: yes, lack of testing is the primary reason breakage happen
20:23:52 <AL13N> O_O
20:23:56 <andre999> I've been installing the packages I imported on my system
20:24:08 <andre999> so far, all things I use
20:24:11 <misc> AL13N: well, you just need to have rpm-build installed in a vm...
20:24:13 <AL13N> misc: if i can have a little bit of help from someone knowing buildsystem i could do it
20:24:24 <AL13N> misc: well, i wanted a bit more
20:24:27 <shikamaru> having a test grid for packages would be nice, but that’s another topic which should be discussed with qa team
20:24:38 <misc> AL13N: well, just post on -dev
20:24:43 <AL13N> misc: automatic dependencies, and chroots inside vm
20:24:55 <AL13N> building for both arch at the same time
20:24:59 <AL13N> that sort of thing
20:25:06 <misc> #action AL13N post on -dev to expose what he need
20:25:11 <AL13N> ok
20:25:22 <shikamaru> ready to help you dude :)
20:25:36 <misc> so, for mentoring session, ennael ( who added the topic on agenda ), wanted to know how the proposal of last week went
20:25:38 <shikamaru> back to mentoring
20:26:01 <misc> ie, try to organize some hours where dedicated people are on the #mageia-mentoring channel
20:26:14 <misc> so, did people found avaliable slots ?
20:27:02 <stewbintn> calendar looks empty
20:27:03 <shikamaru> I should have subscribed myself to the calendar, didn’t have time this weekend
20:27:20 <shikamaru> will do next week-end
20:27:59 <misc> stewbintn: yes, hence my question from timeslot rather than asking for people to subscribe :)
20:28:16 <Dr_ST_home> hi people, sorry for the delay
20:28:19 <misc> hi Dr_ST_home
20:28:19 <Stormi> calendar is empty, but were there unanswered questions in #mageia-mentoring ?
20:28:24 <shikamaru> Dr_ST_home: welcome
20:29:00 <misc> Stormi: I do not think, but I do not read much logs :/
20:29:02 <shikamaru> Stormi: not sure about that, some experienced packagers out there are helping people :)
20:29:16 <shikamaru> but maybe that should be advertised a bit more I think
20:29:35 <Stormi> so the objective of this calendar is rather to say to mentored people "hey, at this time you're sure to find people there" ?
20:29:37 <shikamaru> especially among packager volunteers that have written their names on the wiki
20:29:42 <stewbintn> I lurk, help when I can, but can't really schedule a slot
20:30:08 <misc> Stormi: yes
20:30:20 <misc> stewbintn: so do i
20:30:27 <anaselli> misc: has missing package deps been already discused?
20:30:31 <misc> ( except that I do not help much )
20:30:33 <misc> anaselli: not yet
20:30:39 <anaselli> ok
20:30:48 <philippeM> same for me hard to schedule
20:30:48 <anaselli> mentoring was after :)
20:30:52 <misc> anaselli: /lastlog #topic  on irssi
20:31:12 <anaselli> thanks
20:31:44 <misc> #info schedule can be hard to garantee for people
20:32:06 <AL13N> *guarantee
20:32:09 <misc> but we are not obliged to be present all week on it, maybe just trying to have at least 1 slot would be enough
20:32:12 <misc> #undo
20:32:12 <Inigo_Montoya`> Removing item from minutes: <MeetBot.items.Info object at 0x83085ac>
20:32:27 <misc> #info schedule can be hard to guarantee for mentors
20:32:51 <AL13N> perhaps a timeslot where there's higher chance you are available
20:33:10 <AL13N> i mean, we're people, we plan, we can never really guarantee availability on a certain timeperiod
20:33:46 <Nanar> but I can warranty when I'll won't be availlable
20:34:02 <andre999> Nanar: that's good :)
20:34:31 <misc> well, let's say that we try to be on tuesday on the chan, at least one person ?
20:34:35 <misc> and advertise it ?
20:35:16 <andre999> misc: good idea - not realistic to expect firm guarantees
20:35:21 <AL13N> Nanar:  has a good idea
20:35:32 <Nanar> me ?!
20:35:32 <AL13N> what if we advertise when we will NOT be available?
20:35:38 <shikamaru> AL13N: yes that’s the point, since we are all in a different timezone :)
20:35:40 <AL13N> that would be more usefull
20:35:51 <misc> andre999: if we do not try to have some date, people will never do it :)
20:36:07 <andre999> misc: true :)
20:36:27 <misc> AL13N: what is the use of saying "do not be at this moment, this person is not present" ?
20:37:04 <AL13N> well, if all mentors do this
20:37:09 <Nanar> I can find an evening
20:37:16 <Nanar> in the week
20:37:26 <AL13N> what is left is a schedule where one can find out when most mentors will be there
20:37:28 <Nanar> maybe two, not more at time
20:37:30 <andre999> maybe we could have "possibly available" and "probably available" ?
20:37:33 <Nanar> except miracle
20:37:54 <misc> this sound quite complex
20:37:56 <Stormi> the simpler the better, so defining slots in advance looks good to me
20:38:02 <Stormi> like misc said :
20:38:09 <AL13N> misc: otoh, if you make it so that it's not 100% guaranteed that the person is there, then you will have more slots
20:38:15 <Stormi> there are mentors on tuesday and this and that evening
20:38:24 <Stormi> and then we try to hang there
20:38:37 <Stormi> + say in other times you have chances to find someone all the same
20:38:45 <misc> with enough mentors, it should be ok I guess
20:39:03 <Nanar> I can try sunday evening
20:39:04 <andre999> Stormi: sounds like a good approach
20:39:49 <misc> ok so can people think of a slot, I will send a mail to summarize this
20:40:05 <Nanar> sending email to who ?
20:40:10 <misc> on -dev
20:40:13 <Nanar> ok
20:40:19 <misc> #action misc send a mail on -dev to follow up about tuesday and sunday proposal
20:40:23 <anaselli> shouldn't timezone written here: http://www.mageia.org/wiki/doku.php?id=packaging&s[]=packager#list_of_registered_people
20:40:24 <erzulie> [ packaging [Mageia temporary wiki] ]
20:40:42 <andre999> it might be a good idea to indicate approx time of day also
20:40:45 <Stormi> I think we should guarantee some presence on week-ends
20:40:50 <anaselli> that should help to understand when people could be in
20:41:15 <misc> andre999: I was thinking of day + hour, yes ( utc )
20:41:29 <anaselli> i'm not a mentor, but when my pc is on i'm into #mageia-mentoring
20:41:39 <Stormi> and really insist on the fact that people can come outside those timeslots, because there usually is one or more mentor (or fellow trainee) available
20:41:42 <andre999> misc: good :)
20:41:53 <misc> anaselli: yup, but we asked to people to put the timezone, they didn't we cannot do much :)
20:42:24 <shikamaru> agree with Stormi
20:42:36 <shikamaru> anything to add to that topic ?
20:42:38 <anaselli> misc: maybe asking mentors for adding it?
20:43:45 <shikamaru> ok
20:43:56 <misc> anaselli: well, they know the timezone of people they work with
20:44:10 <anaselli> misc: good point :)
20:44:12 <misc> maybe pushing this to ldap would help, but that's a topic for another discussion
20:44:26 <misc> anyway, next topic ?
20:45:22 <Nanar> yes
20:46:07 <misc> #topic upgrade tests
20:46:42 <Nanar> by upgrade you mean mdv => mga ?
20:46:54 <misc> yes
20:47:10 <anaselli> mdv 2010.[1|2] right?
20:47:11 <shikamaru> mdv 2010.1/2 -> mga 1
20:47:14 <misc> we discussed of adding bugs of upgrade on the tracker bugs https://bugs.mageia.org/show_bug.cgi?id=56
20:47:15 <erzulie> [ Bug 56 - [TRACKER] tracker report for upgrade issues ]
20:47:24 <misc> and well, there is no bugs
20:47:34 <Nanar> good !
20:47:34 <misc> and I didn't see much report of upgrade
20:47:34 <Stormi> \o/ upgrade is perfect
20:47:48 <AL13N> lol
20:47:51 <misc> so am I the only one to have issue when i did the upgrade ?
20:48:00 <misc> or did bugzilla broke, or stuff like that ?
20:48:03 <AL13N> misc: you had issues you didn't report?
20:48:03 <Nanar> no
20:48:06 <Stormi> I haven't done any upgrade yet
20:48:10 <anaselli> my upgrade failed... but i'll focuse it on alpha2
20:48:12 <shikamaru> misc: I only had one weird issue
20:48:20 <shikamaru> I’m not sure to reproduce it in a reliable way
20:48:28 <misc> AL13N: I have sent mail on -dev
20:48:34 <andre999> i had no problem with upgrades from mdv
20:48:49 <misc> shikamaru: being unclear and unreliable never prevented bug report to be entered :)
20:48:57 <shikamaru> misc: I opened it
20:49:00 <Nanar> firsty issue I see is some xfce packages are missing...
20:49:09 <shikamaru> but I should have made it block the tracker bug
20:49:18 <AL13N> so, that means, there are bugs, but not added to tracker?
20:49:21 <Nanar> which mean xfce users will get problems...
20:49:26 <misc> AL13N: basically yes
20:49:32 <misc> I assume that everybody forgot
20:49:42 <AL13N> i didn't test upgrade
20:49:43 <misc> ( i also forgot before reading again logs 3 minutes ago )
20:49:48 <anaselli> i'd expect more after alpha2
20:50:04 <anaselli> since we start testing days...
20:50:10 <AL13N> i have cloned my mdv, i'm kind of waiting for alpha2
20:50:50 <ahmad78> Nanar: such as?
20:50:59 <shikamaru> misc: https://bugs.mageia.org/show_bug.cgi?id=210 this one :)
20:51:00 <erzulie> [ Bug 210 - Upgrade from 2010.2 fails because some files are missing ]
20:51:04 <misc> #info the tracker bug for upgrade is https://bugs.mageia.org/show_bug.cgi?id=56
20:51:06 <erzulie> [ Bug 56 - [TRACKER] tracker report for upgrade issues ]
20:51:16 <Nanar> ahmad78: not enough history in konsole
20:51:27 <misc> well, is everybody at least familliar with bugzilla ?
20:51:41 <Nanar> ahmad78: but I'll when my seesion will reboot
20:51:52 <ahmad78> Nanar: ok, thanks
20:52:12 <AL13N> i haven't done dependencies, though
20:52:17 <AL13N> how does something work like this?
20:52:26 <Nanar> using vbox to test upgrade is another way
20:52:30 <AL13N> i had kind of assumed triage team would handle that >_<
20:52:30 <misc> ahmad78: since I am not sure, can you tel us how it should be done ?
20:52:37 <anaselli> i seem to recall one mine somwhere
20:52:42 <misc> ( ie, added on blogs, depends on ? )
20:52:51 <anaselli> with drakfiles attached...
20:52:57 <misc> AL13N: well, even if triage team do, we can help them
20:53:01 <AL13N> misc: do you mean blocks?
20:53:07 <misc> AL13N: yes
20:53:16 <misc> ( especially since triage team is 1,5 person at the moment )
20:53:20 <AL13N> do i just add a bug nummer in there? or link?
20:53:23 <ahmad78> misc: the other reports block the tracker bug
20:53:30 <ahmad78> (if that's what you mean)
20:53:46 <AL13N> so do we add #56 on our own bug?
20:53:53 <AL13N> is that what we should do?
20:53:53 <misc> yes, in blocks
20:53:57 <shikamaru> AL13N: yes, in the blocks field
20:54:14 <AL13N> and dependencies what is that then?
20:54:19 <AL13N> does that get autofilled in?
20:54:24 <misc> AL13N: the reverse, and yes
20:54:31 <AL13N> ok
20:54:36 <philippeM> I just added mine about kernel-netbook, I forgot to link it to 56 sorry
20:54:51 <AL13N> so if people had blocked on #56, #56 dependencies would have shown something
20:55:02 <AL13N> unless it's broken...
20:55:03 <ahmad78> AL13N: wait and see
20:55:04 <misc> AL13N: yes
20:55:25 <AL13N> oh, looks nice
20:55:28 <ahmad78> philippeM: no problem, hopefully triage will get to it before Judgement day :)
20:55:55 <ahmad78> philippeM: but of course now you know, so you can do it yourself :)
20:55:59 <misc> ok so next topic ?
20:56:04 <Nanar> we have an issue only on i585 about noarch
20:56:17 <philippeM> ahmad78: I did
20:56:27 <Nanar> this can create bugs on only some cases
20:56:30 <Nanar> also
20:56:39 <misc> Nanar: then this should be reported, I guess ?
20:57:17 <Nanar> misc: planned
20:58:01 <misc> ok
20:58:06 <misc> so next topic ?
20:58:09 <shikamaru> yep
20:58:23 <misc> so
20:58:42 <misc> "Think about basic rules for packages updates during development release"
20:58:51 <misc> #topic basic rules for packages updates
20:59:09 <ahmad78> major changes should be discussed and announced on the -dev ML
20:59:15 <misc> so as we are soon to release, and to prevent last minutes breakage, we try to avoid too much breakage
20:59:40 <ahmad78> and the version freeze should be announced on the ML as a reminder
20:59:43 <misc> yet, some may happen by errors, and so we should 1) find a way to warn people or to block them ( temporary )
21:00:07 <misc> ahmad78: yup :/
21:00:19 <misc> #info send reminder for freeze on ml
21:00:30 <ahmad78> misc: the problem with that was, too much work for ppl with submit permissions during freeze...
21:00:45 <misc> ahmad78: yes, hence the question of finding a better system
21:00:53 <AL13N> can we still add new packages (unimportant ones)?
21:01:20 <misc> AL13N: as said before, if the package do not obsoletes half of the system, yes :)
21:01:34 <misc> but if this was as simple as that, this could be done
21:01:48 <misc> the question is "how can we automate without being too painful"
21:02:06 <AL13N> do we actually need to do the freeze?
21:02:16 <AL13N> doesn't just warn people work?
21:02:23 <AL13N> there aren't much packagers atm anwyay
21:02:33 <shikamaru> a thing that could be done for core packages would be to rebuild a test chroot with packages and try to build a dummy package, then reject the package for the real chroot if it fails
21:02:36 <Nanar> just warning doesn't work with some of them
21:02:42 <shikamaru> I remember seeing this
21:02:51 <misc> yes, but genuine errors can still happen , and the less manual rules we put, the less error we will have
21:03:12 <misc> I would prefer to not have to think if I can or cannot do stuff
21:03:27 <andre999> how about a script that would refuse to build something which doesn't have non available requires
21:03:36 <andre999> during the critical period
21:04:00 <boklm> andre999: that's not really a problem of missing requires
21:04:19 <misc> well, the exact requirement of what is exactly causing issue is more ennael duty
21:04:28 <misc> byt she is not here ( yet )
21:04:29 <Nanar> the pb is more "the software does not work anymore"
21:04:57 <AL13N> but that is hard to make sure
21:05:05 <Nanar> of course
21:05:21 <Nanar> but we know changing major version is dangerous
21:05:23 <misc> I guess we could have a list of package to watch for iso creation
21:05:47 <misc> because changing the major version of libstuff is not a problem if that used by 3 people
21:05:49 <ahmad78> misc: that might be hard, those packages have deps on other packages... etc
21:05:50 <AL13N> it's my opinion that we should not do something that requires too much resources
21:05:55 <misc> while new gcc would be
21:06:09 <misc> ahmad78: well, fedora as the concept of critical path
21:06:43 <misc> https://fedoraproject.org/wiki/Critical_path_package
21:06:45 <erzulie> [ Critical path package - FedoraProject ]
21:06:47 <boklm> AL13N: oh, so you don't think we should do something that require too much resources ?
21:07:08 <misc> we can try to have the same list of package that we should watch
21:07:39 <AL13N> boklm: well, i believe human resources are usefull for other stuff than implementing new freeze features, but that's IMHO
21:07:47 <misc> having pino not working do not block iso. having perl would
21:08:03 <boklm> or we can watch packages for which there is more than N packages which depends on it
21:08:41 <misc> boklm: erlang being broken may not impact much :)
21:08:47 <ahmad78> misc: ok, reading looks interesting indeed
21:08:50 <misc> and I doubt many package depend on busybox
21:08:53 <andre999> I like the critical path concept
21:09:40 <misc> maybe we can ask to iso makers the list of stuff that should never be broken and apply the freeze just on that ?
21:10:28 <anaselli> misc: the idea is good... but if you use fc you know sometimes upgrades have trouble anyway....
21:10:34 <AL13N> how hard is the freeze? on "name-version" or "name-version-release" ?
21:10:36 <ahmad78> misc: building on fedora method would be a goot starting point
21:10:42 <ahmad78> good
21:10:56 <misc> anaselli: the idea is not to copy them, but to know what should be watched to not prevent iso creation
21:11:04 <Dr_ST_home> btw, is there any list of "priority" packages in mageia? I'm more "scientific-oriented" for packages, dunno if I can import them now or not
21:11:09 <misc> now, i would also see the methodology used by others distros
21:11:20 <andre999> misc: should be sure to include packages with lots of dependancies
21:11:20 <boklm> misc: if more than 50 packages depend on one package, I think it's probably an important one
21:11:22 <anaselli> misc: i see :)
21:11:34 <misc> boklm: transitive or not ?
21:11:39 <boklm> yes
21:11:54 <andre999> boklm: maybe we should say 10 ?
21:11:56 <boklm> for example for perl:
21:11:56 <boklm> $ urpmq --whatrequires-recursive perl | wc -l
21:11:57 <boklm> 3303
21:12:07 <AL13N> holy hell
21:12:22 <Nanar> boklm: and only one package requires basesytem-minimal
21:12:24 <misc> boklm: we could try, could you produce a list ?
21:12:38 <Nanar> is it important ?
21:12:40 <boklm> misc: yes
21:12:51 <andre999> perl packages are a mess -- broken up to finely
21:12:59 <ahmad78> nope
21:13:09 <boklm> Nanar: yes, there are also important packages where nobody depends on them
21:13:13 <ahmad78> andre999: you're judging by?
21:13:22 <misc> #action boklm  produces list of package that are required by more than 50 rpms
21:13:42 <misc> $ urpmq --whatrequires-recursive xmoto | wc -l
21:13:42 <misc> 1
21:13:43 <boklm> Nanar: but we can still use this number to find some of the important packages
21:13:55 <misc> mhh, the list is incomplete if xmoto is not in the list
21:14:04 <shikamaru> :]
21:14:09 <boklm> hmm, yes
21:14:32 <andre999> ahmad78: a myriad of tiny packages - instead of being collected into more manageable libraries
21:14:39 <AL13N> perhaps we can also add all the packages recursively in basesystem-minimal ?
21:14:51 <ahmad78> andre999: that's the way perl modules live
21:14:57 <misc> ok so next topic ?
21:15:03 <andre999> AL13N: we should
21:15:07 <AL13N> and how hard is the freeze? on "name-version" or "name-version-release" ?
21:15:17 <AL13N> or just completely blocked?
21:15:24 <andre999> ahmad78: unfortunately /:
21:15:44 <ahmad78> name-version
21:15:48 <misc> AL13N: in mandriva, we have freezed with review, ie people could still let packages go if asked
21:16:01 <ahmad78> unless with -release you change something fundamental in the package
21:16:02 <misc> so we can first get a list of important rpm, and later decide
21:16:12 <AL13N> perhaps we can also add all the packages recursively in basesystem-minimal ?
21:16:29 <AL13N> or is that a bad idea?
21:16:34 <misc> #info AL13N produces a list of package required by basesystem to be added to boklm list
21:16:40 <AL13N> i knew it
21:16:50 <andre999> :)
21:17:03 <AL13N> ok, next topic
21:17:19 <misc> so last topic except that I do not know what ennael planned exactly
21:17:27 <misc> #topic Deal with missing packages and dependancies import
21:17:48 <AL13N> afaik ennael asked use to deal with missing deps list before
21:17:51 <misc> so,  http://pkgsubmit.mageia.org/data/missing-deps.i586.txt
21:17:57 <ahmad78> by deal you mean package them?
21:18:09 <misc> mikala proposed a change to the list format, we should deploy it soon ( not commited yet )
21:18:12 <AL13N> or make them dissapear from list
21:18:18 <andre999> I'm going to work on importing (some) of the missing packages
21:18:22 <misc> boklm also proposed to deploy youri-check
21:18:23 <Nanar> so here I think a lot of them come from missing noarch I pointed earlier
21:18:36 <AL13N> ah
21:18:39 <AL13N> hmm
21:18:50 <Nanar> and for others, just import missing rpm...
21:19:00 <Nanar> and test your own rpms
21:19:06 <shikamaru> youri-check \o/
21:19:09 <Nanar> am I wrong here ?
21:19:09 <AL13N> http://pkgsubmit.mageia.org/data/missing-deps.x86_64.txt is a different list, bt
21:19:22 <AL13N> *btw
21:19:29 <anaselli> misc: important deps? or just deps :)
21:19:44 <ahmad78> Nanar: no you're not, but it's hard to test each and every package one submits...
21:20:11 <AL13N> ahmad78: it's possible if you have > 1000 packagers
21:20:19 <Nanar> adding a package rarelly remove dependencies
21:20:40 <Nanar> and currently we are mostly adding packages
21:20:44 <AL13N> Nanar: actually not true, i've seen people fix buildrequires but not all requires
21:20:47 <andre999> AL13N: we have > 1000 packagers ?
21:20:47 <Nanar> not updating one
21:20:49 <ahmad78> Nanar: no, adding packages adds new dpes
21:21:08 <anaselli> i planned to port task-edu and his missing deps, but i believe i can't do that before next week-end
21:21:09 <Nanar> so new packages are not tested
21:21:11 <misc> also, did people followed the thread initiated by ennael about iso content ?
21:21:20 <misc> anaselli: no problem
21:21:36 <anaselli> misc: freeze is until 15th?
21:21:47 <andre999> but adding packages can resolve deps also
21:21:57 <misc> anaselli: well, the freeze is just a formal one, asing to people to take care when updating stuff
21:22:28 <anaselli> just to know i can always do all on my machine and releasing/submitting after :)
21:22:29 <andre999> misc: I did
21:22:31 <AL13N> Nanar: perhaps not all subpackages are tested
21:23:00 <Dr_ST_home> bash is broken ?
21:23:02 <ennael> hi there... sorry for tonight, was having social life :)
21:23:09 <AL13N> np
21:23:14 <andre999> I (try to) test all I import
21:23:16 <AL13N> Dr_ST_home: packaging error
21:23:16 <misc> Dr_ST_home: mhh no
21:23:55 <anaselli> ennael: from a social to a virtual one... welcome :)
21:23:58 <Dr_ST_home> ok, so in short, if I wanna help, is there a list somewhere?
21:24:01 <AL13N> when the list says which packages are responsible, it'll be easier to spot
21:24:10 <boklm> Dr_ST_home: list of missing packages ?
21:24:22 <AL13N> http://pkgsubmit.mageia.org/data/missing-deps.x86_64.txt
21:24:22 <boklm> Dr_ST_home: http://pkgsubmit.mageia.org/data/missing-deps.i586.txt
21:24:26 <ennael> I can put one up to date from iso build also
21:24:37 <misc> AL13N: mikala is working on it, as said
21:24:53 <AL13N> misc: that's why i said "when"
21:24:56 <ahmad78> the list is wrong about bash... or some wrong file deps somewhere..
21:25:06 <Dr_ST_home> boklm: ok, but what this means, the package is imported and does not build? or the package is missing,
21:25:11 <AL13N> ahmad78: exactly
21:25:21 <Dr_ST_home> I don't trust the libjpeg62 is missing, for instance ...
21:25:29 <ennael> Dr_ST_home: missing packages
21:25:30 <boklm> Dr_ST_home: the package is missing (maybe on svn, but not on repository)
21:25:41 <stewbintn> yes, was just looking at that, I have it installed...
21:26:07 <AL13N> it could be a typo in correct requires, or the noarch problem mentioned by Nanar
21:26:36 <stewbintn> so how do things end up removed from repos?
21:26:54 <AL13N> either fix the problem having the bug, or packaging the required ones
21:27:13 <boklm> stewbintn: packages are removed when obsoleted by an other one
21:27:48 <misc> Dr_ST_home: this one should be fixed soon
21:27:57 <stewbintn> urpmq --sources tells me it's present @ibiblio (libjpeg62)
21:29:20 <boklm> stewbintn: not for me
21:29:41 <boklm> stewbintn: using distrib-coffee
21:30:15 <ahmad78> boklm: jpeg-turbo side effects?
21:30:19 <boklm> probably be cause libjpg-turbo was submitted and obsoleted libjpeg
21:30:21 <boklm> ahmad78: yes
21:30:27 <stewbintn> hmm, ok, organized chaos as usual :p
21:30:30 <misc> yes
21:30:37 <misc> anyway, anything to had on the topic ?
21:30:59 <misc> #info boklm proposed to deploy youri-check
21:31:13 <misc> #info mikala proposed a change to the script used to generate missing list
21:31:24 <andre999> should be indicate on the ml which packages on the list we are working on ?
21:31:30 <misc> http://svnweb.mageia.org/adm/puppet/modules/buildsystem/files/
21:31:30 <erzulie> [ [adm] Index of /puppet/modules/buildsystem/files ]
21:31:55 <shikamaru> andre999: it would be a good idea if you did that here indeed
21:32:10 <misc> andre999: well, i do not think this will change much, there is few collision, and we would lose more time coordinating that just doing the work twice from time to time
21:32:11 <andre999> ok :)
21:32:13 <shikamaru> that would prevent someone else to do it at the same time
21:32:23 <shikamaru> and would help people reviewing what you did :)
21:32:26 <misc> shikamaru: how often does it happen ?
21:33:15 <andre999> I was thinking of the list of missing dependancies from ennael
21:34:23 <AL13N> good point
21:34:29 <shikamaru> misc: well, it happened to oliver for kmess
21:34:35 <andre999> if everyone focuses on the list, there risks to be duplicates
21:34:55 <misc> we could say to people to commit first and later to clean ?
21:34:56 <AL13N> who will do the maven stuff? btw?
21:35:00 <shikamaru> for new packagers packaging can take quite some time and I can understand that one could be disappointed if that was for nothing :)
21:35:03 <AL13N> not me
21:35:11 <shikamaru> not that I mean it should be a general rule
21:35:19 <shikamaru> just to favor peer review for trainees
21:35:22 <misc> shikamaru: yup, indeed
21:35:29 <andre999> there are 265 packages in the list
21:36:13 <misc> well, I do not care much about people packaging my stuff, but I guss people who are newer can send package if they wish to warn others
21:36:45 <shikamaru> your idea to import package first and then work on it sound sensible yep
21:36:56 <misc> I guess this would satisfy people ( ie, if people do not send mail, they cannot complain that someone else did the job )
21:38:04 <misc> #info people should warn on ml if they wish to work for a long time on a rpm and do not want someone else to do the work
21:38:09 <andre999> I'm going to focus on gnome and some pilots
21:38:36 <AL13N> andre999: not gnome 3!!!
21:38:41 <misc> #info people can also import first and then work to avoid others packagers to do the same work twice
21:38:48 <misc> anyway, last topic
21:38:50 <andre999> no no gnome2 :)
21:38:57 <misc> #topic Others questions
21:38:59 <andre999> in ennael's list
21:39:12 <Nanar> 1) dev meeting are not on the claendar
21:39:15 <Nanar> calendar
21:39:21 <misc> indeed
21:39:22 <andre999> pkgs missing for alpha2
21:39:24 <misc> ennael: ?
21:39:25 <Nanar> 2) topic are sent very late
21:39:50 <misc> Nanar: well, yes, we should be better on this point :/
21:40:21 <AL13N> (also, we have team leader and backup, but who is representative?)
21:41:11 <andre999> the dev meeting was on last week, but missing this week and the next
21:41:18 <misc> andre999: yes
21:41:22 <ennael> added
21:41:40 <andre999> so the repeat function wasn't activated
21:41:41 <Nanar> ennael: thanks !
21:41:58 <ennael> Nanar: topic are sent late because we did not have time before
21:42:05 <ennael> feel free to propose some before
21:42:42 <Nanar> ennael: on calenar, the item is not evrey wenesday
21:43:11 <misc> indeed
21:43:32 <ennael> I have only 2 hands and google does not want to save my changes
21:43:40 <Nanar> ennael: ok ok
21:43:43 <ennael> so you will have to wait at least 5 minutes
21:43:46 <misc> ok
21:43:50 <Nanar> ennael: was in case you missed it
21:44:02 <misc> or in case you forgot your password /o\
21:44:09 * Nanar hide
21:44:14 <misc> ( or case socialisation involved alcohol )
21:44:35 <andre999> or all of the above :)
21:44:40 <ennael> maybe :)
21:44:42 <misc> anyway, that will close the meeting, who lasted more than planned
21:44:48 <AL13N> wait
21:44:53 <AL13N> also, we have team leader and backup, but who is representative?
21:45:04 <misc> AL13N: mhh no, the contrary
21:45:06 <AL13N> i remember council meeing asking on that
21:45:09 <AL13N> oh
21:45:17 <misc> https://epoll.mageia.org/vote/ISJTLYRT
21:45:19 <erzulie> [ Epoll: packagers representatives ]
21:45:38 <AL13N> so we have 2 representatives and no team leaders and backup?
21:46:08 <AL13N> iirc each team was to have a leader, backup and representative
21:46:18 <misc> iirc, we also decided to see this later
21:46:22 <andre999> aren't they shared functions ?
21:46:45 <AL13N> ok, as long as noone is missing from council group list
21:47:09 <andre999> I thought it was 2 representatives, one for council, the other team leader
21:47:11 <misc> ok so can we close ?
21:47:27 <misc> andre999: i guess we will need to clearly explain this if people are confused :/
21:47:31 <shikamaru> ok for me
21:47:31 <AL13N> afaik we still have 13 minutes
21:47:41 <misc> AL13N: meeting should last 30 minutes
21:47:43 <misc> AL13N: so no
21:47:44 <AL13N> lol
21:47:57 <andre999> ok :)
21:47:58 <misc> anyway thanks for coming
21:48:01 <misc> #endmeeting