| Riddell | cjwatson: mitya57: we don't even use debconf's perlqt frontend in kubuntu, we use debconf-kde which is a c++ library so I expect it can be dropped | 00:00 |
|---|---|---|
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| RAOF | Hm. Who's familiar with the seeds/germinate process? I need to know why mir-client-platform-mesa is being pulled in to the vivid touch image, and how to stop it. | 00:22 |
| mdeslaur | ROAF: because it's a reverse-depends of libmirclient8 perhaps? | 00:39 |
| RAOF | mdeslaur: It's an alternative rdepends of libmirclient8, yes. | 00:44 |
| RAOF | But mir-client-platform-android is explicitly seeded, and satisfies that alternative. | 00:45 |
| mdeslaur | RAOF: hrm, not sure then. perhaps infinity would know | 01:05 |
| infinity | RAOF: It's almost certainly because of the alternate dep, and could just need a blacklist. | 01:26 |
| infinity | RAOF: Germinate's not always bright in the face of alternate deps. | 01:27 |
| RAOF | Ah. | 01:27 |
| RAOF | Let me see if I can work out how to do that... | 01:28 |
| infinity | RAOF: To be fair, situations that call for blacklists usually mean your deps are wrong, but I can see how this is a curious special case, since you want two different defaults. | 01:28 |
| RAOF | An alternative would be to *not* depend on a driver module at all for libmirclient8. | 01:28 |
| infinity | Which is possibly also correct. | 01:29 |
| RAOF | That would probably be reasonable. | 01:29 |
| infinity | Unless it needs it to load. | 01:29 |
| RAOF | Well... it's not *linked* to the driver module, but it'll fail as soon as you try to do anything with it. | 01:29 |
| RAOF | But that's a solution that doesn't require me to try and work out how germinate works again, so... :) | 01:30 |
| infinity | RAOF: Decoupling it is probably the right thing anyway. | 01:30 |
| infinity | RAOF: Since the android/gnu thing really needs to *stop* being how we define "touch" and "not". | 01:31 |
| RAOF | Heh, yes. | 01:31 |
| infinity | RAOF: That all needs to be defined in hardware support packs that just drop the right bits in place, and userspace should opprtunistically use the right bits as it discovers them. | 01:32 |
| infinity | RAOF: Otherwise, any hope for convergence is a bit of a joke, IMO. | 01:32 |
| infinity | RAOF: Or any hope for touch devices with free driver stacks. :P | 01:32 |
| RAOF | We've *very nearly* landed the necessary bits in Mir to do that, yes. | 01:37 |
| RAOF | (This has been apparent for a while ☺) | 01:37 |
| lamont | Unpacking python-oslo-config (1:1.6.0-0ubuntu1) ... | 03:00 |
| lamont | dpkg: error processing archive /var/cache/apt/archives/python-oslo-config_1%3a1.6.0-0ubuntu1_all.deb (--unpack): | 03:00 |
| lamont | trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1 | 03:01 |
| lamont | I wonder if that is already known | 03:01 |
| infinity | lamont: Sounds like some missing Breaks/Replaces. Report and/or pester jamespage and/or fix it yourself cause you're still a core-dev? :) | 03:26 |
| infinity | lamont: Oh, already reported as LP: #1410727 | 03:27 |
| ubottu | Launchpad bug 1410727 in oslo-config (Ubuntu) "package python-oslo-config (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python2.7/dist-packages/oslo/config/cfg.py', which is also in package python-oslo.config 1:1.5.0-0ubuntu1" [High,Confirmed] https://launchpad.net/bugs/1410727 | 03:27 |
| infinity | jamespage: ^ | 03:29 |
| pitti | Good morning | 04:54 |
| ScottK | mitya57: I don't know. | 05:48 |
| pitti | slangasek: any preference for today's EU/US sprint handover hangout? | 06:35 |
| slangasek | pitti: preference - do you mean for time? | 06:36 |
| pitti | slangasek: oh, nevermind, I just saw the cal entry | 06:36 |
| slangasek | my /preference/ is to have it quite a bit later than I actually scheduled it ;) | 06:36 |
| pitti | (I didn't get a mail notification for it, weird) | 06:36 |
| pitti | slangasek: I have a meeting 17:00 to 18:00 UTC, anything before and the hour after would WFM | 06:37 |
| slangasek | pitti: would an hour later work, maybe? | 06:40 |
| slangasek | that's more realistic considering I'm still awake | 06:40 |
| pitti | slangasek: yes, even two hours | 06:40 |
| slangasek | pitti: two hours later runs into other conflicts | 06:41 |
| pitti | slangasek: not three hours (as that overlaps with my other meeting), but four works again | 06:41 |
| doko_ | hangover hangout? | 06:43 |
| === doko_ is now known as doko | ||
| pitti | did I actually write.. | 06:43 |
| pitti | no :) | 06:43 |
| pitti | doko: today is the handover; tomorrow (at Friday evening) is the hangover :) | 06:44 |
| pitti | slangasek: time added to the pad | 06:45 |
| * pitti invites jamespage | 06:46 | |
| pitti | cjwatson, slangasek, xnox: who maintains ubiquity these days? If we work review based, I'd appreciate a look at https://code.launchpad.net/~pitti/ubiquity/systemd/+merge/246535 | 07:11 |
| pitti | I believe I tested it sufficiently, but more eyes can't hurt | 07:11 |
| pitti | slangasek: do you want to tackle bug 1312976 for the sprint? you said you wanted to rearrange the init.d scripts as well, do that in Debian, etc. | 07:16 |
| ubottu | bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976 | 07:16 |
| pitti | slangasek: apparently upstream also has native systemd jobs (I've seen some patches fly by via CC: systemd-devel@), so maybe we can just use those | 07:49 |
| pitti | didrocks: ah, having a look at some touch ones? | 08:05 |
| pitti | I got some easy ones without android deps this week; for the others we should probably wait for xnox to wake up? | 08:05 |
| pitti | well, some of those might still be simple | 08:06 |
| didrocks | pitti: I'm currently on the edubuntu one, but I think we should start with the android config one first and try to understand how that exactly works | 08:06 |
| didrocks | pitti: it contains a lot of upstart jobs, maybe we should do Touch once all the others are done? | 08:07 |
| didrocks | and do a real iterative work on it | 08:07 |
| pitti | didrocks: I don't have a good feeling about how much work it is TBH | 08:07 |
| pitti | I'm not very familiar with the phone booting | 08:08 |
| didrocks | pitti: I think it would be better to directly Do The Right Thing and revisit(Tm) | 08:08 |
| didrocks | pitti: but TBH, seeing how close rtm is on rebasing on vivid from what I heard, I doubt they will move to systemd this cycle, still doesn't stop us of doing the work | 08:08 |
| didrocks | but my gut feeling is it would be less work to really understand the dependencies and directly optimize it | 08:09 |
| didrocks | wdyt? | 08:09 |
| pitti | not sure what you mean with DTRT? you mean stop listening to android events? | 08:09 |
| pitti | I don't think we can do that anytime soon | 08:09 |
| pitti | maybe for special cases like MTP (as I hinted in my reply to xnox), but I haven't investigated that really | 08:10 |
| didrocks | pitti: it seems to me that there are a lot of jobs that are just events in the middle or specific for one device | 08:10 |
| didrocks | pitti: I'm pretty sure some cruft piled up over time | 08:10 |
| pitti | oh, for sure | 08:12 |
| dholbach | good morning | 08:22 |
| mardy | seb128: hi! Does the session-migration stuff work on Ubuntu touch? | 08:31 |
| tseliot | doko: hi, are we going to switch to gcc 5.0 in 15.04? | 08:33 |
| didrocks | mardy: it does run, yeah | 08:33 |
| pitti | didrocks: please remove from the pad when the package moves to vivid; please keep it as long as it's in -proposed still | 08:33 |
| pitti | didrocks: we've had several packages getting stuck | 08:33 |
| mardy | didrocks: cool, thanks! | 08:33 |
| didrocks | pitti: ok, got it | 08:33 |
| didrocks | mardy: yw ;) | 08:33 |
| didrocks | mardy: if you have never used it, some hints: http://blog.didrocks.fr/post/Announcing-session-migration-now-in-ubuntu | 08:34 |
| didrocks | mardy: or ask me for the dh_migration usage if needed | 08:35 |
| mardy | didrocks: IIRC I've used it once, long time ago; but I'll certainly ask, if in doubt :-) thanks :-) | 08:35 |
| didrocks | no worry ;) | 08:35 |
| seb128 | mardy, hey, what didrocks said | 08:38 |
| kickinz1 | o/ | 08:38 |
| mardy | seb128, didrocks: LOL, sorry, I just realized that I mixed you guys up -- must be because of your Frenchness ;-) | 08:38 |
| didrocks | mardy: sure sure, "all the same" :p | 08:40 |
| mardy | ;-) | 08:40 |
| LocutusOfBorg1 | hi developerz! | 08:56 |
| darkxst | pitti, what locale gets used during package build tests? and is it the same on debian? | 09:34 |
| pitti | darkxst: C.UTF-8 usually | 09:34 |
| pitti | darkxst: and yes, it should be the same everywhere | 09:35 |
| darkxst | pitti, tracker tests fail on debian, but not ubuntu | 09:35 |
| darkxst | martyn thinks its sorting issue due to locale's | 09:36 |
| pitti | darkxst: oh, wait, during *package build* | 09:36 |
| pitti | darkxst: I thought autopkgtest, sorry | 09:36 |
| pitti | darkxst: so, should be C for both D and U | 09:36 |
| darkxst | pitti, actually I meant autopkgtest | 09:36 |
| pitti | darkxst: ah; Debian runs in a simple schroot, Ubuntu in qemu; that might explain it | 09:36 |
| darkxst | pitti, I can reproduce the debian failures just running adt tests locally in a debian vm | 09:38 |
| === greyback__ is now known as greyback | ||
| mitya57 | Riddell, I think I will keep it as it will be less delta than dropping it :) | 09:51 |
| mitya57 | Oooh, I just realized that libqtgui4-perl is used not only when generating .pm file, but when actually drawing the interface, too. | 09:57 |
| cjwatson | infinity: blacklists are not only normally a sign of wrong dependencies, but normally flat-out don't work for what people try to use them for :-) | 09:59 |
| cjwatson | pitti: I see xnox is reviewing, so I'll leave it to him. I don't immediately see anything wrong ... | 10:02 |
| pitti | cjwatson: thanks | 10:03 |
| xnox | morning =) | 10:05 |
| pitti | hey xnox, wie gehts? | 10:08 |
| xnox | pitti: sehr gut, danke schon ;-) | 10:10 |
| pitti | xnox: ah, while I do see the oem-config debconf page, I can't actually do anything there | 10:21 |
| pitti | doesn't react to any keypresses | 10:21 |
| pitti | xnox: that might be because its running in an upstart job which get their own PTY as stdin/out/err? | 10:21 |
| xnox | pitti: yes. | 10:26 |
| xnox | "console output" in upstart speak, in systemd there are Stdin= Stdout= stanzas or some such, no? | 10:27 |
| pitti | xnox: there are TTY* options; usually units don't have any tty/pty at all, their stdout/err goes to the journal | 10:28 |
| pitti | xnox: I updated the MP | 10:28 |
| pitti | (comments, not code yet) | 10:28 |
| pitti | xnox: or perhaps under upstart it collides with getty1 somehow? | 10:29 |
| pitti | xnox: anyway, I won't put a lot of effort into debugging this under upstart now :) | 10:29 |
| xnox | pitti: well, console output means that "/dev/console" is being opened with O_RDWR | O_NOCTTY | 10:31 |
| xnox | in upstart. | 10:31 |
| xnox | pitti: StandardIntput=tty, StandardOutput=tty for oem-config job? for both oem-config & oem-config-debconf jobs. | 10:34 |
| xnox | .... sorry "units". jobs in systemd are state transitions | 10:34 |
| pitti | xnox: yep, I'm testing that ATM | 10:38 |
| pitti | xnox: sorry, doing three things at once | 10:39 |
| pitti | TTYVHangup=yes too, I think | 10:39 |
| pitti | and TTYReset=yes also couldn't hurt | 10:39 |
| pitti | OK, I have a clean test VM again; my previous try purged oem-config, so using -snapshot now :) | 10:40 |
| xnox | pitti: yes, it likes to purge itself. | 10:40 |
| pitti | jamespage: do you know if someone is looking at manila? | 10:42 |
| jamespage | pitti, noone yet | 10:42 |
| === _salem is now known as salem_ | ||
| jamespage | pitti, I was going to take a look after my meeting finishes | 10:42 |
| jamespage | pitti, kickinz1 is looking at maas | 10:42 |
| pitti | xnox: hah, now I have a systemd unit which behaves in the exact same way -- I see debconf, but dead keyboard :) | 10:49 |
| xnox | pitti: ship it, it's no regression parity =) | 10:50 |
| pitti | xnox: I wonder if that's a qemu quirk or so | 10:50 |
| pitti | xnox: Bazinga! | 10:52 |
| pitti | xnox: ok, all hunky-dory now; I updated the MP | 11:02 |
| * pitti goes back to isc-dhcp and its umpteen jobs | 11:05 | |
| doko | tseliot, no | 11:05 |
| === kickinz1 is now known as kickinz1|afk | ||
| jhenke | hi, are there any plans for updating boost in the v cycle? currently in archive are 1.54 and 1.55, but upstream released 1.57 in november 2014 | 11:41 |
| tseliot | doko: ok, thanks | 11:42 |
| pitti | xnox: do you want to re-review the ubiquity MP, or are you happy with it? | 12:03 |
| xnox | pitti: i have not looked at your recent commits. | 12:04 |
| xnox | pitti: in general i'm happy with it. | 12:04 |
| * pitti is very sure to not have broken upstart mode, so we might just upload it now to ease testing tremendously | 12:04 | |
| xnox | pitti: do you know how to merge & release ubiquity the right way, or shall I do it? | 12:04 |
| pitti | jamespage: yay you | 12:05 |
| jamespage | pitti, that was a package in need of some love | 12:05 |
| pitti | xnox: well, for merging I'd just push my commits to trunk (looks cleaner than merge IMHO) | 12:05 |
| pitti | xnox: as for releasing, is it more than just bzr bd -S? that already does a lot of magic like downloading packages etc. | 12:06 |
| xnox | pitti: yes, bzr bd -S should do the right thing. | 12:06 |
| pitti | xnox: at least it's now I built my local test debs | 12:06 |
| pitti | xnox: that doesn't do the "Automatic update of source packages..." thing, though | 12:06 |
| pitti | I suppose there's a script for that? | 12:06 |
| xnox | pitti: ./debian/rules update; debcommit; bzr bd -S | 12:06 |
| xnox | pitti: bzr bd -S -> does update-local which will bail the build if out of date. | 12:07 |
| pitti | xnox: ok, I'll do that | 12:07 |
| pitti | xnox: ah, nothing new apparently; well, last update was just a week ago | 12:08 |
| xnox | cool. | 12:08 |
| pitti | xnox: ack, then I'll upload, and ask some cdimage folks in the afternoon to get us a new live image | 12:08 |
| pitti | xnox: thanks | 12:08 |
| pitti | xnox: argh, can't push, EPERM -- can you pull from my branch and push, please? | 12:09 |
| pitti | (or merge if you prefer) | 12:09 |
| cjwatson | I generally use debuild -S rather than bzr bd -S | 12:09 |
| cjwatson | which is not to say the latter won't work | 12:09 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | it's become a habit of mine | 12:09 |
| xnox | pitti: i think i can grant you permissions. | 12:09 |
| cjwatson | but it saves effectively re-running the d-i update bits | 12:09 |
| xnox | cjwatson: i added bzr bd -S magic, because you called me out on having unclean stuff in the ubiquity upload debdiffs =)))))) | 12:10 |
| xnox | pitti: you have permisssions now. | 12:10 |
| xnox | pitti: also spam =) | 12:11 |
| pitti | I was afraid of that :) | 12:11 |
| xnox | ev: i have successfully passed the batton to pitti. | 12:13 |
| xnox | \o/ | 12:13 |
| xnox | pitti: congrats on being the new maintainer of ubiquity =) | 12:13 |
| * pitti runs away screaming -- err, to have some lunch | 12:13 | |
| cjwatson | xnox: well. mostly I called you out for not reading the debdiffs before upload :) | 12:14 |
| cjwatson | but ok | 12:15 |
| jamespage | pitti, re the zentyal packages; i've pinged the upstream developers who are mean't to maintain those packages; basically if they don't want to update, I suggest we remove zentyal from the archive | 12:16 |
| jamespage | its not been touched for over two years now so is vastly out-of-date | 12:17 |
| pitti | jamespage: ah right, and not in Debian either; no objection to cleaning them up if they don't reply or don't want to indeed | 12:17 |
| xnox | jamespage: pitti: zentyal would be broken / dangerous if we switch to systemd by default. | 12:19 |
| xnox | for pid 1. | 12:19 |
| jamespage | xnox, indeed | 12:19 |
| xnox | also would be nice to remove system-config-* bits. | 12:20 |
| pitti | oh, that's the "new" name for ebox | 12:21 |
| pitti | xnox: dangerous because they are very upstart specific and the web frontend etc. only configures that? | 12:21 |
| xnox | pitti: yes. | 12:22 |
| xnox | pitti: not sure where the upstream stand at, but they did claim way back when that they will maintain it in ubuntu. | 12:22 |
| jamespage | xnox, that's not happened so much | 12:28 |
| jamespage | xnox, they have ppu rights for zentyal | 12:28 |
| === kickinz1|afk is now known as kickinz1 | ||
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | tseliot: do you have some minutes to help me understand the nvidia-prime upstart job? for bug 1312255 | 13:25 |
| ubottu | bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255 | 13:25 |
| pitti | tseliot: I'm fine with porting it if you don't have time, but the upstart job looks a bit weird | 13:25 |
| pitti | is anyone looking for a really easy upstart → systemd porting to learn about it? ltsp-cluster-{accountmanager,lbagent} are simple | 13:40 |
| didrocks | apw: hey, I see you are conmux's upstream, does this package makes sense under systemd or should it be replaced with manually instanced serial-getty? | 13:41 |
| apw | didrocks, it does something other that that which getty does, i can add system startups if that is needed | 13:42 |
| apw | systemd | 13:43 |
| didrocks | apw: I have some spare cycles to do it now, seems quite a nice one with instantiated services. Just wanted to know if you feel it worthed it | 13:43 |
| pitti | jamespage, xnox: https://github.com/Zentyal/zentyal seems to be quite active though; it just seems they stopped uploading to Ubuntu; maybe people are supposed to use their own archive now | 13:43 |
| didrocks | apw: so, it seems that indeed, it does make sense, so doing it | 13:43 |
| didrocks | pitti: FYI ^ | 13:43 |
| apw | didrocks, ahh, do indeed, but who knows how much use it gets these days | 13:44 |
| pitti | apw, didrocks: also see Debian bug 775185 | 13:44 |
| ubottu | Debian bug 775185 in conmux "conmux: has only upstart job, no upstart dependency" [Normal,Open] http://bugs.debian.org/775185 | 13:44 |
| didrocks | apw: mind answering on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775185? | 13:44 |
| pitti | would make sense to upload it there too | 13:44 |
| didrocks | pitti: I'll attach a debdiff to it | 13:44 |
| pitti | apw: including a systemd unit upstream would be nice indeed | 13:44 |
| rbasak | pitti: we just had a conversation in #ubuntu-server about Zentyal. Conclusion is to remove it from Vivid. | 13:44 |
| pitti | hey rbasak | 13:45 |
| rbasak | pitti: in favour of their own repository, yes. | 13:45 |
| rbasak | pitti: o/ | 13:45 |
| pitti | rbasak: ack, sounds good; I'll clean them up then | 13:45 |
| rbasak | Thanks! | 13:45 |
| didrocks | pitti: ah, you referenced the bug in the pad, funny, I was looking at conmux's bug to see if a patch was already attached were I saw we were in sync :) | 13:46 |
| pitti | didrocks: yeah, that's a curious case -- must be the only upstart-only package in Debian :) | 13:46 |
| pitti | (and undeclared on top of that) | 13:46 |
| didrocks | pitti: yeah, we found it! :) the package was in ubuntu first and just uploaded in debian as-is | 13:47 |
| didrocks | pitti: that means though, they will have the same postrm and so on issue once switch to systemd on that package as they don't have our patch | 13:48 |
| didrocks | (in invoke-rc.d) | 13:48 |
| pitti | jamespage, rbasak: zentyal> *flush* | 13:50 |
| pitti | ok, I'll grab the ltsp-cluster-* ones now; might just as well get it over with | 13:53 |
| jamespage | pitti, rbasak: yes indeed | 13:55 |
| jamespage | pitti, I'd flush all of them | 13:55 |
| pitti | jamespage: yes, that's what I did (not just those on the pad) | 13:55 |
| pitti | $ remove-package -m 'unmaintained in Ubuntu for 2 years, upstream has their own repository' zentyal-ca zentyal-dhcp zentyal-dns zentyal-firewall zentyal-network zentyal-ntp zentyal-objects zentyal-openvpn zentyal-printers zentyal-services zentyal-users zbuildtools zentyal-common zentyal-samba zentyal-squid | 13:55 |
| jamespage | pitti, thanks | 13:55 |
| pitti | I checked reverse-depends | 13:55 |
| didrocks | pitti: do you know if it's possible to start some instances of a template service from another one (rather than running systemctl start fooservice@barinstance)? | 14:00 |
| pitti | didrocks: Requires=otherinstance@%I.service ? | 14:03 |
| didrocks | pitti: well, the instance name is dynamically generate, though more from a script | 14:04 |
| didrocks | pitti: maybe a generator would be the best solution, but I feel that being a little bit overkill for conmux | 14:05 |
| pitti | didrocks: uh, a template template? | 14:05 |
| pitti | didrocks: how dynamic? you can also create .d dirs in /run/systemd/system/ with the extra Requires, but I suppose that needs some daemon-reload | 14:06 |
| === seb128_ is now known as seb128 | ||
| didrocks | pitti: basically, there is 'for filename in dir -> start conmux-daemon@filename' | 14:07 |
| pitti | didrocks: ah -- well, that does sound like a generator | 14:07 |
| didrocks | until now, it was conmux.upstart doing that (after starting the main server) | 14:07 |
| didrocks | yeah, ok, let's go for a simple generator then | 14:07 |
| tseliot | pitti: what is it that's not clear about nvidia-prime.upstart? | 14:07 |
| pitti | didrocks: /bin/dash FTW :) | 14:08 |
| didrocks | pitti: not a bin fan in term of perf as it impacts boot time, but well :) | 14:08 |
| pitti | didrocks: well, *shrug*, the upstart job was also a script, so not really a regression? | 14:08 |
| didrocks | pitti: true :) and so, creating some conmux.d/ -> Requires | 14:09 |
| didrocks | on all those instance | 14:09 |
| didrocks | sounds sane? | 14:09 |
| pitti | tseliot: it seems it only starts start-nvidia-persistenced if prime is *not* supported | 14:09 |
| pitti | didrocks: yes | 14:09 |
| pitti | didrocks: and TBH, as long as a script uses only builtins and doesn't call grep and other external programs a lot, it should be fine | 14:10 |
| didrocks | pitti: yeah, it's really rudimentary | 14:10 |
| pitti | one can do a lot with POSIX sh already, and bash is even more powerful :) | 14:10 |
| pitti | ok, [ "${haystack%needle*}" != "$haystack" ] isn't exactly easy to read, but much cheaper than a grep | 14:11 |
| tseliot | pitti: we can probably get rid of that, as we start and stop nvidia-persistenced with a udev rule /lib/udev/rules.d/71-nvidia.rules in the nvidia packages | 14:16 |
| pitti | apw: btw, in https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration you have a WI to merge initramfs-tools; infinity once said he'd also want to do a two-way merge with Debian (but that was already a long time ago) | 14:17 |
| pitti | apw: just saying for coordination | 14:17 |
| pitti | tseliot: ah, that's much more elegant indeed | 14:17 |
| tseliot | pitti: I think I need to take care of this myself, as I need to test it with my systems with hybrid graphics. Sorry it's taking so long, but I've focussed on the drivers (speaking of which, nvidia-graphics-drivers-346 and nvidia-graphics-drivers-346-updates are still in Vivid NEW) | 14:18 |
| pitti | tseliot: but I figure that wouldn't provide the same "do that before lightdm" synchronization? | 14:18 |
| pitti | tseliot: ok | 14:18 |
| pitti | tseliot: actually I wonder if that upstart job is doing what you expect -- it basically doesn't do anything if prime-supported is true | 14:19 |
| tseliot | pitti: the do before lightdm is a requirement only for switching between graphics drivers (as X will be off) | 14:19 |
| pitti | s/is true/shows something/ | 14:19 |
| pitti | tseliot: that's what's confuzing me | 14:19 |
| tseliot | pitti: yes, maybe I made the upstart job redundant as I now handle a lot of stuff directly in the gpu-manager | 14:21 |
| tseliot | this is also why I need to check | 14:21 |
| tseliot | (mostly because I don't remember, it's been a while) | 14:21 |
| pitti | rbasak, jamespage: do you know what "CPC cloud images" are? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they have some dynamic upstart jobs | 14:23 |
| === roadmr is now known as roadmr_afk | ||
| hallyn | pitti: thanks for your help with the versioning - do you mind also sponsoring http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.1.9-2+deb7u1.dsc ? | 14:27 |
| pitti | hallyn: will do in a few mins | 14:28 |
| pitti | ?quit | 14:32 |
| rbasak | pitti: that's utlemming and Odd_Bloke's department. Cloud images, basically. | 14:45 |
| pitti | rbasak: ah, so the CPC doesn't mean anything special? | 14:45 |
| pitti | hallyn: is debian bug 726127 fixed in testing/unstable? if so, the bug should be closed with an appropriate Version: | 14:47 |
| ubottu | Debian bug 726127 in libnetcf1 "libnetcf1: The function ipcalc_netmask in netcf had a bug for any netmask > 24" [Important,Open] http://bugs.debian.org/726127 | 14:47 |
| Odd_Bloke | rbasak: pitti: Also rcj. | 14:47 |
| pitti | utlemming, Odd_Bloke, rcj: does "CPC" cloud image mean anything special? https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration mentions that they create some dynamic upstart jobs | 14:48 |
| Odd_Bloke | pitti: We're the Certified Public Cloud team, so it just means the cloud images that we produce. | 14:48 |
| pitti | Odd_Bloke: ah, so just http://cloud-images.ubuntu.com/ ? | 14:49 |
| pitti | i. e. this affects all cloud images, it's not an upstart job only in some "special" fork of them? | 14:49 |
| Odd_Bloke | pitti: I'm not 100% sure; utlemming would be able to answer that question better. | 14:50 |
| Odd_Bloke | pitti: But we do build images from the ci.u.c images specifically for some clouds, so we do have forks/derivatives of the images there. | 14:50 |
| pitti | halfie: uploaded | 14:51 |
| pitti | hallyn: uploaded | 14:51 |
| pitti | halfie: sorry, tab error | 14:51 |
| pitti | awe_: hey Tony, how are you? | 14:58 |
| pitti | awe_: do you want to review https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103 or should I just push/upload this? no-op for upstart, tested with systemd on a desktop | 14:59 |
| pitti | didrocks, slangasek, xnox: hangout now, right? | 15:00 |
| pitti | jamespage: ^ if you want to join, too | 15:01 |
| jamespage | pitti, | 15:01 |
| jamespage | ok | 15:01 |
| awe_ | pitti, just started a mtg ( that I'm leading ), will ping you when I'm done | 15:01 |
| xnox | pitti: url? | 15:01 |
| * xnox saw no emails. | 15:01 | |
| pitti | xnox: in the pad | 15:01 |
| pitti | xnox: you didn't get an invite? | 15:02 |
| hallyn | pitti: yeah, that bug was fixed long ago in unstable. | 15:04 |
| xnox | lol, i joined and the hangout froze =) | 15:07 |
| === roadmr_afk is now known as roadmr | ||
| slangasek | pitti: did you get the ubiquity review you were looking for? | 15:29 |
| === kickinz1 is now known as kickinz1|afk | ||
| xnox | pitti: without the property bridge, touch should boot but without mtp support and the like. | 15:30 |
| xnox | lxc-android-boot & lxc-android-config are needed though. | 15:30 |
| === kickinz1|afk is now known as kickinz1 | ||
| pitti | slangasek: yes, ubiquity is in vivid now | 15:37 |
| pitti | slangasek: and xnox also told me the secret how to test it in text mode | 15:37 |
| pitti | slangasek: so now, while it's broken in text mode under upstart, it actually works under systemd :) | 15:37 |
| slangasek | heh | 15:38 |
| pitti | hallyn: ah, can you close the bug then? send to XXX-done with "Version: 1.2.3-4" (first fixed version) in the first line, and then some quick explanation | 15:38 |
| hallyn | pitti: ok - i was actualy going to do that first this morning, then realized wheezy might be a problem still :) | 15:39 |
| hallyn | pitti: thanks | 15:40 |
| pitti | slangasek: so if you could build a new ubuntu desktop live, I'd appreaciate -- I'd like to do the full end to end testing without the crazy casper hacking to install local .debs | 15:40 |
| pitti | hallyn: ack, thanks | 15:40 |
| slangasek | pitti: I kicked off the build, it should be running now | 15:42 |
| awe_ | pitti, looks good to me. One question though...what's the meaning of --nodetach on the ExecStart line? | 15:43 |
| awe_ | also does "multi-user.target" == desktop? | 15:43 |
| xnox | awe_: multi-user.target ~= standard runlevel. | 15:43 |
| pitti | awe_: --nodetach is to keep it running in the foreground instead of demonizing | 15:43 |
| xnox | (default boot state for server, desktop, phone, cloud) | 15:44 |
| pitti | awe_: that's generally preferable under systemd and upstart, as it (1) avoids the unnecessary fork, and more importantly (2) you get the output logged properly, instead of it going to /dev/null | 15:44 |
| pitti | awe_: multi-user.target is roughly "runlevel 2" | 15:44 |
| pitti | awe_: i. e. it would be started on graphical and text boots after rcS/single user mode (in SysV terms) | 15:44 |
| awe_ | pitti, ofonod actually does the double fork | 15:45 |
| pitti | awe_: unless it's decidedly graphical (like lightdm) or early-boot, it's the most common default target to hook it in | 15:45 |
| awe_ | which is why the upstart job has "expect fork" | 15:45 |
| awe_ | ( unless I'm mistaken ) | 15:45 |
| pitti | awe_: right, I know; but not with --nodetach | 15:45 |
| awe_ | is there documentation for "--nodetach"? | 15:46 |
| pitti | awe_: I think I just did ofonod --help or so | 15:46 |
| awe_ | hmmm | 15:46 |
| pitti | awe_: it was fairly easy to find, so I guess I got it from --help or the manpage | 15:46 |
| awe_ | sorry, for some reason I thought that was being passed to ExecStart | 15:47 |
| awe_ | lemme check the ofono src | 15:47 |
| pitti | awe_: so, there's two types: Type=simple (the default) just stays in the foreground, and "Type=forking" (equivalent to upstart's "expect fork") for daemonizing ones | 15:47 |
| pitti | awe_: yes, it is passed to the program you specify in ExecStart | 15:47 |
| pitti | awe_: but with it staying in the foreground it's a lot easier to debug problems (sudo systemctl status ofono will show the recent output -- journal magic) | 15:48 |
| awe_ | yea... sorry, just never used --nodetach before | 15:48 |
| awe_ | so... aren't there security implications for not forking into the background? | 15:48 |
| pitti | awe_: so, it works just fine by itself and with phonesim (that's already systemd-ified, I uploaded yesterday) | 15:48 |
| pitti | awe_: no; forking is really just an old way of starting daemons when we only had SysV init | 15:49 |
| pitti | awe_: it's completely obsolete with upstart or systemd | 15:49 |
| pitti | awe_: these already do that forking/isolation for you | 15:49 |
| awe_ | OK, not something I was aware of... I'll take your word for it, for now. ;)- | 15:50 |
| pitti | awe_: it was the same in upstart -- daemonizing and "expect fork" worked, but you never got a log in /var/log/upstart | 15:51 |
| awe_ | pitti, reviewed/approved | 15:51 |
| pitti | awe_: with --stay-in-the-foreground (for whatever daemon) and without "expect fork", we had /var/log/upstart/<job>.log | 15:51 |
| pitti | awe_: ack, thanks | 15:51 |
| awe_ | pitti, that cause the log output when to syslog, where I expected it to! | 15:51 |
| awe_ | ;) | 15:51 |
| awe_ | it's very useful to see ofono's log messages intertwined with NM's messages | 15:52 |
| pitti | awe_: you can still do that :) | 15:52 |
| awe_ | ok | 15:52 |
| pitti | awe_: so, I don't mind much if you want to switch to Type=forking and drop the --nodetach | 15:52 |
| pitti | this is just how most other stuff behaves these days | 15:52 |
| pitti | awe_: so you get the per-unit output separately, or everything in one log, or any filtering of the complete log | 15:53 |
| awe_ | let's leave it as for now. We can discuss more when we go to move the phone image to systemd | 15:53 |
| pitti | awe_: ack; either way, it's simple enough to flip | 15:53 |
| awe_ | if possible, I'd like to get rid of the need for the override | 15:53 |
| awe_ | if possible... | 15:53 |
| pitti | awe_: sorry, which override? | 15:54 |
| awe_ | hey, one other thing.. if you get a chance, we're seeing an issue with phonesim-autostart on vivid: https://bugs.launchpad.net/ubuntu/+source/ofono-phonesim/+bug/1401143 | 15:54 |
| ubottu | Launchpad bug 1401143 in ofono-phonesim (Ubuntu) "Installing ofono-phonesim-autostart makes the phone unusable" [High,Confirmed] | 15:54 |
| xnox | pitti: where is the ofono job? | 15:54 |
| Odd_Bloke | So I just ran pull-lp-source and it stomped on an existing directory; is there a backup of the directory it stomped on anywhere? | 15:54 |
| awe_ | any chance you could take a look | 15:54 |
| awe_ | pitti, there's an ofono.override installed in touch images | 15:54 |
| xnox | pitti: did you add that it should claim the BusName=org.ofono? | 15:54 |
| xnox | awe_: don't worry about the touch, i'm working on the ofono override for touch. | 15:54 |
| pitti | awe_: ah! yeah, I guess we'll get to that when we review the touch upstart jobs tomorrow | 15:54 |
| xnox | pitti: awe_: please please =) i have a patch to the event bridge to make ofono job work on the touch properly. | 15:55 |
| awe_ | xnox, please keep me in the loop... as mentioned, if possible it'd be great to get rid of the need for an override | 15:55 |
| pitti | xnox: no, I didn't; so far it doesn't do socket activation and notification anyway, but I guess it wouldn't hurt | 15:55 |
| xnox | awe_: there is an email on ubuntu-devel with rough plan, tomorrow i'll post working debs for testing. But I don't have phone to test it on, so will ask for remote hands. | 15:56 |
| awe_ | xnox, ack | 15:56 |
| awe_ | I"m off this afternoon, but will be around tomorrow to review/test/... | 15:56 |
| pitti | awe_: ugh, only happens on krillin, not on mako? explains why I've never seen it :/ | 15:56 |
| pitti | awe_: I keep this open and have a closer look, and check if there's anything fishy wrt. stopping it | 15:57 |
| awe_ | yea... if you don't have a krillin, I can do some more debug on my end, but might have to wait till Mon | 15:57 |
| awe_ | pitti, the one pain in the ass is the upstart watchdog that we added... if the respawn limit gets hit, the phone goes into a hard reboot loop | 15:57 |
| awe_ | ( which I've suggested we get rid of and put a limit on number of reboots that happen ) | 15:58 |
| pitti | awe_: ah, was that added only on krillin? | 15:58 |
| awe_ | no | 15:58 |
| awe_ | but only vivid, not rtm | 15:58 |
| pitti | awe_: but ofonod is running, it's just not through its upstart job | 15:58 |
| pitti | ah | 15:58 |
| awe_ | yea, but somehow upstart gets confused and tries to restart the ofono job | 15:58 |
| awe_ | and fails repeatedly hitting the respawn limit | 15:59 |
| awe_ | which then triggers the watchdog to reboot the phone | 15:59 |
| awe_ | ad infinitum | 15:59 |
| xnox | pitti: ofono on the phone should not do dbus activation, this is one of the things i have fixed.... | 15:59 |
| xnox | pitti: otherwise watchdog has no idea. | 15:59 |
| pitti | xnox: ah right, so BusName= is just to determine a more precise "did that service finish starting up" | 16:00 |
| awe_ | xnox, yea...that was fixed awhile back | 16:00 |
| xnox | awe_: in systemd watchdog is builtin, thus you can specify which units to activate on failure, etc. | 16:00 |
| awe_ | xnox, watchdog is a new thing... to detect system processes that are in a bad state | 16:00 |
| awe_ | xnox, cool | 16:00 |
| xnox | pitti: yeap, if it's on the bus, it's ready to accept connections. Previously we needed fork as the notification when it's ready. | 16:00 |
| awe_ | anyways, I have to jump on to our stand-up | 16:00 |
| awe_ | be around tomorrow to discuss more | 16:00 |
| awe_ | thanks! | 16:00 |
| pitti | xnox: works fine, pushed to https://code.launchpad.net/~pitti/ofono/systemd/+merge/246103 | 16:07 |
| xnox | slangasek: pmcgowan: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/5 *shrug* | 16:09 |
| ubottu | Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] | 16:09 |
| ericsnow | we (juju core) are working on getting systemd support in place for the dev feature freeze (see https://launchpad.net/bugs/1409639) | 16:14 |
| ubottu | Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] | 16:14 |
| ericsnow | we would welcome any pointers on gotchas we should be aware of, particularly relative to dynamic script/unit generation | 16:14 |
| xnox | ericsnow: use systemd go bindings; don't work to systemctl; use correct location for units. | 16:14 |
| xnox | ericsnow: if you are doing boot-time generation of units -> use systemd generator spec (see for example gpt-auto-generator) | 16:15 |
| ericsnow | also, we rely on LXC and on cloud-init, and it is unclear from the various resources I've seen what the status is for those (relative to systemd) | 16:15 |
| xnox | ericsnow: for any other on-the-fly generated things store them in /run/systemd/system/, activate and enable them. | 16:15 |
| xnox | ericsnow: LXC in ubuntu does work i believe, talk to stgraber/hallyn for details. | 16:16 |
| xnox | ericsnow: i don't know the status of cloud-init port to systemd, i believe it was done a while back - pmcgowan any comment on cloud-init? | 16:16 |
| stgraber | xnox: at the moment LXC works on a systemd host. systemd containers don't work so well in the distro (that's what I'm working on right now) | 16:16 |
| xnox | slangasek: is pmcgowan - ubuntu server team manager? | 16:17 |
| pmcgowan | xnox, I think you are asking the wrong person | 16:17 |
| stgraber | got one more patch to get upstream and then we need to release and get 1.1 in Ubuntu | 16:17 |
| xnox | pmcgowan: right. | 16:17 |
| stgraber | xnox: gaughen is | 16:17 |
| ericsnow | xnox: thanks for the updates | 16:17 |
| xnox | gaughen: is cloud-init ported to systemd? | 16:17 |
| xnox | pmcgowan: sorry for confusion. | 16:17 |
| pmcgowan | np | 16:17 |
| xnox | gaughen: https://bugs.launchpad.net/juju-core/+bug/1409639/comments/5 | 16:17 |
| ubottu | Launchpad bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] | 16:17 |
| pitti | ericsnow: wrt. dynamic: transient units should go into /run/systemd/system/, they will only be valid for the current boot; permanent unpackaged units (I think that's what you are after) into /etc/systemd/system/ | 16:18 |
| pitti | ericsnow: unless you generate the units automatically based on some configuration file, then you mgiht rather want a generator (which synthesizes them in /run/ based on the config) | 16:19 |
| xnox | ericsnow: packaged things will be in /lib/systemd/system -> thus one cannot just check for files, always talk to systemd over the API. | 16:19 |
| pitti | ericsnow: (I'm deliberately very high-level here -- happy to dive down if you are interested in either) | 16:19 |
| ericsnow | xnox, pitti: how much can we depend on /run/systemd/system/ being the right path on all systems (ubuntu or otherwise)? | 16:19 |
| xnox | ericsnow: you should use pkg-config to query the paths, if you want dynamic discovery of the locations. | 16:20 |
| pitti | ericsnow: those are standard upstream paths everywhere | 16:20 |
| ericsnow | xnox: which go systemd binding are you referring to? | 16:20 |
| xnox | ericsnow: but /run/systemd/system is fairly universal. | 16:20 |
| pitti | ericsnow: /etc as well; just /lib/systemd/ isn't, but you shouldn't write there anyway (unless through .debs) | 16:20 |
| gaughen | smoser, can you answer xnox's question above about cloud-init/systemd | 16:20 |
| ericsnow | xnox: (good point on using the bindings, by the way) | 16:21 |
| gaughen | xnox, I would think that cloud-init is systemd friendly since we used it for snappy | 16:21 |
| gaughen | but I need to pull in the expert.. ahem, smoser | 16:21 |
| xnox | ericsnow: the one in the archive, used by coreos & docker, actively maintained - golang-go-systemd-dev https://launchpad.net/ubuntu/+source/golang-go-systemd https://github.com/coreos/go-systemd | 16:21 |
| ericsnow | xnox: I'll look into using systemd generator spec | 16:21 |
| pitti | ericsnow: high-level: it's a program (or a script) which reads whatever config files you have, and create unit files or links (for additional dependencies) in /run/systemd/system | 16:22 |
| xnox | ericsnow: generator spec is ok, but is invoked very early in the boot - before one has network. It's good for static things - e.g. generate .mount units from /etc/fstab to mount things. (that's upstream in the systemd) | 16:22 |
| pitti | ericsnow: we use that to generate units for sysv init scripts, or units for network interfaces defined in /etc/network/interfaces -- that's the spirit/use cases for them | 16:23 |
| pitti | ericsnow: if OTOH you have a "make install" situation where you install packages and configure them through a charm, creating them statically in /etc/systemd/system/ sounds more appropriate | 16:23 |
| staylor_ | I'm a little confused by the proper way to package a kernel for sharing, I started off with make-kpkg but it seems the official kernels may be built using the pkg-deb system built into the kernel? | 16:24 |
| pitti | xnox, ericsnow: btw, there's nothing inherently wrong with calling systemctl; it might just not be the most comfortable/efficient API | 16:24 |
| smoser | reading | 16:24 |
| smoser | xnox, um... looking at the changelog *your* name appears wrt cloud-init and systemd :) | 16:25 |
| xnox | pitti: it's localised output, instead of static no? (e.g. not like upstart) | 16:25 |
| * xnox eye roll | 16:25 | |
| smoser | xnox, i really suspect there is work to do for cloud-init and systemd. i do not think that it probably behaves exactly as i'd like it to. | 16:26 |
| pitti | xnox: yes; as I said, depends on what you want to do; if you just need to call "systemctl enable" or similar, the exit status is just fine | 16:26 |
| xnox | smoser: does it boot? i can't remember if i tried that in the end. | 16:26 |
| smoser | it does boot. yes. used in snappy. | 16:26 |
| pitti | I also run systemd in adt VMs (which are also cloud-init based), just not for the initial run | 16:26 |
| xnox | smoser: cool. | 16:31 |
| xnox | ericsnow: cloud-init with systemd in ubuntu works fine. | 16:31 |
| Odd_Bloke | cjwatson: https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1411310 <-- these are the changes I've had to make to live-build to produce CPC images | 16:33 |
| ubottu | Launchpad bug 1411310 in live-build (Ubuntu) "[PATCH] Enable tuning of EXT images produced by lb_binary_rootfs" [Undecided,New] | 16:33 |
| smoser | it does work, i'm almost certain there are bugs. | 16:34 |
| didrocks | xnox: you can always rely on systemctl show output, not systemctl cat or whatsover (and no localized output for anything in systemctl, but no garantee either that it stays stable apart from some commands like show, is-enable…) | 16:42 |
| didrocks | xnox: always be aware that /run/systemd/generator*/ are not bound to boot time, but by daemon-reload time, so if you update/install any package executing that command, it will be entirely cleaned and reloaded, not sure it's what they want if they don't use a generator (seems /etc would be better for them as juju is in some admin role in some way) | 16:44 |
| didrocks | ericsnow: FYI ^ | 16:44 |
| cjwatson | Odd_Bloke: fair enough, but you probably want somebody from foundations :) | 16:45 |
| cjwatson | doesn't look too complex | 16:46 |
| Odd_Bloke | cjwatson: Ack; is there a process I should be following that isn't "10 PING random Foundations person; 20 SLEEP 12h; 30 GOTO 10"? :p | 16:50 |
| cjwatson | Odd_Bloke: 10 ACQUIRE core-dev 20 UPLOAD it yourself | 16:50 |
| cjwatson | :-P | 16:50 |
| cjwatson | Odd_Bloke: or, more seriously, subscribe ubuntu-sponsors and it should pop onto the sponsorship queue which gets frequent attention | 16:51 |
| Odd_Bloke | Done. | 16:52 |
| Odd_Bloke | (The latter. :p) | 16:52 |
| tseliot | pitti: can you remind me how to switch to systemd in vivid, please? | 16:59 |
| tseliot | (or point me to the docs) | 16:59 |
| didrocks | tseliot: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems | 17:01 |
| pitti | tseliot: https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems shows how to do it one-time or permanently | 17:01 |
| pitti | ah, thanks didrocks :) | 17:01 |
| didrocks | sorry, thought you already EOD ;) | 17:01 |
| tseliot | didrocks, pitti: thanks! | 17:01 |
| pitti | xnox: I alraedy reviewed the upstart logrotate one ages ago, and I'm afraid the "no classes" one doesn't tell me anything, that needs another upstream | 17:01 |
| pitti | xnox: the update-notifier is just dropping the :sys:, is that what's meant by "class"? | 17:02 |
| pitti | xnox: either way, that looks fine; do you want to upload that yourself, or want me to sponsor it? | 17:02 |
| xnox | pitti: "no class" is a bad name, a better name would "run udev-bridge on the session upstart, in addition to system upstart" | 17:03 |
| xnox | pitti: and drop memory usage of loca-bridge -> do not store all upstart jobs classes, as they are not used. | 17:03 |
| xnox | pitti: and drop event bridge config file for system init as it makes no sence on the system init (retransmit system init events... to system init) | 17:04 |
| pitti | xnox: off for dinner, but can sponsor the update-notifier MP if you can't/don't want to | 17:06 |
| tseliot | pitti: does the Requires= section support alternative dependencies, as with || | 17:06 |
| tseliot | ? | 17:06 |
| xnox | tseliot: no, but your alternatives (pluginA || pluginB) can both do [Install] WantedBy=the-main-one | 17:07 |
| slangasek | right; or you can use Wants instead of Requires | 17:07 |
| * xnox looks if there is requiredby. | 17:07 | |
| tseliot | I'd like to start the service only if either lightdm or gdm has started | 17:08 |
| xnox | tseliot: it's better to ask what's your main thing, and what the alternates are. | 17:08 |
| xnox | tseliot: then use [Install] WantedBy=graphical.target | 17:08 |
| xnox | tseliot: without requires. | 17:08 |
| xnox | tseliot: what's the service? | 17:09 |
| xnox | pitti: i'll upload things tomorrow. | 17:09 |
| tseliot | xnox: it's a service that should replace the nvidia-prime upstart job. All it has to do, is actually unload a module when the login manager (being only lightdm or gdm) is stopped | 17:10 |
| tseliot | as per LP: #1312255 | 17:11 |
| ubottu | Launchpad bug 1312255 in nvidia-prime (Ubuntu) "[systemd] nvidia-prime package needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312255 | 17:11 |
| xnox | tseliot: note that you can do conditionals based on udev devices, can we construct conditionals for nvidia-prime devices regardless of custom scripts in use? | 17:12 |
| xnox | tseliot: in your case you should use things like Wants,Before and display-manager.target | 17:13 |
| xnox | tseliot: note that display-manager.target is dynamic and is the "currently configured for use display-manager" without need of encoding "ligtdhm | gdm |...." | 17:13 |
| tseliot | xnox: I'm not sure we can. This is only for users of the nvidia binary driver, and it can be a bit of a mess, as the NVIDIA GPU may be disabled (in which case udev wouldn't work) | 17:14 |
| tseliot | xnox: is that display-manager.target or display-manager.service? | 17:15 |
| xnox | tseliot: target | 17:15 |
| tseliot | ok, thanks | 17:15 |
| ericsnow | xnox, pitti: thanks for the help; I'll come back if I have any more questions | 17:16 |
| xnox | tseliot: it's a generic target, and each $dm.service hooks on to it. Just boot vivid and checkout things with systemctl - critical paths, boot order, dependencies etc. | 17:16 |
| tseliot | xnox: would [Install] WantedBy=graphical.target be useless in this case? | 17:17 |
| === kickinz1 is now known as kickinz1|afk | ||
| pitti | tseliot: sorry, was cooking dinner | 17:38 |
| pitti | tseliot: not directly (as that would be a bit of gambling during boot -- which one do you start?) | 17:38 |
| pitti | tseliot: but usually in this case you use Alias= and Requires= that | 17:39 |
| pitti | tseliot: in your specific case, Requires=display-manager.service | 17:39 |
| pitti | xnox: ^ FYI | 17:39 |
| xnox | pitti: however i think nvidia-prime should be started before, rather than together with display-manager. | 17:40 |
| pitti | tseliot: ah, then it's better to create a display-manager.service.d/nvidia-prime.conf with an ExecPostStop=rmmod | 17:40 |
| pitti | tseliot: seems easier | 17:40 |
| tseliot | pitti: np. BTW, I was thinking that, since the upstart job only unloads the module on shutdown, then maybe something like this should do the trick: http://pastebin.ubuntu.com/9756959/ | 17:40 |
| pitti | xnox: that's Before=display-manager.service | 17:40 |
| tseliot | and leave login managers alone, since all we have to do is make sure that the specific module is not loaded on shutdown | 17:41 |
| tseliot | or nasty things can happens on some systems | 17:41 |
| pitti | tseliot: I'm not 100% sure if the .d/ directories work for "virtual" units (i. e. Alias=) | 17:41 |
| pitti | tseliot: would be nice if they did, then this would be super-easy | 17:41 |
| pitti | tseliot: failing that, I'll think about something else, but let me try that first | 17:41 |
| xnox | tseliot: could you email ubuntu-devel mailing list describing how nvidia prime works and what needs to happen, imperically, not in terms of any init system? | 17:42 |
| tseliot | pitti: I stole the WantedBy=multi-user.target line from the wiki page | 17:42 |
| xnox | cause i really have no idea how nvidia-prime works, and it's fairly non-typical integration. | 17:43 |
| pitti | yeah, and the upstart job looks really the wrong way around | 17:43 |
| pitti | if the udev rules DTRT, it can probably just go away? | 17:43 |
| tseliot | pitti: udev won't help if the discrete GPU was disabled by ACPI | 17:44 |
| pitti | tseliot: but then you wouldn't have an nvidia card? | 17:44 |
| tseliot | xnox: yes, I can do that but it's really just the pre-stop stanza of the upstart job that I need at this point | 17:45 |
| pitti | tseliot: http://paste.ubuntu.com/9756999/ | 17:46 |
| tseliot | pitti: if a system is intel+nvidia, and you disable nvidia, you still have to make sure that nvidia is re-enabled before shutdown (by unloading the bbswitch module) | 17:46 |
| pitti | tseliot: this works fine -- after boot I get a /tmp/pwned, so the .d/ trick works fine for virtual units | 17:46 |
| tseliot | or the system might not see the nvidia GPU on next boot (at all) | 17:46 |
| pitti | tseliot: ah, that's this part, not the start-nvidia-persistenced bit | 17:46 |
| pitti | tseliot: in your case you want ExecStopPost=..., I just used that for easier visibility | 17:47 |
| tseliot | pitti: yes, we can leave alone the persistenced bit, that is covered by a udev rules (and it's just a leftover in the upstart job) | 17:47 |
| pitti | tseliot: so, just ship a static file like that and all should be well | 17:47 |
| pitti | ok, time for eating now, bbl | 17:48 |
| tseliot | pitti: like the one I put on pastebin, right? | 17:48 |
| xnox | tseliot: pitti: i think we want to steal this job https://wiki.archlinux.org/index.php/bumblebee#Enable_NVIDIA_card_during_shutdown | 17:48 |
| pitti | tseliot: just not with [Install], as display-amanger.servie already exists | 17:48 |
| xnox | tseliot: pitti: on shutdown, without anything else enable nvidia card. | 17:48 |
| pitti | tseliot: oh, ExecStopPost=-/bin/rmmod ... (the minus makes failure of that command non-fatal) | 17:49 |
| xnox | tseliot: or just use that pattern for anything you want to happen on shutdown, e.g. rmmod. | 17:49 |
| tseliot | xnox: oh, nice | 17:49 |
| pitti | xnox: that works too, yes | 17:49 |
| tseliot | pitti: ok, no "install" then | 17:49 |
| pitti | if you only want this to happen when ther's a display manager, my .d solution will do that, but the above will always rmmod | 17:50 |
| xnox | see ya'll tomorrow | 17:50 |
| pitti | need to run, bbl | 17:50 |
| tseliot | xnox, pitti: thanks! | 17:50 |
| pitti | tseliot: re; so, either approach should work, it depends on whether this should always happen (also for text mode), or only if there is (or rather was) X.org/lightdm/gdm | 18:06 |
| pitti | tseliot: for the .d/ extension you don't need to do anything, for the separate unit like in the wiki you need [Install] and dh_systemd_enable | 18:07 |
| tseliot | pitti: if there's no X or login manager of any kind, then I doubt the bbswitch will be loaded (as gpu-manager loads it) | 18:07 |
| pitti | tseliot: btw, 'echo ON > /proc/acpi/bbswitch' sounds like pretty much the opposite of rmmod bbswitch? | 18:18 |
| tseliot | pitti: I don't echo ON, as I set the module to re-enable the GPU when unloaded anyway | 18:18 |
| tseliot | I think my solution is better (vs the echo ON one) | 18:19 |
| pitti | tseliot: I was just quoting that from https://wiki.archlinux.org/index.php/bumblebee#Enable_NVIDIA_card_during_shutdown | 18:19 |
| tseliot | pitti: yes, I know. It's mostly the same | 18:19 |
| pitti | tseliot: rmmod has a tendency to block or cause kernel crashes for some modules, but if it works for that one, ok | 18:19 |
| pitti | ack | 18:19 |
| pitti | tseliot: thanks | 18:20 |
| tseliot | yes, I haven't seen any problems with that | 18:20 |
| tseliot | pitti: thanks to you | 18:20 |
| pitti | mterry: hey Mike, how are you? | 18:24 |
| pitti | mterry: would you have some time to look at the two python MIRs in bug 1407695? | 18:24 |
| ubottu | bug 1407695 in xmlsec1 (Ubuntu) "[MIR] python-saml2, python-repoze.who, xmlsec1" [High,New] https://launchpad.net/bugs/1407695 | 18:24 |
| pitti | /lib/init/init-d-script: 12: /etc/rc2.d/S02whoopsie: -c: not found | 18:31 |
| pitti | oh, -ENODIDROCKS | 18:31 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| pitti | slangasek, ericsnow: any remaining questions for me for today? | 18:54 |
| ericsnow | pitti: no, thanks | 18:54 |
| slangasek | pitti: nope! thanks :) | 18:58 |
| pitti | slangasek: ah, we have a new desktop image; giving that a quick whirl still, | 19:00 |
| pitti | jodh: would you mind blacklisting oem-config-debconf and upstart-watchdog in the to-migrate branch? | 19:05 |
| hallyn | say, what is it that builds a "*egg-info" file in a python related package? | 19:06 |
| hallyn | i'm looking at the libvirt-python source package, but all it has is a rule in the .spec file to rm the files. nothing about genearting them | 19:06 |
| pitti | hallyn: usually setup.py install | 19:09 |
| pitti | hallyn: sorry, setup.py build | 19:09 |
| pitti | hallyn: i. e. python distutils | 19:09 |
| hallyn | pitti: i don't see *distutils* in debian control, and no setup.py install in debian rules... | 19:10 |
| pitti | hallyn: distutils is built into python | 19:11 |
| pitti | hallyn: is it using pybuild/ | 19:11 |
| pitti | ? | 19:11 |
| hallyn | pitti: so the complaint is that the file is present in trusty but not precise | 19:11 |
| hallyn | is tha texpected, i.e. precise package builds didn't do it automatically, trusty's do? | 19:11 |
| pitti | hallyn: yep, dh auto-detects teh build system as python and calls ./setup.py | 19:11 |
| pitti | hallyn: I suppose precise's package didn't use dh yet, but had all the build steps manually? | 19:12 |
| pitti | still a bit odd why that didn't build an .egg-info; or perhaps it just didn't install it? | 19:12 |
| hallyn | seems likely | 19:12 |
| hallyn | guess i'll try by hand | 19:12 |
| * pitti pull-lp-source libvirt-python precise | 19:12 | |
| pitti | err, doesn't exist there? | 19:13 |
| hallyn | right it was included in 'libvirt' | 19:13 |
| pitti | hallyn: indeed, libvirt-python was added in trusty | 19:13 |
| pitti | ah | 19:13 |
| pitti | hallyn: hah, easy -- that used autoconf, not ./setup.py (i. e. python distutils) | 19:14 |
| pitti | no distutils, no egg | 19:14 |
| hallyn | so is there an easy way to add it manually to the precise package? | 19:14 |
| hallyn | it does have include /usr/share/cdbs/1/class/python-distutils.mk | 19:15 |
| hallyn | well the bug reporter suggests just manually creating one | 19:17 |
| hallyn | maybe i'll just do that | 19:18 |
| pitti | slangasek: yay, ubiquity-only+oem mode+systemd end-to-end testing success; and with that, good night :) | 19:19 |
| pitti | hallyn: yeah, distutils.mk won't help you as there's no setup.py | 19:19 |
| pitti | hallyn: shipping a statically made-up one seems easiest for an SRU, if it's crucial | 19:20 |
| slangasek | pitti: thanks, g'night! | 19:20 |
| sarnold | hey pitti, late night :) how's the feet? | 19:21 |
| pitti | sarnold: much better already, thanks | 19:22 |
| sarnold | pitti: nice! glad to hear it | 19:22 |
| pitti | sarnold: yeah, quite late, but I'm really happy about the progress | 19:22 |
| pitti | maybe tomorrow I won't start at 6 again :) | 19:22 |
| * pitti waves good night | 19:22 | |
| sarnold | :) | 19:22 |
| sarnold | nn | 19:22 |
| hallyn | pitti: thanks. (i marked the bug medium, as i don't thin kit's critical; meaning it doesn't meet SRU threshold; wlil see if the submitter deems it important enough to reply) | 19:24 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === superm1_ is now known as superm1 | ||
| jdstrand | arges: hey, now that you've been able reproduce the qcow2 corruption bug, would it be ok for me to say, migrate to ext4? I'm ok with staying on saucy qemu for now if it would help with future testing (I don't run untrusted vms) | 20:57 |
| bdmurray | zul: is there an SRU bug for this heat upload in the unapproved queue for utopic proposed? | 21:00 |
| arges | jdstrand: running with ext4 should be fine. You shouldn't need to use saucy qemu however | 21:10 |
| arges | jdstrand: and yea I just reproduced it again with upstream qemu. so i'll hack on that more when I have time | 21:11 |
| jdstrand | arges: yeah, I wasn't clear. I meant-- I am on ext3 now. it is my understanding going to ext4 may solve my problems with later qemus | 21:15 |
| arges | jdstrand: yes. thats right | 21:15 |
| jdstrand | arges: so, I am wondering if I go to ext4 and supported qemu is ok, or if you want me to stay put | 21:15 |
| arges | jdstrand: nope please use ext4, i have everything documented to reprodue and fix | 21:16 |
| jdstrand | oh nice | 21:16 |
| * jdstrand hugs arges :) | 21:16 | |
| jdstrand | of course, now I need to decide how to get there :) | 21:16 |
| jamespage | bdmurray, reject that please - its gone to the wrong place | 21:17 |
| jamespage | it should have been for vivid | 21:17 |
| * jamespage rejects | 21:17 | |
| jamespage | rechecks rather | 21:17 |
| bdmurray | jamespage: I'm sorry are you double checking? | 21:19 |
| === salem_ is now known as _salem | ||
| === danwest is now known as danwest-afk | ||
| Bluefoxicy | Oh that is hilarious. | 22:08 |
| Bluefoxicy | Steam does a rm -rf / | 22:08 |
| roadmr | stgraber: hello, what's the proper way to add a config item via the lxc python api? I tried container.set_config_item("lxc.mount.entry", blah) then container.save_config() but the config file got borked and the container doesn't start :( | 22:27 |
| stgraber | roadmr: set_config_item on lxc.mount.entry will override the existing mount list | 22:29 |
| stgraber | roadmr: you probably want append_config_item in that case | 22:29 |
| roadmr | stgraber: oh! cool, let me try that then | 22:29 |
| roadmr | thanks! | 22:30 |
| roadmr | stgraber: \o/ it works!! yay, thanks :D | 22:32 |
| === mgedmin_ is now known as mgedmin | ||
| === Bluefoxicy_ is now known as Bluefoxicy | ||
| === mnepton is now known as mneptok | ||
| === tedg` is now known as tedg | ||
| === mfisch is now known as Guest97735 | ||
| === Ursinha_ is now known as Ursinha | ||
| === mnepton is now known as mneptok | ||
| === gusnan is now known as 17WAAXWCT | ||
| === kgunn is now known as Guest4292 | ||
| === broder_ is now known as broder | ||
| === psivaa_ is now known as psivaa__ | ||
| === FourDollars_ is now known as FourDollars | ||
| === PeterS is now known as 7JTAB3JD3 | ||
| === tarpman_ is now known as tarpman | ||
| === balloons is now known as Guest8667 | ||
| === maxb is now known as Guest47523 | ||
| === Pici is now known as Guest32967 | ||
| === charles_ is now known as Guest52246 | ||
| === elijah is now known as Guest92966 | ||
| === Tribaal_ is now known as Tribaal | ||
| === TheMuso` is now known as TheMuso | ||
| === dkessel_ is now known as dkessel | ||
| === mwhudson_ is now known as mwhudson | ||
| === robru_ is now known as robru | ||
| === DalekSec_ is now known as DalekSec | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!