[09:26] krisives: debian/rules is executble so you can just run "debian/rules unpatch" [09:27] Or slightly more aggressively, "fakeroot debian/rules clean" [09:27] hyperair, building XD [09:28] Right now everytime I want to make my test deb I have to run make -f debian/rules unpatch [09:28] I just do ./debian/rules unpatch instead? [09:33] You don't even need the ./ [09:34] <\sh> /window 14 [09:34] <\sh> grmpf [09:37] Zhenech: oh pbuilder's fixed eh? [09:37] hyperair, yupp [09:38] ah, good =) [09:39] Anyone know a good C regular expression library I should use? [09:39] hyperair, done [09:40] that was fast O_o [09:41] well, it wasnt really big :) [09:41] hmm true =\ [09:41] hyperair, btw, if you have time, it'd be nice to replace the hardcoded 0.17 version of geany with something dynamic (parse the output of geany --version and put it in substvars?) [09:43] oh yeah that would be a good idea. [09:45] geany --version |awk '{print $2}' [09:45] that prints the version just fine :) [09:51] or pkg-config --modversion geany [09:53] or that, right === yofel_ is now known as yofel === azeem_ is now known as azeem [10:58] hi, how to cancel a dh_auto_test? [10:58] rawang: ctrl-c? [10:58] or do you mean "how do you make it not run?" [11:01] cjwatson, yeah [11:01] how do I make it not run :) [11:02] cjwatson, I just leave %: to do dh $@ [11:02] i mean [11:02] %: [11:02] dh $@ [11:02] use dh7 [11:03] That will certainly run dh_auto_test [11:03] yould you just have a blank override_dh_auto_test ? [11:03] yes [11:03] oh, [11:04] override_dh_auto_test with nothing command right? [11:04] just put override_dh_auto_test: [11:04] then dh voodoo will run whatever you specify instead of dh_auto_test [11:05] which is nothing [11:05] good idea [11:07] right, sorry, that was what I was going to suggest but I got distracted :) [11:07] if you do that, you need to build-depend on debhelper (>= 7.0.50) [11:08] I also have to ask - why? [11:08] it should be unusual to have to arrange *not* to run a test suite [11:08] so it's worth looking into why you feel the need to turn this off, and fixing it [11:09] cjwatson, so what is usual way to disable the tests? [11:10] cjwatson, the tests need a dbus daemon within build environment, but apparently the temp build environment don't have [11:11] Laney, StevenK directhex thanks for you ideas :) [11:12] the tests should perhaps create a private dbus session so that they don't intefere with anything on the system [11:12] cjwatson: I believe that is the version that adds the override_* handling [11:13] james_w: yes [11:13] james_w: what I meant is why does he need to disable the test suite [11:13] ah, sorry, misread [11:13] cjwatson, yep, so what is usual way to disable the tests? [11:13] rawang: we already gave you the usual way to disable the tests - but it's also usual, when disabling tests, to consider why [11:13] but not using override [11:13] it's best not to disable tests at all [11:14] yes, agreed [11:14] dh 7 didn't have an elegant way to disable tests before 7.0.50 - you could do it but it was painful [11:14] dh build --before dh_auto_test # I think [11:14] and that might confuse something else - so use that only if you're prepared to debug stuff :) [11:15] cjwatson, the build is ahead of test already [11:16] but seems like override_dh_auto_test won't work [11:16] rawang, nah, the point is, the debian/rules "build" rule is handled as "dh build" which runs through a long list of dh_foo commands. you used to specify "dh build --before dh_foo" then "dh build --after dh_foo" to make changes to dh_foo behaviour [11:18] directhex, yes, i see, but the problem is i only want to skip the dh_auto_test [11:18] rawang, which is what i just described - the old pre-7.0.50 way to do that [11:18] rawang, doesn't the build system have a --disable-tests or something? [11:19] directhex, and override_dh_auto_test doesn't work, my debhelper is 7.0.17ubuntu4 [11:19] well, that explains why it doesn't work [11:20] let me find an example of old overrides [11:20] directhex, yea, unluckily, the build system don't have a --disable-tests options :( [11:20] gnome-subtitles in pkg-cli-apps svn [11:20] directhex, sure, thanks ! :) [11:20] ok [11:21] http://svn.debian.org/wsvn/pkg-cli-apps/packages/gnome-subtitles/trunk/debian/rules [11:21] rawang: why not patch the source to not run the tests. [11:22] slytherin, you mean patch an option to disable the tests for configure? [11:22] something like that [11:23] why's that better than overriding dh_auto_test? [11:23] slytherin, ok, nice, but I might need to skip the tests first to see whether it works or not, thanks :) [11:23] I suppose you could disable some of the test [11:23] Laney: it will surely work no matter what version of debhelper. :-) [11:23] s [11:23] heh [11:23] a versioned build-dep is no problem... [11:24] directhex, there is not a "skip test" from your example [11:25] if --disable-tests is specified, the dh will not run dh_auto_test wisely? [11:27] rawang, there's an override though - dh_auto_configure is overridden [11:27] rawang, try also nant [11:28] directhex, sorry, what is nant? :) [11:28] directhex, even though I could override configure, but does it help to avoid running dh_auto_test? [11:29] rawang, another overridden package [11:29] ok [11:29] rawang, um..... the point here is you do as cjwatson says, and use "dh build --before_auto_test \n dh_build --after dh_auto_test" as your build: rule [11:30] is it? [11:30] and then the build rule will do everything before, and everything after, dh_auto_test in its list o' commands - but not dh_auto_test [11:30] I thought the point was to override and version the b-d [11:30] Laney, or that [11:30] * Laney spins in circles [11:30] * Laney goes back to just a minute [11:30] * directhex flings a monkey at Laney [11:31] directhex, oh, the point is run all the dhs before and after dh_auto_test, so that we could skip dh_auto_test, right? [11:31] right [11:31] got it [11:32] ugh, it appears to be complicated then, :( [11:32] rawang, easier with 7.0.50! [11:33] if my debhelper > 7.0.50, i could just using "override_dh_auto_test: with nothing " to simply skip the dh_auto_test, right? [11:34] right [11:34] ok [11:34] will try === noodles775 is now known as noodles775-afk [11:52] geser: thanks for adding the debian bug watcher to the bug. I completely forgot about that === jussi01_ is now known as eviljussi01 [12:12] andv, about bug #400528 [12:12] Launchpad bug 400528 in taskjuggler "Please merge taskjuggler 2.4.3-1 from Debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/400528 [12:13] fabrice_sp, yeah [12:13] the address is the new one that has to be used ("Ubuntu Developers discuss@lists.ubuntu.com>" ) [12:14] it's auto generated by update_maintainer script [12:14] fabrice_sp, ppl keep using the other one [12:14] it seems [12:14] I'll check the changelog, because I let MoM generate it, and it seems MoM is forgetting some things [12:14] the MOTU one, you mean? [12:15] fabrice_sp, yeah, some ppl keep using MOTU one [12:15] fabrice_sp, does it really matter? === ryanakca_ is now known as Guest23202 [12:16] andv, I'm just following https://wiki.ubuntu.com/DebianMaintainerField (and I already had this discussion here about the right Maintainer value) [12:16] it changed in May 2009 [12:17] fabrice_sp, perfect then [12:17] leave that comment out ;) [12:18] ok :-) I'll check the changelog entries when at home (in 6 hours, more or less :-/ ) thanks [12:18] fabrice_sp, np, watch out for missing entries in the future [12:20] andv, I generally use meld to compare the changelog. I'll check what happened in that case. Bye [12:20] fabrice_sp, perfect, cya === a|wen_ is now known as a|wen [12:41] does anyone know how to boot live CD iso using grub2? [12:45] andv: as long as people switch over gradually eventually, it's not *that* important [12:45] cjwatson, ok perfect [12:45] slytherin: no idea, no effort put into it, and doing that would certainly lose the graphical menu for now [12:45] cjwatson, anyway when revieweing I gonna tell them it's better to adopt the new way [12:46] slytherin: I'd like to switch over to it eventually (maybe a couple of cycles out); you're welcome to try it now as long as you're aware that you'll be trailblazing :) [12:47] cjwatson: Perhaps I put my question wrong. I read in one of the articles mentioned in latest UWN that it is possible to boot a ISO image from grub so there is no need to burn that ISO to a CD. [12:48] I don't know the answer, but I'd start with grub.enbug.org [12:49] I searched on the grub wiki. Didn't find anything there. [12:49] there's an iso9660 module, certainly === noodles775-afk is now known as noodles775 [12:49] I am wondering where did th article writer get that info from [12:49] 'insmod iso9660' in the grub shell and play around from there? [12:49] Ok. Let me try. [13:08] hi folk, [13:08] Recently django released a stable/security update [13:08] http://www.djangoproject.com/weblog/2009/jul/28/security/ [13:10] Is this the sort of thing that should be applied to Universe SRU? [13:11] wrt django is it possible to update it to 1.0.3 directly? upstream has a pretty big range of various tests [13:11] unfortunately those tests aren't distributed in tarballs.. [13:12] I have attempted to create an update to 1.0.3 following the update recipe on the MOTU wiki [13:12] Just wondering what the next step would be === ryanakca is now known as Guest56094 [13:21] andv: Might if I take a mergin (unison) question here, instead of going on and on in the comment field? [14:10] didrocks: Are you going to update clutter-gtk? [14:10] didrocks: Since you didn't put clutter-gtk-0.9 into the archive [14:11] StevenK: I wasn't planning putting 0.9 into the archive but waiting for 1.0 (I didn't checked if it's released yet) [14:11] didrocks: It's out, 0.10.2 [14:11] didrocks: Which requires clutter 1.0 [14:12] StevenK: ok, can this wait for this week-end? (and clutter 1.0 is waiting for an archive admin approval FYI) [14:12] didrocks: I'm a member of -archive, I'm just about to accept it [14:12] or is there some emergency on that? (not sure to be able to handle it before this timeline) [14:12] didrocks: Well, is it in Debian? [14:12] StevenK: thanks :) If you can have a look about mutter, this will be awesome [14:13] StevenK: it's still in NEW. I'm working with kov merging the changes [14:13] (same for mutter) [14:13] didrocks: It's not my archive day, I was just asked to look at clutter since I know about it [14:14] didrocks: I'd prefer it sooner [14:15] StevenK: ok, I will try to take a look at it this evening. If I can't, I will tell you tomorrow, is that ok? [14:15] didrocks: Sure. I'm happy to finish up the work, given some direction, too. [14:16] StevenK: great :) === Guest56094 is now known as ryanakca === ryanakca is now known as Guest44125 === paulproteus_ is now known as paulproteus === Guest44125 is now known as ryanakca === ripps_ is now known as ripps [15:30] bdrung, fetching your stuff [15:30] 18k/s [15:30] why is mentors sooo slow [15:30] Zhenech: no idea [15:36] bdrung, are there any lookworth changes to the packaging besides of the fix for #536480? [15:37] not for arc-colors at it seems :) [15:37] s/at/as/ [15:40] Hello to upload to mentors.debian.net is this the correct config file? http://pastebin.com/mca03d0a [15:40] same for shiki colors *build* [15:45] bdrung, I guess you tested the alternatives stuff? I have no gnome to tamper with here :) [15:49] Zhenech: it's running on my two systems, and the PPA is updated, too (tested by many people). I only broke thing for Ubuntu hardy users. ;) [15:49] haha [15:49] I dont care for ubuntu ;) [15:50] (well, I do, but... you know ;)) [15:50] Zhenech: i know. the packages fits better into debian than ubuntu. === noodles775_ is now known as noodles775 [15:51] stupid inkscape btw, when it is launched in batch/headless mode, it still complains it cant open a DISPLAY... [15:55] Zhenech: yes. and it can behave strange with relative pathes: https://bugs.launchpad.net/inkscape/+bug/398221 [15:55] Launchpad bug 398221 in inkscape "export drawing to png failed" [Undecided,Confirmed] [15:56] Zhenech: i tried imagemagik for transforming svgs into pngs, but the result is crap. [15:56] never tried [15:56] I guess I made one SVG in my life [15:56] and that was using inkscape :) [15:56] btw [15:57] there is a minor glitch in your gnome common postinst [15:57] Zhenech: imagemagik is *the* command line tool for images (but it fails on svgs) [15:57] bdrung, I know, you don't want to know how many "convert" calls I have in several scripts at work [15:57] converting JPG and PDF back and forth [15:57] wi28 [15:57] ups [15:58] Zhenech: i use it for converting my wallpapers. [15:58] bdrung, any reason you call update alternatives on EVERY invocation of the postinst? [15:59] wouldnt "configure" be sufficient? [16:00] Zhenech: i don't know. the script is mostly stolen from gnome-icon-theme. [16:01] Zhenech: all noteworty changes are commented in the changelog. So there are no changes for arc and shiki. For gnome-colors there is only the bug fix. [16:03] yeah, arc and shiki are fine, will upload "gleich" :) [16:04] for gnome its better to wrap that call into [16:04] if [ "$1" = configure ]; then [16:04] ... [16:04] fi [16:04] imho [16:09] Zhenech: when will configure run? [16:10] see http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [16:10] esp 6.6 6.7 and 6.8 [16:11] interestingly you also use remove or deconfigure in your prerm, and one of my own packages has remove or upgrade for the same task... [16:12] time for a smoke, brb :) [16:13] YokoZar: arne is onto you about .otf files in games [16:14] spring-engine includes FreeSansBold.otf, it should just depend on ttf-freefonts [16:26] bdrung, shiki uploaded [16:28] bdrung, arc uploaded === FlannelKing is now known as Flannel [16:55] Zhenech: i will have a look at all the maintainer scripts target and update the tonight. [16:56] ok [17:36] anyone know why the cairo-dock plugins aernt available in Ubuntu repos? [17:37] what package name? [17:38] Laney: cairo-dock has plugins available when installed from their repos , but not In the Ubuntu repos [17:40] maybe nobody packaged it [17:40] Laney: http://developer.berlios.de/project/showfiles.php?group_id=8724&release_id=15624 < plug-ins [17:40] Laney: do i send a mail to the list? [17:40] mac_v: because it's wainting in REVU [17:42] gilir: so ? when can we expect it in the Karmic repos? [17:42] when it's done [17:42] ;) [17:43] mac_v: you can monitor the status here : http://revu.ubuntuwire.com/p/cairo-dock-plugins [17:44] gilir: thanx for the link :) [17:44] DEB_BUILD_OPTIONS=nocheck dh_auto_test [17:44] what's this? [17:44] anyone else having problem with buildd script on jaunty? [17:45] I don't understand what you did to makeshlibs either [17:47] Laney: nocheck to skip the tests when using dh v7 [17:48] why not an empty override? [17:48] and makeshilbs to avoid unnecessary shlibs generation [17:49] Laney: I didn't know empty override works :) [17:49] yes sir [18:17] Can any of the python experts take a look at http://paste.ubuntu.com/247356/ and tell me if it is problem with buildd script? [18:26] andv, about the changelog of taskjuggler [18:28] there is a sync in hardy, and also in Intrepid, so the ubuntu specific changelog has been lost before then. Does it make sense to add the Ubuntu entry before 2.4.1-1 (Intrepid)? [18:29] This is not the way I've done merge until now, as I only recover the Ubuntu entries in the last changelog available. [18:29] andv: Hey, that ^^ was pretty much the same question I was about to ask you :) [18:30] andol, :-) === Fluffles is now known as Cuddles [18:30] the merge request for taskjuggler is bug #400528 (in case you want to have a look :-) ) [18:30] Launchpad bug 400528 in taskjuggler "Please merge taskjuggler 2.4.3-1 from Debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/400528 [18:57] I've been able to build successfully sound-juicer. Is it possible for some MOTU to give-back the build. so that it get rebuilt? Thanks [19:00] fabrice_sp: Done. [19:00] fabrice_sp: All archs? [19:00] Ah. [19:00] thanks jpds ! (and iulian too :-) ) [19:01] iulian: The buildd script filters out all the successful ones. :) [19:02] why do i get this error? even though I have correct version of cmake installed? [19:02] dpkg-checkbuilddeps: Unmet build dependencies: cmake (>= 2.6.4) [19:02] yeah: it was only i386 in that case (all others except powerpc has been already built) [19:03] though cmake is installed in /usr/local/bin [19:03] jpds: Oh cool, didn't know that. [19:03] kamalnandan, /usr/local is not good [19:03] kamalnandan, what is the output of apt-cache policy cmake ? [19:05] fabrice_sp: thanks for your response..here is the output.. [19:05] http://paste.ubuntu.com/247378/ [19:06] BTW..i downloaded the source of cmake 2.6.4 , built that and installed..and it got installed in /usr/local/bin only.. [19:08] fabrice_sp..if its installed in /usr/local/bin, is there any problem? [19:08] kamalnandan, why don't you just install the Ubuntu package? [19:09] kamalnandan, yes: debuild don't know about local application (in /usr/local). Only about packages [19:09] there is 2.6.2 only available in ubuntu package..i need 2.6.3.. [19:09] kamalnandan, 2.6.4 in karmic [19:10] kamalnandan, it would be easier to setup a karmic chroot [19:10] and build it inside (or a karmic pbuilder) [19:10] !pbuilder [19:10] pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto [19:10] i have jaunty..how do i setup karmic? [19:10] !chroot [19:10] chroot is used to make programs believe that the directory they are running in is really the root directory. It can be used to stop programs accessing files outside of that directory, or for compiling 32bit applications in a 64bit environment (https://wiki.ubuntu.com/DebootstrapChroot) [19:11] I love that ! thing :-) [19:11] Our lovely robot. [19:11] :-D [19:11] fabrice_sp...i havnt really ever used chroot.. [19:12] kamalnandan, with a chroot, you will avoid installing unnecessary packages in your normal environment [19:12] and you can have several versions (I even have a sid and a hardy chroot) [19:13] slytherin: I believe a work-around is going to be put in place. [19:13] fabrice_sp: how do we do that? [19:14] kamalnandan: Everything you want to know can be found in those wiki pages. [19:15] fabrice_sp, who says they are lost? [19:15] fabrice_sp, I see them [19:15] iulian: thanks..let me check that.. [19:15] fabrice_sp, taskjuggler (2.2.0-1ubuntu1) dapper; urgency=low [19:15] * debian/rules: call dh_iconcache [19:15] for example [19:15] fabrice_sp, you have to include all ubuntu changelogs [19:15] I hope that's clear [19:16] andol, yes? [19:16] andol, you added karmic/intrepid entries and lost all the previous ones [19:17] andol, what's not clear? [19:17] andol, unison (2.13.16-5ubuntu1) feisty; urgency=low [19:17] andol, unison (2.13.16-6ubuntu1) feisty; urgency=low [19:17] should I continue? [19:17] ;) [19:20] fabrice_sp: you meant this page ..right [19:20] https://wiki.ubuntu.com/PbuilderHowto [19:21] andv, when I say lost I mean that in the last changelog (for version 2.4.1-1ubuntu3), there is only changes since 2.4.1-1 because of the sync of 2.4.1-1. [19:21] fabrice_sp, https://edge.launchpad.net/ubuntu/+source/taskjuggler [19:22] fabrice_sp, it seems they are not lost in this page [19:22] Anyway, I'll recover all the ubuntu changes since the very first version, even if the package has been synced several time since then [19:22] andv, I was speaking in term of last changelog [19:22] fabrice_sp, what's the point of dropping changelog entries? [19:23] andv, it was already dropped. I didn't dropped them by myself [19:23] fabrice_sp, they got dropped cause a sync [19:23] yes [19:23] fabrice_sp, but LP register every changelog entry submitted [19:23] fabrice_sp, as you can see in the link I sent you [19:23] fabrice_sp, so take LP as reference [19:24] I knoiw. that's only that until now, I alsways used the last changelog as reference. I will change the way I do the merge to include all entris since dapper [19:24] using LP and not the changelog [19:25] follow LP [19:25] and you'll do good [19:25] :) [19:26] those pages are there to be checked [19:26] does that mean also that when you 'ubuntify' a package (to fix a FTBFS, fo r example), you should check the previous ubuntu version, and add all of them to the changelog? [19:26] or it only apply to merge? [19:26] fabrice_sp, you should answer yourself now :) [19:27] fabrice_sp, if you fix a FTBFS on Ubuntu you won't use the Debian package [19:27] but the one you find in the Ubuntu archives [19:27] when you do a merge, you grab debian package and apply ubuntu changes [19:28] losing changelog entries is not nice anyway [19:29] StevenK: I am wondering about how to deal with clutter-gtk-doc (as it is the same package name and files in 0.8 version). Do we plan to remove 0.8 in karmic and I add a Replaces: or do you think we should use make the same trick that in clutter, ie using version number in -doc package name? [19:30] tbh, I still don't see the point of recovering a changelog entry from dapper, when the package has been synced 8 times since then. But I will add the dapper entry. Should I also add the build* entries? [19:30] ooops: no build entry in that case [19:31] fabrice_sp, nvm [19:31] fabrice_sp, leave it as it is [19:31] np: I'm updating it right now [19:37] andv, new debdiff uploaded [19:37] fabrice_sp, perfect [19:38] fabrice_sp, thanks for the fast responses [19:38] fabrice_sp, I gonna process it later when I get back home [19:38] fabrice_sp: You helped me yesterday, right? [19:38] thanks to you to sponsor my upload [19:38] fabrice_sp, are you willing to become a developer? [19:38] krisives, I think so, yes [19:38] about the patches, right? [19:38] I found the problem I was having [19:39] or you are just a normal contributor [19:39] fabrice_sp: It was because my patch name was lexigraphically (caps) before the other patches [19:39] I actually filed a bogus bug report and then RTFM'd and it was in the man page :( [19:39] andv, for the moment, I'm just a u-c-d, but willing to become a motu at some point [19:39] krisives, this things happens, yes :-) [19:40] fabrice_sp, cool [19:40] Yeah, but alwys lame to be the guy who fails to RTFM [19:40] lol [19:40] fabrice_sp, when andol gets back tell him what to do [19:40] andv, ok [19:41] ty [19:41] yw :-) [19:45] fabrice_sp, where you the one who said you use mom? [19:45] The code in question is parsing an SFTP address by hand, and many NPE and other bugs have came from it, would it be a horrible idea to link with libpcre3 and use a regex? [19:46] andv, yes, but only to quickly get the dsc files, and the changelog. This is the part I will have to change [19:46] fabrice_sp, start doing merges manually [19:46] fabrice_sp, you'll improve and learn more [19:47] andv, apart from the changelog, I do it manually [19:47] easier to see what's happening [19:47] k [19:53] andv: You know, looking at the current Ubuntu unison package (2.27.57-1ubuntu1) doesn't contain any of those older changelog entries in its debian/changelog [19:54] andv: If we add stuff, neither present in the current debian or ubuntu package, is it really a merge then? [19:54] andol, add stuff? [19:54] we add something that was there before [19:55] andol, https://edge.launchpad.net/ubuntu/+source/unison [19:55] andol, you see any changelog you didnt add? [19:56] andv: Yes, I know LP keeps track of old stuff. What I'm saying is that the package unision 2.27.57-1ubuntu1 doesn't have those entires in its debian/changelog. [19:56] andol, so? [19:56] andol, it's something nice to do adding all changelog's entries [19:57] andv: Hence I'm confusing about it beinga merge of 2.27.57-1ubuntu1 and 2.27-57-2, since we are adding stuff which isn't actually in any of those two packages. [19:57] fabrice_sp, can you please explain him [19:57] im leaving [19:57] please only add the changelog entries since the last sync not all available ubuntu changelog entries [19:57] geser, why? [19:57] geser, I'm used to apply all changelog entries [19:58] geser, some other developers are used to apply them all [19:58] there is no rule against it [19:58] why do you add changelog entries for changes that have nothing to do with the current changes (i.e. when there was a sync in between) [19:59] geser, what's the point of dropping entries? [19:59] geser, does old entries hurt someone? [19:59] no, but they don't help either [19:59] some developers add them all, some other don't [19:59] there is no rule [19:59] and I prefer having all of them [20:00] why it is important to re-add changelog entries from dapper when you do a change in karmic? [20:00] geser, I'm used to do it [20:00] geser, I see nothing bad on doing it [20:00] geser, I could say the same of dropping them [20:01] geser, someone worked on that package on dapper so we have to credit him for his work [20:01] dropping stuff won't help [20:01] and why do we credit it only in dapper and karmic and not e.g. in jaunty (where the package is synced)? [20:02] geser, all changelog entries are added [20:02] geser, so we add jaunty stuff too [20:02] and when there are no ubuntu changes in jaunty? [20:02] then there are no ubuntu changelog entries there at all? [20:02] geser, if there are no changes we have to credit no one [20:03] and why do you want to credit someone for changes in dapper when adding a new change to a synced package? [20:04] or do I don't understand the problem? [20:04] it looks like you are not understanding [20:04]