[00:54] Can anyone tell me if I'm correct on this: For the next little while the best method for upgrading packages is to upload it to Debian and then request a sync into Ubuntu? [01:05] stochastic: yes [01:05] but if itsn't able, you need to do merge [01:06] ?? if it isn't able? [01:06] stochastic: even in general that's arguably the more courteous/proper way of getting it done unless it's direly urgent to get the new version into Ubuntu [01:08] ari-tczew: Even better than merging is getting the Ubuntu diff into Debian and then asking for a sync [01:11] ScottK: yes I know about it [01:12] this method make management more comfortable in future (only syncs request without any changes) [01:12] ari-tczew: It's not a point of comfort, but of effeiciency. If we don't get our stuff back into Debian and just merge, it's more work for us. [01:12] how do we give a package to debian? they don't really have the ppa system setup yet do they? Is there a motu group over there that you have to get in touch with? [01:13] jgoppert_: It depends on the package, but if you look at mentors.debian.net, they have a sponsorship process. [01:13] Also if you work on a package with a team maintainer in Debian, you can often contact that team and get stuff back into Debian [01:14] ScottK: if I send package to mentors.debian.net, do I need to wait for response from orginal maintainer? I'm asking about NMU. [01:14] ari-tczew: If it's an existing package, you need to work with the maintainer first [01:15] https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers for more details [01:15] OK, I'll learn about it leater. [01:16] * stochastic politely grumbles about debian worrying about their own external health... [01:17] wish debian and ubuntu would just merge and get it over with [01:17] I think that I'll upload more packages than in karmic's cycle with good co-operation with sponsors. [01:18] ari-tczew: Perhaps set a goal to become a sponsor during this cycle. [01:18] jgoppert_: Not possible. Different goals. [01:19] http://www.google.com/trends?q=ubuntu%2C+debian [01:19] Yeah, but can't everyone just get along we'd have more development in the same direction [01:20] ScottK: It would be nice! [01:20] jgoppert_: No, they can't, it's the nature of large, distributed projects. [01:20] If I'll learn about forwarding packages to Debian, I'll request candidate to MOTU. [01:20] jgoppert_: If only there weren't actual people involved, sure. [01:21] people suck, nothing new there [01:24] If debian and ubuntu's bug tracking and package uploading worked closer together, then ubuntu developers woudn't have to re-learn everything to make their contributions to debian [01:24] ok ok.. i used to love debian, but was soo much work, so do you guys just run a virtual machine and do your work there? [01:25] That or work in a chroot. [01:25] well i've got some gui stuff so probably would want to double check it was actually functional [01:25] question: Do I need to join first MOTU, then join ubuntu-universe-sponsors? === micahg1 is now known as micahg [01:26] stochastic: Package uploading it pretty much identical. It's just where you point the package. [01:26] ari-tczew: Yes [01:27] ScottK, but why can't I just point it to a single place and both projects look at it? [01:27] OK, thanks ScottK for information. [01:28] ScottK, or request a package upgrade in one place and have the .dsc file considered by both debian and ubuntu [01:31] stochastic, things get... confusing... if one of the two distros rejects your package for some reason, e.g. there was a bug in it [01:31] you end up with packages with the same version number, but different content [01:31] it's awkward enough when the source packages are incompatible between distros (different md5sum) [01:33] should my data files be installed as uvsim-data with arch=all? [01:34] directhex, true, there are challenges, but the systems are very disparate from an initial user's view. Why can't I log into the debian bug tracker with my lauchpad account, or check a box to have it duplicated in debian's tracker, etc... [01:34] stochastic, it would be nice to be able to mangle debian bugs from launchpad [01:35] stochastic, but they ARE disparate. debian has its own infrastructure which it's built up over about 17 years [01:36] well then launchpad should integrate with them. [01:36] I'm just wishing, not really expecting change overnight [01:50] to install my doxygen documenation do i just put doc/html/* in the debian/doc file? [02:00] what does this mean? E: uvsim source: not-binnmuable-any-depends-all uvsim-apps -> uvsim-data === ubott2 is now known as ubottu [02:02] jgoppert_, binnmu is a debian-only problem. [02:03] it resulted from uvsim-app Depends: uvsim-data (= ${binary:Version}) [02:03] i just wiped the binary:Version part out is that the right thing to do? [02:09] no queue now on the build farm, so much better than a week ago [02:11] jgoppert_, you can run lintian -i on your package to get a verbose description of problems [02:11] thanks [02:11] stochastic: Lots of reasons. To start with the different maintenance model. Ubuntu team maintenance and Debian individual maintainers don't align well. [02:15] on my sf project i setup doxygen to build but didn't put the html in my tarball, so i added the doxygen build command to the build section of the rules file, is that pretty standard? [02:20] jgoppert_: Yes. We need to be able to build everything from the source. [02:21] Your tarball should contain source. Doxygen output doesn't sound like source. [02:23] cool, that's what i did [03:56] I'm trying to build a debian unstable pbuilder environment, but using this pbuilderrc file: http://pastebin.ubuntu.com/314790/ It gives me the error Failed getting release file http://mirrors.kernel.org/ubuntu/dists/sid/Release [03:57] err, /ubuntu/dists/sid *would* be invalid [03:58] stochastic: Install ubuntu-dev-tools and then do pbuilder-dist sid create [04:02] ScottK, thanks, I had been doing pbuilder create --distribution sid [04:03] pbuilder-dist can make it a lot easier. [04:13] this is my .pbuilrrc: http://pastebin.ubuntu.com/314802/ [04:13] works great === YDdraigGoch is now known as Richie [04:27] http://sandrotosi.blogspot.com/2009/11/things-that-make-me-angry.html [04:27] o_O [04:28] directhex: very cool to see Mono getting a compacting GC! [04:29] LucidFox: I'm pretty sure Mez referenced that blog post, too [04:32] Yes, on Planet Ubuntu. That's where I found it. [04:32] LucidFox: There were a number of reactions on planet.debian too. None particularly supportive. [04:50] On a tangentially-related note... [04:50] I noticed that when my package is sponsored into Debian, a binary package for amd64 is always uploaded, even though I only uploaded the source package to mentors. [04:51] Is it the sponsor who builds the binary package? [04:52] how can i make pbuilder-dist not generate packages owned by root [04:52] LucidFox: Yes. [04:53] pbuilder w/o -dist doesnt [04:53] LucidFox: Debian always does binary uploads. This way they know stuff at least built once before upload. [04:57] ScottK: They do not know that. [04:57] ScottK: They know that somehow on the uploader's system a binary package was produced. [04:57] wgrant: Well that's the theory. [04:57] Agreed. [04:57] I think source uplaods are better. [04:58] The Debian way often misses build-depends because people don't build in a clean chroot. [04:59] My favorite was one package (don't recall which) where the username of the Debian maintainer was hard coded into the path used in one of the maintainer scripts. It could only build on his system [05:00] That's awesome! [05:01] Ehehehe [05:01] But mentors.debian.net is supposed to hold source uploads, right? [05:09] WHOOO! [05:09] I managed to fill a btrfs FS to 94.5% [05:10] LucidFox: Yes [05:10] jdong: How'd the exam go? [05:10] ScottK: oh almost certainly failed. [05:11] So as predicted. [05:11] I might have understood the first question :) [05:11] that's an accomplishment. [05:11] * ScottK remembers exams like that [05:11] Vaguely. [05:11] It was a long time ago [05:14] OK, first pass through my merges is done. 15 syncs. 5 more that will be once depends are sorted. 3 more that will be once Debian stuff in progress is done, and 3 actual merges. [05:15] That may be my best sync ratio so far. [05:15] ScottK: But Ubuntu doesn't give anything back, remember... [05:15] wgrant: Well yeah. Except all this crap. [05:16] A fair fraction of those were just pulled from Debian patches that the maintainer hadn't dealt with. [05:16] Ah. [05:16] One I had bbdebian sponsor a QA upload for me. [05:17] The rest were properly sent back to them. [05:17] Oh, one I'm the maintainer in Debian, but it was close to release so I just uploaded. === sbalneav_ is now known as sbalneav [05:23] wgrant: Also one of the three uploads was reportbug where it's pretty unavoidable. [05:24] Every time I build a package I keep getting this difference in debian/control : http://pastebin.ubuntu.com/314836/ [05:25] it is due to the @GNOME@ in control.in and I am wondering if this is something I should be concerned with or ignore? the diff is between the debian package and the ubuntu package I merged with it [05:27] Oh, packages.qa.debian.org now shows the version in NEW. [05:32] nobody? [05:33] serialorder: Ignore it. [05:33] serialorder: It's crazy GNOME packaging stuff. [05:34] And is of no concern beyond that implicit in having automatically generated control file. [05:34] +s [05:34] i didn't add that, I just worked on the morge ;) [05:35] Right. [05:35] merge* [05:38] ok second question, sometimes if the merge is simple and it is only going to take a short amount of time I will work on the merge before posting the bug report [05:39] then I end up in this annoying situation where I have to post the bug report, find out the big number, go back and edit the diff to include it and post a second comment actually including the attachments [05:39] is there a less tedious way to do that? [05:54] serialorder: Become a MOTU so you can just upload it and not bother with the bug. Short of that, no. [05:54] ScottK, i am working on it [05:55] :-) [05:58] eglibc # james_w, don't want it slipping in by mistake [05:58] I take Ubuntu isn't going to migrate to eglibc anytime soon? [05:59] LucidFox: Already did. [05:59] Hasn't it already? [05:59] ...Oh. [05:59] yes, it has. [06:20] ScottK: around? [06:20] nxvl: Barely [06:20] ScottK: Just commented on Bug #413252 [06:20] Launchpad bug 413252 in courier "package courier-base 0.61.2-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [High,Triaged] https://launchpad.net/bugs/413252 [06:20] i can't reproduce it [06:20] have you? [06:22] nxvl: No. I didn't try. Based on that and the Debian bug it seemed pretty clear. Did you have maildrop installed before you intalled courier-base? === neoXsys is now known as neoxsys [06:34] ScottK: nope [06:34] ScottK: i knew there was some other package i was missing [06:34] trying [06:37] apt-get source package grabs from karmic is there a way to get lucid source in a similar way? [06:38] serialorder: bzr branch lp:ubuntu/package_name [06:38] thanx nxvl [06:41] nxvl, bzr branch lp:ubuntu/lucid/tracker gives me error tracker in lucid has no default branch. [06:41] serialorder: let me check [06:41] yeah, it hasn't been bzrized [06:42] serialorder: you will need to download it from launchpad [06:42] serialorder: https://edge.launchpad.net/ubuntu/+source/tracker [06:42] ok so when does the method you mentioned first work? [06:43] serialorder: we are moving everything to bzr branches, but is still work in progress [06:43] oh ok [06:43] serialorder: most of the package have already branches, but some of them aren't still bzrized, i think for DIF we will have all the archive in bzr [06:43] but i'm being optimist [06:43] serialorder: most probably the importer failed to import the package. you can try yourself with 'bzr import-dsc' [06:44] serialorder: where do you live? as in country [06:44] serialorder: Or you edit your /etc/apt/sources.list to have the deb-src lines point to lucid. [06:44] US [06:45] oh, then probably you won't overlap much, but if you are still here in 2 hours, james_w will probably be around and you can ask him more about the bzr thing [06:45] serialorder: oh yeah, what ScottK said will work too [06:45] hopefully i will be asleep in 2 hours =) [06:46] ScottK: btw, did you got more info about the universe going away plans? [06:46] ScottK: i'm REALLY confused about ti [06:46] it* [06:46] ScottK, i think that will do the trick [06:46] nxvl: Did you see my mail to the MOTU list about the spec item for UDS? [06:46] i'm even doubting on applying to core-dev because of it [06:46] ScottK: subscribed already [06:47] ScottK: and will be there if it doesn't overlap with any session i'm running [06:47] OK. [06:48] We'll get it figured out. [06:48] i was just courios if you got any more infor on that, because there is not much around [06:48] nxvl: I mostly know from reading specs and tech board meetings. [06:48] It's not entirely clear. [06:49] yeah, that's what i mean [06:49] ther eisn't something really clear on the topic [06:49] i kinda like the idea, since we have had problems in the past because of the motu/core-dev separation, but things should be clearer === funkyHat_ is now known as funkyHat [06:50] (i.e. kde guys applying for motuship and complains about non-kde people that they have no idea who he is) [06:51] Same thing with Server Team people and sometimes ubuntu-desktop people. [06:52] yeah [06:52] i just mentioned kde as an example [06:52] but it's really s/kde/specific-team/ [06:52] Yep. [06:52] well, time to go to bed [06:52] read you tomorrow [06:53] ugn, apt hasn't finished running [06:53] ugh* [06:58] slytherin: yes, there are known issues with ppc and sound anomalies, but no more so than other arches [06:58] slytherin: if you're trying to debug this on Ubuntu (no KDE, Xfce, etc.), you should try PULSE_NO_SIMD=1 [06:58] dtchen: Ok. So should I file a bug or leave it? [06:58] I will try tonight [06:59] ScottK: was able to reproduce the bug [06:59] slytherin: if in doubt, always file a new bug [06:59] Ah. Good. [06:59] ScottK: it was indeed maildrop [07:00] nxvl: OK. Then sound like the patch is the right thing to do. [07:00] dtchen: ok [07:01] ScottK: will do tomorrow, need to sleep now :D [07:01] Sure thing [07:46] What's a symbols file, and where can I read more about it? [07:59] LucidFox: have you read dpkg-gensymbols(1)? [08:02] * LucidFox reads [08:04] <\sh> moins [08:04] good morning [08:04] hi dholbach! [08:05] * porthose_ tips his hat [08:05] hi porthose_, siretart`, \sh === porthose_ is now known as porthose [08:08] hi [08:10] * LucidFox takes extra care to type "dput mentors" rather than "dput ubuntu" === dholbach_ is now known as dholbach [08:44] good morning one and allk [08:49] morning! [09:06] Hi there. :) I wonder, how long is it expected to take until the CoC 1.1 will appear on launchpad.net/codeofconduct? [09:07] Rhonda, hi, I guess this a #launchpad question :) [09:08] Ah, didn't know about that channel, and given that MOTUs have to sign it ... ;) [09:08] yes, actually all Ubuntu Members should have it signed but the last time I signed it was like 2 years ago, so no new version is out yet [09:09] Rhonda, The current version is 1.0.1, released 2005-04-12 [09:10] I got the impression after mako's blog about the new version that it should already be up, or at least is expected to be there soon. [09:10] av`: Yes, and that's the one I have issues with, that's why I'm waiting for 1.1 :) [09:11] Rhonda, I see 1.1 was approved already by the CC on the 20th of October [09:11] I know that. :) [09:12] Rhonda, maybe someone forgot to update the LP page, worth asking on #launchpad, maybe with the ppl being busy for the release they left that out :) [09:13] Dropped my message there already. ;) [09:13] ... thanks to your notice. [09:14] np, let me know the progress on it [09:14] Nobody told LP about it. [09:14] that's why then :) [09:14] It will probably not be on LP until 3.1.11 (2009-12-05), unless somebody makes a pretty compelling case for its necessity. [09:15] wgrant: That some people have issues with the old CoC and won't sign it isn't compelling enough? [09:16] Rhonda: Well, it has been that way for nearly five years now. Another three weeks shouldn't make terribly much difference. [09:17] ... combined with that the old version only spoke of developers and not of community members as a whole, belittling other contributors than code contributors. [09:19] Rhonda, it's already approved so it's just an issue of having it on LP, so you can start contributing since the old CoC will become obsolete [09:20] av`: Unfortunately not because that would require the signed CoC. [09:20] AIUI [09:21] well, having it signed is needed if you are going to join the developers / members teams, but that require some months to happen usually, so nobody prevents you to start contributing now since in three weeks it will be uploaded into LP [09:22] you stated that you will sign the latest CoC so it's fine IMHO [09:22] av`: Besides, I already did a fair amount of bug handling over time without having it signed anyway, if that's what you want to suggest. :) [09:23] yeah, so who prevents you to start doing what have you planned to do [09:24] Applying for motu might be the next step on my agenda. ;) [09:24] Or upload right for a subset of packages from what persia suggested to me. And AIUI that also requires the signed CoC. [09:24] I didnt see your name into the queues yet, so you can start preparing some updates / debdiffs if you didnt already [09:25] e.g you need several sponsors talking about your work positively before applying [09:26] Well, no, one needs several endorsements. Whether those are sponsors or not is only tangentially relevant. [09:27] persia, sponsors + several uploads done I would say [09:28] av`: Several uploads done to fix LP bugs, yes (but take a look at the e.g. wesnoth changelog). For people who have other ways to get stuff into the archive, sponsors are more optional. [09:29] persia, sure, I was telling how it generally work for 'normal' ppl ;) [09:29] Oh, sure. I agree with you for most cases :) [09:29] huhi persia, long time no see .. everything fine? =) [09:29] Technically I still prefer to fix stuff inside Debian for Ubuntu too so all involved parties do benefit from it. :) [09:30] sebner: Just painfully busy, but that should be over soon. [09:30] persia: sounds great :) [09:30] * Rhonda still tries to come up with a way to get away with the ubuntu irssi diff, but that's unfortunately a bit more complicate. [09:31] Anyway, off to a meeting. :) [09:34] Rhonda! [09:34] Good to see you here. :) [09:55] Rhonda, can you show me your debian/rules snippet for the irssi diff? we could use that for some other packages [10:02] directhex: There isn't one: see http://patches.ubuntu.com/i/irssi/irssi_0.8.14-1ubuntu1.patch [10:03] * LucidFox looks at REVU and weeps. [10:03] The first 17 packages are for Jaunty. [10:05] persia, oh... :/ [10:05] directhex: There are packages that *do* have such snippets. Usually based on /etc/lsb-release or something. [10:05] I'm not sure what to do with all the old packages on REVU. [10:07] persia, yeah, lsb_release munging, i use that... but not for applying patches [10:08] LucidFox: I have a few low-priority packages that I update every 6 months ... perhaps the good thing to do would be to advocate them ? :P anyway I'll have to update them for lucid now [10:08] LucidFox: I generally just reviewed them if they were up for review, regardless of age, and nuked them if there was no response to a review for 3 months. [10:08] julez: Updating soonest would likely get REVU scanners more excited :) [10:09] I share the fault though, not advertising them that much [10:40] LucidFox: You know that you always could have pestered me in other places, too. ;) [10:40] I do know. [10:41] Still, glad to see you here. [10:41] directhex: That's what I meant with "unfortunately a bit more complicate" - not there yet. :) [10:41] julez> Update them for lucid and ping me here! [10:42] LucidFox: thank you, as soon as I can :) [10:43] When karmic development started, I reviewed the oldest packages on REVU and put them all on "needs work", pointing out other problems besides the distribution. [10:43] If there were any [11:25] looking for stuff to do... [11:25] fcuk112: What sort of stuff do you like to do? [11:26] fix bugs, packaging [11:26] new features to existing apps perhaps. [11:26] Any particular sort of applications that interest you more? [11:27] not really fussed. would really like to help out with audio but it's a little out of my league i think. [11:28] Perhaps working with applications that use audio? [11:29] For example, there's a heap of bugs in the audacity package, which probably needs someone to look at fixing a chunk of them and otherwise triaging the rest: https://launchpad.net/ubuntu/+source/audacity/+bugs [11:30] that's an idea, thanks i'll take a look. [11:30] Good luck! [11:30] :) [11:43] LucidFox: thanks for your analysis [11:43] LucidFox: faac has license problems anyway, see the bugtracker. for the rest, well, I totally agree to your email [12:43] hi, how do I get an advocate for a package I uploaded to revu? http://revu.ubuntuwire.com/p/rhythmbox-radio-browser thanks for any help [12:53] segler: Asking here is a good way (although not too often) [12:55] ttx: When processing merges for packages maintained by Debian java team if the diff is really small I suggest that you file bug in Debian (or let me know so that I can file them) so that we can make it a sync. [12:56] slytherin: I know that we have many Ubuntu Developers who have connections to certain packaging teams in Debian. Do you think it would be beneficial to have a wiki page listing this information? [12:57] nhandler: Surely. [12:57] slytherin: so far I've been committing the diff to debian-java svn [12:57] ttx: That's great. I will check them and get someone to upload them. [12:57] slytherin: but yes, that sounds more productive [12:58] slytherin: I'll create one this afternoon then when I get home (unless you feel like making it earlier) [12:58] slytherin: most of the fixes I commit are the -headless and default-jdk usual suspects [12:59] slytherin: + some java bytecode level adjustments [12:59] slytherin: so that code generated matches the runtime dep [12:59] ttx: They benefit Debian too. And in the end reduces maintenance overhead. :-) [13:00] slytherin: that's why I committed those directly [13:01] slytherin: We can do the commit-in-debian/sync style for the next relevant ones [13:02] sure [13:02] what was the command again to create sync requests ? [13:03] c_korn: requestsync [13:03] slytherin: thanks [13:04] * slytherin wonders why sun-java6 has been orphaned in Debian. :-( [13:08] slytherin, because it's evil non-free? [13:08] Rather, because it's not default-jdk for any arches anymore. [13:08] directhex: The reason is not explained in the bug. [13:08] persia: It never was. === ogra_ is now known as ogra [13:09] slytherin: Well, in terms of package relationships, perhaps. In terms of default java client was perhaps different. [13:11] persia: I don't think so. Openjdk is still not as perfect as most users would want. [13:12] slytherin: I think it's that it's as perfect as the ex-maintainer of sun-java6 needed it to be :) [13:12] persia: ex-maintainer? You mean doko has retired? [13:13] slytherin: I don't mean to imply anything beyond that the package is currently orphaned. [13:14] hmm. May be I should add comment on bug asking why. [13:14] No point really. [13:14] It's not terribly hard to maintain, if you want it. Just sign up for the right Sun mailing list, and review each of the service release updates as they come out. [13:15] If you don't want it, no point asking :) [13:16] persia: Point is that the bug should contain reason why it was orphaned. The last upload was just about a month ago. [13:16] slytherin: And the bug filer differs from the last uploader. [13:16] right [13:17] Could ask, but maybe the answer exists at l.d.o somewhere already. [13:17] I will check [13:19] I want the package libjhdf5-java to be synced (http://packages.debian.org/sid/libjhdf5-java) but requestsync quits with this error: E: The package 'libjhdf5-java' does not exist in the Debian primary archive in 'sid' [13:22] this is the command I used: requestsync -n -d sid --lp libjhdf5-java lucid [13:23] c_korn: Congratulations! You now have the opportunity to teach requestsync about contrib :) [13:23] persia: that is not the reason. [13:24] c_korn: requestsync needs source package name. You are using binary package name. [13:24] * persia stops attempting to suggest fixes for tools never used [13:25] c_korn: And in lucid the syncs should happen from squueze (testing) instead of sid (unstable) unless you have very string reason for sync from sid. [13:25] /string/strong [13:28] slytherin: ok. I have already files another sync request (bug 479981). should I mark it as invalid and reopen it for squeeze ? [13:28] Launchpad bug 479981 in ubuntu "Sync libjgraphx-java 1.0.2.7-1 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/479981 [13:29] c_korn: Probably easier just to change the title/description [13:29] c_korn: probably mark it incomplete until package makes into testing. [13:38] slytherin: ok, done. === Ash-Fox_ is now known as Ash-Fox [14:13] asac: how about putting m-d under the hood of the debian mozilla team? [14:14] bdrung: the debian mozillateam is a-no-team [14:14] asac: what's a a-no-team? [14:14] a no-team ;) [14:15] asac: how can a team be a no-team? [14:15] consider you going in a room with a label "team" with a bunch of folks and noone working in a team ... thats a no-team [14:16] so no. i think the right place is to put it in ubuntu [14:16] basically ubuntu is the only place where you will be able to maintain things like this in a team. noone wants to do serious mozilla stuff in debian. and debian even has no user base so you dont even get feedback there [14:16] i just made a new upload addressing the comments on revo. so I'm asking if somebody could review it: http://revu.ubuntuwire.com/p/rhythmbox-radio-browser thanks in advance === neoXsys is now known as neoxsys [14:18] i was long enough on debian side only to compare ... and all i see is that in debian a mozillateam does not work [14:18] asac: can you leave a comment on http://glandium.org/blog/?p=495 ? [14:18] no [14:18] you should not start discussing things with mike on debian/ubuntu relation [14:18] he hates ubuntu [14:19] so it will only lead to a bike shed [14:19] ubuntu is the big evil thing in the world ... [14:19] yes [14:19] k [14:20] i tried to engange with him for a long time ... send him patches for years ... all worth nothing [14:20] what he did first thing when i moved to ubuntu was to drop his patch system ;) [14:20] so ubuntu cannot reuse his work ... and extract patches easily [14:20] :) [14:20] not sure if he finally pushes his private git branch somewhere [14:20] heh [14:20] but he didnt do that for the first years at least [14:21] seems like the debian-Ubuntu flames are reigniting [14:21] no i dont flame [14:21] what is d-m? [14:21] just explain the situation [14:21] mozilla-devscripts [14:21] that's sad. free software is about collaboration. [14:22] * jdong nods [14:22] siretart: dm is 'deutsche mark' :p [14:22] I see [14:22] hehe [14:22] dm is debian maintainer ;) [14:22] jaja :) [14:22] are patches in debian/patches directory applied before clean target is run during a build? [14:23] no ... they are unapplied (if the build system is a bit sane) [14:23] not sure i understand your question ;) [14:24] slytherin: Check debian/rules. If clean: depends on patch: it does. If it doesn't, it doesn't (not doing so is more common) [14:24] asac: There is a problem in the clean target itself. I have created a patch to fix it. But apparently the patch is not getting applied. [14:24] I always thought one should depend on unpatch in the clean target. === highvolt1ge is now known as highvoltage [14:25] jdong: that approach breaks if you patch the upstream build system and rely on your patches during cleanup [14:25] siretart`: ah, right [14:25] I've fortunately not encountered that level of brokenness yet ;-) [14:26] * siretart` can't await the dpkg version 3 source level format [14:27] what's new/different in version 3 exactly? [14:27] quilt is integrated, you don't have to care about patch system integration anymore [14:27] ah [14:28] jdong: And you don't need to uuencode binary changes anymore, it's not a .diff.gz but a debian.tar.gz [14:28] persia: So should I add the dependency on patch? [14:29] whoo! now that's cool :) [14:29] Also, it finally allows orig.tar.bz2 [14:29] even multiple [14:30] * jdong nods [14:30] * Rhonda thinks of converting wesnoth to v3 rather sooner than later. [14:30] Upstream ships .bz2 :) [14:30] where's the best place to look for info about this? [14:31] slytherin: If you want to apply all the patches before clean. If you just want to apply one, do it in the clean: rule, and unapply it when you're done. [14:31] I think madduck aggregated some blog articles about it. [14:31] persia: I guess I will apply only one. [14:32] siretart: when will it be supported by Ubuntu? [14:32] bdrung: ubuntu supports it actually for ages. launchpad support is finished but not deployed yet. will come with the next launchpad release [14:34] So 5th December? [14:34] siretart: for ages? is version 3 that old? [14:34] bdrung: see the dpkg changelog [14:35] bdrung: it was included in debian lenny [14:36] bdrung: It has to be supported in a stable release to be able to get used for the upcoming reason because the build daemons obviously run stable and shouldn't break. :) [14:36] * Rhonda . o O ( ... like it happened with the "Breaks:" control field addition, interestingly ) [14:44] Hey guys quick question, what would the equivalent of using binary-post-install/package in debian/rules be if I use dh7? [15:08] Heya gang [15:25] huhu bddebian === erhesrhsrtb54vyh is now known as Elbrus [15:31] Heya sebner [15:40]