| === salem_ is now known as _salem | ||
| pitti | Good morning | 04:29 |
|---|---|---|
| pitti | ahasenack: hello; I'm around now | 04:30 |
| infinity | rsalveti: That sure is a lot of undeclared build-deps. | 04:58 |
| hallyn_ | xnox: so one oddity i've found with threaded libnih: when any thread calls nih_error_init(), it onexit()s a fn that asserts context_stack != NULL - but context_stack is __thread | 06:04 |
| hallyn_ | while onexit is process-wide | 06:04 |
| hallyn_ | so if you fork, you get a NULl context_stack but still have the onexit'd fn; so then you have to _exit() instead of exit() | 06:04 |
| hallyn_ | else, ugly assert error msgs | 06:05 |
| hallyn_ | I suppose it might also be an issue when the original process exits if the last exiting thread had context_stck == NULL... | 06:06 |
| dholbach | good morning | 06:31 |
| highvoltage | micahg: your upstream guys came through, thunderbird looks good again in trusty this morning | 06:36 |
| seb128 | hey dholbach! | 06:37 |
| dholbach | salut seb128 | 06:41 |
| zyga | mvo: hey | 07:49 |
| zyga | mvo: did you have a chance to look at tarmac lately? | 07:50 |
| mvo | zyga: hey, I haven't, was on vacation and have not looked into this at all yet | 07:57 |
| === oSoMoN_ is now known as oSoMoN | ||
| zyga | mvo: ok, thanks | 07:58 |
| * Laney backports high fives micahg | 08:20 | |
| Laney | dug out the ol' GPG key again ;-) | 08:20 |
| rbasak | pitti: I just spotted bug 1447654 which reminds me of bug 1450053. A user reports that mysql doesn't start on boot unless he installs policykit-1. I wonder if this is a systemd related bug? | 08:22 |
| ubottu | bug 1447654 in policykit-1 (Ubuntu) "installing policykit-1 hangs under systemd" [Medium,Confirmed] https://launchpad.net/bugs/1447654 | 08:23 |
| ubottu | bug 1450053 in mysql-5.6 (Ubuntu) "upgrade 14.04 to 15.04, mysql no longer starts on boot due to missing policykit-1" [High,New] https://launchpad.net/bugs/1450053 | 08:23 |
| pitti | rbasak: does mysql-5.6 actually have a .service, not just an init.d script? | 08:32 |
| rbasak | pitti: yes it does have a .service | 08:32 |
| pitti | we used to have some (cosmetical) bugs where systemctl enable foo.service failed with such an "no such file" error message if there was no actual .service | 08:33 |
| rbasak | Yeah I've seen that bug. | 08:33 |
| rbasak | I don't know if this is a separate issue or the fix or that would have fixed this. | 08:33 |
| pitti | rbasak: so, I need to look into this more closely, I don't have an off-hand idea | 08:33 |
| rbasak | Seems odd that installing policykit-1 fixed the issue. | 08:33 |
| rbasak | pitti: OK, thanks. Shall I tag it for you? | 08:33 |
| pitti | rbasak: might be a red herring -- a followup says that installing polkit didn't help | 08:34 |
| rbasak | pitti: that was a different person. | 08:34 |
| rbasak | "This issue affects me too, except that all the circumstances are different and it failed in a different way" -- well, that's a different bug then. | 08:35 |
| pitti | yes, I know, but it still sounds like a red herring to me | 08:35 |
| pitti | anyway, I'll try to reprodue | 08:35 |
| rbasak | Thanks | 08:35 |
| rbasak | I agree it's unclear. I'm getting bug reports about genuine issues in packaging in mysql 5.6 (new stuff), systemd-related issues, and users with screwed up databases getting failures. And they're all muddled up :( | 08:35 |
| ricotz | diwic, hi :), any plans to fix those failures? https://launchpad.net/ubuntu/+source/pulseaudio/1:6.0-0ubuntu7 | 08:54 |
| diwic | ricotz, let me forward that to hwang4 | 08:54 |
| diwic | ricotz, I hope he'll fix today or tomorrow. Feel free to revert if it's urgent | 08:56 |
| diwic | sorry | 08:57 |
| ricotz | diwic, no, just curious since it sits there for a week already ;) | 08:57 |
| diwic | ricotz, yeah, I missed that email in my inbox | 08:57 |
| flexiondotorg | dholbach, Thanks for sponsoring :-) | 08:59 |
| dholbach | no worries | 09:03 |
| alkisg | xnox, would you mind if I chatted 5 minutes with you about another upstart bug related to LP #1343905? I.e. I think that /etc/X11/Xsession.d/00upstart should go after 50x11-common_determine-startup in order to be able to locate the session from $STARTUP too, not only from $1 | 09:05 |
| ubottu | Launchpad bug 1343905 in upstart (Ubuntu Trusty) "Empty desktop in Xubuntu 14.04 on reboot after upgrading upstart package" [High,Fix released] https://launchpad.net/bugs/1343905 | 09:05 |
| alkisg | That part affects us on LTSP fat client desktops, they stopped being able to launch Unity in 14.04 because of that 00upstart script, and I'm trying to see if it'll be best to fix this in upstart or in ltsp | 09:06 |
| alkisg | So basically what I'm proposing is, 00upstart to be renamed to 50x12-upstart, and BASESESSION=${1% *} to become BASESESSION=${STARTUP% *} | 09:10 |
| xnox | alkisg: that should not be necessory. | 09:15 |
| xnox | alkisg: note that 00upstart really just saves variables for 99upstart to do stuff. | 09:16 |
| alkisg | xnox: it's possible for xsession to be called without parameters | 09:16 |
| alkisg | That then falls back to "defaults" | 09:16 |
| alkisg | The defaults are processed in 50x11-common_determine-startup | 09:16 |
| alkisg | From that script, $STARTUP is determined | 09:16 |
| alkisg | *then* 00upstart should decide the SESSIONTYPE based on that | 09:17 |
| xnox | I'd ask to poke stgraber - he did the user session upstart stuff and he knows LTSP. | 09:17 |
| alkisg | Unfortunately he seems too busy to deal with ltsp the last 2 years | 09:17 |
| xnox | doh, he is a busy man =) | 09:17 |
| alkisg | We've been trying to convince him to let us maintain ltsp in ubuntu instead, because it's been broken for too long | 09:17 |
| xnox | alkisg: why are you calling it without any arguments thogh on ltsp? are you not using a login manager at all? | 09:18 |
| alkisg | We're using LDM, the ltsp login manager | 09:18 |
| xnox | right... and why doesn't that parse/set session to launch? | 09:18 |
| alkisg | It's a valid scenario, see that script or the xsession manpage | 09:18 |
| xnox | imho default should be XTerm =) | 09:19 |
| alkisg | No, it's x-session-manager | 09:19 |
| alkisg | There's an alternative for that | 09:19 |
| alkisg | man Xsession mentions those | 09:19 |
| alkisg | There's support in Xorg and in debian for that since decades, only 14.04 broke it | 09:19 |
| alkisg | I can easily work around that in upstream ltsp, but it's wrong | 09:20 |
| alkisg | It should be fixed in upstart instead | 09:20 |
| alkisg | Even 00upstart reads x-session-manager | 09:20 |
| alkisg | It just does so at the wrong point, 00 instead of 51 | 09:20 |
| alkisg | xnox: I've already tried the 2 changes that I"m proposing and they work fine: 0upstart to be renamed to 50x12-upstart, and BASESESSION=${1% *} to become BASESESSION=${STARTUP% *} | 09:23 |
| xnox | alkisg: the idea behind 00upstart is that we only kick in for blessed sessions | 09:24 |
| xnox | alkisg: what is the value of $DESKTOP_SESSION and is it listed in /etc/upstart-xsessions for you? | 09:24 |
| alkisg | xnox: right, all those in /etc/upstart-xsessions | 09:24 |
| xnox | it is possible that it's out of date on 14.04 | 09:24 |
| alkisg | DESKTOP_SESSION is ubuntu | 09:24 |
| xnox | (upstart-xsessions) | 09:24 |
| xnox | ok. | 09:24 |
| alkisg | xnox, I've already troubleshooted the issue | 09:24 |
| alkisg | I do have the solution above ^... | 09:24 |
| alkisg | My question essentially is, if you guys want to fix that in upstart, or should we workaround the upstart bug in the ltsp code instead... | 09:25 |
| xnox | this is stuff is not upstart upstream, but in ubuntu packaging. | 09:26 |
| alkisg | Ah, that's why you mentioned to file distro-specific bug reports in that other bug I mentioned | 09:27 |
| alkisg | Ok, that's even easier then, isn't it? | 09:27 |
| xnox | the problem is that we cannot use STARTUP, no | 09:27 |
| alkisg | Why? | 09:27 |
| xnox | your solution is not right. | 09:27 |
| alkisg | Why? | 09:27 |
| xnox | look at 99upstart | 09:27 |
| xnox | we override STARTUP to become /sbin/upstart --user | 09:28 |
| alkisg | Yes? | 09:28 |
| alkisg | I know | 09:28 |
| xnox | and everything should be launched from there. | 09:28 |
| alkisg | Right | 09:28 |
| xnox | as in by upstart | 09:28 |
| alkisg | OK let me describe the problem better | 09:28 |
| alkisg | You're using $1 | 09:28 |
| xnox | not by user scripts, defaults or the x-session-manager | 09:28 |
| alkisg | Which is "gnome-session --session=ubuntu" | 09:28 |
| alkisg | At 50x11, STARTUP also is "gnome-session --session=ubuntu" | 09:28 |
| alkisg | So if 00upstart went to 50x12, it could use STARTUP instead of $1, both would have the same value | 09:29 |
| xnox | 50x11 is a no-on | 09:29 |
| alkisg | No change at all there | 09:29 |
| alkisg | BUT | 09:29 |
| xnox | it doesn't nothing when STARTUP is populated | 09:29 |
| xnox | it does nothing that is. | 09:29 |
| alkisg | It only determines what the user wants to launch | 09:29 |
| xnox | 50x11 only processes when STARTUP is empty, and one cannot have an upstart session if it was empty... | 09:30 |
| xnox | no, login manager should offer and consume user choices. | 09:30 |
| alkisg | xnox, I already tried it and it works | 09:30 |
| xnox | 50x11 doesn't process what user wants, it tries to do educated guess when not having any information what's so ever. | 09:30 |
| alkisg | 50x11 processes the user and the system alternatives | 09:31 |
| xnox | we cannot allow-user-xsession with upstart --user session, as we have no idea that it will work | 09:31 |
| alkisg | Wait wait | 09:31 |
| xnox | cause upstart --user will not process STARTUPFILE | 09:31 |
| alkisg | In 00upstart you read x-session-manager, right? | 09:31 |
| xnox | only conditionally | 09:31 |
| xnox | but we do not read STARTUPFILE | 09:32 |
| alkisg | OK, on what condition? if [ "$BASESESSION" = x-session-manager ] | 09:32 |
| alkisg | Are you willing to do the same if "$1" is empty? | 09:32 |
| xnox | yes. | 09:32 |
| alkisg | If it's "default" ? | 09:33 |
| xnox | no | 09:33 |
| alkisg | man Xsession | 09:33 |
| xnox | default should launch default. | 09:33 |
| alkisg | default | 09:33 |
| alkisg | produces the same behavior as if no session type argument had been given at all. | 09:33 |
| xnox | but default is not in /etc/upstart-xsessions.... | 09:33 |
| alkisg | 50x11-common_determine-startup | 09:33 |
| xnox | oh that's desktop_session, ignore that. | 09:33 |
| alkisg | sorry ./20x11-common_process-args | 09:33 |
| * xnox is confused how one would end up with DESKTOP_SESSION defined, yet without passing an argument. | 09:34 | |
| alkisg | One should be able to just launch Xsession and have it work, with the default gnome-session --session=ubuntu | 09:35 |
| alkisg | That was only broken now, in 14.04 | 09:35 |
| alkisg | And it will hopefully stop being broken in 16.04 with systemd | 09:35 |
| alkisg | So we're basically only talking about 14.04 now... | 09:35 |
| xnox | yeah, i need to pull 14.04 with latest updates to check. | 09:36 |
| xnox | in essence we try to make sure we never launch and override STARTUP by accident | 09:36 |
| xnox | thus we operate in whitelist mode only. | 09:36 |
| alkisg | If you prefer a patch inside 00upstart that essentially duplicates the work done by 50x11, ok, no problem | 09:36 |
| alkisg | xnox, upstart never uses STARTUP anyway | 09:36 |
| xnox | if DESTKOP_SESSION is correct and known to be upstart enabled | 09:37 |
| xnox | we expect an agument for the session-manager as well | 09:37 |
| alkisg | I'm just saying that if 50x11 does the work and sees that the user actually wants one of the upstart-supported sessions, then use the work of 50x11 | 09:37 |
| xnox | otherwise upstart session will be borked when launched in 99upstart | 09:37 |
| alkisg | Don't just check $1 | 09:37 |
| xnox | we cannot modify 50x11 at all. | 09:37 |
| alkisg | I'm not asking to | 09:37 |
| xnox | (to be upstart aware) | 09:37 |
| alkisg | I'm only asking the 2 changes I said, 00upstart to be renamed to 50x12-upstart, and BASESESSION=${1% *} to become BASESESSION=${STARTUP% *} inside it | 09:38 |
| xnox | no, we cannot do that. | 09:38 |
| xnox | we will loose any variables set between 00-50 | 09:38 |
| alkisg | There are none | 09:38 |
| xnox | which must be exported to upstart session. | 09:38 |
| alkisg | 50 determines the session | 09:38 |
| alkisg | You cannot set vars before the session is determined | 09:38 |
| alkisg | And, you don't | 09:39 |
| xnox | alkisg: sure there are! this is admin modifyable config scripts, and i'm sure admins have exported variables between 00-50 which they expect to be present for all sessions. | 09:39 |
| alkisg | No script sets vars based on 00upstart, until after 50x | 09:39 |
| xnox | 50x11 is not support in upstart user sessions | 09:39 |
| alkisg | The admin is wrong then | 09:39 |
| xnox | honestly show me your login manager, it looks broken. | 09:39 |
| alkisg | Because 50x is where the session is determined | 09:39 |
| xnox | because it suppose to parse | 09:39 |
| xnox | valid sessions from | 09:39 |
| xnox | one sec. | 09:39 |
| xnox | 50x is not where the session is determined, let me check this | 09:39 |
| alkisg | That's where the x-session-manager alternative is processed, where the user options are processed etc | 09:40 |
| alkisg | That's the central point (hence the 50 number) where the session is determined | 09:41 |
| xnox | so sessions in Ubuntu as a whole, that is all variants | 09:41 |
| xnox | are define din /usr/share/xsessions/ | 09:41 |
| xnox | as *.desktop files | 09:41 |
| alkisg | Yup | 09:41 |
| xnox | all login managers must process that | 09:41 |
| xnox | and launch as specified there. | 09:41 |
| alkisg | Suppose you're not using a login manager | 09:41 |
| xnox | and offer them to the user to choose from | 09:41 |
| alkisg | You just want to run Xsession | 09:41 |
| xnox | that's not supported | 09:41 |
| xnox | you must use a login manager in ubuntu | 09:42 |
| alkisg | It can be supported by that little change | 09:42 |
| xnox | or exec in a compatible way | 09:42 |
| xnox | no | 09:42 |
| alkisg | And it was supported until 14.04 | 09:42 |
| xnox | there are admins that drop 10foo in to Xsession.d | 09:42 |
| alkisg | (it was runniing, I mean) | 09:42 |
| xnox | and we want to support it. | 09:42 |
| xnox | i beleive 13.10 was were we stopped supporting that | 09:42 |
| alkisg | You want to support broken configurations but not just running Xsession? | 09:42 |
| xnox | when ehte upstart user ssions were started to be support. | 09:42 |
| xnox | you can run Xsession | 09:42 |
| xnox | but not managed by user upstart | 09:43 |
| xnox | to have user upstart managed xsession it must be launched properly as per /usr/share/xsessions and ideally by a login manager | 09:43 |
| xnox | if you don't want upstart, and plain xsession it will work. | 09:43 |
| xnox | but e.g. unity DE is no longer support in such combination, as a few desktop things started to depend on user upstart session to be available. | 09:44 |
| alkisg | Not all login managers do what you want | 09:44 |
| xnox | do you see what i mean? | 09:44 |
| alkisg | E.g. LDM doesn't do it | 09:44 |
| alkisg | So we have to fix it because you want to support a possible broken configuration of some sysadmin?> | 09:44 |
| xnox | if LDM doesn't parse /usr/share/xsessions and doesn't offer a user to launch xubuntu.desktop -> LDM is broken. Please open a bug against LDM package in Ubuntu. | 09:44 |
| alkisg | It does parse them | 09:44 |
| alkisg | And it launches them as mentioned in the Exec line | 09:45 |
| xnox | alkisg: and does it do "Exec=" as specified in them? | 09:45 |
| xnox | which should work then. | 09:45 |
| xnox | for unity. | 09:45 |
| alkisg | The problem is the "default" | 09:45 |
| alkisg | What is the default session? | 09:45 |
| xnox | i don't see a .desktop file with a default. | 09:45 |
| alkisg | Xsession says "it's called default" | 09:45 |
| xnox | in e.g. lightdm it has a setting what id default. | 09:45 |
| alkisg | So for ages LDM and other DMs are using that | 09:46 |
| xnox | if there is only one -> LDM should use that as default? | 09:46 |
| xnox | honestly i hear the first time about default.desktop | 09:46 |
| alkisg | If I find other DMs that use "default" or "empty", will it help in convincing you? | 09:46 |
| alkisg | E.g. SDM, XDM, nodm, whatever? | 09:46 |
| xnox | in Ubuntu we don't have default, as that's ambigious - on a Xubuntu build one only has /usr/share/xsessions/xubuntu.desktop | 09:47 |
| alkisg | I never mentioned default.desktop | 09:47 |
| xnox | we currently support a lot of xsessions. | 09:47 |
| alkisg | I'm talking about the default session, as documented by Xsession | 09:47 |
| xnox | please point me to ldm code which parses and execs /usr/share/xsession | 09:47 |
| alkisg | OK, moment | 09:47 |
| xnox | alkisg: note that unity is not the default xsession in Ubuntu =) | 09:47 |
| xnox | we dont' provide one. | 09:48 |
| alkisg | ubuntu is | 09:48 |
| xnox | can i run ldm locally, without having the rest of LTSP stuff? | 09:48 |
| xnox | (as in as a replacement for local lightdm?) | 09:49 |
| cjwatson | zyga,mvo: If you mean tarmac for git, I'm reasonably sure it still needs a couple of small LP changes | 09:49 |
| xnox | alkisg: send me ldm info and or links to xnox @ubuntu.com and i'll look into it. | 09:49 |
| xnox | got to go. | 09:49 |
| alkisg | xnox: it's not ldm specific | 09:49 |
| zyga | cjwatson: yes, what kind of changes are you thinking about? | 09:50 |
| alkisg | I can send you other DMs if you want... | 09:50 |
| alkisg | xnox, should I file a bug report so that we talk there? | 09:50 |
| xnox | alkisg: i need to see what ldm does, and check if it is sensible. | 09:50 |
| alkisg | Thanks a lot btw | 09:50 |
| zyga | ev: hey | 09:50 |
| xnox | alkisg: from what i can tell - supported login managers in ubuntu parse /usr/share/xsession/ubuntu.desktop correctly and launch it correctly. something is broken in LDM case. | 09:51 |
| zyga | ev: would you have a moment to talk about CI | 09:51 |
| xnox | either in parsing or launching or what not. | 09:51 |
| xnox | and fiddling with xsession.d seems like the wrong place to band-aid it. | 09:51 |
| alkisg | xnox, you can't use ldm locally, here's the relevant script: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/view/head:/rc.d/X50-dmrc-processing | 09:51 |
| alkisg | xnox: the problem started when *upstart* fiddled with Xsession.d | 09:52 |
| alkisg | That's what I'm trying to fix | 09:52 |
| cjwatson | zyga: It doesn't have quite enough API to be able to operate on merge proposals for a given repository; needs some thought about what to do with linked bugs, although I suppose that could be treated as optional for the time being | 09:52 |
| alkisg | It put 00upstart in the wrong place | 09:52 |
| alkisg | I.e. before the xsession is determined | 09:52 |
| zyga | cjwatson: yeah, I would treat that as optional for now, can you be more specific as to what is missing? | 09:52 |
| zyga | cjwatson: I wanted to creat a proof-of-concept merger for git on launchpad | 09:52 |
| alkisg | xnox: anyway, if you're willing to do that: | 09:52 |
| alkisg | (12:32:35 μμ) alkisg: Are you willing to do the same if "$1" is empty? | 09:52 |
| alkisg | (12:32:41 μμ) xnox: yes. | 09:52 |
| alkisg | LTSP is fine then | 09:52 |
| alkisg | Problem solved | 09:52 |
| zyga | cjwatson: so I need to query for merge proposals for a repository (I can do branch filtering locally) | 09:53 |
| cjwatson | zyga: git_repository.landing_candidates basically | 09:53 |
| xnox | alkisg: think of upstart user session as supper-set and replacement for xsession. it doesn't support all xsessions ever possible. | 09:53 |
| zyga | ah | 09:53 |
| zyga | cjwatson: so that's not exposed yet, I see | 09:53 |
| xnox | and thus it doesn't parse xsessions and bails out on unknown stuff. | 09:53 |
| alkisg | xnox: we're not looking for other xsessions | 09:53 |
| cjwatson | zyga: right, largely because the name is awful and we were trying to think of a better one | 09:53 |
| zyga | cjwatson: is that being worked on now? | 09:53 |
| zyga | :D | 09:53 |
| cjwatson | zyga: but maybe we should just give up and export the bzr-ish name | 09:53 |
| cjwatson | zyga: we want tarmac for Launchpad itself, so it's definitely on our radar :) | 09:53 |
| zyga | cjwatson: I think exporting any name now is good, I suspect both people that use it won't mind | 09:54 |
| alkisg | xnox: it only needs to support "default" and <empty>, as specified in the Xsession manpage | 09:54 |
| zyga | cjwatson: have you thought about the way tarmac uses zbr? | 09:54 |
| cjwatson | that's not quite how we deal with LP API compatibility | 09:54 |
| zyga | cjwatson: as a checkout, with lock held? | 09:54 |
| cjwatson | zyga: I don't much care, it clearly can't do that with git | 09:54 |
| zyga | cjwatson: do you have an idea on how to translate that to a full clone that doesn't have the lock | 09:54 |
| zyga | cjwatson: ok | 09:54 |
| alkisg | xnox: if you're willing to add support for <empty> in 00upstart, it's fine for ltsp. As a programmer I think it's wrong, but as LTSP upstream I don't mind | 09:54 |
| zyga | cjwatson: one more question, how do you talk to git from launchpad, any library to recommend? | 09:55 |
| cjwatson | zyga: presumably it can just try and fail if it tries to push a non-fast-forward thing | 09:55 |
| cjwatson | zyga: we use pygit2 | 09:55 |
| zyga | cjwatson: thanks | 09:55 |
| cjwatson | zyga: it's not entirely packaged in Ubuntu, but the bits we use are in the LP PPA | 09:55 |
| cjwatson | zyga: however, due to not being packaged, it might be better for tarmac just to call out to git | 09:55 |
| cjwatson | zyga: the pygit2 API isn't very stable | 09:55 |
| zyga | cjwatson: yeah, that is somewhat easier | 09:56 |
| cjwatson | zyga: it's not like calling out to git involves slow Python process startup, unlike bzr | 09:56 |
| xnox | alkisg: looking at what you posted default is LDM concept and it is suppose to "get_dmrc_key" Session... and if that is empty you bail.... | 09:56 |
| xnox | alkisg: which is a wrong thing to do. | 09:56 |
| xnox | alkisg: first you need to check which sessions you have available e.g. ls /usr/share/xsessions/*.desktop and populate that as list of availble options | 09:56 |
| xnox | (even over ssh) | 09:56 |
| zyga | cjwatson: can you ping me (or tell me where to look) for when the missing api lands to production/ | 09:56 |
| xnox | and if user didn't choose any, choose one of the available ones. | 09:57 |
| xnox | (e.g. no Session defined in .dmrc) | 09:57 |
| pitti | apw, infinity: do you plan to merge initramfs-tools this cycle? I'm particularly interested in the bits that mount /usr from the initramfs, as that's a rather major delta that we have right now | 09:57 |
| alkisg | xnox: if the user has something in his .dmrc, he's notified that it's a wrong selection before it falls back to the defaults | 09:57 |
| alkisg | That's done by Xsession since ages | 09:57 |
| alkisg | *something wrong | 09:57 |
| xnox | alkisg: and your defaults should be one of the options from /usr/share/xsessions for ubuntu | 09:57 |
| alkisg | xnox: if the user has specified a session? | 09:57 |
| alkisg | Why? | 09:57 |
| alkisg | Anyway, that's unrelated | 09:57 |
| cjwatson | zyga: also, tarmac's use of bzr with locks and such is really just a written-out version of what the bzr client does; I don't think it's using a bound branch, so the lock is purely local to tarmac | 09:58 |
| xnox | alkisg: if the user didn't specified any. | 09:58 |
| alkisg | The user gets notified that he has selected a non-existing session | 09:58 |
| alkisg | Ah then we just use '' | 09:58 |
| zyga | cjwatson: it actually is | 09:58 |
| xnox | alkisg: because on ubuntu all valid options for login manager are provided in /usr/share/xsessions only. | 09:58 |
| alkisg | I.e. we let xsession do its job | 09:58 |
| cjwatson | zyga: oh, well, shrug, same comment as above then | 09:58 |
| zyga | cjwatson: but anyway, that just won't carry over to git world | 09:58 |
| zyga | cjwatson: yeah | 09:58 |
| xnox | alkisg: and the you shouldnt' use '', you should bail =) | 09:58 |
| xnox | alkisg: you have nothing to login into. | 09:58 |
| alkisg | xnox: yes, and Xsession is smart enough to select the one that is at /etc/alternatives/x-session-manager | 09:58 |
| cjwatson | zyga: api> can do, just remembered that I also wanted to think about the way the source/target/prereq refs are exported on the branch_merge_proposal webservice object | 09:59 |
| alkisg | xnox: suppose you have 3 sessions in xsessions/ | 09:59 |
| alkisg | Which one does your DM login to? | 09:59 |
| alkisg | The one defined in alternatives | 09:59 |
| alkisg | That's what Xsession does as well | 09:59 |
| alkisg | Why is that an issue? | 09:59 |
| xnox | alkisg: it gives me a drop down to choose from in alpahbetical order by pretty name. | 09:59 |
| cjwatson | zyga: it's just about usable in principle by tarmac today but is a bit cumbersome, needs some thought | 09:59 |
| alkisg | xnox: and which entry is preselected? Alphabetically? | 09:59 |
| alkisg | No | 09:59 |
| alkisg | Check the lightdm code | 10:00 |
| xnox | alkisg: in lightdm greeter first one is pre-selected. | 10:00 |
| alkisg | Really?! | 10:00 |
| xnox | it's greeter specific, not lightdm core. | 10:00 |
| zyga | cjwatson: my tarmac and lp api is too rusty to have an opinion on that yet, I need to poke it a little ot offer insight | 10:00 |
| alkisg | What about lightdm-set-defaults previously, | 10:00 |
| xnox | other greeter can do UI logic differently | 10:00 |
| alkisg | and the lightdm.conf.d/users.conf now? | 10:00 |
| zyga | cjwatson: are you familiar with the github API? | 10:00 |
| zyga | cjwatson: can we learn something from that? | 10:00 |
| cjwatson | zyga: we've looked at it and borrowed inspiration where appropriate | 10:00 |
| xnox | it has config files to do specific things, e.g. on xubuntu builds we provide lgithdm setting to choose xubuntu as default. | 10:00 |
| cjwatson | zyga: you're not telling me anything new by pointing me at it, at least ;-) | 10:01 |
| xnox | because lightdm greeter behaves differently on ubuntu/xubuntu/lubuntu etc builds | 10:01 |
| cjwatson | zyga: but it's necessary to fit the API into Launchpad's model as well, so it can't just be translated directly | 10:01 |
| alkisg | xnox:lightdm provides this: [SeatDefaults] user-session=gnome-fallback | 10:01 |
| zyga | cjwatson: I didn't expect anything less :) | 10:01 |
| xnox | alkisg: to get upstart unity session you need to specify DESKTOP_SESSIOn | 10:01 |
| zyga | cjwatson: ok, I'll look at the current API and get back to you | 10:01 |
| Unit193 | Considering, there's at least unity-greeter and lightdm-gtk-greeter for defaults? | 10:02 |
| zyga | cjwatson: thanks! | 10:02 |
| xnox | alkisg: in the case user doesn't choose it, LDM doesn't do it. | 10:02 |
| alkisg | xnox: that's another issue, yes, otherwise it hangs | 10:02 |
| alkisg | It doesn't bail, it just hangs | 10:02 |
| xnox | alkisg: thus it is broken and doesn't laucnh ubuntu.desktop xsession correctly. | 10:02 |
| alkisg | But OK we can do that | 10:02 |
| === dupondje_ is now known as dupondje | ||
| cjwatson | zyga: sure. I'd been planning to look at tarmac myself on the grounds that I was expecting to have to evolve the webservice a bit in parallel with working on it, but don't mind a slightly shorter to-do list ;-) | 10:03 |
| alkisg | xnox: anyway, to sum up... are you williing to add support for empty parameter in 00upstart as you said? | 10:03 |
| zyga | cjwatson: one thing I'd like to do with tarmac is to rip it in half later so that one can build a good web UI on top | 10:03 |
| zyga | cjwatson: so that tarmac just runs somewhere in the back | 10:03 |
| zyga | cjwatson: and people have live visibility into it | 10:03 |
| cjwatson | I'll leave that up to you :) | 10:03 |
| xnox | alkisg: DESKTOP_SESSION must be set though. and with empty parameter i don't see how that would be supported. | 10:03 |
| alkisg | xnox: I'll push code to LDM to set DESKTOP_SESSION | 10:04 |
| zyga | cjwatson: as for tarmac and launchpad itself, what do you require to run tests? | 10:04 |
| cjwatson | from our point of view, well, right now what we have is pqm.launchpad.net which returns a mostly empty page unless it's actually in the process of merging something, practically anything would be an improvement | 10:04 |
| zyga | cjwatson: what does tarmac do for you? | 10:04 |
| zyga | (apart from merging) | 10:04 |
| cjwatson | zyga: nothing | 10:04 |
| alkisg | xnox: or, I can send you a patch that sets it in 00upstart if you prefer | 10:04 |
| zyga | cjwatson: it doesn't run tests? | 10:04 |
| cjwatson | zyga: right now we're just looking for a merge robot | 10:04 |
| alkisg | That ^ would be saner | 10:04 |
| cjwatson | zyga: we don't use tarmac today | 10:04 |
| zyga | cjwatson: ah, ok, thanks | 10:04 |
| xnox | alkisg: no. | 10:04 |
| cjwatson | zyga: our tests are run separately by buildbot, post-merge | 10:05 |
| alkisg | xnox: it would be best if we wouldn't have to rewrite all DMs to support the newest upstart scheme that will go away in 2 years... :-/ | 10:05 |
| xnox | alkisg: earlier you said DESKTOP_SESSION is set.... | 10:05 |
| cjwatson | zyga: (but pre-deployment) | 10:05 |
| alkisg | xnox: that's what I'm working on now | 10:05 |
| xnox | alkisg: DESKTOP_SESSION is a generic thing from freedesktop.org | 10:05 |
| alkisg | xnox: so in my tries since this morning, I have a patch that sets it | 10:05 |
| alkisg | OK, then I'll fix that in LDM | 10:05 |
| xnox | alkisg: .... so there is nothing for me to test. i'm out. | 10:05 |
| cjwatson | zyga: so we just need something where authenticated developers can send a merge instruction | 10:05 |
| alkisg | xnox: the empty one? | 10:06 |
| alkisg | Didn't you say you're willing to do that? | 10:06 |
| cjwatson | zyga: (right now, it's signed e-mail to pqm, we'd be open to sensible alternatives, preferably CLI) | 10:06 |
| cjwatson | zyga: but aiui tarmac just takes top-approved MPs? | 10:06 |
| alkisg | xnox: thanks a lot for your time, I'll file the bug against upstart and work around it from the LTSP code | 10:07 |
| zyga | cjwatson: it has some knobs to tweak, yeah but it looks at approved MRs in general | 10:07 |
| xnox | alkisg: the bug is in LDM, it should (a) parse desktop sessions (b) use freedesktop DESKTOP_SESSION | 10:07 |
| xnox | at the moment it does neither | 10:07 |
| alkisg | xnox: I patched (b) | 10:08 |
| alkisg | And it does (a) | 10:08 |
| zyga | cjwatson: you can define how voting works in a limited way | 10:08 |
| cjwatson | zyga: right, so that would probably be basically fine for us, as long as we can turn off any test running and such | 10:08 |
| alkisg | xnox: we do present a list to the user, it's in another script called ldminfod | 10:08 |
| xnox | alkisg: it doesn't do (a). | 10:08 |
| xnox | alkisg: it only ever parses "foo.desktop" if user asked for "foo" but how would a user know that? | 10:08 |
| alkisg | xnox: at that point in the script I sent you, the user has selected the combobox entry of ldm that ldminfod sent | 10:08 |
| alkisg | Let me give you the link to ldminfod... | 10:09 |
| alkisg | xnox: anyway please don't focus on ldm | 10:09 |
| alkisg | I'm wasting your time that way | 10:09 |
| alkisg | Please only mention that one thing: | 10:09 |
| zyga | cjwatson: yeah, tests are opt-in, nothing happens by default | 10:09 |
| alkisg | xnox: in 00upstart, if [ "$BASESESSION" = x-session-manager ]; then | 10:10 |
| alkisg | ==> are you willing to add a || -z $BASESESSION there? | 10:10 |
| cjwatson | zyga: we might need to tweak its policy a bit, but meh, it has plugins. I think the policy we probably want is "top-approved by a member of ~launchpad", which isn't something tarmac supports natively | 10:11 |
| cjwatson | zyga: or maybe "top-approved plus at least one Approve vote by a member of ~launchpad" | 10:12 |
| cjwatson | (latter probably more sensible) | 10:12 |
| xnox | alkisg: no | 10:12 |
| cjwatson | mind you, LP's own security on setting MPs to top-approved might be sufficient | 10:13 |
| alkisg | xnox: ok, thanks a lot for your time, I'll work around that bug in ltsp. | 10:13 |
| xnox | alkisg: parse all .desktop sessions, over user a choice, there is no choice "default" since there is no default.desktop file, execute it property with DESKTOP_SESSION set and Exec= line from the .desktop file, that's only way how each of the DEs support being started via xsession.d scripts in Ubuntu Project as a whole. | 10:14 |
| xnox | and elsewhere in other freedesktop compliant DEs and other login managers (e.g. gdm, mate, etc.) | 10:14 |
| xnox | ssdm and so on. | 10:14 |
| alkisg | xnox: you have misunderstood a *LOT* of what I said and what we do. It might be due to english not being my native language | 10:14 |
| alkisg | We do parse all .desktop sessions | 10:15 |
| alkisg | I've said it a lot of times, I don't know why you're still saying that we don't | 10:15 |
| alkisg | I never said that there's a "default" choice | 10:15 |
| xnox | .... yet still have default) case in the script you pointed me to, which should never be executed. | 10:15 |
| alkisg | I don't know why you're saying that | 10:15 |
| alkisg | I don't want to set the Exec line though | 10:15 |
| alkisg | It's against the standards | 10:15 |
| xnox | there is no /usr/share/xsessions/*.desktop file in ubuntu with empty Exec line | 10:16 |
| alkisg | I will put a script to work around the upstart bug, but not set the Exec line | 10:16 |
| alkisg | check man Xsession | 10:16 |
| xnox | yet you somehome "parse" them and provide empty "exec" line. | 10:16 |
| alkisg | LDM wants to support the default Xsession in the sense of xorg | 10:16 |
| xnox | alkisg: you suppose to get exec line from .desktop file. | 10:16 |
| alkisg | Not in the sense of xnox | 10:17 |
| alkisg | No | 10:17 |
| alkisg | I'm not supposed to do that unless the user specified that | 10:17 |
| xnox | alkisg: in the sense of xorg, there is no such sessions in ubuntu. We moved on to freedesktop specs from xorg. | 10:17 |
| alkisg | Either from a menu, or from a config file | 10:17 |
| xnox | alkisg: keep up with recent times. | 10:17 |
| alkisg | For one -z line? | 10:17 |
| alkisg | That's why we're arguing for 1 hour... | 10:17 |
| alkisg | You can support running plain xsession with one -z | 10:18 |
| alkisg | And you don't want that | 10:18 |
| alkisg | OK, I don't mind | 10:18 |
| alkisg | But I do want to support it in ltsp | 10:18 |
| * alkisg is sad because he appreciates xnox a lot... hopefully he knows that :-/ | 10:22 | |
| === alkisg is now known as work_alkisg | ||
| pitti | cjwatson, apw, Laney, utlemming, etc.: debootstrapping wily is fixed now, FTR | 10:50 |
| cjwatson | Thanks | 10:50 |
| Laney | good stuff | 10:50 |
| pitti | cjwatson: I added a gross hack to /usr/share/debootstrap/functions to use local .debs | 10:50 |
| pitti | I wonder why after all these years the debootstrap maintainers never needed that ;) | 10:51 |
| cjwatson | Probably everyone just did the same local hack when they did and never worked out how to productionify it | 10:51 |
| highvoltage | is it new that the ubuntu image builders do an upgrade instead of building the image from scratch? (was just surprised looking at today's build failure but I've also admittedly not kept track for the last release) | 10:52 |
| cjwatson | They don't | 10:52 |
| cjwatson | I mean, there's probably an upgrade in there due to live-build, but it's incidental | 10:53 |
| highvoltage | yeah in today's failed build it was... | 10:53 |
| highvoltage | 63 upgraded, 12 newly installed, 0 to remove and 0 not upgraded. | 10:53 |
| cjwatson | highvoltage: That's just upgrading the buildd base image | 10:54 |
| highvoltage | but good to know that it's just incidental | 10:54 |
| cjwatson | highvoltage: It doesn't relate to the output live image | 10:54 |
| cjwatson | highvoltage: You can see further down that there's still a debootstrap | 10:55 |
| rbasak | slangasek: with your unixodbc maintainer hat on, please could you take a look at bug 1319701? In particular, I'm not sure your changelog message in bug comment #7 is true based on what upstream are saying in #5. | 10:56 |
| ubottu | bug 1319701 in php5 (Ubuntu) "ODBC apps different SQLLEN sizes linked against same DM" [Undecided,Confirmed] https://launchpad.net/bugs/1319701 | 10:56 |
| === oSoMoN__ is now known as oSoMoN | ||
| strikov | I'm trying to install udev-dbgsym on trusty and this operation fails because udev 204-5ubuntu20.11 is available in -updates but only udev-dbgsym 204-5ubuntu20 (without .11 at the end) is available in ddebs. Is it expected? More details: http://pastebin.ubuntu.com/11243234/ | 11:31 |
| strikov | rbasak: Hi! Do you any thought on ^^^ | 11:32 |
| strikov | * Do you have any thoughts on ^^^ | 11:32 |
| cjwatson | strikov: The ddeb publishing mechanism was inherently unreliable for all builds that happened up to the end of last month. | 11:39 |
| cjwatson | strikov: As of the end of last month, they're stored in Launchpad and we won't lose them; but if a ddeb built before that isn't on ddebs.ubuntu.com, it's lost. | 11:39 |
| strikov | cjwatson: I see, thanks. So that's somewhat expected. | 11:40 |
| cjwatson | It's not surprising, at least. | 11:41 |
| rbasak | Thanks cjwatson. strikov: I didn't know anything about this really. Do you need any help from me? If you're doing what I think you're doing, can you rebuild systemd locally, update a cloud image locally with that build and then use the ddeb you produced locally if that reproduces the issue? | 11:43 |
| strikov | rbasak: I think I'm fine. I wanted to know which ID_PATH has been generated for virtio devices before udev guys disabled this functionality. I finally found this value on precise. I wanted to do some gdbing on trusty but not it's not really needed. Thanks anyway! | 11:46 |
| strikov | rbasak: ID_PATH looks like pci-0000:00:04.0-virtio-pci-virtio2 and helps you to identify the specific device in udev rule | 11:47 |
| rbasak | I see. Makes sense. | 11:48 |
| strikov | rbasak: Unfortunately this ID_PATH is not generated for virtio devices anymore. Point behind this decision is that order of virtio devices can be randomly shuffled on vm reboot hence we can't rely on ID_PATH value | 11:50 |
| mgedmin | which package is responsible for creating /root/.profile? | 12:09 |
| mgedmin | because https://bugs.launchpad.net/ubuntu/+source/xen-3.1/+bug/1167281 clearly shouldn't be assigned to xen | 12:09 |
| ubottu | Ubuntu bug 1167281 in xen-3.1 (Ubuntu) ""stdin: is not a tty" due to "mesg n" instead of "tty -s && mesg n" in .profile" [Undecided,Confirmed] | 12:09 |
| ogra_ | pitti, did we forget to switch the anacron cron.d job to systemd ? https://lists.ubuntu.com/archives/ubuntu-users/2015-May/280909.html | 12:11 |
| === _salem is now known as salem_ | ||
| === dbarth_ is now known as dbarth | ||
| tjaalton | Loaded: loaded (/lib/systemd/system/anacron.service; enabled; vendor preset: enabled) | 12:30 |
| tjaalton | works fine for me | 12:30 |
| seb128 | mardy, thanks for looking at that fb integration issue! | 12:33 |
| pitti | ogra_: the .service is there (as tjaalton said), there might be this "start -q anacron" somewhere still, though | 12:33 |
| pitti | not in /etc/cron.d/anacron, that uses invoke-rc.d | 12:34 |
| ogra_ | i wonder how the user got to that state then | 12:34 |
| ogra_ | seems he has the old /etc/cron.d/anacron ... | 12:34 |
| pitti | ah, the joys of old conffiles | 12:37 |
| mardy | seb128: yw! | 12:49 |
| mardy | seb128: I also commented here: https://bugzilla.gnome.org/show_bug.cgi?id=748991 | 13:01 |
| ubottu | Gnome bug 748991 in web-sharing "Error to publish on Facebook" [Major,New] | 13:01 |
| geser | pitti: do you have an idea why https://launchpadlibrarian.net/205906374/buildlog_ubuntu-wily-amd64.cpl-plugin-amber_4.3.3%2Bdfsg-2_BUILDING.txt.gz failed during building the ddebs? does the package something wrong? (some more cpl-plugin-* fail with the same error) | 13:03 |
| seb128 | mardy, thanks | 13:04 |
| pitti | geser: not off-hand; building locally | 13:12 |
| pitti | geser: would you mind filing a bug against pkg-create-dbgsym for now? sounds like another special case with this funny override_dh_gencontrol-indep | 13:18 |
| geser | pitti: done; bug #1457038 | 13:23 |
| ubottu | bug 1457038 in pkg-create-dbgsym (Ubuntu) "Builing the -dbgsym packages for cpl-plugin-* fails" [Undecided,New] https://launchpad.net/bugs/1457038 | 13:23 |
| pitti | geser: thanks | 13:23 |
| micahg | Laney: yep, trying to move some things along | 13:29 |
| === work_alkisg is now known as alkisg | ||
| slangasek | rbasak: Debian and Ubuntu were always using a 64-bit SQLLEN on 64-bit archs despite this not being the upstream ABI, because the upstream ABI was broken and there was no reason to keep compatibility with it | 14:03 |
| rbasak | slangasek: I see, thanks. | 14:08 |
| rbasak | slangasek: I don't really follow this bug at all though :( | 14:08 |
| rbasak | Anyway, I guess it's not that important in the grand scheme of things. | 14:09 |
| === oSoMoN__ is now known as oSoMoN | ||
| pitti | rbasak: ok, the mystery in bug 1450053 just became a lot smaller :) | 15:13 |
| ubottu | bug 1450053 in mysql-5.6 (Ubuntu) "upgrade 14.04 to 15.04, mysql no longer starts on boot due to missing policykit-1" [High,Incomplete] https://launchpad.net/bugs/1450053 | 15:13 |
| slangasek | rbasak: what is "PDO ODBC"? | 15:16 |
| slangasek | oh that php odbc nonsense | 15:17 |
| slangasek | yeah so I don't know how that package was built to get 32-bit SQLLEN, but it's not unixodbc's fault ;) | 15:18 |
| rbasak | Yeah. PHP ships two separate modules. odbc.so, and pdo_odbc.so. | 15:18 |
| rbasak | I presume two different APIs or something from the perspective of a PHP user. Not really sure. | 15:18 |
| rbasak | pitti: I'm still a little confused as to how that happened. mysql-5.6 in Trusty and Utopic is SysV only I think. | 15:20 |
| pitti | rbasak: perhaps he has -5.5 installed? that's the most plausible explanation so far | 15:25 |
| rbasak | I guess. It should have got upgraded though. | 15:26 |
| === matsubara_ is now known as matsubara | ||
| micahg | hi pitti, you seem to be TIL on libgphoto2, was this a merge you were planning on doing? There's at least one thing in dependency wait for it | 15:31 |
| pitti | micahg: ah, can do; queueing for tomorrow | 15:32 |
| micahg | great, thanks | 15:32 |
| === salem_ is now known as _salem | ||
| pitti | rbasak: ah, mariadb :) | 15:38 |
| === _salem is now known as salem_ | ||
| === oSoMoN_ is now known as oSoMoN | ||
| rbasak | pitti: ah. Thank you for working that bug. | 16:31 |
| === alkisg is now known as work_alkisg | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === utlemming is now known as utlemming_away | ||
| === utlemming_away is now known as utlemming | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!