[00:07] <TheMuso`> @pilot in
[00:16] <jtaylor> TheMuso`: as you are piloting, you may want to look at simplejson in trusty, its empty which likely to cause other fallout failures
[00:16] <jtaylor> if rsalveti is not already on it
[00:16] <rsalveti> jtaylor: no, and indeed, that would be helpful
[00:17] <jtaylor> < off to bed
[00:17] <rsalveti> issue started to happen when the new version was merged from debian, as it now uses dh-python
[00:17] <TheMuso`> Its not in the queue, so what exactly is the problem, is there a bug report?
[00:17] <rsalveti> didn't investigate it further
[00:17] <StevenK> wgrant: ^
[00:17] <rsalveti> TheMuso`: nops, just noticed because it crashed for me
[00:17] <rsalveti> when using a personal lp script
[00:17] <StevenK> wgrant: That could be your simplejson issue ...
[00:17] <rsalveti> the package is empty :-)
[00:18] <TheMuso`> Oh ok.
[00:18] <TheMuso`> If nobody else is looking at it, I'll get right on it.
[00:18] <rsalveti> awesome, thanks
[00:19] <TheMuso`> Maybe something we need to add to auto pkg testing...
[00:20] <TheMuso`> Hrm, seems Barry may have beaten me to it.
[00:20] <TheMuso`> What version do you guys have?
[00:20] <stgraber> nope, barry's upload is the broken one
[00:20] <TheMuso`> Latest in LP is 3.3.1-1ubuntu2
[00:20] <TheMuso`> Oh ok.
[00:20] <stgraber> look at the content of python3-simplejson
[00:20] <stgraber> it's empty
[00:20] <stgraber> (as in, valid package but only a changelog.gz file)
[00:21] <TheMuso`> Yup, just wasn't sure if the merge upload was the broken one.
[00:21] <wgrant> StevenK: Yeah, I just downgraded.
[00:45] <TheMuso`> Ok, fix uploaded, relatively simple in the end, give it an houro ro so I guess.
[04:02] <TheMuso`> @pilot out
[05:38] <sarnold> brainwash: jfyi: http://www.openwall.com/lists/oss-security/2013/11/15/2
[06:16] <pitti> Good morning
[06:23] <pitti> bdmurray: thanks!
[08:00] <dholbach> good morning
[09:23] <cjwatson> slacker_nl: openssl> doesn't seem so - must've been overlooked
[09:24] <cjwatson> brainwash: well, it's fixed in trusty now.  I don't know if the security team consider it worth stable updates, you'd have to ask them (maybe sarnold since he was interested)
[09:24] <cjwatson> slacker_nl: sorry, I meant slangasek
[09:25] <cjwatson> brainwash: Ah, looks like sarnold is taking care of it
[09:43] <JackYu> cjwatson, you are so busy:)
[09:54] <doko> seb128, empathy ftbfs in -proposed
[09:55] <seb128> doko, I know, I've no clue why though, if you have help is welcome
[09:55] <seb128> dpkg-shlibs is not happy but I'm not sure why
[09:56] <cjwatson> JackYu: yup ...
[09:56] <doko> stgraber, lintian fails tests in -proposed
[09:56] <seb128> dpkg-shlibdeps: error: no dependency information found for debian/empathy/usr/lib/empathy/libempathy-3.8.5.so (used by debian/nautilus-sendto-empathy/usr/lib/nautilus-sendto/plugins/libnstempathy.so)
[09:56] <seb128> what does that mean?
[09:57] <Laney> seb128: Oh, I looked at that a little bit
[09:57] <Laney> If you remove -Xusr/lib/empathy/ from the dh_makeshlibs arguments it builds
[09:57] <Laney> sjoerd added that, maybe check with him
[09:57] <seb128> Laney, 3.8.4 builds fine and there is like no change between those versions
[09:57] <pitti> Laney: that sounds wrong, though; we don't want the symbols of private libraries be considered in shlibdeps/
[09:58] <Laney> I'm not proposing that as a fix.
[09:58] <pitti> although, if a different binary package actually uses that, I guess we do
[09:58] <Laney> But you need the dependency to be there somehow ...
[09:58] <seb128> https://launchpadlibrarian.net/156496416/empathy_3.8.4-1ubuntu2_3.8.5-0ubuntu1.diff.gz
[09:58] <seb128> do you see anything weird in that diff?
[09:59] <seb128> I even diffed the build log for both locally (with a sed 3.8.4->3.8.5)
[09:59] <seb128> there is no difference in the build/linking
[09:59] <seb128> I don't get it
[09:59] <pitti> seb128: so perhaps debhelper/dpkg got changed? does 3.8.4-1ubuntu2 still actually build?
[09:59] <seb128> pitti, yes, I built both on my trusty
[09:59] <Laney> I guess that's what dh_shlibdeps -Lempathy is trying to solve
[09:59] <seb128> 3.8.4 builds
[09:59] <seb128> 3.8.5 fails
[10:00] <geser> does somebody know why the gnome-keyring build in trusty got "cancelled"? the build logs look like a successful build
[10:00] <Laney> hung processes left over
[10:00] <Laney> s/hung//?
[10:00] <seb128> geser, the build was never finishing because the testsuit let a gnome-keyring-daemon process behind apparently
[10:01] <seb128> Laney, pitti: that's the diff of both builds here on trusty: http://paste.ubuntu.com/6420396/
[10:01] <seb128> Laney, pitti: I did a sed 's/3.8.4/3.8.5/g' to lower the diff
[10:02] <seb128> but you can see, strictly no change in the build/linker
[10:08] <pitti> -       $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/configure.ac
[10:08] <pitti> +       $(top_srcdir)/configure.ac
[10:08] <pitti> the dropping of this lt~obsolete.m4 could be related?
[10:09] <pitti> I don't see any other change which could potentially do this
[10:18] <seb128> pitti, well, maybe that's what is creating the issue, but adding those back doesn't seem the right fix
[10:22] <seb128> Laney, pitti: doh, I fixed it
[10:23] <seb128> Laney, pitti: the package has a debian/shlibs.local with
[10:23] <seb128> libempathy-gtk 3.8.4 empathy (= ${binary:Version})
[10:23] <seb128> libempathy 3.8.4 empathy (= ${binary:Version})
[10:23] <seb128> you need to update the version there
[10:23] <pitti> ah
[10:23] <seb128> that's a stupid thing :/
[10:24] <Laney> haha
[10:26] <tseliot> pitti, seb128: do either of you have the time to approve the nvidia packages in trusty? bug #1250449
[10:29] <pitti> tseliot: I can have a look later (but we don't usually have bugs for NEW packages)
[10:30] <tseliot> pitti: right, maybe it's something we can reuse in the future? (to backport the packages to saucy or precise)
[10:30] <pitti> yes, for those you can add tasks
[10:31] <tseliot> that was the idea
[10:31] <tseliot> pitti: thanks
[10:32] <doko> TheMuso`, was it intended to go backwards with the dotconf soname bump?
[10:35] <infinity> doko: Looks like the actual SONAME changed from foo1.0.so.0 to just foo.so.0, so the package rename makes sense.
[10:38] <doko> zul, jamespage: please have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (msgpack-python)
[11:08] <doko> pitti, I see that postgresql-server-dev-9.3 wants to demote ...
[11:14] <doko> zul, jamespage: removing msgpack-python, python-msgpack provides it
[11:15] <lifeless> so something weird
[11:15] <lifeless> latest raring cloud image has /etc/systemd/system on it
[11:16] <lifeless> which has thrown off our code for detecting systemd vs upstart
[11:16] <ogra_> lifeless, looks like that came in with the enablement of syslog from systemd
[11:17] <xnox> lifeless: pitti did some work on correctly detecting: logind available vs systemd available vs either not available (as in at runtime, rather than install time)
[11:17] <ogra_> pitti, ^^
[11:17] <lifeless> pitti: what would you recommend as the way to check? Or is there a thing you've written we can query?
[11:18] <xnox> lifeless: going forward on debian sysv/systemd are co-installable, despite not actually running. Which is in part inherited by ubuntu (co-installation & config file cruft)
[11:18] <xnox> lifeless: i think one should be checking cgroups. and there is one for systemd and one for logind.
[11:18] <lifeless> xnox: yeah, we kinda need to figure out which to use, given directory tree on disk.
[11:19] <lifeless> xnox: vs a running system
[11:19] <lifeless> xnox: I should perhaps have asked this in #ubuntu-server :) - oops!
[11:19] <xnox> lifeless: http://cgit.freedesktop.org/systemd/systemd/commit/?id=66e411811b8090 seems relevant and does it via /run
[11:20] <slickymaster> good morning all
[11:21] <infinity> xnox: Hey, boost boy.  Want to tell me why this is FTBFS: https://launchpad.net/ubuntu/+source/libpwiz/3.0.4624-3ubuntu1/+build/5233964
[11:21] <xnox> lifeless: at the moment on ubuntu/debian one cannot co-install upstart with sysv/systemd. So the check for upstart can be: which initctl >/dev/null && initctl version | grep -q upstart
[11:22] <ogra_> lifeless, or check which package /sbin/init installed
[11:22] <pitti> lifeless, xnox: the recommended way to check for logind i access("/run/systemd/seats/", F_OK) and "systemd is pid 1" is existence of /run/systemd/system/
[11:23] <pitti> s/i/is/
[11:23] <xnox> infinity: something like https://bugs.launchpad.net/linaro-aarch64/+bug/1186352 ?
[11:23] <lifeless> pitti: thanks; if I have a chroot unpacked in front of me, which might be Fedora or Ubuntu, what would you do to check?
[11:23] <infinity> xnox: That could be it, yeahp.
[11:23] <pitti> lifeless: in a chroot there is no init nor logind..
[11:23] <infinity> xnox: I wonder if that's just cargo-culted from the glibc bits that do the same thing.
[11:24] <xnox> infinity: i wouldn't be surprised.
[11:24] <lifeless> pitti: bah, pedant :) - I'm tired and being imprecise. Unpacked cloud image.
[11:24] <xnox> infinity: boost, is kind of like nih++
[11:24] <pitti> lifeless: oh, you mean you construct a bootable system in a chroot and want to see which init is *going to be* booted?
[11:24] <lifeless> right
[11:24] <lifeless> we download the ubuntu cloud image
[11:24] <lifeless> or a fedora cloud image
[11:24] <lifeless> or $os
[11:25] <ogra_> lifeless,  if dpkg -S /sbin/init 2>/dev/null|grep -q upstart; then echo "running upstart"; else echo "no upstart"; fi
[11:25] <pitti> lifeless: well, if it's Fedora, it's systemd; if it's Ubuntu, it's upstart; if it's Debian, there's no way to know unless there is only upstart or systemd installed, but they might still run with sysv
[11:25] <lifeless> so far we've just checked the .../system dir in /etc as that was sufficient and reliable/
[11:25] <ogra_> (though that wont work on fedora indeed)
[11:25] <lifeless> ogra_: if which dpkg && ... :)
[11:25] <pitti> /etc/os-release should give you the distro
[11:26] <lifeless> pitti: and breaks on derivatives- I want to probe the feature, not the label - that scales much better.
[11:26] <pitti> lifeless: tricky; then I guess trying rpm -Q or dpkg -S on /sbin/init might still be the best bet
[11:27] <lifeless> kk
[11:27] <lifeless> thanks!
[11:27] <xnox> lifeless: ubuntu one will have /sbin/initctl, and fedora one will have /usr/bin/systemctl, on debian if there is no /sbin/initctl and there are /sbin/init and /sbin/systemd you can boot "debian" with either sysv or systemd.
[11:28] <xnox> pitti: on debian at the moment, upstart package conflicts with sysv-init. so if upstart is installed on debian, then it's upstart only.
[11:28] <pitti> xnox: ah, right
[11:30] <lifeless> xnox: brilliant, thanks heaps!
[12:24] <mardy> seb128: hi! Am I looking at the wrong place? I cannot find the most recent Ubuntu packaging for shotwell: https://code.launchpad.net/ubuntu/+source/shotwell
[12:25] <seb128> mardy, the UDD importer is buggy on that source I guess
[12:26] <seb128> mardy, bzr branch lp:~ubuntu-desktop/shotwell/ubuntu; bzr bd-do
[12:26] <mardy> seb128: thanks!
[12:26] <seb128> yw
[13:56] <rbasak> I'm having difficulties with hwclock/system time being the epoch on a machine I'm working on with MAAS. Can I clarify my understanding of where the pieces fit, please, so that I can debug?
[13:57] <rbasak> The installer (d-i netinst) should NTP and set hwclock before booting into the system, right, assuming ntp.ubuntu.com was available at the time of install?
[13:58] <rbasak> And when booting into the system, hwclock(8) suggests to me that the kernel should copy the rtc time to the system time, so userspace doesn't need to run --systohc? Is this accurate? I can't find any reference to doing that on Saucy - just --systz.
[14:29] <xnox> rbasak: hm. we have two upstart jobs on ubuntu. one to load up hwclock time and one to save.
[14:29] <xnox> rbasak: at boot hwclock time is loaded, later ntp runs and ajusts time, at shutdown the time is saved back into hwclock.
[14:29] <rbasak> xnox: hwclock-save and hwclock, right?
[14:30] <rbasak> xnox: hwclock does: exec hwclock --systz $tz --noadjfile $badyear
[14:30] <xnox> rbasak: correct. hwclock at boot, hwclock-save at shutdown.
[14:30] <rbasak> xnox: so it seems that it doesn't load any more
[14:30] <rbasak> xnox: no --hctosys
[14:30] <rbasak> --systz is just for non-UTC RTC correction for dual boot with Windows, AFAICT from the man page
[14:30] <rbasak> So I _think_ responsibility has moved to the kernel
[14:31] <xnox> If you specify neither --utc nor --localtime, the default is which‐
[14:31] <xnox>               ever was specified the last time hwclock was used to set the  clock
[14:31] <xnox>               (i.e.   hwclock  was successfully run with the --set, --systohc, or
[14:31] <xnox>               --adjust options), as recorded in the adjtime file.  If the adjtime
[14:31] <xnox>               file doesn't exist, the default is UTC time.
[14:31] <xnox> ..
[14:31] <xnox> rbasak: we always run with one of --utc or --localtime.
[14:32] <xnox> rbasak: so we don't need hctosys.
[14:32] <rbasak> xnox: right, but that's not the issue here. My problem is that the system time is (sometimes) 1970.
[14:32] <xnox> unless i'm understanding this wrong.
[14:32] <infinity> xnox: Eh?
[14:32] <infinity> xnox: You need hctosys if the kernel isn't picking up the system time elsewise.
[14:32] <rbasak> infinity: is it a bug if the kernel doesn't pick up the system time?
[14:32] <infinity> xnox: --systz explicitly doesn't read the hardware clock.
[14:33] <rbasak> I'm not entirely sure what's going on, since I only get to examine the system after some time.
[14:33] <infinity> rbasak: In theory, the kernel should probably always have the right time these days.  In theory.  Where are you seeing it not?
[14:33] <rbasak> In my failure case, the hwclock is correct, but the system time is 1970.
[14:33] <rbasak> I've also had another failure case the other way round, though.
[14:33] <rbasak> infinity: midway.
[14:33] <infinity> midway has a hwclock that works?
[14:33] <rbasak> So I think a kernel bug is not out of the question.
[14:34] <infinity> highbank didn't.  This is progress.
[14:34] <rbasak> Oh, really?
[14:34] <rbasak> I thought it worked.
[14:34] <rbasak> Perhaps that's my problem.
[14:34] <infinity> highbank doesn't have a battery-backed RTC at all, so how it could have a correct time unless it had been set by a system already is a mystery.  I didn't think midway was different, but maybe.
[14:35] <rbasak> Define "battery-backed". I think it retains it as long as the chassis is powered, even if a node "isn't".
[14:35] <rbasak> (ie. as long as the BMC is powered I think that means)
[14:35] <xnox> rbasak: and you don't have working ntp?
[14:35] <infinity> Except that BMCs randomly cut/blip power occasionally. ;)
[14:35] <infinity> And I'm not even sure your assertion is true.
[14:36] <rbasak> xnox: the lab it's in doesn't appear to have correctly functioning ntp (firewalled off). However, the default gateway does appear to have an ntp service. So I'm trying to use that.
[14:36] <infinity> Anyhow, if you're seeing a correct time in the hwclock, then this tangent in the conversation is pointless.
[14:36] <infinity> And it's possible the rtc driver just sucks (or doesn't exist) for that platform.
[14:36] <infinity> Which would be a "bug robher" thing.
[14:36] <rbasak> infinity: not necessarily! I have cases where hwclock is wrong, too. So I'm trying to understand the whole picture so I can maybe come up with a plausible root cause.
[14:37] <infinity> rbasak: From my experience with highbank, I'd say that relying on the hwclock at all is just wrong.
[14:37] <infinity> rbasak: But robher would know more about if midway is better somehow, and if it has a functional rtc driver.
[14:38] <rbasak> infinity: juju agents fail if the system clock is wrong.
[14:38] <rbasak> infinity: so somewhere between MAAS handing off to juju, the clock needs to be fixed.
[14:38] <infinity> rbasak: And do we expect to run juju/maas in an environment where we can't sync clocks sanely?
[14:38] <rbasak> It's fine to require that we can sync clocks. The question is: where?
[14:38] <rbasak> On every boot, with ntpdate?
[14:38] <infinity> This is a solved problem in the UNIX world for, well, decades.  We can't run NFS without NTP either, why would we do anything else without it? :P
[14:40] <xnox> rbasak: i thought maas server starts ntp, and all nodes that it brings up should be using ntp time from maas server. such that all of them talk the same time.
[14:40]  * xnox recalls reading something about maas/ntp bug or some such..
[14:40] <rbasak> xnox: nope. But perhaps we should add that.
[14:40] <stgraber> doko: I know and I have no idea why
[14:40] <rbasak> xnox: OTOH, it would be nice if I could just configure MAAS with the address of a working ntp server
[14:40] <xnox> rbasak: if it doesn't, and network doesn't have NTP, it's doomed =)
[14:40] <rbasak> xnox: you may be thinking of the MAAS datasource clock skew issue. That part is working fine.
[14:41] <xnox> rbasak: so broadcast / advertise NTP?
[14:41] <rbasak> xnox: that's fine. We can do that. At which stage should a node be picking it up?
[14:41]  * xnox thought that should be working, unless we hardcode to ntp.ubuntu.com and somesuch.
[14:42] <infinity> Do what I do, highjack DNS for ntp.ubuntu.com, so you don't have to change any default configs.
[14:42] <infinity> (Don't do what I do)
[14:42] <infinity> (Please)
[14:42] <xnox> rbasak: it should be advertised on the network at all times & maas server should have synced from it, such that nodes are installed with ntp running already.
[14:42] <rbasak> Haha. I'm perfectly placed to do that right now. Already serving a maas. domain to make juju go in this lab environment.
[14:43] <rbasak> xnox: that's not enough. By default ntp will die if the clock skew is too great. It assumes that the system time is already reasonable.
[14:44] <rbasak> xnox: we need to make the system time reasonable on the node at some point. I'm fine with doing that, but currently I don't believe there's a mechanism for that. I'm asking *at what point* should such a mechanism be put in? Every boot? Custom upstart job injected by MAAS? Etc.
[14:44] <barry> rbasak: panic 0
[14:44] <rbasak> In the meantime, I'm trying to do it with a MAAS commissioning script, which MAAS can arrange to run before d-i netinst runs.
[14:45] <xnox> cjwatson: does d-i have NTP support / ovverride hwclock time, with NTP one?
[14:45] <rbasak> barry: I'm fine with that too, if that's OK with everyone concerned. But we still need MAAS to arrange for ntp.conf to be changed, in that case.
[14:45] <rbasak> xnox: that would be great, with a preseed. Unless the hwclock won't be maintained between d-i and the booted system, which AIUI infinity suspects is not.
[14:46] <infinity> rbasak: ntpdate is run by an ifupdown snippet every time an interface comes up, if it's installed.
[14:46] <xnox> rbasak: right. and we do have ntpdate running by default everywhere. I guess you just need to tweak it to force update time (if it's too far out)
[14:46] <rbasak> infinity: oh, so it is!
[14:48] <infinity> rbasak: Which is why I say I hijack ntp.ubuntu.com, because that's the default in /etc/default/ntpdate and I don't let that resolve outside one of my draconian networks.
[14:48]  * rbasak wonders if he can preseed that
[14:48] <rbasak> # Not used if NTPDATE_USE_NTP_CONF is yes.
[14:48] <rbasak> NTPSERVERS="ntp.ubuntu.com"
[14:49] <rbasak> NTPDATE_USE_NTP_CONF=yes
[14:49] <rbasak> ntp.conf has ntp.ubuntu.com, but also ....ubuntu.pool.ntp.org.
[14:49] <infinity> Note that NTPDATE_USE_NTP_CONF=yes has no effect if you have no ntp.conf
[14:49] <infinity> But I guess you do.
[14:50] <rbasak> So it seems that my issues are entirely due to my NTP-firewalled lab environment? Great.
[14:55] <rbasak> It looks like /usr/sbin/ntpdate-debian will use /var/lib/ntp/ntp.conf.dhcp in preference to /etc/ntp.conf. If that means that I can specify NTP via DHCP then perhaps I can fix the lab at once and everything will magically work.
[14:58]  * rbasak disappears for a while
[15:01] <cjwatson> xnox: It has some in clock-setup, don't remember the exact details
[15:19] <barry> doko: bs4 uploaded w/o pypy.  i suspect we're fighting a losing battle over time though and might be better served in the long run by mir'ing pypy
[15:20] <yolanda> hi, any clue about this error? configure.ac:66: error: possibly undefined macro: AC_DEFINE
[15:20] <yolanda> i googled it, it says that i check about pkg-config, autotools, etc... but i have everything installed
[15:29] <tumbleweed> barry: don't scare me
[15:29] <cjwatson> yolanda: I suggest putting the source package somewhere for people to look at
[15:30] <yolanda> cjwatson, happens to me with couchdb, when i just added a -- with autoreconf in rules
[15:30] <yolanda> i added dh-autoreconf bd in debian/control
[15:30] <yolanda> do you want me to push to chinstrap?
[15:33] <barry> tumbleweed: is that better than essentially disabling all *-pypy binary packages that trigger mirs?  it's Something We Should Discuss
[15:34] <tumbleweed> barry: yeah, that's reasonable. I'm slightly scared about promising any support for pypy, though. Upstream is entirely uninterested in old releases
[15:35] <barry> tumbleweed: yeah, there is that
[15:35]  * barry might start a mlist thread
[15:36] <arun> Excuse me guys, I wanted to talk with some devs , please if you are here, please help me what I need to do (steps)
[15:43] <cjwatson> yolanda: The line number is misleading; if you look at the generated configure after that failure, you find that it's inside an AX_LIB_CURL call, so the problem is that whatever should provide the AX_LIB_CURL macro isn't installed
[15:46] <yolanda> cjwatson, i'm looking at 1.4.0-0buntu1 version, line number looks ok: AC_DEFINE([HAVE_BUILTIN_EXPECT], [1],
[15:47] <yolanda> problem seems to come from the ACLOCAL_AMFLAGS= -I m4, removing that solves the issue, but not sure if that's good idea or if there is some other way to solve it
[15:49] <yolanda> cjwatson, mm, removing that breaks build anyway, so do you want me to push to chinstrap so you take a look?
[15:49] <yolanda> i need to run autoreconf because i need to inject a new DISTRIBUTION var into Makefile, to display Ubuntu distribution
[15:52] <cjwatson> yolanda: The line number is misleading, as I said.  It has AC_DEFINE on that line, yes, but that's not actually what's failing.
[15:52] <cjwatson> yolanda: You could build-depend on autoconf-archive, or you could copy the AX_LIB_CURL macro out of autoconf-archive into acinclude.m4 in a patch.
[15:52] <yolanda> cjwatson, thx
[15:52] <yolanda> i'll try it
[15:52] <cjwatson> -I m4 isn't relevant
[15:53] <cjwatson> And removing that is very probably a bad idea
[16:02] <yolanda> cjwatson, sure, just googling at the cause and trying different things. But your suggestion works for sure, i added autoconf-archive as build-depends and now builds fine
[16:03] <cjwatson> Great
[16:04] <cjwatson> It's a pretty generic failure so googling is probably unhelpful in this case - it'll lead you down a bunch of different paths which don't necessarily apply :)
[16:06] <yolanda> cjwatson, yes, mostly they were suggesting to add dependencies that i already had, but I was unable to see the root of the problem
[16:07] <cjwatson> Looking for the offending unexpanded macro in the generated configure script is the best way to debug this kind of thing
[16:07] <yolanda> cjwatson, nice to learn more about that
[16:45] <Laney> mdeslaur: hey, have you seen https://bugs.launchpad.net/ubuntu/+source/libcommons-fileupload-java/+bug/1251340 ?
[16:46] <mdeslaur> Laney: no, I had not, thankt
[16:46] <mdeslaur> thanks
[16:46] <Laney> np
[16:47] <caribou> is there an easy way to have sbuild know how to fullfill a dependancy from a PPA ?
[16:49] <roadmr> caribou: I usually schroot into the source image and add the ppa manually, may not be the easiest or more automated way but it works
[16:50] <caribou> roadmr: that was my first idea
[16:50] <caribou> roadmr: I'll do that, I don't need much automation in that context
[16:51] <caribou> roadmr: thanks
[16:52] <roadmr> caribou: no problem!
[17:44] <BenC> Anyone ever installed powerpc packages on x86? I've setup apt, and just want to install libncurses5-dev:powerpc, but it needs debconf:powerpc, which can't be satisfied
[17:44]  * BenC is unsure why libc6 needs debconf anyway
[18:00] <orbisvicis> where can I find more info on $(py_setup_install_args) ?
[18:09] <orbisvicis> (nevermind)
[18:24] <slangasek> BenC: libc6 needs debconf to ask about restarting services on upgrade... but debconf should be Multi-Arch: foreign (it has been everywhere for a long time), so the debconf you already have installed is supposed to do the job
[18:24] <infinity> slangasek: Ben and I got sorted in /msg
[18:25] <slangasek> infinity: hmph
[18:25] <infinity> (I didn't notice he'd asked here)
[18:25] <slangasek> ah :)
[18:43] <sarnold> bdmurray: do I recall that you're looking to aggregate many bugs of this sort? 1251537
[18:47] <bdmurray> sarnold: nope, that kind
[18:47] <bdmurray> er not that kind
[18:49] <sarnold> bdmurray: whooops then :) thanks
[18:54] <bdmurray> slangasek: I've also found many a VarLogDistUpgradeApttermlog.gz file with one of the following errors http://pastebin.ubuntu.com/6422642/
[19:11] <BenC> slangasek: raring wasn't working properly, but saucy appears to be installing things
[19:11] <slangasek> interesting
[19:14] <slangasek> bdmurray: well, those are all dpkg database corruption
[19:15] <slangasek> bdmurray: so it probably points back to the same general lack of sensible error handling of dpkg --unpack failures
[19:15] <bdmurray> slangasek: those were independent of the --unpack failures
[19:16] <slangasek> ah
[19:16] <slangasek> bdmurray: did those errors immediately precede the "already configured" error, though?
[19:17] <BenC> slangasek: However, why can't I have gcc-powerpc-linux-gnu and gcc installed together?
[19:17] <slangasek> hum, I don't know the answer to that one :)
[19:17] <slangasek> in saucy?
[19:17] <BenC> Yeah
[19:17] <bdmurray> slangasek: in some cases I guess so
[19:18] <bdmurray> dpkg: unrecoverable fatal error, aborting:^M files list file for package 'linux-image-3.8.0-30-generic' is missing final newline^M
[19:18] <BenC> I may have some mixed raring/saucy packages, so let me clear that up first
[19:18] <bdmurray> dpkg: error processing apt (--configure):^M package apt is already installed and configured^M
[19:18] <slangasek> BenC: ok - fwiw it works for me in a saucy chroot; a mixed install might be failing because of mismatched version of gcc base packages
[21:16] <bdmurray> @pilot in
[22:13] <Noskcaj> mdeslaur, Is it worth merging ruby1.8?
[22:17] <Noskcaj> And to anyone with buildd powers, guava-libraries failed to upload
[22:40] <jtaylor> isn't ruby-1.8 being removed in debian?
[22:42] <jtaylor> there is a tracker, so probably makes sense to follow with it for trusty
[22:44] <Noskcaj> jtaylor, I think it is. The latest debian change just removes all the "provides", i'm not sure if it's worth the time to merge
[22:48] <Noskcaj> xnox, do you mind if i change vtk's depends from tiff to tiff5? It's causing other packages to ftbfs