[00:07] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso` [00:16] 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] if rsalveti is not already on it [00:16] jtaylor: no, and indeed, that would be helpful [00:17] < off to bed [00:17] issue started to happen when the new version was merged from debian, as it now uses dh-python [00:17] Its not in the queue, so what exactly is the problem, is there a bug report? [00:17] didn't investigate it further [00:17] wgrant: ^ [00:17] TheMuso`: nops, just noticed because it crashed for me [00:17] when using a personal lp script [00:17] wgrant: That could be your simplejson issue ... [00:17] the package is empty :-) [00:18] Oh ok. [00:18] If nobody else is looking at it, I'll get right on it. [00:18] awesome, thanks [00:19] Maybe something we need to add to auto pkg testing... [00:20] Hrm, seems Barry may have beaten me to it. [00:20] What version do you guys have? [00:20] nope, barry's upload is the broken one [00:20] Latest in LP is 3.3.1-1ubuntu2 [00:20] Oh ok. [00:20] look at the content of python3-simplejson [00:20] it's empty [00:20] (as in, valid package but only a changelog.gz file) [00:21] Yup, just wasn't sure if the merge upload was the broken one. [00:21] StevenK: Yeah, I just downgraded. === steve__ is now known as sbeattie [00:45] Ok, fix uploaded, relatively simple in the end, give it an houro ro so I guess. === hholtmann_ is now known as hholtmann [04:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === Ursinha-afk is now known as Ursinha [05:38] brainwash: jfyi: http://www.openwall.com/lists/oss-security/2013/11/15/2 === freeflying is now known as freeflying_away [06:16] Good morning [06:23] bdmurray: thanks! === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [08:00] good morning === freeflying is now known as freeflying_away === sgnb is now known as Guest40212 [09:23] slacker_nl: openssl> doesn't seem so - must've been overlooked [09:24] 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] slacker_nl: sorry, I meant slangasek [09:25] brainwash: Ah, looks like sarnold is taking care of it [09:43] cjwatson, you are so busy:) === doko_ is now known as doko [09:54] seb128, empathy ftbfs in -proposed [09:55] doko, I know, I've no clue why though, if you have help is welcome [09:55] dpkg-shlibs is not happy but I'm not sure why [09:56] JackYu: yup ... [09:56] stgraber, lintian fails tests in -proposed [09:56] 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] what does that mean? [09:57] seb128: Oh, I looked at that a little bit [09:57] If you remove -Xusr/lib/empathy/ from the dh_makeshlibs arguments it builds [09:57] sjoerd added that, maybe check with him [09:57] Laney, 3.8.4 builds fine and there is like no change between those versions [09:57] Laney: that sounds wrong, though; we don't want the symbols of private libraries be considered in shlibdeps/ [09:58] I'm not proposing that as a fix. [09:58] although, if a different binary package actually uses that, I guess we do [09:58] But you need the dependency to be there somehow ... [09:58] https://launchpadlibrarian.net/156496416/empathy_3.8.4-1ubuntu2_3.8.5-0ubuntu1.diff.gz [09:58] do you see anything weird in that diff? [09:59] I even diffed the build log for both locally (with a sed 3.8.4->3.8.5) [09:59] there is no difference in the build/linking [09:59] I don't get it [09:59] seb128: so perhaps debhelper/dpkg got changed? does 3.8.4-1ubuntu2 still actually build? [09:59] pitti, yes, I built both on my trusty [09:59] I guess that's what dh_shlibdeps -Lempathy is trying to solve [09:59] 3.8.4 builds [09:59] 3.8.5 fails [10:00] does somebody know why the gnome-keyring build in trusty got "cancelled"? the build logs look like a successful build [10:00] hung processes left over [10:00] s/hung//? [10:00] geser, the build was never finishing because the testsuit let a gnome-keyring-daemon process behind apparently [10:01] Laney, pitti: that's the diff of both builds here on trusty: http://paste.ubuntu.com/6420396/ [10:01] Laney, pitti: I did a sed 's/3.8.4/3.8.5/g' to lower the diff [10:02] but you can see, strictly no change in the build/linker [10:08] - $(top_srcdir)/m4/lt~obsolete.m4 $(top_srcdir)/configure.ac [10:08] + $(top_srcdir)/configure.ac [10:08] the dropping of this lt~obsolete.m4 could be related? [10:09] I don't see any other change which could potentially do this [10:18] pitti, well, maybe that's what is creating the issue, but adding those back doesn't seem the right fix [10:22] Laney, pitti: doh, I fixed it [10:23] Laney, pitti: the package has a debian/shlibs.local with [10:23] libempathy-gtk 3.8.4 empathy (= ${binary:Version}) [10:23] libempathy 3.8.4 empathy (= ${binary:Version}) [10:23] you need to update the version there [10:23] ah [10:23] that's a stupid thing :/ [10:24] haha [10:26] pitti, seb128: do either of you have the time to approve the nvidia packages in trusty? bug #1250449 [10:26] bug 1250449 in nvidia-graphics-drivers-319 (Ubuntu) "Include the 331 driver in Ubuntu" [Medium,In progress] https://launchpad.net/bugs/1250449 [10:29] tseliot: I can have a look later (but we don't usually have bugs for NEW packages) [10:30] pitti: right, maybe it's something we can reuse in the future? (to backport the packages to saucy or precise) [10:30] yes, for those you can add tasks [10:31] that was the idea [10:31] pitti: thanks [10:32] TheMuso`, was it intended to go backwards with the dotconf soname bump? [10:35] 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] zul, jamespage: please have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (msgpack-python) [11:08] pitti, I see that postgresql-server-dev-9.3 wants to demote ... [11:14] zul, jamespage: removing msgpack-python, python-msgpack provides it [11:15] so something weird [11:15] latest raring cloud image has /etc/systemd/system on it [11:16] which has thrown off our code for detecting systemd vs upstart [11:16] lifeless, looks like that came in with the enablement of syslog from systemd [11:17] 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] pitti, ^^ [11:17] pitti: what would you recommend as the way to check? Or is there a thing you've written we can query? [11:18] 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] lifeless: i think one should be checking cgroups. and there is one for systemd and one for logind. [11:18] xnox: yeah, we kinda need to figure out which to use, given directory tree on disk. [11:19] xnox: vs a running system [11:19] xnox: I should perhaps have asked this in #ubuntu-server :) - oops! [11:19] lifeless: http://cgit.freedesktop.org/systemd/systemd/commit/?id=66e411811b8090 seems relevant and does it via /run [11:20] good morning all [11:21] 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] 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] lifeless, or check which package /sbin/init installed [11:22] 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] s/i/is/ [11:23] infinity: something like https://bugs.launchpad.net/linaro-aarch64/+bug/1186352 ? [11:23] Ubuntu bug 1186352 in Linaro AArch64 cross-distro work "boost 1.5x library "context" needs porting" [Undecided,New] [11:23] 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] xnox: That could be it, yeahp. [11:23] lifeless: in a chroot there is no init nor logind.. [11:23] xnox: I wonder if that's just cargo-culted from the glibc bits that do the same thing. [11:24] infinity: i wouldn't be surprised. [11:24] pitti: bah, pedant :) - I'm tired and being imprecise. Unpacked cloud image. [11:24] infinity: boost, is kind of like nih++ [11:24] 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] right [11:24] we download the ubuntu cloud image [11:24] or a fedora cloud image [11:24] or $os [11:25] lifeless, if dpkg -S /sbin/init 2>/dev/null|grep -q upstart; then echo "running upstart"; else echo "no upstart"; fi [11:25] 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] so far we've just checked the .../system dir in /etc as that was sufficient and reliable/ [11:25] (though that wont work on fedora indeed) [11:25] ogra_: if which dpkg && ... :) [11:25] /etc/os-release should give you the distro [11:26] pitti: and breaks on derivatives- I want to probe the feature, not the label - that scales much better. [11:26] lifeless: tricky; then I guess trying rpm -Q or dpkg -S on /sbin/init might still be the best bet [11:27] kk [11:27] thanks! [11:27] 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] 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] xnox: ah, right [11:30] xnox: brilliant, thanks heaps! === brainwash_ is now known as brainwash === MacSlow is now known as MacSlow|lunch === Sweetsha1k is now known as Sweetshark [12:24] 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] mardy, the UDD importer is buggy on that source I guess [12:26] mardy, bzr branch lp:~ubuntu-desktop/shotwell/ubuntu; bzr bd-do [12:26] seb128: thanks! [12:26] yw === kentb is now known as kentb-afk === tkamppeter_ is now known as tkamppeter === MacSlow|lunch is now known as MacSlow [13:56] 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] 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] 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] rbasak: hm. we have two upstart jobs on ubuntu. one to load up hwclock time and one to save. [14:29] rbasak: at boot hwclock time is loaded, later ntp runs and ajusts time, at shutdown the time is saved back into hwclock. [14:29] xnox: hwclock-save and hwclock, right? [14:30] xnox: hwclock does: exec hwclock --systz $tz --noadjfile $badyear [14:30] rbasak: correct. hwclock at boot, hwclock-save at shutdown. [14:30] xnox: so it seems that it doesn't load any more [14:30] xnox: no --hctosys [14:30] --systz is just for non-UTC RTC correction for dual boot with Windows, AFAICT from the man page [14:30] So I _think_ responsibility has moved to the kernel [14:31] If you specify neither --utc nor --localtime, the default is which‐ [14:31] ever was specified the last time hwclock was used to set the clock [14:31] (i.e. hwclock was successfully run with the --set, --systohc, or [14:31] --adjust options), as recorded in the adjtime file. If the adjtime [14:31] file doesn't exist, the default is UTC time. [14:31] .. [14:31] rbasak: we always run with one of --utc or --localtime. [14:32] rbasak: so we don't need hctosys. [14:32] xnox: right, but that's not the issue here. My problem is that the system time is (sometimes) 1970. [14:32] unless i'm understanding this wrong. [14:32] xnox: Eh? [14:32] xnox: You need hctosys if the kernel isn't picking up the system time elsewise. [14:32] infinity: is it a bug if the kernel doesn't pick up the system time? [14:32] xnox: --systz explicitly doesn't read the hardware clock. [14:33] I'm not entirely sure what's going on, since I only get to examine the system after some time. [14:33] rbasak: In theory, the kernel should probably always have the right time these days. In theory. Where are you seeing it not? [14:33] In my failure case, the hwclock is correct, but the system time is 1970. [14:33] I've also had another failure case the other way round, though. [14:33] infinity: midway. [14:33] midway has a hwclock that works? [14:33] So I think a kernel bug is not out of the question. [14:34] highbank didn't. This is progress. [14:34] Oh, really? [14:34] I thought it worked. [14:34] Perhaps that's my problem. [14:34] 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] Define "battery-backed". I think it retains it as long as the chassis is powered, even if a node "isn't". [14:35] (ie. as long as the BMC is powered I think that means) [14:35] rbasak: and you don't have working ntp? [14:35] Except that BMCs randomly cut/blip power occasionally. ;) [14:35] And I'm not even sure your assertion is true. [14:36] 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] Anyhow, if you're seeing a correct time in the hwclock, then this tangent in the conversation is pointless. [14:36] And it's possible the rtc driver just sucks (or doesn't exist) for that platform. [14:36] Which would be a "bug robher" thing. [14:36] 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] rbasak: From my experience with highbank, I'd say that relying on the hwclock at all is just wrong. [14:37] rbasak: But robher would know more about if midway is better somehow, and if it has a functional rtc driver. [14:38] infinity: juju agents fail if the system clock is wrong. [14:38] infinity: so somewhere between MAAS handing off to juju, the clock needs to be fixed. [14:38] rbasak: And do we expect to run juju/maas in an environment where we can't sync clocks sanely? [14:38] It's fine to require that we can sync clocks. The question is: where? [14:38] On every boot, with ntpdate? [14:38] 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] 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] xnox: nope. But perhaps we should add that. [14:40] doko: I know and I have no idea why [14:40] xnox: OTOH, it would be nice if I could just configure MAAS with the address of a working ntp server [14:40] rbasak: if it doesn't, and network doesn't have NTP, it's doomed =) [14:40] xnox: you may be thinking of the MAAS datasource clock skew issue. That part is working fine. [14:41] rbasak: so broadcast / advertise NTP? [14:41] 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] Do what I do, highjack DNS for ntp.ubuntu.com, so you don't have to change any default configs. [14:42] (Don't do what I do) [14:42] (Please) [14:42] 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] 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] 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] 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] rbasak: panic 0 [14:44] 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] cjwatson: does d-i have NTP support / ovverride hwclock time, with NTP one? [14:45] 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] 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] rbasak: ntpdate is run by an ifupdown snippet every time an interface comes up, if it's installed. [14:46] 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] infinity: oh, so it is! [14:48] 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] # Not used if NTPDATE_USE_NTP_CONF is yes. [14:48] NTPSERVERS="ntp.ubuntu.com" [14:49] NTPDATE_USE_NTP_CONF=yes [14:49] ntp.conf has ntp.ubuntu.com, but also ....ubuntu.pool.ntp.org. [14:49] Note that NTPDATE_USE_NTP_CONF=yes has no effect if you have no ntp.conf [14:49] But I guess you do. [14:50] So it seems that my issues are entirely due to my NTP-firewalled lab environment? Great. [14:55] 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] xnox: It has some in clock-setup, don't remember the exact details === kentb-afk is now known as kentb [15:19] 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] hi, any clue about this error? configure.ac:66: error: possibly undefined macro: AC_DEFINE [15:20] i googled it, it says that i check about pkg-config, autotools, etc... but i have everything installed [15:29] barry: don't scare me [15:29] yolanda: I suggest putting the source package somewhere for people to look at [15:30] cjwatson, happens to me with couchdb, when i just added a -- with autoreconf in rules [15:30] i added dh-autoreconf bd in debian/control [15:30] do you want me to push to chinstrap? [15:33] tumbleweed: is that better than essentially disabling all *-pypy binary packages that trigger mirs? it's Something We Should Discuss [15:34] 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] tumbleweed: yeah, there is that [15:35] * barry might start a mlist thread [15:36] 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] 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] cjwatson, i'm looking at 1.4.0-0buntu1 version, line number looks ok: AC_DEFINE([HAVE_BUILTIN_EXPECT], [1], [15:47] 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] cjwatson, mm, removing that breaks build anyway, so do you want me to push to chinstrap so you take a look? [15:49] i need to run autoreconf because i need to inject a new DISTRIBUTION var into Makefile, to display Ubuntu distribution [15:52] 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] 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] cjwatson, thx [15:52] i'll try it [15:52] -I m4 isn't relevant [15:53] And removing that is very probably a bad idea [16:02] 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] Great [16:04] 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] 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] Looking for the offending unexpanded macro in the generated configure script is the best way to debug this kind of thing [16:07] cjwatson, nice to learn more about that === tarpman_ is now known as tarpman [16:45] mdeslaur: hey, have you seen https://bugs.launchpad.net/ubuntu/+source/libcommons-fileupload-java/+bug/1251340 ? [16:45] Ubuntu bug 1251340 in libcommons-fileupload-java (Ubuntu) "Missing jar file in 1.2.2-1ubuntu0.12.04.1" [Undecided,Confirmed] [16:46] Laney: no, I had not, thankt [16:46] thanks [16:46] np [16:47] is there an easy way to have sbuild know how to fullfill a dependancy from a PPA ? [16:49] 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] roadmr: that was my first idea [16:50] roadmr: I'll do that, I don't need much automation in that context [16:51] roadmr: thanks [16:52] caribou: no problem! === jono is now known as Guest50394 [17:44] 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] where can I find more info on $(py_setup_install_args) ? [18:09] (nevermind) [18:24] 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] slangasek: Ben and I got sorted in /msg [18:25] infinity: hmph [18:25] (I didn't notice he'd asked here) [18:25] ah :) [18:43] bdmurray: do I recall that you're looking to aggregate many bugs of this sort? 1251537 [18:47] sarnold: nope, that kind [18:47] er not that kind [18:49] bdmurray: whooops then :) thanks [18:54] slangasek: I've also found many a VarLogDistUpgradeApttermlog.gz file with one of the following errors http://pastebin.ubuntu.com/6422642/ [19:11] slangasek: raring wasn't working properly, but saucy appears to be installing things [19:11] interesting [19:14] bdmurray: well, those are all dpkg database corruption [19:15] bdmurray: so it probably points back to the same general lack of sensible error handling of dpkg --unpack failures [19:15] slangasek: those were independent of the --unpack failures [19:16] ah [19:16] bdmurray: did those errors immediately precede the "already configured" error, though? [19:17] slangasek: However, why can't I have gcc-powerpc-linux-gnu and gcc installed together? [19:17] hum, I don't know the answer to that one :) [19:17] in saucy? [19:17] Yeah [19:17] slangasek: in some cases I guess so [19:18] 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] I may have some mixed raring/saucy packages, so let me clear that up first [19:18] dpkg: error processing apt (--configure):^M package apt is already installed and configured^M [19:18] 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 === Pici is now known as Guest25996 === Guest25996 is now known as Pici [21:16] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray [22:13] mdeslaur, Is it worth merging ruby1.8? [22:17] And to anyone with buildd powers, guava-libraries failed to upload [22:40] isn't ruby-1.8 being removed in debian? [22:42] there is a tracker, so probably makes sense to follow with it for trusty [22:44] 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] xnox, do you mind if i change vtk's depends from tiff to tiff5? It's causing other packages to ftbfs