[07:55] <pitti> hey calc, good luck with that
[07:55] <pitti> I'm just getting an ordinary cold, but terribly sore throat
[08:25] <huats> morning everyone
[12:53] <seb128> james_w: hi, do you still get bug #173212?
[12:54] <james_w> I did two months ago
[12:54] <james_w> I can test again if you like
[12:54] <james_w> I guess it's more an alsa problem
[12:54] <seb128> james_w: I think the bug is misassigned
[12:55] <seb128> right, but it's not clear exactly what your issue is
[12:55] <seb128> you say that the mixer and applet don't show the same volumes for the same channel?
[12:55] <james_w> the issues is that a new session changes the behaviour
[12:55] <seb128> but that's specific to the applet?
[12:55] <james_w> I'm not sure
[12:55] <seb128> or alsamixer show issues too?
[12:56] <seb128> it would be interesting to know if the alsa settings changes
[12:56] <seb128> or if that's just the applet which shows a wrong status
[12:57] <seb128> there is no hurry to try, don't close your session only for that
[12:57] <seb128> I'm just trying to clean the needinfo bugs
[12:57] <seb128> the fact that this one is hardware specific seems to suggest a driver or alsa issue rather than an applet one
[12:58] <seb128> we lack somebody knowing about the audio stack triaging those bugs
[12:59] <mvo> ember_: hello! I'm looking at the brasero update right now, thanks for working on this! what is the rational for dropping "-+X-Ubuntu-Gettext-Domain=brasero" - is this now done automatically by something?
[13:03] <mvo> seb128: do we have something that sets the X-Ubuntu-Gettext-Domain automatically now (or is there something that makes it obsolete?)
[13:03] <seb128> mvo: gnome.mk when using cdbs does
[13:03] <seb128> mvo: but that's not new
[13:04] <seb128> mvo: otherwise you have to do it in the rules
[13:04] <mvo> I rarely use gnome.mk I guess this is why I haven't noticed
[13:04] <seb128> mvo: cdbs hater ;-)
[13:05] <seb128> mvo: in fact langpack.mk does it, so you can include that rather than gnome.mk but GNOME packages usually use the gnome one for schemas registration, etc
[13:05]  * mvo nods
[13:06] <mvo> ember_: thanks, seb128 figured it out for me :)
[13:10] <james_w> seb128: confirmed.
[13:10] <james_w> seb128: when in a session I can mute, which leaves the volume level at e.g. 50% and sets the mute flag
[13:11] <james_w> seb128: when I restart my session it comes back muted, but with the volume set to 0%, and not having the mute flag set
[13:11] <seb128> you mean the applet has a mute icon?
[13:11] <james_w> seb128: alsamixer just shows a pulseaudio device, do you know how I can debug that side of this further
[13:12] <seb128> what does alsamixer shows?
[13:12] <james_w> the applet has a mute icon, but the checkbox in the context menu is un-checked
[13:12] <seb128> well the applet displays a mute icon when volume = 0
[13:12] <james_w> if you scroll to 0% in the applet then it gets the mute icon
[13:12] <seb128> try pavucontrol?
[13:13] <seb128> what does the gnome mixer displays if you double click on the applet icon for example?
[13:13] <seb128> just to be clear there
[13:13] <seb128> - you have some volume set
[13:13] <seb128> - right click on the applet, select the mute option there
[13:14] <seb128> - the applet is showing the volume as muted, what does the mixer display as volume then?
[13:14] <james_w> the same value as before selecting mute
[13:14] <seb128> - then you restart your session and the volume is 0 rather than using the mute toggle
[13:14] <james_w> yes
[13:14] <seb128> it seems that the volume is changing between sessions then
[13:14] <james_w> so my complaint is that it is not consistent.
[13:15] <seb128> something is switching mute and volume to volume = 0
[13:15] <james_w> agreed
[13:15] <james_w> pavucontrol isn't showing anything useful
[13:15] <seb128> I guess you will have the same issue without having an applet configured
[13:15] <james_w> the gnome mixer is showing volume = 0 and not muted, as you would expect
[13:15] <seb128> ok, I don't know enough about pulseaudio and alsa to give you useful hints there
[13:16] <james_w> I agree, but I don't know how to confirm that
[13:16] <seb128> you would not expect that
[13:16] <seb128> you would expect the volume to be what it was during the previous session
[13:16] <james_w> yeah, I mean I expect that given what the applet is showing
[13:16] <seb128> and the mute flag to be set
[13:16] <seb128> ok, anyway doesn't look like a gnome-applets bug
[13:16] <james_w> I agree
[13:17] <seb128> maybe you can reassign to alsa-lib rather and try to ask to crimsum when he's around if he has an idea about the issue
[13:17] <seb128> you can also try to uninstall pulseaudio and see if you still get the issue when using alsa directly
[13:17] <seb128> hum
[13:17] <seb128> you opened this bug before the pulseaudio time I think
[13:18] <seb128> reassing to alsa-lib and let them deal with the bug
[13:25] <james_w> thanks seb128
[13:25] <james_w> I updated the bug report to be more clear about the behaviour
[13:25] <seb128> james_w: thank you for testing and updating the bug ;-)
[14:01] <asac> seb128: installed xul <IP_ADDRESS> yet? please go for it and let me know if ephy still crashes on shutdown
[14:02] <seb128> asac: not yet, I will let you know, they fixed something which seems similar to the issue?
[14:03] <asac> seb128: just the comment from debian ;)
[14:03] <seb128> ok
[14:10] <asac> seb128: hmmm .... do you use REVU and get acks from two MOTUs for new packages :-P ?
[14:10] <seb128> asac: lol, good one!
[14:10] <asac> well. i am looking through wiki
[14:10] <seb128> asac: no, I use my upload power and get one ack from pitti when it's in NEW ;-)
[14:11] <asac> thats breach of policy isnt it?
[14:11] <seb128> what policy?
[14:11] <asac> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:11] <seb128> that's a MOTU thing
[14:11] <asac> what does that mean?
[14:11] <seb128> I'm not a MOTU ;-)
[14:12] <asac> core-devs dont need taht?
[14:12] <pitti> seb128: you are
[14:12] <asac> this just came up because MOTUs want mozilla packages to go through REVU ... which is completely senseless imo
[14:12] <seb128> well, let's say I've enough to do without bothering using revu, etc
[14:12] <seb128> so maybe I'm abusing my power there dunno
[14:12] <asac> because no MOTU ever reviewed any mozilla package
[14:12] <seb128> but I really don't feel doing extra paper work only to be compliant to some MOTU policy on the topic
[14:13] <asac> seb128: i feel the same. but just ignoring it cant be right ;)
[14:13] <asac> we need to fix that policy then i think
[14:13] <pitti> I thought that revu thing would only apply for non-MOTUs
[14:14] <asac> pitti: apparenlty thats not the case.
[14:14] <pitti> i. e. folks who start learning packaging have to get two MOTU acks (or, likely, some iterations of fixing) before uploading to NEW?
[14:14] <asac> persia said that everything has to go through REVU
[14:14] <asac> for NEW packages
[14:14] <pitti> hm, that's news to me, too
[14:14] <asac> pitti: i think REVU is for non-MOTUs ... and new-packages
[14:14] <asac> pitti: well. policy is that you need two ACKs if you want to upload a new package
[14:15] <asac> REVU is just the standard procedure
[14:15] <asac> pitti: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:15] <pitti> asac: oh, good to know
[14:16] <seb128> what define a policy and who approve what is official policy?
[14:16] <asac> pitti: my personal feeling is that this policy cannot be valid for packages that MOTU team doesnt care for
[14:16] <seb128> ie is that wiki page something official or something MOTU decided in a unilateral way?
[14:16] <asac> for instance: mozillateam packages -> MOTU never touch those
[14:16] <pitti> asac: well core-dev is a subset of MOTU
[14:17] <asac> seb128: i am not sure what the policy process is
[14:17] <asac> from what i understand motu council can just release policies on their own
[14:17] <seb128> and that stands for universe imho
[14:18] <seb128> well I'm not sure why a MOTU should have to go through REVU review either
[14:18] <asac> as a matter of fact most packages go into universe first
[14:18] <seb128> somebody who knows about packaging should be able to just do it and upload
[14:18] <asac> i agree
[14:18] <seb128> right, but that's creating paper work, slowness and extra work for no good reason
[14:19] <asac> right. and fta's experience with REVU is that you never get two acks there
[14:19] <seb128> let's move that to #ubuntu-devel maybe rather?
[14:19] <asac> the first will happen quickly ... the second never happens and you have to run around poking folks
[14:19] <seb128> or wait for dholbach reply?
[14:20] <asac> seb128: lets wait for dholbach
[14:20] <seb128> well, REVU is similar to sponsoring
[14:20] <asac> seb128: and then discuss this properly
[14:20] <asac> when i have the cycles too
[14:20] <seb128> lot of items, not enough manpower, extra delais
[14:20] <asac> i am about to run ;)
[14:20] <seb128> ok
[14:20] <asac> i think archive admin review should be enough for those that have upload rights
[14:20] <seb128> yes
[14:21] <asac> if archive admins say that there is too much garbage then they are supposed to push for a pre-review
[14:21] <asac> at least if archive admins dont ask for it, there is no reason for such a policy
[14:21] <seb128> well, somebody who has upload rights should be able to produce a mostly correct package
[14:36] <ember_> sorry mvo i wasn't here, and thanks for sponsoring.
[14:36] <ember_> seb128: when you have time can you renew me on desktop-bugs team
[14:37] <seb128> the team is an open one you can do that on launchpad directly
[14:37] <ember> where? i was able to renew bugteam but not desktop-bugs
[14:38] <seb128> not sure of the url but your subscription details should let you renew it
[14:38] <seb128> or you might need to wait until expiration
[14:39] <seb128> the team is an open one for sure and you don't need an admin approval, not sure about the launchpad interface, you can ask on #launchpad if that's not clear
[15:40] <seb128> fta: hey, did you read my comments about the cairo update the other day?
[16:00]  * pitti rings the desktop team meeting bell
[16:00] <calc> here
[16:00] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-11-18
[16:00] <pedro_> hello
[16:00] <seb128> hey
[16:00] <calc> oh yea this should be updated on fridge bueno can do it apparently if we ask him
[16:00] <pitti> bryce, Riddell, Keybuk, ArneGoetje: there?
[16:01] <ArneGoetje> hi
[16:01] <Keybuk> _o/
[16:01] <pitti> asac is on holiday
[16:02] <Riddell> hi
[16:02] <pitti> calc: as our US representative, could you ring bryce?
[16:02] <calc> ok
[16:03] <pitti> that's actually the first topic
[16:03]  * calc looking up his number now
[16:03] <pitti> I'll talk to beuno to get the desktop team meeting on the fridge
[16:03] <pitti> seb128 noticed that there wasn't a team meeting reminder
[16:03] <pitti> do you guys actually want to get one every week? or woudl having the meeting in evo be enough for you, and we avoid cronspam?
[16:04] <seb128> having it in e-d-s would be enough imho
[16:04] <seb128> which is not the case right now
[16:04] <Keybuk> pitti: I briefly talked to persia about it, apparently the meeting can't go on the fridge, because we don't use #ubuntu-meeting
[16:04] <pitti> uh?
[16:04] <Riddell> an e-mail the day before to remind about activity I find nice
[16:05] <calc> he didn't answer the phone
[16:05] <pitti> calc: ok, thanks for trying
[16:05] <Riddell> there's nothing channel specific about fridge events, it's for all events
[16:05] <Keybuk> Riddell: apparently the #ubuntu-meeting bot gets confused
[16:05] <Riddell> that's the bot's problem
[16:06] <pitti> ok, I'll continue to send the reminders for now
[16:06] <pitti> ACTION: pitti to continue to send out meeting reminder emails and ask beuno to get it on the fridge
[16:06] <seb128> Keybuk: the calendar can have non meeting events too no? we don't specifically need that to be set as a meeting slot there
[16:07] <Keybuk> dunno :)
[16:07] <Riddell> "Desktop Team Meeting" is on fridge, but for wrong day
[16:07] <pitti> before we come to the main topic: two weeks ago we went through the intrepid-updates bugs
[16:07] <seb128> well, milestones are on the calendar
[16:07] <pitti> it would really be good to get them sorted by UDS, since at UDS and afterwards we'll all have jaunty in our heads
[16:07] <pitti> are there any blockers, or bugs which turned out to be complicated?
[16:08] <Riddell> the cmake/kde4libs/adept breakage is a bit strange
[16:08] <pitti> Riddell: the kde4libs SRU broke builds?
[16:08] <Riddell> yeah
[16:08] <Riddell> NCommander is being great and working on it though
[16:09] <pitti> so shold that block -updates migration of kde4libs? (the bug is verified otherwise)
[16:09] <Riddell> yes, for now
[16:09] <Riddell> it'll likely need a patch to kde4libs to fix
[16:09] <pitti> Riddell: noted
[16:09] <pitti> all others are fine with their intrepid-updates bugs?
[16:10] <seb128> GNOME 2.24.2 tarballs due next week
[16:10] <pitti> oh, fun
[16:10] <seb128> but I don't think we will try to do all the updates since that's not a lts
[16:10] <pitti> right, I agree; it actually was a special exception for hardy
[16:10] <seb128> the evo stack will likely get an another round of updates though
[16:10] <pitti> so we'll only do updates to major bug fixes then?
[16:11] <seb128> yes
[16:11] <pitti> which reminds me, Riddell, is the new kde microrelease in -proposed?
[16:11] <Riddell> pitti: no, I got distracted by merges
[16:11] <Riddell> pitti: I wasn't clear, does it need one bug for every package?
[16:11] <Riddell> or just one meta-bug?
[16:11] <pitti> Riddell: yes, one representative for each package would be good, to track verification and migration
[16:11] <pitti> some uploads already have an LP #
[16:12] <pitti> so we only need one for packages which don't fix any LP bug in their changelog
[16:12] <Riddell> ok
[16:12] <pitti> ok, then let's get to UDS preps
[16:12] <pitti> Keybuk: any initial words?
[16:13] <pitti> last week I asked you to think about what you would like to work on during jaunty
[16:13] <pitti> so I propose everyone gives a quick overview about their intentions
[16:14] <pitti> personally I'd like to concentrate on fixing bugs, robustifying the apport retracers, and working on CD size
[16:14] <Keybuk> I think it'd be worth going through each person to get a list of spec ideas firmed up
[16:14] <seb128> what pitti said + GNOME 2.26 ;-)
[16:15] <pitti> ArneGoetje: ?
[16:15] <ArneGoetje> I have enough on my plate: basically continue to work on my usual stuff... fonts, language-selector, font-selector, plus a new item: ibus (a candidate to replace scim)
[16:16] <Keybuk> you've registered a spec about ibus
[16:16] <ArneGoetje> yes
[16:16] <Keybuk> are there any others you'd want for UDS?
[16:16] <pitti> ArneGoetje: does ibus need UDS discussion, or is it a "just do it" thihng?
[16:16] <ArneGoetje> needs UDS discussion
[16:16] <pitti> ah, ok
[16:16] <ArneGoetje> Keybuk: no thanks :) as I said, I have enough on my plate
[16:16] <Keybuk> do you think language-selector or font-selector could warrant a discussion?
[16:17] <Keybuk> especially since we have new UI and Desktop-interested people?
[16:17] <ArneGoetje> I will probably discuss with mpt about GUI rework and additional features for language-selector.
[16:17] <pitti> ArneGoetje: please register a spec for this then, so that it can be scheduled
[16:18] <ArneGoetje> font-selector: I'm looking forward to finally get hold of Keith Packard... need to prod him for more info about fontconfig.
[16:18] <Keybuk> sounds like they're both worth scheduling an hour for, then
[16:18] <ArneGoetje> pitti: will do
[16:18] <mpt> mm, additional features
[16:18] <pitti> ArneGoetje: thanks; please propose it for the uds-jaunty meeting, so that it stands out from the noise
[16:19] <ArneGoetje> pitti: ok
[16:19] <pitti> ok, thanks
[16:19] <pitti> calc?
[16:19] <calc> get release exception and OOo 3.1 in, get OOo languages switched to Pootle/Rosetta, get OOo split builds working.
[16:19] <Keybuk> which of those are worth a UDS discussion?
[16:20] <Keybuk> sounds like the pootle/rosetta one could be?
[16:20] <calc> i need to talk to doko and rosetta people about that one yes
[16:20] <calc> the release exception i just need to ask for it from the release team i guess, not sure if we need a meeting for that one
[16:21] <pitti> calc: agreed, but the pootle one does warrant one, I think
[16:21] <calc> yes
[16:21] <calc> i will create a blueprint for it
[16:22] <pitti> @all: please nominate them for uds-jaunty
[16:22] <pitti> Riddell: what are your plans?
[16:23] <Keybuk> (and the plans of the Kubuntu Kommunity)
[16:23] <Keybuk> err, I swear I didn't do that deliberately
[16:23] <pitti> of Kourse
[16:23] <Riddell> pitti: listed here https://wiki.kubuntu.org/KubuntuJauntySpecs
[16:24] <Riddell> pitti: summaried as make Kubuntu with KDE 4 good enough for the whingers on the kubuntu-users mailing list :)
[16:24] <Riddell> pitti: we have a meeting tonight to discuss them more, then I'll register the specs in LP
[16:24] <pitti> Riddell: nicely prepared!
[16:25] <pitti> ok, that's everyone except bryce
[16:25] <pitti> ACTION: pitti to talk to bryce about jaunty plans
[16:25] <Keybuk> (and asac, but he's on leave)
[16:25] <pitti> right
[16:25] <pitti> so it seems to be a cleanup cycle for GNOME and KDE, and in general
[16:26] <kwwii> so I am officialy not on the team anymore, right?
[16:26] <pitti> kwwii: sorry, wasn't aware that you were lurking; feel free to introduce your plans as well :)
[16:27] <kwwii> pitti: actually, I don't think I am part of the team anymore...wasn't being nasty :-)
[16:29] <pitti> ok, please make sure to register your specs, preferably by the end of the week
[16:30] <pitti> and let's finish that intrepid thing, so that we have our heads free for jaunty
[16:30] <pitti> I cleared my intrepid-updates bug list, so if anyone needs a hand for his', please give me a ping
[16:30] <pitti> AOB?
[16:31] <pitti> oh, one thing
[16:31] <pitti> DebianImportFreeze is December 25, which means in practice that we have this, next, and one week after UDS for finishing merges
[16:32] <pitti> okay, I feel alone now, so let's wrap up :)
[16:32]  * seb128 hugs pitti
[16:33]  * calc hugs everyone while... not getting them sick ;-)
[16:33] <seb128> oh, I intend to start on GNOME 2.25 for GNOME 2.25.2
[16:33] <seb128> ie, the week before uds
[16:33] <seb128> I don't think we have a real need to hurry on pushing 2.25.1, there is not a lot of users on jaunty yet
[16:33] <seb128> and I prefer to use the time to do cleaning
[16:33] <Keybuk> kwwii: *hugs*
[16:34] <pitti> seb128: sounds fine
[16:35] <seb128> pitti: ok, good, let's do some good cleaning before starting on new crack ;-)
[16:36] <pitti> yeah, and for jaunty too :)
[16:36] <pitti> I appreciate having some time to work on bugs
[16:37] <seb128> me too
[16:38] <bryce> heya
[16:38] <bryce> sorry, I'm onsite in Lexington and was helping an engineer with an X bug
[16:39] <seb128> hey bryce
[16:40] <pitti> hi bryce
[16:41] <pitti> bryce: can you please give a quick intro about what you are planning to work on in jaunty?
[16:41] <bryce> regarding specs, there are a few that ubuntu-x community members are taking the lead on (config tools, etc.) which I'll be assisting on
[16:41] <bryce> I've also posted one for switching -ati from XAA to EXA
[16:41] <bryce> that should be pretty straightforward; mostly just testing and following up on bugs
[16:42] <bryce> testing = stability + performance testing
[16:42] <bryce> also I plan to do more work on my ongoing Xorg testing spec.  Make XSmoke, and the historical drivers page
[16:42] <bryce> aside from that probably won't have much time remaining - OEM X bugs are consuming most of my time these days
[16:44] <bryce> I do want to put a lot of time into getting distro X bugs closed as I'm having good momentum with upstream at getting fixes, so am glad bug fixing is a focus.  I hope I'll have enough time to work on that.
[16:44] <pitti> bryce: ok, so maintenance, cleanup, and better testing?
[16:45] <bryce> right, and enhancing tools for configuration and troubleshooting
[16:45] <pitti> great, seems everyone is focusing on that in jaunty, so far I didn't hear about major new structural changes
[16:45] <pitti> (of which we had quite a lot in hardy, for example)
[16:45] <pitti> jaunty should have been an ideal LTS cycle :-P
[16:45] <seb128> we picked the bad cycle for hardy
[16:45] <bryce> the one pending  X structural change is kernel modesetting; not sure how much we want to push that.  Sounds like it's still fairly experimental.
[16:45] <seb128> s/hardy/the lts
[16:46] <pitti> bryce: ok, thanks for the intro; can you please make sure that the things you want to discuss with others have a blueprint registered, and proposed it for uds-jaunty?
[16:46] <bryce> pitti: yes, all have blueprints registered at this point
[16:46] <pitti> bryce: right, KMS sounds worth discussing
[16:46] <bryce> I'll make sure they're proposed
[16:46] <pitti> bryce: cheers
[16:49] <Keybuk> bryce: are the ones you've posted suggested for uds-jaunty?
[16:49] <Keybuk> I can't find them in the proposed list
[16:49] <seb128> pitti: btw is the multimedia stack a platform or a desktop team land?
[16:49] <bryce> Keybuk: not yet; I'm doing that presently
[16:49] <seb128> I really think we should do something to address the audio stack being outdated and buggy
[16:49] <rlaager> Amen!
[16:49] <Keybuk> bryce: *resists the urge to bring the previous #ubuntu-devel topic in here*
[16:50] <pitti> seb128: as in gstreamer (desktop) or alsa (platform)?
[16:50] <seb128> pitti: as in pulseaudio
[16:50] <pitti> pulseaudio actually sounds desktopish, but since Luke handles it, it's platform
[16:51] <seb128> pitti: or totem and rhythmbox
[16:51] <seb128> not working correctly due to it
[16:51] <bryce> Keybuk: done.
[16:51] <seb128> pitti: "handle", the list of bugs doesn't seem really triaged, the version is outdated, sound effects are not working due to oudated libcanberra, etc
[16:52] <bryce> Keybuk: a few don't really need full discussion sessions for them.
[16:52] <seb128> pitti: would be really nice to put some extra ressources to solve that
[16:52] <pitti> yes, full ack
[16:53] <Keybuk> bryce: x.org conf options editor - is that separate to alberto's spec?
[16:54] <rlaager> pitti, seb128: If the "replacing Pidgin with Empathy" thing comes up again, I'd really like to find a way (i.e. figure out the design and get some code written) to ensure that users can have their libpurple (Pidgin, et al.) IM logs automatically read by Empathy. I think that's the most important "data" that an IM client has given that buddy lists are generally stored on the server.
[16:55] <bryce> Keybuk: nope it's one of the items alberto is working on
[16:55] <rlaager> pitti: I'm obviously not going to propose having that discussion at UDS, but you thought it might come up. If it does, I'd definitely want to be involved.
[16:55] <bryce> Keybuk: that's actually a part-2 from a spec we discussed last UDS
[16:55] <Keybuk> https://blueprints.edge.launchpad.net/ubuntu/+spec/screen-configuration-ui
[16:55] <Keybuk> is already proposed
[16:55] <pitti> rlaager: personally I'm not planning it for jaunty either, since I'd really like to let people work on bug fixing
[16:56] <rlaager> pitti: Ok. I like bug fixing. That's what I want to focus on, but I'm not on any Ubuntu teams officially.
[16:56] <calc> rlaager: merged users (across protocols) is somewhat useful as well and is only stored in libpurple
[16:56] <pitti> rlaager: but independently from that, I think that switch will be made in the distro worlds at *some* point, so talking about migration paths is always good, even if it lands in jaunty+n
[16:56] <tedg> Is there a session at UDS planed for talking about the new GDM?
[16:56] <seb128> rlaager: hi
[16:56] <rlaager> calc: It was my understanding that Empathy didn't support meta-contacts/persons.
[16:57] <calc> rlaager: oh ok
[16:57] <pitti> tedg: good point; can you please register one, so that we can review the missing features and see which ones we need to implement?
[16:57] <bryce> Keybuk: yep, screen-configuration-ui is essentially a part-3 to this, to expand on the xorg-options-editor functionality
[16:57] <rlaager> seb128: Hello! Hopefully I'll be generating more patches for you instead of just a pile of bug reports. :)
[16:57] <tedg> pitti: Okay.
[16:57] <Keybuk> bryce: ah
[16:57] <Keybuk> which is part 1 ?
[16:57] <Keybuk> which is part 2?
[16:57] <seb128> rlaager: quick comment about this gtk bug where you added a upstream change, we usually don't do too much backporting to non-lts if there is not a strong reason to do
[16:58] <seb128> rlaager: the stable updates are quite some work and the team is small so we try to reserve backports to annoying issues
[16:58] <bryce> part 1 is the little dialog enhancement to screen-display-properties which adds in Virtual options for dual-screen functionality - this is deployed already in Intrepid
[16:58] <rlaager> seb128: Fair enough. What about for Jaunty? I'm not sure how much distro patching you like to do.
[16:58] <Keybuk> ok great
[16:58] <Keybuk> I've put them in the right order in the schedule
[16:59] <seb128> rlaager: let's see when they will roll a new tarball, if they don't we will do backporting
[16:59] <bryce> part 2 is to expand that into a general purpose option editor.  part 3 is to expand that into a general purpose xorg.conf configuration tool.
[16:59] <bryce> part 2 is mostly done except for integration, so part 3 is maybe doable for jaunty, but needs discussion.
[17:00] <rlaager> seb128: For what it's worth, I'm at basically 100% of my non-public data under ~/Private now and things seem to work well. I'd love to hear your thoughts on killing off ~/.recently-used (note, not .xbel) by finding and rooting out the EggRecent code from apps (at least Totem, I think).
[17:01] <seb128> that's a good idea but ideally something GNOME would do
[17:01] <johanbr> rlaager: Empathy git has some code for log migration. Haven't tried it, though.
[17:01] <rlaager> johanbr: I'll have to look at that.
[17:09] <ArneGoetje> I guess we are finished with the meeting?
[17:10] <pitti> bryce: oh, were you planning to do the acpi-support obsoletion, too? some of it can be fanned out to several people, but I think someone needs to coordinate it
[17:11] <pitti> ArneGoetje: yes, a while ago
[17:11] <ArneGoetje> pitti: didn't notice since there is still discussion going on... :P
[17:11]  * ArneGoetje -> bed
[17:11] <pitti> well, it's #ubuntu-desktop :)
[17:11] <pitti> ArneGoetje: sleep well
[17:11] <ArneGoetje> thanks
[17:12] <bryce> pitti: unfortunately I likely won't have much time to help
[17:12] <bryce> pitti: the OEM team is going to need a lot of X support going forward, and don't have a dedicated X guy (yet?)
[17:12] <pitti> bryce: since you absorbed quite a lot of knowledge about acpi-support while you were debugging this stuff and doing the merge, would you mind giving a quick tutorial about it at UDS, so that others can help?
[17:13] <bryce> sorry, I must run to another OEM thingee... bbia hour
[17:13] <pitti> so that we get a plan "what do we need to do to migrate to pm-utils"?
[17:13] <bryce> pitti: be happy to participate in the session.  Don't know I really have that much wisdom to share but glad to braindump.
[20:03] <rlaager> This might be something to discuss at UDS: https://bugs.launchpad.net/ubuntu/+bug/40306
[20:04] <rlaager> It is, of course, not fixed (at least not from my point of view with bug #40334, which was marked as a duplicate of it).


[12:18] <totoxxd> .
[12:45] <s9iper1> totoxxd:yes
[12:45] <s9iper1> ?
[18:02] <bil21al> hggdh? are  you there?
[18:02] <hggdh> bil21al: yes, for a short time
[23:05] <codepal> I've just marked https://bugs.launchpad.net/harvest/+bug/722947 invalid, can I have someone double check I've used the right tag?
[23:05] <ubot4`> Launchpad bug 722947 in harvest "Javascript does not work in Opera (affects: 1) (heat: 8)" [Low,Invalid]
[23:06] <micahg> well, that's not a bug in ubuntu, but harvest, but it looks ok
[23:07] <jtaylor> nonono
[23:07] <jtaylor> thats a remnant of a bug I reported a while ago
[23:08] <jtaylor> its probably not fixed but worked around
[23:09] <jtaylor> or is it?
[23:09] <jtaylor> can't find my old bug ._.
[23:13] <jtaylor> its still using the static html for me with opera
[23:14] <codepal> jtaylor, remnant?
[23:14] <codepal> search javascript isn't working in Opera 11.61 - just opened the bug again....
[23:15] <codepal> got a stack trace from Opera, seems a syntax error is causing it - hope it helps!
[23:15] <jtaylor> yes thats what I got a while ago too
[23:15] <jtaylor> the non javscript version is less tested than the javascript one
[23:15] <jtaylor> bug 721486 was my original report
[23:16] <ubot4`> Launchpad bug 721486 in harvest "type error when clicking on "limit to" with opera (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/721486
[23:16] <jtaylor> its indeed better, but its still not the full js version firefox gets
[23:21] <codepal> jtaylor, just a dumb question - do you like using Opera?
[23:21] <jtaylor> yes
[23:21] <jtaylor> been using it since ages
[23:22] <jtaylor> never been a friend of firefox'es "install 20 untrusted extensinos to get it halfwy usable" approach
[23:22] <codepal> lol - dragonfly is a very sweet dev tool
[23:23] <jtaylor> thats nice too
[23:23] <codepal> good to find a fellow Opera lover!
[23:23] <jtaylor> though firebug is ok too
[23:25] <codepal> I've used Opera for a long time, firebug just feels cumbersome to use
[23:25] <jtaylor> I haven't used dragonfly it much recently, but in the early days firebug was superior
[23:25] <codepal> hear about the latest cutting edge dragonfly? - some nice javascript tooltips
[23:26] <jtaylor> looks much nicer now than I ahve it in memory
[23:26] <jtaylor> I think last I used dragonfly was ~2006 ;)
[23:26] <jtaylor> haven'T done much webdev since
[23:29] <codepal> ah ok - fav feature is the screenshot taker built-in & Color picker
[23:29] <codepal> bbl
[23:30] <astraljava> Wasn't aware of harvest. Seems like a cool tool, but it seems to find bugs that are closed already. I see it's marked beta, I suppose I should file a bug about that. :)


