/srv/irclogs.ubuntu.com/2014/10/06/#ubuntu-devel.txt

pittiGood morning05:35
pitticjwatson: 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 rest05:37
pitticjwatson: 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 instead05:38
pittidoko_: RAM on autopkgtest machines> 1 GB by default, 4 GB for large packages like eglibc, libo, linux05:39
doko_pitti: ahh, how can this be raised?05:40
doko_python2.7 assumed >= 4GB on amd64 systems05:41
pittidoko_: I'll just add a little config snippet; 3.4 too?05:41
pittidoko_: 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 patch05:43
doko_can you re-upload after the reversal?05:43
doko_will be online again tonight05:43
pittidoko_: config pushed, next 2.7 run will have 4 GB05:46
pittidoko_: sorry, reupload what?05:46
pittidoko_: oh, you mean revert https://launchpad.net/ubuntu/+source/python2.7/2.7.8-9ubuntu1 ? sure, can do that05:47
pittidoko_: 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 fixed05:48
pittidoko_: uploaded05:55
doko_sure05:55
doko_thanks05:55
ari-tczewpitti, 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=106:02
darkxstpitti, hey, do you know if accountsservices sets LANG prior to display manager firing up?06:02
pittidarkxst: "set" where? the system default locale is supposed to be in /etc/default/locale, and DMs are supposed to read that06:03
ari-tczewdoko_: is it autoblocked by bot?06:03
pittiari-tczew: we are in pre-release freeze06:04
pittiari-tczew: thus uploads of all packages that are in any of a derivative get caught in unapproved for release team review06:04
darkxstpitti, gdm (3.14) is overriding LANG with the value read from accountsservies, which on Ubuntu breaks badly06:05
darkxstI've disable that, but is it correct to assume, LANG is fine at that point06:05
pittidarkxst: oh, you mean for the started session, not for the DM UI itself06:05
darkxstpitti, yes for the started session06:05
pittidarkxst: yes, if you can talk to accountsservice the language should be correct06:05
pittiit just reads some config files06:05
ricotzdarkxst, hi, i reverted that in my earlier snapshot too, but i am suprise it didnt hit me this time, meaning ~uptoic1 works here06:06
ricotz~utopic1 ;)06:06
ricotzpitti, hi06:06
pittihey ricotz, wie gehts?06:06
darkxstpitti, no, Ubuntu accountservices only store the language (en_US) not the full locale (en_US.UTF-8) as needed for LANG06:07
ricotzpitti, danke gut, ich hoffe dir auch! :)06:07
darkxstricotz, I don't see how it could work when it ends up LANG="en_US" or what not06:07
pittiyeah, that value is broken06:08
darkxstpitti, accountsservice is broken?06:08
darkxstI always though ubuntu patched that compared to other distros06:08
ricotzdarkxst, no idea, but it didnt happen this time LANG is correctly set to de_DE.UTF-806:08
pittidarkxst: not to my knowledge (but it's been a long time since I touched it)06:09
pittimy workstation has06:09
pittiANG=de_DE.UTF-806:09
pittiGDM_LANG=de_DE06:09
pittiLANGUAGE=de_DE06:09
pitti(forgot to copy the first "L", sorry)06:09
pittiwhich looks correct06:09
ricotzpitti, it is related to gdm 3.1406:10
ricotzdarkxst, i guess you are running the complete set of gnome3-staging06:10
ricotz(additionally g-s and mutter git master)06:10
darkxstpitti, lightdm seems to set LANGUAGE with the value from accountsservice06:19
darkxstand there are horrible hacks in g-c-c/u-c-c to deal with that also06:20
darkxstricotz, just gnome3-staging, but its unrelated to g-s and mutter06:20
darkxstricotz, if gdm doesn't have a saved_language it falls back to querying setlocale for it06:29
darkxstbut if there is a saved_language (which is a direct copy of what comes form accountsservices that will alway be used06:30
darkxstI think I will just leave it as it now, but if further bugs pop up, will have to teach gdm about Ubuntu's patched accountservice06:31
darkxstg-c-c won't be a probablem we explicitly set the correct LANG there06:31
mardyLaney: hi! A hopefully quick packaging question: I now have a package which contains an application + a QML module07:50
mardyLaney: maybe in the future I'll split the QML module out, but not now07:51
mardyLaney: 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
mardyLaney: my goal is that other packages could start depending on that07:52
=== dbarth is now known as dbarth-afk
Laneyhi 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
LaneyAlso there are more Qtish people like mitya57 and Mirv who could probably give more specialised advice here08:06
mitya57mardy: 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
Laneyha08:08
LaneyI was just checking the UITK and that hasn't been renamed08:08
Laneydid we not go and update existing packages?08:08
mitya57That is tracked in bug 1342031, I think08:09
ubottubug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,Triaged] https://launchpad.net/bugs/134203108:09
Laney'kay08:11
mardyLaney: thanks a lot!08:13
mardyMirv: hi! What is your opinion? ^08:13
Mirvmardy: 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
mardyMirv: the module import path is "Ubuntu.OnlineAccounts.Plugin 1.0"08:25
Mirvmardy: 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.008:25
mardyMirv: OK, there's a ".Plugin" more, so I guess qml-module-ubuntu-onlineaccounts-plugin1.008:25
Mirvmardy: I think you might want to drop the ".Plugin", nothing else uses such, they are all loadable QML modules08:26
Mirvmardy: most of the new naming is explained in https://launchpad.net/bugs/134203108:27
ubottuLaunchpad bug 1342031 in ubuntu-system-settings-online-accounts (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,In progress]08:27
Mirvalthough Ubuntu's specialty is using the version number so that multiple versions of the same module could be co-installed08:27
Mirvupstream doesn't use those08:27
mardyMirv: 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
Mirvmardy: ah! :)08:28
Mirvmardy: then it makes sense, but probably the install dir should be Ubuntu/OnlineAccounts/Plugin.1.0 then?08:28
mardyMirv: we have Ubuntu.OnlineAccounts.Plugin and Ubuntu.OnlineAccounts.Client (and I'll also remove this module in the process)08:28
mardyMirv: yes, that's the install dir08:29
Mirvmardy: ok, then your suggestion was completely correct, thanks!08:29
mardyMirv: actually, it's just Ubuntu/OnlineAccounts/Plugin, with no version number08:29
Mirvmardy: 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
mardyMirv: yes, I think that any future version will be compatible, so I don't need the version number08:30
Mirvok08:31
apware we aware the screensaver in utopic stopped working completely ...09:08
pittiWFM; in fact, after suspend I get both the old gnome-screensaver layout and afterwards the lightdm layout (sometimes)09:09
apwpitti, 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 stopped09:09
pittiapw: ah, I'm not using that, so cannot say09:10
* pitti tries09:10
apwbut why would you get gnome-screensaver now?  we don't use that any more09:10
pittiapw: I take it you verified that locking is actually enabled in settings?09:10
apwpitti, yep, double checked, because the unity update rebound my keybindings back to the default; because that is polite09:11
pittiI changed it to lock after 30 s, and nothing happens indeed09:11
pitti(but without disabling the screen)09:12
pittiI'll now try with switchign off screen after 1 min and locking after 30 s09:12
apwpitti, yeah that is the config i have enabled now for testing ...09:14
apwfthis is filed as bug: #137784709:15
pittiapw: confirmed here, nothing happens09:15
pittithis is a fresh utopic install from yesterday here09:15
pitti(with my ancient config, though)09:16
apwpitti, that is good info for the bug :)09:16
ubottubug 1377847 in unity (Ubuntu) "unity screen saver no longer blanks nor locks automatically" [Undecided,Confirmed] https://launchpad.net/bugs/137784709:17
pittiapw: confirmed with a fresh account, followed up09:19
apwpitti, good thought09:20
pittiseb128: peux-tu voir à bug 1377847 ?09:20
ubottubug 1377847 in unity (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/137784709:20
pittiseb128: ou plûtot, quelqu'un d'équipe du bureau :)09:21
seb128pitti, hey, that's one for bregma/Trevinho rather (unity team), but yeah I can ping them about it09:24
seb128or maybe it's due to the g-s-d/gnome-desktop/u-s-d update09:25
seb128Laney, ^09:25
pittiseb128: cheers09:25
pittiseb128: I'm not sure how much we still use gnome-screensaver (we still install it by default, and I sometimes see it)09:25
pittiseb128: is that still involved at all, or does unity itself do everything now?09:25
seb128pitti, 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 that09:25
pittiseb128: after suspend I still see g-s-s (and then unity, i. e. entering password twice), so something still triggers it at least09:25
pittiseb128: ah, cheers09:25
pittiseb128: not that urgent, but I figure this shoudl be fixed for the release09:26
seb128pitti, I don't think we use g-s, we keep it for a11y iirc since the unity lock screen is less accessible09:26
seb128sure should be09:26
LocutusOfBorg1cjwatson, sorry, about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65973409:27
ubottuDebian bug 659734 in xfonts-scalable-nonfree "xfonts-scalable-nonfree: use dh_installdeb maintscript support" [Wishlist,Open]09:27
LocutusOfBorg1Applying this patch gives me a lintian error with "you should build-depend from debhelper, even if you only build arch independent packages"09:28
LocutusOfBorg1so I didn't apply that part09:28
LocutusOfBorg1is that ok for you? (I would like to request a sync)09:28
Laneypitti: seeing two prompts sounds like a unity/gnome-screensaver bug, please file it and ping Trevinho to look09:30
Laneythe other thing may be gnome-desktop3 fallout09:30
Laneydarkxst: looks like org.gnome.SessionManager.Presence is broken by IdleMonitor breakage ?09:30
* Laney tries reverting that change09:42
=== vrruiz_ is now known as rvr
darkxstLaney, what is broken exactly?09:48
Laneyidle timeout screen locking in unity09:48
Laneyyes, now I have a locked screen09:51
darkxstLaney, Presence and IdleMonitor arent the same thing are they09:52
LaneyIdleMonitor drives Presence no?09:52
darkxstLaney, oh yeh, that would make sense09:59
Laneyyeah ...09:59
darkxstdo so gnome-desktop probably trying to call mutter dbus api for idle monitor09:59
cjwatsonLocutusOfBorg1: 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 regenerated10:05
LocutusOfBorg1yes of course10:06
LocutusOfBorg1I used meld to look at both packages10:06
LocutusOfBorg1they are fine now :) thanks for explaining, I don't want to comment on the bug since you are here :)10:06
pitticjwatson: is there some way of telling ssh to not block on background processes to terminate?10:16
pitticjwatson: sometimes tests spawn things like dbus-daemon or other daemons when you run them through ssh, and then ssh never finishes10:17
pitti$ ssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 & disown; echo done'"10:17
pitti^ reproducer10:17
pittiI didn't find something appropriate in ssh_config nor google :(10:17
pitti(just the same question)10:17
pittithis doesn't happen with similar "remote auxverbs" like schroot, chroot, or lxc-attach10:20
rbasakpitti: does "-n" help?10:20
rbasakThat's my usual first attempt when ssh has oddness to do with that kind of thing.10:20
pittirbasak: no, it doesn't10:21
pitti(above reproducer is harmless and shoudl work everywhere; you can replace localhost with something else, of course)10:21
pittimy first guess is that it's got something to do with the background process still using ssh's PTY10:22
cjwatsonpitti: -f sort of10:22
cjwatsonthough that exits even earlier10:22
pitticjwatson: yeah, then I don't get proper stdout/err from the command10:23
pittinor an exit code10:23
pittiand the ssh command still lingers on10:23
pitti-T also doesn't help (to disable PTY allocation)10:25
apwpitti, i assume yout want the echo done output but not the output of sleep 510:25
cjwatsonssh -o StrictHostKeyChecking=no -o CheckHostIP=no localhost -- "bash -ec 'sleep 5 </dev/null >/dev/null 2>&1 & disown; echo done'"10:25
cjwatsonworks properly10:26
apwpitti, so i think you just need to redirect stdin,out,err for that10:26
cjwatsonapw: snap10:26
apwwhat he said10:26
cjwatsonthis is essentially ssh observing that, well, you asked for stdin/out/err and something still has them open10:26
cjwatsonso get all your semantics in sync10:26
pittiapw: right10:27
pittihmm10:27
pittiNB that the "sleep 5; disown" is just a simple reproducer; in real tests I don't have control over that10:27
pittie. g. upstart's tests leak an init process and 4 dbus-daemons10:28
cjwatsonright so disconnect those from stdin/out/err10:28
cjwatsonor rather, get the tester to do that, IMO10:28
pittiI do redirect the entire output of the test command, but I think I haven't redirected stdin; that might be it10:28
cjwatsonssh keeps channels open until they are "dead"10:28
cjwatsoni.e. nothing has them open any more10:29
pittiok, 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 status10:34
rbasakWould it be reasonable to fail a test that leaves stuff running that is still connected to stdin/out/err when it finishes?10:35
rbasakOr to kill any processes that still do?10:35
apwpitti, ah it is uncontrolled children that tests start.  hmmm.10:37
pittirbasak: that's what happens right now (it hits the test timeout, kills everything, and fails)10:37
apwpitti, so, how about disconnecting the two, shove the tests output into a fifo10:38
pittiof course we can hunt down tests that do that, but it's going to be a lot10:38
apwpitti, and read that and emit that into your stdout, until the thing exits, then simply stop doing it, and exit10:38
rbasakpitti: I mean automatically. With lsof for example, but preferably something less hacky?10:38
pittiapw: yeah, I guess I'll need to add even more tee's and redirects into the already complex plumbing :)10:38
pittibut at least now I know what it's waiting for, so thanks all10:39
apwpitti, running tests from other people sucks...10:39
cjwatsonpitti: all the relevant processes should be in the same control group, I think10:39
cjwatsonand you can preserve the exit status in a trap easily enough10:39
cjwatsonsave it in a variable, exit $thing ...10:39
pitti*nod*10:39
apwas long as you don't kill yourself by accident :)10:40
cjwatsonheh, yeah10:40
pittiright now I'm roughly doing test_program 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stderr);10:41
pittiso that I see live output and also keep their stdout/err in files (as test artifacts)10:41
pittiI suppose I could turn this around, only write to files, and tee those in the outside for live output10:42
pittiit's not as nice due to buffering not being by-line any more, but it shoudl avoid that10:42
pittierr, second my_test_stderr is obviously my_test_stdout10:43
pittiah no, I can't tee them "outside", as that "outside the test" is still "inside ssh"10:43
pittipipeline plumbing is hard :)10:43
apwpitti, 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 buffering10:48
apwor as i say if you tee them into a fifo you may keep the current buffering mode10:48
pittiapw: right, the actual test program will only have the fifos as their stdout/err, but the tees use ssh's10:49
pittiapw: so indeed redirecting to the files *only* and then tee'ing them in background processes should work better10:50
pittierr, not tee'ing then, just cat'ing10:51
=== ricmm_ is now known as ricmm
pitticjwatson, apw, rbasak: thanks for your input! I have some things to try now10:51
apwpitti, 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 same10:52
pittiso AFAIUI the main thing to avoid is to connect the test (and all of its subprocesses) to ssh's stdin/out/err10:53
pittiwhich should already be the case due to the redirection to tee10:54
apwyep, that is your killer10:54
apwpitti, 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 open10:55
pittitest_program </dev/null 2> >(tee -a /tmp/my_test_stderr >&2) > >(tee -a /tmp/my_test_stdout);10:55
pittiAFAICS test_program shoudl not see any of ssh's pipelines? (and this doesn't work, I added the </dev/null)10:55
pittiapw: ah, of course10:56
pittiso I just need to kill the tees after test_program exits10:56
apwso you either need to hard kill both tees if you can find them10:56
apwor add a new fuse in the gap, which is what i proposed the fifo for10:56
pittipkill -g $$ tee?10:57
pittiyay, that by and large works (just need to properly handle the exit status)10:57
pittibazinga!10:58
pittiapw: thanks so much, I was totally missing the "backpropagation" of stdout liveliness through tee10:59
apwpitti, great :)10:59
rbasakpitti: I'm just reviewing this thread: https://lists.ubuntu.com/archives/technical-board/2014-July/001972.html11:22
rbasakpitti: I think there's a little confusion there that I've only just realised.11:22
rbasakThere were two things we requested not too far together in time.11:22
rbasak1. An MRE, which was granted, and which we've excercised. But this wasn't this thread - there was another thread.11:23
rbasak2. A larger exception for pushing new upstream feature releases as SRUs. This is what this thread was about.11:23
rbasakBut in https://lists.ubuntu.com/archives/technical-board/2014-August/001992.html you approved the MRE, but not the larger exception.11:24
rbasakAnd so the larger exception was inadvertently left hanging I think.11:24
rbasakpitti: are you satisfied with the QA situation to grant the more major exception on the list, please?11:25
rbasakOr 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
pittirbasak: ah yes, it was always meant to be "new versions", not just microreleases12:57
pittirbasak: we just don't have a separate list for that12:57
pittirbasak: wiki page updated12:57
Saviqogra_, 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
apwpitti, you used to be jockey king, where did the functionality from that go ... is it ubuntu-drivers-common ?13:01
pittiapw: right, the logic is in u-d-common, the UI in software-properties-gtk13:02
Saviqogra_, 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 though13:02
Saviqogra_, yeah, I'm generally using robru's tool, it failed for me today though13:03
ogra_Saviq, for packages known to cause issues .... like lxc-android-config, we have instructions how to install them from recovery13:03
apwpitti, and does it still automatically offer things like jockey used to do; like bcmwl13:03
ogra_(where you have no bind mounts)13:03
Saviqogra_, 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 tests13:04
ogra_Saviq, yeah, that should be fine13:05
Saviqogra_, sure, once we get images from silos things will be better again ;)13:05
ogra_yeah13:05
ogra_that will solve everything :)13:05
Saviqogra_, and I'm flashing fresh before installing the silo every time13:05
pittiapw: yes, it should; there's "ubuntu-drivers autoinstall" (which we run in the installer), and you  should see drivers in software-properties-gtk13:10
pittiapw: I don't have any on my laptop, but you can test it with /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk13:11
pitti(that pretends to have a broadcom wifi, an nvidia, and an ati card)13:12
apwpitti, thanks13:12
rbasakpitti: thanks!13:12
=== _salem is now known as salem_
=== Ursinha-afk is now known as Ursinha
X1ey bros14:17
X1i 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
bdmurrayted: what would put the first key in this crash on the error tracker? https://errors.ubuntu.com/oops/f10688a8-4ccc-11e4-b8ba-fa163e707a7215:14
=== cyphermox_ is now known as cyphermox
tedbdmurray, Not sure what you mean by first key15:15
tedbdmurray, Oh, you mean the /usr/bin/media-hub-server key?15:15
bdmurrayted: right, that seems wrong15:16
tedHmm, yeah. Not sure, seems like a parsing bug.15:16
tedLike that's part of the stack trace.15:16
bdmurrayted: it looks like the SAS to me15:17
tedSorry, yes.15:17
tedbdmurray, My device is flashing right now, did you see if media hub has an apport hook?15:18
bdmurrayted: it doesn't look like it, so its probably whoopsie15:19
bdmurrayted: its not a recoverable problem so its not that either15:19
tedbdmurray, 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
smoseranyone seeing screensaver not dimming screen on utopic or is it just me15:31
smoserie, i leave laptop for night, and its unlocked and screen on in the morning.15:32
pittismoser: bug 137784715:42
ubottubug 1377847 in gnome-desktop3 (Ubuntu Utopic) "unity screen saver no longer blanks nor locks automatically" [High,Confirmed] https://launchpad.net/bugs/137784715:42
=== mhall119_ is now known as mhall119
smoserpitti, thanks.15:45
=== Guest84187 is now known as mfisch
=== mfisch is now known as Guest9962
RiddellLaney: 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 ubuntu16:59
Laneylolz16:59
Laneywho is that?16:59
infinitySomeone wears that shirt in public?  To work?17:01
RiddellLaney: just a member of the quaker geek cabal keeping an eye on things, you have to watch out for the quiet ones17:01
LaneyShe told me someone was asking about it17:01
LaneyI had the person killed, but must have missed one. Thanks for the info17:01
maswanHey, I wear debconf shirts to work. I prefer giving talks to people stuck in the centos/sl-swamps too. :)17:02
Riddella debian t-shirt is a sign of quality bar staff in any bar worth your money17:02
Laneyinfinity: You mean you don't just pull the first t-shirt from the pile every morning?17:02
infinityLaney: I give careful consideration to not looking like a tool. :)17:03
maswanThey are also appropriate for gala dinners, IME.17:03
Laneyouch17:04
smbCan 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
cjwatsonsmb: fixed, as per #ubuntu-release, just in case anyone only sees scrollback from this channel17: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!