=== ScottL_ is now known as ScottL [00:38] Hey. Are there any fellow DMB members kicking around with a few minutes to spare? [00:40] Laney? === dendrobates is now known as dendro-afk === ailo_ is now known as help === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === asac_ is now known as asac [03:09] pitti: I would be interested in your input on bug #722933 [03:10] Launchpad bug 722933 in cdbs (Ubuntu) "cdbs doc linking behavior is different when building with -b vs. -B" [High,Triaged] https://launchpad.net/bugs/722933 [03:21] slangasek: if you want my 2c, the correct solution is to walk the dependency chain when creating those symlinks [03:21] Chipzz: what dependency chain? You mean look at packages outside the current build? [03:21] I mean [03:22] libfoo-dev: depends: libfoo [03:22] the symlink should be from libfoo-dev to libfoo [03:23] that's what it already does [03:23] but it does so inconsistently where arch: all packages are concerned [03:24] sorry, rather late here and I didn't think my comment through 100% [03:24] probably should have shut up and not wasted your time ;) [03:24] no worries... :) [03:25] trying to recall the difference between arch: all and arch: any at 4AM tends to not be very productive ;p [03:25] I always get these 2 mixed up [03:26] the similarity between the 2 words is rather unfortunate [03:39] Chipzz: All means one package works on all archs (~same as rpm noarch). Arch any means you can build the package for any arch, but you have to built it for that arch. [03:40] ScottK: yeah, I can recall when I look it up :) the problem is having to look it up [03:40] which I didn't at 4AM ;P [03:40] Once I started thinking of it like that ^^^ I was finally able to remember it. YMMV. [03:41] I just thought of a better way ;) [03:42] .all.deb is sth that exists, .any.deb doesn't [03:42] so all refers to the archs it will be able to installed on [03:42] +be [04:43] scottk, hi [04:44] thanks for your feedback [04:44] poolie: Hello. [04:44] i think a debian/control field would work well [04:44] i'm just wondering how that would come to be set on a package: who would decide about it? [04:45] I think that can be decided on a team by team basis. [04:46] In my mind there's a huge difference between "Hey, if you don't use UDD someone will come and hunt you down if you didn't have a really good reason" and the package upload is impossible. [04:46] right [04:46] As long as it's put in debian/control and not hard coded in launchpad somewhere, we can iterate on how best to manage it. [04:47] and, indeed, there's another one to the left of that which is "let's make sure there's a bug explaining why it wasn't or couldn't be used" [04:47] Perhaps. [04:47] well, it can be on the server and still controllable by teams [04:48] Perhaps, but I think the package is a more natural place to find it. [04:48] ok [04:48] one draw back is that it would take one update per package to flip it [04:48] perhaps that's not a big deal [04:48] If it's a package someone wants to set this on, I doubt it's a big deal. [04:49] It'll be getting uploaded anyway. [04:49] I don't know about the need for filing a bug. Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get an ISO to build and needed to push a quick fix and didn't want to mess with bzr. [04:50] ok [04:50] For packages where UDD is problematic (e.g. kernels), the flag won't be set anyway. [04:50] can you tell me more about the "trying to get an iso to build" case? [04:50] Just an example where time is of the essence. [04:51] ok [04:51] i'll update the lep to suggest that then [04:51] Thanks. [04:51] should that warning come from dput, or soyuz, or maybe somewhere else? [05:00] poolie: do you think it's reasonable to assume that any package that a team wants built solely from branch will also be carrying ubuntu changes? [05:00] i guess if you need to build from a branch in the first place you almost certainly have a change of some sort [05:06] broder, it seems likely [05:07] though, i guess, that policy could carry over from one ubuntu cycle to the next even if there are no new changes from debian [05:07] oh look, someone beat me to the punch on-list [05:11] poolie: I'd suggest from dput parsing the .changes file. [05:20] scottk, that seems reasonable [05:21] as i said on the list this is not the first thing we need [05:21] i guess it's good to know there's a way to do it eventually [05:21] perhaps it should have been removed from the lep [05:21] Right, just recognize that some people are going to go ballistic at anything that smells of making this mandatory. [05:22] i know :) [05:23] i'd almost rather have it out there and answer it than have them suspect though [05:23] success for me here means having people use it and like it, not having them use it at any cost [05:28] I suspect that for people who tend to touch the same package or a few over and over this is a relatively easy sell. For people who work on different packages all the time, I think it's going to be harder because branching performance is more important. [05:29] right [05:29] we've worked on that and we'll do more [05:29] the idea that came up in January was basically that for people who _can_ use it, we ought to connect the dots all the way through [05:30] Which makes sense. [05:35] then we can come back and make things smoother or faster === foxxtrot_ is now known as foxxtrot [06:07] UDD? [06:07] Ubuntu Distributed Development [06:55] Good morning [06:58] slangasek: as we don't have access to the arch:all binaries on !i386, I don't see another way than the one you proposed [07:10] slangasek: is there any documentation about this "Multiarch: foreign" field? it seems very weird to me that you have to mark an arch:all package with that (regardless of what it does) [07:22] pitti: https://wiki.ubuntu.com/MultiarchSpec [07:22] pitti: specifically, https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages [07:25] ah, thanks; I wonder why this isn't already the implicit default behaviour for arch:all packages then [07:27] pitti: because of the explanation given there - existing packages can assume that the dependencies of the arch: all package are fulfilled by packages of the same architecture (think python + python extensions) [07:28] so if we suddenly change the behavior and let the dependencies be satisfied by packages from other architectures, things will break [07:32] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: cdbs [07:41] slangasek: you probably want the libx11 multiarch change to ubuntu as well? i've got a merge ready, could pull that in too [07:42] oh [07:42] it was uploaded already :) [07:50] tjaalton: yeah; I didn't want to step on anyone's toes by merging, but as I'm going to be looking at quite a lot of the X library stack in the coming days, if there are other libs you'd like me to merge up I'm happy to do so :) [08:01] slangasek: there shouldn't be any left, a bunch of them were synced on friday, and only a couple of them have ubuntu changes [08:01] so push the changes to debian and then we can sync again [08:01] depending on the package [08:01] slangasek: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html [08:02] that shows which packages have changes [08:02] tjaalton: right, I'll be pushing these changes directly to Debian first; there probably aren't too many packages I can actually change for this round, most of my work is still staged in ppa [08:03] good morning [08:07] slangasek: okay [08:20] good morning [08:21] 05:49 ScottK | It'll be getting uploaded anyway. [08:21] 05:49 ScottK | I don't know about the need for filing a bug. Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get [08:21] | an ISO to build and needed to push a quick fix and didn't want to mess with bzr. === hunger_ is now known as hunger [08:41] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [08:47] * dholbach hugs cdbs [08:47] patch pilots FTW! [08:59] thanks dholbach [09:00] dholbach: probably my last session of patch piloting before my exams :( [09:00] cdbs, all the best with your exams! [09:00] thanks dholbach [09:13] RAOF: X doesn't crash anymore with you packages, thanks :) [09:13] debfx: Awesomeo. === smb` is now known as smb [09:35] bdrung, hi === bdrung changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:hi === bdrung changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [09:36] hi [09:36] bdrung, you looked at the current debian/changelog, and you are not happy with what is looks like? [09:36] (stupid focus) [09:38] bdrung, using a new "*" doesnt look right to me [09:38] ricotz: yes [09:39] ricotz: why not? [09:39] has this something to do with make it work with a script? [09:39] ricotz: no, it's just common practice. [09:40] i my opinion it is a change to the debian packaging [09:40] so if there were only one commit you would have been happy with it? [09:41] no, it's not the number of commits. [09:41] look for example at http://packages.debian.org/changelogs/pool/main/p/portaudio19/current/changelog [09:41] since it is going to be merged to the real branch, the commit message can be pretty [09:42] bdrung, ok, this is done with git-dch? [09:42] ricotz: it's not about commit messages, it's about what's in debian/changelog [09:42] there are many styles to list the changes of a package [09:43] one "*" for every distinct change. you did two: keep the remaining changes from last merge and drop the win32 package [09:44] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gnupg/natty/revision/29/debian/changelog [09:44] the drop of the win32 package is not a subitem of "remaining change" [09:45] re the link: that were all remaining changes [09:45] https://launchpad.net/ubuntu/lucid/+source/gzip/+changelog [09:46] gzip (1.3.12-9) unstable; urgency=high [09:46] http://changelogs.ubuntu.com/changelogs/pool/universe/v/vlc/vlc_1.1.7-1ubuntu1/changelog === tkamppeter_ is now known as tkamppeter [09:46] pitti, hi [09:47] ricotz: there we have one old change "build and install the libx264 plugin" and a new one "v4l is gone from the kernel. Build only v4l2." [09:47] bdrung, have you looked a the gzip one? [09:48] https://launchpad.net/ubuntu/natty/+source/cpio/+changelog [09:48] bdrung, ^ this might be the most recent example [09:49] which is the same thing [09:50] ricotz: look at cpio 2.9-13ubuntu1 -> http://changelogs.ubuntu.com/changelogs/pool/main/c/cpio/cpio_2.11-6ubuntu1/changelog [09:50] ricotz: since that version, it is a "remaining change" [09:51] bdrung, now i see what you mean [09:52] bdrung, ok :), i will change this, anything besides that? [09:52] ricotz: probably not [09:59] bdrung, done [10:08] ricotz: uploaded [10:10] ricotz, thanks [10:11] soliloquy :) [10:14] i mean, bdrung, thanks ;) [10:26] erm [10:26] 2363 robertc 20 0 1182m 694m 1844 S 0 9.1 4:03.13 gnome-power-man [10:26] -not cool- [10:27] When managing power, the first step is accumulation: only once all power is claimed can it be distributed to others (and even that is risky) [10:29] gnome-power-robin-hood [10:30] accumulated power can get risky though (see lybia) [10:31] Riddell, ScottK, so what about QT ? FF is soon and there only seems to be a symbian related bug holding it up, could we get a package before FF ? [10:33] ogra: Isn't the difference between 4.7.1 and 4.7.2 covered by the "Upstream microreleases" clause from https://wiki.ubuntu.com/FeatureFreeze ? [10:34] might be, my concern is that we are waiting for a feature we need to test asap [10:36] ogra: feel free to package a git snapshot, I'll package 4.7.2 when it's out but I don't have time or need to do anything before [10:37] hmm [10:37] k [10:37] Riddell, just be aware that if NEON runtime detection doesnt work and we dont get a fix in by release i will have to turn it off statically again [10:38] to my knowledge it hasnt been tested upstream and the bugfix is only based on assumptions [10:44] I'm looking for a program that will accept input from stdin (from a GTK app) and display it in a window [10:47] mok0: zenity? [10:47] persia: hm, don't know that one... let me check it out [10:47] (you might have to fiddle a bit with redirects and such, but ...) [10:48] persia: the problem is, this graphical app outputs a lot of error info and such via stdout, but you don't see that if the app is started from the menu [10:48] (unless you look in .xsession-errors) [10:49] That sounds like the application itself needs to be fixed. It oughtn't do that. [10:49] Wrapping in a display tool doesn't strike me as ideal. [10:49] persia: me neither [10:50] persia: I could pipe the output to a file in the users home dir, but that doesn't strike me as ideal either [10:50] That's already implemented: .xsession-errors [10:50] persia: heh I completely forgot about that [10:51] persia: haven't worried about .xsession-errors for years [10:51] The application is still buggy, but if you're digging for the output for some reason, it is saved locally. [10:51] persia: I suppose it is partly to help developers [10:51] ogra: yeah, with KDE not compiling on ARM, Qt on ARM isn't much of a priority for me :( [10:52] tell that to the unity guys [10:52] persia: this program embeds Python, and the user is free to create scripts and so on; these output stuff on stdout [10:53] seems like the output is not properly redirected then [10:53] Ah, that's a different issue. That ought be trapped, etc. File an upstream bug: help them there if you have interest, as this will surely be invasive. [10:55] persia: I am working with them already, but I doubt they would give it any priority. It's quite slow to get even small patches accepted === ara_ is now known as ara [10:56] Well, architecturally, I'd probably approach the solution as follows: 1) trap stdout in the launched python scripts, and redirect to some internal buffer [10:56] 2) Add some window or view that allows users to view the internal buffer (or perhaps just some window into it) [10:56] persia: hm, xconsole might do the job [10:57] 3) Add some control to show/hide the window/view [10:57] persia: I agree that would be a good solution. But, as I said, I doubt the developer(s) would give it any priority. [10:58] xconsole doesn't seem like an ideal solution: you'd still have to trap/redirect stuff to /dev/console rather than inherited STDOUT (.xsession-errors), *AND* you break if someone has an actual device attached to /dev/console [10:58] persia: I think you can run xconsole with a different device, using the --file switch [11:00] You're planning to initiate a new pty? [11:00] persia: no, just wondering if it might work using a file [11:01] It won't: read the manpage. "This does not work on regular files ..." [11:01] persia: it actually does [11:02] persia: if I append to the file (using cat >> ) it appears in xconsole [11:02] * persia would be very suspicious and check the code path when the manpage says "this does not work" but it appears to work: there's probably N subtle bugs [11:02] but ugghh it's ugly :-) [11:03] persia: yes. It's a bad solution anyway [11:03] * mok0 ponders if he could use the notification system :-/ === diwic is now known as diwic_afk [11:04] persia: I would also have to deal with shutting down xconsole when the user quits the program. That would be quite hacky [11:05] Not if you write a good wrapper. Parent opens xconsole child, then opens other child, and waits. When other child exits, send signal to xconsole. [11:06] Annoying in shell, but not hard in other languages. [11:07] Could probably be done in Python ... [11:12] http://docs.python.org/library/subprocess.html [11:12] hey tkamppeter [11:13] persia: then I might as well write a wrapper program that opens a nicer window [11:14] Indeed :) [11:15] persia: Hm, I'll give it a thought. Seems like a nicer solution. There are other issues as well. The program is designed for users to navigate to their working directory, and then invoke the program from the CLI [11:16] persia: then it tries to read status files in that dir when starting [11:17] persia: but perhaps I can deal with that using python magic :-) === MacSlow is now known as MacSlow|lunch [11:32] pitti, around? [11:34] tkamppeter: yes; I was out for some errands and an appointment [11:40] pitti, I succeeded that the Debian maintainer accepted all my Ubuntu changes into the Debian package of foo2zjs (except apport hook). Now I want to merge back the Debian package before FF, but it does not appear on https://merges.ubuntu.com/f/. Will there still be a refresh before FF? [11:41] pitti, if not, is there a program for merging the debian/changelog? I do not want to do this manually. [11:41] tkamppeter: it's supposed to run [11:41] tkamppeter: you could try your luck with the new world's UDD branches [11:41] tkamppeter: i. e. check out lp:ubuntu/fo2zjs and bzr merge lp:debian/foo2zjs [11:41] (if the latter is current) [11:42] pitti, what are the "new world's UDD branches"? [11:42] tkamppeter: I don't know how practical this is for merging changelogs, but I have found vimdiff invaluable in the past for merging various other things [11:42] tkamppeter: using bzr merge on the ubuntu/debian imported branches [11:42] (if you know how to drive it, which isn't very dificult) [11:42] tkamppeter: "bzr lp-open lp:debian/foo2zjs" -> hm, this looks out of date [11:44] tkamppeter: personally, in these cases I just write a detailled summary of "Remainign Ubuntu changes:" into the changelog, and drop the older stuff [11:44] pitti, packages.debian.org already shows it and AFAIK the upload was Sunday. [11:44] tkamppeter: as this is only the apport hook now, that's easy to do [11:44] tkamppeter: the Debian changelog has the other changes from us already, after all [11:44] and the older changelogs remain on Launchpad as well, so they aren't lost [11:45] tkamppeter: i. e. take the Debian package, add the apport hook, and that's it [11:45] tkamppeter: btw, if you can commit to the debian repo, you could commit the apport hook there as well, and only install it when building under Ubuntu [11:45] pitti, OK, then I will simply do it this way. [11:46] tkamppeter: http://git.debian.org/?p=pkg-utopia/udisks.git;a=blob;f=debian/rules;h=82db4040c633833183d2f42576758ebbdba95152;hb=HEAD [11:46] tkamppeter: line 27 to 29 [11:46] erm, 25 - 28 [11:47] pitti, what is planned for the future is that I will make packages for Debian where someone at Debian sponsors the upload and after a certain amount of such uploads they want to make me DM, and then one lets all packages auto-sync in Ubuntu. WDYT? [11:48] tkamppeter: that sounds great [11:48] tkamppeter: that's what I do as well with most of my packages [11:50] pitti, so if in some time they will avaluate my DM approval, please add a good word for me. [11:50] my pleasure! [11:50] pitti, thanks for the help. [12:30] ScottK: postfix_2.8.0-1~build1 uploaded to natty [12:31] freshening things to build for sid now === jjohansen is now known as jj-afk [12:32] slangasek: I multiarch-foreign-ified binfmt-support in unstable - hope I did it right [12:32] will sync into Ubuntu in a bit === yofel_ is now known as yofel === MacSlow|lunch is now known as MacSlow === dendro-afk is now known as dendrobates [14:01] pitti, can you tell me what this retracer error means? https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/720895 [14:01] Error: Bug 720895 is private === zyga is now known as zyga-food [14:06] mdz, it means the retracing didn't give a valid stacktrace [14:07] seb128, can we guess why? [14:07] it seems to be happening with a number of bluetooth-applet crashes [14:07] hey mdz [14:07] #2 0x00007ffffe672e70 in ?? () [14:07] No symbol table info available. [14:07] those symbols are lacking [14:07] let me look at the procmaps [14:07] mdz: that's a bit misleading indeed, as the obsolete package really doesn't contribute to the stack trace being bad [14:08] mdz: but all in all it's better to err on this side rather than keeping bugs with useless stack traces open [14:08] * pitti checks the logs [14:09] mdz, the libdbusmenu debug symbols didn't work it seems [14:09] what the heck, it's missing two metric tons of debug symbols [14:09] pitti, the only revelant ones a libdbusmenu-glib3-dbgsym missing [14:09] http://paste.ubuntu.com/570585/ === dendrobates is now known as dendro-afk [14:10] oh, wait, this is misleading [14:10] that's noise added by a recent patch, that tries to find both -dbg and -dbgsym [14:12] pitti, can you see what libdbusmenu versions were installed? [14:12] * pitti fixes that in trunk [14:13] pitti, fix what? the -dbg thing? [14:13] seb128: the confusing warnings about missing -dbg packages [14:14] seb128: I can't see the installed libdbusmenu versions in the log, but it tries to install the one from Dependencies.txt [14:14] libdbusmenu-glib3 0.3.97-0ubuntu3 [14:15] pitti, can you see what dbgsym was brough in? [14:15] there was no version changes for some days before that crash [14:15] the ddeb binaries should have been current and working [14:15] or we are back to the gdb failing to load symbols issue we discussed yesterday [14:16] http://ddebs.ubuntu.com/pool/main/libd/libdbusmenu/ even has both still [14:16] seb128: if it's too old gdb, then it's a different breakage; https://i64539621.restricted.launchpadlibrarian.net/64539621/Stacktrace.txt doesn't complain anywhere about DWARF opcodes [14:17] mdz, can you trigger that crash easily? [14:17] seb128, it happens pretty regularly, debugging with cyphermox right now [14:17] but on the phone [14:17] ok === dendro-afk is now known as dendrobates [14:18] mdz, can you submit the crash and give me the number before it's retraced if you have a chance? [14:18] mdz, I want to try to retrace it manually to see what's going on [14:18] seb128, it may not be the same one but my most recent crash is https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/723166 [14:18] Error: Bug 723166 is private [14:18] mdz, I was going to suggest opening also a but with a stacktrace, seems a libdbusmenu issue [14:18] but->bug [14:18] then we can ping ted about it [14:19] but if cyphermox is debugging it that works as well [14:21] seb128: just telling him how to get to mdz's unretraced bug and how to use apport-retrace [14:21] pitti, I want to figure why the retracing is failing [14:22] pitti, debug symbols work locally, I've been doing indicator valgrind and gdb logs recently and didn't get issues [14:22] that'd be great; good luck! [14:22] danke [14:22] seb128: you could locally install gdb 6.8 and see whether that makes it fail? [14:22] as a first step for bisecting where the problem is [14:22] pitti, ok [14:23] seb128: if it's 6.8, then I'll move back the gdk-pixbuf and udisks issues that'd be next in my queue, and start debugging that in the fakechroots [14:29] why the heck isn't the apport-retrace auth thing working on the retracers [14:30] ok, let me downgrading gdb locally first [14:30] seb128: apport-chroot login --auth $HOME/.lpcookie chroots/natty.tar.gz [14:30] seb128: --auth needs an absolute path, that's a common trap [14:30] pitti, I did that [14:30] and then apport-retrace --auth /tmp/auth [14:30] right [14:30] cat /tmp/auth works? [14:30] if you use e. g. --auth ../.lpcookie, it'll fail [14:31] pitti, ok, that was it, thanks [14:32] seb128: fixed apport-chroot in bzr for doing os.path.abspath() now [14:33] pitti, thanks === zyga-food is now known as zyga [14:43] pitti, hi, could you look at the libbluray package in upload queue? [14:47] ricotz: which queue? [14:48] pitti, natty new queue [14:49] seb128: hm, gdk-pixbuf builds just fine here locally.. [14:49] ricotz: maybe later today, after meetings [14:49] natty queues are usually done by the archive admins [14:50] pitti, alright, thanks [14:50] pitti, it might be using system libraries for itself or something? [14:50] pitti, it built fine there as well before I uploaded [14:50] right, that was my idea; I'll try to remove them first [14:50] ricotz, Riddell is archive admin of the day [14:51] seb128, thx [14:51] Riddell, could you take a look at the libbluray package in the natty new queue it will be needed to build a bluray-capable mplayer [14:52] ricotz: I'll be doing New queue reviews shortly [14:52] Riddell, thanks [14:53] seb128: ah, there; that was it, building against libgdk-pixbuf2.0-dev [14:53] pitti, ok, explains why it works locally [14:57] mterry: about 555901, I opened it myself, I can't review it [15:00] doko_, oh, must have missed that [15:03] mterry: could bug 718774 get some love? we have a feature freeze deadline coming [15:03] Launchpad bug 718774 in pyudev (Ubuntu) "[MIR] pyudev" [Undecided,New] https://launchpad.net/bugs/718774 [15:07] Riddell, sorry, I've been doing feature freeze stuff of my own. I can look at it today [15:07] hi there :-) [15:08] hi raphink [15:08] what's up? [15:08] feature freeze in two days! [15:08] I know Riddell [15:09] trying to get some people motivated to release augeas 0.8.0 before so I can upload it :-) [15:29] mpoirier: ** linux-n900 could not be accepted due to The source linux-n900 - 2.6.35-1.1 is already accepted in ubuntu/natty and you cannot upload the same version within the same distribution [15:30] persia: ^^^^^^^ [15:30] I accepted the first upload and rejected the second [15:35] cjwatson: after banging my head for quite some... time, I finally came across: http://paste.ubuntu.com/570627/ [15:36] cjwatson: I'm more than willing to add my own thanks but I still don't understand what is going on [15:37] cjwatson: are such handlers inherited ? The case at hand is a python process spawning a shell itself spawning a 'yes' process [15:38] cjwatson: if I kill the shell, it turns into a zombie but the the parent python process can still read the 'y' sent by the 'yes' process 8-/ [15:38] who rejected libbluray in NEW and why? [15:39] vila: signal dispositions set to SIG_IGN are preserved across fork and execve [15:39] cjwatson: if I use the subprocess_setup in the paste above, the 'yes' dies with the shell... I'm probably close to understanding why but... not there yet [15:39] siretart: https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039665.html [15:39] vila: meeting, I'll get back to you in a bit [15:39] cjwatson: ok [15:39] Riddell: ah, I see. thanks [15:40] ricotz: I guess you are already on it? [15:41] siretart, hi, actually not, should have looked the copyright file :( [15:42] ricotz: I'm pretty busy today with work stuff. do you have time to have a look? [15:43] siretart, not sure, was it accepted in debian? [15:43] ricotz: still in NEW [15:43] DktrKranz: ping. got a moment to look at a NEW banshee-community-extensions? ;-) [15:44] ricotz: if you can, please fix it in our git and upload from there. or ping me or someone to upload [15:45] siretart, ok, will see if i have some time [15:46] lamont: Coolness. Thanks. [15:46] is there a bug open about the excessive U1 notifications in natty? I get them constantly [15:49] ogra: W: libqtdee2: breaks-without-version libqtdee1 [15:50] DktrKranz: actually forget it, we have new extensions, so wait til 1.9.4 [15:50] ? shouldn't different sonames be coinstallable? [15:50] pitti: that is sort of why we have sonames in package names [15:51] Riddell, thanks [15:52] pitti: the package contains some data files [15:52] ah, that should be moved to a -common package then [15:52] pitti, ok [15:52] pitti, http://paste.ubuntu.com/570635/ [15:52] pitti, on the same return process locally with gdb 6.8 and7.2 [15:52] * ogra is currently busy with libqtbamf, i'll care for qtdee afterwards [15:54] seb128: ok, so I'll sit down and have a deep look at this gdb 7.2 breakage after the TB meeting [15:56] seb128: which bug # were you using for testing again? (in the fakechroots) [15:57] pitti, I didn't find one which fails in today's queue and all the old retracing which failed has their crashdumps cleaned [15:57] seb128: which one were you using for above pastebin? [15:57] pitti, let's wait a bit i'm sure we will receive another crash to play with [15:57] pitti, I just attach gdb to a running indicator and put a breakpoint [15:57] seb128: well, at some point we need to update to gdb 7.2 anyway; it alreayd hurt us with x.org [15:58] seb128: ah [15:58] pitti, I guess you can sig11 an indicator and copy the crashdump to the dc and play with gdb on it [15:58] seb128: I'll find one [15:58] right [15:58] seb128: https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.23.0-1ubuntu3 \o/ [15:58] pitti, danke! [15:58] de rien [15:59] wth with the i386 retracer as well [16:00] pitti, oh btw I commented the 10.10 amd64 retracer because I screwed the tarball for it [16:01] I will fix that later on [16:01] seb128: that's ok; it will fail anyway, as maverick's apport is still trying to talk to edge [16:01] (I did Ctrl-C the wrong command and stopped it while it was doing the update) [16:03] seb128: you can "exit 1" (or anything non-zero) in a --save chroot to abort the saving, btw [16:04] that's the "oh sh**" ejection seat [16:04] right, I know, but that was a run of the crash-digger [16:04] i.e same command as the cron [16:05] ScottK: Hi, the lists of backports bugs are alarmingly long. Is there any chance to draw your attention to bug 719815, which I have prepared with branches that should be ready to build from? [16:05] Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/719815 [16:06] GunnarHj: For something as central to Ubuntu Desktop as gdm, I'd want someone from the Desktop team like seb128 to review it. [16:07] If you can get seb128 (or whoever he wants to look into it) to concur with the backport, then ping me. [16:08] no opinion on that one, pitti has been sponsoring the work in natty and is probably better placed to comment [16:08] ScottK: I see. I'll ask Martin P. then, since he sponsored me when uploading the things in Natty. [16:08] That'd be fine too. === herton is now known as herton_lunch === beuno is now known as beuno-lunch [16:14] tseliot, bryce: AFAIR nvidia or nvidia-common now have postinst magic to do the necessary xorg.conf additions; do we still need to do any of them in jockey? We currently set DefaultDepth=24 (all versions) and AddARGBGLXVisuals=True (for version 96) [16:15] and it also disables the dri2 module [16:15] AFAIR the actual driver doesn't need to be set any more, as x.org now autodetects it and prefers nvidia > nv, right? [16:16] pitti: nvidia-common, in addition to the libraries which Jockey uses, has some debconf magic to handle obsolete drivers but I don't think it deals with xorg.conf in any way [16:18] pitti: the code that touches xorg.conf files is all in Jockey's handlers. And we definitely need the NoLogo option even though DefaultDepth is now set by default when no xorg.conf is available [16:18]