[13:12] <wonko> OvenWerks: there is one small bug I'd like to figure out yet but it's hard to debug because it depends on a dbus message. Technically I know what the issue is, but I just don't know the right way to handle it.
[13:12] <wonko> If JACK == False at startup last_master never gets set to anything
[13:12] <wonko> so we get this: https://paste.ubuntu.com/p/269jNZmgZD/
[13:14] <wonko> We bail out of config_start() pretty early if JACK == False
[13:15] <wonko> That may just be an issue with controls not setting it correctly though, I'll look into that real quick
[13:17] <wonko> I mean, a quick look doesn't show there being an issue there
[13:17] <wonko> well, no, I take that back
[13:18] <wonko> autojack starts before controls at session start, so that's not guaranteed
[13:18] <wonko> But on the other hand, it *is* set to True in my config file, so maybe it's a race condition?
[15:34] <OvenWerks> The place to set that, if it needs to be set, is in config_start.
[15:38] <wonko> yes, but if JACK is set to False it never gets set
[15:40] <wonko> Is there a legitimate case where JACK == Falsed and msg_cb_new needs to actually do something?
[15:40] <wonko> otherwise we should just have it also check JACK and not run the rest if False
[15:41] <wonko> oh, that might be old log messages, but it's still a thing either way.
[15:52] <wonko> Hmm, now I want to write a prometheus exporter for the studio bits. Hmmmmmmm.
[16:42] <OvenWerks> I don't think so, All of those things only make sense if jack is running
[16:44] <OvenWerks> Yes the callbacks for device detection, new and removed, should check that jack is actually running.
[16:45] <OvenWerks> That sounds like a thinko on my part. IT has gone un-noticed because I aways run jack and because anything those callbacks do will fail without doing anything too bad
[16:45] <OvenWerks>  (I think)
[16:52] <OvenWerks> Actually, this could be more robust if aside from checking if jack we check that the pid I store still exists
[17:00] <OvenWerks> wonko: are you making changes to autojack ? If not I could fix up some of these things otherwise I will wait. (fixing merges when two people are working on the same file is not fun)
[17:36] <Eickmeyer> Well done, everyone: http://ubuntustudio.org/2019/10/ubuntu-studio-19-10-released/
[18:01] <OvenWerks> Cool!
[18:42] <wonko> OvenWerks: I'm not doing anything right now. Just happened to look at the log file and remembered that was a thingv
[21:00] <OvenWerks> I will look at it then and fix...
[21:35] <wonko> groovy. I've been playing with Go, Grafana and Prometheus today. Having more fun than I probably should with this: https://imgur.com/fa909U1.png
[21:35] <wonko> :)


