QA/M20130821

From Wiki [en] OpenMandriva
< QA
Jump to: navigation, search


QA meeting

Time & Place

Place: #openmandriva-qa @ irc.freenode.net Date/Time: Tuesday 2013-08-21, 14:30 UTC

Agenda

1. 2013.0 remaining issues before Beta
2. Package update procedures

Summary

Summary

LOG

<Xu_R> Well, it's time...
<itchka> Xu_R: There is a voting system in Bugzilla. There is a python script which allows Bugzilla to be controlled by emails. There are lots of other extenstions that I havent't go my head round yet.
<itchka> It is
<Xu_R> itchka: link to voting system? and controllable by emails is fine by me
* bero (~bero@arklinux/developer/bero) has joined
<itchka> Hi bero
<bero> hi
<Xu_R> Right, agenda: 1. leftover tasks for 2013.0 before beta, and 2. package update system (e.g. how to approve packages for updates)
<itchka> NFS
<ben79> voting system and controllable by e-mail is fine here
<itchka> Bero and I talked about nfs and removed a patch which restored functionality. Blackcrack did some testing and found one problem
<itchka> nfs V3 didn't work. It turned out that rpc.statd wasn't being started this needs a fix to systemd
<itchka> Otherwise all seems good
<bero> Bigger issue for 2013.0: the latest perl-URPM update broke things. Xu_R: you may actually know more about this than I do
<bero> Global symbol "$db" requires explicit package name at /usr/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/URPM/Resolve.pm line 92.
<bero> Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/URPM.pm line 10.
<bero> BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.16.3/x86_64-linux-thread-multi/URPM.pm line 10.
<bero> Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.3/urpm/msg.pm line 8.
<bero> BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.16.3/urpm/msg.pm line 8.
<bero> Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.3/urpm.pm line 8.
<bero> BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.16.3/urpm.pm line 8.
<bero> Compilation failed in require at /usr/sbin/urpmi line 26.
<bero> BEGIN failed--compilation aborted at /usr/sbin/urpmi line 26.
<Xu_R> bero: Yeah, I know where it broke :c the patches we got from ROSA didn't help this
<Xu_R> bero: https://abf.rosalinux.ru/omv_software/perl-URPM/commit/82befd577ec2f752cbe0b05c1680b806f6bb4b86#diff-comment2181
<bero> In the worst case we can just revert
<itchka> Xu_R: were you able to find the pull req from Dennis Silakov?
<Xu_R> itchka: I haven't seen any, except for the patches to perl-URPM and urpmi?
<Xu_R> bero: if I can't fix it in time, I'll revert
<itchka> Xu_R: So now both are in and it's still broken?
<Xu_R> itchka: one of the perl-URPM patches broke it
* Pulfer (~kvirc@84-147-ppp.vntc.ru) has joined
<itchka> Xu_R: have the changes been propogated to the openmandriva2013 repo?
<Xu_R> itchka: no, AFAIK
<Xu_R> bero: we're migrating packages to use omv_software now, right?
<itchka> Good so we can still test new stuff
<Xu_R> has a mirror location been found?
<bero> itchka: no, but we need to pull in urpmi from cooker so updates are pulled from the right place
<bero> Xu_R: yes and yes (migrating to omv_software and mirror location)
<bero> I've patched urpmi with the new mirror list location too
<bero> so as far as I'm concerned we're ready for the beta as soon as you say we are ;)
<Xu_R> bero: doesn't drakx and omvonline need to be patched as well?
<Xu_R> bero: https://issues.openmandriva.org/show_bug.cgi?id=21
<bero> possibly... I didn't try them out... What I did test is urpmi.removemedia -a, then just call drakrpm and do everything through the UI -- that did add the correct cooker repo
<Xu_R> bero: oh, so the GUI did work?
<bero> yes, the gui (at least drakrpm) gets the mirror list from urpmi
<Xu_R> Ok, so that clears that up then
<itchka> Regards beta there are still some files some graphics files in the desktop area that are named Mandriva I saw some in the bootspash setup yesterday. They should be removed
<itchka> I think most of the Moondrake ones have gone now
<itchka> bero: Java status
<bero> basic stuff is working and we've decided not to care about the non-basic stuff for this release
<bero> so things are looking good there
<itchka> ok thanks
<Xu_R> I can confirm the JRE is working, so that's pretty much it for now anyways
<itchka> bero: Will the old installer be activated?
<bero> If we can get it to work
<bero> but it's not a must-have
<itchka> bero: One final problem those with nvidia are having problems getting a gui after install. Could we default to vesa or something
<bero> What driver are those with problems using?
<bero> nv, nouveau or binary?
<itchka> It seems nouveau for some and certainly binary for me (too modern)
<ben79> After initial install it's what system uses by default. In my case with GeForce 6150 it's nouveau usually.
* blackcrack (~blackcrac@HSI-KBW-149-172-249-127.hsi13.kabel-badenwuerttemberg.de) has joined
<ben79> And nouveau currently doesn't work on my system
<bero> We should probably just switch to nv then
<itchka> Also when trying to install nouveau from drakx it offers the nvidia binary drivers and if you say no it still installs them. This breaks my system.
<bero> AFAIK the status of nv is still that it works but doesn't provide any 3D acceleration at all
<ben79> nv doesn't work on my system.
<ben79> Don't know about others
<Xu_R> :/
* bero boycotts nvidia -- no way I can test
* blackcrack think, any shoud decide what he whant use buddy
* blackcrack think too, free live free way's
<itchka> bero: I can test and I know others who can too. Why not vesa? I suppose the livecd bit would look a bit tame.
<ben79> Well mine is onboard the mobo so it's only choice I have. I'm not only one with this condition.
<bero> Does vesa support higher resolutions on nvidia cards these days? It used to be somewhat limited
<Xu_R> It's still somewhat limited AFAIK?
<ben79> vesa is what I use and yes graphics are weak until one can get nvidia driver working.
<itchka> bero: Not sure how can we check?
<blackcrack> Bero.. the other question were works nvidia, mit welchen karten, then deside between vesa and nouveau and vesa .. with vesa can you boot all cards..
<bero> Try getting a box up in 1920x1080 or so w/ vesa
<ben79> vesa supports up to 1280x1024 where as my monitor is 1920x1080
<itchka> bero: what's worse yfor our reputation a blank screen and or limited graphics which can be improved after boot. It's a no contest as far as I can see
<bero> Agreed
<blackcrack> i have an GL2450 24" Monitor.. and vesa it is total okey
<itchka> All graphics cards support vesa
<blackcrack> +++1
<ben79> Does installer have install in 'Basic graphics mode' using xdriver=vesa? If someone installs this way could it be configured to use vesa after install?
* OnlyHuman (~chatzilla@unaffiliated/onlyhuman) has joined
<bero> That makes sense...
<blackcrack> +1
<itchka> +1
<blackcrack> Vesa works in 99% of cases
<blackcrack> classic installer use vesa
<blackcrack> 2.0
<blackcrack> this is a reason why it works well in VBox
<itchka> This stiil leaves the livecd.  It has to be vesa there too graphics setup needs to be after there is a desktop. At least then people get to see what is being offered
<Xu_R> bero: fixed perl-URPM, I think. I'll push it to Cooker...
<itchka> bero: Good man
<bero> Xu_R: Great, thanks
<blackcrack> +1
* bero has to enter a Linaro meeting, so I may be a little bit lagged now
<itchka> vesa for the beta? Sounds like a tune title
<Xu_R> Well, that takes care of 2013.0 remaining tasks...
<Xu_R> Anything else for 2013.0 remaining tasks?
<Xu_R> going once...
<itchka> not that I know of
<itchka> cmon Robert bang that gavel!!
<ben79> nor I
<Xu_R> Ok, next
<Xu_R> Package update process
<Xu_R> aka the process everyone has to follow after beta gets released
<Xu_R> We were discussing of utilizing Bugzilla for this process and having a karma system of some sort
<itchka> Robert shall we outline our discussions?
<Xu_R> Yeah
<itchka> karma system is votes as to whether a revised package is good or bad
<itchka> It has been proposed that we use Bugzilla as central clearing house for bugs AND updates.
<Xu_R> And we would modify Bugzilla to suit our needs.
<itchka> There is the ability on ABF to hold packages until a QA approval is given
<blackcrack> Xu_R, maby it is not bad to have karma.openmandriva for other peoples who whant registration and voting with
<itchka> a fixed or updated package would be put out to test
<blackcrack> and if it is a bad karma, so have it a link for bugzilla for create a new bugrport
<Xu_R> blackcrack: this system will be integrated into Bugzilla.
<itchka> testers with accounts on bugzilla would have a single vote (positive or negative) which they can set against the updated package
<blackcrack> but Karma can get the peoples an first point of contact for newcomers to the bugzilla
<blackcrack> who it is mab bugzilla to heafy ?!... :)
<blackcrack> ehh maybe, heavy *s*
<Xu_R> blackcrack: I don't think I'd want newcomers to touch the testing packages... we don't want to accidentally break their system.
<itchka> The testers would have a different level of permissions to ordinary users
<blackcrack> humm.. i was an newcomer too.. befor 15 jears? or so :)
<blackcrack> *s*
<itchka> Blacky please let me get the proposal out first and then we can discuss it OK?
<blackcrack> :)
<itchka> There can be a higher level of "tester" whose voting "weight" is 2 this will allow QA to push through packages that are urgent the package will still have to be verified by at least one other tester.
<Xu_R> Security and release manager (bero) would probably be that higher level
<itchka> Votes can be positive or negative the trip point will be plus 3 votes for acceptance and minus 3 votes for rejection.
<blackcrack> looks good :)
<bero> This may also be how to maintain the stable cooker branch after release
<itchka> If the package is accepted Bugzilla will generate a command to push the QA acceptance button on ABf and the package will be pushed to the updates repositary.
<Xu_R> bero: I was hoping it would be as well... selective pushing to stable cooker
<itchka> We have not discussed security updates but these may require a different approach this is stil to be discussed. In the case of rejection the normal bugzilla mails will be generated.
<Xu_R> I think security updates should still go through normal routes... Just have a security team expedite it with their karma
<itchka> To notify the package builder of the problem. Certain parts of the distro may have to have a higher number of votes for acceptance. Graphics drivers spring to mind!!!
<ben79> Hmmm. Good point.
<itchka> Xu_R: I think that was about as far as we got wasn't it Robert?
<Xu_R> itchka: that's pretty much it. next would be actually making Bugzilla do this so we can test this method
<Xu_R> itchka: if we could have Bugzilla do this by next week we'd be in shape to test a beta
<itchka> Xu_R: I think that is going to have to be a joint effort. I'm ok with the database side of things and configuring bits of Bugzilla but there may be some perl or python required which are not my strong points
<itchka> Xu_R: I will give it a go if some of you don't mind being called on to help
<Xu_R> itchka: sure, I don't mind
<itchka> Ok then I'm up for it. I'll talk to infra about bringing the new Bugzilla on line.
<Xu_R> itchka: Yeah - remember that we'll have to migrate issues to the new one without losing data
<Xu_R> and Bugzilla provides scripts for it, so it shouldn't be too much of a problem
<ben79> Sound good.
<itchka> Xu_R: That may not be possible as they are different versions of schema the program you pointed me too I think only works between identical versions. I might be able to do something the low level database end though.
<Xu_R> itchka: the schema hasn't changed too much, so I assume it should be ok?
<ben79> If there's anything I can do to help let me know.
<Xu_R> Anything else?
<itchka> Xu_R:Wel I guess we will cross that bridge when we come to it. We don't have too many open bugs so if the worst came to the worst we could always re-raise the outstanding ones
<Xu_R> Questions? Objections?
<ben79> None here.
<Xu_R> itchka: yeah... it's always ideal to keep history, but if we can't do it, then oh well.
<itchka> Well I hate to show lack of confidence but I think we perhaps should think about a back-up plan.
<itchka> I suppose we could do almost the same thing manually
<Xu_R> Yeah...
<Xu_R> We could make an in-house system, but meh...
<itchka> Leave it with me. I'll communicate through om-qa list
<Xu_R> Ok
<Xu_R> anything else?
<Xu_R> Going once...
<Xu_R> Any last words, since we're basically done with the agenda?
<itchka> When is it anticipated there will be the beta
<Xu_R> itchka: beta is now waiting on us, really.
<itchka> Xu_R: Heavy!!!
<blackcrack> humm.. qa gies now more important in group.. nice..
<blackcrack> gies= goes
<Xu_R> JFYI, before I end this
<itchka> I'd better get to it!!!
<Xu_R> I've been building ISOs every other night or so for x86_64
<Xu_R> http://jci.lincomlinux.org/view/OpenMandriva/job/omv-x86_64/
<Xu_R> so just a heads up
<Xu_R> ok, looks like we're done here
<Xu_R> ------------------------------------------------------------------