[00:01] zyga: if you are dealing with memory corruption valgrind --db-attach=yes is useful [00:01] after attaching py-list and see what line of python code caused it [00:01] but unfortunately you need a large amount of suppressions as python is very valgrind noise [00:03] < offline === achernya_ is now known as achernya === _salem is now known as salem_ === shuduo_afk is now known as shuduo === brainwash_ is now known as brainwash === salem_ is now known as _salem === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo === shuduo is now known as shuduo_afk [04:39] kees: ping? === shuduo_afk is now known as shuduo [05:00] Good morning [05:02] xnox: syslog> I'd rather add it as an autopkgtest so that it blocks regressions in -proposed, rather than seeing them in the install smoketests once the damage is already done; but can't hurt to test it in both places, of course === dspiteri is now known as darrenS === darrenS is now known as DarrenS [07:52] good morning === iahmad is now known as iahmad|brb === iahmad|brb is now known as iahmad [08:10] cjwatson：i have updated my merge proposal about https://code.launchpad.net/~penghuanmail/ubiquity/lp.1197220/+merge/195712， hope you can take some time have a look at it， thanks！ [08:17] morning === iahmad is now known as iahmad|afk [08:44] doko_, barry: FTR, haveged didn't help after all, py2.7/3.3 still fail the UUID tests very often [08:44] doko_, barry: so it's not missing entropy, but some other assumption that UUID makes; 23 collisions (i. e. identical UUID) out of 1000 is quite much indeed [08:45] doko_, barry: so I'm not sure whether this is a design problem of UUID1, or the Python test which assumes that it can generate 1000 time-based UUID1s at the same time and not get any collisions [08:46] but if it is, it might perhaps make sense to xfail/disable that test in autopkgtest? can this be done easily, or would that require patching? [08:48] doko_, barry: note that the documentation says it's going to use a 14 bit random sequence number, which is 16384 possible starting values [08:49] doko_, barry: so one would expect 61 collisions amongst 1.000 UUIDs if it was only that; the actual number is lower as it also takes the current time into account, but in the VM we might not have the microsecond precision that this test assumes [08:49] jibel: ^ [08:51] pitti, IIRC you can exclude tests for autopkgtest only directly from debian/tests/ [08:51] err, probably not 61 (birthday paradoxon); too lazy to do the exact calculations, but one certainly can't expect no collisions at all for 1000 out of 16384 [08:52] jibel: yes, that's what we should do; I meant, if there's some easy "$SKIP_TESTS" or if it needs some seddery [08:54] doko_, BTW, python3.4 autopkgtest explicitly calls python3.3 === iahmad|afk is now known as iahmad === doko_ is now known as doko [09:28] pitti, jibel: fixed for the next uploads [09:28] doko: you mean skipping the tests? [09:28] yes. just wondering why they don't fail on the buildds :-/ [09:29] doko: they aren't VMs; I guess they have a higher clock resolution there? [09:30] yes, no vm's [09:30] doko, did you fix python3.3 -> 3.4 in debian/tests/* too ? [09:30] jibel, yes [09:30] doko, thanks [09:31] jibel, however this one didn't reach trusty for arm64 yet ... [09:45] didrocks: sorry, I got a bit confused about notify-osd vs. the new -icons; why are these on manual landing? [09:46] didrocks: I thought we defaulted to auto-landing for stuff which isn't critical on the phone, to avoid too much manual work? [09:49] pitti: hey, cu2d wasn't done for having this manual landing forever [09:49] that was forced upon us [09:50] so it would mean dividing the stacks between desktop-only and the rest [09:50] (so that the desktop-only stacks can land automatically) === shuduo is now known as shuduo_afk [09:51] and TBH, don't really have the time to recreate the views and so on [09:51] hence the landing spreadsheet, so that we can force the publication on those (if tests pass) [09:51] in addition, that won't help us much, because most of the indicators or hud are both desktop and touch [09:52] so we can't land unity7 automatically, because it was built and tests against a version in the ppa which won't be released [09:52] and so, we can have unseen ABI breakages and so on [09:52] (cu2d for that put the stack in manual mode automatically, but it would mean that in the end, it will always be manual as the hud and indicators are in manual mode) === shuduo_afk is now known as shuduo === shuduo is now known as shuduo_afk === _salem is now known as salem_ === sil2100_ is now known as sil2100 [11:12] * cjwatson fixes auto-sync rashing [11:12] *crashing [11:14] ev: how do whoopsie-preferences' crashes and autoreportcrashes setting relate to whoopsie and apport ... i.e. when does whoopsie actually send the reports and when does apport and when does neither? [11:14] also, whoopsie is supposed to get adopted in kubuntu this cycle; finally ^^ [11:16] apachelogger: note we still have this bug where whoopsie doesn't pick up the newly created *.upload stamps in /var/crash; "sudo restart whoopsie" usually helps [11:16] so at least for me, whoopsie seldomly actually uploads something :/ [11:16] it seemed to me it always uploads on start, but yeah I noticed the issue [11:16] apachelogger: at the moment, apport doesn't send crashes to Launchpad, only to whoopsie (we'll turn that back on soon, though, for the dev release) [11:17] apachelogger: whoopsie is supposed to upload as soon as you click "yes, report" in the apport UI, i. e. when the *.upload stamp is created [11:17] (always, also in stable releases) [11:19] hm, I'll likely have to patch some KDE stuff then, since we do not use apport but KDE's tool [11:19] Riddell: ^ [11:19] apachelogger: ah, you don't use apport-kde any more? so we could drop this? [11:19] (it keeps causing issues from time to time, when the sip API changes again) [11:19] ABI [11:20] pitti: I have yet to figure out a plan because it's actually unmaintained from our side [11:20] and it pullls in a gazillion build deps [11:20] apachelogger: it's covered by tests, so it should generally work; it's not a high cost to keep it, but if you say you don't and won't use it any more, I'd rather mothball it [11:21] apachelogger: i. e. you just don't use apport-kde, or not apport at all? [11:22] pitti: it's complicated ;) [11:22] apachelogger: without the apport libs it's probably quite some effort to craft the input files for whoopsie? [11:22] apachelogger: heh, it always is :) [11:22] in dev releases we are supposed to use apport & apport-kde [11:22] in stable releases we use upstream's tool which has absolutely no ties to apport at this point [11:23] apachelogger: ah, ok; so I suppose you'd use whoopsie in dev releases, but not stables, too [11:24] pitti: actually we'd want whoopsie regardless, for the metrics [11:24] so it seems we need to tie the kde tool to whoopsie/apport such that it can tell whoopsie to send a report [11:25] apachelogger: it will need to create a /var/crash/...*.crash with the expected format, and then create the .upload stamp [11:25] apachelogger: whoopsie only has a relatively small and fixed set of keys it looks at, so most of the extra apport fields (from hooks, etc.) aren't necessray [11:26] apachelogger: it's mainly Executable, Package, Dependencies, Signal, Stacktrace, StacktraceAddressSignature (and perhaps a few other easy ones) [11:26] apachelogger: ah, it doesn't need Stacktrace, but CoreDump [11:27] it mainly uses StacktraceAddressSignature for the bucketing [11:27] (perhaps you do want to consider using python3-apport for generating those..) [11:28] yeah, was thinking that just now [11:28] it only needs python3-apt and the lightweight python3-problem-report, so its deps shouldn't be too heavy [11:30] pitti, apachelogger: acceptable fields: http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c#L93 [11:31] ev: cheers [11:32] thx [11:32] so, StacktraceAddressSignature and Package/Dependencies (with all the "modified" checks) are certainly the most complicated ones [11:34] we definitely don't want to reinvent the wheel, so using python3-apport seems certainly most sensible [11:34] pitti: I also put down a todo to check where we want to go with apport-kde [11:39] pitti, hi, do you have a moment for two questions? [11:39] diwic: hey, how are you? shoot [11:39] pitti, hi, sprinting in Taipei actually :-) how are you? [11:40] diwic: and thanks for not treating me like an IP socket by saying "ping" :-P (SCNR) [11:40] diwic: learning the "joys" *cough* of C++.. but quite well [11:40] pitti, so first question was if you were planning to SRU the xdg_runtime_dir fix in systemd to saucy or not [11:41] diwic: ah, it fell off my radar for a bit; upstream committed a different patch, but that might take some time to backport, so we might just as well go with our current one [11:41] pitti, aha, so Lennart actually ended up fixing it? [11:42] diwic: preparing SRUs shouldn't be blocked on me personally, but if noone else wants to touch it I can add it to my TODO [11:42] diwic: yes (I thought I tossed you the commit the other day) [11:43] pitti, nice. Can't find any email from you about it if you sent one, but glad it's fixed anyhow. So let's just see who prepares the SRU first of you and me then. But you'd still have to sponsor/SRU it I presume [11:46] pitti, second question. So my boss wants me to deliver a feature in OSP2, which we ship in preinstalls. OSP2 is based on 12.04.4. The feature needs a backend module in PulseAudio, but the pulseaudio won't be loaded unless you run OSP2, so the regression risk is minimal for standard Ubuntu. [11:47] diwic: http://cgit.freedesktop.org/systemd/systemd/commit/?id=954449b82df7f FYI [11:47] diwic: sounds ok to me, but as I'm not in ~ubuntu-sru I can't give a formal approval [11:48] pitti, really? I was sure you were. :-) [11:48] I had been for a long time, yes [11:49] * pitti adds ffox tab for bug 1197395 as a reminder [11:49] bug 1197395 in systemd (Ubuntu Saucy) "/run/user/$ID/pulse owned by root and not by the user" [Undecided,Confirmed] https://launchpad.net/bugs/1197395 [11:49] pitti, ok, so maybe I should ask one of the 10 ubuntu-sru members instead, any special one you'd recommend? :-) [11:50] diwic: TBH I'd just prepare the bug (testing, regression info), upload it, and see who bites :) [11:50] we don't seem to have a "primary" SRU team member these days [11:52] RAOF, hi, want to discuss an SRU before I prepare so I know I'm doing things the right way? [11:52] pitti: can you approve bug #1255583 please? I'd like to upload a new nvidia-prime that depends on bbswitch [11:52] bug 1255583 in bbswitch (Ubuntu) " [MIR] Main inclusion request for bbswitch" [Medium,Triaged] https://launchpad.net/bugs/1255583 [11:53] tseliot: I'm not in ~ubuntu-mir [11:53] oh [11:53] didrocks: please ^ [11:57] could somebody please approved my mail in u-d-a? [11:57] dholbach: done [11:57] tseliot: hum, module-assistant is recommended by in universe [11:57] pitti, gracias! [11:57] didrocks: but m-a is in main [11:58] tseliot: module-assistant | 0.11.6 | trusty/universe | source, all [11:58] is it? [11:58] we really don't want to put that on users [11:59] we should stick to DKMS IMHO [11:59] didrocks: oh, right [11:59] pitti: agreed :) [11:59] shall I disable the module-assistant bit? [11:59] yep [11:59] tseliot: FYI, the MIR team is small enough to normally not treat urgent issues like that. So ensure first that the MIR really match requirements please :) [11:59] the debian maintainer probably won't be pleased [11:59] tseliot: check-mir is a good one for that [12:00] didrocks: the point I'm going to upload the same thing in Precise for 12.04.4 for HWE [12:01] tseliot: yeah, that's why I'm treating that now, but we have a huge list and a very small team, so preparing that in advance would help to not sidetrack the team (and ensuring if it's urgent that the basic checks pass ;)) [12:01] tseliot: I'm continuing the review meanwhile, fortunately enough, it's a simple one [12:02] didrocks: right, I understand. I was pretty sure module-assistant was in main, I don't know why. Sorry about that [12:02] tseliot: check-mir FTW! :) [12:02] (in ubuntu-dev-tools) [12:02] didrocks: from now on I'll use that, thanks :) [12:03] yw! [12:04] (quite impressive the amount of override we have to make in dh_auto_install for dkms modules and that dh_dkms doesn't do it for us) [12:07] diwic: Sure, what are you after? My bandwidth might be limited though. [12:08] RAOF, well, my boss wants me to deliver a feature for OSP2, which we ship on preinstalls and based on 12.04.4. [12:09] RAOF, the feature includes a backend written as a pulseaudio module. So PulseAudio needs to be SRUed, but the module won't be loaded for normal Ubuntu users, so minimal regression risk. [12:10] diwic, hmm, did pulse recently change in precise ? i cant use my BT headset anymore since the last upgrade [12:10] ogra_, when did you upgrade? The last upgrade only concerned 3.5 mm headset jacks IIRC. [12:11] some time last week [12:11] RAOF, so; the easiest way for me right now would be to sidestep SRU rules and just put something into 12.04.4 without caring about future releases [12:11] ogra_, unless someone else has SRUed PulseAudio - the 15.4 upgrade was several weeks ago if not months [12:11] ogra_, maybe kernel regression? [12:12] well, i surely didnt upgrade for a month or so [12:12] yeah, probably [12:12] A2DP still works fine ... [12:13] ogra_, pulseaudio ...15.4 was released into -updates 2013-10-03 [12:13] ah, yeah, i surely upgraded that before then [12:13] and that's the latest [12:14] RAOF, but I'm not sure that's something the SRU team would agree on. I'm not sure what the solution for 14.04 would be at this point; my deadline is for 12.04.4 and upstream has kind of said no to my current way of doing the backend. [12:15] diwic: Does the core pulseaudio *code* change? [12:15] diwic: Or are you just adding an additional module without any other changes? [12:15] Also, what sort of guarantees do we have that the module isn't going to be loaded. [12:15] RAOF, not core pulseaudio code. Only code changes in the module (which isn't loaded). [12:16] RAOF, the guarantee is "the module isn't listed in /etc/default.pa". [12:16] RAOF, the module would still ship in the Pulseaudio package though. Or possibly in a new binary package, if you prefer. [12:16] No, that's fine. [12:17] As long as it's not loaded by default that seems fine. [12:19] RAOF, ok, thanks - would it be okay to shoot you an email when I've uploaded the SRU (which would then contain the new unused module), to have you releasing it into -updates? [12:19] RAOF: hey do you have some time next week? [12:19] I want to prepare lts-saucy [12:19] mlankhorst: Yeah, after Monday I'll be back not-sprinting. [12:20] perfect, I'll prepare everything for upload then [12:20] diwic: Wait - I can release it into -proposed; do you want to skip -proposed entirely? [12:21] RAOF, sure, I can do -proposed verification, if somebody after that releases it into -updates [12:21] diwic: Right, that's fine. [12:22] RAOF, is that you as well? I don't know the details of the shepherding here, I mostly know that I have a deadline ;-) [12:22] diwic: Yeah, that's fine. [12:22] RAOF, ok, thanks a lot! Hopefully I'll finish the SRU some time next week [12:44] tseliot: everything is good otherwise, just tell me once the fixed version is in the release pocket [12:45] didrocks: sure, thanks. I've sent a message to the maintainer to let him know (trying not upset anybody) [12:48] thanks === FourDollars_ is now known as FourDollars [14:25] Mirv: hi! So, it looks like we'll have to cherry-pick the fix for https://bugreports.qt-project.org/browse/QTBUG-35233 into Qt 5.2.0 [14:25] seb128: FYI ^ [14:25] mardy, thanks [14:27] does anyone knows in which condition apt lists packages with no "candidate"? [14:34] cjwatson, Looking at upstart-app-launch's usage of click. It seems like we need two values, the package directory and the path to the manifest. Would it be reasonable to have a "libclick" that did those? [14:35] cjwatson, i.e., still keep the logic in the click package, but just duplicate it in C. [14:35] tedg: I plan to rewrite click in C, hopefully this cycle [14:35] tedg: until then let's not duplicate [14:36] cjwatson, Okay, perhaps a fallback if you find time running short. [14:46] stgraber: is there a preferred way to install a set of packages when creating a container? [15:04] I'd appreciate if some SRU team member could process bug 1257211 today; they fix a data loss bug in postgresql; usual MRE/no packaging changes/upstream+distro tests pass story [15:04] bug 1257211 in postgresql-9.1 (Ubuntu Trusty) "New upstream microreleases 9.1.11, 8.4.19" [High,In progress] https://launchpad.net/bugs/1257211 [15:20] josepht: not really. The next upstream release (1.0 beta1) will introduce a new --packages parameter to the Ubuntu template but until then you're on your own [15:21] stgraber: okay, I added a --packages parameter to the ubuntu template :) [16:00] cjwatson: hey, I just filed this-- not sure you are aware: bug #1258202 [16:00] bug 1258202 in logrotate (Ubuntu) "recent group permissions change on /var/log cause logrotate errors" [Undecided,New] https://launchpad.net/bugs/1258202 === jdstrand_ is now known as jdstrand [16:01] geofft: hola? what's up? [16:04] !-ubottu [16:04] ubottu is ubotu - added by Pici on 2008-05-08 16:09:51 - last edited by Pici on 2008-05-08 16:09:57 [16:04] !-ubotu [16:04] ubotu aliases: yourself, bot, usage, factoid, brain, add, help me, syntax, factoids, everything, me, ubottu, bots, fact, triggers, trigger - added by Seveas on 2006-06-19 12:15:56 - last edited by tsimpson on 2010-09-18 20:14:50 [16:04] barry: Jenkins Notification [16:04] jdstrand: no, perhaps slangasek can pick this up again since he uploaded the original regression? ;-) [16:05] barry: that's the emails I used to get jenkins notifications from. [16:05] * barry searches his folders [16:05] barry: FYI, we used to have notifications for failed autopkgtests, but they've been broken since the DC move [16:05] barry: (jibel knows details) [16:05] aha! [16:06] cjwatson: ah :) === freeflying is now known as freeflying_away [16:06] slangasek: fyi, bug #1258202 [16:06] bug 1258202 in logrotate (Ubuntu) "recent group permissions change on /var/log cause logrotate errors" [Undecided,New] https://launchpad.net/bugs/1258202 [16:06] jdstrand, cjwatson: doh. How did that merge actually cause the regression, anyway? We clearly had rsyslog configured to run as non-root before in the Ubuntu delta [16:06] pitti: ah, okay! it's a shallow bug then :) [16:07] barry: yeah, AFAIK stuck somewhere between firewalling and mail whitelisting [16:07] pitti, jibel cool. at least it's on the radar. thanks [16:08] slangasek: upstream rearranged how privilege-dropping worked, so it now irrevocably set[ug]ids near the start and can't retrieve privileges when creating new log files [16:08] slangasek: don't know. I see that 13.10 livecd has: [16:08] /var/log drwxr-xr-x root root [16:08] slangasek: I really didn't fancy undoing all that === rickspencer3_ is now known as rickspencer3 [16:54] kees: good morning! I'd like to use LD_AUDIT on a setuid binary :-) [16:55] kees: It looks like the disable-ld_audit patch in eglibc is not specifically a CVE fix, but just (worthwhile) paranoia/hardening while upstream got its act together about patching it right? [16:56] Is it possible to drop that patch at this point, or is that totally unreasonable? === salem_ is now known as _salem === _salem is now known as salem_ [17:38] Sweetshark: are there any plans to update libreoffice in Trusty? the package version in saucy-proposed is greater than the one in trusty. [17:39] bdmurray: its complicated [17:39] ;) [17:41] bdmurray: some toolchain updates (likely the usual suspect gcc) made LO 4.1 FTBFS on trusty, so one cant simply bump that. OTOH LibreOffice 4.2 (which we want to have in trusty anyway, but which is still in beta) builds just fine in trusty. [17:44] bdmurray: so I gotta find a way to get 4.1 to build in trusty without wasting too much time on it as nobody will care for that in two weeks anyway. Unfortunately, the breaker seems to be of the nasty kind (its in an external package we build internally in LO, so patching it would mean patching a patch into the build) [17:47] bdmurray: Ill check if we can update mdds to a version building in trusty, and then build LO 4.1 against it (thus not using an internal copy anymore). Using external mdds is would be a good thing anyway (and be worthwhile beyond 4.1) .... [17:47] seb128: ^^ FYI === _salem is now known as salem_ [17:52] Sweetshark: sounds good, thanks === rickspencer3_ is now known as rickspencer3 [19:11] tseliot: the bug number reference in the gnome-desktop3 changelog in the saucy proposed queue is incorrectly formatted which will negatively affect a few things in the SRU process === ajmitch_ is now known as ajmitch [19:58] bdmurray: feel free to reject the upload, and I'll re-upload tomorrow [20:01] slangasek: stgraber: ok, i'm at wits end trying to get dbus across user namespaces to work. it could be a simple issue, i don't know. but my question is: what is an actual advantage to using dbus versus plain unix sockets? [20:02] (to offset (1) 2-4x slowdown, (2) easy threading at the server, and (3) extra dependencies) [20:03] the main advantage I was after was the easy availability of client libraries and using something people tend to be familiar with. Suppport for things like introspection and a well defined set of types, method signatures, ... [20:04] though I'm certainly not against going with our own protocol if DBus simply doesn't cover our needs. As I mentioned, for me backward compatibility is the most important thing, so unfortunately even if DBus could add the features we need, getting that to work on 12.04 will be a pain... [20:05] so I'm personaly fine if we were to go with our own protocol over a raw unix socket. I'd just request that this be a plain text protocol with API versioning support so we don't get into the same kind of problems we had with the lxc monitor protocol (struct mismatch and breakage on upgrades) [20:05] but it was slangasek who suggested going with DBus, so he may have a few more important reasons :) [20:12] stgraber: ok, thanks. yeah it'll be plaintext and i'll add av ersion #. plaintext - except the scm cred of course === rickspencer3_ is now known as rickspencer3 [20:26] hallyn: in general, dbus is nice because it's really easy to map high level APIs down to it. You don't have to do much to get bindings. [20:27] rbasak: i got enough koolaid from the tutorial :) [20:29] rbasak: as stgraber mentioned, high level bindings will take some upstream work bc we need to send scm_crednetials [20:33] tseliot: I went ahead and reuploaded them myself [20:40] I want to start developing for ubuntu, but was wondering if its okay/suggested to develop in 14.04 daily build installation? [20:41] I plan to start all my dev activities on a virtual box having 14.04 daily builds so that my base ubuntu 13.10 stays safe [20:41] any ideas/suggesstions? [20:44] i think severalppl are using 14.04 daily already [20:44] i will be soon [20:48] cool...thanks [20:49] once installed, am i supposed to update/zsync daily? [20:50] hallyn: the fact that dbus is a structured IPC protocol that the rest of the stack is standardizing on... I think doing your own protocol on top of the socket is going to be harder to sell to the wider community [20:50] hallyn: can you give me details on the problems you're seeing with scm_credentials? is it because the dbus library is hating on the extra packets? === Sweetsha1k is now known as Sweetshark [20:58] bdmurray: excellent, thanks a lot :) [20:59] charlie: you can, however if not developing ubuntu itself, I'll recommend you to update once a week on wednesday, or to avoid weekends, canonical employes rest on weekends and you don't want to keep a broken system if you upgrade on saturday or sunday === negronjl_ is now known as negronjl === Logan__ is now known as Logan_ [21:21] slangasek: scm-credentials aren't my problem. I simply can't get a client in a child user namespace to connect to a parent socket in another userns [21:21] ah [21:21] i haven't figured out why yet, [21:21] all I know is that we get just past the AGREE_UNIX_FD, [21:21] and that works with a raw socket? [21:21] client sends BEGIN, server sends some data, then everyone hangs up [21:21] that's nih-dbus [21:21] hmm [21:22] could you show me the code? [21:22] well for simplicity i was using github.com/stgraber/cgmanager, [21:22] but the problem is'nt there, it's in either nih_main_loop or in dbus_connection somewhere [21:23] i tried steppig through the whole process in gdb, all that did was waste 2 hours [21:23] ltrace doesn't get finegrained enough [21:24] slangasek: iiuc the main point of dbus is that it integrates with idiotic junk^W^Wfeatures like policykit [21:24] which we explicitly don't want. [21:24] no, the main point is to provide a generic IPC mechanism that doesn't require reinventing the wheel [21:25] if you're talking about dbus-daemon, then policykit is an interesting feature; but you shouldn't be talking over dbus-daemon in this context [21:25] 'the wheel' is just listen+accept+fire off a thread. it'll be shorter code than with dbus. [21:25] true [21:25] no bus is involved [21:25] do you know the authentication process well enough to know what should happen next after the AGREE_UNIX_FD? [21:26] * hallyn looks back at the 'specification' [21:26] you still have to design your wire encoding for whatever messages you're passing, which is normally busywork [21:27] no, I'm not familiar with AGREE_UNIX_FD at all [21:27] well I guess it's right after http://dbus.freedesktop.org/doc/dbus-specification.html#auth-command-begin === salem_ is now known as _salem [21:31] hallyn: github.com/stgraber/cgmanager seems to only include the server half of the code... what do you have on the client side? And can you give me a recipe to set up a userns for testing? [21:35] slangasek: my branch contains a "client" in its Makefile, basically just a simple call to dbus-send [21:36] stgraber: ah, ok [21:42] slangasek: i also did need to dbus_connection_set_unix_user_function(conn, allow_user, NULL, NULL); where allow_user always returns 0. [21:43] setting up a new vm since last one blew up [21:44] stgraber: bug 1258304 looks like your bag :) [21:44] bug 1258304 in lxc (Ubuntu) "lxc-create fails on IPv6 address" [Undecided,New] https://launchpad.net/bugs/1258304 [21:44] hallyn: yeah, I saw it in my e-mails... I'll take a look once I'm done with my current tests [22:19] hallyn: stgraber: libnih API docs http://libnih.la/ so far just the "nih" lib, will update with "nih-dbus" and "nih-dbus-tool" [22:19] hallyn, stgraber: so, trying this same dbus-send command against upstart gives me the same failure; and we know initctl works [22:19] xnox: thx [22:19] I think the dbus-send invocation is wrong, though I don't know exactly how [22:20] xnox: i'll look at those in awhile when i wanna clean up the code [22:20] hallyn: there still might be mistakes and formatting errors, but most of the things are documented already. + there is libnih tutorial in the upstart cookbook. [22:20] slangasek: against upstart it's probably because we reject from uid > 0. hallyn is actually using a slightly modified version of my branch which allows all uids. [22:20] slangasek: it then works fine as long as you're in the same userns [22:21] hmm [22:21] xnox: yay! [22:21] right, upstart does reject non-root requests on its private socket [22:21] trying to figure out what I'm seeing here, then [22:22] lemme push a branch real quick that works for testing, [22:23] hm, how do i do that :) [22:25] slangasek: i'm testing effectively with github.com/hallyn/cgmanager branch usernstest [22:26] i can run the dbus-send as random users, but not from another user ns. [22:26] the credentials during auth phase all come through ok - [22:27] hmm, ok [22:32] all right i've got dbgsym packages installed, and gdb is showing me line numbers, but i'd like it to show me code as well so i don't have to keep tabbing back to the vim windows. [22:35] hallyn: 'directory /path/to/source'? [22:35] slangasek: and for dbus packages, waht does the path look like? [22:36] hallyn: wherever you have the source unpacked locally :) [22:36] slangasek: oh, i thought the dbg packages used to do some magic so i didn'thave to do that [22:36] ok, thanks