[00:12] <xnox> slangasek: i think robert collins by "except for firefox. And kernels."  could also mean linux-lts-quantal which is a new upstream version bump, just like firefox.
[03:17] <adrian546864> hi there! trying the SDK preview. I couldnt figure out how to use C++ in the "Ubuntu -> Ubuntu UI - Tabs" type of projects. Anytime I want to add a c++ class i get the message "Failed to add one or more files to project". Isnt that implemented yet? Could somebody help me out. I want to play around with but Im unfortunatly not able to... :(
[03:23] <adrian546864> somebody who can help me with the Ubuntu SDK preview? I want to use c++ for it. is that already supported???
[03:34] <_NerdyMe_> hi there! trying the SDK preview. I couldnt figure out how to use C++ in the "Ubuntu -> Ubuntu UI - Tabs" type of projects. Anytime I want to add a c++ class i get the message "Failed to add one or more files to project". Isnt that implemented yet? Could somebody help me out. I want to play around with but Im unfortunatly not able to... :(
[06:42] <pitti> Good morning
[07:32] <tkamppeter> RAOF, hi
[07:33] <RAOF> tkamppeter: Happy public holiday!
[07:34] <tjaalton> :)
[07:35] <tkamppeter> RAOF, sorry, did not know that today is a holiday for you, can you on tomorrow's workday fix bug 1126427 as soon as possible so that I can update Ghostscript without formal FFe process? Thanks.
[07:35] <dholbach> good morning
[07:38] <RAOF> tkamppeter: Sure.
[07:48] <cjwatson> Sweetshark,bdrung: Is libmspub just code split out of libreoffice, or is it genuinely new code?
[07:54] <dholbach> @pilot in
[07:55] <slangasek> xnox: possible; but the lts backport stacks have even less impact on existing users than the stable kernel tree updates do
[08:11] <pitti> hey slangasek, how are you?
[08:11] <pitti> dholbach: happy flying
[08:11] <dholbach> thanks pitti :)
[08:12] <slangasek> pitti: hey there!  Sorry, I'm late for bed... any chance we can sync up on logind in the "morning"?
[08:12] <pitti> slangasek: I need to go AFK at 1700 UTC for Taekwondo, so anything before that
[08:13] <slangasek> pitti: ok
[08:13] <pitti> slangasek: I just talked to mbiebl some more, I have some TODO today for making standalone logind really work
[08:23] <tkamppeter> slangasek, is it OK when I update ghostscript from 9.06 to 9.07 on Tue or Wed? It needs bug 1126427 to be fixed first.
[08:24] <Sweetshark> cjwatson: code split out of libreoffice. libreoffice 4.0.0beta2 already contained an internal copy (and its a hard dep anyway).
[08:26] <cjwatson> Sweetshark: All right, thanks.  Since it's a split-out, I've gone ahead and moved it to main without need for an MIR.
[08:26] <cjwatson> That should unbreak image builds.
[08:42] <Sweetshark> cjwatson: huh? bug 1124082
[08:53] <infinity> cjwatson: The libmspub thing was a victim of the overrides bug, it was right in proposed.
[08:53] <infinity> cjwatson: Or was right and then got demoted again due to libreoffice not migrating before slangasek cleared out c-m.  Pick one. :P
[09:38] <ev> xnox: ah, lovely
[09:38] <ev> xnox: may I have a bug for that against whoopsie please?
[09:38] <ev> the upstream project, not the package
[09:57] <dholbach> bdrung, do you know somebody who could take a look at https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/1080059?
[10:35] <cjwatson> Sweetshark: Ah, right
[10:35] <cjwatson> infinity: I think the latter.  I noticed it in c-m the other day.
[10:36] <cjwatson> slangasek: ^- this is why I didn't consider clearing out c-m *totally* trivial :-)  What I tend to do is to check rmadison and see whether the package was absent/universe in quantal and main in raring - if so it's probably a recent move and needs checking
[10:42] <Drenriza> Hi all. I was wondering if their is a channel used as the same as the "programming talk" section on ubuntuforums.org. For discussing / asking questions regarding scripting / development under Ubuntu.
[10:42] <tumbleweed> cyphermox: seen bug 1153085 ?
[10:43] <cjwatson> Drenriza: #ubuntu-app-devel more or less
[10:43] <Drenriza> Thanks cjwatson
[10:45] <Drenriza> So what is this channel used for? wiki.ubuntu.com/IRC just describes it as follows "Ubuntu development coordination"
[10:46] <cjwatson> Development of Ubuntu itself, rather than of third-party programs built on Ubuntu
[10:46] <cjwatson> (Catch-all; there are also channels for specialised aspects of Ubuntu development)
[10:47] <Drenriza> When you say Ubuntu itself, you mean the stuff that goes on top of the linux-kernel?
[10:48] <cjwatson> I mean the contents of the Ubuntu archive
[10:48] <Drenriza> Ty cjwatson.
[10:49] <cjwatson> There are things below the Linux kernel that are part of Ubuntu and would also be on-topic here, such as boot loaders
[10:50] <bdrung> dholbach:  quadrispro did the debian upload and the sync. so you could ask him
[10:53] <xnox> cjwatson: i did ponder to set the topic to "Ubuntu Core Development" instead what is currently in the topic "Dev' of Ubuntu ..."
[10:54] <diwic> xnox, "Development of Ubuntu itself (not support or app devel)" perhaps?
[10:55] <xnox> i don't have a strong opinion =)
[10:55] <xnox> Dev' is hard to understand =)
[10:56] <cjwatson> It's not just core development though
[10:56] <cjwatson> The apostrophe is fairly silly
[10:57] <cjwatson> (if "devel" is comprehensible in "app devel", it's also comprehensible at the start of that item)
[10:57] <cjwatson> It's truncated because topic space is scarce
[10:59] <FourDollars> dholbach: hi
[10:59] <FourDollars> dholbach: Could you help to review https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 ?
[11:01] <tumbleweed> we could probably use a better description in https://wiki.ubuntu.com/IRC/ChannelList too
[11:01] <tumbleweed> "Development of Ubuntu (not support or app devel)" ?
[11:01]  * tumbleweed sees lots of out of date contact peopl there...
[11:02] <dholbach> FourDollars, I pinged mvo about it :)
[11:02] <dholbach> FourDollars, but it looks good to me
[11:02] <ogra_> wikis ... out of date at creation time :)
[11:03] <FourDollars> dholbach: Is there any thing I missed?
[11:03] <tumbleweed> ogra_: yeah, the natural state of wikis
[11:03] <ogra_> :)
[11:03] <dholbach> FourDollars, no, not that I can see
[11:03] <FourDollars> dholbach: OK. Thanks.
[11:27] <mitya57> Does anybody want to test/review quantal pybuild backport? lp:~mitya57/ubuntu/quantal/python3-defaults/pybuild-backport
[11:35] <ogra_> lool, eek ... more mailing lists ...
[11:36]  * ogra_ slowly gets why linus loves 3:2 screens .... more vertical height = less scrolling in your mail trees ... 
[11:40] <lool> ogra_: yeah, it's not great when we're splitting signal in even more places  :-(
[11:46] <dholbach> Riddell, would you know who could review https://code.launchpad.net/~bkerensa/ubuntu/raring/plasmate/fix-for-1152730/+merge/152538?
[11:46] <Riddell> dholbach: just discussing now in #k-d
[11:46] <bkerensa> ;)
[11:46] <dholbach> ah great! :)
[11:46] <bkerensa> then sleeps
[11:53] <dholbach> bdrung, thanks
[11:56] <dholbach> @pilout out
[11:56] <udevbot_> Error: "pilout" is not a valid command.
[11:56] <dholbach> @pilot out
[11:56] <dholbach> udevbot_, yeah yeah
[11:56] <udevbot_> Error: "yeah" is not a valid command.
[11:57] <tumbleweed> pedantic bot
[11:57] <vibhav> tumbleweed: Computers are supposed to be pedantic :)
[11:58] <vibhav> s/supposed//
[12:09] <zyga> lool: thanks for ubuntu-platform that's excellent news!
[12:10] <ogra_> hmpf
[12:11] <tumbleweed> wasn't there an existing list called ubuntu-platform@l.u.c?
[12:11] <xnox> yeap, for entirely different reasons ;-)
[12:49] <jdstrand> @pilot in
[13:20] <cyphermox> tumbleweed: I hadn't seen the libqmi bug, no
[13:20] <cyphermox> there's no harm in syncing it now, but we also won't be using it in raring
[13:21] <tumbleweed> yeah, that's basically why he wants it
[13:21] <cyphermox> err
[13:21] <ScottK> tumbleweed: If it's a sync from Debian, I think a new package is fine.
[13:21] <tumbleweed> yup, we should do it
[13:22] <cyphermox> I mean it's totally safe given that there cannot possibly be anything that uses it in raring
[13:22] <cyphermox> so yeah, it's fine by me
[13:22] <cyphermox> should I sync?
[13:23] <tumbleweed> cyphermox: sure, I just acked the FFe
[13:23] <cyphermox> thanks
[13:23] <ScottK> Approved.
[13:27] <cyphermox> tumbleweed: syncpackage: Error: Not permitted to upload directly to raring; try raring-proposed instead.
[13:27] <cyphermox> is there a magic trick for syncpackage to be happy?
[13:27] <cjwatson> Use a modern syncpackage
[13:27] <cyphermox> ah
[13:27] <pitti> are you trying to use a quantal syncpackage?
[13:27] <cyphermox> no
[13:27] <cjwatson> If you don't have one then -r raring-proposed
[13:27] <tumbleweed> sorry, I think we haven't finished reviewing the SRUs for that
[13:27] <cjwatson> Well, you aren't using raring, or else you have weird local configuration
[13:28] <cjwatson> cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-October/000989.html
[13:28] <cyphermox> well, I think something is weird yeah
[13:28] <cjwatson> Perhaps an alias?
[13:28] <cjwatson> tumbleweed: The SRUs have been in -updates for some time
[13:29] <cyphermox> I'll double check but I never aliased that, and I have the latest ubuntu-dev-tools, and I'm not in the branch's directory either
[13:29] <tumbleweed> cjwatson: oh, I'm thinking of different ones then
[13:29] <cjwatson> https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.144  https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.143ubuntu0.1  https://launchpad.net/ubuntu/+source/ubuntu-dev-tools/0.141ubuntu0.1
[13:30] <tumbleweed> so, precise's one is still in -proposed
[13:30] <ScottK> Yes.  One bug unverified.
[13:30] <cjwatson> Oh, so it is
[13:30] <ScottK> I've been tempted to release it anyway.
[13:30] <mdeslaur> tumbleweed: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue?
[13:31] <cjwatson> I think libreoffice-help-* may be busted with 4.0
[13:31] <cjwatson> Noticing UbuntuKylin image build failures which seem similar
[13:32] <mdeslaur> tumbleweed: whoops, sorry, I didn't mean you
[13:32] <tumbleweed> ScottK: bdrung couldn't verify that bug on the weekend, I haven't dug into it yet
[13:32] <tumbleweed> mdeslaur: :P
[13:32] <mdeslaur> Sweetshark: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue?
[13:32] <ScottK> tumbleweed: Worst case I think is "it works"
[13:33] <cjwatson> libreoffice-help-en-us libreoffice-help-zh-cn  are not coinstallable
[13:34] <cjwatson> Blink, there are a load of explicit Conflicts.  What are those for?
[13:34] <tumbleweed> ScottK: yeah
[13:34] <cjwatson> "conflict help language packages in both ways"
[13:35] <Sweetshark> mdeslaur: its a feature, not a bug. libreoffice-help-fr and libreoffice-help-en cant be installed both (otherwise your -fr will be broken anyway)
[13:35] <cjwatson> Sweetshark,bdrung: Can you fill me in what's going on with libreoffice-help-* coinstallability?  The current situation is rather awkward.
[13:35] <cjwatson> Sweetshark: This screws over image builds and the installer
[13:35] <cjwatson> Because there are a number of situations where we install support for multiple languages
[13:35] <mdeslaur> Sweetshark: that's...less than ideal....I can't have two different languages on the same computer anymore?
[13:36] <cjwatson> I would definitely categorise this as a bug
[13:36]  * zyga curses at all-things-perl and gets back to work
[13:37] <Sweetshark> mdeslaur: bug 957589
[13:38] <Sweetshark> cjwatson: ^^
[13:38] <cjwatson> Yes.  Please revert.
[13:38] <cjwatson> This is worse than the previous situation.
[13:41] <Sweetshark> cjwatson: revert *both* conflicts? upstream (Debian) conflicts one way (from en-US to everything else, but not the other way around).
[13:41] <cjwatson> Sweetshark: Do you understand the problem here?  If so then the answer should be clear, I think
[13:42] <Sweetshark> mdeslaur: you can have an many languages as you want as long as none is en-US.
[13:42] <cjwatson> What's special about en-US?
[13:43] <cjwatson> We generally assume (and it's true everywhere else) that it's possible to simultaneously install support for multiple languages without restriction.  en-US being a special case is particularly weird, given that English support is in general always installed.
[13:43] <Sweetshark> cjwatson: Yes, I would remove both conflicts. But when a package build takes a day on ARM it can hurt to be absolutely clear, I guess?
[13:44] <cjwatson> I think it's probably excessive that it's in ubuntu-desktop; but (a) removing that will only partially help, and (b) wouldn't it have been better to get ubuntu-desktop amended before whacking in Conflicts if you thought that ubuntu-desktop was wrong?
[13:44] <cjwatson> Both the Conflicts are a problem.  What's the underlying reason that en-US is broken?
[13:45] <Sweetshark> cjwatson: If I know _why_ I would fix it.
[13:45] <Sweetshark> s/know/knew/
[13:45] <cjwatson> BTW, having the conflicts both ways achieves nothing over having them only one way round.
[13:46] <cjwatson> An unversioned Conflicts is a bidirectional relationship (well, in the absence of a matching Replaces).
[13:46] <Sweetshark> cjwatson: bdrung insisted on having them both ways when reviewing the package.
[13:47] <cjwatson> bdrung: Why?
[13:47] <bdrung> either both way conflicts or no conflict
[13:47] <cjwatson> bdrung: Why?
[13:47] <cjwatson> Nothing wrong with one-way conflicts
[13:47] <bdrung> cjwatson: when updating from 4.0.0beta2 to 4.0.0, en-US would been held back
[13:48] <cjwatson> bdrung: And Conflicts both ways solves that?  How peculiar.
[13:48] <cjwatson> But in any case that should have been a sign that the Conflicts was a bad idea in the first place :-(
[13:49] <bdrung> okay, it's a workaround
[13:49] <cjwatson> Dealing with run-time problems (and Medium priority ones, at that) by adding Conflicts just stores up trouble for later, and trouble of the kind that permeates the upgrade system
[13:50] <Sweetshark> cjwatson: indeed the oneway conflict isnt there in beta2 and was introduced at debian inbetween.
[13:50] <cjwatson> Hm, 'check-language-support -a -l en' doesn't list libreoffice-help-en-us
[13:52] <Sweetshark> cjwatson: so reverting that is a two-line change. Do you want an upload with just that?
[13:53] <pitti> cjwatson: s/-a/--show-installed/
[13:54] <cjwatson> pitti: Oh, yeah, I just figured that out :)
[13:54] <cjwatson> Sweetshark: When would your next upload be otherwise (roughly)?
[13:56] <cjwatson> Well; I guess I'm concerned that ultimately we presumably want to be able to keep multiple help packages installed simultaneously, including en-us, and having a Conflicts in raring means that people's configuration is effectively lost in the meantime
[13:57] <Sweetshark> cjwatson: too long. I havent clear plan beyond 4.0.1 -- so it would be when I fix one important bug. 4.0.2 upstream is on ~April, 1st.
[13:57] <Sweetshark> cjwatson: preparing a source package ...
[13:58] <cjwatson> Sweetshark: I think we should have such an upload then - thanks
[13:59] <cjwatson> I'm going to pull libreoffice-help-en-us out of ubuntu-desktop; I don't think it makes sense there, and it's in the ship and live seeds too so it's not as if it drops off images
[13:59] <cjwatson> Won't fix everything but I think it will at least unblock UbuntuKylin image builds, and it seems correct regardless
[14:00] <Sweetshark> cjwatson: k, thanks a lot.
[14:00] <stgraber> cjwatson: will that still prevent some images from building? I'm kind of worried as we have beta1 coming this week and pretty much everyone signed up for it
[14:00] <cjwatson> stgraber: I'll check the other seeds too
[14:00] <stgraber> cjwatson: thanks
[14:02] <cjwatson> stgraber: I *think* it's just the Ubuntu GNOME remix, but I'll keep an eye on Edubuntu too
[14:13] <Sweetshark> cjwatson: any wish for the urgency other than 'low'? If so, which?
[14:14] <cjwatson> Sweetshark: Doesn't matter; at the moment, nothing in Ubuntu cares
[14:14] <stgraber> Sweetshark: Ubuntu doesn't usually use the urgency field
[14:14] <cjwatson> Well, except for possibly apt-listchanges
[14:15] <tumbleweed> and a slight buildd weight IIRC
[14:15] <cjwatson> Oh yeah
[14:15] <cjwatson> Anyway, all my Ubuntu uploads are 'low'
[14:15] <stgraber> cjwatson: I thought LP also uses the urgency field to give a slightly higher build score
[14:16] <cjwatson> Yeah, tumbleweed said that
[14:16] <cjwatson> It's pretty negligible though; https://help.launchpad.net/Packaging/BuildScores
[14:16] <cjwatson> It's the least significant automatic score adjustment and more or less never matters
[14:18] <cjwatson> Right, since I now get to wait for a load of builds I guess it's lunchtime
[14:21] <stgraber> Laney: I guess that's what I'm saying, yes ;) technically both daemons can run, but to avoid problems you'd have to make sure they're perfectly in sync
[14:22] <jbicha> cjwatson: the urgency field is nice for ppas though
[14:23] <Laney> stgraber: Hm, I have my session registered in both right now
[14:25] <stgraber> Laney: right, I think I do too. I guess the basic, registering the session, getting the session list, unregistering the session should be fine, as long as we have the right pam modules loaded.
[14:26] <Laney> Did you actually see problems?
[14:26] <Laney> if so it would be good to note that in the bug ;-)
[14:26] <Laney> I think doing a full transition might be a bit too big for raring
[14:27] <cjwatson> jbicha: Maybe.  The package set adjustment would still dominate.
[14:27] <stgraber> no, I haven't. I just remember us saying that it'd be a potential source of problem as running both CK and logind isn't a supported setup and that we can't know for sure what all the various piece of software will do when they see both APIs being present
[14:28] <jbicha> cjwatson: the scoring difference is enough to get a package to almost the head of the universe queue and the queue is often several hours long
[14:28] <Laney> pitti: we're having a conversation about logind here, fyi ;-)
[14:29] <pitti> Laney: ah, catching up (me as well, discussing with jdstrand and mbiebl)
[14:29] <dobey> anyone know why apport would open chrom{e,ium} instead of firefox (which is set as default browser) when reporting a "system problem" on raring?
[14:30] <stgraber> dobey: my guess is that apport uses x-www-browser (directly or indirectly) and that for some reason points to chrome on your machine
[14:31] <pitti> oh, dobey left
[14:31] <pitti> it uses xdg-open
[14:32] <cjwatson> jbicha: Fair enough; I guess you have more practical experience with waiting for PPA builds than I do :-)
[14:32] <pitti> dobey: apport calls xdg-open, which does a couple of things (gvfs-open, alternative, sensible-browser, etc.)
[14:33] <pitti> Laney: session registered in both> that's CK and loginctl? that's how it ought to be, yes
[14:33] <Laney> yes - stgraber think this will cause problems
[14:33] <pitti> oh, how?
[14:33] <Laney> i.e. the transition must be done fully
[14:34] <jbicha> cjwatson: of course once everyone does it then we all have to wait in queue again so maybe I shouldn't be announcing it to #ubuntu-devel ;)
[14:34] <stgraber> pitti: I think it "may" be a source of problem, depending on what the various pieces of software do when both API are available. Though I haven't seen anything go wrong yet.
[14:34] <pitti> Laney, stgraber: we have a code grep of everything that talks to CK, so we could certainly check those?
[14:34] <cjwatson> jbicha: heh
[14:35] <pitti> the bits that I looked at either have no clue about logind, or they use #ifdef HAVE_SYSTEMD style
[14:35] <pitti> or they check /sys/fs/cgroup/systemd at runtime (like gnome-shell) and select between the two
[14:35] <stgraber> pitti: yep, that'd work. I guess we want to check whether any of those will try to connect to both at the same time and do something silly like aggregating the session list from both
[14:35] <pitti> right
[14:35] <stgraber> so long as they choose to use one or the other, we should be fine
[14:36] <Laney> I'd say that those would be bugs to fix
[14:36] <pitti> stgraber: btw, I just finished my investigation about programs that check for /sys/fs/cgroup/systemd
[14:36] <pitti> i. e. do they mean "I want systemd init" or "I want logind" or something else
[14:37] <pitti> turns out there's only two packages which actually want systemd init or journal, i. e. not logind
[14:37] <pitti> http://paste.ubuntu.com/5604908/
[14:37] <pitti> and we don't even ship sysvinit
[14:37] <pitti> so for ubuntu, only one package to fix
[14:37] <dobey> pitti: but why didn't it open the default browser? running xdg-open works. clicking on a link in terminal works. apport just suddenly decided to open chromium here. and chromium was running the wrong theme even too.
[14:37] <dobey> oh well
[14:37] <pitti> dobey: oh, root report
[14:38] <pitti> dobey: I figure it somehow failed to suid back to your user, for a system crash?
[14:38] <stgraber> pitti: that's a lot better than I'd have thought ;)
[14:38] <dobey> pitti: that would be quite odd, given it was also logged in on LP, and i've never run chromium as root before myself.
[14:39] <dobey> so it was running as my user. and it was a system crash
[14:39] <dobey> but the theme was wrong, and it was chromium instead of firefox
[14:41] <mitya57> Hi pitti, I'm trying to build pygobject on Debian sid (a crazy idea, I know), and I get this: http://paste.ubuntu.com/5604936/plain/
[14:41] <mitya57> Any idea what may cause that?
[14:41] <pitti> mitya57: you need py3cairo from experimental
[14:42] <mitya57> pitti: Thanks! Maybe time to bump build-dependency?
[14:42] <bdmurray> cjwatson: https://errors.ubuntu.com/bucket/?id=/usr/bin/compiz:8:StaticSwitchScreen::getWindowPosition:StaticSwitchWindow::glPaint:GLWindow::glPaint:FadeWindow::glPaint:GLWindow::glPaint
[14:44] <mitya57> ignore that, Ubuntu version is older but looks like it includes the fix
[14:44] <Sweetshark> bdrung, cjwatson: debdiff at http://people.canonical.com/~bjoern/libreoffice4/libreoffice_4.0.1-0ubuntu2.diff and http://people.canonical.com/~bjoern/libreoffice4/libreoffice_4.0.1-0ubuntu2_source.changes file
[14:47] <Sweetshark> whoops, the diff is reverse
[14:49] <bdrung> Sweetshark: please don't forget to tag 4.0.1-0ubuntu1 in git
[14:49] <Sweetshark> bdrung: already done, pushing now
[14:49] <cjwatson> bdmurray: Thanks, I found it in the end
[14:50] <bdrung> Sweetshark: i don't see it. have you pushed the tags, too?
[14:50] <cjwatson> Sweetshark: LGTM
[14:51] <Sweetshark> bdrung: see the "pushing now" ;)
[14:52] <Sweetshark> bdrung: pushed (also the change for 0ubuntu2)
[14:52] <bdrung> Sweetshark: i saw it. probably the web ui lagged. i see it now.
[14:59] <Sweetshark> debdiff updated to not be reverse fwiw
[15:00] <Sweetshark> bdrung: will you sponsor?
[15:00] <bdrung> Sweetshark: yes
[15:00] <bdrung> Sweetshark: i am doing a test build (which i expect to succeed and to what it's supposed to to) and then i do the upload.
[15:01] <bdrung> Sweetshark: have you done a test build?
[15:02] <bdrung> Sweetshark: btw, does it make sense to merge debian-experimental-4.0 or wait until raring+1 to do that?
[15:02] <shadeslayer> cjwatson: could you update the packageset ? I've added a couple of packages to the kubuntu supported seed
[15:02] <Sweetshark> bdrung: still running
[15:03] <pitti> jdstrand: where did you run your recent archive grep? I wanted to start one on lillypilly, but its load is > 20
[15:03] <cjwatson> shadeslayer: running
[15:04] <shadeslayer> cjwatson: thanks!
[15:04] <jdstrand> pitti: locally
[15:05] <pitti> jdstrand: ah, ok
[15:05] <pitti> jdstrand: well, I'll look around for another mirror in the DC
[15:06] <Sweetshark> bdrung: as for merging: we are past feature freeze (assuming that we do not do rolling releases, which is the most likely scenario), so I am very careful with changes there. I would only merge when all changes look low-risk -- otherwise I would revert to only cherry-pick uservisible and painful changes.
[15:07] <bdrung> Sweetshark: it contains lintian fixes and the VER removal
[15:08] <bdrung> Sweetshark: i tend to prefer the merge, because we have just passed the feature freeze and have enough time till the release.
[15:10] <cjwatson> shadeslayer: done
[15:11]  * shadeslayer tries uploading again
[15:15] <shadeslayer> cjwatson: works, thanks alot!
[15:16] <pitti> jdstrand: hm, didn't find a good one; would it be very much effort for you to kick off another archive grep?
[15:21] <jdstrand> pitti: no. what do you need?
[15:21] <pitti> jdstrand: grep -r fs/cgroup/systemd
[15:23] <jdstrand> ok
[15:24] <pitti> jdstrand: thanks muchly!
[15:24] <xnox> bdmurray: ev: \o/ thanks for the Bug 1056061
[15:25] <ev> xnox: sure thing. Should land with the rollout planned for today
[15:27] <jdstrand> pitti: ok, started. it takes a while so I'll let you know when it's done
[15:27] <pitti> jdstrand: sweet, thanks!
[15:27] <jdstrand> heh, it just found the apparmor one :)
[15:32] <pitti> jdstrand: hm, argh; would it be possible to restart this, with "egrep -r "fs/cgroup/systemd|sd_booted"?
[15:33] <jdstrand> pitti: sure
[15:37] <jdstrand> pitti: done
[15:37] <pitti> cheers!
[16:01] <jamespage> micahg: what have you found using internal Sun Microsystems Java API's?
[16:01] <jamespage> micahg: javax.imageio provides a way forward for some bits and pieces
[16:28] <slangasek> tkamppeter: ghostscript> please coordinate such questions with #ubuntu-release per my mail, not with me personally
[16:30] <slangasek> infinity, cjwatson: libmspub> noted; would it make sense to keep MIR bugs open until the relevant packages make it to raring rather than raring-proposed?
[16:31] <slangasek> pitti: hey, so I just dropped a comment on bug #1153224 with some thoughts
[16:32] <pitti> slangasek: thanks; in meeting still, will look ASAP
[16:32] <Sweetshark> bdrung: at packing libreoffice-dbg here btw ....
[16:34] <pitti> slangasek: FYI, I see no problem with kicking CK out of the standard installation -- I've run without CK since last Thursday
[16:34] <pitti> slangasek: I was mainly talking about teh odd universe package, or more importantly, Kubuntu
[16:34] <pitti> slangasek: also, I fully agree that we don't want udev 195 in raring, that's too risky (and I wasn't proposing that)
[16:35] <pitti> slangasek: I want current logind, so that we get the current libraries
[16:35] <infinity> slangasek: Possibly, though making c-m union proposed into its output will eliminate the need for more process that people get wrong, and that was being worked on, in theory.
[16:35] <infinity> slangasek: I'll chase that up this week and see if we can JFDI.
[16:36] <slangasek> pitti: right, I think my argument applies to Kubuntu as well, not just Ubuntu; I think the Kubuntu folks should have a say in how this impacts them
[16:36] <slangasek> infinity: ok.  worked on by whom, in theory
[16:36] <pitti> slangasek: right
[16:36] <slangasek> pitti: oh.  So we would have current udev, but newer libudev?  Why do we need newer libudev?
[16:36] <infinity> slangasek: By Ursinha.  I'll see where that's gotten to.
[16:37] <pitti> slangasek: if we wanted to, we could also skip that, but it has been the official libudev ABI for quite some time now (thinking about backports, third-party packages, etc)
[16:37] <pitti> slangasek: so the libudev transition is rather harmless, and I could get that done in a day or two at most
[16:40] <pitti> slangasek: but anyway, I had the impression that both you and seb128 were urging for this; we can certainly postpone the whole thing to raring+1, and sort out the udev migration until then as well
[16:40] <slangasek> pitti: are backports/third-party packages the only justification for wanting the ABI bump?
[16:40] <pitti> slangasek: there isn't much difference between the two, so it doesn't matter that much either way
[16:41] <pitti> as for third-party binary stuff, I have no idea what they might prefer
[16:41] <slangasek> pitti: well, I certainly want us to get moved from consolekit to logind, but seeing the number of packages affected I'm wary of doing this before 13.04
[16:41] <pitti> but most of that will target LTSes, I guess
[16:41] <pitti> slangasek: so, if you want to move to logind without moving to libudev1, we can do that
[16:42] <pitti> either with the current v44, or by disabling the libudev{1,-dev} and gudev bits from 198
[16:42] <slangasek> right - I would be more comfortable with that
[16:42] <slangasek> reduces the scope of the transition
[16:42] <pitti> in which case I'd prefer the latter, as it's better supported upstream, more useful for building stuff with logind, and also has a cleaner package
[16:42] <infinity> Do we have a udev linked with kmod yet, or would that also come with this transition?
[16:43] <pitti> infinity: we don't, and it wouldn't come
[16:43] <infinity> Oh, shame.
[16:43] <pitti> infinity: as I said, moving to current udev is a lot of work and not proposed
[16:43] <infinity> Kay.
[16:43] <slangasek> pitti: "cleaner package" - except this package seems to still not be anywhere authoritative
[16:43] <infinity> I didn't read the full backscroll. :P
[16:43] <pitti> infinity: several people patched udev without forwarding or describing patches etc, and packages like lvm2 also havent' been updated in ages, so this will be quite intrusive
[16:44] <infinity> pitti: Check.  Sounds like something worth queueing up in a PPA to land first thing in 13.05 so we can shake out the pain.
[16:44] <pitti> *nod*
[16:45] <pitti> in the meantime I'm corrdinating with Mithrandir and mbiebl wrt. the systemd-services split, udev, etc.
[16:45]  * infinity was just looking forward to not forking modprobe 378 times every boot.
[16:45] <pitti> yeah, so was I
[16:45] <slangasek> hmm, didn't realize we still needed a udev update to get that
[16:45]  * zyga wonder why some people choose movie related nicknames as their identity online
[16:45] <slangasek> I thought now that libkmod was in, we just needed to rebuild udev; apparently not :/
[16:45] <zyga> and gets back to work...
[16:46] <infinity> zyga: Movie-related?
[16:47] <slangasek> pitti: so I think we should take this one piece at a time; first sort out if we can get a transition done based on 44, and if so go ahead with that, then uplift to 195 in coordination w/ Debian; then figure out if we can tackle the newer-udev question
[16:47] <tseliot> slangasek: do you happen to remember (since I think you suggested it in the first place) why we use something like "alias nouveau off" in addition to "blacklist nouveau" in the nvidia driver?
[16:47] <cjwatson> slangasek: Not sure what the right answer is.  I also don't want there to have to be too much manual bug paperwork which will get forgotten
[16:47] <slangasek> tseliot: 'blacklist' has no effect on udev
[16:47] <zyga> infinity: Mithrandir?
[16:47] <tseliot> slangasek: ah, right, thanks
[16:47] <slangasek> cjwatson: infinity thinks this is solvable with c-m report fixes, so that seems a better answer
[16:47] <slangasek> zyga: infinity is a big toystory fan
[16:48] <cjwatson> Probably, yes
[16:48] <infinity> slangasek: "alias off" breaks kmod.  I need to look into that.
[16:48] <slangasek> infinity: cute
[16:48] <Laney> Oh god yes, please do
[16:48] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674110
[16:49] <Laney> nvidia trips over that
[16:49] <infinity> Md forwarded it upstream, but I think upstream may have forgotten about it.  I'm going to poke him and then JFDI myself if he doesn't respond.
[16:49] <pitti> slangasek: we can do a logind transition with 44, yes
[16:50] <pitti> slangasek: the package as it is in raring works fine (modulo adding Conflicts/Replaces: libpam-xdg-support and  changing seeds)
[16:50] <slangasek> right
[16:50] <pitti> slangasek: but as one of the main points was that it blocks updates to newer upstream versions like GNOME, 44 isn't sufficient for some of those
[16:50] <pitti> slangasek: hence my idea to update to 198 in universe, and do the MIR/FFE review based on that
[16:51] <Sweetshark> bdrung: build finished here.
[16:51] <pitti> slangasek: we can still disable libudev1 there if we want
[16:51] <slangasek> I don't think that's a key point for this cycle
[16:51] <pitti> slangasek: ok
[16:51] <infinity> zyga: Mithrandir would be a book reference, not a movie reference, but fair enough.  He's been that for so long, I sometimes forget his name's Tollef, and he's a close friend, so that's mildly embarassing. :P
[16:51] <slangasek> the decision was already taken in Copenhagen not to update GNOME; we shouldn't rush logind in order to reverse that decision
[16:52] <seb128> slangasek, pitti: logind 44 has some unfixed CVE as well
[16:52] <pitti> seb128: really, which?
[16:52] <pitti> seb128: I only know http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174
[16:52] <pitti> which is fixed in 44
[16:52] <slangasek> updating GNOME is NOT a priority for 13.04, and logind is a priority only inasmuch as it helps us a) drop unmaintained code and b) reduce our desktop footprint
[16:52] <seb128> pitti, http://secunia.com/advisories/48331/
[16:52] <pitti> slangasek: oh, I was thinking about the ubuntu gnome remix, not ubuntu itself
[16:52] <seb128> " The weakness is reported in version 44 and prior."
[16:52] <pitti> slangasek: so anyway, we can cut this anyway we like
[16:53] <pitti> slangasek: if you want to go with 44 in raring, that's fine and doable
[16:53] <pitti> slangasek: i. e. we are a MIR and seed change away from this
[16:53] <pitti> (and the FFE, of course)
[16:53] <slangasek> hmm, is that all?  I thought you had quite a few package rebuilds to enable logind support
[16:54] <infinity> seb128: That's the same CVE as pitti pointed out, so clearly one of those databases is wrong.
[16:54] <pitti> slangasek: yes, of course
[16:54] <seb128> infinity, pitti: in any case it's a detail, easy to backport a fix if needed at all
[16:54]  * infinity nods.
[16:54] <slangasek> pitti: right, to me that counts as more than just "a MIR and seed change" - which is why I think we should tackle the ck->logind migration separately from the rest
[16:55] <pitti> slangasek: ok; but please keep in mind that if we do this we have to keep consolekit in teh default install
[16:56] <slangasek> hmm, why?
[16:56] <pitti> slangasek: as e. g. gnome-session requires >= 183 for the inhibit stuff
[16:56] <slangasek> ah poo
[16:56] <pitti> the one in raring, I mean
[16:56] <mbiebl> seb128: the debian patch already contains that patch
[16:56] <mbiebl> see the 44-1 changelog
[16:56] <mbiebl>     - Backport 693ce21: util: never follow symlinks in rm_rf_children()
[16:56] <mbiebl>       Fixes CVE-2012-1174, closes: #664364
[16:56] <seb128> mbiebl, oh, great, thanks
[16:56] <slangasek> pitti: right, in that case I completely reverse my opinion and think we should update systemd first ;)
[16:56] <pitti> slangasek: hence my proposal to update to 198 in universe, and do the libudev1 transition first
[16:56] <mbiebl> seb128: like for a year or so :-)
[16:56] <pitti> slangasek: as that's rather harmless
[16:57] <pitti> slangasek: or alternatively disable libudev/gudev from the package
[16:57] <slangasek> mbiebl: hi there - pitti mentions you have packages for 195, but they're not in the archive or the Vcs-Git repo?
[16:57] <pitti> slangasek: and then do the migration to logind
[16:57] <pitti> slangasek: 198, on http://people.debian.org/~biebl/systemd-198/
[16:57] <pitti> slangasek: I stacked my changes on top of that, and sent them to mbiebl for review
[16:57] <slangasek> pitti: udev itself links against libudev; how will that work?
[16:58] <slangasek> I'm wary that udev won't be happy linking against an external libudev
[16:58] <zyga> infinity: yeah, I was mostly curious as to the motivation, it's not like names are unique anyway
[16:58] <pitti> slangasek: either we ship the .so in "udev", or just drop the -dev
[16:58]  * zyga is spolied by having relatively unused name
[16:58] <slangasek> pitti: i.e., two copies of libudev on the system.  I don't think we want that
[16:58] <pitti> slangasek: but it'll certainly be cleaner to rebuild the 25ish rdepends of libudev0 IMHO
[16:59] <slangasek> pitti: so let's omit libudev from systemd 19x for now, until we're ready to change udev too
[16:59] <pitti> slangasek: but even then we'll still have libudev0 bundled with our old udev package
[16:59] <infinity> pitti: Is the ABI bump much of an API change (or at all)?
[16:59] <infinity> pitti: If not, I don't see the harm in a quick library transition.
[16:59] <pitti> slangasek: so if we want complete migration of the default install, we need current systemd
[16:59] <pitti> slangasek: if we want that, we need some libudev1 in the archive
[16:59] <pitti> slangasek: and if we don't want to update udev, we need libudev0 in teh archive
[17:00] <pitti> slangasek: but we won't have a -dev for libudev0, so it's fairly harmless
[17:00] <pitti> infinity: some, I did an analysis this morning
[17:00] <pitti> infinity: it drops some 5 symbols, which requires (easy) fixes to some three packages, the rest are just rebuilds
[17:00] <infinity> pitti: Yeah, that's approaching zero effort, especially with the analysis already done.
[17:01] <infinity> cjwatson: You win.  kernels stayed in main.
[17:01] <slangasek> pitti: so that's the answer to my earlier question, "why do we need newer libudev"
[17:01] <pitti> slangasek: or I try to build our udev against libudev1, which doesn't actually sound that hard
[17:01] <slangasek> pitti: it wasn't clear to me that the "newer libraries" you needed included libudev
[17:01] <pitti> given that udevd and most of its probes are statiaclly linked
[17:02] <infinity> cjwatson: Do you have a pending seed commit you're waiting to hit <enter> on, or shall I do that now?
[17:02] <pitti> in fact, I'm not quite sure why udev depends on libudev0 at all
[17:02] <cjwatson> infinity: I do indeed
[17:02] <slangasek> pitti: I guess we can cope with libudev0 and libudev1 in the archive together for raring
[17:02] <infinity> cjwatson: Yay.  Go nuts, then.  And thanks for the override fix. \o/
[17:02] <pitti> slangasek: I'm fairly sure I can get rid of libudev0
[17:02]  * xnox catching up on backlog.
[17:03] <cjwatson> infinity: Win
[17:03] <cjwatson> (and done)
[17:03] <xnox> pitti: what do you mean by "and packages like lvm2 also havent' been updated in ages" lvm2 is fairly up to date, not the latest upstream but fairly up to date with useful fixes on  top.
[17:03] <xnox> ?
[17:03] <pitti> for f in `dpkg -L udev`; do echo "[17:03] <pitti> slangasek: so supposedly udev's libudev0 dependency is just a packaging bug
[17:03] <slangasek> pitti: right, checking
[17:04] <cjwatson> infinity: The problems we sometimes have with stable releases are probably something else, unfortunately, as I doubt they'll suffer from the same rapid copy/delete sequence.
[17:04] <slangasek> pitti: hard-coded dep in debian/control; so yes, we can cleanly transition to libudev1
[17:04] <pitti> ah, heh
[17:04] <slangasek> pitti: you needed to go ~now, right?
[17:04] <pitti> slangasek: yeah, I'm afraid so
[17:04] <infinity> cjwatson: Stable release problems are ancestry issues.  Depends on where you're copying from/to.
[17:04] <cjwatson> Ah, yeah, of course
[17:04] <slangasek> pitti: we can pick this up again on the FFe bug later - thanks for the chat, it's much clearer to me now what needs to happen
[17:04] <pitti> slangasek: so my proposal would be to update systemd to 198 in universe, get the FFE for that, do the libudev1 transition; we are really safe until then
[17:05] <infinity> cjwatson: I don't have good notes on where it does and doesn't fail, but we could experiment a bit on staging.
[17:05] <pitti> slangasek: then do the FFE review for logind, if approved do the transition of that
[17:05] <cjwatson> No, now that you mention that I understand what it is
[17:05] <pitti> slangasek: and keep our current udev until after raring
[17:05] <cjwatson> It's harder to fix though
[17:05] <slangasek> pitti: updating systemd to 198 seems like it should also get an FFe
[17:05] <pitti> slangasek: yes; I mentioned it in the same one, but it shoudl probably be split off
[17:06] <slangasek> pitti: ok
[17:06] <slangasek> pitti: have fun at taekwondo :)
[17:06] <pitti> xnox: oh, so it has, thanks
[17:07] <pitti> slangasek: ok, please let me know; I can work on the transition tomorrrow, and put the sourceful fixes for libudev1 into the PPA
[17:07] <pitti> slangasek, stgraber: perhaps you can discuss with ScottK and Riddell for Kubuntu? It would mean that they would need to ship logind plus ConsoleKit
[17:07] <pitti> really need to run now, sorry; TTY tomorrow!
[17:09] <ScottK> Upstream encouraged us to cherry pick the upstream patches and swtich to logind for libsolid4.  What else would it impact?
[17:09] <slangasek> ScottK: there's a list of consolekit-affected packages here: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration
[17:12] <slangasek> at minimum, it seems kdm has consolekit integration
[17:12] <ScottK> We don't ship that by default anymore though.
[17:13] <ScottK> Agreed though.
[17:13] <xnox> slangasek: "whatever lightdm is doing, it should continue to work in kubuntu world" =)
[17:13] <ScottK> polkit-qt we do ship though.
[17:13] <ScottK> xnox: afiestas says there are greeter changes too.
[17:17] <bdmurray> stgraber: is just uncommenting ubuntu in /etc/upstart-xsessions the correct way to ge the xsession running in upstart?
[17:18] <stgraber> bdmurray: yes but it won't quite work yet as we need to get the gnome-session, dbus and gnome-settings-daemon job into their respective packages for it to work
[17:19] <Laney> bdmurray: You'll have to add jobs to start ... that
[17:19]  * Laney literally just did that
[17:20] <bdmurray> stgraber: oh and the ppa version had those jobs
[17:20] <stgraber> bdmurray: which reminds me I need to prepare patches for gnome-session, gnome-settings-daemon and dbus.
[17:20] <stgraber> bdmurray: yeah, the PPA was bundling those but we removed them before landing 1.7 in the archive
[18:23] <bdrung> Sweetshark: build, tested, and uploaded
[18:31] <Sweetshark> bdrung: awesome, thanks.
[18:31] <Sweetshark> cjwatson: ^^
[18:34] <hallyn> @pilot in
[18:39] <jdstrand> @pilot out
[18:42] <Sweetshark> jdstrand: copilot ejecting after liftoff?
[18:44] <sarnold> mid-air pilot hotswap!
[18:46] <jdstrand> hehe, yes :)
[19:05] <tkamppeter> slangasek, OdyX, I have solved the Foomatic problem now and committed everything to GIT/uploaded to Raring. I have made foomatic-db-engine returning a decent error message when no database is available. I have done this upstream and rleased it as foomatic-db-engine 4.0.9. There are no other changes compaired to 4.0.8.
[19:24]  * xnox time to go for a swim \o/
[21:31] <OdyX> tkamppeter: great; release that as tarballs and I'll upload that to experimental :)
[21:35] <tkamppeter> OdyX, foomatic-db-engine is the only package changed upstream for that. The upstream version 4.0.9 is already released and contains the fix. Only this fix is the difference between 4.0.8 and 4.0.9, so the new version can get into any distro with 4.0.8 also after Feature Freeze.
[21:37] <tkamppeter> OdyX, the modified Debian/Ubuntu source packages are foomatic-db-engine and foomatic-db. I have uploaded both to Ubuntu and updated the GIT repos at Debian, so you only need to upload the unchanged GIT snapshots of both to Debian.
[21:37] <OdyX> okay, I'll see if I can get 4.0.9 and foomatic-db update to experimental soon.
[21:39] <captainlinux> Guys is it possible that latest updates have messed up some webcams on Laptops?
[21:40] <captainlinux> After latest updates I'm only getting a black picture.
[21:41] <captainlinux> On clean 12.10 install without updates my cam works. After updates it only gives me a black picture and flashing led.
[21:43] <slangasek> captainlinux: bugs in updates are always possible; if you've confirmed that downgrading to stock 12.10 fixes the problem, then that seems fairly definitive.  You should file a bug against the linux package using the command 'ubuntu-bug linux' and mark it as a regression introduced by an update.
[21:43] <captainlinux> slangasek: Thanks, I will try that.
[22:36] <slangasek> tkamppeter: I think you need to add Provides: foomatic-db-engine to your foomatic-db-compressed-ppds package
[22:36] <slangasek> tkamppeter: update-manager doesn't want to upgrade me in raring because I have foomatic-db-engine installed and u-m doesn't want to remove ti
[22:36] <hallyn> @pilot out
[22:37] <slangasek> tkamppeter: unless, foomatic-db-compressed-ppds doesn't provide the functionality of foomatic-db-engine?
[22:38] <OdyX> slangasek: it doesn't afaik. Provides is sementically wrong afaics.
[22:38] <slangasek> hmm, ok
[22:38] <slangasek> OdyX: do you know why the conflicts/replaces were needed?
[22:39] <slangasek> looks like a wrong use of C/R to me
[22:39] <OdyX> slangasek: the conflict between foomatic-db-engine and foomatic-db-compressed-ppds was my wrong attempt at fixing Debian's #627770. I'll drop that.
[22:40] <slangasek> OdyX: ok, cheers
[22:41] <OdyX> slangasek: it's now fixed correctly on the upstream side by tkamppeter in foomatic-db-engine, thanks him !
[22:42] <slangasek> tkamppeter: thanks for fixing it before I asked ;)