| === freeflying_away is now known as freeflying | ||
| smoser | bdrung, i think its generally more functional to give me straightforward access to all data. | 01:07 |
|---|---|---|
| bdrung | smoser: i would prefer to keep a simple, supportable API. | 01:08 |
| smoser | how is returning a dict of data not supportable? | 01:08 |
| smoser | many times i've wanted data in the form that my function gets it. | 01:10 |
| smoser | its very common to want a release adjective, its version, and whether or not its an lts. | 01:11 |
| smoser | oh, i see. you're thinking about api other than python. | 01:29 |
| smoser | :-(. | 01:29 |
| bdrung | smoser: in case we want to change the file format, the content of the dict could change. the question is: which attributes would we guarantee to be present? | 01:39 |
| smoser | which of the ones i have there would you imply would not be present? | 01:41 |
| smoser | i didn't expose anything not already exposed | 01:41 |
| smoser | other than more conveniently | 01:41 |
| bdrung | we export codename, fullname, and release | 01:42 |
| bdrung | and codename | 01:43 |
| bdrung | how about accepting "all" as result to return a dict with these values? | 01:43 |
| bdrung | smoser: and you probably want a function that can map a codename to this kind of dict | 01:44 |
| bdrung | i'll go to bed now. good night. | 01:44 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| pitti | Good morning | 06:21 |
| RAOF | Morning pittmasterflash! | 06:22 |
| pitti | RAOF: Qapla', member of the Klingon home world! | 06:25 |
| pitti | RAOF: oh, and you misspelt Qo'noS as "Khronos", BTW :) | 06:26 |
| RAOF | :P | 06:26 |
| === tvoss_ is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| pitti | cjwatson, jibel: hmm, why did britney trigger the python-imaging test? the binaries are still in NEW, so there's no point in running them | 07:00 |
| jibel | pitti, I did manually | 07:05 |
| pitti | jibel: ah, ok; thanks | 07:05 |
| jibel | I was verifying publication to the public instance, which is broken for new jobs | 07:06 |
| pitti | rbasak: sorry, I forgot: what's the reason why adt-virt-lxc has an --ephemeral switch which isn't the default? (as AFAICS you really always want this) | 07:13 |
| === tkamppeter_ is now known as tkamppeter | ||
| === sabdfl_ is now known as sabdfl | ||
| === iahmad is now known as iahmad|afk | ||
| === iahmad|afk is now known as iahmad | ||
| pitti | rbasak: I'm changing some CLI in 2.5 anyway, so now would be a good time to drop --ephemeral and replace it with --clone? | 08:55 |
| Laney | seb128: great! | 09:00 |
| seb128 | Laney, what was that about? ;-) | 09:02 |
| Laney | eds calendar reply | 09:03 |
| seb128 | Laney, oh, right ;-) | 09:12 |
| mlankhorst | slangasek: I was viewing the HWE session, I like how the kernel people only think about the kernel in their suggestions and forget the whole reason is userspace, repeatedly. ;) | 09:22 |
| mlankhorst | anyway auto upgrading X.org is HARD | 09:22 |
| mlankhorst | kernel can simply depend on a newer package, userspace on the other hand | 09:22 |
| mlankhorst | it has to do a scary path where all the old packages need to be removed and the new packages need to be installed. | 09:25 |
| pitti | eek, lxc regression | 09:33 |
| pitti | stgraber: FYI, filed bug 1253573; downgrading lxc unbreaks it | 09:41 |
| ubottu | bug 1253573 in lxc (Ubuntu) "[trusty regression] lxc-clone: failed to write /etc/hostname" [Undecided,New] https://launchpad.net/bugs/1253573 | 09:41 |
| tseliot | pitti: do you know if a versioned breaks/replaces would work with a virtual package? | 09:48 |
| pitti | tseliot: no, virtual packages don't have versions | 09:48 |
| pitti | and thus Breaks: don't make sense for them | 09:49 |
| pitti | usually you C:/R:/P: virtual-pkg | 09:49 |
| pitti | or depend on them; there's not much else that you can do with them | 09:49 |
| tseliot | pitti: I suspected that, thanks | 09:49 |
| tseliot | pitti: I need to provide an icon within nvidia-settings, the same icon which the nvidia-driver currently install (well, they actually ship a link to the icon) | 09:50 |
| tseliot | and I'm trying to avoid to conflict/break all the nvidia packages in nvidia-settings | 09:51 |
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| pitti | tseliot: and you can't just put that into a different icon path? | 10:14 |
| tseliot | pitti: true, that would make things so much easier. Thanks | 10:16 |
| cjwatson | xnox: :native> mail me a repro recipe maybe? :native on those targets should work ... | 10:50 |
| xnox | cjwatson: ok. | 10:53 |
| mlankhorst | can we have multiple versions of the same package in the same pocket? | 10:54 |
| cjwatson | mlankhorst: Not really | 10:58 |
| cjwatson | Occasionally you get multiple versions of a source for short periods, but it's only ephemeral | 10:58 |
| cjwatson | You certainly can't assume that anything like that will stick around for any length of time. Pick a different design | 10:58 |
| mlankhorst | I see no sane way of upgrading between lts stacks then :/ | 11:00 |
| mlankhorst | unless we stuff it in backports | 11:01 |
| mlankhorst | but that's not enabled by default either | 11:01 |
| ogra_ | cjwatson, hmm, that germinate output seems to not take into account that recommends are off in ubuntu-touch | 11:39 |
| ogra_ | (unless i'm reading the "Why" column wrong) | 11:39 |
| ogra_ | (looking at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.trusty/touch) | 11:40 |
| === _salem is now known as salem_ | ||
| speakman | Hi folks! Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses) | 11:44 |
| cjwatson | ogra_: I've fixed your seed STRUCTURE file to declare that properly. | 11:44 |
| ogra_ | hmm, i thought you had done that ages ago ? | 11:44 |
| cjwatson | No. | 11:44 |
| === freeflying is now known as freeflying_away | ||
| ogra_ | no, actually i'm sure you have | 11:44 |
| ogra_ | in raring | 11:44 |
| cjwatson | Not in the seeds, only in livecd-rootfs. | 11:45 |
| ogra_ | oh | 11:45 |
| === MacSlow is now known as MacSlow|lunch | ||
| mlankhorst | cjwatson: well the recommended way to rename packages is to provide a transition package. I really see no way to force an upgrade without one though. :/ | 12:01 |
| mlankhorst | and a manual upgrade wouldn't need a new package, they could just install xserver-xorg-lts-saucy manually when it becomes available | 12:02 |
| === freeflying_away is now known as freeflying | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === dholbach_ is now known as dholbach | ||
| rbasak | pitti: --ephemeral breaks tar extraction in certain I/O load conditions due to overlayfs. | 13:56 |
| rbasak | pitti: example: reproduce with the php dep8 test. | 13:56 |
| rbasak | pitti: it reliably reproduces for me on an openstack instance. | 13:57 |
| pitti | rbasak: ah, too bad | 13:59 |
| === dbarth__ is now known as dbarth | ||
| pitti | rbasak: so you'd recommend to keep "clone" as the default for the time being? | 14:11 |
| rbasak | pitti: right | 14:12 |
| pitti | rbasak: that's unpacking the orig.tar? | 14:15 |
| pitti | rbasak: I am just running them through adt-virt-lxc --ephemeral adt and it's way past that | 14:16 |
| pitti | hm, but that's on trusty | 14:16 |
| pitti | rbasak: finished, worked fine; did you see these problems on your local system too, or is that an issue with lxc in kvm on hardware (as we have in cloud instances presumably) | 14:18 |
| rbasak | pitti: it's when adt-run copies things in and out of the container. | 14:18 |
| rbasak | pitti: my failure happens right near the end of the php5 test. I can try and reproduce and give you access to the instance if you want to follow it up? | 14:19 |
| pitti | rbasak: not interested/capable of debugging overlayfs kernel bugs; but would be interesting to determine in which environments they happen indeed | 14:20 |
| infinity | mlankhorst: Why do you want multiple versions of something in a pocket? | 14:33 |
| mlankhorst | upload a 0~~ version that's only selected by pinning the version :P | 14:34 |
| mlankhorst | as a transition package | 14:34 |
| speakman | Once again; Any ideas how to programmatically set the "master" volume in Ubuntu? I can't find any way using DBus. Are there other ways? (And no, not simulate media key presses) | 14:34 |
| mlankhorst | I played around a bit, apart from forcefully doing apt-get install xserver-xorg-lts-saucy I don't see how you can upgrade automatically | 14:35 |
| infinity | mlankhorst: But if installing xserver-xorg-lts-saucy works, then upgrading works. I'm a bit confused here. :P | 14:35 |
| mlankhorst | infinity: yeah but it doesn't allow opt-in automatic opt-in upgrading on EOL | 14:36 |
| infinity | mlankhorst: The thing we were discussing in the session is that there should just a -latest type package that matches the icky-named eol-upgrade package in the kernel. | 14:36 |
| mlankhorst | oh is that all? | 14:37 |
| infinity | mlankhorst: So, said -latest package would be updated to point to -lts-trusty when it's available, and job's done. | 14:37 |
| infinity | mlankhorst: Not sure why that's impossible or even hard. :P | 14:37 |
| mlankhorst | infinity: but if you upgrade to lts-saucy and then the latest version is lts-trusty, strange things happens | 14:37 |
| infinity | ... | 14:37 |
| infinity | mlankhorst: wat? | 14:37 |
| mlankhorst | I mean if the package pointed to lts-saucy before, and now points to lts-trusty | 14:38 |
| infinity | mlankhorst: That's a non-problem. If you have lts-saucy installed and you install lts-trusty, the upgrade works. Why would a package yanking you around not work the same? | 14:38 |
| mlankhorst | because in case of the kernel the solution is to only install a new package, and keep the old | 14:39 |
| infinity | Sure, okay, it'll not work in update-manager without serious quirking, because it tries to remove a ton of packages. | 14:39 |
| infinity | It'll work fine in apt. | 14:39 |
| mlankhorst | in case of userspace, it has to remove the packages from some 40 source packages, then install from another 40-ish new ones | 14:39 |
| infinity | There's nothing stopping us fixing that in update-manager, though. | 14:40 |
| infinity | Since we know the name pattern of packages that are going to be swapped. | 14:40 |
| mlankhorst | infinity: it only works if you manually resolve it with apt-get install, dist-upgrade won't I think | 14:40 |
| infinity | Don't see why dist-upgrade wouldn't work. | 14:40 |
| infinity | Except that no one's ever tried it because we don't have that -latest meta. | 14:40 |
| mlankhorst | except that I was just testing that now | 14:41 |
| mlankhorst | hm *tries without breaks/replaces/conflicts in meta package* | 14:41 |
| stgraber | pitti: thanks | 14:41 |
| infinity | What would it have been breaking/replacing/conflicting? | 14:41 |
| stgraber | smoser, hallyn_: bug 1253573 | 14:41 |
| ubottu | bug 1253573 in lxc (Ubuntu) "[trusty regression] lxc-clone: failed to write /etc/hostname" [Undecided,New] https://launchpad.net/bugs/1253573 | 14:41 |
| mlankhorst | infinity: was trying it to nudge apt-get in the right direction | 14:42 |
| hallyn_ | stgraber: groan | 14:45 |
| mlankhorst | infinity: anyway to test.. install the lts-raring stack from the main archive, and upgrade-to-lts-saucy 0.0 deb from https://mblankhorst.nl/etc/ -- after that enable ppa:canonical-x/x-staging and try to upgrade upgrade-to-lts-saucy | 14:45 |
| mlankhorst | I tried a few variations but none get the correct answer | 14:45 |
| stgraber | hallyn_: I checked and the hook didn't change with the latest upload, so it must be something else... | 14:45 |
| smoser | stgraber, you have any idea what would have done that ? | 14:45 |
| smoser | did the interface to clone hooks change? | 14:46 |
| smoser | the only way i can see that failing that way is if /etc didn't exist in the target (quite odd) or $root_d was set wrong which gets set with the value of "$LXC_ROOTFS_MOUNT" | 14:46 |
| BrotherBrick | hello, can someone help push a SRU (for Ogre on Saucy) through? I can confirm that it works for me: https://bugs.launchpad.net/ubuntu/+source/ogre-1.8/+bug/1250924 | 14:47 |
| ubottu | Ubuntu bug 1250924 in ogre-1.8 (Ubuntu) "[SRU] Ubuntu changes to Ogre install plugins in wrong directory" [Undecided,Triaged] | 14:47 |
| stgraber | smoser: nothing obvious at least... | 14:47 |
| stgraber | pitti: can you pastebin your /var/lib/lxc/<container>/config and /var/lib/lxc/<container>/fstab? | 14:49 |
| hallyn_ | pitti: and contents of /var/lib/lxc/<container>/rootfs/etc - i.e. does hostname exist there | 14:50 |
| stgraber | smoser, hallyn_: oh, one thing I just saw now is that it's a regression from saucy's LXC (alpha1) vs trusty's LXC (alpha3), so not just between alpha2 and alpha3, so quite a few more things that could have gone wrong | 14:50 |
| hallyn_ | oh nm my q | 14:50 |
| infinity | BrotherBrick: I'll sponsor that. | 14:50 |
| showard | thank you infinity | 14:51 |
| stgraber | hallyn_: anyway, reproduced here with a clean container on trusty | 14:52 |
| BrotherBrick | awesome, thanks infinity :) | 14:52 |
| BrotherBrick | and OpenMW thanks you | 14:52 |
| stgraber | hallyn_: lxc-create -t ubuntu-cloud -n p1 && lxc-clone -o p1 -n p2 | 14:52 |
| hallyn_ | stgraber: ditto | 14:53 |
| stgraber | hallyn_: well, with the missing -- -r saucy since trusty doesn't seem available yet for ubuntu-cloud | 14:53 |
| smoser | stgraber, apt-get install distro-info | 14:53 |
| stgraber | hallyn_: we probably ought to add an autopkgtest once we get that one solved, easy enough to test ;) | 14:53 |
| stgraber | smoser: ii distro-info 0.11 amd64 provides information about the dist | 14:54 |
| hallyn_ | stgraber: ok i think i know the problem | 14:55 |
| hallyn_ | it's because i stopped mounting rootfs for the dir case. had to be done for lxc-create, wasn't ready to do it for lxc-clone | 14:56 |
| hallyn_ | (for unprivileged use) | 14:56 |
| hallyn_ | well, | 14:56 |
| stgraber | ah, that'd explain it :) | 14:56 |
| hallyn_ | ah here we go, | 14:56 |
| hallyn_ | if (setenv("LXC_ROOTFS_MOUNT", conf->rootfs.mount, 1)) { | 14:56 |
| hallyn_ | that should be using bdev->dest. | 14:57 |
| hallyn_ | but i need to run to a session | 14:57 |
| stgraber | yeah, I'm sure pitti can wait a few more minutes :) | 14:57 |
| stgraber | hallyn_: send that to lxc-devel when you have a minute, I'll ack, push to master and cherry-pick in the Ubuntu package | 14:57 |
| hallyn_ | stgraber: cool, thanks | 14:58 |
| pitti | stgraber: in case you still need it: http://paste.ubuntu.com/6453636/ | 15:00 |
| pitti | $ sudo cat /var/lib/lxc/adt/rootfs/etc/hostname | 15:01 |
| pitti | adt | 15:01 |
| pitti | stgraber: ^ and that | 15:01 |
| hallyn_ | stgraber: sent | 15:06 |
| === oSoMoN_ is now known as oSoMoN | ||
| === freeflying is now known as freeflying_away | ||
| mlankhorst | infinity: anyway you should have all the pieces to reproduce that lts-stack switching doesn't work :-) | 15:17 |
| infinity | mlankhorst: Yeah, I don't have the time to play with it right now, but I believe you that it might need some work. ;) | 15:18 |
| mlankhorst | ìt really needs transition packages to do a smooth upgrade :\ | 15:18 |
| seb128 | Laney, mardy: https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-10&id=e99485221e2786bda015c14cc7f2287fd223d8aa | 15:20 |
| Laney | neat | 15:21 |
| * Laney tries | 15:21 | |
| seb128 | I can try as well, once I'm not in hangouts anymore | 15:21 |
| seb128 | I'm not sure how much the hangout would like me switching to another user session | 15:21 |
| Laney | seb128: works for me now! | 15:30 |
| seb128 | Laney, \o/ | 15:30 |
| mitya57 | Can anybody please reject https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 (See the last two comments)? | 15:32 |
| Laney | done | 15:33 |
| rbasak | pitti: I've reproduced the issue. I can give you access to the instance if you like? | 15:42 |
| mitya57 | Thanks Laney. | 15:42 |
| mitya57 | Also, https://code.launchpad.net/~albertsmuktupavels/gnome-panel/lp-1199074/+merge/196032 — please reject (duplicate of 196031) | 15:49 |
| stgraber | pitti: LXC uploaded to the archive | 16:00 |
| pitti | rbasak: sorry, between UDS sessions | 16:02 |
| pitti | stgraber: merci! | 16:02 |
| Saviq | mardy, joining the app startup session? we could use some faces in the hangout ;) | 16:08 |
| lool | cjwatson, pmcgowan, sergiusens: Can you guys make the framework followup session? | 16:10 |
| sergiusens | lool, oh, look at the time | 16:11 |
| sergiusens | joining | 16:11 |
| pmcgowan | lool, ah, was going elsewhere but will go there instead | 16:11 |
| mardy | Saviq: one minute | 16:12 |
| cjwatson | lool: remind me when that was? | 16:14 |
| lool | cjwatson: now :-) | 16:14 |
| cjwatson | lool: er, I could have sworn I looked at the calendar invite and it was next week | 16:14 |
| lool | cjwatson: I didnt send any calendar invite | 16:14 |
| cjwatson | lool: I'm sorry, I'm already one-and-a-half booked for this session :-( | 16:14 |
| cjwatson | I definitely need to be in the sru/webapp session | 16:14 |
| lool | understood | 16:15 |
| lool | maybe we should followup after vuds then | 16:15 |
| cjwatson | I thought you'd booked it for outside uds for some reason | 16:15 |
| cjwatson | can you carry on without me and I can review it later? | 16:15 |
| pitti | xnox: wrt. porting to py3, did you notice my review in https://code.launchpad.net/~xnox/system-service/python3/+merge/192805 ? | 16:29 |
| xnox | pitti: yes, i did notice, didn't have time yet to fix it up yet. | 16:30 |
| pitti | xnox: ok, thanks (no hurry, just wanted to make sure it didn't get lost) | 16:30 |
| pitti | barry: I updated python-gconf status in your doc | 16:55 |
| barry | pitti: thanks! | 16:57 |
| seb128 | pitti, can you share the url of that document? /me is curious of what is still using python (I guess that's the topic?) | 16:57 |
| seb128 | s-c-p u1 mostly I guess? | 16:57 |
| pitti | seb128: https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=0 | 16:57 |
| seb128 | danke | 16:57 |
| pitti | seb128: hplip, ubuntu1, software-center, etc.; still quite a bit | 16:58 |
| barry | i'm hoping to at least attack s-c | 16:58 |
| barry | since mvo did so much work to get it nearly there, and we have some experimental xapian support in upstream svn | 16:58 |
| seb128 | what are yellow/blue? | 16:59 |
| mitya57 | Why isn't that doc linked from the blueprint? | 16:59 |
| * mitya57 adds a link | 16:59 | |
| barry | blue means canonical is upstream | 16:59 |
| barry | yellow means there's some hope :) | 16:59 |
| barry | e.g. upstream has support, maybe not officially released, or not packaged yet, etc. | 17:00 |
| seb128 | ok | 17:00 |
| barry | mitya57: thanks. it's linked from the wiki spec | 17:00 |
| seb128 | is s-c really worth the effort? | 17:00 |
| seb128 | I though it was going to be deprecated | 17:00 |
| barry | ralsina_: says it is not going away for 14.04 | 17:00 |
| seb128 | it's buggy like that (see e.u.c), if we spend efforts on it we should spend those fixing bugs | 17:01 |
| Laney | surely not for 14.04 | 17:01 |
| seb128 | well, it's not like we are going to get ride of python2 for 14.04 | 17:01 |
| pitti | right, there's almost no hope for hplip, s-c-p, sso, and the like | 17:01 |
| barry | not entirely, no | 17:01 |
| seb128 | so s-c seems like wasted effort/chances to destabilize it more | 17:02 |
| pitti | so keeping s-c as it is in 14.04 would be sensible | 17:02 |
| seb128 | if it's not properly maintained/moving forward, we should just fixes the most important bugs for the LTS and minimize resources spent on it imho | 17:02 |
| pitti | if we have so much time to spend on py3, let's rather do it on the pieces that we keep :) | 17:02 |
| seb128 | right | 17:02 |
| barry | if that's the case (which is fine, there's plenty of other work to do), then it'll mean we won't need to spend time on deps that only those pieces pull in | 17:03 |
| barry | seb128, pitti, Laney if you guys can review the list (look at applications and library tabs) and let me know what has no hope of porting or just isn't worth it and i'll mark them in the spreadsheet | 17:05 |
| seb128 | barry, sure, seems like pitti got the ones I know about | 17:06 |
| Laney | not sure what the deal is on ibus | 17:07 |
| barry | seb128: thanks | 17:08 |
| seb128 | Laney, not sure about ibus either... | 17:08 |
| Laney | mmm | 17:09 |
| zyga | jodh: is http://upstart.ubuntu.com/wiki/DBusInterface the best place to learn about dbus interface for upstart? | 17:19 |
| pitti | rickspencer3, jono: yes, we'll support direct Q->T upgrades | 17:47 |
| pitti | (that was just discussed an hour ago) | 17:48 |
| jono | thanks pitti | 17:49 |
| rickspencer3 | thanks pitti | 17:59 |
| tkamppeter | Anyone from the design team here? I am starting a session about the mobile print dialog now. | 18:05 |
| === bfiller is now known as bfiller_afk | ||
| === dholbach_ is now known as dholbach | ||
| jodh | zyga: currently, yes. it's on my todo to add a table to the cookbook... | 19:52 |
| === FJKong_ is now known as FJKong | ||
| Noskcaj | Is there a way to test if a package will build on ARM? Some GL changes to evas mean it can be synced if it build on ARM IIRC | 20:29 |
| ogra_ | Noskcaj, you could use a PPA ... got to #launchpad and ask them to enable armhf for it | 20:31 |
| tumbleweed | Noskcaj: or create an arm schroot / pbuilder (using qemu-user-static) | 20:31 |
| Noskcaj | I'll do the first one | 20:31 |
| === bfiller_ is now known as bfiller | ||
| zyga | jodh: thanks | 20:45 |
| === salem_ is now known as _salem | ||
| bdmurray | cyphermox: bug 1198315 is missing SRU information | 21:27 |
| ubottu | bug 1198315 in gnome-control-center (Ubuntu Saucy) "[network]: gnome-control-center SIGSEGV in append_escaped_text() (invalid utf8 ssid name)" [Medium,In progress] https://launchpad.net/bugs/1198315 | 21:27 |
| cyphermox | oh, oops, quite right | 21:28 |
| cyphermox | bdmurray: actually, could you reject it, I have a patch that would be better than what I uploaded earlier | 21:29 |
| bdmurray | cyphermox: done | 21:31 |
| cyphermox | thanks | 21:31 |
| RAOF | slangasek: This is your UTC+11-morning last-night's vUDS reply message… No, we won't have a system compositor on the desktop by default for 14.04; only XMir or Unity8 would run under a system compositor, and we've stated we're not going to be defaulting to either of those for 14.04 | 22:38 |
| bdmurray | bdrung: your upload of apt-mirror to the precise proposed queue does not reference bug 977278 | 22:52 |
| ubottu | bug 977278 in apt-mirror (Ubuntu Precise) "apt-mirror does not support armhf arch" [Undecided,Fix committed] https://launchpad.net/bugs/977278 | 22:52 |
| bdrung | bdmurray: ups | 22:52 |
| bdrung | bdmurray: should i reupload it? | 22:54 |
| bdmurray | bdrung: that'd be great and if you let me know I'll approve it | 22:54 |
| bdrung | bdmurray: reuploaded | 23:06 |
| slangasek | RAOF: so, we wouldn't consider using the system compositor up to the greeter, e.g., and then stopping it in favor of X? | 23:29 |
| RAOF | You mean up to and including the greeter, right? | 23:30 |
| slangasek | RAOF: yeah | 23:31 |
| RAOF | That wouldn't solve the text-on-shutdown problem, and would require us to have nvidia and fglrx drivers that I hope we'll have but am not sure that we'll have... | 23:31 |
| slangasek | righto | 23:31 |
| RAOF | And I'm not sure how it'd interact with user switching; we'd need to bring the sc back up for the greeter, then tear it down again for X, etc? | 23:31 |
| RAOF | Hm, no, that bit would be fine. | 23:31 |
| RAOF | We'd just do the same VT dance we normally do. | 23:32 |
| RAOF | Hm. | 23:32 |
| * slangasek nods | 23:32 | |
| RAOF | And that actually *would* solve the text-on-shutdown problem, assuming we did things in the right order... | 23:32 |
| RAOF | And we wouldn't actually stop the sc, we'd just VT switch from it, so the greeter could still be all up andn ready. | 23:34 |
| RAOF | slangasek: So, I think there are only two reasons why we wouldn't be able to have a sc - (a) do we have the manpower, and (b) will we get nvidia/fglrx Mir drivers? | 23:35 |
| sarnold | are there any concerns about multiple GUI contraptions taking up memory bandwidth and disk bandwidth when paging them in? | 23:39 |
| RAOF | The sc would be pretty small; probably on the order of X (which ends up being ~20MB), and we could make it even smaller if necessary. | 23:40 |
| sarnold | ah once they hit steady state tht's not so bad | 23:41 |
| slangasek | RAOF: <nod> | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!