[00:26] Hello [00:26] I have a suggestion for Ubuntu interface, is this the right place to put it forward? [00:29] A user has an external monitor on a laptop and generally only uses the external monitor when at home, so turns off the laptop screen using the Ubuntu Displays interface. They have found that unplugging the external monitor in order to wander elsewhere in the home for example, does not automatically reactivate the laptop screen. In such a use case I would have expected this to have been the case. I would ther [00:29] efore recommend such addition or even a checkbox in the Display area to facilitate the toggle of this feature on or off. [01:28] jbassett: it's more likely a particular hardware in a particular laptop causing this behaviour at a lower level [04:25] TheMuso: Could you have a look at Bug #1127461 ? It's causing enough problems it's getting blogged about on Planet KDE. The recommended solution is uninstalling qt-at-spi. [04:25] bug 1127461 in qt-at-spi (Ubuntu) "qt-at-spi crash in Krita and other applications" [Undecided,New] https://launchpad.net/bugs/1127461 [04:26] ScottK: Right, I'd say the solution for raring at least is for you to stop shipping qt-at-spi, as the Qt accessibility code for QT4 is no longer maintained, given the move to Qt5. [04:26] But I'll take a look. [04:27] TheMuso: Thanks. I''m particularly concerned about precise though. [04:27] Ah right. [04:27] The issue, as described in the blog post I saw, affected people in Unity sessions as well. [04:28] RIght. [04:30] TheMuso: I checked and it's not in the Kubuntu seeds, but it is in Ubuntu desktop seed for raring. [04:31] Thanks for looking into it. [04:32] ScottK: Right, a result of people using KDE apps in general. I'll see what I can do, no promises as I am unfamiliar with the code base. Hopefully newer code in the qt-at-spi git repo fixes, it, but I doubt it. [04:32] np [04:32] Thanks. I pinged you since I saw you did the last upload ... [04:32] Fair enough. [06:33] infinity: udev-acl conditional> splendid, thank you! [06:33] Good morning [07:48] good morning === jj-_ is now known as jj- [08:05] stgraber, slangasek, ScottK: I followed up to bug 1153224 with a current status, FYI [08:05] bug 1153224 in systemd (Ubuntu) "[FFE] Move to logind for session tracking" [Wishlist,New] https://launchpad.net/bugs/1153224 [08:07] NB that I won't be totally disappointed if you say "not for raring"; I'm mostly pushing for a decision now to see how to go on with this [08:07] (but I think the desktop team and even more so the GNOME Ubuntu flavor teams may want this more than I do) [08:36] pitti, can you reject texlive-base_2012.20120611-5~12.04_source.changes please - it was meant to go my ppa... O:-) [08:40] dholbach: *zap* [08:40] *splatter* [08:42] thanks pitti === racedo` is now known as racedo [08:44] is the consolekit/logind migration complete now? [08:47] tjaalton: no, still waiting on above FFE [08:56] pitti: ok, just wondering if jbicha is/was using some ppa with it that might cause bug 1156074 [08:56] bug 1156074 in xserver-xorg-video-intel (Ubuntu) "[raring] after updates, i965 driver won't load" [Undecided,New] https://launchpad.net/bugs/1156074 [08:57] could be, following up [08:57] I added a question, refresh if it wasn't there yet :) [08:58] ah, I added a similar one [08:58] but it's not a PPA any more actually, you can just use the universe package [09:13] cjwatson: FYI, I committed your aptdaemon updates to bzr, thanks for those! I also added the missing pep8 test dep in bzr now, and looking at the other failed test [09:17] * pitti fixes the three PEP-8 violations upstream [09:26] tvoss: hi! Are you subscribed to the ubuntu-phone ML? I'd like to start a topic there about how implementing the keyring on the phone/tablet, and I think that your participation would be very important :-) [09:26] mardy, I'm subscribed, yes. [09:27] mardy, I think lool should be involved with the discussion, too. Perhaps explicitly list him as recipient? [09:27] lool, are you subscribed to ubuntu-phone? [09:28] tvoss: yes [09:29] lool, thx [09:29] I need help with the ubuntu-sdk [09:30] When I run the tutorial I get errors regarding like file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Toolbar.qml:112: TypeError: Cannot read property 'visible' of null [09:30] and other similar ones [09:30] LyzardKing, you might want to ask in #ubuntu-phone or #ubuntu-app-devel [09:30] ok [09:53] pitti: thanks [09:54] pitti: I think I looked at bzr and it was just an auto-import; I must have been looking at the wrong branch [09:54] debcheckout / Vcs-Bzr: are right [09:54] anyway, I can reproduce the "debian-security/nonfree" failure in a VM [09:54] it works on my normal workstation [09:54] debcheckout? awesome [09:55] oh, wow, multiarch on my 12.04 desktop fails miserably if i add armhf [09:56] (apt-get update chokes on security.ubuntu.com) === tkamppeter__ is now known as tkamppeter [10:05] pitti, cjwatson: woot, should Mark's proposal be on the techboard agenda for today? [10:05] lool: yes, I think it should [10:05] pitti, cjwatson: https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html that is [10:07] Yeah [10:07] pitti: ah, my bad for trusting my old checkout :) [10:09] added, thanks === Claudinux__ is now known as Claudinux [10:26] bdrung: FYI, uploading libsoxr to fix autopkgtest failure === ckpringle_ is now known as ckpringle [10:46] pitti: thanks. i will forward your patch upstream. [10:47] bdrung: danke! [10:47] bitte :) [10:51] pitti: I was moving some tests for an app over to using your dbusmock library, and found it was leaving dbusmockobject processes hanging around. [10:52] pitti: the docstrings imply that these processes should automatically exit when the bus they connect to goes away, so is this a bug? [10:52] jamesh: yes, that's a bug [10:54] pitti: okay. I added explicit terminate()/wait() calls as the dbusmock examples do. So I was wondering if it was a code bug or a docs bug [10:55] jamesh: they should listen to their attached bus going down and terminate themselves [10:55] jamesh: yeah, the examples do that manually indeed, but automatic termination sounds nicer [11:01] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: henrix [11:07] pitti: I filed https://bugs.launchpad.net/python-dbusmock/+bug/1156561 so it won't be forgotten [11:07] Launchpad bug 1156561 in python-dbusmock "DBusTestCase.spawn_server() says spawned daemon will exit when bus closes, but process is left behind" [Undecided,New] [11:07] jamesh: thanks [11:19] hello [11:21] cjwatson I just read what you told me last night about the dangling symlinks. I will try to give an example, and I was not from outside chroot but once inside then in the live in virtualbox, and after that in the installed os in virtualbox. [11:36] sl-modem-dkms has failed to build for quite a while, as exposed by the ubuntu-drivers-common autopkgtest [11:36] do we still actually care about this one? [11:40] pitti: I have an intel graphics card and updated earlier this morning, I have 175-0ubuntu24 and I get LP #1156074 [11:40] Launchpad bug 1156074 in xserver-xorg-video-intel (Ubuntu) "[raring] after updates, i965 driver won't load" [Undecided,Incomplete] https://launchpad.net/bugs/1156074 [11:40] lool: are you running standard raring with consolekit or logind? [11:41] pitti: actually, not sure it's the exact same bug [11:41] pitti: I've rebooted and I'm now getting relatively low res graphics [11:41] lool: do you have an acl on /dev/dri/card0 ? [11:41] but glxinfo works [11:41] yes [11:41] ok, so not the same bug [11:41] and I have facl permission on it [11:41] well, at least the one above said it was due to having no ACL [11:42] I have consolekit but not logind [11:42] pitti: i'd say we do care about sl-modem-dkms, but it often lags behind linux kernel & debian patches it only up to debian's kernel, which is usually less than ours.... [11:42] xnox: there's even a bug for it, but I wonder if I should keep ubuntu-driver-common's tests fail eternally for this [11:42] I guess that autopkgtest should move to sl-modem rather [11:43] pitti: dkms FTBFS tests should be all in each dkms module package. I guess ship a test script in the dkms module, and add/symlink it in each -dkms package? [11:43] apparently, xrandr believes I have a screen connected when I dont [11:44] pitti: ... or with some jenkins magic auto-add them the way autopkgtests are added? [11:44] xnox: that'd be possible, yes; I also have some test in u-d-common to detect that sl-modem is necessary, but that one could drop the actual installation [11:46] pitti: /me ponders about dh_installdep8 which would detect and add typical tests (e.g. initctl checkconf for all upstart jobs, dkms module FTBFS, abi-compliance-checker) [11:48] tseliot: so we have a nvidia-experimental-304 AND nvidia-304? same with -310? [11:48] pitti: do you mean in raring? [11:49] tseliot: as nvidia-current isn't what it used to be any more, I'm adjusting u-d-common's autopkgtests and wonder which versions we shoudl cover [11:49] tseliot: yes [11:50] pitti: I don't remember if I'm doing this already but ideally nvidia-experimental-304 should be a transitional package of 304 (or maybe 304-updates), same as with 310 and its experimental flavour [11:50] apparently not [11:51] also, we have a nvidia-313-updates, but no nvidia-313, is that intended? [11:51] * pitti adds -310 to autopkgtest [11:52] pitti: ok, I'll deal with the transitional packages this week. Furthermore, 313 is not an LTS series, so it won't get a non updates flavour [11:53] ok, so I'll just add a test for 313-updates [11:53] right === mitya57_ is now known as mitya57 === MacSlow is now known as MacSlow|lunch [12:16] cjwatson in the installed version, in Virtualbox, here are the results for "find -L /usr -l", the for /etc then for /var: [12:16] http://pastebin.com/0cjYFLv2 [12:16] http://pastebin.com/Bim1Mk3m [12:16] http://pastebin.com/D4kBPDMQ [12:17] I will start the live version in vbox just now and do the same to compare [12:17] for MRE's and backports of those MRE's to the lts-stack, do I need to run piglit for both on all hardware, or is a smoke test for the lts-stack enough? [12:29] melodie: ah, OK; well I suppose you could clean up the help symlinks, but that will just mean that if people install the langpacks later then they won't get localised help whereas otherwise they might have done [12:29] i.e. it's intentionally breaking stuff for the sake of a few inodes, which is rarely worth it [12:29] Some of the /usr/share/doc/ ones are probably bugs [12:30] No idea where /usr/lib/pkgconfig/python2.pc comes from, I don't have that here - but probably a bug [12:30] cjwatson this is what I thought (languages sake) when I saw what the major number of lines were : not worth trying to remove them [12:30] perhaps ? [12:30] Indeed, I don't think this is worth even the amount of time spent discussing it so far :) [12:31] It will have only a negligible effect on the system [12:31] cjwatson yes, but I could not know before trying to discover why it was there [12:31] thank you very much [12:31] It might be worth tracking down why some of the other symlinks (i.e. not the obvious localised ones) are dangling [12:32] libnss_db.so is odd too [12:32] it might be there after I removed some packages to priviledge others [12:33] I look in my install to see if I find a clue [12:34] in my install it is also a dangling link and it points to /lib/i386-linux-gnu/libnss_db.so.2 [12:34] some of the automatic package mangling-foo was spotted to generate broken symlinks in /usr/share/doc in the past. Also it seems like a few things are "waiting" on language packs, if all of them were installed most of gnome-docs would be fine. [12:35] python2.pc looks like a bug it should be python.pc only. [12:38] hi xnox, is this likely to lead to improvements ? [12:38] melodie: no. [12:39] not important enough ? :) [12:39] ok, I go work on something else thank you [12:39] melodie: installing all language packs, will just use up a lot of disk-space. These documentation dangling symlinks is actually an optimisation, we bundle all translations in language-packs, such that one doesn't carry ~ 4GB of translations to languages one does not speak. [12:40] (~4GB of translations can be stripped from default Mac OS X installation last time I did it) [12:40] xnox I was asking about the two dangling links which should not be there and which you consider as probable bugs [12:41] I know all language packs can't be inside a 700 MB max iso [12:41] melodie: the only "win" will be a couple of bytes saved from the entries in the file system. I'd think one would win more by removing a single /usr/share/doc/$package/changelog.Debian.gz [12:42] (which was proposed to do by default in the past) [12:43] and it seems these broken links don't even take any space [12:44] melodie: yeah broken links are almost zero cost in terms of disk space. [12:47] in my system, python2.pc points to -> python-2.7.pc [12:47] which does not exist [12:47] it is is Precise === _salem is now known as salem_ [13:10] melodie: yeap, cause it's multiarched. [13:12] see /usr/lib/x86_64-linux-gnu/pkgconfig/ === DrKranz is now known as DktrKranz [13:13] xnox ok, then I suppose it is normal [13:13] I don't have a 64bits system here === MacSlow|lunch is now known as MacSlow === wedgwood_away is now known as wedgwood === dpb__ is now known as dpb_ === ckpringle_ is now known as ckpringle === _ is now known as Guest94915 === andreas__ is now known as ahasenack [14:59] xnox: re debian bug #703323, can you update the man page? [14:59] Debian bug 703323 in devscripts "devscripts: [wrap-and-sort] add trailing comma" [Wishlist,Open] http://bugs.debian.org/703323 [15:02] bdrung: *sigh*, yes. [15:02] xnox: i am merging the ubuntu change back to debian, but the tests fail in experimental. [15:03] there, 9 autopkgtest failures less than than this morning [15:03] bdrung: i had no test-failure here. Is it related to ubuntu's switch to python3, which is not possible in debian yet? [15:03] (here as in ubuntu) [15:04] xnox: yes. the python3 switch is possible in debian too. i poked the file maintainer to add python3 support and he did it. [15:05] xnox: http://paste.debian.net/242557/ [15:05] bdrung: interestingw, will look into it later. [15:15] xnox, tumbleweed: the test suite is broken: http://paste.debian.net/242561/ [15:15] the test fails even if the timeout is set to 10 mins. [15:16] bdrung: what if you revert my adding a new option? or is that even with /bare/ devscripts without my patch? [15:17] xnox: i haven't applied your patch. so it's not the fault of your patch. you can try building devscripts 2.13.0ubuntu1 on experimental with the same result. [15:18] bdrung: fun. === rickspencer3_ is now known as rickspencer3 [15:46] tumbleweed: do you object to add a copy of devscripts.logger to ubuntu-dev-tools? [15:55] bdrung: i'm for it. that means dropping python2 module from devscripts on ubuntu side and syncing ubuntu-dev-tools from debian once again =) [15:56] i mean the devscripts.logger delta will go away, and we can switch to python3 on debian side as well that s. [16:07] all right so to get openbios-sparc, i guess i'd need to look at gcc-ppc-linux-gnu and get the analogous for sparc [16:09] janimo, sad, you arent in #ubuntu-release ... you just missed the dead of cdimage-private :) [16:11] ogra_, I got a mail from LP with the WIs set to DONE so did not miss it :) [16:11] oh, there were still WIs ? [16:11] haha [16:12] ogra_, yes, there was an old blueprint [16:12] yeah, i was looking for it but couldnt find it [16:13] ogra_, https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-image-build-tools [16:13] ah, there it is [16:13] i guess i wasnt subscribed [16:13] i searched in my mail [16:14] I happened to run across it the other day and thought I might as well claim them [16:23] xnox: okay. i will do that after the build failure ( http://paste.debian.net/242557/ ) is fixed. [16:38] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [16:57] bdmurray: around? [16:57] update-manager -d tells me: The requested URL /ubuntu/dists/raring/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html was not found on this server. [16:58] bdmurray: is that expected? [16:59] stgraber: could you upload a newer lintian version as suggested at https://lists.ubuntu.com/archives/ubuntu-release/2012-December/002140.html ? I noticed that my computer still had the old one installed [17:03] jbicha: I think the hope was that we would be able to sync from Debian and get something slightly higher than what we have in extra. I'd have to check what they have in Debian nowadays. Will try to do that once I'm done with my meetings [17:03] lamont: that's from a quantal system? [17:03] current quantal running update-manger -d [17:03] quantal + security + udpates only [17:03] lamont: okay thanks [17:04] bdmurray: does it deserve a bug? [17:04] smoser: it seems some work has already been done to accelerate d-i... it no longer uses debootstrap, but copies a pre debootstraped squashfs for the base install... scaling this up a bit may get you to where you want for fastpath install... adding eatmydata for the subsequent part of the install took my total install time for 7m to 3m, how fast did you have in mind? [17:04] lamont: no, I'll just try and fix it [17:05] 0.192.4 had the file, 0.192.5 dropped the .html versions [17:05] lamont: the file is really missing http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/ [17:05] * lamont finally notices that there is still an 'upgrade' button at the bottom of things [17:06] bdmurray: it is in fact [17:06] * lamont actually went and verified it on the master [17:07] psusi, well,it is much faster, yes. and that avoids many dpkg -i. [17:08] however, it still makes sense to use eatmydata for *all* dpkg during an install (squashfs just gets the "base image"), and then any additional packages are installed with dpkg. [17:09] smoser: right.. I tested that and it dropped install time from 7m to 3m [17:09] slangasek: why unionfs? =) we got overlayfs in nexus7 landing soon and heading upstream as well. [17:09] scaling up the squashfs to contain more of a typical virtual install instead of just required/important packages might be a way to improve on it too [17:10] it's the minimum subset of all the possible things that that image can install [17:10] or was last I checked [17:10] cjwatson: right... it's just required/important packages, i.e. what debootstrap used to install [17:11] I know what it is - my point is that it can't be expanded without suddenly having to teach other bits of d-i about how to *remove* packages [17:11] but you could add in more packages if you wanted to.. so maybe identify the set of packages that all cloud installs will want and throw them in too [17:11] I started out with it larger and had to scale it back [17:11] ohh, right.. adding packages means they basically aren't optional to install any more [17:11] it could be expanded to standard if the server team decided to drop the minimal-virtual-machine install type [17:12] (I think I discussed this with the server team at the time) [17:12] or if you choose to do that, then fall back to debootstrap instead? [17:12] can't, files aren't present [17:13] ohh, wait.. the required and important packages have already been removed from the pool? [17:13] from the CD image pool [17:13] ahh... nice... [17:13] also the bootstrap-base udeb isn't present [17:14] wait.. what about a dual squashfs? one with the base, and a second one with -standard? then you just unpack the second one after the first, or not.. [17:15] if somebody can figure out how the heck to make it all work *shrug* - I think dropping the minimal vm install type is a much more rational use of time personally [17:15] I agree [17:16] cjwatson: psusi: well there are server images with squashfs containing everything pre-installed what is needed to become an openstack node and it's in use in the jenkins lab for automatic bare-metal deployment of openstack clouds. [17:17] see qa talk from fosdem by james page. [17:17] there is ongoing work to open up this method and make it more generic and less speciliased on openstack-only. [17:17] it's the fastpath installer work. [17:19] xnox, well, i'm not sure what jamepage said at fosdem. [17:19] smoser: =))))) [17:20] but the fast path installer largely overlaps with much of what d-i does. [17:20] and doesn't use squashfs images. [17:20] smoser: it was so fluid and so well rehersed everyone believed anything he was saying ;-) [17:21] xnox: it sounded to me like the current proposal for fastpath is to reinvent a whole new installer, rather than modify d-i... I'm just pointing out that maybe modifying d-i would be better and doable ( and some work has already been done ) [17:24] xnox: I'm using unionfs as a generic term here [17:24] xnox, slangasek, dont forget that we have to deal with (possibly old) android kernels when aiming for union/overlayfs [17:25] hi. i have problem in 13.04. after awaking from sleep notebook gets slow. mouse pointer move like with delay. [17:25] it's ok to ask here? [17:25] nexus7 should be safe though, we use the same in the desktop and touch images [17:26] slangasek: ack. [17:26] but in general i think it will make porting for people problematic if we require huge kernel changes [17:28] slangasek: ack. [17:28] bosyi: no. #ubuntu+1 is a better channel. [17:29] xnox: thanks === mhall119 is now known as mhall119|lunch [17:44] xnox, cjwatson: hey, is there any known issue with the installer and username pre-seeding? [17:45] The only thing I've heard of that's related is bug 1155704, but I suspect that's a wider problem [17:45] bug 1155704 in Wubi "13.04 installer doesn't create user account" [High,Confirmed] https://launchpad.net/bugs/1155704 [17:45] cjwatson, http://ubuntuone.com/6g6zED1AQpXiDFmAL6qJ0H [17:45] seb128: not that I know of, but u1 plugin started to fail for me with today's images. [17:45] xnox, ^ [17:45] the username in the error is "root" [17:45] where the entry has "jenkins" [17:45] I certainly haven't changed anything near there in ages ... [17:45] k [17:46] Would need to see logs I guess, ideally debug logs [17:46] could be a #qa issue [17:47] cjwatson, thanks, I'm asking the #qa guys to come here to discuss it directly [17:47] mmrazik is the one who got the screenshot [17:48] but he doesn't have access to the logs apparently [17:48] mmrazik, hey ;-) [17:48] cjwatson: let me fwd the screenshot [17:48] screenshots aren't logs :) [17:48] mmrazik, I shared the screenshot [17:48] seb128 already posted the screenshot [17:48] great [17:49] 17:46 Would need to see logs I guess, ideally debug logs [17:49] cjwatson: what are logs? /var/log/syslog? [17:49] cjwatson: its going to be a bit difficult, though [17:49] as the machine has no networking AFAICS and is in Lex === deryck is now known as deryck[lunch] [17:50] /var/log/installer/syslog [17:51] well, /var/log/syslog at this stage actually === rsalveti_ is now known as rsalveti === Ursinha_ is now known as Ursinha [17:51] and /var/log/installer/debug [17:51] nuclearbob: do you have access to any of those ^ ? [17:51] feel free to come up with a way to reproduce the problem that doesn't involve jenkins in a remote lab ... [17:51] mmrazik: I can look at them over a kvm-over-ip and get screenshots, I'm trying to find a better way to get them on the machine [17:51] yeah [17:52] I can try the same preseed on a bm [17:52] *vm [17:53] hallyn: edk2 persistence issues> so step one is to figure out how to do a proper debugging build of ovmf, since I'm failing at that so far ;) any ideas? [17:54] xnox: I'm still testing, but any opinions on http://paste.ubuntu.com/5625860/ and http://paste.ubuntu.com/5625861/ ? It seems to have improved things for the ruby1.8 build, at least [17:54] (As in it actually detects Tcl/Tk now) [17:55] nuclearbob, cjwatson: I'll have the logs in a minute [17:56] slangasek: no. but i need to learn about the upstream source and package, so i'll look into that. [17:56] whoopsie dialog of the day: "Sorry, the application crash.jar has stopped unexpectedly" [17:56] Ya think [17:57] :X [17:57] it didn't crash in the way it should, perhaps? [17:57] I think it's part of the apport testsuite [17:57] poor whoopsie, always taking a bad rap for apport [17:57] Yeah, my bad, had the wrong package that pops up annoying dialogs :) [17:58] cjwatson: everyone conflates the two :) [17:58] cjwatson: /var/log/syslog: http://pastebin.ubuntu.com/5625877/ [17:58] bdrung: no [17:59] cjwatson: /var/log/installer/debug: http://pastebin.ubuntu.com/5625879/ [17:59] mmrazik: is it possible to start the machine with the 'debug-ubiquity' boot parameter? things are a lot more informative that way [18:00] nuclearbob: I actually don't know how to do that easily with utah, etc ^^^ [18:02] mmrazik: adding -b debug-ubiquity to the utah command line should do it, I can try that as well [18:02] nuclearbob: thanks [18:02] I need to leave soon [18:03] recreating this on a VM doesn't seem to be working either, unfortunately and to nobody's surprise === mhall119|lunch is now known as mhall119 [18:21] cjwatson: looks correct. as long as nothing drops out of main, like with my first defaults upload ;-) [18:21] As in tcl-lib? I think I avoided that trap [18:21] xnox: If at first you don't succeed? [18:22] cjwatson: yeah. I think you did it all correctly. [18:24] xnox: I might wait until tomorrow morning to upload it, since I'm getting pretty tired and prefer to be fresh before hitting enter on this kind of thing. But I do seem to have managed to climb up to the point where ruby-ffi builds, which was the original point of this yak-shaving exercise. === blitzkrieg3 is now known as jmleddy [18:26] cjwatson: hi there [18:27] jmleddy: Finishing for the day as the above indicates. Is it quick? [18:28] cyphermox: hmm, what needs "solved" wrt polkit/consolekit on the tablet for NM? [18:28] slangasek: err, I don't know? [18:28] cyphermox: I ask because of the ongoing ck->logind migration discussion [18:28] ok [18:28] cjwatson: yeah, I was just wondering if you had an estimate for bug 967229 [18:28] bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229 [18:28] cyphermox: oh; sergio just assigned a work item to you for it :) [18:29] jmleddy: I thought that had been handed over to bdmurray [18:29] ok [18:29] can you link? [18:29] slangasek: particularly the part about starting plymouth before lightdm stops [18:29] It came up a foundations meeting or two ago [18:29] cjwatson: yes, I think he is working on it [18:29] I haven't heard anything about progress [18:29] bdmurray: ^- ? [18:30] jmleddy: hrm, you aren't mixing up me and cjwatson, are you? :) [18:30] slangasek: oh, perhaps o_O [18:30] sweet [18:30] * slangasek dyes his hair [18:30] slangasek: I though he jumped in [18:30] He's the talented one, I'm just ruggedly handsome [18:30] slangasek's last idea did not improve the situation [18:30] haha, [18:31] bdmurray: improved vs. what? [18:31] * cjwatson goes to try to scavenge dinner, in a hunter-gatherer kind of way [18:31] I still see messages when shutting down [18:31] jmleddy indicated that clearing the VT before lightdm starts takes care of some of it [18:32] bdmurray: slangasek: basically a manager asked me for a date when we would have a complete fix (ie, plymouth starts before lightdm stops) [18:32] and clearing the VT /after/ lightdm starts will take care of more of it [18:32] huh, I had success with turning the text color black and clearing the vt [18:32] bdmurray: so from my POV, this is a per-se correct change to the lightdm job [18:33] well, turning the text color black is a workaround [18:33] agreed [18:33] but yeah even just doing a clear > /dev/tty7 fixed it for the startup text [18:33] still saw services shutting down though [18:33] right, and that is what I still see [18:34] bdmurray: so we do need to clear at boot, even though that doesn't solve the full problem for shutdown; can you drive that piece forward on lightdm? [18:34] bdmurray: okay, that makes more sense [18:34] for shutdown, I think we need to change things so that the plymouth /daemon/ starts before lightdm stops, so that we get the console indirection in place, but that we only start the plymouth /splash/ after lightdm exits [18:35] slangasek: right clearing on boot solves logout and log back in issues [18:35] * slangasek nods [18:35] slangasek: how hard is that to change? [18:35] jmleddy: it's easy to change, hard to get right [18:35] the ordering of all of this is fiddly and the architecture is not fully documented [18:36] okay [18:36] but basically, the plymouth upstart jobs need to be split differently [18:36] I think as long as we're actively working on it I can hold off the OEMs [18:36] I believe the ordering is the last thing we'd talked about and the change had no effect [18:36] bdmurray: which change? [18:37] but ideally they'd like to have a target for when this will be fixed [18:38] I suppose there's a reason why the old "start the splash from the DM on shutdown" method that we used eons ago doesn't work? [18:38] * infinity has always been a bit annoyed that this used to be a solved problem until it was all torn out. [18:38] infinity: you still have to stop the X server first [18:39] Is that actually true in a KMS world? The kernel is perfectly happy with writing my oopses to the same FB as my X session. [18:39] s/oopses/panics/ [18:40] infinity: the X server has to be stopped before you can start the plymouth splash. [18:40] because only one process can own the VT at a time [18:40] and it's important that the VT have an owner [18:40] Well, yes, I get what you're saying. I'm arguing that if that's true, it may be a design/implementation issue with plymouth, not actual architectural fact. [18:40] slangasek: http://pastebin.ubuntu.com/5626006/ [18:41] Anyhow, that same limitation should have been true with gdm and usplash too. How did my old splash-down crap handle it? [18:41] Oh, I didn't use the same VT as X, I bet. [18:41] So, I did a chvt, then splashed away. [18:41] now, this doesn't mean that X has to switch it into text mode when it exits, but in most cases it *is* important that X switch back to text mode, so implementing this correctly means changes to the X server and lightdm [18:42] infinity: to me, that's the ideal solution, put the kernel console to a different vt [18:42] switching to a different VT still implies a race [18:42] jmleddy: This is what we used to do. There's exactly one valid and cool argument not to, which is panics. [18:43] it doesn't matter which VT you're on if that VT is in text mode (however briefly in theory) and things are writing to it [18:43] infinity: yeah, that's what I was worried you would say ;) [18:43] the point is that we should *not* have services writing to the desktop's console on startup/shutdown except in the case of errors (panics) [18:43] slangasek: You bind your splash to a VT, then chvt to it. In that order. [18:43] slangasek: But yes, we shouldn't have output in the first place, I agree. [18:44] bdmurray: so given that didn't help, can you post a screenshot to the bug of what output you were still seeing? [18:45] slangasek: sure [18:58] slangasek: added === deryck[lunch] is now known as deryck [19:17] bdmurray: thanks; that's more or less consistent with the remaining race condition I expected (although I don't know why acpid is talking to the console since it's an upstart job that doesn't have 'console' set), I think the next step is to think about changing /etc/init/rc.conf to no longer be 'console output' [19:17] bdmurray: but I think we need to coordinate this with the server team to make sure we don't disrupt that case [19:18] smoser: what's the right answer for where init script and upstart job start/stop messages should be going on the server images (and cloud in particular)? [19:20] slangasek, i dont know what the right answer is. cloud-init jobs writes with 'console output'. [19:20] but even that is proxied through plymouth. [19:21] smoser: I'm not asking about the mechanism, I'm asking about where you want it to show up [19:21] /dev/console is right. [19:21] ok [19:21] the fact that that is busted in some cases is something that has to be fixed. [19:21] yep [19:22] slangasek, do you have thoughts on a more appropriate place? [19:22] (other htan /dev/console) [19:22] no, my opinion doesn't matter : [19:22] :) [19:22] this is for the server team to decide where they want these messages to go === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [20:05] cjwatson, pitti: Sorry, where/when is the techboard meeting? [20:05] fridge suggests it's either now or was an hour ago on #ubuntu-meeting, but nothing there [20:06] lool: in an hour in #ubuntu-meeting [20:06] my calendar says now [20:06] lool: the meeting time is 21:00 London time [20:06] fridge too [20:06]