[05:08] <pitti> utlemming: systemd.postinst translates these old upstart specific options (nobootwait and optional) to the standard "nofail"; please don't use these in new code
[05:09] <pitti> smoser: /etc/udev/rules.d/70-persistent-net.rules shold be in the initramfs, yes; is it not?
[05:09] <pitti> Good morning
[05:14] <Unit193> Howdy, pitti.  Any way you can fix policykit/dbus/systemd such that restarting dbus (or whatever happened) doesn't require a hard reset?
[05:14] <pitti> Unit193: restarting dbus has never been supported
[05:15] <pitti> Unit193: everything that connects to it will die, like half of your desktop
[05:15] <pitti> not related to polkit or dbus, for these in particular restaritng dbus is fine
[05:15] <Unit193> pitti: I understand this, but something seems to have reset or restarted dbus and the only thing I could do was  reboot -f  to restart it.  Vivid even handled it better than that.
[05:16] <Unit193> I know lightdm and NM die, that's fine.  systemctl failing on every command is not good, though.
[05:16] <pitti> Unit193: run systemctl as root
[05:16] <Unit193> Did.
[05:16] <pitti> hm, systmed has its own private dbus server, it shold talk to that when dbus is down or not installed; but that might be different if it was restarted
[05:16] <Unit193> (As in, sudo -i  and sudo systemctl fooo, nothing worked.  As I said, reboot -f was the only thing.)
[05:16] <pitti> so that might need a systemclt daemon-reexec
[05:16] <Unit193> I did that.
[05:16] <pitti> Unit193: ok, that's news to me
[05:18] <Unit193> pitti: So open to debugging/fixing? :)
[05:18] <pitti> yes, I guess so :)
[05:19] <Unit193> Thank you very much!
[05:24] <pitti> stgraber: once I have an lxd image cached locally, can I do "lxc launch ubuntu/wily/amd64 w1" somehow? (that doesn't work); i. e. like "images:ubuntu/wily/amd64", but using the already cached local copy
[06:14] <hallyn> pitti: you can add aliases to teh already-downloaded images, yes.  'lxc image list', then 'lxc image alias create x1 <some-sha1>'
[06:14] <hallyn> then you can just lxc launch x1 c1
[06:16] <hallyn> pitti: wasn't following previous conv;  you might also be better off using lxd-images.
[06:16] <pitti> hallyn: ah, is that what's done on https://images.linuxcontainers.org:8443 ?
[06:17] <pitti> hallyn: I mean, I find it convenient to do this name-based lookup with distro/release/arch instead of having to look up and use UUIDs
[06:17] <pitti> stgraber, hallyn: lxc/lxd is really nice, many thanks for that!
[06:18] <hallyn> pitti: right, you're really meant to do 'lxd-images download ubuntu --alias wily wily amd64'
[06:18] <pitti> it even works for rebooting xenial containers :) (curiously)
[06:18] <hallyn> orly
[06:18] <pitti> and the remote feature is nice, we could set up armhf testing in scalingstack with that
[06:20] <hallyn> the reason i've not been helpful with the reboot problem actualy is that most ofthe time right now if i type 'reboot' nothing happens.  i need to set up a good test vm.  (that and i'm really hoping to finish cgroup namespaces)
[06:20] <pitti> I guess it's time to add an lxd autopkgtest virt backend :)
[06:21] <hallyn> that should shake out some interesting bugs
[06:25] <pitti> hallyn: uh, reboot is broken for you?
[06:27] <hallyn> yeah, just hangs
[06:27] <pitti> stgraber: do you plan to add xenial lxd images soon? now that there's no debootstrap any more, we'd need these from pretty much day 1
[06:35] <stgraber> pitti: lxd-images pulls from cloud images' release stream so we'd need CPC to publish something in that stream (or you can force with --stream daily)
[06:36] <stgraber> pitti: as for old school images on images.linuxcontainers.org, Jenkins is configured but is failing to produce them due to debootstrap in trusty not knowing about xenial, that should be fixed very soon as there's an SRU in -proposed right now
[06:36] <pitti> stgraber: oh, interesting; so that'll hopefully be quicker again next cycle when the new-style cloud images have settled down
[06:36] <pitti> stgraber: SRU of distro-info-data you mean? thanks for the heads-up
[06:37] <stgraber> yeah, we're trying to standardize on the same images for all cloudy products :)
[06:37] <pitti> until then this could be emulated by creating a wily container, dist-upgrading it, and importing it as image, right?
[06:37] <pitti> (pretty much what I do with cloud images too)
[06:37] <stgraber> pitti: nope, debootstrap itself, for the symlink
[06:37] <pitti> ah
[06:37] <stgraber> pitti: yep, that's how I've been dealing with xenial so far, take wily and upgrade :)
[06:38] <stgraber> actually, let me release it, it's at 6 days now, that's long enough :)
[06:38] <stgraber> done
[06:39] <stgraber> and now off to bed :)
[06:40] <pitti> stgraber: bonne nuit !
[07:24] <alexlist> wgrant: Is linking against e.g. libboost-program-options1.58 but disabling the CXX 11 ABI something that should work?
[07:25] <alexlist> wgrant: e.g., on 15.10,  g++ -o main main.cc -lboost_program_options  -D_GLIBCXX_USE_CXX11_ABI=0
[07:28] <alexlist> Actually that is a question for a larger audience...
[07:39] <alexlist> https://bugs.launchpad.net/ubuntu/+source/boost1.58/+bug/1514717
[07:52] <wgrant> alexlist: wily's libraries are built with the C++11 ABI; you're not going to have much luck linking objects for another ABI against them.
[07:52] <alexlist> wgrant: thx, that's what I feared. So essentially if you depend on a closed source 3rdparty library you are in trouble...
[07:53] <wgrant> Right, proprietary C++ libraries are a bad idea, as the ABI tends to break every few years.
[07:54] <wgrant> Though GCC is a lot better than MSVC on that front, I suppose.
[07:56] <dholbach> good morning
[10:00] <pgquiles_> alexlist: workaround: distribute your own boost and use $ORIGIN in the application
[10:23] <pitti> mvo: meh, bug 1510060 wasn't magically fixed after all :(
[10:24] <mvo> pitti: its back? meh :(
[10:31] <seb128> @pilot in
[11:38]  * dholbach hugs seb128
[11:38] <dholbach> go go go!
[11:39] <davmor2> dholbach: okay we get it you like golang but seriously you don't need to should about it ;)
[11:43] <dholbach> shout? :)
[11:47] <davmor2> dholbach: yeah shout aswell
[11:58]  * seb128 hugs dholbach back
[12:17] <mdeslaur> @pilot in
[12:23] <seb128> mdeslaur, do you start in a particular order? just to not conflict
[12:23] <seb128> mdeslaur, hey btw ;-)
[12:23] <mdeslaur> seb128: nah, no particular order...you?
[12:24] <seb128> mdeslaur, I was starting from the most recents
[12:25] <seb128> but I did skip over a few ones and started in the yellow section now
[12:25] <mdeslaur> seb128: I'll take cups
[12:25] <seb128> mdeslaur, seems like security related, have fun ;-)
[12:26] <seb128> mdeslaur, feel to take the dovecot/apparmor one as well
[12:26] <mdeslaur> ok
[12:48] <seb128> slangasek, hey, could you have a look to https://bugs.launchpad.net/ubuntu/+source/sbsigntool/+bug/1511108 ?
[13:16] <seb128> jibel, hey, could you get (or do you know who could) https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 merged?
[13:17] <matsubara> rbasak, ^
[13:21] <jibel> seb128, sure, let me find someone
[13:22] <seb128> jibel, thanks
[13:22] <seb128> jibel, it's in the sponsoring queue (I guess since Laney's changes) so would be good to get merged
[13:23] <jibel> seb128, actually matsubara or rbasak can do it, it's a server branch
[13:23] <seb128> j
[13:23] <seb128> matsubara, rbasak, ^
[13:23] <seb128> jibel, thanks
[13:23] <matsubara> seb128, I don't have permission, that's why I pinged rbasak. He's the one who usually merge in my changes
[13:30] <seb128> matsubara, k
[13:34] <mdeslaur> seb128: I'll take the xscreensaver merge
[13:40] <rbasak> matsubara: otp, please ping again if I forget.
[13:54] <dgadomski> hey pitti, could you please take a look at debdiffs for bug 1337873
[14:03] <elijah> https://insights.ubuntu.com/2013/02/15/developers-get-the-full-support-they-need/ says there is an #ubuntu-phone but when I try to join it says I need an invitation.
[14:04] <elijah> Anyone know when this will be open?
[14:04] <Laney> Is it meant to be #ubuntu-touch?
[14:04] <Laney> dpm: ^?
[14:05] <brendand> elijah, that's quite an old blog post, #ubuntu-touch exists
[14:05] <dpm> I thought someone had set up a redirect a long time ago
[14:05] <dpm> popey, ? ^^
[14:05] <Laney> presumably the blog post could be edited anyway
[14:05] <dpm> let's see who else gets pinged in the chain :-)
[14:05] <elijah> Okay, so #ubuntu-touch is the official channel?
[14:06] <brendand> elijah, but if you're an app developer there is a full channel just for you - #ubuntu-app-devel
[14:06] <popey> yes
[14:06] <popey> will get the redirect fixed
[14:06] <brendand> popey, but ubuntu-app-devel is more appropriate for application developers
[14:06] <brendand> popey, as i'm sure you'd agree
[14:06] <popey> (I know)
[14:06] <elijah> #ubuntu-touch has a much larger user list
[14:06] <elijah> I am in both though
[14:07] <elijah> I am getting ready to ditch Android, just trying to get started
[14:08] <elijah> Will ubuntu-touch and ubuntu-app-devel eventually become one channel?
[14:09] <elijah> I thought we are moving towards unified apps
[14:12] <slangasek> seb128: yep, it's in my queue
[14:12] <seb128> slangasek, thanks
[14:22] <pitti> dgadomski: you are already reviewing this with Guus, no? I'm not familiar with the ifupdown code and this is rather intrusive
[14:23] <pitti> dgadomski: i. e. could we get this reviewed and landed in sid and xenial for a bit before we backport? this has a really high regression potential
[14:25] <dgadomski> pitti: sure, this is a backport of Guus change already present in debian git repo
[14:25] <pitti> dgadomski: ah, it is? godo
[14:25] <dgadomski> pitti: although I think it has not been released yet
[14:25] <pitti> dgadomski: right, the bug is still open
[14:31] <dgadomski> pitti: it has already been tested in several different environments so it is known to at least fix this bug, releasing to xenial may help us make sure about regressions
[14:32] <pitti> dgadomski: right, so I'm fine with the xenial upload, but I'd give the SRUs some time
[14:33] <dgadomski> pitti: agreed, I'll keep testing it in xenial
[14:34] <seb128> sil2100, hey, what's the status of https://code.launchpad.net/~sil2100/livecd-rootfs/fix-apt-lists-rm-hook/+merge/273117 ? could you get ogra or somebody who usually upload those changes to review?
[14:35] <seb128> ogra_, https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new-and-old/+merge/274875 is in the sponsoring queue, is that something you are still reviewing for mvo?
[14:36] <ogra_> seb128, i'll sing it off once it is ready (requores a lot of other architectural changes first)
[14:37] <ogra_> i thought the apt list removal landed ages ago ... will pull it inot the next livecd-rootfs upload
[14:37] <seb128> ogra_, thanks, the removal landed it seems but that's a follow up to fix small issues
[14:37] <ogra_> ah
[14:40] <smoser> pitti, yeah. even on my physical system, it doesn't show up. http://paste.ubuntu.com/13216207/
[14:42] <smoser> pitti, do you have it in  yours ?
[14:43] <davmor2> hey pitti did you get home in the end or are you working from ausitn?
[14:48] <Unit193> mdeslaur: Thanks!
[14:48] <mdeslaur> Unit193: yw!
[14:49] <mvo> ogra_: fwiw, we could land it now it is fully backward compatible, but I don't mind either way
[14:55] <pitti> smoser: I'm back home, the third flight worked after all :)
[14:55] <pitti> smoser: what is "it" in "it does not show up"?
[14:56] <smoser> pitti, persistent networking
[14:57] <smoser> per
  smoser: /etc/udev/rules.d/70-persistent-net.rules shold be in the initramfs, yes; is it not?
