[04:16] <MTecknology> If something is released under the GNU GPLv3 license.. then you are legally able to rebrand, change the source, and redistribute the code however you see fit under the new name provided there's proper mention of the original source; right?
[04:18] <MTecknology> I'm trying to reach the original author of something but it looks like it might not wind up being possible and I'm just wanting to make sure I at least have that much right..
[05:06] <RAOF> MTecknology: As long as you distribute the derivative work under a the GPLv3 you're golden.
[05:06] <MTecknology> RAOF: nice; thanks :)
[05:07] <MTecknology> I figure I'll wait another week or so to make contact; but for <200 lines any longer seems a bit excessive
[05:07] <RAOF> IIUC you could also distribute a derived work under a GPLv3 compatible licence, too.
[05:08] <kaushal> hi
[05:09] <kaushal> will sun java 6 update 24 available in 8.04 ?
[05:09] <micahg> kaushal: yes, it will be
[05:09] <kaushal> is there a wiki for it ?
[05:10] <micahg> kaushal: no, let me see if the bug is public so you can subscribe to it, it's in progress though
[05:10] <kaushal> sure
[05:13] <micahg> kaushal: bug 716889
[05:13] <micahg> oops
[05:13] <micahg> kaushal: bug 716689
[05:16] <kaushal> micahg: how did you quickly searched the Bug #716689
[05:17] <micahg> kaushal: I gave up on searching, I went to the sun-java6 package and sorted by newest
[05:17] <kaushal> micahg: where exactly ?
[05:18] <kaushal> is it in launchpad ?
[05:18] <micahg> https://bugs.launchpad.net/ubuntu/+source/sun-java6
[05:21] <kaushal> micahg: Thanks
[05:21] <kaushal> micahg: any ETA when it is going to be included in 8.04 ?
[05:21] <micahg> kaushal: no, I just know it's in progress
[05:21] <kaushal> oh ok
[08:43] <kim0> Hi, does the following imply an import error? http://package-import.ubuntu.com/status/qemu-kvm.html
[08:45] <dholbach> good morning
[08:45] <kim0> dholbach: morning :)
[08:45] <dholbach> hi kim0
[08:46] <kim0> dholbach: was just asking .. does the following imply an import error? http://package-import.ubuntu.com/status/qemu-kvm.html
[08:46] <dholbach> it very much looks like it
[08:46] <dholbach> james_w would know
[08:47] <kim0> cool, whoever knows ping me if I should fire a bug
[10:46] <c2tarun> Can anyone please give me link to some ftbfs bugs to work on. Thanks
[12:13] <geser> c2tarun: current FTBFS are listed on http://qa.ubuntuwire.org/ftbfs/
[12:16] <geser> c2tarun: you might also want to look at http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi Those are FTBFS from a archive rebuild done in January (you might need to check if it still happens when you try to rebuild those packages before you start fixing them)
[12:35] <Rhonda> Is it common that launchpad sends reject mails for PPA uploads to the Debian developers of the packages?
[12:38] <Rhonda> Anyone knows Alex Sergeyev and wether they are using IRC?
[12:38] <geser> Rhonda: try #launchpad for the mail question
[12:39] <geser> as he uses a PPA, he has a LP account and should be found with https://launchpad.net/people
[12:40] <geser> https://launchpad.net/~alex-sergeyev has no IRC information, so I guess not
[12:47] <tumbleweed> bdrung: care to do another u-d-t upload? (or should I add myself to uploaders and do it)?
[12:58] <c_korn> any news about the libevent transition ?
[12:59] <kklimonda> c_korn: after pushback from the server folks, it has been postponed to natty.
[13:00] <c_korn> hm, ok.
[13:00] <kklimonda> and by natty I meant natty+1 :)
[13:02] <Rhonda> geser: Ah, thanks. :)
[13:02] <c_korn> yeah, I already feared that
[13:03] <c2tarun> can anyone help me with this error http://paste.ubuntu.com/571086/
[13:05] <kklimonda> c_korn: fortunately all the work you've done won't be lost - I'll forward most of what we've done to Debian and hopefully we'll be able to do the migration with them. (they obviously can do it to experimental)
[13:06] <kklimonda> the current plan is to start doing this as soon as we can, after o archives are open.
[13:07] <TeTeT> c2tarun: did you try to add libX11.so.6 (-lX11) to the linker?
[13:07] <c_korn> kklimonda: ok, good to know. I think for transmission it means to be statically linked to libevent 2. or won't the new version be in natty either ?
[13:07] <james_w> kim0, please file a bug against the 'udd' project in Launchpad if that is blocking you
[13:08] <kklimonda> c_korn: no, the security team have advised against statically linking with libevent2 so we've already decided (and by "we" I mean me ;)) to keep transmission at 2.13 and backport few easy fixes from 2.2x
[13:08] <c2tarun> TeTeT: Dont know how to do that :( sorry Can you please tell.
[13:10] <TeTeT> c2tarun: I'm guessing here, but did you run a 'make' to get this output? If so, try $ LDFLAGS="-lX11" make
[13:11] <c2tarun> TeTeT: it tried debuild -b and I got this error
[13:11] <TeTeT> c2tarun: what package, what Ubuntu version?
[13:12] <c2tarun> TeTeT: glest I downloaded it from archive
[13:12] <c2tarun> TeTeT: by apt-get source
[13:12] <TeTeT> c2tarun: lsb_release -c?
[13:12] <c2tarun> TeTeT: natty
[13:13] <TeTeT> c2tarun: let me boot my Natty desktop, maybe I can reproduce it
[13:13] <c2tarun> TeTeT: sure I'll wait :)
[13:13] <bdrung> tumbleweed: are you DD?
[13:15] <tumbleweed> bdrung: yes
[13:15] <bdrung> tumbleweed: if you want, you can add yourself to uploaders and do the upload
[13:16] <tumbleweed> bdrung: thanks, I will
[13:17] <c_korn> kklimonda: ok, so be it
[13:19] <kklimonda> c_korn: sorry for not telling you, I thought you were in the loop - there were so many various emails CC'ed when the discussion went to the ML that I didn't bother to check.
[13:20] <geser> TeTeT: LDFLAGS aren't the right place for "-l..."
[13:20] <TeTeT> geser: where would they go? I thought it's the easiest place to check if it fixes the compile problem
[13:21] <geser> check the Makefile if it uses LIBS (or something similar) and add it there
[13:22] <c2tarun> geser, TeTeT: are you guys discussing on my error?
[13:23] <geser> adding -l... to LDFLAGS won't work in natty as the ordering is important with "ld --as-needed" and LDFLAGS are used at the beginning of the linker call while the libs should come last (after the object files using them)
[13:23] <geser> c2tarun: yes
[13:23] <geser> sort of
[13:23] <c2tarun> geser: ok sorry to ask this, but can you please tell me why I am getting this error? I mean is something missing or something like that?
[13:24] <TeTeT> geser: ah, I see. meantime I downloaded this glest thing and checked it. It uses autoconf with a configure.ac. I added -lX11 to the libs when X is detected
[13:25] <geser> TeTeT: yes, that's the best way to fix it (and guide c2tarun through it so he learns how to fix the next package himself)
[13:25] <geser> c2tarun: yes, a library is missing in the linker call
[13:26] <c2tarun> ok I guess libX11.so.6 library is missing
[13:26] <c_korn> kklimonda: it's ok. was a bad time for transmission to change to libevent2 in regard to the natty release schedule
[13:26] <c2tarun> TeTeT: ping
[13:27] <TeTeT> c2tarun: please take a look at glest-3.2.2/mk/linux/configure.ac
[13:27] <TeTeT> c2tarun: still around, just built your package
[13:27] <kklimonda> c_korn: yes, it is unfortunately the case that Transmission's release schedule is completely out of sync with Ubuntu :)
[13:28] <c2tarun> TeTeT: ok I am looking at configure.ac
[13:29] <TeTeT> c2tarun: in this configure.ac there is a check for operating system section. Check the line with AC_DEFINE([X11_AVAILABLE])
[13:29] <kklimonda> c_korn: in this case they were really hyped about new features and performance gains that the new libevent was going to get them. They were preparing for this migration for months, if not years. Also, libevent 2 was supposed to be API compatible with 1.4.x - now we know it's not exactly the case after all. :)
[13:29] <kklimonda> s/to get/to give/
[13:29] <c2tarun> TeTeT: I got the line, is it the line in which available spelling is wrong?
[13:30] <TeTeT> c2tarun: yes, that's the one. On the next line I would add the missing -lX11 to LIBS, though there are possibly more appropriate places
[13:31] <c2tarun> TeTeT: can you please pastebin your check for operating system section?
[13:31] <TeTeT> c2tarun: on that next line write, with appropriate indenting, LIBS="$LIBS -lX11"
[13:32] <TeTeT> c2tarun: http://pastebin.ubuntu.com/571104/
[13:33] <c2tarun> TeTeT: ok, done. now?
[13:33] <TeTeT> c2tarun: try the debuild -b again
[13:33] <ari-tczew> kees: around?
[13:34] <c2tarun> TeTeT: ok, its building I got few questions. How do you know which file to change?
[13:35] <TeTeT> c2tarun: very good question. To get from a source file or source directories to a binary executable and assorted libs, one has to compile the source
[13:35] <TeTeT> c2tarun: the compilation is best done in an automated way, as doing it manually would result in many differently built binaries
[13:36] <TeTeT> c2tarun: for the purpose of automating the compilation, Makefiles are there. So I first checked if I find any Makefile in your package
[13:36] <TeTeT> c2tarun: there was none, which told me that there's most likely another system creating the Makefiles
[13:37] <TeTeT> c2tarun: so I checked the directory names and saw 'mk' which sounds familiar to Make, but it was a pure guess
[13:37] <TeTeT> in mk I found linux, in which the autogen.sh and configure.ac files were to be found
[13:38] <c2tarun> TeTeT: ok, and how to figure out what to add? I mean all we knew the name of the library missing libX11.so.6 (I dont know shell scripting very well)
[13:38] <TeTeT> c2tarun: so there's another system called 'autoconf' that can create Makefiles and alike on the fly
[13:39] <TeTeT> c2tarun: the configure.ac is a template file for this system, and it is a good place for a library definition
[13:39] <TeTeT> c2tarun: there might have also been Makefile.in or alike, which might be good candidates as well. Luckily there were not many to choose from
[13:40] <c2tarun> TeTeT: got it, how to figure out what to add? I mean all we knew the name of the library missing libX11.so.6 (I dont know shell scripting very well)
[13:41] <TeTeT> c2tarun: hmm, I looked in configure.ac and checked what's the easiest way to add a library
[13:42] <TeTeT> c2tarun: in the 'Check for operating system' it states ;LIBS="$LIBS -lwsock32" for windows, so I merely used this line and copied it at the right place
[13:43] <c2tarun> TeTeT: wow.... :) that's smart. Do you think I should learn shell scripting before trying to go for ftbfs bugs?
[13:44] <TeTeT> c2tarun: well, it's not even a shell script, it's a template file for autoconfigure. I guess getting some experience with building from source by yourself would be best
[13:44] <c2tarun> TeTeT: ok, now since the package built succesfully, should I file a FTBFS bug on LP and upload the fix? or do i have to create a patch for the changes made?
[13:46] <TeTeT> c2tarun: I would start with filing the FTBFS bug, then upload the change configure.ac, then create a new package with your fix and upload the debdiff
[13:47] <c2tarun> TeTeT: no patches for the change in configure.ac?
[13:48] <geser> c2tarun: some scripting knowledge doesn't hurt, but you don't need to master it. In most cases it's enough when you understand what the script does and has enough scripting knowledge to extend it with those "patterns" you see used in the file you look at
[13:49] <TeTeT> c2tarun: let me check if the package uses a patch system
[13:49] <c2tarun> TeTeT: yup there are few
[13:51] <TeTeT> c2tarun: you can use 'edit-patch' then to create a patch for the configure.ac. For this I would cp the new configure.ac to some safe place. Then extract the sources again, enter the dir, call 'edit-patch libX11'
[13:51] <TeTeT> c2tarun: cp the saved configure.ac to mk/linux/configure.ac, exit, write down your change in the Changelog
[13:52] <TeTeT> c2tarun: then do a 'debuild -S' and you get a new source package
[13:53] <c2tarun> TeTeT: ok, I am going to try it. This package is not following the 3.0 quilt patching system. using that system is easy. is it worth to convert it to 3.0 quilt?
[13:54] <TeTeT> c2tarun: I have no idea about that, I just use the patch system that comes with a package. I'm myself far from being an experienced packager, btw
[13:56] <kklimonda> c2tarun: if the package comes from debian (even if we modify it for some reason) then we try to avoid adding an unnecessary delta.
[13:59] <c2tarun> kklimonda: This package came from debian but I think their it built succesfully, so I think I should drop the idea of changing it to 3.0 quilt and for change in configure.ac I create a patch with some name and in changelog I'll mention that added a patch to fix FTBFS in ubuntu?
[14:01] <kklimonda> c2tarun: yes, don't change the source format, add patch instead - if debian packages already uses some patch system, use the same one, if it doesn't use any you.. I actually don't know what the final decision was about it, I do remember disagreeing with micahg about this case, his opinion was, afair, that you should apply the patch directly to the source, and not add any patch system.
[14:02] <TeTeT> c2tarun: afaik Debian should be interested in the patch against the FTBFS as well
[14:03] <kklimonda> yes, especially now, after the Freeze is over
[14:17] <Laney> persia: Can you approve my (and the others, presumably) membership to the DMB list?
[14:20] <kklimonda> Laney: the next dmb meeting is this monday?
[14:21] <Laney> don't know
[14:21] <Laney> This is something we need to figure out. :-)
[14:25] <kklimonda> ah, good to know :)
[14:30] <TeTeT> I'm running into a problem with the opensc 0.12.0 package I created yesterday. It seems to work fine on Lucid, but when I d/l on Natty and try to build a source package, I get an error: http://pastebin.ubuntu.com/571140/
[14:30] <TeTeT> any pointers on what's going wrong? Or rather, how would I add the orig.tar.gz file in that case?
[14:34] <ari-tczew> TeTeT: dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found
[14:35] <TeTeT> ari-tczew: how would I fix that? If I download the orig.tar.gz and rename it accordingly, dpkg -S will work, but when I place it in a PPA I get the error that it is still missing, as it is not uploaded to it
[14:35] <TeTeT> I suspect I broke the package when copying debian from 0.11.13 to 0.12.0, but have no idea how
[14:35] <ari-tczew> TeTeT: what's filename of tarball right now?
[14:36] <TeTeT> ari-tczew: there's only opensc_0.12.0-0ubuntu0~tetet3.tar.bz2
[14:37] <ari-tczew> pretty wrong
[14:38] <ari-tczew> TeTeT: try opensc_0.12.0.orig.tar.bz2
[14:38] <ari-tczew> the source directory of opensc should be called opensc-0.12.0
[14:41] <TeTeT> ari-tczew: thanks, using the right packagename and then calling debuild -sa -S seems to add the orig.tar.gz to the PPA upload. Now I hope that it will be accepted ;)
[14:53] <TeTeT> cheers, it built for Natty, thanks again ari-tczew
[14:53] <ari-tczew> TeTeT: You're welcome.
[15:58] <bencer_> hi all, i've prepared updated packages for libebox and ebox-* which i'm uploading to my ppa, which should be the procedure to request their inclusion in natty?
[16:44] <micahg> hakermania: was there any change in the last upload?
[16:44] <hakermania> micahg: Yes, I added the linking to QDBus libs (QT += dbus in the .pro file)
[16:46] <micahg> hakermania: yes, but I don't see a patch
[16:48] <hakermania> micahg: I just uploaded a full new package, I didn't patched the old one.
[16:50] <micahg> hakermania: we generally don't patch the upstream code directly unless it's an import from Debian w/out a patch system
[16:51] <hakermania> micahg: Sorry, i'm currently learning all these tricks... Should I do some action right now?
[16:52] <micahg> hakermania: source format  should've created a patch
[16:52] <micahg> source format 3
[16:55] <hakermania> micahg: I'm confused... What should I do now? i did so many changes in the previous uploaded packages and I uploaded no patch... Why should I have a patch now??
[16:59] <micahg> hakermania: I'm not sure what you did, the .orig.tar.gz shouldn't change, any patches should be in the .debian.tar.gz through a patch
[17:00] <hakermania> micahg: Can you guide me through this?
[17:00] <micahg> hakermania: when you run debuild -S -sa on the package it should create a patch in debian/patches with any changes to the source
[17:01] <hakermania> I'll try it right now.
[17:02] <hakermania> micahg: So, I have a built source, and, when I fix everything I want to, I'll run debuild -S -sa  in THE SAME source and it will generate a patch?
[17:03] <micahg> hakermania: in theory if the clean rules are correct
[17:04] <hakermania> micahg: OK
[17:05] <micahg> hakermania: otherwise, if you get other changes in there, you can override the clean in debian/rules (currently not there)
[17:22] <hakermania> micahg: Ok, some patches seem to be added... Question: Is the .deb file updated?
[17:23] <micahg> hakermania: what do you mean?
[17:25] <hakermania> When I build my package manually there is a orig.tar.gz, a .dsc, a DEB package and some other files generated. Is the DEB package updated after making the changes to the old source and running debuild -S -sa ?
[17:25] <micahg> hakermania: no, that's a binary build, not a source build
[17:26] <micahg> debuild -S -sa is a source build which is what we use to upload
[17:26] <hakermania> Can I do something so as to update the DEB file as well (so as to have it available for my own purposes)
[17:26] <micahg> (or -sd if the tarball is in the archive)
[17:26] <micahg> hakermania: you have to run a binary build
[17:27] <hakermania> micahg: OK, now, in the old source there is the .deb file (from the binary build), and now I run the source build but the DEB package is still there. If I upload to REVu now, will the DEB file be uploaded?
[17:28] <micahg> hakermania: no, only source uploads are accepted (so you have to upload the source.changes file
[17:31] <hakermania> micahg: Ok, done. the new package has been uploaded, hopefully with the right procedure :)
[17:33] <micahg> hakermania: ok, will look in a bit
[17:33] <hakermania> micahg: I get this warning on REVU: "Warning! This package could not be extracted; there's no browsable     directory for it on REVU." ??
[17:36] <micahg> hakermania: ok, so now you have this: http://revu.ubuntuwire.com/report.py/diff?upid1=8989&upid2=8992, so that patch seems to have multiple things in it, would it be possible to split the patch into the separate things it does and then add appropriate descriptions?
[17:37] <hakermania> micahg: How do I split a patch?
[17:38] <hakermania> micahg: Do you mean I should update the changelog?
[17:42] <micahg> hakermania: I take it back, it seems all the changes were for the numeric to bool state change
[17:43] <hakermania> micahg: Exactly.
[17:43] <micahg> hakermania: so you can edit that patch now in debian/patches/debian-changes-1.0-0ubuntu1, and give it an appropriate description and link to where you upstreamed these changed
[17:43] <micahg> *changes
[17:44] <alucardni> Can anyone please take a look at the files I uploaded to LP #682461 ???
[17:50] <hakermania> micahg: Thanks for the help. The description will be INSIDE the debian-changes-1.0-0ubuntu1, between the lines? Should I use a specific format for the description? What do you mean "link to where you upstreamed the changes"? Should I link to REVU? Sourceforge?
[17:51] <cdbs> hakermania: http://dep.debian.net/deps/dep3/
[17:51] <cdbs> hakermania: it would be at the beginning of the patch, before anything else already there
[17:52] <hakermania> cdbs, micahg: Thanks. Will read it. Should I redo a source build and upload to REVU after this?
[17:53] <cdbs> hakermania: yes, after every change, you should debuild -S again and upload to revu again
[17:53]  * cdbs g2g
[17:53] <micahg> alucardni: I'm piloting in a bit, I'll take a look then
[17:53] <alucardni> micahg: ok, thank you
[17:57] <hakermania> cdbs: what is <url of original patch> ?
[17:59] <paultag> hakermania: if you got a patch from somewhere
[17:59] <paultag> it's nice to note it in the headers
[17:59] <hakermania> paultag: What if I made it myself ?
[17:59] <paultag> but if it's created by you for the package it's self, it might not matter
[17:59] <paultag> hakermania: just leave it out, no problem
[18:00] <hakermania> paultag: Should I leave out the bug reports, if are non-existent?
[18:00] <paultag> hakermania: yes :)
[18:00] <hakermania> ok thx
[18:00] <paultag> hakermania: none of that is "required", it's meta data on the patch, it's nice to have (and be sure to fill out all you have)
[18:01] <hakermania> paultag: the "Reviewed-By:" field am I supposed to fill it myself? How can I guess who will approve or not the patch??  Or, as the project's developer I have the right to approve it?
[18:02] <paultag> hakermania: there's no sense in reviewing a patch you made yourself. That'd be added if you sent me that patch for my package, and I decided to include it
[18:02] <paultag> hakermania: be minimal :)
[18:02] <paultag> (but complete)
[18:02] <hakermania> paultag: As far as possible :D
[18:05] <hakermania> paultag: What about the Forwarded: field?
[18:05] <paultag> hakermania: that's if you forwarded the patch upstream
[18:06] <hakermania> I'm left only with the Description, Author and Last-Update fields :-(. Is this normal/enough?
[18:06] <paultag> hakermania: yup! :)
[18:06] <hakermania> paultag: Nice
[18:07] <paultag> hakermania: usually I just have my name / description / forwarded if I need it
[18:07] <paultag> descriptions are the most important ones to maintain
[18:08] <hakermania> micahg: New upload.
[18:09] <hakermania> paultag: Unimportant description in my case, only changed numeric to boolean values, as some functions had better take true/false than 1/0
[18:10] <paultag> hakermania: it'd be good to explain why -- was it because of style, a platform's defaults, logical error, what? :)
[18:10] <paultag> hakermania: see, I should be able to glance at the patch and understand why it's needed rather then "thinking"
[18:11] <hakermania> paultag: It is a fact that it is considered bad style in C++ (in C you do not have a type bool, so 0/1 is ok there).
[18:11] <paultag> hakermania: so explain it -- the patch can look like pure C if you don't take care to look into it :)
[18:12] <paultag> hakermania: that was a perfect description right there
[18:12] <hakermania> pautag: No way, Qt libraries are everywhere. Anyway, will look into it again.
[18:13] <hakermania> micahg: Wait a sec for another pakcgae
[18:13] <paultag> Ah, righto :)
[18:21] <hakermania> paultag: I write all the fields etc, but then, when I build through debuild -S -sa all are gone, the meta data go to the previous format, like this: http://paste.ubuntu.com/571276/
[18:22] <paultag> hakermania: cat the patch, is it there?
[18:23] <hakermania> paultag: I have to remake it. Please w8
[18:23] <paultag> hakermania: try removing the old built files up top. I have no idea how debuild handles that stuff, but I use dpkg-buildpackage -S
[18:27] <hakermania> paultag: http://paste.ubuntu.com/571280/ :(
[18:29] <paultag> hakermania: humm, I have no idea. I've never had an issue like that, might want to ask one of the MOTU around :)
[18:30] <hakermania> micahg, cdbs: What do you say about this: http://paste.ubuntu.com/571280/ ? I am making a description of the patch, then I rebuild the package (source build) and the package has turned into its previous format....?
[18:31] <micahg> hakermania: you should rename the patch once you're done with it
[18:31] <micahg> hakermania: and update debian/patches/series with the new name
[18:32] <nonix4> Hmm... to report a bug of firefox refusing to connect to https://bugs.launchpad.net/ and https://bugs.launchpad.net./ (in different ways), guess I should use another browser to file the bug?
[18:33] <micahg> nonix4: do you want to hop in #ubuntu-mozillateam to discuss?
[18:33] <nonix4> 'k
[18:40] <hakermania> micahg: can a patch have uppercase letters?
[18:40] <micahg> hakermania: I think most are lower case
[18:40] <micahg> hakermania: but yes, if needed
[18:48] <hakermania> micahg: new package uploaded
[18:53] <micahg> hakermania: I get e-mailed every time you upload a new version ;)
[18:53] <hakermania> micahg: I know xD
[19:18] <falktx> hey there
[19:18] <falktx> i'm having lots of issues building packages on natty
[19:19] <falktx> afaik, natty has a kinda broken GCC
[19:19] <falktx> how do I force a package to build with an old GCC version?
[19:20] <micahg> falktx: for the archive or personally?
[19:20] <falktx> PPA
[19:20] <falktx> http://launchpadlibrarian.net/64352449/buildlog_ubuntu-natty-amd64.non-sequencer_1.9.3%2Bgit20100103-0ubuntu2~natty3_FAILEDTOBUILD.txt.gz
[19:20] <micahg> falktx: we're going to be dropping gcc-4.1 and gcc-4.3 most likely, so we'll just have 3.3, 4.4, and 4.5
[19:21] <falktx> that will be great
[19:21] <falktx> micahg: when should that happen?
[19:21] <micahg> idk, hopefully before beta
[19:22]  * micahg keeps forgetting to file the metabugs
[19:23] <falktx> micahg: so I shouldn't worry about this much, i guess, right?
[19:24] <micahg> falktx: well, you can try to fix the issues...
[19:24] <falktx> i'm trying
[19:24] <falktx> some are just additional link libraries, others are quite complex
[19:25] <micahg> falktx: well, I don't know offhand how to switch compiler versions, hopefully someone else can jump in here
[19:25] <falktx> i think they did it for Qt
[19:27] <falktx> so far, i added gcc-4.4 to build depends, and in debian/rules 'export CXX=g++-4.4'
[19:58] <m4n1sh> cdbs: ping
[19:59] <m4n1sh> when I upload a new version of my package, LP rejects it saying the orig file is already present
[19:59] <m4n1sh> what do I need to do
[19:59] <m4n1sh> I am using debuild without -us
[20:00] <m4n1sh> but .dsc file still shows the entry of the orig file
[20:00] <m4n1sh> 3f7c7a8b999b443fe2f39a2f080c443a 88313 zeitgeist-sharp_0.1.1.0.orig.tar.gz
[20:04] <bdrung> m4n1sh: to not include the orig file you need to use '-sd'
[20:04] <m4n1sh> bdrung: thanks. trying
[20:05] <m4n1sh> I ran this command
[20:05] <m4n1sh> git buildpackage -S -sd --git-export-dir=../build-area --git-keyid=9E6622AB
[20:05] <m4n1sh> and in .dsc file getting
[20:05] <m4n1sh> Files:
[20:05] <m4n1sh>  3f7c7a8b999b443fe2f39a2f080c443a 88313 zeitgeist-sharp_0.1.1.0.orig.tar.gz
[20:05] <m4n1sh>  4406fa6444a3774dc26aae4f84951231 2892 zeitgeist-sharp_0.1.1.0-2ubuntu1~maverick1~ppa4.debian.tar.gz
[20:05] <cdbs> wierd
[20:06] <cdbs> wait, DSC will mention the hash, I suppose?
[20:06] <cdbs> in both cases
[20:06] <m4n1sh> yes
[20:06] <m4n1sh> which file mentions which files have to be uploaded?
[20:06] <m4n1sh> .changes?
[20:06] <m4n1sh> right?
[20:06] <bdrung> m4n1sh: .changes
[20:06] <cdbs> m4n1sh: yes
[20:07] <m4n1sh> Files:
[20:07] <m4n1sh>  23cf98b7d2d552617c348982eceaa41a 2036 cli-mono optional zeitgeist-sharp_0.1.1.0-2ubuntu1~maverick1~ppa4.dsc
[20:07] <m4n1sh>  b5eff7b685b0d4ba90641b89a89d99b1 2895 cli-mono optional zeitgeist-sharp_0.1.1.0-2ubuntu1~maverick1~ppa4.debian.tar.gz
[20:07] <m4n1sh> yes
[20:07] <m4n1sh> I think none
[20:07] <m4n1sh> it isnt there
[20:07] <cdbs> m4n1sh: I guess the problem is that the checksums are different, of the one on the repo and the one on your system
[20:07] <bdrung> so it won't be uploaded
[20:07] <cdbs> m4n1sh: did you repackage the tarball?
[20:07] <m4n1sh> cdbs: nope
[20:07] <cdbs> m4n1sh: try uploading then
[20:07] <m4n1sh> I am just making changes in debian/ directories
[20:08] <cdbs> that's good
[20:08] <cdbs> okay, /me g2g, sorry
[20:08] <m4n1sh> bdrung: actually it used to get uploaded and then get rejected
[20:08] <m4n1sh> sure
[20:08] <m4n1sh> gn
[20:09] <bdrung> m4n1sh: check the hash sums
[20:10] <m4n1sh> if the one incoming and the old one have different checksums then the upload is rejected?
[20:10] <bdrung> yes
[20:10] <bdrung> existing tarballs can't be replaced by new ones
[20:12] <m4n1sh> thanks
[20:30] <hakermania> micahg: Found any other problem with my package?
[20:31]  * micahg checks
[20:36]  * hakermania says thanks...
[21:13] <hakermania> Good night all.
[22:24] <ricotz> hello could someone second this package upload http://people.ubuntu.com/~ricotz/dockmanager/
[22:25] <ricotz> micahg, ^
[22:25] <micahg> ricotz: I'm #1 :0
[22:25] <micahg> ricotz: or rather, I"m looking at it now
[22:26] <ricotz> siretart, could you take a look? ^
[22:28] <ricotz> gilir_, are you around?
[22:29] <ricotz> RainCT, hello
[22:29] <gilir_> ricotz, yes, but busy, maybe I can look at it later
[22:30] <ricotz> gilir_, it is dockmanager ;)
[22:30] <micahg> ricotz: you have some lintian errors on the binary build
[22:32] <ricotz> micahg, what errors?
[22:33] <micahg> ricotz: http://paste.ubuntu.com/571398/
[22:35] <ricotz> micahg, i built it in a natty pbuilder without errors
[22:36] <micahg> ricotz: sorry, meant warnings
[22:40] <ricotz> micahg, ok, didnt ran it in pedantic, but i thought XB-Python-Version would be sufficient
[22:41]  * micahg doesn't know
[22:42] <micahg> ricotz: if it is, you'll need someone who knows python to advocate the package then
[22:43] <RAOF_> ricotz: You might want to set the environment variable that will prevent gconf from trying to install the schemas in the chroot, and spewing a huge warning.
[22:44] <micahg> ScottK: did we make it to be able to upload to -backports after FF to be copied to the o release when ready?
[22:46] <ricotz> RAOF, you mean in the packaging? how can i do this?
[22:47] <RAOF> ricotz: export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
[22:49] <RAOF> ricotz: Also, dockmanager seems to have incorrect Depends:; why does it depend on python-mpd and python-mutagen, but only Recommend zeitgeist, and why is there no python dependency?
[22:50] <ricotz> RAOF, python-mpd and mutagen is need for some mediaplayer helper
[22:51] <RAOF> And zeitgeist isnt'?
[22:51] <RAOF> And they *all* require python :)
[22:52] <ricotz> RAOF, actually i dont wanted to hard depend on zeitgeist, but right that is no a good idea
[22:52] <ricotz> RAOF, i though XB-Python-Version is enough
[22:53] <RAOF> No; you also need a ${python:Depends} there, although I don't think it'll be populated because you've explicitly excluded the scripts directory from dh_py*'s search.
[22:54] <ricotz> RAOF, ok
[22:55] <ricotz> i am fixing it
[22:57] <RAOF> Also, you're not spelling D-Bus consistently
[22:58] <RAOF> Although colour that a nickpick.
[23:00] <RAOF> And you're missing a manpage for dockmanager-settings.
[23:01] <micahg> RAOF: I posted the pedantic lintian output above for him :)
[23:01] <RAOF> :)
[23:02] <RAOF> I don't use pedantic.
[23:03] <ricotz> :(
[23:11] <ricotz> RAOF, micahg, would you take a second look
[23:11] <micahg> ricotz: sure
[23:12] <ricotz> micahg, thanks
[23:15] <RAOF> And, finally, is there a Debian ITP for this?
[23:16] <micahg> or needs-packaging
[23:17] <ricotz> sorry, there is no bug report or request
[23:20] <ricotz> currently docky and awn are able to use it
[23:21] <micahg> ricotz: the python depends are not working
[23:22] <RAOF> “This package contains dock-independent dbus bindings scripts for”
[23:27] <ricotz> ok, i there isnt more coming
[23:27] <ricotz> i am sorry for this pain
[23:28] <micahg> ricotz: no worries, there's always backports as well, I'd suggest trying to get it in Debian in the meantime
[23:28] <ricotz> actually it is really needed
[23:29] <ricotz> micahg, ^
[23:31] <RAOF> The manpage is a bit malformed; the NAME section should be docmanager
[23:31] <RAOF> Bah, sorry.
[23:31] <RAOF> The manpage is a bit malformed; the NAME section should be docmanager \- $DESCRIPTION.
[23:31] <RAOF> (Replacing $DESCRIPTION with stuff)  lintian -Ii has more details, or I can pastebin the appropriate bit.
[23:32] <micahg> ricotz: both are in universe, if you make a good use case, you might be able to get a release exception
[23:32] <micahg> s/use//
[23:38] <ricotz> micahg, i was hoping after this time we could finish it
[23:38] <ricotz> RAOF, i have updated it
[23:45] <ricotz> RAOF, i hope i didnt delay any x update
[23:46] <RAOF> Nah.  They've already gone through.
[23:52] <ricotz> RAOF, did you find more errors?
[23:52] <RAOF> Just running through it again; other things have come up.
[23:53] <ricotz> thanks
[23:55] <micahg> RAOF: let me know if it checks out, I'll look it over again as well
[23:56] <micahg> ricotz: you're still going to need one more ACK
[23:57] <ricotz> micahg, didnt you said 2?
[23:58] <micahg> ricotz: yep, but RAOF needs to reapply for MOTU (hint, hint), or go for core-dev
[23:58]  * ricotz is hoping RAOF will ack it
[23:58] <ricotz> oh
[23:58]  * micahg hinted the wrong part of that :-/