=== sz0 is now known as sz0`
[02:51] <mwhudson> baah
[02:51] <mwhudson> my x220's sd card reader appears to not work in trusty :(
=== sz0` is now known as sz0
=== sz0 is now known as sz0`
[04:46] <pseudocode77> hello
[06:02] <pitti> Good morning
[06:02] <pitti> dobey: hey
[06:02] <pitti> infinity: sorry, was travelling back from the sprint
=== vibhav is now known as Guest30409
[06:08] <dholbach> good morning
[06:10] <anirudha> I want to pack pre-compiled binary files in a .deb package. Can anyone tell me the minimum set of tools that are needed to achieve  this?
[06:11] <infinity> pitti: I assume you'll be around to chair in two weeks? :)
[06:12] <infinity> pitti: Also, since my magic powers don't yet work (and no point caring until the SSO stuff is done), can you retry binutils/i386?
[06:13] <cjwatson> anirudha: Bare minimum for creating any -dev package is build-essential; but it's less effort to use debhelper as well, in which case you can just use dh_install(1) to put the files in place in the output .deb
[06:13] <pitti> infinity: yes, hopefully; it's a ridiculously bad time for me, with the new TB we should maybe do a new poll for a new time
[06:13] <cjwatson> anirudha: ("for creating any .deb package", I mean)
[06:14] <infinity> pitti: Yeah, I noted the same thing at the end of the meeting.
[06:15] <pitti> infinity: kicked binutils and a few others
[06:15] <infinity> pitti: Not counting conferences and other travel, you're currently the only European on the TB, the rest are spread across 4 timezones in North America.
[06:16] <infinity> pitti: Not sure what would be best for that, but we can probably sort something out.
[06:16] <pitti> infinity: we can just do a new doodle?
[06:17] <infinity> pitti: Sure, doodle away.
[06:17] <infinity> pitti: Mostly, you'll probably find that it'll be scheduling your timezone against slangasek's meeting schedule, and the rest of us will be fairly flexible, I imagine.
[06:20] <pitti> hmm, ubuntu desktop now pulls in a gazillion qml/qt5 packages
[06:20] <anirudha> cjwatson: So do I get dh_install with the package debhelper?
[06:20] <cjwatson> Yes
[06:22] <anirudha> cjwatson: Do I need to install dh_make for creating the correct directory/file structure or debhelper is enough?
[06:23] <cjwatson> No, you don't.  dh_make is just a helper for people unfamiliar with packaging
[06:24] <cjwatson> But it's entirely possible (and often reasonable) to create the small number of files directly
[06:26] <cjwatson> Of what dh_make -s creates, the only files you strictly need are debian/{changelog,control,copyright,rules}, though you should probably also keep debian/source/format, and if you use debhelper you should also keep debian/compat
[06:27] <cjwatson> (If you don't use debhelper, you would need to write a much longer debian/rules; it's not usually worth the effort)
[06:28]  * infinity sighs at easymock trying to pull the entire maven world into main via the new dep on libobjenesis-java ...
[06:28]  * infinity decides this isn't something to try to fix at 12:30am.
[06:28] <jfi> tedg, Trevinho, Hello, I reproduce with the sample at: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators, just add app_indicator_set_label(indicator, "L", "GUIDDDDDE"); at line 165
[06:29] <jfi> tedg, Trevinho, http://pastebin.com/4w8q9VLb
[06:33] <infinity> jamespage: Can libhamcrest-java be made to not nead easymock, or easymock neutered to not need libobjenesis-java?  That chain has decided to pull all things maven into main. :/
[06:33] <anirudha> cjwatson: You are right. I will be automating the process through a script, so dh_make won't help me in any special way.
[06:36] <anirudha> cjwatson: Are you aware of any Ubuntu specific alternative of debhelper? For example (correct me if I am wrong) an alternative to dh_make is bzr-builddeb.
[06:39] <infinity> anirudha: bzr builddeb is just a friendly wrapper that exports a bzr branch and then runs dpkg-buildpackage.
[06:39] <infinity> anirudha: The debian/* bits still need to exist first.
[06:43] <anirudha> infinity: Thanks. That cleared my doubts.
[06:48] <mitya57> When Utopic didn't even have a code name, I sponsored gnome-panel/1:3.8.0-1ubuntu12 to Trusty SRU queue, now it is accepted there. Should I copy it to Utopic (with binaries), or do another upload with version bump, or nothing?
[06:50] <infinity> mitya57: I wouldn't copy it until it gets to updates, or you may find yourself in a bit of a weird versioning bind if it fails SRU validation.
[06:50] <infinity> mitya57: But you could always do a -1ubuntu13 upload to utopic and just not worry about the copy.
[06:51] <mitya57> infinity: Thanks. My main concern was that it could be not copied to -updates until Trusty gets it, that is probably not true.
[06:51] <infinity> mitya57: (As in, that's never the wrong thing to do, it's just sometimes people are lazy and expect others will do the copy forward for them so they don't have to do two uploads :P)
[06:51] <infinity> mitya57: s/Trusty/Utopic/ in your last sentence?
[06:52] <mitya57> Of course.
[06:52] <infinity> mitya57: No one will block the SRU copy on if the fix has landed yet in utopic, no.  But it's also a headache to track the differences and make sure everything's happy, so if you're at all concerned, just do the second upload.
[06:53] <infinity> mitya57: It's not like you're saving any mirror space by being clever with the copy, given that it's gnome-panel, and it'll have a dozen uploads this cycle anyway. :P
[06:53] <mitya57> Maybe I'll do a Debian merge if I have time :P
[06:56] <infinity> mitya57: Oh, speaking of things you uploaded.  Congrats on your sync that failed everywhere EXCEPT powerpc.  That's got to be a first.
[06:56] <infinity> mitya57: (owncloud-client/1.5.3+dfsg-1)
[06:56] <mitya57> infinity: I filed a bug to Debian yesterday, if I don't get any response, I'll just ignore the tests failures
[06:57] <mitya57> I think it has something to do with parallel running (is the powerpc buildd single-core?)
[06:57] <infinity> mitya57: The machine it build on would have been -j2
[06:57] <infinity> mitya57: While the x86 buildds were -j8, armhf was -j4, arm64 was -j8, and ppc64el was... Also -j8
[06:58] <infinity> mitya57: So, yeah, a fair guess.
[06:58] <infinity> mitya57: And the answer there wouldn't be to ignore failures, but to make the testsuite not parallelise.
[06:59] <infinity> mitya57: You just got lucky in landing on a -j2 ppc builder, I guess.  Your other options in that pool were -j4 and -j24 (yes, 24).
[06:59] <mitya57> infinity: Will dh_auto_test -- -j1 do the trick? Or will that result in two conflicting options?
[06:59] <sarnold> -j24? oooo
[06:59] <sarnold> seems a real pity to knock a -j24 machine down to a -j1 test suite, heh
[07:00] <infinity> mitya57: Not sure the best way to do it without looking at the package.
[07:00] <mitya57> sarnold: The test suite is quite small, takes seconds to run
[07:00] <mitya57> infinity: It is using cmake/ctest
[07:01] <sarnold> mitya57: ah :) that's not so bad then
[07:01] <sarnold> especially if it makes the results repeatable. :)
[07:02] <infinity> mitya57: So, you could lose --parallel entirely from dh, or try --max-parallel=1 with dh_auto_test, but not sure if the latter would work if the cmake magic already picked up and hardcoded -j8 earlier in the build process.
[07:03] <infinity> cmake and I aren't the best of friends.
[07:03]  * infinity checks locally to see how reproducible this is.
[07:03] <infinity> Oh, it also handily prints out the -j2 in the log there, so easy to tell if it's fixed.
[07:04]  * infinity tests.
=== sz0` is now known as sz0
[07:10] <infinity> mitya57: http://paste.ubuntu.com/7357643/
[07:10] <infinity> mitya57: That ran the build -j4 on my laptop, but the testsuite -j1, and passed.
[07:11] <infinity> mitya57: Feel free to steal and upload and comment on the Debian bug, I have no interest in having TIL on that package. :)
[07:11] <mitya57> infinity: Thanks, will now upload & comment :)
[07:21] <mpt> bdmurray, iirc, the formula for a series secondary color is halfway between the primary color and white (#ffffff)
[07:40] <work_alkisg> [gnome|unity]-settings-daemon have an Ubuntu-specific patch, that strips the xkb options for keyboard layout switch:
[07:40] <work_alkisg> if (n_sources < 2 || g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "Unity") == 0)
[07:40] <work_alkisg>                 strip_xkb_option (options, "grp:");
[07:40] <work_alkisg> That's causing many serious keyboard issues and I'm trying to find the person that wrote that patch to discuss about possible solutions, before filing more bug reports (I've reported 5-6 related issues already)
[07:40] <work_alkisg> I think the original patch was in gnome-settings-daemon/debian/patches/unity-modifier-media-keys.patch, but I'm having problems locating the branch history in launchpad, could someone help me find the author of that patch?
=== work_alkisg is now known as alkisg
[07:41] <pitti> doko_: ah yes, that was a temporary glitch yesterday, already fixed an hour later
[07:41] <pitti> doko_: I forgot to retry python3.4 as that failed before, due to -testsuite crashing in postinst
[07:41] <pitti> doko_: retried (as there's a new version now)
[07:42] <infinity> alkisg: http://launchpadlibrarian.net/154896043/gnome-settings-daemon_3.8.5-0ubuntu10_3.8.5-0ubuntu11.1.diff.gz
[07:42] <infinity> alkisg: That looks like the upload that introduced it.
[07:42] <alkisg> So william.hua, thanks a lot infinity
[07:43] <mitya57> alkisg: He is attente on #ubuntu-desktop. Also you could just look at http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/438
[07:44] <alkisg> mitya57: thank you, I'll read some more to prepare my "case", and I'll talk to him later on.
=== doko_ is now known as doko
=== alkisg is now known as work_alkisg
[08:34] <infinity> mitya57: Did you not send the 1-line fix to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746278 or is the BTS just lagging?
[08:34] <ubottu> Debian bug 746278 in src:owncloud-client "owncloud-client: FTBFS: tests fail when ran in parallel" [Serious,Open]
=== sz0 is now known as sz0`
=== sz0` is now known as sz0
=== davidcalle_ is now known as davidcalle
[09:48] <GunnarHj> Thanks for the im-config upload, dholbach. Can you please merge the branch too. Since the branch and archive were out of sync, the robot won't do it.
[09:51] <dholbach> GunnarHj, done
[09:51] <GunnarHj> dholbach: Thanks. :)
[09:51] <dholbach> anytime :)
[09:52] <seb128> dholbach, did you upload the SRU as well?
[09:52] <dholbach> seb128, right now I just uploaded the merge
[09:54] <GunnarHj> dholbach: I think seb128 referred to separate SRU bug, which actually is much more urgent.
[09:54] <dholbach> ah ok
[09:56] <seb128> GunnarHj, dholbach: I was speaking about the "no ibus under qt5" bug (I crossed it yesterday while looking at reports since release)
=== sz0 is now known as sz0`
[10:12] <ara> Hello, we have a bug I would like to get triaged, but not sure if it is the right package
[10:12] <ara> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1313522
[10:12] <ubottu> Launchpad bug 1313522 in OEM Priority Project "There is hibernate option even without an active swap partition" [Critical,New]
[10:13] <ara> does anyone know what package we should file the bug against?
[10:14] <rbasak> pitti: so I'm merging vsftpd, and the existing delta drops the init.d script entirely (replacing with an upstart script)
[10:14] <rbasak> pitti: with bug 1273462 not fixed, having it there is an immediate problem. So does this bug block the systemd story?
[10:14] <ubottu> bug 1273462 in upstart (Ubuntu) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [Critical,Triaged] https://launchpad.net/bugs/1273462
[10:15] <pitti> rbasak: hm, I thought during the TC debate and before Debian figured out how to run upstart an sysv side by side in the packaging? i. e. our dh_installinit has already been changed to ignore --upstart-only and all that
[10:16] <rbasak> pitti: AIUI, it is a Debian policy requirement to make sure that if a maintainer ships an upstart script, and upstart is in use, then any shipped init.d script must not break things.
[10:16] <rbasak> AIUI, this was to be implemented by having /lib/lsb/init-functions detect this situation, to easily cover all init.d scripts that use it.
[10:17] <pitti> rbasak: for now, don't worry too much about putting back init.d scripts I think
[10:17] <rbasak> OK
[10:18] <pitti> rbasak: with systemd one could use the init.d script, but it would make much more sense to use socket activation with vsftp and write a proper systemd unit
[10:19] <rbasak> pitti: my thinking was that if we solved this init.d script issue, then systemd would at least magically work for everything without needing specific systemd work on each package.
[10:19] <rbasak> (thus making the systemd migration much easier)
[10:19] <pitti> rbasak: right, that was the idea; I lived under the impression that upstart vs. init.d conflicts were already handled
=== sz0` is now known as sz0
[10:20] <rbasak> Ah, OK. AFAIK, we have agreed how to handle it, but haven't actually done it.
[10:21] <pitti> rbasak: and /lib/lsb/init-functions seemed to indicate that this was the case already
[10:21] <pitti> ah: it defines init_is_upstart(), but doesn't use it by itself
[10:21] <pitti> thus it seems every init.d script would need to add that? that seems crazy and totally impractical
[10:22] <rbasak> I think the plan is to have init-functions do it, but that's pending.
[10:22] <pitti> rbasak: then again, if you directly call the init.d script instead of using "service", you probably get what you asked for
[10:22] <rbasak> So technically we do need to have every init.d script handle it, but in practice I think everyone's waiting for lsb-functions instead.
[10:23] <rbasak> pitti: indeed, but many people do still call init.d scripts directly. We get bugs filed when things break that way.
[10:23] <pitti> ah, service DTRT
[10:23] <rbasak> cf. "/etc/init.d/networking restart"
=== work_alkisg is now known as alkisg
[10:23] <pitti> rbasak: if you run that, a lot more will actually break, but yes
[10:24] <pitti> perhaps we need to make all init scripts non-executable or so
[10:24] <rbasak> Maybe change the shebangs to some kind of wrapper?
[10:25] <rbasak> Seems a bit extreme though.
[10:25] <rbasak> Though actually, rather than doing it across the board, having a guard-type wrapper that a maintainer can just shebang could be another way of implementing the protection.
[10:26] <rbasak> #!/usr/bin/not-if-upstart /bin/sh -e ...
[10:26] <pitti> rbasak: that would again require to touch all packages
[10:26] <rbasak> Or dh_installinit?
[10:29] <pitti> rbasak: perhaps, yes; and a mass-rebuild; but I think making them non-executable might be easier
[10:30] <ara> cjwatson, is systemd the right package for this issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1313522
[10:30] <ubottu> Launchpad bug 1313522 in OEM Priority Project "There is hibernate option even without an active swap partition" [Critical,New]
[10:30] <pitti> I mean, if people are willingly shooting themselves into the foot by calling init scripts and that is considered a bug, let's make them not able to :)
[10:30] <cjwatson> ara: I thought that was pm-utils, but pitti is more likely to know what's current there
[10:30] <pitti> ara: curious; we have disabled hibernate for many cycles by default now
[10:30] <rbasak> How would real pieces (service, rc etc) call init.d scripts if they are non-executable?
[10:31] <rbasak> By reading their shebangs by hand?
[10:31] <ara> pitti, yes, but we (commercial eng) are remapping hibernate to hybrid sleep
[10:31] <rbasak> Also, the user won't get a helpful message that way.
[10:31] <pitti> ara: could be anything between systemd and the indicator; I'll follow up there
[10:31] <ara> pitti, fantastic, thanks
[10:31] <pitti> ara: ah, so they put it back on? can you please describe what you changed there? (in the bug please)
[10:32] <ara> pitti, sure
[10:33] <pitti> ara: don't tell the design team :) they were quite adamant about disabling hibernate by default
[10:33] <ara> pitti, well, this is hybrid sleep it is not the same thing (although very similar) and we make sure it works :D
[10:34] <pitti> ara: yes, but they said having two options was too confusing
[10:46] <pitti> ara: followed up
[10:46] <ara> thanks
[10:48] <pitti> ara: OOI, if such an issue (non-default configuration, non-essentail functionality) is already "Critical", how do you mark things which are actually critical? :)
[10:49] <ara> pitti, well, I marked it as critical only in the OEM priority task, as it is critical for our schedule, not in the ubuntu task
[10:51] <pitti> ara: yes, sure; I was just interested in how you interpret the importance there
[10:55] <xnox> pitti: rbasak: i am working on a proper snippet to fix "running init.d scripts and get upstart job to launch properly" submitted fixes to debian for sysv-init (service command and invoke-rc.d)
[10:56] <xnox> pitti: rbasak: one more patch is needed in upstart it self, and then we can sync all of that to utopic and sru into trusty.
[10:56] <pitti> xnox: ah nice, thanks for the heads-up!
[10:56] <xnox> pitti: rbasak: as far as i can tell, systemd packaging in debian already does it via /ib/lsb/init-functions.d
[10:57] <xnox> pitti: rbasak: such that under systemd one can just operate init.d files and that does call into systemd appropriately.
[10:58] <xnox> pitti: i'm not running systemd, but can you test that ^ ? e.g. call /etc/init.d/ssh restart and check that it gets restarted via systemd unit?
[10:58] <rbasak> xnox: thanks!
[10:58] <pitti> ah, clever! Is there any piece of shell in Debian which does not have a .d/ yet? :-)
=== MacSlow is now known as MacSlow|lunch
[10:59] <cjwatson> xnox: Yes, it does
[10:59] <cjwatson> cjwatson@sid-systemd-amd64:~$ sudo /etc/init.d/ssh restart
[10:59] <cjwatson> Restarting ssh (via systemctl): ssh.service.
[11:00] <xnox> excellent!
[11:00] <cjwatson> (OK, that's on Debian)
[11:00] <pitti> xnox: still want me to test? (need to reboot, currently running upstart as I'm working with LXC)
[11:01] <cjwatson> My Xen guest is only good for server-ish testing, but useful for what I need
[11:02] <xnox> pitti: i think it's fine. no need.
[11:04] <doko> jamespage, if you didn't see it, the maven mess is just caused by easymock's b-d objenesis
[11:05] <pitti> xnox: tested with udev and ssh, works fie
[11:05] <pitti> xnox: fine, too
[11:05] <jamespage> doko, I did but I've not had time to look yet
[11:06] <pitti> xnox: (VMs for the win :) )
[11:16] <ypwong> rrect
=== _salem is now known as salem_
=== mbiebl_ is now known as mbiebl
[12:01] <pitti> ara: FYI, test-building a fix now
[12:18] <pitti> ara: working well
=== alkisg is now known as work_alkisg
=== MacSlow|lunch is now known as MacSlow
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== pete-woods1 is now known as pete-woods-lunch
[13:56] <jhenke> hi, is somebody willing to sync the efibootmgr package with debian? 0.6.1-3 got into testing shortly after the intial utopic sync, ubuntu is still with the old major release 0.5.4-7ubuntu1
[13:57] <jhenke> which would also resolve the delta btw, as the patch was applied upstrem in 0.6.0 release
=== negronjl-afk is now known as negronjl
[14:16] <doko> apw, supermin ftbfs on armhf
[14:31] <pitti> does anyone know how "rtc" gets into /etc/modules? I don't see it in kmod or any postinst on my system
[14:31] <pitti> rtc isn't a module any more, so startup barfs on that
[14:31] <pitti> cjwatson, apw, xnox ^ do you happen to have an off-hand idea?
[14:31] <cjwatson> hw-detect
[14:31] <cjwatson> ./hw-detect.sh:164:get_rtc_info() {
[14:31] <cjwatson> ./hw-detect.sh:168:             amd64/*) register-module rtc ;;
[14:31] <pitti> cjwatson: ah, thanks!
[14:34] <pitti> cjwatson: so I suppose this should maybe check "modinfo rtc" before it adds that, or should it go completely?
[14:34] <apw> doko, i will ahve a look next, just fixing up ruby-kgio
=== jono is now known as Guest72975
[14:37] <apw> pitti, uggg, are you saying that if someone puts something in /etc/modules and we change that module to builtin their machine will no longer boot ?
[14:37] <apw> pitti, that sounds like we should fix whatever loads them ?
[14:37] <pitti> apw: no no, it still boots
[14:38] <pitti> apw: but that unit shows a failure in systemctl status, which looks ugly
[14:38] <apw> oh didums :)
[14:38] <apw> well i guess that is good, so we find it
[14:38] <pitti> apw: cjwatson already pointed out where it's from
[14:38] <apw> but then again is it a failure, to not load ... as you can't remove it in case they run older kernels no ?
[14:38] <apw> or at least for "some time"
[14:39] <cjwatson> pitti: We could probably just remove it from hw-detect if it's gone permanently from the kernel (and not just a config change or whatever), but we'll need to handle it on upgrades as well since hw-detect is an installer component
[14:39] <pitti> apw: I think we already didn't have it in trusty, did we?
[14:39] <pitti> apw: anyway, it's mostly a cosmetical problem, but it seems odd to try and load a module which we don't even ship
[14:39] <cjwatson> well, arguably need to handle it on upgrades
[14:40] <pitti> ah, that too
[14:40] <pitti> or we silence the unit to ignore missing modules
[14:40] <cjwatson> That seems suboptimal - it's probably good typo detection
[14:40] <pitti> but that makes real bugs harder to detect
[14:41] <apw> pitti, yeah its likely anchient
[14:43] <pitti> our kmod.conf just does
[14:43] <pitti> modprobe $module $args || :
[14:43] <pitti> and indeed /var/log/upstart/kmod.log has similar FATAL messages
[14:43] <apw> we like fatal messages
[14:44] <cjwatson> We could ignore named ones, or (probably better) remove them on upgrade of $some_package
[14:45] <pitti> cjwatson: $some_package == kmod perhaps?
[14:46] <pitti> that seems like the closest one
[14:48] <cjwatson> seems plausible
[14:48] <cjwatson> I guess the idea is let's keep the compatibility crud out of runtime paths
[14:48] <pitti> ack, will file bugs etc. later, need to run now (train arriving)
[14:51] <tkamppeter> pitti, which entry do I need to add to the AppArmor profile to silence the audit messages in bug 1314160?
[14:51] <ubottu> bug 1314160 in cups (Ubuntu) "Apparmor profile violated: cupsd does mknod on /var/cache/samba/gencache.tdb" [Undecided,Triaged] https://launchpad.net/bugs/1314160
=== pete-woods-lunch is now known as pete-woods
=== ChrisTownsend1 is now known as ChrisTownsend
[16:05] <smoser> anyone on sru team care to comment on this...
[16:05] <smoser> bug 1185756 was released to -updates
[16:05] <ubottu> bug 1185756 in drbd8 (Ubuntu Precise) "drbd8-utils not compatible with linux-lts-raring kernel in 12.04" [High,Fix released] https://launchpad.net/bugs/1185756
[16:05] <smoser> but it was not fully fixed.
[16:05] <smoser> does it require a new bug ? for SRU of the change ?
[16:22] <smoser> crickets
[16:22] <smoser> infinity, ^ you have thoughts on that ? Daviey ?
=== bfiller is now known as bfiller-afk
[16:40] <smb> smoser, If there is no clean way otherwise, I guess we could open our own bug with "drbd backport causes regressions" and I create a new source package referring to that one
[16:58] <jhenke> Hi, I would like to ask for a sync of the efibootmgr package with Debian. Debian got a new upstream version into testing shortly after the intial utopic sync. That would bring Ubuntu back to the Debian version, as the only diff has been applied upstream in the new version.
=== Ursinha is now known as Ursinha-afk
[17:05] <cjwatson> jhenke: done
=== Ursinha-afk is now known as Ursinha
[17:29] <jhenke> cjwatson thanks
=== roadmr is now known as roadmr_afk
[17:37] <stgraber> ScottK: edubuntu-server is now in the release pocket
=== roadmr_afk is now known as roadmr
[18:37] <bdmurray> pitti: why is gvfs being SRU'ed to trusty? there is no bug reference
=== bfiller-afk is now known as bfiller
[19:18] <mitya57> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746278#12
[19:18] <ubottu> Debian bug 746278 in src:owncloud-client "owncloud-client: FTBFS: tests fail when ran in parallel" [Serious,Open]
[20:59] <ng1002> Question: Is there a terminal command I can use to launch Gnome3's dash?
=== salem_ is now known as _salem
[23:12] <ScottK> stgraber: Thanks.