[00:08] <ari-tczew> micahg, siretart: bug 706725
[00:21] <ari-tczew> mr_pouit: around?
[00:42] <ari-tczew> if package has got changed binary package, is enough to change depends and b-d in rdepends? or replace/conflicts also is needed?
[00:42] <persia> It depends entirely on what sort of binary package change happened.
[00:42] <persia> Do you have an example?
[00:43] <ari-tczew> hello persia
[00:44] <ari-tczew> yes, example: http://paste.ubuntu.com/557454/
[00:44] <ari-tczew> I'm reviewing one sync request which looks small, but it's require a lot of transitions due to some syncs from experimental.
[00:45] <ari-tczew> looks like gigantic work
[00:46] <persia> Ugh.
[00:46] <persia> I generally dislike single source packages providing multiple libraries, and further dislike versioned -dev packages.
[00:47] <persia> But if that's what you7re starting with, you'll also need to adjust the shlibs (and potentially symbols) files, so that things built against it end up with the right dependencies, and then probably rebuild (and likely port) all the rdepends.
[00:49]  * micahg would suggest waiting for Debian to port the rdepends unless there's a pressing reason
[00:49] <persia> Might be done.  Might be relatively easy to port (and Debian/Upstream would appreciate porting patches).
[00:50] <persia> But, yeah, since we're past DIF, probably only worth it if there's some important change.
[00:56] <ari-tczew> micahg, persia: mission failed. getting through the string to the ball, at the end I got: dh_makeshlibs: dpkg-gensymbols -plibgwengui-fox16-0 -Idebian/libgwengui-fox16-0.symbols -Pdebian/libgwengui-fox16-0 returned exit code 1
[00:56] <ari-tczew> too much work
[00:56] <persia> DId you update/change all the symbols files for all the libraries?
[00:57] <ari-tczew> persia: I'm only building experimental packages on my pbuilder-natty.
[01:00] <ari-tczew> FYI, bug 706645
[01:01] <ari-tczew> I can imagine how much rebuilds and transitions will needs Ubuntu 11.10.
[01:01] <ari-tczew> I guess that many libs and important software will be upgraded after Debian 6.0 release like perl 5.12, openssl 1.0
[01:02] <ari-tczew> and viele viele mehr
[01:02] <micahg> ari-tczew: if we can get stuff sync'd with unstable, most of it will happen automatically
[01:02] <micahg> s/will/should/
[01:02] <persia> Yeah.  Once Debian releases, we'll probably want to mostly cherrypick, rather than syncing for natty.
[01:03] <micahg> yeah, I meant sync'd with pretransition versions :)
[01:04] <ari-tczew> micahg: I wish that will be automatically. If it's true that Debian will be released in the 1st half of February, then they have a time to adjust archive since out next devel open - May - June.
[01:04] <ari-tczew> s/out/our
[01:05] <ari-tczew> does anybody know how long adjust toolchain is taking for Debian?
[01:05] <ari-tczew> I;m asking due to curiosity.
[01:07] <ari-tczew> micahg: btw. today reviewing libgpg-error is time-consuming for me. let alone about that much transitions as we've discussed some minutes ago!
[01:07] <kklimonda> out of curiosity :)
[01:07]  * kklimonda would love to have others point out his grammar mistakes more often.
[01:08] <persia> "due to curiosity" is grammatical, if less common
[01:08]  * micahg keeps that in mind :)
[01:08] <kklimonda> persia: really?
[01:08] <kklimonda> thanks, good to know
[01:08] <ari-tczew> what's wrong?
[01:08] <kklimonda> ari-tczew: nothing :)
[01:09] <ari-tczew> ok
[01:09] <kklimonda> persia: it can be used in the same context as "out of curiosity"?
[01:09] <persia> I suppose.  It isn't usually.
[01:09] <ari-tczew> out of curiosity = 0 curiosity
[01:09] <ari-tczew> due to curiosity = a lot of curiosity :>
[01:10]  * ari-tczew feels pretty sick. :-/
[01:11] <micahg> ari-tczew: no, out of curiosity means that curiosity exists, basically the same thing as due to curiosity colloquially
[01:11] <persia> kklimonda, "Colorless green ideas sleep furiously" is grammatical as well: don't fall into the trap that everything grammatical is good: usage is important.
[01:11] <kklimonda> persia: I missed you :)
[01:11] <persia> http://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously
[01:14] <RAOF> persia: So, what we need is a language where only correct statements are grammatical :)
[01:14] <ari-tczew> micahg: OK kklimonda explained me via PM about special case for "out of curiosity"
[01:49] <ari-tczew> bdrung: why kubuntu.org is not supported by update-maintainer?
[01:53] <persia> Because the packages *should* all have "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" as the maintainer, which doesn't include that string.  Anything else encourages separatism.
[01:54] <ari-tczew> persia: maintainer with @ubuntu.com is wrong?
[01:55] <persia> It's suboptimal.  Anything other than the string above implies that that package should only be modified by some subset team, rather than all developers.
[01:55] <persia> This is an exclusionary statement, something we try to avoid.
[02:07] <kklimonda> oh great, looks like libevent transition is going to be a pure joy
[02:08] <kklimonda> the 2.0.10 version have a versioned library, but puts headers in the same location as 1.4.x..
[02:09] <RAOF> That sounds pretty standard.
[02:10] <kklimonda> RAOF: but now we can't really update libevent to 2.0.10 until all applications that are using 1.4.x aren't ported, right?
[02:10] <RAOF> Yes.
[02:11] <Rcart> Hello everyone. Which deb3 fields are more common used in a patch?
[02:12] <kklimonda> RAOF: well, that doesn't sound standard to me.. and to think that just few months back I was asking why are gtk headers versioned.. :)
[02:12] <paultag> Rcart: deb3 or dep3 ?
[02:12] <Rcart> paultag: Sorry, dep3 (:
[02:12] <RAOF> kklimonda: It's what often happens, which makes it fairly standard :)
[02:12] <paultag> Rcart: :)
[02:13] <paultag> Rcart: what ever feels right. There are some that make sense, others that really would only apply to stuff such as the linux project
[02:13] <paultag> Rcart: I use different tags ( most the time ) then others because of my workflow
[02:13] <paultag> Rcart: it's status upstream, description and author are usually common
[02:15] <kklimonda> I use Description, Origin, Forwarded (if Origin != upstream) and Bug-(Debian|Ubuntu)
[02:15] <paultag> +1
[02:16] <paultag> today was a great day. I got rid of most of my patches :)
[02:17] <paultag> God, I hate patches so much. They just fester and clot up the code base
[02:17] <Rcart> Ok, thanks paultag and kklimonda :)
[02:17] <paultag> good luck Rcart!
[02:19] <ari-tczew> I know why Rcart is asking about DEP3 :)
[02:19] <paultag> ari-tczew: yeah?
[02:19] <Rcart> ari-tczew: o/
[02:19] <ari-tczew> paultag: IIRC I suggested him to add to his patch.
[02:19] <ari-tczew> Rcart: hello
[02:19] <paultag> ari-tczew: ah. gotcha
[02:21] <Rcart> ari-tczew: i'm working to update the branch, but found right now that there's a bug report and a patch upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653
[02:21] <ari-tczew> Rcart: is it the same as yours?
[02:23] <Rcart> No, looks better
[02:23] <ari-tczew> Rcart: OK then it's fine. You can exchange patch and in Origin tag put link to comment where you found patch
[02:25] <kklimonda> RAOF: assuming that libeven API hasn't changed (which is apparently the case) is it early enough to start the transition for natty? rdepends are http://paste.ubuntu.com/557486/
[02:26] <ari-tczew> how can I delete package from REVU? I found asterisk since asterisk exists in our and Debian archive already.
[02:26]  * ari-tczew has got an idea to clean up REVU after Debian release.
[02:26] <RAOF> kklimonda: If the API hasn't changed then it's simply a rebuild for all rdepends; that list looks nicely leafy.
[02:27] <Rcart> ari-tczew: You mean import the upstream patch, apply it and update the branch, right? Now i got about dep3 tag :)
[02:28] <ari-tczew> Rcart: yes
[02:28] <RAOF> kklimonda: I'd check if everything on that list builds correctly; if so, I'd consider it early enough for the upgrade.
[02:28] <kklimonda> RAOF: yes, that's what I'm planning on doing :)
[02:33] <persia> ari-tczew, The general practice is just to archive anything already in the archives.
[02:41] <Rcart> ari-tczew: Thanks, working on it.
[02:44]  * ari-tczew is off to bed.
[03:35] <kklimonda> directhex: any idea why banshee uses twice as much cpu as rhythmbox?
[03:35] <kklimonda> directhex: while playing music
[06:08] <siretart> bdrung: thanks for noticing. Yes, your suggestion makes sense to me, feel free to adjust the recipie, it belongs to the motumedia team
[06:10] <sagaci_> test
[07:01] <Rcart> Hi!. I'm importing a patch from upstream and i'm gonna include a dep3 tag to the patch. If i include the Bug field, this most point to the launchpad bug report, and the Bug-Debian to, obviously, the debian bug report, right?
[07:02] <broder> Rcart: no, Bug is the upstream bug tracker. Bug-Ubuntu would be for the launchpad bug
[07:02] <broder> err, that is assuming that upstream isn't using launchpad for bugtracking itself...
[07:05] <Rcart> broder: Great, thanks (;
[07:15] <Rcart> broder: Would please give a look to the patch's tag? http://pastebin.com/0WHkwHS3
[07:16] <broder> Rcart: the debian bts isn't upstream for bittornado, is it?
[07:16] <broder> Rcart: also, there should be an empty line separating the dep-3 block and the actual patch
[07:16] <Rcart> broder: No, is not. So the field mos be: Bug-Debian, right?
[07:17] <broder> Rcart: right
[07:17] <broder> Rcart: also, your origin tag isn't very specific - something like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593653#17 would be better (since it references the specific message - i assume that's the specific message)
[07:19] <Rcart> broder: Your're right :)
[07:22] <Rcart> broder: http://pastebin.com/BA1kgDQX
[07:25] <broder> Rcart: that's fine, though it would be nice if you used some of the other optional tags that apply, like author and forwarded (even better is if you actually forward it)
[07:25] <broder> Rcart: but i need to go to bed now. i'm sure anybody else would be happy to assist if you need any further help
[07:26] <Rcart> broder: thanks a lot :)
[08:01] <dholbach> good morning
[08:16] <AnAnt> Hello
[08:16] <AnAnt> why didn't I get this FTBFS http://launchpadlibrarian.net/62702256/buildlog_ubuntu-natty-i386.libgwenhywfar_4.0.3-1_FAILEDTOBUILD.txt.gz on maverick ?
[08:17] <AnAnt> nor on Debian experimental
[08:24] <RAOF> AnAnt: So, it's failing because one of the symbols in went away.  Being C++, that *could* be due to something changing elsewhere in the toolchain.
[08:26] <AnAnt> gcc 4.5 ?
[08:29] <AnAnt> RAOF: so, what should be fixed ?
[08:29] <AnAnt> RAOF: shall I edit the symbols file & reupload , or the fix should actually be somewhere else ?
[08:32] <tumbleweed> AnAnt: it's a destructor, probably not important, I'd guess you can make it optional and avoid a soname bump
[08:35] <AnAnt> tumbleweed: what do you mean by "make it optional" ?
[08:39] <tumbleweed> AnAnt: see dpkg-gensymbols(1). Btw c++filt is very handy for demangling C++ symbols
[08:43] <AnAnt> thanks
[08:44] <AnAnt> tumbleweed: but why did that symbols dissappear on natty, but not on maverick nor experimental ?
[08:44] <kklimonda> hmm, when I prepare a full branch for a merge should I leave release as UNRELEASED or change it?
[08:46] <tumbleweed> AnAnt: different gcc version, I'd assume
[08:47] <tumbleweed> kklimonda: if it's a merge, you might as well change it. If it's a shared packaging branch, UNRELEASED seems sensible, as you don't want a confusing changelog after a rejected review
[08:48] <AnAnt> tumbleweed: how about using the c++ tag ?
[08:49] <kklimonda> tumbleweed: thanks
[08:50] <tumbleweed> AnAnt: if you are the debian maintainer, it's useful, as you can use it instead of mangled symbols in the symbols file. But it doesn't help you here at all
[11:37] <ari-tczew> wrrrrrrrrrrrrrrrrr
[11:37] <ari-tczew> what da f**
[11:37] <ari-tczew> https://launchpad.net/ubuntu/+source/gnucash/1:2.4.0-3
[11:37] <ari-tczew> we have discussion in the night about that
[11:38] <ari-tczew> AnAnt - facepalm!!! if you read this
[11:38] <ari-tczew> this is gigantic transition
[11:42] <ari-tczew> he uploaded packages from experimental without testing before - https://launchpad.net/ubuntu/+source/libgwenhywfar/+changelog
[11:42] <ari-tczew> shameful
[11:42] <ari-tczew> he should lost his upload access
[11:45] <Laney> maybe he wants to handle the transition
[11:49] <Rhonda> !language | ari-tczew
[11:50] <geser> ari-tczew: where did the discussion happen? I see only a discussion about the symbol issue in my scrollback for this channel
[11:50] <ari-tczew> Laney: looking on his activities, I dount
[11:50] <ari-tczew> doubt*
[11:51] <jpds> Oh well, people should use homebank anyway.
[11:52] <ari-tczew> geser: http://paste.ubuntu.com/557610/
[11:52] <ari-tczew> sync gnucash requires sync 2 B-D from experimental and then do transitions. it's clear to understand in above log.
[11:55] <kklimonda> argh, 4 packages ftbfs with libevent2, one of them being developed by the author of libevent himself..
[11:55] <kklimonda> good morning
[11:55] <ari-tczew> hello kklimonda
[11:55] <geser> ari-tczew: so AnAnt wasn't involved in this discussion but missed reading the bug about the sync before using syncpackage?
[11:56] <ari-tczew> geser: yes, he didn't read sync request for gnucash - again, shameful
[11:56] <Rhonda> It looks like there might be a rush of new stuff into Debian testing in march/april going on. I fear that's too late for natty, is it?
[11:56] <ari-tczew> I'm writing e-mail to DMB - Cc to TB since there is only bdrung in DMB
[11:57] <kklimonda> Rhonda: yeah, the feature freeze is at the end of february
[11:57] <ari-tczew> Rhonda: as clarified in log, we are after DIF and that big transitions are too hard to do
[11:58] <Rhonda> kklimonda: hmm, that might enable at least a bit of flow
[11:58] <soren> jpds: Some of us have *actual* accounting to do, you know :)
[11:58] <jpds> soren: Yeah; me too.
[11:58] <Rhonda> Ah, reminds me that I should do a syncrequest for pgadmin3 again, from experimental :)
[11:59] <Rhonda> ari-tczew: Depends on point of view and what one is willing to invest. But we have been through the willingness of investment before, so …
[12:00] <soren> jpds: No support for currencies (let alone multiple currencies), it doesn't seem to even have the concept of expense and income accounts..
[12:01] <Rhonda> So I guess after I finished the job for the squeeze release I'll put special attention in good sync candidates.
[12:01] <soren> jpds: Does it even do double-entry book keeping?
[12:03] <ari-tczew> Rhonda: 1) Didn't check bug before use syncpackage.   2) Didn't test build before uploading - twice!   3) Guess that didn't consider about transitions needed.
[12:05] <geser> ari-tczew: do you know how many packages are involved in this transition?
[12:05] <Rhonda> ari-tczew: I can understand that. But your tone isn't really helpful nor in accordance with CoC, there's no need to swear, even if *ed out.
[12:06] <ari-tczew> geser: I checked in the night - more than 10 IIRC.
[12:06] <chrisccoulson_> how do you know he didn't consider the transition needed? it's not that many packages....
[12:07] <chrisccoulson_> and not reading a comment on a bug against another package is hardly "shameful", as you put it
[12:07] <chrisccoulson_> i think you're over-reacting a bit
[12:07] <ari-tczew> chrisccoulson_: well, I guess as he didn't test build and didn't check difference between packages synced from experimental.
[12:07] <ari-tczew> even if it's sync, developer should check debdiff between dscs
[12:07] <bdrung> ari-tczew: how do you know that he didn't do a build test? sometimes a package builds locally, but fails in the archive.
[12:08] <ari-tczew> bdrung: built not locally
[12:08] <ari-tczew> because I was checking sync request
[12:09] <bdrung> ari-tczew: i assumes it two times that someone didn't build the package before uploading, but in both cases they did and i worked for them for different reasons.
[12:09] <bdrung> ari-tczew: that's why i prefer to ask the people before judging them.
[12:10] <chrisccoulson_> indeed :-)
[12:10] <bdrung> ari-tczew: the old rule of presumption of innocence
[12:11] <ari-tczew> bdrung: I'm 90% sure that he didn't test build and he will tell you that he did test build, because won't admit to the error. naivete!
[12:13] <bdrung> ari-tczew: did he lied before or why are you sure that he will lie?
[12:16] <dholbach> ari-tczew, I think before you start complaining about somebody, you should take the time to get in touch with them and in a very calm way ask what their actual plan was
[12:18] <dholbach> I agree with bdrung that it's a good idea to first assume some kind of misunderstanding or maybe hear more about the motives/plan behind some move
[12:18] <tumbleweed> especially if you actually want to resolve the situation rather than getting everyone's backs up
[12:19] <dholbach> ari-tczew, I'm a bit concerned that your first reaction is to "report the person to the TB/DMB/whoever" before having talked to them
[12:23] <ari-tczew> wait, 10 minutes
[12:23] <ari-tczew> I''ll have interesting log
[12:27] <dholbach> ari-tczew, this is not about proving that you were right right from the start
[12:28] <dholbach> I'm talking about calming down, assuming some kind of misunderstanding in the interest of keeping a good atmosphere AND solving the problem
[12:29] <dholbach> I personally did many mistakes regarding Ubuntu development, but I'm glad they were pointed out to me in a calm way, so I could go and fix them
[12:30] <dholbach> and keeping the atmosphere friendly and encouraging to me is the most important thing here
[12:30] <AnAnt> Hello, is it required that I check for a syncrequest bug before I syncpackage ?
[12:31] <ari-tczew> bingo ;D
[12:31] <bdrung> AnAnt: at least recommended.
[12:32] <dholbach> ari-tczew, give it a break!
[12:32] <ari-tczew> ok folks, transcripts: http://paste.ubuntu.com/557621/
[12:32] <dholbach> it's easy enough to duplicate a bug
[12:32] <ari-tczew> dholbach: you didn't got it, there wasn't duplicate a bug
[12:32] <ari-tczew> just ignore triaging bugs
[12:32] <ari-tczew> he used syncpackage, not archive-admin way
[12:33] <AnAnt> syncpackage shouldn't be used ?
[12:33] <geser> ari-tczew: is this log from a private conversation of you with AnAnt?
[12:33] <ari-tczew> geser: yes, it is
[12:33] <ari-tczew> I know I shoulnd't
[12:33] <ari-tczew> but this is the way to get feedback objective
[12:33] <geser> ari-tczew: did you ask him if it's ok before you published it?
[12:33] <AnAnt> may I know what is wrong ?
[12:33] <ari-tczew> geser: sorry, no
[12:34] <ari-tczew> I'm bad man
[12:34] <Rhonda> ari-tczew: The log shows that you have a rather aggressive style in private queries, too.  And publishing private stuff isn't really helping.
[12:34] <AnAnt> I built libgwenhywfar on maverick, and it built successfully, I didn't imagine that it would FTBFS (for a reason that I still not sure of) on natty
[12:35] <Rhonda> AnAnt: Right, please testbuild in future on the distribution you will upload too
[12:35] <geser> AnAnt: see http://irclogs.ubuntu.com/2011/01/24/%23ubuntu-motu.html#t11:37
[12:35] <bdrung> AnAnt: always build the package which you are going to upload on the target release! change compiler, compiler flags, different libraries lead to build failures.
[12:35] <Rhonda> AnAnt: cowbuilder or pbuild will help you, giving you chroots for that so you don't have to have a system with each distribution next to each other.
[12:35] <AnAnt> what is "facepalm"
[12:36] <Rhonda> AnAnt: http://deb.at/Ifacepalm
[12:36] <ari-tczew> google it
[12:36] <dholbach> AnAnt, it's safe to ignore it
[12:36] <Rhonda> AnAnt: Feel free to ignore that
[12:36] <bdrung> Rhonda, AnAnt: or pbuilder-dist ;)
[12:37] <AnAnt> ok, I did a mistake, that I later fixed
[12:37] <ari-tczew> how can build package for natty on maverick?
[12:37] <AnAnt> but I have the impression, that there is something worse than an FTBFS going on
[12:37] <ari-tczew> it's illogical
[12:38] <bdrung> AnAnt: yes, a started transition.
[12:38] <ari-tczew> you uploaded package with FTBFS - better and preffered way is add patch on package from experimental and upload fixed package
[12:38] <AnAnt> bdrung: 5 packages ?
[12:38] <AnAnt> ari-tczew: why fix it on experimental, if it builds fine there, we don't even know for sure what caused the FTBFS, that was just a workaround !
[12:39] <dholbach> ari-tczew, can you try to calm down? I think AnAnt is fully aware of the mistake now and in addition to that there's still quite a bit of time to fix it - it's not like we're 5 minutes before natty release
[12:39] <ari-tczew> I was overreacted with quantity of transition, yes, sorry. That was not gigantic. But other ways have been neglected.
[12:39] <AnAnt> bdrung: transitions aren't allowed before feature freeze ?
[12:39] <kklimonda> what's the point of this discussion? if it doesn't build, and we can't afford the transition, just downgrade it. It would already be done.
[12:39] <AnAnt> ari-tczew: what other ways ?
[12:39] <kklimonda> really, if we start calling technical board when people make mistakes then no one is going to do any work harder than simple syncs and merges
[12:40] <Rhonda> kklimonda: From what I understood the FTBFS is already fixed.
[12:40] <kklimonda> because something always may break
[12:40] <kklimonda> I'm preparing a migration of libevent2 atm, over 30 packages to rebuild, 8 to change.
[12:40] <kklimonda> should I be scared that someone will yell at me if something breaks?
[12:40] <ari-tczew> AnAnt: no, it didn't build fine on natty. I was checking it some hours ago on pbuilder-NATTY, not maverick.
[12:41] <bdrung> AnAnt: they are allowed, but ari-tczew claimed that you haven't checked that a transition is required for your upload.
[12:42] <ari-tczew> and didn't check existing bug!
[12:42] <AnAnt> I did
[12:42] <ari-tczew> lie
[12:42] <AnAnt> no, I didn't check a bug
[12:42] <dholbach> ari-tczew, calm down
[12:42] <ari-tczew> busted ^^
[12:42] <AnAnt> I checked the transitions
[12:42] <AnAnt> what is this ?
[12:42] <ari-tczew> nevermind, continue
[13:01] <ari-tczew> AnAnt and all: apologies, my reaction was bad. I have not bad intentions. Just making sure for technical quality.
[13:54] <kunal> hello
[13:54] <kunal> If we are reuploading a changed package (after receiving reviews), we need to change version and upload without source code?
[13:55] <kunal> or same version and use -f option?
[13:57] <ari-tczew> kunal: check patch system 0
[13:58] <ari-tczew> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[13:58] <kunal> ari-tczew: thanks
[13:58] <ari-tczew> You're welcome.
[14:01] <kunal> ari-tczew: is this also applicable for uploading on revu?
[14:02] <ari-tczew> kunal: Yes. Do you want to upload a new package?
[14:02] <kunal> ari-tczew: i already have a package there, i want to integrate review changes
[14:03] <ari-tczew> kunal: aha ok
[14:04] <Laney> kunal: keep the same version
[14:05] <Laney> one version per /Ubuntu archive/ upload
[14:05] <kunal> ok
[14:05] <kunal> and changelog?
[14:05] <ari-tczew> 0ubuntu1
[14:05] <kunal> ok
[15:16] <m4n1sh> a package zeitgeist does not have 0.7 version present in Maverick. So I built it in my PPA. Is the versioning 0.7-0ubuntu1~0ppa1~maverick alright? or it breaks it?
[15:17] <ari-tczew> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1
[15:18] <m4n1sh> ara: I thought that maverick should come later?
[15:18] <m4n1sh> ari-tczew: how is that different?
[15:19] <ari-tczew> m4n1sh: backports have ~maverick1 so you should use ppa as a second
[15:19] <m4n1sh> ari-tczew: i think a few people might be using that package
[15:19] <m4n1sh> so I upload a package with this version
[15:19] <m4n1sh> will it be overridden?
[15:20] <ari-tczew> m4n1sh: what version do you have already in PPA?
[15:20] <m4n1sh>  0.7-0ubuntu1~0ppa1~maverick
[15:20] <ari-tczew> not good
[15:20] <ari-tczew> I must  go away right now, I'm late
[15:21] <m4n1sh> ari-tczew: so i should delete and start? or upload it and it will come as an update?
[16:12] <tsimpson> m4n1sh: 0.7-0ubuntu1~maverick1~ppa1 would be better, as if the package is backported to maverick it would be 0.7-0ubuntu1~maverick1, so the backported version would be considered higher than the PPA version
[16:13] <tsimpson> m4n1sh: however, because you put -0ppa1, 0.7-0ubuntu1~maverick1 would still be higher than the PPA version, so it's not going to cause any trouble
[16:19] <micahg> bdrung: is there an option to not upload the .orig.tar.foo with backportpackage? ( I looked at the man page and didn't see one)
[16:39] <Laney> what shall I do with the versioning of a package that was previously removed?
[16:39] <Laney> Only consider the version that was in a release?
[16:39] <Laney> s/removed\?/removed, and I want to bring back?/
[16:43] <Laney> I'll just upload as if it were the next Ubuntu upload normally, that way there shouldn't be any problems.
[16:46] <bdrung> micahg: no. bug #691897
[16:50] <Laney> haskell rebuilds: good for ones karma
[17:00] <m4n1sh> tsimpson: thanks a lot :)
[17:25] <ari-tczew> how can I fix this FTBFS? http://paste.ubuntu.com/557741/
[17:25] <ari-tczew> udienz: you know? ^^
[17:26] <udienz> ari-tczew, adding -lQtCore
[17:27] <ari-tczew> udienz: @QT_LIBS@ is not enough?
[17:28] <udienz> ari-tczew, i guess enough. i look at nvclock maybe QT_LIBS should added after LIBS
[17:29] <udienz> in nvclock_qt:: section
[17:32] <ari-tczew> udienz: now I'm working on nvclock from Debian svn
[17:34] <udienz> ari-tczew: great!  and patch from doko will usable and not useless anymore
[19:27] <paultag> debfx: thanks for the patch against fluxbox, btw
[19:27] <paultag> debfx: don't think I've messaged you directly
[19:28] <paultag> debfx: we fixed it by correcting the underlying issue, but I'd not seen the ftbfs
[19:28] <debfx> paultag: you're welcome :)
[19:31] <paultag> and now, off to uni -- ciao!
[19:31] <debfx> paultag: feel free to ping me once a new version is in debian so I can sync it to ubuntu
[19:32] <paultag> debfx: will do, it's going to be in about two weeks, I got upstream to do a 1.1.3 release ( first release in 3 years! ), and it squashes most of our bugs :)
[19:32] <paultag> debfx: upstream and myself are killing off the last issues before doing 1.1.3, should be nice and stable
[19:46] <RainCT> bdmurray: So python-espeak is an important package?
[19:48] <bdmurray> RainCT: can you remind me of the bug number?
[19:54] <RainCT> bdmurray: bug #580781
[20:00] <bdmurray> since the "upstream" task was high it seemed reasonable to me that the ubuntu one would be too
[20:02] <RainCT> bdmurray: Isn't "A bug that has a severe impact on a non-core application." -> Medium? Anyway, I'm not worried about it, just wondering whether I'd missed something about python-espeak being used (i'm upstream) :P
[20:04] <broder> bdmurray: ubuntu bug priorities are evaluated in the context of ubuntu as a whole, which will almost always deflate the priority relative to how upstream views a bug
[20:06] <bdmurray> Okay I've set it to Medium.
[21:24] <micahg> bdrung: would it be hard to get a flag to not include the orig.tar.foo instead of it being dynamic
[21:24] <bdrung> micahg: i would prefer to have it autodetecting the need of the orig file
[21:25] <micahg> bdrung: that would require querying LP for the status of the package in the archive it'll be uploaded to
[21:26] <bdrung> micahg: yes
[22:59] <bdrung> tumbleweed: bug #707187
[23:41] <bdrung> ari-tczew: please unsubscribe ubuntu-sponsor if you sponsor an upload