[00:05] <xnox> smoser: yes?!
[00:15] <slangasek> infinity: it hasn't been in the same publisher cycle; if you want to smack it again with change-overrides, go ahead
[04:37] <pitti> Good morning
[04:52] <pitti> wgrant: hey William, how are you?
[04:53] <pitti> wgrant: who should I ask to enable saucy translations in launchpad?
[04:53] <wgrant> Hm, we didn't already do that?
[04:54] <wgrant> Maybe we didn't.
[04:54] <wgrant> 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] <wgrant> It's very early on NRCP
[04:58] <pitti> wgrant: https://translations.launchpad.net/ubuntu/saucy/+language-packs is empty
[04:58] <infinity> wgrant: Yeah, odd that we missed it.  But that's why checklists are worse than something just doing the right thing.
[04:58] <pitti> wgrant: but I got a mail from some contributor who wants to start translating saucy in LP
[04:59] <StevenK> We're not building langpacks, because that happens later, I think
[05:00] <wgrant> pitti: It's not done, yeah
[05:00] <wgrant> And we can't really test it beforehand like we normally do
[05:00] <wgrant> So let's live dangerously :)
[05:00] <pitti> 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] <wgrant> The plan was to have langpacks from the start, AIUI, but that didn't actually happen
[05:03] <infinity> 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] <infinity> 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] <versable> 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] <versable> log: https://launchpadlibrarian.net/141838690/buildlog_ubuntu-precise-i386.etube_0.2-0~2~precise1_FAILEDTOBUILD.txt.gz
[05:16] <versable> bzr code: http://bazaar.launchpad.net/~versable/elementary-community/eTube/files
[05:16] <versable> It builds fine lokally
[05:17] <versable> local*
[05:17] <infinity> versable: Missing build-dep on libwebkitgtk-dev, I'd assume.
[05:17] <infinity> Oh, wait, wrong webkit.
[05:18] <infinity> libwebkitgtk-3.0-dev
[05:18] <versable> infinity: Right, that's probably it. Thanks.
[06:19] <dholbach> good morning
[07:05] <mlankhorst> infinity: feel free to kill the audit dependency for now
[07:05] <mlankhorst> if it still builds
[07:05] <mlankhorst> infinity: xorg-pkg-tools has the list
[07:06] <mlankhorst> sec let me generate it
[07:06] <infinity> 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] <mlankhorst> sure I'll do that too
[07:08] <infinity> mlankhorst: But yeah, let me test-build quickly here.
[07:08] <sarnold> why kill the audit dep? I thought audit had been promoted to main?
[07:08] <mlankhorst> not in precise yet
[07:08] <sarnold> ah
[07:09] <infinity> sarnold: And the one in main won't ever be promoted, since it needs a ton of work to be acceptable.
[07:09] <infinity> s/main/precise/
[07:09] <infinity> Brain.  Hurting.  Long day.
[07:09] <lifeless> infinity: isn't it 0800 for you? Or have you moved. Again.
[07:09] <kiru> i'm a beginner,like to contribute to ubuntu please help
[07:10] <infinity> lifeless: It's 1am.
[07:10] <infinity> lifeless: It'll be 8am for me in a month when I'm in the UK, close enough. :P
[07:10] <mlankhorst> but I've added /libaudit-dev/d for xorg-pkg-tools, next version should upload correctly
[07:10] <lifeless> :)
[07:10] <infinity> mlankhorst: Oh, hrm.  Dropping the build-dep isn't enough.
[07:11] <infinity> mlankhorst: Oh, wait, I remember adding this.  It was also adding some selinux thing.
[07:11]  * infinity checks the changelog.
[07:11] <infinity> http://launchpadlibrarian.net/130794589/xorg-server_2%3A1.13.2-0ubuntu1_2%3A1.13.2-0ubuntu2.diff.gz
[07:11] <infinity> mlankhorst: Needs to be the inverse of that.
[07:12] <infinity> mlankhorst: Are your scripts smart enough to mangle 'selinux = --disable-xselinux' in debian/rules?
[07:12] <mlankhorst> it's sed, i can just do it quickly
[07:13]  * infinity rebuilds again.
[07:13] <mlankhorst> -e "s/--enable-xselinux/--disable-xselinux/" \
[07:14] <infinity> Should do.  It passed confugre with that, at least.
[07:14]  * infinity waits for it to, like, build.
[07:19] <mlankhorst> ok I'll bbl, weather is really nice so it's a crime not to bike :)
[07:20] <infinity> mlankhorst: Heh.  Enjoy.  I'll just upload this as precise2, and if you ever have to respin, your scripts will DTRT?
[07:22] <infinity> mlankhorst: http://paste.ubuntu.com/5741156/ <-- My debdiff, so you can check and see if your script produces the same change.
[08:05] <smb> infinity, Hmmm... is this just broken by my reading? [ubuntu/quantal-proposed] linux_3.5.0-34.55_amd64.tar.gz - (Accepted)
[08:05] <infinity> smb: You don't pay attention to -changes much, if that's the first time you've noticed that. :)
[08:05] <infinity> smb: That's the uefi custom upload.
[08:05] <smb> infinity, I probably do not do that much
[08:06] <smb> It required this to be in a smaller quantity of updates for me to notice. :-P
[08:07] <smb> Thanks for the explanation
[08:35] <pitti> xnox: wrt. cryptsetup uninstall/plymouth in initramfs: is it possible that this is related to cryptswap?
[08:35] <pitti> xnox: I use ecryptfs, so ubiquity set up a cryptswap device and thus kept the full cryptsetup package
[08:36] <pitti> 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] <pitti> xnox: (I haven't checked anythign in ubiquity, it just came to my mind)
[08:36] <xnox> 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] <xnox> ecryptfs does encrypted swap for a few releases now (not sure when it started)
[08:38] <pitti> yes, and that makes sense; I just wonder whether we need to set up/mount swap in initramfs already
[08:38] <pitti> xnox: but that's actually unrelated; I guess (2) is the more interesting question in terms of initramfs size with all defaults
[08:38] <xnox> we shouldn't, indeed.
[08:39] <xnox> 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] <pitti> yes, sure; ecryptfs and cryptswap just came to my mind as possible things which might have changed
[09:34] <xnox> 20130521 saucy daily correctly removes cryptsetup & ecryptfs-tools in a default install, whilst 20130523 and later do not.
[09:45] <xnox> 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] <xnox> and indeed in raring, cryptsetup was not in Task: minimal.
[09:45] <pitti> eek
[09:45] <pitti> indeed, only cryptsetup-bin is supposed to be installed by default
[09:45] <pitti> that's why we split it out in the first place
[09:46] <pitti> xnox: dropping adduser's ecryptfs-utils recommends to suggests?
[09:46] <xnox> pitti: but it was there in raring as well, so how come it _now_ moved up?
[09:47] <pitti> or ecryptfs-utils ought to recommend cryptsetup-bin only (but I'm not sure whether that's sufficient)
[09:47] <pitti> perhaps that changed
[09:52] <xnox> but versions of adduser, ecryptfs-utils nor crypsetup have not changed since raring yet.
[09:53] <pitti> hm; I don't see how cryptsetup would not have been in minimal in raring then
[09:54] <xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130520.log
[09:54] <xnox> vs
[09:54] <xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log
[09:54] <xnox> Resolving minimal dependencies ...! Promoted ecryptfs-utils from d-i-requirements to minimal to satisfy adduser
[09:54] <pitti> but indeed it wasn't
[09:55] <om26er> i have a local repository, how can I increase its priority ?
[09:56] <om26er> not sure what to put infront of "pin:" in the .pref file
[09:58] <xnox> om26er: https://help.ubuntu.com/community/PinningHowto but please note if the packages have identical version number, the "first" repository wins.
[09:59] <wgrant> pitti: saucy's translations are copied and imports are happening now
[09:59] <pitti> wgrant: splendid, thank yoU!
[09:59] <om26er> xnox, and if its a separate repo in /etc/apt/sources.list.d/ ?
[10:00] <xnox> om26er: check with $ apt-policy package what "won"
[10:00] <pitti> xnox: we didn't rebuild d-i or anythign like that on that day -- perhaps on that day someone processed priority-mismatches?
[10:03] <om26er> 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] <xnox> pitti: should I upload adduser lowering ecryptfs-utils from recommends -> suggests?
[10:16] <cjwatson> pitti,xnox: https://launchpad.net/ubuntu/saucy/i386/ecryptfs-utils says no
[10:16] <cjwatson> 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] <xnox> cjwatson: any idea how ecryptfs-utils got into minimal?
[10:17] <xnox> but wasn't before...
[10:17] <pitti> the more interesting question is how it was not in minimal in raring yet?
[10:17] <cjwatson> A Recommends from adduser would be sufficient
[10:17] <xnox> that was also present in raring.
[10:18] <cjwatson> one moment
[10:18] <xnox> 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] <cjwatson> adduser wasn't in minimal in raring for some reason
[10:19] <cjwatson> Ah, it was in required, which is really where it belongs IMO
[10:19] <cjwatson> But required doesn't follow Recommends
[10:19] <cjwatson> So I guess something in required dropped a Depends: adduser
[10:20] <cjwatson> Well, I dunno, adduser in minimal vs. required is OK actually
[10:20] <pitti> xnox: my gut feeling is that adduser should only suggest ecryptfs-utils
[10:20] <cjwatson> TBH this is basically that the Recommends was incorrectly not noticed in raring
[10:20] <cjwatson> So I'd say adduser should be left where it is and drop the Recommends to Suggests
[10:22] <xnox> ack. will upload.
[10:22] <cjwatson> (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] <pitti>  xnox: спасибо!
[10:27] <Koterpillar> 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] <xnox> 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] <xnox> =)
[10:31] <pitti> fun -- making things bigger by *dropping* dependencies..
[10:31] <pitti> TGIF!
[10:36] <apw> xnox, heh :)  pitti TGFT
[10:37] <apw> xnox, fixable without adding spagetti to the seeds ?
[10:37] <xnox> 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] <apw> heh yeah, it is a bit of a scarey thought all told
[10:39] <pitti> well, there's always useradd, for really mini-minimal systems
[10:39] <apw> so i shall look at the new boot charts on monday, fingers cross
[10:39] <pitti> adduser is perl
[10:40] <pitti> (perl-base only, so you can't get rid of that anyway, but still)
[10:41] <rbasak> pitti: got time to talk about locales and postgres?
[10:41] <pitti> rbasak: sure (didn't I talk enough yet on devel@? :-) )
[10:41]  * xnox pretends to speak only ASCII based languages
[10:41] <pitti> rbasak: that's where apw's spaghetti come in
[10:41] <rbasak> pitti: I have a really long reply for you too. I was hoping to shorten it by talking on here :)
[10:42] <rbasak> pitti: I think my objection lies in postgres' postinst behaviour
[10:42] <rbasak> pitti: that if the *user* locale is bad, then the postinst's behaviour changes
[10:42] <pitti> rbasak: that it fails in an invalid locale? I can change that (as I said in my mail)
[10:42] <rbasak> 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] <pitti> i.e . go from "fails to install" to "installs, but doesn't create any cluster"
[10:43] <rbasak> 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] <pitti> 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] <rbasak> pitti: I'd like it to install *and* create a cluster by using /etc/default/locale.
[10:43] <pitti> rbasak: no, the package installation does fail if pg_createcluster fails
[10:43] <rbasak> pitti: the user's locale shouldn't matter.
[10:44] <rbasak> 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] <pitti> 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] <rbasak> 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] <pitti> rbasak: I share the feeling about inconsistency; I just don't know a good answer to it
[10:45] <rbasak> What's wrong with using /etc/default/locale if it exists, falling back to /etc/environment?
[10:45] <pitti> rbasak: in the bug report case there is no /etc/default/locale nor /etc/environment
[10:45] <rbasak> Then that solves the ssh carry through an invalid locale problem too
[10:46] <pitti> rbasak: the problem is that nothing specifies that locales must be defined in those two filese only
[10:46] <rbasak> pitti: I think the bug would still exist if there is; I'll verify.
[10:46] <rbasak> pitti: then in that case only, default to C.UTF-8 but prompt with debconf?
[10:46] <pitti> rbasak: in my experiments, if /etc/default/locale actually does set a locale, that overwrites the one ssh is passing on
[10:46] <rbasak> 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] <rbasak> For users with unusual systems, they'll be asked.
[10:47] <pitti> rbasak: I really want to avoid debconf (for various reasons, see mail); using C.UTF-8 would be acceptable then
[10:47] <rbasak> I'd be happy with C.UTF-8 with no prompting.
[10:47] <rbasak> OK
[10:47] <rbasak> 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] <pitti> then, what do we do about those people who actually want C (I got several reports there)
[10:48] <pitti> rbasak: no, as I said these are not the only files where you can set the locale
[10:48] <pitti> as the primary definition of "locale" is in terms of environment variables, there are a gazillion places to define them
[10:49] <rbasak> How about an extra fall back to the environment but iff /etc/default/locale and /etc/environment doesn't set the locale?
[10:49] <rbasak> 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] <pitti> rbasak: ^ I don't know what you mean by this
[10:50] <pitti> 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] <rbasak> Or how about a debconf prompt with low priority for those who really need an override?
[10:50] <pitti> that's exactly what leads to the curretn bug
[10:50] <pitti> those who really need to change it can just specify it at pg_createcluster
[10:50] <pitti> a debconf prompt is ridiculously expensive (given translations etc.) for such a small corner case IMHO
[10:51] <rbasak> So fall back to C.UTF-8 then.
[10:51] <pitti> rbasak: I'd actually fall back to C
[10:51] <rbasak> OK, fine.
[10:51] <rbasak> I just want /etc/default/locale used in preference to the user's environment.
[10:51] <pitti> if a server does not define any system locale, then presumably the admin actually means it; not sure?
[10:51] <rbasak> I think that'll fix the bug.
[10:51] <rbasak> I understand that you don't think it will.
[10:51] <rbasak> I will verify.
[10:51] <pitti> rbasak: but.. there IS no /e/d/locale for the bug you reported/commented on
[10:52] <pitti> the bug precisely happens on those systems which don't define a system locale
[10:52] <doko> Riddell, how stable/good is kde in saucy (wanting to do a test rebuild)
[10:52] <doko> seb128, didrocks , how stable/good is gtk/gnome in saucy (wanting to do a test rebuild)
[10:53] <Riddell> doko: pretty good, I just uploaded all of KDE SC 4.10.4 which is due to start compiling right about now
[10:53] <rbasak> pitti: I'm not sure that's the case. I believe the system I reproduced on did have /etc/default/locale set.
[10:53] <pitti> 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] <seb128> 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] <rbasak> 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] <doko> Riddell, well, if it starts compiling, then it's still in proposed?
[10:53] <Riddell> doko: yes
[10:53] <doko> so *not* ready
[10:54] <pitti> rbasak: FYI, I use "run-adt-test -sl" for those; they are cloud-image based, and perfect for quick throwaway VMs
[10:54] <pitti> (and all local)
[10:56] <rbasak> Postgres is a very special case here.
[10:56] <rbasak> Normally a locale setting doesn't cause any persistent changes to the system
[10:56] <rbasak> I don't think it's safe for the environment to specify a locale for this purpose.
[10:56] <rbasak> We should define where a system locale is defined, and use that
[10:57] <rbasak> Or use C, and require people to override template1 when they need to.
[10:57] <rbasak> Or use the locale of the user who runs createdb when he runs createdb to do it for him.
[10:57] <pitti> ^ that already happens, I think
[10:58] <rbasak> In that case, why does the postinst need to use anything but C?
[10:58] <pitti> 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] <pitti> 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] <cjwatson> 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] <rbasak> That works for me
[10:59] <pitti> cjwatson: ah, too bad
[11:00] <cjwatson> Unfortunately pam_getenv is broken, or that would be the right answer.
[11:00] <cjwatson> 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] <pitti> I've seen plenty of places which source /e/d/l, though
[11:01] <cjwatson> Might be worth seeing how hard it is to fix pam_getenv ...
[11:01] <pitti> /etc/init/mountall.conf
[11:01] <cjwatson> I wouldn't get too upset about sourcing /etc/default/locale
[11:01] <cjwatson> It might even be formally permitted, I forget
[11:01] <pitti> so mountall will fail if sourcing /etc/default/locale fails
[11:02] <pitti> I thought that was one of the reasons why it got moved out of /e/env
[11:02] <cjwatson> But the locale hasn't been written to /etc/environment for years
[11:02] <rbasak> Would it be OK to attempt to source /etc/environment, and ignore failures? Or is that unsafe too?
[11:02] <cjwatson> Yeah, could be
[11:02] <cjwatson> You have to go to considerable lengths to avoid that killing the calling shell
[11:02] <pitti> cjwatson: right, but I still think it's a legitimate place for defining it
[11:02] <cjwatson> . /etc/environment || true  <- not sufficient
[11:02] <pitti> 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] <rbasak> 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] <cjwatson> 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] <pitti> probably something like $(source /etc/environment  && locale |grep LC_CTYPE || true)
[11:04] <cjwatson> Failing that, I guess you could source in a subshell and pass out the answers you care about, or something
[11:04] <cjwatson> Yeah
[11:04] <cjwatson> But . not source
[11:04] <cjwatson> (source is a bashism)
[11:04] <pitti> and with an actually correct || true'ing (not applying that to grep), etc., but something along that lines
[11:05] <rbasak> Have we agreed with this as a solution then?
[11:06] <rbasak> I still need to check that /etc/default/locale is actually set on the use case that generated the maas bug.
[11:06] <rbasak> But I think it's reasonable to demand that it is set, even if the ssh session has a broken locale
[11:07] <rbasak> Though with pitti's solution, it'd use C without a system locale defined, right?
[11:07] <pitti> rbasak: well, in the cases where it isn't set, it would use C then
[11:07] <pitti> rbasak: right
[11:07] <rbasak> Great
[11:07] <pitti> that still leaves the broken locale for everything else, of course
[11:08] <rbasak> 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] <rbasak> Perhaps he wasn't using a cloud instance, thinking about it.
[11:08] <rbasak> So no cloud-init.
[11:08] <rbasak> I'll track that down with him.
[11:09] <rbasak> 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] <mlankhorst> infinity: yeah it will be fine
[11:12] <mlankhorst> thanks
[11:14] <pitti> rbasak: I updated bug 969462 with a summary
[11:14] <rbasak> pitti: thank you! And for sticking it out with me on this.
[11:15] <pitti> rbasak: heh, you're welcome; locales are messy :/
[11:16] <pitti> rbasak: oh, actually, package installation does not fail in that case any more; that got changed a while ago
[11:17] <pitti> sorry about that (but you wanted that behaviour anyway)
[11:17] <rbasak> Right, OK, thanks. But the maas postinst will still fail without this new behaviour, right?
[11:17] <pitti> there still wouldn't be a DB cluster to talk to, yes
[11:20] <cjwatson> 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] <didrocks> cjwatson: ah, I was waiting for still 30 minutes to see if things are wrong (now that all main promotion are done)
[11:21] <didrocks> cjwatson: uoa-integration-tests is in NEW
[11:21] <didrocks> part of my review list
[11:21] <cjwatson> Oh, it is?  Ah, I missed it
[11:21] <didrocks> python-ubuntu-platform-api? I need to look at it
[11:22] <didrocks> cjwatson: does the migration tool tells you about Main/Universe as well?
[11:22] <cjwatson> No
[11:22] <didrocks> ok, as the migration is quite complex, I hoped I didn't miss anything
[11:22] <didrocks> one sec for python-ubuntu-platform-api
[11:22] <didrocks> hope*
[11:23] <pitti> oh, I thought we were moving away from python
[11:23] <pitti> ah, for tests?
[11:23] <didrocks> pitti: probably for those
[11:24] <didrocks> cjwatson: argh ok, autopilot-touch
[11:25] <cjwatson> Right
[11:26] <pitti> didrocks: btw, this was a nice read! https://launchpad.net/ubuntu/+source/autopilot-gtk/1.3daily13.06.05-0ubuntu1
[11:26] <didrocks> pitti: heh, glad you like it :)
[11:26] <pitti> didrocks: does uploading the package auto-close the upstream bugs, OOI?
[11:26] <didrocks> 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] <didrocks> pitti: no, long debate, nobody agrees, even between the different upstreams
[11:27] <pitti> didrocks: autopilot-gtk doesn't have any ubuntu bugs, but a lot of upstream ones which were addressed by that
[11:28] <didrocks> ok, for autopilot, let's do a manual upload removing the dep, we don't use autopilot-touch in the distro anyway
[11:28] <didrocks> (downgrading to suggests)
[11:30]  * cjwatson clears the broken lplib cache that'd broken component-mismatches
[11:31] <didrocks> cjwatson: for daily release, I'm using a separate cache per process
[11:32] <didrocks> only way to not have this issue
[11:32] <didrocks> (that I found)
[11:32] <cjwatson> I'm using separate caches for a lot of things but not quite everything :-/
[11:33] <wgrant> I thought that fix was SRUed recently.
[11:34] <cjwatson> I don't see it in python-launchpadlib/+changelog
[11:34] <cjwatson> I think I asked for it ...
[11:34] <didrocks> cjwatson: it's in lars.restful IIRC
[11:35] <cjwatson> oh, python-lazr.restfulclient
[11:35] <wgrant> lazr.restfulclient probably
[11:35] <cjwatson> Apparently not to precise though
[11:35] <wgrant> Ah
[11:36] <cjwatson> bug 459418
[11:36] <cjwatson> cyphermox: ^- are you still planning on uploading that to precise?  it's been a few months
[11:37] <cjwatson> and you could help make our archive reports more robust :)
[11:37] <didrocks> and less emails because of the script being broken \o/
[11:43] <rbasak> 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] <cjwatson> rbasak: Go for it
[11:45] <cjwatson> I agree that wants to be out a level
[11:48] <rbasak> Done. Sorry, just realised after I hit submit that I left the changelog blank :-/
[11:53] <cjwatson> *shrug*
[11:56] <seb128> cjwatson, hey, is there a component mismatch report for packages in proposed?
[11:56] <cjwatson> seb128: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[11:56] <cjwatson> (thanks to Ursinha)
[11:56] <seb128> cjwatson, ah, nice, thanks
[11:57] <cjwatson> it's an hour or two out of date for reasons discussed above - should update at the next publisher cycle
[11:57] <seb128> k
[12:20] <Yud_Zroc> Is there a compiling guide for ubuntu?
[12:33] <didrocks> cjwatson: thanks for the pocketsphinx upload :) I asked sil2100 to disable the powerpc tests and he was working on that this morning
[12:33] <didrocks> sil2100: stop, not needed anymore :)
[12:34] <sil2100> Ah, ok ;)
[12:34] <sil2100> Well, it was just a quick fix anyway
[12:35] <cjwatson> Heh, yeah, was just trying to clear a bit of component-mismatches
[12:35] <cjwatson> And the sight of python-support offends me :)
[12:35] <didrocks> cjwatson: does the migration to the main release pocket still don't retain the components in main?
[12:36] <didrocks> ahah :)
[12:36] <cjwatson> I don't understand the question
[12:36] <didrocks> (I'm seeing the scopes in universe, I'm sure I NEWed them in main)
[12:36] <didrocks> like https://launchpad.net/ubuntu/+source/unity-scope-devhelp
[12:36] <cjwatson> There may be some LP bugs there
[12:36] <didrocks> ok
[12:36] <didrocks> I'll repromote them then
[12:37] <cjwatson> https://launchpad.net/ubuntu/+source/unity-scope-devhelp/+publishinghistory definitely suggests a bug
[12:37] <didrocks> no worry, it's a good "end of crazy week" monkey work I can do :p
[12:38] <cjwatson> Probably YA stupid ancestry bug
[12:46] <wgrant> cjwatson, didrocks: Copies don't do binary overrides
[12:46] <wgrant> Well, they respect existing ancestry, but you can't specify overrides
[12:46] <wgrant> Only for sources :/
[12:47] <didrocks> wgrant: ah, ok, makes sense then :)
[12:47] <didrocks> thanks for the explanation
[12:48] <cjwatson> wgrant: But even the source was copied from proposed/main to release/universe
[12:49] <wgrant> cjwatson: But the copy to -release was a cross-suite ancestry lookup
[12:49] <wgrant> I don't think that works in many cases.
[12:49] <wgrant> Hmm
[12:49] <wgrant> But you're right about the source
[12:49] <wgrant> So it's not binary-specific
[12:50] <wgrant> Blargh.
[12:50] <cyphermox> cjwatson: yes, I'll upload in a minute
[12:52] <cjwatson> cyphermox: Great, thanks
[12:52] <cyphermox> done, it will be in the queue
[12:53] <cyphermox> has anyone besides me tried the packages?
[12:53] <cyphermox> seems to work properly here, but maybe I'm not testing it right
[12:54] <cjwatson> I think bits of the reports on lillypilly run with a similar local patch
[12:54] <cjwatson> Just not all of them
[12:55] <cjwatson> It might be worth upgrading lillypilly to a -proposed package by way of verification, once we confirm it basically works at all
[12:59] <cyphermox> ok
[13:00] <dobey> wgrant: thanks for the branch fixing
[13:12] <cjwatson> 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] <arges> 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] <cjwatson> arges: https://merges.ubuntu.com/main.html
[13:14] <cjwatson> 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] <cjwatson> But we default to assuming that the person who uploaded it last will do it
[13:14] <arges> cjwatson: well i'd love to learn and don't mind doing it
[13:15] <cjwatson> arges: also https://wiki.ubuntu.com/UbuntuDevelopment/Merging, perhaps more helpful
[13:15] <arges> thanks, answered my next question
[13:16] <didrocks> 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] <xnox> 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] <arges> xnox: ok thanks
[13:18] <cjwatson> didrocks: shouldn't, from that description
[13:18] <didrocks> ok, thanks :)
[13:19] <cjwatson> platform-api will be a blocker though
[13:19]  * cjwatson moves unity-scopes-runner and the various hud binaries to main
[13:20] <cjwatson> oh, maybe somebody had done the latter already
[13:24] <arges> 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
[13:25] <xnox> arges: usually one merges from lp:debian/iptables (aka sid) or from lp:debian/experimental/iptables (if that's what needed/wanted)
[13:26] <cjwatson> You should certainly not be merging from squeeze, which is oldstable :)
[13:26] <cjwatson> Ever
[13:26] <arges> cjwatson: xnox: ok should the wiki be updated then?
[13:26] <arges> http://developer.ubuntu.com/packaging/html/udd-merging.html
[13:26] <xnox> hmm.... it's a bzr branch somewhere.
[13:26] <cjwatson> I don't think that's a wiki - but yes, that's completely wrong, merge frmo sid
[13:26] <cjwatson> *from
[13:26] <arges> i'm guessing its meant to be more of a generic guide
[13:27] <arges> ok
[13:27] <cjwatson> 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] <mterry> cjwatson, thanks for fixing the pocketsphinx build on powerpc.  I was considering disabling, but hadn't researched the failure yet
[13:38] <mterry> We have a similar problem on sphinxbase, but it also fails on i386 as well as powerpc
[13:39] <arges> cjwatson: do i need to be filing a merge bug before working on this btw?
[13:39] <cjwatson> 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] <cjwatson> arges: no
[13:40] <arges> ack
[13:40] <cjwatson> arges: you're touched-it-last, it's yours by default
[13:40] <cjwatson> merge bugs are weird things anyway imo :)
[13:41] <arges> 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] <arges> the versions match what the merge tool did btw
[13:43] <stgraber> 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] <stgraber> (1.4.18 introduces IPv6 NAT which I need to provide easy IPv6 to containers and VMs)
[13:43] <cjwatson> you shouldn't necessarily expect bzr and MoM to produce the same results; you're meant to use judgement
[13:43] <arges> ok
[13:44] <cjwatson> they're differently smart in different ways
[13:44] <cjwatson> for the most part MoM is likely to be cruder
[13:45] <xnox> mterry: hello, I had a ping from you yesterday but i was gone, and then you were gone. What's up?
[13:45] <mterry> xnox, hi~
[13:49] <pitti> oh, hud now pulling in the voxforge stuff?
[13:49] <pitti> are we getting speech recognition into the desktop now?
[13:50] <pitti> (just seen the new universe → main mail)
[13:50] <pitti> didrocks: ^ FYI, this will block propagation, in case you aren't aware
[13:51] <pitti> so we all need to become much more careful what we yell at our #$#@)*# machines during debugging -- it might land right in the amazon online search!
[13:51] <pitti> (I'm more scared that it might actually find something)
[13:52] <cjwatson> pitti: component mismatches don't block propagation to release
[13:52] <xnox> cjwatson: but the iso will fail to build?!
[13:52] <pitti> cjwatson: uh?
[13:52] <pitti> cjwatson: it should, though, as it will make hud uninstallable?
[13:52] <cjwatson> xnox: didrocks and I established they won't
[13:52] <cjwatson> pitti: it's just a recommends
[13:52] <pitti> aah
[13:53] <xnox> pitti: well there is no such concept in debian, hence britney doesn't have such feature... yet.
[13:53] <cjwatson> furthermore educating britney about components would be hard so I haven't :)
[13:53] <cjwatson> it's a rare-ish problem anyway
[13:54] <pitti> i. e. we rely on "the daily iso doesn't build" indicator to revert cases which break stuff in a major way
[13:54] <pitti> xnox: Debian has a policy that main packages mustn't depend on contrib or non-free; isn't that exactly the same thing?
[13:55] <cjwatson> pitti: with the exception of platform-api, I believe it's all sorted
[13:55] <tjaalton> what's up with llvm-3.2?
[13:55] <pitti> nice
[13:55] <cjwatson> pitti: they do, but britney doesn't enforce it
[13:55] <pitti> cjwatson: ah, good to know; I (dangerously) assumed it would
[13:55] <pitti> thanks
[13:55] <tjaalton> mesa ftbfs due to " llvm-3.2-dev : Depends: llvm-3.2 (= 1:3.2repack-7) but it is not going to be installed"
[13:55] <cjwatson> tjaalton: new llvm-toolchain-3.2 needs clang in main.  I haven't checked what's going on there, whether it's a dropped Ubuntu patch or genuine
[13:55] <cjwatson> there's been some reorganisation there
[13:56] <tjaalton> ah, ok
[13:56] <pitti> oh, wow! seb128, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wants to demote gnome-desktop to universe at last \o/
[13:57] <seb128> pitti, \o/ (what was still using it?)
[13:57] <cjwatson> hm, maybe it's just trivial component-swapping actually
[13:57] <pitti> seb128: not sure, I just saw it; I don't often look at c-m these days
[13:57] <seb128> pitti, great in any case ;-)
[13:58] <cjwatson> tjaalton: next publisher run might sort it out
[13:58] <tjaalton> cjwatson: ok, thanks!
[14:00] <DktrKranz> pitti: is source for c-m published somewhere? I'd like to have something similar for Debian too
[14:00] <cjwatson> DktrKranz: lp:ubuntu-archive-tools.  It's very very very Ubuntu-specific though - it's reliant on germinate output
[14:00] <cjwatson> I'm not TBH sure how it would be useful for Debian
[14:00] <cjwatson> (It specifically doesn't handle free vs. non-free moves)
[14:01] <DktrKranz> ah, pity
[14:01] <cjwatson> It's just for the supported vs. not distinction
[14:01] <cjwatson> But feel free to pull something out of it if you find it useful, obv
[14:01] <DktrKranz> thanks!
[14:04] <infinity> Speaking of components.  I'm trying to sort out why julius, which is in multiverse, claims to be in the ubuntu-desktop task.
[14:05] <infinity> That doesn't seem right...
[14:06] <infinity> Oh, hud.
[14:06] <infinity> Lolz.
[14:06] <cjwatson> Recommends from julius-voxforge
[14:06] <cjwatson> Probably needs to be dropped to Suggests
[14:06] <cjwatson> Assuming julius does actually belong in multiverse
[14:07] <didrocks> yeah, we need to discuss with the touch guys
[14:08] <cjwatson> OK, seriously confused about llvm, actually.  Trying to disentangle
[14:09] <didrocks> infinity: cjwatson: no more julius for the next daily release (Monday)
[14:09] <infinity> cjwatson: Isn't it just that llvm-toolchain-3.2 replaced llvm-3.2, *and* it now pulls in clang?
[14:09] <didrocks> as it doesn't break the iso, I won't rush an upload :)
[14:09] <cjwatson> infinity: except there's something weird going on with clang vs. llvm-defaults
[14:10] <infinity> Oh, wait, it now GENERATES clang, rather than pulling it in.
[14:10] <infinity> They've merged the sources upstream, I guess.
[14:10] <cjwatson> Debian has llvm-defaults 0.17 which seems to have vanished from Ubuntu
[14:10] <infinity> That can't be a bad thing, maybe clang won't be such utter crap.
[14:11] <infinity> So, yeah, we definitely need the new llvm-defaults.
[14:11]  * cjwatson tries explicitly syncing it
[14:12] <infinity> And I think we need to suck up clang in main, cause splitting this back out will probably be more effort than it's worth...
[14:12] <infinity> Maybe.
[14:12] <infinity> Well, at least libclang.
[14:12] <infinity> We might be able to keep the compiler frontend out.
[14:13] <xnox> smoser: Hello, you around? =)
[14:14] <cjwatson> Ah, auto-sync wouldn't have wanted to sync it because clang was modified in Ubuntu
[14:14] <cjwatson> Of course
[14:14] <cjwatson> infinity: Did you ever check over the llvm-3.2 / clang Ubuntu deltas to see if anything needs forward-porting?
[14:14] <infinity> cjwatson: I haven't yet, I should do today.
[14:14] <cjwatson> If you could, that would spook me less, yeah
[14:14]  * infinity nods.
[14:15] <infinity> This whole thing took me rather by surprise, I assume llvm-thingee got autosynced and blew up our carefully-crafted house of cards.
[14:15] <infinity> If we still have patches, they're probably one or two tiny ones I can forward-port and forward.
[14:15] <infinity> Will check after I've rebooted, filed a kernel bug, and had breakfast.
[14:16] <cjwatson> No, it didn't get auto-synced.  Sylvestre filed a sponsorship request or similar and dholbach processed it.
[14:16] <cjwatson> auto-sync was rightly holding off until somebody had a chance to manually resolve the whole stack.
[14:17] <cjwatson> So it's possible we've actually synced a version with the wrong vendor ID, missing support for saucy, and such.
[14:17] <cjwatson> Depending on how clever the latest source is.
[14:19] <pitti> didrocks: reading your "landed" mail, congratulations! that was a big chunk
[14:19] <didrocks> thanks pitti! Happy it's done :)
[14:19] <pitti> didrocks: and nice timing on a Friday afternoon :)
[14:19] <didrocks> isn't it? :)
[14:20]  * pitti resists the temptation to upgrade now, otherwise I'll spend my Saturday fixing my machine
[14:20] <pitti> j/k
[14:21] <xnox> pitti: you are _not_ running saucy?
[14:21] <infinity> Clearly, I should never have rebooted.
[14:21] <infinity> Now compiz is segfaulting on every run.
[14:21] <infinity> \o/
[14:21] <pitti> xnox: of course I do, but I only upgrade in the mornings usually
[14:22] <xnox> pitti: I see.
[14:22] <pitti> xnox: I don't have a raring machine :)
[14:22] <pitti> in fact, it seems I don't even have a raring schroot yet; must be less than three months, i. e. I didn't yet have to do a postgresql update for stables
[14:22] <infinity> Mirv: Did anyone every get a chance to look into that compiz-versus-glib segv?
[14:22] <xnox> pitti: my irc-proxy was upgraded to raring this week. Not sure if I should go for saucy or not.
[14:22] <cjwatson> I think gtk+3.0 needs a rebuild against new wayland ...
[14:22] <infinity> Mirv: It's driving me batty.
[14:23] <cjwatson> mesa too
[14:23] <Laney> cjwatson: seb128 is doing it
[14:23] <Laney> well, gtk, don't know about mesa
[14:24] <barry> yikes, how dead is the latest compiz?
[14:24] <infinity> Oh, I thought that was Colin's impression of Jar Jar.
[14:24] <cjwatson> ok, long as somebody's on it, it makes p-m output giant
[14:24] <infinity> barry: It hatses me.
[14:24] <cjwatson> infinity: that's the segfault-for-fun-and-profit thing?
[14:24] <barry> infinity: it is teh crashez
[14:24] <infinity> cjwatson: Neither fun nor profit.
[14:25] <cjwatson> I've had 'unity --replace &' running on tty1 for a while ...
[14:25] <infinity> cjwatson: Considering high velocity introcution of laptop to wall.
[14:25] <infinity> introduction*
[14:25] <cjwatson> Well, DISPLAY=:0 that, but
[14:25] <infinity> Well, I win some sort of prize for this.
[14:25] <infinity> I now have a classic X cursor on my tty1.
[14:25] <barry> one small silver lining is that the nsa is now being deluged by crash reports
[14:26] <cjwatson> infinity: ha
[14:26] <infinity> kms, you make me giggle.
[14:26] <Laney> so I shouldn't hit go on this dist-upgrade then?
[14:27] <cjwatson> xnox: thanks for merging gdcm
[14:27] <barry> Laney: only if you want to take an early weekend
[14:27] <cjwatson> Laney: compiz has been crashy for a while now ...
[14:27] <infinity> This is still the same compiz/unity from raring.
[14:27] <infinity> But every new glib update seems to make it worse. :P
[14:27] <Laney> oh, alright
[14:27] <Laney> Doesn't seem particularly bad here
[14:28] <barry> hmm, both my saucy desktops are totally useless now
[14:28] <seb128> segfaults should be fixed in today's version
[14:28] <infinity> I seriously can't get it to log me in now...
[14:28] <cjwatson> Laney: I think the pattern is glib cleans up memory leaks => things that failed to increment refcounts properly died
[14:28] <infinity> Maybe a by-hand run will work for now.
[14:28] <xnox> cjwatson: no problem, retried insighttoolkit4 as well.
[14:28] <cjwatson> xnox: I noticed, thanks
[14:29] <infinity> Nope.
[14:29] <infinity> *sigh*
[14:29] <cjwatson> seb128: I hope so :)
[14:29] <infinity> seb128: When can I haz this version?
[14:29] <Laney> gdcm actually got fixed?
[14:29] <seb128> infinity, it's in saucy ?
[14:29] <infinity> seb128: I literally can't log in anymore.
[14:29] <cjwatson> Laney: apparently
[14:29] <seb128> infinity, since when ?
[14:29] <Laney> wowzers
[14:29] <smoser> xnox, here.
[14:29] <infinity> seb128: Wait, today's version of what?
[14:29] <barry> seb128: nope. i *just* dist-upgraded and compiz is completely useless
[14:29] <smoser> i 'never minded' my ping of you yesterday
[14:30] <seb128> infinity, unity; sorry I didn't follow the backlog
[14:30] <seb128> barry, backtrace?
[14:30] <infinity> I got no new unity today.  Has it made it out of proposed?
[14:30] <infinity> Oh, hah, it must have JUST promoted.
[14:30] <infinity> barry: Try again?
[14:30] <barry> seb128: yeah, i'm trying to get a bug report filed, but have to do it remotely
[14:31] <jbicha> infinity: I have the new Unity; it just won't run here :(
[14:31] <infinity> Oh joy, I get a bunch of new scopes forced on me.
[14:31] <barry> infinity: trying...
[14:31] <infinity> Oh, just recommends.
[14:32] <seb128> was any package let on hold of the upgrade or removed?
[14:32] <jbicha> infinity: but no unity-lens-shopping; see, Ubuntu does listen to its users ;)
[14:32] <seb128> can pastebin your dpkg.log?
[14:32] <infinity> jbicha: Heh.
[14:33] <Laney> hah, yeah, compiz segfaulted immediately after the upgrade
[14:33] <Laney> seems to have respawned itself alright though
[14:33] <xnox> smoser: oh. ok. What was it though? Anyway, I'd wanted to say that I did cherry-pick all relevant fixes, and the delta as part of last upload is what we are planning to SRU into Raring to fix all of issues with forgotten events.
[14:33] <jbicha> seb128: the only removals were appmenu-gtk, appmenu-gtk3, and the shopping lens
[14:33] <xnox> smoser: we hope it's sufficient for cloud-init case. Ideally one would still need to refresh raring images, after sru is published, given the caveats outlined in the bug report.
[14:33] <seb128> jbicha, nothing on old?
[14:33] <seb128> hold
[14:34] <jbicha> no
[14:34] <seb128> can you get a stacktrace?
[14:34]  * barry has the same experience as jbicha 
[14:34] <xnox> smoser: do you have any questions about upstart fixes? or you still need to try them first?
[14:34] <smoser> xnox, well i haven't tried them.
[14:34] <smoser> but the reproduce case was pretty straigt forward.
[14:35] <smoser> my ping was complaining about not restarting
[14:35] <jbicha> my ~/.xsession-errors or ~/.cache/gdm/session.log doesn't seem to have any useful info
[14:35] <xnox> smoser: ack. jodh is on holiday, feel free to ping me if anything comes up.
[14:35] <smoser> (on upgrade)
[14:35] <smoser> i guess you're only doing that if its the old version though.
[14:35] <smoser> which is sane.
[14:35] <smoser> and wont really be a problem.
[14:35] <smoser> the images will get refresshed and have this new udev in thm and then that will be that.
[14:36] <xnox> smoser: well, it will restart on upgrade, if the upgrade is done at runlevel 2. If one is in early boot, the upgrade will not restart. (e.g. not yet fully initialised cloud-init instance)
[14:36] <smoser> er.. s/udev/upstart/
[14:36] <seb128> jbicha, what if you run unity from a vt?
[14:37] <barry> infinity, jbicha, seb128 good news.  another dist-upgrade and my desktop is happy again
[14:37] <smoser> xnox, yeah, i had thought you could restart after reaching runlevel 2 in that case.
[14:37] <smoser> but that adds complexity
[14:37] <xnox> smoser: we could hint that reboot is required instead if the upgrade was done in early boot, but I remember you said you don't want to reboot.
[14:37] <smoser> ie, youcould add a job that would run on rc 2 and then it would delete itself.
[14:37] <smoser> right. you could mark the 'reboot-required'
[14:37] <infinity> Huzzah, I'm in a unity session!
[14:37] <smoser> it would seem that you probably should mark that, dont you think?
[14:37] <smoser> as a reboot *is* required.
[14:38] <seb128> barry, cool
[14:38] <xnox> smoser: reaching runlevel 2 is outside of dpkg control, so I'd rather not have ethermal jobs to do that. pitti was also asking for "ethermal" configuration location e.g. /run/init/
[14:38] <pitti> ("ephemeral"?)
[14:38] <smoser> :)
[14:38] <xnox> smoser: yeah, we should mark reboot-required. I'm now not sure why in the end we didn't add it in. I'll check my notes from the sprint.
[14:39] <smoser> but ethermal sounds good too
[14:39] <xnox> pitti: smoser: yes =) my big words should usually be filtered through fuzzy match by context.
[14:39] <smoser> xnox, all in all, i think its sufficient, and soon enough we'll have fully owrking images.
[14:40] <xnox> true.
[14:40] <mlankhorst> soon we'll have eternal configuration locations
[14:40] <smoser> i have to remove the work around in cloud-init also. as to avoid breakage, it does not reload-configuration after writing an upstart job
[14:40] <smoser> (that is required for the case where /etc is overlayfs or some other non-inotify friendly fs)
[14:40] <smoser> and wasn't supposed to hurt anything :)
[14:41] <xnox> =)))) true.
[14:42] <infinity> Aww, crap.  I must have closed firefox twice in a row at some point and lost my several-hundred-tab session.
[14:42] <xnox> smoser: to be honest, I'm of an opinion reload-configuration should live in upstart-file-bridge or upstart itself. E.g. one puts inotify watch on '/' which will get a create event, as soon as anything is written on to overlayfs top level dir, and if it happens to be a "create /etc folder" we should reload.
[14:42] <seb128> jbicha, does another dist-upgrade fix it for you like for barry?
[14:42] <infinity> Grr.
[14:42] <infinity> I blame compiz.
[14:42] <Laney> Ahh, mesa is caught up with llvm
[14:42] <cjwatson> infinity: might still be in one of the sessionstore.* files in your profile
[14:42] <Laney> So I guess wayland is stuck until then
[14:42] <infinity> seb128: I seem to be back in business after another dist-upgrade but, then again, I'd been able to run it in the past too, so I dunno.
[14:43] <infinity> cjwatson: Timestamps and sizes on those don't look promising.
[14:43] <infinity> Yeah, I think it's lost for good.
[14:43] <seb128> infinity, if you have an issue please try to get a backtrace, or ping me and I will help to get debug infos
[14:44] <cjwatson> infinity: backups?
[14:44] <smoser> xnox, i'm confused. i what is different currently than what you're saying ?
[14:44] <smoser> oh. i see.
[14:45]  * Laney restarts session with some trepidation
[14:46] <xnox> smoser: upstart should be resiliant against hostile fs, instead of cloud-init lending a helping hand ;-)
[14:46] <infinity> cjwatson: I don't backup that frequently.  I'm sure I'll live with a fresh firefox start.
[14:46] <infinity> cjwatson: Those tabs just end up being a depressingly long TODO-that-never-gets-TODONE anyway.
[14:47] <infinity> seb128: If it explodes again, I'll be sure to yell.
[14:47] <cjwatson> My backups sucked until I made it a daily cron job.
[14:47] <cjwatson> Although I do need to get a secondary backup disk again.
[14:47] <infinity> cjwatson: My laptop isn't really all that critical to me, which is why I don't backup often.
[14:48] <infinity> cjwatson: Other than PGP and SSH keys, the rest of this data is meaningless to me.
[14:48] <infinity> And those don't change often. :P
[14:49] <cjwatson> It's more minimal-hassle-of-recovery than meaningfulness for me, I think.
[14:50]  * xnox wiped openssh-server keys of my machine the other day..... happens. couldn't be bothered to restore from backup. plus got a new shiny ecdsa key.
[14:50] <barry> doko: ping
[14:52] <doko> barry, ?
[14:53] <barry> doko: hi.  i want to work on sru'ing lp: #1058884 today.  just wanted to check with you so i don't step on your toes if you're planning anything else
[14:54] <doko> barry, there are still some packages in proposed, I think. but I would have to recheck
[14:56] <barry> doko: i saw that proposed is a bit ahead.  would you rather i wait until they clear or should i just go ahead and backfill them?  (fwiw the bzr branches should be current w/the proposed backlog)
[14:56] <bdmurray> cjwatson: could you have a look at bug 1187233?
[14:57] <cjwatson> bdmurray: I punted that over to shim since it doesn't seem to be a GRUB problem; if slangasek has a chance to look, he knows rather more about shim than I do
[14:57] <cjwatson> (It's reminiscent of the problem stgraber reported just before the last physical UDS, FWIW)
[14:58] <cjwatson> Might just be an our-shim-is-too-old problem
[14:58] <doko> barry, weill, you can add the patch on top, but make sure to correctly generate the changelog
[14:59] <infinity> xnox: I don't care about host keys at all, but losing ssh user IDs is a pain, I do keep those in more than one place.
[14:59] <barry> doko: will do, thanks
[14:59] <jbicha> Unity is working now here but I'm not sure what changed :|
[14:59] <bdmurray> cjwatson: okay, thanks
[15:06] <infinity> Aww, crap.
[15:06] <infinity> seb128: Remember when I lost detached menus in some applications but not others?
[15:06] <infinity> seb128: Do you remember why that was?
[15:06] <infinity> seb128: Cause it's back. :)
[15:06] <seb128> infinity, no
[15:06] <infinity> Oh.
[15:06] <infinity> Poo.
[15:07]  * infinity tries to remember WTF caused that.
[15:08] <infinity> seb128: Ahh, the upgrade installed unity-gtk2-module unity-gtk3-module, which removed appmenu-gtk appmenu-gtk3
[15:08] <infinity> seb128: Was that intentional?
[15:08] <seb128> infinity, yes
[15:08] <seb128> infinity, did you restart your session?
[15:08] <infinity> seb128: Kay, well.  I no longer have global menus in pidgin.
[15:09] <infinity> seb128: I rebooted after the upgrade, so yes.
[15:09] <seb128> infinity, do you have unity-gtk2-module?
[15:09] <seb128> oh yes, you said that
[15:09] <seb128> infinity, I'm about to do an upload of gtk2/gtk3, let me know if those fix your issue
[15:09] <infinity> seb128: Mmkay.
[15:10] <pitti> wow, dist-upgrade will use 48.5 MB additional space
[15:10] <infinity> pitti: All the new lenses?
[15:11] <pitti> infinity: yeah, and the voxforge stuff presumably is quite heavy
[15:11] <infinity> I admit, I dist-upgraded with --no-install-recommends
[15:11] <pitti> yeah, I'm pondering that
[15:11] <infinity> pitti: Which would also cull out voxforge stuff.
[15:12] <pitti> infinity: cf. my statement above about yelling crap at my computer during debugging, and then finding amazon search results for that in the dash..
[15:12] <infinity> pitti: Hahaha.
[15:13] <pitti> unity-scope-guayadeque, urgh
[15:13] <pitti> do we really need to install and run all these scopes by default?
[15:13] <pitti> I mean, how many people are going to use all those?
[15:13] <Laney> haha, that package's long description is ex-ce-llent
[15:13] <seb128> pitti, we don't run them
[15:13] <Laney>  This package contains the "guayadeque" scope which allows Unity
[15:13] <Laney>  to search for guayadeque content.
[15:13] <seb128> pitti, we activate them on demand when the server says to use them
[15:14] <pitti> infinity: ah, but even without recommends it's still +35 MB, as the sphinx/voxforge stuff is apparently required
[15:14] <seb128> it's voice stuff for the hud
[15:14] <pitti> right, I know
[15:15] <pitti> let's see how well this machine will understand me
[15:15] <pitti> seb128: est-ce qu'il peut comprendre français ? :-)
[15:15] <seb128> je ne sais pas ;-)
[15:15] <tedg> pitti, We need more data, basically for each language we need 100hrs of samples.  Unfortunately English is the only one there.
[15:16] <pitti> j/k
[15:16] <pitti> yeah, I saw, it's just -hmm-en for now
[15:16] <infinity> pitti: Curious, I was able to remove the voxforge stuff post-upgrade.
[15:16] <tedg> I figure next sprint that is in a non-English country we should sit at Starbucks for a day and get samples from people in line :-)
[15:16] <infinity> pitti: Can't be THAT required.
[15:18] <jbicha> I don't see guayadeque in the Filter Results list; I think Unity is smart enough to not show it if guayadeque isn't installed
[15:19] <pitti> Laney: yeah, seems all scopes have the exact same description with just the name changed
[15:19] <jbicha> there's a QueryBinary=guayadeque field in /usr/share/unity/scopes/music/guayadeque.scope
[15:20] <pitti> tedg: perhaps we shouldn't pull in the -en voxforge bits through direct dependencies, but through our "install language support" magic
[15:20] <pitti> tedg: (at least in teh future, when we actually do have multiple languages)
[15:21] <tedg> pitti, That would make sense to me.  We need to make HUD smarter to handle those languages, but yes.
[15:21] <tedg> pitti, I'd really like to set that up as a way that Loco's could help out.
[15:21] <tedg> pitti, Submit language data to voxforge
[15:22] <tedg> We might be able to get to 100hrs for major languages then.
[15:22] <Laney> how do I try that stuff out?
[15:25] <tedg> Laney, The voice recognition?
[15:25] <Laney> yeah
[15:25] <tedg> Laney, You can get hud tools and use the hud-gtk frontend, or else with Unity 8.
[15:26] <Laney> tedg: ** (hud-gtk:11375): ERROR **: hud-gtk.vala:139: Failed to open file 'share/hud-gtk/hud-gtk.ui': No such file or directory
[15:26] <Laney> ;-)
[15:27] <tedg> Uhg
[15:27] <tedg> cd /usr/share/hud :-)
[16:33] <Quintasan> Laney: I believe I sent you a mail asking if you would sign my new GPG key as I did a transition, do you respect those or I have to catch you on some conference?  :P
[16:34] <Laney> Probably not, sorry
[16:34] <Laney> come to debconf :-)
[16:35] <Quintasan> Laney: I see. Switzerland it is. Never been there, might attempt to get there :P
[16:36] <ogra> oh, debconf is in ch ?
[16:36] <Laney> sure is
[16:36] <ogra> hmm
[16:38] <infinity> cjwatson: So, looks like this only dropped one of our llvm-3.2 patches, the rest made it back to Debian or upstream, I believe.
[16:38] <infinity> cjwatson: Checking clang patches now.
[16:43] <cjwatson> Could be worse then
[16:52] <infinity> cjwatson: Testbuilding before upload, but it looks like this is our remaining delta: http://paste.ubuntu.com/5742432/
[16:52] <infinity> cjwatson: I need to rethink the "list every release ever" madness, and try to simplify that for upstream for all distros, it's borderline insanity.
[16:55] <cjwatson> Distro-specific version comparison would be less bad
[16:56] <cjwatson> infinity: BTW your changelog is wrong, s/Raring/Saucy/
[16:56] <infinity> cjwatson: Picky, picky.
[16:56] <infinity> cjwatson: The queue would have told me ALL about that. :)
[16:57] <infinity> cjwatson: It would have said "dude, that's in unapproved", and I would have jumped on #launchpad-ops and screamed "WHO FROZE MY ARCHIVE?!" and then felt like a right git when I realized I just can't read.
[16:57] <infinity> cjwatson: Oh.  You mean the description of the patch, not the upload target.
[16:57] <infinity> cjwatson: La la la.
[16:59] <cjwatson> I did :)
[17:00] <infinity> cjwatson: That's okay, it was wrong in the patch header too.
[17:00] <cjwatson> Capitalisation hint and all.
[17:00] <infinity> cjwatson: I suspect I cargo-culted it from the last time I'd done the same thing. :P
[17:01]  * infinity wonders what the ratio of cargo-culting programmers to historical cargo-cultists is.
[17:02] <cjwatson> I hardly ever even write new changelog entries when I can copy-and-paste the last similar one I wrote
[17:40] <menace> is there any point in removing all read-privileges for /etc/sysctl.conf or /etc/syslog.conf in terms of security in an standard installation? just stumbled over that in a installation procedure...
[17:41] <sarnold> menace: won't a user still be able to dump all the settings via sysctl -a ?
[17:41] <sarnold> .. or read values out of /proc ?
[17:57] <arges> jdstrand: hi
[17:58] <sarnold> arges: he's out-of-office this week..
[17:58] <arges> sarnold: ah... was going to have him review my iptables merge
[17:58] <arges> i'll ping him next week then
[17:58] <sarnold> arges: okay :)
[18:01] <slangasek> pitti: hey, have you seen bug #1181810 on upower, and do you have any idea what might be causing it?
[18:01] <slangasek> pitti: I'm not sure if it could be related to the changes made to acpi-support
[18:02] <slangasek> (though probably not, I guess, since there's now nothing in acpi-support which handles lid close events)
[18:03] <josepht> slangasek: that looks like a dupe of bug 1180513
[18:03] <slangasek> josepht: ah, ok
[18:04] <slangasek> josepht: thanks for the pointer, that does indeed look like the same issue - and I see I was pinging the right person, as pitti assigned the bug to himself ;)
[18:10] <arges> cjwatson: so i did a iptables merge that installs, runs. whats the best way to post it so that others can review? I could not get the bzr merges working properly, so I used the grab-merge.sh script.
[18:16] <infinity> doko: Can you avoid retrying the armel gcc-4.8 build in toolchain-r after I kill it?  It seems to be taking out pandas left and right.
[18:21] <slangasek> armel?
[18:22] <infinity> slangasek: quantal.
[18:22] <slangasek> hmph :)
[18:33] <kees> sarnold: not all of them, actually.
[18:34] <kees> $ ls -la /proc/sys/fs/*prot*
[18:34] <kees> -rw------- 1 root root 0 Jun  7 11:33 /proc/sys/fs/protected_hardlinks
[18:34] <kees> -rw------- 1 root root 0 Jun  7 11:33 /proc/sys/fs/protected_symlinks
[18:34] <kees> an attacker has to trip the warning to find out if they're set ...
[18:34] <kees> so, it's an interesting point about /etc/sysctl.*
[18:34] <kees> though it's no secret what a distro's settings are.
[18:39] <lifeless> kees: zomg people know what we build our binaries with?
[18:46] <Mirv> infinity: I believe you should have gotten the fix around ~now with today's updates
[18:47] <infinity> Mirv: Indeed, I seem to be more stable now.
[18:47] <infinity> Mirv: Fingers crossed.
[18:58] <kees> lifeless: they do indeed! :)
[19:01] <sarnold> kees: oh, neat :) I've not noticed the tripwarning before :) hehe
[19:02] <kees> sarnold: yeah, if you trigger the link protections, and audit notice is generated
[22:57] <cjwatson> arges: best thing to post is a debdiff from current Debian
[23:11] <bdmurray> slangasek: could you have a look at bug 1187233?
[23:12] <slangasek> bdmurray: well, I suppose I'll need to, yes; this isn't going to be a bug we can fix quickly, there's minimal debugging capabilities here
[23:12] <slangasek> more precisely, getting a debug build of shim will require fiddling the secureboot settings in ways that may prevent the problem from being reproducible anyway... but I'll see what I can do - next week
[23:13] <bdmurray> slangasek: okay, sounds good.
[23:24] <cjwatson> pitti: Please stop dropping the devpts mount from the d-i udev startup script; /usr/share/initramfs-tools/init is not used for d-i
[23:24] <cjwatson> pitti: I'm putting it back to unbreak the server images
[23:26] <cjwatson> (debian/extra/udev.startup is used nowhere else than d-i)