=== debfx_ is now known as debfx [00:09] Laney: Nice. Only 80. Not so bad. [00:29] persia: ping [00:32] ScottK: what's the recommended change for the boost transition? switch from 1.42 to 1.46 in build-depends, or unversioned? === med_out is now known as medberry [00:42] can we safely just swap out 1.42 for 1.46? didn't the interface for boost::filesystem change ~completely between those two versions? [00:44] * micahg is curious as well since he has a FTBFS to fix [00:44] http://www.boost.org/doc/libs/1_46_1/libs/filesystem/v3/doc/index.htm implies that the earlier API can still be used for now [01:20] ajmitch: right, but 1.46 defaults to the new API [01:26] i guess all the changes should break the build [01:31] broder: yep, default changes, but it looks to be possible to just use the single define to change it, rather than having to port to the new API to get things to build [01:31] ah, i see. yeah, that's true [01:32] though honestly i don't think adjusting for the API changes should be difficult, especially for linux-specific apps that wouldn't use std::wstring === txwikinger2 is now known as txwikinger [07:25] good morning === Tobu_ is now known as Tobu [07:58] Laney: when you get a chance, could you please set up a transition for libnotify1 -> libnotify4, bad is depends on libnotify1 or b-d on libnotify4-dev, thanks :) [08:11] dholbach: I might want to link someone to a particular set of harvest filters. Is that possible currently? [08:29] nigelb, it is, you need to fiddle with the url a little bit - just have a look at the url the filter links send you to [08:29] nigelb, there's a couple of bugs filed about making that easier and more consistent [08:29] dylan mccall is the best person to answer the questions [08:30] dholbach: okay :) === _ruben_ is now known as _ruben [09:30] micahg: it'd be easier if you can propose a merge or give me the .ben file — otherwise I might be able to look in 10 hours time or so [09:31] I wonder why the desktop team aren't caring about this transition [11:37] Ok, so http://harvest.ubuntu.com/ now has all the build failures from oneiric ftbfs page [12:03] in a package build, for include modifications, is better use a "debian/patch" folder or a *.diff.gz file? [12:14] no one? [12:16] debian/patches [12:21] soren: ok thanks [12:21] soren: but *.diff.gz is deprecated? [12:28] blackmoon-105: .diff.gz is the format used for uploading to the archive. It's probably not something you should be dealing with directly. [12:30] It's not 'deprecated', but it's generally considered cleaner (if a matter of personal taste and workflow) to use a patch system such as quilt to manage changes to the upstream source. [12:30] (fwiw, those patches will still end up in the .diff.gz if there is one, but they will be easier to read) [12:31] soren: so if i must add extra headers in the source code, i must use "debian/patch", right? [12:32] Laney: ^ [12:33] it's not 'must', but 'would be a good idea to' [12:37] Laney: ok, thank you :) [14:26] anyone have a oneiric powerpc available? what does: python -c "import Tkinter; print Tkinter.__version__" output? [14:29] python2.7 === hannesw_ is now known as hannesw === bdrung_ is now known as bdrung [16:14] Laney: ok, will try to propose a merge, idk, maybe they haven't noticed yet, thanks [17:04] jtaylor: $Revision$ [17:05] tumbleweed: k thx there seems to something wrong with it on powerpc then [17:05] (powerpc sort-of works with qemu-user) [17:05] (matplotlib fails to build because of this) [17:09] tumbleweed: what does python2.6 say? [17:12] jtaylor: $Revision: 73770 $ [17:12] is probably related to the -rc1 of python 2.7 [17:12] th [17:12] should I try a rebuild? [17:13] no I get the same "wrong" output on amd64 now [17:13] ok [17:13] the amd64 matplotlib build was done before -rc1 went into oneric [17:13] powerpc build was delayed a few days [17:15] will probably be fixed when 2.7.2 is final, then it should be rebuilt [17:29] jtaylor: you sure? it looks like an svn substitution, and python moved to hg [17:30] it did? [17:30] so its a upstream bug [17:30] barry: ^ [17:31] but matplotlib should probably not use the subsitution anyway [17:32] matplotlib should probably not care about that version so much, unless there is good need. But providing a useful __version__ isn't exactly a bad idea [17:51] how can i add an extra directory (with files) using quilt? I've tried but i've got thiseoor: " cp: omitting directory `headers-extra/' " [17:56] blackmoon-105: are you using cp -r ? [17:57] ah no I see the problem [17:57] jtaylor: yes because i can't pass -r parameter to cp throught quilty === didrocks1 is now known as didrocks [17:58] quilt add dir/* [18:03] jtaylor: great it works! thank you [18:10] blackmoon-105: why would add a whole directory as a patch? [18:11] micahg: because i need to include extra headers which are all in a directory [19:33] nhandler, Hey. What do you use to do your web UI mockups? === nenolod_ is now known as nenolod === apachelogger is now known as transitlogger === yofel_ is now known as yofel [21:23] is there a better way for multiple forked children to use a mutex than sysV semaphores? [21:49] psusi: you should be able to use a mutex accross many threads [21:49] psusi: why were you thinking semaphores? [21:49] is there something in the critical section that needs that? [21:50] I can't imagine [21:50] hes talking about forks not threads [21:50] jtaylor: sorry, misread [21:50] carry on [21:51] unfortunatly I have no answer :/ [21:51] aye... have a process that forks a few children and need to serialize a critical section [21:52] IMHO forks suck for this [21:52] but that's just me [21:52] the whole not-sharing-memory thing can be a female dog [22:10] there we go... mmap() + sem_init() [22:10] MAP_SHARED [23:08] cody-somerville: I'm using Balsamiq (link in my blog post). Jono recommended it to me (he used it for his LoCo Portal mockup). You also (depending on what you want to use it for) might qualify for a free key for it