[05:28] <pitti> good morning
[07:15] <TheMuso> pitti: Are we likely to update to pygobject 3.0.2 in oneiric-updates?
[07:16] <pitti> TheMuso: we have the most important fixes already
[07:16] <pitti> TheMuso: someone asked me yesterday because a new orca (or onboard?) needs it, and we figured that the patches were already in
[07:16] <TheMuso> pitti: Hrm ok.
[07:17] <TheMuso> pitti: Oh ok thanks, that helps. I was going to ask the same thing.
[07:50] <didrocks> good morning
[07:55] <pitti> bonjour didrocks
[07:55] <pitti> ca va?
[07:56] <didrocks> guten morgen pitti! I'm fine thanks. Seems I still miss some sleep as instead of waking up at 7, I'm waking up at 8.30. But I hope to get that fixed soon :) and you?
[07:58] <pitti> I'm quite fine
[07:58] <pitti> went to Taekwondo the first time after UDS yesterday, feeling my muscles :)
[08:05] <didrocks> heh ;) I run yesterday for the fist time after 3 weeks of no exercice. Surprinsingly, this went "ok"
[08:25] <chrisccoulson> good morning everyone
[08:29] <rodrigo_> morning
[08:31] <didrocks> good morning chrisccoulson, rodrigo_! how are you guys?
[08:33] <rodrigo_> didrocks, I'm fine thanks, and you?
[08:38] <didrocks> rodrigo_: i'm fine, thanks :)
[10:01] <hrw> hi
[10:01] <hrw> unity/2d session - day two
[10:01] <hrw> gwibber went into nuts: http://marcin.juszkiewicz.com.pl/~hrw/shots/crazygwibber.jpg
[10:05] <hrw> is there a way to enable rmb/mmb on maximize button to be maximize vertical/horizontal?
[10:06] <pitti> I'm off to the dentist for a while (¬ \o/)
[10:06] <ricotz> pitti, oh, good luck then ;)
[10:07] <ricotz> Sweetshark, hi :), is there a chance to see libreoffice 3.4.4 for lucid in the ppa?
[10:08] <rodrigo_> pitti: ugh, good luck
[10:08] <ricotz> Sweetshark, i think you somehow planned it while seeing java-helper updated?
[10:08] <ricotz> rodrigo_, hey
[10:09] <rodrigo_> hi ricotz
[10:19] <seb128> hey
[10:19] <seb128> waouh, internet working!
[10:20] <seb128> sorry got some issues to get online today
[10:20] <rodrigo_> hey seb128
[10:25] <didrocks> salut seb128, ça va ?
[10:26] <seb128> hey rodrigo_, didrocks
[10:26] <seb128> didrocks, ca va bien! et toi ?
[10:26] <didrocks> seb128: ça va bien :)
[10:32] <seb128> pitti, if I put https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-video-playback as "informational" is that enough to drop it from your list?
[10:32] <seb128> oh, I already did that it seems, so I guess "no"
[10:32] <seb128> how do I get it off your list? ;-)
[10:32] <seb128> it was a list discussion topic, there is nothing to draft or do
[10:36] <seb128> bryceh, https://bugs.launchpad.net/launchpad/+bug/324387
[10:36] <ubot2> Launchpad bug 324387 in launchpad "Support Redmine Bug Tracker for bug watches" [Low,Triaged]
[10:36] <seb128> bryceh, do you think we could get that on the distro stakeholder bugslist?
[10:38] <didrocks> seb128: still hating your orange ISP?
[10:38] <seb128> didrocks, I didn't have to complain for a while so not really "hating" them ;-)
[10:38] <seb128> but I can't really get better there anyway so...
[10:39] <didrocks> yeah, too far from civilisation… ;-)
[10:39] <seb128> heh
[10:41] <seb128> RAOF, control uploader churn in GNOME packages is because of the auto uploaders computation from pkg-gnome, control.in -> control
[10:58] <hyperair> chrisccoulson: ping
[10:58] <hyperair> chrisccoulson: where do i report firefox-trunk from ubuntu-mozilla-daily bugs?
[10:58] <dpm> morning pitti. Quick question: how can the trend lines for the per-user burndown charts be set? I'm trying to find out how to set mine up, and I'm wondering if it will happen automatically, or is it just a matter of asking or submitting a merge proposal to  ~wi-tracker-configurators/launchpad-work-items-tracker/ubuntu-config
[11:38] <rodrigo_> hmm, what should I do to upload a package branch to precise that is already in oneiric? should I just add a new changelog entry with the precise upload, or just change the last changelog entry to be precise instead of oneiric-proposed?
[11:38] <rodrigo_> seb128, pitti: ^^
[11:39] <seb128> either way works
[11:40] <rodrigo_> ok
[11:40] <rodrigo_> and what would you suggest? :)
[11:41] <seb128> they are equivalent, I usually edit the changelog entry
[11:41] <rodrigo_> ok
[11:45] <nessita> hello all!
[11:56] <didrocks> hey nessita
[11:57] <nessita> hey didrocks
[12:03] <rodrigo_> hey mpt
[12:04] <seb128> hey nessita, how are you?
[12:04] <nessita> seb128:  pretty good! you?
[12:04] <seb128> nessita, I'm good thanks!
[12:04] <nessita> seb128: there is a seb24?
[12:05] <seb128> nessita, seems so, nothing to do with me though
[12:05] <nessita> jeje
[12:05] <pitti> re
[12:05] <nessita> seb128: did you have any chance to review the qt4reactor packaging branch?
[12:05] <pitti> that took a while
[12:06] <pitti> seb128: updated, it's "complete" now
[12:06] <pitti> dpm: ignore the trend lines for now
[12:06] <seb128> hey pitti, danke
[12:06] <pitti> dpm: we usually reset the tracker at feature definition freeze, before that there's too much churn
[12:07] <pitti> dpm: you can override it manually, but don't bother -- we don't want a hundred or so manual adjustments
[12:07] <dpm> ok, gotcha, thanks pitti
[12:07] <pitti> rodrigo_: common practice so far is to add a new changelog entry "upload to precise" and build with -v to include the previous changelog
[12:07] <mpt> hi rodrigo_
[12:07] <pitti> rodrigo_: but s/oneiric-proposed/precise/ and version bump works, too
[12:07] <pitti> the former is more friendly to VCSes, though
[12:08] <rodrigo_> pitti, yeah, just editing the last changelog entry didn't work, the package was rejected, as that version already existed in the archive
[12:08] <pitti> yes, you need to bump the version either way
[12:08] <rodrigo_> yeah
[12:10] <didrocks> no, seb24 is french, seb128 is german :)
[12:10] <rodrigo_> :)
[12:10] <seb128> didrocks, !!! ;-)
[12:10] <didrocks> that was so easy! I couldn't keep telling it, sorry :-)
[12:10]  * didrocks hugs seb128
[12:10] <seb24> yes i'm only a Beta-tester
[12:10] <seb128> didrocks, hug back ;-)
[12:11] <rodrigo_> didrocks, yeah, French joke :)
[12:11] <didrocks> rodrigo_: you didn't follow, French-German joke :p
[12:11] <rodrigo_> oh, right :D
[12:13] <pitti> rodrigo_: saw your control-center upload; I recommend uploading with -v, otherwise people on -chagnes@ don't see the actual changes
[12:13] <pitti> rodrigo_: and bugs that the oneiric-proposed changelog refers to are not auto-closed
[12:13] <pitti> so you now need to do that manually
[12:14] <pitti> seb24: only 104 to go, you can do it!
[12:14] <rodrigo_> pitti, oh, ok
[12:14] <pitti> actually, I'm fairly sure that there is a Pauli principle that you can't have two developers with the same number, lest the world explodes
[12:16] <seb24> pitti : :D
[13:09] <pitti> chrisccoulson: do you still see any need for pkgbinarymangler to export XPI files?
[13:10] <chrisccoulson> pitti - no, i don't think so. i didn't even realize it could do that :)
[13:10] <pitti> we have done that all the time, but as we now build the XPIs from the firefox source, it's pretty obsolete
[13:11] <chrisccoulson> yeah, you should probably kill that then :)
[13:11]  * chrisccoulson hands pitti the axe
[13:11] <pitti> *slash*
[13:11] <pitti> thanks
[13:11]  * rodrigo_ lunch
[13:17] <Sweetshark> ricotz: :/ I just slashed that in WI reduction.
[13:42] <ricotz> Sweetshark, oh no :(
[13:45] <GunnarHj> pitti: ping?
[13:45] <pitti> hello GunnarHj, how are you?
[13:45] <GunnarHj> pitti: I'm ok, hope you are as well.
[13:46] <GunnarHj> pitti: Wondering what happens with bug 868346
[13:46] <pitti> quite fine, apart from my jar (just was at the dentist0
[13:46] <ubot2> Launchpad bug 868346 in lightdm "Language selector broken in Ubuntu" [Medium,In progress] https://launchpad.net/bugs/868346
[13:46] <GunnarHj> pitti: Oh, sorry. ;-)
[13:46] <pitti> GunnarHj: np :)
[13:46] <pitti> GunnarHj: ah, I thought that was discussed with Robert a while ago, he didn't merge yet?
[13:47] <GunnarHj> pitti: Know he wanted you to take a look as well.
[13:47] <GunnarHj> pitti: AFAIK, he approves.
[13:47] <GunnarHj> s/Know/No/
[13:48] <pitti> ok, opened tab for this, will take a look today
[13:48] <GunnarHj> pitti: Great.
[13:49] <GunnarHj> pitti: Also, I have started to work on bug 866062
[13:49] <ubot2> Launchpad bug 866062 in accountsservice "SetLanguage(): Write ~/.pam_environment instead of ~/.profile" [Medium,Triaged] https://launchpad.net/bugs/866062
[13:49] <GunnarHj> pitti: Just so you know, and don't start you too...
[13:49] <seb128> GunnarHj, pitti: we skipped it when we reviewed the changes for the sru because neither robert_ancell or I were confident enough with locales to review the change and be sure it wouldn't create an issue
[13:49] <seb128> we wanted to get a first SRU through without issue
[13:49] <pitti> GunnarHj: ah, great
[13:49] <pitti> GunnarHj: not right now, I'm fighting with pkgbinarymangler
[13:50] <GunnarHj> seb128: Hi Sebastien, ok, I see.
[14:26] <pitti> bryceh: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-xorg is not targetted to precise, should it be? or is this one obsolete?
[14:46] <dobey> pitti: hey
[14:46] <dobey> pitti: so; do we have a plan wrt rb/banshee? :)
[15:09] <dobey> i think pitti is ignoring me, or having a very conveniently late lunch ;)
[15:09] <pitti> dobey: I'm in a call
[15:10] <dobey> ah; meetings :-/
[15:24] <pitti> dobey: so, we had a bunch of discussions on the ML
[15:24] <pitti> dobey: but I'm not sure who would make the final call
[15:24] <pitti> Personally I still prefer switching to RB, though
[15:27] <dobey> pitti: switch now, and if banshee is feasibly stable on gtk3 by alpha2, agree to evaluate a switch back?
[15:27] <pitti> that would WFM for sure :)
[15:28] <pitti> seb128, jasoncwarner_, rodrigo_: ^ opinions?
[15:28] <rodrigo_> pitti, I use banshee, but I think getting rid of mono makes a lot of sense
[15:28] <dobey> really, i don't see banshee being in a supportable state on gtk3 anytime soon :(
[15:29] <kenvandine> i really prefer banshee, but there are some nice pluses for switching
[15:29] <kenvandine> not having to maintain mono in the LTS would be nice
[15:29] <rodrigo_> yes
[15:29] <dobey> well mono itself isn't that bad
[15:30] <kenvandine> and their is the arm issue, i seem to recall the arm builds ending up switching to rhythmbox
[15:30] <dobey> but the complete mess of a "platform" upon which banshee is built is completely crocked.
[15:30] <kenvandine> dobey, but for 5 years... how confident are we that there will be active upstream maintenance for that long?
[15:31] <dobey> kenvandine: banshee itself, and mono itself, will probably be fine. it's all the junk in the middle that's the problem
[15:31] <kenvandine> yeah
[15:32] <chrisccoulson> mvo, for the LTS, we want to provide a way for enterprise users to stick to the extended support version of firefox. we're going to provide a PPA for this, and would like people who switch to it to get their security updates from the PPA rather than precise-security (the version in the PPA will always be older). is it acceptable to ship a file in /etc/apt/preferences.d to automatically set up the pinning to do this? or do we need
[15:32] <chrisccoulson>  to tell people to do this manually?
[15:35] <mvo> chrisccoulson: hm, you already discussed simply to use a alternative packagename and stick it into the main archive I assume?
[15:35] <mvo> chrisccoulson: one problem I can see is that unattended-upgrades will not recordnise the origin by default, you will also have to tweak that
[15:35] <chrisccoulson> mvo - we don't want them parallel installable, as we have to do a lot of hacks to make that work (and hacks that are unapproved by mozilla)
[15:35] <mvo> chrisccoulson: this would be nicely avoided by using the regular archive
[15:35] <mvo> chrisccoulson: well, conflicts would solve that
[15:36] <dobey> pitti: i'm asking, because we're nearly ready to get moving on all the u1 improvements
[15:36] <mvo> chrisccoulson: unless there are more reasons
[15:36] <chrisccoulson> mvo - we also want to make it clear that the extended support version is completely unsupported, and we don't really want people installing it
[15:36] <chrisccoulson> it's just that some enterprise users think it's a good idea
[15:36] <mvo> chrisccoulson: heh, ok
[15:37] <chrisccoulson> so we just want to offer them a PPA for that, with "best-effort" maintenance
[15:38] <bjsnider> dobey, what junkin the middle?
[15:39] <dobey> bjsnider: gtk#, ndesk-dbus, gtk-sharp-beans (whatever that is), and the bunch of little mono binding libs for single API points
[15:40] <bjsnider> gtk-sharp-beans, i had those for lunch yesterday. pretty good.
[15:43] <Laney> they are all because gtk-sharp was frozen
[15:43] <Laney> to bind extra bits.
[15:47] <Laney> but seriously, people are out for banshee, just do it. there is no reaslistic chance of anything else happening, is there?
[15:49] <pitti> if we had a working GTK 3 version and working ARM support, there would be (I don't think that 5 year LTS support of Mono itself is much of a problem)
[15:50] <seb128> re
[15:50] <pitti> you or Chow said that both should not be that far out any more; do you know how far?
[15:50] <pitti> at least the GTK3 support
[15:50] <Laney> olivier is working on the remaining bug, you could speak to him
[15:50] <seb128> pitti, well if lts support of mono is not an issue I would vote to stay on banshee
[15:50] <seb128> if we manage to check that the stability issues from oneiric are fixed
[15:51] <Laney> regarding arm, there's not much we can do if it is unreproducible for us and the arm team refuse to support mono
[15:51] <seb128> the gtk3 transition on untested bindings in a lts cycle makes me nervous though, I wish there would have been a discussion about staying on 2.2
[15:51] <Laney> i don't really see how that is anything that can be solved
[15:51] <seb128> but banshee already got updated
[15:51] <rodrigo_> they refuse to support mono?
[15:52] <mdeslaur> chrisccoulson: just curious: why don't you rename the version in the PPA to firefox-esv or something?
[15:52] <seb128> rodrigo_, could you take on bug #884003?
[15:52] <ubot2> Launchpad bug 884003 in vino "The remote connection indicator is broken" [High,Triaged] https://launchpad.net/bugs/884003
[15:52] <seb128> rodrigo_, you are the one who did the upload with the patch commented and it never got added back ;-)
[15:52] <rodrigo_> seb128, yes
[15:52] <seb128> rodrigo_, thanks
[15:53] <dobey> Laney: people aren't out for banshee; i really wish everyone would stop being so damned defensive with this whole thing.
[15:53] <seb128> Laney, do you have though on how risky the switch to new bindings and new GTK is in a lts cycle and staying on 2.2?.
[15:54] <chrisccoulson> mdeslaur, we'd still need to make it conflict with the official package. and in any case, i also want the packaging to be a snapshot of the official packaging in the archive from which it is based
[15:54] <chrisccoulson> and when i start adding changes, my workload will go up :-)
[15:54] <dobey> seb128: also, the gtk# building against gtk3 doesn't bring in GSettings bindings afaik (and none exist on mono yet, from what i've seen in #banshee)
[15:54] <hrw> is it normal that unity/2d panel^Wlauncher stops hiding after some time?
[15:54] <seb128> dobey, right, different topic, that's not likely to happen this cycle but not important either
[15:54] <chrisccoulson> i want the esr packages to be pretty much zero-maintenance really
[15:54] <Laney> seb128: honestly I haven't run it, if you want to know how stable it is then I would chat with olivier
[15:54] <seb128> hrw, try asking on #ayatana
[15:55] <hrw> ok
[15:55] <dobey> seb128: and maintenance of gtk# itself seems very much up in the air
[15:55] <mdeslaur> chrisccoulson: I don't really like the idea of PPA packages setting up pinning by themselves...
[15:55] <chrisccoulson> mdeslaur, it's ok. i don't mind making people set it up manually :)
[15:55] <Laney> I just filed a bug asking for PPAs to have NotAutomatic :-)
[15:56] <mdeslaur> chrisccoulson: once you show all 3 users of that PPA how to do it, everything will be fine
[15:56] <chrisccoulson> heh
[15:56] <chrisccoulson> i imagine that this PPA will have less users than the firefox-stable PPA :)
[15:56] <ogra_> Laney, who in the arm team said we dont support mono ?
[15:57] <seb128> dobey, well at the same time "support" is not well defined, in practice Ubuntu doesn't "support" things a lot out of security updates, and mono is not very much a security issue
[15:57] <dobey> seb128: no, but an incomplete bindings port seems like a support risk
[16:00] <Laney> ogra_: you didn't refuse, but the emails on -desktop were really rather clear that you would rather not have to deal with mono
[16:01] <ogra_> Laney, well, we feel left alone with our probs by upstream and the rest of the world, its not that we dont want to support mono or anything
[16:01] <dobey> Laney: "would rather not" != "does not"
[16:01] <Laney> I read that upstream is working on armhf support btw
[16:01] <ogra_> Laney, all probs we had over the last releases had to be solved by ourselves
[16:01] <Laney> as part of their monodroid product
[16:02] <ogra_> thats a good move forward and might help us a lot
[16:02] <ogra_> but for ubuntu it isnt even clear if we will switch to hf in precise
[16:02] <ogra_> we dont even have working builders yet
[16:03] <Laney> the guy working on this, who is also one of the most knowledgable runtime hackers upstream is 'vargaz' on gimpnet
[16:03] <ogra_> k
[16:03] <ogra_> lets see how banshee behaves in precise at all ... i dont have any data yet
[16:04] <ogra_> and afaik the bug we had at release date still persists ... while there is a workaround, there isnt a fix yet
[16:05] <ogra_> i'm totally not objecting mono or banshee and i honestly prefer that the arm iamges dont differ from x86 at all ... so please dont read something like "arm doesnt want mono" into my comments :)
[16:07] <dobey> sigh
[16:07] <dobey> anyway, i need to get lunch.
[16:07] <dobey> bbiab
[16:08] <seb128> bah, those discussions suck, there is no way to discuss the default application from a pragmatic way, people always get personal and defensive
[16:09] <seb128> Laney, communication was poorly done but I think you and the other banshee guys are over-reacting as well on it
[16:09] <Laney> yeah sorry to be defensive
[16:10] <Laney> it's a bit hard because we feel like we've put a lot of work in for ubuntu's needs
[16:10] <pitti> yeah, that came as a surprise in the UDS session, we need to discuss that differently in the future; there have been some good recommendations in the thread, such as contacting upstreams beforehand
[16:11] <pitti> Laney: you did indeed
[16:12] <seb128> Laney, do you think the ubuntu-desktop list discussion started by jasoncwarner_ is a better basis?
[16:13] <pitti> jasoncwarner, Sweetshark, bryceh, chrisccoulson, didrocks, tremolux, Riddell, kenvandine, cyphermox, mterry, rodrigo_, seb128, tkamppeter, pedro_, desrt: no topics on https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-11-15, so we'll skip the official meeting; please do add your news of the week, please
[16:13] <seb128> we should really try to figure what's going on with the gtk3 mono bindings and the banshee port to gtk3 and discuss if staying on 2.2 for the lts would be a better choice
[16:13] <didrocks> already done :)
[16:13]  * pitti hugs didrocks
[16:13] <seb128> that's orthogonal to the default player discussion
[16:13]  * didrocks hugs pitti back
[16:14] <mterry> pitti, shoot, I clicked 'request approval' for the spreadsheet with the wrong google login again
[16:14] <seb128> i.e there are 2 discussions there, one being what to do with banshee versions (similar to the discussion we had at UDS for GNOME components)
[16:14] <kenvandine> pitti, cool
[16:14] <Laney> I think it's a good idea, but it doesn't seem like a neutral evalutation of both applications — it feels like if Banshee doesn't come up to scratch then it will be dropped, rather than RB having to sort itself out too.
[16:14] <Laney> regarding gtk3, olivier commeted on list — you should reply to him with your questions
[16:15] <Laney> or give the gtk3 branch a go :-)
[16:17] <rodrigo_> pitti, ok
[16:18] <seb128> Laney, the issue is that we don't compare purely applications, or banshee would stay default, we include gtk stacks, mono supports, etc in equation
[16:19] <seb128> banshee itself is better than rb, the issue is to know if that's worth the price we pay with CD space, support, etc
[16:19] <seb128> we should maybe split the topic in 2 discussions
[16:19] <dobey> "better"
[16:19] <Laney> i think we're (especially hyperair) pretty good at keeping up with srus
[16:19] <seb128> one about the quality issues we had in oneiric and what is planned for this cycle
[16:19] <dobey> it is a matter of what you are talking about, and is a subjective argument; as an ISV, rhythmbox is much better
[16:19] <seb128> the other one about the pro and con of the side arguments
[16:20]  * hyperair nyans at Laney
[16:20] <seb128> dobey, why?
[16:20] <Laney> if you want to stay at 2.2 then we need to figure out what bugs should be fixed for precise
[16:20] <pitti> I don't think we want to stay at 2.2
[16:21] <seb128> well, I don't know enough about banshee to be confident having an opinion on that
[16:21] <pitti> keeping that whole gtk2/gtk#2/webkit-gtk2 stack is quite a high price
[16:21] <seb128> pitti, I don't think we want to transition to a new GTK using untested and unpackaged binding in a LTS cycle
[16:21] <chrisccoulson> if banshee ends up using gtk3, what will be left on the CD using gtk2?
[16:21] <dobey> seb128: banshee's architecture has caused me pretty much nothing but pain in having the u1ms extension in it, while in rhythmbox we never really had to do much with it as everything pretty much just works in a sane way
[16:21] <chrisccoulson> (other than the obvious)
[16:21] <Laney> maybe we can get some ppa builds out of the gtk3 branch
[16:22] <Laney> for people to have a go on
[16:22] <pitti> chrisccoulson: gtk2 is quite a lot still, but getting rid of webkit-gtk2 will already help quite a lot, and it will unblock U1 from porting to GTK3
[16:22] <pitti> U1 is holding a lot of gtk2 stuff, too
[16:22] <dobey> even if banshee were already gtk3; from my POV, rhythmbox is a better choice
[16:23] <hyperair> because of the race condition you had?
[16:23] <pitti> I like the RB UI better, too, but the usability studies say that Banshee's is better, so I trust that more than what I just happen to be used to
[16:23] <chrisccoulson> pitti - it's possible to build firefox with gtk3 now, but to keep flash working, you also need to build a gtk2 libxul + plugin-container, which basically doubles the build time
[16:23] <dobey> hyperair: no, because of all the other problems we have, which are impossible to fix with the way banshee is designed
[16:23] <chrisccoulson> so i'd like to put that off for as long as possible :)
[16:24] <chrisccoulson> seeing as there will probably never be a gtk3 version of flash
[16:24] <dobey> pitti: i hate both the UIs, so that's irrelevant to me :)
[16:24] <chrisccoulson> (now that flash is dead)
[16:24] <pitti> chrisccoulson: HTML5 FTW?
[16:24] <dobey> chrisccoulson: flash isn't dead?
[16:24] <pitti> chrisccoulson: will that really die so soon?
[16:24] <hyperair> is flash really dead?
[16:24] <pitti> (with "so soon" being < 3 years)
[16:24] <chrisccoulson> pitti, i don't think it will die overnight. but it will die ;)
[16:24] <pitti> not that I'd shed a tear for it, but that seems a little optimistic?
[16:25] <ogra_> blackberry will keep it alive !
[16:25] <chrisccoulson> i don't expect adobe to invest anything in to it now, and especially not a gtk3 port
[16:25] <ogra_> :P
[16:25] <pitti> well, I guess the day youtube switches will be the day when most of us can uninstall flash :)
[16:25] <hyperair> html5 by default you mean
[16:25] <Laney> vimeo, iplayer, ...
[16:25] <seb128> chrisccoulson, gtk2> list on the etherpad but basically: compiz firefox gparted libreoffice
[16:25] <hyperair> i'm actually pretty fond of digging inside /proc to get access to the flv's that all these players have
[16:25] <dobey> pitti: the usability studies are BS; they don't say that banshee is better. they say rhythmbox has some issues. and frankly, banshee has pretty much the same issues, as their UIs are almost exactly the same
[16:26] <pitti> hyperair: well, even as a fallback and not by default
[16:26] <hyperair> unfortunately i don't recall firefox offering a sane way of extracting videos
[16:26] <chrisccoulson> seb128, thanks
[16:26] <dobey> hyperair: View->Page Source
[16:26] <hyperair> dobey: that's a lot more time consuming than just diggign in /proc/`pidof plugin-container`/fd/
[16:26] <dobey> i am sad that all the youtube downloader quick bookmarks sites are all broken now though
[16:27] <seb128> chrisccoulson, system-config-printer as well
[16:27] <dobey> hyperair: well, it was much nicer when they were all in /tmp/
[16:27] <hyperair> dobey: ah, that's because the file gets unlink()'d. if you LD_PRELOAD firefox to not unlink FlashXXXX files... it'll stick around ;-)
[16:28] <dobey> hyperair: no, flash doesn't put them in /tmp any more.
[16:28] <hyperair> dobey: yes it does. it just unlink()s them while keeping the fd open.
[16:28] <hyperair> dobey: if you see the symlinks in the /proc tree, they point to /tmp/FlashXXXXX
[16:29] <dobey> hmm
[16:29] <seb128> kenvandine, is gwibber still using gtk2 and python-webkit a lot? is that going away this cycle?
[16:29] <kenvandine> in gwibber-accounts
[16:30] <kenvandine> i can look at taht
[16:30] <kenvandine> that
[16:30] <seb128> do you plan to switch that to gtk3 before the lts?
[16:30] <seb128> kenvandine, no hurry, I'm just counting the webkit-gtk2 users on the CD
[16:30] <kenvandine> :)
[16:30] <kenvandine> how many others?
[16:31] <seb128> banshee, shotwell (will be fixed this cycle)
[16:31] <dobey> anyway, back to banshee v rbox
[16:31] <seb128> software-center
[16:31] <seb128> mvo, is s-c still using gtk2? why does it depends on python-webkit?
[16:32] <pitti> seb128: it doesn't, it uses gir1.2-webkit-3.0
[16:32] <dobey> seb128: there are 2 software center binaries installed afaict
[16:32] <seb128> pitti, well it depends on python-webkit
[16:32] <dobey> seb128: one using gtk2
[16:32] <pitti> seb128: where?
[16:32] <dobey> pitti: software-center-gtk (rather than software-center-gtk3) i presume
[16:33] <pitti> I checked apt-cache show software-center | grep webkit
[16:33] <pitti> no python-webkit
[16:33] <seb128> pitti, I'm still on Oneiric
[16:33] <pitti> seb128: shoudl be the same
[16:33] <seb128> so I guess it got fixed in precise
[16:34] <pitti> seb128: your software-center package has a dependency to python-webkit?
[16:34] <seb128> yes
[16:34] <dobey> [dobey@lunatari:~]: apt-cache depends software-center|grep -i webkit Depends: gir1.2-webkit-3.0
[16:34] <pitti> dpkg -L software-center | xargs grep -i 'import.*webkit'
[16:35] <dobey> that's on oneiric
[16:35] <pitti> /usr/share/software-center/softwarecenter/ui/gtk3/views/purchaseview.py:from gi.repository import WebKit as webkit
[16:35] <pitti> /usr/share/software-center/softwarecenter/ui/gtk3/widgets/videoplayer.py:from gi.repository import WebKit
[16:35] <pitti> /usr/share/software-center/softwarecenter/ui/gtk3/widgets/exhibits.py:from gi.repository import WebKit
[16:35] <pitti> seb128: ^ it's fine in precise
[16:36] <seb128> pitti, ok, it doesn't have a direct depends but "sudo apt-get remove libwebkitgtk-1.0-0" wants to remove s-c here
[16:36] <seb128> so it might be one of its depends
[16:36] <pitti> ah
[16:36] <pitti> seb128: btw, cleaning up the pad; today's images dropped gnome-codec-install
[16:36] <seb128> oh nice, what do you use instead?
[16:37] <pitti> sessioninstaller
[16:37] <pitti> I ported that to PyGI/GTK3 yesterday
[16:37] <pitti> somethign still pulls in python-aptdaemon-gtk, though, /me checks
[16:38] <pitti> ah, ubuntuone-control-panel-gtk
[16:38] <seb128> pitti, hum, does sessioninstaller has special support for codecs?
[16:38] <pitti> seb128: yes
[16:38] <pitti> seb128: I tested it yesterday with toem
[16:38] <pitti> totem, too
[16:38] <pitti> seb128: it provides a gst-install wrapper
[16:38] <pitti> works very nicely
[16:39] <seb128> pitti, ok, great, I need to check what ui it uses
[16:39] <seb128> pitti, i.e how it handles when different codecs can be installed for the same thing
[16:39] <seb128> like mp3 supported by the fluendo one and the universe set
[16:39] <pitti> seb128: you get a lsit of packages with checkboxes
[16:39] <seb128> does it give you enough details to make an informed decision?
[16:39] <pitti> seb128: you can run this:
[16:40] <pitti> ./test --install-gstreamer multi
[16:40] <pitti> in sessioninstaller to test
[16:40] <pitti> seb128: well, it's got special cases for the gstreamer packages in bubble help
[16:40] <pitti> i. e. explain what they do
[16:41] <seb128> pitti, thanks
[16:42] <dobey> hmm
[16:43] <jbicha> no meeting today?
[16:46] <seb128> jbicha, no
 jasoncwarner, Sweetshark, bryceh, chrisccoulson, didrocks, tremolux, Riddell, kenvandine, cyphermox, mterry, rodrigo_, seb128, tkamppeter, pedro_, desrt: no topics on https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-11-15, so we'll skip the official meeting; please do add your news of the week, please
