[05:13] <micahg> is it better to include unistd.h to fix an FTBFS or to properly resolve something like ::close()
[05:18] <StevenK> If it's C, do the include.
[05:19] <micahg> nope, c++
[05:21] <StevenK> cunistd ?
[05:43] <micahg> StevenK: I see unistd.h is included in other files, so I'll use it as well
[05:45]  * micahg is curious that it didn't fail on amd64, but did on every other arch
[05:53] <micahg> tumbleweed: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1311 seems to have broken submittodebian on precise
[06:00] <pwnguin> debfx: i see you have a ppa containing mozilla-sync-server. i gather you might know why it's not functioning on 12.04?
[06:37] <tumbleweed> micahg: ah. that wa sa branch prepared on the plane and I haven't tested it all that much yet
[06:37]  * micahg reverted to the precise version in the mean time
[07:00] <dholbach> good morning
[07:01] <ajmitch> morning dholbach
[07:03] <dholbach> hey ajmitch
[07:14] <debfx> pwnguin: it requires sqlalchemy 0.6 but ubuntu 12.04 has 0.7
[07:14] <geser> good morning
[07:22]  * micahg thinks he's going to cry, amd64 seems to be the only sane arch in quantal
[07:23] <ajmitch> micahg: isn't that a good thing? :)
[07:23] <micahg> ajmitch: not when it means my amd64 test build is worthless for the rest of the archs :)
[07:24] <ajmitch> heh
[07:24] <ajmitch> don't you have an i386 build?
[07:24]  * micahg just compressed 4GB of build logs
[07:24] <micahg> I do, but that means I have to build everything twice before uploading
[07:25] <micahg> I usually only do that when I'm worried i386 will break for some other reason
[07:25] <ajmitch> not fun for firefox or anything else large
[07:29] <geser> micahg: including <unistd.h> is the right fix for such FTBFS, see also http://gcc.gnu.org/gcc-4.7/porting_to.html
[07:30] <micahg> geser: I saw that, but it didn't have an example of something with the scope resolution operator
[07:32] <geser> it should apply there too, as the error is due the source relying on that other headers included unistd.h in the past
[07:32] <micahg> yeah, it worked fine, I just wasn't sure what was more correct as I saw a couple different ways to fix in various Debian patches
[07:34] <micahg> ajmitch: for better or worse the same arch differences seem to be in Debian as well
[10:28] <AmberJ_> Hello
[10:38] <bobweaver> Hello AmberJ_
[10:39] <AmberJ_> Is there a way to automatically create a graph for a to-be-created package?
[10:40] <AmberJ_> I'll like to create a graph which outlines a package and it's dependencies.
[10:40] <AmberJ_> This can be 'manually' done using tools like graphviz. But I want something that'll allow me to 'automate' this process.
[10:41] <AmberJ_> Of course, I can write a script to do this for a particular project. But I thought of asking here first to see if other package maintainers use something similar.
[10:41] <bobweaver> Not sure AmberJ_  I am very new to packaging my-self but I am sure that there is someone here that will be along shortly hold tight. :)
[10:44] <AmberJ_> I just need a high level quick graphical representation to represent dependencies for a project.
[10:45] <AmberJ_> bobweaver, ok I'll hang in here to see if someone replies :)
[10:46] <bobweaver> AmberJ_,  google tells me this http://collab-maint.alioth.debian.org/debtree/
[10:46] <bobweaver> but once again I have no clue
[10:49] <AmberJ_> bobweaver, I guess your link does what apt-rdepends does.
[10:49] <AmberJ_> For e.g. here's visualization of dependencies on 'apt': apt-rdepends -d -r apt > deps.dot && dot -Tpng deps.dot > deps.png && eog deps.png
[10:50] <bobweaver> not sure I am going to test out right now
[10:50] <bobweaver> I think it is funny what apt-cache debtree says about it
[10:54] <AmberJ_> In any case, I don't think debtree or apt-rdepends will help me as I need to create dependency graphs for "yet-to-be-created" packages.
[10:55] <bobweaver> oh like a flowchart ?
[10:55] <bobweaver> I use libredraw for my flowcharts
[10:55] <bobweaver> but once again I am new
[10:56] <AmberJ_> I need exactly what 'debtree' does. But debtree creates graphs if package exist in the repo. I need to do this for a package which is NOT in the repo.
[10:56] <AmberJ_> And, not libredraw... I need an automated script to do this.
[10:56] <bobweaver> but you have .deb ?
[10:57] <AmberJ_> nope
[10:57] <bobweaver> sorry I am sure someone will come along :)
[10:58] <AmberJ_> Ok, here's what I'm doing. I'm doing packages for a project but I'll like to see if project developers agree with "packaging ontology" that I chose. So, I'll like a graph that represents how different components in the project will be packaged.
[10:59] <AmberJ_> Project has many components which can work independently. So, I'll create separate packages for them. In fact, we predict that we'll end up creating 20-30 packages for the project. I'll like to create a graph that represents these packages and how they depend on each other..
[11:01] <geser> AmberJ_: how do intend to figure out the dependencies of your yet-to-get-packaged programm?
[11:02] <AmberJ_> Right now I can think of only two ways:
[11:04] <AmberJ_> 1. Using cmake: The project uses cmake. 'cmake' has an option to build dependency graphs using graphviz .... using "cmake --graphviz=file.dot"
[11:04] <AmberJ_> But the graph that gets created is huge (hundreds of nodes). I tried customizing the graph using cmake-graphviz options but could not get what I want.
[11:05] <AmberJ_> 2. Another way is to write a script that parses a simple plaintext file (with a predefined format) to create a graphviz dependency graph.
[11:05] <AmberJ_> The file may look like:
[11:06] <AmberJ_> package1: package2, package3
[11:06] <AmberJ_> which means that "package1" depends on "package2" and "package3". My script will parse this file to create a graphviz/dot graph.
[11:07] <AmberJ_> So, I thought maybe you guys already use something like this...
[11:08] <Laney> If you can get them into an apt repository, there is apt-cache dotty. Otherwise I don't know (beyond writing a script) I'm afraid.
[11:11]  * bobweaver is having tons of fun with debtree now .. wonder how long and big of a picture  debtree ubuntu-desktop | dot -Tpng >ubuntu-desktop.png    will do 
[11:12] <AmberJ_> Laney, yes, my task is to get them into launchpad PPA but since I never contributed to project's codebase, I'll like developers to confirm that packaging 'classification' that I'm choosing is correct.
[11:12] <AmberJ_> The devs know exactly how components depend on each other.
[11:12] <AmberJ_> I guess I'll have to write my own script then..
[11:58] <bregma> AmberJ_, package1-> package2->package3 _is_ a dot script, have you though of doing that?
[11:58] <AmberJ_> err no, let me check.
[12:10] <dupondje> If we have a specific delta to support KDE, we still merge this? As KDE is not 'supported' anymore by Ubuntu.
[12:22] <geser> dupondje: yes, still merge (if the delta is still needed). universe isn't 'supported' either and we keep the delta
[12:38] <dupondje> geser: ok :)
[12:46] <dupondje> New upstream version with the fix included exists, lets see how hard it is to get it uploaded in debian ... :)
[13:22] <dholbach> Laney, broder, tumbleweed: we agreed on fortnightly meetings(every 2nd and 4th Thursday), right?
[13:23] <Laney> I thought we just agreed on the first one :P
[13:23] <Laney> but that sounds reasonable
[13:23] <Laney> also … I *ahem* … won't be able to make the first meeting
[13:24] <dholbach> that's inexcusable
[13:24] <Laney> sack me :(
[13:24]  * dholbach adds first agenda item: decide on Laney's punishment
[13:24]  * dholbach hugs Laney
[13:24] <Laney> the research group is having an 'away day' that day
[13:30] <dholbach> Laney, does http://paste.ubuntu.com/999028/ look good to you? (anything I forgot?)
[13:31] <dholbach> also did I add some standing agenda items to https://wiki.ubuntu.com/MOTU/Meetings
[13:31] <dholbach> Laney, did we decide to present our first bug fixing initiative at the first meeting already?
[13:31] <dholbach> if so, I better start putting some work into it
[13:32] <Laney> that would be nice, but it doesn't have to be at the meeting if it's not ready imho
[13:32] <Laney> don't forget to link to the agenda from the mail
[13:32] <dholbach> ah yes, of course
[13:32]  * dholbach hasn't written meeting announces in a while ;-)
[13:32] <Laney> "Decide on future meeting times"
[13:33] <dholbach> hum, I thought we'd go with fortnightly Thursday 16 UTC meetings for now
[13:33] <Laney> sure, should make certain everyone else understands this too
[13:33] <Laney> even if we did decide it at UDS, hopefully there will be people who weren't there turning up
[13:34] <dholbach> right, unfortunately the meeting won't be the best time for people who disagree with the timing of it to bring up an alternative :-P
[13:34] <dholbach> but yeah, let's add it as an agenda item for the meeting
[13:35] <Laney> and "find people to blast away most of our crufty wiki pages"
[13:35]  * Laney would help there
[13:35] <Laney> ah, andrewsomething got WIs for that
[13:35] <Laney> (twice..?)
[13:36] <dholbach> ok, mail sent out
[13:37] <dholbach> I'll follow up on the original MOTU-Q-Plans thread as well
[13:37] <Laney> cool!
[13:56] <dupondje> somebody here that can sponsor something for me in Debian ? :)
[13:57] <dupondje> http://mentors.debian.net/package/eterm
[14:00] <dupondje> Whats the easies way to merge a changelog now the MoM doesn't handle this anymore ..
[14:00] <dupondje> easiest*
[14:01] <dupondje> or can we just remove the previous ubuntu changelog entries ?
[14:28] <dupondje> https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication somebody want to endorse me ? :)
[14:32]  * dholbach might have sponsored one or the other upload :)
[14:33] <dupondje> Big chance ;)
[14:33] <Laney> dupondje: are you adopting it?
[14:34] <dupondje> I finally took all my inspiration to create a Wiki page ... :)
[14:35] <geser> dupondje: try dpkg-mergechangelog
[14:36] <dupondje> k :)
[14:36] <Laney> http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=Jean-Louis+Dupond&sponsoree_search=name
[14:37] <dholbach> dupondje, done
[14:38] <dupondje> dholbach: thx
[14:46] <dupondje> geser: what arguments should I use exactly for dpkg-mergechangelogs, man isnt very clear
[15:37] <Laney> dupondje: I just noticed that the previous maintainer (muammar@d.o) offered sponsorship
[15:37] <Laney> you should probably take that up
[15:39] <dupondje> where did you see that? :)
[15:40] <Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620507
[15:40] <dupondje> ah yea, well don't know if I want to maintain that package :) upstream is also quite dead ...
[15:41] <dupondje> but the last upstream version has some wanted fixes so
[15:41] <Laney> is there any worth in keeping it around instead of removing it?
[15:41] <Laney> he'll probably be wiling to sponsor a QA upload anyhow
[15:41] <Laney> but if you don't hear back in a week or so, you can ping me
[15:42] <dupondje> ok!
[15:45] <dupondje> http://developer.ubuntu.com/packaging/html/udd-merging.html this is still up-to-date ? :)
[15:49] <dholbach> dupondje, it's supposed to be - there were some bugs filed though which we want to get fixed
[15:50] <dholbach> dupondje, anything specific which looks problematic to you?
[15:50] <dholbach> maybe barry can help answer some questions in that case :)
[15:50] <dupondje> not really problems. Just trying my first merge with bzr :)
[15:51]  * barry wakes up
[15:51] <barry> dupondje: i think that page is still accurate
[15:52] <dupondje> 1) bzr checkout https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/snort/quantal 2) bzr merge debianlp:sid/snort 3) fix the conflicts 4) add changelog 5) commit ?
[15:54] <barry> dupondje: i'd use `bzr branch ubuntu:snort` probably (just shorter).  step 5 is optional.  you *could* let the importer do all the magic, rather than pushing a new ubuntu:snort revision.  i'd definitely recommend that if quilt is involved.  other folks have different strategies, but this works for me
[15:56] <dupondje> lets see :)
[15:58] <dupondje> Most recent Debian Sid version: MISSING
[15:58] <dupondje> normal ? :)
[15:58] <tumbleweed> sounds like you're going to have to merge it by hand
[15:58] <Laney> in my experience that happens with debian branches even when they are up to date
[15:58] <Laney> check the changelog
[16:00] <dupondje> Also bzr diff -r tag:2.9.2.2-1 gives me tons of changes, while only 2 lines were changed in Ubuntu ... :)
[16:03] <tumbleweed> don't forget those branches are patches applied, so you'll be seeing .pc stuff too
[16:03] <dupondje> bbl
[16:04] <dupondje> how can I ignore that? cause with that overhead its no cool overview :)
[16:04] <Laney> filterdiff
[16:05] <Laney> or -- debian/ to bzr diff
[17:06] <dupondje> bzr diff -r tag:2.9.2.2-1 debian/ seems to give correct diff
[17:06] <dupondje> but now if I commit, all the other changes will be comitted also ?!
[19:12] <dupondje> https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication => Still some endorsments wanted ! :)
[19:39] <micahg> dupondje: I'd suggest e-mailing people asking for endorsement and listing what they've sponsored for you
[19:42] <dupondje> micahg: i'll spam some people personally on IRC :)
[19:57] <dupondje> tumbleweed: could you add your endorsment ? :)
[19:58] <tumbleweed> dupondje: already got it in an open tab, waiting for some time
[19:58] <dupondje> great! :)
[19:58] <dupondje> no stress
[20:20] <dupondje> when is there another mass-sync ?
[20:21] <tumbleweed> they should be ~daily... but it depends on cjwatson's sleep schedule, I think :)
[20:21] <dupondje> 3 days behind it seems (need audacious synced :))
[20:23] <Laney> it might still be syncing from testing
[20:26] <dupondje> could you sync audacious? then I can merge/syncreq audacious-plugins :)
[20:28] <tumbleweed> dupondje: you're application could be longer. if you've done SRUs / security / uploads in debian. you should mention them
[20:29] <jtaylor> there was a sync today
[20:29] <jtaylor> from testing
[20:30] <dupondje> tumbleweed: i'll add those tomorrow :)
[20:30] <dupondje> jtaylor: quantal doesn't sync from unstable?
[20:31] <jtaylor> don't know, maybe there was a 10day gap between todays sync and the last one
[20:31] <tumbleweed> we started by syncing from testing, but the plan is to switch to unstable
[20:31] <tumbleweed> except that apparently launchpad doesn't make that switch easy
[20:31] <dupondje> ah ok
[20:32] <ajmitch> tumbleweed: LP should be simple to fix, right? :)
[20:33]  * tumbleweed leaves that to ajmitch
[20:33] <micahg> it's open source, anyone can do it :)
[20:34] <ajmitch> tumbleweed: nah you just annoy one of the webops to manually clean up the database to get around it
[20:35]  * dupondje is still messing with bzr merges
[20:35] <dupondje> bzr: ERROR: [Errno 2] No such file or directory: '/home/dupondje/quantal/bzr/snort/.pc/applied-patches'
[20:36] <dupondje> boo ! :)
[20:40] <cjwatson> dupondje: I'm running them daily, still from testing until I get confirmation from infinity that the armel compiler issues are sorted out
[20:41] <cjwatson> tumbleweed: I'm just going to ignore the issues with DSD generation and work around them with a sledgehammer *shrug*
[20:41] <dupondje> aha ok :)
[20:42] <tumbleweed> :)
[20:43] <cjwatson> easy enough to just compare lists of published sources, though I'll have to be a bit careful about performance I guess
[20:43] <cjwatson> but it's only daily
[20:43] <cjwatson> it's iterating over several thousand DSDs anyway
[20:44] <tumbleweed> yeah, that's fairly straightforward
[20:45] <cjwatson> really must get around to cronning auto-sync after that
[20:45] <cjwatson> aside from the obvious batch mode stuff I think it just needs something to check whether new packages are alrady in the queue
[20:46] <cjwatson> *already
[20:46] <cjwatson> and maybe something to mail out lists of new packages that need inspection for some reason
[20:47] <dupondje> any news on the MoM btw ?
[20:47] <cjwatson> yes, got the new machine installed today, just waiting on them syncing over a forgotten directory before I can try it out
[20:47] <cjwatson> so should be really close
[20:48] <dupondje> aha great !
[20:48] <dupondje> missing grab-merge :)
[20:48] <dupondje> merging changelogs manually are annoying me :)
[20:48] <jtaylor> dpkg-mergechangelogs
[20:49] <dupondje> jtaylor: what arguments to use? cause I tried it, but couldn't get a correct output
[20:50] <jtaylor> good question, I mostly let git handle it for me :)
[20:55] <dupondje> héhé :) well was stuck there also
[20:57] <stgraber> dpkg-mergechangelogs a/debian/changelog b/debian/changelog > c/debian/changelog
[20:58] <dupondje> Usage: dpkg-mergechangelogs [<option> ...] <old> <new-a> <new-b> [<out>]
[20:58] <dupondje> your missing some :)
[21:04] <jtaylor> old is the merge-base new-[ab] is ubuntu/debian
[21:05] <tumbleweed> bdrung: hrm, we do we still have mergechangelog in u-d-t?
[21:06] <bdrung> tumbleweed: yes (merge-changelog)
[21:06] <stgraber> dupondje: oh right, was thinking of merge-changelog and not dpkg-mergechangelogs ;)
[21:07] <tumbleweed> bdrung: err I meant to ask why
[21:08] <bdrung> tumbleweed: dunno. maybe because noone cares about it?
[21:08] <tumbleweed> dpkg-mergechangelogs looks like it does everything this did
[21:08] <jtaylor> it is easier to use than dpkg-mergechangelogs
[21:09]  * tumbleweed has never used dpkg-mergechangelogs, maybe I should try it :)
[21:09] <jtaylor> its not so nice
[21:09] <jtaylor> isn't the version parsing code used in merge-changelogs in some library?
[21:10] <tumbleweed> err yeah python-debian
[21:15] <dupondje> merge-changelog old-ubuntu debian-new
[21:15] <dupondje> seems to work fine!
[21:32] <tumbleweed> oh well, I'll not retire mergechangelog quite yet, then
[21:33] <dupondje> can't get dpkg-mergechangelogs give me a valid output :(
[21:35] <tumbleweed> that's either user error, a bug, or a documentation bug :)
[21:36] <dupondje> who will tell ... :D
[21:39] <dupondje> tumbleweed: https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication added some more info :)