[01:31] <hyperair> hmmm ubuntu's switching to systemd?
[01:31] <hyperair> http://www.markshuttleworth.com/archives/1200#comment-397370 <-- is this for real?
[01:34] <micahg> hyperair: not a reliable source of information
[01:34] <micahg> * i.e. no clear relation to the project
[01:35] <RAOF> hyperair: I don't know why you'd get that impression.
[01:35] <hyperair> RAOF: i figured it would have been flamed to hell already if it wasn't true.
[01:35] <hyperair> RAOF: so the lack of flames were a cause of concern.
[01:39] <ajmitch> hyperair: I think the lack of flames are probably due to moderated comments
[01:40] <RAOF> Possibly also that it's basically just noise.
[01:53] <hyperair> heh
[01:59] <ajmitch> hyperair: might as well write that there's 'no question' that unity will be rewritten in C# :)
[02:04] <hyperair> ajmitch: good idea!
[02:05] <ajmitch> hyperair: it's probably on news sites already after commenting on it in here
[02:25] <RAOF> ajmitch: I'd support that!
[02:25] <ajmitch> RAOF: think of how confusing it'd be to have unity & unity3d, both in C# :)
[03:37] <pitti> Good morning
[03:37] <ajmitch> morning pitti
[03:38] <pitti> ScottK: I put it into the changelog; I haven't maintained a NEWS file for postgresql so far, perhaps I should for stuff like that
[03:38] <ScottK> pitti: I suppose that'll do, but I think NEWS is better.
[03:39] <pitti> slangasek: GNOME SRUs> A good indication is the version number, it should be 3.6.x for quantal; but that is indeed a bit blurry
[03:39] <pitti> hey ajmitch
[03:41] <ScottK> pitti: Done.
[03:41] <pitti> ScottK: done what?
[03:42] <ScottK> pitti: Accepted the SRUs.
[03:42] <pitti> oh, the ecpg one; thanks!
[03:42] <ScottK> pg on precise and quantal.
[03:45] <slangasek> pitti: ah, good point.  Well, stgraber provided pointers to the upstream module definitions, which is probably good for now.
[03:47] <pitti> skaet, cjwatson, stgraber, infinity, release team: congrats to the final release! that was a rather difficult birth
[03:56] <ScottK> I think it would have been a lot smoother with less last second featuritis.
[03:57] <slangasek> TheMuso: hey, is there really any reason for us to ship libasound2-python?  Debian doesn't ship the smixer plugins at all; I can't find any documentation for how this plugin is supposed to be used, and it's definitely not ported to python3
[04:29] <invalidopcode> This is probably a simple answer but can one "clone" a package from a public launchpad project and then build the project easily?
[04:31] <ScottK> invalidopcode: You probably want #launchpad.
[04:31] <invalidopcode> ScottK: okay, thanks.
[04:31] <invalidopcode> I'm trying to work on the
[04:31] <invalidopcode> lp:ubuntu/quantal/pidgin-libnotify project, that's why I asked here
[04:34] <slangasek> invalidopcode: 'bzr branch lp:ubuntu/quantal/pidgin-libnotify' is the bzr equivalent of a git clone
[04:35] <slangasek> as for building, you perhaps want 'dpkg-buildpackage'
[04:35] <invalidopcode> okay, thanks! I'll try that
[04:38] <invalidopcode> slangasek: it gives me "dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ..."
[04:39] <slangasek> invalidopcode: ah - so you should probably install the bzr-builddeb package, and run 'bzr bd' instead of 'dpkg-buildpackage'
[04:40] <invalidopcode> ah thanks! It seems to be going now :)
[04:43] <invalidopcode> it seems to complain about not being able to sign the package
[04:43] <invalidopcode> it might be because I haven't logged into launchpad
[04:43] <invalidopcode> but if I'm just doing dev, do I need to sign the package?
[04:44] <slangasek> invalidopcode: that will be because you haven't set up your environment with a pgp key; and no, you don't need to sign the package
[04:44] <slangasek> invalidopcode: there are some pages somewhere that talk about this initial env setup, let me see if I remember where they are
[04:44] <invalidopcode> okay thanks!
[04:44] <invalidopcode> yeah I don't want to keep bothering you if I don't have to
[04:44] <slangasek> http://developer.ubuntu.com/packaging/html/getting-set-up.html
[04:46] <invalidopcode> thanks
[04:47] <invalidopcode> I'm new to the Ubuntu dev community... I'm more familiar with the Archlinux pkgbuild system :)
[05:18] <invalidopcode> slangasek: after following all those steps it still fails with "gpg: /tmp/debsign.UclxAL3H/pidgin-libnotify_0.14-4ubuntu11.dsc: clearsign failed: secret key not available"
[05:20] <slangasek> invalidopcode: so in order for debsign to know which key to use, either your PGP key's UID must exactly match the uploader field in debian/changelog, or you need to pass -k<keyid> to tell it which key to use.  (for instance, if you're signing a package that someone else prepared, you need to use this latter option)
[05:20] <slangasek> invalidopcode: however, if you're not actually uploading this anywhere, you can use the -uc -us options instead: bzr bd -- -uc -us
[05:21] <invalidopcode> ah okay
[05:21] <invalidopcode> thanks
[05:22] <invalidopcode> yay! it worked :)
[05:26] <invalidopcode> thanks for all the help slangasek!
[05:34] <invalidopcode> is the new libmessaging-menu library this http://developer.ubuntu.com/api/ubuntu-12.10/c/messaging-menu/ ?
[05:36] <invalidopcode> disregard the stupid question :)
[05:46] <invalidopcode> okay last question. slangasek. what does one to do fix "aborting due to unexpected upstream changes"?
[05:46] <slangasek> invalidopcode: that depends on what those changes are... you might run dpkg-source --commit to keep them, or bzr revert to get rid of them
[05:47] <invalidopcode> so for every change I make I have to do that before building?
[05:47] <slangasek> well
[05:47] <invalidopcode> or is there a better way to do quick development?
[05:48] <slangasek> if you're testing the build, you can also pass -b to bzr bd
[05:48] <slangasek> and skip the source package generation, which is what's failing here
[05:48] <invalidopcode> okay
[06:01] <dholbach> good morning
[06:14] <hallyn> slangasek: so i'm playing with the debian experimental qemu git branch that's taking the place of qemu-kvm soon.  working well for me.  i looked at a diff to the qemu-linaro git tree, and it seems contained enough to arm stuff that it would seem fine to add as a patch, imo, to consolidate the trees.  (there are other barriers of course)
[06:14] <hallyn> something to talk about at uds if nothing else
[06:16]  * hallyn calls it a night
[06:20] <obounaim> Good morning
[06:44] <jibel> mvo, good morning
[06:45] <jibel> mvo, I found bug 1068389 this morning
[06:46] <mvo> jibel: thanks, let me have a look
[07:18] <tjaalton> is there a way to disable automounting certain media/mountpoints?
[07:18] <pitti> tjaalton: put them into fstab (LABEL= or UUID=) and don't mark as "auto"
[07:18] <tjaalton> pitti: ah, thanks
[07:18] <sarnold> tjaalton: 'noauto' in fstab(5) :)
[07:19] <tjaalton> yeah I thought there was a "newer" method :)
[07:19] <tjaalton> but this works too
[07:28] <mvo> jibel: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/2581 - I will upload that now
[07:52] <jibel> mvo, thank you
[07:56] <mvo> jibel: thank you for finding it!
[08:11] <jibel> pitti, about https://code.launchpad.net/~pitti/charms/quantal/jhbuild/jhbuild_from_git/+merge/130365
[08:12] <pitti> jibel: oui?
[08:12] <jibel> pitti, I'd rather not delete the local copy on configuration change or upgrade and preserve any change the user could have made locally
[08:12] <jibel> pitti, what do you think ?
[08:12] <pitti> jibel: you mean in the checked out jhbuild tree?
[08:13] <jibel> pitti, right
[08:13] <pitti> jibel: I can change it accordingly, yes
[08:13] <pitti> jibel: i. e. [ -d jhbuild ] || git clone jhbuild?
[08:13] <pitti> jibel: d'accord, I'll change it accordingly
[08:14] <jibel> this 2 lines +        rm -rf jhbuild
[08:14] <jibel> +        git clone git://git.gnome.org/jhbuild
[08:14] <jibel> as it can be an unpleasant surprise
[08:14] <pitti> jibel: right, and the ones below that for autogen and make
[08:14] <jibel> yes
[08:36] <pitti> jibel: did they approve your charm now?
[08:36] <pitti> jibel: you said yesterday you wanted to wait with the merges until that happened
[08:39] <jibel> pitti, not yet but the fixes are safe, and xfvb something we want by default.
[08:40] <pitti> jibel: ah, so we'll shelve the jhbuild-from-git one for now?
[08:40] <pitti> jibel: good, then I'll continue with my pygobject stuff today, and get back to the charm on Monday
[09:00] <mpt> ev, so, what are the possible causes of a spike
[09:00] <ev> jockey
[09:00] <mpt> (1) There's a big new bug: unlikely, since we were in Final Freeze, and the table doesn't show anything obviously new.
[09:02] <mpt> (2) People installing from scratch experience bugs disproportionately to pre-release testers, e.g. bugs in the installer or, yes, jockey.
[09:02] <ev> A binary program crash that's suddenly appearing and not showing up on the front page because the retracers are down (thanks gnat-gps).
[09:02] <mpt> But the first ubiquity problem is #68, jockey #45.
[09:02] <mpt> ah
[09:02] <ev> So there were 18187 reports for 12.10 yesterday, compared with 6320 the day before.
[09:03] <mpt> (3) There's something wrong with the denominator in the calculation. We're counting many fewer users than we should be.
[09:03] <mpt> (Or fewer machines, rather.)
[09:05] <ev> hmmm, suspicious: there were 63630 unique systems for the 90 day period ending yesterday. There were 565335 for the 90 day period ending on the 17th.
[09:05] <ev> That's not as big an increase as I would suspect.
[09:06] <mpt> UTC, right?
[09:06] <ev> yes
[09:07] <mpt> 12.10 was out for only ~6 of those hours.
[09:08] <ev> sure
[09:08] <ev> so we should definitely see how much the unique system in a 90 day period count grows after today
[09:09] <ev> but this still doesn't explain the big upward swing of reports
[09:22] <jtaylor> is there a way we can modify the fontconfig deprecation warning? it is not clear at all what it wants you to do.
[09:23] <jtaylor> "Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated."
[09:23] <Laney> it's software, so yes
[09:25] <sladen> jtaylor: apt-get source fontconfig && grep -r "is deprecated" fontconfig-*
[09:25] <jtaylor> I'm just looking at it
[09:25] <jtaylor> would a patch be accepted for an sru?
[09:26] <sladen> concentrate on fixing the next release, and think about SRU as a secondary wishlist
[09:27] <sladen> I believe the general tendancy is to ask/warn a user if they are able to do something about it (and tell them how), or not bother them with science if they can do nothing about them.  Thus, either fixing it to a proactive comment, or disabling both make sense
[09:51] <cjwatson> ev: oh, sorry, I promised to deal with the gnat-gps SRU didn't I
[09:52] <cjwatson> done
[09:53] <dupondje> Somebody else is noticing shutdown issues sometimes?
[09:56] <ev> cjwatson: thanks! And no worries at all - I wasn't expecting anything to happen yesterday, given the release
[09:57] <ev> mpt: responding to your PM here: yes, sorry, that should be 56335 systems in the 90 day period ending yesterday
[11:15] <mpt> ev, another example of (2) might be the RecoverableErrors, if people install and then try to install a bunch of apps
[11:16] <ev> mpt: yes, but we separate out the effect of RecoverableErrors into its own line
[11:16] <mpt> ev, not yet :-)
[11:16] <mpt> oh, I see on poppy-dev
[11:16] <ev> :)
[11:16] <mpt> it goes up just as high
[11:17] <doko> barry, ping
[11:18] <mpt> ev, just throwing ideas out there, but do you have something like an off-by-one error in the period you're counting users in? E.g. dividing the number of errors for yesterday by the period up to the day before?
[11:18] <mpt> (...by the number of computers in the period up to the day before, I mean)
[11:20] <ev> I'll do a review of the code now
[12:52] <mitya57> barry, doko: please don't add python3.3 to supported versions until python-docutils is fixed
[12:52] <mvo> stgraber: could you have a look at #1068614 please? probably something relatively easy to fix on the server
[12:53] <mitya57> I would prefer to upload docutils 0.9.1 with some cherry-picked patches, but that would require uploading python-roman
[12:53] <mitya57> and MIRing it
[12:53] <mitya57> is that possible before the archive opens?
[12:54] <mitya57> https://code.launchpad.net/~mitya57/ubuntu/raring/python-roman/1.4.0-1ubuntu1
[12:54] <mitya57> otherwise I can try to backport those patches to 0.8
[12:55] <doko> mitya57, where is the MIR?
[12:55] <mitya57> doko: I haven't filed it because the package is not yet uploaded
[12:55] <mitya57> should I do that?
[12:55] <ScottK> mitya57: Given that the python3-defaults patch for 3.3/multi-version support is incomplete, I don't think we'll have it at the open in any case.
[12:56] <doko> yes please, and upload the package
[12:56] <doko> ScottK, ?
[12:56] <mitya57> I think he means issues with pyqt
[12:56] <ScottK> doko: See my last mail to -devel.  I tried barry's patch and it didn't work out so well.
[12:56] <ScottK> mitya57: Yes, but I don't think it was an issue specific to that package.
[12:57] <doko> hmm, it did work for me for a simple extension. if just qt4 fails, then let it fail ...
[12:57] <ScottK> I'll try another one.
[13:32] <mitya57> MIR done (bug 1068630), so are we uploading new python3-defaults before the archive opening?
[13:42] <stokachu> cjwatson: i was in the process of converting gnome-keyring to multiarch and noticed in the rules file it does this install -m0755 -D debian/gnome-keyring.ubiquity debian/gnome-keyring/usr/lib/ubiquity/target-config/50gkd-caps, i didnt see ubiquity as an rdepends so was wondering what implications this has
[13:43] <stokachu> or if ubiquity will never be multi-arched i guess it wouldn't mattter
[13:43] <cjwatson> The lack of a dependency doesn't matter - it just provides a hook for ubiquity to run in case it is installed
[13:44] <cjwatson> There's no reason for ubiquity ever to be multi-arched as far as I know, so if this is in a multi-arch: same package then you just need to make sure it's identical across architectures as usual
[13:44] <stokachu> libgnome-keyring is MA: same
[13:45] <stokachu> so should be ok then
[13:52] <mitya57> doko: ^
[13:59] <mitya57> and I'm thinking of going with an svn snapshot of docutils because it includes my patch for debian bug 677929.
[14:02] <stgraber> mvo: hmm, yeah, that's fixable on the server. I'll assign that one to me
[14:03] <mvo> stgraber: thanks
[14:05] <doko> mitya57, and the docutils upload?
[14:06] <mitya57> doko: so I should do it now?
[14:07] <doko> mitya57, yes, both please
[14:08] <mitya57> doko: OK, doing
[14:25] <doko> mitya57, did you upload?
[14:27] <mitya57> I've prepared it, will now file a bug report and upload tarballs there
[14:27] <mitya57> I'm not a core developer :)
[14:32] <mitya57> doko: bug 1068667
[14:32] <mitya57> I'm not able to test it now thoroughly because I have to go
[14:33] <mitya57> But I can do that tomorrow
[14:34] <mitya57> doko: ^^
[14:35] <mitya57> and the branch with python-roman packaging is at 1048259
[14:35] <mitya57> *bug 1048259
[14:39]  * mitya57 has to go offline now, sorry :(
[14:46] <mitya57> I'm back :)
[14:57] <stokachu> stgraber: bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"., know anything about this? happens when doinga bzr branch lp:ubuntu/quantal/ssd
[14:58] <stokachu> sssd*
[15:00] <Laney> stokachu: I suggest you file a bug on launchpad.net/udd
[15:00] <stokachu> Laney: ok will do thanks
[15:01] <tumbleweed> there's a source package called ssd?
[15:01] <Laney> sssd
[15:02] <tumbleweed> I see 'ssd' in the pasted URL
[15:02]  * Laney shrugs
[15:02] <stokachu> oh
[15:02] <Laney> typo
[15:02] <stokachu> rofl
[15:02] <Laney> laney@quantal> bzr branch lp:ubuntu/quantal/sssd                                                                                      ~/temp
[15:02] <Laney> bzr: ERROR: Revision {stgraber@ubuntu.com-20110804202131-kd0ddqcwxmznqjw9} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[15:02] <tumbleweed> right :)
[15:12] <stokachu> cjwatson: if you got a few seconds could i get appmenu-gtk and libgnomecanvas approved in the upload queue for precise?
[15:19] <mitya57> doko: attached tested and updated tarballs to bug 1068667, will you sponsor it?
[15:27] <cjwatson> stokachu: Won't running dpkg-query in an Xsession.d script slow down desktop startup performance?
[15:28] <cjwatson> stokachu: And shouldn't this get into a development release first?
[15:28] <stokachu> cjwatson: is raring open for that now?
[15:29] <stokachu> cjwatson: startup performance maybe affected by a small amount
[15:30] <cjwatson> It could be quite significant - opening the dpkg database can be expensive
[15:30] <cjwatson> I think this needs to take a file-based approach instead
[15:30] <cjwatson> Perhaps use a wildcard?
[15:31] <stokachu> cjwatson: hmmm i could do that
[15:31] <stokachu> all arch are basically similar in where its put right? /usr/lib/<arch>/..
[15:31] <stokachu> i wasn't sure for arm etc
[15:31] <cjwatson> It's always one subdirectory down, yes
[15:31] <cjwatson> The name of the subdirectory isn't necessarily what you expect of course
[15:32] <stokachu> yea i can try that approach and see
[15:37] <cjwatson> stokachu: huh, I see slangasek suggested the dpkg-query approach
[15:38] <stokachu> cjwatson: lol i didnt want to say anything :X
[15:38] <cjwatson> slangasek: ^- did you consider the desktop startup performance implications of calling dpkg-query in Xsession?
[15:38] <stokachu> the plot thickens :D
[15:39] <cjwatson> The question of what happens if it's missing is a bit murky anyway, because surely it depends on which architecture of libgtk is running that might try to load it
[15:39] <cjwatson> Or something
[15:40] <stokachu> cjwatson: from my tests it works either way
[15:41] <cjwatson> stokachu: so, unclear about appmenu-gtk, but libgnomecanvas is nice and simple - there were two roughly-identical copies of it in the queue, so I accepted the first and rejected the second
[15:41] <infinity> stokachu: conffiles can be arch-specific, I'd just generate it at build-time with the full path.
[15:41] <cjwatson> infinity: not in a multi-arch: same package
[15:41] <cjwatson> see the bug :)
[15:41] <infinity> cjwatson: Oh, it's in the library.  Ick.
[15:42] <slangasek> cjwatson: hrm, there was a vague tickle in the back of my head, is this actually having a noticeable startup impact?
[15:42] <infinity> But if it's MA:same, the dpkg-query defeats the entire purpose.
[15:42] <infinity> Since it's going to tell you if you have your primary-arch version installed.
[15:43] <infinity> Which may or may not be what you wanted to know.
[15:43] <slangasek> it is
[15:43] <slangasek> this config file is used to set a single environment variable that affects all versions of gtk
[15:43] <infinity> Yes, but.  How does that relate to what I just said?
[15:43] <slangasek> either you have some version of appmenu and you want to set it, or you don't have any and you don't set it
[15:44] <slangasek> oh, sorry, misparsed
[15:44] <slangasek> no, that query doesn't just return for the primary arch
[15:44] <slangasek> try it and see
[15:44] <cjwatson> slangasek: I haven't profiled it, but it would definitely seem to me to be a concern
[15:45] <cjwatson> If we're cracking down on forks during boot, forking something that loads a substantial text database just seems unwise :)
[15:46] <stokachu> cjwatson: i think i attempted the file based check first and slangasek mentioned that wouldnt work
[15:46] <stokachu> i'd have to go back into the notes and see why that was
[15:47] <infinity> slangasek: I bed to differ.  I just installed sl:i386 (so, not having the amd64 one installed at all) and, as I expect, I get "unknown ok not-installed" for sl, and "install ok installed" for sl:i386
[15:47] <infinity> slangasek: So, I maintain that if your appmenu-gtk doesn't match your dpkg arch, this fails.
[15:47] <mitya57> doko: so will you sponsor that or no?
[15:47] <infinity> slangasek: Which kinda seems to defeat half the point of multiarching.
[15:47] <slangasek> infinity: that's not a multi-arch: same package
[15:47] <cjwatson> The dpkg-query call takes ~0.2s here after dropping caches
[15:48] <stokachu> cjwatson: barely enough time to sneeze! :D
[15:48] <cjwatson> stokachu: tight budgets
[15:48] <ScottK> It all adds up.
[15:48] <slangasek> cjwatson: fwiw the tickle in the back of my head also said "what is this crazy design, why are we exporting variables instead of just letting gtk probe it on the filesystem"
[15:48] <cjwatson> slangasek: So for "some version of appmenu is installed", why not just glob over @moduledir@/*/libappmenu.so and test if any of the results exist?
[15:49] <slangasek> infinity: that's not how the dpkg-query output for libc6 looks, to take an example M-A: same package
[15:49] <cjwatson> Equivalent and faster
[15:49] <slangasek> cjwatson: yeah, that should be fine too
[15:49] <infinity> slangasek: That would be hard for me to test, given that it's impossible to remove the native libc6...
[15:49] <cjwatson> for x in @moduledir@/*/libappmenu.so; do if [ -e "$x" ]; then ...; break; fi; done
[15:49] <cjwatson> stokachu: ^-
[15:49] <cjwatson> maybe -f rather than -e to match the original
[15:49] <slangasek> cjwatson: I think I didn't recommend that because of an aversion to dealing with globs in shell scripts
[15:50] <slangasek> clearly that did not serve me well here :)
[15:50] <cjwatson> The above is my standard form, and avoids the usual no-nullglob-related bug
[15:50] <slangasek> stokachu: cjwatson's approach is definitely better
[15:50] <stokachu> so no immediate issues with globs then?
[15:50] <cjwatson> If the design is to test whether *any* libappmenu.so is available, then the glob approach should work
[15:51] <stokachu> ok, cool! ill work on getting that implemented and retested
[15:51] <cjwatson> I don't know whether gtk breaks if $UBUNTU_MENUPROXY is unavailable
[15:51] <stokachu> the original menus are used
[15:51] <cjwatson> OK, good
[15:51] <stokachu> yea i tested that when i broke the build :D
[15:52] <micahg> a fs grep is faster than dpkg-query?
[15:53] <infinity> micahg: In that case, sure.  It's not a find /
[15:53] <infinity> slangasek: I'm curious what you mean by libc6 output looking different.
[15:54] <stokachu> slangasek: and do you ever hear a giggle in the back of your head?
[15:54] <infinity> slangasek: (Purely academic now, since he's not using this approach)
[15:54] <Will123456> hey guys. when you view windows scaled back in the overview/spread mode in either unity or gnome shell, it seems like there's no point in drawing all the UI chrome, buttons and scrollbars and so on. it's an ambitious idea in terms of requiring toolkit/application support, but is the idea of being able to request applications draw only their "content", rather than UI chrome a realistic idea?
[15:54] <Will123456> (and/or a useful idea)
[15:56] <Will123456> an example would be libre office drawing only the text and hiding toolbars, gimp only drawing the image being worked on and none of the toolboxes, calculator only displaying the current result
[16:04] <infinity> slangasek: Just to show I'm not insane, http://paste.ubuntu.com/1289641/
[16:05] <cjwatson> Will123456: #ubuntu-unity might be better for that kind of thing
[16:05] <ScottK> infinity: That only shows this isn't evidence of insanity.  It's not proof otherwise.
[16:05] <infinity> ScottK: ...?
[16:06] <infinity> ScottK: Oh, right.
[16:06] <infinity> ScottK: Yes, I'm clearly insane, we all know that, just not in regards to this. :P
[16:06] <cjwatson> insane on at least one side
[16:15] <Will123456> cjwatson: good call, i'll ask there
[16:19] <stokachu> cjwatson: hmm, i think im going to have to use /usr/lib/*/ rather than moduledir
[16:20] <stokachu> moduledir expands to /usr/lib/<arch>/gtk-2.0/2.10.0/menuproxies/*/libappmenu.so
[16:20] <stokachu> and that won't even work fully
[16:20] <stokachu> i could glob 3 spots perhaps
[16:20] <slangasek> infinity: http://paste.ubuntu.com/1289689/ fwiw :)
[16:21] <infinity> slangasek: izzat quantal or precise?
[16:21] <slangasek> infinity: quantal
[16:21] <infinity> slangasek: Ed zachary.  His upload is to precise.
[16:22] <cjwatson> stokachu: Ah, right, I wasn't clear on the exact directory layout
[16:22] <cjwatson> stokachu: Maybe there's some other piece you can extract from the build system; or *cough* run sed over @moduledir@
[16:22] <stokachu> so i guess my question is that acceptable to do /usr/lib/*/*/*/menuproxies/libappmenu.so
[16:22] <cjwatson> That doesn't feel right
[16:22] <stokachu> yea
[16:23] <cjwatson> maybe you can get hold of the gtk-2.0/2.10.0/menuproxies part separately
[16:23] <stokachu> cjwatson: http://paste.ubuntu.com/1289701/
[16:23] <stokachu> line 36 starts where it handles the appmenu.in portion
[16:24] <cjwatson> but you could always use shell's text processing facilities
[16:24] <cjwatson> moduledir=@moduledir@
[16:24] <cjwatson> moduledir_suffix="${moduledir#/usr/lib/*/}"
[16:24] <cjwatson> etc.
[16:24] <cjwatson> then you can look at /usr/lib/*/$moduledir_suffix/libappmenu.so, or something like that
[16:25] <stokachu> ok ill dig into it some more to see what i can come up with
[16:25] <infinity> stokachu: What's the full path?
[16:26] <stokachu> infinity: http://paste.ubuntu.com/1289706/
[16:26] <stokachu> that was with the splat in there
[16:27] <infinity> stokachu: No, the full path.  What's that extra * expand to?
[16:27] <stokachu> infinity: well thats all that is put into 80appmenu from the configure
[16:27] <stokachu> only @moduledir@ is expanded to what you see there
[16:27] <cjwatson> Yeah, that certainly won't work, try my moduledir_suffix stuff instead
[16:27] <stokachu> the splat was what i put in there
[16:28] <infinity> stokachu: What I mean is, where is the actual file?
[16:28] <stokachu> infinity: oh just remove the splat
[16:28] <cjwatson> infinity: /usr/lib/*/gtk-2.0/2.10.0/menuproxies/libappmenu.so
[16:28] <stokachu> and that would be the full path
[16:28] <infinity> stokachu: I'm going to assume a splat is an asterisk? ;)
[16:28] <stokachu> yea sorry
[16:28] <stokachu> lol
[16:28] <infinity> cjwatson: Right, and globbing works fine, if that is used, then.
[16:29] <cjwatson> Just a matter of picking the expansion of @moduledir@ apart in shell.
[16:29] <infinity> Yeah.
[16:32] <drizt> hi.
[16:34] <drizt> i opened bug with nfs-utils on launchpad two weeks ago but still didn't get any answer.
[16:34] <drizt> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1062022
[16:36] <drizt> also I opened the same bug on Red Hat bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=863054. And the result: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=a16f4a13677d13b0aae9327a3b9e8414470b7927;hp=b010d126bbb8265e5717e596711d754baec11e6c
[16:45] <nod> hi.  i noticed some errors during an "apt-get update" and was told I should drop this here. http://33ad.org/pb/vp
[16:45] <nod> this was about 15 mins ago.  I tried again just now and it seemed to sync ok, so not sure what the transient issue was related to
[16:47] <hallyn> ^ more W: Failed to fetch bzip2:/var/lib/apt/lists/partial/it.archive.ubuntu.com_ubuntu_dists_precise-updates_main_source_Sources  Hash Sum mismatch
[16:47] <sarnold> nod: it looks like there's three it.archive... mirrors; try it a few times and see if it comes back?
[16:48] <nod> it's completed already now, i just thought you guys might want to know
[16:48] <nod> i'm more concerned from an infrastructure standpoint and not this silly vm I'm hacking on :)
[16:49] <infinity> nod: It's not a mirror we directly control, so not a whole bunch we can do about it sometimes being skewed.
[16:49] <sarnold> :)
[16:50] <infinity> (Except to take away their CC DNS entry, but that's probably not necessary here)
[16:50] <nod> interesting. could clock skew introduce issueslike that?
[16:51] <nod> i'd figure it's just a simple rsync of some flat file structure
[16:52] <infinity> nod: It's a flat file structure, but if the Release and Packages files need to match.
[16:53] <infinity> nod: Most mirror admins run scripts to try to mitigate the windows between those two being transferred to seconds (or less), some don't care and it can be minutes.
[16:53] <infinity> nod: Err, that first sentence took a turn when I lost context elsewhere.  "if the Release and Packages files don't match, you get that error" is what I meant to say. :P
[16:54] <nod> heh i grok'd.
[16:54] <infinity> nod: Which is, of course, a feature.  The bug is that they can not match while a mirror is updating.
[16:54] <infinity> (Which is a bug in how we publish the archive and/or in how people mirror it, depending on where one likes to place blame on days that end in 'y')
[16:54] <cjwatson> Also web caches occasionally get unlucky and then get stuck on the mismatching versions until they expire.
[16:55] <infinity> cjwatson: Yeah, that can be unfortunate.
[16:55] <nod> quirky. so it's not an atomic operation by moving to an alternate location, then flipping over to the new repro?
[16:55] <cjwatson> Figuring out the relevant URLs and running wget --no-cache on them can sometimes clear this for an entire office-worth of people at once.
[16:55] <cjwatson> nod: Unix doesn't have atomic directory replacement
[16:55] <infinity> nod: It is on our end, we don't dictate what mirrors do.
[16:55] <cjwatson> It's not even on our end
[16:55] <nod> cjwatson: symlinks :)
[16:55] <cjwatson> It's just close
[16:55] <cjwatson> Well, OK, I guess
[16:56] <infinity> cjwatson: It is on our end on the publishing side is what I meant, as in, we don't push mirrors until ftpmaster is consistent.
[16:56] <cjwatson> nod: But even then, a client's update could straddle the symlink change
[16:56] <cjwatson> So that doesn't really solve the problem ...
[16:56] <nod> other option is to rewrite httpd config to new loc then send HUP
[16:56] <cjwatson> Same problem
[16:56] <nod> yeah.. good point
[16:57] <infinity> The problem is only solvable by subtle mangling the archive format, and we've talked about it a lot.
[16:57] <infinity> Some day, someone might write the code to actually make it happen.
[16:57] <cjwatson> Right, we had a plan to put everything in SHA-512-named files or similar
[16:57] <infinity> cjwatson: Yeah, I vaguely liked that one.  Ugly to humans, simple for computers.
[16:58] <nod> alright... this conversation is getting too interesting.  i can't continue or i'll get distracted from paying the bills with cool stuff.
[16:58] <cjwatson> Mitigatable for humans with symlinks.
[16:58] <cjwatson> More or less.
[16:58] <nod> thx all for your help. bbl when i can spare cycles
[16:58] <infinity> The ugly to humans bit being solvable by linking Packages to the "current" SHA.
[16:58] <infinity> Jinx.
[16:58] <infinity> And the above is necesarry to provide backward compat anyway.
[16:58] <hallyn> @pilot in
[17:04] <stokachu> neat gnome-keyring places gnome-keyring-prompt in /usr/lib/gnome-keyring
[17:04] <stokachu> on precise
[17:05] <stokachu> i think ill mess with that and appmenu on monday
[17:18] <ahasenack> hi!
[17:18] <ahasenack> with the release over, I wonder if someone has time
[17:18] <ahasenack> to look over this SRU of mine: https://bugs.launchpad.net/landscape-client/+bug/1053057
[17:18] <ahasenack> just precise was uploaded so far
[17:18] <ahasenack> (to proposed)
[17:37] <hallyn> ahasenack: the SRU team is a few weeks behind.  thanks for your confirmation of that bug(fix) though.
[17:38] <ahasenack> hallyn: ok, thanks
[17:46] <slangasek> ahasenack: are you looking for upload sponsorship or SRU processing, though?
[17:46] <slangasek> SRU processing we're getting caught up on (I'm on deck today)
[17:46] <ahasenack> slangasek: sru review/processing
[17:46] <slangasek> ah, ok
[17:47] <slangasek> yeah, I tend to process SRU queues newest release to oldest so I'm not sure if I'll make it to oneiric & earlier today
[17:47] <ahasenack> slangasek: ok, thanks anyway
[17:47] <slangasek> but hopefully we'll get the queue down far enough to solve the starvation problem this coming week
[17:59] <alex-foo> what does ubuntu use for file indexing these days?
[18:02] <sarnold> alex-foo: I've got the mlocate package providing my /etc/alternatives/locate ...
[18:02] <alex-foo> for desktop search, i mean.
[18:03] <sarnold> ah.
[18:04] <alex-foo> i think it used to be beagle, then used to be tracker
[18:06] <slangasek> zeitgeist
[18:12] <dobey> well, zeitgeist isn't an indexer
[18:13] <dobey> and the unity lenses do various different things; they don't integrate into a single search solution like tracker or beagle.
[18:26] <fishor> cyphermox, hi. i need your help.
[18:27] <fishor> in gnome-bluetooth, each device has proxy, but not each proxy has device. is it correct?
[18:28] <fishor> cyphermox, bluetooth-client.c:get_proxy_for_iface returns only proxy (no device), but disconnect_callback use it as device.
[18:29] <fishor> so, the problemm is in get_proxy_for_iface or in disconnect_callback
[18:30] <cyphermox> ok
[18:32] <fishor> cyphermox,  so, should get_proxy_for_iface return proxy with device? or just proxy?
[18:35] <cyphermox> no, looks correct to me
[18:35] <cyphermox> just a second
[18:51] <Sexy-Girl-Buntu_> serious bug in python3 that makes ubuntu 12.10 upgrade unusable -> http://paste.ubuntu.com/1290050/
[18:52] <Sexy-Girl-Buntu_> caused by faulty ubuntu-provided python3 packages
[18:52] <Sexy-Girl-Buntu_> "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xeb in position 114: invalid continuation byte"
[18:53] <Sexy-Girl-Buntu_> python3 requires encoding to be explicitly specified according to PEP
[18:53] <ScottK> That's a bug in the driver detection package, not python3.
[18:53] <ScottK> pitti: ^^^
[18:53] <Sexy-Girl-Buntu_> ScottK, any ideas for workaround?
[18:54] <ScottK> No.  I'm not familiar with the code.
[18:54] <slangasek> while it's a bug in the ubuntu-drivers package, it also looks like the trigger may be some database / cache corruption
[18:55] <Sexy-Girl-Buntu_> slangasek, is there a way to purge the cache / db?
[18:56] <slangasek> Sexy-Girl-Buntu_: probably; but I'm also not familiar with this code so I'm trying to work through where the bad data likely is
[18:56] <slangasek> Sexy-Girl-Buntu_: have you filed a bug report in launchpad about this?  it really should be tracked there
[18:57] <Sexy-Girl-Buntu_> slangasek, yes but even the bug reporting is broken and crashing with SIGSEGV so i manually reported
[18:57] <Sexy-Girl-Buntu_> just looking for a temp workaround
[18:58] <slangasek> bug reporting is broken?
[18:58] <slangasek> this code wouldn't have any effect on bug reporting
[18:59] <Sexy-Girl-Buntu_> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1053749
[19:00] <slangasek> ok
[19:01] <slangasek> Sexy-Girl-Buntu_: so if there's corruption, it's most likely in the apt cache.  Could you please save aside /var/cache/apt/pkgcache.bin, run 'sudo apt-get update', and see if the problem goes away?
[19:01] <slangasek> and if it does, please attach pkgcache.bin to that bug report
[19:02] <hallyn> infinity: https://code.launchpad.net/~dannf/ubuntu/precise/open-iscsi/lp1053306/+merge/127359  IIUC that should be marked 'merged' right?  (to take it off sponsor queue)
[19:03] <hallyn> (i'm not allowed :)
[19:05] <Sexy-Girl-Buntu_> slangasek, did not work. also, the md5sum after moving and rebuilding is identical
[19:06] <slangasek> ok
[19:06] <slangasek> Sexy-Girl-Buntu_: do you happen to have the dctrl-tools package installed on this system?
[19:07] <Sexy-Girl-Buntu_> slangasek, not installed -- shall i install it?
[19:08] <slangasek> if so, I'd be interested in the output of this command: grep-available . | iconv -f utf-8 -t ucs-2le > /dev/null; echo $?
[19:08] <slangasek> sorry, make that: grep-available -r . | iconv -f utf-8 -t ucs-2le > /dev/null; echo $?
[19:08] <slangasek> if you can, yes please
[19:09] <Sexy-Girl-Buntu_> slangasek, iconv: illegal input sequence at position 226269
[19:09] <Sexy-Girl-Buntu_> status output 1
[19:10] <hallyn> @pilot out
[19:13] <slangasek> Sexy-Girl-Buntu_: perfect, that's what I was hoping to see - so it means somewhere in your apt sources there's bad input data, since these files are all supposed to be utf8
[19:14] <slangasek> Sexy-Girl-Buntu_: to narrow it down to a file, please run: for F in /var/lib/apt/lists/*Packages; do iconv -f utf-8 -t ucs-2le > /dev/null || echo $F; done
[19:14] <slangasek> Sexy-Girl-Buntu_: that will tell us which package source has the bad data, you can then comment it out of your apt config, run 'apt-get update' again, and bypass the problem for now
[19:15] <slangasek> Sexy-Girl-Buntu_: er, except I got the command wrong again
[19:16] <slangasek> for F in /var/lib/apt/lists/*Packages; do iconv -f utf-8 -t ucs-2le $F > /dev/null || echo $F; done
[19:16] <Girl-Buntu> ok
[19:16] <Girl-Buntu> slangasek, no output
[19:18] <slangasek> hmm, really
[19:18] <slangasek> interesting
[19:19] <slangasek> Girl-Buntu: ok, how about: grep-available -r . | head -c 226300 | tail -n 20 ?
[19:19] <slangasek> perhaps this is due to a locally-installed (i.e., not from apt) package that has bad metadata
[19:20] <Girl-Buntu> slangasek, yeah that seems to be it
[19:20] <Girl-Buntu> Maintainer: Micka�l Guessant <mguessan@free.fr>
[19:20] <Girl-Buntu> Package: davmail
[19:20] <slangasek> if you don't mind sharing the details of that package in the bug report, that would be helpful
[19:21] <slangasek> Girl-Buntu: easiest workaround is probably to edit /var/lib/dpkg/available and remove the offending character
[19:21] <slangasek> (that way you can leave the package installed)
[19:31] <bdmurray> slangasek: there are some similar tracebacks with different KeyError numbers - they are duplicates correct?
[19:33] <Girl-Buntu> slangasek, not the root cuase...still not working
[19:33] <Girl-Buntu> slangasek, edited to no avail
[19:33] <slangasek> bdmurray: if the trace signature is otherwise the same, yes
[19:34] <slangasek> Girl-Buntu: does running 'apt-get update' after the edit make a difference?
[19:34] <Girl-Buntu> slangasek, no
[19:35] <Girl-Buntu> slangasek, the iconv error is removed but not the ability to run the app
[19:35] <slangasek> Girl-Buntu: if you re-run the grep-available -r . | iconv command now, it gives no errors?
[19:35] <Girl-Buntu> slangasek, correct. no errors. still cant run the app though
[19:35] <slangasek> ok
[19:35] <slangasek> Girl-Buntu: how about if you run the same command with grep-status instead of grep-available?
[19:36] <slangasek> i.e., this may require fixing up /var/lib/dpkg/status in addition to /var/lib/dpkg/available
[19:36] <Girl-Buntu> iconv: illegal input sequence at position 223829
[19:36] <Girl-Buntu> ah...
[19:37] <slangasek> sorry, I wasn't sure exactly what dpkg information apt was pulling into its cache
[19:37] <Girl-Buntu> FIXED!
[19:37] <Girl-Buntu> slangasek, u rock -- i will update the bug
[19:37] <slangasek> Girl-Buntu: perfect, thanks for sticking with it
[19:46] <cyphermox> fishor: I'm still debugging it, it's not obvious. I think there's some piece of the recursion that is wrong when cleaning up the device, services behind it and all, but it's complicated
[19:48] <fishor> cyphermox, i see.. i think some extra comments it this source will help in future :)
[19:48] <cyphermox> meh
[19:50] <fishor> cyphermox, meh? what is it?
[19:57] <cyphermox> fishor: I'm not convinced it's a matter of comments
[19:59] <fishor> cyphermox, ah... i just tried to justify my incompetence ;)
[20:02] <cyphermox> don't have to, I'm just as lost ;)
[20:02] <cyphermox> fishor: there's a bug open in launchpad or gnome right?
[20:03] <fishor> cyphermox, in gnome and only for this crash
[20:03] <cyphermox> Bastien can take a look, he's going to have a much easier time figuring it out. I suspect it's a matter of a change in bluez API
[20:04] <fishor> cyphermox, will you contact him, or i should open a bug some where?
[20:06] <fishor> cyphermox, https://bugzilla.gnome.org/show_bug.cgi?id=686172
[20:07] <cyphermox> yeah, that's fine
[20:08] <cyphermox> that one looks good but it brings very little, since the device then doesn't get disconnected either
[20:09] <fishor> cyphermox, yep. it was initial fix of symptom, not real fix.
[20:21] <fishor> cyphermox, can you please assign Bastien to this bug, i do not have his email
[20:21]  * fishor go to sleep
[20:22] <cyphermox> it should be done already
[20:22] <cyphermox> or anyway, he has received the bug mail
[20:26] <sarnold> pwd
[21:26] <xrdodrx> How do I clear the notifyOSD queue?
[21:26] <xrdodrx> I have 4000 notifications in queue due to an application bug.
[21:27] <stgraber> xrdodrx: not really the right place to ask, but I guess killing notify-osd and restart it manually should do the trick
[21:28] <xrdodrx> failed to run command `notify-osd': No such file or directory
[21:29] <xrdodrx> :\
[21:30] <trism> xrdodrx: don't have to restart it, it will be restarted when a notification is sent
[21:31] <stgraber> xrdodrx: /usr/lib/notify-osd/notify-osd though indeed it's dbus activated so should get auto respawned on the next notification
[21:31] <xrdodrx> oh, good. thanks :)
[21:31] <xrdodrx> yes, it was my application that filled up the queue
[21:31] <xrdodrx> ;)
[22:15]  * xnox realised why I can't pronounce raring correctly, because to me it's the act of archiving with RAR, RARing
[22:21] <ScottK> You've finally noticed this name is part of Canonical's secret plan to promote non-free software.
[22:22] <xnox> ScottK: it's Russian, so it's ok.
[22:29] <infinity> hallyn: Only the tech board can mark that merged (or, rather the members of ~ubuntu-branches)
[22:30] <infinity> hallyn: Though, I'm not entirely sure what the point is of merging into a branch no on can write to. :P
[22:30] <slangasek> xnox: it's ok anyway, just as long as you know how to pronounce YOU bun toe
[22:31] <infinity> stgraber: Want to mark https://code.launchpad.net/~dannf/ubuntu/precise/open-iscsi/lp1053306/+merge/127359 merged? :P
[22:31] <xnox> slangasek:  Убунту ? =) correct ?!
[22:31] <stgraber> infinity: done
[22:31]  * xnox is confused which pyflakes is the real pyflakes
[22:32] <ScottK> Will the real pyflakes please stand up.
[22:35] <slangasek> ScottK: you're the real flaky?
[22:38] <ScottK> Probably, but nothing to do with the current conversation.
[23:20] <marrusl> infinity, http://pad.lv/1068889 ... i'd assign it but i can't.  :)
[23:22] <infinity> marrusl: Fixed.
[23:23] <marrusl> dig.
[23:32] <slangasek> marrusl: so in Soviet Russia, Different Strokes watch you?
[23:32] <marrusl> slangasek, +1
[23:33] <marrusl> reminds me... it's probably time to change that one.  :)
[23:33] <slangasek> heh