[12:03] <spiv> postgres statement logging is too late -- the query never reaches postgres.
[12:04] <spiv> The simplest way would be to insert a print just before the relevant line in zope.app.rdb, -- what's the fnal part of the traceback?
[12:07] <daf>     *  Module canonical.rosetta.sql, line 678, in createMessageSetFromText
[12:07] <daf>       return createMessageSetFromText(self, text)
[12:07] <daf>     * Module canonical.rosetta.sql, line 291, in createMessageSetFromText
[12:07] <daf>       if messageIDs.count() == 0:
[12:07] <daf>     * Module sqlobject.main, line 1211, in count
[12:07] <daf>       count = self.accumulate('COUNT(*)')
[12:07] <daf>     * Module sqlobject.main, line 1207, in accumulate
[12:07] <daf>       return conn.accumulateSelect(self,expression)
[12:07] <daf>     * Module sqlobject.dbconnection, line 249, in accumulateSelect
[12:07] <daf>       val = int(self.queryOne(q)[0] )
[12:07] <daf>     * Module sqlobject.dbconnection, line 223, in queryOne
[12:07] <daf>       return self._runWithConnection(self._queryOne, s)
[12:07] <daf>     * Module sqlos.adapter, line 60, in _runWithConnection
[12:07] <daf>       raise DatabaseException, tuple(exc.args)
[12:08] <daf> DatabaseException: unindexable object
[12:09] <spiv> Actually, turning on debug in SQLObject would be sufficient.
[12:10] <daf> could you remind me how I do that?
[12:10] <spiv> Except the current sqlos seems to override that :/
[12:10] <spiv> sqlobject/dbconnection.py is what I edit.
[12:11] <spiv> You may need to remove self.debug = 0 from sqlos/adapter.py, too.
[12:18] <daf> <sqlobject.main.SelectResults object at 0xb421f7cc>
[12:18] <daf>  1/Pool    :  ACQUIRE pool=[]
[12:18] <daf>  1/QueryOne:  SELECT COUNT(*) FROM POMsgID WHERE msgid = 'Opening %%d contact will open %%d new window as well.\r\nDo you really want to display this contact?'
[12:18] <daf>  1/Pool    :  RELEASE (implicit, autocommit=None) pool=[]
[12:18] <daf> but, also:
[12:18] <daf>  1/Pool    :  ACQUIRE pool=[]
[12:18] <daf>  1/QueryOne:  SELECT COUNT(*) FROM POMsgID WHERE msgid = 'Opening %d contact will open %d new window as well.\r\nDo you really want to display this contact?'
[12:18] <daf>  1/Pool    :  RELEASE (implicit, autocommit=None) pool=[]
[12:22] <spiv> Also?  Weird.
[12:22] <spiv> The second one fails I presume?
[12:22] <daf> I presume so too
[12:22] <spiv> :)
[12:26] <daf> ah, think I've found the second one
[12:35] <daf> spiv: ok, I think I've sorted out the SELECTs
[12:35] <daf> spiv: now an INSERT is being a pain
[12:36] <daf> spiv: shouldn't this stuff be automatically escaped in SQLObject?
[12:36] <spiv> Probably, yes.
[12:37] <daf> is it difficult to fix?
[12:37] <spiv> (Which has the added suck that fixing it in SQLObject will break our code thatwe're writing now that assumes the fix isn't there)
[12:37] <daf> i.e. should I do a workaround, or wait for it to be fixed properly?
[12:37] <daf> is it only a problem with percent signs?
[12:38] <daf> speaking of the Rosetta code, there's not much code which is affected
[12:40] <spiv> I'd workaround it.
[12:40] <daf> ok, I know how to hack SELECTS to work
[12:40] <spiv> (man, my wireless is screwing up for some reason)
[12:40] <daf> how do I do the same for INSERTs?
[12:44] <spiv> Yes, it's only % -- it's because Python's printf-like formatting is being invoked.
[12:44] <daf> right
[12:45] <daf> it is a bug, right?
[12:47] <spiv> (i.e. psycopg's cursor.execute does  query % params )
[12:48] <spiv> (sorry about the lag -- my wireless keeps dropping out for no apparent reason)
[12:48] <spiv> You'd fix it for INSERTs the same way -- escape % as %% in any strings.
[12:49] <daf> using which method?
[12:50] <spiv> foo.replace('%', '%%')
[12:50] <spiv> How are you donig it for SELECTS? :)
[12:50] <daf> Class.select()
[12:51] <daf> I've always used Class(...) for insertions previously
[12:53] <spiv> Um, I think we're talking at cross-purposes.
[12:54] <spiv> You can do Class(foo=foo.replace('%', '%%'))
[12:54] <daf> ok, that's what I wanted to know
[12:54] <daf> sorry, I'm tired
[12:54] <spiv> And you can do Class.selectBy(foo=foo.replace('%', '%%'))
[12:55] <daf> oh, right