[16:46] <seb128> that's what we decided at UDS
[16:47] <seb128> pitti, we maybe should communicate about that on the list as well ;-)
[16:47] <didrocks> hey jbicha
[16:47] <chrisccoulson> will do. although, mine isn't that exciting :-)
[16:47] <jbicha> didrocks: howdy
[16:48] <didrocks> jbicha: I've added a comment on https://code.launchpad.net/~manishsinha/gedit/enable-zeitgeist-datasource-plugin/+merge/80561
[16:48] <didrocks> I fixed it for gedit (and same for totem and pushed the commit you forgot to push) :)
[16:48] <jbicha> so bjsnider was interested in joining the GNOME3 team but it's not clear what the procedures are for that
[16:48] <rodrigo_> jbicha, iirc, you need 2 people +1ing your request
[16:49] <rodrigo_> so best thing is to have him send merge proposals for a while
[16:50] <jbicha> and then ask on the desktop mailing list when ready?
[16:50] <jbicha> didrocks: thanks for finishing that up
[16:51] <didrocks> jbicha: no worry :)
[16:51] <pitti> hey jbicha
[16:51] <pitti> jbicha: do you have something we need to discuss? a lot of us are online :)
[16:52] <jbicha> pitti: hi, nothing in particular except the gnome3 team question that was just answered
[16:53] <rodrigo_> jbicha, yes, iirc :)
[16:57] <pitti> seb128: hm, do you know why "ibus" depends on python-ibus?
[16:57] <pitti> seb128: we use ibus-gtk3 nowadays, and ibus itself is just providing /etc/X11/xinit/xinput.d/ibus
[16:57] <pitti> presumably it's meant to be a meta-package
[16:57] <seb128> not sure no
[16:58] <pitti> not on http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/desktop.depends
[16:58] <rodrigo_> need to run some errands, bbl
[16:58] <pitti> desktop: * (ibus)
[16:58] <pitti> desktop: * (ibus-gtk3)
[16:58] <pitti> seb128: ^ aah!
[16:58]  * pitti fixes
[16:58] <seb128> pitti, is the indicator working with gtk3?
[16:59] <pitti> seb128: I think we need ibus-gtk as well, for GTK2 apsp
[17:00] <pitti> seb128: aren't our app indicators using gtk3 now?
[17:01] <pitti> gosh, the dependencies on these packages are horribly messed up
[17:01] <pitti> "ibus" pulls in everything, and the individual binaries like python-ibus miss a lot
[17:01] <seb128> pitti, well, the indicator patch in the current source still to still be using static bindings
[17:02] <seb128> still "seems to be using"
[17:02] <pitti> so what part of ibus actually uses an indicator?
[17:03] <pitti> $ dpkg -L python-ibus|xargs grep -i indicat
[17:03] <pitti> $
[17:03] <pitti> not this one at least
[17:04] <pitti> ibus-gtk{,3}  just ship a GTK 3 immodule, no python
[17:05] <seb128> pitti, ibus: /usr/share/ibus/ui/gtk/panel.py
[17:05] <pitti> seb128: what is dpkg -S /usr/share/ibus/ui/gtk/panel.py for you?
[17:05] <pitti> the "ibus" package only ships a single file here:
[17:05] <pitti> /etc/X11/xinit/xinput.d/ibus
[17:06] <pitti> oh dear, this ^ also looks wrong
[17:06] <seb128> $ dpkg -L ibus |wc -l
[17:06] <seb128> 96
[17:06] <seb128> pitti, are you sure it's installed?
[17:06] <seb128> seems like you uninstalled it and kept a conffile behind?
[17:06] <pitti> if [ -e /usr/lib/gtk-3.0/*/immodules/im-ibus.so ] \
[17:06] <pitti>    && [ -e /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so ]
[17:06] <pitti> then
[17:06] <pitti>     GTK_IM_MODULE=ibus
[17:06] <pitti> that should be ||
[17:06] <pitti> seb128: ah, sorry
[17:06] <pitti> seb128: that explains a lot indeed :) had a multiarch accident recently which removed half of my system
[17:07] <pitti> ok, so the ibus UI is gtk2 still, darn
[17:07] <pitti> soudns like another PyGI port
[17:07] <seb128> right
[17:10] <pitti> I'll contact them and ask about their plans, and whether they want a hand
[17:12] <bryceh> pitti, desktop-p-xorg targeted
[17:13] <pitti> bryceh: thanks
[17:15] <bryceh> seb128, 324387 noted for escalation to launchpad, thanks
[17:19] <pitti> seb128: asked on upstream list, in moderation now (it's google groups)
[17:19] <seb128> pitti, thanks
[17:19] <pitti> so long, have a nice evening everyone!
[17:19] <didrocks> enjoy pitti!
[17:20] <didrocks> bryceh: hey
[17:20] <seb128> bryceh, thank you, yorba uses redmine for their bug tracking (i.e for shotwell) ;-)
[17:20] <seb128> pitti, have fun
[17:20] <didrocks> bryceh: there was this discussion about meta-project in launchpad, which is not exactly the same than project group
[17:20] <didrocks> bryceh: we discussed a little bit with Tim at UDS about this issue (which, has a workaround, we have to add a "unity" upstream task to gather all unity bugs fixed in one release shot)
[17:21] <didrocks> bryceh: the idea was to have meta-project to only have one milestone for all unity component as they are released on the same date and see "what's coming in the new release"
[17:21] <bryceh> seb128, yes taskwarrior does as well, it seems to be getting more popular
[17:21] <didrocks> Tim told that this project was started and some point, but got stalled because nobody requested it
[17:22] <bryceh> didrocks, interesting; was there a LEP produced for it?
[17:23] <didrocks> bryceh: not sure, I can maybe ask thumper about it and ping you back with this tomorrow
[17:23] <bryceh> didrocks, that'd be great
[17:23] <didrocks> bryceh: will ping you back tomorrow! Thanks :)
[17:24] <bryceh> didrocks, great; also if you know of other projects besides unity that could potentially benefit from it, that can help up the priority on it
[17:26] <didrocks> bryceh: compiz? :D (yeah, as another meta-project, not linked to unity)
[17:26] <didrocks> bryceh: but apart from that, not sure TBH
[17:27] <bryceh> didrocks, I'm sure it'll be clearer after reading the LEP
[17:28] <didrocks> yeah, let's wait for thumper
[17:28] <dobey> hmm
[17:28] <dobey> so i'm not sure what to do
[17:28] <bryceh> didrocks, oh also, the launchpad guys really emphasize defining the problem trying to be solved, over just requesting some specific fix, so it's possible Meta-Projects might be the right solution, but we should present it as the underlying issue that needs solved
[17:29] <bryceh> sometimes there's more than one way to solve a given problem
[17:29] <didrocks> bryceh: indeed, if there is a LEP, I will try to sum up to you how we workarounded it and why we needed it, I think that will address this need?
[17:30] <bryceh> didrocks, yep sounds like a good plan
[17:56] <didrocks> time for some exercice, see you tomorrow guys!
[18:22]  * kenvandine goes to get food
[18:28] <chrisccoulson> lol, i was confused for a moment that the output of "df -h" said my SSD was 537GB!
[18:28] <chrisccoulson> then i realized i was logged in to chinstrap
[18:43] <mterry> chrisccoulson, :)
[19:00] <dobey> ugh, there are 56 packages that depend on python-xdg in my quick apt-cache rdepends poking
[22:06] <jasoncwarner_> hey robert_ancell, RAOF TheMuso and bryceh ... meeting time. https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-11-15
[22:08] <jasoncwarner_> hey robert_ancell , just about to start meeting. RAOF bryceh and TheMuso , around?
[22:09] <TheMuso> Morning jasoncwarner_.
[22:09] <RAOF> Good morning all.
[22:10] <cyphermox> good evening all ;)
[22:10] <jasoncwarner_> Awesome, before we begin, I wanted to reinforce pitti's point about number of WI and how many people have for precise.
[22:11] <jasoncwarner_> RAOF TheMuso and robert_ancell , based on pitti's esimates, your WI numbers are way out of whack and need some looking at.
[22:11] <robert_ancell> yup
[22:12] <TheMuso> Right, will look at that this morning.
[22:12] <jasoncwarner_> robert_ancell RAOF TheMuso could you get to those today so pitti and I can review BPs tonight?
[22:12] <jasoncwarner_> thanks!
[22:12] <robert_ancell> jasoncwarner_, is there the summary page up that shows all the items per person?  what is the link?
[22:12] <robert_ancell> sure
[22:12] <RAOF> Mine are artificially inflated by a huge number of bug tasks that aren't actually mine.  I'll get to that today.
[22:12] <TheMuso> robert_ancell: status.ubuntu.com has it.
[22:13] <jasoncwarner_> RAOF: figured in your case...since your number was SOOOO out of whack
[22:13] <TheMuso> http://status.ubuntu.com/ubuntu-precise/u/themuso.html is mine.
[22:13] <jasoncwarner_> thanks everyone.
[22:14] <jasoncwarner_> ok, so why don't we go around the room now. Bryce and RAOF , care to kick us off with X?
[22:14] <RAOF> We're just waking up in X land :).
[22:15] <RAOF> I believe that amd have just released the new fglrx driver that's compatible with Xserver 1.11.
[22:16] <RAOF> Which means that we'll soon be in a position to switch.  The other blocker there is me either (a) fixing up the forward-port of the multitouch patches or (b) dropping them until Chase has got the full upstream solution backported.
[22:17] <RAOF> I'd prefer to do (a).
[22:18] <RAOF> And then when that's done, we'll stage everything in a PPA and copy to the archive.  There shouldn't be any time when X is not installable/upgradable.
[22:18] <RAOF> At least, that's the plan :)
[22:19] <jasoncwarner_> RAOF: I like that last bit! :)
[22:19] <jasoncwarner_> RAOF: thanks, anything else to add?
[22:19] <RAOF> Precise is currently almost entirely unbroken, dive right in? :)
[22:20] <jasoncwarner_> RAOF: cool! thanks :)
[22:20] <jasoncwarner_> TheMuso: your turn!
[22:20] <TheMuso> cRight. Spent a bit of time in the last day or so taking care of some oneiric SRUs for a11y, with one more to be done today.
[22:21] <TheMuso> Starting to ramp up on the more invasive work needed for accessibility pollish in precise, this takes the form of extending dbusmenu for accessible descriptions for various menus in the messaging and network indicators.
[22:22] <TheMuso> I still need to talk to Ted about the exact implementation, and I am hoping to have that done by the end of the week.
[22:23] <jasoncwarner_> TheMuso: nice...thanks.
[22:23] <jasoncwarner_> robert_ancell: what is going on with lightdm and unity-greeter?
[22:24] <dobey> hey jasoncwarner_ :)
[22:24] <jasoncwarner_> hey dobey
[22:24] <robert_ancell> had first meeting with design yesterday, we want to try and get the precise features previewable in budapest so design can check them and try and get some user testing in late feb.
[22:25] <robert_ancell> started work on the harder jobs - the user switching and the flicker on startup.  Aurelien is starting to look into where he can help
[22:25] <bryceh> hi guys, sorry I have another meeting - apparently daylight savings caused them to be co-scheduled
[22:26] <robert_ancell> (done)
[22:27] <dobey> i'll wait until you guys are done with the meeting thing :)
[22:27] <RAOF> robert_ancell: I know I've got some work items in that area - is there anything that I should be prioritising to ensure you're not blocked?
[22:27] <robert_ancell> RAOF, no, I think there's nothing critical.  The flicker disabling on switch is something we should look into earlier rather than later though
[22:28] <RAOF> ok.
[22:30] <jasoncwarner_> robert_ancell: thanks, anything else?
[22:30] <robert_ancell> no
[22:30] <jasoncwarner_> awesome...anyone ? anything else?
[22:31] <RAOF> Oh, yeah.
[22:31] <RAOF> You can roughly halve Banshee's startup time by AOT compiling the system libraries; I'm talking with debian-cli and mono upstream about doing that on package install.
[22:32] <robert_ancell> RAOF, is there any trade-off doing that?
[22:32] <dobey> jasoncwarner_: http://irclogs.ubuntu.com/2011/11/15/%23ubuntu-desktop.html#t15:24
[22:32] <dobey> :)
[22:33] <RAOF> robert_ancell: Disc space, obviously; you need both the AOT code and the original assemblies.  You also give up some optimisation opportunities, and the code will likely have worse cache-locality.
[22:34] <TheMuso> RAOF: How does that affect the live images?
[22:34] <TheMuso> In terms of disk space.
[22:34] <RAOF> Oh, and depending on the CPU/disc ratio it *can* slow down startup, as you need to read more.
[22:35] <RAOF> TheMuso: Good question.  I'm not entirely familiar with how the live images are built.  We wouldn't want the AOT code on the live images anyway, so we need some tweakable there.
[22:35] <TheMuso> RAOF: Right, I guess it would depend on whether the files we don't want are still owned by the package.
[22:35] <TheMuso> If they are not, then it is certainly possible that they could be purged from the filesystem during build.
[22:36] <RAOF> No, they won't be owned by the package.  They'll be generated at install time, like python bytecompiling.
[22:36] <TheMuso> Oh right so you are saying that we will ship banshee as is for the live images, but on updates they will be compiled?
[22:37] <RAOF> I think that's what I'm saying, yes.
[22:37] <TheMuso> Hrm ok.
[22:37] <RAOF> Although what we'd actually want to do is add a "trigger an AOT rebuild" step to the end of the live installer.
[22:37] <TheMuso> Right, thats quite doable.
[22:38] <RAOF> I was forgetting that we don't actually install packages when installing from the livecd :)
[22:38] <TheMuso> Correct, we do a filesystem copy.
[22:38] <TheMuso> Then things are added/tweaked/removed as appropriate.
[22:39] <RAOF> Yeah.  This would just add an extra tweaking step.
[22:41] <RAOF> I wonder if I should turn this into a blueprint with work items...
[22:41] <TheMuso> Depends on how much you have on your plate already.
[22:42] <jasoncwarner_> Ok, sounds like we are about done. thanks everyone!
[22:42] <TheMuso> np
[22:42] <TheMuso> brb
[22:42] <robert_ancell> RAOF, Should we bump this to Q https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-wayland-something-or-other?
[22:45] <RAOF> robert_ancell: That's actually supersceded by wayland-tech-preview, right?
[22:47] <robert_ancell> RAOF, yes, i guess so
[22:47] <RAOF> Marked as such.
[22:47] <RAOF> And we've punted tech-preview to Q?
[22:48] <robert_ancell> RAOF, yes
[22:48] <robert_ancell> RAOF, I'd still like to do it, but not commit to it
[22:48] <RAOF> Likewise.
[22:49] <RAOF> I guess we don't really have a "nice-to-have" chart on status.ubuntu.com
[22:50] <bryceh> robert_ancell, RAOF  yeah any relevant work items postponed from desktop-o-xorg-wayland-something-or-other probably should be carried over to the new blueprint
[22:51] <RAOF> I don't think there are any non-duplicate work items there.
[22:51] <bryceh> jasoncwarner_, sorry, had a LP stakeholder's meeting with skaet scheduled for this time; usually it's later on but guess daylight savings screwed it up
[22:51] <RAOF> At least, not ones that are still open.
[22:51] <bryceh> RAOF, ok then
[22:52] <jasoncwarner_> bryceh: no worries.
[22:52] <bryceh> jasoncwarner_, aside from catching up on bug triage, blueprints, and emails, not much to say on the X front
[22:53] <bryceh> we're having a launchpad stakeholder's meeting later this week (the first one in over a year!) so am gathering requests and ideas for launchpad improvements that we might want over the next 18 months
[22:53] <bryceh> current list:  https://dev.launchpad.net/Ubuntu/InfrastructureNeeds
[22:54] <bryceh> robert_ancell, RAOF for wayland, even if we don't do that blueprint, the wayland snapshots ought to be updated for P.  I can take that task.
[22:55] <bryceh> jasoncwarner_, one question with the work item limits; is  that the number you can do total, or just the max you can have open and assigned at one time?
[22:55] <bryceh> i.e. if I finish my 7, can I take 7 more, or should I stop working at that point and just do bugs only?
[22:58] <jasoncwarner_> bryceh: :) you can always take on more! this was the number pitti, based on calculations of previous cycles, assumed someone could reasonably do. obviously there is some play in those numbers depending on size of WI etc
[23:02] <TheMuso> How does one recalculate their WI limit if one adjusts their availability?
[23:02]  * TheMuso is in the google doc.
[23:03] <bryceh> jasoncwarner_, ok sounds good.  I'm bringing forward old postponed tasks from O that I'd like to still track.  I'll leave them marked postponed for now so they don't exceed the work item limit, and open them up when they won't exceed the limit.
[23:07] <TheMuso> jasoncwarner_: ^^ any idea about my questino above?
[23:08] <jasoncwarner_> TheMuso: not sure, what do you mean? like you have more time? less time?
[23:09] <TheMuso> jasoncwarner_: So I looked atht the doc and saw my availability was at 0.7. I changed it to 0.8, so am wondering how to recalculate the work item limit.
[23:10] <jasoncwarner_> ah, ok...I'll take a look (I didn't put it together, but since I have mad manager spreadsheet skillz, I'm sure I can figure it out ;) )
[23:10] <TheMuso> ok thanks.
[23:11] <jasoncwarner_> TheMuso: it auto adjusts
[23:11] <jasoncwarner_> changing to .8 raised your precise limit
[23:12] <TheMuso> hrm ok I didn't see it change...
[23:12] <TheMuso> Let me have another look.
[23:13] <TheMuso> Hrm ok, I probably don't remember looking at the limit prior to making the change. :)
[23:14] <TheMuso> Right, time to see if WIs can be merged/dropped.


[01:03] <mup> Bug #1482441 opened: maas-cli network connect-macs succeeds with invalid parameters when it should fail <cisco> <landscape> <MAAS:New> <https://launchpad.net/bugs/1482441>
[09:35] <mup> Bug #1482563 opened: validate_in_transaction() error message is too specific <MAAS:Triaged> <https://launchpad.net/bugs/1482563>
[10:32] <mup> Bug #1482589 opened: test_size_is_rounded_to_next_block is flaky <MAAS:New> <https://launchpad.net/bugs/1482589>
[14:35] <dooferlad> hi all, I have a MAAS here that has run out of addresses in the static pool and I want to delete all the existing allocations. Can someone help with that?
[14:38] <dooferlad> I guess POST op=release with the appropriate params to /MAAS/api/1.0/ipaddresses/ repeatedly. I feel a script coming on.
[14:46] <dooferlad> https://gist.github.com/dooferlad/082996faeb2168a76ab4 did it
[18:51] <mup> Bug #1482737 opened: Cannot acquire a node AttributeError: This QueryDict instance is immutable <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1482737>
[21:42] <mup> Bug #1482778 opened: Sorting by ram shows 3-digit machines at bottom of list <sts> <MAAS:New> <https://launchpad.net/bugs/1482778>
[21:57] <mup> Bug #1482784 opened: When filtering nodes by hostname in the API, have to use ".local" domain instead of the domain set for the cluster <oil> <MAAS:New> <https://launchpad.net/bugs/1482784>
[22:00] <mup> Bug #1482784 changed: When filtering nodes by hostname in the API, have to use ".local" domain instead of the domain set for the cluster <oil> <MAAS:New> <https://launchpad.net/bugs/1482784>
[22:12] <mup> Bug #1482784 opened: When filtering nodes by hostname in the API, have to use ".local" domain instead of the domain set for the cluster <oil> <MAAS:New> <https://launchpad.net/bugs/1482784>


[00:38] <bryceh> @pilot out
[02:03] <tsimonq2> arraybolt3: Synced mlpack for you.
[03:43] <tsimonq2> arraybolt3: Uploaded your munin merge.
[03:51] <arraybolt3> ginggs: Horking a pytables merge FYI, you can hork it back whenever.
[04:08] <tsimonq2> arraybolt3: Synced pytables for you.
[04:08] <arraybolt3> thanks :)
[04:09] <tsimonq2> No worries :)
[08:43] <ogayot> tsimonq2: it's /should/ end up being a sync this time!
[08:43] <ogayot> s/it's/it/
[11:03] <doko> arraybolt3: feel free to do any universe merge you would like to do
[13:40] <tsimonq2> @pilot in
[13:40] <tsimonq2> Here, kitty kitty kitty.
[13:41] <tsimonq2> ogayot: `syncpackage -f -s ogayot -b 2044243 kitty` .
[13:42] <tsimonq2> 🐈🐈🐈🐈🐈🐈🐈🐈🐈
[13:47] <tsimonq2> arraybolt3: Uploaded the satpy FTBFS patch for you.
[13:51] <tsimonq2> jbicha: Morning! You have TIL on sponsoring bug 2007702, want to take it? (Otherwise, I can take it tomorrow.)
[13:51] -ubottu:#ubuntu-devel- Bug 2007702 in chromium-browser (Ubuntu Mantic) "[SRU] Deb version numbering is misleading" [Low, New] https://launchpad.net/bugs/2007702
[13:51] <ogayot> tsimonq2: appreciated!
[13:52] <tsimonq2> ogayot: Always happy to sponsor src:kitty ;)
[13:53] <tsimonq2> ogayot: By the way, I had poked Till last night to see if he could take a peek at your Perl cups-related upload, that's taken care of as well. (Plus, you get an upstream maintainer for the library you're depending on acking your patch, so ;) )
[13:54] <jbicha> tsimonq2: don't forget to celebrate the holiday tomorrow 😉
[13:55] <tsimonq2> jbicha: Oh right, I always forget about those darn things until the day before, when my significant other reminds me. ;P
[13:55] <tsimonq2> jbicha: Happy Thanksgiving to you too ;)
[13:59] <ogayot> tsimonq2: ah yes, thanks for pinging Till about it! That was a good call.
[14:01] <tsimonq2> ogayot: Happy to help :)
[14:01] <tsimonq2> pushkarnk, vpa1977: https://code.launchpad.net/~pushkarnk/ubuntu/+source/pgpainless/+git/pgpainless/+merge/456008 sponsored, which (seems like) is blocking some OpenJDK stuff.
[14:03] <tsimonq2> arraybolt3: Your patch FTBFS, likely need a conditional for .11: https://launchpad.net/ubuntu/+source/satpy/0.44.0-1ubuntu1
[14:05] <tsimonq2> @pilot out
[14:05] <tsimonq2> That being said, I'm floating around.
[14:06] <pushkarnk> tsimonq2: Thanks for sponsoring! This was blocking the proposed-migration of java-common/0.75
[14:14] <tsimonq2> pushkarnk: Happy to help! Let me know if there's anything else I can sponsor to get that through. :)
[14:17] <tsimonq2> vpa1977: Also looking at bug 1930541 before I go; as I tell everyone when sponsoring SRUs, verbosity++ is good on SRU templates, so I'll sponsor it, but would appreciate a second look there. :)
[14:17] -ubottu:#ubuntu-devel- Bug 1930541 in maven (Ubuntu) "[SRU] Maven 3.6.3-1 fails to run with OpenJDK 17" [Undecided, Confirmed] https://launchpad.net/bugs/1930541
[14:25] <tsimonq2> Sponsoring queue should now be at 15 on next refresh. A good starter bug for the next pilot may be bug 2043954.
[14:25] -ubottu:#ubuntu-devel- Bug 2043954 in dnspython (Ubuntu) "Please merge dnspython 2.4.2-1 from debian unstable" [Undecided, New] https://launchpad.net/bugs/2043954
[14:28] <LocutusOfBorg> @pilot in
[14:28] <tsimonq2> LocutusOfBorg!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[14:29] <LocutusOfBorg> dnspython done
[14:29] <LocutusOfBorg> @pilot out :D
[14:29] <tsimonq2> LMAO good to see you LocutusOfBorg :D
[14:29] <LocutusOfBorg> @pilot out
[14:50] <LocutusOfBorg> tsimonq2, I can't merge this one? https://code.launchpad.net/~pushkarnk/ubuntu/+source/dnspython/+git/dnspython/+ref/merge-lp2043954-noble
[14:50] <LocutusOfBorg> is it automatic?
[15:11] <tsimonq2> LocutusOfBorg: hmm I'm unsure, usually they just leave a diff against debian/sid, I grab it and do it manually *most* of the time :P
[15:12] <tsimonq2> LocutusOfBorg: but yes the Git end of all that is automatic
[15:13] <LocutusOfBorg> ack
[15:13] <tsimonq2> Thanks for your help LocutusOfBorg
[16:19] <athos> @pilot in
[18:06] <arraybolt3> tsimonq2: eh? It built and autopkgtested right on my machine. Bet it's got something to do with a -proposed package tangling things up, I'll investigate further.
[18:11] <arraybolt3> I forgot to use something like --apt-pocket proposed when doing my local autopkgtests so that slipped by me.
[18:11] <arraybolt3> At least it didn't FTBFS with the exact same error :D
[18:16] <arraybolt3> grr, except these tests are done at build time, so autopkgtest stuff won't work here, I need to enable -proposed in sbuild. I remember how to do that I think though.
[19:19] <vpa1977> tsimonq2: Apologises, regarding 1930541, could you please elaborate on the second look? What have I missed there? =)
[19:29] <Eickmeyer> vpa1977: FYI, it's nice to prepend the bug number with "bug" so that ubottu spits out a link to click on. :) (I'll start: bug 1930541)
[19:29] -ubottu:#ubuntu-devel- Bug 1930541 in maven (Ubuntu) "[SRU] Maven 3.6.3-1 fails to run with OpenJDK 17" [Undecided, Confirmed] https://launchpad.net/bugs/1930541
[19:30] <vpa1977> Eickmeyer
[19:30] <vpa1977> Eickmeyer: thank you =)
[19:31] <Eickmeyer> LP: #{bug} also works, similar to a changelog entry. :)
[21:10] <tsimonq2> vpa1977: Just ensure the "what could go wrong" is fully up-to-date :)
[21:12] <vpa1977> tsimonq2: ok =)
[21:12] <tsimonq2> vpa1977: Thanks for all your work!
[21:13] <tsimonq2> arraybolt3: Just keep me posted, looking forward to getting an FTBFS fix uploaded soon.
[21:30] <athos> @pilot out
[22:17] <arraybolt3> I'm fighting with satpy at the moment, and while I *finally* have it building properly against -proposed, I'm getting a Lintian error "W: python3-satpy: python-module-in-wrong-location usr/lib/python3.12/dist-packages/satpy-0.44.0.dist-info -> usr/lib/python3/dist-packages/satpy-0.44.0.dist-info"
[22:17] <arraybolt3> er, warning I mean
[22:17] <arraybolt3> it looks like the package is trying to install a version for both Python 3.11 and Python 3.12?
[22:18] <arraybolt3> The built package has both /usr/lib/python3/dist-packages and /usr/lib/python3.12/dist-packages directories.
[22:19] <arraybolt3> Any advice on what to do at this point? cc tsimonq2
[22:19] <arraybolt3> oh hey look at this, the python3.12 "version" has one 7-byte file in it named "INSTALLER", which the python3 "version" also has, and they both just say "debian".
[22:21] <arraybolt3> I think what I should do is override something (dh_auto_install perhaps) and then just run an `rm -f debian/python*satpy/usr/lib/python3.12` in there.
[22:22] <arraybolt3> trying that now
[22:22] <arraybolt3> tsimonq2: thanks for your patience, this has been an unusually hard package that needed quite a bit of debugging to fix. Hopefully when this is through it'll let python3-xarray migrate too.
[22:24] <tsimonq2> arraybolt3: Nah, that doesn't seem like the correct approach. I'd say have python3.11 and 3.12 directories, because I *think* that'll Automagically work once we fully switch over to 12.
[22:24] <tsimonq2> arraybolt3: That's just my two cents.
[22:25] <arraybolt3> ah, that makes sense. (fwiw there's no python3.11/dist-packages directory, and I think Debian policy says there ought not be one, so I was just trying to obey the policy :) but you're probably right that it's just an Python transition thing.)
[22:25] <arraybolt3> In that instance I'll get a dep3 patch header done, then start final build tests and review before throwing another FTBFS fix at you.
[22:27] <tsimonq2> $ apt-file find /usr/lib/python3.11 | wc -l
[22:27] <tsimonq2> 15363
[22:27] <tsimonq2> *shrug*
[22:48] <arraybolt3> right, python3.11 exists, it's python3.11/dist-packages that shouldn't exist.
[22:51] <mwhudson> yeah that seems wrong
[22:52] <mwhudson> i just noticed i have python3.11/dist-packages as well (with cython and numpy stuff in it)
[23:03] <arraybolt3> hmm, weird
[23:04] <arraybolt3> https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-path maybe Lintian is buggy :P
[23:04] <arraybolt3> tsimonq2: Do I have to file another FTBFS bug against satpy or can I just throw this patch at you and have you do it?
[23:04] <arraybolt3> (er, have you upload it without needing another bug report?)
[23:06] <arraybolt3> actually I can append it to the existing bug
[23:08] <tsimonq2> arraybolt3: Perfect.
[23:14] <arraybolt3> tsimonq2: Follow-up fixes now available at https://bugs.launchpad.net/ubuntu/+source/satpy/+bug/2044216/comments/3.
[23:14] -ubottu:#ubuntu-devel- Launchpad bug 2044216 in satpy (Ubuntu) "FTBFS due to legacy resampler code (and a buggy test (and a new xarray version))" [High, Fix Committed]
[23:17] <tsimonq2> arraybolt3: .


[05:45] <pushkarnk> doko: working on an MP with a no-change rebuild to fix the changelog
[05:46] <pushkarnk> also, thanks ahasenack
[06:55] -queuebot:#ubuntu-release- New binary: qgis [ppc64el] (noble-proposed/universe) [3.28.15+dfsg-1] (no packageset)
[06:58] -queuebot:#ubuntu-release- New binary: qgis [amd64] (noble-proposed/universe) [3.28.15+dfsg-1] (no packageset)
[07:04] -queuebot:#ubuntu-release- New: accepted qgis [amd64] (noble-proposed) [3.28.15+dfsg-1]
[07:04] -queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (noble-proposed) [3.28.15+dfsg-1]
[08:16] -queuebot:#ubuntu-release- New binary: node-undici [armhf] (noble-proposed/universe) [5.28.2+dfsg1+~cs<IP_ADDRESS>-4] (no packageset)
[08:55] -queuebot:#ubuntu-release- New: accepted libxfce4windowing [source] (noble-proposed) [4.19.2-1ubuntu1]
[11:07] -queuebot:#ubuntu-release- New: accepted node-undici [armhf] (noble-proposed) [5.28.2+dfsg1+~cs<IP_ADDRESS>-4]
[17:17] -queuebot:#ubuntu-release- New binary: rust-loom [amd64] (noble-proposed/universe) [0.5.6-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-loom [arm64] (noble-proposed/universe) [0.5.6-2] (no packageset)
[17:28]  * tsimonq2 notes that Qt and Python 3 are entangled.
[17:29] <arraybolt3> lovely
[17:29] <tsimonq2> qgis seems to be the culprit. :)
[17:37] <vorlon> python3-defaults is just switching the default though, so should be blocking only because of autopkgtests, right?
[17:38] <vorlon> if Qt were otherwise ready to go, we could also roll qgis back to 3.28.14+dfsg-1build1 for the transition
[17:50] -queuebot:#ubuntu-release- New binary: rust-loom [riscv64] (noble-proposed/universe) [0.5.6-2] (no packageset)
[18:18] <tsimonq2> vorlon: I'll have a better answer (read: more thought out) tomorrow, for the time being it's an FYI :) if you find anything interesting in the meantime, let us know.
[19:44] <arraybolt3> Not sure if anyone else is working on Python-related untangling, but if so, I'm taking abinit unless someone else is already working on it.
[23:14] -queuebot:#ubuntu-release- New binary: libgeo-wkt-simple-perl [amd64] (noble-proposed/none) [0.05-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: libdata-find-perl [amd64] (noble-proposed/none) [0.03-2] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-symphonia-core [amd64] (noble-proposed/none) [0.5.2-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-statsd [amd64] (noble-proposed/none) [0.16.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: rust-symphonia-core [armhf] (noble-proposed/none) [0.5.2-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [amd64] (noble-proposed/none) [0.7.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [amd64] (noble-proposed/none) [0.10.2-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-include-dir [amd64] (noble-proposed/none) [0.7.3-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: pynfft [amd64] (noble-proposed/none) [1.3.2-8] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: rust-gix-lock [amd64] (noble-proposed/none) [12.0.1-1] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [armhf] (noble-proposed/none) [0.7.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: pynfft [arm64] (noble-proposed/none) [1.3.2-8] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: rust-include-dir [ppc64el] (noble-proposed/none) [0.7.3-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: pynfft [ppc64el] (noble-proposed/none) [1.3.2-8] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: rust-symphonia-core [arm64] (noble-proposed/none) [0.5.2-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: rust-statsd [arm64] (noble-proposed/none) [0.16.0-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [armhf] (noble-proposed/none) [0.10.2-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-statsd [armhf] (noble-proposed/none) [0.16.0-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [arm64] (noble-proposed/none) [0.10.2-1] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: rust-symphonia-core [ppc64el] (noble-proposed/none) [0.5.2-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [arm64] (noble-proposed/none) [0.7.0-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-gix-lock [ppc64el] (noble-proposed/none) [12.0.1-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: pynfft [armhf] (noble-proposed/none) [1.3.2-8] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: rust-statsd [ppc64el] (noble-proposed/none) [0.16.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [ppc64el] (noble-proposed/none) [0.7.0-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: rust-gix-lock [armhf] (noble-proposed/none) [12.0.1-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: rust-gix-lock [arm64] (noble-proposed/none) [12.0.1-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [ppc64el] (noble-proposed/none) [0.10.2-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: pyfftw [amd64] (noble-proposed/none) [0.13.1-2] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [s390x] (noble-proposed/none) [0.7.0-1] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: pynfft [s390x] (noble-proposed/none) [1.3.2-8] (no packageset)
[23:36] -queuebot:#ubuntu-release- New binary: rust-include-dir [armhf] (noble-proposed/none) [0.7.3-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-include-dir [arm64] (noble-proposed/none) [0.7.3-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [s390x] (noble-proposed/none) [0.10.2-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: pyfftw [ppc64el] (noble-proposed/none) [0.13.1-2] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-include-dir [s390x] (noble-proposed/none) [0.7.3-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-gix-lock [s390x] (noble-proposed/none) [12.0.1-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-statsd [s390x] (noble-proposed/none) [0.16.0-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-symphonia-core [s390x] (noble-proposed/none) [0.5.2-1] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: pyfftw [s390x] (noble-proposed/universe) [0.13.1-2] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: rust-include-dir [riscv64] (noble-proposed/universe) [0.7.3-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: golang-github-prometheus-community-pgbouncer-exporter [riscv64] (noble-proposed/universe) [0.7.0-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: rust-statsd [riscv64] (noble-proposed/universe) [0.16.0-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: rust-compiletest-rs [riscv64] (noble-proposed/universe) [0.10.2-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: pynfft [riscv64] (noble-proposed/universe) [1.3.2-8] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: rust-gix-lock [riscv64] (noble-proposed/universe) [12.0.1-1] (no packageset)


[03:25] <Omnifrog> ok, that install went south pretty quickly
[14:51] <cyberanger> Due to bot spam in other channels, thinking it'd be wise to set mode +q $~a here
[14:53] <cyberanger> Since everyone in here is registered, I'm going to do that now & anyone unregistered won't be able to message in here (but they can join the channel still).