[04:19] <pitti> Good morning
[06:40] <ricotz> infinity, doko, hi, I saw there were some new gcc-5 builds, what about fixing the non-stripped binaries like /usr/lib/gcc/x86_64-linux-gnu/5/lto1
[07:27] <infinity> ricotz: Apparently, that's a feature, not a bug.
[07:27] <infinity> ricotz: But doko intends to strip them before release.
[07:44] <ricotz> infinity, I see, thanks for clarifying
[08:05] <smb> rbasak, In order to move forward with DPDK I updated bug 1487538 with links to source and my PPA. I think the next step is to subscribe sponsors, right?
[08:07] <seb128> what should packages handle deluser calls in postrm/purge that fail because the user is logged in
[08:07] <seb128> like lightdm when users try to remove the package from a system when the login manager is in use
[08:07] <pitti> seb128: TBH I think nothing should ever call deluser automatically
[08:07] <pitti> if a postrm is trying to, then at least with || true
[08:07] <seb128> pitti, so purging lightdm should just let a lightdm user around?
[08:08] <pitti> but the possibility of reusing a previously removed uid for a new account is a security issue
[08:08] <pitti> seb128: yeah, I think that's the lesser evil
[08:09] <seb128> pitti, so you would just drop the deluser call?
[08:09] <seb128> rather than adding || true?
[08:09] <pitti> lightdm is prone to leaking processes and leftover sessions unfortunately
[08:10] <pitti> seb128: no strong opinion between || true and drop, but I'd prefer dropping it, yes
[08:10] <seb128> pitti, thanks
[08:10] <seb128> robert_ancell, ^
[08:10] <pitti> seb128: so the problem is:
[08:10] <pitti> 1. you uninstall package foo with sysuser foo, removing the sysuser foo with uid 123
[08:11] <pitti> 2. you install a package bar, adding sysuser bar with uid 123 (reusing)
[08:11] <pitti> 3. now bar's daemons "take over" any running processes of foo, and can meddle with its leftover files, etc.
[08:11] <robert_ancell> pitti, fair point
[08:11] <seb128> right
[08:12] <pitti> in some cases (when foo doesn't write any files, or makes sure to kill its processes), deluser is a nice cleanup, but this should be ascertained before
[08:12] <pitti> and lightdm in particular writes lots of files and leaks lots of sessions and processes
[08:13] <pitti> at least while it's running I always have a lightdm session around; not sure whether that's still true after stopping lightdm
[08:29] <rbasak> pitti: I think I'd put that a different way. A postrm to clean up a user is fine, but only if it first cleans up anything that is still using that uid first.
[08:29] <pitti> rbasak: yes, that sounds more positive indeed :)
[08:49] <infinity> pitti: FWIW, I was right.  Just noticed the old open tab.  The rerun of the bluetooth indicator boottest worked.
[08:49] <infinity> pitti: So, it's just when it's tied to a bluez transition that it breaks, because upgrading bluez breaks.
[08:49] <infinity> (Yay phone)
[08:49] <pitti> ah, I see
[09:29] <ypwong> Laney, re indicator-bluetooth, do they just need to rebuild image?
[09:30] <ypwong> ... for ubuntu kylin
[09:31] <Laney> ypwong: if they want the new one yeah
[09:32] <ypwong> Laney, i'm sure they do, thanks
[10:20] <Riddell> cyphermox: are you able to take a look at bug 1488838? fails upgrade
[11:21] <rbasak> freeradius in Trusty FTBFS with sbuild -j4 (the same as dpkg-buildpackage -j4 AIUI) but succeeds with DEB_BUILD_OPTIONS=parallel sbuild with no -j flag. Looks like debian/rules just calls $(MAKE) (no debhelper). Presumably it won't fail in Launchpad because that sets DEB_BUILD_OPTIONS and not -j/MAKEFLAGS directly? Should I consider this a buggy package? Or is using sbuild -j wrong?
[11:23] <rbasak> uh, DEB_BUILD_OPTIONS=parallel=4
[11:23] <rbasak> s/no debhelper/ no dh/
[11:24] <infinity> rbasak: sbuild -j and dpkg-buildpackage -j are broken by design.
[11:24] <rbasak> infinity: ah, OK. Thanks. I had always assumed that -j to sbuild just set DEB_BUILD_OPTIONS and used it as a shortcut. Only looked up the definition just now that I got differing behaviour.
[11:25] <infinity> rbasak: Yeah, dpkg-buidlpackage -j sets MAKEFLAGS, it's pure evil.
[11:25] <infinity> rbasak: In wily's dpkg, it now has a safe -J that does what -j should have done.  Making sbuild call that is probably the right answer.
[11:26] <rbasak> That sounds useful. I look forward to getting my shortcut back :)
[11:26] <infinity> rbasak: Anyhow, totally not a bug IMO that a package that in no way avertises parallel build capability fails to build when you try to force the issue.
[11:26] <infinity> rbasak: Who needs a shortcut?  It's shortest to not type -j at all!
[11:26] <infinity> rbasak: I just have this in my .bashrc:
[11:27] <infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc)"
[11:27] <infinity> Which means no thought required on my part.
[11:27] <rbasak> infinity: understood it's not a buggy package - I figured it was either buggy packaging or buggy tooling and was not sure.
[11:27] <rbasak> infinity: I often build on VMs, so need to adjust my VM-setting-up-script to set a sensible parallel= field, that's all.
[11:43] <cyphermox> Riddell: looks like it's much more than modemmanager: all of dbus looks messed up
[11:43] <Riddell> !
[11:43] <cyphermox> Riddell: what were you upgrading from?
[11:44] <cyphermox> direct 15.04 to 15.10?
[11:44] <Riddell> cyphermox: yes, with do-release-upgrade
[11:51] <Riddell> bdmurray, mvo: I fixed bug 1488843 in ubuntu-release-upgrader, how do I upload, is the packaging somewhere in bzr or do I just get it from the archive?
[12:04] <mvo> Riddell: its in lp:ubuntu-release-upgrader
[12:39] <colonolGron> hi
[12:39] <colonolGron> is there any requirement when one woulds like a package to be added to ubuntu?
[12:47] <pitti> colonolGron: it must be free software (or at least freely redistributable, for multiverse), and there needs to be someone looking after it
[12:48] <pitti> i. e. it's not a "throw it over the fence" thing, but an ongoing commitment
[12:49] <colonolGron> well i would like to have a program in ubuntu, but i am not a developer
[12:49] <colonolGron> pitti, this one: https://github.com/jubalh/nudoku/
[12:49] <colonolGron> there seems to be openSUSE and Gentoo package but not Ubuntu :(
[12:51] <pitti> license wise that seems fine
[12:59] <colonolGron> pitti, so i need to find someone who is willing to maintain the deb package and then thats it?
[12:59] <pitti> colonolGron: pretty much, yes
[13:00] <colonolGron> maybe someone in here steps up, i dont know any developers :)
[13:40] <mterry> bdmurray, ~ubuntu-server will look after python-pymsql in main, FYI
[14:05] <flexiondotorg> didrocks, I'd like to make a small UI change to the Ubiquity Slideshow for Ubuntu MATE. Is lp:ubiquity-slideshow the correct branch to submitted merge proposals against?
[14:07] <didrocks> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubiquity-slideshow/".
[14:07] <didrocks> I would say no :p
[14:08] <didrocks> flexiondotorg: seems the branch is at lp:~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
[14:08] <didrocks> (from Vcs-Bzr)
[14:09] <didrocks> but package version 98 is not in, so please import it
[14:09] <flexiondotorg> didrocks, I branch this - bzr branch lp:ubiquity-slideshow-ubuntu
[14:09] <flexiondotorg> And yes. It is version 97 only. Which prompted my question.
[14:09] <flexiondotorg> import it?
[14:09] <didrocks> IIRC, you did propose a branch with it
[14:09] <didrocks> I guess people with commit right to the branch didn't push it
[14:10] <didrocks> let me check, I guess I didn't have commit rights
[14:10] <didrocks> yeah, core-dev don't
[14:11] <didrocks> cyphermox: mind pushing flexiondotorg's changes to this branch?
[14:11] <didrocks> (I guess core-dev should have access to the branches as well, as per Vcs-Bzr)
[14:11] <cyphermox> Ah, sure
[14:12] <didrocks> cyphermox: the branch corresponding to latest upload is lp:~didrocks/ubiquity-slideshow-ubuntu/mate-slideshow
[14:12] <didrocks> so, should be just a matter of pull && push
[14:12] <cyphermox> Yep
[14:12] <didrocks> thx ;)
[14:13] <didrocks> flexiondotorg: meanwhile, branch from my one ^
[14:13] <flexiondotorg> didrocks, Understood. Thanks.
[14:13] <didrocks> yw
[14:50] <vertago1> Hey I was testing 15.10 on one of my systems and ran into a potential issue with dm-raid and systemd's fsck at boot. Any tips on how to get at any log information which would help me out?
[14:53] <brendand> barry, do you know if the use of \ is mentioned in pep8?
[14:56] <barry> brendand: there is some mention of it.  essentially, if you can use parens/braces/brackets to continue lines, do that.  but there are a few cases where only backslashes will work (or where using parens are a bit contrived)
[14:56] <barry> so backslashes aren't prohibited
[15:11] <degorenko> hello here! Is here anyone around, who can help me? I want to fix this bug: https://bugs.launchpad.net/ubuntu/+source/sahara/+bug/1452698 I found this instruction: http://packaging.ubuntu.com/html/fixing-a-bug.html is it correct? jamespage coreycb can you help? :)
[15:13] <coreycb> degorenko, hello, I can work with you on it but zul will need to sponsor you (james is out)
[15:13] <coreycb> degorenko, definitely appreciate the helping hand :)
[15:14] <coreycb> degorenko, this is kilo?
[15:14] <degorenko> coreycb, yes :)
[15:15] <coreycb> degorenko, ok you can work from the kilo branch here:  https://code.launchpad.net/~ubuntu-server-dev
[15:15] <degorenko> and also this bug in official ubuntu repos (vivid, wily)
[15:15] <coreycb> degorenko, we'll land it in vivid, wily and then backport to the cloud archive
[15:17] <coreycb> degorenko, for liberty we've switched to git and this is the process we're following:  https://wiki.ubuntu.com/ServerTeam/OpenStackPackaging
[15:43] <hallyn_> arges: smb: hey, i don't think i'll be in a good place for the bug party today.  Would same time tomorrow work for you guys?
[15:43] <smb> hallyn_, would be ok with me
[15:45] <arges> hallyn_: yea works for me
[15:46] <hallyn_> cool, thx
[15:46] <rbasak> arges: please could you take another look at bug 1321425? I'm not happy about the whitespace noise in the diff but you already sponsored that to Wily so I don't want to make the submitter run round unnecessarily.
[15:47] <rbasak> (there also looks to be quilt refresh noise in unrelated patches eg. the trusty debdiff)
[15:49] <arges> rbasak: iirc the wily upload didn't have those issues
[15:49] <rbasak> arges: http://launchpadlibrarian.net/211349484/irqbalance_1.0.6-3ubuntu1_1.0.6-3ubuntu2.diff.gz - no quilt patch noise, but the whitespace noise in comments is there
[15:50] <arges> rbasak: ack, i see it now.
[15:52] <arges> rbasak: I would at least let jorge know what happened, perhaps its some editor setting he should be aware of in the future. Are you planning on sponsoring the other SRus?
[15:54] <rbasak> arges: I'd be happy to, but I'd like the noise gone before I do.
[15:55] <rbasak> arges: if you're OK with that, I'll ask in the bug.
[15:57] <arges> rbasak: yea lets do it right. i should have caught that
[15:57] <rbasak> OK, thanks.
[16:05] <hallyn_> mdeslaur: arges: I'm wondering whether the ubuntu qemu development tree ought to go back to lp now that it supports git (it's at debian right now, would be nice if you guys could have write access)
[16:07] <hallyn_> (just a thought;  not doing that today)
[16:12] <hallyn_> well shucks.  in w we moved the qemu initscript func into a common script, and moved the scripts from qemu-system-{x86,ppc} to qemu-system-common.  Now I keep bikeshedding over hwo to do it in v,
[16:13] <hallyn_> just putting the full functionality into the original scripts seems simplest;  i can't just add the common script in v without moving it to the new pkg or else v-to-w upgrades will balk
[16:13] <hallyn_> i can move them now into the qemu-system-common pkgs, but htat's not the simplest way, and this is sru...
[16:14] <hallyn_> it's "just" v so we won't be keeping the duplicated scripts around for long
[16:14] <hallyn_> guess i'll do that
[16:14]  * hallyn_ delets the source and starts over
[16:16] <hallyn_> urgh but that'll be easy to get a little bit wrong
[16:29] <hallyn_> dannf: test pkgs for the vivid qemu sru you worked on long ago are at ppa:serge-hallyn/kvm-pxe-backport fwiw (bug 1457639)
[16:29] <hallyn_> well, still building
[16:31] <hallyn_> hm, yeah, those init scripts aren't right
[16:34] <hallyn_> eh maybe they are
[16:56] <mdeslaur> hallyn_: oh, hrm, didn't know we had a tree at debian for that...yeah, lp would be nice
[16:56] <mdeslaur> hallyn_: you're going to make me learn git, aren't you?
[18:57] <hallyn_> mdeslaur: :)
[20:31] <sladen> .
[20:32] <Unit193> ᗣ ᗣ ᗣ   ᗧ * * * * * *
[20:35] <Pici> wakka wakka
[21:18] <dannf> hallyn: ack, i'll test
[21:30] <hallyn> dannf: i've run the qa-regression-tests, all passed,
[21:30] <hallyn> so i pushed to -proposed just a min ago
[21:31] <dannf> hallyn: perfect - i'll wait till it builds there to verify then
[21:32] <hallyn> cool
[21:51] <barry> doko: i think we need to merge dh-python from unstable.  is that something you want to look at or should i?