=== chuck_ is now known as zul
[03:40] <c2tarun> there is bug 732457 , I guess darksnow package follows cdbs patching system in which patches are applied alphabetically. There exists a patch which is editing file Makefile.in should I edit that patch or create a new patch? If I create a new patch what patch name should I use? Patch name for older patch is fixing_Makefile.in.patch
[03:40] <ubottu> Launchpad bug 732457 in darksnow (Ubuntu) "Package darksnow_0.6.1-3 failed to build from source with "ld --as-needed" option" [Undecided,In progress] https://launchpad.net/bugs/732457
[03:43] <Bachstelze> c2tarun: assuming cdbs sorts numbers before letters, ytou could name it 00fix_Makefile_for_gold
[03:44] <c2tarun> Bachstelze, that will be a problem because the line i have to edit is added by patch fixing_Makefile.in.patch
[03:44] <Bachstelze> I'm surprised that patches are not numbered in the first place, though, it seems like tha natural thing to do when they are applied in alphabetical order
[03:45] <Bachstelze> c2tarun: then make it sort after it ;)
[03:45] <Bachstelze> like fixing_Makefile_blahblah
[03:45] <c2tarun> Bachstelze, should I rename the patch fixing_Makefile.in.patch to 02_fixing_Makefile.in.patch and my new patch to 03_fix_ftbfs_binutils-gold.patch? there is also a patch with number 00
[03:47] <Bachstelze> shouldn't be necessary, just find out when exactly your patch should be applied, and name it accordingly
[03:47] <c2tarun> Bachstelze, ok then :) I'll name my patch as z_fix_ftbfs_binutils-gold.patch
[03:47] <Bachstelze> if the curreznt patch is in Debian, only the DEbian maintainer should touch it IMO
[03:48] <c2tarun> Bachstelze, well renaming the patch and sending it to debian can be a solution I guess?
[03:49] <Bachstelze> could be, but it's a very minor issue, it it is one at all
[03:49] <Bachstelze> if it is*
[03:50] <c2tarun> hmm.... it could be an issue if someday number of patches increase to 6 or 7?
[03:50] <Bachstelze> so don't bother with it, there are more important things to do :)
[03:50] <c2tarun> ok :)
[03:50] <c2tarun> I'll name my patch as z_fix_ftbfs_binutils-gold.patch
[03:50] <Bachstelze> sounds good
[03:56] <c2tarun> Bachstelze, can you please look at this error?
[03:56] <c2tarun> http://paste.kde.org/8012/
[03:57]  * Bachstelze looks
[04:00] <Bachstelze> I don't have a lot of experience with cdbs, but by the looks of it, it tries to reverse-apply your patch and fails
[04:01] <Bachstelze> so make sure your patch is correct, and try to apply/unapply it manually to see what happens
[04:02] <c2tarun> how to apply a cdbs patch?
[04:02] <c2tarun> Bachstelze, ^
[04:03] <Bachstelze> can't you apply them with patch ?
[04:11] <Bachstelze> c2tarun: I must go to bed, it's 5 am here :p good luck with your package
[04:11] <c2tarun> Bachstelze, thanks :) good night
[06:18] <fabrice_sp> slangasek, Hi! I saw you uploaded a multiarched version of libsm, and I now have a compilation issue because vtk has reference to usr/lib/libSM.so in cmake files. I already uploaded a non changes upload of vtk 4 days ago because of libexpat. when do you think you will have uploaded all multi-arched patches?
[06:19] <slangasek> fabrice_sp: when we enter beta freeze, I'll be done.  why is vtk embedding paths to libraries in its cmake files?  Can that be corrected so vtk doesn't do that?
[06:26] <jmarsden> vtk is not alone.  I suspect there are several packages doing bad stuff like that which FTBFS as a result of multiarch as libraries are migrated.  php5 is one (in its autotools stuff) I am currently trying to fix up... bug #739977
[06:26] <ubottu> Launchpad bug 739977 in php5 (Ubuntu) "PHP5 FTBFS in Natty" [Undecided,Confirmed] https://launchpad.net/bugs/739977
[06:32] <slangasek> yeah, doesn't surprise me that php also has problems
[06:32] <slangasek> there are far too many NIH build systems about
[06:33] <fabrice_sp> slangasek, so a correct fix for vtk would be to include only lib name in cmake files and no path? I'll try (the bad part is that vtk takes 4 hours to build)
[06:33] <RAOF> s/NIH//.  Given that none of them have managed to materially improve on *autotools* they might as well all die :)
[06:34] <slangasek> fabrice_sp: yes, exactly
[06:34] <fabrice_sp> slangasek, thanks for the tip!
[06:34] <slangasek> fabrice_sp: and if you can future proof this by doing this for *all* libs vtk uses, you won't have to change it again for each new library that gets multiarch support next cycle...
[06:35] <fabrice_sp> slangasek, this is exactly what I was thinking in doing
[07:34] <dholbach> good morning
[07:37] <geser> good morning
[09:12] <mok0> ls
[09:53] <iulian> Morning.
[09:54] <Rhonda> Has.
[09:57] <iulian> Siervus.
[09:59] <iulian> s/Siervus/Servus/
=== ziviani is now known as JRBeer
=== nigelbabu is now known as nigelb
=== yofel_ is now known as yofel
[12:46] <verwilst> if i have a package with an official release of 1.0 for example, and 1.1 isnt out yet
[12:46] <verwilst> but i want to package a source checkout/snapshot
[12:46] <verwilst> how should i version it?
[12:46] <verwilst> 1.0.99?
[12:46] <verwilst> 1.0.99snapshot.. :P
[12:48] <soren> 1.1~something.
[12:48] <verwilst> soren, but when 1.1 final comes out
[12:48] <verwilst> it might think 1.1~something is higher, no?
[12:50] <verwilst> verwilst@laptop:~$ dpkg --compare-versions "1.1-0" gt "1.1~sth" && echo "1.1-0 is greater"
[12:50] <verwilst> 1.1-0 is greater
[12:50] <verwilst> hm
[12:51] <verwilst> so i can name it 1.1~spre1
[12:51] <verwilst> pre*
[13:07] <Rhonda> The ~ character got specificly implemented to mean "lower than anything, even the empty string"
[13:08] <Rhonda> dpkg --compare-versions 1~ lt 1 && echo "yes, 1~ is less than 2"
[13:08] <Rhonda> … minus the typo in the echo message, of course ;)
[13:08] <Rhonda> So release candidates, pre-release versions and anything can make use of ~
[13:09] <Rhonda> But in your case, I'd rather settle for 1.0+vcs20110324-1 or something like that.
[13:11] <soren> Yeah. it depends on how sure you are that the release will actually be 1.1.
[13:31] <directhex> the use of 1.0+ and 1.1~ generally comes down to what you consider the "base" version to be
[13:33] <Rhonda> 1.0.99 is not a sane approach because upstream hasn't done it as 1.0.99
[13:33] <Rhonda> I'd stick with the version information that is inside the upstream VCS as basis for judgement.
[13:49] <soren> Rhonda: That's a good idea.
[13:49] <soren> That's what I've been (subconsciously) doing, I guess.
[13:57]  * Rhonda would like to ask for some testers for bug #734731 so it can marked confirmed
[13:57] <ubottu> Launchpad bug 734731 in lucid-backports "Please backport irssi (0.8.15-2ubuntu1/main)" [Undecided,New] https://launchpad.net/bugs/734731
=== Quintasan_ is now known as Quintasan
[14:41] <verwilst> hello
[14:41] <verwilst> trying to upload a package with a fixed source tarball, but keep getting "File php-sphinx_1.1.0.orig.tar.gz already exists in PPA for Bart Verwilst, but uploaded version has different contents."
[14:41] <verwilst> i tried removing my package from the ppa and then doing a new upload
[14:43] <Bachstelze> verwilst: PPA-related questions are better asked in #launchpad ;)
[14:43] <verwilst> ah ok
[14:44] <verwilst> Bachstelze, fixed ;)
[14:45] <Bachstelze> :)
[15:51] <kim0> Hi folks .. Letting you know Ubuntu Cloud Days starting in 10mins in #ubuntu-classroom .. You can discuss in #ubuntu-classroom-chat .. Thanks
[16:38] <petani> all  can help me compile php with gd enable
[16:38] <micahg> petani: maybe in #ubuntu-packaging
[16:39] <petani> oke thx
[16:39] <petani> micahg why php-gd not support antialiasing image
[16:40] <micahg> petani: I think it comes with gd support in any case, specific php questions should be asked in #ubuntu-server
[16:41] <petani> oke thx again's
[16:42] <RoAkSoAx> james_w: /win 3
[16:43] <RoAkSoAx> argggh
[16:43] <RoAkSoAx> james_w: sorry :)
[17:11] <arand> Are all these files generated by automake, would they all pass as "redistributed under the same license as the project" or would I need to document them in debian/copyright? http://paste.debian.net/111831/
[17:53] <ximion> arand: You don't need to mention them in debian/copyright
[17:53] <ximion> as they're auto-generated, they don't belong to the "original" source code provided in upstream tarball.
[17:54] <ximion> (also, they will imho have the same license as the project in general)
[17:54] <arand> ximion: Not even the install-sh which has an odd extra copyright not from FSF?
[17:55] <arand> ximion: But if they are included in the upstream tarball? I should ask upstream to remove them?
[17:55] <ximion> arand: yes, it would be better if upstream provided a clean tarball
[17:56] <ximion> if there's a copyright mentioned you would have to document it, but for these automake files it really makes no sense
[17:56] <ximion> upstream schould remove the files
[17:56] <ximion> (or use automakes ability to create a clean source tarball
[17:56] <ximion> )
[17:59] <arand> ximion: Well, I'll see if that might float. Though if I get a "meh, no need"-response, I would have to find a way to include them?
[18:41] <ximion> arand: yes (just to be sure) - or repackage the sources
[18:42] <ximion> but it would be very ignorant if upstream gives a "no need" response
=== blankdisk is now known as blankdisk|away
=== blankdisk|away is now known as blankdisk
[20:37] <verwilst> in Depends, where are the results for ${php:Depends} fetched from?
[20:38] <verwilst> or misc:Depends, or stuff like that
[20:41] <verwilst> hm,i think i know
[20:41] <verwilst> kinda
[20:41] <verwilst> dh_shlibs etc
[21:20] <hakermania> micahg: Friend.... I don't know what to say... We are expecting this review for so long :( Please, be a bit interested with Wallch :(((
[21:23] <hakermania> micahg: It's not a personal problem. I don't want it to see it like this. I know that nobody is being paid for this, but I don't like taking "I'll try this weekend" tree weekends now :( :'(
[21:23] <hakermania> three*
[22:11] <micahg> hakermania: you still need someone else to review it besides me
[22:40] <hakermania> micahg: Do the first step, and i'm sure someone will follow
[22:47] <dustin_> anyone on here right now use tumblr blogging?