[00:12] 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. === statik_ is now known as statik === stgraber_ is now known as stgraber === hloeung_ is now known as hloeung [03:17] 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] somebody who can help me with the Ubuntu SDK preview? I want to use c++ for it. is that already supported??? === NerdyMe is now known as _NerdyMe_ === NerdyMe is now known as _NerdyMe_ [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] Good morning === tkamppeter__ is now known as tkamppeter [07:32] RAOF, hi [07:33] tkamppeter: Happy public holiday! [07:34] :) [07:35] 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] bug 1126427 in lcms2 (Ubuntu) "LCMS2 needs multi-threading fixes to work with the new Ghostscript 9.07" [High,New] https://launchpad.net/bugs/1126427 [07:35] good morning [07:38] tkamppeter: Sure. [07:48] Sweetshark,bdrung: Is libmspub just code split out of libreoffice, or is it genuinely new code? [07:54] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [07:55] xnox: possible; but the lts backport stacks have even less impact on existing users than the stable kernel tree updates do [08:11] hey slangasek, how are you? [08:11] dholbach: happy flying [08:11] thanks pitti :) [08:12] pitti: hey there! Sorry, I'm late for bed... any chance we can sync up on logind in the "morning"? [08:12] slangasek: I need to go AFK at 1700 UTC for Taekwondo, so anything before that [08:13] pitti: ok [08:13] slangasek: I just talked to mbiebl some more, I have some TODO today for making standalone logind really work === Ursinha_ is now known as Ursinha [08:23] 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:23] bug 1126427 in lcms2 (Ubuntu) "LCMS2 needs multi-threading fixes to work with the new Ghostscript 9.07" [High,New] https://launchpad.net/bugs/1126427 [08:24] cjwatson: code split out of libreoffice. libreoffice 4.0.0beta2 already contained an internal copy (and its a hard dep anyway). [08:26] 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] That should unbreak image builds. === smb` is now known as smb === directhe` is now known as directhex [08:42] cjwatson: huh? bug 1124082 [08:42] bug 1124082 in libmspub (Ubuntu) "[MIR] libmspub" [Undecided,Fix released] https://launchpad.net/bugs/1124082 === yofel_ is now known as yofel [08:53] cjwatson: The libmspub thing was a victim of the overrides bug, it was right in proposed. [08:53] 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] xnox: ah, lovely [09:38] xnox: may I have a bug for that against whoopsie please? [09:38] the upstream project, not the package [09:57] bdrung, do you know somebody who could take a look at https://bugs.launchpad.net/ubuntu/+source/audacious-plugins/+bug/1080059? [09:57] Launchpad bug 1080059 in audacious-plugins (Ubuntu) "ffaudio plugin is not being built " [Medium,Triaged] [10:35] Sweetshark: Ah, right [10:35] infinity: I think the latter. I noticed it in c-m the other day. [10:36] 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] 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] cyphermox: seen bug 1153085 ? [10:42] bug 1153085 in Ubuntu "[FFe] Sync libqmi 1.0-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1153085 [10:43] Drenriza: #ubuntu-app-devel more or less [10:43] Thanks cjwatson [10:45] So what is this channel used for? wiki.ubuntu.com/IRC just describes it as follows "Ubuntu development coordination" [10:46] Development of Ubuntu itself, rather than of third-party programs built on Ubuntu [10:46] (Catch-all; there are also channels for specialised aspects of Ubuntu development) [10:47] When you say Ubuntu itself, you mean the stuff that goes on top of the linux-kernel? [10:48] I mean the contents of the Ubuntu archive [10:48] Ty cjwatson. [10:49] 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] dholbach: quadrispro did the debian upload and the sync. so you could ask him [10:53] cjwatson: i did ponder to set the topic to "Ubuntu Core Development" instead what is currently in the topic "Dev' of Ubuntu ..." [10:54] xnox, "Development of Ubuntu itself (not support or app devel)" perhaps? [10:55] i don't have a strong opinion =) [10:55] Dev' is hard to understand =) [10:56] It's not just core development though [10:56] The apostrophe is fairly silly === cjwatson changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [10:57] (if "devel" is comprehensible in "app devel", it's also comprehensible at the start of that item) [10:57] It's truncated because topic space is scarce [10:59] dholbach: hi [10:59] dholbach: Could you help to review https://code.launchpad.net/~fourdollars/software-properties/fix-1138121-a-typo-in-CountryInformation.py/+merge/151870 ? [11:01] we could probably use a better description in https://wiki.ubuntu.com/IRC/ChannelList too [11:01] "Development of Ubuntu (not support or app devel)" ? [11:01] * tumbleweed sees lots of out of date contact peopl there... [11:02] FourDollars, I pinged mvo about it :) [11:02] FourDollars, but it looks good to me [11:02] wikis ... out of date at creation time :) [11:03] dholbach: Is there any thing I missed? [11:03] ogra_: yeah, the natural state of wikis [11:03] :) [11:03] FourDollars, no, not that I can see [11:03] dholbach: OK. Thanks. [11:27] Does anybody want to test/review quantal pybuild backport? lp:~mitya57/ubuntu/quantal/python3-defaults/pybuild-backport [11:35] 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] ogra_: yeah, it's not great when we're splitting signal in even more places :-( [11:46] Riddell, would you know who could review https://code.launchpad.net/~bkerensa/ubuntu/raring/plasmate/fix-for-1152730/+merge/152538? [11:46] dholbach: just discussing now in #k-d [11:46] ;) [11:46] ah great! :) [11:46] then sleeps [11:53] bdrung, thanks [11:56] @pilout out [11:56] Error: "pilout" is not a valid command. [11:56] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [11:56] udevbot_, yeah yeah [11:56] Error: "yeah" is not a valid command. [11:57] pedantic bot [11:57] tumbleweed: Computers are supposed to be pedantic :) [11:58] s/supposed// [12:09] lool: thanks for ubuntu-platform that's excellent news! [12:10] hmpf [12:11] wasn't there an existing list called ubuntu-platform@l.u.c? [12:11] yeap, for entirely different reasons ;-) === _salem is now known as salem_ === MacSlow is now known as MacSlow|lunch [12:49] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand [13:20] tumbleweed: I hadn't seen the libqmi bug, no [13:20] there's no harm in syncing it now, but we also won't be using it in raring [13:21] yeah, that's basically why he wants it [13:21] err [13:21] tumbleweed: If it's a sync from Debian, I think a new package is fine. [13:21] yup, we should do it [13:22] I mean it's totally safe given that there cannot possibly be anything that uses it in raring [13:22] so yeah, it's fine by me [13:22] should I sync? [13:23] cyphermox: sure, I just acked the FFe [13:23] thanks [13:23] Approved. [13:27] tumbleweed: syncpackage: Error: Not permitted to upload directly to raring; try raring-proposed instead. [13:27] is there a magic trick for syncpackage to be happy? [13:27] Use a modern syncpackage [13:27] ah [13:27] are you trying to use a quantal syncpackage? [13:27] no [13:27] If you don't have one then -r raring-proposed [13:27] sorry, I think we haven't finished reviewing the SRUs for that [13:27] Well, you aren't using raring, or else you have weird local configuration [13:28] cf. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-October/000989.html [13:28] well, I think something is weird yeah [13:28] Perhaps an alias? [13:28] tumbleweed: The SRUs have been in -updates for some time [13:29] 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] cjwatson: oh, I'm thinking of different ones then [13:29] 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] so, precise's one is still in -proposed [13:30] Yes. One bug unverified. [13:30] Oh, so it is [13:30] I've been tempted to release it anyway. [13:30] tumbleweed: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue? [13:31] I think libreoffice-help-* may be busted with 4.0 [13:31] Noticing UbuntuKylin image build failures which seem similar [13:32] tumbleweed: whoops, sorry, I didn't mean you [13:32] ScottK: bdrung couldn't verify that bug on the weekend, I haven't dug into it yet [13:32] mdeslaur: :P [13:32] Sweetshark: dist-upgrade is trying to remove libreoffice-help-fr...is that a known issue? [13:32] tumbleweed: Worst case I think is "it works" [13:33] libreoffice-help-en-us libreoffice-help-zh-cn are not coinstallable [13:34] Blink, there are a load of explicit Conflicts. What are those for? [13:34] ScottK: yeah [13:34] "conflict help language packages in both ways" [13:35] 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] Sweetshark,bdrung: Can you fill me in what's going on with libreoffice-help-* coinstallability? The current situation is rather awkward. [13:35] Sweetshark: This screws over image builds and the installer [13:35] Because there are a number of situations where we install support for multiple languages [13:35] Sweetshark: that's...less than ideal....I can't have two different languages on the same computer anymore? [13:36] I would definitely categorise this as a bug [13:36] * zyga curses at all-things-perl and gets back to work [13:37] mdeslaur: bug 957589 [13:37] bug 957589 in Ubuntu Translations "Localized LibreOffice Help files ignored when help for en-US is installed" [Medium,Triaged] https://launchpad.net/bugs/957589 [13:38] cjwatson: ^^ [13:38] Yes. Please revert. [13:38] This is worse than the previous situation. [13:41] cjwatson: revert *both* conflicts? upstream (Debian) conflicts one way (from en-US to everything else, but not the other way around). [13:41] Sweetshark: Do you understand the problem here? If so then the answer should be clear, I think [13:42] mdeslaur: you can have an many languages as you want as long as none is en-US. [13:42] What's special about en-US? [13:43] 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] 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] 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] Both the Conflicts are a problem. What's the underlying reason that en-US is broken? [13:45] cjwatson: If I know _why_ I would fix it. [13:45] s/know/knew/ [13:45] BTW, having the conflicts both ways achieves nothing over having them only one way round. [13:46] An unversioned Conflicts is a bidirectional relationship (well, in the absence of a matching Replaces). [13:46] cjwatson: bdrung insisted on having them both ways when reviewing the package. [13:47] bdrung: Why? [13:47] either both way conflicts or no conflict [13:47] bdrung: Why? [13:47] Nothing wrong with one-way conflicts [13:47] cjwatson: when updating from 4.0.0beta2 to 4.0.0, en-US would been held back [13:48] bdrung: And Conflicts both ways solves that? How peculiar. [13:48] But in any case that should have been a sign that the Conflicts was a bad idea in the first place :-( [13:49] okay, it's a workaround [13:49] 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] cjwatson: indeed the oneway conflict isnt there in beta2 and was introduced at debian inbetween. [13:50] Hm, 'check-language-support -a -l en' doesn't list libreoffice-help-en-us [13:52] cjwatson: so reverting that is a two-line change. Do you want an upload with just that? [13:53] cjwatson: s/-a/--show-installed/ [13:54] pitti: Oh, yeah, I just figured that out :) [13:54] Sweetshark: When would your next upload be otherwise (roughly)? === MacSlow|lunch is now known as MacSlow [13:56] 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] 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] cjwatson: preparing a source package ... [13:58] Sweetshark: I think we should have such an upload then - thanks [13:59] 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] Won't fix everything but I think it will at least unblock UbuntuKylin image builds, and it seems correct regardless [14:00] cjwatson: k, thanks a lot. [14:00] 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] stgraber: I'll check the other seeds too [14:00] cjwatson: thanks === ckpringle_ is now known as ckpringle [14:02] stgraber: I *think* it's just the Ubuntu GNOME remix, but I'll keep an eye on Edubuntu too === kentb-out is now known as kentb [14:13] cjwatson: any wish for the urgency other than 'low'? If so, which? [14:14] Sweetshark: Doesn't matter; at the moment, nothing in Ubuntu cares [14:14] Sweetshark: Ubuntu doesn't usually use the urgency field [14:14] Well, except for possibly apt-listchanges [14:15] and a slight buildd weight IIRC [14:15] Oh yeah [14:15] Anyway, all my Ubuntu uploads are 'low' [14:15] cjwatson: I thought LP also uses the urgency field to give a slightly higher build score [14:16] Yeah, tumbleweed said that [14:16] It's pretty negligible though; https://help.launchpad.net/Packaging/BuildScores [14:16] It's the least significant automatic score adjustment and more or less never matters [14:18] Right, since I now get to wait for a load of builds I guess it's lunchtime [14:21] 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] cjwatson: the urgency field is nice for ppas though [14:23] stgraber: Hm, I have my session registered in both right now [14:25] 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] Did you actually see problems? [14:26] if so it would be good to note that in the bug ;-) [14:26] I think doing a full transition might be a bit too big for raring [14:27] jbicha: Maybe. The package set adjustment would still dominate. [14:27] 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] 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] pitti: we're having a conversation about logind here, fyi ;-) [14:29] Laney: ah, catching up (me as well, discussing with jdstrand and mbiebl) [14:29] 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] 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] oh, dobey left [14:31] it uses xdg-open [14:32] jbicha: Fair enough; I guess you have more practical experience with waiting for PPA builds than I do :-) [14:32] dobey: apport calls xdg-open, which does a couple of things (gvfs-open, alternative, sensible-browser, etc.) [14:33] Laney: session registered in both> that's CK and loginctl? that's how it ought to be, yes [14:33] yes - stgraber think this will cause problems [14:33] oh, how? [14:33] i.e. the transition must be done fully [14:34] 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] 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] Laney, stgraber: we have a code grep of everything that talks to CK, so we could certainly check those? [14:34] jbicha: heh [14:35] the bits that I looked at either have no clue about logind, or they use #ifdef HAVE_SYSTEMD style [14:35] or they check /sys/fs/cgroup/systemd at runtime (like gnome-shell) and select between the two [14:35] 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] right [14:35] so long as they choose to use one or the other, we should be fine [14:36] I'd say that those would be bugs to fix [14:36] stgraber: btw, I just finished my investigation about programs that check for /sys/fs/cgroup/systemd [14:36] i. e. do they mean "I want systemd init" or "I want logind" or something else [14:37] turns out there's only two packages which actually want systemd init or journal, i. e. not logind [14:37] http://paste.ubuntu.com/5604908/ [14:37] and we don't even ship sysvinit [14:37] so for ubuntu, only one package to fix [14:37] 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] oh well [14:37] dobey: oh, root report [14:38] dobey: I figure it somehow failed to suid back to your user, for a system crash? [14:38] pitti: that's a lot better than I'd have thought ;) [14:38] 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] so it was running as my user. and it was a system crash [14:39] but the theme was wrong, and it was chromium instead of firefox [14:41] 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] Any idea what may cause that? [14:41] mitya57: you need py3cairo from experimental [14:42] pitti: Thanks! Maybe time to bump build-dependency? [14:42] cjwatson: https://errors.ubuntu.com/bucket/?id=/usr/bin/compiz:8:StaticSwitchScreen::getWindowPosition:StaticSwitchWindow::glPaint:GLWindow::glPaint:FadeWindow::glPaint:GLWindow::glPaint [14:44] ignore that, Ubuntu version is older but looks like it includes the fix [14:44] 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] whoops, the diff is reverse [14:49] Sweetshark: please don't forget to tag 4.0.1-0ubuntu1 in git [14:49] bdrung: already done, pushing now [14:49] bdmurray: Thanks, I found it in the end [14:50] Sweetshark: i don't see it. have you pushed the tags, too? [14:50] Sweetshark: LGTM [14:51] bdrung: see the "pushing now" ;) [14:52] bdrung: pushed (also the change for 0ubuntu2) [14:52] Sweetshark: i saw it. probably the web ui lagged. i see it now. === kentb is now known as kentb-afk [14:59] debdiff updated to not be reverse fwiw [15:00] bdrung: will you sponsor? [15:00] Sweetshark: yes [15:00] 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] Sweetshark: have you done a test build? [15:02] Sweetshark: btw, does it make sense to merge debian-experimental-4.0 or wait until raring+1 to do that? [15:02] cjwatson: could you update the packageset ? I've added a couple of packages to the kubuntu supported seed [15:02] bdrung: still running [15:03] jdstrand: where did you run your recent archive grep? I wanted to start one on lillypilly, but its load is > 20 [15:03] shadeslayer: running [15:04] cjwatson: thanks! [15:04] pitti: locally [15:05] jdstrand: ah, ok [15:05] jdstrand: well, I'll look around for another mirror in the DC [15:06] 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] Sweetshark: it contains lintian fixes and the VER removal === jackyalcine is now known as jacky [15:08] Sweetshark: i tend to prefer the merge, because we have just passed the feature freeze and have enough time till the release. [15:10] shadeslayer: done [15:11] * shadeslayer tries uploading again [15:15] cjwatson: works, thanks alot! [15:16] jdstrand: hm, didn't find a good one; would it be very much effort for you to kick off another archive grep? [15:21] pitti: no. what do you need? [15:21] jdstrand: grep -r fs/cgroup/systemd [15:23] ok [15:24] jdstrand: thanks muchly! [15:24] bdmurray: ev: \o/ thanks for the Bug 1056061 [15:24] bug 1056061 in Errors ""First seen" version is wrong in release-specific table" [High,Triaged] https://launchpad.net/bugs/1056061 [15:25] xnox: sure thing. Should land with the rollout planned for today [15:27] pitti: ok, started. it takes a while so I'll let you know when it's done [15:27] jdstrand: sweet, thanks! [15:27] heh, it just found the apparmor one :) [15:32] jdstrand: hm, argh; would it be possible to restart this, with "egrep -r "fs/cgroup/systemd|sd_booted"? [15:33] pitti: sure [15:37] pitti: done [15:37] cheers! === kentb-afk is now known as kentb [16:01] micahg: what have you found using internal Sun Microsystems Java API's? [16:01] micahg: javax.imageio provides a way forward for some bits and pieces [16:28] tkamppeter: ghostscript> please coordinate such questions with #ubuntu-release per my mail, not with me personally [16:30] 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] pitti: hey, so I just dropped a comment on bug #1153224 with some thoughts [16:31] bug 1153224 in systemd (Ubuntu) "[FFE] Move to logind for session tracking" [Undecided,New] https://launchpad.net/bugs/1153224 [16:32] slangasek: thanks; in meeting still, will look ASAP [16:32] bdrung: at packing libreoffice-dbg here btw .... [16:34] slangasek: FYI, I see no problem with kicking CK out of the standard installation -- I've run without CK since last Thursday [16:34] slangasek: I was mainly talking about teh odd universe package, or more importantly, Kubuntu [16:34] 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] slangasek: I want current logind, so that we get the current libraries [16:35] 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] slangasek: I'll chase that up this week and see if we can JFDI. [16:36] 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] infinity: ok. worked on by whom, in theory [16:36] slangasek: right [16:36] pitti: oh. So we would have current udev, but newer libudev? Why do we need newer libudev? [16:36] slangasek: By Ursinha. I'll see where that's gotten to. [16:37] 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] slangasek: so the libudev transition is rather harmless, and I could get that done in a day or two at most [16:40] 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] pitti: are backports/third-party packages the only justification for wanting the ABI bump? [16:40] slangasek: there isn't much difference between the two, so it doesn't matter that much either way [16:41] as for third-party binary stuff, I have no idea what they might prefer [16:41] 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] but most of that will target LTSes, I guess [16:41] slangasek: so, if you want to move to logind without moving to libudev1, we can do that [16:42] either with the current v44, or by disabling the libudev{1,-dev} and gudev bits from 198 [16:42] right - I would be more comfortable with that [16:42] reduces the scope of the transition [16:42] 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] Do we have a udev linked with kmod yet, or would that also come with this transition? [16:43] infinity: we don't, and it wouldn't come [16:43] Oh, shame. [16:43] infinity: as I said, moving to current udev is a lot of work and not proposed [16:43] Kay. [16:43] pitti: "cleaner package" - except this package seems to still not be anywhere authoritative [16:43] I didn't read the full backscroll. :P [16:43] 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] 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] *nod* [16:45] 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] yeah, so was I [16:45] 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] I thought now that libkmod was in, we just needed to rebuild udev; apparently not :/ [16:45] and gets back to work... [16:46] zyga: Movie-related? [16:47] 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] 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] 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] tseliot: 'blacklist' has no effect on udev [16:47] infinity: Mithrandir? [16:47] slangasek: ah, right, thanks [16:47] cjwatson: infinity thinks this is solvable with c-m report fixes, so that seems a better answer [16:47] zyga: infinity is a big toystory fan [16:48] Probably, yes [16:48] slangasek: "alias off" breaks kmod. I need to look into that. [16:48] infinity: cute [16:48] Oh god yes, please do [16:48] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674110 [16:48] Debian bug 674110 in kmod "modprobe: ../tools/kmod-modprobe.c:550: print_action: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed." [Normal,Open] [16:49] nvidia trips over that [16:49] 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] slangasek: we can do a logind transition with 44, yes [16:50] slangasek: the package as it is in raring works fine (modulo adding Conflicts/Replaces: libpam-xdg-support and changing seeds) [16:50] right [16:50] 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] slangasek: hence my idea to update to 198 in universe, and do the MIR/FFE review based on that [16:51] bdrung: build finished here. [16:51] slangasek: we can still disable libudev1 there if we want [16:51] I don't think that's a key point for this cycle [16:51] slangasek: ok [16:51] 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] the decision was already taken in Copenhagen not to update GNOME; we shouldn't rush logind in order to reverse that decision [16:52] slangasek, pitti: logind 44 has some unfixed CVE as well [16:52] seb128: really, which? [16:52] seb128: I only know http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174 [16:52] The rm_rf_children function in util.c in the systemd-logind login manager in systemd before 44, when logging out, allows local users to delete arbitrary files via a symlink attack on unspecified files, related to "particular records related with user session." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174) [16:52] which is fixed in 44 [16:52] 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] pitti, http://secunia.com/advisories/48331/ [16:52] slangasek: oh, I was thinking about the ubuntu gnome remix, not ubuntu itself [16:52] " The weakness is reported in version 44 and prior." [16:52] slangasek: so anyway, we can cut this anyway we like [16:53] slangasek: if you want to go with 44 in raring, that's fine and doable [16:53] slangasek: i. e. we are a MIR and seed change away from this [16:53] (and the FFE, of course) [16:53] hmm, is that all? I thought you had quite a few package rebuilds to enable logind support [16:54] seb128: That's the same CVE as pitti pointed out, so clearly one of those databases is wrong. === deryck is now known as deryck[lunch] [16:54] slangasek: yes, of course [16:54] infinity, pitti: in any case it's a detail, easy to backport a fix if needed at all [16:54] * infinity nods. [16:54] 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] slangasek: ok; but please keep in mind that if we do this we have to keep consolekit in teh default install [16:56] hmm, why? [16:56] slangasek: as e. g. gnome-session requires >= 183 for the inhibit stuff [16:56] ah poo [16:56] the one in raring, I mean [16:56] seb128: the debian patch already contains that patch [16:56] see the 44-1 changelog [16:56] - Backport 693ce21: util: never follow symlinks in rm_rf_children() [16:56] Fixes CVE-2012-1174, closes: #664364 [16:56] mbiebl, oh, great, thanks [16:56] pitti: right, in that case I completely reverse my opinion and think we should update systemd first ;) [16:56] The rm_rf_children function in util.c in the systemd-logind login manager in systemd before 44, when logging out, allows local users to delete arbitrary files via a symlink attack on unspecified files, related to "particular records related with user session." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1174) [16:56]