20:01:51 <DavidWHodgins> #startmeeting
20:01:51 <Inigo_Montoya> Meeting started Thu Mar  1 20:01:51 2018 UTC.  The chair is DavidWHodgins. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:51 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:01:55 <DavidWHodgins> #topic * Who's new? - If you are then come and say hello.
20:02:11 <DavidWHodgins> Anyone here who hasn't been to a qa team irc meeting before?
20:03:00 <DavidWHodgins> #topic * Wireshark update - What went wrong and how to avoid problem in future.
20:03:29 <wilcal> I thought my local repo was not up to date again
20:03:34 <DavidWHodgins> As per the various mailing lists, there was a problem when bug 22643 was pushed
20:03:36 <[mbot`> Bug: ['wireshark new release 2.2.13 fixes security issues', 'REOPENED', 'QA Team'] https://bugs.mageia.org/show_bug.cgi?id=22643
20:04:00 * Luigi12_work continues to beat the drum to only install packages from updates_testing that are actually assigned to QA
20:04:09 <Luigi12_work> also Dave's idea of using snapshots in a VM is great
20:04:09 <DavidWHodgins> The update added a requires on the qt 5.9 version of libQt5Core
20:04:31 <DavidWHodgins> There were two problems.
20:04:40 <Luigi12_work> and it only added that dynamically when it was built, so it's not a packaging problem
20:04:40 <Luigi12_work> it's a build system problem
20:04:51 <DavidWHodgins> Ah. Ok. Thanks
20:05:28 <DavidWHodgins> So the first problem is the way the build system handles adding requires. Not much we can do about that.
20:06:07 * Pharaoh_Atem waves
20:06:13 <DavidWHodgins> That just leaves the problem Luigi12_work is referring to. Having multiple testing updates installed while testing one update.
20:06:16 <Luigi12_work> more specifically the way it doesn't allow you to build each update in its own clean repo
20:06:31 <tmb> besides stop pushing huge QT updates on stable releases :)
20:06:34 <Pharaoh_Atem> there's no "easy" way to control the buildroot like that
20:06:43 <DavidWHodgins> In this case the wireshark update was tested on a system with the qt5 update installed.
20:06:44 <Pharaoh_Atem> we don't have side tags or side repos or anything like that
20:06:55 <DavidWHodgins> They are both assigned to qa, so it made sense.
20:07:24 <Luigi12_work> tmb: unfortunately it would have probably been needed regardless because the whole world decided not to respect the Qt 5.6 LTS this time.  I hope they'll do better with 5.9!
20:07:25 <DavidWHodgins> The problem is that only updates that depend on each other should be included when testing any given update.
20:08:41 <DavidWHodgins> As the wireshark update was not marked as depending on any other update, testing of it should start with a system with no updates from testing installed. Install the prior wireshark version, ensure it's working, then install the update for wireshark only.
20:09:01 <DavidWHodgins> That's how it should have been tested, which would have caught this problem.
20:09:41 <DavidWHodgins> bug 22643 has now been reopened, and marked as depending on bug 22657
20:09:44 <[mbot`> Bug: ['wireshark new release 2.2.13 fixes security issues', 'REOPENED', 'QA Team'] https://bugs.mageia.org/show_bug.cgi?id=22643
20:09:45 <[mbot`> Bug: ['Qt5 stack update', 'NEW', 'QA Team'] https://bugs.mageia.org/show_bug.cgi?id=22657
20:10:18 <Luigi12_work> we have some other ones we need to mark depends  22657, like VLC and qtpass (not assigned to QA yet)
20:10:33 <DavidWHodgins> Also bug 22680 has been opened requesting that the wireshark update be moved back from core updates to core updates testing
20:10:34 <[mbot`> Bug: ['Roll back needed to move wireshark back from core updates to core updates testing', 'NEW', 'Mageia Bug Squad'] https://bugs.mageia.org/show_bug.cgi?id=22680
20:11:03 <kekePower> I also have a package that depends on qt5
20:11:20 <Luigi12_work> oh yeah, the imagemagick bug too
20:11:27 <tjandrews> The QT5 update is in a kind of limbo at the moment. Some packages are 5.9.4, but others are 5.9.3. That doen't help any.
20:11:41 <Luigi12_work> update in progress
20:12:02 <stratocaster7> sddm does too. I added the depends on 22657 this morning.
20:12:50 <DavidWHodgins> For now, we can check updates with for example "urpmq --requires wireshark|grep Qt_5.9"
20:13:15 <DavidWHodgins> If that has any output, the bug report should be marked as depending on the qt bug
20:14:46 <DavidWHodgins> When the bug does have the depend bug number added, as wireshark now does, even if it has been marked as validated, the system that pushes updates will ignore it until the bug it depends on has also been validated.
20:15:39 <DavidWHodgins> So we don't have to hold off marking an update as ok or validating it, but we do have to make sure the depends on bug number has been added.
20:15:59 <DavidWHodgins> Any questions or comments?
20:16:05 <wilcal> not from me
20:16:59 <DavidWHodgins> Luigi12_work: Pascal has just added to bug 22680 a comment that the wireshark packages have been moved back to testing.
20:17:00 <kekePower> added bug 19078 to the list
20:17:01 <[mbot`> Bug: ['Roll back needed to move wireshark back from core updates to core updates testing', 'NEW', 'Mageia Bug Squad'] https://bugs.mageia.org/show_bug.cgi?id=22680
20:17:02 <[mbot`> Bug: ['imagemagick new buffer overflows fixed in 6.9.5-5 and later (inc. CVE-2016-5010, CVE-2016-6491, CVE-2016-6823, CVE-2016-7101, CVE-2016-7799, CVE-2016-7906, CVE-2016-8707, CVE-2016-9556, CVE-2016-9773, CVE-2016-10046, CVE-2016-1005[1-8], CVE-2016-10068...)', 'NEW', 'Shlomi Fish'] https://bugs.mageia.org/show_bug.cgi?id=19078
20:17:29 <Luigi12_work> cool
20:18:16 <stratocaster7> I'm not part of QA but can an update (like sddm) even be validated when it pulls in other not yet complete packages like qt? That broke system last time Len tried it.
20:18:23 <DavidWHodgins> Not sure if we may run into problems when we go to push it again, as the advisory has already been processed.
20:18:39 <Luigi12_work> I think it'll work, it just won't send another upates-announce e-mail
20:18:43 <DavidWHodgins> stratocaster7: It cannot
20:19:09 <Bequimao> https://bugs.mageia.org/show_bug.cgi?id=22280 also, because of wireshark-libvirt.
20:19:11 <[mbot`> [ 22280 – libvirt new security issues (one fixed upstream, plus CVE-2017-1000256, CVE-2018-5748 and CVE-2018-6764) ]
20:19:29 <DavidWHodgins> Or rather it can be marked as validated, but as long as the depends on bug has not been validated, it will not be pushed to updates.
20:19:53 <DavidWHodgins> validated normally means ready to push.
20:19:57 <Luigi12_work> Bequimao: that doesn't depend on qt5 does it???
20:20:12 <DavidWHodgins> It's pushing the update that actually moves the packages from updates testing to updates.
20:20:36 <Bequimao> when I tested it, I had not installed wireshark
20:20:55 <stratocaster7> DavidWHodgins: I used the wrong term. Validated should have been tested for validation really. Attempting to test sddm broke Len's machine.
20:21:15 <DavidWHodgins> A bug marked as vailidated will not be pushed if it's marked as validated, but has other bugs listed in the depends on field that have not also been marked as validated.
20:21:17 <tarazed_> Three of them
20:21:59 <DavidWHodgins> qa testers have to learn how to downgrade an update when it breaks their system. :-)
20:22:17 <neoser10> using the tty
20:22:22 <tarazed_> Would not even boot
20:22:34 <tjandrews> Difficult to do if your system is broken so badly that you can't boot it.
20:22:35 <DavidWHodgins> On my system, plasma is currently failing due to kwin segfaulting
20:22:36 <Bequimao> DavidWHodgins: Then we must add #22280 to the dependencies.
20:22:41 <neoser10> failsafe did not work???
20:22:47 <DavidWHodgins> tarazed_: Try booting to run level 3
20:23:08 <DavidWHodgins> Just edit the kernel parameters and add " 3" without the quotes to the kernel parameters
20:23:16 <Luigi12_work> Bequimao: did you verify that it is linked to Qt5??
20:23:19 <tarazed_> Yes, I know about that - not from the grub> prompt.
20:23:31 <Luigi12_work> Bequimao: if it's only linked to wireshark it doesn't matter
20:23:38 <DavidWHodgins> Instead of downgrading plasma, I logged into run level 3 and then started mate.
20:25:14 <DavidWHodgins> Bequimao: For wireshark,  "urpmq --requires wireshark|grep Qt_5.9" shows that wireshark does need to depend on bug 22657
20:25:16 <[mbot`> Bug: ['Qt5 stack update', 'NEW', 'QA Team'] https://bugs.mageia.org/show_bug.cgi?id=22657
20:25:36 <Luigi12_work> DavidWHodgins: yeah but he's asking about "wireshark-libvirt" from libvirt
20:26:03 <neoser10> and for wireshark-libvirt may be is good have validated the wireshark thing
20:26:11 <tjandrews> I've decided that for the time being any updates I test will be done in vbox first, with the possible exception of kernels.
20:27:10 <lewyssmith> It seems that all this merited a severe health warning. Not yet back on qa-discuss, was ther one?
20:27:19 <wilcal> Do we have a big risk here where someone with wireshark install could brick their system if they update wireshark
20:27:23 <DavidWHodgins> Ah. wireshark-libvirt does not have a requires on Qt_5.9, so it's ok
20:27:35 <DavidWHodgins> wilcal: No
20:27:58 <DavidWHodgins> The only risk is that people may force the update and then wireshark fails to run.
20:28:27 <Luigi12_work> no, it won't even update wireshark to begin with
20:28:27 <wilcal> running the MCC can you successfully remove wireshark from the system
20:28:27 <DavidWHodgins> Luckily wireshark is not a critical package
20:28:28 <Luigi12_work> no risk
20:28:46 <DavidWHodgins> Luigi12_work: If they use nodeps, they can force it.
20:28:53 <Luigi12_work> well that would be a stupid thing to do
20:28:59 <Luigi12_work> MageiaUpdate doesn't let you do that though
20:29:02 <DavidWHodgins> Agreed. :-)
20:29:12 <DavidWHodgins> Doesn't mean people won't try it.
20:29:24 <neoser10> Here comes the resposability of the pkg maintainer
20:29:29 <Luigi12_work> hopefully not in the 2 days it was out there, since we pulled it back :o)
20:29:36 <DavidWHodgins> With Mandriva it was common to need to do things like that. That's one way Mageia tries to be better.
20:29:44 <Bequimao> DavidWHodgins: wireshark-libvirt installs wireshark. I don't use urpmi, dnf only: http://paste.debian.net/1012651/
20:30:14 <Luigi12_work> Bequimao: it doesn't matter, it's not linked to Qt5, so it will work fine with the prevoius wireshark build
20:30:24 <Luigi12_work> BRB in 10 minutes
20:30:25 <DavidWHodgins> Now that the wireshark update has been pulled back, it should be ok as long as it works with the older version of wireshark.
20:30:34 <Luigi12_work> neoser10: that's not true actually, the packaging itself is fine
20:30:49 <Luigi12_work> yeah wireshark didn't change SONAMES, just Qt
20:30:51 <Luigi12_work> OK, really BRB
20:30:55 <DavidWHodgins> Luigi12_work: It's the package, not the packaging
20:31:40 <DavidWHodgins> The packager didn't do anything to add the dependency on Qt_5.9, that was done automatically by the build system.
20:32:07 <DavidWHodgins> Any more comments or questions on this? :-)
20:32:18 <wilcal> not from me
20:32:43 <neoser10> is possible to "modify" the buildsystem to not use the certain updates???
20:33:00 <neoser10> libraries really
20:33:27 <DavidWHodgins> #info To avoid package dependency problems, ensure only one update from testing is tested at a time, unless the update depends on another in which case both should be installed together for testing.
20:34:19 <kekePower> neoser10: it _is_ possible, but not practical
20:34:25 <DavidWHodgins> neoser10: I doubt it can be done easily, and would probably have other impacts. That's a discussion for the developers and sysadmins
20:34:35 <stratocaster7> neoser10: It is a double edged thing. With huge updates like qt the build system has to use the first newer libraries as it builds subsequent ones.
20:35:31 <neoser10> but if is the newest library is not pushed to updates, can use that newest library???
20:36:03 <tjandrews> We really need to get thisQT/plasma stuff tested and pushed. It would solve a multitude of problems.
20:36:31 <DavidWHodgins> The difficulty would be in ensuring packages that need the updated version get the updated version, and only those packages.
20:36:41 <DavidWHodgins> tjandrews: It's no where near ready.
20:36:53 <tjandrews> Sigh.
20:37:02 <wilcal> Is there not a huge Plasma update coming down the pipe?
20:37:11 <DavidWHodgins> It's segfaulting on my system both under vb and on real hardware. I've switched back to mate till it's fixed.
20:37:32 <DavidWHodgins> wilcal: The QT and Plasma updates are being processed together and depend on each other.
20:37:34 <lewyssmith> -3 So why are they on the updates list?
20:37:54 <DavidWHodgins> Because they are ready for testing.
20:38:05 <DavidWHodgins> Testing has found problems, which are being fixed.
20:38:09 <lewyssmith> But not ready?
20:38:28 <brian__> tranlsation - successful test
20:38:34 <Bequimao> It was discussed before the release of Mageia 6, but postponed because of the risks.
20:38:34 <DavidWHodgins> If the testing didn't find problems they would be ready to push, but testing did find problems.
20:38:40 <lewyssmith> OK, I see. Test with caution.
20:39:23 <tjandrews> lewyssmith: getting an update this massive right on the first try would be incredibly lucky - and suspect.
20:39:40 <DavidWHodgins> Always. Qa testers should expect to find problems, especially with a massive group of updates like this.
20:40:01 <lewyssmith> tjandrews, Accepted. Hence health warning.
20:40:04 <Bequimao> Here it works fine. I have only one problem with Kmail and GMail.
20:40:19 <DavidWHodgins> Our job is to find as many of the problems as we can, and get them fixed before OKing the updates.
20:40:36 <lewyssmith> = QA !
20:40:55 <DavidWHodgins> Don't be surprised if we miss some. We can't test every possible combination of packages or configurations.
20:41:12 <DavidWHodgins> All we can do, is do our best.
20:41:18 <neoser10> this plasma update must be tested in multilanguage configuration..... specially with two or more installed
20:41:19 <kekePower> this is still the best QA team around, imho
20:42:22 <Bequimao> neoser10: It never worked in multilanguage configuration.
20:42:24 <DavidWHodgins> It's easy to slip into some bad practices, like testing updates together that are not marked as depending on each other. I added this item to the agenda to remind everyone not to do that.
20:42:33 <brian__> <<then there's me>> the eception to that rule
20:42:56 <DavidWHodgins> We are human, and make mistakes.
20:43:27 <DavidWHodgins> That's to be expected. We just have to try and use ways that catch the mistakes before the updates go out to the general public.
20:43:56 <DavidWHodgins> Moving on ...
20:44:00 <DavidWHodgins> #topic * Testing updates - Any other difficulties, problems, issues?
20:44:10 <hviaene> Does that mean I have to downgrade each tested packageto test another one???
20:44:23 <DavidWHodgins> Yes
20:44:31 <DavidWHodgins> That's one way of doing it.
20:44:36 <tarazed_> My thanks to dave Hodgins for his support on krb5
20:44:40 <DavidWHodgins> Most of my testing, I do in vb.
20:44:52 <brian__> I keep an up to date VM instance, then clone one test the change then toss the clone
20:45:01 <DavidWHodgins> tarazed_: I'll rewrite the bind instructions to try and make them easier to follow.
20:45:30 <Bequimao> with dnf you'll have # dnf history undo ..
20:45:35 <tarazed_> Yeah, the perennial problem of documentation; at what level to pitch it.
20:45:35 <wilcal> Disposable VM's are my friend
20:45:47 <DavidWHodgins> In vb, I do not have the testing repos enabled, but use "urpmi.update e" to update all repos whether enabled or not.
20:45:55 <tjandrews> OK, so the QT/kf/Plasma packages all depend on each other. Yet they are listed in separate bugs. Some have been sent to QA, some not. Should each bug be tested separately, or all together?
20:45:58 <neoser10> I am repeating tests to be sure and create a named (bind) standart configuration to test that krb and help with docs
20:46:10 <DavidWHodgins> The e works because every repo name contains an e, it's not a urpmi.update switch.
20:46:59 <kekePower> DavidWHodgins: That's a nice hack :-)
20:47:11 <tjandrews> (That question was started before we switched topics, Sorry.)
20:47:40 <DavidWHodgins> Before testing an update in vb, I take a snapshot, then start the guest, enable the testing repos, then install the update to test, test it, shut down the guest, restore the snapshot (to remove that update), then do it all again for the next update.
20:48:27 <wilcal> I have VB clients that I keep up to date then clone them for testing. when done testing the clone i delete it
20:48:40 <brian__> ditto
20:48:54 <brian__> then there are the physical hardware ones, which I'll gamble with some
20:49:05 <brian__> on a test instance of course
20:49:10 <DavidWHodgins> Yes, you can use either a clone or snapshots. Both work the same way.
20:50:05 <DavidWHodgins> On real hardware I use rsync to keep a complete copy (snapshot in effect) of my testing installations, which I restore using rsync after a test.
20:50:19 <hviaene> I can't use VB on my 32-bitter, it's byfar not powerfull enough
20:50:29 <DavidWHodgins> I only use the real hardware for testing things like kernels etc., so keep my test installs as small as I can.
20:50:39 <Bequimao> Of course, you spot regressions when it is too late to rollback snapshots.
20:50:41 <DavidWHodgins> hviaene: Ouch
20:50:41 <brian__> understood.  David if you can share your rsync commands that would be interesitng
20:50:51 <DavidWHodgins> lol
20:51:00 <DavidWHodgins> Bequimao: Yes, sometimes that happens.
20:51:23 <DavidWHodgins> Then you need to know how to use the downgrade option, in run level 3 if needed
20:51:46 <brian__> and a sip of tequila
20:51:53 <lewyssmith> Am I alone to live with just one real h/w system which just accumulates updates?
20:52:33 <brian__> geek here, I have old junk laying around I use
20:52:33 <hviaene> About same here
20:52:50 <DavidWHodgins> Likely not alone, but you have to be much more careful using that for testing and find other ways to ensure dependency problems are caught.
20:52:55 <brian__> probably a u.s. citizen excess thing I suppose
20:53:17 <tjandrews> I'm a bottom feeder. I like to create usable systems from others' castoffs.
20:53:36 <DavidWHodgins> If you have the disk space, it's not hard to add a minimal test install and keep copies of it to use as snapshots
20:53:43 <brian__> gotta run, take care all
20:53:53 <tarazed_> Bye Brian
20:53:53 <DavidWHodgins> Thanks for coming brian__
20:54:21 <Bequimao> on real hw, I used btrfs and snapshots.
20:54:58 <DavidWHodgins> Back on the current topic, looking over the list  of updates, I don't see any that are particularly complicated other then the Plasma/q5/kf5 updates
20:55:05 <kekePower> Bequimao: You could've told me that in Greek and I would've understood better! :O
20:55:20 <lewyssmith> -2 And those that depend on them.
20:55:42 <DavidWHodgins> Tather then going through each of the updates, let's keep this meeting short. Anyone have any questions on the updates waiting for testing?
20:55:58 <DavidWHodgins> s /Tather/Rather/
20:56:22 <DavidWHodgins> #topic * Anything else?
20:56:31 <hviaene> None, that I haven(t written in the bugs
20:56:51 <wilcal> Not from me
20:57:00 <lewyssmith> Yes. I cannot get into qa-discuss home page https://ml.mageia.org/l/info/qa-discuss to sign back on.
20:57:02 <[mbot`> [ qa-discuss - Discussions about QA tasks and requests - info ]
20:57:05 <Bequimao> I have false colours at boot whith kernels 4.14.x.
20:57:12 <hviaene> Can I drop MGA5 alltogerher??
20:57:16 <DavidWHodgins> We are still waiting for more spectre/meltdown updates, especially microcode, so Mageia 6.1 and then 7 are still on hold
20:57:34 <wilcal> more kernel's
20:57:44 <DavidWHodgins> lewyssmith: Were you able to reset your password ok?
20:58:19 <lewyssmith> Yes; but I do not gat that far. The screen never finishes loading.
20:58:19 <stratocaster7> lewyssmith: tmb is working on that. They have been discussing it a bit on #mageia-sysadm.
20:58:34 <DavidWHodgins> wilcal: Hopefully the ones we currently have in testing will be the last updates for the fiasco. We'll have to wait and see though
20:58:35 <tjandrews> I still think it would be good if we had Plasma etc. ready for 6.1.
20:58:45 <hviaene> alltogerher =alltogether
20:58:46 <DavidWHodgins> tjandrews: Agreed.
20:58:48 <lewyssmith> Certainly.
20:58:55 <tmb> lewyssmith, I can add you manually to qa-discuss for now
20:59:23 <tmb> (while I need to fix some remaining sympa issues)
20:59:29 <lewyssmith> Thanks. It can wait. Life is peacfeul without it, & one can work!
20:59:34 <DavidWHodgins> :-)
20:59:46 <DavidWHodgins> Looks like countdown time then.
20:59:50 <DavidWHodgins> t - 5
20:59:52 <wilcal> bye all
20:59:53 <DavidWHodgins> 4
20:59:56 <DavidWHodgins> 3
20:59:58 <DavidWHodgins> 2
20:59:58 <hviaene> an I drop MGA5 alltogerher??
20:59:59 <tarazed_> Herman: your decision.  There are still people using it though - some on this page.
20:59:59 <lewyssmith> Goodbye all.
21:00:20 <tarazed_> Cheerio.
21:00:37 <DavidWHodgins> hviaene: Doesn't hurt to keep it around, just in case for a while. Depends on how tight for space your system is.
21:00:40 <DavidWHodgins> 1
21:00:47 <DavidWHodgins> Thanks for coming everyone
21:00:53 <DavidWHodgins> #endmeeting