[00:35] slangasek: re e.u.c: JDFI. If anyone complains about it going away, send them to the TB. The TB exists (or doesn't) to resolve technical disputes, not to design the OS. [00:41] ScottK: yes, I wasn't proposing to send this to the TB, that was stgraber :) [00:41] Ah. OK. [00:41] I only said to assign the bug to the TB to open e.u.c for trusty... if it's going away, we can just make it go away in the code [00:42] Right JFDI getting rid of it then. [00:44] ScottK: changing the various packages to stop putting extras.u.c in the distro is something that can be done at any point without TB approval, that's fine. The TB should still be the one making the decision to kill the delegation to the ARB, kill the team and update all the exceptions about extra repositories that were designed for the ARB. === Noskcaj10 is now known as Noskcaj [00:45] so yeah, killing it from the distro can easily be done without a TB, killing it for good, will need a bit more paperwork and discussions, though that can be done later and shouldn't be a big deal anyway [00:45] Sooner the better. [00:46] agreed [01:12] So JFDI the distro bits and the rest can be cleaned up later. I think any TB decision would be a formality at this point. [06:26] hey stgraber, I haven't been on the ARB for a while === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [15:17] does aarch64 in ubuntu have neon? [15:18] I'm updating fftw, and wondering if I should preemptively enable its neon support on aarch64 [15:33] are there (expected to be) any Aarch64 processors that have no support for neon? [15:44] there is neon for arm64 and it's been extended, over v7 offering. No idea if it's optional or mandatory. [15:54] that shouldn't matter it does runtime detection [15:54] so the compiler will accept the flagß [16:00] the DEB_HOST_ARCH is arm64? [16:13] highvoltage: you're still in the team apparently, which is all I care about to get the archive fixed ;) [16:15] xnox: neon is mandatory for aarch64. [16:15] infinity: ah, cool. [16:15] highvoltage: you are our south african back door! \o/ [16:19] the DEB_HOST_ARCH is arm64? [16:21] stgraber: heh, ok [16:22] seems to be, at least thats used in xorg [16:27] highvoltage: can you go to https://launchpad.net/~app-review-board/+archive/ppa/+copy-packages [16:27] highvoltage: then copy lightread from quantal to saucy (copy including binaries, no rebuild) [16:28] highvoltage: s/saucy/trusty/ sorry [16:28] highvoltage: once it's fully published in trusty, removed it from the archive at https://launchpad.net/~app-review-board/+archive/ppa/+delete-packages [16:28] highvoltage: (that's all so we get the trusty series initialized and can get the release upgrader to work again) [17:14] cjwatson: Okay, you can stop with the transitions now. I think you've firmly established ownership of the activity donut. [17:15] xnox: You too, young man. :P === Guest6309 is now known as Vivek === Vivek is now known as Guest62207 === Guest62207 is now known as Vivek [18:35] infinity: direct SQL queries on the database do not count ;-) [18:39] can some dev or package maintainer take a look at bug 1183580 please? the debian library seems to work fine and would need to be synced [18:39] bug 1183580 in librcc (Ubuntu) "librcc segfaults on latest saucy" [High,Triaged] https://launchpad.net/bugs/1183580 [18:41] it's has been broken for months now and I feel like something needs to happen [18:59] brainwash: librcc source package is in sync with debian, and what is in 13.10 and Trusty is same source as in debian. [18:59] brainwash: to it's an ubuntu specific problem: e.g. when/how it was compiled, or our toolchain, or one of the reverse dependencies, etc. [19:00] If the Debian binary works and ours doesn't, it may come down to toolchain differences, perhaps some flag needs setting to make it behave. [19:01] the actual package maintainer seems to be inactive, so any chance for a fixed package? [19:01] * infinity can look at it when he gets home tonight, if xnox doesn't beat him to it. [19:02] thanks, I really hope it will get fixed in saucy :) [19:02] brainwash: define "actual package maintainer"? =) ubuntu packages are collectively maintained, and debian maintainer doesn't have to look into ubuntu specific bugs. [19:02] fixing it in saucy requires an SRU; syncing the version from Debian is unlikely to be a valid SRU target [19:03] slangasek: especially when saucy is in-sync with current sid ;-) [19:03] https://launchpad.net/ubuntu/+source/librcc [19:03] right, or even syncing the new upstream version from $wherever [19:03] does mention the name of the maintainer [19:05] Well, if building the new upstream on Ubuntu works, there's probably a cherry-pick one can make from $upstream_vcs. [19:05] If no one's done anything about this in the next ~8h, I'll poke it with a large stick when I get back from shenanigans. :P [19:08] Shenanigan's? https://plus.google.com/107394684970924577932/about [20:47] stgraber: ok, copying lightread from quantal to trusty... [20:47] "Requested sync of 1 package to Application Review Board PPA. [20:47] Are debug symbols available for ppa:gnome3-team/gnome3 ? [20:47] Please allow some time for this to be processed." [20:49] stgraber: so what should I remove once it's fully published? lightread for trusty of for quantal or all of it? [20:51] highvoltage: the one in trusty [20:51] highvoltage: we just want LP to generate the pocket on ppa.launchpad.net but don't actually want anything in it at the end [20:51] ah I see [20:52] highvoltage: I guess publishing should be done in ~10min, then you can remove it and we'll be good in another ~10min [20:53] stgraber: ok, will check on the hour [20:56] it's published, removin... [21:00] highvoltage: thanks [21:01] hope it worked :) [23:53] Can someone look at all our ogmrip packages? many of them should either be removed or synced from deb-multimedia