[00:00] <cjwatson> ok, please try to make some progress on at least the information gathering part of that when you can, and update the spec with comments
[00:00] <cjwatson> we'll need to move on
[00:00] <cjwatson> bryce:
[00:00] <calc> ok
[00:00] <cjwatson> calc: thanks
[00:00] <bryce> Here's my blueprints --
[00:00] <bryce> xorg-input-hotplug:  DONE.  Finished up docs + testing.  Yay!
[00:00] <bryce> mouse-extra-buttons:  DONE.
[00:00] <bryce> xorg-options-editor: DEPLOYMENT.  Needs promotion to main.  http://bryceharrington.org/ubuntu/ScreenRes/screens-3.png
[00:00] <bryce> xorg-ctrl-alt-backspace:  POSTPONED to intrepid+1.  (Still disagreements)
[00:00] <bryce> x-testing-infrastructure:  Not FF critical, but some progress.  3 of 7 tasks done.
[00:00] <bryce> console-setup:  (Forgot what needs done?)
[00:00] <Riddell> I'm assuming this channel isn't going to be free for the Kubuntu meeting due in a minute
[00:00] <bryce> Other FF-critical non-blueprint development work --
[00:00] <bryce> Xorg apport hooks:  DONE.  Some testing remains.
[00:00] <bryce> Redo bulletproof-x to not depend on displayconfig-gtk:  IN PROGRESS. Fairly easy change, but I'll need a FFe for it.
[00:00] <cjwatson> Riddell: sorry, can you give us 10 minutes?
[00:00] <bryce> We're also awaiting releases of late drivers (-fglrx, -ati) and Xorg 1.5
[00:00] <bryce> tjaalton also would like a FFe for a -synaptics upload
[00:01] <tjaalton> howdy ho
[00:01] <tjaalton> synaptics should be ready in a minute
[00:01] <cjwatson> bryce: console-setup> I think not on your plate any more - it's just the translations work
[00:01] <bryce> cjwatson: ok thanks.  It's still assigned to me so I figured I ought to mention.
[00:02] <cjwatson> feel free to unassign that
[00:02] <bryce> I don't think I can, but I'll give it a try
[00:02] <Riddell> ** Kubuntu meeting moved to #kubuntu-devel **
[00:02] <cjwatson> Riddell: sorry, and thanks
[00:02] <bryce> cjwatson: nope, don't have permission
[00:03] <cjwatson> bryce: I've done it
[00:03] <bryce> thx
[00:03] <bryce> the -fglrx lateness is probably the biggest issue.  It probably won't make the release in October, so may need an SRU.
[00:04] <asac> bryce: no 3d for ati in release
[00:04] <asac> wow
[00:04] <bryce> for -ati we're shipping a pretty recent git snapshot, but I'd be more comfortable shipping a released version
[00:04] <cjwatson> bryce: please file MIR bugs for the main promotions for xorg-options-editor with some commentary so that we have something to work on
[00:04] <asac> thats a huge regression :) ... at least for those that are struck
[00:04] <bryce> cjwatson: ok will do
[00:05] <bryce> asac: yeah...  there will be much gnashing of teeth.  ATI is working on it as their top priority.  We'll see.
[00:05] <asac> bryce: i have a machine with X1950 ... and i cannot even watch videos without frame dropping
[00:06] <asac> on that
[00:06] <tjaalton> X.org 7.4 will be released "within a week", so there's still time for ati to get their act together..
[00:06] <asac> (with radeonhd)
[00:06] <tjaalton> asac: use -ati
[00:06] <cjwatson> bryce: thanks, perhaps you could come to the release team meeting on Friday and fill us in on more detail ther
[00:06] <cjwatson> e
[00:06] <cjwatson> ArneGoetje:
[00:06] <ArneGoetje> language-selector: uploaded into archive; one bug to fix: l-p-{gnome|kde) does not get pulled in anymore, needs code rewrite to fix, will do this during the next days.
[00:06] <bryce> cjwatson: ok
[00:06] <slangasek> I'm not sanguine about the notion of pushing in -fglrx as an SRU, with no working version at all in the release; but yes, we can talk about that later
[00:07] <cjwatson> ArneGoetje: any language pack structure changes in that, or just application code?
[00:07] <asac> tjaalton: ill try. last time it didnt work with anything else than radeonhd iirc
[00:07] <ArneGoetje> cjwatson: just application code
[00:07] <tjaalton> asac: pre-hardy?
[00:07] <asac> tjaalton: not sure. since fglrx was usually available i think it was in this cycle where i tried
[00:07] <tjaalton> asac: -ati in intrepid should support 3d for it
[00:07] <asac> good ... ill see
[00:07] <tjaalton> er, mesa
[00:09] <cjwatson> ArneGoetje: how have you been getting on with the CJK font work carried over from last cycle? I know you've still been doing bits to it on and off
[00:09] <ArneGoetje> cjwatson: not finished. language-selector took more time than expected
[00:10] <ArneGoetje> cjwatson: I still have some updates that need to get in before it could be released
[00:10] <bryce> asac: -ati has been improving rapidly since ATI released documentation.
[00:11] <cjwatson> ArneGoetje: ok, thanks
[00:11] <asac> bryce: that would be too good to be true ;)
[00:11] <cjwatson> asac:
[00:11] <asac> 3g-networking-intrepid (quite good, but as i said before it wouldn't make much sense to stop syncing new snapshots after FF); things to happen until this is finalized: mobile broadband wizard and its provider database to get into main; gsm/cdma probing code for devices that are only recognized as v.250 (upstream decision pending whether this should go to NM or hal); gathering final feedback (especially for the broadband provider database that wil
[00:11] <asac> flash-experience-intrepid (good progress): beta status for: better description (webservice needs deployment) and plugin alternatives (UI needs to be polished/finalized). good progress: anti-flash-detection-kit (some difficulties to get the event to the proper listener in the browser); at risk: adobe offers deb on their website (adobe will support ubuntu in Flash 10, but debs on their site are at risk); not a feature, but a bug: apturil in UI thre
[00:11] <asac> firefox-kde-integration-intrepid (deferred): no cycles to implement. real solution should go into upstream for 3.1 (QT support!! yay!).
[00:11] <asac> (no spec) safe-ffox-upgrade (done/needs real live testing): implementation appears to work well and awaits release with the next ubufox upload
[00:11] <asac> (no spec/maybe flash experience) nspluginwrapper for i386: finalizing QA on 1.1.0; upload didnt happen because we decided to go for the latest upstream development instead of 1.0. upload should happen any minute
[00:12] <asac> (no spec) branding-package-split: working with max attention; unless something really bad pops up this will happen during this week
[00:12] <asac> sorry for the "longer lines" ... but i thought i write things down as there would definitly be questions
[00:13] <cjwatson> you need to use splitlong.pl or something :)
[00:13] <slangasek> 3g-networking-intrepid: what's our end-point, as far as snapshot syncing?  Is there an upstream "final release" somewhere on the schedule?
[00:13] <cjwatson> "database that wil"
[00:13] <asac> slangasek: the end point is when upstream starts to do intrusive changes again
[00:13] <cjwatson> and "apturil in UI thre"
[00:13] <asac> slangasek: which will happen when they switch to modem manager for dialup connections
[00:13] <asac> i keep my eyes open that no too intrusive things reach us
[00:14] <asac> from there on i would cherry pick bugs
[00:14] <slangasek> asac: so we'll be releasing with "the last snapshot before things become disruptive"?
[00:14] <asac> yes. and then cherry picking on top
[00:14] <asac> i'd say that we stop after beta in any case
[00:15] <asac> cjwatson: ... gathering final feedback (especially for the broadband  provider database that will ship by the wizard) during beta phase.
[00:15] <asac> ... but a bug: apturil in UI thread
[00:16] <asac> cjwatson: that should complete this?
[00:16] <cjwatson> oh, that was it, ok
[00:16] <asac> yes
[00:17] <cjwatson> all right, thanks all; overall I'm pretty pleased with the amount we've got done, let's just try to get the last few bits and pieces in place for feature freeze and then try to get this heap o' junk into a releasable state ;-)
[00:17] <bryce> :-)
[00:18] <cjwatson> we've run late, so I'll not bother with stuff like the sponsorship queue today, although please try to keep up your attention to that when you find a spare hour
[00:18] <cjwatson> any other business?
[00:19] <TheMuso> no
[00:20] <slangasek> nope :)
[00:20]  * doko is heading for bife de chorizo
[00:20]  * asac is proud that he cleared his queue last week ;)
[00:21] <asac> doko: sounds tasty
[00:21] <asac> enjoy
[00:21] <cjwatson> doko: lucky you
[00:21] <cjwatson> ok, adjourned
[00:21] <bryce> thanks
[00:21] <liw> thanks
[00:21] <evand> thanks
[00:21] <doko> bye
[00:21] <ArneGoetje> thanks
[00:21] <slangasek> doko: heh, are you still in .ar?
[00:21] <ogra> thanks
[00:21] <slangasek> thanks, all
[00:22] <james_w> thanks all
[00:22] <TheMuso> thanks
[00:22]  * TheMuso gets breakfast.
[00:25] <doko> slangasek: yes, went skiing today =)
[00:26]  * slangasek looks longingly at the bife de chorizo, a continent away
[00:26] <doko> will send a photo ;p
[00:29] <slangasek> cruel
[13:00] <davidm> Good morning
[13:00]  * ogra waves
[13:00] <davidm> #startmeeting
[13:00]  * yannick_d waves
[13:01] <lool> davidm: MootBot isn't very alive these days
[13:01] <davidm> Hmm, mootbot seems to be dead
[13:01] <davidm> Oh well
[13:01] <davidm> I'll bug the scribes about it later.
[13:02] <ogra> (if they are not as dead as their bug)
[13:02] <davidm> OK first topic and I'll do stuff as if mootbot was online.
[13:02] <davidm> [topic] lool to purchase USB web camera
[13:02] <davidm> This is closed, I know lool bought one.
[13:02] <lool> Done: purchased the dumbest Logitech one which is supported under Ubuntu
[13:02] <davidm> [topic] lool+davidm+... test new version of Ekiga (2.9)
[13:03]  * ogra hasnt found one on ubuntu that isnt apart from the Q1 one
[13:03] <lool> (Might purchase another one with HD support, depending on whether the Q1U's webcam is supproted with 2.6.27)
[13:03] <ogra> it definately isnt with the latest 2.6.26
[13:03] <lool> We did some Ekiga testing last Monday, but we completely failed testing video; we only got audio working after great struggling
[13:03] <lool> And that was under i386
[13:03] <ogra> there is a driver from the manufaturer i wanted to try though
[13:03] <davidm> This was harder, we were not able to get this to work well between two PC's audio only.
[13:04] <ogra> but freeze came in my way
[13:04] <yannick_d> lool, can you explain what was the issue?
[13:04] <lool> ogra: 2.6.27 lands many uvc support changes
[13:04] <ogra> lool, i know
[13:04] <ogra> and madwifi as well
[13:04] <ogra> both doesnt work on the Q1 atm
[13:05] <davidm> yannick_d, we had two issues, one I think is not an issue now, one still is
[13:05] <lool> yannick_d: We had some; one thing is that we were behind a hotel's nat, and davidm was behind a second nat; despite this audio would work, so it seemed to work
[13:05] <yannick_d> ok there was a NAT issue. and?
[13:05] <lool> yannick_d: We also probably lacked a working sip account for video; we never managed one to one calls, only conf calls to a central place
[13:05] <davidm> yannick_d, I was double natted
[13:06] <davidm> yannick_d, do you know of a server lool and I can get accounts on that passes video?
[13:06] <persia> Does ekiga.net not do that?
[13:06] <ogra> doesnt the ekiga default server ?
[13:06] <lool> yannick_d: I also tried calling telephones with "tel:" and actual phone numbers with my home sip account at my ISP, and it didn't work
[13:06] <yannick_d> davidm, a conference server with video? no there is not such thing for free AFAIK
[13:07] <lool> yannick_d: I'm not sure how they are supposed to look like, but the SIP INVITES looked like INVITE<EMAIL_ADDRESS>[13:07] <yannick_d> lool, the tel: URI might be a problem...
[13:07] <lool> I thought it would simply be INVITE 1234
[13:07] <lool> yannick_d: What's the correct way to enter a PSTN?
[13:07] <yannick_d> lool, try<EMAIL_ADDRESS>instead
[13:08] <lool> Didn't manage to get this working either (this is what was going out when I simply typed a pstn with this sip account as the default)
[13:08] <lool> I tried with and without + and international or local format
[13:09] <yannick_d> lool, this works with freephonie.net, i have an account here too
[13:09] <lool> But then, some days it's broken; I didn't have my N810 with me to confirm it was working this day
[13:09] <lool> yannick_d: Could have been a downtime of the SIP thing
[13:09] <lool> It was refusing calls with some 4xx codes
[13:10] <lool> In the testing, we also discovered that davidm's webcam could be supported under hardy and isn't; this requires backporting a simple driver fix for ov56x-jpeg
[13:10] <davidm> yannick_d, is there a way to make video calls between lool and I?
[13:10] <lool> davidm: Now there is, because we're at two locations it should be easier
[13:10] <yannick_d> lool, for testingpurpose, please try using ekiga.net sip server and pc-2-pc calls first. Using a commercial PSTN bridge is another issue which brings stuff like number format issue in the way...
[13:11] <lool> yannick_d: We tried using ekiga.net accounts as well, but only saw the invites /sometimes/ and never managed an audio call in this wey
[13:11] <lool> I suspect our network setup was completely unusual and a bad way to test
[13:11] <yannick_d> davidm, to test video, you both might register an account on ekiga.net for free, and try to call each other.
[13:11] <davidm> yannick_d, OK we will try again before next week now that I am back in my usual location.
[13:12] <yannick_d> you could also test the avahi support, if you are both in the same LAN
[13:12] <lool> yannick_d: We spent too much time fighting webcam drivers and network and sip accounts on monday that we exhausted our testing time and we had other things to do for FF, but I'm happy to /continue/ testing in more regular conditions
[13:12] <lool> yannick_d: Ah, how is this enabled?
[13:12] <yannick_d> lool, it is automated
[13:12] <davidm> yannick_d, we got text support working using avahi but not audio and video
[13:12] <lool> yannick_d: How do you see the other people around?
[13:13] <yannick_d> lool, in the roster, under "network neighbours"
[13:13] <lool> yannick_d: I tried setting it up with empathy and telepathy on monday, but we could only send text messages; we didn't manage to call with salyt
[13:13] <lool> *salut
[13:13] <lool> (we also did some quick telepathy testing)
[13:13] <yannick_d> lool, sip support in EMpathy sucks now...
[13:13] <lool> Yeah, sofiasip's settings didn't match my expectations
[13:14] <yannick_d> the buddy list can not contains sip URI in EMpathy last time i tested it.
[13:14] <lool> yannick_d: So I think we should pursue testing and fix the webcam driver issue we discovered
[13:14] <yannick_d> I've been able to have a working audio+video call ekiga 2.9<-> Empathy
[13:14] <lool> yannick_d: If you're in France, we could do tests together too
[13:15] <davidm> lool, agreed, we will continue testing.
[13:15] <yannick_d> we aware, empathy use the h263-1998 video codec
[13:15] <lool> yannick_d: I expect to be quite busy today and tomorrow still, but next week is fine
[13:15] <davidm> [action] lool+davidm continue testing new version of Ekiga (2.9)
[13:15] <yannick_d> You can ask help on the ekiga mailling list too, like if you have problem with your nat etc. I'm there too
[13:16] <davidm> OK, that was all of the old business
[13:16] <lool> yannick_d: Frankly this was a one time bizarre setup because we had no other way to work this day
[13:16] <yannick_d> ok
[13:16] <davidm> [topic] FF status
[13:16] <lool> (I was routing davidm over my laptop's wired intf towards the hotel's wifi...)
[13:16] <yannick_d> i'm not sure i'll be able to join for the next week meeting: i must go to work and no internet there...
[13:16] <ogra> just stop working then :P
[13:17] <davidm> Is there anything we need to review now here?
[13:17] <lool> yannick_d: We can chat together anytime, not just during meetings
[13:17] <lool> yannick_d: If that's mroe convenient, we can test ekiga over the WE together
[13:17] <yannick_d> lool, where?
[13:17] <lool> yannick_d: In #ubuntu-mobile?
[13:18] <yannick_d> ok
[13:18] <davidm> lool, any FF issues we should/need to cover now?
[13:18] <lool> yannick_d: I'm<EMAIL_ADDRESS>and you can probably easily find an email for me
[13:18] <yannick_d> ok, thx i'll contact you
[13:18] <lool> davidm: Well I think we had plenty of packages to push before FF
[13:19] <lool> I know persia/stevenk/ogra were working on *-default-settings pacakges
[13:19] <lool> Are both of these pushed?
[13:19] <ogra> yep, pushed and done
[13:19] <lool> ogra was to look at pidgin-maemo versus empathy versus pidgin IIRC
[13:19] <ogra> i'D like to do some minir theme changes for mobile but artwork deadline in in a month
[13:19] <lool> This might have implied pushing pidgin-maemo if we wanted a chance to keep it in intrepid
[13:20] <lool> Anyone pushed pidgin-maemo?
[13:20] <persia> Big FF things are 1) we don't have an IM client, and 2) we need to look at media players (unless I missed something)
[13:20] <ogra> i didnt manage all of them yet but apart from some security issues with empathy in IRC i found it quite good as replacement
[13:20] <ogra> i'll finish that off today/tomorrow
[13:21] <lool> ogra: Ok, then perhaps send your analysis to the list?
[13:21] <davidm> ogra, does empathy support the various IM protocols?
[13:21] <ogra> if i need freeze exceptions i'll deal with them myself
[13:21] <persia> pidgin-maemo and moblin-media-browser-plugin are still on REVU, which makes me think they didn't get pushed.
[13:21] <ogra> davidm, the same set pidgin does
[13:21] <lool> davidm: It does even wrap libpurple
[13:21] <davidm> OK, thanks
[13:21] <lool> (which is pidgin's lib)
[13:21] <lool> But empathy was pushed back for intrepid in the desktop team due to usability issues
[13:22] <StevenK> I'd like to not use moblin-media if I can.
[13:22] <lool> I think you're not alone
[13:22] <ogra> lool, we can build from universe if we want it
[13:22] <lool> I'll push elisa updates
[13:22] <ogra> so thats a non issue
[13:23] <lool> I'm late for pushing elisa (new upstream releases and it's in main) but had too many last minute things fall on my plate before FF to manage yesterday
[13:23] <ogra> and i didnt find it worse than pidgin with fullscreen windows
[13:23] <ogra> where is the UNR stuff at ?
[13:23] <lool> Yeah, exactly what I was typing :)
[13:23] <ogra> :)
[13:23] <lool> StevenK: I think you were pushing UNR packages
[13:24] <davidm> StevenK, you here?
[13:24] <lool> StevenK: how many/which packages did you look at, and what's the status?
[13:24] <lool> StevenK: I think njpatel rolled a new netbook-remix-launcher tarball to address some concerns I raised and matching the package name
[13:25] <lool> Hmm we had StevenK a minute ago
[13:25] <davidm> I have an email from StevenK with FF status: * UNR packages  This is four packages, with all but one of them in okay shape. I suspect this can be massaged into one FFe, too.
[13:26] <davidm> So they missed FF
[13:26] <lool> It's late on his side thouhg
[13:26] <davidm> I wonder where StevenK is, he was around a few minutes ago.
[13:27] <ogra> davidm, its all universe so a bit easier to deal with exception wise
[13:27] <Hobbsee> ogra: as in, no one will notice, if the freeze gets violated?  :)
[13:27] <lool> davidm: The only thing which worries me is making StevenK push UNR packages versus working on the images, but he sent out a link to an image today
[13:27] <StevenK> I'm here, my wife called me away
[13:28] <lool> StevenK: Cool, so what is the problematic package?  what needs to be done on the others to get them in intrepid?
[13:28] <ogra> (actually i assume we culd make a deal with MOTU, review one package for MOTU, get one exception granted or some wuch ... so all of use benefit ;) )
[13:28] <persia> Hobbsee: No, as in it won't break CD builds and so it is likely to be approved with a convincing reason, rather than a convincing reason + several months of testing.
[13:28] <ogra> Hobbsee, ^^^
[13:28] <StevenK> lool: The launcher
[13:28] <Hobbsee> ogra: now there's an idea... :)
[13:28] <persia> ogra: It *really* doesn't work that way :p
[13:28] <StevenK> lool: The other 3 look okay
[13:28] <ogra> persia, but it *could* ;=
[13:28] <Hobbsee> persia: no, but it might be a good idea...
[13:28] <Hobbsee> persia: that's true
[13:29] <ogra> it raises MOTU manpower and helps us as well
[13:29] <persia> Right.  And this is why corruption and graft always win :(
[13:29] <ogra> heh
[13:29] <lool> StevenK: Ok; I have a fairly good idea of status of launcher; concerning the others did you push them to REVU/got them reviewed already?
[13:29] <StevenK> lool: No, I will be doing that tomorrow.
[13:30] <lool> ogra: IOW bribery
[13:30] <StevenK> I suspect they need repackaging and then uploading
[13:30] <lool> bribery with free reviews :)
[13:30] <ogra> well, bribery the community benefits from
[13:30] <ogra> its a win win deal
[13:31] <ogra> we could level it out like 10:1 ... or so
[13:31] <davidm> OK we are 1/2 through our meeting time.
[13:31] <davidm> lool, anything left on the FF topic that we need to cover?
[13:32] <lool> davidm: Please give priority to image building for alpha 5 before UNR packaging if that's suitable
[13:32] <davidm> if not we should move on the other status issues.
[13:32] <davidm> lool, agreed
[13:32] <lool> StevenK: Unless you think both are almost done :)
[13:32] <lool> I don't think we have anything more to discuss on FF; of course we might discover plenty of stuff with the images
[13:32] <davidm> [topic] status of intrepid tasks: merge of ppa, installer, images etc.  * StevenK status
[13:33] <lool> Did I mention I pushed modest?
[13:33] <davidm> lool, you did not
[13:33] <lool> I pushed modest to Ubuntu and my ppa
[13:33] <davidm> good, I'm happy to hear that
[13:33] <lool> A couple of hours after FF,
[13:33]  * persia suspects the PPA to have been redundant
[13:33] <davidm> StevenK, how goes image building?
[13:33] <lool> It's relatively broken due to missing icons and strings, but that I can probably fix
[13:33] <StevenK> davidm: The image is up.
[13:33] <StevenK> But it's broken.
[13:34] <lool> persia: I think not, I don't see modest in the repos yet and I mailed cgregan for him to take a look
[13:34] <persia> StevenK: Broken beyond that the default session doesn't start?
[13:35] <StevenK> persia: Nope, that was it
[13:35] <lool> davidm: Re: FF, I'd like to note that we're only at 2.6.26 for lpia because it's a separate source
[13:35] <lool> Need to talk to chickencutclass
[13:35] <ogra> *if* .27 will be used
[13:35] <StevenK> I mentioned that earlier.
[13:35] <persia> The -rt kernel is also stuck at 2.6.26, so we're not alone in kernel version history.
[13:35] <lool> ogra: In lpia or in general?
[13:35] <davidm> StevenK, what remains to be done on image building?  Anything?
[13:35] <ogra> currently the status is that there will be a call for testing as i understood
[13:36] <davidm> We will have to stick on 2.6.26 for lpia
[13:36] <ogra> but there is still an opportunity that it might be rolled back
[13:36] <ogra> davidm, and differ from ubuntu ?
[13:36] <lool> davidm: Why is that?
[13:36] <davidm> We need the poulbo graphics driver and that is coming from an outside source
[13:36] <ogra> hmm
[13:36] <ogra> thats tricky
[13:36] <davidm>  I doubt at this late time I can get them to move
[13:37] <ogra> if work on .26 stops we'll miss out a lot
[13:37] <persia> Hrm.  Someone ought mention that to the thread on ubuntu-devel@ as part of arguments against movig to 2.6.27
[13:37] <davidm> I am having trouble getting the driver at all
[13:37] <ogra> (wifi on the Q1 doesnt work with .26 for example)
[13:37] <lool> davidm: Well we don't have it anyway
[13:37] <davidm> But we have a call later today to get info on this so it will have to wait until then.
[13:38] <lool> ogra: Yeah, wanted to test ath5k as well
[13:38] <ogra> .27 is supposed to have the necessary fixes for that wifi issue
[13:38] <ogra> lool, no need to, i had to resort to madwifi for it
[13:38] <ogra> it wont pick up IP/AP
[13:38] <lool> I wouldn't want us to have a different kernel version for lpia
[13:38] <StevenK> They have moved to .27
[13:38] <StevenK> I wouldn't either
[13:38] <lool> That seems really risky
[13:38] <ogra> .27 has massive fixes for ath5k
[13:39] <ogra> which wont be backported if ubuntu really switches
[13:39] <davidm> With the atom chip and it's graphics if we move and Intel does not supply a driver then we have no driver at all.
[13:39] <lool> I don't want to even think about a subsequent udev/hal update
[13:39] <ogra> so we'll lose here
[13:39] <lool> davidm: I guess we have vesa
[13:39] <ogra> heh
[13:40] <lool> I'm not sure it's that different from psb for our purposes...
[13:40] <davidm> True, that is about it, and that will not work for USG, they need the driver to work.
[13:40] <lool> Might even suspend better *cough*
[13:40] <ogra> but UNR needs clutter
[13:40] <ogra> and thus GL support
[13:40] <lool> Is USG going to base on intrepid?
[13:40] <lool> They maintain their own kernel anyway
[13:41] <davidm> lool, some work is.  They have to provide upgrades
[13:41] <davidm> Well technically I suppose we can have 2.6.27 and they can have 2.6.26 but that is a mess
[13:41] <lool> I agree we should make the poulsbo concern known in the 2.6.27 discussion, but it wont have any weight if we don't even ahve 2.6.26 drivers
[13:42] <davidm> That is a call later.
[13:42] <lool> It's no more a mess than us having .26 and Ubuntu having .27
[13:42] <ogra> davidm, "we" ?
[13:42] <ogra> ubuntu ?
[13:42] <ogra> or just mobile ?
[13:42] <davidm> mobile / USG
[13:42] <lool> Let's clarify tonight
[13:42] <davidm> yes
[13:42] <lool> I'll try to think of updating ubuntu-devel@ on this topic with psb debate
[13:43] <davidm> persia status of installer
[13:43] <persia> You know, it'd be best to also participate in the wider discussion.  Having two different kernels for two different architectures is bound to cause issues.
[13:43] <persia> The installer still doesn't install.  On the bright side, I know lots more about how the installer is supposed to work.
[13:43] <persia> I think I'm nearly there, but am currently chasing networking issues with the latest image.
[13:44] <davidm> OK
[13:44] <davidm> lool status of MIC merges?
[13:45] <lool> *done*!
[13:45] <davidm> :-)
[13:45] <lool> Would like to see a tarball release from them
[13:45] <lool> I've sent further comments on design of MIC and would be willing to provide a patch to move to / add intrepid platforms
[13:46] <davidm> So we need to get a tarball release from them and then can put fresh packages into Intrepid?
[13:46] <lool> But it's not really clear who leads what and whether this thing will evolve
[13:46] <lool> Well we don't strictly need it; we have about the same features as they do
[13:46] <ogra> would be cleanr though
[13:46] <lool> We developped more changes than they did
[13:46] <ogra> but require a FFe
[13:46] <lool> Yeah, it would be cleanup
[13:46] <lool> And it's not strictly needed
[13:47] <lool> What we would get are a cleaner base to patch on and some features like i18n
[13:47] <lool> But this is all minor or wishlist material
[13:47] <davidm> OK
[13:47] <lool> It's not like we're using MIC anyway
[13:47] <davidm> Very true.
[13:47] <persia> It's probably not worth an FFe, but would be nice for intrepid+1
[13:47] <lool> Sure, I'm the defacto MIC maintainer these days
[13:47] <davidm> ogra status?
[13:47] <lool> I'll update it if they release
[13:48] <davidm> lool, thanks
[13:48] <ogra> classmate: still fiddling with the gstreamer issue ETA tomorrow for hardy-proposed and SRU
[13:48] <ogra> touchpads: bug #261873 opened, discussed with bryce ... he agreed that it should eb fixed for release
[13:49] <davidm> ogra, how much left before classmate is put to bed do you think?
[13:49] <ogra> mobile: settings uploaded, creates a desktop like http://people.ubuntu.com/~ogra/ubuntu-mobile-intrepid.png, waiting for installer (depends on ubuntu user without password for autologin atm
[13:49] <ogra> )
[13:50] <ogra> davidm, i will always have to touch it from time to time until 8.04.2
[13:50] <ogra> for kernel security updates
[13:50] <davidm> OK
[13:50] <ogra> but thats all scripted on my side
[13:51] <ogra> so only some mins of work plus build time, testing and triggering elmo
[13:51] <davidm> ogra, is the process you use to generate images documented anywhere?  I know that cjwatson had a hard time making a working image in your absence
[13:51] <ogra> its only: execute ./cron.daily in the build tree
[13:51] <ogra> that will autobuild
[13:52] <ogra> i have done my last image in my own env but will take a look at antimony (which has a 1:1 copy of my system)
[13:52] <davidm> OK 8 minute warning
[13:52] <davidm> ogra thanks
[13:52] <davidm> last topic
[13:52] <ogra> i'd like to put a proposal out :)
[13:53] <davidm> ???
[13:53] <ogra> we should start collecting spec ideas for intrepid+1 asap on a wikipage
[13:53] <davidm> +1
[13:53] <cjwatson> it wasn't so hard, for the record; just startup problems
[13:53] <ogra> so we can follow the regular distro/spec process this time, now that the packages are sanely in the archive
[13:53] <davidm> I agree strongly
[13:53] <ogra> great
[13:54] <davidm> cjwatson, thanks for that, I just want to make sure we have it documented so it's not hard if it ever needs be done again. :-)
[13:54] <ogra> (i.e. al the requests for 1024x756 got me thining about inclusion of a sane patch for gtk for example... that needs preparation for a spec)
[13:54] <davidm> [topic] Switch claws with modest/libwpeditor libwpeditor-plus?
[13:55] <davidm> I think you all just about put this to bed last week?
[13:55] <lool> Hmm I pushed modest and libwpeditor+ to my ppa, but cgregan hadn't a change of testing them
[13:55] <lool> Also modest suffers from many issues such as missing strings and icons which render it quite ugly
[13:56] <davidm> but we have the possbility of choice if we need it?
[13:56] <lool> I think we need to defer discussion until a) I can address some of the issues b) other people can test it c) we test the images
[13:56] <davidm> 4 minute warning
[13:56] <davidm> lool, OK
[13:56] <lool> davidm: Yes exactly, the hurry was to get the packages pushed, they are now
[13:56] <davidm> thanks
[13:57] <davidm> I'll carry an acttion to review in future but not next week.
[13:57] <lool> Which reminds me of two other FF related issues which I usually report on: langpacks and xulrunner; we're still missing translations in intrepid AIUI and xulrunner I didn't merge
[13:57] <lool> I really need to tend to it now rather tahn later
[13:57] <davidm> [action] review modest and libwpeditor+ after lool has time to address some of its issues.
[13:57]  * ogra creates https://wiki.ubuntu.com/MobileAndEmbedded/IntrepidPlusOneSpecSuggestions
[13:57] <davidm> OK
[13:57] <lool> I poked cgregan to have an early look and work with me on solving the issues
[13:57] <davidm> ogra, thanks
[13:58] <davidm> lool, good enough
[13:58] <lool> ogra: Oh nobody told you the codename for intrepid+1?
[13:58] <davidm> lool, has it been announced?
[13:58] <lool> No :)
[13:58] <ogra> heh
[13:58] <lool> Which makes it even more fun to guess
[13:58] <davidm> :-)
[13:58] <davidm> OK almost out of time.
[13:59] <davidm> any last opens?
[13:59] <davidm> 1 minute warning
[13:59] <Hobbsee> the sky is falling!
[13:59] <lool> The jitty jamthund!
[14:00] <davidm> #endmeeting
[14:00] <davidm> Thanks everyone.
[14:00]  * persia doubts "jamthud"
[14:00]  * Hobbsee covers lool in jam.
[14:01] <lool> the jolly jumper!
[14:01] <lool> The jumpy jellyfish
[14:01]  * Hobbsee hums
[14:01] <lool> Or the jelly fish :)
[14:01] <Hobbsee> jolly jumbuck, i thought it was...
[14:02] <StevenK> Hah
[15:00] <persia> Who's here for the Java Meeting?
[15:00] <robilad> here
[15:00] <Koon> o/
[15:01] <Koon> the usual suspects :)
[15:01] <persia> :)
[15:01]  * persia hopes slytherin and doko might join
[15:01] <Koon> I /think/ doko is still in vacation.
[15:02] <persia> Could be.  He was at a meeting earlier.
[15:02] <persia> Anyway: Agenda is at https://wiki.ubuntu.com/JavaTeam/Meeting
[15:02] <cjwatson> see the foundations team meeting notes last night for some items relevant to Java
[15:02] <Koon> I see. /This/ kind of vacation.
[15:02] <persia> Nobody added anything, so nothing special to discuss.  We've just the RoadMap
[15:03]  * persia checks the Foundations Team meeting log
[15:03] <robilad> url?
[15:04] <persia> Seems that doko is looking at some of the continued changes to use default-jre(-headless), and may also be looking at making it more headless.
[15:04] <persia> http://irclogs.ubuntu.com/2008/08/27/%23ubuntu-meeting.html
[15:05] <persia> We may hear more next week.  On for other updates:
[15:05] <persia> robilad: Where are you on identifying tasks that need doing?
[15:05] <robilad> working my way through the maven pom system and trying to figure out a good way to automate that with aptitude
[15:06] <persia> Is there anything else non-maven that needs doing that would benefit from someone looking into it?
[15:06] <robilad> basically, when you use maven to build software it downloads many jars
[15:06] <robilad> and those come with a kind of descriptions, 'pom' files
[15:07] <robilad> which contain artifact ids
[15:07] <robilad> which could in theory be fed into aptitude etc. more or less automatically.
[15:07] <robilad> except that there are many little catches. ;)
[15:07] <robilad> but getting there.
[15:08] <persia> So a tool that can read .pom files and pass arguments to apt to tell it what to install?
[15:08] <robilad> well, to tell me what seems to have a package of sorts, and what hasn't
[15:08] <robilad> that's the one way to figure out what to do
[15:08] <Koon> robilad: feel free to add any of your thoughts to https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec
[15:09] <robilad> the other one is to just install all jars in ubuntu, generate a list of packages mapping to each one of them, and then to see which jars in a build match
[15:09] <persia> Yeah, that feels definitely part of the maven stuff, but it's good :)
[15:09] <robilad> neither way is really perfect :/
[15:09] <robilad> and I'm doing the former as it should in theory just require a bit of shell scripting
[15:09] <robilad> ;)
[15:11] <Koon> we're still at the brainstorming stage for this maven support thing. Might be useful to schedule a session at next UDS on the subject (though I won't be coming there)
[15:11] <Koon> and make sure the (other) relevant persons can join.
[15:12] <persia> Koon: You'll be able to attend remotely, no?
[15:12] <Koon> persia: I'll definitely try to attend remotely to select sessions
[15:12] <Koon> but on the maven thing I'm more a catalyst than a specialist
[15:12] <persia> Koon: Excellent.  Just complain over VoIP if we're not loud enough.
[15:13] <Koon> and we are getting to a stage where specialists will be handy
[15:13] <persia> Right.  Let's jump ahead since we're on the topic: Koon: how is maven going?
[15:13] <slytherin> Koon: what is the status of your maven2 patching effort? Do you need any help? I may be able to lend a hand over weekend. I would rather do it in 5-6 hours stretch than in pieces.
[15:13] <Koon> the https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec presents two alternatives
[15:14] <Koon> one is the maven2 jpp-patched (the fedora way)
[15:14] <Koon> the other is kaaloo's maven proxy system
[15:14] <Koon> the first alternative can theorically be tested using the packages in my PPA
[15:14] <Koon> (as described in the ubuntu-java email persia kindly resent on my behalf)
[15:14] <persia> Any update from kaaloo on how the proxy system is coming along?
[15:15] <Koon> nothing since Aug 12, but August might not be the busiest month for him.
[15:15] <Koon> my feeling is that it's a nice way around the problem, but I feat the complexity of its implementation
[15:16] <slytherin> persia how about moving Koon's package to java team ppa?
[15:16] <Koon> the jpp stuff is more hackish, maybe more work, but much simpler work.
[15:16] <Koon> i guess I could publish it there
[15:16] <Koon> (as a member of the team) ?
[15:16] <persia> slytherin: I don't see much advantage to one PPA over another.  PPAs can depend upon each other if required.
[15:17] <slytherin> Koon: yes, if you are member
[15:17] <Koon> anyway, it's probably more useful to push the packaging to the team bzr
[15:17] <slytherin> persia: The reason I am asking that is anyone else from team can modify and the reupload the package
[15:18] <persia> slytherin: Ah, with a single source for testing.  Don't let my ambivalence block something you find useful to get something done :)
[15:18] <slytherin> :-)
[15:18] <Koon> slytherin: i'll push the current maven2 packaging mods to the team bzr
[15:18] <slytherin> Koon: next task for you then, move your package to team ppa and add the ppas link on your spec page
[15:19] <slytherin> Koon: let's setup bzr once we have more than 2 people working on it.
[15:20]  * slytherin secretly dislikes bzr
[15:20] <persia> Well, pushing the bzr stuff along with the PPA makes sense, as it keeps things together.
[15:20] <Koon> OK, I will do a little cleanup, push the packaging to team BZR and the resulting package in team PPA
[15:20] <persia> Anything else for maven?
[15:21] <Koon> nothing on my side.
[15:21] <persia> slytherin: How goes the investigation into performance improvements?  Is that something likely, or is it something we ought drop for now, and pick up later?
[15:22] <slytherin> persia: drop as of now.
[15:22] <persia> Anyone else want it before I drop it?
[15:22] <persia> OK.  Gone.
[15:23] <persia> slytherin: How about moving stuff to Universe?  Are we caught up with Debian, or still behind?
[15:24] <slytherin> persia: We are almost with debian, I haven't checked updates in recent weeks. I still have to file few bugs yet.
[15:24] <persia> slytherin: OK.  Is that progress blocked by anything?
[15:25] <slytherin> persia: yes, I am short on time. :-)
[15:26] <persia> Anyone have some time to help slytherin?  The goal here is to identify everything that can be free, so we have a good idea what can be pulled into main.
[15:27] <slytherin> as a start, if anyone can file bugs for libgdata-java and libcodemodel-java it will be good. They are in sync with Debian.
[15:28] <persia> slytherin: Could you send a mail to the mailing list describing the steps required, and asking for help?
[15:28] <slytherin> persia: will do
[15:28] <persia> OK.
[15:29] <persia> As a reminder, we've now reached FeatureFreeze: as a result we'll not be adding any new libraries, new software, or new upstream versions to intrepid without especially good reasons.
[15:29] <persia> Also, any significant changes to behaviour will require an exception.
[15:29] <persia> Does anyone have anything that they expect to need an exception?
[15:30] <slytherin> persia: two packages, ant and fop
[15:31] <persia> slytherin: What do they need?  Especially for ant (as so much build-depends on ant)?
[15:31] <slytherin> ant has a bug fix release 1.7.1.
[15:32] <persia> Any new features, or just bug fixes?
[15:32] <slytherin> persia: AFAIK, just bug fixes
[15:32] <slytherin> fop has a new release 0.95, haven't checked changelog. But debian developer is busy so we won't see an update for long time.
[15:33] <slytherin> persia: ok, wait - Ant 1.7.1 has extended support for Java6 features. Ant 1.7.1 <script> now has support for JavaFX.
[15:33] <persia> That would require an exception.  Is it something we *need* for intrepid, or just nice to have?
[15:34] <slytherin> persia: I will check release notes and see what kind of bug fixes it has. It might be worth having FFE.
[15:35] <persia> OK.  If we need any, please try to report them as soon as possible.  Approvals can take a while, and we may have to rebuild things.
[15:35] <persia> Also, we ought generally avoid them if at all possible.
[15:35] <slytherin> persia: will do both of them by weekend
[15:37] <persia> OK.  Anyone else have any thing we need to discuss?
[15:37] <slytherin> I have one thing.
[15:38] <persia> Yes?
[15:38] <slytherin> doko is not in favor of removing 'library-gcj' packages from 'Recommends'.
[15:39] <persia> OK.  Generally he knows best about these things.  What does that cost us?
[15:39] <Koon> yes, I've expressed a different opinion in bug 249178
[15:39] <slytherin> persia: that costs users about 20 MB of download.
[15:40] <Koon> doko proposed to limit the problem by dropping the recomend of libgcj9-0-awt in libgcj9-0
[15:42] <Koon> personally I think -gcj packages hardly qualify for something you want to have in all but unusual installations, which is the definition of Recommends
[15:42] <persia> Ah.  Looking again at the Foundations Team meeting log (http://irclogs.ubuntu.com/2008/08/27/%23ubuntu-meeting.html) there is mention of java-gcj-compat-hl
[15:42] <persia> Does that also help?
[15:42] <persia> Note also: 23:20	doko	249178 should be uploaded
[15:42] <Koon> it mitigates the issue
[15:43] <Koon> you would still get the gcj packages as soon as you install a jar library that happens to have a -gcj counterpart
[15:43] <Koon> but they wouldn't install all X libraries with them.
[15:44] <persia> OK.  That makes sense.  So it's more about parallel installation than anything else.
[15:45] <Koon> yes. If you drop the recommend, GCJ users get lousy performance unless they install the suggested -gcj package
[15:45] <persia> Personally, I think the wider solution is probably best discussed in concert with Debian.  Having two copies of every library doesn't seem right, but support for gcj remains essential for some architectures.
[15:45] <Koon> if you keep it, you install useless packages for all those who just use openjdk
[15:46] <Koon> doko's proposal is to mitigate the issue by limiting the number of useless packages that would be installed
[15:46] <slytherin> I am not really sure about this lousy performance argument.
[15:46] <persia> slytherin: Koon: Would either of you be willing to debate this with the Debian Java team?  I think we'll probably only get mitigation for intrepid given the scope of the issue (and number of packages affected), but it would be good to also have a plan for the future.
[15:47] <persia> slytherin: I thought GCJ didn't have a particularly fast JIT, which is why the native compilation was preferred.
[15:47] <robilad> it has no jit
[15:47] <slytherin> persia: For debian default-jre is gcj for lenny. So it may not make much difference for them.
[15:47] <Koon> I think doko intends to fix it in a more definitive manner for Intrepid+1 anyway
[15:47] <Koon> see https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026070.html
[15:47] <persia> slytherin: For the release as a whole, sure, but it's with those people that a fruitful discussion can be held: otherwise we need to maintain variance on all the libraries that have such recommendations.
[15:48] <slytherin> persia: I will drop a mail to debian-java list.
[15:48] <Koon> the best way to make sure we're in line with future debian is to follow doko's suggestions :)
[15:48] <slytherin> Two questions. 1. How many people prefer GCJ over Sun JRE at any point of time. 2. How may people who prefer GCj are not aware of -gcj packages.
[15:49] <persia> Koon: Well, as far as that goes, it's also the best way to make sure we're in line with future Ubuntu :)
[15:49] <persia> slytherin: Depends on the architecture.  For some architectures, I expect the answers are 1) everyone, and 2) most of them.
[15:52] <robilad> i'd have a small dpkg-query question - is there a way to query whether a given file is present anywhere in the archive, even if it is not installed?
[15:52] <slytherin> robilad: don't think so.
[15:53] <robilad> dpkg-query -S does a fine job locally but I'd need something that let's me find out whether a jar exist in maybe another package
[15:53] <persia> I don't think with dpkg-query, but apt-file (or working with Contents.gz) can do that.  Anyway, that question makes me suspect our meeting is over, and we ought take discussion back to #ubuntu-java
[15:53] <Seveas> robilad, use apt-file
[15:53] <persia> Thanks everyone.
[15:53] <robilad> thanks & back to work ;)
[15:54] <Koon> thanks persia
[15:54] <slytherin> yup, back to work.


