[03:27] <pitti> Good morning
[06:52] <dholbach> good morning
[06:57] <didrocks> good morning dholbach
[07:08] <dholbach> salut didrocks
[07:09] <dholbach> didrocks, how was the response so far? :)
[07:09] <didrocks> dholbach: excellent! and more than positive overall, so great to see that!
[07:09] <dholbach> :-D
[07:11] <seb128> didrocks, nice to read that!
[07:13] <pitti> stgraber: I'd appreciate if you could take a look at bug 1362224 -- that seems to break cloning and juju-local pretty thoroughly?
[07:42] <zbenjamin> cjwatson: ping, is there some API i can use to find out the writeable location of a specific app or scope ? I could use a way to find this out from the SDK launcher
[08:05] <mardy> Laney: hi! About bug 1029289, I'd like to have the fix backported to trusty as well. Should I prepare a branch of eds 3.10.4 containing the backported fix?
[08:06] <seb128> mardy, laney is on holidays
[08:07] <seb128> mardy, but yeah, having an update on top of 3.10.4-0ubuntu1.2 would be the way to go there
[08:16] <mardy> seb128: OK, I'll try to prepare it
[08:16] <seb128> mardy, thanks
[08:41] <zbenjamin> jdstrand: ping, do you know if there is any API to query app writeable locations i can use from the SDK launcher? I need a shared directory so i can communicate with the app
[08:41] <zbenjamin> jdstrand: same is required for scopes
[09:23] <pitti> wgrant: to confirm, is the RTM langpack export cron'ed now?
[09:39] <wgrant> pitti: Yup.
[09:40] <pitti> wgrant: thanks! adjusting work items in https://blueprints.launchpad.net/ubuntu/+spec/qa-u-spanish-translations accordingly
[09:41] <pitti> [wgrant] Confirm that message sharing between Ubuntu and this distro will work: TODO
[09:41] <pitti> wgrant: there's still that one, FTR
[09:41] <wgrant> Oh, forgot about the blueprint.
[09:43] <wgrant> pitti: That all works fine, but let me know if anything seems off.
[09:43] <wgrant> We're on lightly tested ground here.
[09:44] <pitti> wgrant: ack, thanks; if it works in principle (i. e. stuff has translations with by and large the same numbers than ubuntu), it's fine
[09:57] <rbasak> infinity: are you available to talk about bug 1359349 please?
[09:58] <rbasak> AIUI, you had some concern about the upgrade/transition path?
[10:02] <Saviq> xnox, hey, can I bug you about a x-building conundrum?
[10:07] <doko> ScottK, please check packages before blindly removing them:  lp: #6107581 this is a normal ftbfs, and afaics has nothing to do with clang.
[10:08] <doko> bug #1346252
[10:08] <doko> xnox, no idea why you filed this one ...
[10:19] <ScottK> doko: ansgar asked me to remove it.  The documentation may have been off, but it wasn't blind.
[10:20] <Saviq> doko, maybe you'll be able to help, libqtdbusmock is a library execing python, it depends on python-dbusmock, too, the problem for x-building is that it tries to pull in build arch python-dbusmock instead of host arch, how should this be solved?
[10:40] <pete-woods> xnox: hi. do you have any time to help me with this cross-build issue I have received? https://bugs.launchpad.net/ubuntu/+source/libqtdbusmock/+bug/1364842
[10:40] <pete-woods> basically libqtdbusmock is a wrapper around the python-dbusmock library
[10:40] <pete-woods> it doesn't link it it, just execs as a module
[10:41] <pete-woods> but it seems that the ubuntu-system-settings app won't cross compile due to a dependency on libqtdbusmock now
[10:43] <pete-woods> ha
[10:43] <pete-woods> hadn't realised Saviq was just asking the same thing!
[10:44] <pitti> darkxst: FYI, I just synced https://launchpad.net/ubuntu/+source/systemd-shim/7-2 -- so you now merely need to rebuild that in your PPA against/for systemd 214
[10:55] <darkxst> pitti, great!
[11:18] <rbasak> didrocks: http://blog.didrocks.fr/post/Ubuntu-loves-Developers returns Content-Type: application/octet-stream and Firefox wants me to save a download file :-/
[11:19] <rbasak> Server: cloudflare-nginx
[11:22] <didrocks> rbasak: interesting, I don't have that with my Firefox, let me try something
[11:22] <didrocks> rbasak: mind trying again?
[11:23] <didrocks> I wonder if it's static htlm page + cloudflare doing this
[11:23] <didrocks> html*
[11:24] <didrocks> (sorry, can't really test in the same condition as my ISP doesn't allow self-dns redirection as my IP == server IP)
[11:26] <rbasak> didrocks: working now
[11:26] <didrocks> rbasak: ok, mind trying with http://79.94.243.69/post/Ubuntu-loves-Developers ?
[11:26] <didrocks> (bypassing cloudflare + static html page)
[11:27] <rbasak> didrocks: that also works in Firefox. Using wget, I no longer see a Content-Type header at all.
[11:28] <didrocks> rbasak: yeah, so it's cloudflare + static html page, thanks! that gives me a hint from where to start my investigation :)
[11:28] <rbasak> didrocks: ah, so cloudflare turns the no-content-type into a content-type=octet-stream?
[11:28] <didrocks> rbasak: that's my guess
[11:29] <rbasak> That seems a bit wrong to me.
[11:29] <didrocks> it clearly is :)
[11:46] <mdeslaur> xnox: happy birthday :)
[11:48] <jdstrand> zbenjamin: there is not yet an api to query for a writable area, though, there will be. however, the writable areas are very predictable: http://developer.ubuntu.com/apps/platform/guides/app-confinement/
[11:48] <jdstrand> zbenjamin: (see Runtime Environment)
[11:49] <jdstrand> zbenjamin: scopes are similar: https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
[11:51] <zbenjamin> jdstrand: i saw that document, my only concern is that they might change
[11:51] <jdstrand> zbenjamin: pick the ones in .local/share/...
[11:51] <zbenjamin> jdstrand: can i somehow query if a app/scope is running in confinement or not?
[11:53] <zbenjamin> jdstrand: or going to be run in confinement, i think for the app there is some env var defined that specifies that
[11:55] <jdstrand> zbenjamin: the paths won't change any time soon (we follow XDG basedirs to be predictable)
[11:56] <jdstrand> zbenjamin: you have everything you need in the sdk to know if it will be confined
[11:56] <jdstrand> zbenjamin: if it is not click, then it won't be confined. if it is click, check the apparmor template. if it is not 'unconfined', it is confined
[11:56] <zbenjamin> jdstrand: awesome thx
[11:57] <zbenjamin> jdstrand: same for scopes i gues
[11:57] <zbenjamin> s
[11:57] <didrocks> rbasak: ok, that should be fixed now (played with my htaccess to force the content type if the file is set)
[11:58] <didrocks> rbasak: I used a static html file yesterday after popey tried to DDOS me when tweeting :)
[11:58] <popey> lolz
[11:58] <jdstrand> zbenjamin: yes. so, for apps, use the ~/.local/share/<'name from click manifest'>
[11:59] <zbenjamin> jdstrand: i'm going to put files and named pipes the helper script has to read and write into those locations , so we do not need to have access to /tmp anymore, but only the supported directories
[11:59] <zbenjamin> jdstrand: ok
[12:00] <jdstrand> zbenjamin: for scopes, if it uses the 'ubuntu-scope-network' apparmor template, use ~/.local/share/unity-scopes/leaf-net/<name in click manifest>
[12:00] <ogra_> xnox, happy birthday !!
[12:01] <jdstrand> zbenjamin: for scopes, if it uses the 'unconfined' template, use ~/.local/share/unity-scopes/unconfined/<name in click manifest>
[12:01] <jdstrand> zbenjamin: that sounds great
[12:02] <rbasak> didrocks: :)
[12:02] <didrocks> thanks again for the notice :)
[12:02] <rbasak> didrocks: I use a static generator for my blog now, just so I don't have to care.
[12:02] <rbasak> No problem.
[12:05] <zbenjamin> jdstrand: so we have real confinement in case when gdbserver is not attached (no debug policy needed), and when gdbserver is attached we can cut some more privileges from the debug policy
[12:06] <jdstrand> cool
[12:06] <jdstrand> (we could remove the user-tmp abstraction)
[12:08] <zbenjamin> jdstrand:  :)
[12:27] <vak> i use  "apt-get source --compile" to compile a huge package. Is it possible to pass "-j N" option to the underlying make utility calls?
[12:37] <rbasak> vak: the standard that Debian source packages follow is to heed the environment setting DEB_BUILD_OPTIONS="parallel=N"
[12:37] <rbasak> vak: I'm not sure if apt-get source --compile passes that through or not, but you could try it.
[12:38] <rbasak> vak: paying attention to that environment setting is up to the source package though. Helpers like debhelper support it by default, unless the packager is doing something custom.
[12:38] <vak> rbasak: thank you! will the compilation continue from its interrupted place if i CTRL-C it ?
[12:39] <rbasak> vak: no idea about apt-get source --compile; I don't use that. Usually you can resume a build if you're managing it manually only.
[12:39] <rbasak> So I'd say probably not, at a guess.
[12:40] <vak> well... not sure what you mean, because the package isn't my, and the compilation i started as 'apt-get source --compile this_damn_huge_package'
[12:40] <vak> i see ))
[12:40] <vak> gotta wait then ((
[12:55] <doko> jamespage, why is bug #1353729 a blocker? there is a workaround. the real blocker for mysql-5.6 are the failing autopkg tests, now known for months and still unfixed ...
[12:59] <jamespage> doko, that's not what's blocking transition - rbasak is working on the autopkgtests
[12:59] <jamespage> doko, what's the workaround - must have missed it
[13:04] <doko> jamespage, "works with -O1", so just build this file with lowered optimization
[13:07] <vak> rbasak: 1)the DEB_BUILD_OPTIONS is respected! 2) the compilations starts from scratch
[13:44] <mardy> seb128: hi! About bug 1029289, I created a branch (lined to the bug), tested it in a ppa (ppa:mardy/daily) and updated the bug description to make it ready for the SRU
[13:48] <seb128> mardy, thanks, did you subscribe ubuntu-sponsors to the bug?
[13:49] <mardy> seb128: no, I was trying to get someone from #ubuntu-bugs; I'll follow your advice, though
[13:49] <seb128> k
[13:56] <Lazza> Hello everyone
[14:18] <mpt> mvo, hi, update-manager just opened while I was in the middle of an apt-get upgrade. That isn’t supposed to happen. Any extra logs that might be useful for the bug report?
[14:25] <mvo> mpt: it used to check with the ubuntu-system-service, but http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/788 changed this - but the change happend a long time ago. is this utopic or trusty?
[14:25] <kenvandine> bigon, i have a request related tot he folks package
[14:25] <kenvandine> bigon, i'm looking at splitting the dummy and key-file backends out of the lib package into a separate binary, so they don't get loaded everything it's used
[14:26] <mvo> mpt: if the upgrade is still running, could you run pkgexec /usr/lib/update-notifier/package-system-locked and see what that outputs?
[14:26] <kenvandine> s/everything/everytime
[14:26] <kenvandine> bigon, i think they are only used by tests
[14:26] <mpt> mvo, it’s 14.04
[14:29] <mpt> mvo, assuming you meant pkexec: “/var/lib/dpkg/lock:  22676”
[14:29] <mvo> mpt: ups, pkexec indeed . and echo $? - do you see "2" there?
[14:30] <mpt> mvo, yes
[14:31] <mvo> hm, those are the correct values, it should not have started it :/
[14:35] <mpt> Ok, just using ubuntu-bug then
[14:35] <bigon> kenvandine: hey, the key-file is used if eds is not running I think
[14:35] <bigon> the dummy one I'm not too sure
[14:36] <kenvandine> we noticed it with the address-book-service, which only needs eds
[14:36] <kenvandine> bigon, bug 1364548
[14:36] <kenvandine> bigon, i have a branch that moves them both to a libfolks-misc25 package
[14:37] <kenvandine> bigon, what do you think of that?
[14:37] <doko> jamespage, 5.5.39-0ubuntu3 re-introduces the autopkg test failures
[14:41] <doko> mlankhorst, what is the mesa/llvm status? time to update mesa?
[14:42] <jamespage> doko, I look again
[14:42]  * jamespage siggs
[14:42] <bigon> kenvandine: maybe this should be discussed with the other telepathy folks
[14:43] <bigon> are you on #telepathy?
[14:43] <kenvandine> wow... i'm not anymore :)
[14:43] <mlankhorst> doko: still waiting for someone to ack the MRE's
[14:46] <doko> mlankhorst, ok, commented
[15:06] <shadeslayer> pitti: poke
[15:08] <pitti> hello shadeslayer
[15:08] <shadeslayer> pitti: hey, so I'm sort of seeing this https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1359439 on the kubuntu-plasma5 ISO
[15:09] <pitti> yep, known issue; I think that hallyn is working on that
[15:09] <shadeslayer> pitti: trying to get to the live session from ubiquity-dm just relaunches ubiquity-dm
[15:09] <shadeslayer> http://paste.ubuntu.com/8224229/
[15:09] <shadeslayer> pitti: ok, but can someone check if it's the same issue?
[15:09] <shadeslayer> I /think/ it's the same issue, but would be nice to get confirmation
[15:10] <shadeslayer> that paste is the ubiquity-dm debug log
[15:12] <shadeslayer> http://paste.ubuntu.com/8224245 is the dmesg log
[15:14] <zbenjamin> jdstrand: i could use some more help with this. On the launcher side i can just install the click package and inspect the apparmor file to know if the app will run in confinement. But in confinement. how does a process know if its confined or not?
[15:14] <zbenjamin> jdstrand: my small helper script that sets up the env inside needs to know that
[15:16] <pitti> most certainly not; that shim error is mostly cosmetical (or sohuld be)
[15:17] <pitti> shadeslayer: that QXcbConnection: XCB error, is that the cause or consequence of the crash?
[15:18] <shadeslayer> pitti: I /think/ that's comes from ubiquity-dm and has nothing to do with the login process
[15:23] <shadeslayer> pitti: mmmm
[15:23] <shadeslayer> pitti: [   93.207654] kactivitymanage[4339]: segfault at 7f06c56bf9c8 ip 00007f06ced5f4bd sp 00007fff471f7958 error 4 in libQt5Core.so.5.3.0[7f06cea60000+516000]
[15:23] <shadeslayer> that looks bad
[15:24] <pitti> shadeslayer: sorry, gotta run now; but seems you found something there?
[15:24] <shadeslayer> yep
[15:24] <shadeslayer> I'll have a look
[15:24] <shadeslayer> pitti: thx for your help
[15:32] <jdstrand> zbenjamin: so, there are two ways: look in /proc/self/attr/current and see the label the process. the UBUNTU_APPLICATION_ISOLATION env var is also set, but I think possibly only for apps
[15:32] <jdstrand> zbenjamin: however, there is an issue-- apps that use the 'unconfined' template apparmor template in the security manifest end up with an apparmor label that is not 'unconfined'
[15:33] <zbenjamin> jdstrand: ok, the UBUNTU_APPLICATION_ISOLATION is not set for scopes , that was my first hope ;)
[15:34] <jdstrand> so the test is imperfect in that instance
[15:34] <jdstrand> scopes actually try to readdir ~/.local/share/unity-scopes/unconfined/ to see if they are unconfined
[15:35] <jdstrand> an app could try to readdir ~/.local/share
[15:35] <jdstrand> that isn't ideal, I realize
[15:36] <jdstrand> an app could check UBUNTU_APPLICATION_ISOLATION=1, and if it is, look in its security manifest to see if it is using the unconfined template
[15:38] <jdstrand> it will be better once we have the query api in place
[15:38] <zbenjamin> hm but the app or scope will not know the name of the apparmor file :/
[15:39] <zbenjamin> jdstrand: we are just supporting click packaged apps for now
[15:39] <jdstrand> tbh, this isn't a use case that was part of the design-- we figured the app developer would know whether s/he chose to use an unconfined template
[15:40] <jdstrand> why does the app need to kinow if it is confined for your use case?
[15:41] <jdstrand> actually, the query api doesn't solve this-- you still have to ask it if a particular path is readable or writable (though it would be much cleaner than doing a readdir and checking the return code)
[15:42] <zbenjamin> jdstrand: not the app, we use a generic helper script to setup the debugging environment (inject gdbserver, redirect stderr and stdout to pipes) , the config file for that has to be in a location it can read, and it of course needs to know where to look at
[15:42] <tseliot> xnox: hi, I'm wondering what was the use case of adding support for scaling the plymouth theme for LP: #1292458
[15:42] <tseliot> *for
[15:43] <zbenjamin> jdstrand: the helper script runs, sets up what we need, and then replaces itself with the app or scope using execv
[15:43] <jdstrand> zbenjamin: I suggest this: write a small library function, eg is_confined(). have it do a readdir on $HOME. if it fails, return 0, if it succeeds, return 1. when the query api is available, you can change is_confined() to use the query api
[15:44] <zbenjamin> jdstrand: awesome :) sounds good enough for me
[15:44] <jdstrand> zbenjamin: this is to be used with the debug policy group?
[15:46] <zbenjamin> jdstrand: the goal is to make this work without the debug policy group and only use it when debugging c++ or qml (release mode vs debug mode)
[15:46] <zbenjamin> jdstrand: but with the debug policy group i can read /home right, so my library call will fail
[15:46] <jdstrand> zbenjamin: that is what I was getting at, yes
[15:47] <jdstrand> the bash abstraction which is #included in the debug policy group has: @{HOMEDIRS}                      r,
[15:47] <jdstrand> so, let's use ${HOME}/.local/share
[15:47] <zbenjamin> jdstrand: that is harder than i thought ;)
[15:49] <jdstrand> that should work fine. click user hooks do stuff in ~/.local/share/click so ~/.local/share is guaranteed to exist if you install a click
[15:49] <jdstrand> if we need to change the path at some point, we can
[15:53] <Saviq> mardy, hey, found an interesting bug in OA as trusted prompts... if I go "Cancel" in the U1 setup, I get the same UI as a standalone app...
[15:54] <Saviq> mardy, one reason seems to be that it has the --desktop_file_hint still, which it shouldn't any more
[15:54] <Saviq> mardy, the other seems to be that it respawns it
[16:16] <alexbligh1> possibly a stupid question, but what is the cleanest way for a package to get its own version number either at build time (I can copy it to an installed file) or in the postinst script?
[16:16] <infinity> rbasak: I'm around now.
[16:16] <rbasak> infinity: on a call. I will ping when done.
[16:17] <infinity> rbasak: Alrighty.
[16:22] <cjwatson> alexbligh1: grub2/debian/rules:deb_version          := $(shell dpkg-parsechangelog | sed -ne "s/^Version: \(.*\)/\1/p")
[16:22] <cjwatson> or anything roughly similar
[16:22] <cjwatson> alexbligh1: in fact, since dpkg 1.17.0, you can use $(shell dpkg-parsechangelog -SVersion)
[16:22] <cjwatson> I should convert my packages to that
[16:23] <alexbligh1> cjwatson, ah that's neater. I was using dpkg-gencontrol -O, which is yucky.
[16:23] <alexbligh1> thx
[16:41] <rbasak> infinity: ping
[16:43] <infinity> rbasak: Hai.
[16:45] <rbasak> So this thing.
[16:45] <rbasak> I found that if I dist-upgrade to my prepared packaging (in my PPA), then apt-get seems to resolve the upgrade to removing mysql-server.
[16:45] <rbasak> And not installing mysql-server-5.6.
[16:45] <rbasak> I can force it by asking for a newer mysql-server.
[16:46] <rbasak> I didn't really see a way round this. A similiar thing must have happened during 5.1->5.5 but I don't see exactly what.
[16:46] <rbasak> However, AFAICT, if apt-get has no visibility of mysql-5.5 generated binary packages, then it is happy to upgrade mysql-server and install mysql-server-5.6 to resolve the situation, which is what we want.
[16:46] <infinity> rbasak: So, this will happen if the resolver thinks the 5.5->5.6 upgrade will remove more packages than just removing mysql-server would do.
[16:46] <rbasak> So, for a one off, it seemed easier to do it that way. But if you can tell me what I should be doing instead, that's fine too.
[16:47] <rbasak> I thought it was something like that.
[16:47] <rbasak> The catch is that we have multiple binary 5.5 packages that should be removed and replaced with different name 5.6 ones.
[16:47] <infinity> This may be a subtle badness in how conflicts are forcing things off, or similar?
[16:47] <rbasak> mysql-server-5.5, mysql-server-core-5.5 off the top of my head.
[16:47] <rbasak> Those would be removed, and 5.6 equivalents would be installed.
[16:47] <infinity> If it's a 1:1 swap, that shouldn't be an issue.  If the dpkg relationships are right.
[16:48] <rbasak> Removing mysql-server is removing just one package, right?
[16:48] <rbasak> And the upgrade involves removing at least two 5.5 server packages.
[16:49] <rbasak> And I do want those two removed.
[16:49] <rbasak> So surely whatever I do, apt-get will favour removing one package over removing two packages?
[16:50] <rbasak> And then once mysql-server is removed, there's nothing to pull in 5.6 even after 5.5 disappears.
[16:53] <infinity> rbasak: You mean upgrading removes 2 net packages?
[16:53] <infinity> rbasak: (ie: install 4, remove 6?)
[16:54] <rbasak> I'm not sure. Let me check.
[16:54] <infinity> rbasak: If so, you can hint apt to DTRT with decent abuse of C/R pairs.  But I'd have to see the specifics to know what's up.
[16:57]  * rbasak digs
[17:02] <rbasak> infinity: it involves installing 5 and removing 4.
[17:03] <rbasak> dist-upgrade wants to remove mysql-server, in total removing 2, installing 1 and upgrading 2.
[17:04] <rbasak> To be complete, for the upgrade it wants to remove 4, install 5 and upgrade 1.
[17:04] <infinity> rbasak: Okay, so it sounds like this is something that package relationships might be able to get slightly more right.
[17:05] <infinity> rbasak: Fundamentally, though, unless you stage your entire transition in a devirt PPA and sync it all at once, we can't do what you're asking for (process NBS before you do the transition), as that breaks the archive.
[17:06] <rbasak> I was asking to process NBS after the new binaries arrive, but before a publisher run.
[17:06] <rbasak> (I know that's unusual, but I couldn't see any other way out)
[17:06] <rbasak> Can you help me with the package relationships please? It's not clear to me what I'm looking for.
[17:08] <rbasak> Thinking about it deeper I can understand how what I was asking for may well be impossible.
[17:09] <infinity> rbasak: Asking me to process NBS after you upload is "before the transition".
[17:09] <infinity> rbasak: As things will still depend on the old binaries, and become uninstallable.
[17:09] <rbasak> OK
[17:10] <infinity> rbasak: Unless there's no new libmysqlclient this time?  That simplifies things a lot.
[17:10] <rbasak> libmysqlclient18 stays and with the same soname. I've just switched it from being built from src:mysql-5.5 to it being built from src:mysql-5.6. So apt-get sees a packaging version bump but nothing else.
[17:11]  * rbasak hopes he checked the other reverse deps, but it was a while ago.
[17:11] <zbenjamin> jdstrand: so i can write anywhere in ~/.local/share ? or in ~/.local/share/packagename
[17:11] <infinity> rbasak: So, for package relationships, the key to apt's view of the world WRT "violent removal" versus "polite removal" is that the polite option needs a Conflict/Replace pair hint, not just a conflict.  If you have a bunch of conflicts, then it assumes all conflicting packages are "equal", and picks the path of least damage.
[17:12] <infinity> rbasak: If one package C/R another, however, it will get a precedence in the preference weights for the purpose of an upgrade calculation.
[17:12] <rbasak> I think I've got mostly B/R rather than C/R, but I do seem to have an R in most things, unless I missed something.
[17:13] <infinity> rbasak: B/R means something entirely different.
[17:13] <infinity> rbasak: B/R means "I overwrite some files from this other thing", C/R means "when I'm installed, this other packages needs to go away".
[17:14] <infinity> rbasak: mysql-5.5 and mysql-5.6 shouldn't break each other (unless, in some version combo, they're coinstallable), they should conflict.
[17:15] <infinity> rbasak: Another way to think about it is that if it's no versioned (and can't be), breaks was probably wrong, and the logical inverse, if you can version it, conflicts is probably wrong.
[17:17] <rbasak> infinity: OK, thanks. I thought Breaks was enough (and I think I inherited this from the original 5.6 packaging). I didn't realise it affected apt's resolution.
[17:17] <infinity> rbasak: Right, so.  A policy re-read might be in order.  Or some nuanced education. ;)
[17:18] <rbasak> I have it up and have been re-reading :)
[17:18] <rbasak> With your explanation I can see how I can interpret policy in the way that you say.
[17:18] <rbasak> I'm not sure it's obvious from just reading it though.
[17:19] <infinity> rbasak: Conflicts means "these two packages can't be installed together".  Breaks means "deconfigure A to install B".  Replaces means "overwrites some files".  B/R means "deconfigure and replace some files" (the best way to replace files, as it won't let you undo the process and lose files mysteriously), C/R means "can't install together and, furthermore, prefer this package always".
[17:19] <Saviq> seb128, hey, I think you've been through this before... is there a script for moving all bugs from project to ubuntu/project?
[17:20] <infinity> rbasak: In the case of two packages that should never coexist, Conflicts is always right.  When one should take precedence over another (ie: a version takeover, or a change or upstreams, etc), the "good" one should C/R instead of just C.
[17:20] <rbasak> OK, got it.
[17:20] <rbasak> So if I change the relevant (I think probably all, but will check) Breaks to Conflicts, apt should do the right thing.
[17:21] <rbasak> I'm >EOD now, so I'll try this tomorrow. Thank you.
[17:21] <rbasak> (and also noted that it's more correct to use Conflicts here, so I'll do that)
[17:21] <infinity> rbasak: One could make some very solid arguments for how all of these states should be different relationships instead of mysterious magic pairs, but it's what we've got to deal with today. :P
[17:21] <rbasak> :)
[17:22] <rbasak> I think I was just reading from a point of view that breaks is less invasive (in general, I see now it's probably not relevant here) and from what I read in policy that breaks would do, so I didn't consider it an issue.
[17:22] <rbasak> I didn't realise that it also affected apt's resolution.
[17:22] <rbasak> Anyway, I get it now. Thanks.
[17:24] <infinity> rbasak: It's possible that even with policy-compliant relationships, the upgrade won't do what you want.  If that end up being the case, point me at your work, and I'll argue with the tools (and mvo) instead of you. :)
[17:26] <shadeslayer> can someone help me with a weird build failiure that I absolutely do not get
[17:26] <shadeslayer> https://launchpadlibrarian.net/183945400/buildlog_ubuntu-trusty-i386.firefox_32.0%2Bbuild1-0ubuntu0.14.04.2~ppa1~trusty1_FAILEDTOBUILD.txt.gz
[17:26] <shadeslayer> it only happens on i386 on Trusty
[17:28] <shadeslayer> https://launchpad.net/~rohangarg/+archive/ubuntu/firefox/+sourcepub/4389166/+listing-archive-extra
[17:29] <sarnold> shadeslayer: on a first guess, it looks like the headers may not be protecting themselves against multiple inclusion with the usual #ifndef mangled_header_name #define mangled_header_name .... #endif   trick
[17:29] <shadeslayer> they are not
[17:29] <shadeslayer> sarnold: how would that affect amd64 btw?
[17:30] <sarnold> some projects don't do that, instead they manage their dependencies to avoid it.. dunno what firefox does..
[17:30] <shadeslayer> or for that matter, precise built fine on i386 and amd64, same patches
[17:30] <sarnold> shadeslayer: d'oh, I forgot that bit :(
[17:30] <LocutusOfBorg1> https://launchpadlibrarian.net/183614592/buildlog_ubuntu-trusty-i386.firefox_32.0%2Bbuild1-0ubuntu0.14.04.1_UPLOADING.txt.gz
[17:30] <LocutusOfBorg1> seems that the official build succeeded
[17:30] <shadeslayer> LocutusOfBorg1: yes, this is specific to 2 patches that I add
[17:30] <infinity> LocutusOfBorg1: Yeah, the official build lacks the KDE patches that are causing the issue. :)
[17:30] <LocutusOfBorg1> but cris reported a similar build failure https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1348333
[17:31] <shadeslayer> nah, looks like a different thing
[17:31] <LocutusOfBorg1> ah ok there is a delta :)
[17:31] <shadeslayer> LocutusOfBorg1: yeah :)
[17:32] <shadeslayer> LocutusOfBorg1: specifically these patches : http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch & http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/firefox-kde.patch
[17:33] <LocutusOfBorg1> mozilla-kde.patch
[17:33] <LocutusOfBorg1> firefox-kde.patch
[17:33] <LocutusOfBorg1> yes, I was already looking at them lol
[17:33] <shadeslayer> :)
[17:34] <infinity> shadeslayer: Anyhow, I'd say the class redefinition error is pretty clear.  Why it's only happening on one arch could be any number of things, but maybe that header is conditionally included, or the class conditionally defined, etc.
[17:34] <shadeslayer> that would be very weird
[17:35] <infinity> Have you read the mozilla codebase?
[17:35] <infinity> Weird doesn't begin to describe it.
[17:35] <jdstrand> zbenjamin: if confined, you can neither read nor write to ~/.local/share/, which is why I was saying do (the equivalent of) a readdir()
[17:35] <shadeslayer> infinity: I have
[17:35] <shadeslayer> infinity: unfortunately, you're right :(
[17:35] <jdstrand> zbenjamin: if confined, you can write to ~/.local/share/<name for click manifest>
[17:35] <jdstrand> ~/.local/share/<name from click manifest/*
[17:36] <jdstrand> zbenjamin: ^ (and  ~/.local/share/<name from click manifest/ itself)
[17:36] <LocutusOfBorg1> shadeslayer, mozilla-kde.patch
[17:36] <LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.h
[17:37] <LocutusOfBorg1> there is no #ifdef guard
[17:37] <shadeslayer> yeah
[17:37] <shadeslayer> I think adding ifdef guards is the best way forward here
[17:37] <LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.h
[17:37] <sarnold> shadeslayer: hmmm, http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch#l2579
[17:38] <LocutusOfBorg1> also in nsKDERegistry
[17:38] <shadeslayer> sarnold: that's utils
[17:38] <sarnold> this one is missing though http://www.rosenauer.org/hg/mozilla/file/e4fa9844604e/mozilla-kde.patch#l2842
[17:38] <shadeslayer> not registry
[17:38] <sarnold> shadeslayer: ahh d'oh
[17:39] <LocutusOfBorg1> I think I found it
[17:39] <LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsKDERegistry.cpp
[17:39] <LocutusOfBorg1> there is one +#include "nsKDERegistry.h"
[17:40] <LocutusOfBorg1> also done here
[17:40] <LocutusOfBorg1> +++ b/uriloader/exthandler/unix/nsCommonRegistry.cpp
[17:40] <LocutusOfBorg1> and the last one includes nsKDERegistry.h
[17:40] <LocutusOfBorg1> so it might be repeated here since there is no guard
[17:40] <LocutusOfBorg1> also nsMIMEInfoUnix.cpp includes it
[17:44] <shadeslayer> shouldn't that be fine btw?
[17:44] <shadeslayer> or well, it looks fine to me
[17:45]  * shadeslayer thinks it's a issue with the generated CPP file
[17:45] <shadeslayer> which probably has arch dependent includes and what not
[17:48] <sarnold> just fix up the includes to properly handle multiple inclusions
[17:49] <shadeslayer> sarnold: yeah
[17:50] <shadeslayer> that's what I'm doing
[17:50] <sarnold> shadeslayer: if you figure out why it only errors on x86 and not amd64, I'd be interested to know why :)
[17:50] <sarnold> shadeslayer: but if you just get it fixed that'd make sense, hehe
[17:50] <shadeslayer> sarnold: heh ok, I'll have to do a local build probably
[17:52] <shadeslayer> if I have time, I'll look into it
[18:22] <hallyn> pitti: stgraber: slangasek: tedg: so I do have a concern actually about the upstart-cgroup-phone thing.
[18:23] <hallyn> I was going to make Abandon mean that we set the cgorup remove-on-empty and try to delete it.  But I guess that actually doesn't work for upstart
[18:23] <hallyn> bc if the upstart job has a task still in the cgroup, then we can still have the same race.
[18:23] <hallyn> (alas jodh is gone)
[18:23] <hallyn> the question is can that ever happen - that an upstart job says 'pre-start' or 'start script' is done, but there are stlil tasks running thta are descendents of that job?
[18:23] <tedg> Couldn't it just set it to remove-on-empty and just make it Upstart's job to remove the PIDs?
[18:24] <hallyn> that's not the problem
[18:24] <hallyn> I have StopUnit to kill the tasks, I'm happy with that
[18:24] <hallyn> but by default we use Abandon.  So if a task remains in the upstart job's cgroup, then it could still exit - causing autoremove of the cgroup - after the post-stop has created the cgroup but before it exec'd the tasks
[18:25] <hallyn> so, until i hear from jodh (or someone else) that upstart wlil ensure that all job tasks are done at the end of pre-start etc,
[18:25] <hallyn> i wont set remove-on-empty
[18:25] <hallyn> i'll just delete, and if it wasn't empty, well, it won't be removed.
[18:26] <tedg> For the UAL case (which is the one I care about) we try and ensure that all the processes are removed.
[18:26] <tedg> I'd honestly rather just be able to set a flag that says if PIDs are left, kill them.
[18:26] <hallyn> ok, then i will do the remove-on-empty.  if you end up having trouble after al, then we can remove it
[18:26] <tedg> So it would call RemoveUnit at the end of the instance.
[18:26] <hallyn> well you have htat 'flag', only systemwide
[18:27] <hallyn> (KillUserProcesses in /etc/systemd/logind.conf)
[18:50] <hallyn> desrt_: so using /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service we can register Name=org.freedesktop.systemd1 as a path for which we are started when there is activity.  can we do the same at runtime (only until reboot)?
[18:58] <seb128> Saviq, bdmurray has something for that iirc
[19:01] <Saviq> seb128, almost got there myself, thanks :)
[19:35] <bdmurray> pitti: do you have any ideas about bug 1365079?
[19:42] <bdmurray> pitti: I'm not positive how to proceed.
[21:42] <doko> cjwatson, looking at the coreutils autopkg test failures. there are now a lot more, and I don't know if just disabling these is the right thing to do. It might be better to build a coreutils-test package including the config.h and test binaries like getlimits and ginstall
[23:19] <catbus1> Hi, I don't see Ubuntu 14.04.2 release date on https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule, is there a plan to update this page with the upcoming point release schedule info?