=== mwhudson_ is now known as mwhudson === raju is now known as ubufox [03:40] Good morning [03:43] pitti: isn't this a bit early, even for you? :) [03:44] yeah, I usually sleep another hour or so after my wife gets up, but couldn't any more [03:44] we have a thunderstorm here [03:46] A morning thunderstorm? [03:46] Curious [03:48] RAOF: it got high time for some rain, anyway :) [05:33] Good morning! [05:33] 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] good morning pitti ... yet more beer! [05:59] almost :) [06:00] rickspencer3: good morning to you! [06:00] now we need to get the daily tests going [06:00] good morning pitti :) [06:01] 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] rickspencer3: That could be because precise is released ... :-) [06:01] rickspencer3: oh, precise -- you should be looking at http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html :) [06:01] d'oh! [06:02] hence pitti | almost :) [06:02] stupid browser history [06:02] that omap4 linux is still there, I see [06:02] well, *close* to a beer ;) [06:02] yeah, seems the ti-omap kernel guys don't like that package, it ceases to exist at every other upload === vibhav is now known as Guest59295 [06:53] good morning === smb` is now known as smb === zumbi_ is now known as Guest88650 [07:31] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [08:22] 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:22] Launchpad bug 999522 in qt4-x11 (Ubuntu) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,New] [08:27] tsdgeos, do you know why it hasn't been accepted upstream? [08:27] dholbach: upstream=Qt? [08:27] dholbach: it *has* been accepted upstream [08:27] ahhhh [08:27] ok [08:27] sorry, I misread [08:28] is it in Q already? [08:29] 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] ok, I see [08:29] I can help you get it into Q, which is one of the first steps of https://wiki.ubuntu.com/StableReleaseUpdates [08:30] tsdgeos, would you mind adding some information to the bug report according to the documentation? [08:30] i can try [08:30] cool, thanks a bunch [08:30] not sure what's missing though :D [08:31] impact of the bug, test-case, possibility of regressions, etc. [08:31] test case is the most important one [08:31] 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] there's a link to the bug and there's a test case there [08:32] it must be in the Ubuntu bug [08:32] i can copy & past if that's what you want [08:32] SRU verification is a bottleneck and it's important for uploaders to cooperate in keeping it smooth [08:33] c&p done [08:37] tsdgeos, is there a way to get the resulting patch from https://codereview.qt-project.org/#change,24361 easily? :) [08:37] You actually only want https://codereview.qt-project.org/#patch,unified,24361,12,src/gui/kernel/qdnd_x11.cpp [08:38] since we don't ship the unittests [08:38] well, qt doesn't ship the unittests [08:38] so we don't etiher [08:38] ok, thanks [08:39] If it helps [08:39] there's http://qt.gitorious.org/qt/qt/commit/c3eb2e63425c47b8e3eeb7416e225fab10c5c15a too [08:39] perfect [08:40] I don't use git very often, nor the codereview.qt page :) [08:41] 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] dholbach: updated https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/999522 [08:42] Launchpad bug 999522 in qt4-x11 (Ubuntu) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,New] [08:42] thanks tsdgeos === Guest59295 is now known as vibhav [09:09] 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] Launchpad bug 999522 in qt4-x11 (Ubuntu Quantal) "[SRU] Fix problems in Qt dragging when all of the window target has been shaped out for input" [Undecided,Triaged] https://launchpad.net/bugs/999522 [09:09] debfx, that'd be awesome [09:10] tsdgeos, does this only need to be fixed in quantal and precise? [09:10] 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] ok, I just saw that somebody added bug tasks for precise as well, so we're all set [09:14] great :) tx [09:31] broder: could it be that backportpackage doesn't pass -v0 when the package is NEW in the destination release? [09:34] ev: hey Evan, how are you? [09:35] ev: I'd appreciate a quick look at https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744 [09:35] I'm good, how are you? [09:35] sure [09:35] ev: I'm great, thanks! had a nice weekend, and you? [09:35] yeah, loving this sunny weather [09:35] ev: in particular, I'm interested how ubiquity gets the jockey-text -a auto-install drivers into teh target system [09:35] ev: by copying the installed bits from the live system, or running the plugins again in /target [09:36] ev: will respond to your retracing mail ASAP [09:36] thanks [09:36] * ev looks over the merge [09:38] ev: I have the full install syslog, in case you want to take a look [09:38] pitti: debconf doesn't like multiple things talking to it [09:39] 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] err [09:39] DEBCONF_DB_REPLACE=configdb DEBCONF_DB_OVERRIDE="Pipe{infd:none outfd:none}" ubuntu-drivers autoinstall [09:40] ev: ah, that's why you restart the jockey-backend with those [09:40] precisely [09:41] ev: ok, that explains the man-db error; I'll fix that [09:41] cheers [09:41] ev: so is it expected that my /target doesn't have bcmwl-kernel-source? [09:43] pitti: you'll also need to replicate jockey/debian/jockey.ubiquity [09:43] so that the packages get installed in the /target as well [09:43] ev: ah, that was my question [09:43] ev: so the plugins don't run again in /target [09:44] pitti: nope, there's no guarantee that /target exists when a plugin is run [09:44] especially for ubi-prepare, which occurs before partitioning [09:44] plugins can define stuff that happens post-install [09:44] ev: I mean, the targets run only once, and we don't run ubuntu-drivers/jockey again in /target later on [09:45] (i.e. subclass plugin.InstallPlugin) [09:45] ah indeed [09:45] ev, cjwatson: ack, so I'll provide the counterpart of jockey/debian/jockey.ubiquity [09:45] I forgot about that one [09:45] dunno if that's what's wanted here, haven't looked at the diff [09:46] cjwatson: right, I just needed to refresh my memory how drivers got into /target [09:46] yeah, if jockey.ubiquity is a target-config hook, that's preferable to code directly in ubiquity [09:47] cjwatson: right, jockey-common ships a /u/l/ubiquity/target-config/31jockey_packages [09:47] I'll put a corresponding script into ubuntu-drivers-common [09:49] 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] ev: it calls apt-install, which will install the given package into /target, I presume [09:49] that's my understanding, yes [09:49] good, thanks [09:50] I'll give it another full test run with both changes then (debconf env and hook) [09:52] cheers [09:52] I've updated the MP with this discussion === JanC_ is now known as JanC [10:31] can somebody please reject https://code.launchpad.net/~logatron/ubuntu/quantal/imagemagick/fix-for-993041/+merge/107156? (patch sent to debian instead) [10:31] dholbach: done [10:31] thanks pitti === Pendulum_ is now known as Pendulum === MacSlow is now known as MacSlow|lunch === Guest55695 is now known as Pici [12:10] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:25] 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] get to zero? [12:26] this site supports my findings https://wiki.kubuntu.org/Kernel/Debugging/Backlight [12:26] i'm on ubuntu 10.04 [12:27] sounds like a kernel issue [12:30] ogra_, i think it is more ubuntu related... [12:31] Benkinooby, well, that file contents are controlled by the kernel [12:31] ogra_, when reading the website what does "disassembled DSDT" mean? [12:31] ogra_, ok, didn't know that [12:32] ah, ok found some hints on google [12:32] DSDT is part of your bios [12:32] its the table defining what HW your machine has [12:34] 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] no idea, i dont use intel hardware :) [12:35] but that might or might not help, i would ask some ACPI/kernel-powermanagement expert ;) [12:35] ogra_, where can i find them, do you know? [12:36] probably in #ubuntu-kernel [12:36] 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] ogra_, but i'll go for that kernel channel for now :) [12:37] try ubuntu-devel-discuss then === MacSlow|lunch is now known as MacSlow [12:37] ogra_, thank you for helping me on [12:37] 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] or the ubuntu-kernel ML :) === _salem is now known as salem_ === dendroba` is now known as dendro-afk [13:10] 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] short question: until when can I get a debian-package into quantal-universe? === zyga is now known as zyga-afk [13:15] larsduesing: you want to be considering Feature Freeze as the deadline [13:15] ok [13:15] larsduesing: easy till FeatureFreeze (around Aug 23rd), after that you need a freeze exception [13:16] (I have the problem that it is in state "won't compile" - in kfreebsd... ) [13:16] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667755 [13:16] Debian bug 667755 in src:aiccu "aiccu: FTBFS[kfreebsd]:" [Serious,Open] [13:18] 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] yes [13:19] I'm aware of that [13:19] but it won't get to debian unstable - because it won't compile on kfreebsd [13:20] it already is in unstable [13:20] oh [13:20] wait [13:21] "won't compile on kfreebsd" is the sort of thing that impedes migration to testing, not to unstable. [13:22] sorry... [13:22] 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] You should probably use apt-install rather than apt-get directly, unless you need the package to be installed immediately. [13:22] ev: do you know of any plugins which install packages? [13:23] cjwatson: ah, that'll work for the live system, too? [13:23] No, apt-install is "queue for installation in target" [13:23] cjwatson: right, but simple-plugins installs driver packages (such as bcmwl-kernel-source) into the live system, in ubi-prepare [13:23] 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] Oh [13:24] that currently calls jockey-text -a, and has some custom code to launch the d-bus backend with some magic debconf env [13:24] You would have to be careful to do anything like that before the main business of copying stuff starts, I think [13:24] Maybe [13:24] And even then it would need a separate debconf db [13:24] yes, it's done after checking "3rd party drivers" and finishes before the partitioning screen [13:25] The only stock plugin that installs packages is, I think, usersetup (oem-config-*) [13:25] Ok, another question... how to debug apport-plugins? (at the moment I do a kill -SIGFPE to get apport to run...) [13:25] 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] Right, which is "temporary throwaway db" [13:26] larsduesing: unless your hook depends on a crash, you can use "apport-bug packagename" [13:26] and I can halt any transfer to launchpad there, too? [13:27] 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] larsduesing: yes, just don't click on "submit" [13:27] 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] I see... being too cautious [13:28] thanks [13:28] cjwatson: I guess the bad fd is due to fd 3 pointing to its own directory for some reason [13:28] 3 would be the file descriptor that's expected to be usable for writing to the debconf frontend [13:28] right [13:28] 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] I'm afraid the best way to debug this is usually to get an strace -f of everything and slog through it [13:29] I've done it before, I can probably have a go if need be [13:29] cjwatson: it does have DEBIAN_HAS_FRONTEND=1 [13:29] Which means that the debconf confmodule won't launch its own [13:30] cjwatson: strace -x is http://paste.ubuntu.com/1013051/ [13:30] err, sh -x [13:30] getting strace now [13:30] You might need something along the lines of ubiquity.install_misc.debconf_disconnect === carif_ is now known as carif [13:30] Oh, yeah, that doesn't look right [13:31] Can you paste the script that you're -x-ing there? [13:32] cjwatson: http://paste.ubuntu.com/1013056/ [13:33] cjwatson: (the old one called jockey-text -a) === bregma_ is now known as bregma [13:34] erk, strace says "operation not permitted"; I guess something is already tracing it [13:34] 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] And to reconnect to it properly [13:37] cjwatson: yay, that works [13:37] -u DEBCONF_REDIR was the trick apparently [13:37] cjwatson: many thanks! [13:39] pitti: It'd probably have been all three (well, at least the first two). You're welcome. [13:39] I wouldn't recommend paring that down to any fewer sets/unsets. [13:40] 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] Oh, it does? OK. Just as long as you do that before loading the confmodule. [13:42] right, that wasn't the case (and part of the problem presumably) [13:42] 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] Though that's only a problem with the shell confmodule. [13:42] I just moved it all to simple-plugins, so that the env setup is in one place, before loading confmodule [13:43] 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] 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] 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] Launchpad bug 1002271 in software-center (Ubuntu) "REGRESSION: crash in cell renderer" [Medium,In progress] https://launchpad.net/bugs/1002271 [13:55] (5.2.2 moved to -updates with a regression and the regression fixes is blocked on verification) [13:55] (better if you have the bug mentioned and confirm the update fixes it) [14:00] slangasek: would you have any objection to moving the qemu-utils package to qemu-linaro? [14:00] hm, i guess that might not work :) i'm being silly [14:01] just trying to think how best to line up with what debian is doing (with separate qemu source package providing qemu-utils) [14:02] seb128: sure, one sec [14:03] mdeslaur, thanks [14:03] 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/ is now the approved way [14:04] apw: yes [14:05] ev: https://code.launchpad.net/~pitti/ubiquity/ubuntu-drivers-common/+merge/107744 is tried and tested now; thanks for your help! [14:05] xnox, thanks [14:05] apw: also note about 'smart quilt handling' it will unapply patches before merging. [14:06] * ev looks [14:06] xnox, handy indeed === zyga-afk is now known as zyga [14:16] hallyn: I don't think I would, no [14:42] need help building a test package for nautilus, please [14:42] I'm following these instructions: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html [14:43] 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] apw: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~apw/ubuntu/quantal/pciutils/". [14:48] slangasek, xnox: damn lp:~apw/ubuntu/quantal/pciutils/debian-merge [14:48] I can't speak for 1); if 2) is true, then 'syncpackage -f -d unstable pciutils' [14:48] stupid namespace restrictions which just hurt my head [14:49] (i.e. we don't use bzr to do syncs) [14:50] cjwatson, yep ... makes sense, as steve did the last set of changes hopefully he can confirm we do indeed have no delta [14:50] apw: no delta [14:50] $ bzr diff --old lp:debian/pciutils --new lp:~apw/ubuntu/quantal/pciutils/debian-merge | diffstat [14:50] Most recent Debian version: MISSING [14:50] changelog | 6 ++++++ [14:50] 1 file changed, 6 insertions(+) [14:51] apw: why is there no maintainer field update? =) [14:51] xnox, _assuming_ i did the merge right [14:52] there should be more diff than that in the changelog, if merged using bzr [14:52] Laney, the only thing in the changelog is the 6 lines saying i did the merge [14:53] Laney, and when i compared the two trees i found nothing to report as 'remaining changes' [14:53] xnox, i think the bzr vis output also says that i'd expect no delta, so i think i am right [14:53] 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] and if not, then a by hand merge might have gone wrong :P [14:54] apw: when I do merge locally I have a few conflicts. [14:54] Laney, well i'd agree except that for the most recent upstream update, they merged our tree in [14:54] how did you resolve pci.ids update-pciids.sh [14:55] i see, if they took our changelog then this would happen too [14:55] 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] xnox, update-pciids.sh i compared in its unpatched state and they do not differ [14:56] 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] join #ubuntu-desktop [15:00] apw: I wold sync. [15:00] I would sync. [15:00] xnox, thanks, i think i agree with that too :) [15:07] xnox, i assume that appropritate even if you are going to get a delta back shortly [15:08] apw: yes [15:08] we like syncing where it's possible to do so without losing Ubuntu patches [15:10] cjwatson, and i assume once i run this syncpackage it will get seen by someone who can call me stupid [15:10] if you can't upload then you want to use 'requestsync' instead [15:10] syncpackage may direct you thus [15:10] ahh ... [15:10] If you have upload rights, syncpackage is entirely self-service [15:11] So in that case it won't get seen except after the fact [15:11] I see you have upload rights to pciutils [15:14] cjwatson, yes indeed. right one last sanity check and i am hitting it [15:23] ogasawara: hey Leann, how are you? [15:24] pitti: Hi martin, just saw your email about the apport hook for the backport kernels [15:24] could anybody competent have a look at my try of a merge from debian-sid to quantal of aiccu? [15:24] http://bazaar.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/revision/17 [15:24] 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] 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] 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] bryce_: ^^ I'm assuming you want ubuntu-bug style bug reporting for the backported X packages in the PPA? [15:29] pitti: could you look at bug 1004029? [15:29] Launchpad bug 1004029 in apport (Ubuntu Precise) "apport-collect does not work for bugs with only a linux task" [High,Triaged] https://launchpad.net/bugs/1004029 [15:29] bdmurray: yes, that's on my list (nice description BTW!) [15:29] pitti: thanks ;-) [15:33] ogasawara, bryce_: I followed up to bug 1004101; please let me know there what you prefer [15:33] Launchpad bug 1004101 in apport (Ubuntu) "[RFE] Allow Bug Reporting When Running Backport Kernel" [Medium,Incomplete] https://launchpad.net/bugs/1004101 [15:33] pitti: ack, I'll add a comment for the kernel preference there [15:49] 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] 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] run dpkg-source --commit and it will format your changes for you in a nice patch under debian/patches [15:53] but will that submit the change to the package on the repos? [15:53] sorry, I'm new. [15:53] nope. I can see why commit sounds scary though. [15:54] 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] trying it now [15:58] anyone knows which piece of code reacts to cursor-theme changes in org.gnome.desktop.interface ? [16:09] asomething: it failed again http://pastebin.com/jHJgsDyN [16:10] asomething: apparently, it can't even read the file that dpkg-source --commit had me create [16:11] 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] asomething: ok. [16:13] wahh [16:14] 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] I did all like http://developer.ubuntu.com/packaging/html/udd-merging.html [16:24] Hi! [16:24] I would need some info regarding quantal and the packages that are to land in quantal PPA's [16:25] 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] We would essentially need boost 1.48 on quantal [16:25] The new g++ toolchain is more standard compliant it seems and breaks, for instance, shared_ptr [16:26] quantal has boost 1.49 [16:26] cjwatson: exellent - but the default is 1.46 still? [16:26] not AFAICS [16:26] it *has* boost 1.46, but libboost-dev points to 1.49 [16:27] perhaps you're explicitly build-depending on libboost1.46-dev or some such [16:27] Ah! [16:27] Need to check unity packaging for that [16:27] in which case, don't do that :) [16:27] Since on my quantal chroot after doing build-dep for unity, I got boost 1.46 installed [16:27] But this might indeed be the case [16:28] Yeah, that's the fault of unity's Build-Depends [16:28] ..., libboost1.46-dev, libboost-serialization1.46-dev, ... [16:28] Ok, but now it all makes sense - I wonder actually why it's not just libboost-dev [16:28] probably should just s/1\.46//g there [16:29] maybe with >= 1.46 [16:29] cjwatson: thanks! [16:29] (or whatever) [16:29] you're welcome [16:29] pitti, apw, seb128: hi :) [16:29] ev, hey ;-) [16:29] so, bug 984944 was fixed in quantal only [16:29] Launchpad bug 984944 in apport (Ubuntu) "Reject crashes that happen right after upgrade" [Medium,Fix released] https://launchpad.net/bugs/984944 [16:30] pitti, is whoopsie using the same "don't report" rules than apport? [16:30] i. e. for precise you may still get crash reports that apply to a running binary which is already fixed [16:30] seb128: yes [16:31] well, it's supposed to, anyway [16:31] is the motivation for this just because we can't accurately tell the version, or is there concern about things like firefox [16:31] where upgrading underneath it breaks the universe [16:31] see the bug [16:31] ah [16:31] pitti, presumably /proc/$$/exe points to the real binary if we replace it? [16:31] indeed, just did :) [16:31] right [16:31] seems we got quite a lot of crashes where the user already upgraded to the new version [16:32] but the previous binary was still running [16:32] then it crashed [16:32] okay, I'm happy then [16:32] and apport claimed it would still affect the new version [16:32] and thus generating new duplciates for the newer version [16:32] which doesn't make sense [16:32] right [16:32] thanks for fixing that [16:33] right, so mark_report_upload() (which triggers whoopsie) is called after UnreportableReason check [16:33] so whoopsie should not see those either [16:34] lrwxrwxrwx 1 apw apw 0 May 29 17:33 /proc/4175/exe -> /home/apw/tmp/test (deleted) [16:34] apw: I compare that time stamp against the mtime of the actual binary, AFAIR [16:34] pitti, ok sounds good ... [16:35] http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2296 [16:35] exe_mtime = os.stat('/proc/%s/exe' % pid).st_mtime [16:35] 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] process_start = os.lstat('/proc/%s/cmdline' % pid).st_mtime [16:35] 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] ohhhh, right [16:36] okay nevermind then [16:36] meh, this is my pet project, and I don't know the whole code by heart any more.. [16:36] apport clearly grew way too big :) [16:37] or it grew contributors [16:37] ev, ok so we're back to that bug not being fixed :) [16:37] apw: and work not having to go into errors.ubuntu.com. Win. [16:37] well, for certain definitions of win [16:37] I need to stop rooting for the crashes [16:37] so should we backport this to precise? [16:38] seems harmless enough [16:38] apw, this apport change is in q only [16:38] apw, not in precise [16:38] oh poop ... hmm [16:38] I have two other bugs to work on which apply to precise, so I'll do an SRU by EOW anyway [16:39] pitti: rockstar, cheers [16:39] added a precise task [16:41] pitti, i assume that ExecutableTimestamp: 1333654544 [16:41] pitti, that that is an accurate timestamp on the binary we are running right ? [16:42] ev, the installed binaries carry the timestamp in the .deb, so we ought to be able to work it out [16:42] apw: yes, it's st_mtime of what /proc/pid/exe points to [16:43] i. e. the value of ExecutablePath: in the report [16:43] apw: if we still have the .debs around ... [16:43] cjwatson, yeah if ... [16:57] good night everyone === s1aden is now known as sladen [18:05] 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] SpamapS: updated the remmina bug [18:18] dupondje: thanks! [18:20] Hi all! [18:22] Howdy PaoloRotolo [18:23] JonEdney, hi [18:25] dupondje: the freerdp bug would benefit from the same description modification [18:26] bdmurray: i'll do after food :) [18:30] dupondje: great, thanks! [19:01]