[08:12] <elfy> recently lost update manager telling me there are updates available - also not seeing the "You need to restart to finish installing updates" message - until I happened to reboot - then it appeared
[08:13] <elfy> not sure if that's a bug or something to do with indicator-'things' changing
[08:36] <ochosi_> elfy: well you could start other applications that have their own indicators, i think the restart and update-man stuff all goes through the pkg indicator-application
[08:40] <elfy> the only thing I appear to have in indicators is the volume app - I'm all a bit confused about what used to be where, if it's coming back, when it's coming back - just appears to have appeared with no reason - so thought I'd mention it
[08:42] <ochosi_> what about nm-applet?
[08:42] <ochosi_> indicator or systray?
[08:42] <elfy> oooh - not got nm-applet it appears
[08:43] <ochosi_> wait, not at all?
[08:43] <elfy> nope
[08:43] <ochosi_> that sounds bad
[08:43] <ochosi_> that's quantal with all updates?
[08:43] <elfy> yep
[08:44] <ochosi_> i guess in that case we have to look whether they changed anything in indicator-application
[08:44] <ochosi_> no, there are no recent changes i can see
[08:45] <ochosi_> i mean they changed the versioning scheme
[08:45] <ochosi_> maybe that breaks it...
[08:46] <elfy> k - maybe it was good I wandered by with a random statement then :)
[08:47] <ochosi_> i'll test in my vbox at work in a bit and then take a look
[08:47] <ochosi_> our indicator-application-gtk2 definitely still carries the old versioning scheme
[08:47] <ochosi_> so i guess i'd need to look at whether they also changed it for libindicator
[08:48] <ochosi_> strange, i mean those version-bumps happened all back in july
[08:48] <ochosi_> so they shouldn't have gone unnoticed
[08:49] <ochosi_> bbiab
[09:24] <ochosi> elfy: doesn't look like i can confirm the behavior you describe
[09:24] <ochosi> only missing 3 updates (which i'm installing now), which are unrelated
[09:25] <elfy> mmm - ok, I'll try a clean install at some point this week with b2 and move stuff about :)
[09:25] <elfy> odd - but meh :)
[09:26] <ochosi> oh well, it seems i got more updates coming
[09:26] <ochosi> (wrong mirror)
[09:26] <ochosi> there's even one related to dbusmenu
[09:27] <ochosi> i'll see whether things are still as should-be after install/restart
[09:27] <elfy> I got a bunch of updates this morning
[09:28] <ochosi> and that broke it?
[09:28] <elfy> no - sure that the update notification has been gone longer - I rarely notice the nmapplet - so that could have snuck out with this latest update
[09:29] <elfy> biab - rain has stopped - time to go for a wander
[09:30] <ochosi> otherwise please check whether you can downgrade any related packages that were recently upgraded
[09:36] <ochosi> elfy: ok, even after the latest updates i can't confirm your problem
[09:36] <elfy> ok - I'll assume I've broken something here then :p
[09:36] <elfy> thanks ochosi for confirming
[09:47] <ochosi> elfy: wait, did you say "confirming"? :)
[09:50] <knome> ochosi, "confirming you can't confirm" ?
[09:51] <ochosi> well yeah, it's just misleading to call that confirming :)
[09:52] <knome> but it *is* a confirmation, whether the outcome was positive or negative
[09:52] <elfy> confriming that I'be broken it somewhere :)
[12:31] <ochosi> knome: could you talk to folks@kubuntu when you're at UDS about how they got sponsoring? http://blogs.kde.org/2012/09/21/kubuntu-got-donations-kde-needs-donations
[12:31] <ochosi> knome: just since that seemed so illegal for us to do
[12:43] <knome> ochosi, nobody said illegal
[12:43] <knome> ochosi, we were not sure, we never really asked the legal dept
[12:44] <knome> bbl
[17:31]  * Guest74694 chirp chirp
[17:31] <bluesabre> darn, that failed
[17:31] <bluesabre> :)
[17:43] <astraljava> bluesabre's a cricket?
[17:43] <bluesabre> Until my cricket became Guest74694
[17:44] <astraljava> Occasionally guest star visitors make that bit of a difference in brining down the house.
[17:48] <bluesabre> :)
[17:49] <bluesabre> So how are things, astraljava?
[17:53] <astraljava> Quite diverse. I'm excited and saddened at the same time. I'm going to finally start hunting my dream, which is creating my own music.
[17:54] <astraljava> And how about you?
[18:53] <pleia2> xnox: haha, just saw bug 1055766
[18:54] <drc> :)
[19:24] <Unit193> pleia2: Thanks, that report is going places!
[19:25] <drc> looks like the ubuntu root-guys sent it to the "round file in the corner of the office"
[19:28] <genii-around> Heh "being labeled a snark nearly made my monocle drop out!"
[19:35] <Sysi> competing hard with "too sad icon" bug
[22:42] <xnox> pleia2: sabdfl joined in on the fun, so I think it's all cool =)
[22:43] <Unit193> I really liked that one, yes.
[22:44] <pleia2> xnox: yeah :)
[22:47] <ochosi> tbh i'm a bit happy that we don't have to deal with huge decisions like that one in xubuntu
[22:48] <ochosi> so finally, there's an upside of not having enough contributors :p
[22:53] <SkippersBoss> yeah but do we really want that upside hmm


