[00:05] smoser: yes?! [00:15] infinity: it hasn't been in the same publisher cycle; if you want to smack it again with change-overrides, go ahead === _salem is now known as salem_ === fginther|afk is now known as fginther === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [04:37] Good morning [04:52] wgrant: hey William, how are you? [04:53] wgrant: who should I ask to enable saucy translations in launchpad? [04:53] Hm, we didn't already do that? [04:54] Maybe we didn't. [04:54] Let's see if I can remember how. [04:56] * infinity wonders why that doesn't happen as an artifact of opening a new series. [04:56] It's very early on NRCP [04:58] wgrant: https://translations.launchpad.net/ubuntu/saucy/+language-packs is empty [04:58] wgrant: Yeah, odd that we missed it. But that's why checklists are worse than something just doing the right thing. [04:58] wgrant: but I got a mail from some contributor who wants to start translating saucy in LP [04:59] We're not building langpacks, because that happens later, I think [05:00] pitti: It's not done, yeah [05:00] And we can't really test it beforehand like we normally do [05:00] So let's live dangerously :) [05:00] well, with a rolling release thingy, as well as for people who start translating in LP it would actually be nice to have langpacks early as well, but opening saucy translations is indeed a bit more important [05:01] The plan was to have langpacks from the start, AIUI, but that didn't actually happen [05:03] mlankhorst: So... Whoever NEWed all your lts-raring stack did so to universe, and thus you missed out on noticing that xorg-server-lts-raring has a build-dep on libaudit-dev that needs to be dropped (it's in universe in precise, and we're not likely to promote it, since the condition for promoting it in raring was a bunch of code cleanups) [05:04] mlankhorst: I suspect they NEWed everything to universe, now I get to go hunt them down and clean up. Unless you have a quick list of all the source packages involved, so I can mindlessly promote the lot? :P [05:15] Hey, a package won't build for me in lp. Package "webkitgtk-3.0 missing". libgtk-3-dev is in the build-depends though [05:16] log: https://launchpadlibrarian.net/141838690/buildlog_ubuntu-precise-i386.etube_0.2-0~2~precise1_FAILEDTOBUILD.txt.gz [05:16] bzr code: http://bazaar.launchpad.net/~versable/elementary-community/eTube/files [05:16] It builds fine lokally [05:17] local* [05:17] versable: Missing build-dep on libwebkitgtk-dev, I'd assume. [05:17] Oh, wait, wrong webkit. [05:18] libwebkitgtk-3.0-dev [05:18] infinity: Right, that's probably it. Thanks. [06:19] good morning [07:05] infinity: feel free to kill the audit dependency for now [07:05] if it still builds [07:05] infinity: xorg-pkg-tools has the list [07:06] sec let me generate it [07:06] mlankhorst: I was thinking that killing the audit dep was something you'd have to do in your fancy scripts, so it doesn't come back. [07:07] sure I'll do that too [07:08] mlankhorst: But yeah, let me test-build quickly here. [07:08] why kill the audit dep? I thought audit had been promoted to main? [07:08] not in precise yet [07:08] ah [07:09] sarnold: And the one in main won't ever be promoted, since it needs a ton of work to be acceptable. [07:09] s/main/precise/ [07:09] Brain. Hurting. Long day. [07:09] infinity: isn't it 0800 for you? Or have you moved. Again. [07:09] i'm a beginner,like to contribute to ubuntu please help [07:10] lifeless: It's 1am. [07:10] lifeless: It'll be 8am for me in a month when I'm in the UK, close enough. :P [07:10] but I've added /libaudit-dev/d for xorg-pkg-tools, next version should upload correctly [07:10] :) [07:10] mlankhorst: Oh, hrm. Dropping the build-dep isn't enough. [07:11] mlankhorst: Oh, wait, I remember adding this. It was also adding some selinux thing. [07:11] * infinity checks the changelog. [07:11] http://launchpadlibrarian.net/130794589/xorg-server_2%3A1.13.2-0ubuntu1_2%3A1.13.2-0ubuntu2.diff.gz [07:11] mlankhorst: Needs to be the inverse of that. [07:12] mlankhorst: Are your scripts smart enough to mangle 'selinux = --disable-xselinux' in debian/rules? [07:12] it's sed, i can just do it quickly [07:13] * infinity rebuilds again. [07:13] -e "s/--enable-xselinux/--disable-xselinux/" \ [07:14] Should do. It passed confugre with that, at least. [07:14] * infinity waits for it to, like, build. [07:19] ok I'll bbl, weather is really nice so it's a crime not to bike :) [07:20] mlankhorst: Heh. Enjoy. I'll just upload this as precise2, and if you ever have to respin, your scripts will DTRT? [07:22] mlankhorst: http://paste.ubuntu.com/5741156/ <-- My debdiff, so you can check and see if your script produces the same change. [08:05] infinity, Hmmm... is this just broken by my reading? [ubuntu/quantal-proposed] linux_3.5.0-34.55_amd64.tar.gz - (Accepted) [08:05] smb: You don't pay attention to -changes much, if that's the first time you've noticed that. :) [08:05] smb: That's the uefi custom upload. [08:05] infinity, I probably do not do that much [08:06] It required this to be in a smaller quantity of updates for me to notice. :-P [08:07] Thanks for the explanation [08:35] xnox: wrt. cryptsetup uninstall/plymouth in initramfs: is it possible that this is related to cryptswap? [08:35] xnox: I use ecryptfs, so ubiquity set up a cryptswap device and thus kept the full cryptsetup package [08:36] xnox: but (1) I doubt whether we really need swap that early (in intramfs), and (2) at least in the past we didn't set up cryptswap for non-ecryptfs; perhaps we do now? [08:36] xnox: (I haven't checked anythign in ubiquity, it just came to my mind) [08:36] pitti: correct. ecryptfs does pull in cryptsetup for encrypted swap. But default unecrypted (neither full, nor homedir) install shouldn't pull in cryptsetup. [08:37] ecryptfs does encrypted swap for a few releases now (not sure when it started) [08:38] yes, and that makes sense; I just wonder whether we need to set up/mount swap in initramfs already [08:38] xnox: but that's actually unrelated; I guess (2) is the more interesting question in terms of initramfs size with all defaults [08:38] we shouldn't, indeed. [08:39] I'd like to still find out why/how we are regressed, instead of simply implementing conditional logic (do not include ecryptfs in initramfs, unless '/' or '/usr' are encrypted) [08:40] yes, sure; ecryptfs and cryptswap just came to my mind as possible things which might have changed === doko_ is now known as doko [09:34] 20130521 saucy daily correctly removes cryptsetup & ecryptfs-tools in a default install, whilst 20130523 and later do not. [09:45] pitti: so it seems like cryptsetup via ecryptfs-utils via adduser moved from "d-i-requirements" to "minimal" on 20130521, while on 20130520 it was not. [09:45] and indeed in raring, cryptsetup was not in Task: minimal. [09:45] eek [09:45] indeed, only cryptsetup-bin is supposed to be installed by default [09:45] that's why we split it out in the first place [09:46] xnox: dropping adduser's ecryptfs-utils recommends to suggests? [09:46] pitti: but it was there in raring as well, so how come it _now_ moved up? [09:47] or ecryptfs-utils ought to recommend cryptsetup-bin only (but I'm not sure whether that's sufficient) [09:47] perhaps that changed [09:52] but versions of adduser, ecryptfs-utils nor crypsetup have not changed since raring yet. [09:53] hm; I don't see how cryptsetup would not have been in minimal in raring then [09:54] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130520.log [09:54] vs [09:54] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log [09:54] Resolving minimal dependencies ...! Promoted ecryptfs-utils from d-i-requirements to minimal to satisfy adduser [09:54] but indeed it wasn't [09:55] i have a local repository, how can I increase its priority ? [09:56] not sure what to put infront of "pin:" in the .pref file [09:58] om26er: https://help.ubuntu.com/community/PinningHowto but please note if the packages have identical version number, the "first" repository wins. [09:59] pitti: saucy's translations are copied and imports are happening now [09:59] wgrant: splendid, thank yoU! [09:59] xnox, and if its a separate repo in /etc/apt/sources.list.d/ ? [10:00] om26er: check with $ apt-policy package what "won" [10:00] xnox: we didn't rebuild d-i or anythign like that on that day -- perhaps on that day someone processed priority-mismatches? [10:03] xnox, here http://paste.ubuntu.com/5741445/ my repo is indeed getting higher priority, but I want to set it to 600 or 1000 just to be sure, but seems my pref file is broken ? [10:16] pitti: should I upload adduser lowering ecryptfs-utils from recommends -> suggests? [10:16] pitti,xnox: https://launchpad.net/ubuntu/saucy/i386/ecryptfs-utils says no [10:16] Indeed there's a bunch of priority-mismatches I'd been deliberately not processing until I had a chance to think about it :) [10:16] cjwatson: any idea how ecryptfs-utils got into minimal? [10:17] but wasn't before... [10:17] the more interesting question is how it was not in minimal in raring yet? [10:17] A Recommends from adduser would be sufficient [10:17] that was also present in raring. [10:18] one moment [10:18] i see that it moved into minimal on 20130521 http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log [10:18] adduser wasn't in minimal in raring for some reason [10:19] Ah, it was in required, which is really where it belongs IMO [10:19] But required doesn't follow Recommends [10:19] So I guess something in required dropped a Depends: adduser [10:20] Well, I dunno, adduser in minimal vs. required is OK actually [10:20] xnox: my gut feeling is that adduser should only suggest ecryptfs-utils [10:20] TBH this is basically that the Recommends was incorrectly not noticed in raring [10:20] So I'd say adduser should be left where it is and drop the Recommends to Suggests [10:22] ack. will upload. [10:22] (required doesn't process Recommends because it corresponds to debootstrap and debootstrap doesn't; but this does mean that there are some corner cases where Recommends kind of get lost) [10:23] xnox: спасибо! [10:27] Where do I find documentation (ideally, examples) for implementing a host for Application Indicators? Not an indicator itself, but something that would show them? [10:30] apw: i think you can still blame pitti and systemd for bootspeed regression, as it was udev that dropped adduser dependency when moving from udev->systemd source package thus triggering an unfortunate series of seed changes and promoting cryptsetup into minimal. [10:30] =) [10:31] fun -- making things bigger by *dropping* dependencies.. [10:31] TGIF! [10:36] xnox, heh :) pitti TGFT [10:37] xnox, fixable without adding spagetti to the seeds ? [10:37] apw: yeah, uploaded adduser that moves ecryptfs-utils from recommends to suggests. But it's kind of hilarious that adduser is now not required =) [10:39] heh yeah, it is a bit of a scarey thought all told [10:39] well, there's always useradd, for really mini-minimal systems [10:39] so i shall look at the new boot charts on monday, fingers cross [10:39] adduser is perl [10:40] (perl-base only, so you can't get rid of that anyway, but still) [10:41] pitti: got time to talk about locales and postgres? [10:41] rbasak: sure (didn't I talk enough yet on devel@? :-) ) [10:41] * xnox pretends to speak only ASCII based languages [10:41] rbasak: that's where apw's spaghetti come in [10:41] pitti: I have a really long reply for you too. I was hoping to shorten it by talking on here :) [10:42] pitti: I think my objection lies in postgres' postinst behaviour [10:42] pitti: that if the *user* locale is bad, then the postinst's behaviour changes [10:42] rbasak: that it fails in an invalid locale? I can change that (as I said in my mail) [10:42] pitti: I'm trying to verify this. I'd like the postinst to ignore the user's locale (ie. the environment) and use /etc/default/locale instead, if it is there. [10:42] i.e . go from "fails to install" to "installs, but doesn't create any cluster" [10:43] pitti: I'm not sure that it does actually fail. I think it already has that behaviour. But I'm struggling to fire up a cloud instance to test at this moment. [10:43] rbasak: you also need to check at least /etc/environment then, and quite possibly /etc/profile, /etc/profile.d/, and whereever else admins might drop locale definitions in [10:43] pitti: I'd like it to install *and* create a cluster by using /etc/default/locale. [10:43] rbasak: no, the package installation does fail if pg_createcluster fails [10:43] pitti: the user's locale shouldn't matter. [10:44] It's confusingly inconsistent if the way a package is set up depends on the user's environment at the time of the dpkg run [10:44] rbasak: well, it's the locale in a root context; the problem is that in that pathological case ssh + sudo carry the remote locale all the way into a root context where it is totally invalid [10:45] Even without ssh, if the user sets a valid locale in ~/.profile or ~/.bashrc or whatever and uses sudo, then it'll work but there's still an inconsistency [10:45] rbasak: I share the feeling about inconsistency; I just don't know a good answer to it [10:45] What's wrong with using /etc/default/locale if it exists, falling back to /etc/environment? [10:45] rbasak: in the bug report case there is no /etc/default/locale nor /etc/environment [10:45] Then that solves the ssh carry through an invalid locale problem too [10:46] rbasak: the problem is that nothing specifies that locales must be defined in those two filese only [10:46] pitti: I think the bug would still exist if there is; I'll verify. [10:46] pitti: then in that case only, default to C.UTF-8 but prompt with debconf? [10:46] rbasak: in my experiments, if /etc/default/locale actually does set a locale, that overwrites the one ssh is passing on [10:46] In the majority of cases, the installer would have fixed it in /etc/environment (old) or /etc/default/locale (new), and there will be no prompt. [10:47] For users with unusual systems, they'll be asked. [10:47] rbasak: I really want to avoid debconf (for various reasons, see mail); using C.UTF-8 would be acceptable then [10:47] I'd be happy with C.UTF-8 with no prompting. [10:47] OK [10:47] Does that mean you agree with me? No using the environment at all; use /etc/default/locale, fall back to /etc/environment; fall back to C.UTF-8. [10:48] then, what do we do about those people who actually want C (I got several reports there) [10:48] rbasak: no, as I said these are not the only files where you can set the locale [10:48] as the primary definition of "locale" is in terms of environment variables, there are a gazillion places to define them [10:49] How about an extra fall back to the environment but iff /etc/default/locale and /etc/environment doesn't set the locale? [10:49] I'm trying to pin down using the "system" locale here, rather than the user locale. Only the user locale is available from the environment. [10:49] rbasak: ^ I don't know what you mean by this [10:50] i. e. use /e/d/locale, if that doesn't define anythign, use /e/environment, if that doesn't define anything use the environment? [10:50] Or how about a debconf prompt with low priority for those who really need an override? [10:50] that's exactly what leads to the curretn bug [10:50] those who really need to change it can just specify it at pg_createcluster [10:50] a debconf prompt is ridiculously expensive (given translations etc.) for such a small corner case IMHO [10:51] So fall back to C.UTF-8 then. [10:51] rbasak: I'd actually fall back to C [10:51] OK, fine. [10:51] I just want /etc/default/locale used in preference to the user's environment. [10:51] if a server does not define any system locale, then presumably the admin actually means it; not sure? [10:51] I think that'll fix the bug. [10:51] I understand that you don't think it will. [10:51] I will verify. [10:51] rbasak: but.. there IS no /e/d/locale for the bug you reported/commented on [10:52] the bug precisely happens on those systems which don't define a system locale [10:52] Riddell, how stable/good is kde in saucy (wanting to do a test rebuild) [10:52] seb128, didrocks , how stable/good is gtk/gnome in saucy (wanting to do a test rebuild) [10:53] doko: pretty good, I just uploaded all of KDE SC 4.10.4 which is due to start compiling right about now [10:53] pitti: I'm not sure that's the case. I believe the system I reproduced on did have /etc/default/locale set. [10:53] rbasak: so what this would need is to find a way to tell whether a defined locale from the env that isn't in /e/d/l nor in /e/env comes from someplace else in the system or from sudo [10:53] doko, it should be good/stable enough to have a rebuild, we are on the stable serie for both and have no update planned soon [10:53] pitti: I can't seem to reproduce right at this moment, because I can't get an available instance on a private cloud I have access to. [10:53] Riddell, well, if it starts compiling, then it's still in proposed? [10:53] doko: yes [10:53] so *not* ready [10:54] rbasak: FYI, I use "run-adt-test -sl" for those; they are cloud-image based, and perfect for quick throwaway VMs === Guest86601 is now known as zumbi [10:54] (and all local) === zumbi is now known as Guest22269 [10:56] Postgres is a very special case here. [10:56] Normally a locale setting doesn't cause any persistent changes to the system [10:56] I don't think it's safe for the environment to specify a locale for this purpose. [10:56] We should define where a system locale is defined, and use that [10:57] Or use C, and require people to override template1 when they need to. [10:57] Or use the locale of the user who runs createdb when he runs createdb to do it for him. [10:57] ^ that already happens, I think [10:58] In that case, why does the postinst need to use anything but C? === Guest22269 is now known as zumbi_ [10:58] so perhaps a middle ground would be for the postinst to clean up its entire locale environment (LANG, LANGUAGE, LC_*), then source /etc/environment, then source /etc/default/locale, and then run pg_createcluster [10:59] that'll break use cases where the admin defines a system locale in a different place, but these seem rather small to me (we have to compromise somewhere) [10:59] You can't source /etc/environment safely. It may look mostly like a shell file, but it has a formally different syntax; it's a pam_env configuration file. [10:59] That works for me [10:59] cjwatson: ah, too bad [11:00] Unfortunately pam_getenv is broken, or that would be the right answer. [11:00] I think the above may be true for /etc/default/locale too, technically, although it's in practice safer since its key set is more restricted [11:01] I've seen plenty of places which source /e/d/l, though [11:01] Might be worth seeing how hard it is to fix pam_getenv ... [11:01] /etc/init/mountall.conf [11:01] I wouldn't get too upset about sourcing /etc/default/locale [11:01] It might even be formally permitted, I forget [11:01] so mountall will fail if sourcing /etc/default/locale fails [11:02] I thought that was one of the reasons why it got moved out of /e/env [11:02] But the locale hasn't been written to /etc/environment for years [11:02] Would it be OK to attempt to source /etc/environment, and ignore failures? Or is that unsafe too? [11:02] Yeah, could be [11:02] You have to go to considerable lengths to avoid that killing the calling shell [11:02] cjwatson: right, but I still think it's a legitimate place for defining it [11:02] . /etc/environment || true <- not sufficient [11:02] not wanting to be too selfish, but even my own server has that, and that was a debian install from a few years back [11:03] I only became aware of /etc/default/locale recently, when something broke. I've been using /etc/environment for a long time. But note that something broke (can't remember what). [11:03] pitti: pam_getenv was meant to be the safe answer to this. I'm not sure how long it's been broken for [11:04] probably something like $(source /etc/environment && locale |grep LC_CTYPE || true) [11:04] Failing that, I guess you could source in a subshell and pass out the answers you care about, or something [11:04] Yeah [11:04] But . not source [11:04] (source is a bashism) [11:04] and with an actually correct || true'ing (not applying that to grep), etc., but something along that lines [11:05] Have we agreed with this as a solution then? [11:06] I still need to check that /etc/default/locale is actually set on the use case that generated the maas bug. [11:06] But I think it's reasonable to demand that it is set, even if the ssh session has a broken locale [11:07] Though with pitti's solution, it'd use C without a system locale defined, right? [11:07] rbasak: well, in the cases where it isn't set, it would use C then [11:07] rbasak: right [11:07] Great [11:07] that still leaves the broken locale for everything else, of course [11:08] Right. I need to track down why Julian didn't get the cloud-init warning. Perhaps that's not the final solution but it should have worked for him. [11:08] Perhaps he wasn't using a cloud instance, thinking about it. [11:08] So no cloud-init. [11:08] I'll track that down with him. [11:09] For other things, the warnings about the locale being broken are fine, I think. At least no other functionality other than displayed messages are broken, AFAIK. [11:12] infinity: yeah it will be fine [11:12] thanks [11:14] rbasak: I updated bug 969462 with a summary [11:14] bug 969462 in postgresql-common (Ubuntu) "fails to start after install if invalid locale is set" [Low,In progress] https://launchpad.net/bugs/969462 [11:14] pitti: thank you! And for sticking it out with me on this. [11:15] rbasak: heh, you're welcome; locales are messy :/ [11:16] rbasak: oh, actually, package installation does not fail in that case any more; that got changed a while ago [11:17] sorry about that (but you wanted that behaviour anyway) [11:17] Right, OK, thanks. But the maas postinst will still fail without this new behaviour, right? [11:17] there still wouldn't be a DB cluster to talk to, yes [11:20] didrocks: Did you notice that a few bits of today's autolanding are stuck in -proposed because python-ubuntu-platform-api and uoa-integration-tests don't exist? [11:21] * xnox tried to set C.UTF-8 locale & purge langpacks from my server. I'm still stuck with en_GB.utf8, en_US and en_US.iso88591 in locale -a output. [11:21] cjwatson: ah, I was waiting for still 30 minutes to see if things are wrong (now that all main promotion are done) [11:21] cjwatson: uoa-integration-tests is in NEW [11:21] part of my review list [11:21] Oh, it is? Ah, I missed it [11:21] python-ubuntu-platform-api? I need to look at it [11:22] cjwatson: does the migration tool tells you about Main/Universe as well? [11:22] No [11:22] ok, as the migration is quite complex, I hoped I didn't miss anything [11:22] one sec for python-ubuntu-platform-api [11:22] hope* [11:23] oh, I thought we were moving away from python [11:23] ah, for tests? [11:23] pitti: probably for those === schmidtm_ is now known as schmidtm [11:24] cjwatson: argh ok, autopilot-touch [11:25] Right [11:26] didrocks: btw, this was a nice read! https://launchpad.net/ubuntu/+source/autopilot-gtk/1.3daily13.06.05-0ubuntu1 [11:26] pitti: heh, glad you like it :) [11:26] didrocks: does uploading the package auto-close the upstream bugs, OOI? [11:26] it's matching any bugs related to the commit if there are, but keep the commit message (there is a list of commit message and a tag to not display some though) [11:27] pitti: no, long debate, nobody agrees, even between the different upstreams [11:27] didrocks: autopilot-gtk doesn't have any ubuntu bugs, but a lot of upstream ones which were addressed by that [11:28] ok, for autopilot, let's do a manual upload removing the dep, we don't use autopilot-touch in the distro anyway [11:28] (downgrading to suggests) [11:30] * cjwatson clears the broken lplib cache that'd broken component-mismatches === MacSlow is now known as MacSlow|lunch [11:31] cjwatson: for daily release, I'm using a separate cache per process [11:32] only way to not have this issue [11:32] (that I found) [11:32] I'm using separate caches for a lot of things but not quite everything :-/ [11:33] I thought that fix was SRUed recently. [11:34] I don't see it in python-launchpadlib/+changelog [11:34] I think I asked for it ... [11:34] cjwatson: it's in lars.restful IIRC [11:35] oh, python-lazr.restfulclient [11:35] lazr.restfulclient probably [11:35] Apparently not to precise though [11:35] Ah [11:36] bug 459418 [11:36] bug 459418 in lazr.restfulclient (Ubuntu Precise) "Cache is not safe for concurrent use (by processes or threads)" [High,In progress] https://launchpad.net/bugs/459418 [11:36] cyphermox: ^- are you still planning on uploading that to precise? it's been a few months [11:37] and you could help make our archive reports more robust :) [11:37] and less emails because of the script being broken \o/ [11:43] Any objections if I fix https://wiki.ubuntu.com/StableReleaseUpdates#Procedure? The "If you can't upload" section looks like it's got lost at the end of a bullet point; I think it needs to be clearer since people who can't upload may just assume that they can't do anything. [11:45] rbasak: Go for it [11:45] I agree that wants to be out a level [11:48] Done. Sorry, just realised after I hit submit that I left the changelog blank :-/ [11:53] *shrug* [11:56] cjwatson, hey, is there a component mismatch report for packages in proposed? [11:56] seb128: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt [11:56] (thanks to Ursinha) [11:56] cjwatson, ah, nice, thanks [11:57] it's an hour or two out of date for reasons discussed above - should update at the next publisher cycle [11:57] k === cking_ is now known as cking === _salem is now known as salem_ [12:20] Is there a compiling guide for ubuntu? === MacSlow|lunch is now known as MacSlow [12:33] cjwatson: thanks for the pocketsphinx upload :) I asked sil2100 to disable the powerpc tests and he was working on that this morning [12:33] sil2100: stop, not needed anymore :) [12:34] Ah, ok ;) [12:34] Well, it was just a quick fix anyway [12:35] Heh, yeah, was just trying to clear a bit of component-mismatches [12:35] And the sight of python-support offends me :) [12:35] cjwatson: does the migration to the main release pocket still don't retain the components in main? [12:36] ahah :) [12:36] I don't understand the question [12:36] (I'm seeing the scopes in universe, I'm sure I NEWed them in main) [12:36] like https://launchpad.net/ubuntu/+source/unity-scope-devhelp [12:36] There may be some LP bugs there [12:36] ok [12:36] I'll repromote them then [12:37] https://launchpad.net/ubuntu/+source/unity-scope-devhelp/+publishinghistory definitely suggests a bug [12:37] no worry, it's a good "end of crazy week" monkey work I can do :p [12:38] Probably YA stupid ancestry bug === OdyX` is now known as OdyX [12:46] cjwatson, didrocks: Copies don't do binary overrides [12:46] Well, they respect existing ancestry, but you can't specify overrides [12:46] Only for sources :/ [12:47] wgrant: ah, ok, makes sense then :) [12:47] thanks for the explanation [12:48] wgrant: But even the source was copied from proposed/main to release/universe [12:49] cjwatson: But the copy to -release was a cross-suite ancestry lookup [12:49] I don't think that works in many cases. [12:49] Hmm [12:49] But you're right about the source [12:49] So it's not binary-specific [12:50] Blargh. [12:50] cjwatson: yes, I'll upload in a minute [12:52] cyphermox: Great, thanks [12:52] done, it will be in the queue [12:53] has anyone besides me tried the packages? [12:53] seems to work properly here, but maybe I'm not testing it right [12:54] I think bits of the reports on lillypilly run with a similar local patch [12:54] Just not all of them [12:55] It might be worth upgrading lillypilly to a -proposed package by way of verification, once we confirm it basically works at all === salem_ is now known as _salem [12:59] ok [13:00] wgrant: thanks for the branch fixing === _salem is now known as salem_ [13:12] arges: Could you merge iptables, or tell somebody else they can do it (you're touched-it-last so it defaults to you)? There's some stuff in saucy-proposed blocked on that. [13:13] cjwatson: hi. Ok not really sure what you mean by merge, should i just try to reformat my patches to work on top of a fresh debian version? [13:13] arges: https://merges.ubuntu.com/main.html [13:14] Yours is only the most recent patch - there's a large stack of Ubuntu patches that need to be ported forward. You might want to just ask jdstrand to do it since he did the last big chunk of work :) [13:14] But we default to assuming that the person who uploaded it last will do it [13:14] cjwatson: well i'd love to learn and don't mind doing it [13:15] arges: also https://wiki.ubuntu.com/UbuntuDevelopment/Merging, perhaps more helpful [13:15] thanks, answered my next question [13:16] cjwatson: pyruntest build-dep (for gtester2xunit) and julius-voxforge (recommended by hud) are the 2 we missed I guess. We filed the MIRs, but that won't block the iso building if it's not treated today (as being build-dep and recommends only), right? [13:17] arges: there is also a UDD / bzr workflow. When branches are up to date... and when bzr manages to merge sensibly.... http://developer.ubuntu.com/packaging/html/udd-merging.html [13:17] xnox: ok thanks [13:18] didrocks: shouldn't, from that description [13:18] ok, thanks :) [13:19] platform-api will be a blocker though [13:19] * cjwatson moves unity-scopes-runner and the various hud binaries to main [13:20] oh, maybe somebody had done the latter already === hggdh_ is now known as hggdh [13:24] xnox: so i should be merging from debianlp:squeeze/iptables (in this case) which seems to be at an older version, or bzr merge-upstream seems to be at a newer version that whats reported on the merges.u.c page === davidcalle_ is now known as davidcalle [13:25] arges: usually one merges from lp:debian/iptables (aka sid) or from lp:debian/experimental/iptables (if that's what needed/wanted) [13:26] You should certainly not be merging from squeeze, which is oldstable :) [13:26] Ever [13:26] cjwatson: xnox: ok should the wiki be updated then? [13:26] http://developer.ubuntu.com/packaging/html/udd-merging.html [13:26] hmm.... it's a bzr branch somewhere. [13:26] I don't think that's a wiki - but yes, that's completely wrong, merge frmo sid [13:26] *from [13:26] i'm guessing its meant to be more of a generic guide [13:27] ok [13:27] No point being generic since package merging is basically for one purpose [13:27] * xnox found a branch and will update in a sec. [13:38] cjwatson, thanks for fixing the pocketsphinx build on powerpc. I was considering disabling, but hadn't researched the failure yet [13:38] We have a similar problem on sphinxbase, but it also fails on i386 as well as powerpc [13:39] cjwatson: do i need to be filing a merge bug before working on this btw? [13:39] I thought it was probably more urgent to get the python-support dep out of main than to worry about the test failure [13:40] arges: no [13:40] ack [13:40] arges: you're touched-it-last, it's yours by default [13:40] merge bugs are weird things anyway imo :) [13:41] ok next question: so i merged with bzr merge lp:debian/iptables into lp:ubuntu/iptables, and the conflict doesn't match whats here : https://merges.ubuntu.com/i/iptables/REPORT [13:42] the versions match what the merge tool did btw [13:43] oh, nice, Debian has iptables 1.4.18 now, that means that once arges is done with the merge I'll be able to stop using my locally packaged 1.4.18! [13:43] (1.4.18 introduces IPv6 NAT which I need to provide easy IPv6 to containers and VMs) [13:43] you shouldn't necessarily expect bzr and MoM to produce the same results; you're meant to use judgement [13:43] ok [13:44] they're differently smart in different ways [13:44] for the most part MoM is likely to be cruder [13:45] mterry: hello, I had a ping from you yesterday but i was gone, and then you were gone. What's up? [13:45] xnox, hi~ [13:49] oh, hud now pulling in the voxforge stuff? [13:49] are we getting speech recognition into the desktop now? [13:50]