[00:58] <nigelb> pitti: this is the trouble with apport I was talking about yesterday malone bug 583109
[03:14] <bluefoxicy> so, besides a license that basically says "Do whatever the fuck you want to," there is also a license that requires you to be dead to use the software.
[03:14] <bluefoxicy> I swear you just can't make this shit up.
[03:22] <G> bluefoxicy: what requires you to be dead to use?
[04:55] <m4t> is there a way, either through session or system dbus, to get mouse/kb idle for an x session?
[04:55] <m4t> i downloaded like 600MB of xmlto dependencies to compile gnome-screensaver docs, but the listed GetSessionIdleTime doesn't seem to exist
[04:58] <m4t> maybe i want consolekit's GetSystemIdleSinceHint?
[07:09] <dholbach> good morning
[07:24] <ddecator> didrocks: ping
[08:07] <didrocks> ddecator: yes?
[08:09] <ddecator> didrocks: hey, i was just wondering if the apport hook mentioned in bug 579548 is something you guys would really like, and if you'd be willing to have me write one for you
[08:11] <didrocks> ddecator: yeah, the hardware stuff is the first step. TBH, I'm not sure about additional info that can be relevant, maybe glxinfo will be good?
[08:11] <didrocks> ddecator: if you can do it, that would be awesome :)
[08:12] <ddecator> didrocks: yah, i'm just starting to learn how to write hooks, but that one seems simple enough. if you can just let me know what info exactly you would like it to grab, i can work on getting it setup tomorrow and attach it to the report for you guys to review :)
[08:13] <didrocks> ddecator: sweet, you can maybe also have some look at clutter forums to see what's people are asking for too. That can be a good hint about what to include in the report
[08:14] <ddecator> didrocks: sure thing, i'll look into that tomorrow (2:14am here right now, haha)
[08:15] <didrocks> ddecator: take some rest ^^ In any case, I won't really have time to review it before next week :)
[08:16] <ddecator> didrocks: good deal, thanks for getting back to me :)
[08:17] <didrocks> ddecator: you're welcome. Thanks for tackling that! Just ping me when you need some help
[08:18] <pitti> Good morning
[08:18] <ddecator> morning pitti
[08:18] <pitti> jdstrand: thanks
[08:18] <pitti> kees: ok, can do; I thought about globally resetting it tomorrow, but I can do those individually as well
[08:21] <RAOF> ddecator, didrocks: If you need any help you probably want to look at the X apport hooks, which already collect that information.
[08:22] <ddecator> RAOF: thanks for the tip
[09:26] <mb4_> morning
[09:26] <mb4_> can i ask questions about packaging here?
[09:40] <pitti> kees: updated db, charts should update in 30 mins
[09:43] <pitti> mb4_: yes
[11:21] <juliank> mvo: Do you have any plans to move to update-manager 0.200 for maverick? Having to mostly independently developed series of update-manager does not look like a good thing.
[11:43]  * cjwatson wraps his head around the dpkg merge
[12:08] <mvo> juliank: it was on the agenda for last cycle already, but time was/is a issue
[12:08] <dholbach> juliank: I just had a look over it, it seems like the version in Debian needs to still merge a lot
[12:11] <juliank> mvo: OK.
[12:11] <juliank> dholbach: Yeah, I know that there are large differences in some parts.
[12:12] <mvo> juliank: btw, did you notice that I merged the "unbranded-icons" branch into trunk? that is probably useful for the debian packages of s-c
[12:15] <juliank> mvo: I currently use the standard package management icons (system-software-install) and I may stay with 2.0.X for squeeze to have the same as lucid, unless someone asks me to ship the same release as maverick.
[12:15] <mvo> juliank: ok, sounds good. trunk/ is in a lot of churn currently, so staying with 2.0.x is a good choice
[12:16] <mvo> turnk is also pretty exciting, but that is a different matter :)
[12:16] <juliank> mvo: I will merge the 2.1 stuff into a debian-next branch once you released it.
[12:16] <mvo> ok
[12:18] <juliank> mvo: You forgot to merge the changes for debian/control, BTW; including the one to only conflict with gnome-app-install (<< 1) [without the version, it breaks the upgrade path]. I also reformatted a bit there, since tabs and spaces where mixed in trunk.
[12:19] <juliank> (And without merge information, merging it back becomes increasingly complicated)
[12:19] <mvo> juliank: ok, I fix that
[12:22] <jdstrand> pitti: fyi, still waiting on sparc and powerpc (est start time, 3 and 4 hours respectively)
[12:34] <mvo> juliank: I added a unbranded desktop file now too, so with the icons and the desktop file its just the .ui file that needs some work
[12:45] <juliank> mvo: OK.
[12:46] <juliank> tseliot: Is there a branch for x-kit somewhere?
[12:50] <mvo> juliank: if you cherry pick r789,790 then that should make the branding easier, I moved code into the Distro class where it belongs
[13:03] <dmart> Has anyone been having trouble with NFS servers running on lucid?
[13:03] <dmart> I'm finding that when a client executes fcntl(... F_SETLKW ...) in an NFS chroot, it hangs for minutes at a time
[13:04] <dmart> normal file assess works OK though, and lockd processes are present on client and server
[13:04] <dmart> The server lockd is stuck in disk sleep state the whole time, but since it's a kernel process this is possibly normal.
[13:09] <pitti> jdstrand: please let me know if you need build score bumping, etc.
[13:11] <jdstrand> pitti: I think it would probably be a good idea (at least for hardy). redhat released today. if we plan on it being in -proposed for a week, then it doesn't matter. if we want to release today, it would probably be good
[13:11] <jdstrand> pitti: I am testing the i386 and amd64 binaries this morning
[13:12] <dmart> slangasek: Have you seen rpc.statd failing to launch on lucid?  It looks like this may be the cause of my problem (see scrollback)
[13:16] <tseliot> juliank: it's here: https://launchpad.net/xorgparser why are asking?
[13:18] <juliank> tseliot: Debian packaging. The branch contains a debian/ directory for 0.4.2, but code from 0.4.2.2 though.
[13:20] <tseliot> juliank: right, it shouldn't contain a debian directory. The tarball doesn't contain it
[13:21] <juliank> tseliot: The package is native, so from my point of view something went really wrong then.
[13:21] <tseliot> juliank: ?
[13:23] <tseliot> juliank: what's wrong with having a native package? x-kit is not in debian
[13:23] <juliank> tseliot: The package is a native package with one tarball and the version 0.4.2.2; although it should be 0.4.2.2-1 and using a .diff.gz on the upstream tarball (which despite your statement above, also contains the debian/ directory)
[13:23] <juliank> or 0.4.2.2-0ubuntu1
[13:24] <tseliot> juliank: only 0.4.2.2 contains the debian directory and it was mistake
[13:25] <tseliot> the other tarballs don't have it
[13:26] <juliank> tseliot: Well, but the package should then still be not native, since you have two different tarballs with the same version. A native package is only for the case where the upstream tarball is equal to the package; that's not the case here.
[13:26] <juliank> If you do upstream releases without a debian/ directory, your package must not be native.
[13:28] <juliank> The tarballs even complete the .bzr directory!!!
[13:28] <juliank> s/complete/contains/
[13:28] <tseliot> yes, I've noticed that (in the launchpad page)
[13:29] <jdstrand> pitti: not sure if you rescored yet, but hardy is currently scheduled to 1-3 hours, so maybe not worth it
[13:34] <tseliot> juliank: but yes, good point, I can replace the upstream tarball and correct the version
[13:35] <juliank> tseliot: Never replace an existing tarball, it will break the assumptions of your users.
[13:35] <tseliot> juliank: the one in the launchpad page
[13:35] <juliank> tseliot: Your upstream users.
[13:39] <juliank> tseliot: You don't work with Python very much, right? (My points being: non-PEP8 function names (myFunc instead of my_func), comparisons to None using == instead of 'is', classes not derived from object ['class MyClass:' should be 'class MyClass(object):')
[13:41] <tseliot> juliank: I wrote that code some time ago, now I have different habits. I used to adopt the QT coding style but now it's no longer the case.
[13:42] <tseliot> and I don't want to break the api
[13:43] <ScottK> It's not rare to see PyQt code that follows Qt conventions instead of Pythonic ones.
[13:44] <juliank> ScottK: We're talking about simple Python code, not Qt related.
[13:44] <ScottK> Ah, sorry.  Poor assumption on my part.
[13:46] <tseliot> juliank: may I ask the purpose of your code review?
[13:46] <tseliot> just curious
[13:47] <juliank> tseliot: Well, I just want to understand it, to consider how to go on with packaging jockey for Debian (which needs python-xkit). I can either package it standalone as in Ubuntu or merge X-Kit into jockey and not expose the API at all.
[13:49] <juliank> It's just the question of whether I want to support it generally or only for jockey-internal use.
[13:50] <tseliot> juliank: ok
[14:00] <dmart> Keybuk: hi there, do you have a moment for a quick upstart question?
[14:03] <dmart> Keybuk: never mind, looks my issue is already tracked here: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/581941
[14:17] <nigelb> pitti: got a min?
[14:17] <pitti> nigelb: what's up?
[14:17] <nigelb> remember I was talking to you about some trouble with nondefault gconf values?
[14:17] <nigelb> here's the bug, bug 583109
[14:18] <pitti> nigelb: yep, saw it an assigned to me
[14:18] <nigelb> pitti: ok, so you're faster ;)
[14:18] <nigelb> shall we proceed as usal with the hook and let this bug be fixed in apport?
[14:19] <nigelb> i.e. not wait for this to be fixed for the hook
[14:27] <apw> does anyone know if we have any 'first boot' processing which occurs after a karmic to lucid upgrade but not after a scratch install of lucid ?
[14:27] <pitti> nigelb: yes, I think so; it's independent from the hook
[14:28] <nigelb> pitti: ok, tks :)
[14:34] <cjwatson> apw: not unless individual packages implement it
[14:34] <cjwatson> apw: (postinst scripts can tell whether they're being upgraded or fresh-installed)
[14:35] <juliank> Launchpad always times out ....
[14:40] <smoser> persia, or cjwatson or dmb member.
[14:40] <smoser> trying to add my feed to planet ubuntu
[14:40] <smoser> i can't write to lp:~planet-ubuntu/config/main planet-ubuntu
[14:40] <cjwatson> that's not a dmb thing ...
[14:40] <smoser> well, dmb approved me
[14:40] <cjwatson> well, wait, were you given per-package upload rights?
[14:40] <cjwatson> I may have forgotten to add you to ~ubuntu-dev
[14:41] <smoser> yeah, i was granted ppu
[14:41] <smoser> i searched that list and didn't find myself, but didn't know if i would have been in a sub group
[14:41] <cjwatson> right, I'll sort that out now, thanks for the note
[14:41] <smoser> thank you cjwatson
[14:43] <cjwatson> smoser: should work for you now
[14:44] <smoser> cjwatson, it does. thanks.
[15:03] <nigelb> stefanlsd: ping
[15:16] <slangasek> dmart: there are various race conditions with statd startup in lucid, currently.  Do you have /var on a separate partition?
[15:19] <dmart> slangasek: I don't think /var is on a separate partition, but is may be experiencing the race problems you refer to: see https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/581941
[15:21] <slangasek> dmart: right - in that case that's the known fallout from the preceding portmap startup change; discussed in bug #525154, though that's now something of a catch-all bug for statd startup issues
[15:23] <dmart> I guess I can work round this one manually for now
[15:24] <slangasek> dmart: setting statd to 'start on local-filesystems' probably fixes it for you, if you're not on nfsroot
[15:25] <slangasek> I've just been slow to make that change in lucid because the code is touchy and I haven't had a solid block of time to think all the way through it
[15:25] <dmart> OK, I'll try it.  The box in question is a server; my main problem is huge timeout delays when clients do locking calls
[15:27] <slangasek> well, /separately/, there's a race condition with nfs-kernel-server startup because it's not converted to upstart yet
[15:27] <doko> cjwatson: about the cpuname change: I think it's the correct fix. the triplet is used to be passed to configure, and it should be the correct one.  it easier to grep the rules files for wrong conditionals.
[15:28] <cjwatson> doko: is there any way to get this merged to Debian in advance of Debian switching gcc's defaults?
[15:28] <cjwatson> e.g. can we add that cputable line as a separate line?
[15:28] <cjwatson> (in dpkg)
[15:29] <doko> but: currently we are using the triplet names as multiarch names (as for multilib). maybe this really should be changed to architecture names, maybe the linux names extended to something like i386-linux
[15:30] <doko> cjwatson: afaik this a table lookup, with the arch as index. don't know how this should work
[15:31] <cjwatson> well, I guess I can play with it
[15:31] <cjwatson> I care because this is one of the two remaining unforwarded changes in dpkg - tantalisingly close to being able to sync it
[15:47] <hunger> Is maverick going to use gcc 4.5 or 4.4? What was decided at UDS?
[15:51] <Aquina> I read nothing about that in UWN and slo no statement about this in the video casts so far.
[15:51] <Aquina> I gess 4.5 is possible however.
[15:52] <hunger> Aquina: Thanks. I only found a mail from pitti (pre-UDS) stating that the default toolchain is still set to 4.4 at that time since gcc version was a UDS decission.
[15:59] <cjwatson> right.  new dpkg heading for maverick.  hold on to your hats.
[16:02]  * ogra grabs the rope
[16:02] <ion> Any hope dpkg-multiarch will make it into maverick? Anyone working on it?
[16:04] <cjwatson> ion: slangasek has been making noises about working on it this cycle
[16:04] <ion> Nice
[16:15] <cody-somerville> ugh, getting kubuntu blueprint changes for some reason
[16:18] <Riddell> probably because kubuntu-dev is the assignee and ubuntu-core-dev is a member of that
[16:20] <tremolux> rickspencer3: I have more data for the bug report btw
[16:20] <rickspencer3> nice
[16:21] <rickspencer3> tremolux, I'd like us to know what is going on so that if we see that problem again, folks know what's up and how to work around it
[16:21] <tremolux> rickspencer3: unfortunately, it's a weird error
[16:21] <tremolux> rickspencer3: yes, we need a report, I'll write it and add what I found out
[16:22] <rickspencer3> something about auth or keys or something?
[16:22] <tremolux> rickspencer3: yes, something seemed wrong there
[16:22] <tremolux> rickspencer3: plz try to find out what happened to the ppa if you can
[16:22] <rickspencer3> he deleted it
[16:22] <tremolux> rickspencer3: oh, bummer
[16:22] <rickspencer3> he said he added it a long time ago, and the keys were misbehaving or something
[16:23] <rickspencer3> he's in #quickly if you want to chat to him directly
[16:23] <tremolux> rickspencer3: that sounds like what the problem then, yeah
[16:23] <rickspencer3> tremolux, but I would like software-center to handle the problem if it's at all likely to happen again to others
[16:24] <tremolux> rickspencer3: agreed
[16:24] <rickspencer3> of course if it's a rare circumstance, prioritize appropriately
[16:24] <tremolux> rickspencer3: should be very rare, yep
[16:25] <rickspencer3> in that case, meh
[16:25] <rickspencer3> it's not like there was data loss or crashes, etc...
[16:26] <tremolux> rickspencer3: I'll log it, it's important to keep track of
[16:26] <rickspencer3> k
[16:26] <rickspencer3> thanks
[17:13] <nucc1> hi i'm a novice programmer, i'm trying to track down an Evolution bug, can anyone help me interpret this error message? its only 3 lines. http://pastie.org/969603
[17:16] <cjwatson> the first two lines are probably irrelevant, and the third means that the program attempted an invalid memory access
[17:16] <cjwatson> http://en.wikipedia.org/wiki/Segmentation_fault
[17:17] <cjwatson> you'll need to use further tools to find out why: evolution may have its own debugging options to emit more verbose output, or else use tools such as strace, gdb, or valgrind
[17:21] <nucc1> thanks, i'll look into using a debugger. evolution doesn't seem to have any option for getting more verbose debug output
[17:25] <cjwatson> nucc1: #ubuntu-desktop may have more detailed experience here
[17:27] <nucc1> ok. trying to use gdb right now
[17:28] <tekknokrat> Hi, I need a workaround for /usr/share/python/python.mk for backporting trac-0.11.7 for hardy
[17:29] <tekknokrat> Is this the right place to ask?
[17:29] <Drakeson> would someone please remove the extra space between "]" and "<" (in "...] </default>") from line 121 of /usr/share/gconf/schemas/control-center.schemas, in package capplets-data ?  every upgrade keeps nagging about not being able to parse that.
[17:30] <Aquina> I would check the package in Launchpad and report it there.
[17:31] <nucc1> cjwatson, gdb says the segfault comes from libgtkhtml-editor
[17:31] <Drakeson> cjwatson: upgrade evolution
[17:31] <Drakeson> oops!
[17:31] <Drakeson> nucc1: upgrade the evolution package.
[17:32] <nucc1> Drakeson, i think im uptodate. trying to check if i somehow ended up with an odd version of libgtkhtml
[17:34] <Drakeson> nucc1: what is the version of evolution that you have? older than 2.30.1.2-1ubuntu2 ?
[17:35] <nucc1> i'm using 2.28.3, ubuntu lucid default
[17:37] <Drakeson> are you on maverick?
[17:38] <ScottK> Most people won't be at this point.
[17:38] <ogra_cmpc> one would hope so
[17:39] <Drakeson> sorry, that was meant for nucc1
[17:39] <Drakeson> nucc1: are you on maverick?
[17:39] <Drakeson> nucc1: are you on maverick?
[17:40] <nucc1> i'm on lucid. trying to trace random evolution crashes.
[17:41] <nucc1> looks like i had libgtkhtml-editor 3.30 as opposed to 3.29 that ships with lucid
[17:42] <Drakeson> a few days ago evolution got broken (gtkhtml-editor got upgraded, but evolution was blocked because evolution-exchange was holding it back). thought that might be your problem ...
[17:43] <nucc1> thanks, i must have entered the wrong channel. i was thinking that 'ubuntu-devel' means 'ubuntu developers'
[17:43] <nucc1> now i realise it means 'development version'
[17:44] <ogra_cmpc> well the development version i swhat the ubuntu developers develop :)
[17:45] <ogra_cmpc> so you are actually right here ...
[17:45] <ogra_cmpc> for your particular evo prob #ubuntu-desktop would be the better channel though
[17:45] <nucc1> ogra_cmpc, but that usually means they are working on the current development version, whereas i'm interested in something to do with current stable :)
[17:45] <nucc1> yea, i've been told. just stayed here cos of the inertia
[17:46] <ogra_cmpc> we're also intrested in breakage in the recently released version in case its severe
[17:47] <ogra_cmpc> if you find a bad enough bug in the stable relese there is always the possibility for a stable release update to fix it
[17:50] <nucc1> ah, yes, i'll stay on it. if i find it's worth escalating, i'll find out how and do it
[19:33] <Sarvatt> darn, llvm-dev isn't installable in maverick at the moment :( depends on oprofile which isn't installable because - Depends: binutils (< 2.20.2) but 2.20.51.20100518-1ubuntu1 is to be installed
[19:46] <cjwatson> doko: ^- can Sarvatt's problem be fixed by a simple rebuild?
[20:15] <ccheney> pitti: i noticed some users can't seem to get apport-collect to work for openoffice.org it is complaining the package 'openoffice.org' isn't installed but that is just the source package name (and a generally non-installed binary meta package)
[20:15] <pitti> ccheney: right, it works against binary packages; otherwise it cannot collect information about the binary package, since it doesn't know which one
[20:17] <ccheney> pitti: it appears for some unknown reason to me that the binary package hint for openoffice.org packages is usually the openoffice.org meta package instead of something like openoffice.org-common or -core that is always installed, do you know how that ends up getting added to the bug report?
[20:20] <ccheney> pitti: and i am assuming the line "Binary package hint: openoffice.org" is what apport-collect looks at to see what to lookup?
[20:20] <pitti> ccheney: I actually don't know what this "binary package hint" is or where it comes from; apport doesn't use it
[20:21] <ccheney> pitti: oh ok, so how does it determine the binary package name when launchpad only knows about source package names?
[20:21] <ccheney> pitti: is there some file to modify to do the proper mappings?
[20:21] <pitti> ccheney: you mean for retracing? It's in the "Package:" field of the apport data
[20:22] <pitti> i. e. the one you report the bug against
[20:22] <ccheney> pitti: er no when someone files a bad lp bug and i tell them run eg: apport-collect bugnumber
[20:22] <ccheney> pitti: for several people so far it has returned that they don't have the openoffice.org (meta) package installed, which is generally never installed
[20:23] <pitti> ccheney: ah, for this we need an apport hook which also covers source packages
[20:23] <pitti> ccheney: it tries to collect information about the binary package of the same name, but if that doesn't exists (or rather, isn't installed), it's simply not collected
[20:23] <pitti> ccheney: then it only collects the info from the source_<srcpackagename>.py hook
[20:24] <ccheney> pitti: if i don't want to do anything special other than get the normal apport reported info what would i do to fix it for that?
[20:26] <pitti> ccheney: for apport-collect? or for bug filing?
[20:26] <ccheney> pitti: for apport-collect i suppose, the bug filing probably should be fixed to but isn't as urgent
[20:28] <pitti> ccheney: hm, does OO.o have a package hook? I don't have one here
[20:28] <ccheney> pitti: no it doesn't have a package hook, i was just wanting them to add the standard apport info that all packages get via apport-collect to an old bug filed without apport
[20:29] <ccheney> pitti: there isn't too much that i would need in a hook, maybe what video driver they are using, but the standard info is usually all i ever need
[20:29] <pitti> ccheney: you could ask people to run apport-collect -p openoffice.org-draw 12345, for example
[20:30] <pitti> i. e. against the application that they actually have a problem with
[20:30] <ccheney> ah ok so the -p is still useful, i thought it was deprecated and not actually used anymore
[20:30] <pitti> for apport-collect it's still useful
[20:31] <pitti> it's not necessary any more for ubuntu-bug
[20:31] <ccheney> oh ok
[20:32] <ccheney> pitti: thanks for the help
[20:32] <pitti> you're welcome
[20:45] <hendry> i'm deploying a commericial binary package on Ubuntu and I'm wondering how I should create a shortcut on the user's desktop. Any advice here?
[20:57] <juliank> hendry: According to the topic, you should ask in #ubuntu-app-devel. But anyway, you should not create stuff on the desktop.
[20:58] <juliank> Which is impossible on installation time anyway, since installation is run as root; and not as the normal user who wants to run the application
[21:15] <Sarvatt> cjwatson: changing the oprofile Build-Depends: to binutils (>= 2.20.51.20100518-1ubuntu1) and rebuilding certainly seems to work so far as to letting llvm-dev install at least :D