[19:20] <corrinado[m]> Quick question: If I'm helping someone install Wine (staging) on 21.10 -- is there a specific Repository that is recommended to add as a PPA? Or would those already be included with the install?
 "Quick question: If I'm helping..." <- Pretty sure staging is not installed by default. https://wiki.winehq.org/Ubuntu
[21:13] <corrinado[m]> Appreciate that Moons of Moons . If I were to do a 'standard' *staging* install from somewhere like WineHQ, do you know if I'll be overstepping any functionality that gets shipped in uStudio?
[23:53] <Eickmeyer> corrinado[m]: Shouldn't matter, just support would come directly from WineHQ as opposed to Ubuntu channels.
[23:53] <Eickmeyer> Not for the whole OS, just for anything using Wine.


[13:27] <dholbach> hiya
[13:27] <dholbach> can somebody check if the bot is gone from #ubuntu-devel
[13:27] <dholbach> I mean the one that responds to "@pilot"
[13:30] <Pici> dholbach: looks like it wasn't restarted after the ubottu.com migration... give me a few minutes
[13:30] <dholbach> thanks Pici
[13:33] <Pici> dholbach: should be good now
[13:35] <dholbach> cool, thanks
[13:36] <Pici> (also added it to the monitoring dashboard)


[01:55] <xnox> highvoltage: =)))) it was magic to me, when "accelerated" dlocate was pointed out to me.
[03:39] <infinity> siretart: I noticed, yep.  handbrake finally built after being in proposed for two cycles. :P
[03:48] <infinity> siretart: I guess as soon as the libtiff5 transition happens in Debian, we can just sync?  That'll be pleasant.
[03:48] <infinity> siretart: Should make security much simpler too, assuming you're already doing decent security support for libav in Debian.
[03:49] <infinity> (And maybe no one is... Hrm...)
[05:23] <pitti> Good morning
[05:47] <infinity> jamesh: Where did your openvswitch "2.0.0" come from?  All I can find tagged upstream is 1.9.3
[05:47] <infinity> jamesh: Also, still not ported to 3.12.  Boo.
[05:47] <infinity> jamesh: Err, james tab fail.
[05:47] <infinity> jamespage: ^^^
[05:48] <pitti> http://openvswitch.org/releases/openvswitch-2.0.0.tar.gz ?
[05:48] <pitti> (that's what Debian PTS says, with the watchfile)
[05:48] <infinity> pitti: Cute, given that it's not tagged in git.
[05:49] <infinity> Looks like maybe they just forgot to tag it, I see the "prepare" commit.
[05:50] <infinity> jamespage: Nevermind on the first question, looks like they just forgot to tag it.
[05:51] <infinity> jamespage: The "not ported to 3.12" thing's still irksome, though.  I now have autopkgtest yelling at me. :P
[05:53] <pitti> perhaps we could add a linux-libc-dev build depend to openvswitch, so that in the future openvswitch's autopkgtest runs with a kernel update
[05:53] <pitti> then the kernel would be held back until openvswitch is fixed, instead of silently breaking it
[05:53] <infinity> pitti: Hrm?
[05:54] <infinity> pitti: It's not linux-libc-dev, it's linux-headers (it's a dkms module that explodes), but yeah, ISWYM.
[05:55] <pitti> infinity: ah, or make openvswitch-datapath-dkms depend on some linux-y package, sure
[05:55] <pitti> not sure whether we would actually want to block the kernel for these, but in principle it's "new linux breaks existing stuff"
[05:55] <infinity> pitti: Well.  It shouldn't.  That's a bit of a problem.  Adding arbitrary incorrect dependencies to trick adt seems a bad idea.
[05:56] <pitti> infinity: not really -- openvswitch-datapath-dkms does need the kernel headers and doesn't depend on them
[05:56] <infinity> pitti: No, no, no, no.  And no.
[05:56] <pitti> we just mostly don't add them because we don't know *which* kernel headers to depend on
[05:56] <pitti> it's a kind of "implicit", "you need some of them" dependency
[05:56] <infinity> pitti: I've faught hard to get people to STOP adding linux-headers-foo deps to packages, because they're never correct, and can't be.
[05:56] <pitti> which we can't express
[05:56] <pitti> infinity: yes, I'm aware of that
[05:57] <infinity> pitti: No different from packages that depend on a linux kernel version, we can't express that either.
[05:57] <pitti> infinity: hence my proposal to add linux-libc-dev instead, which is also built by the kernel
[05:57] <pitti> while any fixed package name as a dep is wrong, not having any dependency at all is also wrong
[05:57] <pitti> it's just more conveniently wrong :)
[05:58] <pitti> but stops us from being able to detect those regressions in -proposed
[05:58] <infinity> I suppose it ends up pulling in linux-libc-dev anyway, since it depends on libc6-dev, so it's not going to add more useless croft.
[05:59] <infinity> Nor cruft...
[05:59] <pitti> yes, it's build-essential
[05:59] <infinity> But perhaps we should rather special-case dkms rdeps to recurse for kernel testing.
[06:00] <infinity> Adding debian/control curft to every dkms package seems inelegant.
[06:00] <infinity> WHY CAN'T I TYPE THE WORD CRUFT?!
[06:00] <pitti> (you just did)
[06:00] <infinity> Yeah, yeah. :P
[06:00] <infinity> croft... curft... I'm on a roll.
[06:00] <pitti> but yes, it affects many other packages, too
[06:01] <pitti> infinity: we have a whole set of jenkins jobs for dkms, FYI (https://jenkins.qa.ubuntu.com/view/DKMS/)
[06:01] <infinity> pitti: Yeah, I know, but those don't block kernel migration, clearly.
[06:01] <infinity> Or proposed migration in general.
[06:01] <pitti> right
[06:02] <pitti> jibel and the kernel team discussed that at length, not sure whether not blocking in -proposed on DKMS regressions was intended or not
[06:02] <pitti> (as we clearly don't want to block it for *every* DKMS package we have in the archive)
[06:02] <infinity> Sure we do.
[06:02] <infinity> Just as we block on any other regression.  So we can examine the situation and take a decision.
[06:03] <infinity> The kernel isn't any more a unique snowflake than any other package in that regard.
[06:04] <pitti> I guess their concern was that we don't really support most DKMS packages that we import from Debian, and if we'd do that blocking we essentially would have to
[06:04] <infinity> See, the way I see it, we have to either fix, remove, or temporarily ignore every failure.  But it's better to know than not.
[06:04] <infinity> Just like any other transition.
[06:04] <pitti> we certainly don't want to break the nvidia/fglrx/bcmwl drivers with new kernels, though
[06:05] <infinity> A, B, and C get fixed, D gets removed because we don't care.
[06:05] <infinity> Leaving D broken is bad.  Not fixing C when we could have with a trivial patch is also bad.
[06:05] <pitti> I'd be happy with that; I was just saying what they discussed back then
[06:06] <infinity> I think the story is different for lts-hwe stuff, where a dkms package might work with 3.2 but not 3.8, and we might opt to just leave the 3.8 path broken.
[06:06] <infinity> But no such excuse in a devel series with only one kernel.
[06:08] <infinity> Anyhow, I don't remember ever discussing tying this into britney when we talked about dkms automagic testing, so I don't think there's some process failure here, just something we never got around to discussing and implementing. :)
[06:11] <jibel> we never discussed about blocking automatically the kernel when there is a failure with a dkms module. Currently kernel n+1 from the kernel team ppa is tested and manually reviewed, and published to the distro after review by the kernel team.
[06:12] <infinity> jibel: Sure, I know, I'm a big part of the SRU process, and that's all basically fine, IMO, but I think the devel process might need some work here.
[06:13] <infinity> jibel: Not anything newly broken that wasn't before, so no big rush to sort out something better, but I think we should think about it.
[06:15]  * infinity glares at libticables' configure.ac and wishes for laser vision.
[06:17]  * xnox thought at one point we wanted to block kernel on some _important_ dkms modules, but not all of them.
[06:18] <jamespage> infinity, I failed to find time for the powerpc build failure as well
[06:18] <jamespage> infinity, and yes it does not support 3.12
[06:18] <infinity> jamespage: I fixed the PPC failure, which is why I'm now being yelled at by autopktest about 3.12 incompat. ;)
[06:18] <jamespage> infinity, but we may actually be able to drop the dkms packages as the kernel natively supports GRE and VXLAN tunnels
[06:18] <jamespage> infinity, but I still need to check that out...
[06:18] <infinity> jamespage: Oh, if the dkms package can disappear, that would be lovely.
[06:19] <jamespage> infinity, agreed - I'm really looking forward to not having to fix it with every kernel bump we do
[06:19] <jamespage> I had to cherry pick the 3.11 support from trunk
[06:20] <infinity> jamespage: Yeahp, and by the time 3.12 is fixed, we'll be on 3.13. ;)
[06:20] <infinity> (Not to mention lts-backport kernels in 14.04...)
[06:20] <jamespage> infinity, I just need to check with upstream with some of the megaflows stuff - I don't understand whether thats in the upstream native kernel module or not
[06:20] <jamespage> and will be important to some larger cloud users
[06:20] <jamespage> infinity, time is my problem this week
[06:25] <infinity> jamespage: I'm happy to leave it in its current state in proposed, if you're chasing down the dkms things.  I was just whining because of the angry email I got after fixing it. :)
[06:25] <jamespage> infinity, OK - leave it with me - I'll check this next week
[06:34] <jibel> pitti, I proposed a patch for sbuild and pbuilder autopkgtest failures. If you have a minute for a review it is bug 1247420
[06:42] <pitti> jibel: oh, do we limit autopkgtest dependencies to main now for main packages?
[06:43] <jibel> pitti, no it is in the test, the chroot used to test pbuilder and sbuild only have main enabled
[06:43] <infinity> Yeah, it's creating a chroot in the test, which makes sense, given the package being tested.
[06:46] <infinity> jibel: So, I'm all for the other improvements to those tests (fixing set -e, using better lsb_release bits), but would have been nice to have them in another commit, so you could more easily split out the bunch and submit them to Debian as two different patches.
[06:46] <pitti> jibel: or it could perhaps build a package in main?
[06:46] <pitti> infinity: the autopkgtest of at least sbuild isn't in Debian at all, FYI
[06:46] <infinity> Oh, it's not?  Figured it was, given the lsb_release forking based on release.
[06:46] <infinity> Nevermind, then. :)
[06:47] <pitti> jibel: ah, nevermind; with that it can test the "components=" functionality, too :)
[06:47]  * infinity does appreciate it when a test tests as much as it can.
[06:47] <infinity> Unit testing is for wimps.
[06:49]  * infinity is quite fond of rbasak's libapache2-mod-svn test that appears to test svnadmin, svn, and the apache module, all in one go.
[06:49] <infinity> Which is, basically, the entire source package.
[06:49] <pitti> i. e. "fastest" and "hardest to debug" :)
[06:49] <pitti> but as long as these tests give you useful output when they fail, it seems okay
[06:50] <infinity> pitti: Well, when your testsuite is essentially a shell script, it's not hard to debug where one line breaks.
[06:51] <infinity> (Obviously, unit testing and the like have their place when your tests need to be more complex, or you're testing for specific regressions, etc, but most autopkgtests don't seem that fancy)
[06:51] <infinity> I do question if maybe some of them SHOULD be that fancy.
[06:51] <pitti> jibel: can you please forward the updated test to debian bug 705926 ?
[06:51] <infinity> When I was working on Maemo, we were religiously breaking build-time test suites out into -tests runtime packages and mangling them to run under a runtime test harness.
[06:52] <infinity> Which, obviously, took way longer to run than the average autopkgtest, but also provided some decent coverage in some cases.
[06:52] <infinity> Undecided if the pain was worth it.
[06:53] <jibel> pitti, sure, and pbuilder diff to 705917
[06:53] <pitti> jibel: en effet, merci !
[08:41] <sil2100> stgraber: ping!
[09:29] <pitti> tseliot: hm, nvidia and fglrx build, but nvidia-updates and fglrx-updates fail: http://paste.ubuntu.com/6357855/
[09:29] <pitti> tseliot: (detected by ubuntu-drivers-common autopkgtest)
[09:30] <pitti> tseliot: want a bug for that, or are you on it? I suppose the non-updates variants have a patch which isn't applied to -updates?
[09:30] <tseliot> pitti: I'm wondering why the system we have in place doesn't send me an email as planned
[09:30] <pitti> tseliot: that's
[09:30] <pitti> err
[09:30] <pitti> tseliot: that's mostly because the autopkgtest isn't in the nvidia/fglrx package itself, but in u-d-common; that didn't get an upload
[09:31] <pitti> tseliot: so the system doesn't know whom to contact, it just contacts jibel and me as fallback
[09:32] <tseliot> pitti: oh, ok. Please add my email address when you can. I'll check all the flavours, just to be sure
[09:32] <pitti> tseliot: the other flavours are fine; the current u-d-c test on jenkins fails all of them due to something else, but I just fixed that in git (uploading now)
[09:33] <pitti> well, we test nvidia 304 and 319 and fglrx, and all -upates for those, perhaps there are other flavours by now
[09:34] <tseliot> pitti: there's 173. Also I'm going to introduce 331
[09:35] <pitti> tseliot: thanks; I'm uploading u-d-common now as the other tests are fixed again
[09:36] <tseliot> pitti: ok, thanks
[10:11] <didrocks> pitti: hey!
[10:12] <seb128> is anyone here on saucy with some hardware which requires binary drivers (e.g use of the software-properties' driver install)
[10:12] <seb128> I need somebody to SRU confirm bug #1241210
[10:14] <didrocks> pitti: IIRC, you were the one adding me to ubuntu-drivers. I think I'm going to expire from the team. I think it would make more sense that I'm part of this team through UDS organizer, being a track lead?
[10:14] <didrocks> pitti: it seems only the tech board (but only having sabdfl in this team?) is an admin for it
[10:17] <seb128> didrocks, TB expired and need to be renewed I think, until then you might need sabdfl/get stucked :/
[10:17] <didrocks> yeah, let's see how it goes…
[10:18] <didrocks> I guess the issue of TB expiring impacted many other nominations
[10:18] <pitti> didrocks: -ENOTECHBOARD at the moment, I'm afraid :/
[10:18] <didrocks> yeah
[10:18] <pitti> seb128: /usr/share/ubuntu-drivers-common/fake-devices-wrapper software-properties-gtk ?
[10:21] <seb128> pitti, thanks, I didn't know about /usr/share/ubuntu-drivers-common/fake-devices-wrapper
[10:23] <pitti> seb128: heh, I cobbled that together back then for that very reason (it's been a while since I actually had a computer which needs binary drivers)
[10:24] <seb128> pitti, is it actually downloading/installed drivers when you use the UI? (it seems to be really downloading stuff, I wonder if I'm going to end up with nvidia installed :p)
[10:24] <seb128> it does it seems
[10:25] <pitti> seb128: yes, you will
[10:25] <pitti> so better uninstall it again afterwards, unless that's a VM
[10:25] <seb128> pitti, thanks
[10:25] <seb128> (hum, it doesn't prompt me for reboot :/)
[10:26] <pitti> seb128: in the original designs it was supposed to update the status to something like that after installation ("restart computer to activate" or so)
[10:27] <seb128> pitti, well, I'm trying to test https://code.launchpad.net/~seb128/software-properties/dont-use-deprecated-reboot-commands/+merge/191720
[10:27]  * seb128 reads code again
[10:30] <seb128> good, that's working
[10:30] <seb128> pitti, danke
[10:32] <pitti> seb128: ah, good; seems a bit confusing to invoke that dialog, but I guess better than no confirmation at all
[10:33] <seb128> pitti, right, better than getting a whoopsie dialog because the code is calling a non existing binary, in any case
[10:33] <pitti> heh, absolutely :)
[12:49] <hrw> hi
[13:51] <brainwash> pitti: hey, could the logind resume issue be indeed related to some bug in kernel 3.11? the new systemd-shim package only fixed the problem for like 50% of the people
[13:52] <pitti> brainwash: or it could be that they suspended for more than 10 minutes?
[13:52] <pitti> brainwash: if that's not it, then I suppose there's another, independent, bug somewhere between logind and shim
[13:53] <brainwash> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/103
[13:53] <brainwash> maybe the 30sec d-bus timeout?
[13:54] <brainwash> i can only reproduce it with a fake suspend
[13:55] <brainwash> but it would explain why logind does not get stuck for some people, it simply reverts back to PrepareForSleep = false after the d-bus timeout
[13:56] <brainwash> hopefully some people will post their log files
[14:26] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/rar/+bug/776851
[14:26] <maxiaojun> can anyone help this?
[14:30] <xnox> maxiaojun: why bug against ubuntu-package? backports are tracked / managed by backports projects only.
[14:31] <maxiaojun> the bug wasn't a back port request
[14:32] <xnox> maxiaojun: it had tasks open against Backports project so yes, it was a backport request. Was it meant to be something else?
[14:33] <xnox> maxiaojun: and it's fix-released in 13.04 and up.
[14:33] <maxiaojun> xnox: fixed in short term releases isn't that useful
[14:33] <maxiaojun> xnox: it was a bug towards rar package only
[14:35] <xnox> maxiaojun: in that case, you should have nominated the bug for series where it's still a problem and follow the StableReleaseUpdates procedure. Do you know about Stable Release Updates?
[14:37] <maxiaojun> i should have asked and may be someone told me that the best i can get is back port
[14:38] <xnox> maxiaojun: #ubuntu-bugs are usually helpful when "i know where/what needs to be fixed, but not sure how to properly triage/request that"
[14:38] <xnox> maxiaojun: load up bug #776851 again
[14:39] <xnox> maxiaojun: I've nominated it for Precise & Quantal with status incomplete, and set it to fix released (aka raring and up are fine)
[14:39] <xnox> maxiaojun: I've also added a comment about stable release updates.
[14:39] <xnox> maxiaojun: if you can provide information as per template "https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template" that would be a great help.
[14:39] <maxiaojun> the problem is very very clear
[14:40] <xnox> focus on test-cases and regression testing, e.g. sample test files that used to fail and now pass, and regular files that worked before and not after.
[14:41] <xnox> maxiaojun: it is not to me. It should be made clear to those who don't use that package, developers and "Ubuntu Stable Release Team" who ultimately decide if an update goes in.
[14:41] <xnox> maxiaojun: by default we do not update package in stable releases, and only release targetted bugfixes.
[14:41] <maxiaojun> haven't you seen all the previous user comments?
[14:42] <xnox> maxiaojun: sure, but somebody neeeds to summarise what a problem is, steps to re-create reproduce, and assess regression potential.
[14:42] <maxiaojun> *any* rar file with non-ascii filenames in it is a test case
[14:43] <xnox> maxiaojun: well then write that up. using https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[14:43] <maxiaojun> yes, rar 4.20 is very likely to break rar 4.0 beta 3
[14:43] <maxiaojun> because old bugs cannot be reproduced
[14:43] <xnox> maxiaojun: without those steps done, it will not be uploaded / accepted into stable updates channels for precise/raring.
[14:44] <xnox> maxiaojun: did command line options changes? are all/same binaries present? did it gain extra dependencies? or loose some?
[14:44] <maxiaojun> none
[14:45] <xnox> maxiaojun: if you don't want to work on getting a Stable Release Update out for rar, that's ok. But _I'm_ not going to do it. Hopefully somebody else well.
[14:45] <xnox> s/well/will.
[14:45] <maxiaojun> i appreciate your wild imagination
[14:47] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/rar/+bug/731066
[14:47] <maxiaojun> asked about SRU before
[14:47] <maxiaojun> but as bugs being marked "fixed", it is a bit hard to find them out
[14:49] <xnox> maxiaojun: now it's on https://bugs.launchpad.net/ubuntu/quantal and https://bugs.launchpad.net/ubuntu/precise pages
[14:50] <xnox> maxiaojun: bug needs to be nominated to the series where it's still a bug, if it's significant enough to warrant an SRU, and if someone is working on getting it out.
[14:50] <maxiaojun> but a normal use cannot request for nomination
[14:52] <maxiaojun> during the raring cycle the culture was a bit different, as 9-month-support (useless support) isn't decided yet
[14:54] <maxiaojun> xnox: do you think i should still try sru request?
[14:54] <xnox> maxiaojun: i believe anyone can request to nominate. and then it will be pending to be "accept/decline" nomination. which developers regularly go through.
[14:54] <maxiaojun> xnox: not the case
[14:54] <xnox> maxiaojun: or ping people on #Ubuntu-bugs to get bugs nominated.
[14:55] <maxiaojun> that's time-consuming
[14:55] <xnox> maxiaojun: i filed the sru request for you, based on your request. (nominated bug for the right series)
[14:55] <maxiaojun> thank you! where?
[14:56] <xnox> maxiaojun: if you fill out the template, then it will move to confirmed state. After that and update needs to be prepared (should be easy, since it's basically package version tweak) and then a sponsor will need to upload it.
[14:56] <xnox> maxiaojun: bug, same one. I've updated it to be nominated for series. <xnox> maxiaojun: load up bug #776851 again
[14:56] <xnox> clcik on it.
[15:16] <maxiaojun> done
[15:40] <pitti> tseliot: FYI, https://jenkins.qa.ubuntu.com/job/trusty-adt-ubuntu-drivers-common/9/ARCH=amd64,label=adt/ is a current run, and has .crash files for the DKMS failures, and the logs (which now succeed for all packages except said two)
[15:41] <tseliot> pitti: thanks. I have fixed nvidia locally and now I'm working on the other package
[15:41] <pitti> tseliot: sweet, thanks
[15:48] <psusi> does anyone know what happened to the /etc/mtab -> /proc/mounts transition?  I thoguht we supposedly had done that for new installs a release or two back, but it doesn't seem to be the case.  What component is responsible for creating /etc/mtab ( dpkg says not owned by anyone )?  Is it d-i?  ubiquity?
[16:15] <maxiaojun> xnox: don't how to do the version change in debdiff, and debdiff seems a little useless here as some files are binary only
[16:16] <xnox> maxiaojun: debdiff against raring package.... it will have correct version for the SRU, target release, changelog entry with bug closure (LP: #NNNYNNN)
[16:17] <xnox> something that a sponsor can apply against raring package, such that it's appropriately ready to be uploaded into "precise" and "quantal" series.
[16:18] <maxiaojun> "it will have" means i don't need to do anything special?
[16:19] <maxiaojun> as this package packages binary-only software, debdiff just captures some doc change actually
[16:19] <xnox> yes. it's packaging metadata change.
[16:19] <xnox> (the debian/changelog needs updating)
[16:19] <xnox> $ pull-lp-source rar raring
[16:19] <xnox> $ cd rar-*
[16:19] <xnox> $ dch -i
[16:20] <xnox> and then correct the entry: 1) target series 2) version number 3) entry text 4) bug number closure.
[16:20] <xnox> build the source package with $ debuild -S
[16:20] <xnox> and do a debdiff between raring version and the new one with $ debdiff
[16:20] <xnox> rince, repeat twice - once for precise and once for quantal.
[16:22] <chiluk> so I'm trying to sru a fix for bip in precise, and it's currently versioned 0.8.8-1build1   what is the correct way to increment that build number?
[16:25] <xnox> chiluk: 0.8.8-1build1.1   or 0.8.8-1ubuntu0.1
[16:25] <xnox> chiluk: note that u > b =)
[16:26] <chiluk> yeah...
[16:26]  * xnox preffers 0.8.8-1ubuntu0.1, but either is valid
[16:26] <xnox> chiluk: the only hard-rule is that it needs to be >> then precise but << than quantal (or any possible SRUs / Security versions there)
[16:26] <xnox> s/then/than/
[16:27] <xnox> and there in infinite amount of versions between 0.8.8-1build1 and 0.8.8-2 =)
[16:28] <xnox> chiluk: for luci-updates they used 0.8.2-1squeeze4build<IP_ADDRESS>
[16:28] <xnox> which looks a bit odd =) but well, it works.
[16:30] <chiluk> xnox well in this case I'm backporting the only change from quantal back into precise.
[16:35] <maxiaojun> xnox: debdiff done, are they what you expected to see?
[16:37] <xnox> maxiaojun: yes, looks good. Subscribing ubuntu-sponsors.
[16:39] <xnox> maxiaojun: a few request piled up in the sponsoring queue at the moment. http://reqorts.qa.ubuntu.com/reports/sponsoring/ but very soon one of the patch pilots will review your debdiffs and/or comment with reviews or uploads it for Ubuntu Stable Release team to review.
[16:39] <xnox> maxiaojun: thanks a lot for your work! =) everything is done now, just wait for a sponsoring
[16:39] <xnox> your bug will appear on the report, next time it refreshes.
[16:40] <maxiaojun> thank you for your helps also!
[16:44] <xnox> maxiaojun: no problem =)
[16:46] <mapreri> Do you now if someone (doko?) will take care if pushing automake 1.14 in trusty? (ref: http://packages.qa.debian.org/a/automake-1.14.html   and bug # 1191959)
[16:46] <mapreri> of*
[17:00] <xnox> mapreri: i'm working on it. but got sidetracked.
[17:01] <xnox> mapreri: i am aware of that bug and fix/patch.
[17:01] <xnox> mapreri: i still need to run full autopackage test.
[17:01] <xnox> I will send an email about it to ubuntu-devel and I hope to get automake 1.14 in, before the first full-archive trusty rebuild.
[17:05] <mapreri> xnox: great! I'm waiting for it :). Yesterday I was working on merging lighttpd, and it complains about the lack of automake 1.14, and I don't want at all to patch it to work with 1.13 :p
[17:06] <xnox> mapreri: just wait, or upload it with "Build-depends: automake (>= 1.14)" or whatever the proper epoch:version is. It will go into dep-wait state and will be built once the new automake is in.
[17:10] <cjwatson> It's also not terrible to just let it FTBFS until automake 1.14 is in
[17:11] <mapreri> xnox: cjohnston  I prefer waiting... I definitely prefer performing a local build before uploading something
[17:59] <slangasek> cjohnston: do we have an autoscheduler for this vUDS?
[17:59] <cjohnston> slangasek: nope
[17:59] <cjohnston> well, shouldnt
[18:00] <cjohnston> doesn't appear as though we do
[18:01] <cjwatson> FYI: publisher down pending investigation of I/O errors
[18:02] <slangasek> cjohnston: what do you mean, "shouldn't"?  So the track leads need to schedule everything by hand
[18:02] <slangasek> ?
[18:02] <cjohnston> slangasek: correct... no auto scheduler... leads need to manually schedule things
[18:04] <slangasek> cjohnston: and who decided that this was a good idea?
[18:04] <cjohnston> slangasek: this was based on complaints from track leads
[18:04] <cjohnston> been this way for atleast all of the vUDS events IIRC
[18:14] <slangasek> cjohnston: ok, but who made this decision?  I am a track lead, and have *never* complained about the presence of the autoscheduler.  I also haven't been manually scheduling sessions for vUDS, which means someone else must have been doing it for the foundations track
[18:15] <slangasek> so if someone else is going to manually schedule the sessions, then I suppose I don't need to worry about it; but so far no one has done this for our blueprints this round
[18:15] <slangasek> and if no one else is doing this, then I will complain - loudly - about the busywork involved in manually scheduling these sessions
[18:16] <cjohnston> mhall119: do you have any more backstory on ^
[18:17] <mhall119> I don't know who made the original decision not to use autoscheduling, bit cjohnston is correct that it was never used for vUDS
[18:18] <mhall119> I think, because track leads have to start every session's Hangout, we wanted to make sure they were scheduled according to the track lead's needs
[18:26] <knocte> hallo, how many Approve votes must a merge-request receive to be merged?
[18:27] <infinity> knocte: It's not about voting, it's about someone who can actually merge it being the approver.
[18:27] <infinity> (Can, and is willing to)
[18:28] <infinity> @pilot in
[18:28] <infinity> knocte: Which MP is this?
[18:28] <knocte> infinity: https://code.launchpad.net/~knocte/ubuntu-themes/cleanup-empty-rules/+merge/192903
[18:32] <infinity> Ahh, I won't touch that with a 20-foot pole, my knowledge of GTK themes isn't deep enough, but I'll see if it can get reviewed by someone who can merge it.
[18:33] <knocte> infinity: it doesn't require gtk superpowers really, just CSS knowledge to know that the patch brings sanity :)
[18:33] <knocte> s/CSS/basic CSS/
[18:35] <infinity> knocte: Well, see.  I know CSS well enough from, like, 1999, but I don't know if GTK's CSS relies on empty classes to work around quirks, or if the ubuntu themes themselves might, or whatever.  So, I'd rather have someone more knowledgable sort it out and commit to the upstream branch.  I've pinged someone to that end.
[18:36] <knocte> infinity: ok thanks; and to the best of my knowledge, gtk's CSS works (or should work, if it doesn't "file a bug") in the same way as normal CSS so I don't think there would be quirks or similar hacks
[19:39] <hallyn_> tjaalton: hey - so looking at https://launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/0.1.1-0ubuntu1 - do you think it's worth just trying rebuilds?
[19:40] <hallyn_> it looks like libxext-dev didn't get installed
[19:41] <hallyn_> I can dig, but don't know the dependencies in the X cruft very well
[19:51] <hallyn_> hm, looks like xserver-xorg-video-qxl should perhaps be build-depping on it
[19:52] <mdeslaur> xnox: looks like you dropped some changes in thin-client-config-agent that caused LP: #1187450
[19:54] <stgraber> utlemming: upload rights granted, you're all set
[19:54] <utlemming> stgraber: awesome, thank you sir
[19:55] <xnox> mdeslaur: =/
[19:56] <xnox> mdeslaur: assigned to myself & scheduled SRUs.
[19:56] <mdeslaur> xnox: not sure if it's worth sruing, honestly
[19:57] <xnox> mdeslaur: well if remote login is broke, that's kind of important =/
[19:58] <mdeslaur> xnox: ok
[19:58] <mdeslaur> xnox: thanks
[20:06] <infinity> hallyn_: You have any qemu days coming up in your schedule?
[20:07] <infinity> hallyn_: https://wiki.debian.org/Arm64Qemu <-- Do want in Ubuntu.  And vagrant and co would happily take a sane patch for it in Debian too, from what he told me in #debian-arm
[20:08] <psusi> cjwatson: grub-install takes the GRUB_DISTRIBUTOR and truncates it at the first space and converts it to lower case for use as the efi bootloader_id... why is this?
[20:10] <hallyn_> infinity: i'll take a look this week.  I'm less than thrilled that it's a whole separate tree, but maybe it only has a few cleanly cherrypickable patches
[20:11] <hallyn_> (i'll check the m-l for past submissions too)
[20:11] <hallyn_> (hopefully tomorrow)
[20:11] <infinity> hallyn_: They're in the process of upstreaming it with a target of (I believe) 1.8, but pulling in a patch for 1.6 would be nice.
[20:11] <infinity> hallyn_: I haven't looked, but I'm hoping/assuming it's fairly self-contained.
[20:12] <hallyn_> yup will give the backport a shot
[20:13] <hallyn_> tjaalton: xserver-xorg-video-qxl built fine for my in chroot on porter-armhf.  can you just add libxext-dev to build-deps?  (I don't have upload rights)
[20:13] <infinity> What.  The.  Eff.
[20:14] <infinity> Alt-Right and Alt-Left have started swapping me between VCs.
[20:14] <infinity> This is seriously messing with my head, since that's also how I move between irssi windows.
[20:14] <psusi> infinity: did you hit sysrq-e?
[20:14] <infinity> Oh, I bet this is a consequence of running console-setup under my X session while fiddling with a chroot.
[20:15] <infinity> psusi: Definitely not. :)
[20:15] <infinity> This is remarkably jarring, though.
[20:16] <infinity> And Alt-F1 works from my X session without the need for the usual Ctrl modifier now.
[20:16] <infinity> Head explodey.
[20:17] <stgraber> infinity: that's fairly easy to fix, let me try to remember how
[20:17] <infinity> stgraber: I was thinking "toss hands in air; reboot".
[20:18] <infinity> And was already closing terminals to that end. :P
[20:18] <stgraber> kbd_mode can fix it for you
[20:18] <infinity> Probably.  But I only reboot my laptop once a month anyway, it's due.
[20:18] <stgraber> infinity: sudo kbd_mode -s
[20:19] <infinity> stgraber: That did indeed fix it, though.  Thanks.  I'll try to remember that the next time I do this to myself.
[20:19] <infinity> (And now I'll reboot anyway, cause I like to see what explodes when I do)
[20:19] <infinity> Which reminds me...
[20:19] <infinity> Whose baby is the "waiting 300 minutes for your network configuration to happen" upstart job?
[20:20] <infinity> stgraber, slangasek: ?
[20:20] <slangasek> infinity: yes
[20:20] <stgraber> not mine, though usually when it happens it's my fault somehow ;)
[20:20] <slangasek> infinity: if you're actually waiting 300 seconds for your network configuration, it's because your network is misconfigured :P
[20:20] <infinity> Every time I accidentally leave eth0 in auto and then do something silly like reboot in an airport lounge, I have a sad.  That could really do with an "I don't care, skip it" key, like fsck has.
[20:20] <stgraber> (since it should never appear if ifupdown/NM do their job)
[20:21] <infinity> slangasek: Yes, it's absolutely because I left something on auto and don't have a cable in.  Not arguing otherwise. :)
[20:23] <infinity> slangasek: The "I don't care" key would still be nice, for idiots like me, and also for people who actually have a broken network and would like to get to the OS in a timely fashion to debug it.
[20:23] <infinity> Currently, I swear I can hear a tiny whip cracking and cackling in the distance while it says "your network is still broken, I shall punish you for another minute.  hold please."
[20:24] <slangasek> infinity: ah, hmm.  well, that would take some rejiggering of /etc/init/failsafe.conf to give it a way to listen for a key asynchronously
[20:29] <infinity> slangasek: Want a wishlist bug?
[20:31] <infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1247963
[20:35] <stgraber> I'm not sure how the user interaction works within plymouth, but from an upstart point of view, we could do it by having failsafe.conf do "start failsafe-keypress &" with that job waiting for a keypress from plymouth and if it matches whatever we're looking for, emit static-network-up which will get failsafe.conf to exit and the boot to continue
[20:42] <xnox> stgraber: we are already watching for some keypresses and emit events for those. E.g. "control-alt-delete" =) we could overload that job, to try emitting static-network-up ;-)
[20:44] <stgraber> well, in this case, I think it'd be much cleaner to get plymouth to forward the keypress (same thing as we do with mountall) than have upstart watch another obscure key combination :)
[21:20] <jtaylor> can one fix gdb for python3 in saucy without recompiling gdb against python2?
[23:15] <slangasek> infinity: wishlist bug> well, that's not likely to be fixed unless you work on it, fwiw
[23:19] <RAOF> jtaylor: Yeah, mostly. You can run 2to3 on the gdb hook, and that worksish.
[23:19] <jtaylor> unfortunately not
[23:19] <jtaylor> that fixes the error in starting gdb
[23:19] <jtaylor> but the python plugins are still broken
[23:20] <jtaylor> I recompiled with py2 now, easier than figuring out how the plugins work :/
[23:21] <slangasek> mmm? are you working on porting gdb's python support to py3?
[23:21] <jtaylor> no trying to debug python extension code
[23:21] <slangasek> ah
[23:21] <jtaylor> may I ask why gdb was changed? its not seeded
[23:21] <jtaylor> oh it is
[23:22] <slangasek> right, gdb is certainly in main at the very least :)
[23:22] <jtaylor> everything in main must now be python3?
[23:23] <slangasek> well, "must"
[23:23] <slangasek> we are in the process of deprecating python2 from main and have been for a couple of years already
[23:23] <slangasek> but it hasn't been the easiest transition in the wolrd
[23:23] <jtaylor> yes but gdb wasn't really ready for py3 yet
[23:23] <jtaylor> the python plugins are incredibly useful
[23:23] <slangasek> according to the changelog the change to support it was made upstream
[23:24] <slangasek> are the plugins part of the gdb source or from somewhere else?
[23:24] <jtaylor> I think they are part of python
[23:24] <slangasek> e.g.?
[23:24] <jtaylor>  /usr/lib/debug/usr/bin/python2.7-dbg-gdb.py
[23:26] <slangasek> the equivalent scripts seem to exist in the python3.3-dbg package
[23:26] <jtaylor> tried those too, didn't really work
[23:27] <jtaylor> I didn't look into it much, just tried 2to3 and the python3 file, then I recompiled gdb
[23:27] <slangasek> I'm not familiar with how these are used, how can I reproduce the problem you're seeing (so I can help make sure it gets fixed)?
[23:27] <jtaylor> just needed to debug something rather quickly
[23:28] <jtaylor> if you start gdb you get a syntax error, and if the plugins are working you get nice python object resolving, e.g. http://paste.ubuntu.com/6361710/
[23:28] <slangasek> if you start gdb how?
[23:28] <slangasek> when I run 'gdb' I get no such error
[23:29] <jtaylor> hm I get it everytime, do you have python-dbg installed?
[23:29] <slangasek> no - you mean installing python3.3-dbg, and running 'gdb' with no target, is sufficient to reproduce the problem?
[23:29] <jtaylor> let me just revert my gdb
[23:30] <jtaylor> ah no you have to debug python
[23:30] <slangasek> ok
[23:30] <jtaylor> http://paste.ubuntu.com/6361721/
[23:31] <jtaylor> hm there is bug 1241668
[23:33] <jtaylor> the upstream patch does not work :/
[23:33] <jtaylor> like 2to3 it just fixes the syntax errors but not the functionlity
[23:35] <slangasek> right, it seems like even /usr/lib/debug/usr/bin/python3.3dm-gdb.py is a python2 script, not a python3 script... I guess nobody was able to test this until recently because gdm didn't support python3
[23:35] <slangasek> er, gdb
[23:41] <slangasek> jtaylor: so, how would I test the functionality?  2to3 lets me run gdb, and I can set a breakpoint on a C function but don't know how to use this to set a breakpoint on a python function
[23:42] <xnox> (there were bugs with it, but i thought is or in-process of being fixed and uploaded)
[23:42] <xnox> third party plugins non-with-standing...
[23:42] <jtaylor> slangasek: break e.g. in PyTuple_Size
[23:43] <slangasek> Python Exception <class 'AttributeError'> 'PyDictObjectPtr' object has no attribute 'items':
[23:43] <jtaylor> the frame should show the content of the tuple if the plugin works
[23:43] <slangasek> I guess that's the issue?
[23:43] <jtaylor> yes
[23:43] <slangasek> righto
[23:43] <jtaylor> one of them, depending on what feature is used you get different errors
[23:46] <jtaylor> upstream issue is http://bugs.python.org/issue19308
[23:46] <jtaylor> the patch there does not seem to work (commented on it)
[23:47] <barry> oh my, look at all the python going on here
[23:52] <StevenK> barry: O HAI. If you have a second, care to weigh in on https://bugs.launchpad.net/launchpad/+bug/1050173 ?
[23:53] <slangasek> fwiw that looks suspiciously like a bug in the gdb support, to me... why does it want 'items' instead of 'iteritems' (the function that's provided by the class in this script, even for python2)?