=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
[00:41] <msx> hi all, sorry to bother here but I'm unable to find the answer anywhere else: i'm looking for a clean way to close the session (logout) from the command line. gnome-session-quit wont work, nor the dbus method shown here: http://askubuntu.com/questions/15795/how-can-you-log-out-via-the-terminal. Also, I don't want to just 'sudo reboot' but a nicier, more polite method so all running application can
[00:41] <msx> safely end it's ongoing stuff and then end. Any idea?
[01:25] <dobey> msx: most applications can't/don't use proper session management, and if they did, they should handle SIGTERM correctly anyway. so i'd say "sudo reboot" is about as "nice" as it's going to get realistically
[01:31] <hallyn> hm, neither the precise nor trusty server cd isos are installable right now;  stops at kernel modules not being compatible
[01:36] <msx> dobey: hey! well, i noted that quiting a session when using Unity web brosers will close cleanly while using any other method they will offer to recover. If i'm not mistaken I think Unity someway passes a SIGHUP signal while powering off or restarting X just sends a SIGTERM signal, hence the difference
[01:37] <msx> sarnold told me about d-feet, a dbus browser so i'm looking into this path right now...
[01:43] <dobey> i don't know what the browsers do exactly. i don't think they get a SIGHUP though
[01:44] <msx> dobey: hmm, okay, i'm fairly new to the way how GUI apps interact with the system, will look upon that, thanks!
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== timrc is now known as timrc-afk
[02:19] <robert_ancell> cjwatson, who maintains ubiquity now?
[03:48] <pitti> Good morning
[04:59] <ion> that
[07:09] <dholbach> good morning
[07:11] <mvo_> hey dholbach
[07:12] <dholbach> hi mvo_
[07:26] <cjwatson> robert_ancell: well, it's been somewhere between xnox and me for a while, mostly xnox - I guess "foundations" is the answer
[07:27] <robert_ancell> cjwatson, there was a proposal to update metacity to 3.12 - that's used in ubiquity right?
[07:27] <robert_ancell> What's the best way to check 3.12 is good to go in?
[07:29] <cjwatson> robert_ancell: ubiquity just uses it as a simple wm; about all it does is set org.gnome.metacity.compositing-manager to true, run metacity --sm-disable, and then expect it to manage windows
[07:29] <cjwatson> robert_ancell: if it works as a window manager with compositing switched on then I'd say we're fine
[07:30] <robert_ancell> cjwatson, oh good - org.gnome.metacity.compositing-manager defaults to true now. That was the main point I wanted to check
[07:47] <cjwatson> robert_ancell: yup, should be fine
[07:47] <robert_ancell> cjwatson, ta
[07:52] <jibel> mvo_, hey, could you have a look at bug 1348067 ? this is an upgrade from precise to trusty
[07:52] <ubottu> bug 1348067 in update-manager (Ubuntu) "update-manager crashed with TypeError: pulse() takes exactly 1 argument (2 given)" [Medium,New] https://launchpad.net/bugs/1348067
[07:57] <mvo_> jibel: is this new?
[07:58] <mvo_> jibel: sure, I have a look
[08:03] <jibel> mvo_, it seems to be relatively new. I found only 1 bug report, reported yesterday and I reproduced it this morning
[08:04] <mvo_> jibel: thanks, and it happens when the user clicks on the "upgrade" button in the main ui?
[08:09] <jibel> mvo_, it happens when the user clicks 'upgrade' on the release announcement dialog
[08:10] <mvo_> jibel: thanks, I'm upgrading my precise vm just now and investigate!
[08:11] <jibel> argh and then ubuntu-desktop fails to upgrade :/
[08:21] <cjwatson> sarnold: Sorry to nag, but librevenge?  I really want to stop proposed-migration taking 25 minutes per run due to thinking really hard about libav every time :)
[08:40] <mvo_> jibel: its confusing, neither python-apt nor apt has changed in this area recently :/
=== shuduo is now known as shuduo_afk
[09:25] <xnox> cjwatson: well, we can't use metacity 3.12, until unity7 is ported to gtk3 & metacity 3.12. Or is robert implieying that was done now?
[09:25]  * xnox checks
[09:27] <ev> cjwatson: oh hi. Rumour has it that you got jemjem to work with the x86 emulator. I can't seem to find a branch on LP with this, though.
[09:27] <cjwatson> ev: err that was ages ago and almost certainly stale
[09:28] <ev> boo hiss
[09:28] <cjwatson> ev: I thought it had been superseded by xnox's branches
[09:28] <cjwatson> pretty sure I pushed something somewhere but let me check
[09:28] <xnox> =)
[09:28] <xnox> ok.
[09:29] <cjwatson> ev: I was basically using lp:~xnox/ubuntu-test-cases/touch-emulator plus https://code.launchpad.net/~cjwatson/ubuntu-test-cases/python3 I believe
[09:29] <cjwatson> ev: After I did that I heard that that had been superseded by some similar branches somewhere else, but I never rebased
[09:31] <ev> ah, so has jemjem changed along the way? It started out as a juju charm, but this is decidedly not.
[09:32] <ev> background> I'm trying to see what the state of nested kvm is as it relates to the touch emulator running on openstack. I appear to be missing a few gl packages in the server cloud image, and it's not obvious what remains after manually installing a lot of mesa.
[09:32] <cjwatson> I'm not sure I ever used jemjem as such
[09:32] <cjwatson> Just some of the code that went into it
[09:33] <cjwatson> At the time I was experimenting with getting autopkgtest working on top, but I don't think I used anything jujuish
[09:33] <cjwatson> However I don't think this necessarily says anything about the state of jemjem in general
[09:35] <ev> yeah
[09:43] <rbasak> I'm looking at Juju upstream's QA process and how it fits around SRUs and trying to figure out a decent QA process to land major version changes to Trusty for Juju in a way that makes sense for Ubuntu.
[09:43] <rbasak> One thing I'd like to do is have upstream's QA test trusty-proposed packages. But ideally, this would happen before the package actually hits trusty-proposed.
[09:44] <rbasak> Would it be possible to prepare a build in a PPA, have upstream QA the binaries from the PPA, and then land the binaries in the trusty-proposed unapproved queue as normal?
[09:44] <rbasak> The reason is that I'd like to be testing the same binaries that match upstream's binary distribution that's done outside-of-archive (for cross-distro and cloud provider purposes)
[09:47] <xnox> rbasak: that's what silos are...
[09:47] <xnox> rbasak: non-virt ppas, building with -proposed enabled, and later src+bin are copied and published into the archive, after they have been validated.
[09:48] <xnox> rbasak: talk to sil2100 / robru about it.
[09:49] <rbasak> xnox: thanks. But maybe I need someone on the release team to arrange something like this for Juju?
[09:49] <xnox> rbasak: not release team, but landing team sil2100/robru. We have landed SRUs like that already, e.g. unity7
[09:49] <rbasak> The specific reason here is that when Juju upstream "releases", binaries become available to external sources (eg. uploaded to cloud providers).
[09:50] <rbasak> I'd like to integrate Ubuntu's QA (ie. -proposed for SRUs and 7-day aging period etc), so that an Ubuntu QA issue actually holds back the upstream release.
[09:50] <xnox> rbasak: still not sure what release team got to do with it. release team deals with ubuntu milestones only. landing team can give you ppas and facilitate in staged upload for sru.
[09:51] <rbasak> I wasn't aware of the landing team.
[09:51] <xnox> rbasak: checkout #ubuntu-ci-eng
[09:51] <xnox> rbasak: ... everything that is SRUed must be in devel release already, which most of the time also means released....
[09:52] <rbasak> Hmm, good point.
[09:52] <rbasak> I suppose this would only be for the development release then.
[09:57] <rbasak> I hadn't considered that this could well have the same needs as the desktop side and is already being done - thanks!
[09:58] <cjwatson> If it's not a matter of just merging branches, you might be better off with an ordinary devirtualised PPA rather than bothering with CI Train, though.
[09:58] <cjwatson> (If you already have a suitable PPA.)
[10:07] <rbasak> I'm not familiar with the CI Train and what its requirements would be. There's already a fairly complex process for upstream to generate a release tarball because golang.
[10:07] <rbasak> They have a Jenkins job do everything, so it's outside VCS at that point.
[10:07] <rbasak> Maybe an ordinary devirt PPA would be better, then?
[10:07] <rbasak> How do I go about going through the details and arranging this?
[10:08] <cjwatson> I would just use a separate devirt PPA if I were you.  xnox is right that CI Train deals with some of this, but if you can't use its auto-merging stuff then all it gives you is a devirt PPA with some extra annoyance around getting it assigned, and they have a limited pool right now
[10:08] <cjwatson> Create a PPA, ask webops, solemnly swear that only Canonical people will be allowed to upload to it
[10:08] <cjwatson> Remember to get the right set of architectures enabled
[10:09] <rbasak> OK, thanks. How is the copy to devel-proposed organised?
[10:09] <cjwatson> If you can upload to a suite, you can also copy to it
[10:09] <cjwatson> copy-package in lp:ubuntu-archive-tools with the -b option
[10:09] <rbasak> Great - thank you!
[10:11] <rbasak> I wonder. I can ensure that the devel release always gets it first. But since upstream's goal is to land in the previous LTS via an SRU, they test against that before release, and so I'd like to land it to stable-proposed nearly simultaneously.
[10:12] <rbasak> So would I be able to do the same to trusty-proposed, QAing both at once?
[10:12] <rbasak> I guess I'll need to copy with binaries from the devirt PPA to trusty-proposed. Will that work, and just end up in the unapproved queue as normal?
[11:05] <xnox> rbasak: you do need to make sure you build them clean, e.g. that ppa must have -proposed, -security, -updates pockets enabled, and there are no other non-archive dependencies in it, nor packages not from the archive (unless they are landing into the archive at the same time)
[11:12] <rbasak> xnox: ack
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== MacSlow is now known as MacSlow|lunch
[12:38] <mdeslaur> rbasak: Hi! Think you could merge apache2 2.4.10 soon to fix the security issues?
[12:40] <rbasak> mdeslaur: sure. Looks fairly trivial.
[12:41] <mdeslaur> rbasak: cool, thanks
=== MacSlow|lunch is now known as MacSlow
[13:07] <intgr> pitti: Hey. Sorry to highlight you, but is there an ETA for PostgreSQL 9.3.5 in trusty repos?
[13:07] <pitti> intgr: I'll prepare the updates ASAP, but it's not a critical update, and I'm a bit swamped, so probably not before start of next week
[13:08] <intgr> Ah ok, thanks.
=== _salem is now known as salem_
[13:18] <pitti> intgr: you can subscribe to bug 1348176 to track the status if you want
[13:18] <ubottu> bug 1348176 in postgresql-9.3 (Ubuntu Utopic) "New upstream microreleases 9.3.5, 9.1.14, 8.4.22" [Undecided,New] https://launchpad.net/bugs/1348176
[13:18] <kentb> Hi...Can anyone help with sponsoring a few package upgrade bugs I've opened for 14.10?  There are 4 in all and I can provide bug numbers. Thanks in advance.
[13:20] <intgr> pitti: Cool
=== pete-woods is now known as pete-woods|lunch
[13:40] <xnox> kentb: generally, just list the bugs straight away. As people who might be interested in those bugs (and get highlighted by e.g. package name) may not poke you to ask for numbers =)
[13:40] <kentb> xnox, ok. will do that now...I was worried about spamming the channel :)
[13:41] <kentb> https://launchpad.net/bugs/1335907
[13:41] <kentb> https://launchpad.net/bugs/1335941
[13:41] <kentb> https://launchpad.net/bugs/1335947
[13:41] <kentb> https://bugs.launchpad.net/ubuntu/+source/openwsman/+bug/1334832
[13:41] <ubottu> Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New]
[13:41] <xnox> kentb: phhh =) ubottu is except from spam protections =)
[13:41] <ubottu> Ubuntu bug 1335941 in sblim-sfcc (Ubuntu) "Update to sblim-sfcc 2.2.7 for Utopic" [Undecided,New]
[13:41] <ubottu> Ubuntu bug 1335947 in cim-schema (Ubuntu) "Upgrade cim-schema to 2.41.0 for Utopic" [Wishlist,Triaged]
[13:41] <ubottu> Ubuntu bug 1334832 in openwsman (Ubuntu) "Update to upstream 2.4.7 for Utopic" [Undecided,New]
[13:43] <xnox> kentb: would you want me to review and sponsor that into.... Debian?
[13:44] <kentb> xnox, I do have ITP bugs in Debian opened for those as well if you're inclined
[13:44] <kentb> xnox, but there are a few more in Debian as well, since the build-deps for those packages don't exist in Debian yet, either
[13:44] <xnox> kentb: if you use appropriate version number, and dput into mentors.debian.org i'd sponsor into debian from there.
[13:45] <kentb> xnox, I've got 'em in mentors...let me hunt them down for you
[13:45] <xnox> kentb: and at the same time upload into utopic. Such that once it clears in debian we can sync them across.
[13:45] <xnox> kentb: and/or start with build-deps first indeed =)
[13:45] <kentb> ok.
[13:47] <kentb> xnox, build deps for debian:  https://mentors.debian.net/package/sblim-sfc-common
[13:47] <kentb> and
[13:47] <kentb> https://mentors.debian.net/package/sblim-cmpi-devel
[13:50] <kentb> xnox, and the rest:
[13:50] <kentb> https://mentors.debian.net/package/sblim-sfcc
[13:50] <kentb> https://mentors.debian.net/package/sblim-sfcb
[13:50] <kentb> https://mentors.debian.net/package/openwsman
[13:50] <kentb> https://mentors.debian.net/package/wsmancli
[13:50] <kentb> https://mentors.debian.net/package/cim-schema
[13:50] <kentb> xnox, wsmancli does not need to be synced to 14.10 as I got that one upgraded already
[13:51] <kentb> we also already have sblim-cmpi-devel and sblim-sfc-common in Ubuntu and there's no new upstream release to upgrade to as of today
[13:52] <xnox> kentb: well, debian version number will be higher (e.c. -1 >> -0ubuntuX) and it would be syncable over.
[13:52] <xnox> with zero net difference =)
[13:55] <kentb> oh ok cool
[14:00] <hallyn> jodh: xnox: why is notify-cgmanager.conf needed in user upstart session?
[14:01] <hallyn> jodh: I'll stick your change to the upstart files in git;  but does this mean that the new job should also go into git under config/init somewhere?  I wonder how best to structure that
[14:06] <hallyn> jodh: also, do you know whether nih-dbus-tool places any restrictions on the files it generates?  Or do they fall under whatever license the source files were under?
[14:07] <xnox> hallyn: no restriction.
[14:07] <hallyn> thx
[14:07] <xnox> hallyn: notify-cgmanager.conf is needed to be installed into /usr/share/upstart/sessions/ such that one can have cgroups support in user-session jobs =)
[14:08] <xnox> hallyn: i don't know how to best integrate it upstream. Imho, in user-session mode it should just assume that cgroups support is available, but i lost that argument with jodh, hence the notify call to the user-session upstart as well.
[14:08] <hallyn> well, what's there doesn't guarantee that anythign is available :)
[14:09] <hallyn> except for the upstart job that claims they are
[14:09] <hallyn> (if notify-cgmanager.conf first did a 'cgm ping' that would be more reliable)
[14:12] <xnox> hallyn: but "cgm" is a lot of dependencies which we don't have on the phone.
[14:12] <xnox> hallyn: for ubuntu it's fine =) cause the same package ships both jobs ;-) hence one would have one available.
[14:13] <hallyn> xnox: right but cgmanager/proxy couldve failed to start.  if that's not relevant, then ok
[14:13] <hallyn> yeah i really need to write a non-script version of cgm
=== pete-woods|lunch is now known as pete-woods
[14:14] <xnox> hallyn: yeah irrelevant. notify only allows attempting to start cgroups stanza jobs, if that fails or blocks, those jobs will simply fail.
[14:14] <hallyn> ok
[14:14] <hallyn> oh, goodie, the other changes are already in git :)
[14:16]  * xnox didn't have lunch yet. let me pop out to get some.
[14:16] <hallyn> the user session one should probably at least go into the debian pkg
[14:16] <hallyn> \o
[14:16] <hallyn> thx for the info
[14:50] <mvo_> jibel: initify mentioned that there is a upgrade bug in saucy->trusty right now. do you have have advice how to reproduce? or can I just use a server install and try
=== timrc-afk is now known as timrc
[14:58] <infinity> mvo_: Intentional attempt to avoid nick highlighting me, or dyslexic fingers? :)
[14:58] <mvo_> infinity: too much stuff at once
=== timrc is now known as timrc-afk
[15:20] <jibel> mvo_, this is https://jenkins.qa.ubuntu.com/view/Upgrade/job/upgrade-ubuntu-saucy-trusty-desktop-amd64/140/
[15:20] <jibel> mvo_, install saucy + ubuntu-desktop^ and upgrade
[15:21] <mvo_> jibel: thanks!
=== salem_ is now known as _salem
[15:33] <jibel> mvo_, see also bug 1347721 with ubuntu-gnome. It contains a clone
[15:33] <ubottu> bug 1347721 in ubuntu-release-upgrader (Ubuntu) "Ubuntu GNOME Saucy -> Trusty upgrade displays failure warning" [Undecided,New] https://launchpad.net/bugs/1347721
[15:34] <mvo_> thanks jibel
[15:49] <mvo_> jibel: is there a indiciation in the automatic testing system when it started to happen?
[15:50] <jibel> mvo_, June 25th
[15:53] <mvo_> jibel: hm, thats a long time, thanks
[15:53] <infinity> jibel: Wow, we lasted a whole two months after release before something changed enough to resurface the bug?
[16:25] <dholbach> slangasek, sent the UOS update to u-d-a
[16:30] <slangasek> dholbach: the original mail never went through to u-d-a, correct?  I wonder if it would be better to have a mail subject with the correct dates, rather than one that's Re: wrong dates :)
[16:30] <dholbach> hum hum
[16:30] <dholbach> it already went through on community-announce@ and ubuntu-news-team@
[16:30] <dholbach> but I agree - that would have been a good idea
[16:31] <slangasek> dholbach: do you want me to accept it as-is, or do you prefer to resend with a different subject?
=== _salem is now known as salem_
[16:32] <dholbach> slangasek, ok... let me re-send to u-d-a with a fixed subject
[16:32] <slangasek> ok; rejecting the current one
[16:36] <dholbach> slangasek, thanks, new mail sent
[16:44] <mvo_> jibel: can not repdocue with the clone :(
[16:45] <mvo_> jibel: more tomorrow
=== ximion is now known as ximion-afk
=== roadmr is now known as roadmr_afk
[18:32] <slangasek> pitti: do you have any idea why address-book-service-dbgsym is missing?  source+binary in universe, .ddeb shows in the log: https://launchpadlibrarian.net/180026273/buildlog_ubuntu-utopic-armhf.address-book-service_0.1.1%2B14.10.20140715-0ubuntu1_UPLOADING.txt.gz
[18:32] <slangasek> pitti: so it doesn't seem to obviously be caused by any of the known bugs
[18:38] <_nedR> darkxst, I see you are one of maintainers of gnome-control-center.. just wondering if i were to compile from  lp:ubuntu/utopic-proposed/gnome-control-center and run it in 13.10 would it blow up in my face?
[18:42] <rww> 13.10's end of life, so running it in general is likely to blow up in your face.
[18:45] <_nedR> rww.. it is only about 8 months old,... I am just wondering can i run the current version (without applying changes) would it mess up... Does it need 14.04 to develop and run or 14.10 ?
=== _salem is now known as salem_
[18:48] <rww> !13.10
[18:48] <ubottu> Ubuntu 13.10 (Saucy Salamander) was the 19th release of Ubuntu. Support ended on July 17th, 2014. See !eol, !upgrade and http://ubottu.com/y/saucy
[18:48] <sarnold> neat
[18:49] <_nedR>  rww.. I am wondering would developing  and running a utopic version  of gnome-control-center need ubuntu-utopic or is ubuntu-trusty as development machine?
[19:01] <slangasek> xnox: can you give me a hint about the right way to make autopilot-qt's build use proper flags for building, like -g?  (qmake-based)
=== JanC_ is now known as JanC
=== ximion-afk is now known as ximion
[19:33] <kees> hallyn: ooh, nice catch on the PR_SET_MM refactor's use of RLIMIT_DATA!
[19:33] <hallyn> i had to look at taht 3 times, was sure i was being silly :)
[19:38] <thomi> slangasek:curious - why are you building ap-qt?
[19:40] <slangasek> thomi: because the package fails to properly build with debugging symbols enabled currently, as required by policy
[19:40] <thomi> slangasek: ahhh. I can do that for you today, if you like.
[19:41] <thomi> slangasek: as I'm working in there currently
[19:41] <thomi> slangasek: when should it be built with debugging symbols, and is '-g' all that's required?
[19:41] <slangasek> thomi: right - please make sure the settings from dpkg-buildflags are applied during the build :)
[19:41] <slangasek> thomi: you should just use the dpkg-buildflags abstraction, which will build with the right flags (there's more than just -g - it should also be setting a variety of hardening flags)
[19:42] <thomi> ahhh, I never knew about that before
[19:42] <slangasek> thomi: these aren't urgent wrt autopilot-qt, which is hopefully not being run in production on phones :), but as I'm currently auditing the state of debug symbols it cam eup
[19:43] <thomi> slangasek: yeah. interesting - what's the difference between CPPFLAGS and CXXFLAGS?
[19:44] <slangasek> thomi: CPP is c preprocessor; cxx is c++
[19:44] <thomi> slangasek: I'll patch ap-qt, but FYI this seems to be the general recipe: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1020275.html
[19:44] <thomi> or at least shows how several other packages seem to do it
[19:45] <slangasek> thomi: right; you could probably do that with a little less duplication of subshells by just calling dpkg-buildflags once for each variable and stashing in a make variable, but ok
[19:45] <thomi> true
[19:49] <highvoltage> t/win 24
=== roadmr_afk is now known as roadmr
[20:07] <slangasek> pitti, ev: does apport-retrace have any smarts for dealing with -dbg packages built from the source package, vs. ddebs?
[21:42] <dobey>  binutils : Conflicts: binutils:armhf but 2.24.51.20140709-1ubuntu1 is to be installed
[21:42] <dobey>  binutils:armhf : Conflicts: binutils but 2.24.51.20140709-1ubuntu1 is to be installed
[21:42] <dobey> whee
[21:42] <dobey> slangasek: ^^ any idea how to get around that? :)
[21:43] <dobey> slangasek: it's breaking cross-compile of something that requires g++-4.9 :-/
[21:52] <dobey> slangasek: nevermind, i guess to cross-compile the dep needs to have :native
[21:56] <slangasek> dobey: there is no general solution for cross-compiling things that build-dep on specific toolchain packages, at the moment; effectively the current answer is "ignore the build-deps"
[21:56] <slangasek> (g++-4.9:native doesn't satisfy the build-dependency when cross-building)
[21:58] <dobey> it seems to. i'm not getting the build dependency complaint any more
=== salem_ is now known as _salem
[22:13] <michagogo> slangasek: how far down in your queue is my email re: bug 1314616?
[22:13] <ubottu> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
[22:15] <michagogo> (the email in question is https://lists.ubuntu.com/archives/ubuntu-devel/2014-July/038389.html from July 2)
[23:07] <sarnold> Trevinho: another one.. https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1348353
[23:07] <ubottu> Ubuntu bug 1348353 in unity-greeter (Ubuntu) "Lock screen password field doesn't intercept key pressings from keyboard" [Undecided,New]
[23:09] <catbus1> this may not be the right place to ask this question: is 14.04.1 out yet?
[23:11] <sarnold> catbus1: not yet, i'll be annotated here when it is: https://wiki.ubuntu.com/Releases
[23:11] <catbus1> sarnold: ok, thank you!
[23:12] <hallyn> slangasek: so i'd want to test it for a bit (and track down weird libnih-induced bug), but there's now a compiled 'cgm' program;  how much is the debian ftp team gonna hate me if i say we don't need the cgmanager-utils package any more?