[00:32] <laz0rrrgore> hi guys. i'm on 12.10 & gnome3-team ppa, and i'm using two different keyboard-layouts, but shell doesn't show an indicator. does anyone know why? i've read that the ppa would fix this issue ...
[04:36] <X-warrior> hey does anybody has a screenshot so I can see how ubuntu gnome looks like?
[04:36] <X-warrior> other question, was this version created because users wanted gnome instead of unity?
[04:39] <robert_ancell> X-warrior, any standard GNOME3 screenshot should look correct
[04:40] <robert_ancell> It was created because people wanted to use an unmodifed version of GNOME on Ubuntu, I'm sure they come from a range of backgrounds (Unity, other distros etc)
[04:41] <X-warrior> oh this gnome3 looks like unity
[14:46] <topyli> congrats for being offficial. you should probably be here: https://wiki.ubuntu.com/IRC/IrcTeam/Scope
[14:47] <topyli> otherwise i don't think the irc team has any problems with it. except maybe you'll need more ops in the future :)
[14:47] <topyli> also here: http://www.ubuntu.com/project/about-ubuntu/derivatives
[15:14] <Pici> woo
[16:03] <SonikkuAmerica> Now that we're an official flavor, will it be possible to upgrade to 13.04 directly from 12.10 Remix, or will it require a new ISO?
[16:15] <camelinahat> G'day jbicha
[16:23] <SonikkuAmerica> lol, like anyone comes here...
[16:24] <SonikkuAmerica> Which is weird... I guess Ubuntu GNOME still needs a catch-on somewhere.
[16:25] <camelinahat> SonikkuAmerica: Oh they do, but as you can imagine its a rather busy time for everyone getting infrastructure set up to start getting ready for Final beta release as well as daily images.
[16:26] <SonikkuAmerica> You don't say. I'm actually excited! I'm using the 12.10 "Remix" right now, and am glad that GNOME is getting itself flavor status in Ubuntu again
[16:26] <SonikkuAmerica> ESP. since Unity is ditching the GTK+ toolkit
[16:31] <camelinahat> I agree, on both fronts. Since Unity (and Gnome 3 really) I've been waiting for a 'Gubuntu' variant. I've seen other partial attempts and other distro's based off of Ubuntu but glad to see Ubuntu GNOME  as an official flavour. And glad to help out with it any way I can as well.
[16:55] <jbicha> I wonder if these work: http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/
[16:59] <camelinahat> !!
[17:02] <camelinahat> Booting from it now in my vm
[17:16] <camelinahat> jbicha: Nice. Seems to be working well so far
[17:36] <camelinahat> jbicha: Is there a bug list for filing bugs (for the installer for instance). Currently one of the screenshots shows Gnome Epiphany and another shows Gnumeric both of which I believe are no longer part of the standard installation?
[17:37] <jbicha> camelinahat: I believe you can file a bug against ubiquity-slideshow-ubuntu for that
[17:39] <camelinahat> jbicha: Thanks, I wasn't sure if there was (or will be) ones specific for Ubuntu Gnome to track. Thanks.
[17:59] <camelinahat> jbicha: Do you want me to announce daily-build availability on FB/G+ or wait until a message is sent out to the mailing list?
[18:00] <jbicha> I'd prefer a mailing list announcement first, did you want to write one?
[18:04] <camelinahat> No problem. And I'm not sure if I'm qualified for that haha. Any special notices or considerations or what-not to mention?
[18:07] <jbicha> well we're community ran and I don't want people to think this is a one-man show
[18:08] <jbicha> we're not doing powerpc or amd64+mac images unless we have people volunteer to test those for all of the milestones
[18:14] <camelinahat> I don't know that people think it's a one-man show, but at the moment you (and Perhaps Tim on the mailing list) are the most visible members of the community. I think much of that will start being clearer though once we have various wiki pages and an official homepage set up and such
[18:42] <camelinahat> jbicha: How's something like this look? http://paste.ubuntu.com/5611511/
[18:46] <camelinahat> Or should I drop 'first release of Ubuntu Gnome 13.04.. daily builds' and phrase it more 'the availability of ...'
[18:52] <jbicha> camelinahat: yeah I don't think "release" is the right word, here's a retweak of the 1st and 3rd paragraphs: http://paste.ubuntu.com/5611546/
[18:53] <jbicha> you can remove the extra "always" from the 5th paragraph
[19:00] <camelinahat> jbicha: Sounds good. http://paste.ubuntu.com/5611569/
[19:04] <jbicha> let's say "Ubuntu 13.04 Final Beta"
[19:04] <jbicha> it looks great, thank you!
[19:13] <topyli> epiphany of course isn't a part of the standard ubuntu installation, but i certainly think it should be part of the gnome flavor :)
[19:13] <topyli> it isn't in debian though
[19:32] <camelinahat> Well that's all for me today. G'nite folks. And grats on daily builds! =)
[21:12] <dupondje> hmz, empathy broken for others also in raring?
[21:12] <dupondje> with gnome-shell


[05:29] <cpaelzer> good morning
[05:34] <lotuspsychje> morning cpaelzer
[05:38] <cpaelzer> hi lotuspsychje
[08:24] <mirespace> good morning
[08:49] <lotuspsychje> hey mirespace
[09:08] <mirespace> hi lotuspsychje
[09:37] <rbasak> cpaelzer: when did you push the python-tempita team subscription change? I'm a bit puzzled why the script did the reverse of what you intended, unless you only pushed it this morning?
[09:40] <cpaelzer> rbasak: I pushed it this morning, then I saw the mail and realized I pushed to the wrong branch, then I fixed my mistake - I expect it will be removed next night
[09:40] <rbasak> Ah no problem. Nothing broken in the script then. Thanks! :)
[10:53] <athos> good morning!
[10:56] <athos> wow, lots of changes in gnome after my last full upgrade here
[11:55] <ahasenack> morning
[12:10] <ahasenack> kanashiro: when building rclone, do you recall it being an ftbfs in focal?
[12:11] <ahasenack> or you didn't touch focal
[12:11] <ahasenack> I even found a missing build-dep
[12:11] <ahasenack> but now tests fail
[12:20] <kanashiro> ahasenack, I was working on a custom build but I do remember the FTBFS in focal
[12:20] <ahasenack> k
[13:06] <ahasenack> kanashiro: does this ring any bells? https://launchpadlibrarian.net/593729634/focal-rclone-build.log
[13:06] <ahasenack> last line is a huge go install command line
[13:06] <ahasenack> but I don't see the actual error
[13:08] <ahasenack> hm, found something, many lines up:
[13:08] <ahasenack>  /usr/lib/go-1.13/pkg/tool/linux_amd64/link: signal: killed
[13:08] <ahasenack> it's like a murder mistery
[13:08] <ahasenack> mystery
[13:09] <ahasenack> "who killed link"
[13:09] <ahasenack> and why
[13:09] <ahasenack> ok, out of memory
[13:09]  * ahasenack gives the vm more ram
[14:52] <bryceh> good morning
[17:44] <lotuspsychje> bug #1966968 tested on both jammy -server & desktop


