=== henrix is now known as henrix_ === wedgwood is now known as wedgwood_away === arosales is now known as arosales-afk [02:23] cjwatson: I had a look at the gnulibc bug you were talking about. Is it true that the program assumes that gets is detected? [02:24] s/program/source/ [04:42] cjwatson, hey, can you approve my spidermonkey post on ubuntu-devel? [05:30] Hi! (hope that's not ot) I can't find how to change my ubuntu single sign-on username. Here https://login.ubuntu.com/ I can only change full name, email or pwd. [05:30] Any tips? [05:31] I found this post which sounds similar to my scenario: http://askubuntu.com/questions/162435/changing-user-name-on-https-myapps-developer-ubuntu-com-dev [05:35] Ah! I found the way! It's reported here: https://answers.launchpad.net/launchpad/+faq/53 (quite tricky to find indeed) [05:36] cheshair: nice :) I just got there.. [05:36] sarnold: thanks for your interest! i appreciate, did you find it quick? [05:37] cheshair: no, you found it first, it would have taken me several more minutes at the least [05:37] (i started getting there via /topic #launchpad and seeing the answers url...) [05:38] sarnold: oh i see, thanks again! :-) [05:48] vibhav: gnulib, not gnulibc - and no, not really, the bug was that gnulib was trying to install a wrapper for gets that warned when you tried to use it, but it was doing so using typeof to detect the original libc type of gets and this broke when gets was absent from libc [05:49] vibhav: this is fairly complex and you aren't necessarily expected to understand it, which is why I just pointed to a few packages that I knew had been temporarily distro-patched to fix the problem :) [05:49] (as in, typeof is moderately obscure to start with and understanding gnulib requires a fairly clear understanding of autoconf and libc) [05:51] darkxst: done [05:53] cjwatson: Ah, I get it now. Well learning something new never does any harm :) === doko_ is now known as doko [05:59] query cjwatson [05:59] cjwatson, heh, still awake, or already? [06:04] doko: btw, I had a look at kasumi. Would it be better to file a MIR or lower the recommends? [06:05] (It should be noted that kasumi is simple dictionary utility for anthy) [06:08] doko: already :-/ [06:09] cjwatson: Actually, I know what typeof does :D [06:18] vibhav: I stand corrected, sorry :) [06:18] :) [06:23] doko: Could you have a look at https://code.launchpad.net/~vibhavp/ubuntu/raring/anthy/fix-component-mismatch/+merge/150961 ? === lilstevie is now known as b3ll === b3ll is now known as lilstevie === fisted_ is now known as fisted [07:08] Good morning [07:21] bdmurray,ev: phased update support is now live in LP; you can see the column for it in https://launchpad.net/ubuntu/raring/i386/man-db [07:21] (e.g.) [07:22] I suggest memorising how to get to those binary package publishing history pages, as it's hard to find them by navigation alone [07:24] good morning === vibhav is now known as Guest98376 === smb` is now known as smb === bambee is now known as rperier [08:40] hi [08:40] the canonical-partner repository is pretty slow. where's the proper place to report this? === Guest98376 is now known as vibhav [08:58] cjwatson: awesome, thanks! === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix [09:25] tomreyn: #canonical-sysadmin i suppose [09:33] thanks Laney [09:34] tomreyn: I believe there were flash and/or java updates though, so it's likely to be due to higher than average traffic [09:35] is java in there, too? [09:35] there surely were flash updates, which is why i noticed [09:35] but that's like 5 or 6 MB [09:37] sorry, not java [09:37] but 5/6 * is surely a lot [09:47] maybe 2 mirrors are not enough then === BruceMa is now known as BruceMa_afk [10:07] doko: boost1.53 is being prepared in svn but it apperantly has some packaging restructuring in progress and hence is not uploaded yet. [10:08] i guess you'd want me to drive that to an upload ;-) [10:08] well, if 1.53 will be the next debian default, yes, that would be good [10:39] seb128, does gnome-calculator need a MIR? [10:39] doko, no, it's a rename of gcalctool [10:51] ev, hey, is filtering on a source/binary known to be broken (e.u.c)? [10:52] ev, I'm trying to see telepathy-gabble bugs but it seems to never finish "Loading..." [10:53] seb128: think I've spotted the bug. Fixing. [10:54] ev, thanks === fisted_ is now known as fisted === EagleScreen is now known as Guest89798 [11:06] http://www.ubuntu.com/testing is very outdated [12:11] aloha [12:15] diwic, which alsa-tools version is this? [12:16] doko, hmm, 1.0.25-2ubuntu1 [12:18] doko, I tried packaging 1.0.26.1, that's when I discovered it and found it present in current version as well === _salem is now known as salem_ [12:22] Laney: anyone else I should poke re my partial upgrade ? [12:22] http://pastebin.ubuntu.com/5573162/ [12:22] I'm not sure what the intended behaviour is [12:23] jbicha: is the Breaks strictly necessary? [12:28] Laney: we can't run two different cogl libraries at the same time so we don't want the old library to be present at all... [12:29] doesn't britney ensure this? [12:29] I basically copied what Debian did the last time we had to do the cogl transition [12:34] so I believe Debian needs the breaks, I have no idea whether Ubuntu upgrades can work without it [12:34] I can see how it would be a problem if you're running unstable (or raring-proposed) [12:35] i.e. if the transition is in progress === komputes_ is now known as komputes === fabo_ is now known as fabo [12:38] Laney: http://paste.ubuntu.com/5573220/ [12:38] haha, classy [12:39] why keep them? [12:39] Laney: such that they match the attic/ folder in the branch. [12:39] why are those kept? [12:39] because they might be useful in the future [12:39] for the next transition of that library, for example [12:40] or as examples for some future transition [12:40] same. if transition finished 3 days ago, but I am confused why something is borked, one can look at it. [12:40] can't say i've done that [12:40] but whatevs [12:40] =) [12:40] Laney, what's the issue exactly there? (sorry I disconnected), is the partial upgrade because the old soname needs to be removed? === seb128_ is now known as seb128 [12:40] tkamppeter_: mind if I close https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1029865 as WONTFIX since from your description it seems to be a hardware issue? [12:40] Launchpad bug 1029865 in linux (Ubuntu) "Intel HD graphics: Starts always with 1024x768 resolution on a 1920x1080 monitor (HDMI and DisplayPort)" [High,Confirmed] [12:40] seb128: right, because there's a Breaks from clutter-something to libcogl [12:40] czajkowski: we shouldn't have partial upgrades in raring =( [12:41] feels like u-m should allow this, but I don't know how to capture the situation [12:41] and I do think we could remove the Breaks but there wouldn't be anything to stop things like this coming from Debian [12:43] xnox: hence me joining here to find out whuy :) [12:44] thanks ;-) [12:45] Laney: you can -delete them, I'm not fussed. [12:46] xnox: I think that should be done in the 'go' script [12:46] to remove them before they're rsynced to public [12:47] * Laney JFDI [12:48] ev, foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; total those absolute values; put the uuid in the bucket that results in the lowest total, using the earliest if there's a tie}. [12:49] xnox: OK it's in place [12:49] we can expose the attic later if it's wanted [12:50] jbicha: I'll upload to remove the Breaks now and we can decide whether u-m should be able to handle this situation at our leisure later [12:53] ev, a simpler version that would probably work just as well: foreach uuid, {foreach percentage bucket, {calculate the absolute value of the difference, if you put the uuid in that bucket, between its resulting percentage and its target percentage}; put the uuid in the bucket that has the lowest absolute difference, using the earliest if there's a tie}. [13:01] czajkowski: jbicha: OK, uploaded - please see if the partial upgrade goes away when that's rolled out in a couple of hours [13:01] seb128: ↑ fyi [13:03] Laney, perhaps "Breaks" in update-manager is (or would best be) covered by bug 1038113? [13:03] bug 1038113 in update-manager (Ubuntu Raring) "support conflicts/provides/replaces and allow removal in this case" [High,Fix released] https://launchpad.net/bugs/1038113 [13:03] Laney, how did you fix it? [13:03] I just dropped the breaks [13:03] I don't think we need it [13:03] Laney, it seems like that breaking on an old package that needs to be removed should be a normal/supported upgrade case [13:03] oh, maybe not, that's fixed in Raring already apparently [13:03] mpt: that was fixed and seems to me to be about a rather more specific case (complete replacement as expressed by the Provides) [13:03] seb128: It was intended to stop users doing partial upgrades in the middle of the transition [13:04] Laney, right, but it seems like at the end of the transition it should be ok [13:04] not sure why we need to drop it [13:04] shouldn't update-manager just do the right thing [13:04] because u-m refuses to remove packages like that [13:04] e.g remove the old package [13:05] which means we pile old cruft... [13:05] I don't know if it has any autoremoval support [13:05] ok [13:05] Laney, anyway, thanks for fixing it [13:05] it seems like it's going to bite us again in the futur though [13:05] and I do think it behaves a bit differently wrt removals when doing a release upgrade (there must be other packages being forced out in that case, surely) [13:05] sometimes we do require removal from the old soname because there is a file conflict or something === amitk is now known as amitk-afk [13:07] yeah [13:07] and sometimes we'll just plain want to get rid of packages for some reason [13:07] mpt: do you know how update-manager handles this? === soren__ is now known as soren [13:08] i.e. what is the specification that determines when you get a partial upgrade? [13:14] perhaps it's just unreasonable; after all, you do sometimes use dist-upgrade instead of upgrade (apt-get upgrade also didn't handle this case) [13:17] Laney, fwded you a recent email which is discussing killing the partial upgrade button [13:17] cool, ty [13:17] yw [13:29] the background is for each uuid representing a core file coming in, we need to assign it to a specific bucket such that the total number of uuids processed into a bucket over time matches the percentage assigned to that bucket [13:30] oh, the first part of what I wrote didn't send [13:30] [13:27:11] mpt: we don't know the set of uuids ahead of time. The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range [13:30] [13:27:42] we then pass the bucket information along with the uuid so that it doesn't need to be run again using the uuid as input, thus dropping the deterministic requirement [13:31] xnox: http://people.canonical.com/~ubuntu-archive/transitions/ much cleaner now :-) [13:31] Laney: all media files are gone, no css /js [13:32] oh yeah :P [13:32] already putting that back [13:32] *too* clean ;) [13:32] ev, you don't need to know the set of uuids ahead of time. [13:32] Laney: is it croned to wipe media files? =) [13:33] blame xnox [13:34] Laney: i had a careful -max-depth 1 [13:34] symlink [13:34] adding a -type f [13:34] *sigh* [13:35] Laney, not really. If it turns out to require UI, please assign a bug to me, and I'll extend either or to cover it. [13:35] xnox: that's better, yes? === Ursinha-afk is now known as Ursinha [13:36] hopefully it will all work after a cron run [13:37] mpt: oh, but it requires knowing how many uuids are in each bucket? [13:37] mpt: I would think that, if anything, we'll extend update-manager to understand that some types of removals are OK when upgrading (so no new UI) [13:38] automatically installed libraries only, no other relationships broken or something like that [13:38] ev, how many you've put in each bucket so far, sure. [13:38] Laney, sounds good. [13:38] mpt: yeah, that's not ideal. Requires persistent storage for those totals. [13:39] I'd much rather use something that gets close to accurate but doesn't require knowledge of any step before [13:43] ev: Forgetful, deterministic, and accurate, pick two. You can demonstrate this with the simplest useful example: two buckets which you want 50% full each. A forgetful and deterministic algorithm would incorrectly either put every uuid into the first bucket, or every uuid into the second. [13:47] mpt: forgetful and accurate [13:48] So, use random numbers :-) [13:48] mpt: "The solution I've come up with is to drop the deterministic requirement and just use random.randint(1,100) which each bucket mapping to a portion of that range" :) [13:48] yep [13:49] but you're absolutely right about first defining the constraints, and thanks for the pointers [13:55] ev: mpt: whenever I see you both discussing topics on here it is incredibly reassuring [13:56] mpt: ev: continuing kudos to you [13:56] sladen, not as reassuring as it might appear, because we aren't sitting next to each other at the moment. I haven't seen ev in days. :-) [13:56] sladen: thanks :) [13:56] mpt: yeah, I really must get back into the office [13:56] but this whole working until midnight thing is addictive [13:59] miaow! though it's a fair point, I didn't find Bluefin to be as inspiring an office as Millbank and I can see reasons for avoiding it ;-) [14:00] it at least has better coffee than I (suddenly) do at home [14:01] I think my transition to the UK can be considered complete when I now prefer Monmouth to Dunkin Donuts [14:02] pitti, can you mark https://code.launchpad.net/~johnv/ubuntu/precise/libappindicator/bug-1122596/+merge/148027 as merged? [14:02] seb128: done [14:02] pitti, danke [14:02] can debian/rules work from a different directory than root? [14:03] i'm trying to get around a limitation of launchpad recipes === tuxinator_ is now known as tuxinator [14:04] pitti, I noticed that your reviewed the l-s MR, did you look at https://launchpadlibrarian.net/132004936/accountsservice_lp-1130690.diff as well and didn't like or were you just letting that for someone else [14:04] seb128: I didn't get to that one [14:04] pitti, I don't like that stack of scripts but at this point that small addition is not going to make a difference [14:04] seb128: yeah, same here; it has become a terrible mess [14:05] pitti, ok, I'm going to upload it then, I just wanted to check with you first to not step on your toes [14:05] pitti, danke ;-) [14:05] merci [14:08] jodh, do I understand correctly that the Upstart user session will replace update-notifier completely? Or would it just be launching update-notifier periodically? [14:08] Oh, I should have read the work items: "[seb128] replace update-notifier with upstart jobs: BLOCKED" [14:08] mpt, define "update-notifier" :p [14:09] seb128, the bane of ev's existence [14:09] pitti - any idea ^? [14:09] mpt, https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-reduced-power-ram has [14:09] [brian-murray] change update-notifier to be running on demand, from an upstart job, does the action it has been called for and exit: BLOCKED [14:09] seb128, because it includes various bits of Apport too [14:10] mpt, right, update-notifier evolved to be collection of different things over time [14:10] And, unimportantly, but my focus right this minute, the cause of bug 399591 [14:10] bug 399591 in One Hundred Paper Cuts "System Monitor shows unfriendly name "update-notifier"" [Low,Triaged] https://launchpad.net/bugs/399591 [14:10] mpt, we plan to separate those in "logical units" [14:11] xnox, I don't intend to drop guile-1.8, just demote it [14:11] seb128, would the update part of it just be merged with update-manager, or would it stay separate? [14:13] mpt, that's a good question, update-manager doesn't have a nonUI part atm afaik, but we could teach it to do "silent" updates and only display the ui if there are updates then [14:13] mpt/seb128: I thought that the upstart-time-bridge would mean update-notifier would not need to run constantly, but we probably won't have that bridge in the first iteration. [14:14] mpt, no concrete plan atm though [14:14] jodh, right [14:17] hm seems I was still on a rc1 kernel :P [14:17] mpt, seb128: :D === bambee is now known as rperier [14:22] seb128: RT 59730 should fix that problem [14:24] dusty42: hi [14:24] ev, thanks a lot for the quick fix! [14:25] dusty42: let's talk here about the problem [14:25] seb128: sorry it took as long as it did - got pulled aside for other things [14:25] trying to get webops on it now [14:25] (for context if anyone wants to help) - dusty42 is looking at a situation where a user is ssh-ing from macosx and inherits some of the environment from osx, that in turn causes issues with setlocale() [14:26] we're not sure if what osx is doing is correct [14:26] OS X is doing it the wrong way for sure [14:26] just that it causes actual problems that gives the impression that "ubuntu is broken [14:26] dusty42: so you said that LC_CTYPE from osx is set to "UTF-8" [14:26] OS sets environment variable LC_CTYPE=UTF-8 [14:27] when you ssh to remote host, ssh client sets LC_CTYPE=UTF-8 on remote system as well [14:27] I mentioned that we can either fix this in one specific case (in the app that is affected now) [14:27] or look at fixing it somewhere globally in ubuntu [14:27] doko: why not? fedora supposedly has everything on 2.0 [14:28] if that's possible to fix reliably [14:28] dusty42: for now I'd see if we can work around it at the app level but as I said earlier it'd be good to bring this topic up in the ubuntu-devel mailing list [14:28] as it probably affects everything [14:29] and mac developers sshing to ubuntu servers would get the bad impression that things don't work in certain cases [14:29] dusty42: what does putty/windows does if you have a means to check that? [14:31] This snippet demonstrates how locale module in Python behaves on different LC_CTYPE env variables: http://pastie.org/6354504 [14:32] zyga: yes, I'll check that for sure [14:32] infinity, Hi... so I back-ported a piece of lb_binary_rootfs from 3.0.1-1 to enable ext3 and ext4 rootfs's and I noticed a peculiar line "Chroot chroot "ln -s /proc/mounts/mtab /etc/mtab" (line 128)... this caused us to hit a bug in precise but was silent in quantal... /proc/mounts/mtab... is that... valid? (I had to change back to /proc/mounts to get it working) [14:33] infinity, wondering if you've encountered this at all [14:33] dusty42: cool, I suspect it is safe to just blindly change 'UTF-8' to 'C.UTF-8' since the magic C.UTF-8 locale was added to glibc [14:36] zyga: yes, that's right [14:37] zyga: however, where should this env variable be corrected? [14:37] dusty42: I would encourage you to document this, which osx version, what kind of settings (defaults matter) etc [14:37] dusty42: so if we do for just-the-app fix then we can simply change how we call setlocale [14:37] dusty42: if we want to do some bigger changes we'd have to ask someone else [14:38] pitti: ^^ do you know if it would be sane/good to fix broken env that comes from osx uses sshing into ubuntu? [14:39] pitti: like doing some tests in the early environment files that (hopefully) all the shells source, or even straight in the ssh package [14:39] zyga: I wouldn't quite know where, though [14:39] in general I have always found it rather questionable to forward locale env through ssh as well [14:39] it causes at least as much unintended damage as it does good [14:40] yeah, especially since there is no agreed-upon meaning for any of the values [14:40] I suspect that LC_TYPE=UTF-8 is valid somewhere but it just breaks us [14:40] pitti: in case with OS X, the defaults are broken (well, at least with regard to Ubuntu settings) [14:41] pitti: alternatively [14:41] pitti: we could do it at libc level [14:41] pitti: where it would be an alias of C.UTF-8 [14:41] zyga: this sounds like the nicest workaround, actually [14:41] well, the names of locales are defined by the local localedef conventions and thus by the distro/OS [14:42] but I don't know if that's sensible actually -- can LC_CTYPE carry language definition? [14:42] that's one major reason why they don't belong forwarded [14:42] (the other is that in many cases the locale doesn't even exist on the remote machine) [14:42] it sure makes sense in LC_MESSAGES but for LC_CTYPE? [14:42] pitti: yeah, that's another valid problem [14:42] pitti: we track that separately [14:42] it's much better to use the remote computer's .bashrc or .pam_environment or whatever IMHO [14:42] no, it doesn't make sense for any LC_* [14:43] pitti: so do you think that what osx does is correct? sending us LC_CTYPE=UTF-8? [14:43] IMHO we should drop SendEnv from /etc/ssh/ssh_config, but I guess cjwatson feels otherwise [14:44] pitti: do you think we should move this to the mailing list to get feedback from more people? [14:44] zyga: well, UTF-8 is not a locale, but if OSX defines a locale with that name (presumably based on en_US), it's valid within an OSX context [14:44] pitti: the topic is certainly interesting but perhaps invisible to us, since we don't use windows/osx typically [14:45] oh, there is perhaps a workaround, see bug 313317 [14:45] bug 313317 in Ikarus Scheme "guard should allow definitions in its body" [Low,Fix committed] https://launchpad.net/bugs/313317 [14:45] err, debian bug 313317 [14:45] Debian bug 313317 in openssh-server "openssh-server: PAM environment takes precedence over SendEnv" [Normal,Open] http://bugs.debian.org/313317 [14:46] (which I actually consider a good thing) [14:46] debian bug 391964 and debian bug 558171 are also related [14:46] Debian bug 391964 in openssh-client "warn if client-requested locale not available on server?" [Important,Open] http://bugs.debian.org/391964 [14:46] Debian bug 558171 in openssh-client "openssh-client: some LC_LOCALE settings make ssh fail to open a shell" [Important,Open] http://bugs.debian.org/558171 [14:46] debian bug 573316 is probably the closes thing [14:46] Debian bug 573316 in openssh-client "request for new UnSendEnv directive (or change SendEnv)" [Wishlist,Open] http://bugs.debian.org/573316 [14:46] pitti: yeah, that does sound right a lot [14:46] zyga: ^ in case you want to refer to some bugs in your mail [14:47] dusty42: ^^ would you mind looking at those as possible general solutions to this problem? [14:47] pitti: thanks a lot [14:48] well, these are not solutions, they are bugs which happen because of the locale forwarding [14:48] Sure [14:48] I have more, like people create postgresql clusters with wrong encodings, and get tons of perl errors due to wrong locales [14:49] xnox, well, in this case maybe consider moving the headers into a location where guile-1.8-dev had them [14:49] zyga, dusty42: so it seems cjwatson went off IRC for the first time in years, so bad time to discuss this :/ [14:50] :D [14:50] pitti: I came across the postgresql bug myself, IIRC our cloud images were affected by tyhat [14:50] that [14:51] pitti: sorry, I misunderstood then, I'ms till reading the bugs you've referenced [14:51] It's actually not that hard to handle this at app level [14:52] dusty42: so either fix it on the client ssh side by dropping SendEnv, or on the server side by adding a .pam_environment file with the correct locale for the remote system [14:52] dusty42: true but then each app has to do it [14:52] pitti: note that we cannot fix the client, this is osx that's causing the problem (and putty) [14:52] zyga: of course, and this aint' cool at all [14:52] nah, fixing a broken environment really shouldn't be done by-app [14:52] pitti: although putty is broken in different way [14:53] IIRC putty uses some silly old encoding by default but does not actually specifies it as such in any of the environment variables it sends [14:53] hi, is there a lightdm channel or is it here? [14:53] like sending ISO8859-2 over the wire (and interpreting that locally for display) and not sending anything at all as environment [14:54] this causes issues with backspace and how it is interpreted [14:55] pitti: so, as I understand, those bugs should be closed because it's the problem on the client system, not Ubuntu itself, correct? [14:55] dusty42: no, Debian/Ubuntu's ssh also defaults to forwarding these environment vars [14:57] dusty42: also note that most users don't understand that and just see broken ubuntu [14:57] pitti: fixing the LC_CTYPE globally via /etc/.profile is a bad idea, right? E.g. detect if it's "UTF-8" and change to "C.UTF-8"? [14:57] dusty42: so if we can get a workaround that just makes things work right when we see broken input, that's good [14:59] maybe not /etc/.profile, somewhere else (not yet sure where) === wedgwood_away is now known as wedgwood [15:01] zyga, you're needed :) === kentb-out is now known as kentb [15:03] plars: hey, are you by any chance expert at building crosstools on recent ubuntu ? [15:03] :) [15:03] * zyga -> meeting [15:04] hallyn: nope, sorry :( [15:04] i've wasted like a day now trying to get it to compile, always ends up failing somewhere. (used linaro releases 2012.10 and 2012.12 before, now using upstream ) [15:04] ok - thanks [15:07] plars: hey, long time no see, how are you doing? [15:17] Mirv: can you please apply https://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtsvg-opensource-src/revision/22 to Debian git? [15:18] I've been doing some icon themes testing in Debian, and without that change SVG themes don't work [15:28] Mirv: and while we are at it, please also apply http://paste.ubuntu.com/5573584/ [15:36] rickspencer3: Friday 27th Feb??? [15:38] hi mitya57 [15:38] did I put a weird typo in my email? [15:38] *sigh* [15:39] maybe I mean tomorrow :) [15:40] hopefully everyone will understand that [15:40] rickspencer3: Friday 27th Feb? ;-) [15:41] Laney, I know I know [15:41] :P [15:41] I spent *days* working on that email [15:41] and I missed that one thing [15:41] I am such a bad proof reader [15:41] yeah, the letters stop going in [15:41] you mean tomorrow, I guess? [15:42] Laney: Clearly, yesterday. [15:42] jpds: Ah, OK. [15:42] * Laney speeds up to 88mph [15:42] thanks Laney [15:42] :) [15:42] only 88 ? [15:43] ah, you're in an autobahn-less country ... /me forgot :P [15:43] rickspencer3: At least I just exposed that I didn't read the few lines immediately prior to my saying it ... [15:43] ogra_ hasn't seen back to the future? [15:43] clearly [15:43] oh, i missed the referral [15:43] :P [15:44] zyga: sorry, was in a meeting. I'm doing well, lots going on as always :) [15:44] plars: :-) === rickspencer3 is now known as CalvinKlein [15:45] Laney, ^ that's for you [15:46] :D [15:47] stgraber: Hey ho [15:47] so, trying out user session jobs ... what's the compiz one for? [15:47] That should be started by gnome-session if needed shouldn't it? [15:47] Sweetshark, online? === tkamppeter_ is now known as tkamppeter [15:48] If I remove it I can start other gnome sessions (trying shell) under upstart [15:50] Laney: right, compiz, nautilus, gnome-settings-daemon and pulseaudio are all example jobs to show what we could to if the plan was to phase out some parts of gnome-session [15:50] doko: yes and in call [15:51] stgraber: ah [15:51] Laney: I don't think we should push those to the archive as they're indeed not needed in the current state of things [15:51] but since we still call gnome-session then they can get in the way sometimes [15:52] Laney: but e.g. it would be nice to at least have gtk-window-decorators as an upstart job, cause it crashes a lot and we can respawn it. Similar with compiz. I'm not sure about gnome-session's respawing capabilities. [15:52] Laney: compiz and nautilus might, gnome-settings-daemon and pulseaudio won't [15:52] right [15:52] Laney: as gnome-settings-daemon and pulseaudio are overriden by /usr/share/upstart/xdg/autostart/ [15:53] Laney: if you can point me which piece of gnome-session starts compiz i'd like to know, cause I failed to find the right place to override. [15:53] xnox: AFAIK the .session file for unity tells it to start [15:53] gnome-session searches for a matching .desktop file [15:53] Laney: we nifty prepend /usr/share/upstart/xdg to XDG_CONFIG_DIRS to shadow a few autostart/*.desktop files in favor of upstart jobs. [15:54] right [15:54] And I'd like to shadow compiz for example, in a similar fashion if possible. [15:54] so we'd want some kind of interfacing with .session files maybe [15:54] or something [15:54] cause imho having upstart manage the window manager would be awesome. [15:54] to only start compiz in a session which wants it [15:54] or we do it by default where ubuntu.session has upstart in it instead of compiz. [15:54] (wait that won't work) [15:57] see Required* in /usr/share/gnome-session/sessions/*.session and gnome-session(1) [15:57] as long as we're in a world that mixes upstart and gnome-session, we're going to have to live with some hardcoded values in the jobs. It should however be possible to do something along the lines of "start on starting gnome-session DESKTOP_SESSION=ubuntu [15:57] mlankhorst, you can close the bug, it is in fact some hardware problem. [15:57] " [15:58] does that work? [15:58] could you have some thing which reads the .session files and emits some events based on what they'd cause to be started? [15:58] s/files/file to be loaded/ [15:58] hi, somebody opened a bug report against my project, that it doesn't install in the right place on Ubuntu 12.04 [15:59] looking closer, it turns out that the autotools stuff runs this code, to find where to install the Python module: http://paste.fedoraproject.org/3987/ [15:59] and as you can see in the paste, the returned folder is wrong (it should be python3.2, not python3) [15:59] any idea on how to fix this properly? [15:59] Laney: we may need an extra "export DESKTOP_SESSION" in gnome-session.conf, but yes, it's easy enough to get DESKTOP_SESSION to be exported to other jobs so they can start depending on that [16:00] I didn't know you could have "start on " - that's useful for now indeed [16:01] barry: doko: maybe you would have any idea on bochecha's question? ^ [16:01] bochecha: hi. let me look [16:02] barry, hi, thanks :) [16:02] Laney: writing a parser for gnome-session should be possible too but I guess this really depends on the plans for the desktop, because it may be quite a bit of work to get something that's flexible enough and I don't think we want to invest that kind of time if there are chances we'd move away from gnome-session [16:02] (not that I really know anything about your plans, hence why I ask ;)) [16:02] right, I don't know that that's planned [16:03] or how much work it would be to nick parts of it out of gnome-session itself [16:04] bochecha: well, actually, the path in line #2 looks right. dist-packages is correct for debian/ubuntu (instead of site-packages), and because of pep 3147/3149 file tagging, we can install all python3 modules in the same location without conflict [16:04] barry, but then, the module can't be imported in python3 [16:05] bochecha: line #1 does look a little weird in that sysconfig is imported but not used ;) [16:05] bochecha: hm why not? all python3.X look in python3/ location. [16:05] bochecha: hmm, do you know why it can't be imported? have you tried using -v? can it not be imported because it can't be found, or because of some other problem on import? [16:06] barry, actually, it can be imported, you're right that /usr/lib/python3/dist-packages is in sys.path [16:06] I incorrectly tried to reproduce the bug [16:06] the reporter had used /usr/local as his prefix [16:07] and /usr/local/lib/python3/dist-packages is not in sys.path [16:07] barry, only /usr/local/lib/python3.2/dist-packages is [16:07] bochecha: ah, yes, that's true [16:08]