TheMuso` | @pilot in | 00:07 |
---|---|---|
=== 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` | ||
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:16 |
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:17 |
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:18 |
TheMuso` | Maybe something we need to add to auto pkg testing... | 00:19 |
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:20 |
TheMuso` | Yup, just wasn't sure if the merge upload was the broken one. | 00:21 |
wgrant | StevenK: Yeah, I just downgraded. | 00:21 |
=== steve__ is now known as sbeattie | ||
TheMuso` | Ok, fix uploaded, relatively simple in the end, give it an houro ro so I guess. | 00:45 |
=== hholtmann_ is now known as hholtmann | ||
TheMuso` | @pilot out | 04:02 |
=== 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 | ||
sarnold | brainwash: jfyi: http://www.openwall.com/lists/oss-security/2013/11/15/2 | 05:38 |
=== freeflying is now known as freeflying_away | ||
pitti | Good morning | 06:16 |
pitti | bdmurray: thanks! | 06:23 |
=== freeflying_away is now known as freeflying | ||
=== freeflying is now known as freeflying_away | ||
=== freeflying_away is now known as freeflying | ||
dholbach | good morning | 08:00 |
=== freeflying is now known as freeflying_away | ||
=== sgnb is now known as Guest40212 | ||
cjwatson | slacker_nl: openssl> doesn't seem so - must've been overlooked | 09:23 |
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:24 |
cjwatson | brainwash: Ah, looks like sarnold is taking care of it | 09:25 |
JackYu | cjwatson, you are so busy:) | 09:43 |
=== doko_ is now known as doko | ||
doko | seb128, empathy ftbfs in -proposed | 09:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 09:59 |
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:00 |
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:01 |
seb128 | but you can see, strictly no change in the build/linker | 10:02 |
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:08 |
pitti | I don't see any other change which could potentially do this | 10:09 |
seb128 | pitti, well, maybe that's what is creating the issue, but adding those back doesn't seem the right fix | 10:18 |
seb128 | Laney, pitti: doh, I fixed it | 10:22 |
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:23 |
Laney | haha | 10:24 |
tseliot | pitti, seb128: do either of you have the time to approve the nvidia packages in trusty? bug #1250449 | 10:26 |
ubottu | bug 1250449 in nvidia-graphics-drivers-319 (Ubuntu) "Include the 331 driver in Ubuntu" [Medium,In progress] https://launchpad.net/bugs/1250449 | 10:26 |
pitti | tseliot: I can have a look later (but we don't usually have bugs for NEW packages) | 10:29 |
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:30 |
tseliot | that was the idea | 10:31 |
tseliot | pitti: thanks | 10:31 |
doko | TheMuso`, was it intended to go backwards with the dotconf soname bump? | 10:32 |
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:35 |
doko | zul, jamespage: please have a look at http://people.canonical.com/~ubuntu-archive/nbs.html (msgpack-python) | 10:38 |
doko | pitti, I see that postgresql-server-dev-9.3 wants to demote ... | 11:08 |
doko | zul, jamespage: removing msgpack-python, python-msgpack provides it | 11:14 |
lifeless | so something weird | 11:15 |
lifeless | latest raring cloud image has /etc/systemd/system on it | 11:15 |
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:16 |
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:17 |
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:18 |
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:19 |
slickymaster | good morning all | 11:20 |
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:21 |
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:22 |
pitti | s/i/is/ | 11:23 |
xnox | infinity: something like https://bugs.launchpad.net/linaro-aarch64/+bug/1186352 ? | 11:23 |
ubottu | Ubuntu bug 1186352 in Linaro AArch64 cross-distro work "boost 1.5x library "context" needs porting" [Undecided,New] | 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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
lifeless | xnox: brilliant, thanks heaps! | 11:30 |
=== brainwash_ is now known as brainwash | ||
=== MacSlow is now known as MacSlow|lunch | ||
=== Sweetsha1k is now known as Sweetshark | ||
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:24 |
seb128 | mardy, the UDD importer is buggy on that source I guess | 12:25 |
seb128 | mardy, bzr branch lp:~ubuntu-desktop/shotwell/ubuntu; bzr bd-do | 12:26 |
mardy | seb128: thanks! | 12:26 |
seb128 | yw | 12:26 |
=== kentb is now known as kentb-afk | ||
=== tkamppeter_ is now known as tkamppeter | ||
=== MacSlow|lunch is now known as MacSlow | ||
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:56 |
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:57 |
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. | 13:58 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:40 |
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:41 | |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:48 |
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:49 |
rbasak | So it seems that my issues are entirely due to my NTP-firewalled lab environment? Great. | 14:50 |
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:55 |
* rbasak disappears for a while | 14:58 | |
cjwatson | xnox: It has some in clock-setup, don't remember the exact details | 15:01 |
=== kentb-afk is now known as kentb | ||
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:19 |
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:20 |
tumbleweed | barry: don't scare me | 15:29 |
cjwatson | yolanda: I suggest putting the source package somewhere for people to look at | 15:29 |
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:30 |
barry | tumbleweed: is that better than essentially disabling all *-pypy binary packages that trigger mirs? it's Something We Should Discuss | 15:33 |
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:34 |
barry | tumbleweed: yeah, there is that | 15:35 |
* barry might start a mlist thread | 15:35 | |
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:36 |
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:43 |
yolanda | cjwatson, i'm looking at 1.4.0-0buntu1 version, line number looks ok: AC_DEFINE([HAVE_BUILTIN_EXPECT], [1], | 15:46 |
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:47 |
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:49 |
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:52 |
cjwatson | And removing that is very probably a bad idea | 15:53 |
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:02 |
cjwatson | Great | 16:03 |
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:04 |
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:06 |
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:07 |
=== tarpman_ is now known as tarpman | ||
Laney | mdeslaur: hey, have you seen https://bugs.launchpad.net/ubuntu/+source/libcommons-fileupload-java/+bug/1251340 ? | 16:45 |
ubottu | Ubuntu bug 1251340 in libcommons-fileupload-java (Ubuntu) "Missing jar file in 1.2.2-1ubuntu0.12.04.1" [Undecided,Confirmed] | 16:45 |
mdeslaur | Laney: no, I had not, thankt | 16:46 |
mdeslaur | thanks | 16:46 |
Laney | np | 16:46 |
caribou | is there an easy way to have sbuild know how to fullfill a dependancy from a PPA ? | 16:47 |
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:49 |
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:50 |
caribou | roadmr: thanks | 16:51 |
roadmr | caribou: no problem! | 16:52 |
=== jono is now known as Guest50394 | ||
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 | 17:44 | |
orbisvicis | where can I find more info on $(py_setup_install_args) ? | 18:00 |
orbisvicis | (nevermind) | 18:09 |
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:24 |
slangasek | infinity: hmph | 18:25 |
infinity | (I didn't notice he'd asked here) | 18:25 |
slangasek | ah :) | 18:25 |
sarnold | bdmurray: do I recall that you're looking to aggregate many bugs of this sort? 1251537 | 18:43 |
bdmurray | sarnold: nope, that kind | 18:47 |
bdmurray | er not that kind | 18:47 |
sarnold | bdmurray: whooops then :) thanks | 18:49 |
bdmurray | slangasek: I've also found many a VarLogDistUpgradeApttermlog.gz file with one of the following errors http://pastebin.ubuntu.com/6422642/ | 18:54 |
BenC | slangasek: raring wasn't working properly, but saucy appears to be installing things | 19:11 |
slangasek | interesting | 19:11 |
slangasek | bdmurray: well, those are all dpkg database corruption | 19:14 |
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:15 |
slangasek | ah | 19:16 |
slangasek | bdmurray: did those errors immediately precede the "already configured" error, though? | 19:16 |
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:17 |
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 | 19:18 |
=== Pici is now known as Guest25996 | ||
=== Guest25996 is now known as Pici | ||
bdmurray | @pilot in | 21:16 |
=== 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 | ||
Noskcaj | mdeslaur, Is it worth merging ruby1.8? | 22:13 |
Noskcaj | And to anyone with buildd powers, guava-libraries failed to upload | 22:17 |
jtaylor | isn't ruby-1.8 being removed in debian? | 22:40 |
jtaylor | there is a tracker, so probably makes sense to follow with it for trusty | 22:42 |
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:44 |
Noskcaj | xnox, do you mind if i change vtk's depends from tiff to tiff5? It's causing other packages to ftbfs | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!