[08:59] <frankban> hi gmb: how are you doing?
[09:00] <gmb> frankban: I'm good, thanks. Did I miss anything yesterday that I need to be aware of?
[09:00] <frankban> gmb: not if you've red the handoff emails by gary
[09:01] <frankban> gmb: could you take a look at https://code.launchpad.net/~frankban/launchpad/bug-980295-soyuz-upload/+merge/102255
[09:01] <frankban> >
[09:01] <frankban> ?
[09:01] <gmb> Not yet; I'll look at them presently.
[09:01] <gmb> frankban: Sure; I'll look at that in a few minutes.
[09:02] <frankban> gmb: after that, what do you think about pairing on something? We are in the subunit/testr/buildbot land and you know how things are tricky there
[09:03] <gmb> frankban: Ok, sure. Let me get up to date on everything and I'll ping you when ready
[09:04] <frankban> gmb: thanks, great
[10:06] <gmb> frankban: I've approved your branch. What is it that we need to pick up next, then?
[10:08] <frankban> gmb: thanks. we can decide looking at gary's email. brad is working on subunit. maybe we can pick buildbot, or something else from the kanban board
[10:09] <gmb> Ok.
[10:09] <gmb> Looking...
[10:15] <gmb> frankban: "buildbot results show subunit streams filtered by workers" looks interesting, though I'm not sure we can do all that much with it until the bug 949950 work lands.
[10:15] <_mup_> Bug #949950: Feature request: an option to show full subunit stream of running tests <Testrepository:New for gary> < https://launchpad.net/bugs/949950 >
[10:17] <frankban> gmb: looking
[10:20] <frankban> gmb: it's described by gary as:
[10:20] <frankban> * buildbot's testr call in master.cfg should get the --subunit argument from the work on bug 949950
[10:20] <frankban>   * we add multiple stdout parsers in the buildbot output for the testr call.
[10:20] <frankban>     > One will simply be the stdout.
[10:20] <frankban>     > We will have one for each of the test processes piped through subunit-filter to give us the output per worker (e.g. subunit-filter --with="^tags: worker-0" -error --failure --success), and then piped through "subunit-ls --no-passthrough"
[10:20] <_mup_> Bug #949950: Feature request: an option to show full subunit stream of running tests <Testrepository:New for gary> < https://launchpad.net/bugs/949950 >
[10:20] <frankban>     > We will have one that will show us only the failures, perhaps in non-subunit format.  This one might also update the status of the waterfall for on the fly test counts.
[10:20] <frankban>   * for the buildbot piping to work, we *might* need to clean up the output of our testr command (i.e., removing lines 1-44 of http://paste.ubuntu.com/932523/).  it might be robust enough without it.
[10:20] <frankban> gmb: I don't know if we need the subunit output from testr to use subunit-filter
[10:21] <gmb> Hmm.
[10:21] <frankban> gmb: to test it we could take the output from the .testrepository/tmpxxxx file, maybe
[10:21] <gmb> frankban: Yes, that's what I was thinking as well.
[10:23] <frankban> gmb: I have started the charms, using constraints (hope they work)
[10:24] <gmb> frankban: Okay. I'm still waiting on being able to kill VMWare - it's eating my CPU but I'm in the middle of apt-get upgrade on the VM; I'll try and start a hangout but no promises.
[10:36] <frankban> aarghh... restarting the juju environment --constraints mem=10G --constraints cpu=8 gave me 4 cores...
[10:36] <gmb> !
[10:37] <gmb> I love Juju's ability to be completely and utterly maddening at almost every turn.
[10:37] <gmb> frankban: I'm in https://plus.google.com/hangouts/_/extras/canonical.com/hallo-tuesday#; no idea how good my audio will be though.
[10:39] <gmb> Aaaaah
[10:39] <gmb> Firefox crash.
[10:39] <gmb> Thankfully, I'm nearly done with the updates...
[10:40] <gmb> Restarting FF, anyway...
[10:42] <frankban> ok, constraints don't work...
[10:46] <gmb> frankban: Oh, fun. So am I right in thinking that there's now no way to start the kind of instances we need?
[10:46] <frankban> gmb: I am trying to check if the error is in the juju wrapper, using the real juju now
[10:47] <gmb> Ah, okay.
[10:47] <frankban> gmb: if that's not the case, I could use constraints in environment.yaml
[10:48] <gmb> frankban: Ah, right. For some reason I thought that wouldn't work - I guess I was confusing it with default-instance-type and suchlike, which are now non-functional.
[10:48] <frankban> or maybe... gmb do you know a way to specify the ec2 image type in contsraints?
[10:49] <gmb> Hang on, I think bac wrote some useable instructions...
[10:49] <gmb> frankban: http://pastebin.ubuntu.com/927016/
[10:50] <gmb> That worked for me last week, IIRC.
[10:50] <gmb> So I guess tweaking that for a c1.xlarge instance should work.
[10:50] <gmb> "should"
[10:51] <frankban> cool thanks gmb
[10:51] <gmb> frankban: If you're starting an lpbuildbot master/slave, it probably makes sense to set that running and then grab lunch. By which time, I should also have my CPU back.
[10:52] <frankban> gmb: ok
[10:52] <frankban> see you later
[10:52] <gmb> Okay.
[10:53] <gmb> frankban: I've added our faces to the card for this on the Kanban board.
[10:53] <frankban> thanks gmb
[10:58] <frankban> gmb: your ssh key is the carrot one?
[10:58] <gmb> frankban: Yes.
[11:03] <frankban> gmb: added your keys and started 2 screen sessions
[11:03] <frankban> master: ec2-204-236-222-6.compute-1.amazonaws.com
[11:03] <gmb> frankban: Thanks.
[11:03] <frankban> slave: ec2-184-73-121-132.compute-1.amazonaws.com
[11:03] <gmb> Okay. I'll grab food and check them out later.
[11:12] <bac> hello gents
[11:12] <bac> carrot keys?
[11:13] <benji> gmb and frankban: I'm readying email and looking at the board to figure out what I should work on.  Is the board up to date?  Do you have any suggestions?
[11:13] <bac> hi benji -- i think it is euro lunch
[11:14] <benji> bac: "euro lunch" sounds like a new fad, one I could get behind
[11:15] <bac> benji: yes.  euro* maybe not but *lunch definitley
[11:15] <benji> :)
[11:16] <bac> benji: did you see gary's emails re: the testr/subunit/testtools stuff?
[11:16] <benji> yep, I'm re-reading them now to try to figure out where I can be most helpful
[11:16] <bac> he and i are in the middle of trying to get the --subunit option to work
[11:17] <benji> yep
[11:18] <benji> bac: unless you want to pair, it looks like I should work on one of the prerequisites for 974622
[11:20] <bac> benji: maybe we can pair later?  pairing before 9am is probably a bad idea
[11:20] <benji> heh
[12:07] <gary_poster> I was going to restart after that upgrade, but running out of time
[12:08] <gary_poster> benji, how did the manuel py3 work go?
[12:08] <gary_poster> ooh, nvidia app got a nice new pretty icon
[12:08] <gary_poster> bac benji frankban gmb, call in 2
[12:08] <benji> gary_poster: really well, we had the tests passing around noon and had a release made by 3 (with some Thai in between)
[12:09] <gary_poster> benji, great! :-)
[12:09] <gary_poster> I suspected Thai might play a part in the day
[12:10] <bac> umm, thai
[12:10] <gary_poster> If my magic trackpad worked reliably, I would not have a single complaint about the more recent precise versions.
[12:31] <gary_poster> bac, https://talkgadget.google.com/hangouts/_/extras/canonical.com/goldenhordepart2thequickening ?
[12:31] <bac> gary_poster: ok
[12:47] <benji> gary_poster: what should I look at now?
[12:48] <gary_poster> benji, good question.  bac and I are talking in https://talkgadget.google.com/hangouts/_/extras/canonical.com/goldenhordepart2thequickening .  I need to prepare and deal with kids very very soon...
[12:49] <gary_poster> benji, could join us there for now
[12:49] <benji> gary_poster: is that an invitation
[12:49] <benji> oh, it is
[13:00] <bac> rejoining
[13:44] <gary_poster> bac: good to know: "gnome-open" is roughly equivalent to OSX "open"
[13:52] <bac> benji: here is what happens when i exit "script" while sharing a screen:  http://paste.ubuntu.com/933977/
[13:53] <bac> something got terminated [1] but not the ssh to chinstrap as you see it is still running
[13:54] <benji> bac: hmm, I don't understand that
[13:54] <bac> me neither
[14:01] <benji> bac: we want these in lp:~yellow, right?
[14:02] <bac> benji: yes, i think so
[14:10] <bac> gary_poster, benji: here is the final diff: http://pastebin.ubuntu.com/934005/
[14:10] <benji> bac: thanks; the testtools roll-up branch is ready at lp:~yellow/testtools/latest
[14:11] <bac> ok
[14:11] <bac> still working on MP
[14:11] <benji> k
[14:11] <gary_poster> nice bac
[14:19] <bac> benji: my branch is at lp:~bac/testrepository/bug-949950
[14:20] <benji> k
[14:20] <gary_poster> benji, bac, it looks like we have basic approval from Robert on https://code.launchpad.net/~yellow/testrepository/integrate_worker_tagging/+merge/102165
[14:20] <gary_poster> jml will adjust the wrap_results approach per his review
[14:20] <bac> great
[14:21] <gary_poster> and then we can write a test and try to get it officially merged
[14:21] <gary_poster> ISTR not being quite sure what we could test; looking...
[14:21] <gary_poster> heh
[14:22] <gary_poster> yeah, if we could test to see that "case" had the expected wrap_result, and that wrap_result did what we expected, that would be an acceptable unit test, but case is not exposed directly...
[14:23] <gary_poster> we could write wrap_result in such a way that it could be tested in isolation...
[14:24] <gary_poster> that might be sufficient, though IWBNI we could verify that it was being used in the proper integration
[14:25] <bac> benji: do you want to hangout to do the ppa recipes?
[14:26] <benji> bac: sure, if you want to get it going I'll be there in a minute when I get this other roll-up branch done
[14:26] <bac> benji: ok, the google won't let me into the hangout.  :(
[14:28] <gary_poster> frankban, could you let me know what version of lxc is installed in ec2?  0.7.5-3ubuntu51 is supposed to make the manual fstab change unnecessary, so I'm wondering if that has propagated yet
[14:28] <gary_poster> all the way to ec2
[14:28] <gary_poster> (which is sometimes behind the times)
[14:28] <gary_poster> no rush, but today would be good
[14:29] <benji> ok, lp:~yellow/testrepository/latest is ready now, too
[14:30] <frankban> gary_poster:  0.7.5-3ubuntu52
[14:30] <gary_poster> frankban, uh-oh
[14:30] <benji> bac: try it now (https://talkgadget.google.com/hangouts/_/extras/talk.google.com/goldenhorde#)
[14:30] <gary_poster> frankban, we should verify that the manual hack is still necessary then
[14:30] <benji> hmm, that's not the canonical one, but I guess it should work
[14:30] <gary_poster> if it is, we should report it
[14:30] <gary_poster> and maybe install our workaround in setuplxc
[14:31] <gary_poster> frankban, once you have the current test run, do you have the time to undo the manual change you made and rerun the tests?
[14:32] <frankban> gary_poster: one test run actually automatically started and finished without the hack: http://ec2-204-236-222-6.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/0/steps/shell_9/logs/stdio
[14:33] <gary_poster> frankban, ack, thanks.  Yeah, looks like the hack is still necessary.  I'll consult with hallyn
[14:34] <frankban> gary_poster: meanwhile I am going to start a test with the hack
[14:34] <gary_poster> cool thanks frankban
[14:34] <bac> benji: it was too much fun
[14:34] <bac> benji: want to try the normal hangout?
[14:35] <benji> bac: sure, do you want to make one or shall I? (I can't make a "canonical" one for some reason)
[14:35] <bac> benji: i'm in
[14:35] <bac> yeah, it is messing up today wrt to identities
[14:36] <benji> bac: what is the URL?
[14:36] <bac> you know, the normal one
[14:36] <bac> https://talkgadget.google.com/hangouts/_/extras/talk.google.com/goldenhorde#
[14:36] <benji> bac: "We're sorry, you are not invited to that hangout"
[14:36] <bac> gah
[14:42] <gary_poster> frankban, I spoke with hallyn and apparently this is expected
[14:42] <gary_poster> we should adjust setuplxc
[14:42] <gary_poster> to make this change
[14:43] <gary_poster> eventually there will be an official fix for lucid containers
[14:43] <gary_poster> but not right now
[14:43] <gary_poster> i'll make a card
[14:44] <frankban> gary_poster: add an option to setuplxc to add that line in var/lib/lxc/lptests/fstab?
[14:45] <gary_poster> frankban, yeah.  I guess an opton makes sense so we can easily undo it in the future, but for now it is required, so you could make the change without an option too
[14:46] <frankban> gary_poster: it could make sense to add the hack to lpsetup too
[14:46] <gary_poster> frankban, agreed
[14:49]  * gary_poster babysits/lunches quite early
[15:19] <frankban> parallel tests always find horrible ways to fail...
[15:27] <frankban> sometimes it's like working with quantum computers: http://dilbert.com/strips/comic/2012-04-17/
[16:08] <gary_poster> frankban, :-) .  Do you have new results yet?  I didn't see them on the ResultsLog page
[16:09] <frankban> gary_poster: I am looking at them right now, some new errors: http://ec2-204-236-222-6.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/1/steps/shell_9/logs/stdio
[16:17] <gary_poster> So a DisconnectionError, some weird hwdb thing, another DisconnectionError that looks like bug 974617 (we thought it was fixed), and our old friend UncleanReactorError
[16:17] <_mup_> Bug #974617: test_operational_view_integration fails intermittently in parallel tests <paralleltest> <qa-untestable> <Launchpad itself:Fix Released by bac> <Python PGBouncer:Triaged> < https://launchpad.net/bugs/974617 >
[16:19] <gary_poster> frankban, could you get the output of testr failing for the wiki's pastebin?  I think that is easier to read
[16:19] <gary_poster> frankban, I'll file bugs, unless you want to
[16:20] <frankban> thanks gary_poster, I will update the ResultsLog page
[16:20] <gary_poster> cool thanks frankban.  I'll put the bugs I file there
[16:30] <frankban> gary_poster: I hope the UncleanReactorError will be a dead old friend tomorrow: could you suggest me a place in launchpad where to put some testing generic tools, like the clean_up_reactor function?
[16:31] <gary_poster> frankban, ...lp.testing?  looking there
[16:32] <gary_poster> frankban, yeah, lib/lp/testing/__init__.py?  look in there and see what you think
[16:33] <frankban> gary_poster: yes I was looking there too, it seems a good place, thank you
[16:33] <gary_poster> cool, welcome
[16:38] <benji> darn: "Rejected: testrepository_0.0.5+z~ppa1~precise1.dsc: Version older than that in the archive. 0.0.5+z~ppa1~precise1 <= 0.0.5++trunk146~yellow2~precise1"
[16:39] <gary_poster> heh
[16:39] <gary_poster> opaque to me
[16:42] <benji> I think we need that to be "++z"... yep, that works
[17:30] <benji> bac: testtools and testrepository are happy now (https://launchpad.net/~yellow/+archive/ppa)
[17:33] <benji> well, now that all the testtools branches are merged we should switch to using the testtools trunk and fix our testr branch, I'll do both of those
[17:55] <bac> benji: could you change the ownership of the testr build recipe to be ~yellow?
[17:56] <bac> benji: also, in the past we had different build recipes for different branches (yellow branch, trunk, etc).  i think that is wrong and confusing.  we should have one recipe and just change the branch that is used.
[18:03] <bac> hey gary_poster did you see jml's comments on my MP? https://code.launchpad.net/~bac/testrepository/bug-949950/+merge/102317
[18:03] <gary_poster> bac, no, looking
[18:04] <benji> bac: (was afk) yep, I'll change ownership now; on the second part (different build recipes for different branches), I don't understand what action you're wanting me to take
[18:05] <benji> ownership changed
[18:05] <bac> benji: encouragement not to create a new recipe for testtools trunk
[18:06] <benji> bac: oh! right, I was going to edit the recipe we made to point it to the trunk, is that what you are wanting?
[18:06] <bac> benji: yes, as opposed to what stupid people do (me) -- create a new recipe
[18:08] <gary_poster> bac, comments: sounds ok.  (1) I thought we saw all tests when we ran the subunit make check with --subunit?  I'm mistaken? (2) changing make_result as he describes: :-/ sounds like fixing the tests will be time-consuming and annoying.  Hopefully I'm wrong.  "vars" comment: I wonder if he's asking for a change to getattr.  Not clear. :-/
[18:09] <benji> recipe updated, builds requested
[18:09] <bac> gary_poster: as to 1) i'm not sure.
[18:09] <bac> 2) yes, i think it'll break lots
[18:09] <gary_poster> :-/
[18:09] <bac> 3) using getattr looks more standard
[18:10] <gary_poster> true
[18:10] <bac> gary_poster: would you grab the branch and see if the output is what you remember?
[18:10] <gary_poster> sure bac.  gimme a sec, in the middle of something else, but can do in 5
[18:11] <bac> thanks
[18:14] <gary_poster> bac, no I remember lots of blather
[18:14] <gary_poster> maybe those were just the failing tests
[18:14] <gary_poster> but I thought it also included successes
[18:16] <gary_poster> bac, are you working on that?
[18:16] <bac> gary_poster: i don't think we changed anything significant related to that
[18:16] <gary_poster> I don't think so either bac
[18:16] <bac> gary_poster: yes
[18:16] <gary_poster> cool bac thank you
[18:16] <bac> gary_poster: but i wanted to see if we had a regression before i implemented jml's suggestions
[18:17] <gary_poster> I doubt it
[18:17] <gary_poster> I suspect my memory/care in looking atthe result yesterday more
[18:18] <benji> gah! since the recipes evaluated to having the same version the new builds failed, I think I can fix that without too much trouble
[18:18] <benji> (I should have changed ppa1 to ppa2.)
[18:19] <bac> benji: i sure wish the build machinery tested the versioning before doing all of the work...
[18:19] <benji> really
[19:57] <bac> gary_poster: i think we confused ourselves yesterday when we ran:
[19:57] <bac> python -m subunit.run testrepository.tests.test_suite
[19:57] <bac> that does show all of the results
[19:57] <bac> think that could've been it?
[19:58] <gary_poster> bac, oh, yeah, maybe so
[19:58] <bac> gary_poster: anyway, i've about finished the follow-up branch
[19:58] <bac> test fallout was not so bad
[19:59] <gary_poster> bac, awesome.  thank you
[20:03] <bac> gary_poster: better, no?  http://pastebin.ubuntu.com/934507/
[20:04] <gary_poster> bac, yes :-)
[20:06] <benji> I'm heading out to the dentist.  I'll see you guys tomorrow.
[20:06] <bac> here's the diff gary_poster: http://pastebin.ubuntu.com/934512/
[20:06] <bac> bye benji -- good luck
[20:06] <gary_poster> bye benji
[20:09] <gary_poster> bac, looks nice.  you need to add the options for the load command too, according to jml, right?  Did I miss that?
[20:21] <bac> gary_poster: oh yeah
[20:43] <bac> gary_poster: that was easy.  MP created.
[20:44] <gary_poster> bac, great
[20:44] <gary_poster> bac, fix for bug 974617 didn't work: my alaysis must have been failty :-(
[20:44] <_mup_> Bug #974617: test_operational_view_integration fails intermittently in parallel tests <paralleltest> <qa-untestable> <Launchpad itself:Triaged> <Python PGBouncer:Triaged> < https://launchpad.net/bugs/974617 >
[20:44] <gary_poster> faulty
[20:45] <gary_poster> analysis
[20:45] <bac> gary_poster: dang
[20:45] <gary_poster> my typing is faulty too
[20:45] <bac> so is it only failing in paralleltests?
[20:49] <bac> gary_poster: see you tomorrow.  have a good evening
[20:49] <gary_poster> bye bac
[20:49] <gary_poster> you too


