[05:35] <pitti> Good morning
[05:37] <pitti> cjwatson: add systemd to minimal> TBH I don't understand the purpose -- it's not necessary in e. g. a schroot, and dependencies should do the rest
[05:38] <pitti> cjwatson: we still haven't discussed what we do with the "init" metapackage; if we are going to adopt it, we should IMHO seed this and only this instead
[05:39] <pitti> doko_: RAM on autopkgtest machines> 1 GB by default, 4 GB for large packages like eglibc, libo, linux
[05:40] <doko_> pitti: ahh, how can this be raised?
[05:41] <doko_> python2.7 assumed >= 4GB on amd64 systems
[05:41] <pitti> doko_: I'll just add a little config snippet; 3.4 too?
[05:42] <pitti> doko_: 2.7's test currently succeeds; did you add a workaround for that which you want to drop?
[05:43] <doko_> pitti, sure. no, reverted the upstream patch
[05:43] <doko_> can you re-upload after the reversal?
[05:43] <doko_> will be online again tonight
[05:46] <pitti> doko_: config pushed, next 2.7 run will have 4 GB
[05:46] <pitti> doko_: sorry, reupload what?
[05:47] <pitti> doko_: oh, you mean revert https://launchpad.net/ubuntu/+source/python2.7/2.7.8-9ubuntu1 ? sure, can do that
[05:48] <pitti> doko_: btw, we can only set that for x86, ppc64el and armhf machines just don't have that much RAM; for that the test should be fixed
[05:55] <pitti> doko_: uploaded
[05:55] <doko_> sure
[05:55] <doko_> thanks
[06:01] <ari-tczew> pitti, bdrung, tumbleweed: about script syncpackage: it's not possbile to sync some packages, seems to be a reason of FFe. e.g. syncpackage mugshot - http://paste.ubuntu.com/8505156/ - looks fine and I should get an e-mail about sync processed, but I didn't get it. There is no that synced package on Launchpad, as well. is it a bug, or everything is fine?
[06:02] <doko_> ari-tczew, https://launchpad.net/ubuntu/utopic/+queue?queue_state=1
[06:02] <darkxst> pitti, hey, do you know if accountsservices sets LANG prior to display manager firing up?
[06:03] <pitti> darkxst: "set" where? the system default locale is supposed to be in /etc/default/locale, and DMs are supposed to read that
[06:03] <ari-tczew> doko_: is it autoblocked by bot?
[06:04] <pitti> ari-tczew: we are in pre-release freeze
[06:04] <pitti> ari-tczew: thus uploads of all packages that are in any of a derivative get caught in unapproved for release team review
[06:05] <darkxst> pitti, gdm (3.14) is overriding LANG with the value read from accountsservies, which on Ubuntu breaks badly
[06:05] <darkxst> I've disable that, but is it correct to assume, LANG is fine at that point
[06:05] <pitti> darkxst: oh, you mean for the started session, not for the DM UI itself
[06:05] <darkxst> pitti, yes for the started session
[06:05] <pitti> darkxst: yes, if you can talk to accountsservice the language should be correct
[06:05] <pitti> it just reads some config files
[06:06] <ricotz> darkxst, hi, i reverted that in my earlier snapshot too, but i am suprise it didnt hit me this time, meaning ~uptoic1 works here
[06:06] <ricotz> ~utopic1 ;)
[06:06] <ricotz> pitti, hi
[06:06] <pitti> hey ricotz, wie gehts?
[06:07] <darkxst> pitti, no, Ubuntu accountservices only store the language (en_US) not the full locale (en_US.UTF-8) as needed for LANG
[06:07] <ricotz> pitti, danke gut, ich hoffe dir auch! :)
[06:07] <darkxst> ricotz, I don't see how it could work when it ends up LANG="en_US" or what not
[06:08] <pitti> yeah, that value is broken
[06:08] <darkxst> pitti, accountsservice is broken?
[06:08] <darkxst> I always though ubuntu patched that compared to other distros
[06:08] <ricotz> darkxst, no idea, but it didnt happen this time LANG is correctly set to de_DE.UTF-8
[06:09] <pitti> darkxst: not to my knowledge (but it's been a long time since I touched it)
[06:09] <pitti> my workstation has
[06:09] <pitti> ANG=de_DE.UTF-8
[06:09] <pitti> GDM_LANG=de_DE
[06:09] <pitti> LANGUAGE=de_DE
[06:09] <pitti> (forgot to copy the first "L", sorry)
[06:09] <pitti> which looks correct
[06:10] <ricotz> pitti, it is related to gdm 3.14
[06:10] <ricotz> darkxst, i guess you are running the complete set of gnome3-staging
[06:10] <ricotz> (additionally g-s and mutter git master)
[06:19] <darkxst> pitti, lightdm seems to set LANGUAGE with the value from accountsservice
[06:20] <darkxst> and there are horrible hacks in g-c-c/u-c-c to deal with that also
[06:20] <darkxst> ricotz, just gnome3-staging, but its unrelated to g-s and mutter
[06:29] <darkxst> ricotz, if gdm doesn't have a saved_language it falls back to querying setlocale for it
[06:30] <darkxst> but if there is a saved_language (which is a direct copy of what comes form accountsservices that will alway be used
[06:31] <darkxst> I think I will just leave it as it now, but if further bugs pop up, will have to teach gdm about Ubuntu's patched accountservice
[06:31] <darkxst> g-c-c won't be a probablem we explicitly set the correct LANG there
[07:50] <mardy> Laney: hi! A hopefully quick packaging question: I now have a package which contains an application + a QML module
[07:51] <mardy> Laney: maybe in the future I'll split the QML module out, but not now
[07:51] <mardy> Laney: in the debian/control file, should I add a "Provides: qtdeclarative5-online-accounts-plugin1.0" (this is the module name), even if that package does not exists=
[07:52] <mardy> ?
[07:52] <mardy> Laney: my goal is that other packages could start depending on that
=== dbarth is now known as dbarth-afk
[08:06] <Laney> hi mardy, I guess you could do but note that Provides don't work with versioned relationships so Depends: qml-blah (>> 1.0) won't get your package.
[08:06] <Laney> Also there are more Qtish people like mitya57 and Mirv who could probably give more specialised advice here
[08:08] <mitya57> mardy: yes, provides will be nice, but please use the new naming scheme (qml-module-foo)
[08:08] <Laney> (FYI I think the package naming scheme is more like qml-module-foo now)
[08:08] <Laney> ha
[08:08] <Laney> I was just checking the UITK and that hasn't been renamed
[08:08] <Laney> did we not go and update existing packages?
[08:09] <mitya57> That is tracked in bug 1342031, I think
[08:09] <ubottu> bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,Triaged] https://launchpad.net/bugs/1342031
[08:11] <Laney> 'kay
[08:13] <mardy> Laney: thanks a lot!
[08:13] <mardy> Mirv: hi! What is your opinion? ^
[08:23] <Mirv> mardy: so you have a binary package that provides both QML module and something else? if nothing depends on "qtdeclarative5-online-accounts-plugin1.0", yes please use qml-module-online-accounts1.0 for example (but that depends on the exact installation location of the QML module)
[08:25] <mardy> Mirv: the module import path is "Ubuntu.OnlineAccounts.Plugin 1.0"
[08:25] <Mirv> mardy: so eg. if your install path is /usr/lib/*/qt5/qml/Ubuntu/OnlineAccounts.1.0, then the package name would be qml-module-ubuntu-onlineaccounts1.0
[08:25] <mardy> Mirv: OK, there's a ".Plugin" more, so I guess qml-module-ubuntu-onlineaccounts-plugin1.0
[08:26] <Mirv> mardy: I think you might want to drop the ".Plugin", nothing else uses such, they are all loadable QML modules
[08:27] <Mirv> mardy: most of the new naming is explained in https://launchpad.net/bugs/1342031
[08:27] <ubottu> Launchpad bug 1342031 in ubuntu-system-settings-online-accounts (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,In progress]
[08:27] <Mirv> although Ubuntu's specialty is using the version number so that multiple versions of the same module could be co-installed
[08:27] <Mirv> upstream doesn't use those
[08:28] <mardy> Mirv: it's a bit different here, the "plugin" does not refer to the fact that this is a QML module; it's really part of the API name (it's an API for developing _plugins_ for Online Accounts)
[08:28] <Mirv> mardy: ah! :)
[08:28] <Mirv> mardy: then it makes sense, but probably the install dir should be Ubuntu/OnlineAccounts/Plugin.1.0 then?
[08:28] <mardy> Mirv: we have Ubuntu.OnlineAccounts.Plugin and Ubuntu.OnlineAccounts.Client (and I'll also remove this module in the process)
[08:29] <mardy> Mirv: yes, that's the install dir
[08:29] <Mirv> mardy: ok, then your suggestion was completely correct, thanks!
[08:29] <mardy> Mirv: actually, it's just Ubuntu/OnlineAccounts/Plugin, with no version number
[08:29] <Mirv> mardy: if you do not install into versioned directory, you may not be planning on co-installable multiple versions and you shouldn't used "1.0" in the package name either?
[08:30] <mardy> Mirv: yes, I think that any future version will be compatible, so I don't need the version number
[08:31] <Mirv> ok
[09:08] <apw> are we aware the screensaver in utopic stopped working completely ...
[09:09] <pitti> WFM; in fact, after suspend I get both the old gnome-screensaver layout and afterwards the lightdm layout (sometimes)
[09:09] <apw> pitti, so you get screen saver if you just sit an wait for it; more than one of us has found the blanking and locking there has stopped
[09:10] <pitti> apw: ah, I'm not using that, so cannot say
[09:10]  * pitti tries
[09:10] <apw> but why would you get gnome-screensaver now?  we don't use that any more
[09:10] <pitti> apw: I take it you verified that locking is actually enabled in settings?
[09:11] <apw> pitti, yep, double checked, because the unity update rebound my keybindings back to the default; because that is polite
[09:11] <pitti> I changed it to lock after 30 s, and nothing happens indeed
[09:12] <pitti> (but without disabling the screen)
[09:12] <pitti> I'll now try with switchign off screen after 1 min and locking after 30 s
[09:14] <apw> pitti, yeah that is the config i have enabled now for testing ...
[09:15] <apw> fthis is filed as bug: #1377847
[09:15] <pitti> apw: confirmed here, nothing happens
[09:15] <pitti> this is a fresh utopic install from yesterday here
[09:16] <pitti> (with my ancient config, though)
[09:16] <apw> pitti, that is good info for the bug :)
[09:17] <ubottu> bug 1377847 in unity (Ubuntu) "unity screen saver no longer blanks nor locks automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1377847
[09:19] <pitti> apw: confirmed with a fresh account, followed up
[09:20] <apw> pitti, good thought
[09:20] <pitti> seb128: peux-tu voir à bug 1377847 ?
[09:20] <ubottu> bug 1377847 in unity (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/1377847
[09:21] <pitti> seb128: ou plûtot, quelqu'un d'équipe du bureau :)
[09:24] <seb128> pitti, hey, that's one for bregma/Trevinho rather (unity team), but yeah I can ping them about it
[09:25] <seb128> or maybe it's due to the g-s-d/gnome-desktop/u-s-d update
[09:25] <seb128> Laney, ^
[09:25] <pitti> seb128: cheers
[09:25] <pitti> seb128: I'm not sure how much we still use gnome-screensaver (we still install it by default, and I sometimes see it)
[09:25] <pitti> seb128: is that still involved at all, or does unity itself do everything now?
[09:25] <seb128> pitti, I'm on vac today, just ran IRC to have a look at the backlog, I can look at it more tomorrow if nobody picks it up before that
[09:25] <pitti> seb128: after suspend I still see g-s-s (and then unity, i. e. entering password twice), so something still triggers it at least
[09:25] <pitti> seb128: ah, cheers
[09:26] <pitti> seb128: not that urgent, but I figure this shoudl be fixed for the release
[09:26] <seb128> pitti, I don't think we use g-s, we keep it for a11y iirc since the unity lock screen is less accessible
[09:26] <seb128> sure should be
[09:27] <LocutusOfBorg1> cjwatson, sorry, about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659734
[09:27] <ubottu> Debian bug 659734 in xfonts-scalable-nonfree "xfonts-scalable-nonfree: use dh_installdeb maintscript support" [Wishlist,Open]
[09:28] <LocutusOfBorg1> Applying this patch gives me a lintian error with "you should build-depend from debhelper, even if you only build arch independent packages"
[09:28] <LocutusOfBorg1> so I didn't apply that part
[09:28] <LocutusOfBorg1> is that ok for you? (I would like to request a sync)
[09:30] <Laney> pitti: seeing two prompts sounds like a unity/gnome-screensaver bug, please file it and ping Trevinho to look
[09:30] <Laney> the other thing may be gnome-desktop3 fallout
[09:30] <Laney> darkxst: looks like org.gnome.SessionManager.Presence is broken by IdleMonitor breakage ?
[09:42]  * Laney tries reverting that change
=== vrruiz_ is now known as rvr
[09:48] <darkxst> Laney, what is broken exactly?
[09:48] <Laney> idle timeout screen locking in unity
[09:51] <Laney> yes, now I have a locked screen
[09:52] <darkxst> Laney, Presence and IdleMonitor arent the same thing are they
[09:52] <Laney> IdleMonitor drives Presence no?
[09:59] <darkxst> Laney, oh yeh, that would make sense
[09:59] <Laney> yeah ...
[09:59] <darkxst> do so gnome-desktop probably trying to call mutter dbus api for idle monitor
[10:05] <cjwatson> LocutusOfBorg1: that part of the patch was essentially resynchronising with an error introduced by the previous NMU, I think; keeping debhelper in Build-Depends rather than Build-Depends-Indep is fine, but make sure that you do so in debian/control.in so that debian/control can be correctly regenerated
[10:06] <LocutusOfBorg1> yes of course
[10:06] <LocutusOfBorg1> I used meld to look at both packages
[10:06] <LocutusOfBorg1> they are fine now :) thanks for explaining, I don't want to comment on the bug since you are here :)
[10:16] <pitti> cjwatson: is there some way of telling ssh to not block on background processes to terminate?
[10:17] <pitti> cjwatson: sometimes tests spawn things like dbus-daemon or other daemons when you run them through ssh, and then ssh never finishes
[10:17] <pitti> $ ssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 & disown; echo done'"
[10:17] <pitti> ^ reproducer
[10:17] <pitti> I didn't find something appropriate in ssh_config nor google :(
[10:17] <pitti> (just the same question)
[10:20] <pitti> this doesn't happen with similar "remote auxverbs" like schroot, chroot, or lxc-attach
[10:20] <rbasak> pitti: does "-n" help?
[10:20] <rbasak> That's my usual first attempt when ssh has oddness to do with that kind of thing.
[10:21] <pitti> rbasak: no, it doesn't
[10:21] <pitti> (above reproducer is harmless and shoudl work everywhere; you can replace localhost with something else, of course)
[10:22] <pitti> my first guess is that it's got something to do with the background process still using ssh's PTY
[10:22] <cjwatson> pitti: -f sort of
[10:22] <cjwatson> though that exits even earlier
[10:23] <pitti> cjwatson: yeah, then I don't get proper stdout/err from the command
[10:23] <pitti> nor an exit code
[10:23] <pitti> and the ssh command still lingers on
[10:25] <pitti> -T also doesn't help (to disable PTY allocation)
[10:25] <apw> pitti, i assume yout want the echo done output but not the output of sleep 5
[10:25] <cjwatson> ssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 </dev/null >/dev/null 2>&1 & disown; echo done'"
[10:26] <cjwatson> works properly
[10:26] <apw> pitti, so i think you just need to redirect stdin,out,err for that
[10:26] <cjwatson> apw: snap
[10:26] <apw> what he said
[10:26] <cjwatson> this is essentially ssh observing that, well, you asked for stdin/out/err and something still has them open
[10:26] <cjwatson> so get all your semantics in sync
[10:27] <pitti> apw: right
[10:27] <pitti> hmm
[10:27] <pitti> NB that the "sleep 5; disown" is just a simple reproducer; in real tests I don't have control over that
[10:28] <pitti> e. g. upstart's tests leak an init process and 4 dbus-daemons
[10:28] <cjwatson> right so disconnect those from stdin/out/err
[10:28] <cjwatson> or rather, get the tester to do that, IMO
[10:28] <pitti> I do redirect the entire output of the test command, but I think I haven't redirected stdin; that might be it
[10:28] <cjwatson> ssh keeps channels open until they are "dead"
[10:29] <cjwatson> i.e. nothing has them open any more
[10:34] <pitti> ok, so since I can't control what a test does, but I still want its stdout/err, I think this doesn't help; I also played around with putting a pkill -g into trap, but that ruins the exit status
[10:35] <rbasak> Would it be reasonable to fail a test that leaves stuff running that is still connected to stdin/out/err when it finishes?
[10:35] <rbasak> Or to kill any processes that still do?
[10:37] <apw> pitti, ah it is uncontrolled children that tests start.  hmmm.
[10:37] <pitti> rbasak: that's what happens right now (it hits the test timeout, kills everything, and fails)
[10:38] <apw> pitti, so, how about disconnecting the two, shove the tests output into a fifo
[10:38] <pitti> of course we can hunt down tests that do that, but it's going to be a lot
[10:38] <apw> pitti, and read that and emit that into your stdout, until the thing exits, then simply stop doing it, and exit
[10:38] <rbasak> pitti: I mean automatically. With lsof for example, but preferably something less hacky?
[10:38] <pitti> apw: yeah, I guess I'll need to add even more tee's and redirects into the already complex plumbing :)
[10:39] <pitti> but at least now I know what it's waiting for, so thanks all
[10:39] <apw> pitti, running tests from other people sucks...
[10:39] <cjwatson> pitti: all the relevant processes should be in the same control group, I think
[10:39] <cjwatson> and you can preserve the exit status in a trap easily enough
[10:39] <cjwatson> save it in a variable, exit $thing ...
[10:39] <pitti> *nod*
[10:40] <apw> as long as you don't kill yourself by accident :)
[10:40] <cjwatson> heh, yeah
[10:41] <pitti> right now I'm roughly doing test_program 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stderr);
[10:41] <pitti> so that I see live output and also keep their stdout/err in files (as test artifacts)
[10:42] <pitti> I suppose I could turn this around, only write to files, and tee those in the outside for live output
[10:42] <pitti> it's not as nice due to buffering not being by-line any more, but it shoudl avoid that
[10:43] <pitti> err, second my_test_stderr is obviously my_test_stdout
[10:43] <pitti> ah no, I can't tee them "outside", as that "outside the test" is still "inside ssh"
[10:43] <pitti> pipeline plumbing is hard :)
[10:48] <apw> pitti, as you are teeing their output anyhow, they will be "not connected to a terminal anyhow" right?  and it is only tail or whatever on that log, its output mode which defines buffering
[10:48] <apw> or as i say if you tee them into a fifo you may keep the current buffering mode
[10:49] <pitti> apw: right, the actual test program will only have the fifos as their stdout/err, but the tees use ssh's
[10:50] <pitti> apw: so indeed redirecting to the files *only* and then tee'ing them in background processes should work better
[10:51] <pitti> err, not tee'ing then, just cat'ing
=== ricmm_ is now known as ricmm
[10:51] <pitti> cjwatson, apw, rbasak: thanks for your input! I have some things to try now
[10:52] <apw> pitti, tailing, but you may need to keep tee in the loop, teing to a fifo, and reading that in ssh, to keep the buffering the same
[10:53] <pitti> so AFAIUI the main thing to avoid is to connect the test (and all of its subprocesses) to ssh's stdin/out/err
[10:54] <pitti> which should already be the case due to the redirection to tee
[10:54] <apw> yep, that is your killer
[10:55] <apw> pitti, well the issue is tee will propogate the issue, ie if tees input survives, then its connection to its output survives, whcih is sshs channel so that stays open
[10:55] <pitti> test_program </dev/null 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stdout);
[10:55] <pitti> AFAICS test_program shoudl not see any of ssh's pipelines? (and this doesn't work, I added the </dev/null)
[10:56] <pitti> apw: ah, of course
[10:56] <pitti> so I just need to kill the tees after test_program exits
[10:56] <apw> so you either need to hard kill both tees if you can find them
[10:56] <apw> or add a new fuse in the gap, which is what i proposed the fifo for
[10:57] <pitti> pkill -g $$ tee?
[10:57] <pitti> yay, that by and large works (just need to properly handle the exit status)
[10:58] <pitti> bazinga!
[10:59] <pitti> apw: thanks so much, I was totally missing the "backpropagation" of stdout liveliness through tee
[10:59] <apw> pitti, great :)
[11:22] <rbasak> pitti: I'm just reviewing this thread: https://lists.ubuntu.com/archives/technical-board/2014-July/001972.html
[11:22] <rbasak> pitti: I think there's a little confusion there that I've only just realised.
[11:22] <rbasak> There were two things we requested not too far together in time.
[11:23] <rbasak> 1. An MRE, which was granted, and which we've excercised. But this wasn't this thread - there was another thread.
[11:23] <rbasak> 2. A larger exception for pushing new upstream feature releases as SRUs. This is what this thread was about.
[11:24] <rbasak> But in https://lists.ubuntu.com/archives/technical-board/2014-August/001992.html you approved the MRE, but not the larger exception.
[11:24] <rbasak> And so the larger exception was inadvertently left hanging I think.
[11:25] <rbasak> pitti: are you satisfied with the QA situation to grant the more major exception on the list, please?
[11:25] <rbasak> Or does this need to go to a TB meeting?
=== MacSlow is now known as MacSlow|lunch
=== dbarth-afk is now known as dbarth
[12:57] <pitti> rbasak: ah yes, it was always meant to be "new versions", not just microreleases
[12:57] <pitti> rbasak: we just don't have a separate list for that
[12:57] <pitti> rbasak: wiki page updated
[13:00] <Saviq> ogra_, hey, you told mzanetti it's not good to do dist-upgrade when testing a silo, can you explain?
=== MacSlow|lunch is now known as MacSlow
[13:01] <ogra_> Saviq, it isnt good to do dist-upgrade at all ... it will fail on many cases where packages have writable bind mounts for files ...
[13:01] <apw> pitti, you used to be jockey king, where did the functionality from that go ... is it ubuntu-drivers-common ?
[13:02] <pitti> apw: right, the logic is in u-d-common, the UI in software-properties-gtk
[13:02] <Saviq> ogra_, oh well, yeah, but how do we test silos otherwise? ;)
[13:02] <ogra_> Saviq, robrus ci tools from phablet-tools have some work-arounds for this (ignoring sources.list and only pulling from silos etc) with which you *can* use dist-upgrade ... by default you shouldnt though
[13:03] <Saviq> ogra_, yeah, I'm generally using robru's tool, it failed for me today though
[13:03] <ogra_> Saviq, for packages known to cause issues .... like lxc-android-config, we have instructions how to install them from recovery
[13:03] <apw> pitti, and does it still automatically offer things like jockey used to do; like bcmwl
[13:03] <ogra_> (where you have no bind mounts)
[13:04] <Saviq> ogra_, yeah, ok, so it's more about dist-upgrade when it upgrades more than just the silo, if we're testing just unity8 (so yeah, maybe not dist-upgrade but install the relevant packages), it should be fine to use apt?
[13:04] <ogra_> Saviq, technically even making the image permanently writable will already taint your tests
[13:05] <ogra_> Saviq, yeah, that should be fine
[13:05] <Saviq> ogra_, sure, once we get images from silos things will be better again ;)
[13:05] <ogra_> yeah
[13:05] <ogra_> that will solve everything :)
[13:05] <Saviq> ogra_, and I'm flashing fresh before installing the silo every time
[13:10] <pitti> apw: yes, it should; there's "ubuntu-drivers autoinstall" (which we run in the installer), and you  should see drivers in software-properties-gtk
[13:11] <pitti> apw: I don't have any on my laptop, but you can test it with /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk
[13:12] <pitti> (that pretends to have a broadcom wifi, an nvidia, and an ati card)
[13:12] <apw> pitti, thanks
[13:12] <rbasak> pitti: thanks!
=== _salem is now known as salem_
=== Ursinha-afk is now known as Ursinha
[14:17] <X1> ey bros
[14:18] <X1> i have the known problem/bug with mounting cryptswap at the startup, lubuntu 14.04, it says,  dev/mapper/cryptswap1 not ready or present, found many threats to that topic, but nothing really helped, someone has a link to solve the problem, or can help me? would be nice!
=== mnepton is now known as mneptok
=== wedgwood is now known as Guest78028
=== wedgwood1 is now known as wedgwood
=== wedgwood is now known as Guest11202
=== charles_ is now known as charles
[15:14] <bdmurray> ted: what would put the first key in this crash on the error tracker? https://errors.ubuntu.com/oops/f10688a8-4ccc-11e4-b8ba-fa163e707a72
=== cyphermox_ is now known as cyphermox
[15:15] <ted> bdmurray, Not sure what you mean by first key
[15:15] <ted> bdmurray, Oh, you mean the /usr/bin/media-hub-server key?
[15:16] <bdmurray> ted: right, that seems wrong
[15:16] <ted> Hmm, yeah. Not sure, seems like a parsing bug.
[15:16] <ted> Like that's part of the stack trace.
[15:17] <bdmurray> ted: it looks like the SAS to me
[15:17] <ted> Sorry, yes.
[15:18] <ted> bdmurray, My device is flashing right now, did you see if media hub has an apport hook?
[15:19] <bdmurray> ted: it doesn't look like it, so its probably whoopsie
[15:19] <bdmurray> ted: its not a recoverable problem so its not that either
[15:20] <ted> bdmurray, Yeah, wonder if it's been a bug that it's had for a while, but got filtered out by the key filter we removed a while back.
[15:31] <smoser> anyone seeing screensaver not dimming screen on utopic or is it just me
[15:32] <smoser> ie, i leave laptop for night, and its unlocked and screen on in the morning.
[15:42] <pitti> smoser: bug 1377847
[15:42] <ubottu> bug 1377847 in gnome-desktop3 (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/1377847
=== mhall119_ is now known as mhall119
[15:45] <smoser> pitti, thanks.
=== Guest84187 is now known as mfisch
=== mfisch is now known as Guest9962
[16:59] <Riddell> Laney: you've been spotted in real life 17:48 < Helen> when i was in the pub (in nottingham) on friday one of the bar staff was wearing a debian conference tee shirt from portland.  think she said her boyfriend works for ubuntu
[16:59] <Laney> lolz
[16:59] <Laney> who is that?
[17:01] <infinity> Someone wears that shirt in public?  To work?
[17:01] <Riddell> Laney: just a member of the quaker geek cabal keeping an eye on things, you have to watch out for the quiet ones
[17:01] <Laney> She told me someone was asking about it
[17:01] <Laney> I had the person killed, but must have missed one. Thanks for the info
[17:02] <maswan> Hey, I wear debconf shirts to work. I prefer giving talks to people stuck in the centos/sl-swamps too. :)
[17:02] <Riddell> a debian t-shirt is a sign of quality bar staff in any bar worth your money
[17:02] <Laney> infinity: You mean you don't just pull the first t-shirt from the pile every morning?
[17:03] <infinity> Laney: I give careful consideration to not looking like a tool. :)
[17:03] <maswan> They are also appropriate for gala dinners, IME.
[17:04] <Laney> ouch
[17:33] <smb> Can someone check the xen package in Utopic. Somehow the publishing history claims it should be moved to release but its not there (xen-4.4.0-0ubuntu8)
=== Guest9962 is now known as mfisch
=== mfisch is now known as Guest33821
[17:57] <cjwatson> smb: fixed, as per #ubuntu-release, just in case anyone only sees scrollback from this channel
=== roadmr is now known as roadmr_afk
=== nik90 is now known as nik90|Dinner
=== roadmr_afk is now known as roadmr
=== nik90|Dinner is now known as nik90
=== Ursinha is now known as Ursinha-afk
=== salem_ is now known as _salem
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk