[04:07] <StevenK> pitti: O hai! I spent some time on the weekend trying to get ekiga to build with the new opal and pt, and it's hopeless. :-(
[04:10] <pitti> Good morning
[04:10]  * micahg thought pitti uploaded a new version of htat
[04:10] <pitti> StevenK: but I already uploaded the new ekiga which works fine
[04:10] <pitti> StevenK: I mentioned that on the bug which opal and ptlib referenced
[04:10] <pitti> StevenK: sorry about the double-work
[04:12] <pitti> bdmurray: it's meant to mark the bug as a dupe of the real master bug
[04:16]  * mneptok waves to pitti
[04:17]  * pitti throws some candies towards mneptok
[04:17] <pitti> mneptok: how are you?
[04:17] <mneptok> pitti: great, thanks!
[04:17]  * mneptok is on a month-long vacation, and is quite relaxed
[04:18] <pitti> mneptok: sounds nice! you are spending it at home, or in the internets? isn't that a good time for travelling etc.?
[04:19] <pitti> uh, half of the armel builders offline?
[04:20] <micahg> pitti: system upgrades, I was told they should be back soon
[04:20] <mneptok> pitti: i spend most days on the motorcycle riding around New Mexico
[04:20] <pitti> ah, cheers
[05:15] <ScottK> slangasek: honeyd FTBFS when rebuild (needed for NBS) looks somewhat multi-arch like to me.  The error is "configure: error: Couldn't figure out how to access libc"
[05:16] <lifeless> ScottK: win!
[05:16] <ScottK> It is because it's clearly too hard for me, so somebody else's problem ...
[05:35] <micahg> doko_: pitti: hopefully by EOD you can remove the old libav binaries (uploaded and building)
[05:35] <pitti> micahg: yay
[05:43] <didrocks> good morning
[05:50] <ScottK> didrocks: I'm about to go sleep, since it's very late here, but I'd appeciate it if you could look into the qt4-x11 build failures today.
[05:55] <didrocks> ScottK: I'll try having a look, not sure I got time (already busy schedule), but will try (saw some build failure on arm, right?)
[06:21] <tkamppeter> pitti, hi
[06:25] <pitti> tkamppeter: hey, how are you? enjoyed your holidays?
[06:52] <doko> didrocks, ScottK see the ftbfs report
[06:52] <didrocks> doko: do you have a bug # handy? (did you subscribe me to it? I didn't see it)
[06:53] <didrocks> I guess it's bug #847224
[06:53] <doko> didrocks, see http://qa.ubuntuwire.org/ftbfs/
[06:55] <didrocks> doko: yeah, I'll see that with ScottK about what to do to reduce the build time as it's the timeout killing the build
[06:55] <didrocks> same on powerpc it seems
[06:56] <micahg> wow, it used to be 10 hrs on armel, I guess it was raised
[06:56] <didrocks> micahg: it's a timeout of no activity while building the documentation
[06:57] <micahg> didrocks: I understand, the timeout used to be 10 hrs, I guess it's now 13.3
[06:57] <doko> 800min ...
[07:00] <didrocks> doko: anyway, the -doc packages are arch:all as you infered, let me see how to disable the build for other archs
[07:07] <didrocks> hum, nice, seems Qt doesn't have an option to disable the build of documentation
[07:08] <didrocks> seems it will need a painful patch arch-dep
[07:09] <dholbach> good morning
[07:10] <poolie> hi all
[07:10] <poolie> could someone from the sru team (or archive admin?) promote the fix for https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/736216 in natty?
[07:10] <didrocks> hey dholbach, poolie
[07:11] <poolie> hi there
[07:11] <poolie> ... or, let me know what needs to be done
[07:14] <dholbach> hey didrocks, hi poolie
[07:15] <poolie> hi there
[07:15] <doko> cjwatson, so building with -DGDK_DISABLE_DEPRECATED seems to be as bad as -Werror ...
[07:18] <poolie> didrocks, could you suggest what i should do to get that sru to move?
[07:19] <doko> micahg, did the qt4 security upload fail with this doc timeout too?
[07:20] <didrocks> poolie: it seems you subscribe the ubuntu-sru team to it, isn't it? but the Natty curl status is fix committed, is there any reason?
[07:20] <didrocks> "Accepted curl into natty-proposed" oh, it's already in -proposed
[07:20] <poolie> i think the state is fixed in -proposed, not yet fixed in -updates
[07:21] <poolie> it's in proposed
[07:21] <poolie> it apparently works
[07:21] <poolie> it needs to go into -updates
[07:22] <didrocks> yeah, and there is verification-done-natty (but still verification-needed, I guess for other?) not sure if that puzzles pitti's script
[07:22] <poolie> perhaps that's it
[07:22] <didrocks> let's wait for him to have some time to have a look :)
[07:23] <pitti> v-done-release is an invention of the kernel team, this tag isn't recognized by the SRU report page
[07:23] <pitti> it should just be v-done
[07:23] <pitti> anyway, can release now
[07:23] <poolie> thanks
[07:23] <pitti> done
[07:29] <poolie> thanks pitti
[07:49] <dholbach> @pilot in
[07:53] <poolie> i'm surprised that ntfs mounts with umask=0 by default, although mount(8) says it's umask=077
[07:53] <poolie> is that an intentional ubuntu change?
[07:55] <tkamppeter> pitti, it is about bug 807261, the problem of cups-pk-helper breaking s-c-p.
[07:55] <tkamppeter> pitti, I have added a longer comment to it.
[07:56] <jamespage> morning all
[07:56] <jamespage> doko - any chance you could sponsor those two branches you reviewed for me on Friday?
[08:19] <doko> jamespage, sure
[08:19] <jamespage> doko: thanks
[08:29] <cjwatson> micahg: some of libav will still have to wait for insighttoolkit to finish its eight-day or whatever it is armel build so that itksnap and vmtk can be fixed - but yes, gnash was the other blocker, so thanks!
[08:30] <cjwatson> doko: yeah, it should be a maintainer-only thing rather than a release tarball thing
[08:30] <cjwatson> doko: also -DALLSORTSOFOTHERTHINGS_DISABLE_DEPRECATED
[09:02] <tkamppeter> pitti, ping
[09:05] <pitti> tkamppeter: pong
[09:12] <tkamppeter> pitti, have you seen my message above?
[09:12] <pitti> tkamppeter: yes; do you need me to do anythign with this bug?
[09:13] <tkamppeter> pitti, I want to know what you think is the best solution without loosing any functionality.
[09:14] <tkamppeter> pitti, There are the following possibilities:
[09:14] <pitti> why do we need cups-pk-helper?
[09:14] <pitti> for s-c-p?
[09:14] <pitti> we haven't before
[09:14] <pitti> I thought it's only needed for the upstream control-center printer capplet
[09:14] <pitti> (which we don't use in ubuntu/unity, just with gnome shell
[09:15] <tkamppeter> pitti, s-c-p does not need cups-pk-helper, so if there is nothing else needing it, one could simply make sure that it does not get pulled into the default installation.
[09:15] <pitti> tkamppeter: it doesn't
[09:15] <pitti> tkamppeter: if you install gnome-shell, it will be pulled in
[09:16] <tkamppeter> pitti, what pulls it in currently is gnome-shell and gnome-shell I have installed, probably because my Oneiric is grown out of daily updates from Natty.
[09:16] <pitti> does it hurt to have it installed?
[09:16] <tkamppeter> pitti, we must assure that updaters from Natty and older will not get cups-pk-helper pulled in.
[09:17] <pitti> the upstream capplet is hidden in the control center under UNity
[09:17] <pitti> so nothing ought to invoke it?
[09:17] <pitti> tkamppeter: why?
[09:17] <pitti> tkamppeter: I thought s-c-p wouldn't use cups-pk-helper; you mean it does?
[09:17] <tkamppeter> pitti, yes, if cups-pk-helper is installed, s-c-p asks for an admin password, even if the user is in the lpadmin group.
[09:17] <pitti> bah
[09:18] <pitti> it oughtn't
[09:18] <pitti> tkamppeter: we can't assure that cups-pk-helper isn't installed, as people might have gnome-shell installed
[09:19] <cjwatson> hyperair: could you please confirm my last comment in bug 756161?
[09:19] <pitti> tkamppeter: can we disable cups-pk-helper support in s-c-p easily? does it have a configure option?
[09:19] <tkamppeter> pitti, I can also patch away the cups-pk-helper support in s-c-p by adding only two lines.
[09:19] <tkamppeter> pitti, it is not a configure option, it is setting a variable to False at two points.
[09:20] <hyperair> cjwatson: ah, that package's been obsoleted by geany-plugins afaik
[09:20] <hyperair> cjwatson: rm please
[09:20] <cjwatson> hyperair: right, that was what I said in my comment :)
[09:20] <cjwatson> hyperair: shouldn't geany-plugins-doc Breaks/Replaces geanydoc as well though?
[09:20] <hyperair> did you?
[09:21] <cjwatson> hyperair: oh, it might not quite have saved yet when I asked you, reload
[09:21] <pitti> tkamppeter: do you think that would be okay? it seems like the best solution to me
[09:21] <tkamppeter> pitti, best solution would be to fix cups-pk-helper to support the user-in-lpadmin-group case, but probably this is more work, and not easy to project into the architecture of PolicyKit.
[09:22] <pitti> tkamppeter: right
[09:22] <pitti> tkamppeter: I think if/when we switch to cups-pk-helper and the upstream applet, we'll deprecate lpadmin in the desktop
[09:22] <hyperair> cjwatson: right, i guess it should.
[09:22] <pitti> it's one of the few "hardware access" groups that we still have, and it's a thorn in the eye
[09:22] <cjwatson> hyperair: want a separate bug?
[09:23] <hyperair> cjwatson: actually no. geanydoc is the source package name.
[09:23] <hyperair> cjwatson: geany-plugin-doc is the binary package name
[09:23] <cjwatson> oh
[09:23] <hyperair> Package: geanydoc
[09:23] <hyperair> Binary: geany-plugin-doc
[09:23] <hyperair> Version: 0.4-0ubuntu3
[09:23] <pitti> tkamppeter: we can then even configure polkit to allow access to local printers from a local desktop session (as these users have physical access anyway)
[09:23] <cjwatson> so it's just an orphaned source package then, fine
[09:23]  * cjwatson really must produce a report of those
[09:23] <hyperair> well more like it should have been removed
[09:23] <hyperair> i thought i got rid of all those already
[09:23] <hyperair> hmm
[09:25] <cjwatson> hyperair: oh well, this one's gone now, thanks
[09:26] <hyperair> cjwatson: geanyprj also needs to be removed.
[09:26] <hyperair> and that should be it.
[09:27] <cjwatson> hyperair: that was done a while back, bug 825069
[09:27] <hyperair> ah okay.
[09:27] <hyperair> then that should be it :-)
[09:27] <cjwatson> excellent
[09:27] <tkamppeter> pitti, another solution would s-c-p trying cups authentication not allowing a password prompt and only if the authentication fails try cups-pk-helper and as last mean try cups authentication with password. But this would be a bigger change, perhaps not doable for Oneiric.
[09:28] <pitti> tkamppeter: yeah, that even sounds upstreamable then
[09:30] <tkamppeter> pitti, this would be a good idea, switch to PolicyKit instead of lpadmin-group-based access in s-c-p (keep lpadmin group only for the command line utils of CUPS) and allowing general access to locally defined print queues for local desktop users.
[09:31] <tkamppeter> s/general access/general passwordless access/
[09:39] <Daviey> Does syncpackage, when sponsoring a sync with a bug number default to giving attribution to the bug reporter?
[09:39] <tumbleweed> not yet
[09:39] <Daviey> tumbleweed: thanks.
[09:40] <tumbleweed> Daviey: Bug 827608
[09:41] <tumbleweed> actually that's not even the sponsorship one, that's just a pre-requisite
[09:41] <Laney> that was about self syncs
[09:41] <Laney> sponsored syncs are in another one
[09:42] <Laney> ah, which is linked frmo there: bug 827555
[09:42] <Daviey> tumbleweed: ah! making good progress :)
[09:42] <tumbleweed> Daviey: unfortunatly the sponsorship one is of low importance, so it may take a while...
[09:43] <Laney> we can probably get people interested
[09:44] <Laney> they seem good like that on this feature
[09:45] <Daviey> \o/
[09:46] <Daviey> Well i just did a sync which should have been sponsored, and yes - i now feel like an ass.
[09:46] <Daviey> I don't think the chap will mind, thankfully.
[09:47] <Laney> did the tool make you think it was going to be credited correctly?
[09:47] <tumbleweed> it looks like we're going to have to sneak one more upload in, we can mention that
[09:48] <Daviey> Laney: well.. i hoped :).. Considering it said i /could/ overwrite it if i appended --no-lp
[09:48] <Daviey> so i thought! Ah!, it must be smart enough :)
[09:48] <Daviey> Although, i did suspect it might not be.. having ack-sync pulled out from under me was kinda frustrating.
[09:50] <tumbleweed> I don't think it's worth using --no-lp just for sponsorship attribution (I asked sponsorees if they minded not being attributed, and they didn't care)
[09:55] <Laney> :q
[09:56] <Laney> there appear to not be any open sync requests to test how sponsor-patch works
[09:56] <Laney> woe
[09:57] <Daviey> So syncpackage is still expected to close the bug, and not launchpad?
[09:57] <Daviey> Not ideal when the sync isn't automagic.
[09:57] <Daviey> as in, NEW.
[09:57] <Daviey> Laney: I have one you can hijack.
[09:58] <Laney> that's no worse than how it was before, but it might have been an opportunity to only close bugs on publication, indeed
[09:59] <tumbleweed> but there's another feature request bug open for this
[10:00] <tumbleweed> (although I doubt that'll help with the NEW case)
[10:15]  * didrocks wonders why he gets some FTBFS on other deps not yet published on the same arch (explicitely set in debian/control)
[10:16] <didrocks> was the same with unity-2d last Friday
[10:19] <tkamppeter> pitti, for me it looks like that the quickest solution to solve the s-c-p/cups-pk-helper incompatibility problem in Oneiric is to apply the 2-line patch to make s-c-p not using cups-pk-helper.
[10:20] <tkamppeter> pitti, letting s-c-p try password-less CUPS auth before PK auth and then passworded CUPS auth is a good idea to suggest upstream, too complicated to rush into Oneiric.
[10:25] <tkamppeter> pitti, I am trying now another possible solution: Using, as you suggested, cups-pk-helper but opening up the right to manipulate local queues for all local desktop users without password. password is only needed for server settings and manipulating remote printers.
[10:26] <tkamppeter> pitti, this I am doing by replacing most "auth_admin_keep" by "yes" in /usr/share/polkit-1/actions/org.opensuse.cupspkhelper.mechanism.policy.
[10:27] <tkamppeter> pitti, WDYT? Which method should we use in Oneiric?
[10:38] <tkamppeter> pitti, if we opt for using the cups-pk-helper-based solution, I can patch s-c-p to check for the SSH_CLIENT env variable to not use PK is s-c-p is run through SSH, a ~6 lines patch.
[10:51] <debfx> mvo: would it be a problem for app-install-data if kubuntu stopped stripping translations from desktop files?
[10:54] <bdrung> Laney, Daviey, tumbleweed: sponsor-patch just calls syncpackage (without --no-lp) and due to the mentioned bug it does not yet support crediting the requester.
[10:56] <Laney> bdrung: shouldn't it do the AA way until that is fixed?
[10:57] <bdrung> Laney: good idea. i hoped that this will be fixed before oneiric is released
[10:57] <Laney> no idea about that
[10:59] <tumbleweed> it won't be able to credit the requestor without an API change on teh launchpad function, so that seems to be a safe thing to do
[11:08] <pitti> tkamppeter: re (sorry, was at lunch)
[11:09] <pitti> tkamppeter: no, please don't replace with "yes", we should only do that for users who are in the "admin" group already
[11:09] <pitti> tkamppeter: I think for oneiric we should just do the 2-line patch you suggested
[11:18] <bdrung> tumbleweed: btw, the changes are ready for oneiric. currently sponsor-patch doesn't support sync request at all. now it supports it (except the crediting)
[11:22] <tkamppeter> pitti, OK, will do so.
[11:23] <pitti> tkamppeter: thanks
[11:23] <diwic> pitti, is there a way to force a proper retrace of bug 838453 ? Apport's conclusion is wrong.
[11:25] <tkamppeter> pitti, admin-group-only authentication (but asking for password) is the standard scenarion if one does not change the cups-pk-helper configuration. Would be great if cups-pk-helper would give the possibility to allow access for users in the admin group (in the lpadmin group) without asking for their password if they are logged in on the desktop already.
[11:25] <pitti> tkamppeter: yes, that's possible, just not in the .policy file
[11:26] <pitti> tkamppeter: but as we don't use cups-pk-helper, I wouldn't change it in oneiric now
[11:26] <tkamppeter> pitti, so this would be a feature request for cups-pk-helper in Powerful Pitti, our next LTS.
[11:26] <pitti> tkamppeter: heh
[11:27] <pitti> tkamppeter: actually it would go into policykit-desktop-privileges, but either way, it's a simple change; I can do it easily
[11:28] <tkamppeter> pitti, great. Will you add this to your TODO list or should I report a bug?
[11:28] <pitti> tkamppeter: bug report will do fine
[11:29] <pitti> we can target it to P
[11:29] <tkamppeter> pitti, OK.
[11:29] <Laney> cjwatson: pitti: I'm confused about appointing the new DMB member. Does the TB need to confirm it?
[11:30] <pitti> Laney: erm, shouldn't DMB members be voted on?
[11:30] <Laney> it has been?
[11:30] <pitti> I thought the current DMB was the result of a poll
[11:30] <Laney> did you miss the election?
[11:30] <mvo> debfx: I don't think so, should be fine
[11:30] <pitti> yeah, that's what confused me; what does the TB need to confirm then?
[11:30] <pitti> Laney: ah, you mean adding it to the team?
[11:30] <Laney> the results of the poll
[11:31] <Laney> well, that too
[11:31] <cjwatson> TB is the administrator so would need to take action on it
[11:31] <Laney> I am asking if the TB needs to explicitly confirm
[11:31] <Laney> or just push the buttons to add the new member
[11:31] <cjwatson> I think we just push buttons
[11:31] <pitti> I wouldn't see why, but I might miss something
[11:32] <Laney> I thought I recalled you ratifying previous polls, but good
[11:33] <Laney> was concerned because at the last minute I can't make the meeting tonight, so I wanted to ensure that micahg can be a full member at it
[11:33] <pitti> Laney: I actually voted, I just seem to have missed the announcement of the result
[11:34] <Laney> hasn't been done yet until after it's confirmed at this meeting
[11:34] <Laney> but you can see the result on your poll link
[11:38] <Laney> (FYI I have been trying to follow https://wiki.ubuntu.com/CommunityCouncil/Restaffing but found it a bit confusing on this point)
[11:41] <pitti> does anyone have an idea how I work around the "Server presented certificate that does not match host staging.launchpad.net"  lplib error when trying to connect to staging?
[11:41] <pitti> ('DNS', '*.staging.launchpad.net')
[11:42] <pitti> that doesn't seem to include "staging.lp.net" itself
[11:42] <pitti> ah, ignore me, it's the second part of subjectAltName, so it ought to work?
[11:50] <pitti> ah, bug 839826 ?
[11:50] <pitti> this even has a patch, trying that
[11:56]  * Laney ran into that on Debian too
[11:59] <pitti> works fine, sponsoring this
[12:04] <Laney> DktrKranz: tumbleweed: ^ any chance of uploading to debian?
[12:10] <DktrKranz> Laney: could do, non sure about "when"
[12:10] <Laney> as you please, I built a package for myself
[12:11] <DktrKranz> I think I could be able to prepare an upload on Wed at latest
[12:12] <Laney> :-)
[12:39] <jml> pitti: I'm still getting those tracebacks in .xsession-errors: http://paste.ubuntu.com/687590/
[12:40] <pitti> jml: i. e. this still crashes for you? python -c 'from gi.repository import GLib; print GLib.markup_escape_text("a&b")'
[12:40] <jml> pitti: yes. TypeError: markup_escape_text() takes exactly 2 argument(s) (1 given)
[12:41]  * pitti scratches head -- this is oneiric current?
[12:41]  * pitti tries on current live CD
[12:42] <jml> pitti: yes. fresh update today.
[12:42] <jml> pitti: if you want, I can give you some package versions.
[12:42] <jml> pitti: but I'd neet to know which ones are relevant
[12:42] <pitti> jml: I first test on current live CD, to check whether it's my system that is non-standard somehow
[12:43] <jml> pitti: makes sense. thanks.
[12:43] <pitti> no, works on current desktop live CD
[12:43] <pitti> jml: dpkg -l libgirepository-1.0-1 gir1.2-glib-2.0 python-gobject
[12:44] <jml> pitti:
[12:44] <jml> http://paste.ubuntu.com/687594/
[12:44] <pitti> gir1.2-glib-2.0     1.29.16-0ubuntu1
[12:44] <pitti> there you go
[12:45] <pitti> jml: you want 1.29.17
[12:46] <pitti> jml: strange that you got the current version of libgirepository-1.0-1, it's built from the same source
[12:46] <jml> pitti: for some reason, it's kept back
[12:46] <pitti> what does sudo apt-get install gir1.2-glib-2.0 say?
[12:47] <pitti> it might want to remove something, so don't say yes, just check what it complains about
[12:47] <cjwatson> down to merely nine LP-batched pages of build failures ...
[12:47] <pitti> jml: ^
[12:48] <jml> cjwatson: yay progress?
[12:48] <pitti> jml: well, I was referring to what I said before, but agreed to "yay progress" :)
[12:48] <cjwatson> after a long and protracted war of attrition, the enemy is now merely nine times our size
[12:48] <jml> pitti: will do. just need a sec for an upgrade I started to finish.
[12:49] <cjwatson> but I think the lesson is "don't let the enemy get that large in the first place"
[12:50] <pitti> cjwatson: doesn't the vast majority of the universe FTBFS just happen due to us having a different toolchain and through bad luck through autosyncs?
[12:50] <jml> pitti: I think it just wants new packages: python-gobject-2
[12:50] <pitti> i. e. do we actually have a realistic alternative to not introduce these?
[12:50] <jml> pitti: nothing being removed
[12:50] <pitti> jml: that's right
[12:50] <pitti> jml: so it seems you have the old python-gobject, too
[12:50] <cjwatson> pitti: no, but we did have a realistic alternative to leaving them untended for > six months
[12:50] <pitti> jml: yes, you do
[12:51] <jml> pitti: yeah, I do. Have just installed the latest gir1.2-glib-2.0
[12:51] <cjwatson> with a large queue, people get into the mindset that build failures are basically normal and that there's no rush
[12:51] <pitti> jml: don't you use dist-upgrade? a mere upgrade will hold them back, right
[12:51] <jml> pitti: my dist-upgrade has been broken for a while.
[12:51] <pitti> cjwatson: agreed to > 6 months
[12:51] <jml> pitti: http://paste.ubuntu.com/687600/
[12:52] <pitti> it's just not something I like to see us spending manmonths on right after the autosync wave
[12:52] <cjwatson> the vast majority are easy; I fixed 15 build failures yesterday despite only being around for a few hours on a Sunday when others were asleep; if we'd been putting in consistent effort, there wouldn't be a problem
[12:52] <pitti> jml: hm, flashplugin-installer is at 10.3.183.7ubuntu1
[12:53]  * jml checks ppa
[12:53] <jml> s
[12:53] <jml>  flashplugin-installer : Depends: flashplugin-downloader but it is not installable
[12:54] <cjwatson> (this is not to say that some people haven't been putting in consistent effort, but there aren't enough of them)
[12:56] <Laney> which ftbfs list are you using?
[12:56] <cjwatson> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ftbfs
[12:56] <Laney> ta
[12:56] <Laney> nemerle is binaries removed; close?
[12:57] <directhex> IMHO we should just kill nemerle for real
[12:57] <directhex> it's been a waste of archive space for years
[12:58] <cjwatson> Laney: it'll still show up in test rebuilds if binaries are removed; if you close the bug it will just get refiled at some point, unless the source is removed
[12:59] <cjwatson> removing binaries is a solution of sorts to NBS, but it doesn't eliminate FTBFS
[12:59] <Laney> yeah we should probably just get it killed
[12:59] <cjwatson> I don't object but would need a bug with rationale
[13:00] <Laney> I have definitely made a net negative contribution to package numbers in Debian since I became a DD
[13:01] <pitti> Laney: well, quality > quantity :)
[13:01] <jml> Oh. Hmm.
[13:02] <jml> flashplugin-downloader exists, but only for i386. amd64 seems to be out of luck.
[13:03] <pitti> jml: flashplugin-downloader:i386 exists
[13:03] <pitti> jml: perhaps you upgraded to oneiric early, but didn't set up multiarch as per slangasek's announcement?
[13:03] <cjwatson> the idea was to magically transition people to that, but I don't think it's completed yet
[13:03] <jml> pitti: well, *that* sounds plausible :)
[13:03] <cjwatson> oh, could just be that, yes
[13:04] <pitti> he made it sound like natty -> oneiric beta upgrade would work, but natty -> alpha-2 -> beta-1 wouldn't
[13:04] <pitti> jml: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
[13:04] <jml> pitti: yeah, got it, thanks.
[13:05] <didrocks> jml: I guess it's https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
[13:05] <jml> didrocks: thanks. I think I've got it though :)
[13:06] <didrocks> jml: oupss, seems I didn't read the 2 last lines, sorry for repeating :)
[13:07] <jml> didrocks: that's ok. :)
[13:10] <debfx> pitti: pkgbinarymangler doesn't touch .desktop files if they don't have a Gettext-Domain key, right?
[13:10] <pitti> debfx: it adds X-Ubuntu-Gettext-Domain to .desktop files if it can figure out the domain
[13:11] <pitti> (and then removes translations)
[13:11] <debfx> pitti: oh, how does it figure out the domain?
[13:12] <pitti> debfx: ah, sorry, I mixed that up
[13:12] <pitti> debfx: the answer to your question is "yes"
[13:12] <pitti> debfx: dh_translations adds the -Domain: key
[13:13] <debfx> ok, thanks
[13:13] <pitti> debfx: (it's built from pkgbinarymangler source, but it's not done by pkgbinarymangler, the binary package)
[13:14] <pitti> debfx: dh_translations checks a few standard places, like po/Makefile ("GETTEXT_PACKAGE"), setup.cfg ("domain="), and some cmake equivalent
[13:14] <pitti> everything which doesn't use standard intltool/automake/python distutils/cmake needs to be fixed manually
[13:15] <doko> pitti, alamanah and seahorse-plugins need a new upload
[13:15] <debfx> pitti: dh_translations isn't run automatically though?
[13:15] <pitti> doko: seahorse-plugins is gone
[13:16] <pitti> debfx: no by debhelper; it's done by cdbs' gnome.mk (and perhaps pkg-kde-* cdbs modules)
[13:16] <doko> pitti, fine, then please re-upload alamanah
[13:16] <pitti> debfx: there's a --with-translations dh module
[13:16] <pitti> doko: ah, you removed the binaries; right, doing
[13:18] <pitti> doko: uploaded; will depwait until the libcruptui binaries get NEWed and published, but will sort itself out
[13:19] <Laney> we can fix gdcm by syncing
[13:19] <Laney> not sure if it needs ffe though
[13:21] <Laney> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.0.18 "probably"
[13:39] <doko> Sweetshark, please could you have a look at https://launchpad.net/bugs/835773
[13:41]  * Sweetshark looks
[13:42] <Sweetshark> eek, that dep might be ugly.
[14:06] <hallyn> anyone in coredev have a few minutes to take a look at the fix for bug 838205 ?
[14:06] <hallyn> systemtap is unusable in o without it
[14:07] <hallyn> zul: ^
[14:09] <zul> hallyn: sure
[14:09] <hallyn> zul: thanks
[14:30] <tkamppeter> pitti, s-c-p uploaded and PK changes reported as bug 847896.
[14:30] <pitti> tkamppeter: I saw, thanks!
[14:37] <charlie-tca> Can I assign bug 845549 to the desktop team?
[14:54] <dholbach> pitti, I think I can close https://bugs.launchpad.net/ubuntu/+source/python-httplib2/+bug/839826?
[14:54] <pitti> dholbach: oh, didn't that get auto-closed with the upload?
[14:54] <dholbach> ok, closing :)
[14:55] <Laney> Closes: vs. LP: ;-)
[14:56] <pitti> argh, sorry
[14:56] <pitti> dholbach: thanks!
[14:56] <dholbach> de rien
[15:12] <dholbach> Laney, do you think you can update your debdiffs.txt list?
[15:12] <Laney> what for?
[15:12] <Laney> bdmurray is tagging new ones
[15:13] <Laney> s/tagging/dealing with/ (by subscribing spnosors)
[15:13] <dholbach> oh, so they should all turn up on the sponsoring overview?
[15:13] <dholbach> so is there a list of "old ones"?
[15:13] <Laney> we only have to deal with the backlog
[15:13] <Laney> that's my file
[15:13] <dholbach> ok, can you update it? :-)
[15:14] <dholbach> I came across a few ones that luckily were closed already
[15:14] <Laney> closed since I generated it?
[15:14] <dholbach> yep
[15:16] <Laney> alright
[15:16] <dholbach> thanks muchly
[15:17] <Laney> dholbach: if I give you the script, can you get it running on some qa machine?
[15:17] <dholbach> I guess I can - what does it need?
[15:17] <Laney> just lplib
[15:18] <dholbach> ok cool
[15:24] <ubuntu__> hi all, Q). lh config --mode ubuntu --tasks "ubuntu-live" --distribution lucid hangs on grub, creating file /etc/default/grub/
[15:32] <ximion> hi! could someone who has the required rights please mark lp bug #847591 as priority:"high" and mark it as "needs to be fixed until oneiric release" (target it to oneiric)?
[15:33] <cjwatson> ximion: done
[15:33] <ximion> cjwatson: Thanks!
[15:34] <ximion> this bug renders PK unusable and will result in an FTBFS very soon, if it is the bug I have in mind
[15:34] <ximion> (I'll provide a fix asap)
[15:40] <dholbach> doko, I'll close https://bugs.launchpad.net/ubuntu/+source/seahorse-plugins/+bug/832888 - it seems the package was removed from oneiric
[15:41] <doko> dholbach, yes, scroll back for pitti's comments
[15:41] <dholbach> thanks
[15:48] <desrt> doko: hey.  i was wondering if you could take a look at https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
[15:49] <desrt> doko: it's causing the compiles for glib to occasionally hang on the builders
[15:51] <doko> desrt, you're sure that this is not an glib issue?
[15:51] <desrt> doko: i've attached a testcase that's written against pure libc
[15:51] <desrt> doko: so it's either libc or kernel
[15:51] <desrt> and i suspect libc (for reasons listed in the bug)
[15:52] <doko> geser, pitti: vala issues in bug 832770 and bug 832760
[15:53] <doko> soren, zul: does this still belong to server? bug 836997
[15:53] <dholbach> @pilot out
[15:54] <zul> doko: dont think so
[16:10] <doko> apw, ogasawara: is uns still maintained by the kernel team? or can it be removed? see bug 756096
[16:11] <apw> doko, erm no idea.  will have a look
[16:12] <ogasawara> doko: I'm unaware of anyone from our team maintaining it.
[16:14] <doko> jamespage, could you have a look at 835757? new minor upstream version in debian, which seems to address the build failure
[16:15] <jamespage> looking at bug 835757 now
[16:20] <bregma> hey folks, I have a fix for a FTBFS bug in oneiric but I'm not sure where to go next, could I get some guidance?
[16:21] <infinity> bregma: Follow up to the launchpad bug (or file one, if there isn't one) with a patch?
[16:22] <bregma> what kind of a patch?  a merge request?  a debdiff?
[16:22] <infinity> "A patch".
[16:22] <infinity> People are far too picky about how they get their patches, and they shouldn't be.
[16:23] <infinity> If you fixed the package, show us how.  Leave it to someone actually uploading the fix to worry about how to make it get there. ;)
[16:24] <cjwatson> infinity++
[16:24] <cjwatson> (aleph-2?)
[16:25] <bregma> I have no idea what ;people uploading the fix' prefer, but I can provide any of debdiff, merge request to the repo on launchpad, or bare diff if that what someone would rather have, how am I supposed to tell?
[16:25] <infinity> bregma: I like simple patches or debdiffs.  Others like merge requests.  Others still might like you to phone them and explain the fix.  I say, do what you find works best for you.
[16:26] <infinity> bregma: We can deal with most/all of the above, and fretting over how you submit a patch isn't my idea of fun.  Just give us what works for you, and we'll make it work for us.
[16:27] <dholbach> yeah, just attach the patch on the bug in LP (if there's a bug already) and subscribe ubuntu-sponsors - that should work
[16:28] <nigelb> infinity: That's one of the best advice I've heard :)
[16:28] <apw> doko, ok so this usn build failure seems to be include foobar again
[16:41] <jamespage> doko: minor version upgrade on uimaj looks fine for sync - however will need a sync of maven-repo-helper as has a minimum required version higher that we have in oneiric by +x.x.1 which looks OK to me as well
[16:42] <doko> jamespage, thanks, could you update the report?
[16:42] <jamespage> doko: ack
[16:45] <jamespage> doko: done
[16:49] <doko> barry: please could you have a look at bug 835762? python2.6 hard coded?
[16:50] <micahg> barry: is there a reason why python-debian wasn't converted to dh_python2?
[16:54] <Laney> dholbach: I'd forgotten how long this script takes to run ...
[16:54] <dholbach> :)
[16:55] <doko> apw, so yes, the world moves around the kernel ;-P
[16:55] <apw> doko, no i mean its another case of broken handling of the includes ... different though, and not kernel fault, am working on fixing it
[16:55] <doko> ahh, ok
[16:56] <apw> doko, looks like long standning bad code.  probabally the compiler stopped doing something evil and it broke
[16:59] <ejat> hi .. anyone looking into bug 811441
[17:02] <SpamapS> hmm.. would it be an accurate statement that the alternate and mini isos don't use ubiquity at all?
[17:04] <cjwatson> SpamapS: yes, except for oem-config
[17:07] <SpamapS> cjwatson: I've just redirected bug 847782 to d-i from ubiquity then.. I'm thinking this is actually correct behavior from d-i .. and we may just close the bug.. but its probably worth a bit of discussion first.
[17:08]  * SpamapS already s/Ubiquity/installer/ as well
[17:09] <cjwatson> I'll have a look when my internet access isn't made of stale cheese.
[17:13] <cjwatson> SpamapS: surely this is a bug in the new upstart network jobs?  the 'auto' line has been there a lot longer than they have; they're what broke things
[17:15] <cjwatson> (unless the pre-upstart init scripts behaved the same way; I forget)
[17:18] <ScottK> SpamapS: Can haz clamav in -updates?
[17:21] <ejat> thanks cjwatson
[17:22]  * ejat just upgrade to oneiric .. need to do the manual work around .. 
[17:22] <SpamapS> ScottK: I did that last Friday I thought
[17:23] <SpamapS> ScottK: its possible that sru-release timed out.. Is clamav big?
[17:23] <ScottK> Not really.
[17:23] <SpamapS> cjwatson: the pre-upstart scripts would wait for 1 minute per interface.
[17:23] <ScottK> https://launchpad.net/ubuntu/natty/+source/clamav says it's not there.
[17:23] <SpamapS> cjwatson: upstart did away with that waiting.
[17:24] <SpamapS> cjwatson: which caused *a lot* of issues for server users with complex network setups.
[17:25] <SpamapS> cjwatson: so the idea now is to wait only if its listed in /etc/network/interfaces .. but I may have underestimated how many people have an 'auto eth0' that will never come up. :-P
[17:26] <SpamapS> ScottK: indeed it did not go through. Trying again.
[17:26] <ScottK> Thanks.
[17:29] <SpamapS> ScottK: succeeded this time
[17:29] <ScottK> Cool.  Thanks again.
[17:34] <ghostcube> ich kenne einen philosophie studenten der hat nen job gefunden :D
[17:34] <ghostcube> nanananana
[17:35] <ghostcube> ups wrong channel lol
[17:35] <ghostcube> i hate quassel sometimes
[17:35] <ghostcube> :D
[17:35] <ghostcube> sorry guys
[17:52] <barry> ScottK: or other kubuntuistas.  i just grabbed the daily image for kubuntu amd64, but when i try to install it in a vm, i get "No installable kernel was found in the defined APT sources".  it ask if i want to continue w/o installing a kernel, which the warning makes me think is a bad idea.  does anybody know if this is a temporary (i.e. archive) problem, or something more serious that warrants a bug report?
[17:52] <barry>  
[17:52] <ScottK> It was temporary.
[17:53] <ScottK> The alternates were rebuilt after and should work.
[18:05] <barry> ScottK: cool, thanks, i'll try again
[18:08] <bdmurray> Is there somebody who might review my apport merge proposal and upload it?
[18:08] <bdmurray> https://code.launchpad.net/~brian-murray/apport/ubiquity-dupe-sig-improvements/+merge/75050
[18:38] <doko> barry, please don't set reports like bug 835001 to incomplete. it's reproducible in the rebuild. it doesn't have to ftbfs in the main archive
[18:39] <barry> doko: how can you debug it if it only ftb in the test rebuild then?
[18:41] <doko> barry, does it really build in a clean/fresh pbuilder chroot?
[18:41] <doko> most likely an issue with python versions
[18:41] <barry> it built in my sbuild cleanly.  i'll retry it in pbuilder after finishing up on python-django-nova
[18:42] <doko> Sweetshark, ooo-build-extensions is still in unstable, black-list it?
[19:03] <doko> barry, fix uploaded
[19:03] <barry> doko: fix for...?
[19:03] <doko> the build failure
[19:04] <barry> doko: acidobasic?
[19:04] <doko> yes
[19:04] <barry> doko: okay cool, thanks
[19:05] <doko> Laney, https://launchpadlibrarian.net/79716630/buildlog_ubuntu-oneiric-i386.fregression_2100.76-3_FAILEDTOBUILD.txt.gz
[19:12] <SpamapS> Hrm, so I just found that sary-ruby ftbfs on Ubuntu where it does build on sid because of libglib being multi-arch .. is Debian headed that direction already?
[19:27] <NCommander> Who maintains the rmadison CGI? I'd like to see it properly work with ports architectures
[19:28] <micahg> +1 :)
[19:28]  * Pici as well
[19:33] <soren> NCommander: I believe it's cjwatson.
[19:34]  * NCommander pokes at the script
[19:35] <soren> doko: I'd say yes.
[19:35] <soren> doko: I'm on holiday for a couple of days. I'll take a look when I get back.
[19:35] <doko> soren, thanks
[19:36] <soren> doko: Thanks for pointing it out!
[19:56] <RoboTux> Greetings everyone
[19:56] <RoboTux> The tcc package in Ubuntu suffers a quite bad bug: it generates programs which only runs on Debian and Ubuntu
[19:56] <RoboTux> The fix is in Debian and a merge package has successfuly been generated
[19:57] <RoboTux> Could anyone update the package in Ubuntu to this new version? (the changes are small and tested since 2 months in Debian)
[19:58] <RoboTux> https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/820983 Here is the bug
[20:20] <doko> I want to turn off compiz. 5th crash today ... what's the best option?
[20:21] <micahg> unity-2d?
[20:21] <doko> micahg, just install on top?
[20:21] <micahg> doko: should be available from lightdm
[20:24] <doko> hey, feels even faster ...
[20:26] <RoboTux> Does anyone know who I should ask about tcc?
[20:26] <micahg> RoboTux: https://wiki.ubuntu.com/SponsorshipProcess
[20:27] <RoboTux> Thanks
[20:31] <doko> and colsXrows numbers are back again when resizing \o/
[20:33] <cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
[20:38] <cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
[21:02] <geser> cjwatson: did you sync tecnoballz? if yes, it "Failed to upload": Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression. (https://launchpadlibrarian.net/79382192/upload_2868254_log.txt)
[21:27] <Laney> doko: ah, I had to use --build-dep-resolver=internal
[21:56] <Laney> doko: we need to remove 'vr'
[21:57] <doko> Laney, I assume, just the source?
[21:59] <doko> ahh, no. binary and source
[21:59] <Laney> yeah it has binaries too
[21:59] <Laney> was removed from sid a while ago & provides an uninstallable real package which would otherwise be pure virtual
[22:01] <SpamapS> @pilot in
[22:04] <cjwatson> geser: hm, I did but I never got a failure mail.  I'll fix that, thanks
[22:05] <Laney> native sync bug (due to not attributing you correctly)
[22:08] <cjwatson> Laney: is that the same as the failure to show up in +uploadedpackages?
[22:08] <Laney> I belive that's all the same bug, yes
[23:54] <SpamapS> argh
[23:55]  * SpamapS wonders when he'll be able to stop fighting unity/compiz and just use his computer. :-P
[23:59] <infinity> SpamapS: When you switch to xubuntu.
[23:59] <SpamapS> ;)