[04:17] <elfy> evening peeps - just thought I'd pop by and say I love the work you all do under considerable pressure
[04:18] <elfy> luckily the troll presssure I get is ameliorated somewhat
[18:02] <BlindStevie> Hello, all!
[18:10] <k1l_> hi
[18:14] <BlindStevie> What's the topic of conversation, k1l_?
[18:16] <ninnnu_> Nothing
[18:16] <k1l_> right now here is no conversation. but this channel is for all the irc operators in the ubuntu channels. if you want to chat you can go to #ubuntu-offtopic and if you want support you can ask in #ubuntu
[18:18] <BlindStevie> Thanks for the information.


[07:55] <SiDi> hi
[13:55] <dns53> does this team manage mailing lists?
[14:13] <SiDi> dns53, all lists, do you mean ?
[14:25] <dns53> the loco list
[14:27] <SiDi> I suppose it's newz2000 who manages the whole lists.ubuntu.com but i dont think he controls what happens in the lists themselves.
[18:50] <mpt_> http://www.bing.com/search?q=ubuntu
[18:53] <SiDi> wow
[18:53] <SiDi> their engine isnt clever
[18:53] <SiDi> uses my geographical location to sort the answers
[18:53] <SiDi> instead of my locale
[18:54] <knome> i learned that ubuntu is the magazine of finland-south africa club
[19:01] <newz2000> wow, I like the mouse-over taht shows a summary of the contents of the target page
[19:01] <mpt> Bing is quite sure that I'm in Australia -- I don't know how it got that idea
[19:04] <knome> newz2000, i don't see that
[19:04] <newz2000> knome: when you mouse over the results a line and dot show up on the right... if you mouse over it you see a summary of the page
[19:05] <knome> no, i don't see a dot
[19:06] <knome> oh right, now i do
[19:06] <newz2000> :-)
[19:06] <newz2000> subtle
[19:07] <knome> the page looks totally different on epiphany and firefox
[19:07] <knome> on epiphany, i have way more content
[19:07] <knome> i wonder if it's because the locale is en only
[19:10] <SiDi> heya newz2000
[19:10] <newz2000> hey SiDi
[19:10] <SiDi> mpt, i got an IP that isnt linked to my country too when i'm in france :] Stupid people make stupid search engines :]
[19:11] <SiDi> newz2000, i wanted to ask you something about the wiki themes
[19:11] <SiDi> is it possible to have one for xubuntu ? :D
[19:11] <newz2000> SiDi: I'd rather not
[19:11] <newz2000> as a matter of fact there has been recent talk to remove kubuntu's theme
[19:11] <newz2000> don't think it will happen, but the prob is
[19:11] <mpt> knome, weird, I have the opposite issue -- it's far more interesting in Firefox
[19:12] <newz2000> that google shows some results illogically as being part of the kubuntu wiki and others as being part of ubuntu wiki
[19:12] <SiDi> newz2000, aw
[19:13] <SiDi> newz2000, the only point of that would be to change brown to blue though
[19:13] <SiDi> we use a custom menu for xubuntu pages, its blueish, and that's just not sexy :D
[19:13] <newz2000> well, there's also the need for a separate domain
[19:13] <newz2000> SiDi: if adding some styles to the ubuntu theme could make your pages more attractive I'd support that
[19:14] <newz2000> non-intrusive styles that only affect certain pages for example
[19:15] <SiDi> is it possible to change the aspect of the page with code inside our wiki pages ?
[19:15] <mpt> SiDi, https://lists.canonical.com/archives/ubuntu-website/2009-March/000620.html
[19:15] <SiDi> the best for us would be to have a page like https://wiki.ubuntu.com/Xubuntu/Toolbox/Menu that changes the rest too
[19:16] <newz2000> SiDi: can you add a class attribute to your menu? If so then we could add necessary styles to the main style sheet
[19:17] <SiDi> our "wiki" consists of the childs of wiki.ubuntu.com/Xubuntu btw :p
[19:18] <mpt> newz2000, would you do that server-side, or only for browsers that support the :has-child() selector? :-)
[19:18] <SiDi> knome, ping
[19:19] <newz2000> neither, I'm thinking of styling only specific elements of the page that have pre-defined classes on them
[19:19] <newz2000> like the menu
[19:21] <SiDi> newz2000, isnt there a way to specify a different CSS for a part of the wiki ?
[19:22] <newz2000> SiDi: I don't know for sure but if you want to propose a solution I'll consider it. We're using moin 1.6 series.
[19:30] <knome> SiDi, pong
[19:37] <SiDi> knome, newz2000 asked if we could add a class to our menu :P
[19:43] <SiDi> http://moinmo.in/FeatureRequests/ThemeCssPerPage
[19:45] <SiDi> is it normal i dont understand anything ?
[19:46] <newz2000> those are theoretical solutions as far as I can tell... I'm not too comfortable with it since some browsers (ahem) let you embed scripts in stylesheets
[19:48] <newz2000> I'm adamantly opposed to any feature that lets people use our wiki tool to hack into the computers who happen to visit our site with IE.
[19:48] <newz2000> ...wiki as a tool...
[19:48] <newz2000> :-D
[19:48] <SiDi> newz2000, heheh :D
[19:49] <SiDi> newz2000, think about how we'd protect our precious knowledge from the microsoft marketing department
[19:49] <newz2000> Though that would be a clever trick if we could automatically install Ubuntu on the computers of anyone using IE
[19:50] <SiDi> yeh
[19:50] <SiDi> with wubi
[19:50] <SiDi> hm... i shall write the first ubuntu-installing virus :]
[19:53] <SiDi> i must find their wiki
[19:53] <SiDi> their irc *
[19:53] <SiDi> this stuff is too confusing
[20:09] <SiDi> newz2000, http://paste.ubuntu.com/185944/
[20:09] <SiDi> Do you understand what he means ? :D
[20:16] <SiDi> http://paste.pocoo.org/show/120415/ <- he told me we could execute arbitrary code depending on what's in the "request" param
[20:25] <newz2000> SiDi: yes, I know what he means
[20:26] <SiDi> That's dirty, right ? :P
[20:26] <newz2000> well, it can be done elegantly, but it would require major revision to the theme
[20:26] <newz2000> think simpler, I'll bet you can come up with something that will work nicely
[20:31] <SiDi> i dont even know if we can put CSS inside the wiki pages :x
[20:31] <newz2000> you can definitely use style rules
[20:32] <newz2000> I thin css classes work also
[20:32] <newz2000> think
[20:32] <SiDi> Do you know the syntax for the style rules inside a wiki page ?
[20:33] <newz2000> I've seen it used on tables...
[20:34] <newz2000> SiDi: see the first few lines of this: https://wiki.ubuntu.com/Artwork?action=raw
[20:37] <SiDi> Per line isnt affordable unfortunately ^^
[20:38] <SiDi> What i actually want is that all the pages below Xubuntu/ automatically get a style applied, and the worse thing to do when creating a page would be copy pasting a block of wikitext or including it as we currently include our menu
[20:40] <newz2000> I'd suggest against trying to make a drastic change to the site this way, I'm referring to making your menu look good with the stock ubuntu theme
[20:41] <SiDi> well, at worse that's ok, we'll survive ^^
[20:41] <SiDi> its just about marketing :P


[01:22] <sontek> I'm trying to build my first package to put on a PPA and I followed some of the MOTU tutorials but I'm currently getting the error: "dh_install: libmemcached-dev missing files (usr/share/pkgconfig/*), aborting"
[01:22] <sontek> what did I miss?
[05:14] <tumbleweed> sontek: you listed files in debian/libmemcached-dev.install that don't exist
[05:14] <tumbleweed> in this case presumably the .pc file
[05:45] <Logan_> ABI transitions need to die. Like, right now.
[05:47] <tumbleweed> ABI transitions are better than segfaults
[05:48] <Logan_> Touché.
[05:51] <Logan_> I'm dealing with this mess right now: http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi1.6.html
[05:51] <Logan_> To make it even better, there are tons of conflicts(?) with other transitions.
[05:51] <Logan_> And packages that now decide to FTBFS.
[05:53] <Logan_> The transition tracker should let you leave notes on packages.
[06:23] <tumbleweed> MPI, fun
[06:23] <tumbleweed> you can leave notes on transition trackers, but not on the packages themselves. patches welcome, I guess


