[00:00] Anyone around that knows the first magic to put in the Sources file to make it functionally empty? Trying to make a repo that has deb-src be a noop. [00:06] coderanger: Just make it empty? [00:07] coderanger: Of course, if you're distributing binaries built from copyleft (like, GPL) source, you really don't want your Sources to be empty. :P [00:07] infinity: "Encountered a section with no Package: header" [00:08] infinity: These aren't packages built from normal debian-style sources, so deb-src is meaningless [00:08] but easier to make it a noop than to explain to users why apt-add-repo is wrong :-0 [00:09] coderanger: So just don't have a Sources.gz at all if you don't intend to serve deb-src... [00:09] coderanger: apt-add-repository only turns on matching deb-src if people call it with -s/--enable-source [00:09] No [00:09] Its the default [00:10] (unless apt-add-repo was changed since 12.04) [00:12] Anyhow, I don't get the error you do with a zero-length Sources file. [00:12] (Just tested) [00:12] Hmm, what about with a single newline in it [00:12] S3 was grumping about 0-byte files [00:12] That would confuse apt, yes. The first line of Packages/Sources shouldn't be a newline. [00:12] Okay, hmm [00:13] If you're doing this in a storage scenario that hates zero-byte files: [00:13] (base)adconrad@cthulhu:~/source-test$ : > Sources && gzip -c Sources > Sources.gz [00:13] (base)adconrad@cthulhu:~/source-test$ ls -l [00:13] total 4 [00:13] -rw-rw-r-- 1 adconrad adconrad 0 Jan 5 17:13 Sources [00:13] And then upload Sources.gz, but not Sources. Problem solved. [00:14] -rw-rw-r-- 1 adconrad adconrad 28 Jan 5 17:13 Sources.gz [00:14] Hah, fair enough [00:14] Most real Debian/Ubuntu mirrors never publish the non-compressed versions anyway. [00:14] Yeah, I just have the tool generate them for the hell of it [00:17] * mwhudson has to laugh at this [00:17] Hmm, the zero-byte error might be libcloud instead of S3, sigh [00:21] mwhudson: Hmm? [00:22] coderanger: the battle between different unhelpful technologies and the solution of compressing a 0-byte file into a larger thing [00:24] mwhudson: lolcomputers [00:24] yeah [00:26] Well, given the HTTP overhead in requesting and returning a 0-length file, making it 28 bytes isn't really making the problem much worse. :P [00:29] Hm. Why isn't upstart-dbus-bridge started on the system init? [00:39] RAOF: hey, can i bug you about my x problem quickly? [00:39] mwhudson: Sure [00:39] RAOF: every so often i get a short freeze, something restarts [00:39] and then some font render buffer is corrupted and i get this sort of thing: [00:40] RAOF: http://people.canonical.com/~mwh/mangled.png [00:40] (x220 so sandybridge graphics) [00:40] RAOF: is this a known problem? [00:41] I get that sometimes with my i915 lockups. [00:41] And sometimes not. [00:41] Whee! I love font cache corruption. [00:41] (The corruption, that is) [00:41] yeah, it's not every time [00:41] the lockups themselves seem to happen a lot more when spotify is running, but that might just be anecdata [00:41] I'm not aware of that problem, but I'm less involved in the X bug triage than I once was :) [00:42] mwhudson: Say, since you're another poor Sandy user, maybe you've seen the weird bug that no one else has ever seen... [00:42] RAOF: heh, fair enough [00:42] is there some way to dump the cache at least? [00:42] mwhudson: When you open new windows (a new Firefox, a new gnome-terminal, whatever), do they sometimes seem to lose the ability to repaint themselves except when being moved? [00:42] infinity: not seen that one [00:43] Weirdst bug ever, cause I seem to be the only one who sees it. :/ [00:44] infinity: you got lucky with hardware? [00:44] I guess, but it's hardly obscure hardware. === freeflying_away is now known as freeflying [00:44] T420s [00:45] Basically identical to your X220 under the hood. [00:45] i mean, you have slightly broken hardware [00:45] ? [00:45] it's not like i'm the only person in the company with an x220 either :) [00:45] Also possible, but I'd expect broken hardware to behave in more obviously broken ways, not in ways that look like software bugs. :P [00:46] Whereas the Sandy lockups and font cache corruption are things everyone experiences, AFAIK, to varying degrees. [00:46] But my weird "new windows don't know how to window correctly" thing seems unique. [00:46] Or other people just have never sorted out how to describe it and close their non-responsive (not actually, but not painting sure LOOKS unresponsive) windows out of frustration... === panda is now known as Guest88517 === shuduo|afk is now known as shuduo [04:17] dpkg: error processing /var/cache/apt/archives/gstreamer1.0-plugins-ugly_1.2.2-1ubuntu2_i386.deb (--unpack): [04:17] trying to overwrite '/usr/share/locale/id/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:i386 0.10.19-2ubuntu2 [04:17] alkisg: Yeah, join the club :) [04:18] * alkisg removed gstreamer 0.10 ugly to work around that... [04:18] You're looking at bug #1266141 [04:18] bug 1266141 in gst-plugins-ugly1.0 (Ubuntu Trusty) "package gstreamer1.0-plugins-ugly 1.2.2-1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/locale/sl/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:amd64 0.10.19-2ubuntu2" [High,Triaged] https://launchpad.net/bugs/1266141 [04:18] Thanks, as long as it's reported... :) [04:18] * RAOF just --force-overwrite'd it [04:53] slangasek: Hey, are you around? [04:56] Logan_, Any chance you could look at some stuff on the sponsoring queue? I've got 20+ packages, some of which we really need for xubuntu. [04:56] Also some lubuntu and ubuntu-gnome stuff [04:57] Noskcaj: Shit, that's a huge backlog. I'm dealing with Bug 1266141 right now (look at how many people affected, ugh), but I'll take a look ASAP. [04:57] bug 1266141 in gst-plugins-ugly1.0 (Ubuntu Trusty) "package gstreamer1.0-plugins-ugly 1.2.2-1ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/locale/sl/LC_MESSAGES/.mo', which is also in package gstreamer0.10-plugins-ugly:amd64 0.10.19-2ubuntu2" [High,Triaged] https://launchpad.net/bugs/1266141 [04:57] thanks. I'm one of the people affected by that bug, so a fix would be great [04:58] Oh wonderful. More pressure. :P [04:58] I managed to delete my entire home directory, so working on that first. [05:02] Logan_, nice work ;) [05:02] Oh, believe me, I'm killing it today. [05:02] rm -rf gst* != rm -rf gst * [05:02] Obviously. [05:02] I don't know why I did that. [05:04] I think I might have to back out all of the changes to the gstreamer packages if the fix I'm thinking of doesn't work. [05:05] debdiff. The moment of truth. [05:05] Oh thank god. It worked. [05:06] * Logan_ hugs Noskcaj. [05:06] * Noskcaj hugs Logan_ [05:06] Happiness everywhere. Alright. Lemme upload. [05:06] Hopefully my PC will update again now [05:09] it effects me too but just force installed it as suggested [05:12] Logan_: the pressure you must feel :D [05:12] Tell me about it. [05:13] she'll be good mate, look at all those 'effected people' cheering you on... [05:15] Uploaded. Phew. [05:15] Noskcaj: Now, onto the sponsorship queue. [05:17] Logan_, Could https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436 be one of the ones you look at? It's a two month old merge and we still need it in xubuntu [05:17] * Logan_ looks. [05:18] Noskcaj: https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1254366/comments/5 [05:18] Ubuntu bug 1254366 in xfce4-session (Ubuntu) "Add support for light-locker in xflock4" [Undecided,Confirmed] [05:19] We're wanting to fix this a a basic, no regression way now. Then get it all working fully in upstream for the next release [05:21] Noskcaj: The patch looks alright. So Jarno is just concerned that it's running a lock command for every possible one, without considering whether or not they are running? [05:22] Does this cause any error? [05:22] I guess not, since it's going to /dev/null... [05:22] Logan_, no errors, we've been calling two commands for ages [05:22] Have you tested it with and without light-locker? [05:22] I haven't personally, but some of the other xubuntu guys have [05:22] And it's all good? [05:24] Noskcaj: ^, and you didn't credit Sean. [05:25] And can I have an upstream bug where this patch was forwarded? [05:25] Sorry I'm being such a stickler. It's just the process. :) [05:27] I'll try and find one. I think sean might have fixed it upstream already [05:31] Okay. Try to find a commit. [05:31] I'll look into the gnome-tweak-tool merge now. [05:38] Noskcaj: Shouldn't we wait for Debian? [05:39] At least report it, and maybe forward the patch. We can merge if we approach feature freeze with no response. [05:39] Another sponsor may disagree, but that's my opinion on new upstream versions. [05:40] Logan_, Request of darkxst, the gnome dev lead. It's been in their testing PPA for ages. Plus pkg-gnome is understaffed, i've got stuff there needing sponsorship for 6 months [05:40] Fine. Then at least report a bug in Debian requesting a new upstream release. [05:40] I'll test the merge. [05:43] I got two conflicts. Please fix. [05:43] Will do. This is why PPA merging is a pain [05:51] I'll redo the merge, since i probably broke something [06:14] Logan_, For some reason that merge error comes up even with just bzr merge-upstream and a dropped patch [06:14] Noskcaj: That's odd. [06:14] yeah [06:23] I might leave this one till debian update it [07:04] RAOF: hm, dbus-bridge has been changed to run on session-init only these days I think?! Do you have /etc/init/upstart-dbus-bridge.conf that is RC ? [07:05] xnox: I did not have an /etc/init/upstart-dbus-bridge.conf until I modified the one from it out of /usr/share/upstart/sessions [07:07] I was just playing with watching NetworkManager events and autogenerating apt-cacher-ng's mirror substitution file from mirrors.ubuntu.com when I change networks, and realised the reason that my job wasn't triggering is that the system init isn't watching dbus :) [07:10] RAOF: i see, so you are the rare case where you _do_ want it on the system-init =) [07:10] I just wondered if there was some reason why the system-init no longer watched dbus :) === geser_ is now known as geser === alkisg1 is now known as alkisg [07:18] RAOF: well, in session-init (were most dbus events are used at the moment) it was that "session dbus" events were naked, yet "system dbus" events would arrive with "sys:" prefix. So we moved system-init system-dbus-bridge to session-init only. [07:19] if we ever get dbus-bridge using jobs in default / system-init, then we can look into having sys:dbus events filtered out on the session-init size. [07:19] (side) === sabdfl_ is now known as sabdfl === NCommander is now known as 14WABSAYH === mthaddon` is now known as mthaddon [09:00] Logan_, On the xfce-session stuff, there's no upstream bug, but the upstream devs also work on light locker, so it will be done soon. please approve the branch [09:01] Noskcaj: Please file a bug. :) [09:01] I'll do that tomorrow, need sleep now. [09:50] what does apport-noui do exactly? (it is stated that it automatically submit bugreports, but does it do so when "sumbit bug reports to canonical" is disabled?) [10:19] jamespage, why is this golang patch not applied in debian? [10:19] doko, differences in the way dpkg detects shared library deps (I think) [10:20] doko, I can probable persuade the debian maintainer to take that patch [10:20] I think it should not effect the debian builds negatively === schmidtm_ is now known as schmidtm [10:28] wgrant, your pykde4 upload now lets python3-pyqt4 depend on both libpython3.3 and libpython3.4. it should not directly link the extension against the shared library === Lutin_ is now known as Lutin [11:06] I do love embedded waflib copies everywhere ... [11:06] can't have enough of them :) [11:12] can someone reproduce the skimage adt failure? [11:12] I can't in a chroot or adt-run [11:15] (ignore the 3.4 failure, adt chokes on py3.3 which I can'T reproduce) === Sweetsha1k is now known as Sweetshark === _salem is now known as salem_ [12:32] jtaylor, https://launchpadlibrarian.net/161710633/buildlog_ubuntu-trusty-arm64.fftw3_3.3.3-7ubuntu1_FAILEDTOBUILD.txt.gz [12:32] did you introduce this? [12:32] * enable runtime detected neon support for arm64 [12:32] yes [12:32] I was told (here) arm64 has neon [12:35] so why doesnt it work? no hardware or gcc does not support it? [12:36] jtaylor: neon is uncoditional on arm64 and it's supperset of armhf, so one doesn't need to specify neon build flags [12:37] interesting, gcc could ignore the flag then ... [12:37] fix requires a change the the build system [12:37] jtaylor: it's wrong to set it. cause you might be forcing an armv7 build instead of armv8. [12:37] dropping --enable-neon will disable neon altogether even if its auto-on [12:38] jtaylor: remember that arm64 can execute armv7/32bit binaries with neon. [12:38] patches accepted, I don't have the hardware to test it [12:38] jtaylor: mk-sbuild --arch arm64? [12:38] jtaylor: mk-sbuild --arch arm64 trusty? [12:39] that works now? [12:39] nice [12:39] jtaylor: it worked since trusty opening, saucy release had small bug in qemu-debootstrap however. [12:40] but I don't use sbuild [12:41] jtaylor: use whatever you use, there is qemu-user-static binary for arm64. [12:41] so you can execute native arm64 chroots. [12:41] meh I don't have time for that now, patch it out, I'll fix it when it gets a problem in debian [12:41] fftw needs merging anyway [12:42] jtaylor: yeah back it out in ubuntu or debian or both. [12:42] cause otherwise fftw will be stuck in -proposed. [12:42] its main so nothing I can do [12:43] or better its more time efficient for someone else to drop the two lines [12:43] jtaylor: i think you should do it =)))) you could have pastebined patch "enabling neon arm64" asking anybody here to test it. [12:43] I did [12:44] was told it works, so I did it to save an extra upload [12:44] jtaylor: and there was a non-ftbfs build log? [12:44] at the time it was said qemu arm64 does not work yet [12:44] jtaylor: yes, neon works on arm64. that build FTBFS however. [12:44] asier to just do it on real hardware and see then [12:45] which is what I did [12:45] now we have the result :) [12:45] and can fix it [12:48] I'm happy to take any patches and forward them upstream [12:48] if you don't want to bother creating one drop the two lines in debian/rules and disable it altogether [12:48] I may have time to look into it myself but not today [12:49] sorry for abusing ubuntu as my testing platform, should have asked for a buildlog when I did this [12:53] information needed for a proper patch is how to detect arm64 in configure.ac [12:55] hm a debian specific one is simpler as we can assume gcc supports fpu=neon [12:55] jtaylor: aarch64* [12:55] just dropt he gcc check [12:55] (in case "${host_cpu}" etc.) [12:55] do you know an example of the top of your head? [12:56] I was basing that on the "dnl configure options" block near the top of configure.ac [12:56] the arm64 triplet starts with "aarch64" so you can use that [12:57] cf. "dpkg-architecture -aarm64 -qDEB_HOST_GNU_TYPE" (ignore stderr) [12:57] jtaylor: If you prefer pbuilder over sbuild, then 'pbuilder-dist trusty arm64 create' should do the thing [12:57] mitya57: not in saucy :/ [12:57] not running trusty yet [12:57] oh no [12:57] I'm just dumb and mixed upt he ordering [12:58] k then I can give it a try today [12:58] You can always backport ubuntu-dev-tools & qemu-debootstrap [13:01] qemu backport requires more backports :/ [13:01] jtaylor: yeah, for host_cpu aarch64 it should define have_neon & not mangle gcc flags. But do get that test-built before uploaded. [13:01] jtaylor: qemu-user-static are statically linked binaries... so just download the deb & unpack arm64 static binary out of it. [13:01] (or install trusty qemu-user-static) [13:02] nice thx [13:02] jtaylor: or run nested chroots.... =) chroot into trusty, then create arm64 pbuilder/sbuild/whatever chroot there for arm64. [13:03] why must arm64 look like amd64 :( I always click the wrong linkg when downloading debs [13:05] /usr/sbin/qemu-debootstrap --arch arm64; E: Sorry, I don't know how to support arch [13:06] version 1.7.0 [13:06] * xnox votes to rename all arches using UUIDs [13:06] jtaylor: yeah that's the other bit i've fixed in trusty. it's a shell script with hard-coded names of arches it knows about.... [13:06] (or maybe it wasn't shell, it's just a script...) [13:08] I installed the trusty versiion [13:08] 1.7.0+dfsg-2ubuntu5 [13:09] xnox: ^ [13:10] * xnox wonders if it got broke again. [13:13] hallyn: looks like 1.7.0+dfsg-2ubuntu1 merge reverted/dropped changes I've applied in 1.6.0+dfsg-2ubuntu4 [13:14] hallyn: where/how should they be done, to not get lost? as qemu-debootstrap for arm64 is now broken again... [13:15] debian/binfmts/qemu-arm64 possibly also reverted, not sure. [13:24] stgraber (or other lxc gurus): do you know if you can mount /proc in a lxc container? My debootstrap is failing me on that one: W: Failure trying to run: chroot /var/cache/pbuilder/trusty-amd64/base.cow/. mount -t proc proc /proc [13:25] didrocks: not sure if its relevant, but i see something about lxc config to mount proc/sys here: http://l3net.wordpress.com/2013/11/03/debian-virtualization-lxc-debootstrap-filesystem/ [13:25] lxc.mount.entry=proc /proc proc nodev,noexec,nosuid 0 0 [13:25] lxc.mount.entry=tmpfs /dev/shm tmpfs defaults 0 0 [13:25] asac: I guess this is to mount /proc into the container, let me look/have a try [13:29] asac: yep, that didn't do it from what I tried [13:29] xnox: ping me when its fixed and I'll have a look (bin/qemu-arm64-static also does not exist) [13:29] that its in proposed doesn't matter, the only really relevant change is arm64 support [13:31] ogra_: xnox: do you know about lxc (see didrocks question above)? if not, anyone besides stgraber who might know? [13:32] actually is arm64 build now required for proposed migration? [13:32] there shouldnt be anything blocking you from mounting /proc [13:33] ogra_: weird, I used the ubuntu template to create my container though [13:33] didrocks: i think by default you cannot mount / remount proc from inside the lxc container. You should either specify it in the template on the host side, or grant the container to do so (note it's a security risk and apparmor will block from doing so as well) [13:33] didrocks: what's your use-case / what are you trying to achieve? [13:34] xnox, better ask what is pbuilders use-case :) [13:34] xnox: I'm just trying to test locally my new ci system (pbuilder/cowbuilder are used to create source package) and I didn't want to install jenkins on my desktop, so lxc container ;) [13:34] jtaylor: the requirement is imposed by britney and it's same as it always been, the built architectures should not regress - since there if fftw3/3.3.3-5ubuntu1 built on arm64, it should continue to be built on arm64. [13:35] jtaylor: and enforced by release & archive teams =) [13:35] (and the jenkins CI job is using then the pbuilder/cowbuilder, that's why I'm trying to create one inside the container) [13:35] didrocks: right, i think we do apparmor confinment on the lxc containers by default, but there was a key / config to disable apparmor confinment for a given lxc container. [13:36] * asac lunch [13:36] didrocks: (reboot of the host may be required) [13:36] didrocks: alternatively $ juju bootstrap lcy01 / lcy02 and have disposable things to install jenkins on ;-) [13:36] xnox: interesting, ok, let me have a look :) [13:36] xnox: not so much enforced as we generally decline to overrule the automation :) [13:37] jtaylor: full docs: https://wiki.ubuntu.com/ProposedMigration [13:37] xnox: right, the thing will be jujuifed, but right now, local development :) [13:37] thx [13:38] didrocks: i at times launch throwaway instances in couple of click through dashboard.cs.c.c to install things like jenkins to not trash my host, nor sufficate from my small VM sizes / lxc container restrictions. [13:39] xnox: I gave a shot to merging backuppc following Logan's confirmation that he would not work on it [13:45] will qt 4.8.5 land in trusty? [13:47] tester56: yes, it's almost ready [13:47] Waiting for Rohan to do some final testing & upload [13:48] pfft ... 4.8 ... use 5.x ! [13:48] :) [13:48] ++ogra_ [13:48] would resolve a few crashes: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1200523 [13:48] Ubuntu bug 1200523 in qt4-x11 (Ubuntu Saucy) "Some of the kubuntu patches break plasma" [Undecided,Fix released] [13:49] see also https://bugs.kde.org/show_bug.cgi?id=302931 [13:49] KDE bug 302931 in general "changed a value in system settings and clicked APPLY [@ Plasma::FrameSvgItem::~FrameSvgItem]" [Crash,Resolved: downstream] [13:49] just experienced one crash yesterday with trusty === Fudgey is now known as Fudge [13:50] the first bug is marked as already fixed [13:51] xnox: I Have a bzr branch ready if you want to have a look [13:51] the second one looks like the same issue [13:55] caribou: make a merge proposal against lp:ubuntu/$package [13:55] caribou: leave the default reviewers. [13:55] caribou: and request a second review from me (~xnox) [13:55] (that way i get notified, and it will also land in the sponsorship queue report) [13:55] xnox: I used lp:ubuntu/backuppc/trusty-proposed as a reference branch, is that correct ? [13:55] mitya57: yeah is the same issue, but according to the bug report it is only resolved using 4.8.5 ... [13:57] caribou: lp:ubuntu/backuppc [13:57] xnox: the source branch ? [13:58] caribou: if trusty-proposed was ahead of ubuntu/backupppc, you'd add your changes on top of lp:ubuntu/trusty-proposed/backuppc but still make merge proposal into lp:ubuntu/backuppc [13:58] xnox: ok, I'll check both & rebuild if needed [13:58] caribou: it doesn't matter in this case as both lp:ubuntu/backupppc and lp:ubuntu/trusty-proposed/backuppc are the same, 3.2.1-4ubuntu2 is last version in either of the branches. [13:59] xnox: k [14:06] is medibuntu down? I can't access http://packages.medibuntu.org/ [14:06] knocte, support is in #ubuntu [14:07] sorry [14:07] (and i think medibuntu stopped a while ago) [14:10] didrocks: you can but not with the default apparmor profile as doing so is a security risk. [14:12] stgraber: ok, that confirms then, I'll fetch your documentation as well on what needs to be disabled then [14:13] stgraber: as alternative, i've directed didrocks to use beefy canonistack instances, instead of local lxc containers. [14:15] didrocks: let me grab you my sbuild LXC apparmor profile, that should do the trick for you. [14:16] stgraber: ah, excellent, that should unblock me for the short term (like today) and I'll then look at canonistack within the week [14:17] didrocks: set lxc.aa_profile to lxc-container-default-builder for your container [14:17] didrocks: then create /etc/apparmor.d/lxc/lxc-default-builder containing: http://paste.ubuntu.com/6703385/ [14:17] didrocks: after that, do "sudo /etc/init.d/apparmor reload" and restart your container [14:19] didrocks: those rules are enough for me to run sbuild here (used for LXC's own CI environment), I'm only guessing they should work with pbuilder too. If something still fails, let me know (with a copy of the dmesg output) and I'll tell you what to add. [14:20] Funny MP: https://code.launchpad.net/~chris.gagnon/kubuntu-packaging/enable-unit-tests-qtbase-opensource-src/+merge/200535 - states that DFSG is not mandatory in Ubuntu [14:20] I believe it is, at least in main/universe [14:21] Thoughts? [14:21] mitya57: He's sort of correct; for non-code elements the Ubuntu licensing policy states that we'll consider them case-by-case [14:22] Though it's still good practice to do things in a Debian-mergeable way where possible [14:22] mitya57: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp [14:22] Yes, will ask if we can skip tests that need such data [14:23] (last para of that section) [14:23] stgraber: worked perfectly! Thanks a lot :) [14:25] didrocks: good to hear! np [14:43] xnox: hm. well i keep the source at github.com/hallyn/qemu, but I looked at all the debdiffs in the archive so shouldn't have lost any changes. i'll look at 1.6.0+dfsg-2ubuntu4 again - though my internet is dead so i'm on ip-over-pigeon right now. [14:44] erm [14:44] is it just me or is the toolchain messed up ? [14:44] checking if gcc -std=gnu99 static flag -static works... *** Error in `/usr/bin/ld': corrupted double-linked list: 0x091a6558 *** [14:44] on i386 [15:00] gcc -std=gnu99 -o conftest -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -DPRE_RELEASE=0 -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-Bsymbolic -static conftest.c [15:01] $ cat conftest.c [15:01] int main(){return 0;} [15:08] /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail ../../bfd/elflink.c:13053 [15:08] xnox, seb128: do you know what might cause this: http://paste.ubuntu.com/6703638/ ? [15:08] bleh [15:08] it happens when running http://paste.ubuntu.com/6703644/ [15:08] anyone wants to look at that toolchain failure? [15:09] dholbach, I don't [15:10] seb128, should I file a bug for it? [15:10] dholbach: arch mis-match? what's your "host" / main arch, and which foreign arches are enabled? [15:10] dholbach: you shouldn't need to install "ubuntu-sdk-libs-dev:armhf" that's already installed (abeit partially) [15:11] bleh [15:11] does gcc -fPIE -pie make sense on a static binary? [15:11] mlankhorst: on some arches =))))))) [15:11] xnox: -static -fPIE -pie ? [15:11] xnox, I just wanted to make sure that everything's installed, to make sure it works as part of instructions for folks to compile their QML extensions [15:11] well I guess it might [15:11] mlankhorst: oh pie, not pic. hm.... not sure. [15:12] dholbach, I guess you can, though I'm not the best person to ping about multiarch issues, let's see if xnox manages to help you ;-) [15:12] still staticaly linked and movable [15:12] dholbach: no, you shouldn't put that in instructions. anything that click chroot create doesn't already install that's needed would be a bug in click [15:12] dholbach: the instructions should be - click create, cmake compile. [15:12] please don't work around software bugs in instructions ... [15:12] (if it is a bug) [15:13] cjwatson: should i seed cmake:native somewhere, or can you install one, btw? [15:13] cjwatson, no, I didn't want to work around software bugs - I just assumed that ubuntu-sdk-libs-dev would give people everything they potentially need to compile their QML extensions [15:13] dholbach: where are these instructions you are talking about? [15:13] dholbach: click chroot is already meant to install everything they need [15:13] xnox, there are none right now [15:13] cjwatson, ok, thanks [15:13] xnox: send me an MP with a suitable change to click/chroot.py? [15:14] cjwatson: ack. [15:15] (and this was just for playing around locally) [15:16] tedg, who could nudge https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 along? :) [15:17] dholbach, charles_ has been doing most of those reviews, considering the weather, sending hot chocolate is probably your best bet :-) [15:18] tedg, thanks [15:19] charles_, if you have a bit of time, it'd be fantastic if you could review the MP mentioned above :) [15:31] dholbach: I'll review it asap, it's third on my list right now [15:31] * dholbach hugs charles_ [15:31] thanks a bunch! [15:31] hm, when did I pick up an _ on my nick === charles_ is now known as charles [15:32] tedg: that would be Ice Frapuchinno on arrival ;-) [15:33] xnox, You clearly don't believe in the magic that is dholbach ;-) [15:33] It is freaky cold though. Staying inside today. [15:34] tedg: very cold here as well, i've put on socks today with my flip-flops. =)))))) [15:34] tedg, just come over to europe ... we are stuck in eternal fall/spring here [15:34] https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1266492 causes a FTBFS when attempting to rebuild existing xorg-server too [15:34] Ubuntu bug 1266492 in binutils (Ubuntu) "ld:i386 crashes with -static -fPIE -pie" [High,New] [15:36] tedg: is it just me or click app launcher can block until the app is started? e.g. like with normal upstart job one has $ start foo; and $ start --no-wait foo. First one will block, until foo is started. The second one, will return immediately. [15:37] tedg: i'm asking because starting click apps in the emulator, on underclock CPUs of cloud instances take forever wall-clock time, and autopilot currently timesout within "10 seconds" (actually 10x1s sleeps, which are subject to poor clock resolution) [15:37] xnox, I think that should work, but the cascading may break it. I haven't tested. But that changes a lot in the proposed MRs, so I wouldn't test on trunk today. [15:37] tedg, I could ask the XKCD guy to find out how hot a hot chocolate would need to be to survive 8200km and still be nice and warm ;-) [15:38] tedg: i'm testing as it is on the current system-images (stock, no ppas enabled etc.) [15:38] dholbach, Wonder if you could get one of those containers they store liquid nitrogen in... they're very insulated. [15:38] dholbach: isn't that same as http://what-if.xkcd.com/1/ ? [15:39] xnox, That's old :-) You might see if the behavior is different if you call "application-click" directly. [15:39] tedg: right, let me compare with what autopilot code actually calls.... [15:39] xnox, if the hot hot chocolate experiment resulted in http://what-if.xkcd.com/imgs/a/1/05.png I'd probably try tedg's approach first :-) [15:42] tedg: autopilot does "$ start application APP_ID=$(app_id)" that doesn't block does it? [15:42] (can it be optionally made to block?) [15:45] xnox, It calls "start" for the sub-jobs, which should block, no? [15:45] xnox, But, again, that's going to change a lot, so I'd not want to fix it for trunk today. [15:46] tedg: right, i'll work around that in my juju charm then. [15:46] (for now) [15:46] * xnox needs proof of concept anyway. [16:23] xnox: bug 1022815, which you commented on at one point in time has had a patch added [16:23] bug 1022815 in cryptsetup (Ubuntu) "initramfs should try password against other devices" [Undecided,Confirmed] https://launchpad.net/bugs/1022815 === sarnold_ is now known as sarnold === marcoceppi_ is now known as marcoceppi === tkamppeter_ is now known as tkamppeter [17:37] dholbach, ted: https://code.launchpad.net/~ted/upstart-app-launch/tracking-arch/+merge/196194 approved [18:37] jdstrand: regarding test-libvirt.py in qrt; it does a device-detach then checks whether the device was removed from apparmor profile. However, libvirt now waits for qemu to say the device is removed before actually removing the device, and since the guest image doesn't do acpi that never happens [18:37] jdstrand: so do you prefer to (a) add acpi to the guest image, (b) check that the device is in the vm's xml and skip the apparmor check if so, or (c) skip the test on new libvirt? [19:31] cyphermox: Hi, do you know if anyone is looking at the nm-applet bug that results in multiple "Authetication Required" dialogs onscreen? It's lp:#1224040; the bug is still present in 14.04. [19:41] smagoun: it was supposed to have been fixed long ago, I'm going to ask upstream. I certainly haven't seen it happen in a long while here and I used to get that to show up pretty easily [19:42] cyphermox: It's easy enough for me to reproduce. I came back to a machine that was idle for 2 weeks, if my math is right there were 3196 dialogs onscreen. :/ nm-applet was using 2.4GB of ram [19:42] oh, I believe you :) [19:43] cyphermox: anyway, thanks for checking with upstream. Let me know if there is anything I can do to help debug/test! [19:43] sure [19:44] I discussed this with dcbw a few times already, I'll just remind him and let him know it's still broken [19:46] oooof, 3196 dialogs? did you grab a screenshot? [19:47] sarnold: I think all the dialogs are superimposed, so they look like a single dialog (but with an evil thick black border) [19:48] roadmr: heh, those must be some very menacing pixels indeed :) [19:49] sarnold: haha :) yes, it's just the merged drop shadows from all the dialog but it looks weird somehow [19:50] sarnold: no screenshot no, but I have a witness (pmcgowan, who is not in this room right now) . You can see all the dialogs using super-w in unity, which is sloooooooooooow with that many dialogs [19:52] smagoun: oh well, it sounds less impressive than I hoped for. :) [19:53] :) === timrc-afk is now known as timrc === wendar_ is now known as wendar [21:20] Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control [21:26] cjwatson, bug 1266516 [21:26] bug 1266516 in console-setup (Ubuntu) "New version available upstream: 1.104" [Undecided,New] https://launchpad.net/bugs/1266516 [21:35] hallyn: ok, I'm here (and still trying to climb out of holiday backlog) [21:36] hallyn: I think ideally we would adjust the vm to have acpi, since the code is all still there to do this in libvirt and we should be testing for it [21:38] hallyn: iirc, the libvrt vm is dapper. if there were other reasons to update the vm that would be helpful for adding tests, then I would go that route. otherwise, skip the test until such time as you want to regenerate the vm? [21:40] jdstrand: how did you generate the vm? wonder if i coudl just update sources.list and have it work :) [21:41] hallyn: see QRT/scripts/libvirt/README.qatest [21:41] k [21:42] hallyn: basically, that should work. it is just ubuntu-minimal + ssh [21:42] Noskcaj: ack, will try to look this week; it generally takes some time [21:42] built using vmbuilder, which is being dropped :) [21:44] Hi guys. Can anyone tell me where to find the python indicator api docs? Every link I go to says it's gone. I'm fed up with the rubbish power indicator with no brightness control [21:46]