[01:00] <yofel> pitti: hi, can you upload a new version of the apport bash-completion to apport-bzr? My r16 has support for all apport commands in /usr/bin now
[02:02] <jdstrand> lool: yes, that is what I meant the other way-- ufw doesn't flush the builtins by default, so applications that add rules in the manner that libvirt does will work out of the box. if you would prefer to have ufw manage the builtin chains, you can do that with MANAGE_BUILTINS in /etc/default/ufw
[02:02] <jdstrand> s/other way/other day/
[02:06] <maxb> debchange has been mismerged breaking the --distributor option (again)
[02:06] <maxb> :-/
[02:26] <maxb> If there's a sponsor around, could you eyeball https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/509441 and tell me whether you'd want anything more in the bug before you considered it reviewable?
[02:34] <chrisccoulson> whats happening with the buildd's? i've just had a weird build failure, and I just checked the last few minutes and it seems that everyone's uploads are failing in the same way
[02:34] <chrisccoulson> http://launchpadlibrarian.net/38063194/buildlog_ubuntu-lucid-i386.gnome-power-manager_2.29.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[02:35] <RAOF> Being discussed in #launchpad; looks like it's fixed.
[02:35] <chrisccoulson> RAOF - thanks
[02:35] <RAOF> And that pkgbinarymangler was the culprit.
[02:35] <chrisccoulson> i guess i'll just leave my upload for tonight
[02:42] <stgraber> chrisccoulson: it should work just fine now
[02:44] <chrisccoulson> stgraber - thanks, i'll retry that shortly
[04:14] <hyperair> are the buildds broken?
[04:14] <RAOF> They have been.  I think they're meant to be fixed now, though.
[04:14] <hyperair> i see.
[04:14] <hyperair> then maybe someone should retry g-p-m's build
[04:19] <stgraber> hyperair: clicked a few links on LP, will start building in a few minutes
[04:20] <hyperair> stgraber: thanks.
[04:28] <wolter> Hi, I come to speak on behalf of the Ubuntu Manual Project. We wanted to know if there were any solid plans for the Software Center
[07:15] <dholbach> good morning
[07:44] <pitti> good morning
[07:46] <pitti> yofel: bash-completion> pulled, thank you!
[08:17] <pitti> argh
[08:17] <pitti> anyone doing syncs right now?
[08:18] <pitti> ah, I don't think I actually touched them; flush-backports just looks very strange
[09:11] <tkamppeter> pitti, hi
[09:12] <pitti> tkamppeter: guten Morgen
[09:16] <tkamppeter> pitti, about bug 369850, you wanted to ask the user to check udev for his parallel port and printer.
[09:16] <pitti> tkamppeter: still on my list
[09:16] <tkamppeter> pitti, OK
[09:19] <ttx> pitti: could you reset the burndown line on http://macaroni.ubuntu.com/~pitti/workitems/canonical-server-lucid-alpha-3.html to Jan 17 (or later) ?
[09:21] <pitti> ttx: sure, I could; however, do you have two minutes to find out how to do it yourself? (teach a man to fish and all that)
[09:21] <ttx> pitti: I'm all ears :)
[09:22] <pitti> ttx: bzr get lp:launchpad-work-items-tracker
[09:22] <ttx> done
[09:22] <pitti> ttx: I added you to ~work-items-tracker-hackers, so that you can commit
[09:23] <pitti> ttx: edit config/lucid.cfg
[09:23] <pitti> ttx: and add an entry to trend_start
[09:23] <pitti> something like
[09:23] <pitti>   ('canonical-server', 'lucid-alpha-3'): 123
[09:24] <pitti> then commit/push the change, and the next cronjob will pick it up
[09:24] <pitti> oh, please append the trailing comma
[09:24] <ttx> I suppose 123 is day of year ?
[09:24] <pitti> ttx: no, the number of work items that the trend line starts on
[09:25] <ttx> ah, right
[09:25] <ttx> so you don't reset on a day
[09:26] <ttx> pitti: the starting day is hardcoded somewhere ?
[09:27] <pitti> ttx: it's the beginning of the cycle
[09:27] <pitti> ttx: in theory we could change it to start from the previous milestone
[09:27] <pitti> but then you couldn't plan ahead
[09:27] <ttx> pitti: ok, so I need to extrapolate a little.
[09:27] <pitti> however
[09:27] <pitti> ttx: how about this:
[09:28] <pitti> we change the trend line start for milestone m not to start on opening release, but on the end of m-1
[09:28] <pitti> that should give better defaults
[09:29] <ttx> pitti: yes, that sounds better
[09:29] <pitti> ttx: but anyway, just commit your change now; we can drop those again once we have a more clever trend line start
[10:23] <maxb> If there's a sponsor around, could you eyeball https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/509441 and tell me whether you'd want anything more in the bug before you considered it reviewable?
[10:43] <pitti> tkamppeter: bug 369850 already has all the udev logs, and it's assigned to a kernel engineer; so I think we can just let it sit there for now
[10:48] <RAOF> seb128: I was looking at the gnome-shell FTBFS in lucid, and I've got a branch up that fixes it, but I'd like to discuss it because I'm not sure whether it should be fixed there or in gjs.
[10:48] <seb128> RAOF, do you set LD_LIBRARY_PATH or proload libmozjs?
[10:48] <seb128> oload -> eload
[10:49] <RAOF> Neither; I dropped the linkage against libmozjs.
[10:49] <RAOF> But LD_LIBRARY_PATH works, yes.
[10:50] <seb128> does your change makes "gjs" work?
[10:50] <seb128> ie calling the gjs interpreter
[10:51] <RAOF> It doesn't change gjs, only gnome-shell - it drops the extra dep by passing --as-needed to the linker.
[10:51] <RAOF> But I think there should be a better fix in gjs, yes.
[10:51] <RAOF> Possibly - it looks like gjs-consuming apps don't actually need a mozjs linkage, so the pkg-config files should'nt add that dep.
[10:52] <seb128> does gnome-shell run correctly?
[10:52] <seb128> because as said gjs doesn't run
[10:52] <RAOF> Yes.
[10:52] <seb128> so I expect you will still get issues if gjs is not fixed correctly
[10:52] <RAOF> With what package does gjs not run?
[10:53] <seb128> run "gjs"
[10:53] <seb128> it's from the gjs binary
[10:53] <RAOF> BAH!  Stupid locally installed apps.
[10:53] <seb128> I don't really get the issue
[10:54] <seb128> ldd lists libmozjs twice
[10:54] <RAOF> Three times, for libgnome-shell.so.
[10:54] <seb128> one which is a not found and one which is a correct one
[10:54] <seb128> I think I tried to ldd gjs-gi.so or something
[10:54] <seb128> but still there is a bug somewhere
[10:55] <seb128> but the same version works on karmic
[10:55] <RAOF> It's because libgnome-shell is explicitly linked against libmozjs & libgjs-gi, libgjs-gi is explicitly linked against libmozjs and libgjs, and libgjs is explicitly linked against libmozjs with a correct RPATH
[10:55] <seb128> so I'm a bit puzzled by the issue
[10:55] <seb128> how come it worked in karmic?
[10:55] <RAOF> Now, I shrug my shoulders.
[10:56] <RAOF> Were we building against libmozjs-dev?
[10:56] <seb128> no
[10:56] <seb128> using xulrunner-dev
[10:57] <seb128> could be that gjs was buggy in karmic too
[10:58] <seb128> but we had LD_LIBRARY_PATH hacks in gnome-shell
[10:58] <RAOF> That would make it work.
[10:58] <seb128> I think I dropped them thinking debian was solving that in some other way
[10:58] <seb128> but they don't, they use their libmozjs binary
[10:58] <RAOF> Yeah, by declaring libmozjs a system-library.
[10:58] <seb128> which is a lib I think
[10:59] <RAOF> Yeah; Debian've stuck an soname on it and called it charlie.
[10:59] <dholbach> mdke, sabdfl: if you should be around...  #ubuntu-meeting ? :)
[10:59] <seb128> not sure what is better between the karmic library path change or your as-needed
[10:59] <seb128> asac claims libmozjs is not ready to be shipped this way
[11:00] <seb128> ie as a system library
[11:00] <RAOF> Upstream were talking about aggressively breaking api, yes.
[11:00] <seb128> since upstream doesn't assure stability, etc
[11:00] <RAOF> Well, as long as as-needed doesn't break anything it's got a pleasant side effect of fixing a bunch of dpkg-shlibdeps warnings.
[11:00] <seb128> right, feel free to upload
[11:01] <RAOF> But I think a real solution would be to ensure that the gjs pkg-config files don't pull in libmozjs, and ensure that libgjs-gi has the right rpath set.
[11:03] <RAOF> But investigating that can be a job for tomorrow.
[11:05] <cemc> anybody care to take a look at this? bug #96850 (last comment). thanks.
[11:06] <seb128> RAOF, thanks for working on those
[11:07] <RAOF> seb128: No problem.  Now, if nouveau would just fix their 3d so that gnome-shell didn't have serious glitches on this laptop... ;)
[11:11] <ScottK> pitti: Would you please have a look at accepting quassel for karmic-proposed.  jdong already approved the SRU (Bug #509287), but I didn't feel I should accept it since it's my upload.
[11:12] <pitti> ScottK: right, I saw the bug mail; done
[11:12] <ScottK> pitti: Thanks.
[11:25] <tkamppeter> pitti, OK. I overlooked this. I am simply subscribed and get the notifications. I think that I have delegated it to the kernel. And it seems that it is really the kernel and not udev according to Scott Remnant.
[11:27] <tkamppeter> pitti, I got a patch with fixes memory hogging by pdftopdf today from upstream, I will apply it to CUPS. After that we could do an SRU for Karmic to fix 3 problems.
[12:20] <cjwatson> soren: erk, what's with the new dependency on grub in python-vm-builder?  I thought I removed the dependency on grub being installed on the host some time ago.
[12:20] <cjwatson> lool: ^- oh, it was your change
[12:21] <cjwatson> lool: upstream r348 was supposed to remove this requirement
[12:26] <tkamppeter> pitti, CUPS updated to include pdftopdf memory hog fix. Can you upload it? Thanks/
[12:27] <lool> cjwatson: I wanted to look into this today; I remembered a hard requirement on grub1, and saw what I recalled when grepping vm-builder, but apparently I missed the grub2 bits
[12:27] <lool> let me revert that then
[12:27] <soren> lool: The grub2 bits are not there. cjwatson just fixed things so that having grub in the guest sufficed.
[12:27] <soren> (rather than on the host)
[12:28] <lool> Great; that's actually what I wanted to do as well
[12:28] <lool> I pointed people requesting a port to grub2 to the bug proposing to use the guest's bootloader instead
[12:28] <cjwatson> I already produced a branch for grub2
[12:29] <cjwatson> hmm, though maybe I never finished it
[12:29] <cjwatson> apparently not.  running it in the chroot should be enough though.
[12:29] <lool> That's great, that was the next thing I wanted to do
[12:29] <lool> cjwatson: There's a branch for ext4 support which will turn itself on only if the target is >= karmic
[12:29] <lool> cjwatson: perhaps you want to do the same thing for grub1 versus 2
[12:29] <cjwatson> lool: http://paste.ubuntu.com/358992/ is my WIP if you want to pick it up; I don't have time at the moment
[12:30] <cjwatson> I think I shelved it because it was blocked on a grub-install bug processing the --grub-probe option, but that's now fixed
[12:30] <soren> seb128: You do this boot time testing thing all the time, right? Could I pursuade you to see how installing irqbalance affects boot speed?
[12:31] <seb128> soren, I do regular ones, sure I will try that this afternoon and let you know
[12:31] <soren> seb128: Fantastic, thank you.
[12:36] <lool> cjwatson: reported bug + attached your patch in 509609; thanks
[12:37] <cjwatson> lool: cheers
[12:52] <seb128> soren, is irqbalance supposed to be running after boot?
[12:53] <seb128> it's enabled by default apparently in the etc config
[12:53] <seb128> but not in the processes list
[12:53] <soren> seb128: That's expected.
[12:53] <soren> seb128: On single cpu systems (even multi-core), it will only run for a short while.
[12:53] <soren> seb128: Like 10 seconds or so.
[12:54] <seb128> soren, ok, I found it on the chart
[12:54] <seb128> soren, it has no visible activity there
[12:55] <seb128> seems to not make any difference
[12:55] <seb128> that's on the mini config
[12:55] <seb128> ie atom cpu
[12:55] <bluefox_> is there a reason ubuntu doesn't package songbird?
[12:55] <soren> seb128: No difference at all? Neither positive nor negative?
[12:56] <soren> seb128: I guess if it made any difference, it's too little to be reliably measured.
[12:56] <seb128> soren, right, charts change in a 0.5 seconds margin between boots
[12:56] <seb128> soren, it's not significant enough to tell there
[12:57] <soren> seb128: Ok, that's good enough for me. Thanks very much!
[12:57] <seb128> you're welcome
[12:58] <soren> zul: You're driving the irqbalance-by-default thing, right?
[12:58] <soren> zul: If so, see the last 20-ish lines of scrollback ^^
[13:00] <zul> soren: yep reading cool!
[13:00] <zul> ill reply to the mailing list today
[13:00]  * zul goes back to fixing a broken server
[13:34] <Riddell> superm1: is dell-recovery ment to be a native package?
[13:36] <cjwatson> james_w: do you know if there's a workaround for bug 499651?
[13:39] <geser> cjwatson: I had once a similar case and it was because the Ubuntu packaging and Debian packaging were done independent (we didn't have synced/merged the Debian package once)
[13:42] <didrocks> I have a new documentation package for a library that export some files like that: /usr/share/gtk-doc/html/libdbusmodel/index.html. I have no strong opinion if I should call the package libdbusmodel0-doc or libdbusmodel-doc (including serie or not). Any thought?
[13:43] <geser> does the -dev package contain the soversion?
[13:44] <didrocks> geser: no, it doesn't
[13:45] <geser> then I'd prefer libdbusmodel-doc as I don't see why you might need two different -doc versions installed and yet only the most recent -dev package
[13:47] <didrocks> geser: I agree
[13:47] <didrocks> geser: thanks :)
[13:47] <cjwatson> geser: but these are both automatic imports
[13:48] <ogra> pitti, you only enabled the autobuilds yesterday again, right ?
[13:49] <pitti> ogra: correct
[13:49] <ogra> thanks
[13:49]  * ogra wonders why the livefs log for tonight didnt get mirrored
[13:49] <seb128> doko, you tried to upload pyorbit to karmic
[13:49] <ogra> i see it on the live build machine for armel, but not on people.c.c
[13:50] <seb128> doko, you're summary of ubuntu change doesn't mention the dbg either
[13:50] <seb128> doko, is that wanted?
[13:51] <doko> seb128: ahh, will fix it
[13:51] <seb128> doko, thanks
[13:51] <seb128> doko, right, it seems you dropped the -dbg in that upload
[13:52] <seb128> not sure if that's what you confirmed or just the wrong upload target
[13:53] <ogra> cjwatson, could it be that the log mirroring script that writes to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ uses rookery as a machine name ? (seems the logs dont get mirrored since the move)
[13:53] <seb128> slangasek, somebody didn't flush syncs, is that you?
[13:53] <cjwatson> ogra: what do you mean "uses rookery as a machine name"?
[13:53] <ogra> cjwatson, as target for the copying ...
[13:54] <cjwatson> ogra: it's a pull script
[13:54] <ogra> oh, ok
[13:54] <ogra> then i guess its just fallout of the mmove and the mentioned cron issues
[13:55] <cjwatson> ogra: I'll look into it
[13:55] <ogra> thanks
[13:57] <SeaOrifice> can someone help me in compiling a driver module for an ethernet card ???
[14:12] <seb128> doko, is the new glibc known to be buggy with valgrind?
[14:12] <seb128> I get zillion of errors
[14:12] <seb128> ==5869==    at 0x4A5679F: __strlen_sse2 (strlen.S:106)
[14:12] <seb128> example
[14:12] <seb128> ==5869== Invalid read of size 8
[14:12] <seb128> ==5869==    at 0x4A5679F: __strlen_sse2 (strlen.S:106)
[14:12] <seb128> ==5869==    by 0x43A1FBC: gtk_widget_class_path (gtkwidget.c:9934)
[14:12] <seb128>  
[14:12] <seb128> on anything I try to run
[14:13] <doko> I'd rather say that the old valgrind doesn't work with it
[14:13] <seb128> do you plan to upgrade valgrind?
[14:13] <doko> not this week
[14:13] <apw> pitti, i thought we had an older db for the new burndown charts on macaroni?  i seem to have four tall bars now
[14:13] <seb128> ok :-(
[14:13] <seb128> doko, is there any workaround that I could use to be able to use valgrind?
[14:14] <seb128> I need it to debug some crasher
[14:16] <doko> I didn't look yet. maybe take a look at a new valgrind yourself for now?
[14:16] <seb128> doko, I can try, thanks
[14:35] <Laibsch> lool: I'd like to talk with you about MIR for kasumi (bug 424238)  Do you have some time?
[14:37] <lool> Laibsch: Sure
[14:37] <lool> Laibsch: Just ask here
[14:37] <pitti> apw: four tarballs?
[14:37] <Laibsch> lool: OK
[14:37] <Laibsch> Here we go
[14:38] <pitti> apw: I still keep a v1 db around from yesterday, if you mean that
[14:38] <apw> pitti, hehe no, i mean i still have that jump in the data
[14:38] <pitti> apw: right
[14:38] <pitti> apw: didn't see my ping from this morning?
[14:38] <pitti> apw: that was a genuine data loss, due to a brain fart of mine, sorry
[14:38] <apw> pitti, ahh missed it, having lots of irc issues
[14:38] <apw> oh so i really do have 130 odd tasks?
[14:38] <pitti> apw: I'll adjust the trend line start accordingly
[14:39] <apw> pitti, in other news, i see we are flattening inprogress and todo to todo in the db, i'd like to stop doing that
[14:39] <Laibsch> lool: I've made a new upload to mentors.debian.net: http://mentors.debian.net/debian/pool/main/k/kasumi/kasumi_2.5-0.dsc (don't worry about the -0 version number, that is not meant for release).  Changes are documented at http://git.debian.org/?p=collab-maint/kasumi.git
[14:39] <pitti> apw: right, the current task count is correct
[14:40] <apw> so that my tables can differentiate, and before i make the _completions zap inprogress to todo i wondered if you wanted that too
[14:40] <pitti> apw: I added some debugging to that yesterday, to compare total #wi from by-assignee and by-spec, and they all match now (I fixed the duplicate bug)
[14:40] <Laibsch> lool: the things that may still need to be done were listed in the bug tracker (last comment).  It would be nice if you let took a look and let me know about the current state of affairs from your perspective.
[14:40] <apw> pitti, yeeks
[14:40] <Laibsch> s/let//
[14:40] <lool> If I debdiff the current kasumi against your updated one, the debian/changelog doesn't list the changes you did
[14:40] <pitti> apw: I don't need an "in progress" state for my purposes, but if you do, feel free to hack it in
[14:40] <Laibsch> lool: no, that will be done once I release
[14:40] <Laibsch> git-buildpackage
[14:41] <Laibsch> it's better not to commit changes to the changelog until release
[14:41] <Laibsch> lool: take a look at the commits in git
[14:41] <lool> Laibsch: You can update the changelog before each upload to mentors though
[14:41] <lool> git-dch is clever enough to check when the debian/changelog was last updated
[14:41] <Laibsch> alright
[14:41] <Laibsch> that aside
[14:41] <Laibsch> It's not meant to be released that way
[14:41] <Laibsch> same with -0
[14:41] <apw> pitti, so are we officially no longer updating the old data now?
[14:42] <pitti> apw: you mean the one on piware?
[14:42] <lool> Laibsch: was the patch sent upstrean
[14:42] <lool> *upstream
[14:43] <apw> yeah ... trying to work out where we are at
[14:43] <pitti> apw: the "entire cycle" cronjobs are still running; cjwatson asked me to, for having consistent WI counts
[14:43] <pitti> apw: I don't have cronjobs for alpha-3 on piware.de
[14:43] <Laibsch> lool: no, not that I know.  Is that a requirement for MIR?  The list was already long enough :-D
[14:43] <apw> so i should be swapping and working with the new ones
[14:44] <Laibsch> lool: Remember, I'm trying to help you guys
[14:44] <pitti> apw: ideally yes; I'm fine with having the trend line adjusted accordingly; that's what desktop and mobile are doing now
[14:44] <lool> Laibsch: The MIR is about evaluating the pain / risks of having a package in main
[14:44] <Laibsch> This all started because I pushed back stuff for scim-anthy from Ubuntu so you could sync instead of merge
[14:45] <apw> pitti, am i correct in thinking you cannot generate a .png trivially?  it seems we cannot insert .svg into wiki land
[14:45] <Laibsch> lool: balance that with the risk of contantly needing to merge a package that is already in main
[14:45] <lool> Laibsch: I will list all issues I find the packaging and ask whether it's properly maintained; some small issues are fine, it's not like this patch is complex for instance, but it's normal that I check the quality of the maintenance
[14:45] <Laibsch> lool: because that is the alternative.
[14:45] <Laibsch> lool: sure
[14:45] <Laibsch> I'm just also trying to make you understand my position
[14:45] <lool> Laibsch: I don't really get it; are you maintaining this in Debian as well?
[14:45] <Laibsch> I'm not benefiting from a MIR for kasumi
[14:46] <Laibsch> it's only more work
[14:46] <Laibsch> lool: sure
[14:46] <Laibsch> both packages
[14:46] <Laibsch> I saw they were not properly maintained
[14:46] <lool> Laibsch: Whatever issue I find is useful to resolve in both distros then
[14:46] <Laibsch> and asked Ikuya if he wanted help
[14:46] <Laibsch> yes, absolutely
[14:46] <lool> Laibsch: I'm not trying to create more work for you; I'm scanning the whole package and saying "I found this and that blahblah"
[14:47] <Laibsch> lool: I'm grateful for that
[14:47] <lool> Laibsch: Great; let's attack the actual issues and see what's left we can't easily resolve?
[14:47] <apw> pitti, do what do you need from me to work out the original burndown, i assum we just set the start number back at the original date to what it is now
[14:47] <Laibsch> but we should differentiate between "look at X when you have time" and "you need to fix Y before MIR can be granted"
[14:47] <lool> Laibsch: I see you use the upstream man page now, but you kept a xsltproc build-dep; is it really needed now?
[14:47] <Laibsch> lool: sounds like a plan
[14:47] <lool> (grepping for xsltproc in the source returns nothing)
[14:48] <Laibsch> that predates my time so I need to check
[14:48] <lool> Laibsch: I will absolutely let you know which ones are blocking issues and which aren't; sometimes there are many small issues and I'll say: fix some of these
[14:48] <lool> Laibsch: It doens't predate your time, but it's a commit by Ikuya
[14:49] <Laibsch> well, that's the thing.  There already was a list, and now there are new things.  So, I'm afraid it will never end.  At which point I would tend to more pressing issues and let somebody else resolve it.
[14:49] <Laibsch> It predates my "kasumi" time
[14:49] <Laibsch> or at least I think
[14:50] <lool> Laibsch: you did some commits in the git repo before that change
[14:50] <lool> Laibsch: ee4923ddb5ac9db4af8f003a202f4836b06a6437 is the commit
[14:50] <lool> You did 618b24b15438b34361ba648838d9649acd39fb1d just before
[14:51] <pitti> apw: .png> pychart can do it, but not on macaroni, since that doesn't have ghostscript
[14:51] <lool> Laibsch: I would love if you could file an upstream bug on the usage of AM_PATH_GTK_2_0() that's really old stuff
[14:52] <apw> pitti, for now it'll have to be a link to the chart
[14:52] <pitti> apw: if it's important, we could do an RT and ask for it
[14:52] <Laibsch> I see.  Those commits were made when we actually met in Kobe
[14:52] <apw> pitti, makes the pages less intuitive, not the end of the world
[14:52] <lool> Laibsch: Do you have a build log of your kasumi 2.5 tree somewhere?
[14:52] <lool> (On Ubuntu)
[14:52] <Laibsch> no
[14:52] <Laibsch> sorry
[14:52] <Laibsch> It was a local pbuilder build
[14:53] <Laibsch> There's still some errors about "uselessly linking against $blah"
[14:53] <pitti> apw: btw, feel free to adjust the trend line start yourself (it's in config/lucid.cfg, there are existing examples)
[14:53] <lool> Laibsch: BTW the original MIR review had the blocking stuff listed: So I'd love if you could work on copyright and rules to fix at least the licensing, pot and configure .PHONY issues.
[14:53] <lool> Laibsch: Your list is pretty much complete and looks good
[14:54] <lool> Laibsch: (comment #6 in the MIR)
[14:54] <apw> pitti, when is trend_start value in time?
[14:54] <lool> Laibsch: I don't understand the settings menu bit
[14:54] <jdstrand> stefanlsd: hi! where is the code for http://people.ubuntu.com/~stefanlsd/synclist.html?
[14:54] <pitti> apw: it's the #WIs that the trend line starts at
[14:54] <apw> but 'when'
[14:55] <apw> at the first column in the charts?  or at some specific date
[14:55] <pitti> apw: ah; lucid start
[14:55] <pitti> apw: right, at the first column
[14:55] <Laibsch> lool: https://bugs.launchpad.net/ubuntu/+source/kasumi/+bug/424238/comments/6 is essentially what I understand is what's left of the original request.  And I'm sorry but my skills don't seem to be adequate to fix any of them.  So, somebody else will have to do that (or heavy coaching, I can't spend days on fixing this).
[14:55] <pitti> apw: we could let the alpha-3 chart start at the end of alpha-2; but then we couldn't plan ahead so easily
[14:56] <apw> pitti, so first column of the current data, not as at 1 november sort of thing
[14:56] <Laibsch> lool: settings menu relates to your earlier comment "do we really want to add a new entry in the settings menu that late in the cycle and for a very specific app which most people dont need to configure?"  Don't ask me, I understand all the stuff you wrote ;-)
[14:57] <lool> Laibsch: updated 403189
[14:57] <lool> Laibsch: So who from the kasumi maintainers has the skills to fix the remaining issues?
[14:58] <Laibsch> to be honest, I'm not sure ;-)
[14:59] <lool> Hmm
[14:59] <Laibsch> skill level in Japan doesn't always match that in Europe or the US
[14:59] <lool> Laibsch: Who's your sponsor?
[14:59] <Laibsch> But that goes for the programming itself as well ;-)
[14:59] <lool> This is going to be a handicap for me http://kasumi.sourceforge.jp/index.php?%A5%D0%A5%B0%CA%F3%B9%F0
[14:59] <Laibsch> I have several sponsors, depending on package and work load of the sponsor
[15:00] <lool> Laibsch: I guess you do speak Japanese?
[15:00] <Laibsch> lool: yes
[15:00] <Laibsch> It's a patchwork of skills needed to get Japanese stuff in shape
[15:00] <lool> Laibsch: I could help locally to address some of these issues, but I can't directly work with upstream if their web pages are in Japanese (starting with I don't know which button to push)
[15:01] <soren> Oh.
[15:01] <Laibsch> sure
[15:01] <soren> UDW is /next/ week.
[15:01] <Laibsch> I'm glad to help
[15:01]  * soren stops preparing for his session "tonight"
[15:01]  * soren facepalms
[15:01] <lool> Laibsch: I see the warnings at http://lintian.debian.org/maintainer/ikuya@oooug.jp.html#kasumi were mostly fixed -- great
[15:02] <lool> Laibsch: So overall I think this made nice progress but we need to get the updated source in Debian and finish some of the remaining technical bits; I'm happy to assist there
[15:02] <lool> Laibsch: Concerning sponsoring, I'm technically a DD but given the nature of the applications, I would highly prefer if you could find someone who uses or can at least test the app
[15:03] <Laibsch> But as I said, I will need some help in the more technically involved issues.  I'm not a computer programmer and I know close to nothing about build systems.  But that usually doesn't keep me from maintaining packages or writing recipes in openembedded.org.  I find that most people that do know about build systems don't bother about packaging them properly according to Debian standards.
[15:03] <Laibsch> I know two DDs in Japan that I can ask
[15:03] <Laibsch> This is a simple app, though
[15:03] <Laibsch> It's basically a dictionary front-end
[15:04] <Laibsch> lool: given the remaining list, I'll need more coaching, preferably in the form of patches ;-)
[15:04] <lool> Laibsch: Ack; as said, I can help there
[15:05] <lool> Laibsch: I'm putting this down in the MIR
[15:05] <Laibsch> "drop obsolete AM_GTK macro" doesn't really give me concrete enough hints
[15:05] <Laibsch> cool
[15:05] <lool> Laibsch: Could you push your 2.5 to some PPA?
[15:05] <Laibsch> sure
[15:06] <Laibsch> lool: https://launchpad.net/~r0lf/+archive/hardy should arrive in a minute or two, depending on LP load
[15:06]  * Laibsch hopes it builds in hardy
[15:06] <lool> Laibsch: Building on lucid would be good
[15:06] <Laibsch> I will copy later
[15:07] <lool> To clarify: I'm interested in a lucid build log
[15:07] <pitti> apw: correct, it's always the first bar; no date (sorry for lag, I'm on a hideous network connection right now)
[15:08] <Laibsch> lool: I uploaded it there because that is the only target I have in ~/.dput.cf with a fixed Ubuntu release.  Otherwise I get errors of "unstable is not a known release" or "UNRELEASED is not a known release".  Saves me from changing debian/changelog all the time.
[15:08] <Laibsch> lool: I'll copy it once it arrives
[15:09] <lool> Laibsch: You can add checks of target release to your dput.cf
[15:11] <jdstrand> kees, mdeslaur: do you guys happen to know where the code is for http://people.ubuntu.com/~stefanlsd/synclist.html? I'd like to check it in somewhere in our tools
[15:11] <jdstrand> (I asked stefanlsd earlier, but he doesn't seem to be around atm)
[15:12] <kees> jdstrand: sorry, I don't.
[15:12] <mdeslaur> jdstrand: nope, sorry
[15:12] <jdstrand> np
[15:12]  * jdstrand tries to be patient
[15:13] <lool> Laibsch: So I unpacked the 2.5 source package, and I could ./configure&& make distcheck (got a tarball in the end) which is good
[15:15] <lool> Laibsch: Would you mind pointing me at the upstream Vcs for kasumi?
[15:16] <Laibsch> cvs -z3 -d:pserver:anonymous@cvs.sourceforge.jp:/cvsroot/kasumi co kasumi2
[15:16] <Laibsch> cvs -d:pserver:anonymous@cvs.sourceforge.jp:/cvsroot/kasumi login
[15:17] <Laibsch> lool: http://sourceforge.jp/cvs/view/kasumi/kasumi2/
[15:18] <lool> thanks
[15:19] <Laibsch> lool: https://launchpad.net/~r0lf/+archive/ppa/+sourcepub/935159/+listing-archive-extra
[15:20] <Laibsch> https://launchpad.net/~r0lf/+archive/ppa/+build/1454487
[15:24] <apw> pitti, i have a couple of blueprints with wither ubuntu-10.04 or ubuntu-10.04-beta-1 as milestones and the spec entries in the table do not seem to have the milestone
[15:25] <apw> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-bugs-with-patches
[15:25] <apw> the milestones do appear in the list correctly
[15:27] <apw> pitti, ahh we need a '.' in the match
[15:28] <apw> pitti, got an incantion i can apply to collect to test it? (/query it perhaps)
[15:29] <superm1> Riddell, it is meant to be yes.  It's developed for ubuntu
[15:29] <Riddell> superm1: groovy, I'll accept
[15:29] <superm1> thanks
[15:33] <kees> asac: can you look at bug 507744 to be added to the work you're doing for the next firefox package?
[15:38] <masquitos> anybode here?
[15:41] <mdeslaur> chrisccoulson, seb128: fyi, I've added some apport hooks to the gnome-screensaver bzr
[15:42] <chrisccoulson> mdeslaur - thanks
[15:42] <chrisccoulson> mdeslaur - i'm going to do an upload later with a couple more changes in
[15:44] <mdeslaur> chrisccoulson: cool, thanks
[15:54] <smoser> slangasek, in Keybuk's absense, maybe you can verify.  I think that upstart used to read '--verbose' and '--debug' off the kernel command line, and documentation implies that it does, but i'm virtually certain it is not doing so now.
[15:55] <akgraner> robbiew, ping got a sec?
[16:02] <micahg> Laibsch: meeting in #ubuntu-bugs
[16:02] <Laibsch> micahg: Ah, thanks for reminding
[16:04] <jdstrand> james_w: perhaps a dumb question-- once I follow https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging and then commit the changes, will the source get built automatically or do I need to upload like normal?
[16:05] <jdstrand> james_w: hi btw :)
[16:06] <hwilde> in udev 60-persistent-storage.rules where does it get $env{ID_FS_UUID_ENC}    ?
[16:15] <cjwatson> jdstrand: you still need to upload; building directly from branches is being worked on but isn't ready yet (and will take a while, I expect)
[16:15] <jdstrand> cjwatson: cool, thanks
[16:16] <pitti> hwilde: from blkid
[16:16] <pitti> hwilde: in particular, from this rule: KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
[16:16] <jdstrand> james_w, cjwatson: tbh, this is the first time I've used bzr merge-package. It was a simple merge, but the process was very nice. :)
[16:40] <xteejx> Hi guys, I'm having problems with qemulator, as are a few others, I understand that the Ubuntu Development Team are the maintainers? I wanted to ask if there is any chance we can get the latest unstable svn version, as the stable hasn't been updated for a few years?
[16:41] <ttx> pitti: when does the workitem code refresh ? I committed the trendsline reset this morning and it still doesn't appear on the graph...
[16:41] <pitti> ttx: I got a "branch is diverged" cron error mail, so you won't see your change in the current charts; I'll fix it up this evening, when I'm back at a computer where I can ssh to macaroni
[16:41] <xteejx> specifically, the problem with bug 382521 - it's unusable
[16:41] <pitti> ttx: in principle, it pulls hourly
[16:41] <ttx> pitti: ok cool, thanks
[16:45] <directhex> moo
[16:50] <xteejx> Do any of the maintainers for qemulator (Ubuntu Development Team) have any idea if there is a chance of getting the latest version into Ubuntu, as I believe it may then be usable.
[16:50] <xteejx> ref bug 382521 as described above :)
[17:09] <kees> Riddell: so, I'm looking at virtuoso-opensource.
[17:09] <kees> Riddell: it builds a daemon that listens on 0.0.0.0 :(
[17:10] <lamont> kees: and no option to force it to an IP other than 0.0.0.0?
[17:10] <kees> actually, I take it back, the default ini does the config
[17:11] <lamont> heh.  ini
[17:11] <kees> Riddell: so, how is this intended to work?
[17:11] <kees> Riddell: what generates the .ini that it loads?
[17:12] <Riddell> kees: nepomuk semantic desktop does, it always sets DisableTcpSocket=1
[17:12] <kees> ah! okay.
[17:12] <kees> Riddell: what do you think of shipping the server in /usr/lib/virtuoso-opensource instead of /usr/bin ?
[17:13] <Riddell> kees: that would probably need some patches somewhere but should be fine
[17:13] <kees> hm.
[17:13] <Riddell> kees: yeah it's just libsoprano that needs patching, I see where it needs done so not hard I think
[17:13] <kees> I think it would just be cleaner that way, since virtuoso-t doesn't run out of the box (it needs the .ini) so putting it in /usr/bin seems odd
[17:14] <Riddell> I agree
[17:19] <pitti> apw: http://macaroni.ubuntu.com/~pitti/workitems/canonical-kernel-team.html
[17:19] <pitti> apw: there, adjusted trend line
[17:19] <apw> pitti, cool except we are the wrong side of it
[17:19] <pitti> how do you mean?
[17:28] <kees> Riddell: it should be using system zlib instead of its internal copy, too.
[17:28] <kees> Riddell: I'm trying to figure out what libsrc/Wi/bif_files.c is for, though.  it seems to have a specific function to run commands
[17:28] <Riddell> kees: yeah I couldn't see an obvious way to make it do that
[17:29] <kees> Riddell: really? it's in the configure.in I thought
[17:29] <Riddell> of course it's possible I missed something obvious
[17:29] <kees> ./configure  --without-internal-zlib   if its docs are to be believed
[17:30] <Riddell> oh, duh
[17:31] <kees> maybe it needs further tweaking to get the right includes, but I haven't actually tried it.
[17:33] <jjardon> Maybe of your interest: udev-browser: http://0pointer.de/blog/projects/udev-browse.html
[17:38] <macli>  /close
[18:41] <seb128> ev: hey
[18:42] <ev> seb128: hi
[18:42] <seb128> ev: thanks for the pygtk patch, did you send it upstream, I don't find the bug...
[18:43] <ev> seb128: I mentioned it in the changelog: https://bugzilla.gnome.org/show_bug.cgi?id=607453
[18:44] <seb128> ev: oh right, I overlooked that, I'm use to have the info in the patch description ;-)
[18:44] <seb128> ev: thanks
[18:44] <ev> ah, apologies
[18:44] <seb128> nothing to apology about, sorry for overlooking it in the changelog
[19:05] <xaxez> http://pastebin.com/m116119d1 any idea????
[19:48] <spy6> hi there
[19:48] <spy6> i'm affected by #469985 ... is there a backport of mountall for karmic available?
[19:49] <spy6> or any other solution to get karmic running in a domU with olter kernel?
[19:49] <spy6> older even
[20:01] <xnox> bug #469985
[20:07] <Laibsch> lool: ping, are you there?
[20:08] <spy6> xnox: the fix is just for lucid, not for karmic
[20:09] <james_w> cjwatson: I do not I am afraid
[20:10] <xnox> spy6: i just wanted to see what the bug was =) cause I issues with mountall and thought that that was the bug I'm having
[20:14] <spy6> xnox: ah ...k
[20:14]  * xnox is not developer yet =)
[20:20] <alkisg> Could anyone help in an edubuntu-devel problem? Trying to create a fat client chroot: (1) chroot /opt/ltsp/i386 (2) debootstrap && apt-get install edubuntu-desktop (3) exit the chroot (4) umount /opt/ltsp/i386/proc ==> PROBLEM: in use.
[20:20] <alkisg> I tried lsof and fuser and ls /proc/*/exe to see the process that uses $chroot/proc, nothing. Then I logged off, stopped gdm, stopped any service I could think of, and tried umount again. STILL in use.
[20:20] <alkisg> How can that be happening?
[20:22] <alkisg> BTW, the same method with ubuntu-desktop, instead of edubuntu-desktop, doesn't give this problem.
[20:49] <slangasek> smoser: I think at one point Keybnz had a mistaken belief that kernel commandline options would be passed to init directly, but later discovered they aren't; if he's implemented any handling of /proc/cmdline, I haven't heard of it
[20:50] <smoser> slangasek, never mind the above. it appears that i just didn't know how args are passed to init. apparently 'init=' is given, kernel invokes init with args from there out.
[20:50] <smoser> if '--debug' is on the kernel command line, it *does* get through to whatever program is 'init'
[20:51] <slangasek> oh, ok
[20:51] <smoser> any options specified like 'a=b' (having an '=' in them) are not passed. and if there is an init= arg on the cmdline, then any tokens before that will not be passed.
[20:51] <smoser> this is experimentation data only.
[20:52] <slangasek> oh, ok
[20:56] <slangasek> zul: er, why did you take the samba change from karmic-proposed for bug #462169?
[20:57] <zul> slangasek: yeah
[20:57] <slangasek> zul: I asked *why* :)
[20:57] <zul> slangasek: better than nothing im working on the upstart conversion as we speak
[20:57] <slangasek> no, not better than nothing
[20:57] <slangasek> see my last comment on the bug
[20:57] <zul> slangasek: k ill revert it
[20:58] <slangasek> can you reproduce the original problem?
[20:58] <zul> no i had once on a alpha testing
[20:58] <slangasek> ok
[20:58] <zul> and i think smoser did as well
[20:58] <slangasek> if it's no longer reproducible, the upstartification is much simpler; I already have the upstart jobs here, I just need to tune the start condition for nmbd
[20:59] <zul> oh? can i see them?
[20:59] <slangasek> sure, sec
[21:00] <smoser> i did see dead nmbd in alpha2 testing, and logged it in the iso tracker
[21:00] <zul> slangasek: im just curious to see if im on the right track for my own education
[21:00] <slangasek> zul: http://paste.ubuntu.com/359214/, http://paste.ubuntu.com/359215/
[21:00] <slangasek> smoser: ok, how do I reproduce that?
[21:01] <slangasek> smoser: I have been entirely unable to trigger an nmbd failure in current lucid, no matter how I mangle my configs and network interfaces
[21:01] <smoser> wow. i just did out of the box. in a kvm.
[21:02] <smoser> hold on
[21:02] <slangasek> zul: oh, that version of the smbd job is broken; it needs to be 'exec smbd -F' and no 'expect daemon', somehow whatever smbd does on start to daemonize confuses upstart and it loses track of the process
[21:02] <smoser> i just walked through http://testcases.qa.ubuntu.com/Install/ServerWhole#Samba%20server and the suggested 'pgrep' showed no nmbd
[21:03] <slangasek> smoser: if you're going to reproduce it, please set 'log level = 3' in /etc/samba/smb.conf first
[21:03] <zul> slangasek: yeah I had that in my testing as well
[21:03]  * zul goes get ready for a hockey game
[21:08] <smoser> slangasek, so if you did a clean install of alpha2 and nmbd does not die for you?
[21:08] <slangasek> smoser: I haven't done a clean install of alpha2; don't have the spare hardware, but at best it's racy anyway
[21:09] <slangasek> what I don't understand is why I still can't get nmbd to fail when I hard-kill lo
[21:10] <smoser> slangasek, well, i dont have spare hardware either, but i do have kvm :) and thats where i see it fail, so might aid in the racy-ness
[21:10] <slangasek> yeah, I don't have any spare hardware that'll run KVM
[21:10] <slangasek> :-P
[21:58] <smoser> slangasek, i'll offer a trade.  i will reproduce 462169 for you if you will look at bug 509841
[21:59] <smoser> I've attached differences in '--debug' console output .  At very least, please read the attached http://launchpadlibrarian.net/38103669/only.combined.txt and see if anything jumps out at you.
[22:03] <Laibsch> ping lool
[22:03] <seb128> cjwatson, pitti, Riddell, james_w, slangasek: did any of you started doing syncs yesterday?
[22:04] <james_w> seb128: I did it last Sunday night
[22:04] <seb128> there is quite some item not flushed in the sync dir
[22:04] <slangasek> seb128: it may have been james_w; the rest of us were already discussing on #ubuntu-release and none of us confessed :)
[22:04] <seb128> I'm trying to figure who did that
[22:04] <slangasek> I thought Riddell said he was flushing them
[22:04] <slangasek> like, an hour ago
[22:04] <seb128> he didn't apparently
[22:05] <slangasek> Riddell: ^^ ?
[22:05] <seb128> I'm waiting on that to try a soyuz bug ;-)
[22:05] <seb128> bah gtk-sharp guys
[22:06] <james_w> yes, that could well have been me. I may have lost network while doing the flush, sorry for not using screen
[22:06] <seb128> james_w, no problem, can it be flushed now? ;-)
[22:06] <james_w> I don't see why not
[22:07] <seb128> ok thanks
[22:07] <seb128> doing that now
[22:07] <james_w> what does soyuz do for interrupted flushes?
[22:07] <seb128> I just didn't want to get in conflict with other people work
[22:07] <james_w> is it going to reject a bunch of them?
[22:07] <james_w> I'm not doing anything currently, so you won't conflict with me
[22:07] <seb128> I don't know but it's not going to accept things twice
[22:08] <slangasek> james_w: yes, a stopped and restarted flush will give rejects
[22:08] <seb128> directhex, the debian gtk-sharp changes suck
[22:08] <seb128> james_w, can you flush the queue then? ;-) I don't want to be responsive for other people rejected item in the queue :-p
[22:09] <james_w> heh
[22:09] <seb128> directhex, do you have some sort of transition plan to make sure to fix things the .pc binary broke before lucid?
[22:09] <seb128> binary *move* broke
[22:09] <ccheney> doko: the thumb arm patch doesn't apply for 3.2.0 should it be just a small modification to fix it, or should i upload it without that patch so you can look at what it needs for 3.2?
[22:10] <ccheney> doko: looks pretty simple for me to just update the patch if that is likely to be enough to make it work
[22:11] <RAOF> seb128: I'm not directhex, but that's mostly fixed in Sid already.  I think the transition plan was “pull the fixed stuff from testing after it migrates”.
[22:11] <seb128> I got 2 ftbfs today already
[22:11] <seb128> that starts annoying me
[22:12] <seb128> we can't let the archive broken until we might sync from testing things which migrated
[22:12] <ccheney> doko: actually solenv/inc/unxlngr.mk looks significantly different from the 3.1.1 version
[22:13] <ccheney> doko: should i just change CDEFAULTOPT=-Os to CDEFAULTOPT=-O2 ?
[22:13] <RAOF> It might be time to upload from pkg-cli-apps/pkg-cli-libs VCS again to speed things up.
[22:13] <sebner> RAOF: hola, do you know if docky is supposed to be stable?
[22:14] <RAOF> sebner: Which one?  The one in current gnome-do releases, or the new split out one in lp:docky?
[22:14] <slangasek> seb128: "sync from testing" is a default policy only, anything that it's appropriate to sync from unstable can be synced in the usual way
[22:14] <sebner> RAOF: latter
[22:14] <seb128> slangasek, right, it's just annoying that we got things broken and no transition plan or somebody looking at it
[22:15] <seb128> slangasek, they moved the .pc to a new binary which means all build-depends are broken
[22:15] <slangasek> heh, ok
[22:15] <seb128> I ran into 2 broken case today
[22:15] <seb128> dunno how many of those are still around
[22:15] <RAOF> sebner: It's not sufficiently feature-complete for a release, but it's moderately workable?
[22:15] <slangasek> smoser: looking at 509841
[22:17] <sebner> RAOF: kk, I'm using it since some days and it generally works well but it lags heavily from time to time (Xserver goes to 100%) so I'm wondering if that's the fault of docky, xserver, compiz or nvidia driver
[22:18] <slangasek> smoser: in the ramdisk case, what starts your network interfaces?  (I see no mention of them in the log)
[22:18] <slangasek> smoser: I'd also like a tarball of /etc/init from this system
[22:18] <smoser> yeah, thats wierd. there is *no* changes
[22:18] <RAOF> sebner: That's a strange interaction with the nvidia driver; start docky with the --nvidia to activate a work-around.
[22:18] <smoser> between the ramdisk and non-ramdisk systems. oh, i suppose its possible that *nothing* starts the interface in the ramdisk case.
[22:19] <smoser> i can provide tarball of /etc/init, but you can download it at a waste of meer 200+M (download the UEC image).
[22:19] <slangasek> smoser: ok - which image is it?
[22:19] <sebner> RAOF: cool! thanks for the hint :)
[22:20] <smoser> http://uec-images.ubuntu.com/lucid/20100118/
[22:20] <smoser> i used amd64, but thats not relevant as far as i can tell.
[22:21] <Laney> seb128: There is not "no transition plan", we are trying to get enough done in Debian so that we can sync it
[22:21] <slangasek> smoser: ack, downloading
[22:21] <seb128> Laney, doesn't seem a good way to deal with a transition :-(
[22:22] <directhex> seb128, if you don't mind syncing from sid, then things are mostly done
[22:22] <smoser> that tarball contains everything to reproduce.  the ramdisk inside it is what i used, command line to kvm is in the bug....
[22:22] <seb128> directhex, what about ubuntu?
[22:22] <seb128> directhex, I ran into launchpad integration and indicator being broken today
[22:22] <seb128> directhex, did somebody try to figure what needs to be changed, what will come from debian, what is ubuntu specific?
[22:22] <sebner> RAOF: just wondering that this "bug" only appear after using docky for some hours
[22:23] <RAOF> sebner: Or after resume-from-suspend, apparently.  It's got something to do with long-lived graphics buffers.
[22:23] <directhex> seb128, i wasn't aware there *were* ubuntu-specific things, they seem to be missing from the multidistrotools page we've been lookign at
[22:23] <sebner> RAOF: ah, understood :) /me never uses resume anyways :)
[22:24] <seb128> directhex, I'm pondering making the old binary depends on the new one
[22:25] <sebner> RAOF: btw, any roadmap for it?
[22:25] <smoser> slangasek, i just attached all of /etc. figuring it might be useful for /etc/fstab or /etc/network/interfaces.
[22:26] <RAOF> sebner: For docky?  Not really; we've been trying to push DBO to work out the release-blocking bugs, but he's busy elsewhere and doesn't want it released before some nebulous stuff has happened.
[22:27] <seb128> directhex, grep-dctrl says there is 28 sources to update
[22:28] <seb128> that's for libgtk2.0-cil only though
[22:28] <sebner> RAOF: heh. Are there already some major differences betweend g-d docky and split out docky?
[22:28] <RAOF> sebner: Yes; they're quite different now.
[22:29] <sebner> RAOF: so I'm fine with the new one?
[22:30] <RAOF> sebner: Yes
[22:31] <RAOF> seb128: Have you seen the pkg-mono transition tracking page? http://wiki.debian.org/Teams/DebianMonoGroup/Mono-devTransition
[22:31] <sebner> RAOF: great! thanks for you time :)
[22:31] <seb128> no I didn't
[22:31] <directhex> seb128, i count about gtk# 60 rdeps, with about half done in sid, so that sounds about right
[22:31] <seb128> I will look to that in a minute, need to restart
[22:31] <seb128> brb
[22:32] <Laney> that page isn't so helpful in tracking apps sadly
[22:36] <seb128> re
[22:36] <seb128> directhex, RAOF: ok thanks
[22:37] <seb128> seems to not be so many before lucid
[22:37] <seb128> would have nice to have an email on the lists about the transition though
[22:37] <seb128> to not surprised maintainers who get build failure after trivial changes
[22:37] <directhex> the hope was to get it all finished before it begame an issue
[22:37] <directhex> too many Closes:
[22:38] <seb128> well you overlooked ubuntu specific sources there
[22:38] <seb128> those will need get automagically changed
[22:38] <seb128> need -> not
[22:42] <Laney> I guess the MDT page builds its index from sid
[22:42] <Laney> would be better if it took the union
[22:44] <directhex> i should upload some NMUs
[22:45] <seb128> let me know if you need some syncs
[22:47] <slangasek> smoser: in the initramfs case, what's mounted on /tmp after the boot finishes?
[22:48] <directhex> sebner, bareftp seems okay to me, do you remember what the last blocker was?
[22:53] <chrisccoulson> jdstrand - when you did the recent transmission security update, you pushed your bzr branch without bzr add'ing the actual patch
[22:53] <chrisccoulson> i got a bit confused there ;)
[22:56] <sebner> directhex: FTBFS because gnome-keyring-sharp was not found by configure. I added a patch for it. If it builds it's ready for uploading. But really, ask meebey. Not my cup of tea anymore
[23:00] <jdstrand> chrisccoulson: oops
[23:01] <chrisccoulson> heh, no worries
[23:01] <jdstrand> I'll commit it
[23:02] <slangasek> smoser: ?
[23:04] <chrisccoulson> jdstrand - no worries about committing it
[23:05] <chrisccoulson> i've just pushed the update for beta 5 to bzr now, and the patch is merged upstream
[23:05] <jdstrand> chrisccoulson: ok-- sorry about that
[23:12] <sebner> directhex: The patch name in the changelog is false though (shame on me)
[23:12] <directhex> sebner, never mind. uploaded
[23:13] <cjwatson> jdstrand: can we safely copy horde3 from jaunty-security from jaunty-updates?  The changelog history diverges, but from a quick glance it looks as though the divergence is not interesting, as the diverging entries are just fakesync comments?
[23:13] <cjwatson> from jaunty-security TO jaunty-updates
[23:13] <jdstrand> cjwatson: yeah, I meant to do that earlier but forgot
[23:13] <sebner> directhex: heh, also though I don't care anymore take my thanks
[23:14] <cjwatson> jdstrand: I'll let you go ahead, then :)
[23:14] <jdstrand> k :)
[23:14] <jdstrand> done
[23:16] <nixternal> congrats cjwatson, persia, soren, geser, stgraber, and cody-somerville \o/
[23:16]  * sebner copy&paste nixternal : congrats cjwatson, persia, soren, geser, stgraber, and cody-somerville \o/
[23:17] <nixternal> hehe :)
[23:17] <stgraber> thanks
[23:18] <cjwatson> cheers, looking forward to serving with you
[23:18] <nixternal> dang, was hoping you said "serving you", cuz I could really use a cold beer right about now :)
[23:19] <stgraber> nixternal: is your fridge that far away ? ;)
[23:20] <nixternal> it is seriously 3 feet in front of me, but 6 inches of that is a wall :)
[23:23] <sebner> nixternal: so it seems I'm not the only one thinking about cjwatson being butler? :P
[23:23] <nixternal> ouch :)
[23:24] <soren> nixternal: Thanks and same to you.
[23:24] <directhex> ?
[23:24] <soren> http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_ea7519273c82ed12
[23:29] <cody-somerville> moo
[23:32] <geser> sebner: thanks
[23:51] <wolter> Hi, can anybody advice me on how to get my notify-osd volume control back?
[23:51] <wolter> Everything else works fine
[23:54] <slangasek> wolter: "back"?
[23:55] <wolter> slangasek, i removed pulseaudio once and with it, the notify-osd volume control stopped working
[23:55] <wolter> instead, the traditional gnome one took the job
[23:55] <slangasek> why did you remove pulseaudio?
[23:56] <smoser> slangasek, i can try mountall --debug. in fact, i had tried that, but did not get any of mountall's output to console.
[23:56] <smoser> almost as if it wasn't taking.  I'll try again though. Where would you expect mountall output to go ?
[23:56] <wolter> slangasek, because I was (am) having problems with my microphone
[23:56] <wolter> but now I have pulseaudio back installed
[23:57] <slangasek> smoser: ok - what about the contents of /proc/mounts in the case of a successful boot?
[23:57] <smoser> you want to see them , i can put them there.
[23:58] <slangasek> smoser: yes, please
[23:58] <slangasek> smoser: mountall output> try adding 'console output' to the upstart job as well (as a separate line, not as part of the script)
[23:59] <slangasek> wolter: so when you say "notify-osd volume control", you're talking about the on-screen display that shows when the volume has been changed with a hotkey?
[23:59] <smoser> slangasek, the job has 'console output' : http://paste.ubuntu.com/359300/
[23:59] <slangasek> smoser: heh, ok