[00:37] <cyphermox_> mbiebl: ack, any time
=== manny__ is now known as mannyv
[02:46] <xnox> cjwatson: infinity: there was something-rather about ppc64el and stuff failing to convert to/from vectors e.g. "could not convert from '__vector(4) __bool int' to 'bool'" seen in latest performous build.
[02:46] <xnox> what was it?
[02:46]  * xnox goes to grep my irc logs
=== superm1_ is now known as superm1
[03:37] <eam> Hi, I'm looking to talk to someone about this linking policy: https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition what is the right forum?
[03:38] <eam> I'm concerned these recommendations result in shared objects unsuitable for loading via dlopen()
[03:39] <eam> The few packages I've examined for interpreted languages which load C stubs appear to completely disregard the build recommendations (which, as far as I can tell is the right approach)
[03:48] <hallyn_> mbiebl_: the systemd-shim patches are up in https://mentors.debian.net/package/systemd-shim
[05:06] <pitti> Good morning
=== zmok is now known as lisca
[06:16] <pitti> hallyn_: still here? do you know why desrt didn't yet push the patches to trunk? because he didn't have time to test them yet, or is there something known-broken still?
[06:22] <Tribaal> hi all, how can I make sure my package (waiting for sponsorship) is following the right procedure?
[06:22] <Tribaal> shoud I just wait?
[06:25] <Noskcaj> Tribaal, link to it?
[06:25] <Tribaal> Noskcaj: https://code.launchpad.net/~tribaal/ubuntu/utopic/ubumirror/1341523-upstream-release/+merge/226654
[06:26] <Noskcaj> The version is normall -0ubuntu1, not ubuntu0
[06:26] <Tribaal> Noskcaj: ok, will fix
[06:26] <Noskcaj> or for this, ubuntu1
[06:27] <Noskcaj> (no -0_
[06:27] <Noskcaj> )
[06:27] <Tribaal> Noskcaj: oh ok
[06:28] <Tribaal> Noskcaj: pushed. Looks better?
[06:29] <Noskcaj> yeah
[06:30] <Tribaal> Noskcaj: so now, I just need to wait for someone to pick it up right? No other steps needed?
[06:30] <Noskcaj> Don't subscribe sponsors to the bug, it has nothing to be sponsored
[06:30] <Tribaal> Noskcaj: oh?
[06:30] <Noskcaj> And they are auto-subscribed to the branch
[06:31] <Tribaal> Noskcaj: what do you mean? sponsorship is not needed for branches?
[06:31] <Noskcaj> The sponsors team is subscribe to a merge (the branch) which is different to the bug
[06:32] <Tribaal> ah
[06:32] <Tribaal> ok
[06:32] <Noskcaj> You would subscribe them to the bug if you were using a debdiff
[06:32] <Tribaal> Noskcaj: ahhh ok
[06:32] <Tribaal> Noskcaj: so, that explains the double entry in http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html I suppose
[06:33] <Noskcaj> yep
[06:33] <Tribaal> ok, I'll unsbscribed them then
[06:34] <Noskcaj> You mention the a few bugs are fixed in this release. If they are shown at https://bugs.launchpad.net/ubuntu/+source/ubumirror , you should probably close them in the changelog
[06:34] <Noskcaj> The packaging could have a minor update too, but it's less important
[06:35] <Tribaal> Noskcaj: I don't understand your packaging minor update remark
[06:36] <Noskcaj> standards-version should be bumped to 3.9.5, debhelper version to 9, remove the upstream-vcs link
[06:37] <Tribaal> Noskcaj: will do.
[06:37] <Noskcaj> ok
[06:39] <Tribaal> Noskcaj: pushed. Should look better
[06:40] <pitti> xnox: hm, I still have rtc in /etc/modules in my just freshly upgraded VM; I thought you fixed that already?
[06:42] <Noskcaj> Tribaal, Use http://paste.ubuntu.com/7802062/ as you changelog. You should try to cover everything changed.
[06:43] <Tribaal> Noskcaj: should I set myself as maintainer?
[06:43] <Noskcaj> yeah. It seems that you are
[06:43] <Tribaal> Noskcaj: fair enough
[06:45] <Noskcaj> d/copyright could probably be improved, but that's an issue for another day
[06:45] <Tribaal> Noskcaj: pushed.
[06:45] <Tribaal> Noskcaj: yes, I'll update upstream as well (there is a lot of things to do there still :) )
[06:45] <Tribaal> like adding man pages
[06:46] <Noskcaj> ok. I suggest you use lintian to find these packaging issues in future. it helps a lot
[06:46] <Noskcaj> Now we wait for someone with upload rights (i.e. not me) to look at the package
[06:47] <pitti> hallyn_, desrt: ah, I was wondering why there was only one systemd cgroup, and all processes are in that -- seems systemd-shim should grow a dependency to cgmanager now
[06:48] <Tribaal> Noskcaj: ah, yes, thanks for the tip about lintian
[06:48] <Tribaal> Noskcaj: I should have thought of it mysellf
[06:48] <Tribaal> Noskcaj: thanks a lot for you help
[06:49] <pitti> stgraber, hallyn_, desrt: so this can't go to Debian yet as cgmanager isn't in Debian -- do you plan to upload it there?
[06:50] <pitti> stgraber, hallyn_, desrt: oh, it's already in the NEW queue
[06:51] <pitti> splendid!
[06:56] <pitti> hallyn_, desrt: one nitpick is that it doesn't seem to clean up sessions on logout, I suppose because cgroup_unit_stop() isn't implemented?
[07:00] <pitti> hallyn_: I uploaded https://launchpad.net/ubuntu/+source/systemd-shim/6-3ubuntu1 with the added dependency
[07:01] <pitti> hallyn_: I think the next steps are to implement cgroup_unit_stop(), merge this into trunk, release 7, and upload that to Debian as soon as cgmanager gets out of NEW
[07:02] <pitti> hallyn_: FYI, http://people.canonical.com/~pitti/tmp/systemd-208/
[07:50] <Noskcaj> pitti, debian now has upower 0.99. Any progress on porting python-dbusmock?
[07:51] <Noskcaj> This shall be a mess
=== psivaa-off is now known as psivaa
[07:52] <pitti> Noskcaj: still on my ever-growing TODO list; but I suppose it's a very simple fix, I already had it working with 0.99
[07:52] <Noskcaj> ok
[07:53] <Noskcaj> We're still waiting on the ubuntu-touch team, so it's not super urgent here, only "be done by 14.10" if you can
[07:59] <pitti> yes, that should be no problem at all
[08:12] <xnox> pitti: we didn't remove it on upgrades in the end. It's not added on fresh installs I think.
[08:12] <xnox> pitti: or did it get _added_ on upgrades?!
[08:12] <pitti> xnox: no, I think just not removed
[08:13] <xnox> ack.
[09:09] <pitti> xnox: no, I think just not removed
[09:10] <pitti> xnox: sorry, -EFOCUS
[09:20] <LocutusOfBorg1> xnox, thanks
[09:22] <LocutusOfBorg1> and also thanks to cjwatson ;)
[09:23] <LocutusOfBorg1> I think the libav transition is getting almost done, right? ;)
[09:23] <cjwatson> See my recent comments in #ubuntu-release
[09:23] <cjwatson> (on irclogs.u.c if you don't have scrollback)
[09:24] <cjwatson> It's definitely close, but still a couple of tricky bits
[09:33] <pitti> hallyn_, stgraber: current phone boots/works fine with updated shim and systemd 208 as well \o/
[09:35] <LocutusOfBorg1> wonderful!
[09:36] <pitti> mbiebl_: so yay, it seems systemd 208 is finally unblocked, once cgmanager makes it through Debian's NEW queue
[09:37] <cjwatson> \o/
[09:37] <pitti> mbiebl_: >= 205, I mean
[09:52] <Laney> pitti: would you be able to run `edit-acl -p xubuntu-uploaders -S trusty -P xubuntu add' please?
[09:54] <pitti> Archive Upload Rights for xubuntu-uploaders: archive 'primary', package set 'xubuntu' in utopic
[09:54] <pitti> Archive Upload Rights for xubuntu-uploaders: archive 'primary', package set 'xubuntu' in trusty
[09:54] <pitti> Laney: ^ done
[09:54] <Laney> thank you!
[09:54] <pitti> yw!
[09:54] <Laney> bluesabre: ^^^
[09:54] <bluesabre> thanks pitti and Laney :D
[09:57] <Noskcaj> Would anything break if http://people.canonical.com/~platform/desktop/ubuntu-desktop.html was patched to us packages.qa.debian.org/package rather than packages.qa.debian.org/p/packages.html ?
[09:57] <Noskcaj> all lib links are broken because of how this is coded
[09:58] <pitti> no, nothing should break; I think this is seb128's code
[09:58] <Noskcaj> Would in be too early to swap to tracker.debian.org?
[10:02] <seb128> Noskcaj, pitti: code is  lp:ubuntu-desktop-versions and patches are welcome
[10:02] <Noskcaj> seb128 i'm pushing a fix for lib links not working
[10:03] <Noskcaj> and was wondering if we should swap to tracker.debian.org
[10:03] <seb128> what is the difference/why would it be better?
[10:04] <Noskcaj> It's the replacement to packages.qa.debian.org .
[10:04] <xnox> seb128: tracker.debian.org is the sexy new replacement for packages.qa.debian.org
[10:04] <Noskcaj> I'll find the "official" list of why it's better
[10:04] <xnox> seb128: it literary blown my mind away when i saw it for the first time =)
[10:04] <seb128> xnox, seems quite similar to be from a content perspective
[10:05] <xnox> seb128: yeah, content is the same, it's just eye-candy =)
[10:05] <pitti> yeah, it almost has the same information; I'm missing the suites in the upload list, though
[10:05] <seb128> I find it less easy to read/parse
[10:06] <seb128> Noskcaj, no objection from me to the change in any case
[10:06] <xnox> it's python/django vs perl
[10:07] <seb128> yeah, I guess as any change it takes some getting used to
[10:07] <Laney> it's mean to be reusable for derivatives / more modular, IIUC
[10:07] <Laney> meant
[10:08] <Noskcaj> I'll put the first merge up tonight, it's past "computer off time"
[10:08]  * pitti files a bug about getting the suites back
[10:08] <Noskcaj> g'night
[10:08] <seb128> Noskcaj, night
[10:09] <pitti> ah, debian bug 754805
[10:09] <ubottu> Debian bug 754805 in tracker.debian.org "tracker.debian.org: no info about where the package has been "accepted" (e.g. unstable or experimental)" [Normal,Open] http://bugs.debian.org/754805
[10:09] <cjwatson> mm, I don't think the all-white thing is an improvement, I find it harder to scan visually
[10:09] <cjwatson> but I guess that's just CSS so I suppose I can userstyle it if I really care
[10:11] <pitti> yeah, the red title bars made the various boxes visually easier to find and tell apart
[10:11] <seb128> +1
[10:11] <seb128> that's what I meant by "
[10:11] <seb128> "I find it less easy to read/parse"
[10:13] <pitti> Noskcaj: so dbusmock's upower tests still succeed here with upower from trunk; I'll check your PPA
=== doko_ is now known as doko
[10:17] <doko> Mirv, seb128: please don't upload no change rebuilds with a new ubuntuN suffix. All these uploads should have a buildN suffix if no ubuntuN suffix exists. seen for your Qt3 uploads in June
[10:17] <xnox> seb128: cjwatson: pitti: there is a bug filed about "too white washy look" asking to bring back the debian magenta colours.
[10:17] <seb128> doko, qt3? me?
[10:18]  * xnox we have qt3 in the archive?.... sounds like a bug
[10:18] <doko> qt5 then, anyway
[10:19] <seb128> I've uploaded qt5?
[10:19] <cjwatson> With Qt5 it really helps to actually name the full source package
[10:19] <cjwatson> Since there are quite a few of them
[10:20] <seb128> doko, not sure what you are talking about there, can you give some specifics?
[10:20] <xnox> doko: what's the source package name? quite a few qt packages are "forked" from debian and thus it starts off with 0ubuntu1 and hence no way to use "binNMU suffix" upon no change rebuilds. Plus there are gazzilion of qt5 src packages....
[10:24] <doko> xnox, seb128, Mirv: at least gammaray, but there seem to be more
[10:24] <seb128> doko, I've nothing to do with that upload
[10:25] <doko> fcitx-qt5
[10:25] <seb128> doko, that one is in sync
[10:26] <seb128> doko, did you actually mention my name because of an upload I did or was that an error?
[10:26] <xnox> doko: right that looks like the set of things that Mirv mass-rebuild in a huge ppa/train landing.
[10:26] <seb128> not sure what youa re trying to blame me for there
[10:26] <xnox> doko: I guess Mirc didn't know about $ dch -r at the time, nor any of the people who approved all of those uploads.
[10:29] <cjwatson> -R
[10:29] <Mirv> doko: yes, there's a filed bug about not forgetting about those
[10:30] <Mirv> fcitx-qt5 was fixed by another sync from Debian, gammaray is still there
[10:30] <Mirv> it was actually a last minute decision to not care about that smallish issue to not delay the landing, but it was spotted
[10:33] <Mirv> now there seems to have been another gammaray release in debian today, so that could be synced to fix bug #1332143 for good
[10:33] <ubottu> bug 1332143 in gammaray (Ubuntu) "Sync again from Debian some time after Qt 5.3 landing" [Undecided,New] https://launchpad.net/bugs/1332143
[10:44] <xnox> cjwatson: does "memmove (e, e + 1, (char *)(*env + *len) - (char *)e);" look safe? or what was the glibc saga w.r.t. memory moves & copies being backwards and thus overriding src before it got copied to dst?
[10:44] <cjwatson> the thing you're referring to was with code incorrectly using memcpy rather than memmove, or equivalent
[10:45] <cjwatson> that looks safe although those casts look clumsy and I'm sure it's possible to do better
[10:45] <cjwatson> may not be very performant
[10:46] <cjwatson> obviously haven't checked the lengths
[10:46] <cjwatson> presumably (*env + *len) and e are part of the same object otherwise the pointer arithmetic is undefined
[10:49] <xnox> cjwatson: ah, ok.
[10:49] <xnox> jodh: ^
[10:54] <zyga> pitti: ping
[10:54] <zyga> pitti: are you still the best person to talk to about i18n in ubuntu?
[10:54] <pitti> hello zyga
[10:54] <zyga> pitti: I have a problem and a proposed solution but I'm looking for advice and feedback
[10:54] <pitti> zyga: I don't think there is "a" best person, we haven't had a designated i18n maintainer for years
[10:54] <zyga> pitti: ok :-)
[10:55] <zyga> pitti: I'll take that as yes anyway :D
[10:55] <pitti> so probably best to just ask here
[10:55] <zyga> pitti: so, there idea is as follows, we'd like to build search indices along with some of our packages, so that after installation apps can load package data (think of it as pluggable levels in a game) and search without having to reindex
[10:56] <zyga> pitti: now the caveat, we want that to be i18n, we have translations for everything in gettext and we could build localized search indices at package build time
[10:56] <lifeless> pitti: i18n is a 'solved problem' :)
[10:57] <zyga> pitti: to do that correctly though, I think, we'd have to get the locale for each supported language and maintain that as a part of our package, we'd also ship all the translations as a part of the "level/add-on" package
[10:57] <zyga> pitti: I was looking for any suggestions or any best practices to look at
[10:57] <pitti> (will read in a bit, need to empty brain state)
[10:57] <zyga> pitti: thanks!
[11:03] <pitti> zyga: why do you need the locale? do you need time/date/monetary formatting in there? For just gettext() having the mo or po files is sufficient
[11:04] <pitti> zyga: and intltool-extract/intltool-merge even support that kind of operation for common formats
=== MacSlow is now known as MacSlow|lunch
[11:23] <zyga> pitti: I don't think we need any of the locale features you've mentioned, you are right, we can just load those translations directly, using python, and generate the index this way
[11:24] <zyga> pitti: still, we'll end up with translated index (or one larger index with translations, haven't though if we should try that yet)
[11:44] <mapreri> It's more than 30 hours since last merge-o-matic update. What's up?
[11:44] <mapreri> cjwatson: ↑
[11:45] <cjwatson> mapreri: poked
[11:46] <mapreri> cjwatson: thanks
[11:46] <cjwatson> dpkg-source's new strictness on patch headers has had a lot of sequential fallout as people gradually fix packages
[11:46] <cjwatson> each time there's a fix merge-o-matic tries to diff against the old version and finds it can no longer unpack it
[11:47] <cjwatson> so I have to go and nuke the old version out of the pool
[11:48] <mapreri> umh, ok
[11:52] <cjwatson> mapreri: I've at least arranged for it to mail me about failures now
[11:52] <cjwatson> (Hadn't done that before because it was too noisy on success, but I think I've fixed that now)
[11:53] <mapreri> cjwatson: at leas I don't need to poke you every time (I think this is the 3rd) :)
[11:54] <cjwatson> Yeah, assuming the mail path works, this way I should actually notice
=== psivaa is now known as psivaa-lunch
[12:17] <xnox> mvo_: would you like to steal my aptitude merge? =)
[12:18] <mvo_> xnox: sure
[12:18] <mvo_> (famous last words I guess)
[12:18] <xnox> mvo_: that would be amazing, thanks =)
[12:18] <xnox> mvo_: well, it's not that bad. It's hardly console-setup merge ;-)
[12:18] <mvo_> haha, yeah, its not quite of epic proportions yet :P
[12:22] <cjwatson> mapreri: Excellent, failure mails work
[12:23] <mapreri> cjwatson: \o/
=== _salem is now known as salem_
[12:25] <cjwatson> mvo_: Just thinking about how to backport your apt/trusty upload to precise for use on the production publisher - has the libapt-pkg ABI really not changed since precise?  That would be handy if so
[12:26] <cjwatson> mvo_: I'm thinking that we could leave both libapt-inst1.4 and libapt-inst1.5 installed, and so not have to rebuild python-apt
[12:30] <Saviq> pitti, hey, do you know if -dbgsym packages were supposed to (or could) be available in the silo PPAs?
[12:31] <mvo_> cjwatson: I think this would work, but I can look into doing a real backport of this feature to precise. my understanding was that a upgrade to trusty was planed and thats why I stopped pursuing the backport
[12:31] <cjwatson> mvo_: I'd rather upgrade this independently; usually the apt-ftparchive upgrade is the riskiest part of the publisher upgrade
[12:31] <cjwatson> mvo_: Given that we're targeting trusty anyway, we could just as well use this as the next best thing to a proper SRU verification
[12:32] <cjwatson> And then upgrade the publisher systems to trusty a bit later
[12:33] <cjwatson> That will take longer though - we'll probably want a trusty buildbot, we'll need to upgrade dogfood, and there are some other bits and bobs
[12:33] <cjwatson> And we probably ought to finish the precise upgrade everywhere first :)
[12:34] <mvo_> cjwatson: ok, that makes sense. I can double check the abi again, but I don't think we broke it.
[12:35] <caribou> Q: When applying a debdiff that removes a quilt patch, is it mandatory to "quilt pop -a" first before applying the debdiff ???
[12:35] <caribou> I have a case where debuild complains of locally modified files if I don't unapply the quilt patches before
[12:35] <cjwatson> caribou: It's the path of least confusion
[12:36] <caribou> cjwatson: so there is no upfront mandatory procedure then
[12:36] <caribou> cjwatson: i.e. what I am doing of unapplying the patches first is correct
[12:37] <caribou> cjwatson: so when I ask for sponsoring of that debdiff, the sponsor will not come back at me saying "your debdiff doesn't apply unless I unapply the other patches first"
[12:38] <cjwatson> Sounds fine
[12:39] <caribou> cjwatson: thanks
[12:58] <cjwatson> Saviq,pitti: Should be.  Is this the same as the question tvoss asked on #ubuntu-ci-eng?
[12:59] <pitti> Saviq: yes, PPAs can be configured to produce dbgsyms, they will be right in the PPA repo then
[12:59] <pitti> Saviq: I don't know how exactly (if you don't see it in the PPA config page), infinity will know then
[13:00] <cjwatson> pitti: I've checked, they're all configured right and I see output for at least some silos
[13:00] <cjwatson> Which is why I'm asking if it's the same question 'cos then I don't have to track down the details twice because people had a conversation elsewhere and then asked two separate people in two different channels at about the same time ;-)
=== greyback is now known as greyback|lunch
[13:15] <mvo_> xnox: almost done with aptitude, why did you add dh-autoreconf? if it needs to be there I would like to put a rational in the changelog :)
[13:16] <mvo_> (or drop it to keep the delta small)
[13:17] <xnox> mvo_: most likely added during bootstraps of arm64 & ppc64el.
[13:17]  * xnox reads diff
[13:18] <xnox> mvo_: wait. I have added patches that modify configure.ac (the cherrypicks for boost1.53 compat) and thus hence had to use dh-autoreconf to get them working.
[13:18] <xnox> aptitude-0.6.8.2/debian/patches/0002-support-again-Boost-1.53.patch
[13:18] <mvo_> xnox: aha, good. so I can drop it, thanks
[13:18] <mvo_> xnox: the fixes for boost are upstream now
[13:45] <hallyn_> pitti: hi, systemd-shim isn't handling Stop right now, but the sessions are being removed on (on my systems) because cgmanager is setting remove-on-empty
[13:46] <hallyn_> oh, is Stop a forcible kill of the session?
[13:46] <pitti> hallyn_: hm, not here; I tried with "ssh test@localhost", that adds sessions but doesn't clean them up
[13:46] <pitti> hallyn_: depends, that's configurable (we don't enable it by default)
[13:47] <hallyn_> pitti: I bet your system has cgroup-lite installed, or it otherwise pre-mounted the cgroups before cgmanager started.  in that case cgmangaer won't do autoremove
[13:47] <hallyn_> (since it doesn't watn to step on toes)
[13:47]  * pitti boots VM to check
[13:48] <pitti> hallyn_: no, not installed (it's pretty much a stock utopic install with new shim and systemd only)
[13:49] <pitti> hallyn_: I also get this when logging in a new user on tty1, checking with "loginctl", logging back out, and checking loginctl again under X
[13:49] <hallyn_> pitti: running upstart?
[13:49] <pitti> hallyn_: upstart
[13:50] <pitti> hallyn_: so user-1001.slice/session-c2.scope cgroup does get removed
[13:50] <pitti> hallyn_: user-1001.slice stays around
[13:50] <hallyn_> pitti: can you set cgmanager_opts="--debug" in /etc/default/cgmanager, reboot the vm, and pastebin /var/log/upstart/cgmanager.log?
[13:50] <hallyn_> oh, ok
[13:50] <pitti> hallyn_: but it doesn't disappear from logind
[13:50] <hallyn_> yeah,
[13:50] <pitti> hallyn_: I think this might just be because the notify_on_removal callback doesn't work?
[13:50] <hallyn_> that's actually bc the way desrt did it he made the slices not their own
[13:50] <hallyn_> "thing"
[13:50] <pitti> hallyn_: so I think that the cgroup itself is removed fine, just logind doesn't get to kknow
[13:51] <hallyn_> oh, ok
[13:51] <hallyn_> hm.  then yeah i guess we need stop.
[13:51] <hallyn_> does logind need to get  JobRemoved ffor the StopSession?
[13:51] <hallyn_> and, pardon my terminology - will it be a StopTransientUnit method?
[13:51] <pitti> I also still have /run/systemd/sessions/c2
[13:51] <hallyn_> yeah bc the logind upstart job created /run/systemd
[13:52] <pitti> hallyn_: I don't know exactly, but I think that's just StopUnit
[13:52] <hallyn_> or, no.
[13:52] <hallyn_> ok
[13:52] <hallyn_> pitti: I"ve promised to do some other things today, but will try to get to StopUnit asap
[13:52] <pitti> hallyn_: it's not a big deal, it just caught my eye (as sessions will pile up in logind)
[13:52] <hallyn_> desrt's code was so clean that at this point it should be pretty simple
[13:52] <pitti> hallyn_: for now, this is working very nicely already, great work!
[13:53] <pitti> hallyn_: it works well on the phone too, so we can certainly land that soon
[13:53] <pitti> that == systemd 208 (and 214, which is being prepared in Debian)
[13:53] <hallyn_> awesome :)
[13:53] <hallyn_> well, here's teh sad part, i assume 214 will need a patch to systemd-shim
[13:54] <hallyn_> bc somewhere between those the StartTransientUnit message format changed
[13:54] <hallyn_> to add an (always empty) aux segmenet
[13:54] <hallyn_> segment
[13:54] <pitti> hallyn_: in the message signature?
[13:54] <pitti> hallyn_: that would be fine, it could offer both signatures
[13:54] <pitti> s/message/method/
[14:00] <hallyn_> pitti: oh, ok - i dont' know how to do that, but cool.
[14:00] <hallyn_> that's for the message from logind to systemd-shim, nto the other way around
[14:01] <pitti> hallyn_: it just adds two methods, one with each signature (like in C++)
[14:01] <pitti> hallyn_: but anyway, that's not critical for now; I think we first want to go to 208 as that's reasonably well tested in Debian already
[14:01] <pitti> there's little reason to get ahead of Debian (even 204 is working well enough)
[14:03] <hallyn_> cool
=== Ursinha is now known as Ursinha-afk
[14:06] <mbiebl_> hallyn_, pitti: should I poke an ftp-master regarding cgmanager?
[14:06] <pitti> mbiebl_: can't hurt, especially now that 208 is in unstable
[14:07] <pitti> mbiebl_: I was quite surprised, doesn't this effectively break logind for every sysvinit user?
[14:07] <mbiebl_> pitti: and thanks for the reminder regarding the session cleanup
[14:08] <hallyn_> mbiebl_: maybe ping slangasek ?
[14:08] <cjwatson> hallyn_: Steve isn't a Debian ftpmaster
[14:08] <hallyn_> oh, i thought he was
[14:09] <hallyn_> that is, i thought he said he was a few days ago.  mustve misunderstood
[14:09] <cjwatson> hallyn_: https://www.debian.org/intro/organization#distribution
[14:09] <cjwatson> he's an archive admin in Ubuntu
[14:11]  * hallyn_ educates himself
[14:12] <hallyn_> xnox: see debian bug 754910 - looks like the work we did yesterday may turn out in vain
[14:12] <ubottu> Debian bug 754910 in wnpp "ITP: cgmanager" [Wishlist,Open] http://bugs.debian.org/754910
[14:13] <mbiebl_> hallyn_: oh, luca just told me that both were kicked
[14:14] <hallyn_> that's productive
[14:15]  * hallyn_ grumbles and goes to do some btrfs coding for lxc
[14:15] <pitti> hm, Daniel's upload was much older
[14:16] <pitti> but hallyn filed the ITP, dbm's didn't even have an ITP
[14:16] <pitti> both seem good reasons to take hallyn_'s *shrug*
[14:17] <mbiebl_> grml
[14:17] <hallyn_> I don't undestand why he'd want to go this route
[14:17] <mbiebl_> it's not like daniel hasn't enough packages already...
[14:18] <hallyn_> his is far too old to suffice for systemd-shim...
[14:18] <hallyn_> oh well.
[14:19] <pitti> so changing the owner back to hallyn_ and reuploading seems appropriate to me
[14:19] <pitti> pwning someone else's ITP isn't exactly polite
[14:21] <DktrKranz> the problem is daniel's upload predates the ITP
[14:22] <hallyn_> replied to the itp
[14:23]  * pitti sent a grumbling, but restrained followup too
[14:24] <xnox> I'm failing at my command-line & emacs skills. I've downloaded an email in mbox format and now want to reply to it, how do I do that?
[14:24] <pitti> DktrKranz: yes, but that's dbm's problem, not hallyn_'s
[14:24] <pitti> that's what ITPs are for, so that other people know that you are working on something
[14:24] <xnox> DktrKranz: he hasn't filed ITP.
[14:24] <xnox> DktrKranz: and he is not the best maintainer of the two.
[14:24] <hallyn_> xnox: usually 'mutt -f <file>' works, unless you need to re-add the From: line above each msg
=== greyback|lunch is now known as greyback
[14:25] <xnox> hallyn_: i've never used mutt =)
[14:25] <pitti> $ cat ~/bin/mutt_open_mbox
[14:25] <pitti> #!/bin/sh
[14:25] <pitti> exec gnome-terminal -x mutt -f "$1"
[14:25] <pitti> that's my handler in firefox for the "mbox" links in Debian bugs
[14:25] <pitti> quite nice
[14:25] <xnox> would that open emacs for me to type reply & email it via my smtp?!
[14:26] <pitti> xnox: well, it's just an mbox -- any MUA should be able to read that?
[14:26] <xnox> The program 'mutt' can be found in the following packages:
[14:26] <xnox>  * mutt
[14:26] <xnox>  * mutt-patched
[14:26] <xnox> Try: sudo apt-get install <selected package>
[14:26] <pitti> xnox: well no, it's calling mutt
[14:26] <pitti> xnox: feel free to adjust to emacs, of course :)
=== Ursinha-afk is now known as Ursinha
[14:30] <hallyn_> one of these days i want to spend a day using emacs for email.  just to get comfy with it
[14:30] <hallyn_> (like i did with ed :)
[14:30] <DktrKranz> xnox: I fully agree with both, but if we had accepted the package before hallyn_, we would have been lost anyway
=== hallyn_ is now known as hallyn
=== psivaa-lunch is now known as psivaa
[14:45] <stokachu> bdmurray, ping
[14:51] <loa> xnox, hello. Did you check that bug about degraded raid?
[14:54] <xnox> loa: nope. Will do soon, working on mdadm 3.3 update.
[14:56] <loa> xnox, with fixes for that?
[14:58] <xnox> hallyn: pitti: i have also replied to that bug.
[14:59] <loa> xnox, who are you? you dev from ubuntu?
[15:00] <loa> work on mdadm looks very important.
[15:00] <xnox> loa: nah, i'm nothing special.
[15:01] <loa> but why always all go around you? :D
[15:01] <xnox> loa: i simply idle on irc too much. that's all.
[15:01] <loa> idle? Spending too much time here?
[15:02] <xnox> pitti: hallyn: in the end, i've opened the mbox file in thunderbird and hit reply button =)))))
[15:06] <hallyn> xnox: whatever works :)  the worst is when mail archive mbox files need to be massaged in perl before you can open them.
[15:09] <xnox> hallyn: on my books "massaged in perl" is a rare fetish i have never participated in =)
[15:09] <hallyn> missing out, dude :)
[15:09]  * hallyn back to btrfs
[15:16] <bdmurray> stokachu: hey
[15:39] <achiang> hi, when doing an apt-get install of a package, i notice that during the installation, apt wants to remove another package (modemmanager), which is almost certainly a bug. how do i track down why this package is marked for removal?
[15:40] <cjwatson> apt-get -o Debug::pkgProblemResolver=true, usually
[15:40] <achiang> i mean, it's obviously a conflicts or something like that, but i can't figure out which new package is causing the conflict
[15:40] <achiang> ah
[15:40] <achiang> thx
[15:40] <cjwatson> output is a bit opaque but for something like this it should be decipherable
[15:41] <achiang> hm, no, that didn't seem to help - http://pastebin.ubuntu.com/7804018/
[15:46] <cjwatson> urr.  at this point I'd either swear and break out grep-dctrl, or invoke mvo
[15:47] <Laney> aptitude time ;-)
[15:49] <roadmr> achiang: hm, ofono is in your list of packages to install, and it directly Conflicts: modemmanager
[15:50] <seb128> achiang, you can try to "apt-get install ubuntu-sdk modemmanager" and see the output
[15:50] <cjwatson> oh yeah, that's a good idea too
[15:50] <seb128> but it's likely going to get down to what roadmr said
[15:50] <achiang> roadmr: duh, i didn't see ofono in there.
[15:50] <roadmr> achiang: -o Debug::pkgDepCache::AutoInstall=true will show you how ofono came to be in your list of packages to install
[15:51] <achiang> thanks for the better eyes
[15:51] <roadmr> achiang: :D glad my tired, squinty eyes could help :D
[15:54] <achiang> roadmr: ah, that debug line is very helpful, thank you
[15:55] <achiang> http://pastebin.ubuntu.com/7804068/
[15:55] <achiang> lines 259, 260...
[15:59] <smoser> anyone able to tell me what i'md oing wrong
[15:59] <smoser>  http://paste.ubuntu.com/7804080/
[15:59] <smoser> seems gpg --verify has race conditions in it.
[16:09] <smoser>  http://paste.ubuntu.com/7804138/
[16:09] <smoser> ^^ cleaned up a bit.
[16:39] <sandstrom> Anyone know how I can find Boris Ostrovsky on irc? (https://launchpad.net/~boris-ostrovsky)
=== tgm4883_ is now known as tgm4883
[17:35] <mbiebl_> Noskcaj: hi, can you please prep a new release for xfce4-systemload-plugin for upower 0.99
[17:36] <mbiebl_> all that seems to be missing is a dch -r
[17:36] <mbiebl_> Please update svn accordingly and/or point me to a .dsc
=== roadmr is now known as roadmr_afk
=== snk_ is now known as Guest96684
=== dpm is now known as dpm-afk
=== roadmr_afk is now known as roadmr
=== alexisb is now known as alexisb_lunch
=== dpm-afk is now known as dpm
[21:10] <rbasak> dannf: your fix for 1324992 looks fine. I'll modify your changelog entry to 1.1.5-3ubuntu3.1 as well, shall I, and upload to Trusty, as Utopic and Trusty are currently identical?
[21:10] <rbasak> (upload to Trusty also)
[21:35] <Noskcaj> Could someone please retry django-celery? I think the build failure has been fixed by a newer version of celery that we now have
=== alexisb_lunch is now known as alexisb
=== salem_ is now known as _salem