[08:46] <cnd> Hey Satoris
[08:46] <cnd> I just sent you an email, did you get it?
[08:46] <Satoris> Not yet.
[08:46] <cnd> Satoris, ok, I sent it to<EMAIL_ADDRESS>[08:47] <cnd> apparently canonical devs don't get @ubuntu.com addresses automatically anymore
[08:47] <Satoris> Wait, now I got it.
[08:47] <cnd> hmm, ok
[08:48] <Satoris> Restarting Evolution did the trick.
[08:48] <cnd> Satoris, are you an ubuntu member?
[08:49] <Satoris> Not that I know of.
[08:50] <cnd> interesting...
[08:51] <cnd> probably shouldn't spread knowledge of this too far :)
[08:54] <WebVisitor-0> Hi everybody, can anyone help in drivers of Samsung ld220z touch installation on unbutu linutop 4? tanks.
[08:55] <Satoris> cnd: have you looked at the spurious gesture bug I commented on Friday?
[08:56] <cnd> Satoris, not yet
[08:56] <cnd> Satoris, you can try reverting those commits to see if it fixes things
[08:56] <cnd> I probably won't be able to do much this week
[08:57] <cnd> WebVisitor-0, driver development usually occurs on the linux-input mailing list
[08:57] <cnd> and there's documentation in the linux source code in Documentation/input/multi-touch-protocol.txt
[10:55] <Satoris> cnd: the regular Oneiric package which does not have the fuzz patch (165) works perfectly.
[11:00] <cnd> Satoris, ahh, interesting
[11:00] <cnd> I didn't push it because it didn't have much testing
[11:01] <cnd> so that's good :)
[11:01] <cnd> Satoris, can you revert the commit noting the bug the it caused?
[11:07] <Satoris> Sure thing.
[11:45] <cnd> Satoris, remember to use bzr commit --fixes='lp:<bugnumber>' where it makes sense
[11:45] <cnd> including when committing a merge
[11:45] <Satoris> Does it actually do anything?
[11:46] <cnd> it adds some metadata to the commit, and it links things up better in launchpad
[11:46] <cnd> it's not a big deal and isn't worth withholding a commit from merging
[11:46] <cnd> but it's nice to have
[11:51] <Satoris> Disconnecting due to package upgrade ->
[11:56] <Satoris> Final confirmation that 165 was the issue: building the merged branch into a package and installing it makes things work.
[13:06] <cnd> Satoris, awesome
[13:06] <cnd> thanks for testing it out :)


