[00:18] <Plouj> Iiinteresting.
[00:18] <Plouj> Release.gpg exists in /var/lib/apt/lists/ _until_ I run do-release-upgrade.
[00:19] <Plouj> And the extra ---- GPG stuff creeps into Release on the client. The server doesn't have it (as expected).
[00:19] <Plouj> perhaps do-release-upgrade is broken in Lucid
[00:22] <sarnold> Plouj: does just 'apt-get update' do that?
[00:35] <Plouj> sarnold: no
[00:35] <Plouj> not from a fresh install, at least
[01:20] <BenC> infinity: linux-ppc coming in 5 minutes
[01:24] <infinity> BenC: Cool, sagari's all yours.
[01:24] <infinity> BenC: Did you manage to get anyone from IBM or Freescale (or elsewhere) to bite on the importance of a V8 port, by the way?
[01:25] <BenC> infinity: it's been brought up at some high level discussions...
[01:25] <infinity> BenC: chrome and nodejs were bad enough, but losing fundamental bits of QT5 as well is getting a bit ridiculous.
[01:25] <BenC> waiting to see how that pans out
[01:25] <BenC> infinity: Ick, I hadn't heard about QT5+v8
[01:25] <BenC> That's sub par for sure
[01:26] <infinity> Maybe this will finally spur someone to do a generic C port or something.
[01:31] <BenC> infinity: upload away...
[01:34] <cjwatson> a/wg 66
[01:34] <cjwatson> oops
[01:47]  * infinity eyes component-mismatches suspiciously.
[01:55] <cjwatson> That is a bit odd.  Regression from the latest commit?  I can't see why, though.
[02:09] <infinity> cjwatson: Talking about c-m's kernel hatred, or something else?
[02:12] <infinity> cjwatson: Oh, I see.  It learned about pockets.  Not immediately obvious why that would break udebs, though.
[02:16] <infinity> +        if options.suite != pocket:
[02:16] <infinity> +            suite = "%s-%s" % (options.suite, pocket)
[02:16] <infinity> +        else:
[02:16] <infinity> +            suite = options.suite
[02:17] <infinity> Isn't that always going to rewrite raring to raring-release?
[02:18] <infinity> Or to "raring-", perhaps?  I dunno.
[02:25] <infinity> Oh, no.  Hrm.
[04:07] <Mirv> mhall119: the ubuntu-ui-toolkit uploads have been prepared for automation, but the automated uploads will probably be only enabled after S begins. we need to figure out whether we upload 0.1.40 to raring or even newer.
[05:50] <didrocks> xnox: slangasek: not sure how you deal with your WI on the fundation team, but please, do not set them to "DONE" when there are still some work to do on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVVX1BOYm1qdUtyX2xUNmdwWlhTS0E#gid=0 in term of tests
[05:51] <didrocks> xnox: should I revert your WI on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-delivering-touch-apps-to-raring so that we have a real view of what's need to be done?
[06:23] <infinity> ...
[06:23] <infinity> I just upgraded and rebooted and my global menus are gone.
[06:24] <lifeless> infinity: \o/ ?
[06:25] <infinity> lifeless: Well, given that 99% of my windows are terminals, and I just turned the menu off instead, I don't care much, but I imagine it points to a bug somewhere. :P
[06:25] <infinity> didrocks: ^-- Thoughts?
[06:26] <didrocks> infinity: I didn't restart since my upgrade, but seeing that only Unity was reviewed in the last 24 hours (we still have a lot of things stuck in unapproved…), I doubt there is a change
[06:26] <didrocks> let me try a guest session
[06:26] <infinity> didrocks: I haven't rebooted in about a month, so I'm not really the best bisection candidate.
[06:26] <sarnold> infinity,didrocks: https://bugs.launchpad.net/bugs/1165436
[06:26] <infinity> didrocks: But all my menus have gone application-local.
[06:26] <didrocks> sarnold: no access to it
[06:26] <sarnold> *sigh* moment..
[06:27] <infinity> Scratch that.  All my gtk3 menus, maybe?  Firefox's is still global.
[06:27] <didrocks> infinity: you did try gedit or something like that?
[06:27] <sarnold> infinity,didrocks fixed..
[06:27] <infinity> didrocks: gedit, pidgin, gnome-terminal: all local menus.  firefox: global.
[06:28] <didrocks> sarnold: not really helpful but report :/
[06:28] <sarnold> the auto-translation is supremely rough, but it sounds like the same problem to me.
[06:28] <infinity> sarnold: Oh, I was hoping that bug would be informative. :P
[06:28] <sarnold> didrocks: hehe, yeah, it -does- lack a bit in details.
[06:29] <sarnold> infinity: it does add one bit of data though -- it's not just you :)
[06:29]  * infinity wonders if he has anything QTish installed to confirm this "only gtk3" suspicion.
[06:29] <pitti> Good morning
[06:29] <didrocks> hey pitti
[06:30] <RAOF> Hey pitti!
[06:30] <didrocks> dkms running…
[06:30] <infinity> Hrm, no, mumble is QT and it's also got local menus.
[06:31] <infinity> So firefox is just special?
[06:31] <infinity> Oh, wait, it does global menus differently, doesn't it?
[06:31] <StevenK> Firefox has a plugin for it
[06:32] <didrocks> infinity: justr tried a guest, working and restarted my own session, still working
[06:32] <pitti> tjaalton: can do; do you know of some demo program that also exercises that particular effect (blur?) which upstream may have for reproducing?
[06:32] <infinity> *grump*
[06:33] <infinity> didrocks: Is there a sane way to trace what might be going on here?
[06:33] <didrocks> infinity: it's weird you are getting firefox though, because this would mean /usr/lib/x86_64-linux-gnu/indicator-application-service is running
[06:33] <infinity>  2690 ?        Sl     0:00 /usr/lib/x86_64-linux-gnu/indicator-application-service
[06:33] <didrocks> as well as /usr/lib/unity/unity-panel-service
[06:33] <infinity> Indeed it is.
[06:34] <infinity> Not that I know what that means.
[06:34] <didrocks> infinity: do you have the same in a guest?
[06:34] <tjaalton> pitti: I've filed it already: https://bugs.freedesktop.org/show_bug.cgi?id=63283
[06:34] <pitti> tjaalton: ah, thanks
[06:34] <tjaalton> pitti: not sure about the demo, I'll check
[06:34] <infinity> didrocks: I don't have the guest account enabled.  Would take some violence to test that.
[06:35] <didrocks> infinity: as you are never rebooting, you maybe have some dbus protocol mismatch, but in the last day, only unity change and nothing close to that code
[06:35] <didrocks> infinity: I would be interested in a new session test
[06:35] <infinity> didrocks: But I'll hazard a guess that if it doesn't happen for you, it also wouldn't for me.
[06:35] <infinity> didrocks: I never reboot, until today.  Which is when I saw it.
[06:35] <pitti> tjaalton: subscribed, thanks; I can test patches
[06:36] <tjaalton> pitti: nice. no news on that front yet I'm afraid :)
[06:36] <didrocks> infinity: I'm still puzzled that firefox is working for you…
[06:36] <infinity> didrocks: It's the only thing that is...
[06:37] <infinity> Oh, and LibreOffice too.  Just tested.
[06:37] <infinity> But same story there, right?  Firefox and LibreOffice both do global menus via different paths than "normal" applications, right?
[06:38] <didrocks> well, they have different hooks
[06:38] <didrocks> but the unity part is the same
[06:39] <didrocks> so I would guess you have something in your gtk3 and qt patches
[06:39] <infinity> Okay, more confusion.
[06:39] <infinity> About Computer gives me global menus.
[06:39] <infinity> That didn't really match the pattern.
[06:40] <didrocks> yeah, it's gnome-control-center which is a gtk3 application
[06:40]  * infinity scratches his head.
[06:40] <infinity> Yeah, hence the confusion.  Should behave the same as gnome-terminal and pidgin, one would assume.
[06:40] <infinity> And gedit.
[06:40] <infinity> And it doesn't.
[06:40] <infinity> Argh.
[06:41] <infinity> didrocks: I can try a clean session in a sec, but if that works (and it probably does), there's something very strange going on here in some profile/settings upgrade...
[06:42] <didrocks> infinity: there is nothing to do with any settings or profile written anywhere, that's why I'm puzzled
[06:43] <didrocks> it's just a gtk appmenu plugin which is loaded if on the disk…
[06:44]  * infinity adds a new user and logs out.
[06:47] <infinity> didrocks: Huh.  Fresh user, same problem.
[06:47] <didrocks> interesting, and gnome-control-center is still showing the exported menu?
[06:47] <infinity> didrocks: So, apart from disabling guest, the only other GUI-related tweak I've done on a system level is disabling overlay scrollbars.  I can't imagine that would have such a strange effect, though?
[06:48] <didrocks> infinity: I doubt it would impact it, but that's interesting, because both applications don't use the same GTK API
[06:48] <infinity> didrocks: Yeah, g-c-c and firefox still DTRT, gnome-terminal and gedit not.
[06:48] <didrocks> infinity: you do have the global menu for nautilus?
[06:48] <infinity> didrocks: nautilus is global.
[06:48] <didrocks> ok, so you "only" don't have them for the apps using appmenu-gtk3 library
[06:49] <didrocks> infinity: I bet appmenu-gtk3 is installed, right?
[06:49] <infinity> It sure isn't.
[06:49] <didrocks> oh?
[06:49] <didrocks> well, that's your answer though
[06:49] <didrocks> then*
[06:50] <infinity> (base)adconrad@cthulhu:~$ reverse-depends appmenu-gtk3
[06:50] <infinity> Reverse-Recommends
[06:50] <infinity> [06:50] <infinity> * indicator-appmenu
[06:50] <infinity> * kubuntu-desktop
[06:50] <infinity> * kubuntu-full
[06:50] <infinity> That doesn't seem like it would pull it in...
[06:50] <infinity> And certainly not guarantee it.
[06:50] <didrocks> infinity: indicator-appmenu is installed by default, isn't it?
[06:51] <didrocks> it recommends all the qt and gtk bindings
[06:51] <infinity> Yes, and installed.  And I generally upgrade with recommends, but there may have been resolver pain that caused it to not get installed.
[06:51] <infinity> The only one I have installed is appmenu-qt5
[06:51] <didrocks> infinity: possible, well, rather something which removed it I guess :)
[06:52] <didrocks> ok, you need the 3 others for gtk2, 3, qt4
[06:52] <didrocks> (gtk3 without)
[06:52] <didrocks> (gtk3 without the new GNOME api)
[06:52] <didrocks> which is the case for gnome-terminal and gedit for instance
[06:52] <infinity> I'm not the only person this happened to, so there must be a bit of a hiccup here.
[06:52] <didrocks> yeah, once some people are making upgrade testing, I'll look at that closely
[06:53] <infinity> Doesn't jibel run upgrade testing constantly now?
[06:53] <didrocks> infinity: you need to logout/login back or export UBUNTU_MENUPROXY="libappmenu.so" to your apps for having the library loaded
[06:53] <infinity> Anyhow, installed the lot here.
[06:53] <didrocks> (it's in /etc/X11/Xsession.d/80appmenu-gtk3)
[06:53] <infinity> I'll log out. :P
[06:54] <didrocks> ok ;)
[06:59] <infinity> didrocks: So, yeah.  All fixed.  But clearly not a happy upgrade.
[07:00] <didrocks> infinity: yeah, would be interesting so see what upgrade path concluded to removing those modules, especially as there is no particular conflicts/breaks against them AFAIK
[07:02]  * infinity goes crosseyed reading apt history logs.
[07:03] <infinity> didrocks: So, it's pooooossible I did this to myself.
[07:04] <didrocks> infinity: oh? you hated them? and forgot about it? :p
[07:04] <infinity> didrocks: No, I think I was going on an "autoremove doesn't remove enough crap" rampage, judging from my apt history.
[07:04] <didrocks> ah, here we go ;-)
[07:04] <infinity> And they got caught in the crossfire. :P
[07:04] <didrocks> heh
[07:05] <infinity> Doesn't explain the entertainingly-worded bug, but it explains mine.
[07:05] <didrocks> infinity: oh, I know why it's working for g-c-c and nautilus
[07:05] <didrocks> infinity: it's because, GNOME has a new "global menu API"
[07:05] <didrocks> and we hook into it
[07:05] <didrocks> not all apps transitionned to it though
[07:05] <infinity> Ahh.
[07:05] <didrocks> but for those, it's built-in gtk3
[07:06] <didrocks> no need for a 3rd party module
[07:28] <dholbach> good morning
[07:39] <zyga> good morning
[07:40] <tjaalton> bad usb-creator
[07:41] <tjaalton> fails to empty a usb-stick with raring installer on it
[07:43] <zyga> tjaalton: is it using udisks1?
[07:44] <tjaalton> zyga: looks like it, and the error seemed udisks-y
[07:45] <zyga> tjaalton: I mean udisks1 vs udisks2
[07:45] <tjaalton> it depends on udisks, not udisks2
[07:45] <zyga> tjaalton: I wonder if that is caused by the fact that gvfs is using udisks2 and certain events are no longer emitted through udisks1 dbus
[07:45] <zyga> tjaalton: right
[07:47] <tjaalton> so it didn't get ported, and is installed by default
[07:48] <zyga> yes
[07:48] <zyga> it could still work fine
[07:48] <zyga> since udisks1 still works fine
[07:48] <zyga> but there are some subtle differences in behavior
[07:49] <zyga> just because other pieces of the desktop use udisk2 instead of udisks1
[07:52] <tjaalton> it's bug 1160035
[08:00] <tjaalton> actually no, my error is different
[08:02] <jibel> doko_, hey, could you have a look at bug 1165172
[08:34] <xnox> didrocks: platform-api is in the daily landing PPA. Sensors are not yet. I've set them to DONE/INPROGRESS. Or do you want them both INPROGRESS?
[08:36] <xnox> @pilot in
[08:37] <didrocks> xnox: I would like INPROGRESS if possible, I added some coments to the spreasheet ;)
[08:37] <didrocks> xnox: so that DONE really means "nothing else to be left to do"
[08:37] <didrocks> xnox: do you mind answering to my questions on the spreadsheet between 2 sponsosrings?
[08:41] <xnox> didrocks: spreadsheets have comments =) ok will asnwer them.
[08:41] <didrocks> thanks!
[09:47] <m_3> does pbuilder safely survive a laptop suspend in raring?
[09:48] <mlankhorst> why wouldn't it?
[09:48] <m_3> it seems fine, just kept chugging along... wondering if I should suspect the build
[09:48] <lifeless> m_3: do you mean a pbuilder build in progress? Should be fine
[09:48] <m_3> mlankhorst: dunno, just never suspended with it before and was windering
[09:48] <m_3> cool
[09:48] <m_3> thanks!
[09:48] <mlankhorst> if your system survives a suspend, userspace should not notice a thing from suspend
[09:50] <m_3> ack
[09:50] <lifeless> time skew + network going away and returning
[09:50] <lifeless> quite noticable if anything is looking for it - but nothing should be
[09:50] <mlankhorst> time skew is forward time skew, though
[09:50] <lifeless> yes
[09:50] <mlankhorst> and network outage can happen without suspend too
[09:51] <lifeless> yup
[09:51] <lifeless> just saying, it is noticable if anything cares
[09:52] <mlankhorst> meh personally I do echo mem > /sys/power/state; /etc/init.d/fancontrol restart
[09:53] <mlankhorst> I keep hoping that nouveau survives, I haven't nailed down why it doesn't yet :(
[10:06] <rbasak> When debian/source/options contains single-debian-patch, is it acceptable to remove that file to introduce an Ubuntu delta?
[10:10] <zyga> pitti: ping
[10:10] <pitti> hello zyga
[10:10] <zyga> pitti: is this section of the upstart cookbook no longer accurate after we moved to logind: http://upstart.ubuntu.com/cookbook/#run-a-job-when-a-user-logs-in
[10:10] <zyga> pitti: it mentions start on dbus-activation org.freedesktop.ConsoleKit
[10:11] <mlankhorst> rbasak: why would you want to?
[10:11] <pitti> zyga: indeed; but that seems wrong even now
[10:11] <rbasak> mlankhorst: to keep the Ubuntu delta in a separate patch, so it's easier to merge in future?
[10:11] <zyga> pitti: ah, I thought so
[10:11] <pitti> consolekit is being called/used way before the first user logs in
[10:11] <mlankhorst> oh sure
[10:12] <pitti> zyga: one needs to actually listen for CK's/logind's signals for new sessions, or query for current sessions, not just check when the service gets activated
[10:12] <mlankhorst> though can't you just explicitly create ubuntu patches for the delta?
[10:12] <zyga> pitti: I think the actual answer is 'it depends and it is complicated'
[10:12] <zyga> pitti: the cookbook should be corrected though, it can lead people to do wrong stuff
[10:12] <rbasak> mlankhorst: I did but dpkg-source squashed them into the single patch and then the build got confused by trying to double apply it. Removing single-debian-patch from source/options fixes that problem
[10:12]  * zyga tries to recall james hunt's IRC nickname
[10:13] <rbasak> zyga: jodh
[10:13] <mlankhorst> ah
[10:13] <zyga> thanks
[10:13] <zyga> jodh: hey
[10:14] <jodh> zyga: hi
[10:14] <zyga> jodh: pitti and I think that one section of the upstart cookbook is incorrect
[10:15] <jodh> zyga: feel free to raise a bug with details.
[10:15] <zyga> jodh: thanks
[10:16] <zyga> jodh: do you know of a way to start a job after a server is initialized, is that also runlevel=2 in practice?
[10:16] <zyga> brendand: ^^
[10:17] <jodh> zyga: http://upstart.ubuntu.com/cookbook/#normal-start
[10:18] <zyga> thanks
[10:19] <zyga> pitti, jodh: reported as https://bugs.launchpad.net/upstart-cookbook/+bug/1166708
[10:19] <jodh> zyga: thanks
[10:20] <pitti> zyga: FYI, we didn't move to logind yet (denied FFE)
[10:20] <brendand> jodh, will that guarentee that a network connection is in place when the job starts?
[10:20] <brendand> jodh, i.e. what are 'basic' services
[10:20] <zyga> pitti: oh, too bad
[10:21] <zyga> pitti: well, -s is just a few moments away
[10:21] <zyga> pitti: -s will be pretty cool I think
[10:21] <pitti> yeah, I plan to do the migration on the sprint, when I can get a hold of Robert for logind, etc.
[10:21] <jodh> brendand: runlevel gets emitted after the last static i/f is up. I admit it's a bit terse, but this is all documented in upstart-events(7).
[10:23] <brendand> jodh, so using 'start on (local-filesystems and net-device-up IFACE!=lo)' is okay?
[10:23] <jodh> brendand: maybe this should be discussed on #upstart? What are you actually truing to do?
[10:25] <xnox> brendand: the fact that network is up, configured and one has ipaddress does not mean one can access the internet though...
[10:26] <brendand> xnox, we don't need to access the internet :)
[10:26]  * brendand moving this to #upstart
[11:25] <pitti> xnox: I uploaded a fixed apturl for bug 1103024 now
[11:26] <pitti> seb128: do you see any reason to keep ubuntu-system-service in raring?
[11:26] <xnox> pitti: interesting, thanks. i will have a look.
[11:27] <seb128> pitti, not if we don't "fix" gnome-control-center to add back the "set proxy" feature
[11:27] <pitti> oh, right
[11:27] <pitti> "apt-cache rdepends ubuntu-system-service" doesn't have any remaining depends any mroe
[11:29] <seb128> pitti, right, and the archive grep didn't return anything else using the dbus api
[12:37] <mdeslaur> I thought we discouraged the use of aptitude on ubuntu...but I can't seem to find a relevant link...am I remembering wrong?
[12:39] <tumbleweed> it was broken in the early multi-arch days, but should be fine again now
[12:41] <mdeslaur> I seem to recall something about it not using the same dependency resolver, so it would do funny stuff on Ubuntu
[12:42] <tumbleweed> it has its own dependency resolver, yes
[12:42] <tumbleweed> but if it does "funny stuff" those are bugs
[12:54] <xnox> mdeslaur: I am an avid ex-user of aptitude, I stopped using it when multiarch landed.
[12:55] <xnox> mdeslaur: I remember during squeeze release somebody was doing upgrade tests with apt-get and aptitude and the two upgrades were not the same =/
[12:57] <tkamppeter> pitti, hi
[12:57] <pitti> hello tkamppeter
[12:57] <mdeslaur> xnox: I guess I'm misremembering an official stance on it
[12:58] <tkamppeter> pitti, do you have any idea what is happening with this bug: bug 1157972?
[12:59] <pitti> the apport-collect was rather unhelpful
[12:59] <pitti> tkamppeter: but /etc/cups/printers.conf isn't even a conffile, so unless you added something to the postinst that would replace it, I have no idea
[12:59] <pitti> the description of the bug is rather vague
[12:59] <tkamppeter> pitti, the user tells that his conffiles are overwritten without any backup and AFAIK dpkg always takes backups. The only place in the maintainer scripts where conffiles are actually removed is the purge section of postrm.
[13:00] <pitti> tkamppeter: printers.conf isn't handled by dpkg, it's not a conffile
[13:00] <tumbleweed> xnox: same, also used to be an avid aptitude user. use it a lot less now. but of course the upgrades aren't going to be the same - the dependency problem is non-trivial...
[13:00] <tkamppeter> pitti, and how can the update remove it then?
[13:01] <pitti> tkamppeter: as I said, no idea
[13:01] <tkamppeter> pitti, (assuming that the purge section of postrm is not called on update).
[13:03] <tkamppeter> pitti, as I have already checked the maintainer scripts that they do not touch printers.conf (except purge) it seems that I can safely ignore this bug as being noise.
[13:03] <pitti> tkamppeter: yes, I think so
[13:03] <xnox> @pilot out
[13:05] <tkamppeter> pitti, another mysterium for me is that an update to a newer Ubuntu release removes cups-pdf (bug 987026). cups-pdf is not necessarily needed due to PDF output facilities already integrated in most desktop apps, but if a user installs it, it should stay on his system.
[13:06] <tkamppeter> pitti, and there are no conflicts with cups-pdf defined in other packages, as the user can simply re-install cups-pdf.
[13:08] <OdyX> tkamppeter, pitti : printers.conf disappears on cups downgrades.
[13:08] <OdyX> tkamppeter, pitti: saw that but as we don't support downgrades, I've never investigated.
[13:09] <pitti> so perhaps its the daemon itself which removes printers.conf if it deems it incompatible?
[13:09] <tkamppeter> OdyX, pitti, can it be that purge is called during a downgrade?
[13:09] <pitti> tkamppeter: that needs /var/log/dist-upgrade/ logs for debugging
[13:10] <OdyX> tkamppeter: no: http://wiki.debian.org/MaintainerScripts#Downgrading
[13:11] <tkamppeter> OdyX, pitti, if the daemon removes printers.conf (or any other conffile) this would be a severe upstream bug. This should get reported upstream.
[13:15] <tkamppeter> OdyX, you should check error_log (in debug mode) to see whether CUPS tells there why it is removing print queues or why it is removing printers.conf altogether.
[13:17] <tkamppeter> OdyX, perhaps bug 1157972 is the same problem.
[13:24] <jamespage> pitti,is it possible to configure apport to report bugs for packages from alternative sources to a specific launchpad project?
[13:25] <pitti> jamespage: yes, quite a lot of packages do that
[13:26] <pitti> jamespage: see /usr/share/doc/apport/package-hooks.txt.gz (CrashDB field), and e. g. /usr/share/apport/package-hooks/source_linux-nexus7.py as an example
[13:27] <pitti> jamespage: you can also make a package hook which sends ubuntu reports for packages from ubuntu, and to an LP project if it comes from e. g. a PPA
[13:28] <jamespage> pitti, I think its that second example I need; specifically I want to report bugs to the cloud-archive project for packages that come from http://ubuntu-cloud.archive.canonical.com/
[13:39] <pitti> ogasawara: don't make it too easy to contribute to the kernel, lest I may lose my fear completely :)
[13:39] <ogasawara> pitti: :)
[13:52] <mpt> tvoss, hi, I see you're the drafter of <https://blueprints.launchpad.net/ubuntu/+spec/client-1303-location-service>
[13:53] <tvoss> mpt, yup
[13:54] <mpt> tvoss, in the description of the code I see mention of GPS. Would/will it use locations of wi-fi hotspots and cell tower locations as well?
[13:54] <tvoss> mpt, it uses arbitrary location providers, but the client does not know about the actual provider
[13:54] <mpt> tvoss, I don't know what that means, sorry
[13:54] <mpt> What's a location provider?
[13:57] <tvoss> mpt, gps, is a location provider, a wifi hotspot, glonass etc.
[13:57] <tvoss> mpt, does that impact design?
[13:58] <mpt> tvoss, yes, it affects the text. For example, whether we need to tell people that location will be less accurate when wi-fi is off.
[13:58] <xnox> tvoss: will it tell the client precission? e.g. you are in london +/- 1km radius vs London Big Ben +/- 15m
[13:59] <tvoss> mpt, hmmm, the text inside applications?
[13:59] <mpt> tvoss, no, in the System Settings panel.
[14:00] <mpt> Which I'm working on right now. :-)
[14:01] <tvoss> xnox, that depends on the application, we will provide location updates, heading, velocity, and accuracies, plus geocoding capabilities
[14:01] <mpt> tvoss, I think you're using "accuracies" for what xnox meant by "precision"
[14:02] <mpt> ?
[14:02] <jamespage> pitti, figured it out - thanks for the pointers
[14:02] <xnox> mpt: yes. and accuracy is more correct term anyway =)
[14:03] <tvoss> mpt, ack, and for the system settings: As the list of location sources is not fixed, we would need to account for that, too, I guess
[14:03] <tvoss> mpt, do you have a draft for the ui?
[14:04] <mpt> tvoss, what do you mean by "fixed"? Do you mean "decided yet", or "the same all the time"?
[14:04] <tvoss> mpt, the same all the time/might differ per device
[14:05] <mpt> tvoss, as I say, I'm working on it right now.
[14:05] <tvoss> mpt, okay
[14:09] <jamespage> pitti, do you think my changes would be an acceptable SRU for apport in precise? I'm just defining a new crashdb and general-hook
[14:12] <sconklin> @pilot in
[14:46] <dobey> dpm_: hey, i have a second mail that was in moderation that i sent last night after you went away. could you let it through?
[14:46] <dobey> dpm_: also, is there anyone else that can moderate that list, so i can poke them instead when you aren't around? :)
[14:48] <dpm> dobey, done
[14:49] <dobey> dpm: gracias
[14:49] <dpm> dobey, I'm thinking of sharing the moderation with other members of the translations community, but those who'd be good candidates are in similar time zones as I am
[14:49] <dpm> dobey, for now I'll whitelist you
[14:50] <dobey> dpm: ah ok, thanks
[14:50] <dpm> if someone has got a suggestion on how I can add a couple of filters to mailman for @ubuntu.com or @canonical.com e-mail addresses, I'd add those, which would make things easier
[14:51] <dobey> maybe barry knows something :)
[14:51]  * barry is sure he knows... something ;)
[14:52] <barry> dpm: yes, you can whitelist all @ubuntu.com or @canonical.com, but you have to do it on a per-list basis
[14:52] <barry> dpm: go to Privacy options->Sender filters
[14:52] <dpm> barry, that's exactly what I want, I just want to whitelist those addresses on the ubuntu-translators list
[14:53] <barry> dpm: then scroll down to accept_these_nonmembers
[14:53] <barry> dpm: enter this on one line:
[14:53] <barry> dpm: er, let's make that two lines:
[14:53] <barry> .*@ubuntu.com
[14:53] <barry> .*@canonical.com
[14:53] <barry> shoot, wait
[14:53] <barry> it's:
[14:53] <barry> ^.*@ubuntu.com
[14:53] <barry> ^.*@canonical.com
[14:54] <barry> (the leading ^ tells mm that what follows is a python regexp)
[14:54] <roaksoax> slangasek: howdy! I was wondering if MAAS was gonna be accepted into -proposed for verification
[14:54] <dpm> barry, ah, before there was:
[14:54] <dpm> ^.@ubuntu.com
[14:54] <dpm> ^.@canonical.com
[14:55] <dpm> that might be why it didn't work
[14:55] <dobey> ah someone forgot the *
[14:55] <barry> dpm: unless x@canonical.com posted :)
[14:55] <dobey> yeah
[14:55] <dpm> :-)
[14:55] <barry> ^.+@canonical.com might also work better
[14:56] <dpm> ok, I've used that, then
[14:57] <barry> cool
[14:57] <dpm> thanks barry and dobey!
[15:42] <doko> rbasak, heh, nice, first use of the powerpc cross compiler =)
[15:44] <tjaalton> pitti: if you're still around, there's a mesa build I did with one revert http://koti.kapsi.fi/~tjaalton/mesa
[15:44] <stokachu> xnox: i've got a few bugs needing a little attention could i paste them for you?
[15:44] <tjaalton> pitti: looks like it's working just as fine on snb as with the 19 upstream patches the previous one had..
[15:45] <xnox> stokachu: ok, paste away here. And we can discuss them =)
[15:45] <stokachu> xnox: cool thanks
[15:46] <stokachu> bug 1013798, bug 857983, bug 1068399, bug 1158465, bug 859600, bug 1069570
[15:47] <stokachu> and bug 1027086
[15:47] <stokachu> bug 1069570
[15:51] <xnox> stokachu: about azure - upload utlemming's branches?
[15:51] <stokachu> xnox: yea
[15:51] <stokachu> xnox: i didnt think there was anything formal really for azure stuff
[15:52] <stokachu> im going to have those guys apply for per package rights on azure in the near future
[15:52] <xnox> stokachu: as in, there are no debdiff nor merge proposals => thus nothing to sponsor =)
[15:52]  * xnox skipped though it during piloting.
[15:53] <xnox> stokachu: for libgcrypt "bug" only python-gnutls is needed and libgcrypt says the same across the board?
[15:53] <stokachu> xnox: yea we should remove the libgcrypt being affected
[15:54] <xnox> stokachu: that's fine, I'll mark it invalid then.
[15:54] <stokachu> cool, that one needs to be uploaded as well
[16:07] <stokachu> micahg: are you still actively handling backports?
[16:25] <pitti> tjaalton: ah, that somehow removes gstreamer1.0-plugins-bad, but not a biggie
[16:26] <pitti> tjaalton: testing now
[16:29] <pitti> tjaalton: it seems a tad faster than the PPA version, and a tad slower than the raring version
[16:31] <pitti> good night everyone
[16:33] <stokachu> xnox:  bug 778627 has verification-done how longs does it usually take for it to make it into -updates?
[16:34] <seb128> pitti, 'night
[16:41] <xnox> stokachu: http://people.canonical.com/~ubuntu-archive/pending-sru.html so stuff that is green and still in proposed should be promoted to -updates, but it's manual step done by SRU team.
[16:42] <stokachu> ok
[16:42] <Riddell> chrisccoulson: ping
[16:43] <Riddell> chrisccoulson: bug 1165408 is annoying but an easy fix
[16:48] <stokachu> bdmurray: do you have some time to push bug 778627
[16:50] <stokachu> bdmurray: and bug 1162876 :)
[16:52] <cjwatson> I'll release that now
[16:52] <cjwatson> Well, no, not apt-cacher-ng, it's far too young
[16:52] <bdmurray> stokachu: yes, however apt-cacher-ng has not been available for more than 7 days
[16:52] <cjwatson> Generally bugs must age for ... what he said
[16:52] <stokachu> ah ok
[16:52] <cjwatson> Doing bash now
[16:52] <stokachu> cjwatson: excellent thank you!
[16:53] <cjwatson> Looks like we'd got a bit behind on releasing to -updates
[16:54] <stokachu> yea ive been pinged more times than normal on some of them
[16:56] <stokachu> bdmurray: re: bug 1013798 do you have an eta of when you'd be able to look that over?
[16:59] <stokachu> stgraber: re: bug 1057358 do you have an eta when this will be addressed?
[17:06] <bdmurray> stokachu: I was on vacation most of last week, I'll get to it today or tomorrow
[17:09] <stokachu> bdmurray: ok cool
[17:16] <tjaalton> pitti: hmm ok.. but sounds like an improvement and not that bad than stock 9.1.1
[17:17] <tjaalton> pitti: actually it's probably way better than stock 9.1.1, the ppa one had one additional branch that fixed it for SNB
[17:19] <stokachu> seb128: i appreciate all your hard work :) would you mind adding bug 859600 to be sponsored? :P
[17:20] <stokachu> seb128: add to your todo list i mean
[17:44] <ogra_> lol
[17:44] <ogra_> http://lists.debian.org/debian-devel/2013/04/msg00337.html
[17:44] <ogra_> thats hilarious ...
[17:44] <ogra_> package roulette
[17:45] <ogra_> xnox, we should actually ship it now that i read that mail ... but definitely in "section: games"
[17:45] <geser> ogra_: catching up with Debian mails? :)
[17:46] <ogra_> geser, well, someone proposed inclusion of (and eventually a switch to) aptitude by default on ubuntu-devel-discuss ... that thread came up in the discussion
[17:50] <slangasek> ogra_: heh, I assumed you were referring to the /earlier/ package roulette thread
[17:50] <slangasek> https://lists.debian.org/debian-devel/2013/04/msg00000.html
[17:50] <ogra_> lol
[17:53] <seb128> stokachu, hey, I can try having a look but it 's a non trivial change so it would be better if you could get somebody more familiar with multiarch issues (e.g slangasek) to review it
[17:54] <stokachu> seb128: ah ok
[17:55] <slangasek> man
[17:55] <slangasek> you desktop people, always making me the patsy for multiarch
[17:56] <seb128> slangasek, there will be free beers in return it that makes it better? ;-)
[17:56] <infinity> slangasek: If the pasties fit...
[17:56] <infinity> Oh, wait.  "patsy".  *cough*
[17:59] <med_> heh
[18:02] <stokachu> infinity: could you pretty please help us out on a azure bug
[18:03] <slangasek> seb128: beer makes me fat, and we're focused on reducing footprint this cycle
[18:03] <seb128> slangasek, fair enough, free glass tap water for you ;-)
[18:03] <slangasek> hah
[18:03] <seb128> +of
[18:03] <jcastro> slangasek: try wine!
[18:03] <slangasek> jcastro: I do!
[18:03] <slangasek> ;)
[18:04] <infinity> slangasek: Try more!
[18:04] <infinity> stokachu: Which one?  The walinuxagent update?
[18:04] <stokachu> infinity: we've got a heater and no debdiffs or MP's, i will work with those for future bugs on the processes
[18:04] <stokachu> infinity: yea :(
[18:04] <infinity> stokachu: Shouldn't need diffs or MPs, it's in the queue already, no?
[18:04] <stokachu> there are related branches attached to the series but that is all
[18:04] <stokachu> for raring i think lemme check precise
[18:04] <infinity> Unless we're talking about two different things.
[18:05] <slangasek> roaksoax: maas> sorry about that, I'm not sure how it fell off the radar... I thought I had done this already, maybe I was waiting for a queue diff or something
[18:05] <stokachu> infinity:  this one is bug 1158465
[18:05] <infinity> stokachu: https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=walinux
[18:05] <slangasek> so I saw that walinuxagent has been packaged in Debian now
[18:05] <infinity> stokachu: I'll review them today.
[18:05] <slangasek> only the maintainer has called it 'waagent'
[18:05] <slangasek> someone want to sync up with them? :)
[18:05] <stokachu> med_: ^ (sync with debian?)
[18:05] <stokachu> infinity: awesome man i really appreciate it
[18:05] <infinity> slangasek: Can we call it waaaahagent instead?
[18:06] <slangasek> wagilent
[18:06] <med_> stokachu, I think there are some deltas. I'll take a look   slangasek infinity
[18:07] <slangasek> med_: by 'sync with Debian' I don't mean "take Debian's package unmodified", just "correct the fact that we're doing double work with them" :)
[18:07] <med_> slangasek, I think that we'll have some work to do to get them synced up.
[18:08] <med_> since upstream has taken our patches, that should put debian in a better position
[18:08] <infinity> Given upstream's constant insistence that THE WHOLE WORLD WILL EXPLODE if you don't run the latest version, I'm not sure we can sync with Debian terribly effectively.
[18:08] <med_> I'll review (and try and engage utlemming ) in the debian packages and see if we can't all "get together"
[18:08] <infinity> But maybe they'll settle the eff down and stabilise soon.
[18:09] <infinity> (A man can dream)
[18:09] <slangasek> med_: Debian is also a few upstream versions behind, from what I see - 1.2 vs. 1.3.2?
[18:09] <med_> yep, uck
[18:10] <infinity> Anyhow, if we can consolidate on packaging, slapping a new orig on occasionally isn't world-ending.
[18:10] <infinity> (But, for now, 1.2 and 1.3.x packaging would be pretty different by necessity, due to 1.2's silly attempts to reinstall itself from itself without patching all that out)
[18:17] <roaksoax> slangasek: no worries :), I thought it was ready for verification too but it wasn;t :(
[18:18] <slangasek> roaksoax: accepted now
[18:18] <roaksoax> slangasek: awesome! thanks a lot :)
[18:18] <slangasek> infinity: well, I don't see any good reason that Debian should be using 1.2 instead of 1.3.2 either, do you?
[18:19] <infinity> slangasek: Oh, absolutely not.  They should be on the latest and shiniest.
[18:20] <slangasek> hallyn: hey, wrt ovmf/edk2, I'm surprised that you say there's no support upstream for maintaining state - I certainly did find code in ovmf that's meant to load/save UEFI variables from disk, I just haven't figured out yet why it's not working
[18:20] <infinity> slangasek: But given that we've been agressively SRUing new upstreams (at least, for now, I really hope that settles down), we won't stay in sync for long unless Debian's maintainers are on the ball (or we join them).
[18:20] <slangasek> infinity: well, step one is to get the Debian maintainer to fix the package name ;p
[18:21] <hallyn> slangasek: it was two weeks ago i was looking, but the docs certainly said there wa sno support.  maybe it's in the works?
[18:21] <infinity> slangasek: Or for us to suck it up and do a transitional one, yeah.
[18:21] <slangasek> infinity: 'waagent' is a much woorse name
[18:21] <infinity> slangasek: waaaah.
[18:21] <slangasek> hallyn: what docs are those?
[18:21] <infinity> slangasek: But I agree, and given that it's only in unstable, there's time to fix.
[18:22] <slangasek> hallyn: I assure that the code is there and quite mature - it just isn't working for me, and I've thus far failed at creating a debug build of ovmf
[18:22] <infinity> And, for whatever reason, the Debian maintainer decided it was amd64-only.
[18:22] <slangasek> hallyn: do you know the right way to get a debug build? :)
[18:22] <infinity> I guess he couldn't fathom the concept of people running i386 cloud instances.
[18:23] <utlemming> infinity: that is because Windows Azure only supports amd64
[18:23] <utlemming> infinity: they won't allow 32-bit builds
[18:23] <infinity> utlemming: Then why does our package build for i386? :P
[18:23] <utlemming> s/they/MS/g
[18:23] <infinity> (And really?  Silly Azure)
[18:24] <infinity> utlemming: Still, nothing stopping you from running an amd64 kernel and i386 userspace.
[18:24] <utlemming> infinity: I don't remember the reason...but I for some reason it wasn't allowed to be uploaded
[18:24] <utlemming> infinity: that sounds like vaugely like the justification
[18:24] <utlemming> infinity: I can't remember the reason for it being that way
[18:25] <infinity> I doubt there's a "valid" reason, so not much point trying to remember what it was.
[18:25] <infinity> (The valid reason may, in fact, have more to do with Windows images than Linux ones, and they just applied the same rules blindly across the board)
[18:27] <hallyn> slangasek: apparently the tip at the bottom of OvmPkg/REAMDE is NOT one of the things i tried
[18:27] <hallyn> so, maybe that works
[18:27] <hallyn> slangasek: I do know jeremy-kerr's bios has debugging enabled (if i tested right)
[18:28] <slangasek> yeah, his has debugging
[18:28] <slangasek> but I can't reproduce it with the package :-)
[18:29] <slangasek> hallyn: the README talks about 'UNIXGCC' which is not the build profile we're using... we're using 'GCC47'
[18:30] <utlemming> infinity, slangasek: fixing Debian's version is going to be painful. They are going to have the same problem that we ran into, whereby upgrading the system can lock out the admin user
[18:30] <hallyn> slangasek: sigh, i'm trying to find the file i'd been editint go try enabling debugging, but these directory names just confound me
[18:31] <infinity> utlemming: It's only in unstable so far.  Maybe you can just convince the maintainer (very politely) to just take your packaging?
[18:32] <infinity> utlemming: Upgrades from his current package to yours are probably not even worth worrying about, if the switcheroo is quick. :P
[18:32] <utlemming> infinity: yeah, I think I'll ask him. The other problem with it is the name is supposed to be walinuxagent.
[18:34] <infinity> utlemming: Well, yes.  Taking your packaging would imply the name change too.
[18:34] <infinity> utlemming: And then you could just ask ftpmaster to remove waaahagent, and done.
[18:34] <hallyn> slangasek: anyway i mainly need that postponed until after this coming week.  after that i'll look bac into it (noted in my tickler file)
[18:35] <slangasek> hallyn: ok :)
[18:36] <slangasek> hallyn: fwiw, from what I've read of the code I think the problem is going to come down to understanding *where* ovmf is pulling the persistence from, and maybe a bug in when it applies its fallback of creating a new file
[18:37] <slangasek> since it uses UEFI's own filesystem calls to manage it, there are possibly-arcane rules about the order in which it iterates the FAT filesystems
[18:47] <hallyn> slangasek: yeah, it was while trying to find where it gets its persistance that i thought i saw notes sayint it doesn't.  maybe it was old mailing list notes.
[18:48] <slangasek> hallyn: right - well, there's an awful lot of code here for it to not do anything ;)
[19:01] <ogra_> slangasek, beer has influence on your shoe size ?
[19:01] <ogra_> (you should see a doctor ... )
[19:05] <slangasek> ogra_: yes, it pools in my feet
[19:05] <ogra_> oouch ...
[19:11] <infinity> ogra_: Do you nick highlight on "beer"?
[19:11] <ogra_> lol
[19:12] <ogra_> you dont ?
[19:13] <infinity> ogra_: I don't drink.
[19:17] <slangasek> infinity: you "imbibe"?
[19:17] <mlankhorst> chug ;)
[19:19] <infinity> I won't listen to this slander.
[19:21] <dobey> slander? libations!
[19:55] <dobey> man, i didn't realize aptitude was such a controverisal piece of software
[19:57] <slangasek> heh
[19:57] <slangasek> it's only controversial because it's buggy
[19:57] <infinity> It's only controversial because people insist that it's useful.
[19:57] <infinity> Bugginess wouldn't matter if those people stopped. :P
[19:58] <slangasek> dobey: the first time I typed 'aptitude install $foo' and was offered a solution to remove 10 packages, upgrade 4, and not install the package I requested, I ragequit
[19:58] <cyphermox> +1
[19:58] <mlankhorst> :>
[19:58] <cyphermox> however perhaps the response was overwhelming
[19:59] <dobey> slangasek: it's almost like getting recommendations to install things i already have installed :)
[19:59]  * ogra_ has never used it ... 
[19:59] <dobey> i've never used aptitude either. no need to
[19:59] <ogra_> but the thread is really entertaining ...  why couldnt  he bring it up on friday though
[20:00] <dobey> apt-get works fine
[20:00] <cyphermox> ogra_: on friday?
[20:00] <ogra_> fridays are for trolling :)
[20:00] <cyphermox> so you could do more reading? :D
[20:01] <slangasek> cyphermox: hey, wrt your latest commit on libappindicator, I'm reasonably certain that your 'clean' target is entirely superfluous and should be dropped
[20:01] <cyphermox> slangasek: I think so too
[20:01] <cyphermox> but I opted to just fix it for now, clean up properly later
[20:01] <cyphermox> (wasn't mine in the first place)
[20:01] <slangasek> cyphermox: I welcome such proper cleanup at all points :)
[20:02] <cyphermox> slangasek: good point though, I better do it *now* so I don't forget
[20:02] <cyphermox> the rule as it is will just do what it would do if it was absent nayway
[20:02] <slangasek> yep... except it actually does it twice ;)
[20:03] <cyphermox> which makes it more clean! :)
[20:07] <cyphermox> slangasek: you didn't file a bug about this did you?
[20:08] <slangasek> cyphermox: nope
[20:08] <cyphermox> ok, just making sure
[20:17] <dobey> mhall119: hey. recently (i think last week sometime), i saw a post on planet ubuntu iirc, that mentioned someone having poked about with making a softwre-center UI for ubuntu touch using the sdk. do you know anything about that? like where the code is and who did it?
[20:49] <tjaalton> slangasek: hey, about the lightdm/plymouth race.. guess it's time to upload the upstart job change to raring? It has fixed the race for me
[20:49] <slangasek> tjaalton: yes... mlankhorst tried to pin that on me, without much success ;-)
[20:49] <slangasek> (I think I agreed to upload it and then it fell off my radar)
[20:50] <slangasek> tjaalton: feel free to upload the change described in my last comment on the bug?
[20:50] <tjaalton> heh, ok
[20:50] <tjaalton> yep, I'll prepare it tomorrow
[20:50] <tjaalton> another thing..
[20:51] <tjaalton> we'd (still) like to update mesa 9.0.3 -> 9.1.1 (9.1.2 later this week)
[20:51] <tjaalton> bug 1164093 is the ffe report
[20:53] <tjaalton> so the latest word is that with a fairly simple revert the intel performance issue with blur/fade is mostly solved
[20:54] <slangasek> tjaalton: I saw the earlier comments about the mesa upgrade; on its face it makes me very nervous to take this post-final beta
[20:55] <slangasek> as it's not clear to me how much burn-in it's had beyond identifying the one intel performance regression
[20:55] <tjaalton> i've ran it for two months on sandybridge
[20:57] <tjaalton> but yeah it could've gone in earlier
[20:58] <slangasek> tjaalton: one person running it for two months is not the kind of reassuring breadth of coverage I'd be looking for
[20:58] <slangasek> tjaalton: maybe you should coordinate with balloons to get some community testing, and we can revisit based on what people find?
[20:59] <tjaalton> I'm not the only one, it's been on the staging ppa for that long, although it had all of xserver 1.14 too
[20:59]  * doko did hear that argument earlier this month as well ;p
[20:59] <tjaalton> slangasek: I sent a CFT last Friday, a handful of people reported success but all on intel I think
[21:00] <tjaalton> slangasek: ok I could post to the forums too, and update the ppa package to match what I have now
[21:01] <slangasek> doko: yes, because silence is not assent and we need to get in the habit of being more rigorous about testing things before we land them without a rollback plan :-)
[21:01] <slangasek> tjaalton: well, best would be if you could coordinate with balloons
[21:01] <slangasek> ... who is hiding from us on #ubuntu-release
[21:01] <tjaalton> oh, a person? :P
[21:01] <slangasek> that way we can be systematic about gathering feedback, and you don't have to worry :)
[21:01] <slangasek> yes! :)
[21:01] <tjaalton> sure thing
[21:01] <tjaalton> thanks
[21:26] <lifeless> win 52
[21:33] <med_> infinity, slangasek : stop working on walinuxagent please (for the moment)
[21:33] <slangasek> med_: oh, I've done no work on it, never fear :)
[21:35] <jerry66> http://www.reddit.com/r/fuckedhardxxx/comments/1c0mor/hot_amateur_movie_collection/
[21:36] <med_> slangasek, nod.
[21:43] <med_> slangasek, infinity it was a pebcak, not a package issue with walinuxagent.
[21:59] <mhall119> dobey: yeah, Ashley Johnson or something like that, let me find his posts
[22:00] <dobey> mhall119: thanks
[22:01] <mhall119> dobey: http://elbuntuprojects.com/new-ui-in-progress-ubuntu-mobile-appstore/
[22:01] <mhall119> I don't see a link for code though
[22:02] <mhall119> dobey: ah, here it is: https://github.com/elbuntu/umobile-software-center-universal
[22:02] <dobey> ah, thanks
[22:08] <dobey> hmm