xnox | smoser: yes?! | 00:05 |
---|---|---|
slangasek | infinity: it hasn't been in the same publisher cycle; if you want to smack it again with change-overrides, go ahead | 00:15 |
=== _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 | ||
pitti | Good morning | 04:37 |
pitti | wgrant: hey William, how are you? | 04:52 |
pitti | wgrant: who should I ask to enable saucy translations in launchpad? | 04:53 |
wgrant | Hm, we didn't already do that? | 04:53 |
wgrant | Maybe we didn't. | 04:54 |
wgrant | Let's see if I can remember how. | 04:54 |
* 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:56 |
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:58 |
StevenK | We're not building langpacks, because that happens later, I think | 04:59 |
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:00 |
wgrant | The plan was to have langpacks from the start, AIUI, but that didn't actually happen | 05:01 |
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:03 |
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:04 |
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:15 |
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:16 |
versable | local* | 05:17 |
infinity | versable: Missing build-dep on libwebkitgtk-dev, I'd assume. | 05:17 |
infinity | Oh, wait, wrong webkit. | 05:17 |
infinity | libwebkitgtk-3.0-dev | 05:18 |
versable | infinity: Right, that's probably it. Thanks. | 05:18 |
dholbach | good morning | 06:19 |
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:05 |
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:06 |
mlankhorst | sure I'll do that too | 07:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
* infinity rebuilds again. | 07:13 | |
mlankhorst | -e "s/--enable-xselinux/--disable-xselinux/" \ | 07:13 |
infinity | Should do. It passed confugre with that, at least. | 07:14 |
* infinity waits for it to, like, build. | 07:14 | |
mlankhorst | ok I'll bbl, weather is really nice so it's a crime not to bike :) | 07:19 |
infinity | mlankhorst: Heh. Enjoy. I'll just upload this as precise2, and if you ever have to respin, your scripts will DTRT? | 07:20 |
infinity | mlankhorst: http://paste.ubuntu.com/5741156/ <-- My debdiff, so you can check and see if your script produces the same change. | 07:22 |
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:05 |
smb | It required this to be in a smaller quantity of updates for me to notice. :-P | 08:06 |
smb | Thanks for the explanation | 08:07 |
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:35 |
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:36 |
xnox | ecryptfs does encrypted swap for a few releases now (not sure when it started) | 08:37 |
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:38 |
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:39 |
pitti | yes, sure; ecryptfs and cryptswap just came to my mind as possible things which might have changed | 08:40 |
=== doko_ is now known as doko | ||
xnox | 20130521 saucy daily correctly removes cryptsetup & ecryptfs-tools in a default install, whilst 20130523 and later do not. | 09:34 |
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:45 |
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:46 |
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:47 |
xnox | but versions of adduser, ecryptfs-utils nor crypsetup have not changed since raring yet. | 09:52 |
pitti | hm; I don't see how cryptsetup would not have been in minimal in raring then | 09:53 |
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:54 |
om26er | i have a local repository, how can I increase its priority ? | 09:55 |
om26er | not sure what to put infront of "pin:" in the .pref file | 09:56 |
xnox | om26er: https://help.ubuntu.com/community/PinningHowto but please note if the packages have identical version number, the "first" repository wins. | 09:58 |
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/ ? | 09:59 |
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:00 |
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:03 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:22 |
pitti | xnox: спасибо! | 10:23 |
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:27 |
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:30 |
pitti | fun -- making things bigger by *dropping* dependencies.. | 10:31 |
pitti | TGIF! | 10:31 |
apw | xnox, heh :) pitti TGFT | 10:36 |
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:37 |
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:39 |
pitti | (perl-base only, so you can't get rid of that anyway, but still) | 10:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
pitti | rbasak: FYI, I use "run-adt-test -sl" for those; they are cloud-image based, and perfect for quick throwaway VMs | 10:54 |
=== Guest86601 is now known as zumbi | ||
pitti | (and all local) | 10:54 |
=== zumbi is now known as Guest22269 | ||
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:56 |
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:57 |
rbasak | In that case, why does the postinst need to use anything but C? | 10:58 |
=== Guest22269 is now known as zumbi_ | ||
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:58 |
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 | 10:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
rbasak | Have we agreed with this as a solution then? | 11:05 |
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:06 |
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:07 |
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:08 |
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:09 |
mlankhorst | infinity: yeah it will be fine | 11:12 |
mlankhorst | thanks | 11:12 |
pitti | rbasak: I updated bug 969462 with a summary | 11:14 |
ubottu | 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 |
rbasak | pitti: thank you! And for sticking it out with me on this. | 11:14 |
pitti | rbasak: heh, you're welcome; locales are messy :/ | 11:15 |
pitti | rbasak: oh, actually, package installation does not fail in that case any more; that got changed a while ago | 11:16 |
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:17 |
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:20 |
* 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:21 |
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:22 |
pitti | oh, I thought we were moving away from python | 11:23 |
pitti | ah, for tests? | 11:23 |
didrocks | pitti: probably for those | 11:23 |
=== schmidtm_ is now known as schmidtm | ||
didrocks | cjwatson: argh ok, autopilot-touch | 11:24 |
cjwatson | Right | 11:25 |
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:26 |
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:27 |
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:28 |
* cjwatson clears the broken lplib cache that'd broken component-mismatches | 11:30 | |
=== MacSlow is now known as MacSlow|lunch | ||
didrocks | cjwatson: for daily release, I'm using a separate cache per process | 11:31 |
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:32 |
wgrant | I thought that fix was SRUed recently. | 11:33 |
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:34 |
cjwatson | oh, python-lazr.restfulclient | 11:35 |
wgrant | lazr.restfulclient probably | 11:35 |
cjwatson | Apparently not to precise though | 11:35 |
wgrant | Ah | 11:35 |
cjwatson | bug 459418 | 11:36 |
ubottu | 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 |
cjwatson | cyphermox: ^- are you still planning on uploading that to precise? it's been a few months | 11:36 |
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:37 |
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:43 |
cjwatson | rbasak: Go for it | 11:45 |
cjwatson | I agree that wants to be out a level | 11:45 |
rbasak | Done. Sorry, just realised after I hit submit that I left the changelog blank :-/ | 11:48 |
cjwatson | *shrug* | 11:53 |
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:56 |
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 | 11:57 |
=== cking_ is now known as cking | ||
=== _salem is now known as salem_ | ||
Yud_Zroc | Is there a compiling guide for ubuntu? | 12:20 |
=== MacSlow|lunch is now known as MacSlow | ||
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:33 |
sil2100 | Ah, ok ;) | 12:34 |
sil2100 | Well, it was just a quick fix anyway | 12:34 |
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:35 |
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:36 |
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:37 |
cjwatson | Probably YA stupid ancestry bug | 12:38 |
=== OdyX` is now known as OdyX | ||
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:46 |
didrocks | wgrant: ah, ok, makes sense then :) | 12:47 |
didrocks | thanks for the explanation | 12:47 |
cjwatson | wgrant: But even the source was copied from proposed/main to release/universe | 12:48 |
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:49 |
wgrant | Blargh. | 12:50 |
cyphermox | cjwatson: yes, I'll upload in a minute | 12:50 |
cjwatson | cyphermox: Great, thanks | 12:52 |
cyphermox | done, it will be in the queue | 12:52 |
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:53 |
cjwatson | I think bits of the reports on lillypilly run with a similar local patch | 12:54 |
cjwatson | Just not all of them | 12:54 |
cjwatson | It might be worth upgrading lillypilly to a -proposed package by way of verification, once we confirm it basically works at all | 12:55 |
=== salem_ is now known as _salem | ||
cyphermox | ok | 12:59 |
dobey | wgrant: thanks for the branch fixing | 13:00 |
=== _salem is now known as salem_ | ||
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:12 |
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:13 |
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:14 |
cjwatson | arges: also https://wiki.ubuntu.com/UbuntuDevelopment/Merging, perhaps more helpful | 13:15 |
arges | thanks, answered my next question | 13:15 |
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:16 |
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:17 |
cjwatson | didrocks: shouldn't, from that description | 13:18 |
didrocks | ok, thanks :) | 13:18 |
cjwatson | platform-api will be a blocker though | 13:19 |
* cjwatson moves unity-scopes-runner and the various hud binaries to main | 13:19 | |
cjwatson | oh, maybe somebody had done the latter already | 13:20 |
=== hggdh_ is now known as hggdh | ||
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:24 |
=== davidcalle_ is now known as davidcalle | ||
xnox | arges: usually one merges from lp:debian/iptables (aka sid) or from lp:debian/experimental/iptables (if that's what needed/wanted) | 13:25 |
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:26 |
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:27 | |
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:38 |
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:39 |
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:40 |
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:41 |
arges | the versions match what the merge tool did btw | 13:42 |
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:43 |
cjwatson | they're differently smart in different ways | 13:44 |
cjwatson | for the most part MoM is likely to be cruder | 13:44 |
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:45 |
pitti | oh, hud now pulling in the voxforge stuff? | 13:49 |
pitti | are we getting speech recognition into the desktop now? | 13:49 |
pitti | (just seen the new universe → main mail) | 13:50 |
pitti | didrocks: ^ FYI, this will block propagation, in case you aren't aware | 13:50 |
=== wedgwood_away is now known as wedgwood | ||
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
cjwatson | tjaalton: next publisher run might sort it out | 13:58 |
tjaalton | cjwatson: ok, thanks! | 13:58 |
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:00 |
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:01 |
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:04 |
infinity | That doesn't seem right... | 14:05 |
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:06 |
didrocks | yeah, we need to discuss with the touch guys | 14:07 |
cjwatson | OK, seriously confused about llvm, actually. Trying to disentangle | 14:08 |
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:09 |
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:10 |
infinity | So, yeah, we definitely need the new llvm-defaults. | 14:11 |
* cjwatson tries explicitly syncing it | 14:11 | |
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:12 |
xnox | smoser: Hello, you around? =) | 14:13 |
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:14 | |
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:15 |
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:16 |
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:17 |
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:19 |
* pitti resists the temptation to upgrade now, otherwise I'll spend my Saturday fixing my machine | 14:20 | |
pitti | j/k | 14:20 |
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:21 |
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:22 |
cjwatson | mesa too | 14:23 |
Laney | cjwatson: seb128 is doing it | 14:23 |
Laney | well, gtk, don't know about mesa | 14:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
xnox | =)))) true. | 14:41 |
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:42 |
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:43 |
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:44 |
* Laney restarts session with some trepidation | 14:45 | |
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:46 |
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:47 |
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:48 |
cjwatson | It's more minimal-hassle-of-recovery than meaningfulness for me, I think. | 14:49 |
* 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:50 |
doko | barry, ? | 14:52 |
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:53 |
ubottu | Launchpad bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [Undecided,Confirmed] https://launchpad.net/bugs/1058884 | 14:53 |
doko | barry, there are still some packages in proposed, I think. but I would have to recheck | 14:54 |
=== mmrazik is now known as mmrazik|afk | ||
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:56 |
ubottu | bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [Critical,New] https://launchpad.net/bugs/1187233 | 14:56 |
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:57 |
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:58 |
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 | 14:59 |
=== gusch is now known as gusch|away | ||
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:06 |
* infinity tries to remember WTF caused that. | 15:07 | |
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:08 |
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:09 |
pitti | wow, dist-upgrade will use 48.5 MB additional space | 15:10 |
infinity | pitti: All the new lenses? | 15:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:18 |
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:19 |
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:20 |
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:21 |
tedg | We might be able to get to 100hrs for major languages then. | 15:22 |
Laney | how do I try that stuff out? | 15:22 |
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:25 |
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:26 |
tedg | Uhg | 15:27 |
tedg | cd /usr/share/hud :-) | 15:27 |
=== gusch|away is now known as gusch | ||
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:33 |
Laney | Probably not, sorry | 16:34 |
Laney | come to debconf :-) | 16:34 |
Quintasan | Laney: I see. Switzerland it is. Never been there, might attempt to get there :P | 16:35 |
ogra | oh, debconf is in ch ? | 16:36 |
Laney | sure is | 16:36 |
ogra | hmm | 16:36 |
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:38 |
=== plars is now known as plars-afk | ||
cjwatson | Could be worse then | 16:43 |
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:52 |
cjwatson | Distro-specific version comparison would be less bad | 16:55 |
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:56 |
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:57 |
cjwatson | I did :) | 16:59 |
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:00 |
* infinity wonders what the ratio of cargo-culting programmers to historical cargo-cultists is. | 17:01 | |
cjwatson | I hardly ever even write new changelog entries when I can copy-and-paste the last similar one I wrote | 17:02 |
=== plars-afk is now known as plars | ||
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:40 |
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:41 |
arges | jdstrand: hi | 17:57 |
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 :) | 17:58 |
slangasek | pitti: hey, have you seen bug #1181810 on upower, and do you have any idea what might be causing it? | 18:01 |
ubottu | bug 1181810 in upower (Ubuntu) "After upgrade to saucy, lid close policy is not being respected" [High,Confirmed] https://launchpad.net/bugs/1181810 | 18:01 |
slangasek | pitti: I'm not sure if it could be related to the changes made to acpi-support | 18:01 |
slangasek | (though probably not, I guess, since there's now nothing in acpi-support which handles lid close events) | 18:02 |
josepht | slangasek: that looks like a dupe of bug 1180513 | 18:03 |
ubottu | bug 1180513 in gnome-settings-daemon (Ubuntu) "lid close actions are ignored laptop always suspends" [Medium,Triaged] https://launchpad.net/bugs/1180513 | 18:03 |
slangasek | josepht: ah, ok | 18:03 |
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:04 |
=== sraue_ is now known as sraue | ||
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:10 |
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:16 |
slangasek | armel? | 18:21 |
infinity | slangasek: quantal. | 18:22 |
slangasek | hmph :) | 18:22 |
kees | sarnold: not all of them, actually. | 18:33 |
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:34 |
lifeless | kees: zomg people know what we build our binaries with? | 18:39 |
Mirv | infinity: I believe you should have gotten the fix around ~now with today's updates | 18:46 |
infinity | Mirv: Indeed, I seem to be more stable now. | 18:47 |
infinity | Mirv: Fingers crossed. | 18:47 |
kees | lifeless: they do indeed! :) | 18:58 |
sarnold | kees: oh, neat :) I've not noticed the tripwarning before :) hehe | 19:01 |
kees | sarnold: yeah, if you trigger the link protections, and audit notice is generated | 19:02 |
=== salem_ is now known as _salem | ||
cjwatson | arges: best thing to post is a debdiff from current Debian | 22:57 |
=== wedgwood is now known as wedgwood_away | ||
bdmurray | slangasek: could you have a look at bug 1187233? | 23:11 |
ubottu | bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [Critical,New] https://launchpad.net/bugs/1187233 | 23:11 |
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:12 |
bdmurray | slangasek: okay, sounds good. | 23:13 |
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:24 |
cjwatson | (debian/extra/udev.startup is used nowhere else than d-i) | 23:26 |
=== broder_ is now known as broder |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!