[03:40] <pitti> Good morning
[03:43] <slangasek> pitti: <blink>  isn't this a bit early, even for you? :)
[03:44] <pitti> yeah, I usually sleep another hour or so after my wife gets up, but couldn't any more
[03:44] <pitti> we have a thunderstorm here
[03:46] <RAOF> A morning thunderstorm?
[03:46] <RAOF> Curious
[03:48] <pitti> RAOF: it got high time for some rain, anyway :)
[05:33] <larsduesing> Good morning!
[05:33] <larsduesing> could be anybody so kind, and have a look after https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix/+merge/107351, please?
[05:59] <rickspencer3> good morning pitti ... yet more beer!
[05:59] <pitti> almost :)
[06:00] <pitti> rickspencer3: good morning to you!
[06:00] <rickspencer3> now we need to get the daily tests going
[06:00] <rickspencer3> good morning pitti :)
[06:01] <rickspencer3> nice to wake up to a cup of coffee irl, and a beer on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[06:01] <StevenK> rickspencer3: That could be because precise is released ... :-)
[06:01] <pitti> rickspencer3: oh, precise -- you should be looking at http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html :)
[06:01] <rickspencer3> d'oh!
[06:02] <pitti> hence pitti | almost :)
[06:02] <rickspencer3> stupid browser history
[06:02] <rickspencer3> that omap4 linux is still there, I see
[06:02] <rickspencer3> well, *close* to a beer ;)
[06:02] <pitti> yeah, seems the ti-omap kernel guys don't like that package, it ceases to exist at every other upload
[06:53] <dholbach> good morning
[07:31] <dholbach> @pilot in
[08:22] <tsdgeos> dholbach: I have a upstream patch that's been accepted in Qt that i'd like to get in Ubuntu's Qt https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/999522 Any hint on how to proceed?
[08:27] <dholbach> tsdgeos, do you know why it hasn't been accepted upstream?
[08:27] <tsdgeos> dholbach: upstream=Qt?
[08:27] <tsdgeos> dholbach: it *has* been accepted upstream
[08:27] <dholbach> ahhhh
[08:27] <dholbach> ok
[08:27] <dholbach> sorry, I misread
[08:28] <dholbach> is it in Q already?
[08:29] <tsdgeos> nope, there hasn't been a Qt release with it yet, so it isn't part of any ubuntu package as far as i know
[08:29] <dholbach> ok, I see
[08:29] <dholbach> I can help you get it into Q, which is one of the first steps of https://wiki.ubuntu.com/StableReleaseUpdates
[08:30] <dholbach> tsdgeos, would you mind adding some information to the bug report according to the documentation?
[08:30] <tsdgeos> i can try
[08:30] <dholbach> cool, thanks a bunch
[08:30] <tsdgeos> not sure what's missing though :D
[08:31] <dholbach> impact of the bug, test-case, possibility of regressions, etc.
[08:31] <cjwatson> test case is the most important one
[08:31] <dholbach> just some more information for those who want to assess and test it, who haven't been following the unity-2d bugs closely
[08:32] <tsdgeos> there's a link to the bug and there's a test case there
[08:32] <cjwatson> it must be in the Ubuntu bug
[08:32] <tsdgeos> i can copy & past if that's what you want
[08:32] <cjwatson> SRU verification is a bottleneck and it's important for uploaders to cooperate in keeping it smooth
[08:33] <tsdgeos> c&p done
[08:37] <dholbach> tsdgeos, is there a way to get the resulting patch from https://codereview.qt-project.org/#change,24361 easily? :)
[08:37] <tsdgeos> You actually only want https://codereview.qt-project.org/#patch,unified,24361,12,src/gui/kernel/qdnd_x11.cpp
[08:38] <tsdgeos> since we don't ship the unittests
[08:38] <tsdgeos> well, qt doesn't ship the unittests
[08:38] <tsdgeos> so we don't etiher
[08:38] <dholbach> ok, thanks
[08:39] <tsdgeos> If it helps
[08:39] <tsdgeos> there's http://qt.gitorious.org/qt/qt/commit/c3eb2e63425c47b8e3eeb7416e225fab10c5c15a too
[08:39] <dholbach> perfect
[08:40] <dholbach> I don't use git very often, nor the codereview.qt page :)
[08:41] <dholbach> does anybody know what might be crashing in https://launchpadlibrarian.net/106359743/buildlog_ubuntu-quantal-i386.sphinx_1.1.3%2Bdfsg-4ubuntu1_FAILEDTOBUILD.txt.gz? is it xvfb?
[08:42] <tsdgeos> dholbach: updated https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/999522
[08:42] <dholbach> thanks tsdgeos
[09:09] <debfx> dholbach, tsdgeos: I want to merge and update Qt in quantal anyway so I don't mind adding the patch from bug #999522 on top of it
[09:09] <dholbach> debfx, that'd be awesome
[09:10] <dholbach> tsdgeos, does this only need to be fixed in quantal and precise?
[09:10] <tsdgeos> dholbach: well, it does affect precise, and since it's an LTS i'd really appreciate if it was fixed there too
[09:11]  * dholbach nods
[09:11] <dholbach> ok, I just saw that somebody added bug tasks for precise as well, so we're all set
[09:14] <tsdgeos> great :) tx
[09:31] <Laney> broder: could it be that backportpackage doesn't pass -v0 when the package is NEW in the destination release?
[09:34] <pitti> ev: hey Evan, how are you?
[09:35] <pitti> ev: I'd appreciate a quick look at https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744
[09:35] <ev> I'm good, how are you?
[09:35] <ev> sure
[09:35] <pitti> ev: I'm great, thanks! had a nice weekend, and you?
[09:35] <ev> yeah, loving this sunny weather
[09:35] <pitti> ev: in particular, I'm interested how ubiquity gets the jockey-text -a auto-install drivers into teh target system
[09:35] <pitti> ev: by copying the installed bits from the live system, or running the plugins again in /target
[09:36] <pitti> ev: will respond to your retracing mail ASAP
[09:36] <ev> thanks
[09:36]  * ev looks over the merge
[09:38] <pitti> ev: I have the full install syslog, in case you want to take a look
[09:38] <ev> pitti: debconf doesn't like multiple things talking to it
[09:39] <ev> since ubiquity is already talking to it, you need to do something like DEBCONF_DB_REPLACE=configdb DEBCONF_DB_OVERRIDE="Pipe{infd:none outfd:none}"
[09:39] <ev> err
[09:39] <ev> DEBCONF_DB_REPLACE=configdb DEBCONF_DB_OVERRIDE="Pipe{infd:none outfd:none}" ubuntu-drivers autoinstall
[09:40] <pitti> ev: ah, that's why you restart the jockey-backend with those
[09:40] <ev> precisely
[09:41] <pitti> ev: ok, that explains the man-db error; I'll fix that
[09:41] <ev> cheers
[09:41] <pitti> ev: so is it expected that my /target doesn't have bcmwl-kernel-source?
[09:43] <ev> pitti: you'll also need to replicate jockey/debian/jockey.ubiquity
[09:43] <ev> so that the packages get installed in the /target as well
[09:43] <pitti> ev: ah, that was my question
[09:43] <pitti> ev: so the plugins don't run again in /target
[09:44] <ev> pitti: nope, there's no guarantee that /target exists when a plugin is run
[09:44] <ev> especially for ubi-prepare, which occurs before partitioning
[09:44] <cjwatson> plugins can define stuff that happens post-install
[09:44] <pitti> ev: I mean, the targets run only once, and we don't run ubuntu-drivers/jockey again in /target later on
[09:45] <cjwatson> (i.e. subclass plugin.InstallPlugin)
[09:45] <ev> ah indeed
[09:45] <pitti> ev, cjwatson: ack, so I'll provide the counterpart of jockey/debian/jockey.ubiquity
[09:45] <pitti> I forgot about that one
[09:45] <cjwatson> dunno if that's what's wanted here, haven't looked at the diff
[09:46] <pitti> cjwatson: right, I just needed to refresh my memory how drivers got into /target
[09:46] <cjwatson> yeah, if jockey.ubiquity is a target-config hook, that's preferable to code directly in ubiquity
[09:47] <pitti> cjwatson: right, jockey-common ships a /u/l/ubiquity/target-config/31jockey_packages
[09:47] <pitti> I'll put a corresponding script into ubuntu-drivers-common
[09:49] <pitti> ev: just to be sure, /u/l/ubiquity/target-config/31jockey_packages runs in the live system, not in chroot /target, does it?
[09:49] <pitti> ev: it calls apt-install, which will install the given package into /target, I presume
[09:49] <ev> that's my understanding, yes
[09:49] <pitti> good, thanks
[09:50] <pitti> I'll give it another full test run with both changes then (debconf env and hook)
[09:52] <ev> cheers
[09:52] <ev> I've updated the MP with this discussion
[10:31] <dholbach> can somebody please reject https://code.launchpad.net/~logatron/ubuntu/quantal/imagemagick/fix-for-993041/+merge/107156? (patch sent to debian instead)
[10:31] <pitti> dholbach: done
[10:31] <dholbach> thanks pitti
[12:10] <dholbach> @pilot out
[12:25] <Benkinooby> hi, i want to turn off my laptops' backlight in order to use it with strong sunlight. i tried to fiddle with /sys/class/backlight and later with /proc/acpi/video and the xset command (with dpms option) but on luck finally i found out, that /proc/acpi/video/GFX0/DD04/brightness specifies the levels to be set for the backlight and that in can only adjust to the given levels in that file - but the lowest level is 20 and not 0. how can i
[12:25] <Benkinooby> get to zero?
[12:26] <Benkinooby> this site supports my findings https://wiki.kubuntu.org/Kernel/Debugging/Backlight
[12:26] <Benkinooby> i'm on ubuntu 10.04
[12:27] <ogra_> sounds like a kernel issue
[12:30] <Benkinooby> ogra_, i think it is more ubuntu related...
[12:31] <ogra_> Benkinooby, well, that file contents are controlled by the kernel
[12:31] <Benkinooby> ogra_, when reading the website what does "disassembled DSDT" mean?
[12:31] <Benkinooby> ogra_, ok, didn't know that
[12:32] <Benkinooby> ah, ok found some hints on google
[12:32] <ogra_> DSDT is part of your bios
[12:32] <ogra_> its the table defining what HW your machine  has
[12:34] <Benkinooby> ogra_, i'm on http://powersave.sourceforge.net/powersave/DSDT.html ... so i need to find these tables, disassmbel them, edit them (adding the level 0 as supoorted level) recompoile them and then go?
[12:35] <ogra_> no idea, i dont use intel hardware :)
[12:35] <ogra_> but that might or might not help, i would ask some ACPI/kernel-powermanagement expert ;)
[12:35] <Benkinooby> ogra_, where can i find them, do you know?
[12:36] <ogra_> probably in #ubuntu-kernel
[12:36] <Benkinooby> ogra_, maybe a mailing list would be more useful than irc... not sure.. also i'm not much of an expert... more like a blind man hitting a bee nest with his stick
[12:37] <Benkinooby> ogra_, but i'll go for that kernel channel for now :)
[12:37] <ogra_> try ubuntu-devel-discuss then
[12:37] <Benkinooby> ogra_, thank you for helping me on
[12:37] <pitti> ev: got back to this now; odd, I still get the "bad fd" error even with that debconf env (I added a print to ubuntu-drivers to verify it's there)
[12:39] <ogra_> or the ubuntu-kernel ML :)
[13:10] <mterry> ev, hello!  So I submitted a crash in quantal, but don't see it in errors.u.c (extended time to a year and still don't see it).  Is there another way to see the data?
[13:13] <larsduesing> short question: until when can I get a debian-package into quantal-universe?
[13:15] <Laney> larsduesing: you want to be considering Feature Freeze as the deadline
[13:15] <larsduesing> ok
[13:15] <geser> larsduesing: easy till FeatureFreeze (around Aug 23rd), after that you need a freeze exception
[13:16] <larsduesing> (I have the problem that it is in state "won't compile" - in kfreebsd... )
[13:16] <larsduesing> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667755
[13:18] <geser> larsduesing: quantal syncs from unstable now, but as aiccu has Ubuntu delta it needs a merge to get new Debian revisions of that package into quantal
[13:19] <larsduesing> yes
[13:19] <larsduesing> I'm aware of that
[13:19] <larsduesing> but it won't get to debian unstable - because it won't compile on kfreebsd
[13:20] <Laney> it already is in unstable
[13:20] <larsduesing> oh
[13:20] <larsduesing> wait
[13:21] <cjwatson> "won't compile on kfreebsd" is the sort of thing that impedes migration to testing, not to unstable.
[13:22] <larsduesing> sorry...
[13:22] <pitti> ev: hm, it seems calling apt-get in simple-plugin just doesn't work -- /proc/self/fd/3 is a link to /proc/5146/fd (i. e. to its own directory), which seems to be what apt-get/man-db are stumbling upon
[13:22] <cjwatson> You should probably use apt-install rather than apt-get directly, unless you need the package to be installed immediately.
[13:22] <pitti> ev: do you know of any plugins which install packages?
[13:23] <pitti> cjwatson: ah, that'll work for the live system, too?
[13:23] <cjwatson> No, apt-install is "queue for installation in target"
[13:23] <pitti> cjwatson: right, but simple-plugins installs driver packages (such as bcmwl-kernel-source) into the live system, in ubi-prepare
[13:23] <cjwatson> I don't quite get what you need in the live system - isn't your plugin in the very package you need installed?
[13:23] <cjwatson> Oh
[13:24] <pitti> that currently calls jockey-text -a, and has some custom code to launch the d-bus backend with some magic debconf env
[13:24] <cjwatson> You would have to be careful to do anything like that before the main business of copying stuff starts, I think
[13:24] <cjwatson> Maybe
[13:24] <cjwatson> And even then it would need a separate debconf db
[13:24] <pitti> yes, it's done after checking "3rd party drivers" and finishes before the partitioning screen
[13:25] <cjwatson> The only stock plugin that installs packages is, I think, usersetup (oem-config-*)
[13:25] <larsduesing> Ok, another question... how to debug apport-plugins? (at the moment I do a kill -SIGFPE <pid> to get apport to run...)
[13:25] <pitti> cjwatson: the current code that uses jockey just launches the d-bus backend with DEBCONF_DB_REPLACE=configdb and DEBCONF_DB_OVERRIDE='Pipe{infd:none outfd:none}'
[13:25] <cjwatson> Right, which is "temporary throwaway db"
[13:26] <pitti> larsduesing: unless your hook depends on a crash, you can use "apport-bug packagename"
[13:26] <larsduesing> and I can halt any transfer to launchpad there, too?
[13:27] <pitti> cjwatson: when I run the apt-get command manually while ubiquity runs, it works; but when ubiquity launches it through simple-plugins, man-db keeps breaking on "3: bad file descriptor", which I can't replicate
[13:27] <pitti> larsduesing: yes, just don't click on "submit"
[13:27] <pitti> larsduesing: you can use the expander to see the data, or use "apport-bug --save /tmp/myreport package" to get a file with the data
[13:28] <larsduesing> I see... being too cautious
[13:28] <larsduesing> thanks
[13:28] <pitti> cjwatson: I guess the bad fd is due to fd 3 pointing to its own directory for some reason
[13:28] <cjwatson> 3 would be the file descriptor that's expected to be usable for writing to the debconf frontend
[13:28] <pitti> right
[13:28] <cjwatson> Perhaps you have managed to arrange for it to think there's a debconf frontend running but for it not to be connected, or something
[13:29] <cjwatson> I'm afraid the best way to debug this is usually to get an strace -f of everything and slog through it
[13:29] <cjwatson> I've done it before, I can probably have a go if need be
[13:29] <pitti> cjwatson: it does have DEBIAN_HAS_FRONTEND=1
[13:29] <cjwatson> Which means that the debconf confmodule won't launch its own
[13:30] <pitti> cjwatson: strace -x is http://paste.ubuntu.com/1013051/
[13:30] <pitti> err, sh -x
[13:30] <pitti> getting strace now
[13:30] <cjwatson> You might need something along the lines of ubiquity.install_misc.debconf_disconnect
[13:30] <cjwatson> Oh, yeah, that doesn't look right
[13:31] <cjwatson> Can you paste the script that you're -x-ing there?
[13:32] <pitti> cjwatson: http://paste.ubuntu.com/1013056/
[13:33] <pitti> cjwatson: (the old one called jockey-text -a)
[13:34] <pitti> erk, strace says "operation not permitted"; I guess something is already tracing it
[13:34] <cjwatson> Try adding 'env -u DEBIAN_HAS_FRONTEND -u DEBCONF_REDIR DEBIAN_FRONTEND=noninteractive' to the start of that DEBCONF_DB_REPLACE=... command; you need it to start a new frontend
[13:35] <cjwatson> And to reconnect to it properly
[13:37] <pitti> cjwatson: yay, that works
[13:37] <pitti> -u DEBCONF_REDIR was the trick apparently
[13:37] <pitti> cjwatson: many thanks!
[13:39] <cjwatson> pitti: It'd probably have been all three (well, at least the first two).  You're welcome.
[13:39] <cjwatson> I wouldn't recommend paring that down to any fewer sets/unsets.
[13:40] <pitti> cjwatson: I meant, ubuntu-drivers already sets DEBIAN_FRONTEND and removes DEBIAN_HAS_FRONTEND (that was copied from the old jockey code); but I'll now keep all three of them together
[13:42] <cjwatson> Oh, it does?  OK.  Just as long as you do that before loading the confmodule.
[13:42] <pitti> right, that wasn't the case (and part of the problem presumably)
[13:42] <cjwatson> Personally I prefer to do this outside whatever scripts load the confmodule, to avoid confusion with the confmodule re-execing the calling script.
[13:42] <cjwatson> Though that's only a problem with the shell confmodule.
[13:42] <pitti> I just moved it all to simple-plugins, so that the env setup is in one place, before loading confmodule
[13:43] <pitti> doing it in ubuntu-drivers is both too late, as well as confusing/wrong, as you might want to use it outside of ubiquity, too
[13:43] <cjwatson> Right; this is an integration problem, rather than something intrinsic to ubuntu-drivers.
[13:45]  * pitti does a fresh boot/test run now
[13:55] <seb128> is anyone on precise using proposed who could ack that software-center 5.2.2.1 still works fine for them on bug #1002271?
[13:55] <seb128> (5.2.2 moved to -updates with a regression and the regression fixes is blocked on verification)
[13:55] <seb128> (better if you have the bug mentioned and confirm the update fixes it)
[14:00] <hallyn> slangasek: would you have any objection to moving the qemu-utils package to qemu-linaro?
[14:00] <hallyn> hm, i guess that might not work :)  i'm being silly
[14:01] <hallyn> just trying to think how best to line up with what debian is doing (with separate qemu source package providing qemu-utils)
[14:02] <mdeslaur> seb128: sure, one sec
[14:03] <seb128> mdeslaur, thanks
[14:03] <apw> cjwatson, was just using bzr merge-package and it is now telling me it is deprecated, does that imply use of bzr merge lp:debian/<package> is now the approved way
[14:04] <xnox> apw: yes
[14:05] <pitti> ev: https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744 is tried and tested now; thanks for your help!
[14:05] <apw> xnox, thanks
[14:05] <xnox> apw: also note about 'smart quilt handling' it will unapply patches before merging.
[14:06]  * ev looks
[14:06] <apw> xnox, handy indeed
[14:16] <slangasek> hallyn: I don't think I would, no
[14:42] <vsingh165> need help building a test package for nautilus, please
[14:42] <vsingh165> I'm following these instructions:  http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
[14:43] <apw> slangasek, got a sec to look at a branch for me?  i was just merging pciutils from debian and 1) i wanted to make sure what i did made sense, and 2) if it does i think that means there is no longer a delta (they did merge your changes by the look of things) and what does one do then: lp:~apw/ubuntu/quantal/pciutils
[14:47] <xnox> apw: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~apw/ubuntu/quantal/pciutils/".
[14:48] <apw> slangasek, xnox: damn lp:~apw/ubuntu/quantal/pciutils/debian-merge
[14:48] <cjwatson> I can't speak for 1); if 2) is true, then 'syncpackage -f -d unstable pciutils'
[14:48] <apw> stupid namespace restrictions which just hurt my head
[14:49] <cjwatson> (i.e. we don't use bzr to do syncs)
[14:50] <apw> cjwatson, yep ... makes sense, as steve did the last set of changes hopefully he can confirm we do indeed have no delta
[14:50] <xnox> apw: no delta
[14:50] <xnox> $ bzr diff --old lp:debian/pciutils --new lp:~apw/ubuntu/quantal/pciutils/debian-merge | diffstat
[14:50] <xnox> Most recent Debian version: MISSING
[14:50] <xnox>  changelog |    6 ++++++
[14:50] <xnox>  1 file changed, 6 insertions(+)
[14:51] <xnox> apw: why is there no maintainer field update? =)
[14:51] <apw> xnox, _assuming_ i did the merge right
[14:52] <Laney> there should be more diff than that in the changelog, if merged using bzr
[14:52] <apw> Laney, the only thing in the changelog is the 6 lines saying i did the merge
[14:53] <apw> Laney, and when i compared the two trees i found nothing to report as 'remaining changes'
[14:53] <apw> xnox, i think the bzr vis output also says that i'd expect no delta, so i think i am right
[14:53] <Laney> how did you do the merge? I just mean that if you used 'bzr merge' then it would have merged all of the old changelog entries in too.
[14:54] <Laney> and if not, then a by hand merge might have gone wrong :P
[14:54] <xnox> apw: when I do merge locally I have a few conflicts.
[14:54] <apw> Laney, well i'd agree except that for the most recent upstream update, they merged our tree in
[14:54] <xnox> how did you resolve pci.ids update-pciids.sh
[14:55] <Laney> i see, if they took our changelog then this would happen too
[14:55] <apw> xnox, pci.ids i took wholesale from debian as its actually an imported file, so merging it makes no sense and theirs was newer
[14:56] <apw> xnox, update-pciids.sh i compared in its unpatched state and they do not differ
[14:56] <apw> xnox, i think the delta there is actually false, its a fileid missmatch _i_think_ but ... i am here to make sure i did it right, and may well not have done
[14:58] <barry> join #ubuntu-desktop
[15:00] <xnox> apw: I wold sync.
[15:00] <xnox> I would sync.
[15:00] <apw> xnox, thanks, i think i agree with that too :)
[15:07] <apw> xnox, i assume that appropritate even if you are going to get a delta back shortly
[15:08] <cjwatson> apw: yes
[15:08] <cjwatson> we like syncing where it's possible to do so without losing Ubuntu patches
[15:10] <apw> cjwatson, and i assume once i run this syncpackage it will get seen by someone who can call me stupid
[15:10] <Laney> if you can't upload then you want to use 'requestsync' instead
[15:10] <Laney> syncpackage may direct you thus
[15:10] <apw> ahh ...
[15:10] <cjwatson> If you have upload rights, syncpackage is entirely self-service
[15:11] <cjwatson> So in that case it won't get seen except after the fact
[15:11] <cjwatson> I see you have upload rights to pciutils
[15:14] <apw> cjwatson, yes indeed.  right one last sanity check and i am hitting it
[15:23] <pitti> ogasawara: hey Leann, how are you?
[15:24] <ogasawara> pitti: Hi martin, just saw your email about the apport hook for the backport kernels
[15:24] <larsduesing> could anybody competent have a look at my try of a merge from debian-sid to quantal of aiccu?
[15:24] <larsduesing> http://bazaar.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/revision/17
[15:24] <pitti> ogasawara: would it be ok/desirable to treat all the packages in https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport as semi-official wrt. apport-bug? In that case I can just declare that PPA a "native origin", i. e. a package source that apport accepts
[15:25] <ogasawara> pitti: yes I think we want to consider them semi-official and would want to allow bug reporting for all the packages appearing there
[15:25] <pitti> ogasawara: i. e. I can do that, or just accept the kernel from that PPA, or accept a kernel package with any particular naming pattern
[15:25] <ogasawara> bryce_: ^^ I'm assuming you want ubuntu-bug style bug reporting for the backported X packages in the PPA?
[15:29] <bdmurray> pitti: could you look at bug 1004029?
[15:29] <pitti> bdmurray: yes, that's on my list (nice description BTW!)
[15:29] <bdmurray> pitti: thanks ;-)
[15:33] <pitti> ogasawara, bryce_: I followed up to bug 1004101; please let me know there what you prefer
[15:33] <ogasawara> pitti: ack, I'll add a comment for the kernel preference there
[15:49] <vsingh165> Hi, I'm trying to test a fix for nautilus and I can't build the test package.  I'm following the wiki's instructions but with no luck:  http://pastebin.com/sv3CKS35
[15:52] <asomething> vsingh165, the key line there is "dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/nautilus_3.2.1-2ubuntu12.diff.Ns16hs"
[15:52] <asomething> run dpkg-source --commit and it will format your changes for you in a nice patch under debian/patches
[15:53] <vsingh165> but will that submit the change to the package on the repos?
[15:53] <vsingh165> sorry, I'm new.
[15:53] <asomething> nope. I can see why commit sounds scary though.
[15:54] <vsingh165> yeah...I just recently started contributing.  I do know my programming, and love Linux, but am unfamiliar with all this package build stuff.  Thanks for your help.
[15:55] <vsingh165> trying it now
[15:58] <tsdgeos> anyone knows which piece of code reacts to cursor-theme changes in org.gnome.desktop.interface ?
[16:09] <vsingh165> asomething: it failed again http://pastebin.com/jHJgsDyN
[16:10] <vsingh165> asomething: apparently, it can't even read the file that dpkg-source --commit had me create
[16:11] <asomething> vsingh165, hmmm... I'm not sure about that one. I'm actually in a meeting in another channel so I can't really look too closely. Maybe someone else can help you out. Sorry
[16:11] <vsingh165> asomething: ok.
[16:13] <larsduesing> wahh
[16:14] <larsduesing> can anybody help me: why is .pc in my patch?!? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/107823
[16:15] <larsduesing> I did all like http://developer.ubuntu.com/packaging/html/udd-merging.html
[16:24] <sil2100> Hi!
[16:24] <sil2100> I would need some info regarding quantal and the packages that are to land in quantal PPA's
[16:25] <sil2100> Since during investigation of a build problem in unity on quantal, I noticed that the boots library that's the default (1.46) is a bit too old for the gcc toolchain we are using
[16:25] <sil2100> We would essentially need boost 1.48 on quantal
[16:25] <sil2100> The new g++ toolchain is more standard compliant it seems and breaks, for instance, shared_ptr
[16:26] <cjwatson> quantal has boost 1.49
[16:26] <sil2100> cjwatson: exellent - but the default is 1.46 still?
[16:26] <cjwatson> not AFAICS
[16:26] <cjwatson> it *has* boost 1.46, but libboost-dev points to 1.49
[16:27] <cjwatson> perhaps you're explicitly build-depending on libboost1.46-dev or some such
[16:27] <sil2100> Ah!
[16:27] <sil2100> Need to check unity packaging for that
[16:27] <cjwatson> in which case, don't do that :)
[16:27] <sil2100> Since on my quantal chroot after doing build-dep for unity, I got boost 1.46 installed
[16:27] <sil2100> But this might indeed be the case
[16:28] <cjwatson> Yeah, that's the fault of unity's Build-Depends
[16:28] <cjwatson> ..., libboost1.46-dev, libboost-serialization1.46-dev, ...
[16:28] <sil2100> Ok, but now it all makes sense - I wonder actually why it's not just libboost-dev
[16:28] <cjwatson> probably should just s/1\.46//g there
[16:29] <cjwatson> maybe with >= 1.46
[16:29] <sil2100> cjwatson: thanks!
[16:29] <cjwatson> (or whatever)
[16:29] <cjwatson> you're welcome
[16:29] <ev> pitti, apw, seb128: hi :)
[16:29] <seb128> ev, hey ;-)
[16:29] <pitti> so, bug 984944 was fixed in quantal only
[16:30] <seb128> pitti, is whoopsie using the same "don't report" rules than apport?
[16:30] <pitti> i. e. for precise you may still get crash reports that apply to a running binary which is already fixed
[16:30] <pitti> seb128: yes
[16:31] <pitti> well, it's supposed to, anyway
[16:31] <ev> is the motivation for this just because we can't accurately tell the version, or is there concern about things like firefox
[16:31] <ev> where upgrading underneath it breaks the universe
[16:31] <pitti> see the bug
[16:31] <ev> ah
[16:31] <apw> pitti, presumably /proc/$$/exe points to the real binary if we replace it?
[16:31] <ev> indeed, just did :)
[16:31] <ev> right
[16:31] <pitti> seems we got quite a lot of crashes where the user already upgraded to the new version
[16:32] <pitti> but the previous binary was still running
[16:32] <pitti> then it crashed
[16:32] <ev> okay, I'm happy then
[16:32] <pitti> and apport claimed it would still affect the new version
[16:32] <pitti> and thus generating new duplciates for the newer version
[16:32] <pitti> which doesn't make sense
[16:32] <ev> right
[16:32] <ev> thanks for fixing that
[16:33] <pitti> right, so mark_report_upload() (which triggers whoopsie) is called after UnreportableReason check
[16:33] <pitti> so whoopsie should not see those either
[16:34] <apw> lrwxrwxrwx 1 apw apw 0 May 29 17:33 /proc/4175/exe -> /home/apw/tmp/test (deleted)
[16:34] <pitti> apw: I compare that time stamp against the mtime of the actual binary, AFAIR
[16:34] <apw> pitti, ok sounds good ...
[16:35] <pitti> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296
[16:35] <pitti> exe_mtime = os.stat('/proc/%s/exe' % pid).st_mtime
[16:35] <ev> pitti: check_unreportable happens after mark_report_upload as we still want to upload crashes that would normally be rejected on launchpad because of outdated packages
[16:35] <pitti> process_start = os.lstat('/proc/%s/cmdline' % pid).st_mtime
[16:35] <pitti> ev: actually, it's not even using UnreportableReason; it's checked right in the "apport" program, i. e. it won't even write a .crash file
[16:36] <ev> ohhhh, right
[16:36] <ev> okay nevermind then
[16:36] <pitti> meh, this is my pet project, and I don't know the whole code by heart any more..
[16:36] <pitti> apport clearly grew way too big :)
[16:37] <ev> or it grew contributors
[16:37] <apw> ev, ok so we're back to that bug not being fixed :)
[16:37] <ev> apw: and work not having to go into errors.ubuntu.com. Win.
[16:37] <ev> well, for certain definitions of win
[16:37] <ev> I need to stop rooting for the crashes
[16:37] <pitti> so should we backport this to precise?
[16:38] <ev> seems harmless enough
[16:38] <seb128> apw, this apport change is in q only
[16:38] <seb128> apw, not in precise
[16:38] <apw> oh poop ... hmm
[16:38] <pitti> I have two other bugs to work on which apply to precise, so I'll do an SRU by EOW anyway
[16:39] <ev> pitti: rockstar, cheers
[16:39] <pitti> added a precise task
[16:41] <apw> pitti, i assume that ExecutableTimestamp: 1333654544
[16:41] <apw> pitti, that that is an accurate timestamp on the binary we are running right ?
[16:42] <apw> ev, the installed binaries carry the timestamp in the .deb, so we ought to be able to work it out
[16:42] <pitti> apw: yes, it's st_mtime of what /proc/pid/exe points to
[16:43] <pitti> i. e. the value of ExecutablePath: in the report
[16:43] <cjwatson> apw: if we still have the .debs around ...
[16:43] <apw> cjwatson, yeah if ...
[16:57] <pitti> good night everyone
[18:05] <henrix> RAOF: not sure if you're the right person to ask... we have a bunch of pkgs that landed on the wrong component in -proposed
[18:09] <dupondje> SpamapS: updated the remmina bug
[18:18] <SpamapS> dupondje: thanks!
[18:20] <PaoloRotolo> Hi all!
[18:22] <JonEdney> Howdy PaoloRotolo
[18:23] <PaoloRotolo> JonEdney, hi
[18:25] <bdmurray> dupondje: the freerdp bug would benefit from the same description modification
[18:26] <dupondje> bdmurray: i'll do after food :)
[18:30] <bdmurray> dupondje: great, thanks!
[19:01] <seb128> bdmurray, hey, not sure how you accepted the gnome-control-center SRU the other day but the bugs didn't tagged verification-needed
[19:02] <bdmurray> seb128: which numbers? I'll take a look at the code and them
[19:04] <seb128> bdmurray, that SRU, https://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.2
[19:04] <seb128> bug #1004384
[19:04] <seb128> bug #980317
[19:05] <seb128> bdmurray, thanks
[19:07] <bdmurray> seb128: weird the same tool is adding the tags to bugs I've done today
[19:08] <seb128> bdmurray, not sure if you use the same tool as the other SRU team members are using or if you changed it but that's the first time I see SRU bugs non tagged in a long time
[19:08] <bdmurray> seb128: the same tool and I'll look into it some more
[19:09] <seb128> ok, if that only happened once maybe don't bother much, I will ping you if I see that happening again
[19:11] <bdmurray> seb128: thanks, and I'll verify they get tagged for a while
[19:31] <seb128> bdmurray, SpamapS, RAOF, slangasek: one of you might want to send an email to ubuntu-devel(-announce) about SRU rules being stricted, that would probably spare work compared to having to go through 90% of the uploaded packages to add comments saying that
[19:52] <dupondje> bdmurray: description updated!
[21:15] <cyphermox> eep, sorry, I uploaded the wrong .changes for freecad; this was meant to be a sync
[22:00] <cjwatson> henrix: if it's what I think you mean (linux*/oneiric), I'm dealing with it now
[22:00] <henrix> cjwatson: yep, that's it! :)
[22:00] <henrix> cjwatson: thanks