[05:47] <pitti> Good morning
[05:48] <pitti> shadeslayer: sorry, no idea about the automake test driver; I merely fixed the broken autopkgtest
[05:48] <pitti> shadeslayer: yes, what cjwatson says; don't use cdbs' auto-update
[07:01] <dholbach> good morning
[07:02] <ion> that
[07:16] <pitti> builds fail with "Unable to connect to archive-team.internal:http:
[07:16] <pitti> infinity: ^ known?
[07:18] <cjwatson> pitti: known, we're working on it
[07:18] <pitti> cjwatson: thanks
[07:18] <cjwatson> pitti: fallout from the lillypilly->snakefruit switchover
[10:39] <shadeslayer> cjwatson: there is a multiarch'd virtuoso which uses debhelper in debian experimental, however that will break soprano, which is why I haven't requested a sync
[10:39] <shadeslayer> and thought it'd be a better idea to fix our own package
[10:46] <apw> pitti, hey ... whats the ramifications of adding a source pacakge which does not yet exist into apport in precise, specifically i am adding linux-lts-raring and it seems appropraite to add linux-lts-saucy at the saem time if that isn't going to explode
[10:46] <apw> pitti, as in adding a new link to debian/apport.links
[10:46] <pitti> apw: that seems rather straightforward
[10:47] <pitti> apw: i. e. if we already decide to SRU a new kernel, this should be part of that exception
[10:47] <apw> pitti, yeah agreed.  in this case i am fixing raring cause it was missed (and i'll send you a merge request to look at in a bit) and thinking we might want to do saucy in advance to save doing an additional SRU
[10:48] <apw> though as it is so easy, perhaps we don't care
[10:48] <pitti> apw: if we already know that we are going to backport the saucy kernel, it seems fine to do it in one go
[10:52] <apw> pitti, ok, will just get this tested, and then get it up for review.  I think it needs that cause i am ripping out a hack which you added for before these packages hit the actual archive; and now is redundant
[10:52] <pitti> apw: ah, we added some PPA lookup?
[10:52] <apw> pitti, we added some PPA 'ok' which is fine i guess, but we also mapped the names over to linux else you couldn't file the bugs either
[10:53] <apw> and that doesn't seem appropriate any more
[10:53] <apw> and we only did it for quantal, not all lts kernels
[10:53] <apw> so it was a bit of an old hack
[11:11] <shadeslayer> cjwatson: well, I can also pass --add-missing which fixes the issue
[11:45] <apw> pitti, ok here is my proposed changes, they seem to work on a VM ok: lp:~apw/ubuntu/precise/apport/lts-backport-kernels
[11:45] <apw> pitti, if you could cast your weathered eye over them, then perhaps i can try the release process
[11:47] <pitti> apw: so the meta packages are named linux-meta-raring (or something such), not linux-raring-meta?
[11:47] <apw> linux-meta-lts-raring | 3.8.0.31.31 | precise-proposed | source
[11:47] <pitti> ah, so it says in the second hunk, nevermind
[11:48] <apw> yeah after a shakey start we have standarised on the 'base name' (linux, linux-meta, linux-signed etc) followed by the variant
[11:48] <pitti> apw: LGTM then, thanks!
[12:18] <doko> didrocks, are you aware of the unity-* and friends build failures in the test rebuild?
[12:21] <doko> seb128, has libburn ubuntu specific patches, or is it just the new upstream?
[12:21] <seb128> doko, just new upstream version
[12:22] <doko> barry, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5014145 ?
[12:22] <barry> doko: i'll put it in a tab for later ;)
[12:27] <mlankhorst> mdeslaur: poke :)
[12:27] <mdeslaur> mlankhorst: hi
[12:31] <mlankhorst> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/glamor-egl/+bug/1227919 ?
[12:32] <mdeslaur> sarnold: what's the status on mlankhorst's MIR? ^
[12:32] <mdeslaur> mlankhorst: sarnold will be here in 3-4 hours, I'll see what the status is then
[12:32] <mlankhorst> ok thanks
[13:08] <doko> infinity, I see you touched corosync last weekend. could you have a look at openais (ftbfs) too?
[13:40] <bloopletech> I have just reported a bug in libgl1-mesa-glx, and I'd like to do what I can to avoid the bug being ignored/unnoticed. The issue revolves around the x86_64-linux-gnu_gl_conf alternative, and two packages that provide it, libgl1-mesa-glx, and nvidia-304. I am able to help troubleshoot the issue right now; if this is the wrong venue for discussing the issue, a pointer would be super helpful
[13:40] <bloopletech> The bug url is https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1229734
[13:57] <bloopletech> If I could work out _what_ is calling update-alternatives, that would probably be enough, because at least then I can add the fix as described in the bug *after* that in the boot
[14:17] <pitti> stgraber: what's the status of these "mount partitions on top of /etc/ files" hack? is that only going to last until we get a proper aufs/overlayfs working?
[14:18] <pitti> stgraber: it's certainly not something which we could ever use in a converged ubuntu
[14:19] <stgraber> pitti: getting upstream aufs/overlayfs is I think the biggest blocker there, the Android kernels can be heavily patch and be rather ancient, so having reliable overlays was out of the question
[14:20] <pitti> stgraber: right, but is that still the eventual plan?
[14:21] <stgraber> pitti: it's one of the options we started discussing with slangasek when looking at the converged story, yes
[14:22] <stgraber> pitti: the biggest concern I have there so that if we choose to use aufs or overlayfs, we basically say no to community ports
[14:23] <stgraber> pitti: as no existing Android kernels support it by default and most ports maintainer lack the knowledge required to merge those rather massive patches
[14:23] <pitti> stgraber: oh, why? you think that the block API will change so often that these modules don't port well across kernel versions/
[14:23] <pitti> ?
[14:24] <pitti> stgraber: if that isn't an option, then I guess we'll have to re-think having a writable /etc/, or using some other overlay solution
[14:24] <stgraber> pitti: well, I always noticed that those patches take a couple of weeks to get re-applied whenever we switch to a new Ubuntu kernel, so I assume they are a bit of a pain to apply
[14:24] <stgraber> apw would surely know more about that :)
[14:25] <cjwatson> IIRC aufs is worse than overlayfs for that
[14:31] <Laney> pitti: do you think you'd be able to work on the timedated hack to tide us over?
[14:32] <pitti> Laney: if we actually find a solution how to do it, yes
[14:32] <pitti> Laney: I really don't want my name on a patch which does in-place file updating
[14:32] <Laney> I guess we can add a writeable directory to /etc to store the intermediate stuff in
[14:32] <Laney> like you suggested for /data
[14:32] <cjwatson> That was my suggestion
[14:32] <pitti> right
[14:32] <cjwatson> Make /etc/localtime and /etc/timezone a symlink into that, so localtime ends up being a two-level symlink
[14:33] <Laney> yeah
[14:33] <pitti> so a two-level symlink, or copying the file content to /data
[14:33] <Laney> Should be able to do it all within /etc
[14:33] <pitti> Laney: this needs to be changed in at least tzdata and systemd then, and possibly also in other tools which adjust the time
[14:35] <stgraber> doing that stuff within /etc would mean we have the original file in that sub-directory so factory reset will work properly
[14:36] <stgraber> having the symlink point to /userdata would be more of a problem (as I mentioned in the bug)
[14:36] <apw> stgraber, they are a mare to apply and forward port often yes as they dig right into the vfs, the bit which has no stable ABI
[14:37] <stgraber> and having the tools change /userdata/system-data/etc/... instead of /etc would work but won't give you much since bind-mounts work on the inode and th atomic replace currently done will switch inode too (with the bind-mount pointing to the old file rather than the new one)
[14:37] <stgraber> apw: thanks for confirming my fears! so definitely not something we'd want our community porters to do for all of their weird and old kernels (I had a few trying to run Ubuntu Touch saucy on 2.6.32...)
[14:38] <Laney> Can't we bind mount the whole of /etc? :-)
[14:40] <doko> jamespage, zul: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg shows some missing MIR's for the dependencies
[14:40] <stgraber> Laney: you deal with crazy people adding stuff to /etc then ;)
[14:40] <Laney> ?!
[14:40] <stgraber> Laney: (the usual, how do you distinguish a new file being added to /etc from an old file being removed by the user locally)
[14:41] <Laney> don't you have to care for that currently?
[14:41] <stgraber> nope
[14:41] <Laney> some of the whitelisted things are conffiles
[14:41] <stgraber> transition is a one time thing done on first boot
[14:42] <zul> doko:  python-wsme (#1207030), msg-pack (#1207003) and (#1207034) have the MIR compete and waiting for promotion
[14:42] <stgraber> so any file (or directory) listed in writable-paths will be copied to /userdata and bind-mounted on first boot, if the content changes in the rootfs after that, you won't see it until you do a factory reset (which will trigger another copy from the rootfs to /userdata)
[14:43] <jdstrand> tkamppeter: hi! in your next cups upload, can you fix bug #1229766? I added the apparmor rule to the description
[14:44] <doko> zul, python-wsme needs MIR's for it's dependencies
[14:45] <zul> doko:  gotcha
[14:46] <doko> zul, promoted msgpack-python
[14:46] <zul> doko:  thanks
[14:46] <doko> will wait with python-thrift until the others are complete
[14:47] <zul> doko:  thrift (#1207034) btw
[14:51] <stgraber> tedg: ping
[14:51] <stgraber> tedg: so I have a bit of a problem with edubuntu where we appear to ship ubuntu-system-settings and a bunch of other touch related packages by default...
[14:51] <stgraber> tedg: apparently that's because indicator-sound recommends ubuntu-system-settings | gnome-control-center
[14:52] <mterry> zul, I see the new MIR
[14:52] <ogra_> thats overly poitless on touch
[14:52] <ogra_> *pointless
[14:52] <zul> mterry:  cool one more coming down
[14:52] <stgraber> tedg: edubuntu ships gnome-control-center, but since ubuntu-system-settings is preferred, if we're unlucky at image build time, we'll end up pulling ubuntu-system-settings...
[14:52] <ogra_> tedg, drop the recommends, it isnt used on touch ... and since it breaks desktop ...
[14:53] <ogra_> stgraber, ^^^
[14:53] <stgraber> tedg: can you either drop the recommend or switch the order to be more reasonable?
[14:53] <stgraber> ogra_: that'd work for me
[14:53] <ogra_> needs to be a hard dep or just carefully seeded
[14:53] <stgraber> tedg: please do it in the next two hours or I'll have to cowboy it myself into the archive. I consider this a critical bug for Beta 2 and as such want it resolved ASAP. Thanks
[14:53] <ogra_> else touch wont consider it anyway
[14:54] <stgraber> ogra_: ah right, you guys still use no-install-recommends
[14:54] <ogra_> stgraber, please coordinate cowboying with #ubuntu-ci-eng ...
[14:55] <xnox> tedg: it seems like your interpretation of "Recommends" is what the "Enhances" stanza is http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[14:56] <tedg> stgraber, K, will change.
[14:56] <tedg> xnox, The problem is that a menu item breaks if it's not there.
[14:56] <tedg> xnox, So it's not a crash, but it's not really an "additional feature"
[14:57] <xnox> tedg: menu item breaks where? on ubuntu-touch panel, desktop panel, ubuntu-system-settings, gnome-control-center?
[14:57] <tedg> stgraber, Only concern is that I don't know if I can get it released... releasing is... tricky.
[14:58] <tedg> xnox, ubuntu touch for one, desktop panel for the other.
[14:58] <xnox> tedg: i'm sure a few people can dput it, e.g. stgraber and myself included.
[14:58] <stgraber> tedg: so it's currently a blocker for an image we need to release on Thursday and needs to be tested today. So I know we've got the fancy CI process now and I'm fine waiting 2-3 hours for you to go through that.
[14:59] <stgraber> tedg: but if that's not done by then, I'll just dput it straight to the archive and add a manual unblock in britney to bypass the touch block
[14:59] <xnox> tedg: right - recommends has no affect on the touch image, so indicator-sound must be seeded. Thus Recommends should be dropped, as one doesn't want gnome-control-center on touch.
[15:00] <stgraber> right, the way touch works means the change is guaranteed no-op there, so I don't buy the "affects touch" part :)
[15:00] <tedg> xnox, Well we've done all the other indicators with the recommends the other way.  So I'd prefer to keep them the same.  Or I guess change all.
[15:00] <tedg> Not sure why indicator-sound ended up backwards.
[15:00] <xnox> tedg: instead seeds need to be correct for the menu-item to be correct in the indicator-sound. And probably indicator-sound should hide the menu-item if it can't find neither ubuntu-system-settings nor gnome-system-settings.
[15:01] <xnox> tedg: recommends are _not_ installed on touch images. So recommends really has no effect on touch images. Not sure how the rest of them were done.
[15:01] <xnox> tedg: i see explicit seeds on touch.
[15:01] <tedg> xnox, Sure, but that's additional test code for an invalid scenario, I'd rather fix it in packaging than write more tests :-)
[15:02] <stgraber> tedg: I think dropping the recommend from all of them would make more sense since recommends are ignored on touch. Having the recommend there just makes it that much more confusing when people are trying to figure out why a package is or isn't installed on a particular image.
[15:02] <xnox> tedg: you can do "Recommends: gnome-control-center" as it will not be installed on touch, but will be installed on normal "fat" desktops.... until we converge that is.
[15:03] <tedg> I guess the difference for me is "can do" vs. "communicates what we're trying to say"
[15:04] <tedg> Sure, it would *work*.  But "Recommends: gnome-control-center | ubuntu-system-settings," will work and describes the relationships.
[15:04] <stgraber> anyway, with my Edubuntu hat on, I don't really care what you end up doint, so long as we get an unbloated image soon, I currently have system-image-* + ubuntu-system-settings + gsettings-ubuntu-touch-schemas + ... so I effectively have no idea whether the bug I'm seeing in the image are a result of that or more important things I need to get solved by tomorrow
[15:04] <xnox> tedg: it should be valid to install without recommends, yet for you one of them is a hard dependency.
[15:05] <xnox> tedg: thus above usage of recommends is contradictory to the packaging definition of Recommends, as per http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[15:05] <tedg> xnox, "Recommends:  This declares a strong, but not absolute, dependency. "  which is what I think we have.
[15:07] <stgraber> tedg: accept that as far as touch is concerned you could just as well have put that in the description field since dpkg on those images cares as much about the description field as it does about the recommends one :)
[15:07] <xnox> tedg: but you say indicator-sound is buggy, if your single recommends  is not present. (single, but can be satisfied by one of the two or both packages)
[15:07] <tedg> stgraber, Sure, but isn't that something we'll fix on touch eventually?
[15:07] <xnox> tedg: not in 13.10.
[15:08] <xnox> tedg: and we need to release working 13.10 images for both touch & edubuntu
[15:08] <tedg> xnox, Sure, but I can't express "one of these depending on which frontend you're using" :-)
[15:08] <stgraber> tedg: I hope we'll be consistent in that regard for 14.04, yes
[15:08] <stgraber> tedg: anyway, I'll get back to doing some work. I'll get back to Edubuntu stuff at 2pm here (in 3 hours), would be nice if you could get that thing fixed and landed by then. If it's not at that point, let me know how far you got and I'll cowboy the rest.
[15:09] <tedg> stgraber, K.  https://code.launchpad.net/~ted/indicator-sound/recommends-reorder/+merge/187265
[15:09] <xnox> tedg: but when recommends will be enabled on both touch & desktop, "Recommends: gnome-control-center | ubuntu-system-settings" will still be wrong, as it will then instead pull in gnome-system-settings into touch images.
[15:09] <xnox> And e.g. desktop starting to use ubuntu-system-settings while edubuntu continues with gnome-system-settings for example.
[15:09] <stgraber> tedg: that trailing comma is confusing
[15:10] <tedg> xnox, Not if ubuntu-system-settings is seeded, no?
[15:10] <tedg> stgraber, I thought that was supposed to be to make diff's clearer?
[15:10] <stgraber> tedg: hmm, I suppose it does when it's a vertical list
[15:10] <stgraber> tedg: I'm just surprised dpkg isn't picky about this, but yeah, if that works, fine :)
[15:11] <xnox> tedg: we have seeds exactly because there is no way to correctly order recommends for all packages. And at the moment, despite correct seeding, edubuntu seed is pulling the first recommends (ubuntu-system-settings).
[15:12] <tedg> xnox, I guess, are you sure edubuntu seed gnome-system-settings?
[15:12] <xnox> tedg: yes.
[15:12] <tedg> Hmm.  That's weird.
[15:13] <tedg> xnox, I think it's a foundations bug then.  /me closes
[15:13] <tedg> :-)
[15:13] <Laney> gnome-control-center!
[15:13] <xnox> tedg: two members of foundation are asking you to remove the buggy recommends and use seeds instead.
[15:13] <xnox> (stgraber and I)
[15:13] <xnox> tedg: your move ;-)
[15:14] <Laney> it does sound like a bug in the image process though, to be fair
[15:14] <tedg> xnox, So you're saying foundations is lazy and won't fix its bugs?
[15:14] <Laney> even if I agree with you guys that the quick fix is fine
[15:15] <xnox> tedg: I'm saying your usage of recommends is broken, and not what it is intended to be used for.
[15:15] <stgraber> Laney: well, kinda, I didn't look at an apt debug output, but my guess is that based on ordering, both end up having the same weight (as uninstalled, recommended packages) and so whichever is first wins.
[15:15] <tedg> Anyway, yes.  That fix short term.  But it things like seeded things should always satisfy first.
[15:15] <Laney> But you get both, right?
[15:16] <tedg> Seems like I should be able to put something at the end of "infinite |s" and if it's seeded, that's the one that is taken.
[15:16] <stgraber> Laney: I do indeed, as I said, would need to look at an apt debug output to figure it out, chances is it's doing it in multiple run and Edubuntu is getting unlucky where Ubuntu is being lucky
[15:16]  * Laney nods
[15:16] <xnox> tedg: the correct way to do this is for you to do Recommends on a virtual package "system-settings" and then have both types of settings-mangers provide that virtual package. then the seeds will work correctly.
[15:16] <stgraber> Laney: ah, no, much simpler than that actually :)
[15:17] <stgraber> Laney: ubuntu-system-settings is in universe
[15:17] <xnox> tedg: not on an " bar | baz" alternative.
[15:17] <stgraber> Laney: so it'd have been used in Ubuntu as well if it was in main
[15:17] <stgraber> Laney: Ubuntu builds without universe, Edubuntu builds with it
[15:17] <Laney> haha
[15:17] <stgraber> Laney: so an Ubuntu netboot install would currently get you ubuntu-system-settings too
[15:18] <tedg> xnox, In the dependency resolution I can't see what the difference is there.  Effectively it's creating a temporary "tmp32" that both provide and then resolving to that.
[15:18] <stgraber> (one more reason to fix this ASAP as that means we probably have a bunch of users who have it on their Ubuntu desktop too...)
[15:18] <Laney> Yeah, I think it should be fixed now but it'd also be interesting to find out if the reason it showed up is fixable
[15:19] <cjwatson> if you explicitly seed something that should take precedence, both in germinate and apt
[15:19] <cjwatson> but it has to be seeded in the same or an interior seed, not something exterior
[15:20] <cjwatson> xnox: that won't help, germinate and apt would both produce nondeterministic results for a bare virtual
[15:20] <xnox> oh. ok.
[15:21] <cjwatson> tedg,stgraber: I can look into the seed resolution point soon but not now
[15:21] <xnox> cjwatson: what's the difference between interior vs exterior seeds? is include platform.saucy exterior?
[15:22] <xnox> cjwatson: why would the result for a bare virtual be nondeterministic, if a package that provides it is already seeded?
[15:23] <Laney> I guess it means that edubuntu's seed just has a dependency on the ubuntu-desktop package
[15:23] <xnox> Laney: but e.g. gnome-control-settings is listing Task: edubuntu-desktop
[15:23] <ogra_> ubuntu toucxh doesnt (and probably will never) respect recommends
[15:23] <ogra_> that recommends is totally bogus
[15:23] <xnox> Laney: s/settings/center/
[15:23] <ogra_> just drop it altogether
[15:23] <cjwatson> xnox: no I mean desktop is outside desktop-common but desktop is inside live
[15:26] <cjwatson> xnox: It shouldn't be nondeterministic if a provider is already seeded, but nor should foo | bar
[15:26] <cjwatson> xnox: So no gain
[15:31] <tkamppeter> jdstrand, OK.
[15:31] <tumbleweed> hpodder fetch
[15:31] <tumbleweed> grr
[15:32] <pitti> awe_: wrt. the phone call stack, does this look about right? dialer-app → telephony-service-handler → telepathy-ofono → ofono ?
[15:32] <awe_> yes
[15:32] <pitti> awe_: does anythign except telepathy-ofono talk to ofonod?
[15:33] <awe_> pitti, in mid-stand-up
[15:33] <pitti> awe_: thanks; I was wondering what I have to restart in order for recording ofonod (my approach from a few weeks ago doesn't work any more)
[15:33] <pitti> awe_: nevermind, can talk later
[15:40] <didrocks> jamespage: doko: we have an issue with latest libunwind: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz
[15:41] <jdstrand> tkamppeter: thanks!
[15:41] <awe_> pitti, I just finished the stand-up
[15:41] <lool> (thanks didrocks)
[15:41] <lool> RAOF: ^
[15:41] <didrocks> jamespage: doko: downgrading to 1.1-1ubuntu2 works
[15:41] <awe_> pitti, yes.. there are multiple processes that can/do talk to ofonod
[15:41] <didrocks> any of you can help figuring this out?
[15:41] <didrocks> (this is blocking Mir landing)
[15:41] <didrocks> asac: FYI, now that we have for sure the culpurit component ;) ^
[15:41] <awe_> telepathy-ofono, system-settings and NM are the top three...
[15:42] <awe_> pitti, fyi... we have a new guy in PES who I asked to do some work with umockdev/ofono last week
[15:43] <awe_> I was planning on emailing a few folks ( you, Jualian, ... ) to discuss
[15:43] <jamespage> didrocks, does your build use pkg-config files?
[15:43] <awe_> as Alfonso ( abeato ) has run into some of the same kind of issues you may now be seeing
[15:43] <jamespage> that was introduced in 1.1-2
[15:44] <pitti> awe_: ah, maybe; it was working quite well a few weeks ago, but now it seems there is a lot of chatter from all different places towards ofonod, which makes predictable communications hard
[15:44] <awe_> exactly
[15:44] <awe_> that said, there's also some issues with ofono's protocol stream not being deterministic
[15:44] <RAOF> jamespage: Yes
[15:44] <pitti> awe_: so I guess for testing dialer-app we should rather provide a dbus-mock of the ubuntu phone service; and test that against a mock of telepathy-phone, and so on
[15:44] <didrocks> jamespage: it's xorg-server failing to build FYI
[15:45] <jamespage> didrocks, yeah - I see
[15:45] <pitti> awe_: testing ofonod itself against a mock rild seems easier, as you can test that in isolation (right now this involves some 5 processes)
[15:45] <awe_> pitti, let's get the terminology straight, there's telephony-service and telepathy-ofono
[15:46] <awe_> so you're saying that we should mock telephony-service?
[15:46] <seb128> tedg, stgraber, hey, why "Recommends: ubuntu-system-settings | gnome-control-center," isn't right if edubuntu has g-c-c installed, shouldn't that be enough for the recommends?
[15:46] <awe_> for the dialer app tests?
[15:46] <pitti> awe_: that would be the logical thing (mock the direct layer below you)
[15:46] <awe_> ( below the dialer app, you mean )?  ;)-
[15:47] <pitti> awe_: or perhaps telepathy-ofonod, as dialer-app seems to talk to both telephony-service AND telepathy
[15:47] <pitti> i. e. there doesn't seem to be a clear layer separation
[15:47] <awe_> right
[15:47] <RAOF> jamespage: Ah. So the problem was probably always there, just that 1.1-2 actually made the configure check pass.
[15:47] <pitti> awe_: "ofono's protocol stream not being deterministic" -> did that change recentlY/
[15:47] <pitti> ?
[15:48] <stgraber> seb128: if we'd install the indicator after the rest of the system is installed, yes
[15:48] <awe_> pitti, no, I think you just got lucky
[15:48] <jamespage> RAOF, might be
[15:48] <cjwatson> seb128,tedg,stgraber: this is certainly odd - Edubuntu livefs builds install everything by tasks, so germinate's view of the world ought to win
[15:48] <stgraber> seb128: but we're talking about a rootfs build at which point neither is installed, both come from recommends so they probably end up having the same weight at some point
[15:48] <RAOF> We've had a timebomb patch in the xserver since March :)
[15:48] <seb128> stgraber, isn't that going to create the reverse issue for touch then?
[15:48] <stgraber> seb128: nope, touch doesn't use recommends
[15:48] <cjwatson> stgraber: it still ought to be controlled by germinate's expansion, via Task field
[15:48] <cjwatson> s
[15:49] <RAOF> jamespage: Confirmed that building with unwind 1.1-1ubuntu2 works, but also doesn't actually use libunwind
[15:49] <awe_> pitti, as mentioned we've done some analysis, and abeato has also come up with some ideas on how we could address these issues..  I'd like to review his notes, and then will share them with you, and others later today
[15:49] <seb128> stgraber, is that going to stay that way or are we up to get the same issue when we start using them?
[15:49] <cjwatson> Hmm, gnome-control-center is in Task: edubuntu-desktop, not Task: edubuntu-desktop-gnome
[15:49]  * ogra_ still votes for just dropping the recommends
[15:49] <ogra_> add it back in 14.04
[15:49] <cjwatson> ogra_: I still want to investigate the underlying issue here
[15:49] <ogra_> and have the headdache then
[15:49] <pitti> awe_: ack; I currently got an assignment to create some autopilot tests for dialer-app and messaging-app
[15:49] <pitti> awe_: (some nontrivial ones, that is)
[15:50] <pitti> awe_: so I guess I'll investigate providing dbus mocks for telepathy next, WDYT?
[15:50] <awe_> ah, OK I was wondering who the DRI was for that task
[15:50] <awe_> ;D
[15:50] <stgraber> seb128: at some point it may be a problem, though if touch ever switches to installing recommends, the fact that ubuntu-system-settings is directly seeded by its main seed should make germinate do the right thing
[15:50] <pitti> awe_: "DRI"?
[15:50] <jamespage> RAOF, OK
[15:50] <awe_> designated responsible individual
[15:50] <cjwatson> Hm, so Task: edubuntu-desktop is a weird thing
[15:50] <awe_> sorry, too many acronyms floating around in my head
[15:50] <jamespage> RAOF, I guess an immediate fix is to drop the libunwind dependency from xord
[15:51] <jamespage> xorg rather
[15:51] <awe_> jamespage, what does RAOF mean?
[15:51] <cjwatson> $ diff -u <(grep-aptavail -nsPackage -wFTask ubuntu-desktop | sort -u) <(grep-aptavail -nsPackage -wFTask edubuntu-desktop | sort -u)
[15:51] <cjwatson> $
[15:51] <cjwatson> It really only exists because seeds/ubuntu.saucy/desktop doesn't force a task name
[15:52] <jamespage> awe_, RAOF is a person - no idea what his/her nick stands for tho
[15:52] <RAOF> Wow. The build logs for xorg-server on the buildds are rubbish.
[15:52] <seb128> stgraber, ok, I will trust you and cjwatson to do the right thing here... seems like it should be working still without that change from what cjwatson said?
[15:52] <RAOF> jamespage: Running Around On Fire
[15:52] <cjwatson> seb128: continue to follow my stream of consciousness, I'm getting there :)
[15:52] <jamespage> RAOF, lol - sounds familiar ;-)
[15:52] <RAOF> I *think* we're not building with LIBUNWIND, but the actual configuration message is “checking for LIBUNWIND... __thread” ☺
[15:53] <cjwatson> Task: edubuntu-desktop-gnome includes the ubuntu-desktop metapackage, which normally covers this up because it recursively includes all the same things
[15:53] <cjwatson> However, this is NOT enough to force the correct expansion in this kind of case
[15:53] <awe_> hahaha
[15:53] <RAOF> (This makes more sense in context, as the surrounding checks are about TLS)
[15:54] <stgraber> seb128: yes, doing that change was the easiest way to get the image back to normal and as the change makes sense anyway (even if only for consistency with the other indicators), it seemed like the right thing to do for now.
[15:54] <cjwatson> The way apt works, it installs all the packages it's been explicitly told to install (which includes every package that a task expands to), and then it tries to resolve any of those that are broken
[15:54] <cjwatson> But that means that if you have this kind of ambiguity then it can only reliably be solved by top-level entries
[15:55] <cjwatson> In the case of Edubuntu, gnome-control-center isn't a top-level thing apt's been told to install - it's "just" a dependency of ubuntu-desktop
[15:55] <cjwatson> So it depends whether apt happens to follow the dependency chain leading to whatever tedg's package is first, or the dependency chain of ubuntu-desktop
[15:55] <cjwatson> Which is nondeterministic
[15:56] <cjwatson> stgraber: I am reasonably confident that the correct fix for this is http://paste.ubuntu.com/6150689/
[15:56] <cjwatson> We should also kill Task: edubuntu-desktop - it does nothing useful except bloat the Packages file
[15:56] <cjwatson> But that's less safe, so I'd probably prefer to do that at the start of next cycle
[15:57] <cjwatson> (Because we have to make sure nothing is using it)
[15:57] <stgraber> cjwatson: yep, that live-build change makes sense since edubuntu-desktop-gnome always include ubuntu-desktop anyway
[15:57] <cjwatson> stgraber: Want me to upload it?  Is there a bug number?
[15:58] <stgraber> cjwatson: no bug number, feel free to upload
[15:59] <cjwatson> stgraber: done
[15:59] <cjwatson> tedg: see, Foundations fixes its bugs :-P
[15:59] <cjwatson> tedg: (which is independent of whether your use of Recommends is correct - I don't much care either way on that)
[16:00] <tedg> Heh
[16:00] <tedg> Not sure if I prefer a fix to to give xnox a hard time ;-)
[16:00] <tedg> or to
[16:00] <stgraber> tedg: so with cjwatson's change, our next image should be good regardless of the indicator change, so I still think it's worth fixing just for consistency's sake (and also to make the netboot installs less broken) but it's certainly less critical now
[16:00] <xnox> =)))))))))))))))))
[16:00] <cjwatson> stgraber: I think you're mistaken that an Ubuntu netboot install would get ubuntu-system-settings - it uses Task: ubuntu-desktop which should solve the ambiguity
[16:01] <xnox> tedg: well.... =)
[16:01] <asac> didrocks: whats the culprit component?
[16:01]  * asac tries reading backlog
[16:01] <didrocks> asac: libunwind, RAOF and jamespage are working on a fix
[16:01] <tedg> stgraber, Okay, so I won't push for a release for just that.  But it'll be fixed in trunk and get out in the next release set.
[16:01] <stgraber> cjwatson: ah yeah, but it'll still be wrong for Edubuntu then, right?
[16:01] <cjwatson> stgraber: Edubuntu netboot I'm not sure of, it might still need a tweak
[16:01] <mterry> zul, how come python-wsme doesn't Depend on python-pycherry3?
[16:01] <RAOF> didrocks: Shiny new Xserver in your inbox.
[16:01] <cjwatson> Let me check
[16:02] <didrocks> RAOF: directly delivered at home? I hope there is no extra charge ;)
[16:02] <jamespage> RAOF, are you trying the drop the dependency hammer?
[16:02] <asac> didrocks: good news.  thanks
[16:02] <RAOF> jamespage: Indeed
[16:02] <cjwatson> stgraber: No, Edubuntu netboot is fine - it so happens that it's been explicitly including the ubuntu-desktop task since intrepid
[16:02] <RAOF> jamespage: That seems like the most sensible course at this point.
[16:02] <zul> mterry:  not sure
[16:03] <stgraber> cjwatson: nice!
[16:03] <cjwatson> stgraber: See bug 276317
[16:11] <Laney> pitti: writable directories work
[16:25] <didrocks> RAOF: I think you saw the new failures
[16:25] <didrocks> maybe it's my fault, but I didn't touch anything from your dsc
[16:25]  * didrocks looks
[16:25] <RAOF> ...
[16:25] <RAOF> Oh, whoops.
[16:25] <didrocks> quilt push -a is happy
[16:26] <gcds> Hello, maybe someone could recommend data protocol to communicate between processes using unix domain sockets?
[16:26] <RAOF> Shouldn't be.
[16:26] <didrocks> but I don't see it ;)
[16:26] <didrocks> weird
[16:26] <didrocks> why doesn't it yell here?
[16:26] <didrocks> Applying patch os-use-libunwind-to-generate-backtraces.patch
[16:26] <didrocks> didrocks@tidus:/tmp/xorg-server-1.14.2.901$
[16:26] <didrocks> RAOF: weird, isn't it? ;)
[16:27] <didrocks> anyway, your patch would interest me ;)
[16:27] <RAOF> didrocks: Drop the patch from debian/patches/series :)
[16:27]  * RAOF forgot to do that
[16:27] <didrocks> RAOF: ah ok
[16:45] <doko> seb128, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/4993076 (gtk2-engines)
[16:48] <seb128> doko, ok
[16:50] <didrocks> and built on armhf, thanks RAOF!
[16:50] <doko> didrocks, did you see my message about the unity-* and friends ftbfs?
[16:50] <RAOF> Hurray!
[16:50] <didrocks> doko: yeah, it's building in the ppa, so I think next landing will fix those
[16:50] <didrocks> doko: don't have time to investigate in why the tests results don't fetch the right ones
[16:51] <infinity> doko: Re: corosync, looks like the new version doesn't include coroipcc.
[16:51] <didrocks> (it seems you didn't see the ping about libunwind though, but we got that fixed thanks to RAOF)
[16:51] <infinity> roaksoax: Can you check out https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5010725 ?
[16:51] <doko> infinity, yes found out the same
[16:55] <infinity> doko: Oh, hrm.  Did you only drop the SPU stuff from gcc-4.8 and gcc-snapshot, but not older releases?
[16:55] <infinity> doko: Looks like 4.4/4.6/4.7 are still holding newlib in main.
[16:56] <doko> shouldn't be there on it's own
[16:56] <infinity> (base)adconrad@cthulhu:~$ reverse-depends src:newlib
[16:56] <infinity> Reverse-Depends
[16:56] <infinity> [16:56] <infinity> * gcc-4.4-spu                   (for newlib-spu)
[16:56] <infinity> * gcc-4.6-spu                   (for newlib-spu)
[16:56] <infinity> * gcc-4.7-spu                   (for newlib-spu)
[16:57] <infinity> (base)adconrad@cthulhu:~$ reverse-depends -b src:newlib
[16:57] <infinity> Reverse-Build-Depends
[16:57] <infinity> [16:57] <infinity> * gcc-4.4                       (for newlib-spu)
[16:57] <infinity> * gcc-4.6                       (for newlib-spu)
[16:57] <infinity> * gcc-4.7                       (for newlib-spu)
[16:57] <doko> but why are these versions in main?
[16:58] <infinity> Because things {Build-,}Depend on them, I suppose.
[16:58] <doko> infinity, gmime and libunistring have test failures for locking cases
[16:58] <infinity> doko: Oh, only 4.7 is in main, the other two are in universe.
[16:58] <doko> test cases
[16:58] <infinity> (4.7 in main is, at least, my fault...)
[16:59] <roaksoax> infinity: sure!
[16:59] <infinity> And grub2, and u-boot, and a few others.
[17:00] <doko> even the kernel still uses gcc-4.7 on armhf
[17:00] <infinity> Yeah.
[17:01] <doko> we'll have to keep 4.7 for the whole android compat stuff, I assume
[17:08] <bdmurray> slangasek: the other week we'd decided to let the fix for bug 1058884 be superceded by a security upload correct?
[17:13] <cjwatson> doko,infinity: mm, I can maybe see about switching grub2 to 4.8
[17:13] <sarnold> mlankhorst: I'll start glamor-egl audit today, once I'm caught up on the outstanding pings left over from my long weekend; I expect to finish it today (if it's really nice code :) or tomorrow (more likely)
[17:15] <roaksoax> infinity: i think we can actually drop it from the archives, but i'll need to look into reverse deps
[17:21] <roaksoax> infinity: http://pastebin.ubuntu.com/6151010/
[17:24] <infinity> cjwatson: I wouldn't stress it too much, I'm not moving eglibc to 4.8 in this cycle.  Shows testsuite regressions I don't have the time to fix before release.
[17:26] <infinity> roaksoax: http://paste.ubuntu.com/6151025/
[17:28] <roaksoax> infinity: os in fedora asterisk-ais related stuff has been dropped
[17:28] <roaksoax> and fedora doesn't ship ocfs2-tools
[17:28] <roaksoax> but we can drop it
[17:34] <infinity> roaksoax: pacemaker-mgmt needs transitioning to the corosync new world order too (or also removal?)
[17:34] <cjwatson> Yeah, I tried to rebuild that but it failed
[17:34] <roaksoax> infinity: i'm gonna look at it now
[17:35] <infinity> roaksoax: If you could figure out the remaining corosync rdeps and finish the transition and file a removal bug against all the packages you think need to go, that would be helpful.
[17:35] <roaksoax> infinity: will do, thanks for finding this out!
[17:58] <slangasek> bdmurray: bug #1058884> yes
[17:59] <bdmurray> mdeslaur: ^
[17:59] <mdeslaur> thanks bdmurray, slangasek
[18:00] <infinity> slangasek: Is that still a thing?  I thought barry had hacked around that?
[18:01] <infinity> slangasek: Oh, it never got out of proposed.  Sadness.
[18:01] <slangasek> infinity: the fix is nearly impossible to do an SRU verification on and we have at least one possible regression report, so it's not published, yeah
[18:15] <infinity> sarnold: Oh hey, good timing.  I was just about to bug you about glamor-egl and noticed you'd assigned the bug to yourself.  Does that mean the audit is underway and I should shut up and leave you alone?
[18:15] <sarnold> infinity: indeed, it's just sitting behind the morning's email and triage run..
[18:16] <infinity> sarnold: \o/
[18:16] <sarnold> :D
[18:17] <sarnold> down to only FOUR MIR audits, it feels good :)
[18:20] <infinity> sarnold: Want me to get you some more?
[18:20] <sarnold> infinity: it -is- kinda fun :) I just wish I weren't blocking co-workers ...
[18:28] <mterry> xnox, you work with cherrypy3, right?
[18:34] <infinity> sarnold: Well, I try to only poke you when I think something really should be audited (like this case, library linked by X driver running in ring 0, WCPGW), but I can certainly give you more work. :P
[18:36] <sarnold> infinity: lol
[18:41] <barry> slangasek, infinity yeah
[18:42] <mterry> zul, cherrypy3 has tests that aren't being run.  They seem to require cherryp3 to be installed first.  Any chance we can dep8-ify them?
[18:42] <zul> mterry:  sure
[19:17] <gcds> Hello, maybe someone knows how to add library dependency to configure file /
[19:18] <gcds> I have modified c app to use one library but would like to add it to the configuration file
[19:19] <slangasek> stgraber: so you moved the milestone on bug #1206872, but ... is that bug still an issue?
[19:20] <slangasek> doko: ^^ can you tell me whether samba still needs config.* updates for aarch64?  If so I can certainly poke at it
[19:20] <stgraber> slangasek: I don't know, I just ran move-milestoned-bugs on all past milestones
[19:20] <slangasek> stgraber: ah :)
[19:31] <doko> slangasek, I don't know, wanted to wait for a build on real hardware
[19:32] <slangasek> doko: what's the first version of config.sub that supports aarch64?
[19:32] <slangasek> I can just check the source quickly
[19:35] <doko> slangasek, just grep for aarch64, that should be fine
[19:36] <doko> xnox, could you have a look at the libvigraimpex ftbfs? multiarch'd boost?
[20:05] <ari-tczew> every bug has to be ACKed until is sponsored by release team since yesterday?
[20:43] <slangasek> doko: hah, so the current samba in unstable has config.sub from 2009... yeah, guess that'll need an update
[20:56] <infinity> slangasek: dh_autotools-dev or dh_autoreconf to the rescue?
[21:00] <slangasek> infinity: eventually
[21:01] <infinity> slangasek: dh_autotools-dev_updateconfig and dh_autotools-dev_restoreconfig can be nicely hooked into old skool rules files that aren't dh(1) friendly.
[21:02] <infinity> slangasek: And still much cleaner than shipping a big config.* diff.
[21:02] <infinity> slangasek: (and the added bonus of Just Working for new ports)
[23:29] <doko> infinity, libidn has another locking test failure
[23:38] <infinity> doko: Fun. :/
[23:39] <infinity> doko: Worse, it works on Debian.
[23:40]  * infinity grabs the source to test on current Debian and see if that's still true.
[23:46] <smoser> dpkg-query --show | grep zlib
[23:46] <smoser> zlib1g:amd64	1:1.2.8.dfsg-1ubuntu1
[23:46] <smoser> why does that say ':amd64'
[23:47] <infinity> doko: Bah.  It builds fine on my kernel.  Might only break on precise's...
[23:47] <smoser> when none of the other packages ('zlib' say :amd64).
[23:47] <infinity> smoser: Because it's a multi-arch:same library.
[23:47] <infinity> (base)adconrad@cthulhu:~$ dpkg -l libc6 | awk '/^i/ {print $2}'
[23:47] <infinity> libc6:amd64
[23:47] <infinity> libc6:i386
[23:47] <infinity> smoser: ^-- For example.
[23:48] <infinity> smoser: MA:same stuff shows the arch, because you can have more than one.
[23:50] <infinity> doko: Oh, wait.  That was on sid where it worked.  I'm not awake.  *tries saucy locally now*
[23:54] <smoser> infinity, thanks.
[23:54] <infinity> doko: Okay, yeah, libidn failure reproduced locally.  Can I blame your toolchain?  Seems more likely than my 3 glibc patches. :P
[23:55] <smoser> so if you debconf-set-selections libc6 values without ':arch', which do they apply to ?
[23:55] <infinity> smoser: Without an arch qualifier, you get the native arch.
[23:55] <infinity> smoser: Though, in the case of debconf, the templates are probably shared between all of them anyway.
[23:56] <cjwatson> Yeah, debconf doesn't use the arch qualifier for its owner fields.
[23:56] <infinity> Well, it COULD.  It's up to the maintainer to do so, though.
[23:56] <infinity> (base)adconrad@cthulhu:~$ debconf-show libc6
[23:56] <infinity>   glibc/upgrade: true
[23:56] <infinity> * glibc/restart-services: ssh exim4 cups cron atd
[23:56] <infinity> * libraries/restart-without-asking: false
[23:56] <infinity>   glibc/disable-screensaver:
[23:56] <infinity>   glibc/restart-failed:
[23:56] <cjwatson> Owner, not namespace.
[23:57] <cjwatson> Actually I wonder if my previous statement is true.
[23:57] <infinity> ^-- I could be generating those with arch qualfiers during build, and naming them explicitly in maintainer scripts.
[23:57] <infinity> But why would I?
[23:57] <cjwatson> elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst|postrm|prerm)$!) {
[23:57] <cjwatson>         $package=$1;
[23:57] <cjwatson> infinity: The owner is used for garbage-collection on purge.  It's not part of the question name.
[23:57] <infinity> cjwatson: Oh, right.  I always forget that owner and namespace are two things for reasons I don't grasp.
[23:57] <cjwatson> But it is mentioned as the first field in debconf-set-selections input.
[23:58] <cjwatson> $ debconf-get-selections | grep libc6: | head -n2
[23:58] <cjwatson> libc6:amd64     glibc/upgrade   boolean true
[23:58] <cjwatson> libc6:i386      glibc/upgrade   boolean true
[23:58] <cjwatson> That probably actually makes sense, since they want to be GCed independently on purge.
[23:58] <infinity> Perhaps, yeah.
[23:59] <cjwatson> In practice, getting the wrong owner at worst means that your preseeded answer is immortal and never gets purged.
[23:59] <infinity> Or it could be (but isn't, apparently) done the way dpkg file ownership is done, via refcounting.
[23:59] <cjwatson> And for libc6, it really doesn't matter.  It's going to stick around forever anyway.  Likewise zlib1g, not that that has any debconf templates.