[00:06] <xnox> infinity: hm..... curl is depwait
[00:07] <xnox> infinity: can you promote libgnutls28-dev to main?
[00:07] <infinity> ...
[00:07] <infinity> Wasn't that the one with the problematic license that we were avoiding linking to?
[00:07] <xnox> infinity: yes.
[00:07] <xnox> infinity: and curl switched to it.
[00:07] <infinity> And we should switch curl back, then.
[00:08] <xnox> infinity: talk to the newest member of foundations team then =)
[00:08] <xnox> infinity: mvo that is.
[00:08] <infinity> Unless the license issues have magically gone away.
[00:09] <xnox> he also trumped my curl upload =/
[00:09] <xnox> before it had a chance to migrate.
[00:10] <xnox> infinity: although libgmp license did change for the better.
[00:10] <xnox> infinity: so if we have new libgmp10 then actually the license issue might be resolved for lgply things.
[00:10] <xnox> 2 or 3.
[00:11] <infinity> We do not have a gmp10 with that license.
[00:11] <xnox>   * copyright: Updated to reflect new dual-licensing (LGPLv3+ or GPLv2+).
[00:11] <xnox>     Closes: #741607.
[00:11] <xnox> infinity: so shall i upload curl that trumps mvo util we get new gmp?
[00:11] <infinity> We need 2:6.0.0+dfsg-1 merged.
[00:11] <infinity> Well, or higher, obviously.
[00:11] <xnox> who maintains gmp? doko?
[00:12] <infinity> He's TIL, but only for small changes.
[00:12] <infinity> I'll merge it now.
[00:12] <xnox> oh, debian schience team and steve =)
[00:12] <xnox> infinity: well, i can just take ubuntu delta into debian.
[00:13] <xnox> and i thought i did, or it could have been some other package with identical diff.
[00:14] <infinity> Looks like the ELFv2 patch is upstream in 6.0
[00:14]  * infinity checks for the rest.
[00:18] <infinity> Okay, looks like we only need the libstc++ delta.
[00:18] <infinity> The rest is unnecessary now.
[00:18] <infinity> I'll just upload with that, if you want to do a Debian upload later, up to you.
[00:23] <infinity> Oh, hrm, might need symbols updates too.
[00:23]  * infinity tosses it at his PPA out of laziness to see the fallout on arm64/ppc64el.
[00:26] <xnox> well building on ppc64el porter box at the moment (debian upload) =)
[00:28]  * infinity uploads harder, with orig...
[00:31] <infinity> Man, those are some bizarre arch combinations in that symbols file...
[00:31] <infinity> Glad I'm test building instead of guessing.
[00:31] <infinity> Aaaand, it's FTBFS on ppc64el before it gets that far.
[00:31] <xnox> fat fallout?
[00:32] <infinity> /build/buildd/gmp-6.0.0+dfsg/build/.libs/libgmp.so: undefined reference to `BMOD_1_TO_MOD_1_THRESHOLD'
[00:32] <infinity> collect2: error: ld returned 1 exit status
[00:32] <xnox> yeap
[00:32] <infinity> Bets on that being optimized out with -O3?
[00:33] <xnox> i've added ppc64el in debian/rules to pass --disable-fat
[00:33] <xnox> that gets it going i believe.
[00:33] <xnox> nope, still fails.
[00:33] <xnox> dropping -O3 -> maybe
[00:33] <infinity> Oh, it's -O3 on all arches, though.
[00:34] <infinity> Guess I need to actually read some source.
[00:35] <infinity> Hrm.  Scary hacks for that in arm...
[00:35] <infinity> ifdef(`BMOD_1_TO_MOD_1_THRESHOLD',,
[00:35] <infinity>   `define(`BMOD_1_TO_MOD_1_THRESHOLD',0xffffffff)')
[00:35]  * infinity shudders.
[01:04] <xnox> infinity: https://gmplib.org/repo/gmp/rev/4a6d258b467f ?
[01:13] <infinity> xnox: Feh, I just fixed it differently.   :P
[01:16] <xnox> well debian updated whole bunch of symbols, no idea if they will work for ppc64el/arm64
[01:17] <infinity> xnox: They don't, that's why I did my test builds.  Fixing now.
[01:17] <xnox> cool.
[01:17] <cyphermox> infinity: xnox: anything I can help with re: helping gst-plugins-bad1.0 in particular and the huge chunk of text in update_output disappear?
[01:17] <xnox> cyphermox: guess what we are doing.... =)
[01:17] <cyphermox> I know ;)
[01:17] <cyphermox> that's why I'm proposing more hands
[01:19] <xnox> infinity: sign up cyphermox for +1 maint?
[01:19] <cyphermox> I have done +1 maint in the past
[01:20] <infinity> Consider him signed up.
[01:22] <cyphermox> I just need to know what to look at so as not to duplicate work
[01:25] <infinity> Anything that isn't gmp would have you not duplicating my evening. :P
[01:26] <cyphermox> k
[01:30]  * infinity hopes this one sticks.
[01:38] <infinity> xnox: There's a fair chance those ppc64el symbols changes will need to happen for ppc64 too, but I don't have a ppc64 chroot set up right now to check.
[01:38] <infinity> I guess I could debootstrap one quickly...
[01:39] <xnox> infinity: true. ppc64 build fails in debian with the same error that we are applying patch for.
[01:39] <infinity> Right, that patch will fix that, and then it'll probably fail on symbols.
[01:40] <xnox> and looks like there are symbols files changes for sh4 & alpha that i can pull from ports buildds.
[01:40] <infinity> Meh, I have nothing better to do in the next few minutes, let's see how badly broken debootstrapping ppc64 is.
[01:41] <xnox> infinity: here is my diff which does build on ppc64el http://paste.ubuntu.com/7370138/
[01:42] <xnox> should be pretty much the same what you got.
[01:42] <infinity> xnox: I already have a diff in Ubuntu.
[01:42] <infinity> (as in, I uploaded a long while ago)
[01:42] <xnox> i didn't see =)
[01:43] <infinity> xnox: My diff also, importantly, has one arm64 symbol fix too.
[01:43] <infinity> xnox: So, if you don't want to parse that by hand, you might want to just copy mine.
[01:44] <xnox> infinity: yeah, diffed what i have and what you did.
[01:44] <xnox> - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !powerpc !ppc64el !s390x !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[01:44] <xnox> + (arch=!arm64 !armel !armhf !arm64 !hppa !mips !mipsel !powerpc !ppc64el !s390x !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[01:44] <xnox> looks funny
[01:44] <xnox> i guess listing arm64 doesn't hurt. (also no idea which side is which)
[01:44] <infinity> Erm, I didn't do that. :P
[01:45] <xnox> yeah =))) me
[01:46]  * infinity watches his ppc64 debootstrap grind away...
[01:46] <xnox> Also this one:
[01:46] <xnox> - (arch=ppc64el)__gmpn_sublsh2_n@Base 2:5.1.1
[01:46] <xnox> + (arch=ppc64el)__gmpn_sublsh2_n@Base 0
[01:46] <xnox> did you go for 2:5.1.1 just for consistency?
[01:47] <infinity> xnox: Yours might be more correct there, in theory, I don't have a version older than 5.1.1 on ppc64el to check. :P
[01:47] <infinity> (And there isn't one)
[01:47] <xnox> yeah, that's what i thought. if it never was any prior version, might as well go with 0.
[01:47] <xnox> anyway, reverting to your edition.
[01:48] <infinity> DEBOOTSTRAP HARDER, ARGH.
[01:49] <infinity> xnox: Test build on ppc64 will probably take 30m or so.    I forgot to drop dh-autoreconf from my build-deps, despite dropping its usage in rules.
[01:54] <infinity> Oh well.
[01:56] <saiarcot895> Just out of curiosity, are the arm builders (at least the PPA ones) on actual ARM hardware, or are they using pre-compiled cross-compilers?
[01:57] <infinity> saiarcot895: The PPA builders use qemu-user-static.
[01:57] <infinity> saiarcot895: The distro builders are on real hardware.
[01:57] <infinity> saiarcot895: Neither uses cross-compilers.
[01:58] <saiarcot895> infinity: Might using the cross-compilers like g++-arm-linux-gnueabi be faster?
[01:58] <saiarcot895> and then compile on i386 or amd64?
[01:58] <NCommander> saiarcot895, introduces far too many problems
[01:59] <NCommander> cross-compilation fine for an embedded system or a small selection of packages, but cross-compilation adds massive amounts of complexity to the build process, and a lot of stuff just really goes and explodes
[01:59]  * NCommander once had to cross-build mysql and still has the scars from it
[02:00] <saiarcot895> NCommander: ah, I feared that
[02:00] <xnox> infinity: (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !powerpc !ppc64el !s390x !sh4 !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[02:00] <xnox> insn't that just arch=amd64-any ?
[02:01] <infinity> xnox: Might be.  I didn't read closely enough to match.
[02:02] <infinity> saiarcot895: Ubuntu and Debian are set up to be self-hosting systems, not cross systems.  So, yes, as NCommander hints at, we're in good shape to natively compile anything, in poor shape to cross many/most things.
[02:02] <infinity> saiarcot895: We've put a lot of work into making our base system cross-friendly, but after that, it falls apart quickly.  Crossing the PPAs would mean you could build about 200 packages. :P
[02:03] <NCommander> saiarcot895, when it comes to package compilation, its a massively distributable process :-)
[02:03] <infinity> xnox: Though, I assume you mean any-amd64
[02:04] <infinity> xnox: I don't see sparc on that list, but maybe it's missing from the whole symbols file due to sparc being relatively unbuildable while GCC is skewed...
[02:06] <infinity> Oo, but doko uploaded gcc-4.9 for sparc, that should clear up.
[02:06] <xnox> quite any-amd64
[02:06] <infinity> Could take two weeks for those poor buildds to catch up.
[02:07] <infinity> xnox: Okay, ppc64 finished, and it's more or less as I expected.  Want the dh_makeshlibs diff output, or just an updated-and-tested symbols file?
[02:08] <xnox> infinity: just the diff would be fine.
[02:08] <infinity> It's not quite as simple as "add ppc64 everywhere we have ppc64el".
[02:08] <xnox> infinity: i just walked alpha sh4 diffs.
[02:08] <infinity> http://paste.ubuntu.com/7370230/ <-- That's the diff against my Ubuntu upload.
[02:09] <infinity> xnox: Builds fine otherwise though, so yay.
[02:09] <infinity> xnox: No idea what the deal is with those .__ symbols...
[02:11] <infinity> Certainly looks a bit odd.
[02:11] <xnox> quite.... cuase they all exist without leading .
[02:12] <infinity> xnox: Those .__ ones are all there in 2:5.1.3+dfsg-1 too, so it's not a regression.
[02:12] <infinity> xnox: Just weird.
[02:13] <infinity> xnox: Old version for ref: http://paste.ubuntu.com/7370243/
[02:13] <infinity> (Not sure if they're *all* there, didn't compare, but the point is that there were a bunch of them and this isn't a new phenomenon)
[02:15] <infinity> xnox: Quite possibly an upstream bug or something, but also nothing that wasn't already there.
[02:15] <xnox> infinity: so i should add them for ppc64?!
[02:16] <infinity> xnox: Add them, or figure out a clever way to ignore them.  But yeah, they need to be there for dh_makeshlibs to not explode.
[02:18] <infinity> xnox: AFAICT, none of libgmp's rdeps link to the weird dot symbols.  They could probably be filtered out in a linker script.
[02:18] <infinity> xnox: But also, meh.
[06:52] <elfy> good morning release team - not sure if this is the right place to ask - but is there a reason why there's no xubuntu images on the utopic iso tracker?
[06:53] <cjwatson> They've been failing to build
[06:54] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/xubuntu/latest/livecd-i386.out
[06:54] <cjwatson> Haven't really investigated yet
[06:57] <elfy> cjwatson: ok - thanks
[06:58] <cjwatson> Looks like that should be fixed for the next build
[06:58] <cjwatson> https://launchpad.net/ubuntu/+source/hunspell-en-us/20070829-6ubuntu2
[06:58] <elfy> cjwatson: excellent - I can start haranguing my testers soon then :)
[06:59] <elfy> thanks for the info
[06:59] <cjwatson> np
[07:29] <infinity> Oh nice, gst-plugins-whatever migrated.
[07:30] <infinity> Still some AIEEE overflow madness, but should be getting near the end of it.
[07:30] <darkxst> infinity, any chance you can bump through g-i and gjs to trusty-proposed?
[07:31] <infinity> darkxst: If they're simple.  I'm only sort of awake.
[07:31]  * infinity looks
[07:31] <darkxst> g-i is simple, gjs should be a MRE
[07:33] <infinity> Bonus points for regenerating debian/control with a non-braindead pkg-gnome-thingee.
[07:36] <infinity> darkxst: MRE or not, a bug ref on the gjs upload would be nice, so there's some way to track that the binaries have been validated to be sane.
[07:37] <infinity> darkxst: (And that particular upload wouldn't really need an MRE anyway, if you wanted to validate all the upstream bugs it fixes, it's pretty straightforward)
[07:40] <darkxst> infinity, oh oops it should have been linked too bug 1283551
[07:40] <ubot2> Launchpad bug 1283551 in gjs (Ubuntu) "gjs-console crashed with signal 5" [Medium,Confirmed] https://launchpad.net/bugs/1283551
[07:40] <darkxst> but really there about 10 different bugs that will be fixed by the update
[07:40] <infinity> darkxst: Heh.  Oops.  Can you upload that yourself, or need a sponsor?
[07:40] <darkxst> I can re-upload
[07:41] <infinity> darkxst: Kay, cool.  Add a bug ref or two and I'll make sure it's identical other than the changelog, and we're good.
[07:42] <infinity> I like that upstream naively thinks sprinkling semicolons around is just "style changes" in javascript.
[07:43] <darkxst> javascript doesnt care so much about semi-colons!
[07:43] <infinity> JS being infamous for randomly changing flow based on if you do or don't semicolon post-brace, in circumstances that only language parsers and people who've never seen the sunlight understand.
[07:44] <infinity> darkxst: Trust me, that statement is patently false in many (most?) JS implementations. ;)
[07:45] <infinity> I got so fed up with random JS implementations doing different things with what seemed like simple C-style flow control that I have up and literally just put a semicolon on the end of EVERYTHING now.
[07:45] <infinity> Since that seems to be the only thing that's parsed consistently.
[07:45] <infinity> s/have up/gave up/
[07:48] <infinity> And since most people repurpose their JS parser for CSS (given the nearly identical syntax), I tend to do the same for CSS too.
[07:48] <infinity> This is my PTSD from a horrible past of web development.
[07:50] <darkxst> infinity, right I tend to avoid JS when I can these days, although I still have to deal with python's stupid handling of integers/floats everyday ;(
[07:51] <darkxst> ^infinity linked the top few bugs, but there are probably dozens more, need to go get dinner now though ;) ....
[07:52] <infinity> Oh, you didn't need a new version.
[07:52] <infinity> But meh.
[07:52] <darkxst> infinity, oh, ppa's do ;(
[07:53] <infinity> Yeah, the queue is a special place that exists outside the archive. :)
[07:53] <infinity> No big deal.
[07:54] <darkxst> infinity, right, you don't learn these things when going through sponsors ;)
[07:54] <infinity> Heh, you linked the same bug twice.
[07:55] <darkxst> cut+paste fail ;(
[07:55] <infinity> I'm going to officially not care.
[07:57] <darkxst> infinity, fixed now anyway
[08:07] <infinity> xnox: Repeated nag about boost1.55/gccxml
[09:37] <darkxst> infinity, still around? can you give gjs a rebuild in trusty-proposed (tests failed due to g-i update not being finished, and yes I probably should have added a depend on that....)
[09:38] <infinity> darkxst: You should be able to yourself, if you're the uploader.
[09:39] <darkxst> infinity, ah ok, yes!
[09:40] <infinity> Try not to abuse this newfound knowledge. ;)
[09:43] <darkxst> infinity, hah! why would I do that? according to Laney, I need to abuse my own server to get some warmth into this house ;)
[09:44] <infinity> He speaks wisdom.
[09:44] <infinity> This is why I'm trading all my ARM kit for old IA64 and PARISC stuff.
[09:45] <darkxst> my old P4 was a toaster! too bad I don't have it anymore ;(
[09:46] <darkxst> 95W TDP, shutdown a bunch of times from overheating, extactly what I could use now ;)
[09:50] <infinity> Huh.  I'm trying to decide if I think xbmc-bin-recommends-dummy.so is a really clever hack to avoid hardcoding recommended libraries in debian/control, or just vomitously horrid.
[09:50] <infinity> I guess it can be both.
[09:50] <cjwatson> Embrace the power of and.
[09:51] <infinity> I think I shall remember this awful hack the next time I feel the urge to depend/recommend on a library I don't actually link with.
[09:51] <infinity> It's certainly a cute trick.
[09:54] <cjwatson> Has it been clever enough not to actually ship the .so in question?
[09:55] <infinity> I didn't check the source, but I'd hope so.
[09:55] <infinity> dpkg-shlibdeps -pdlopenlibs -edebian/tmp/xbmc-bin-depends-dummy.so -xlibc6 -O >>debian/xbmc-bin.substvars
[09:55] <infinity> dpkg-shlibdeps -dRecommends -edebian/tmp/xbmc-bin-recommends-dummy.so -xlibc6 -O >>debian/xbmc-bin.substvars
[09:56] <infinity> So, yeah, it's not installed.
[09:56] <cjwatson> Good stuff
[09:57]  * cjwatson keeps going with the libmikmod/sdlgfx intertwined transitions
[09:57] <cjwatson> (tedious but not hard)
[09:57]  * infinity decides to give sleep another whirl.
[11:21] <xnox> cjwatson: libmikmod transition also needs libmikmod2-dev -> libmikmod-dev changes e.g. as in patch proposed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744906
[11:21] <ubot2> Debian bug 744906 in bb "bb: Please build-depend on libmikmod-dev instead of libmikmod2-dev" [Wishlist,Open]
[11:21] <cjwatson> xnox: I already did all that
[11:22] <cjwatson> xnox: Although it probably isn't a problem in Debian because NBS works differently there so the Provides has a better chance of taking effect
[11:22] <cjwatson> Or at least not as much of a problem
[11:23] <xnox> right, i've been mislead by launchpad "latest upload" on bb was not the one from proposed.
[11:24] <cjwatson> Yeah, it took me two goes there
[11:24] <cjwatson> Dunno why it's confused about the latest upload
[11:24] <cjwatson> Oh, because build1 didn't change anything meaningful and so propagated to release
[11:25] <cjwatson> Anyhow, it should all be done now once builds finish
[11:26] <cjwatson> i.e. taoframework and widelands
[12:10] <elfy> superm1: I hope I remember you being something to do with mythbuntu - if not sorry for the bump - but I've seen reports that the 14.04 download from your website is broken - confirmed it
[13:23] <psivaa> cjwatson: infinity: autorun.inf and wubi.exe dont appear in the list in utopic desktop images. iso static vaildation tests are flagging this up.
[13:25] <cjwatson> psivaa: thanks, should be fixed next build
[13:25] <cjwatson> ubuntu-archive@snakefruit:~/public_html/wubi$ cp -a trusty utopic
[13:25] <psivaa> cjwatson: ack, thanks
[13:25] <arges> xnox: hmm I used the scripts, wonder why I didn't add the tag properly. anyway sounds like you got it resolved. thanks
[13:57] <michagogo|cloud> I thought wubi was dead? :-/
[13:58] <stgraber> michagogo|cloud: it's still used to show the autorun UI on Windows
[13:58] <michagogo|cloud> What autorejoin UI is there?
[13:58] <michagogo|cloud> Autorun*
[13:59] <michagogo|cloud> (Autocorrect)
[13:59] <stgraber> something telling you it's an Ubuntu CD, that you should reboot to start it and maybe still offering to change your boot.ini to boot from CD (not sure about that last part, especially with newer Windows)
[14:04] <tgm4883> elfy: thanks for the ping. We noticed it broke yesterday after the server's hard drive filled up. Not sure why it's still not working though
[14:14] <elfy> tgm4883: ok and welcome :)
[14:25] <Daviey> tgm4883, elfy: Fixed. Thanks.
[14:26] <elfy> \o/
[14:52] <apw> pitti, did we have an ADT hickup, a random selection of the tests run for sysvinit seem to be qemu being killed hard
[17:00] <rtg> can somebody restart sysvinit autopackage testing ? qemu appears to have prematurely aborted on some tests.
[17:01] <xnox> rtg: do you have vpn access? you can restart the job yourself, i believe.
[17:02] <rtg> xnox, I only have Q/A lab VPN access AFAIK
[17:02] <xnox> rtg: ok, let me restart it.
[17:02] <rtg> xnox, thanks
[17:04] <xnox> rtg: do you mean sysvinit adt itself, or everything that it has triggered?
[17:04] <rtg> xnox, I'm not smart enough to know the difference.
[17:04] <rtg> you choose
[17:04] <xnox> rtg: which job /result you see aborted? url?
[17:05] <rtg> xnox, I'm looking at people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html in which I see a number of failures under sysvinit
[17:06] <xnox> rtg: right but e.g. mysql is a valid failure by the looks of things. i can retrigger them all.
[17:08] <rtg> xnox, I don't my patch could have cause a mysql failure, so there must be something new in Utopic causing this ? sysvinit was copied forward from trusty.
[17:09] <xnox> rtg: well some of these jobs have not yet ever passed on utopic....
[17:09] <rtg> I don't think*
[17:09] <xnox> rtg: retried all but linux, which is still in progress on i386
[21:16] <doko> demoted ruby1.9.1 \o/
[21:26] <xnox> doko: may day, may day, holliday!
[21:26] <xnox> =))))) *giggle*
[22:10] <xnox> gvfs is blocked on failed deja-dup and dbus-test-runner tests, that have never yet passed in utopic.
[22:11] <xnox> gvfs is a no-change rebuild for plist transition.
[22:11] <xnox> can it please be unblocked?
[22:25] <Laney> They both work in trusty fairly consistently so I think we at least need to figure out what's gone wrong
[22:28] <xnox> Laney: true.