[14:57] <seb128> jibel, and do you know who would be right to review https://code.launchpad.net/~psivaa/ubuntu-test-cases/remove-ceph-lxc-floodlight/+merge/240144 ?
[14:57] <seb128> https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 as well
[14:58] <psivaa> seb128: the latter should be rejected. I'll do that
[14:58] <seb128> psivaa, thanks
[14:59] <pitti> smoser: could you please add set -x to /usr/share/initramfs-tools/hooks/udev and do "sudo update-initramfs -u"?
[14:59] <sil2100> seb128: ok, I'll try getting someone to review that ASAP
[15:00] <pitti> smoser: when I touch /etc/udev/rules.d/70-persistent-net.rules and update, my initrd gets it
[15:00] <seb128> sil2100, thanks
[15:00] <smoser> pitti, sure.
[15:01] <smoser> pitti, looking at /usr/share/initramfs-tools/hooks/udev
[15:01] <smoser> its based on NEED_PERSISTENT_NET
[15:02] <psivaa> seb128: sil2100: https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 could also be reviewed please. I was talking with a bad memory when I said that should be rejected
[15:02] <pitti> smoser: oh sorry, which release is that?
[15:02] <smoser> i dont know why you'd get it, though.  either you must have configured it, or 'root_over_the_network' would be true for your system (which would seem odd)
[15:02] <pitti> smoser: this is gone from wily
[15:03] <smoser> why?
[15:03] <pitti> smoser: >= wily just copies everything in /etc/udev/rules.d/ into the initramfs (which doesn't have a counterpart in /lib/udev/rules.d/, i. e. all custom rules)
[15:03] <pitti> because we can't know which bits apply to the initrd
[15:03] <pitti> smoser: I mean the specific check is gone from wily
[15:04] <jibel> seb128, both are for the server team
[15:04] <seb128> jibel, k, the merges mention daily iso testing so I was unsure if that was a QA thing
[15:05] <seb128> who is in the server team that could be pinged about those? ;-)
[15:05] <jibel> seb128, yes but the server team manages its own tests
[15:05] <jibel> seb128, matsubara or rbasak
[15:05] <seb128> jamespage, ^ you own lp:ubuntu-test-cases/server it seems, can you get those reviewed?
[15:05] <seb128> rbasak, matsubara, ^
[15:06] <seb128> they are sitting there for around a year
[15:06] <seb128> we should get them out of the sponsoring queue if we can :-)
[15:06] <seb128> jibel, thanks
[15:15] <smoser> pitti, i'm looking at wily system up to date.
[15:15] <smoser> it most definitely includes /etc/udev/rules.d/70-persistent-net.rules based on NEED_PERSISTENT_NET
[15:16] <smoser> maybe you meant 'I mean the specific check is gone from XENIAL'
[15:16] <smoser> ?
[15:20] <smoser> am i missing something?
[15:21] <pitti> smoser: no, I meant http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=022e24e5b3 which is in wily
[15:21] <pitti> smoser: in my wily VM I don't see anything "NEED*" in /usr/share/initramfs-tools/hooks/udev ?
[15:22] <pitti> smoser: indeed in older releases there was a check like that, as apparently someone thought back then that we don't need the interface names in initrd yet (i. e. without taking the iscsi use case into account)
[15:22] <smoser>  grep NEED /usr/share/initramfs-tools/hooks/udev
[15:22] <smoser> if [ -z "$NEED_PERSISTENT_NET" ] && root_over_the_network; then
[15:22] <smoser>   NEED_PERSISTENT_NET='yes'
[15:22] <smoser> case "$NEED_PERSISTENT_NET" in
[15:22] <smoser> $ dpkg -S /usr/share/initramfs-tools/hooks/udev
[15:22] <smoser> udev: /usr/share/initramfs-tools/hooks/udev
[15:22] <smoser> $ dpkg-query --show udev
[15:22] <smoser> udev    219-7ubuntu6
[15:22] <pitti> well, that's not wily :)
[15:22] <smoser> $%&*#
[15:23] <smoser> smoser stop being an idiot
[15:23] <smoser> i swear that system was wily a minute ago :)
[15:23] <pitti> smoser: so yes, in vivid this was still the case
[15:23] <smoser> thank you
[15:23] <pitti> smoser: is that important for an SRU?
[15:23] <smoser> maybe i would need this for trusty.
[15:24] <pitti> in principle it should apply, but I had thought the existing NEED checks should apply to iscei
[15:24] <smoser> but not tat the moment.
[15:24] <smoser> the path would be to support iscsi root and ibft
[15:24] <smoser> https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1513254
[15:24] <smoser> is where this came up, was just looking at the path that would include ibft for iscsi
[15:28] <seb128> mdeslaur, unsure it's still worth doing SRUs to vivid for non critical issues
[15:29] <seb128> mdeslaur, btw when do you set mps to merged? to you actually push to the udd vcs?
[15:29] <mdeslaur> seb128: yeah, didn't think it was worth it either, but sru team can decide
[15:29] <mdeslaur> seb128: when I upload the package
[15:29] <mdeslaur> I don't actually udd merge it
[15:30] <seb128> mdeslaur, k, you put https://code.launchpad.net/~e7appew/ubuntu/vivid/deluge/fix-set-trackers-cherry-picked/+merge/271221 to approved and not mergd though?
[15:30] <mdeslaur> seb128: hrm, what do you usually do?
[15:30]  * mdeslaur has no idea what to set that to
[15:30] <seb128> mdeslaur, I set it to merged when I upload to get it out of the queue summary
[15:31] <seb128> but I'm not sure it's right either ;-)
[15:31] <mdeslaur> ok, I'll set it to merged too
[15:31] <seb128> just avoiding having items staying on the queue
[15:31] <mdeslaur> I thought approved got it out of the queue, but merge works for me too :P
[15:31] <seb128> for the same reason I also unsubscribe ubuntu-sponsors from SRU bugs because it takes a while to get them to fix released
[15:31] <seb128> ok, maybe it does
[15:31] <seb128> but then they stay in that state
[15:32] <seb128> merged is done ;-)
[15:32] <mdeslaur> sounds good, merged from now on
[15:32] <seb128> thanks
[15:33] <seb128> xnox, you asked details on https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1472314 and got a reply and the submitter pinged since, you might want to have another look? ;-)
[15:34] <xnox> seb128: i do not currently have internet at home. so i cannot do any ubuntu stuff at the moment.
[15:34] <seb128> xnox, no worry, enjoy the quiet time without internet disturbances ;-)
[15:36] <mdeslaur> I wish I didn't have internet :)
[15:36] <seb128> cyphermox, hey, do you plan to deal with an eventual trusty SRU for https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1459872 ?
[15:37] <seb128> mdeslaur, yeah, who needs a job anyway :p
[15:38] <cyphermox> seb128: yes, that's the plan
[15:38] <seb128> cyphermox, no need of keeping it in the sponsoring queue then?
[15:38] <cyphermox> ah, no. sorry, I didn't notice it was
[15:39] <seb128> cyphermox, thanks
[15:41] <seb128> cyphermox, same for https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/277903 ,
[15:41] <seb128> it's assigned to you
[15:41] <cyphermox> yes
[15:42] <seb128> thanks ;-)
[15:43] <seb128> Sarvatt, do we still care about vivid for https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1506107 ?
[15:45] <Sarvatt> seb128: trusty's lts-vivid at least
[15:45] <Sarvatt> that's whats shipping on OEM machines till 16.04
[15:47] <mdeslaur> seb128: did you forget to actually unsubscribe sponsors here? 1506536
[15:47] <mdeslaur> bug 1506536
[15:47] <seb128> mdeslaur, seems I did!
[15:48] <seb128> Sarvatt, is tjaalton or robert_ancell going to sponsor that SRU for you?
[15:50] <Sarvatt> seb128: tseliot just said he would
[15:52] <seb128> great
[15:52] <seb128> tseliot, Sarvatt, thanks
[15:52] <tseliot> yw
[16:06] <seb128> smoser, pitti, mvo, there is an update patch on https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/525674 since you reviewed the previous version and had comment could you maybe have another look to the updated one?
[16:09] <smoser> seb128, done.
[16:10] <smoser> please sponsor that for xenial
[16:13] <seb128> smoser, thanks
[16:16]  * smoser says thank you.  cpaelzer best.fix.ever!
[16:19] <seb128> mvo, ^ maybe you merge that back in update-notifier's vcs? ;-)
[16:22] <seb128> @pilot out
[16:22] <seb128> dholbach, do you know if it was discussed listed the newest sponsoring entries first on the page?
[16:22] <mdeslaur> @pilot out
[16:22] <dholbach> seb128, no... maybe Laney knows?
[16:22]  * dholbach hugs mdeslaur
[16:23]  * mdeslaur hugs dholbach back
[16:23] <seb128> @pilot out
[16:23] <seb128> oh, I just did that :p
[16:24] <seb128> dholbach, my rational would be that the top of the page is always year old difficult items that probably most people skips over
[16:24] <seb128> but some new comers might also try to get to one, find it difficult, go the next one, same and then give up
[16:24] <seb128> I think it would be less discouraging to have the newest ones first
[16:24] <dholbach> you can sort it the other way if you click on the title
[16:24] <dholbach> but I'm happy either way
[16:24] <seb128> lol
[16:24] <seb128> I know that, I also sort it first thing
[16:25] <seb128> well, I just wanted to mention it, I've no strong opinion
[16:26] <seb128> and I do try to tackle some ancient ones ;-)
[16:26] <Laney> no
[16:26] <Laney> not discussed
[16:26] <Laney> I think it's bad we have ancient stuff there
[16:27] <seb128> yeah, it is
[16:27] <seb128> but sorting them first obviously doesn't resolve the issue
[16:27] <seb128> it just means people who know what they are doing skip over those and others might think things are just impossible to review
[16:31] <mterry> seb128, mdeslaur: stop piloting so hard, you make the rest of us look bad  :)
[16:31] <seb128> lol
[16:31] <mdeslaur> slackers :)
[16:31] <seb128> mterry, there are some easy items left, help yourself ;-)
[16:31] <seb128> like the 2 most recent ones
[16:32] <pitti> seb128: bon travail sur le "sponsoring queue" !
[16:32] <seb128> pitti, merci !
[16:32] <seb128> mdeslaur, you could have handled https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1481033 since it's a security one :-)
[16:32] <seb128> replacing it with a dummy binary
[16:33] <mdeslaur> I've been the bad guy twice now for doing that, first sun-java, then owncloud
[16:33] <mdeslaur> I'll get someone else get the death threats this time :)
[16:34] <mdeslaur> s/get/let/
[16:35] <Chipaca> xnox: o/
[16:35] <Chipaca> xnox: any news on bug 1025555? (cjwatson mentions you need to follow up something with intel?)
[16:36] <xnox> hm.
[16:36] <xnox> yes and no.
[16:36] <xnox> in a meeting now.
[16:37] <Chipaca> xnox: i'd assumed i was going to get an async answer; no hurry :)
[16:43] <seb128> cyphermox, did you say you would handle the https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095 modemmanager/n-m uploads for trusty as well?
[16:46] <cyphermox> I'll do all these sponsorings this PM
[16:48] <roadmr> heya folks. I'd like the checkbox package to stop building all its binaries altogether. Is it OK for the ubuntu branch to contain just the debian directory which will build the required transitional packages?
[17:00] <pitti> infinity, kees, stgraber, slangasek, mdeslaur: TB meeting
[17:32] <seb128> xnox, in https://launchpad.net/ubuntu/+source/samba/2:4.1.11+dfsg-1ubuntu1 you did
[17:32] <seb128> -		reload nmbd 2>/dev/null
[17:32] <seb128> +		service nmbd reload 2>/dev/null
[17:32] <seb128> but that seems buggy (https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1385868)
[17:33] <seb128> debian uses
[17:33] <seb128> 		[ ! -f /var/run/samba/nmbd.pid ] || kill -HUP `cat /var/run/samba/nmbd.pid`
[17:33] <seb128> should we go back to that
[17:33] <slangasek> yes we should
[17:33] <slangasek> :)
[17:33] <seb128> or is there a better version of that line?
[17:33] <slangasek> no there's not
[17:33] <seb128> slangasek, thanks
[17:33] <slangasek> not one that is boot-system-agnostic
[17:33] <seb128> unsure why we changed it in the first place
[17:33] <seb128> k
[17:33] <seb128> I guess because we were upstart centric
[17:37] <ogra_> could someone bump the score of https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/8284490 ? (sits there saying "15 min" since over 1h
[17:37] <ogra_> )
[17:38] <cjwatson> ogra_: done
[17:38] <ogra_> thanks
[17:38] <cjwatson> unusually long armhf queue
[17:38] <ogra_> do we know why livecd-rootfs is arch any ?
[17:38] <ogra_> i guess i asked that before
[17:38] <cjwatson> changelog does
[17:38]  * ogra_ reads
[17:39] <ogra_> ah, android :/
[19:29] <hallyn> xnox: any time this week to pick up the shadow pkg? :)
[19:35] <gAtheos> Hey, I am a computer science student and I am looking to contribute to development of Ubuntu in some way, does anyone have any advice or some direction for where I could go or what I could do?
[19:44] <TJ-> gAtheos: see https://wiki.ubuntu.com/ContributeToUbuntu#Maintaining_Ubuntu
[20:14] <slangasek> pitti: http://autopkgtest.ubuntu.com/packages/c/cantor/xenial/armhf/ - I guess it's going to be a bit more difficult now to reproduce these tests exactly given the new pinning handling, and the test output doesn't say *what* packages are uninstallable; any advice on debugging?
[20:14] <cyphermox> gAtheos: the easiest way to start is probably to pick some software that you're interested in and see if you can triage or fix bugs, etc. starting with something you know and use helps.
[20:16] <slangasek> pitti: and ppc64el gets timeout connecting to systemd :/ http://autopkgtest.ubuntu.com/packages/c/cantor/xenial/ppc64el/
[20:25] <slangasek> Laney: how does mathgl 2.3.3-3build2 count as a rebuild if you're changing debian/control...?
[20:28] <slangasek> Laney: the gsl transition has gotten wedged in with the ocaml and giflib transitions fwiw
[20:29] <slangasek> also mathgl apparently needs porting to the new gsl
[21:07] <gAtheos> cyphermox: That is what I am trying to do. I found a bitesize bug in RhythmBox and have been following the instructions found here: http://goo.gl/V3zA6j and I have just been having a lot of trouble. I have no doubt I will be able to contribute once I get started, but I have no experience doing this and the examples and walkthroughs seem lacking
[21:30] <cyphermox> gAtheos: yes, it's a bit outdated. You probably should just grab the code using 'pull-lp-source rhythmbox' to start hacking on it rather than creating a repo.
[21:42] <gAtheos> cyphermox: I'll have to try that once I get home
[22:43] <sil2100> cyphermox: hey! Another no-change rebuild - this one would be a 'just in case' rebuild, as the package fails to install for other reasons right now: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.6/+bug/1515031
[22:43] <sil2100> cyphermox: still, the packages depend on ocaml so I would feel better if this gets released anyway