=== jbicha is now known as Guest1332 [05:13] is it better to include unistd.h to fix an FTBFS or to properly resolve something like ::close() [05:18] If it's C, do the include. [05:19] nope, c++ [05:21] cunistd ? [05:43] 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] tumbleweed: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/1311 seems to have broken submittodebian on precise [06:00] 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] 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 === yofel_ is now known as yofel [07:00] good morning [07:01] morning dholbach [07:03] hey ajmitch [07:14] pwnguin: it requires sqlalchemy 0.6 but ubuntu 12.04 has 0.7 [07:14] good morning [07:22] * micahg thinks he's going to cry, amd64 seems to be the only sane arch in quantal [07:23] micahg: isn't that a good thing? :) [07:23] ajmitch: not when it means my amd64 test build is worthless for the rest of the archs :) [07:24] heh [07:24] don't you have an i386 build? [07:24] * micahg just compressed 4GB of build logs [07:24] I do, but that means I have to build everything twice before uploading [07:25] I usually only do that when I'm worried i386 will break for some other reason [07:25] not fun for firefox or anything else large [07:29] micahg: including is the right fix for such FTBFS, see also http://gcc.gnu.org/gcc-4.7/porting_to.html [07:30] geser: I saw that, but it didn't have an example of something with the scope resolution operator [07:32] 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] 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] ajmitch: for better or worse the same arch differences seem to be in Debian as well [10:28] Hello [10:38] Hello AmberJ_ [10:39] Is there a way to automatically create a graph for a to-be-created package? [10:40] I'll like to create a graph which outlines a package and it's dependencies. [10:40] This can be 'manually' done using tools like graphviz. But I want something that'll allow me to 'automate' this process. [10:41] 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] 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] I just need a high level quick graphical representation to represent dependencies for a project. [10:45] bobweaver, ok I'll hang in here to see if someone replies :) [10:46] AmberJ_, google tells me this http://collab-maint.alioth.debian.org/debtree/ [10:46] but once again I have no clue [10:49] bobweaver, I guess your link does what apt-rdepends does. [10:49] 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] not sure I am going to test out right now [10:50] I think it is funny what apt-cache debtree says about it [10:54] 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] oh like a flowchart ? [10:55] I use libredraw for my flowcharts [10:55] but once again I am new [10:56] 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] And, not libredraw... I need an automated script to do this. [10:56] but you have .deb ? [10:57] nope [10:57] sorry I am sure someone will come along :) [10:58] 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] 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] AmberJ_: how do intend to figure out the dependencies of your yet-to-get-packaged programm? [11:02] Right now I can think of only two ways: [11:04] 1. Using cmake: The project uses cmake. 'cmake' has an option to build dependency graphs using graphviz .... using "cmake --graphviz=file.dot" [11:04] 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] 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] The file may look like: [11:06] package1: package2, package3 [11:06] which means that "package1" depends on "package2" and "package3". My script will parse this file to create a graphviz/dot graph. [11:07] So, I thought maybe you guys already use something like this... [11:08] 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] 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] The devs know exactly how components depend on each other. [11:12] I guess I'll have to write my own script then.. === almaisan-away is now known as al-maisan [11:58] AmberJ_, package1-> package2->package3 _is_ a dot script, have you though of doing that? [11:58] err no, let me check. [12:10] If we have a specific delta to support KDE, we still merge this? As KDE is not 'supported' anymore by Ubuntu. [12:22] dupondje: yes, still merge (if the delta is still needed). universe isn't 'supported' either and we keep the delta === al-maisan is now known as almaisan-away [12:38] geser: ok :) [12:46] New upstream version with the fix included exists, lets see how hard it is to get it uploaded in debian ... :) [13:22] Laney, broder, tumbleweed: we agreed on fortnightly meetings(every 2nd and 4th Thursday), right? [13:23] I thought we just agreed on the first one :P [13:23] but that sounds reasonable [13:23] also … I *ahem* … won't be able to make the first meeting [13:24] that's inexcusable [13:24] sack me :( [13:24] * dholbach adds first agenda item: decide on Laney's punishment [13:24] * dholbach hugs Laney [13:24] the research group is having an 'away day' that day [13:30] Laney, does http://paste.ubuntu.com/999028/ look good to you? (anything I forgot?) [13:31] also did I add some standing agenda items to https://wiki.ubuntu.com/MOTU/Meetings [13:31] Laney, did we decide to present our first bug fixing initiative at the first meeting already? [13:31] if so, I better start putting some work into it [13:32] that would be nice, but it doesn't have to be at the meeting if it's not ready imho [13:32] don't forget to link to the agenda from the mail [13:32] ah yes, of course [13:32] * dholbach hasn't written meeting announces in a while ;-) [13:32] "Decide on future meeting times" [13:33] hum, I thought we'd go with fortnightly Thursday 16 UTC meetings for now [13:33] sure, should make certain everyone else understands this too [13:33] even if we did decide it at UDS, hopefully there will be people who weren't there turning up [13:34] 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] but yeah, let's add it as an agenda item for the meeting [13:35] and "find people to blast away most of our crufty wiki pages" [13:35] * Laney would help there [13:35] ah, andrewsomething got WIs for that [13:35] (twice..?) [13:36] ok, mail sent out [13:37] I'll follow up on the original MOTU-Q-Plans thread as well [13:37] cool! [13:56] somebody here that can sponsor something for me in Debian ? :) [13:57] http://mentors.debian.net/package/eterm [14:00] Whats the easies way to merge a changelog now the MoM doesn't handle this anymore .. [14:00] easiest* [14:01] or can we just remove the previous ubuntu changelog entries ? [14:28] https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication somebody want to endorse me ? :) [14:32] * dholbach might have sponsored one or the other upload :) [14:33] Big chance ;) [14:33] dupondje: are you adopting it? [14:34] I finally took all my inspiration to create a Wiki page ... :) [14:35] dupondje: try dpkg-mergechangelog [14:36] k :) [14:36] 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] dupondje, done [14:38] dholbach: thx [14:46] geser: what arguments should I use exactly for dpkg-mergechangelogs, man isnt very clear [15:37] dupondje: I just noticed that the previous maintainer (muammar@d.o) offered sponsorship [15:37] you should probably take that up [15:39] where did you see that? :) [15:40] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620507 [15:40] Debian bug 620507 in wnpp "O: eterm -- Enlightened Terminal Emulator" [Normal,Open] [15:40] ah yea, well don't know if I want to maintain that package :) upstream is also quite dead ... [15:41] but the last upstream version has some wanted fixes so [15:41] is there any worth in keeping it around instead of removing it? [15:41] he'll probably be wiling to sponsor a QA upload anyhow [15:41] but if you don't hear back in a week or so, you can ping me [15:42] ok! [15:45] http://developer.ubuntu.com/packaging/html/udd-merging.html this is still up-to-date ? :) [15:49] dupondje, it's supposed to be - there were some bugs filed though which we want to get fixed [15:50] dupondje, anything specific which looks problematic to you? [15:50] maybe barry can help answer some questions in that case :) [15:50] not really problems. Just trying my first merge with bzr :) [15:51] * barry wakes up [15:51] dupondje: i think that page is still accurate [15:52] 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] 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] lets see :) [15:58] Most recent Debian Sid version: MISSING [15:58] normal ? :) [15:58] sounds like you're going to have to merge it by hand [15:58] in my experience that happens with debian branches even when they are up to date [15:58] check the changelog [16:00] 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] don't forget those branches are patches applied, so you'll be seeing .pc stuff too [16:03] bbl [16:04] how can I ignore that? cause with that overhead its no cool overview :) [16:04] filterdiff [16:05] or -- debian/ to bzr diff [17:06] bzr diff -r tag:2.9.2.2-1 debian/ seems to give correct diff [17:06] but now if I commit, all the other changes will be comitted also ?! === Elbrus_tries_aga is now known as Elbrus [19:12] https://wiki.ubuntu.com/JeanLouisDupond/MOTUApplication => Still some endorsments wanted ! :) === jalcine is now known as Jacky [19:39] dupondje: I'd suggest e-mailing people asking for endorsement and listing what they've sponsored for you [19:42] micahg: i'll spam some people personally on IRC :) [19:57] tumbleweed: could you add your endorsment ? :) [19:58] dupondje: already got it in an open tab, waiting for some time [19:58] great! :) [19:58] no stress [20:20] when is there another mass-sync ? [20:21] they should be ~daily... but it depends on cjwatson's sleep schedule, I think :) [20:21] 3 days behind it seems (need audacious synced :)) [20:23] it might still be syncing from testing [20:26] could you sync audacious? then I can merge/syncreq audacious-plugins :) [20:28] dupondje: you're application could be longer. if you've done SRUs / security / uploads in debian. you should mention them [20:29] there was a sync today [20:29] from testing [20:30] tumbleweed: i'll add those tomorrow :) [20:30] jtaylor: quantal doesn't sync from unstable? [20:31] don't know, maybe there was a 10day gap between todays sync and the last one [20:31] we started by syncing from testing, but the plan is to switch to unstable [20:31] except that apparently launchpad doesn't make that switch easy [20:31] ah ok [20:32] tumbleweed: LP should be simple to fix, right? :) [20:33] * tumbleweed leaves that to ajmitch [20:33] it's open source, anyone can do it :) [20:34] 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] bzr: ERROR: [Errno 2] No such file or directory: '/home/dupondje/quantal/bzr/snort/.pc/applied-patches' [20:36] boo ! :) [20:40] 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] tumbleweed: I'm just going to ignore the issues with DSD generation and work around them with a sledgehammer *shrug* [20:41] aha ok :) [20:42] :) [20:43] easy enough to just compare lists of published sources, though I'll have to be a bit careful about performance I guess [20:43] but it's only daily [20:43] it's iterating over several thousand DSDs anyway [20:44] yeah, that's fairly straightforward [20:45] really must get around to cronning auto-sync after that [20:45] 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] *already [20:46] and maybe something to mail out lists of new packages that need inspection for some reason [20:47] any news on the MoM btw ? [20:47] yes, got the new machine installed today, just waiting on them syncing over a forgotten directory before I can try it out [20:47] so should be really close [20:48] aha great ! [20:48] missing grab-merge :) [20:48] merging changelogs manually are annoying me :) [20:48] dpkg-mergechangelogs [20:49] jtaylor: what arguments to use? cause I tried it, but couldn't get a correct output [20:50] good question, I mostly let git handle it for me :) [20:55] héhé :) well was stuck there also [20:57] dpkg-mergechangelogs a/debian/changelog b/debian/changelog > c/debian/changelog [20:58] Usage: dpkg-mergechangelogs [