[08:00] <oSoMoN> good morning
[08:02] <Laney> hey
[08:06] <davmor2> Morning all
[08:07] <davmor2> Laney: any idea when there will be iso images for AA
[08:07] <Laney> wasn't aware there wasn't tbh
[08:07] <Laney> not that I've tried
[08:08] <Laney> http://cdimage.ubuntu.com/ubuntu/daily-live/pending/ looks ok to me
[08:11] <duflu> davmor2: They work too (I just installed). But expect Unity7 still
[08:12] <duflu> Also the installer icon on the desktop fails - you can find it in the dash
[08:12] <duflu> instead
[08:13] <davmor2> Laney: yes that's not released, released would be in current. Pending is like something in proposed
[08:13] <Laney> I...
[08:13] <Laney> I...
[08:13] <Laney> I know...
[08:13] <Laney> Your question was "when there will be iso images"
[08:13] <duflu> I thought pending meant just pending testing(?)
[08:13] <Laney> it wasn't "why aren't there iso images in current?"
[08:14] <davmor2> duflu: yes the same as proposed
[08:15] <duflu> Kind of... except I also thought that yesterday's pending can be today's 'current' and plenty of stuff in proposed is not installed by default still
[08:15] <duflu> So not related to 'proposed' ?
[08:16] <Laney> It's not related to artful-proposed
[08:16] <Laney> It's just some smoke tests that are run on the images and probably need to be configured for artful still
[08:16] <davmor2> duflu: yes only the yesterdays is todays current bit isn't happening :D
[08:16] <duflu> Well, for most of the year (fingers crossed)
[08:53] <davmor2> Laney: do you know how the transition from unity → gnome will happen?
[08:56] <Laney> ubuntu-desktop will be updated and it will install gnome instead of unity
[09:28] <davmor2> Laney: right but would that happen on upgrades too or just fresh installs, I ask because it isn't how it has happened in the past and was checking on the expected behaviour so I can test for it later
[09:33] <Laney> davmor2: yes upgrades too
[09:34] <Laney> it's sort of open what settings will be migrated and stuff though
[09:39] <davmor2> Laney: right so at the package level it'll be a gnome-x replaces unity-x and so on right rather than what we have done in the past which was to additionally install gnome-x along side unity-x right?
[09:48] <Laney> davmor2: It won't uninstall packages off your system if that's what you are asking
[09:48] <davmor2> Laney: right so people would still be logging into unity by default then
[09:51] <Laney> I don't know what you're trying to get out of me
[09:51] <Laney> No
[09:52] <davmor2> Laney: I'm trying to gauge what would happen on upgrade from 16.04.x to 18.04 and 17.04 to 17.10 so that I can confirm the expected happens basically :)
[09:52] <Laney> I would expect some kind of transition from Unity sessions to GNOME Shell sessions
[09:54] <Laney> it's possible that people will still be able to use Unity but I think that will have to be an explicit choice to go back
[09:54] <davmor2> Laney: right thanks
[09:56] <Laney> maybe at the very start it'll be a bit rough :)
[09:56] <Laney> I think Ken's going to do the initial bit of work there
[09:56] <Laney> (sorry if I made that up)
=== muktupavels_ is now known as muktupavels
[10:43]  * Laney sucks at cdbs
[10:46] <jbicha> Laney: good morning
[10:46] <jbicha> just convert it to dh ;)
[10:47] <jbicha> so, gnome-terminal fails to build because no one submitted Unity7 to https://standards.freedesktop.org/menu-spec/latest/apb.html
[10:47] <Laney> not really something that I maintain
[10:48] <jbicha> and 'make check' runs desktop-file-validate https://bazaar.launchpad.net/~ubuntu-desktop/gnome-terminal/ubuntu/view/head:/debian/patches/01_onlyshowin.patch
[10:48] <Laney> are you sure about that? https://bugs.freedesktop.org/show_bug.cgi?id=97947
[10:48] <ubot5`> Freedesktop bug 97947 in general "validate: Add Unity7 and Unity8" [Normal,New]
[10:49] <jbicha> can we get allison[m] to approve that?
[10:50] <Laney> Just make it say Unity
[10:50] <Laney> The 7/8 thing isn't the relevant any mroe
[10:50] <Laney> s/the/that/
[10:51] <jbicha> ok, gnome-terminal doesn't run on Unity8 but whatever
[10:52] <Laney> if it turns out Unity 8 gets maintained then we can think about this kind of thing again
[10:53] <Laney> but I wouldn't waste time on it atm
[10:53] <jbicha> makes sense
[10:57] <jbicha> are you going to sync the other gstreamer universe pkgs? https://qa.debian.org/developer.php?email=pkg-gstreamer-maintainers%40lists.alioth.debian.org
[10:58] <Laney> I think I need to do python and editing something and rtsp
[11:00] <andyrock> good morning
[11:08] <jbicha> by the way, do-release-upgrade asked me if I wanted to remove obsolete pkgs for artful upgrade; unity8 was part of the obsolete pkgs
[11:10] <Laney> good
[11:11] <jbicha> so many people upgrading may get Unity removed (I'm guessing if they manually installed some indicator or something that wanted Unity the removal might not happen though)
[12:30] <mitya57> Laney, hi, what’s the status of https://code.launchpad.net/~malaperle/ubuntu-themes/ubuntu-themes/+merge/294568 ? Should I include it in my ubuntu-themes landing?
[12:32] <Laney> mitya57: evidently not uploaded, so feel free
[12:33] <Laney> I thought it was though
[12:33] <Laney> so maybe check?
[12:35] <mitya57> Oh right, it was merged
[12:35] <Laney> dunno why the mp isn't marked as so
[13:25] <Trevinho> hey guys
[13:26] <Trevinho> kenvandine: I fixed the issue with shadows and resizing in GS..
[13:26] <kenvandine> Trevinho, woot!
[13:26] <Trevinho> I need to cover other cases tho, so I've not a MP ready yet
[13:26] <kenvandine> Trevinho, what was it?
[13:27] <Trevinho> kenvandine: 'decoration' class had to set the margin (and the border-radious to get rid of the corners) too.
[13:27] <kenvandine> Trevinho, cool, let me know when you have an MP ready
[13:27] <kenvandine> Trevinho, and thanks!
[13:28] <Trevinho> kenvandine: sure
[13:28] <Trevinho> kenvandine: for now you can just have the fix with
[13:28] <Trevinho> http://pastebin.ubuntu.com/24505169/
[13:32] <GunnarHj> jbicha: Any chance you can sponsor the gnome-user-docs patch? Since you subscribed to the bug report, I haven't (yet) subscribed ubuntu-sponsors.
[13:36] <jbicha> GunnarHj: I'm already looking at it :)
[13:36] <GunnarHj> jbicha: Cool, thanks!
[14:02] <oSoMoN> qengho, hey, not sure if you saw my question last week about chromium translations?
[14:02] <oSoMoN> I was wondering whether https://translations.launchpad.net/chromium-browser/translations/+templates is still in use?
[14:51] <qengho> oSoMoN: I have some tools to construct debian patches to apply Launchpad translations, but they're not well tested.
[14:52] <qengho> oSoMoN: Upstream doesn't carry any translations from Launchpad.
[15:03] <oSoMoN> qengho, and what about desktop file translations? if we were to update the strings in the desktop file (see bug #1668730), how do we go about updating the template, and then the actual translations in the desktop file, is there a tool for that?
[15:03] <ubot5`> bug 1668730 in chromium-browser (Ubuntu) "Tweak .desktop Actions for more consistency" [Undecided,Confirmed] https://launchpad.net/bugs/1668730
[15:05] <qengho> oSoMoN: I don't know of a tool for desktop file, but there may be a generic one.
[15:06]  * qengho brb
[15:27] <Laney> plars: any chance you could review https://code.launchpad.net/~xnox/utah/skip-wubi-more/+merge/323328 please?
[15:29] <plars> Laney: I'm not a utah guru, and I don't really have a good way to test it but I can sanity check and ack if that's all you need?
[15:30] <Laney> plars: if it gets merged that's what I need
[15:30] <plars> Laney: done!
[15:30] <Laney> thanks :D
[15:31] <Laney> now... hope the smoke tests run from the branch
[15:31] <plars> Laney: I have no idea if someone has it setup with tarmac, so let me know if I need to manually merge it or something
[15:33] <xnox> plars, to be honest that python script is fairly stand alone. I believe i did run it just against the iso, sans any utah-voodo
[15:33] <Laney> don't see any bot comments on recent MPs
[15:33] <xnox> plars, it looks like it's manual push thing.
[15:34] <Laney> so no tarmac AFAICT
[15:34] <plars> :(
[15:36] <Laney> then xnox can kick the job again
=== ximion_ is now known as ximion_mtx
=== ximion_ is now known as ximion_mtx
[15:41] <oSoMoN> qengho, I take it from your previous comment about upstream that http://davidplanella.org/chromium-opens-to-community-translations-in-launchpad/ is no longer a thing?
[15:43] <plars> Laney: xnox: pushed to trunk
[15:45] <Laney> plars: cheers
[15:46] <plars> happy to help
[15:47] <Laney> now if only I had powers on platform-qa-jenkins O:)
[15:48] <xnox> Laney, to be honest, we need to sort that out.
[15:48] <xnox> Laney, i want more admin admin rights there, to grant other people rights.
[15:49] <Laney> go forth and seek them out
[15:49] <xnox> triggered https://platform-qa-jenkins.ubuntu.com/view/desktop/job/ubuntu-artful-desktop-amd64-iso-static-validation/
[15:49] <Laney> looks bad
[15:51] <qengho> oSoMoN: Correct. Chromium has professional translators, and were always a bit hostile to translation contribution.
[15:54] <xnox> Laney, plars - hm, i can't remember how new utah code got deployed. i wonder if there is some recipe that builds the packages and updates things. cause i can't see any checkouts of code anywhere at the moment.
[15:55] <Laney> xnox: I think it might have to be deployed on that venonat host
[15:56] <xnox> https://code.launchpad.net/~utah/utah/dev/+recipes
[15:56] <xnox> looks encouranging
[15:56] <xnox> it was built by magic 8 minutes ago. i wonder if it got triggered on commit somehow
[15:56] <xnox> https://code.launchpad.net/~canonical-platform-qa-jenkins/+recipe/utah-production
[15:57] <Laney> that's what happens yeah
[15:57] <Laney> but will it get dist-upgraded to on the host?
[15:57] <xnox> let's see if things are better tomorrow =)
[15:58] <Laney> let's forget and remember in a week*
[15:58] <Laney> :P
[16:00] <xnox> aha
[16:00] <xnox> https://platform-qa-jenkins.ubuntu.com/view/All/job/iso-testing-setup/configure
[16:01] <xnox> has things like:
[16:01] <xnox> sudo add-apt-repository -y ppa:canonical-platform-qa-jenkins/canonical-platform-qa-jenkins-prod
[16:01] <xnox> sudo apt-get update
[16:01] <xnox> sudo apt-get install -y --force-yes download-latest-test-iso dl-ubuntu-test-iso utah
[16:01] <xnox> [ -d /data/iso ] || sudo mkdir /data/iso
[16:01] <xnox> sudo chown -R jenkins:jenkins /data/iso
[16:01] <xnox> pip3 install --user junit_xml
[16:01] <xnox> looks one needs to manually trigger it
[16:02] <xnox> INFO: Skipped: Skipping images without wubi.
[16:03] <xnox> win
[16:06] <plars> \o/
[16:08] <Laney> nice
[16:09] <Laney> keep an eye on https://platform-qa-jenkins.ubuntu.com/view/desktop/job/ubuntu-artful-desktop-amd64-smoke-default/2/console
[16:10] <Laney> argh
[16:11] <Laney> next door are doing drilling
[16:12] <flocculant> Laney: downstairs drilling at 11pm couldn't work out why I was so £$%£$%^ at him
[16:14] <xnox> Laney, checkout https://platform-qa-jenkins.ubuntu.com/view/desktop/ now, amd64 went into full test all the things mode now =)
[16:14] <xnox> and i386 will soon too.
[16:14] <xnox> Laney, can we please stop making i386 desktop images?!
[16:15] <Laney> dunno
[16:24] <jbicha> xnox: Ubuntu GNOME was probably days away from announcing that there would be no more UG i386 images after 18.04 LTS when Mark made his little announcement first…
[16:25] <xnox> jbicha, after 18.04? as in you still wanted to make 18.04 LTS i386 images?
[16:25]  * xnox is *sad*
[16:25] <jbicha> xnox: yes, because it's not nice to strand people on 17.04 or 17.10
[16:26] <jbicha> so if you want i386 to go away, at least for flavors now is the time to push for it
[16:26] <Laney> http://cdimage.ubuntu.com/ubuntu/daily-live/current/ looks updated
[16:26] <xnox> Laney, smoke default passed for both i386 and amd64, so the links should be updated, yeah.
[16:27] <xnox> jbicha, you say that about stranding people, the argument was that we will not be able provide security support for i386 for key server and desktop things.
[16:28] <xnox> and therefore it will fallout, e.g. if firefox drops i386 support
[16:28] <xnox> it will affect 16.04, as we do wholesome backports for firefox security updates.
[16:28] <tjaalton> and upgrades would still be possible without images
[16:28] <jbicha> xnox: do you want to start the ubuntu-devel list thread then?
[16:28] <xnox> tjaalton, yes that.
[16:29] <jbicha> tjaalton: the Ubuntu GNOME proposal was to *kill* upgrades too
[16:29] <tjaalton> jbicha: ah
[16:29] <xnox> jbicha, no, you will not be allowed to do that.
[16:29] <jbicha> update-manager/do-release-upgrade would not allow upgrading past 18.04 LTS
[16:29] <xnox> because it is a lot of pain, on the archive maintaince side of things
[16:29] <xnox> we have tried to e.g. kill upstart on s390x alone, and that caused a hell of a lot of pain, due to transient arch:all packages.
[16:29] <xnox> which jump hoops with arch:any depends.
[16:29] <jbicha> of course, there is a workaround if someone really wanted to install i386 but it wouldn't be supported by Ubuntu GNOME
[16:30] <jbicha> xnox: I think I'm talking about something different than what you are?
[16:30] <jbicha> also, flavors tend to have shorter support frames
[16:31] <jbicha> https://wiki.ubuntu.com/UbuntuGNOME/32bit_support
[16:31]  * ogra_ sighs ... so my terminals are back to taking minutes to start when spawned with ctrl-alt+t ... and i forgot what the workaround was that i had to use last time this happened
[16:31] <xnox> not really, most flavors did sign up for the full LTS cycles.
[16:31] <xnox> jbicha, i think we will keep packages in the archive. Even if we e.g. publish i386 ones into universe, and amd64 ones into main.
[16:32] <flocculant> xnox: which flavour signed up for full LTS cycle? I know Xubuntu doesn't
[16:32] <jbicha> xnox: I think Kylin was the only flavor to do 5 years for 16.04
[16:33] <jbicha> Kylin 16.04 was just Unity plus a bit more so that makes sense
[16:33] <flocculant> not sure about Kubuntu - but I pretty sure others are 3 years
[16:34] <xnox> flocculant, need to check the ubuntu-publishing thing with the info.
[16:34] <jbicha> xnox: yes, if you read the wiki link I posted, I explicitly said that i386 packages would still be built for now; there just wouldn't be images and do-release-upgrade wouldn't let you upgrade
[16:34] <xnox> apt-cache should show the years of support field.
[16:35] <xnox> which for kubuntu on xenial appears to be 9m =/
[16:35] <xnox> xubuntu is 3y
[16:35] <xnox> at least as per metadata
[16:36]  * flocculant is glad you said that ...
[16:36] <jbicha> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/#Official_flavours
[17:01] <xnox> ok, email sent.
[17:01] <xnox> i hope this is not going to hit softpedia / omg ubuntu / what-not like the upstart email i sent the other day
[17:03] <jbicha> xnox: you might as well email them too since you know they're going to report it :|
[17:04] <xnox> jbicha, well, i added an opening note for those journalists.
[17:05] <jbicha> why do you want to maintain the upgrade path?
[17:05] <jbicha> if you think it's unsupportable, then don't have an easy upgrade button!
[17:05] <xnox> jbicha, i do not want to maintain the upgrade path; but we will maintain the archive, because otherwise it is a load of pain
[17:06] <jbicha> well you used the words "upgrade path"
[17:06] <xnox> jbicha, server/IoT will be supported, and unwinding desktop on one arch, but not the others is a lot of work, and it constantly clogs up britney as we have discovered when we compiled unity8 on s390x by accident and then tried to back-paddle out of it.
[17:06]  * xnox goes to read my message again
[17:07] <jbicha> xnox: why can't we just have do-release-upgrade and update-manager *not* offer the upgrade if ubuntu-desktop (or similar metapackage) is installed?
[17:07] <xnox> jbicha, on the flavors bit. Yes, because it will be available. We may choose not to publish upgrade-manager metadata, but the upgrade will be available.
[17:08] <xnox> jbicha, we can, but one is better off with supported i386 base from 18.04 even if the desktopy stuff is not supported anymore.
[17:08] <xnox> because we will maintain the core/base/platform stuff for i386 still in 18.04 due to IoT and cloud-guest.
[17:08] <jbicha> xnox: then they can just use the netinst or manually hack their sources.list
[17:08] <xnox> my ultimate thinking there was this
[17:09] <xnox> we cannot safely or easily or automatically cross-grade people from i386 to amd64
[17:09] <jbicha> right
[17:09] <xnox> thus we will keep the archive there (even if with updates enabled)
[17:09] <xnox> and just wait for all of them to reinstall into amd64.
[17:09]  * xnox by updates i mean upgrade-manager
[17:10] <xnox> "continue to support the declining i386 classic desktop/server user base"
[17:10] <xnox> and by support, i mean not do much at all =)
[17:10] <jbicha> unless you make it difficult for them, some people will keep using i386 for as long as they can
[17:10] <oSoMoN> qengho, thanks, that confirms what I suspected
[17:10] <jbicha> if it's a pain to install, then they might just try the easier amd64 option
[17:10] <xnox> jbicha, i don't want to break people's installs intentionally. The biggest drop-off of i386 usage came from stopping  advertising the images.
[17:11] <xnox> (existing installs)
[17:11] <jbicha> how will it break installs?
[17:11] <xnox> by making them insecure, because we will have a supported i386 kernel, and I do want people to use supported i386 kernels.
[17:11] <xnox> disabling upgrades, is effectively making those installs vulnerable.
[17:12] <xnox> because internet is a nasty place with funny cat videos.
[17:12] <jbicha> I'm sure there will be plenty of guides showing them how to install from netinst because it's not *that* difficult
[17:16] <jbicha> I got the impression that in a year or two or so, we will break people's installs by forcibly removing Firefox from i386 computers?
[17:17] <jbicha> so it would be better to be more firm about making existing users aware that the platform is no longer supported for desktops
[17:21] <mdeslaur> I don't think we should upgrade i386 users to later releases...just let them get to the end of their support period and have update-manager just pop up the usual "no longer supported" dialog
[17:21] <xnox> jbicha, well, if we remove firefox i386, i'm sure we will install something useful to replace that. e.g. w3m or elinks....
[17:21]  * xnox *giggles*
[17:21] <mdeslaur> we will unlikely be testing i386 desktop packages if we don't have install media
[17:22] <xnox> mdeslaur, we currently uder test i386 install media; but we do test i386 packages quite a bit via autopkgtesting. But it is more server/cli focused.
[17:22] <mdeslaur> yeah, but we do test i386 security updates
[17:22] <xnox> mdeslaur, i disagree about the ugprade paths. Leaving i386 users on 17.04 is sad, leaving them on 16.04 or 18.04 is responsible.
[17:22] <mdeslaur> which we probably won't be doing anymore
[17:23] <xnox> mdeslaur, you will because of iot.
[17:23] <mdeslaur> xnox: not desktop packages, no
[17:23] <xnox> and that does include web browser engine
[17:23] <xnox> because of sinage
[17:23] <xnox> signage?
[17:23] <xnox> the kiosk thing
[17:24] <mdeslaur> xnox: I guess getting broken updates is better than getting no updates
[17:24] <mdeslaur> perhaps
[17:24] <xnox> mdeslaur, i don't buy that no test security updates. You are doing them for i386 for 16.04. Thus we can at least make 18.04 i386 desktop a 3year support thing, no?
[17:24] <xnox> mdeslaur, or possibly 4yr because of 16.04 ESM
[17:24] <xnox> mdeslaur, yeah, i am for broken updates on i386.
[17:25] <xnox> at least we will have some feedback about that, rather than leaving, knowngly, vulnerable machines out there.
[17:25] <mdeslaur> xnox: you're suggesting supporting i386 18.04, but just not having install media?
[17:25] <xnox> yes.
[17:25] <mdeslaur> sorry, I need to re-read your post
[17:26] <mdeslaur> I guess we could netinst a desktop system for testing
[17:26] <xnox> mdeslaur, we support existing installs only "continue to support the declining i386 classic desktop/server user base"
[17:26] <xnox> mdeslaur, you will boot the cloud image and install ubuntu-desktop
[17:26] <xnox> we will have cloud images, because we must for cloud-guest container; buildds; adt testing; and to produce/test iot & core/snappy.
[17:27] <mdeslaur> I can install a cloud image on real hardware?
[17:28] <xnox> mdeslaur, yes.
[17:28] <xnox> mdeslaur, it's call MAAS or subiquity
[17:29] <mdeslaur> ah, with the subiquity installer, I see
[17:29] <xnox> have you tried subiquity? the UX is amazing
[17:29] <mdeslaur> xnox: can I use my mouse? :P
[17:29] <xnox> althought it did not succeed for me, to complete.
[17:29] <mdeslaur> no, I didn't try it
[17:30] <xnox> mdeslaur, better you can use Alexa to guide it, thanks to the Amazon Cloud Voice recognition API
[17:30] <mdeslaur> lol
[17:30] <xnox> and auto-configuration with router config.
[17:42] <jbicha> GunnarHj: I think I'll have gnome-user-guide recommend ubuntu-docs if you don't mind (instead of depends)
[17:44] <GunnarHj> jbicha: In that case I actually think that depends is more correct. Given the pending changes in debian/rules, gnome-user-guide won't work without ubuntu-docs (no index.page file).
[17:45] <jbicha> it depends on how big of a deal the "circular dependency" problem really is
[17:45] <GunnarHj> Is that bad style?
[17:45] <jbicha> I don't think I've ever experienced a problem because of it, but Debian people tell me it is bad
[17:45] <GunnarHj> ok
[17:46] <GunnarHj> jbicha: But then I'd say depends in gnome-user-docs and recommends in ubuntu-docs, i.e. the other way around.
[17:46] <jbicha> I believe Debian upgrades are more complicated than Ubuntu ones
[17:47] <jbicha> GunnarHj: ok, I'll upload gnome-user-docs with Depends: ubuntu-docs
[17:47] <GunnarHj> jbicha: Should I make that change in ubuntu-docs?
[17:48] <GunnarHj> i.e. recommends instead of depends...
[17:48] <Henster> hey guys , my new Msi windows laptop is looking a bit lonley should i install the 16 lts or the new 17 dual boot  .. i like the idea i only need to partision one for version 17 drive ?
[17:49] <jbicha> GunnarHj: yes, unless someone else says we can ignore the circular dependency issue on Ubuntu
[17:50] <GunnarHj> jbicha: Let's be cautious; I'll change it.
[17:52] <Henster> should i just do Gnome .. aaah im so undesided now ,, want to cry ,,,
[18:17] <GunnarHj> jbicha: Just to be clear: I can wait with uploading ubuntu-docs 17.10.3 until after gnome-user-docs is in release, right?
[18:23] <jbicha> GunnarHj: yes or you can upload now
[18:26] <GunnarHj> jbicha: Hmm.. Suppose I can do it now since it no longer *depends* on u-g-d. I'll do so, so we have all the control stuff in place.
[18:40] <cyphermox> jbicha: g-c-c MIR is "accepted" inasmuch as the only issue I have with it is that unit tests aren't being run
[18:42] <jbicha> cyphermox: since you're here, could you look into LP: #1687474 and LP: #1686726 ?
[18:42] <ubot5`> Launchpad bug 1687474 in gnome-user-docs (Ubuntu) "[MIR] gnome-user-docs" [Undecided,New] https://launchpad.net/bugs/1687474
[18:42] <ubot5`> Launchpad bug 1686726 in gnome-getting-started-docs (Ubuntu) "[MIR] gnome-getting-started-docs" [High,Triaged] https://launchpad.net/bugs/1686726
[18:43] <cyphermox> sure, they're open tabs, I just had to deal with other stuff first :)
[18:45] <cyphermox> oh, dh_scour: we should fix that, I saw another such bug and I should still have some code somewhere
=== JanC is now known as Guest52042
=== JanC_ is now known as JanC
[18:49] <jbicha> could you be more specific about control-center? it looks to me like we are not disabling tests there
[19:04] <cyphermox> jbicha: g-s-s, I got things mixed up
[19:06] <jbicha> ok, understood