18:01:44 <bmwiedemann> #startmeeting
18:01:44 <bugbot> Meeting started Mon Jan 21 18:01:44 2013 UTC.  The chair is bmwiedemann. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:44 <bugbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:58 <Ilmehtar> Hi all!
18:02:35 <bmwiedemann> our first meeting topic would be...
18:02:38 <bmwiedemann> #topic Beta1
18:04:02 <bmwiedemann> openQA results look rather poor currently with breakages happening during install and 2nd stage
18:05:30 <bmwiedemann> then various gtk applications have display problems with cirrus' 24 bpp graphics. And there was some problem with VirtualBox kernel drivers, so that graphics was completely broken there
18:05:48 <Ilmehtar> yup, I've spotted that too, do we have a bug ID for it so I can add myself to the CC?
18:06:15 <LWFinger> I had noticed the openQA problems, and had low expectations. I also found the VB problem. Bug #799492.
18:06:17 <bmwiedemann> Ilmehtar: http://openqa.opensuse.org/ lists some on the left
18:07:01 <Ilmehtar> bmwiedemann: I see the mention of the cirrus issue, just not a bug ID..I'll search around and make one if it needs it :)
18:07:54 <bmwiedemann> Ilmehtar: the top one is a link
18:08:01 <bmwiedemann> to bugzilla
18:08:25 <bmwiedemann> bnc#799216
18:08:31 <Ilmehtar> bmwiedemann: found it, got it, thank you :)
18:10:06 <bmwiedemann> upgrading from 12.1 seems to work, while it has some problems from 11.4
18:10:27 <bmwiedemann> (e.g. firefox not starting)
18:10:27 <LWFinger> Is that supposed to work?
18:10:51 <bmwiedemann> there was some hope with 11.4 getting updates from Evergreen
18:11:16 <LWFinger> On the Forums, we always recommend only 1 step at a time.
18:11:25 <bmwiedemann> but I guess there will be cases, where the effort is not worth it
18:11:38 <Ilmehtar> I did lots of Beta1 installs during the Hackathon. the issues with LVM are really worrying for me - not only does it fail on fresh installs (of a blank hdd), but it fails if you are trying to delete the LVM partitions and create a non-LVM installation in its place
18:11:57 <cboltz> is the upgrade failure caused by something in $HOME or something system-wide?
18:12:09 <cboltz> (if $HOME, the step by step upgrade won't help much ;-)
18:12:21 <bmwiedemann> cboltz: could be some $HOME issue. did not look closer.
18:12:55 <LWFinger> A new test user should answer that question.
18:13:35 <LWFinger> My upgrade from 12.2 was OK.
18:13:46 <cboltz> I would be surprised if it's something system-wide because all system-wide files come with rpm
18:13:53 <cboltz> and I expect rpm to cleanup ;-)
18:14:51 <bmwiedemann> http://openqa.opensuse.org/results/openSUSE-DVD-x86_64-Build0348-11.4kde64zdup look good apart from the missing firefox
18:14:52 <bmwiedemann> http://openqa.opensuse.org/results/openSUSE-NET-i586-Build0348-11.4gnome32zdup has some error there
18:15:23 <bmwiedemann> I will have to do another run and look closer
18:15:40 <bmwiedemann> The LVM issues should be solved by now
18:16:16 <Ilmehtar> in beta1? or in more recent builds?
18:16:21 <bmwiedemann> after beta1
18:16:53 <bmwiedemann> someone did cleanup a part in linuxrc that was supposed to be unused
18:17:03 <bmwiedemann> (and yet was still used)
18:17:25 <Ilmehtar> nifty, I'll have a play with that. I've been looking into a polish issue with systemd/luks/plymouth - when you get prompted to unlock an encrypted partition/device, if you dont respond in 90 seconds, systemd decides to keep on booting anyway
18:17:58 <bmwiedemann> which can be the right thing, when it is /home
18:18:05 <bmwiedemann> and you want unattended boots
18:18:39 <bmwiedemann> I had some trouble with systemd on my remote headless server already
18:18:43 <Ilmehtar> yeah..but it's not possible logging in with GNOME if your /home/username is missing..
18:18:55 <bmwiedemann> right
18:19:07 <Ilmehtar> and systemd does it regardless of the partition.. even /  :)
18:19:21 <bmwiedemann> but locally, you could ctrl-alt-f1 and login as root to mount the missing partition
18:19:53 <cboltz> the timeout is a bad idea if for example your /var is encrypted ;-)
18:19:56 <Ilmehtar> yeah, it's managable, would just be nice to tune it if we can ;)
18:20:05 <bmwiedemann> yes
18:20:21 <cboltz> you'll basically have to restart _everything_, and a reboot is usually faster than typing 20 restart commands ;-)
18:20:42 <bmwiedemann> (except if your BIOS needs 3 minutes)
18:20:53 <cboltz> so I agree with Ilmehtar that the timeout should be tuneable (10000 seconds for me, please ;-)
18:22:16 <bmwiedemann> who opens a bnc for it?
18:22:25 <bmwiedemann> or is there one already?
18:22:57 <Ilmehtar> it's open, let me find it, gah I guess I forgot to CC myself on it
18:23:26 <Ilmehtar> bug 749706
18:25:19 <bmwiedemann> thanks.
18:26:08 <bmwiedemann> I will reinstall my netbook's spare partition with 12.3-Beta1 to see how it fares on intel graphics
18:26:57 <bmwiedemann> is there anything else we could do to make 12.3 better?
18:27:18 <cboltz> can you unlock the KDE screensaver without using the mouse?
18:27:24 <bmwiedemann> I was thinking to look deeper into bnc#799216
18:27:28 <LWFinger> Any possibility of doing VB installation tests on openQA?
18:27:47 <cboltz> (I can't - it needs at least a mouse click somewhere)
18:27:49 <CzP> I'm using now beta1 as my primary machine, and until now I ran only into problems caused by myself :)
18:27:49 <bmwiedemann> LWFinger: not on the same machine, as only one can grab the hardware virt
18:28:03 <CzP> so it looks pretty promising
18:28:17 <LWFinger> Too bad.
18:28:49 <bmwiedemann> but maybe I will find a spare machine to do it...
18:28:54 <LWFinger> I too am using Beta1 on primary box for 2 days. No real problems.
18:29:05 <CzP> ThinkPad T410 with Intel graphics, encrypted LVM (which did not work a week before...)
18:29:37 <LWFinger> Mine is HP dv2815 with nVidia.
18:30:21 <LWFinger> Anyone install from Live CD?
18:30:22 <bmwiedemann> that sounds promising
18:30:35 <LWFinger> KDE Live CD.
18:30:42 <CzP> I used the net installer
18:31:01 <bmwiedemann> http://openqa.opensuse.org/results/openSUSE-KDE-LiveCD-i686-Build0348 looked good
18:31:16 <LWFinger> My attempt with the KDE Live CD froze on installation.
18:31:26 <LWFinger> I have not investigates further.
18:31:42 <LWFinger> The media passed checks.
18:32:04 <bmwiedemann> http://openqa.opensuse.org/viewimg/openqa/testresults/openSUSE-KDE-LiveCD-x86_64-Build0348/yast2_i-1.png but sometimes there is this "green console" bug
18:32:48 <LWFinger> I didn't see that.
18:32:58 <LWFinger> My install was NET upgrade from 12.2.
18:33:48 <LWFinger> For the first time ever, the default desktop settings had some things that were poorly visible.
18:33:56 <bmwiedemann> seems to only hit 64bit LiveCDs
18:34:09 <LWFinger> I'm gradually getting the settings improved.
18:34:20 <LWFinger> Mine was 64-bit.
18:34:42 <bmwiedemann> but not liveCd
18:34:44 <poorboywilly> LWFinger: KDE?  I've also seen a few rough areas
18:34:56 <LWFinger> Yes, KDE.
18:35:28 <poorboywilly> but only visual...everything else has been real smooth
18:35:52 <LWFinger> Yes. The worst was the Connection Manager in the NM applet.
18:35:54 <bmwiedemann> so KDE theming issues?
18:36:05 <LWFinger> Yes.
18:36:13 <poorboywilly> yes the new plasma theme has exposed a few problems since it is light text on dark background
18:36:47 <poorboywilly> one thing that is still very puzzling to me is the check boxes in knetworkmanager
18:36:55 <poorboywilly> I can't figure where it is getting those colors
18:37:13 <bmwiedemann> you could try asking alin or tittiacoke for help
18:37:16 <LWFinger> They are bad. I've now got them visible.
18:37:28 <poorboywilly> what did you change?
18:37:55 <LWFinger> I was afraid you would ask. Let me look.
18:37:59 <poorboywilly> :)
18:38:20 <poorboywilly> there is an issue with combo boxes in plasmoids too...thankfully only a couple plasmoids actually have combo boxes
18:38:38 <LWFinger> I added the "Blue Sora" desktop theme. That helped.
18:38:39 <poorboywilly> I added to upstream KDE bug about the problem
18:39:22 <LWFinger> Still, the dark background is a problem.
18:39:36 <poorboywilly> the checkbox might be KDE bug too, but we also might not be supplying a proper background in the new theme
18:41:03 <poorboywilly> that's a new one, I just booted my laptop with the live CD and my mouse doesn't work...
18:42:36 <LWFinger> What sort of mouse?
18:44:25 <poorboywilly> thinkpad t60 trackpad + knobby thing
18:44:59 <poorboywilly> synpactics, that's what I couldn't think of
18:45:26 <LWFinger> My synaptics touchpad on HP has been OK.
18:45:53 <LWFinger> I also have not seen that complaint on the Beta forum.
18:45:57 <poorboywilly> I've done KDE and gnome several times and first I've had this
18:46:15 <LWFinger> Ah, wonderful intermittents.
18:46:33 <poorboywilly> dmesg has several messages and then one that says "psmouse seriol: Failed to enable mouse on isa0060/seriol"
18:47:29 <LWFinger> Is the touchpad supposed to use psmouse?
18:48:01 <poorboywilly> no idea, I haven't delved into mouse or touchpad issues at all before
18:48:18 <LWFinger> I've never had to look at the details for my touchpads other than to turn off tapping.
18:51:04 <bmwiedemann> I think, normally the synaptics driver is used and psmouse is only a poor fallback that does not know about tapping or scrolling
18:52:49 <poorboywilly> the first message I see about it is "psmouse seriol: synaptics: Touchpad model: 1..."
18:54:42 <LWFinger> Actually, my touchpad is an Alps Glidepoint.
18:55:18 <LWFinger> It comes in as an i8042 serial device.
18:56:12 <bmwiedemann> maybe we should move on then...
18:56:38 <bmwiedemann> #topic Next meeting
18:57:19 <bmwiedemann> RC1 is scheduled for 2013-02-07
18:57:33 <bmwiedemann> which is not far
18:58:12 <bmwiedemann> deep freeze is starting in February
18:58:54 <LWFinger> Is 02-11 too soon after RC1?
18:58:54 <bmwiedemann> so shall we have another meeting before RC1?
18:59:36 <bmwiedemann> after RC1 only the most critical issues will be fixed
18:59:50 <bmwiedemann> (or unimportant leaf packages)
19:00:09 <LWFinger> If we keep filing bugs, is another meeting useful?
19:00:44 <bmwiedemann> hm. maybe not... if the important bugs get to the right people
19:01:14 <LWFinger> Is there a list of the "right" people?
19:02:01 <cboltz> LWFinger: ask   osc maintainer   ;-)
19:02:10 <bmwiedemann> there is maintainer information in OBS. I use http://aw.zq1.de/cgi-bin/public/opensusemaintainer/linuxrc
19:02:29 <bmwiedemann> (just replace the last part with the source package name of your choice)
19:03:36 <LWFinger> Thanks for both suggestions.
19:05:14 <bmwiedemann> so 2013-02-11 18:00 UTC for next meeting. OK?
19:05:23 <Holgi> would be fine with me
19:05:43 <LWFinger> OK here.
19:06:13 <poorboywilly> no objection
19:06:16 <bmwiedemann> #agreed next meeting 2013-02-11 18:00 UTC
19:06:25 <bmwiedemann> #topic open discussion
19:07:20 <bmwiedemann> I'm still wondering if there is not a way to develop openSUSE without this kind of breakage in core components
19:08:28 <bmwiedemann> e.g. projects like OpenStack require unit-tests and smoketests to succeed before any git commit is accepted
19:10:20 <LWFinger> The kernel changes require the approval of Linus and several senior devs, but is this possible with oS?
19:11:18 <cboltz> there's an easy trick, but it sounds funny ;-)
19:11:22 <poorboywilly> yeah I don't know that the project has the developer resources to have every change tested prior to inclusion
19:11:25 <bmwiedemann> Linus admitted that he rarely reads code
19:11:38 <cboltz> usually the breakage is around beta1 because everybody submits the latest version before feature freeze
19:12:06 <cboltz> so just don't announce feature freeze in advance ;-)
19:12:06 <bmwiedemann> yes. and bugfixes for issues that have been open for over a month
19:12:20 <cboltz> and reject late version updates more strictly
19:12:47 <LWFinger> Try to modify a key kernel component, and you soon learn that Linus does read code! Linus does not code much anymore.
19:13:16 <bmwiedemann> so people should submit new versions prior to the first milestone... but wouldnt we then get all breakage there?
19:13:46 <poorboywilly> this is a common problem in many large projects, I think a solution is to break the development into several iterations
19:13:49 <bmwiedemann> well. plenty of time to fix it then
19:13:53 <poorboywilly> instead of one big freeze
19:13:59 <poorboywilly> freeze 3, 4 times per release
19:14:28 <bmwiedemann> we have tiny 3-day freezes prior of each milestone
19:14:31 <LWFinger> In the kernel, the feature freeze corresponds to the MS1 release - only bug fixes after that.
19:14:35 <bmwiedemann> hardly enough to build
19:16:13 <bmwiedemann> but if we freeze (core) openSUSE code before MS1, there needs to be a staging area where it is prepared...
19:16:16 <poorboywilly> two issues there, I don't think that's enough frozen (read: stabilization) time and perhaps there is still no incentive for people to put in features early
19:17:23 <poorboywilly> yes staging is a must,there is no way to stabalize something unless you control the changes coming in
19:18:22 <bmwiedemann> of course we would get some breakage in the staging area then
19:18:38 <poorboywilly> what do you mean exactly?
19:19:09 <bmwiedemann> just as happens today in Factory, there can be incompatible versions etc
19:19:44 <cboltz> I'm not sure if staging would help that much - basically we rename Factory to staging with that ;-)
19:20:10 <cboltz> (in other words: there will always be some breakage)
19:20:39 <bmwiedemann> cboltz: but what about the more stable Factory repo after the staging area
19:20:43 <poorboywilly> yes there will but it is nearly impossible to get stable software if you are trying to implement features and fix bugs at the same time
19:20:55 <bmwiedemann> we dont have that today. and it might be useful
19:21:51 <cboltz> well, I'm not against trying it - it might catch some things before they hit factory
19:22:06 <cboltz> but it also adds some additional paperwork
19:22:49 <cboltz> (and we already have/had staging projects for some "big" changes)
19:23:29 <poorboywilly> well then, we need to evaluate those staging projects and determine if they helped or not
19:23:30 <bmwiedemann> ... if there was a way to make it automated.
19:23:58 <cboltz> and, well, IMHO factory is even allowed to be broken sometimes - except in the time after beta1 ;-)
19:24:01 <poorboywilly> if they did, then create processes based on them for more
19:24:15 <poorboywilly> if not, find out why and figure out different ways to solve the problem
19:24:29 <bmwiedemann> cboltz: depends on the level of brokenness. e.g. zypper should never break
19:25:30 <poorboywilly> when is zypper allowed to be updated...any time?
19:25:41 <cboltz> if "break" just means "fails to build" without breaking something else, it doesn't hurt too much IMHO
19:25:43 <poorboywilly> and other stuff like the kernel, gcc, etc
19:26:04 <cboltz> gcc is a better example for something that shouldn't break ;-)
19:26:20 <cboltz> (and IIRC we already had staging projects for gcc updates)
19:26:24 <bmwiedemann> cboltz: no, I mean building but malfunctioning.
19:26:51 <cboltz> which brings us to the next question: who tests the packages in the staging project?
19:26:59 <cboltz> and with testing, I mean more than "it builds"
19:27:21 <bmwiedemann> something like the openQA automatisms could
19:28:20 <bmwiedemann> there is only a limited number of core packages (a lot of them in Base:System)
19:28:26 <poorboywilly> and then humans where that's not possible
19:28:55 <bmwiedemann> and it could be worthwile to throw updates into a test area one-by-one
19:29:33 <cboltz> poorboywilly: openQA will work, but I doubt many humans will test staging
19:29:45 <poorboywilly> yes...and I think at least the core packages should only be updated in waves...gather a series of updates, perform them, then work on high-level packages
19:30:14 <bmwiedemann> cboltz: that is OK. as long as the test results say, it is good, it does not need humand
19:30:36 <poorboywilly> well, my point is that openQA can't do everything.  Not yet at least :)
19:30:57 <bmwiedemann> what things it can not do?
19:31:11 <bmwiedemann> apart from ATI/NVidia driver testing...
19:31:33 <cboltz> bmwiedemann: it can't do things users do "accidently"
19:31:50 <cboltz> well, it could, but nobody would ever come up with the idea to write such crazy testcases
19:32:07 <bmwiedemann> I could insert random keystrokes ;-)
19:32:21 <poorboywilly> can it test mouse interaction?
19:32:29 <cboltz> bmwiedemann: sounds like a good start ;-)
19:32:35 <bmwiedemann> mouse is not so easy
19:32:50 <bmwiedemann> but in principle, it could
19:34:25 <bmwiedemann> the point of openQA is not, that it gives proof of bugfreeness. That is very hard in computer science. The point is to show that it can work.
19:34:46 <bmwiedemann> so there is at least one non-broken path though the maze
19:35:08 <poorboywilly> right, which is the perfect place to start when testing new integrations of components
19:35:43 <bmwiedemann> if Factory received less breakage, chances are, that more humans looked at it
19:36:05 <poorboywilly> and more humans is good right?
19:36:13 <bmwiedemann> yes :-)
19:36:20 <bmwiedemann> more users = more testers
19:36:28 <poorboywilly> so there is definitely motive for less breakage in Factory
19:37:27 <poorboywilly> we need 1) processes to get less breakage 2) analysis of the results 3) refining the process with data from 2
19:37:55 <poorboywilly> I think staging changes for basic go/no go type testing is certainly one likely way to help it
19:38:02 <bmwiedemann> currently we have mandatory reviews and factory-auto checks from coolo
19:38:22 <bmwiedemann> which tests that packages build
19:39:03 <poorboywilly> obviously a good thing!  we also agree that simple "it builds" doesn't necessarily mean it is not broken
19:39:25 <poorboywilly> so the missing link seems to be we must determine if it is reasonable to imagine this isn't broken
19:40:27 <bmwiedemann> some core parts of openSUSE just can not be unit-tested. it needs system/integration-tests like openQA which is slower
19:41:58 <poorboywilly> so how can we do that with the resources we have?
19:44:21 <bmwiedemann> not sure. maybe I'll have a chat with coolo about it and/or try to sum up the idea on the factory ML.
19:44:53 <poorboywilly> I don't think we can do it continuously, but in batches certainly seems reasonable
19:47:22 <bmwiedemann> our current openQA machine can run approx 3 tests in parallel and one test typically takes an hour (because it is a full graphical install with extra tests)
19:48:16 <bmwiedemann> so it could be possible to test updates to core packages, which should be less than 40/day
19:50:27 <bmwiedemann> anyway... it is getting late
19:50:38 <bmwiedemann> so let's close today's meeting
19:51:04 <bmwiedemann> Thanks everyone for attending. I will add links to the logs on http://en.opensuse.org/openSUSE:Testing_meeting
19:51:11 <bmwiedemann> #endmeeting