[09:26] <maxb> krisives: debian/rules is executble so you can just run "debian/rules unpatch"
[09:27] <maxb> Or slightly more aggressively, "fakeroot debian/rules clean"
[09:27] <Zhenech> hyperair, building XD
[09:28] <krisives> Right now everytime I want to make my test deb I have to run make -f debian/rules unpatch
[09:28] <krisives> I just do ./debian/rules unpatch instead?
[09:33] <maxb> You don't even need the ./
[09:34] <\sh>  /window 14
[09:34] <\sh> grmpf
[09:37] <hyperair> Zhenech: oh pbuilder's fixed eh?
[09:37] <Zhenech> hyperair, yupp
[09:38] <hyperair> ah, good =)
[09:39] <krisives> Anyone know a good C regular expression library I should use?
[09:39] <Zhenech> hyperair, done
[09:40] <hyperair> that was fast O_o
[09:41] <Zhenech> well, it wasnt really big :)
[09:41] <hyperair> hmm true =\
[09:41] <Zhenech> 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] <hyperair> oh yeah that would be a good idea.
[09:45] <Zhenech> geany --version |awk '{print $2}'
[09:45] <Zhenech> that prints the version just fine :)
[09:51] <hyperair> or pkg-config --modversion geany
[09:53] <Zhenech> or that, right
[10:58] <rawang> hi, how to cancel a dh_auto_test?
[10:58] <cjwatson> rawang: ctrl-c?
[10:58] <cjwatson> or do you mean "how do you make it not run?"
[11:01] <rawang> cjwatson, yeah
[11:01] <rawang> how do I make it not run :)
[11:02] <rawang> cjwatson, I just leave %:   to do  dh $@
[11:02] <rawang> i mean
[11:02] <rawang> %:
[11:02] <rawang>         dh $@
[11:02] <rawang> use dh7
[11:03] <StevenK> That will certainly run dh_auto_test
[11:03] <directhex> yould you just have a blank override_dh_auto_test ?
[11:03] <Laney> yes
[11:03] <rawang> oh,
[11:04] <rawang> override_dh_auto_test with nothing command right?
[11:04] <Laney> just put override_dh_auto_test:
[11:04] <directhex> then dh voodoo will run whatever you specify instead of dh_auto_test
[11:05] <Laney> which is nothing
[11:05] <rawang> good idea
[11:07] <cjwatson> right, sorry, that was what I was going to suggest but I got distracted :)
[11:07] <cjwatson> if you do that, you need to build-depend on debhelper (>= 7.0.50)
[11:08] <cjwatson> I also have to ask - why?
[11:08] <cjwatson> it should be unusual to have to arrange *not* to run a test suite
[11:08] <cjwatson> so it's worth looking into why you feel the need to turn this off, and fixing it
[11:09] <rawang> cjwatson, so what is usual way to disable the tests?
[11:10] <rawang> cjwatson, the tests need a dbus daemon within build environment,  but apparently the temp build environment don't have
[11:11] <rawang> Laney, StevenK directhex thanks for you ideas :)
[11:12] <james_w> the tests should perhaps create a private dbus session so that they don't intefere with anything on the system
[11:12] <james_w> cjwatson: I believe that is the version that adds the override_* handling
[11:13] <cjwatson> james_w: yes
[11:13] <cjwatson> james_w: what I meant is why does he need to disable the test suite
[11:13] <james_w> ah, sorry, misread
[11:13] <rawang> cjwatson, yep, so what is usual way to disable the tests?
[11:13] <cjwatson> 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] <rawang> but not using override
[11:13] <cjwatson> it's best not to disable tests at all
[11:14] <rawang> yes, agreed
[11:14] <cjwatson> 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] <cjwatson> dh build --before dh_auto_test # I think
[11:14] <cjwatson> and that might confuse something else - so use that only if you're prepared to debug stuff :)
[11:15] <rawang> cjwatson, the build is ahead of test already
[11:16] <rawang> but seems like override_dh_auto_test won't work
[11:16] <directhex> 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] <rawang> directhex, yes, i see, but the problem is i only want to skip the dh_auto_test
[11:18] <directhex> rawang, which is what i just described - the old pre-7.0.50 way to do that
[11:18] <directhex> rawang, doesn't the build system have a --disable-tests or something?
[11:19] <rawang> directhex, and override_dh_auto_test doesn't work,  my debhelper is 7.0.17ubuntu4
[11:19] <directhex> well, that explains why it doesn't work
[11:20] <directhex> let me find an example of old overrides
[11:20] <rawang> directhex, yea, unluckily, the build system don't have a --disable-tests options :(
[11:20] <directhex> gnome-subtitles in pkg-cli-apps svn
[11:20] <rawang> directhex, sure, thanks ! :)
[11:20] <rawang> ok
[11:21] <directhex> http://svn.debian.org/wsvn/pkg-cli-apps/packages/gnome-subtitles/trunk/debian/rules
[11:21] <slytherin> rawang: why not patch the source to not run the tests.
[11:22] <rawang> slytherin, you mean patch an option to disable the tests for configure?
[11:22] <slytherin> something like that
[11:23] <Laney> why's that better than overriding dh_auto_test?
[11:23] <rawang> slytherin, ok, nice, but I might need to skip the tests first to see whether it works or not, thanks :)
[11:23] <Laney> I suppose you could disable some of the test
[11:23] <slytherin> Laney: it will surely work no matter what version of debhelper. :-)
[11:23] <Laney> s
[11:23] <Laney> heh
[11:23] <Laney> a versioned build-dep is no problem...
[11:24] <rawang> directhex, there is not a "skip test" from your example
[11:25] <rawang> if --disable-tests is specified, the dh will not run dh_auto_test wisely?
[11:27] <directhex> rawang, there's an override though - dh_auto_configure is overridden
[11:27] <directhex> rawang, try also nant
[11:28] <rawang> directhex, sorry, what is nant? :)
[11:28] <rawang> directhex, even though I could override configure, but does it help to avoid running dh_auto_test?
[11:29] <directhex> rawang, another overridden package
[11:29] <rawang> ok
[11:29] <directhex> 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] <Laney> is it?
[11:30] <directhex> 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] <Laney> I thought the point was to override and version the b-d
[11:30] <directhex> 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] <rawang> 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] <directhex> right
[11:31] <rawang> got it
[11:32] <rawang> ugh, it appears to be complicated then, :(
[11:32] <directhex> rawang, easier with 7.0.50!
[11:33] <rawang> 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] <directhex> right
[11:34] <rawang> ok
[11:34] <rawang> will try
[11:52] <c_korn> geser: thanks for adding the debian bug watcher to the bug. I completely forgot about that
[12:12] <fabrice_sp> andv, about bug #400528
[12:13] <andv> fabrice_sp, yeah
[12:13] <fabrice_sp> the address is the new one that has to be used ("Ubuntu Developers <ubuntu-devel-
[12:13] <fabrice_sp> discuss@lists.ubuntu.com>" )
[12:14] <fabrice_sp> it's auto generated by update_maintainer script
[12:14] <andv> fabrice_sp, ppl keep using the other one
[12:14] <andv> it seems
[12:14] <fabrice_sp> I'll check the changelog, because I let MoM generate it, and it seems MoM is forgetting some things
[12:14] <fabrice_sp> the MOTU one, you mean?
[12:15] <andv> fabrice_sp, yeah, some ppl keep using MOTU one
[12:15] <andv> fabrice_sp, does it really matter?
[12:16] <fabrice_sp> andv, I'm just following https://wiki.ubuntu.com/DebianMaintainerField (and I already had this discussion here about the right Maintainer value)
[12:16] <fabrice_sp> it changed in May 2009
[12:17] <andv> fabrice_sp, perfect then
[12:17] <andv> leave that comment out ;)
[12:18] <fabrice_sp> ok :-) I'll check the changelog entries when at home (in 6 hours, more or less :-/ ) thanks
[12:18] <andv> fabrice_sp, np, watch out for missing entries in the future
[12:20] <fabrice_sp> andv, I generally use meld to compare the changelog. I'll check what happened in that case. Bye
[12:20] <andv> fabrice_sp, perfect, cya
[12:41] <slytherin> does anyone know how to boot live CD iso using grub2?
[12:45] <cjwatson> andv: as long as people switch over gradually eventually, it's not *that* important
[12:45] <andv> cjwatson, ok perfect
[12:45] <cjwatson> slytherin: no idea, no effort put into it, and doing that would certainly lose the graphical menu for now
[12:45] <andv> cjwatson, anyway when revieweing I gonna tell them it's better to adopt the new way
[12:46] <cjwatson> 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] <slytherin> 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] <cjwatson> I don't know the answer, but I'd start with grub.enbug.org
[12:49] <slytherin> I searched on the grub wiki. Didn't find anything there.
[12:49] <cjwatson> there's an iso9660 module, certainly
[12:49] <slytherin> I am wondering where did th article writer get that info from
[12:49] <cjwatson> 'insmod iso9660' in the grub shell and play around from there?
[12:49] <slytherin> Ok. Let me try.
[13:08] <amar> hi folk,
[13:08] <amar> Recently django released a stable/security update
[13:08] <amar> http://www.djangoproject.com/weblog/2009/jul/28/security/
[13:10] <amar> Is this the sort of thing that should be applied to Universe SRU?
[13:11] <kklimonda> wrt django is it possible to update it to 1.0.3 directly? upstream has a pretty big range of various tests
[13:11] <kklimonda> unfortunately those tests aren't distributed in tarballs..
[13:12] <amar> I have attempted to create an update to 1.0.3 following the update recipe on the MOTU wiki
[13:12] <amar> Just wondering what the next step would be
[13:21] <andol> andv: Might if I take a mergin (unison) question here, instead of going on and on in the comment field?
[14:10] <StevenK> didrocks: Are you going to update clutter-gtk?
[14:10] <StevenK> didrocks: Since you didn't put clutter-gtk-0.9 into the archive
[14:11] <didrocks> 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] <StevenK> didrocks: It's out, 0.10.2
[14:11] <StevenK> didrocks: Which requires clutter 1.0
[14:12] <didrocks> StevenK: ok, can this wait for this week-end? (and clutter 1.0 is waiting for an archive admin approval FYI)
[14:12] <StevenK> didrocks: I'm a member of -archive, I'm just about to accept it
[14:12] <didrocks> or is there some emergency on that? (not sure to be able to handle it before this timeline)
[14:12] <StevenK> didrocks: Well, is it in Debian?
[14:12] <didrocks> StevenK: thanks :) If you can have a look about mutter, this will be awesome
[14:13] <didrocks> StevenK: it's still in NEW. I'm working with kov merging the changes
[14:13] <didrocks> (same for mutter)
[14:13] <StevenK> didrocks: It's not my archive day, I was just asked to look at clutter since I know about it
[14:14] <StevenK> didrocks: I'd prefer it sooner
[14:15] <didrocks> 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] <StevenK> didrocks: Sure. I'm happy to finish up the work, given some direction, too.
[14:16] <didrocks> StevenK: great :)
[15:30] <Zhenech> bdrung, fetching your stuff
[15:30] <Zhenech> 18k/s
[15:30] <Zhenech> why is mentors sooo slow
[15:30] <bdrung> Zhenech: no idea
[15:36] <Zhenech> bdrung, are there any lookworth changes to the packaging besides of the fix for #536480?
[15:37] <Zhenech> not for arc-colors at it seems :)
[15:37] <Zhenech> s/at/as/
[15:40] <coolbhavi> Hello to upload to mentors.debian.net is this the correct config file? http://pastebin.com/mca03d0a
[15:40] <Zhenech> same for shiki colors *build*
[15:45] <Zhenech> bdrung, I guess you tested the alternatives stuff? I have no gnome to tamper with here :)
[15:49] <bdrung> 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] <Zhenech> haha
[15:49] <Zhenech> I dont care for ubuntu ;)
[15:50] <Zhenech> (well, I do, but... you know ;))
[15:50] <bdrung> Zhenech: i know. the packages fits better into debian than ubuntu.
[15:51] <Zhenech> stupid inkscape btw, when it is launched in batch/headless mode, it still complains it cant open a DISPLAY...
[15:55] <bdrung> Zhenech: yes. and it can behave strange with relative pathes: https://bugs.launchpad.net/inkscape/+bug/398221
[15:56] <bdrung> Zhenech: i tried imagemagik for transforming svgs into pngs, but the result is crap.
[15:56] <Zhenech> never tried
[15:56] <Zhenech> I guess I made one SVG in my life
[15:56] <Zhenech> and that was using inkscape :)
[15:56] <Zhenech> btw
[15:57] <Zhenech> there is a minor glitch in your gnome common postinst
[15:57] <bdrung> Zhenech: imagemagik is *the* command line tool for images (but it fails on svgs)
[15:57] <Zhenech> bdrung, I know, you don't want to know how many "convert" calls I have in several scripts at work
[15:57] <Zhenech> converting JPG and PDF back and forth
[15:57] <Zhenech> wi28
[15:57] <Zhenech> ups
[15:58] <bdrung> Zhenech: i use it for converting my wallpapers.
[15:58] <Zhenech> bdrung, any reason you call update alternatives on EVERY invocation of the postinst?
[15:59] <Zhenech> wouldnt "configure" be sufficient?
[16:00] <bdrung> Zhenech: i don't know. the script is mostly stolen from gnome-icon-theme.
[16:01] <bdrung> 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] <Zhenech> yeah, arc and shiki are fine, will upload "gleich" :)
[16:04] <Zhenech> for gnome its better to wrap that call into
[16:04] <Zhenech> if [ "$1" = configure ]; then
[16:04] <Zhenech> ...
[16:04] <Zhenech> fi
[16:04] <Zhenech> imho
[16:09] <bdrung> Zhenech: when will configure run?
[16:10] <Zhenech> see http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[16:10] <Zhenech> esp 6.6 6.7 and 6.8
[16:11] <Zhenech> 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] <Zhenech> time for a smoke, brb :)
[16:13] <Riddell> YokoZar: arne is onto you about .otf files in games
[16:14] <Riddell> spring-engine includes FreeSansBold.otf, it should just depend on ttf-freefonts
[16:26] <Zhenech> bdrung, shiki uploaded
[16:28] <Zhenech> bdrung, arc uploaded
[16:55] <bdrung> Zhenech: i will have a look at all the maintainer scripts target and update the tonight.
[16:56] <Zhenech> ok
[17:36] <mac_v> anyone know why the cairo-dock plugins aernt available in Ubuntu repos?
[17:37] <Laney> what package name?
[17:38] <mac_v> Laney: cairo-dock has plugins available when installed from their repos , but not In the Ubuntu repos
[17:40] <Laney> maybe nobody packaged it
[17:40] <mac_v> Laney: http://developer.berlios.de/project/showfiles.php?group_id=8724&release_id=15624 < plug-ins
[17:40] <mac_v> Laney: do i send a mail to the list?
[17:40] <gilir> mac_v: because it's wainting in REVU
[17:42] <mac_v> gilir: so ? when can we expect it in the Karmic repos?
[17:42] <Laney> when it's done
[17:42] <mac_v> ;)
[17:43] <gilir> mac_v: you can monitor the status here : http://revu.ubuntuwire.com/p/cairo-dock-plugins
[17:44] <mac_v> gilir: thanx for the link :)
[17:44] <Laney> DEB_BUILD_OPTIONS=nocheck dh_auto_test
[17:44] <Laney> what's this?
[17:44] <slytherin> anyone else having problem with buildd script on jaunty?
[17:45] <Laney> I don't understand what you did to makeshlibs either
[17:47] <gilir> Laney: nocheck to skip the tests when using dh v7
[17:48] <Laney> why not an empty override?
[17:48] <gilir> and makeshilbs to avoid unnecessary shlibs generation
[17:49] <gilir> Laney: I didn't know empty override works :)
[17:49] <Laney> yes sir
[18:17] <slytherin> 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] <fabrice_sp> andv, about the changelog of taskjuggler
[18:28] <fabrice_sp> 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] <fabrice_sp> 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] <andol> andv: Hey, that ^^ was pretty much the same question I was about to ask you :)
[18:30] <fabrice_sp> andol, :-)
[18:30] <fabrice_sp> the merge request for taskjuggler is bug #400528 (in case you want to have a look :-) )
[18:57] <fabrice_sp> 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] <jpds> fabrice_sp: Done.
[19:00] <iulian> fabrice_sp: All archs?
[19:00] <iulian> Ah.
[19:00] <fabrice_sp> thanks jpds ! (and iulian too :-) )
[19:01] <jpds> iulian: The buildd script filters out all the successful ones. :)
[19:02] <kamalnandan> why do i get this error? even though I have correct version of cmake installed?
[19:02] <kamalnandan> dpkg-checkbuilddeps: Unmet build dependencies: cmake (>= 2.6.4)
[19:02] <fabrice_sp> yeah: it was only i386 in that case (all others except powerpc has been already built)
[19:03] <kamalnandan> though cmake is installed in /usr/local/bin
[19:03] <iulian> jpds: Oh cool, didn't know that.
[19:03] <fabrice_sp> kamalnandan, /usr/local is not good
[19:03] <fabrice_sp> kamalnandan, what is the output of apt-cache policy cmake ?
[19:05] <kamalnandan> fabrice_sp: thanks for your response..here is the output..
[19:05] <kamalnandan> http://paste.ubuntu.com/247378/
[19:06] <kamalnandan> 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] <kamalnandan> fabrice_sp..if its installed in /usr/local/bin, is there any problem?
[19:08] <fabrice_sp> kamalnandan, why don't you just install the Ubuntu package?
[19:09] <fabrice_sp> kamalnandan, yes: debuild don't know about local application (in /usr/local). Only about packages
[19:09] <kamalnandan> there is 2.6.2 only available in ubuntu package..i need 2.6.3..
[19:09] <fabrice_sp> kamalnandan, 2.6.4 in karmic
[19:10] <fabrice_sp> kamalnandan, it would be easier to setup a karmic chroot
[19:10] <fabrice_sp> and build it inside (or a karmic pbuilder)
[19:10] <fabrice_sp> !pbuilder
[19:10] <kamalnandan> i have jaunty..how do i setup karmic?
[19:10] <fabrice_sp> !chroot
[19:11] <fabrice_sp> I love that ! thing :-)
[19:11] <iulian> Our lovely robot.
[19:11] <fabrice_sp> :-D
[19:11] <kamalnandan> fabrice_sp...i havnt really ever used chroot..
[19:12] <fabrice_sp> kamalnandan, with a chroot, you will avoid installing unnecessary packages in your normal environment
[19:12] <fabrice_sp> and you can have several versions (I even have a sid and a hardy chroot)
[19:13] <TheMuso> slytherin: I believe a work-around is going to be put in place.
[19:13] <kamalnandan> fabrice_sp: how do we do that?
[19:14] <iulian> kamalnandan: Everything you want to know can be found in those wiki pages.
[19:15] <andv> fabrice_sp, who says they are lost?
[19:15] <andv> fabrice_sp, I see them
[19:15] <kamalnandan> iulian: thanks..let me check that..
[19:15] <andv> fabrice_sp, taskjuggler (2.2.0-1ubuntu1) dapper; urgency=low
[19:15] <andv>   * debian/rules: call dh_iconcache
[19:15] <andv> for example
[19:15] <andv> fabrice_sp, you have to include all ubuntu changelogs
[19:15] <andv> I hope that's clear
[19:16] <andv> andol, yes?
[19:16] <andv> andol, you added karmic/intrepid entries and lost all the previous ones
[19:17] <andv> andol, what's not clear?
[19:17] <andv> andol, unison (2.13.16-5ubuntu1) feisty; urgency=low
[19:17] <andv> andol, unison (2.13.16-6ubuntu1) feisty; urgency=low
[19:17] <andv> should I continue?
[19:17] <andv> ;)
[19:20] <kamalnandan> fabrice_sp: you meant this page ..right
[19:20] <kamalnandan> https://wiki.ubuntu.com/PbuilderHowto
[19:21] <fabrice_sp> 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] <andv> fabrice_sp, https://edge.launchpad.net/ubuntu/+source/taskjuggler
[19:22] <andv> fabrice_sp, it seems they are not lost in this page
[19:22] <fabrice_sp> 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] <fabrice_sp> andv, I was speaking in term of last changelog
[19:22] <andv> fabrice_sp, what's the point of dropping changelog entries?
[19:23] <fabrice_sp> andv, it was already dropped. I didn't dropped them by myself
[19:23] <andv> fabrice_sp, they got dropped cause a sync
[19:23] <fabrice_sp> yes
[19:23] <andv> fabrice_sp, but LP register every changelog entry submitted
[19:23] <andv> fabrice_sp, as you can see in the link I sent you
[19:23] <andv> fabrice_sp, so take LP as reference
[19:24] <fabrice_sp> 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] <fabrice_sp> using LP and not the changelog
[19:25] <andv> follow LP
[19:25] <andv> and you'll do good
[19:25] <andv> :)
[19:26] <andv> those pages are there to be checked
[19:26] <fabrice_sp> 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] <fabrice_sp> or it only apply to merge?
[19:26] <andv> fabrice_sp, you should answer yourself now :)
[19:27] <andv> fabrice_sp, if you fix a FTBFS on Ubuntu you won't use the Debian package
[19:27] <andv> but the one you find in the Ubuntu archives
[19:27] <andv> when you do a merge, you grab debian package and apply ubuntu changes
[19:28] <andv> losing changelog entries is not nice anyway
[19:29] <didrocks> 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] <fabrice_sp> 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] <fabrice_sp> ooops: no build entry in that case
[19:31] <andv> fabrice_sp, nvm
[19:31] <andv> fabrice_sp, leave it as it is
[19:31] <fabrice_sp> np: I'm updating it right now
[19:37] <fabrice_sp> andv, new debdiff uploaded
[19:37] <andv> fabrice_sp, perfect
[19:38] <andv> fabrice_sp, thanks for the fast responses
[19:38] <andv> fabrice_sp, I gonna process it later when I get back home
[19:38] <krisives> fabrice_sp: You helped me yesterday, right?
[19:38] <fabrice_sp> thanks to you to sponsor my upload
[19:38] <andv> fabrice_sp, are you willing to become a developer?
[19:38] <fabrice_sp> krisives, I think so, yes
[19:38] <fabrice_sp> about the patches, right?
[19:38] <krisives> I found the problem I was having
[19:39] <andv> or you are just a normal contributor
[19:39] <krisives> fabrice_sp: It was because my patch name was lexigraphically (caps) before the other patches
[19:39] <krisives> I actually filed a bogus bug report and then RTFM'd and it was in the man page :(
[19:39] <fabrice_sp> andv, for the moment, I'm just a u-c-d, but willing to become a motu at some point
[19:39] <fabrice_sp> krisives, this things happens, yes :-)
[19:40] <andv> fabrice_sp, cool
[19:40] <krisives> Yeah, but alwys lame to be the guy who fails to RTFM
[19:40] <fabrice_sp> lol
[19:40] <andv> fabrice_sp, when andol gets back tell him what to do
[19:40] <fabrice_sp> andv, ok
[19:41] <andv> ty
[19:41] <fabrice_sp> yw :-)
[19:45] <andv> fabrice_sp, where you the one who said you use mom?
[19:45] <krisives> 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] <fabrice_sp> andv, yes, but only to quickly get the dsc files, and the changelog. This is the part I will have to change
[19:46] <andv> fabrice_sp, start doing merges manually
[19:46] <andv> fabrice_sp, you'll improve and learn more
[19:47] <fabrice_sp> andv, apart from the changelog, I do it manually
[19:47] <fabrice_sp> easier to see what's happening
[19:47] <andv> k
[19:53] <andol> 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] <andol> andv: If we add stuff, neither present in the current debian or ubuntu package, is it really a merge then?
[19:54] <andv> andol, add stuff?
[19:54] <andv> we add something that was there before
[19:55] <andv> andol, https://edge.launchpad.net/ubuntu/+source/unison
[19:55] <andv> andol, you see any changelog you didnt add?
[19:56] <andol> 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] <andv> andol, so?
[19:56] <andv> andol, it's something nice to do adding all changelog's entries
[19:57] <andol> 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] <andv> fabrice_sp, can you please explain him
[19:57] <andv> im leaving
[19:57] <geser> please only add the changelog entries since the last sync not all available ubuntu changelog entries
[19:57] <andv> geser, why?
[19:57] <andv> geser, I'm used to apply all changelog entries
[19:58] <andv> geser, some other developers are used to apply them all
[19:58] <andv> there is no rule against it
[19:58] <geser> 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] <andv> geser, what's the point of dropping entries?
[19:59] <andv> geser, does old entries hurt someone?
[19:59] <geser> no, but they don't help either
[19:59] <andv> some developers add them all, some other don't
[19:59] <andv> there is no rule
[19:59] <andv> and I prefer having all of them
[20:00] <geser> why it is important to re-add changelog entries from dapper when you do a change in karmic?
[20:00] <andv> geser, I'm used to do it
[20:00] <andv> geser, I see nothing bad on doing it
[20:00] <andv> geser, I could say the same of dropping them
[20:01] <andv> geser, someone worked on that package on dapper so we have to credit him for his work
[20:01] <andv> dropping stuff won't help
[20:01] <geser> and why do we credit it only in dapper and karmic and not e.g. in jaunty (where the package is synced)?
[20:02] <andv> geser, all changelog entries are added
[20:02] <andv> geser, so we add jaunty stuff too
[20:02] <geser> and when there are no ubuntu changes in jaunty?
[20:02] <geser> then there are no ubuntu changelog entries there at all?
[20:02] <andv> geser, if there are no changes we have to credit no one
[20:03] <geser> and why do you want to credit someone for changes in dapper when adding a new change to a synced package?
[20:04] <geser> or do I don't understand the problem?
[20:04] <andv> it looks like you are not understanding
[20:04] <andv> he is doing a merge
[20:04] <geser> if the changes are carried over since dapper then I'm also for keeping the changelog entries since dapper
[20:04] <andv> and I told him to apply all changes since the beginning
[20:04] <andv> (on the changelog)
[20:05] <geser> but I'm not for re-introducing changelog entries for changes that were merged in to the debian package already
[20:05] <andv> geser, we think that different then
[20:05] <andv> geser, there is no rule on it
[20:05] <fabrice_sp> sorry, I was having an ice cream
[20:05] <andv> geser, I like to have them all, but might be different for you
[20:05] <geser> no, but you are the first I know of doing it that way
[20:06] <andv> DktrKranz does it too
[20:06] <andv> for example
[20:07] <andv> geser, anyway as I already said there is no rule on it
[20:07] <andv> so we can have different opinions
[20:07] <geser> true
[20:08] <andv> no one can say that my / your opinion is right or wrong
[20:08] <andv> so andol if you wanna do it, good
[20:08] <andv> if not I won't take care of your merge, sorry
[20:10] <geser> and I'm certainly not telling that my opinion is the only truth, just commenting
[20:10] <andol> Well, unison 2.27.57-2 doesn't seem to come with any overly important changes anyway...
[20:12] <andv> geser, yeah np
[20:12] <geser> andol: I'm not saying that you shouldn't do as your sponsor wants it, just noting that other sponsors might have a different view on things
[20:13] <andv> I'm off, andol if you still wanna fix it as fabrice_sp
[20:13] <andv> * ask
[20:13] <andol> geser: ok
[20:13] <fabrice_sp> I'm still here with my ice cream (32ºC here) :-)
[20:14] <andol> fabrice_sp: Ice cream is something I agree very much to :-)
[20:14] <andv> leaving
[20:14] <fabrice_sp> lol
[20:14] <andv> cya
[20:14] <fabrice_sp> bye
[20:14] <geser> fabrice_sp: and it's not thawing?
[20:14] <andv> 7away
[20:15] <fabrice_sp> geser, no, because I'm a fast eater :-)
[20:17] <sebner> geser: have I read the backlog correctly? andv wants to re-add changes to the changelog when there was a sync and the re-added changes doesn't have anything todo with the current changes?
[20:17] <geser> sebner: if I understand it correctly then yes
[20:18] <sebner> geser: wth? You are right, nobody does that, simply because it doesn't make any sense
[20:19] <geser> I certainly won't hunt down old changelog entries from LP and only keep those which are already there
[20:21] <iulian> Hmm, could someone please enlighten me a bit about this situation.  When we do a change to a package and that change is merged with the debian package, why should we bother in keeping the changelog of that *specific* change we did?
[20:21] <iulian> In this case, the changes will appear twice.
[20:22] <geser> iulian: not the change, but the old changelog entries, telling that we changed the package once in the past
[20:23] <iulian> geser: I meant the changelog entries.
[20:23] <sebner> iulian: if you sync a package our old changes vanish because debian changelog doesn't contain them
[20:25] <iulian> sebner: Yes, but it seems that andv wants to keep the changelog entries, even though, the changes we made are merged.
[20:25] <iulian> This is what I want to clarify.
[20:25] <fabrice_sp> iulian, you cna have a look at  bug #400528
[20:26] <geser> yes, e.g. intrepid: make changes, jaunty: sync, karmic: make other changes and re-add intrepid changelog
[20:26] <fabrice_sp> in this case, I added the Dapper entry to the changelog
[20:26] <fabrice_sp> (you have both changelog)
[20:26] <andol> or in my case, bug #377652
[20:26] <iulian> geser: Why's that?
[20:28] <geser> iulian: don't know, andv told to credit the old contributor
[20:28] <iulian> geser: That's why +packages are for.
[20:28] <iulian> Or whatever that page was.
[20:29] <andol> iulian: https://launchpad.net/ubuntu/+source/packagename ?
[20:30] <iulian>  /+uploaded-packages
[20:32] <geser> andol: I'm currently reading through the bug, but we don't need to mention the maintainer change (can lookup the mail for andv if necessary)
[20:40] <andol> geser: Thanks, but I was actually just about to unassign myself from the merge. The changes just doesn't seem important enough to take a fight with a sponsor over.
[20:43] <geser> andol: for me http://launchpadlibrarian.net/29794377/unison_2.27.57-2_2.27.57-2ubuntu1.debdiff would be ready for sponsoring (after a quick look), but I don't want to hijack this now
[20:44] <andol> geser: Ohh well, no hurry I guess. If nothing else we can always let this issue rest for a day or two.
[20:46] <geser> I'm for educating new contributors, but certainly don't let them repeat a debdiff for small errors till they are near the point of abandoning the merge
[20:46] <geser> I inform them about the small errors (so they learn for the future) and fix them myself before uploading
[20:48] <andol> geser: Actually, I don't mind nitpicking, as long as I get to learn more. In this case the problem was/is having to do changes which I didn't understand why to do. (I.e the old changelog entries)
[20:48] <geser> me neither
[20:51]  * iulian nods.
[22:31] <bdrung_> Zhenech: i had a close look at the debian policy and i have to agree on using configure for installation and remove | upgrade for removing.
[22:34] <Zhenech> bdrung_, great
[22:35] <Zhenech> gimme fixed dsc and I upload tomorrow
[22:35] <bdrung_> Zhenech: wait a moment. i have to modify my upload script.
[22:38] <Zhenech> bdrung_, no hurry, I wont upload today anyways
[22:39] <StevenK> didrocks: Using the version number sounds fine
[22:40] <bdrung_> Zhenech: thanks for uploading the other two packages.
[22:40] <Zhenech> np
[22:40] <bdrung_> Zhenech: writing the makefiles for upstream makes new upstream releases simple to package. :)
[22:43] <Zhenech> bdrung_, heh, thats good
[22:44] <bdrung_> Zhenech: he is the designer and i am the programmer. that fits good together. :)
[22:44] <Zhenech> yeah, from my expirence programmes cant design
[22:44] <Zhenech> and designers cant code :)
[22:44] <bdrung_> Zhenech: he once wrote a script for installing *-colors, and the code was ugly ;)
[22:45] <bdrung_> i would be a bad designer.
[22:45] <dupondje> https://bugs.launchpad.net/ubuntu/+source/dutch/+bug/407951 <- need to get synced :)
[22:47] <bdrung_> Zhenech: the script is now running. if there are no problems, the new package will be available in approxatly 15 minutes.
[22:49] <bdrung_> Zhenech: the ppa seems to be used by many people. when i break something there (mostly with hardy), then there will be a bug report the same day.
[22:50] <dupondje> somebody want to check my sync request ? :)
[22:51] <Zhenech> bdrung_, great :)
[22:51] <Zhenech> bdrung_, restoring backup of my main machine (had to testinstall windows) and going to bed
[22:51] <Zhenech> will have a look at your changes tomorrow from work
[22:51] <Zhenech> at about 1100 cest
[22:52] <bdrung_> Zhenech: you can use utc+2
[22:52] <bdrung_> ups
[22:53] <bdrung_> Zhenech: should i send you the dsc link?
[22:53] <bdrung_> when it's up?
[22:53] <Zhenech> bdrung_, I guess ill find it
[22:53] <Zhenech> but you could ping me on irc tomorrow
[22:53] <Zhenech> in the case ill forget
[22:53] <bdrung_> Zhenech: ok
[22:53] <bdrung_> Zhenech: i will ping you, when i am up. :)
[22:53] <Zhenech> kk
[22:54] <bdrung_> Zhenech: i would have normal sleep time when i would live in utc-4. :)
[22:54] <fabrice_sp> dupondje, it's for main, so perhaps, you would have more luck at #ubuntu-devel :-)
[22:54] <Zhenech> haha
[22:54] <Zhenech> yeah, my sleep time is also kinda strange
[22:55] <bdrung_> Zhenech: that's normal for an "informatiker"
[22:56] <Zhenech> no, itd be normal if theyd be constant
[22:56] <Zhenech> but sometimes I go to bed at 2200 and wake up at 0900
[22:56] <Zhenech> and osmetimes I go to bed at 0400 and wake up at 1000
[22:57] <bdrung_> Zhenech: my are not so fluctuating. i go to bed between 0100 and 0400 and wake up ...
[22:58] <bdrung_> either my clock rings between 0800 and 1000 or i will sleep 7 hours or longer.
[23:05] <bdrung_> Zhenech: ok, the updated package is on mentors
[23:05] <Zhenech> ok, will do tomorrow then
[23:05] <Zhenech> bedtime now
[23:05] <Zhenech> n8
[23:08] <bdrung_> Zhenech: gn8
[23:36] <andv> andol, you there?
[23:38] <andv> sebner, who says no one do that?
[23:41] <andv> geser, maint field change not need to be added on changelog
[23:41] <andv> geser, is that right?