[00:29] hi guys [01:43] Noskcaj: I didn't merge it. I did a mistaken sync. === _salem is now known as salem_ [02:41] Are the official armhf Ubuntu builders running on native hardware or is it emulated? [03:01] juliank: has bug #753682 been *properly* fixed now? [03:01] bug 753449 in branding-ubuntu (Ubuntu) "duplicate for #753682 package branding-ubuntu 0.5 failed to install/upgrade: trying to overwrite '/usr/share/gnome-games/quadrapassel/pixmaps/quadrapassel.svg', which is also in package quadrapassel 1:2.32.1-0ubuntu3" [High,Fix released] https://launchpad.net/bugs/753449 [03:01] juliank: I have a staged merge of gnu-efi, but was waiting for resolution of this bug [05:37] Good morning [05:53] RAOF: hey Chris [05:53] RAOF: do you have 5 mins to review/accept the postgresql SRUs (lucid/precise/trusty)? people keep pinging [06:01] pitti: Howdie. === salem_ is now known as _salem === lisca is now known as terror_bird [06:57] good morning [06:59] Noskcaj, can you please take a look at jquery, python-wsme and libgtop2 is still unresolved as well [07:17] dholbach, I've looked at wsme, will get to the others soon [07:17] thanks Noskcaj [07:18] wsme breaks trying to debuild -S for me, and we should have had those depends since three versions ago [07:18] The old delta was more than i realised [07:20] good morning [07:50] Noskcaj, what's breaking? [07:51] Noskcaj, the problem with the (build)depends is that some are in main and some are in universe - so if we want them in main, we need to follow https://wiki.ubuntu.com/MainInclusionProcess and maintain them in main [07:51] dholbach, It says a heap of files have been modified, no matter what i do [07:52] I understand the problem (have done MIRs before), i've not got time to really look into it till school tomorrow ;) [07:53] ok... I was just commenting on "we should have had those depends since three versions ago" :) [07:56] Noskcaj, if you get -3 from from proposed and install all (new) build-deps, "debuild -S -us -uc" should work === dupondje_ is now known as dupondje [09:01] hey jodh, good morning [09:09] pitti: hi === ming is now known as Guest28776 [09:46] jamespage: is anyone taking care of the haproxy component mismatch? [09:47] Maybe just delegate haproxy-doc to universe? [09:47] relegate [10:08] rbasak: not that I am aware of [10:08] rbasak: its a new js depends right? [10:16] cjwatson, Can you tell me where I can find the code (file/library) that actually masters the official sanctioned Ubuntu flavour isos? [10:16] flexiondotorg: lp:ubuntu-cdimage is the top level [10:16] I had a quick grep of lp:ubuntu-cdimage [10:16] File? [10:16] etc/crontab [10:16] I'm not going to walk you through it file by file, but you can trace it from there [10:17] It calls out to Launchpad to build live filesystems (squashfs, etc.) [10:17] jamespage: yeah, but looks like it's only for haproxy-doc. [10:17] Unless I missed something. [10:17] The top level of that is in lp:launchpad-buildd, basically lpbuildd/livefs.py [10:17] What does it use to make the iso mkisofs or xorriso? [10:17] I'm just looking for how it is invoked. [10:17] xorriso nowadays [10:18] that stuff is in the debian-cd branch linked from configs/devel in lp:ubuntu-cdimage [10:18] cjwatson, Thanks. [10:18] CONF.sh, tools/boot/utopic/* [10:19] rbasak: indeed it is only the docs [10:19] jamespage: so, docs to universe? I can't see anyone wanting that in production anyway. [10:20] rbasak:sure [10:43] mlankhorst: do you have a wiki page/spreadsheet/similar where you collect feedback for the new X.org in the PPA? [10:44] mlankhorst: I just upgraded/rebooted, and so far unity, video, glxgears, external monitor are fine, I don't notice any difference [10:44] pitti: I'm asking for emails for now, easiest way :P [10:44] mlankhorst: ack, I'll mail you on Friday or so, when I've run them for some time [10:49] jibel,pitti: I don't suppose it would be possible to get an extra autopkgtest executor or two? The queues seem to have been backed up somewhat of late [10:50] cjwatson: it would be much more helpful if qemu wouldn't freeze all the time with current guest kernels :/ [10:51] the current retry-o-mania after wasting an hour or so is a nuisance [10:52] the timeout is 50min when the kernel upgrade freezes :( [10:52] cjwatson: not sure if we can easily get more hardware in the lab; a better option would be to switch to using HP cloud instances, vila is currently working on that (not in the context of -proposed testing, but it's not too different) [10:52] jibel: it's not just kernel upgrades, I've seen it on other dist-upgrades to proposed, to [10:52] o [10:53] OK, well thought it was worth asking === MacSlow is now known as MacSlow|lunch [10:55] jibel: or at least I thought I did [10:55] pitti, we could decrease install timeout [10:56] jibel: 20 or 30 mins would certainly do, too; but large packages like libo certainly take some time to fetch/download/install their deps [10:56] jibel: we could try with 20, and if we see "honest" timeouts with that, we'll increase again? [10:58] pitti, 20 min sounds good. LO fails all the time anyway. maybe the kernel itself will be a problem. [10:58] jibel: I suppose it happens with the kernel upgrade as they are particualrly big or have lots of files (linux-headers); it doesn't even get to rebooting the VM, so I think it's rather dying on I/O errors? [10:58] jibel: no, kernel should be fine; build timeout is 100.000 s [10:58] jibel: --timeout-install is just for dist-upgrade to -proposed and installing the test deps [10:59] jibel: btw, the other day I tried to reproduce that locally, but I never saw qemu freeze [10:59] jibel: it downloads the -proposed bits, reboots to the -proposed kernel, and happily goes on [11:02] jibel: http://paste.ubuntu.com/7903813/ ? [11:10] cjwatson, Other than the slightly different xorriso configuration for amd64+mac iso, is there anything significantly different in the iso contents? [11:11] Sweetsha1k, https://bugs.launchpad.net/ubuntu/+source/libixion/+bug/1349859 needs a MIR [11:11] Ubuntu bug 1349859 in libixion (Ubuntu) "[MIR] libixion (b-d of libixion)" [Undecided,Incomplete] === tvoss is now known as tvoss|lunch [11:29] doko_: should that read "libixion (b-d of libreoffice)"? otherwise that subject doesnt make too much sense to me ... [11:30] Sweetsha1k, no, liborcus, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [11:31] flexiondotorg: http://askubuntu.com/a/40480/3228 [11:31] doko_: ah, ok. It starts to make sense now. ;) [11:33] pitti, +1 [11:57] jibel: committed; can you roll this out, s'il te plaƮt ? === psivaa is now known as psivaa-lunch === MacSlow|lunch is now known as MacSlow [12:14] pitti, done, I also disabled 'set -x' at the end of the script to stop polluting the console with a list of packages [12:14] Hi! I was not able to find ubuntu's packaging branch for accountsservice, can anyone link please ? [12:17] the one i found is 2 years old https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/accountsservice/utopic [12:20] xnox: is bug 1320534 still an issue for you? I've used schroots for weeks under systemd [12:20] bug 1320534 in schroot (Ubuntu) "sbuild fails under systemd-boot" [Undecided,New] https://launchpad.net/bugs/1320534 [12:21] pitti: well, i just removed /dev/shm mount. [12:21] pitti: do you have /dev/shm in your sbuild/schroot under systemd? [12:22] * xnox does clean run test. [12:22] I wouldn't know why not, but let me try again [12:23] om26er: use source package + debdiff workflow $ pull-lp-source accountsservice, modify / add new changelog entry, generate source package and debdiff the two *.dsc, attach a patch to a bug report on launchpad. [12:23] om26er: there are pleaora of packages that are not available as branches. [12:23] jibel: oh, I'm just dist-upgrading a local VM: unpacking linux-headers indeed takes awfully long and pretty much kills the VM [12:23] om26er: what specifically do you want to modify in accountsservice? [12:24] jibel: but that's without an overlay on memory but onto the actual disk [12:24] xnox, I want to backport this fix https://bugs.freedesktop.org/show_bug.cgi?id=78279 [12:24] Freedesktop bug 78279 in general "Make accountsservice polkit policy work for non-local admin users" [Normal,Resolved: fixed] [12:25] xnox, It allows me to write to accountsservice over ssh, right now its not allowed. [12:25] om26er: well, create a debdiff as per above and open a bug on launchpad (if there isn't one already) and attach patch to it. [12:27] xnox, I will propose to the ubuntu's source branch, which I assume is the same ? [12:31] om26er: no, there is no source branch for ubuntu that matches the archive. [12:32] om26er: archive is authoratative, please create a patch on the bug report. [12:32] xnox, aah, ok, I will attach the debdiff then === doko_ is now known as doko [12:32] tseliot, are you aware of https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.96.1 ? [12:32] om26er: both patches and branches end up in the same sponsors review queue. [12:33] xnox, I'll try with a patch pilot to get it landed early. [12:33] xnox: oh, /dev/shm is not bind-mounted by default, I see; I now booted systemd, uncommented /dev/shm/ from /etc/schroot/default/fstab, now I have /dev/shm/ in my sid schroot [12:33] tmpfs on /var/lib/schroot/mount/utopic-amd64-8e585e3f-4774-431e-87d8-f0afdb607c60/dev/shm type tmpfs (rw,nosuid,nodev) [12:33] doko: err... I hadn't noticed. pitti ^ ImportError: No module named 'aptdaemon.pkutils' [12:34] pitti: does it look familiar? https://launchpadlibrarian.net/177412602/buildlog_ubuntu-utopic-amd64.ubuntu-drivers-common_1%3A0.2.96.1_FAILEDTOBUILD.txt.gz [12:35] tseliot: no, not at all; supposedly something in aptdaemon changed? [12:35] it seems like it [12:35] pitti: hm, not /etc/schroot/default/fstab, but rather it is the default in /etc/schroot/sbuild/fstab and it's not a bindmount but a fresh tmpfs. [12:36] pitti: and mounting/creating a tmpfs fails when booted under systemd. [12:36] tmpfs /dev/shm tmpfs defaults 0 0 [12:37] xnox: ah, that's different then; /me tests that [12:38] xnox: how do I tell a schroot to use the sbuild profile? [12:38] who is currently caring about qtbase-opensource-src ? needs a merge from Debian [12:39] doko: that would be Mirv i think. [12:39] not online [12:39] xnox: err sorry, above line is already a tmpfs mount, not a bind mount [12:39] xnox: so sbuild would automatically use the "sbuild" profile, while "schroot" would use "defualt"? [12:39] doko: oh, qt4? probably ScottK, Mirv, Riddell, or myself... [12:39] no, qtbase-opensource-src [12:39] xnox: That's Qt5. [12:40] Or mitya57 [12:40] pitti: i'm fuzzy as to how the profiles are selected =) but yeah, changes to sbuild thingy make sbuild use those options. [12:40] pitti: hence on the bug report, i've attached the failed sbuild log [12:41] xnox: ah, there's a profile= option for chroot.d/* [12:41] xnox: ok, now I get it [12:41] doko: what specifically needs merging? there is a point release jump there.... [12:42] xnox, yes, the point release. there are a lot of dep-waits [12:42] *sigh* ok. === psivaa-lunch is now known as psivaa [12:46] xnox: hah, mystery solved. Followed up [12:48] doko, pitti: aptdaemon.pkcompat seems to be a little broken: http://pastebin.ubuntu.com/7904535/ [12:49] barry, could you provide the MIR's for LP: #1349832 ? [12:49] Launchpad bug 1349832 in python-virtualenv (Ubuntu) "[MIR] dependencies for python3.4-venv" [Undecided,Incomplete] https://launchpad.net/bugs/1349832 [12:49] pitti: so..... mk-sbuild should be fixed? or should add /dev bind-mount to sbuild profile? [12:49] ... or both? [12:50] xnox: I suppose the symlink is a consequence of https://wiki.debian.org/ReleaseGoals/RunDirectory [12:50] xnox: you could change your sbuild fstab to bind-mount /run/shm instead [12:50] xnox: or just rbind-mount the whole /dev/ === timrc is now known as timrc-afk [12:51] /dev/shm/ isn't in /etc/schroot/sbuild/fstab by default, so I don't see how to fix the package [12:51] perhaps adding a commented-out bind mount if that's a common case? [12:51] pitti: why does it work when booted with upstart? [12:52] pitti: is /run/shm missing? === timrc-afk is now known as timrc [12:52] pitti: is /run/shm missing? under systemd that is? [12:52] jdstrand: (really you this time :) ) I'd like to do bug 1341083; as ufw is also in Debian (but older), how wuold you like to handle this? I upload to Ubuntu and when you update Debian you take the Ubuntu package? or submit someplace else? [12:52] bug 1341083 in ufw (Ubuntu) "ufw needs systemd unit or init.d script" [Medium,Triaged] https://launchpad.net/bugs/1341083 [12:52] barry, xnox: wait, why was python3-venv seeded? [12:53] xnox: under systemd /dev/shm/ is the actual mount, and /run/shm doesn't exist (in git a symlink to /dev/shm/ was added) [12:53] we really don't want pip in main [12:53] xnox: but in general stuff uses /dev/shm/, and /run/shm/ should be phased out [12:54] doko: did i over-seed it?! =) [12:54] where "stuff" is really just "libc" [12:54] * xnox checks [12:54] pitti: and breaking everyones existing sbuild chroots setup with mk-sbuild =) [12:54] pitti: is symlink to /dev/shm in systemd in utopic-proposed? [12:55] xnox: why everyone's? [12:55] pitti: if you file a Debian bug and point to the Ubuntu bug, that would be good [12:55] xnox: no, not yet; if it helps I can cherry-pick that, but AFAICS this wouldn't change this bug [12:55] jdstrand: do you want me to just upload (after testing, of course), or a MP? [12:55] pitti: I can also do the upload to Ubuntu if there is a debdiff [12:55] pitti: for the past 5 years or so mk-sbuild was recommended and preffered way to setup sbuild chroots advertised to all developers. I understand that you probably set them up some old-school way =) [12:55] pitti: an mp would be fine [12:56] xnox: yes, that's what I use as well [12:56] pitti: horum. [12:56] xnox: but /dev/shm/ isn't in sbuild/fstab by default, so I wonder why this breaks everyone's setups? [12:56] I've been using mk-sbuild and deleting the profile=sbuild bit for some time :) [12:56] yeah, me too [12:56] pitti: I would like to examine the unit file, both for my own edification and to make sure I understanding what it is doing [12:56] pitti: i'm confused a little. let me try something out here. [12:56] jdstrand: ack; I'll just attach it to the Ubuntu bug then? [12:57] pitti: sound sperfect [12:57] jdstrand: cheers [12:57] typo notwithstanding :) [12:57] pitti: thanks! [12:57] jdstrand: I suppose the Debian package has an init.d script, so it's not that important there; but a native unit is still nicer [12:58] pitti: it does-- there is logic in debian/rules on which to use [12:58] jdstrand: ah, we should install the init.d script in either case though, for proper LSB dependencies [12:59] otherwise a sysvinit script could never depend on ufw (not sure whether that has a practical meaning, but still) [13:02] pitti: that handling is many years old, so I don't doubt it should be fixed, especially in light of recent changes [13:03] xnox, removed [13:05] bdmurray, cjwatson, slangasek: please subscribe foundations to python-idna and python3-dateutil bug reports === _salem is now known as salem_ [13:06] doko,bdmurray,slangasek: done [13:16] doko, xnox didn't know it was seeded. all straightened out now? [13:17] * barry sees it was via email [13:25] barry, yes === tvoss|lunch is now known as tvoss [13:25] pitti hey there [13:27] xnox, looks good https://launchpadlibrarian.net/181062108/debdiff.patch ? [13:27] attached to https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1349813 [13:27] Ubuntu bug 1349813 in accountsservice (Ubuntu) "[org.freedesktop.Accounts.Error.PermissionDenied: Not authorized] While trying to change a ringtone" [Undecided,In progress] [13:37] tvoss, any update on LP: #1349834 ? [13:37] Launchpad bug 1349834 in libjsoncpp (Ubuntu) "[MIR] flask-script and libjsoncpp (b-d's for net-cpp)" [Undecided,Incomplete] https://launchpad.net/bugs/1349834 [13:37] doko, haven't gotten to it, yet. I plan on patching out those build-deps from net-cpp [13:38] om26er: looks good, assigned for pitti to review =) [13:39] jdstrand: attached, working well now and the packaging got quite a bit simpler [13:39] tvoss: hello [13:40] pitti: thanks! :) === Ursinha is now known as Ursinha-afk [13:40] xnox, thanks. === pete-woods is now known as pete-woods|lunch [13:40] om26er, xnox: yes, LGTM [13:40] pitti, un-"hello there" :) [13:41] tvoss: /me undoes the warm handshake and hug then, too! [13:41] * tvoss still hugs pitti [13:45] pitti: I have a one line patch for aptdaemon which fixes the issue http://paste.ubuntu.com/7904992/ === pete-woods|lunch is now known as pete-woods [13:45] pitti: shall I proceed with the upload? Do I have to update some bzr tree after that? [13:46] tseliot: oh, nice! please upload, I can commit that to Vcs-Bzr: [13:46] pitti: yes, please. I'll take care of the upload, you'll deal with bzr [13:47] tseliot: yep, will grab the diff from LP; thanks! [13:48] jamespage, LP: #1346056 probably needs some server love [13:48] Launchpad bug 1346056 in python-wsme (Ubuntu) "Please fix component mismatch introduced through sync python-wsme of 0.6-3 (main) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/1346056 [13:49] doko, ack [13:50] pitti: ok, aptdaemon_1.1.1+bzr973-1ubuntu4 is in. We'll also have to rebuild ubuntu-drivers-common === pete-woods is now known as pete-woods|lunch [13:54] jamespage, infinity: about the jquery, ... libv8-3.14 component mismatches ... do we want this in main? [13:54] doko, v8 is a nack from the security team [13:54] so no [13:58] tseliot: Wow, something's gone wrong somewhere. There's no aptdaemon_1.1.1+bzr973-1 in Debian, why is there an aptdaemon_1.1.1+bzr973-1ubuntu4 in Ubuntu? [13:59] juliank: I'm not really sure, all I know is that aptdaemon_1.1.1+bzr973-1ubuntu3 was breaking ubuntu-drivers-common === Ursinha-afk is now known as Ursinha [13:59] Does not matter much, not going to package a bzr snapshot in Debian anyway. [13:59] juliank: mvo seems to be the uploader of 1.1.1+bzr970-1ubuntu1 [14:00] But apparently mvo mixed up 0ubuntu1 and 1ubuntu1 [14:01] slangasek: I asked you yesterday already: Do you still need gcc 4.6 & GNU_EFI_USE_MS_ABI support for gnu-efi (what for?) or can this be dropped, and the package synced from unstable? [14:03] xnox: would you mind filing a Debian bug for bug 1326327 and CC: pkg-systemd-maintainers@lists.alioth.debian.org ? [14:03] bug 1326327 in debhelper (Ubuntu) "dh_installinit should generated update-rc.d remove to remove rc*.d symlinks" [Undecided,New] https://launchpad.net/bugs/1326327 [14:03] And if anyone here is interested in elilo, go and take it over in Debian or it will be removed. [14:04] I don't think anyone here cares about elilo [14:04] juliank: why not just take the patch into debian? the reasoning is entirely valid. [14:04] juliank: http://launchpadlibrarian.net/151318291/gnu-efi_3.0u%2Bdebian-1ubuntu1_3.0u%2Bdebian-1ubuntu2.diff.gz [14:04] (any more) === Sweetsha1k is now known as Sweetshark [14:04] xnox: I don't see the point in that patch. And I don't know if it even works anymore in 3.0v [14:04] juliank: cjwatson: we do care about building shim on precise though, and that patch was backported all the way back to precise. [14:05] sure, I was talking about elilo not gnu-efi [14:05] cjwatson: ah, noticed now. sorry. [14:06] juliank: but to answer (what for?) -> to build src:shim on precise (12.04) which has gcc-4.6 as the default toolchain. [14:13] xnox: That makes sense for precise then, but for utopic? [14:16] juliank: at the time we had to backport everything to precise. I don't know if we will continue to backport e.g. gnu-efi to precise, if shim changes. [14:17] juliank: anyway, i think that gcc-4.6 should be supported by gnu-efi, at least because of mac os =) [14:17] juliank: and not cause a static compile time #error =) [14:18] and because of 12.04 still being used for another 3 years. [14:18] xnox: But I'm not sure it works, and I don't want to risk breaking things. gnu-efi was broken in unstable for a long time already because it used stub va_* functions. Now I switched it to use gcc builtins which is the only thing that works. [14:19] juliank: please do not sync, and override/drop changes in ubuntu =) and update package as you see fit in Debian. [14:20] juliank: and the patch we carry is not useless in ubuntu. [14:26] pitti: If we were playing chess, I'd now say "check" ;-) bug 1320534 updated [14:26] bug 1320534 in systemd (Ubuntu) "systemd does not honor Ubuntu default mountpoints (as listed in /lib/init/fstab by upstart/mountall)" [Undecided,Confirmed] https://launchpad.net/bugs/1320534 [14:28] zul, LP: #1349500 please remove the six code [14:28] Launchpad bug 1349500 in python-retrying (Ubuntu) "[MIR] python-retrying" [High,Incomplete] https://launchpad.net/bugs/1349500 [14:28] doko: ack [14:34] bdmurray, cjwatson, slangasek: please subscribe foundations to libisocodes bug reports [14:35] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges [14:39] doko,bdmurray,slangasek: done. thanks for going through these [14:48] hallyn: FYI, I just created https://github.com/lxc/lxc/pull/285 to unbreak LXC under systemd [14:50] dobey, any update on ubuntu-sso-client? [14:51] hallyn: do you think it's ok to upload that to utopic? I'd also like to add a systemd unit to set up the lxc bridge and load the AA policies, so that LXC works OOTB [14:51] pitti: loks fine to me [14:53] pitti: merged into git. Do you want to push it to utopic? [14:54] hallyn: ah cool, thanks! [14:54] hallyn: yes; as I said, if you don't mind I'd like to add an lxc-net script with the guts of /etc/init/lxc-net.conf and create a systemd unit for this [14:54] pitti: yup, that'd be awesome [14:55] bug 1312532 FTR [14:55] then I'll ake a look at it and learn a thing or two [14:55] bug 1312532 in lxc (Ubuntu) "[systemd] Factorize lxcbr0 setup and use it for all init systems" [Low,Confirmed] https://launchpad.net/bugs/1312532 [14:55] fwiw I created a pair of cgmanager .service files yesterday. seemed to be working [14:55] hallyn: ah, gretat [14:55] great, even [14:55] hallyn: I had to stop cgmanager under systemd as it breaks LXC [14:56] how does it do that? [14:56] http://paste.ubuntu.com/7905528/ [14:56] but yeah the systemd job is disabled by default so should help there [14:56] hallyn: well, I suppose it's not actually cgmanager's fault, but LXC trying to talk to cgmanager when systemd does the cgroup management or so (I don't know the details) [14:56] hallyn: indeed, yes [14:57] huh [14:57] pitti: 0.28-2 also was missing the patch which made cgmanager remount it's / private, [14:57] so you ended up with extra cgroup mounts on th system. [14:57] so 0.28-3 should be a huge improvement all-around under sytemd [14:57] cool, looking forward to it [14:58] and plusgood for getting in sync with Debian, eases bug fixing all aronud [14:58] * hallyn is gonna have to disable the touchpad on this laptop. it's huge! why does eveyrone thing I want huge phones and huge touchpads? [14:58] hallyn: +1 [14:58] pitti: plusungood for burning bridges along the way :( [14:59] hallyn: you mean like the heated discussions at plumber's about who wants to own the cgroup management? [14:59] *sheesh*, these happen all the time, and IIRC that still was still surprisingly technical [15:01] xnox: thanks for clarifying bug 1320534, sorry for closing prematurely [15:01] bug 1320534 in ubuntu-dev-tools (Ubuntu) "missing /run/shm backwards compat symlink" [Undecided,Confirmed] https://launchpad.net/bugs/1320534 [15:02] pitti: hm, now i can't find where does mk-sbuild get /run/shm from. [15:02] xnox: I'm honestly not aware that I ever changed the "sbuild" profile fstab, so I never ran into that [15:02] xnox: how do you mean? isn't mountall creating /run/shm? [15:02] doko: i didn't get a chance to poke at it yet. i think i would probably just disable the tests at this point, i don't have time to debug squid. and my plate is full with getting things done for the phone beta :-/ [15:03] pitti: let me ask the question properly. [15:03] xnox: oh, in my sid schroot /run/shm is an empty dir, so I figure debootstrap? [15:03] dobey, ok, if I upload doing just that? [15:04] pitti: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674755#53 mbiebl syas that ubuntu-dev-tools should be fixed to use /dev/shm instead. But i see nothing in mk-sbuild that fiddles with /run/shm vs /dev/shm. [15:04] Debian bug 674755 in systemd "systemd: tmpfs inconsistencies (/run/lock, /run/shm, /tmp)" [Normal,Open] [15:04] simple question, is gsoap blocking the virtualbox migration, right? [15:04] pitti: unless it's copying host settings, we change init, new host != container, caboom. [15:05] doko: sure [15:05] LocutusOfBorg1: the blocker there is gridsite [15:05] I see [15:05] interesting, the debian rebuild was successful [15:07] pitti: so in my newly created mk-sbuild utopic, on utopic. shm is a symlink to /run/shm. What made it so? [15:07] juliank: yes, and I asked you in response whether Debian bug #753682 has been properly fixed [15:07] Debian bug 753682 in gnu-efi "gnu-efi: Undefined va_copy, causes gummiboot to FTBFS" [Serious,Fixed] http://bugs.debian.org/753682 [15:08] slangasek: not gonna update gnu-efi in precise? =) [15:09] juliank: in my last merge I was still maintaining compatibility with gcc-4.6 because precise uses it, and we've had to update gnu-efi wholesale in SRU before in support of shim [15:10] juliank: so I think we should keep that patch as the only delta for now; I'm otherwise happy to update gnu-efi as soon as #753682 is properly fixed (which I'll verify by rebuild-testing the gnu-efi revdeps like shim) [15:11] xnox: good question; perhaps some sysvinit postinst? [15:11] wgrant: hey, do you have a strategy for typing on your t440s without moving the mouse around? The "disable touchpad while typing" doesn't sem to be working [15:11] pitti: horum. [15:12] pitti: infinity what makes /dev/shm a symlink to /run/shm? === pete-woods|lunch is now known as pete-woods [15:13] hallyn: I always disable that option, since I manage to not touch the touchpad while typing. [15:13] hallyn: But indeed, it seems to not work. Odd. [15:14] I guess my ogre hands aren't dainty enough or something :) [15:14] pitti: initscripts.postinst ? [15:14] xnox: bingo [15:16] pitti: does your merge address that mess? =) [15:17] xnox: hm, that creates the dirs, but not the symlinks [15:18] slangasek: You did? I did not notice that [15:18] juliank: ok, lost to scrollback then :) [15:18] juliank: or I was talking to a ghost due to my IRC proxy lying to me about your presence ;) [15:18] pitti: it totally does. [15:19] xnox: I must be blind then; I only see mkdirs [15:19] arges, Hi! [15:19] om26er: hi [15:19] slangasek: Yeah, must be a ghost. The last thing I have received from you before today was on Dec 18 [15:19] pitti: if the 38 states state machine detects, RUNACTION LINKRUN or LINKDEV, either /run/shm is symlinked to /dev/shm, or /dev/shm is symlinked to /run/shm [15:20] pitti: grep for "compat_link" [15:20] that is, the last thing you wrote and mentioned juliank [15:20] xnox: yes, that's defined, but nothing is using it [15:20] arges, since you are the pilot, can you land my change ? [15:20] bug 1349813 [15:20] bug 1349813 in accountsservice (Ubuntu) "[org.freedesktop.Accounts.Error.PermissionDenied: Not authorized] While trying to change a ringtone" [Undecided,In progress] https://launchpad.net/bugs/1349813 [15:20] xnox: ooh, silly me! [15:21] Version: 2.88dsf-53.2ubuntu1 [15:21] xnox: I have my proposed merge installed [15:21] slangasek: And yes, that bug is properly fixed in 3.0v-5. I replaced all the va_* stuff in efistdarg.h with definitions using gcc builtins [15:21] om26er: looking [15:21] xnox: was looking again in my utopic chroot, and that indeed does all that [15:21] That's the only way to get it working with -nostdinc [15:21] pitti: =)))))))) [15:21] xnox: so I guess that makes it a "yes" :) [15:21] xnox | pitti: does your merge address that mess? =) [15:21] \o/ [15:22] pitti: so, when are we landing that? [15:22] xnox: as soon as someone sends enough beer to slangasek to review my merge [15:22] slangasek: we want pitti's merge to stop us from going on witch-hunts of insanity =) [15:23] . o O { why don't we have a font for U+1F37A BEER MUG ? } [15:23] juliank: perfect, thanks [15:23] pitti: on the list for this week :) [15:23] slangasek: you are speaking about creating a glyph for BEER MUG, of course [15:24] naturally [15:24] om26er: i noticed that no bug was mentioned in the changelog entry (i'm adding the one you posted) [15:25] arges, oops! forgot about that. [15:31] Hi, I'm looking for sponsorship on a package upgrade if anyone has some time to look at it. Thanks! https://bugs.launchpad.net/ubuntu/+source/sblim-sfcb/+bug/1335907 [15:31] Ubuntu bug 1335907 in sblim-sfcb (Ubuntu) "Update to version 1.4.8 sblim-sfcc for Utopic" [Undecided,New] [15:32] om26er: ok sponsored for utopic! [15:33] arges, wow, thanks [15:34] chrisccoulson: ping [15:34] chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1274605 [15:34] Ubuntu bug 1274605 in firefox (Ubuntu) "Please demote xul-ext-ubufox from Firefox Recommends to Suggests" [Undecided,Confirmed] [15:34] could someone *please* look at that [15:37] cjwatson, https://github.com/bagder/curl/commit/5fcef972b289bdc7f3dbd7a55a5ada0460b74b2d [15:38] this seems to be the problem, right? [15:38] I still don't catch if it a mistake or not, but should be the source of the problem of gridsite === Ursinha is now known as Ursinha-afk [15:38] ah, interesting. I'd be inclined to change gridsite to just use the new names [15:39] and the problem is in curl 7.37.1, the debian rebuild happened before, so we didn't get a build failure in debian [15:39] maybe curl made a mistake [15:39] well, it failed to provide compatibility, true [15:39] I guess I could backport that commit [15:40] what? [15:40] this is the commit that introduced the build failure... [15:40] AFAICS [15:40] I'm dropping a line on that commit [15:41] hallyn: would something like http://paste.ubuntu.com/7905830/ be acceptable for upstream? [15:41] LocutusOfBorg1: oh, gridsite and curl are trying to define mutually recursive includes, I see [15:42] yes [15:43] which would be because CURLOPT_WRITEDATA is now a real symbol rather than a #define [15:43] I still don't get it [15:43] curl.h has [15:43] #define CURLOPT_FILE CURLOPT_WRITEDATA /* name changed in 7.9.7 */ [15:43] and it is included before the define [15:44] htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function) [15:44] #define CURLOPT_WRITEDATA CURLOPT_FILE [15:44] it's a real symbol rather than a #define, so gridsite's #ifndef fires [15:44] because CURLOPT_WRITEDATA isn't #defined, it's an actual proper symbol now [15:44] oh yes [15:45] I missed the ifndef [15:45] anyway, if you got the problem I think my work is done ;) if you want I can try to fix it, I would like to see gsoap finish its transition [15:45] pitti: there's not some systemd-network-ish way that it would be properly done for the .service files? [15:46] LocutusOfBorg1: I've got it, thanks [15:46] i think the patch is fine (apart from a /usr/share/lxc/$script sourcing /etc/default - i dont' know if that breaks some standards. and you know how i love an drespect standards) [15:46] I did the rest of the transition a day or two ago === Ursinha-afk is now known as Ursinha [15:48] yes I see, thanks to you :) [15:51] BTW thanks for the buildd stack migration [15:51] mostly not me :) but yeah it's pretty cool [15:51] so much less hassle [15:52] after 6 years I can start build on armhf packages depending from haskell suite [15:52] surprised that didn't work before. did it hate the hardy kernel? [15:52] don't know [15:53] something like haskell-blabla-0b15202 is not coinstallable with haskell-blabla2-f212 [15:53] something like a bad haskell transition [15:53] nothing to do with scalingstack then [15:53] it's using the very same chroots [15:53] why is it working now? [15:53] I was wondering something qemu related [15:54] what series are you building these against? [15:54] no, installability won't be affected by qemu [15:54] ok let me see one thing [15:54] BTW I got already two segmentation fault in gcc [15:54] https://launchpadlibrarian.net/181061819/buildlog_ubuntu-trusty-armhf.boinc_7.4.0~nightly1~~git20140730%2Br21925~r184~ubuntu14.04.1_FAILEDTOBUILD.txt.gz [15:54] qemu: uncaught target signal 11 (Segmentation fault) - core dumped [15:54] Segmentation fault (core dumped) [15:54] since the upgrade [15:55] the second one is here [15:55] https://launchpadlibrarian.net/181036546/buildlog_ubuntu-utopic-armhf.hedgewars_0.9.21~alpha~7716~ubuntu14.10.1_FAILEDTOBUILD.txt.gz [15:55] you see, now the installation part has been successful [15:55] (I'll try to search a build log with the failure) [15:55] I'm sure the segfault was fixed by the kernel/qemu upgrade, yes [15:56] oh, that's since the upgrade? [15:56] well, did that fail before as well? [15:56] no [15:56] never [15:56] in general we can't fix qemu failures [15:56] at best we can escalate them [15:57] but qemu-user is fundamentally pretty unreliable - if it works, celebrate, if not, sorry [15:57] btw the uninstallability problem of haskell stack was only with ppa builders [15:57] don't believe that :) [15:58] https://launchpadlibrarian.net/132287908/buildlog_ubuntu-quantal-armhf.hedgewars_0.9.18-0.2~ubuntu12.10.1~ppa1_FAILEDTOBUILD.txt.gz [15:58] LocutusOfBorg1: with -proposed disabled, it's possible that you were unlucky and hit a brief period when it was broken in utopic [15:58] LocutusOfBorg1: oh come on you're seriously comparing quantal to utopic? :) [15:58] it was probably just uninstallable in quantal [15:58] since that predates proposed-migration, it would not at all surprise me [15:58] but quantal isn't worth investigating now [15:59] https://launchpadlibrarian.net/140105253/buildlog_ubuntu-saucy-armhf.hedgewars_0.9.18-0.3~saucy1_FAILEDTOBUILD.txt.gz [15:59] I can try to rebuild a package, let me reproduce [15:59] oh, wait, there's a qemu failure there, it's not package-level uninstallability [15:59] qemu: Unsupported syscall: 257 [15:59] ghc: timer_create: Function not implemented [16:00] right, so I believe that is one of the set of things fixed by the upgrade [16:00] good, that makes sense now [16:00] yes, there was a bug against it [16:00] https://bugs.launchpad.net/qemu/+bug/1042388 [16:00] Ubuntu bug 1042388 in qemu (Ubuntu) "qemu: Unsupported syscall: 257 (timer_create)" [Undecided,Triaged] [16:00] anyway, it's great that that's fixed, but armhf virtual PPAs are still basically best-effort [16:00] I think it can be closed now [16:00] cjwatson, I'm not complaining ;) [16:01] I don't know whether that deals with the problem pitti had in that bug trail, so reluctant to close [16:02] last thing, with the new format 0.4 {debupstream} isn't working anymore? deprecated? [16:03] LocutusOfBorg1: do you have a link to a recipe build where that fails? [16:03] LocutusOfBorg1: 0.4 didn't work *at all* before the upgrade [16:03] yes [16:03] https://launchpadlibrarian.net/181034312/buildlog.txt.gz [16:03] bzr: ERROR: bzrlib.errors.BzrCommandError: Invalid deb-version: {debupstream}~7716~ubuntu14.10.1: Invalid version string '{debupstream}~7716~ubuntu14.10.1' [16:06] LocutusOfBorg1: odd, looks like that should work. I can't investigate fully now, but please file a bug against launchpad-buildd [16:06] we never upgraded launchpad to 0.4 recipes [16:07] it needs newer something rather, that it doesn't have. [16:07] xnox: yes we did [16:07] xnox: on Monday [16:07] i'm so out of date =) [16:08] scalingstack brought us lots of shiny [16:08] oh, we are on scaling stack now?! =) [16:08] awesome. [16:08] yup [16:08] hey.. [16:09] it actually works and the builders have stopped falling over every ten minutes [16:09] there no equivalent to /etc/udev/rules.d/70-persistent-net.rules for block devices [16:09] is that correct ? [16:09] i know i could do things based on disk id or path with udev and guarantee links or something to the kernel device name in /dev [16:09] jodh: we should try building procenv and upstart in virtualised ppas, as they should be awesome shiny now, instead of acient xen kernels. [16:10] but is there anything that could explicitly guarantee that 'sda' was the name given to some block device and 'sdb' was to another. [16:10] * LocutusOfBorg1 opens a bug report [16:10] hallyn: re (sorry, was out for supermarket); this is the preparation for writing units which also call lxc.net [16:11] hallyn: I don't know about systemd-network in particular, but it's very simple, and we don't want to build it in Debian/Ubuntu for now [16:13] https://bugs.launchpad.net/launchpad-buildd/+bug/1350430 cjwatson :) [16:13] Ubuntu bug 1350430 in launchpad-buildd "{debupstream} not recognised by format 0.4" [Undecided,New] [16:14] seb128, gtk+3.0 unconditionall build-depends on mir, which is not avail on powerpc and ppc64el [16:14] doko, good observation [16:15] wait [16:15] since when? [16:15] Laney, since robert_ancell uploaded the Mir backend earlier today [16:15] 3.12.2-0ubuntu5 [16:15] xnox: I've already got a virt build of procenv: https://code.launchpad.net/~jamesodhunt/+recipe/procenv-daily. Odd that it's set to build daily but hasn't since the 5th though. [16:15] seems subideal [16:15] indeed [16:15] that's a bug [16:15] those happen ;-) [16:16] let me have a look, it's probably easy to change [16:16] Laney, ^ or did you start looking (don't want to dup work) [16:17] no you can, this laptop is too crappy to build gtk reasonably [16:17] k [16:17] patch headers would be welcomed too at the same time [16:17] noted [16:17] ty [16:17] Laney, how is the hackfest btw? ;-) [16:17] not enough power! [16:18] but yeah, pleasant, there's quite a few people still here [16:19] slangasek: ah, so I'm not objecting to building systemd-sysv, I just seemed to remember that the other day you said you don't want it yet; but that was probably in the trusty time frame [16:21] wow [16:21] the new buildd stack makes the build get stuck [16:21] https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439 [16:21] jodh: it builds daily, if there was any change in all the involved branches. [16:21] jodh: this is not travis-ci =) [16:22] 509 upgraded, 24 newly installed, 0 to remove and 0 not upgraded. [16:22] Need to get 468 MB of archives. [16:22] It's always pleasant to see a massive transition finally go through. [16:22] cjwatson: Congrats. [16:22] jodh: you can cron API to push "build now" for you =) [16:22] xnox: thus, it should be labelled "built daily on change", not "built daily" since it's currently misleading :) [16:24] xnox: regardless, you are right - we now see 3.13.0-32-generic in uname! :) [16:24] LocutusOfBorg1: you know that #launchpad is the right place to ask about PPA builder problems, right? [16:26] cjwatson, now I know ;) [16:26] thanks [16:28] infinity: only took weeks [16:28] jodh: wow launchpad build on virt PPAs =) [16:28] jodh: ehm upstart that is =) [16:29] jodh: we should probably bump numbers in the recipes. [16:29] xnox: omg green ticks everywhere! :-) [16:30] * jodh thinks green ticks are better than red leeches :) [16:30] cjwatson: it feels like double Christmas! === SpamapS_ is now known as SpamapS [16:36] pitti: looks good then [16:37] doko: done [16:41] pitti: right, could have been in trusty :) [16:59] zul, https://launchpadlibrarian.net/181072252/buildlog_ubuntu-utopic-i386.python-retrying_1.2.1-1ubuntu1_UPLOADING.txt.gz [17:00] no dependencies on python{,3}-six [17:00] echo six > requirements.txt [17:03] zul: swift autopkg test fails [17:03] doko: ack [17:11] jodh: wgrant: aha! [17:11] syndaemon in unity is called with -t, which doesn't stop mouse movement. dropping that flag fixes it [17:11] now i can type [17:32] pitti: so were you going to push that apparmor fix for lxc for systemd to utopic yourself? [17:33] zul: ??? http://launchpadlibrarian.net/181073883/python-retrying_1.2.1-1ubuntu1_1.2.1-1ubuntu2.diff.gz [17:33] doko: crap sorry about this [17:51] xnox, did you already look at llvm-defaults? [17:51] mitya57: about bug 1349927, Would you agree to setting this bug as a duplicate of bug 1295835? I can also move it to qtchooser if it makes more sense. [17:51] bug 1349927 in qtdeclarative-opensource-src (Ubuntu) "qmlscene doesn't work on 14.04 and 14.04.1 without installing qt5-default" [Undecided,Invalid] https://launchpad.net/bugs/1349927 [17:51] bug 1295835 in qtchooser (Ubuntu) "qtchooser should have a fallback mechanism (for version AND architecture)" [Critical,Triaged] https://launchpad.net/bugs/1295835 [18:15] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [18:27] xnox: hey, were you going to remove the Essential: yes flag from init, then? [18:27] xnox: or maybe you've already done so and it's waiting in utopic-proposed? [18:28] roadmr: feel free to mark as duplicate [18:28] mitya57: thanks === roadmr is now known as roadmr_afk [19:34] barry: hi, are you aware of bug #1349478? it's a top crasher on the phones currently [19:35] bug 1349478 in system-image (Ubuntu) "/usr/sbin/system-image-dbus:sqlite3.OperationalError:_check_for_update:emit_signal:UpdateAvailableStatus:__init__:__enter__:_cursor" [Undecided,New] https://launchpad.net/bugs/1349478 [19:35] nope haven't seen that one yet [19:35] barry: can I assign it to you? [19:36] slangasek: already done :) [19:36] cheers [19:37] slangasek: i think this is the one that ogra_ pointed me to yesterday. it can only happen if the directory /var/lib/system-image doesn't exist or has bogus perms. which makes sense in the testing environment, but not on live devices (nothing changed here). well, i guess something changed if this is happening on installed devices. [19:41] doko, Thanks for fixing jquery [19:51] barry: I don't know if the submissions are from installed devices or not - there are plenty of test environments proportional to installed devices right now :) [19:52] slangasek: true :) i'm almost positive this is related to LP: #1301995 which fixed this for log files when run as non-root [19:52] Launchpad bug 1301995 in Ubuntu system image "system-image can't open its log file if not run as root" [High,Fix released] https://launchpad.net/bugs/1301995 [19:52] guess where it's run as non-root? [19:53] barry: well, "from the apport hook", but I'm not sure if that's the answer you were looking for :) [19:53] slangasek: nope ;) [19:53] anyway, should be an easy fix. i'll try to swing around to it asap [20:00] infinity, Could you merge wxwidgets3.0 soon please? I've got a merge waiting on it [20:15] Howdy. So is there a specific date that tasksel updates Ubuntu tasks from seeds? Or would I have to poke someon/Colin about that? [20:25] mlankhorst, online? [20:42] hallyn: do we use q35 machine type much for qemu/tools that use qemu in ubuntu? [20:43] q35? [20:43] i think qemu64 used to be the default. haven't heard of q35 i dn't think [20:43] hallyn: yea machine type q35 vs i440fx (which seems to be the default for most tools virt-install/uvtool) [20:43] oh. yeah, I don't think we do [20:44] hvm [20:44] jamespage: smoser: do you kno wof any places where we use q35 (on purpose) machine type under qemu? [20:44] ok [20:44] arges: why do you ask? [20:44] hallyn: trying to get virt-test working with Ubuntu, and it runs each test on i440fx and on q35 [20:45] didn't know how widely used q35 was; since it doubles the tests [20:46] hallyn, no. only if by default. [20:46] feh, seems i've not enabled kvm in the bios [20:46] well regardless if i440fx is default and most people use it we'll start there. [20:46] sounds good === roadmr_afk is now known as roadmr [21:53] hi there, since we got a lot of users complaining they are not prompted for the LTS -> LTS upgrade from 12.04 to 14.04 can someone tell me when the LTS upgrade path will be opened? [22:04] Is there a script to do a rebuild of a list of reverse dependencies in a ppa? [22:32] xnox, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756564 any idea about that? [22:32] Debian bug 756564 in cmake "cmake's FindFLTK module proposes static libs for linking" [Important,Open] === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [23:02] doko: yes, i've seen that happen when libraries are either split badly (e.g. /lib /usr/lib and or multiarch symlinks are broken and/or non-existant) and then cmake goes south and does "statically link everything" which usually fails and fails the builds or worse succeeds the builds =( [23:02] doko: i'll look into it tomorrow. [23:02] slangasek: done, stuck in alpha2 block. [23:03] doko: i do have llvm-defaults locally, but haven't uploaded it yet. Would be stuck in alpha2 block I think, and I haven't rebuilding everything yet. [23:32] i wonder how long it takes a panda to build ghc =) [23:32] or maybe llvm 3.5 is hung ;-) [23:45] doko: what specifically breaks? as cmake FindFLTK should find /usr/lib/fltk/FLTKConfig.cmake, include it direct and get all the shared and static paths. [23:45] doko: i'll experiment more locally here, but do you have example cmake using package that uses FLTK and doesn't get shared FLTK?