pitti | Good morning | 05:35 |
---|---|---|
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:37 |
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:38 |
pitti | doko_: RAM on autopkgtest machines> 1 GB by default, 4 GB for large packages like eglibc, libo, linux | 05:39 |
doko_ | pitti: ahh, how can this be raised? | 05:40 |
doko_ | python2.7 assumed >= 4GB on amd64 systems | 05:41 |
pitti | doko_: I'll just add a little config snippet; 3.4 too? | 05:41 |
pitti | doko_: 2.7's test currently succeeds; did you add a workaround for that which you want to drop? | 05:42 |
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:43 |
pitti | doko_: config pushed, next 2.7 run will have 4 GB | 05:46 |
pitti | doko_: sorry, reupload what? | 05:46 |
pitti | doko_: oh, you mean revert https://launchpad.net/ubuntu/+source/python2.7/2.7.8-9ubuntu1 ? sure, can do that | 05:47 |
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:48 |
pitti | doko_: uploaded | 05:55 |
doko_ | sure | 05:55 |
doko_ | thanks | 05:55 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
darkxst | pitti, lightdm seems to set LANGUAGE with the value from accountsservice | 06:19 |
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:20 |
darkxst | ricotz, if gdm doesn't have a saved_language it falls back to querying setlocale for it | 06:29 |
darkxst | but if there is a saved_language (which is a direct copy of what comes form accountsservices that will alway be used | 06:30 |
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 | 06:31 |
mardy | Laney: hi! A hopefully quick packaging question: I now have a package which contains an application + a QML module | 07:50 |
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:51 |
mardy | ? | 07:52 |
mardy | Laney: my goal is that other packages could start depending on that | 07:52 |
=== dbarth is now known as dbarth-afk | ||
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:06 |
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:08 |
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:09 |
Laney | 'kay | 08:11 |
mardy | Laney: thanks a lot! | 08:13 |
mardy | Mirv: hi! What is your opinion? ^ | 08:13 |
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:23 |
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:25 |
Mirv | mardy: I think you might want to drop the ".Plugin", nothing else uses such, they are all loadable QML modules | 08:26 |
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:27 |
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:28 |
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:29 |
mardy | Mirv: yes, I think that any future version will be compatible, so I don't need the version number | 08:30 |
Mirv | ok | 08:31 |
apw | are we aware the screensaver in utopic stopped working completely ... | 09:08 |
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:09 |
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:10 |
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:11 |
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:12 |
apw | pitti, yeah that is the config i have enabled now for testing ... | 09:14 |
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:15 |
pitti | (with my ancient config, though) | 09:16 |
apw | pitti, that is good info for the bug :) | 09:16 |
ubottu | bug 1377847 in unity (Ubuntu) "unity screen saver no longer blanks nor locks automatically" [Undecided,Confirmed] https://launchpad.net/bugs/1377847 | 09:17 |
pitti | apw: confirmed with a fresh account, followed up | 09:19 |
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:20 |
pitti | seb128: ou plûtot, quelqu'un d'équipe du bureau :) | 09:21 |
seb128 | pitti, hey, that's one for bregma/Trevinho rather (unity team), but yeah I can ping them about it | 09:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:30 |
* Laney tries reverting that change | 09:42 | |
=== vrruiz_ is now known as rvr | ||
darkxst | Laney, what is broken exactly? | 09:48 |
Laney | idle timeout screen locking in unity | 09:48 |
Laney | yes, now I have a locked screen | 09:51 |
darkxst | Laney, Presence and IdleMonitor arent the same thing are they | 09:52 |
Laney | IdleMonitor drives Presence no? | 09:52 |
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 | 09:59 |
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:05 |
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:06 |
pitti | cjwatson: is there some way of telling ssh to not block on background processes to terminate? | 10:16 |
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:17 |
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:20 |
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:21 |
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:22 |
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:23 |
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:25 |
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:26 |
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:27 |
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:28 |
cjwatson | i.e. nothing has them open any more | 10:29 |
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:34 |
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:35 |
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:37 |
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:38 |
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:39 |
apw | as long as you don't kill yourself by accident :) | 10:40 |
cjwatson | heh, yeah | 10:40 |
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:41 |
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:42 |
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:43 |
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:48 |
pitti | apw: right, the actual test program will only have the fifos as their stdout/err, but the tees use ssh's | 10:49 |
pitti | apw: so indeed redirecting to the files *only* and then tee'ing them in background processes should work better | 10:50 |
pitti | err, not tee'ing then, just cat'ing | 10:51 |
=== ricmm_ is now known as ricmm | ||
pitti | cjwatson, apw, rbasak: thanks for your input! I have some things to try now | 10:51 |
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:52 |
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:53 |
pitti | which should already be the case due to the redirection to tee | 10:54 |
apw | yep, that is your killer | 10:54 |
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:55 |
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:56 |
pitti | pkill -g $$ tee? | 10:57 |
pitti | yay, that by and large works (just need to properly handle the exit status) | 10:57 |
pitti | bazinga! | 10:58 |
pitti | apw: thanks so much, I was totally missing the "backpropagation" of stdout liveliness through tee | 10:59 |
apw | pitti, great :) | 10:59 |
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:22 |
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:23 |
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:24 |
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? | 11:25 |
=== MacSlow is now known as MacSlow|lunch | ||
=== dbarth-afk is now known as dbarth | ||
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 | 12:57 |
Saviq | ogra_, hey, you told mzanetti it's not good to do dist-upgrade when testing a silo, can you explain? | 13:00 |
=== MacSlow|lunch is now known as MacSlow | ||
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:10 |
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:11 |
pitti | (that pretends to have a broadcom wifi, an nvidia, and an ati card) | 13:12 |
apw | pitti, thanks | 13:12 |
rbasak | pitti: thanks! | 13:12 |
=== _salem is now known as salem_ | ||
=== Ursinha-afk is now known as Ursinha | ||
X1 | ey bros | 14:17 |
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! | 14:18 |
=== 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 | ||
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 | 15:14 |
=== cyphermox_ is now known as cyphermox | ||
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:15 |
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:16 |
bdmurray | ted: it looks like the SAS to me | 15:17 |
ted | Sorry, yes. | 15:17 |
ted | bdmurray, My device is flashing right now, did you see if media hub has an apport hook? | 15:18 |
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:19 |
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:20 |
smoser | anyone seeing screensaver not dimming screen on utopic or is it just me | 15:31 |
smoser | ie, i leave laptop for night, and its unlocked and screen on in the morning. | 15:32 |
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 | 15:42 |
=== mhall119_ is now known as mhall119 | ||
smoser | pitti, thanks. | 15:45 |
=== Guest84187 is now known as mfisch | ||
=== mfisch is now known as Guest9962 | ||
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? | 16:59 |
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:01 |
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:02 |
infinity | Laney: I give careful consideration to not looking like a tool. :) | 17:03 |
maswan | They are also appropriate for gala dinners, IME. | 17:03 |
Laney | ouch | 17:04 |
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) | 17:33 |
=== Guest9962 is now known as mfisch | ||
=== mfisch is now known as Guest33821 | ||
cjwatson | smb: fixed, as per #ubuntu-release, just in case anyone only sees scrollback from this channel | 17:57 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!