[00:04] <TheMuso> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
[01:33] <xnox> ScottK: doko: I don't see a reason for that, either. Mind sharing your train of thought here?
[01:34]  * ScottK didn't either.
=== jono is now known as Guest2834
=== ironhalik_ is now known as ironhalik
[03:59] <TheMuso> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[05:17] <DigvijayUbuntu> Hello people
[05:17] <DigvijayUbuntu> I needed help understanding how the ubuntu-software-center code is layout
[05:17] <DigvijayUbuntu> any pointers on where i can start?
[05:19] <sarnold> DigvijayUbuntu: I really love ctags, id-utils, and cscope
[05:19] <DigvijayUbuntu> sarnold: i am a bit confused
[05:19] <DigvijayUbuntu> so you can help me?
[05:19] <sarnold> DigvijayUbuntu: I can try :) hehe
[05:20] <DigvijayUbuntu> ok greate =)
[05:20] <DigvijayUbuntu> wait lemme pm u
[06:00] <pitti> Good morning
[06:08] <tvoss> pitti, good morning :)
[06:08] <vibhav> guten morgen
[06:15] <tvoss> guten morgen :)
=== MaJian is now known as BruceMa
[06:41] <KeithW> Hello folks. We just released mosh 1.2.4 and uploaded 1.2.4-1 to Debian. What is the appropriate way to respectfully request a sync to Ubuntu raring (universe) and a FFe to make the release?
[06:58] <infinity> KeithW: Point me at a 1.2.3 -> 1.2.4 changelog?
[06:58] <KeithW> infinity: http://mailman.mit.edu/pipermail/mosh-devel/2013-March/000447.html
[06:59] <infinity> KeithW: Looks good to me, syncing.
[06:59] <infinity> Or... I would if LP knew about the version in unstable yet. :P
[07:00] <infinity> I'll sync when it does.
[07:00] <infinity> KeithW: FWIW, I would have called the mm:ss disconnect display a bugfix, not a feature.  Being offline for eighty bazillion seconds has always annoyed me. :P
[07:01] <KeithW> :-)
[07:01] <KeithW> Thanks much!
[07:33] <dholbach> good morning
[07:34] <dholbach> can somebody from the desktop people reply to https://twitter.com/larsschuetze/statuses/316652779605225473 maybe? :)
[07:42] <mardy> thomi: ping (need some help with autopilot)
[07:58] <mardy> dholbach: hi! Do you know how to write autopilot tests?
[07:59] <dholbach> mardy, I'm afraid not - I wrote an autopkgtest once though :)
[08:00] <mardy> dholbach: do you know anyone who could help me, who is currently online? It's a rather newbie-like question, I presume
[08:03] <dholbach> mardy, maybe just best ask the question?
[08:05] <dholbach> pitti, Mirv: ^ do you know much about autopilot?
[08:05] <mardy> dholbach: let's try :-)  How do I wait till an application becomes visible, after calling start_app()?
[08:06] <pitti> mardy: perhaps you can pick a particular widget and use Eventually() to wait until its visible property becomes tru?
[08:06] <pitti> true
[08:06]  * pitti only did some baby steps with autopilot as well, I'm afraid
[08:07] <Mirv> dholbach: I can run the autopilot tests of unity and tweak if something fails, but not that much. I'd take a look at unity autopilot tests for a basis.
[08:07] <mardy> pitti: I'll try -- but I guess that I won't be able to get a handle to any widget, until the window is created
[08:08] <Mirv> mardy: Eventually seems to be used in Unity..
[08:09] <mardy> Mirv: I tried that, but on what property? "user_visible" doesn't work ("Eventually is only usable with attributes that have a wait_for function or callable objects.")
[08:11] <mardy> funny thing is that none of the tests in http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/trunk/files/head:/ubuntu_autopilot_tests/ check for the window visibility
[08:11] <mardy> maybe start_app() actually waits for the window visibility itself?
=== smb` is now known as smb
=== zyga is now known as zyga-afk
[08:38] <dholbach> seb128, salut - do you know who could reply to https://twitter.com/larsschuetze/statuses/316652779605225473?
[08:38] <seb128> dholbach, salut
[08:38] <seb128> looking
[08:40] <seb128> dholbach, you could reply? ;-)
[08:40] <dholbach> no
[08:40] <dholbach> I don't know the answer
[08:40] <seb128> no reason we can't if there are applications proving good enough
[08:41] <seb128> I don't see qml equivalent/replacements of our desktop core apps atm though
[08:41] <seb128> but I'm pretty sure that will happen in the futur, hard to predict when and what apps though
[08:41] <thomi> mardy: Hi
[08:42] <dholbach> seb128, ok
[08:42] <thomi> mardy: did you get your problem resolved?
[08:43] <mardy> thomi: hi! Just trying to write some autopilot tests for Online Accounts, and I've a few questions :-)
[08:43] <mardy> thomi: does the start_app() actually wait for the window to be visible, before returning?
[08:44] <thomi> mardy: hmmm, let me check
[08:44] <mardy> thomi: none of the tests in http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/trunk/files/head:/ubuntu_autopilot_tests/ is waiting for that, they all seem to assume the window is already available
[08:45] <thomi> mardy: it doesn't check for window visibility inside that method, no. I belive some of the tests have their own way of checking that the application has been initialised
[08:45] <thomi> which would be the correct way to do it
[08:45] <thomi> since an application window can be visible, but not initialised yet
[08:46] <thomi> mardy: so Ideally you'd start the app (via launch_test_application), and then read application state to ensure that it's been set up correctly
[08:47] <mardy> thomi: OK, the second question is: are start_app() and launch_test_application() completely separate? or can I get an ApplicationProxyObject froma BamfApplication object?
[08:48] <thomi> mardy: they are completely separate, and no, you can't. launch_app just starts the application normally, whereas launch_test_application does the "magic glue" that allows autopilot to introspect the application
[08:48] <mardy> thomi: well, I guess that if I use launch_test_application() directly, the question above doesn't even apply
[08:48] <mardy> thomi: OK, now it's clear. Thanks! :-)
[08:48] <thomi> mardy: lots of people make that mistake, and we're making it clearer in newer versions of autopilot :)
[08:49] <thomi> the launch_app methods are there if you want to test how your application interacts with opther apps.... which is really useful if you happen to be testing a desktop shell =)
[08:49] <thomi> autopilot is showing it's lineage :)
[08:52] <thomi> mardy: It's getting late here, so I'm going AFK. If you run in to any other problems, feel free to dop me an email: thomi.richards@canonical.com
[08:52]  * thomi waves
[08:54] <mardy> thomi: mmm... just got one more question :-) Are my "print" statements eaten up somehow?
[08:58] <mardy> thomi: actually, it seems that launch_test_application() never returns
[09:08] <mardy> thomi: nevermind, I was missing libautopilot-gtk :-)
[09:12] <vrodic> why is ubuntu insiting on trying to ship outdated versions of mesa. 13.04 only has 9.0.3, but drivers in 9.2 are much better
=== ckpringle_ is now known as ckpringle
=== schmidtm_ is now known as schmidtm
=== ckpringle_ is now known as ckpringle
[09:36] <cjwatson> seb128: we seem to have a gnome-settings-daemon that breaks the current version of indicator-datetime, and no new indicator-datetime - do you know what's up with the latter?
[09:36] <cjwatson> looks like policykit-desktop-privileges and gnome-settings-daemon aren't currently coinstallable so image builds are failing as a result
[09:40] <seb128> cjwatson, yeah, cyphermox was supposed to autoland indicator-datetime to go with the other bits and didn't for some reasons :-(
[09:40] <seb128> cjwatson, I'm looking at it
[09:42] <cjwatson> seb128: thanks - can you let me know when it's landed so I can retry image builds, please?
[09:42] <seb128> cjwatson, will do, sorry about the issue
[09:43] <seb128> cjwatson, I overlooked that britney was not checking for installability to migrate stuff, when I uploaded I though it would stay in proposed until the breaks were resolved
[09:51] <cjwatson> seb128: it checks for installability, but not coinstallability of arbitrary sets
[09:51] <cjwatson> seb128: (which gets into the seriously NP-complete side of things, never mind being exception city :) )
[09:51] <seb128> cjwatson, was there any discussion about checking for installability of ubuntu-desktop?
[09:52] <pitti> isn't that pretty much what daily live fs builds do?
[09:52] <seb128> or (*)ubuntu-desktop
[09:52] <pitti> (installing ubuntu-desktop and telling us about failures)
=== ckpringle_ is now known as ckpringle
[09:52] <seb128> pitti, I was talking about plugging the result of that check in britney's migration
[09:53] <pitti> tricky; britney would take ages with that, I guess
[09:53] <cjwatson> seb128: we do check for installability of ubuntu-desktop
[09:53] <seb128> pitti, we broke daily iso with an uncomplete transition
[09:53] <cjwatson> seb128: we don't check for installability of the ubuntu-desktop *task* (i.e. including all Recommends)
[09:53] <cjwatson> you've fallen into the crack there
[09:54] <cjwatson> You can tell this because http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html doesn't show ubuntu-desktop as uninstallable
[09:55] <cjwatson> It might be worth generating some kind of per-task virtual packages that depend on everything in each task
[09:55] <cjwatson> Though we'd have to be careful about when the task changes
[09:56] <cjwatson> Or we could get proposed-migration to promote Recommends to Depends selectively or something ...
[09:56] <cjwatson> All seems fairly hackish but I suppose possible
[09:57] <seb128> yeah, I'm not sure what is best either...
[09:57] <seb128> cjwatson, I'm going to do a manual upload for indicator-datetime, utah seems to be out of order on the daily builds
[09:57] <seb128> e.g http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/183/label=autopilot-nvidia/console
[10:00] <cjwatson> seb128: got it, thanks
=== tkamppeter_ is now known as tkamppeter
[10:12] <mardy> pitti: any idea how I can introspect a GtkTreeView contents in autopilot? I don't see the "model" property there...
[10:12] <pitti> mardy: no, I don't; unfortunately autopilot-gtk is rather limited right now
[10:13] <mardy> pitti: OK, tough luck :-) I'll file a bug in the meantime, let's see how it goes...
[10:18] <seb128> cjwatson, indicator-datetime uploaded/built everywhere, I guess it just need to be published and to be moved to raring proper with gnome-settings-daemon and we should be ok for the iso
[10:19] <seb128> cjwatson, we will need systemd-services/systemd-shim promoted as well (MIR are approved, we just need to promote the binaries)
=== iainfarrell1 is now known as iainfarrell
[10:28] <cjwatson> seb128: ok, cool, I'll keep an eye on the hints
[10:28] <cjwatson> and I'll go and poke those MIRs
[10:33] <dholbach> pete-woods, AFAICT sphinx-voxforge-en looks good - it might be worth to put your comment (#10) from the bug report into either debian/copyright or debian/watch or maybe both to make it clear where the files are coming from and how they are constructed... also in case somebody else might want to update/fix the package and should not know how to go about it
[10:34] <dholbach> pete-woods, if you reupload the source package (or somewhere else) with that fix, you should just have to update the .dsc and .debian.tar.gz file - I can then upload it for you
[10:35] <pete-woods> dholbach: thanks for the review. I will put some more information in the debian/watch file - at the moment it doesn't mention the training tool I write
[10:35] <cjwatson> seb128: I can't find the MIR for systemd-services - can you point me at it?
[10:35] <pete-woods> *wrote
[10:35] <seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1152187
[10:35] <ubottu> Launchpad bug 1152187 in systemd (Ubuntu) "[MIR] systemd" [Undecided,Fix released]
[10:35] <seb128> cjwatson, comment #12 has the ack
[10:37] <seb128> cjwatson, and #14 from security
[10:48] <cjwatson> seb128: oh, it's closed, ok
[10:51] <cjwatson> seb128: moved all those to main now
[10:51] <seb128> cjwatson, thanks a lot
[10:56] <cjwatson> seb128: looks like it's been promoted now
[10:59] <seb128> cjwatson, good, I just got the launchpad emails that indicator-datetime and gnome-settings-daemon moved to raring
[11:55] <pete-woods> dholbach: did you see my comment on the sphinxtrain package? (https://bugs.launchpad.net/ubuntu/+bug/1144015)
=== MacSlow is now known as MacSlow|lunch
[11:55] <ubottu> Launchpad bug 1144015 in Debian "[needs-packaging] New package sphinxtrain" [Unknown,New]
[11:55] <pete-woods> it's not installable in the state in the bug tracker
[11:55] <pete-woods> I can't update it myself, as you already have extra changes in there
[11:56] <pete-woods> (also have learned by 0ubuntu1 lesson :) )
[12:17] <vibhav> Do we need a FFE for syncing ncpfs?
[12:19] <vibhav> http://packages.debian.org/changelogs/pool/main/n/ncpfs/ncpfs_2.2.6-9/changelog , if anyone wants to read the changelog
=== _salem is now known as salem_
[12:19] <vibhav> (the latest release fixes from critical bugs though)
[12:20] <tumbleweed> vibhav: the latest release has also been synced
[12:21] <tumbleweed> it's from november
[12:22] <vibhav> wierd, ubuntuwire still shows it.
[12:22] <vibhav> (must be update lag)
[12:22] <tumbleweed> probably because it's stuck in -proposed
[12:23] <vibhav> ah
[12:23]  * vibhav takes a look
[12:23] <vibhav> yes, it is
[12:23] <vibhav> tumbleweed: thanks
=== mmrazik is now known as mmrazik|afk
[12:24] <tumbleweed> vibhav: in fact, IIRC, I even commented about why it's stuck on the rcbugs page on ubuntuwire
[12:25] <tumbleweed> it looked non-trivial, but we should unstick it
[12:25] <vibhav> tumbleweed: yeah, I saw it
[12:44] <mlankhorst> oops
[12:44] <mlankhorst> can someone delete the xxv-modesetting upload I did? forgot to fixup distro
[12:45] <pitti> mlankhorst: where did you upload it to?
[12:45] <mlankhorst> precise-proposed
[12:46] <pitti> mlankhorst: seems someone already removed it, or the upload was rejected
[12:46] <pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[12:47] <mlankhorst> probably in new
[12:47] <mlankhorst> yeah
[12:54] <mlankhorst> I don't think precise had the modesetting driver :)
=== timchen`` is now known as timchen119
=== MacSlow|lunch is now known as MacSlow
[13:15] <cjwatson> mlankhorst: rejected from NEW
[13:16] <mlankhorst> ty
[13:19] <ogra_> xnox, for your switch back to metacity, dont we also need to seed it again ?
[13:20] <xnox> ogra_: don't think so. compiz uses libmetacity to draw decorators. so 2/3 binary packages from src:metacity was still on the cd anyway.
[13:21] <ogra_> just wanted to make sure ...
[13:22] <xnox> ogra_: and today's image wasn't build yet (due to respin with g-s & stuff) so will be testing once it lands.
[13:22] <ogra_> ++
[13:33] <leagris> Hey, hello
[13:34] <leagris> Themuso, I wanted to reach you if you have a little bit time to talk about Ubuntu low sight accessibility
[13:36] <cyphermox> seb128: tests failed, the autopilot vms exploded overnight, that's why it didn't land
[13:37] <seb128> cyphermox, ok, would have been nice to do a manual upload to unbreak installability of the desktop/cds
[13:37] <seb128> cyphermox, but no worry, we sorted it out this morning
[13:37] <cyphermox> would have been, but you asked and I was no longer around
[13:38] <cyphermox> sorted it how? is there something to merge back into indicator-datetime now?
[13:38] <leagris> For all, I have strong concerns if Compiz E-Zoom could dissapear in the next ubuntu releases (while dropping Xorg). EZoom is the best suited screen magnifier for my 10% signtness. Comparing to Gnome Orca magnifier or its KDE counterpart or even the closed source world. Ezoom is responsive, smooth, easy and work anywhere even with full screen applications.
[13:38] <seb128> cyphermox, I did a manual upload of lp:indicator-datetime/13.04 to raring
[13:39] <cyphermox> seb128: ok!
[13:39] <seb128> cyphermox, so I guess yes, we will need that merged back (or overwritten, I don't care much about the changelog entry)
[13:39] <dholbach> pete-woods, I'm not sure what this means......... is the bug fixed already?
[13:39] <cyphermox> seb128: yeah, I'll just merge it and it's going to be fine
[13:39] <seb128> cyphermox, thanks
[13:40] <seb128> cyphermox, the utah guys looked at their issue this morning and retried the tests, which failed because systemd-services was not promoted yet, I retried again
[13:41] <pete-woods> dholbach: sorry, I got my wires crossed and contacted the wrong person about it :$
[13:41] <dholbach> pete-woods, ok... no worries :)
[13:41] <cyphermox> it failed again in this case :)
[13:44] <seb128> cyphermox, indeed :-(
[13:45] <seb128> one day utah will work for more than 2 runs in a row
[13:45] <ogra_> wishful tinking :)
=== wedgwood_away is now known as wedgwood
=== kentb-out is now known as kentb
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
=== zyga-afk is now known as zyga
=== davidcalle_ is now known as davidcalle
=== rickspencer3_ is now known as rickspencer3
[18:05] <mlankhorst> slangasek: can I reassign bug 982889 to you?
[18:05] <ubottu> bug 982889 in lightdm (Ubuntu) "X trying to start before plymouth has finished using the drm driver" [Critical,Confirmed] https://launchpad.net/bugs/982889
[18:05] <slangasek> mlankhorst: if you wish... but I'd also be happy for you to follow through on it :)
[18:07] <mlankhorst> I don't trust myself touching upstart on other computers
=== psivaa is now known as psivaa_afk
=== rickspencer3_ is now known as rickspencer3
=== xxiao is now known as ausxxh
[19:16] <slangasek> why is update-manager upgrading packages that it's not showing me in the details list?
[19:16] <ScottK> It's an over achiever?
[19:16] <slangasek> ... specifically, packages that I'm hacking on locally and want to hold back but have not done a dpkg hold on, expecting update-manager to let me unselect them
[19:17] <xnox> slangasek: talk to mpt. It's the new design saying that "technical packages" are lumped together into "Core OS" item.
[19:17]  * xnox looks for the wiki / definition page.
[19:17] <slangasek> xnox: there's a "Base OS" pulldown that lets me see lots of packages... but not the ones I care about
[19:17] <slangasek> libdbus - listed.  libdecoration0 - not listed
[19:18] <slangasek> "Ubuntu base", it's called here
[19:18] <xnox> slangasek: https://wiki.ubuntu.com/SoftwareUpdates#Expanded_presentation_of_updates
[19:19]  * xnox upgrades using cmd-line only =/
[19:19]  * xnox ponders if I should be using the "normal" updates method
[19:23] <slangasek> xnox: yes; I assert that, even within the context of that design spec which I disagree with, the current behavior is buggy because I have no way at all to see and control the complete list of updates being installed
=== racarr is now known as racarr|lunch
[19:43] <blitzkrieg3> does anyone have a good way to test the timezone picker in ubiquity?
=== Lutin_ is now known as Lutin
=== G4MBY is now known as PaulW2U
=== salem_ is now known as _salem
=== Tonio_ is now known as Tonio_aw
[22:22] <xnox> blitzkrieg3: please explain more? to test what?
[22:23] <xnox> (it has geoip detection, visuals/timezone highlights, setting correct timezone for the target user, offline geoip-less mode)
[22:23] <xnox> it's actually a few things the meat of the timezone picket is libtimezonemap which is also used by gnome-control-center as the time picker.
[23:00] <KeithW> I am impressed that you guys synced mosh 1.2.4 and correctly reverted the appropriate commit to fix the FTBFS on armhf with no drama!
=== wedgwood is now known as wedgwood_away
[23:01] <coderanger> Anyone know if apt (10.04+) actually still uses the MD5 and SHA1 fields in repos?
[23:01] <coderanger> Guessing it is just crufty old stuff and everything hopefully uses the sha256 sums now, but I've not looked into the apt source
[23:01] <sarnold> coderanger: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738
[23:01] <ubottu> Launchpad bug 1098738 in apt (Ubuntu) "apt-get source only checks md5 hashes in Sources files" [High,In progress]
[23:01] <coderanger> sarnold: I haz a sad now
[23:02] <coderanger> Will include all of them then, thanky
[23:02] <infinity> KeithW: Oh, I was going to make drama for you, but you weren't online. :P
[23:03] <KeithW> infinity: Haha, well, impressive! We just pushed 1.2.4a to Debian to do the same thing.
[23:04] <infinity> KeithW: Didn't feel like fixing the broken test code instead?  The revert was just the path of least resistance for me. :P
[23:04] <KeithW> We already had our own end-to-end test of OCB with the same test vectors in src/tests, so it didn't seem worth it. The real problem was that the built-in ocb.cc test doesn't even give a bad return code on failure, so it wasn't even working for us as an automated test!
[23:05] <infinity> KeithW: Hah.  Smooth.
[23:05] <infinity> KeithW: Alright, I'll resync 1.2.4a-1 over my upload later, then.  After I've seen it build on all the Debian buildds.
=== Tonio_aw is now known as Tonio_
[23:05] <infinity> KeithW: (Which I should have checked before doing the sync for you before, mea culpa)
[23:06] <KeithW> Ok, I think your existing 1.2.4 is fine (the only relevant changes in 1.2.4a warnings on RHEL 5 and ARM/MIPS/s390 that failed the build), but also fine if you want to sync it.
[23:07] <KeithW> Er, the only changes in 1.2.4a are to fix build warnings.
[23:07] <infinity> Oh, I'm sure mine's fine, I'd just sync it to get it off my plate, so it autosyncs correctly again later.
[23:08] <infinity> (We don't autosync packages with Ubuntu changes, for obvious reasons)
[23:08] <KeithW> Oh, ok. Sounds good.
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
=== Tonio_ is now known as Tonio_aw
[23:30] <xnox> Mirv: when are you planning to upload qt5 again? I really want the Gtk theming fix in, but there are a few more things stagged in the bzr branch.
[23:31] <ScottK> xnox: What and is it upstream?
[23:32] <xnox> ScottK: don't panic. We missded -gtkstyle & libgtk2.0-dev build-dep in qt5 package vs qt4 package, hence gtk theming support didn't build and right now qt5 hello world app looks like it's from 1987
[23:32] <ScottK> OK.
[23:32] <ScottK> What are the few more things?
[23:32] <sarnold> (can we keep that as an option? :)
=== Tonio_aw is now known as Tonio_
[23:34] <xnox> ScottK: see unreleased stanza: https://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/view/head:/debian/changelog
[23:34] <xnox> ScottK: also do you have highlight on my nick or just on "qt" ? =)
[23:41] <ScottK> Just happend to notice.
[23:42] <ScottK> OK.  Not too scary.