[00:23] <joaopinto> sistpoty,
[00:23] <joaopinto> notecase (1.9.8-0ubuntu3) karmic; urgency=low
[00:23] <joaopinto>   * FTBFS: Added include <stdio.h> to IniFile.h (LP: #447628)
[00:23] <joaopinto> like this ?
[00:23] <sistpoty> joaopinto: that's excellent!
[00:23] <joaopinto> ok, goind go attach the debdiff now
[00:23] <joaopinto> going to
[00:24]  * funkyHat hasn't found any other FTBFS that aren't C or C++ problems :(
[00:24] <joaopinto> hum, there is a change which was not done by me
[00:24] <joaopinto> -Architecture: i686
[00:24] <joaopinto> +Architecture: amd64
[00:24] <joaopinto> oh, deb dir
[00:25] <joaopinto> this is some temporary dir as part of the building process
[00:25] <joaopinto> notecase-1.9.8/deb/control
[00:26] <joaopinto> sistpoty, the package building source touchs a deb dir, it was no my change, i'll keep it in in the debdiff
[00:27] <sistpoty> sure thing, amd64 does make more sense imho ;)
[00:28] <joaopinto> done, bug 447628
[00:33] <sistpoty> joaopinto: the changed file doesn't seem to be one I'd worry about. patch looks good :), test-building
[00:37] <joaopinto> I would like to update a package to a newer version: http://icculus.org/referencer/ChangeLog, the new version is from August and it's mostly bugfixes
[00:43] <joaopinto> well, maybe is to late for that
[00:43] <joaopinto> I hate fixing problems on out-dated packages
[00:45] <sistpoty> joaopinto: sorry, was afk for a minute, and notecase failed to build for me (not your fault, problems with mirror on my side, retrying)
[00:45] <joaopinto> I did a test build on a karmic schroot
[00:47] <sistpoty> joaopinto: yes, as I wrote it's not your fault (my pbuilder failed to download build-deps, due to 403 on my mirror, grmpf)
[00:47] <sistpoty> ah, better now, compiling :)
[00:52] <sistpoty> joaopinto: in regards to referencer, imo it makes sense to file a FFe if it builds fine and subscribe seb128 (his terrain)
[00:52] <sistpoty> at least from a quick read of changelog
[00:53] <joaopinto> I am not experienced in those processes, i will just fix the ftbfs for now
[00:54] <sistpoty> !FFE
[00:54] <joaopinto> if the new version was not request, is because no one care about it until now
[00:54] <joaopinto> requested
[00:55] <sistpoty> joaopinto: gnome is a little bit special due to its release cycle being coordinated with Ubuntu's
[00:55] <joaopinto> there are some bugs reported about referencer, they would need to be checked and validated against the new version
[00:55] <sistpoty> joaopinto: question is if it's a package fallling under that release cycle
[00:55] <sistpoty> joaopinto: btw: notecase uploaded, thanks again!
[00:56] <joaopinto> yw :)
[00:56] <joaopinto> I am just test building referencer now
[01:02] <captivus> Hello.  I have, embarrassingly, forgotten my passphrase for the OpenPGP key I created when I created my LP account a few months back.
[01:02] <captivus> (I've clearly not used it since then.)
[01:03] <captivus> Anyone have any suggestions?
[01:03] <sistpoty> captivus: revoke that key and create a new one?
[01:03] <captivus> Ok.  How do I do that?
[01:04] <captivus> Oh, wait -- I'd have had to have created a revocation key, right?
[01:04] <captivus> How do I know if I created one?
[01:04] <captivus> (I don't recall doing that.)
[01:04] <sistpoty> captivus: using your revocation certificate that you've printed on paper and stored in your treasury once you generated the old key?
[01:04] <captivus> Oh, well that would be sensible ...
[01:04] <captivus> ... I definitely didn't do that.
[01:05] <sistpoty> captivus: then do that for the key you generate now ;)
[01:05] <captivus> sistpoty: LOL!  I'm going to be forever haunted by the ghost of this old key.  It's going to be lingering out there associated with my name forever.
[01:05] <captivus> God, that's so embarrassing.
[01:06] <sistpoty> captivus: yes, happened to me as well :(
[01:06] <joaopinto> sistpoty, bug 447659
[01:08] <sistpoty> joaopinto: looking
[01:09] <sistpoty> joaopinto: that's c++?
[01:09] <sistpoty> joaopinto: if so the really correct header is <cstdint>
[01:09] <joaopinto> siretart, yes, it's c++
[01:09] <joaopinto> ops :\
[01:09] <joaopinto> used the C header
[01:10] <sistpoty> joaopinto: I'll fix this before uploading, ok?
[01:10] <joaopinto> ok
[01:11] <joaopinto> sistpoty, it fails to compile if you include <cstdint>
[01:11] <joaopinto> /usr/include/c++/4.4/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
[01:12] <sistpoty> joaopinto: ah, crack, that that was solved with -4.4 now
[01:12] <sistpoty> thought that... even
[01:13] <sistpoty> joaopinto: another tiny change: I've updated the maintainer field... ok?
[01:14] <joaopinto> ok
[01:15] <sistpoty> argh, me hates de.archive.ubuntu.com today. mirrors don't seem to be in agreement depending which ip resolve to the name
[01:15] <sistpoty> (and one constantly says 403)
[01:18] <joaopinto> lighttpd looks another candidate for FFe
[01:18] <joaopinto> but that should be requested by someone really using it
[01:22] <joaopinto> argh, lighttpd calls automake, it produces a big debdiff, is that ok to fix FTBFS ?
[01:25] <sistpoty> joaopinto: sure, if it's only autotools files there's no problem
[01:27] <sistpoty> joaopinto: hm, you're fixing faster than I can sponsor :P (referencer uploaded, thanks!)
[01:27] <joaopinto> sistpoty, bug 447672
[01:27] <joaopinto> I only changed debian/control and added the changelog entry, all the other diff is autotools
[01:31] <sistpoty> joaopinto: patch is ok, but debian/changelog is erm, very brief. can you be a little bit more verbose there? ;)
[01:32] <joaopinto> erm, more verbose how ? I just noted it needed automake1.10 because configure invoked aclocal-1.10 :P
[01:34] <sistpoty> joaopinto: as in * debian/control: change build-dependency of ... * rerun autotools
[01:34] <jbernard_> i just posted a patch for Bug #447677, if anyone has a sec to review
[01:35] <sistpoty> <- out for 5 minutes, will continue reviewing then
[01:35] <quidnunc> When trying to run sudo do-release-upgrade -d I get "Building old list of packages... errors present. Is apt/dpkg running?" Anyone know what the problem is?
[01:35] <joaopinto> well, rerun autotools was not an explicit action, actually I could just trim dow the diff
[01:35] <quidnunc> Or, how can I run do-release-upgrade with debug logging on?
[01:36] <joaopinto> quidnunc, this channel is not for support, try #ubuntu or #ubuntu+1
[01:36] <quidnunc> Sorry
[01:39] <joaopinto> sistpoty, i will be attaching a new diff, without the autotools changes
[01:39] <sistpoty> joaopinto: thanks!
[01:44] <sistpoty> jbernard_: excellent, thanks! can you forward the patch to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549778 please?
[01:45] <joaopinto> brb
[01:45] <jbernard_> sistpoty: yep, im working on it right now
[01:45] <jbernard_> sistpoty: i crosslinked to the deb bug in LP
[01:45] <sistpoty> :)
[01:46] <sistpoty> jbernard_: uploaded, thanks!
[01:47] <jbernard_> sistpoty: awesome! thanks man
[01:50] <joaopinto> sistpoty, https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/447672
[01:51] <sistpoty> joaopinto: looks great, test-building again
[02:03] <sistpoty> joaopinto: lighttpd uploaded, thanks!
[02:04] <superm1> sistpoty, re bug 432678 there is a kernel component that needs to be updated too
[02:04] <superm1> it's been on my TODO for the last week or so to fully investigate
[02:04] <superm1> but it's a daunting task.  i always shrug whenever i need to touch LIRC
[02:05] <superm1> if you can make a call in terms of the FFe, i'll sort out the technical details if you lean towards yes though
[02:05] <sistpoty> superm1: thanks for the info
[02:05] <sistpoty> superm1: basically having you sort out details is what makes me lean very much towards it
[02:06] <sistpoty> superm1: the FFe only sounded as if we'd need to make changes to the stock kernel of which noone is aware yet ;)
[02:06] <superm1> which is true
[02:07] <superm1> there is a LIRC patchset that sits on top of the kernel
[02:07] <sistpoty> superm1: will that patchset work with an older lirc?
[02:07] <superm1> no it won't
[02:08] <superm1> so it's either new LIRC + new patches to kernel
[02:08] <superm1> or stay with the current stuff
[02:08] <sistpoty> superm1: hm, are you ok if I'll elevate this to ubuntu-release then?
[02:09] <superm1> sistpoty, yeah however you'd like to do it.  i'll clone a kernel and try to look into the technical details over the weekend
[02:09] <sistpoty> superm1: excellent, thanks!
[02:10] <superm1> it's worth mentioning the patches apply directly to a lirc/ directory and don't hurt anything else ever
[02:10] <superm1> so as long as they're verified to compile, they're harmless
[02:12] <sistpoty> <- doesn't know much about the kernel and certainly doesn't feel qualified to decide about kernel matters :P
[02:16] <joaopinto> sistpoty, check bug 447701 please , and now i am going to bed
[02:54] <sistpoty> <- falls into bed now.. gn8 everyone
[04:39] <mzz> How do I get debuild (or dpkg-buildpackage, or whatever's actually doing this) to show me the commandline used for "Now running lintian..."? I'm getting a complaint there (bad-ubuntu-distribution-in-changes-file unstable) that lintian -iIE --pedantic does not give me.
[04:43] <mzz> ah! I need to run it on the changes file, not on the dsc
[04:44] <mzz> (I'm guessing that always runs more checks?)
[11:36] <surfzoid> Hi, after a build package request at bugzilla, it took usually long time to see it in ubuntu ?
[11:37] <surfzoid> oups sorry, i mean launchpad not bugzilla :-)
[11:45] <av`> surfzoid, package name?
[11:45] <surfzoid> MonoOSC,  day ago :-)
[11:45] <surfzoid> https://bugs.launchpad.net/bugs/443398
[11:46] <surfzoid> 5 days ago
[11:46] <surfzoid> av`: not so long :-)
[11:46] <av`> surfzoid, give me a sec and I have a look at it, finishing something
[11:46] <surfzoid> hey, oki, very nice :-)
[11:48] <joaopinto> surfzoid, not goind to happen for this release
[11:48] <joaopinto> ops, gone
[11:51] <slacker_nl> i'm reading some of the chat logs of ubuntu developer week, why does dholbach installs some of the packages with no-install-recommends? apt-get install --no-install-recommends bzr ubuntu-dev-tools devscripts dpkg-dev cdbs
[12:15] <Laney> motu-release folks: would http://projects.qnetp.net/versions/show/9 get a FFe you think?
[12:35] <joaopinto> can someone check and upload the fix for bug 447933 ?
[12:37] <Laney> joaopinto: is the patch upstream?
[12:37] <joaopinto> no, I am going to send it now
[12:38] <Laney> ok
[12:46] <joaopinto> report upstream now
[12:46] <joaopinto> reported
[12:46] <joaopinto> who should I subcribe when no one is available for FTBFS bugs ?
[12:52] <Laney> this package takes ages to build
[13:01] <joaopinto> Laney, it does :P
[13:02] <jbernard_> joaopinto: i've been subscribing 'universe sponsors' to my FTBFS bugs
[13:02] <Laney> oh there it's finished
[13:03] <joaopinto> jbernard_, ok tks, Laney you are working on it right ?
[13:03] <Laney> joaopinto: uploaded
[13:04] <joaopinto> Laney, tks
[13:05] <Laney> please could you send it to debian too?
[13:14] <joaopinto> Laney, I have sent it to the upstream authors, it will land into debian on the next update
[13:16] <Laney> joaopinto: they might want to fix the ftbfs more immediately
[13:19] <joaopinto> ok
[13:25] <av`> jbernard_, did you do any FTBFS fix recently?
[13:25] <joaopinto> Laney, bug 447967
[13:26] <av`> joaopinto, the LP: xxxx field is broken
[13:27] <joaopinto> ops, forgot to update the source diff
[13:27] <ari-tczew> aloha
[13:28] <joaopinto> av`, fixed
[13:28] <av`> joaopinto, where did you grab that patch from?
[13:29] <joaopinto> av`, from myself
[13:34] <joaopinto> and yes, I have sent it upstream and to debian which is the same
[13:47] <mok0> Oh great, karmic upgrade  broke my sbuilder :-(
[13:49] <joaopinto> Laney, looking at 447967 or should I subscribe universe sponsors ?
[13:49] <joaopinto> that one is an easy build
[13:49] <joaopinto> it's a text game :P
[13:57] <hyperair> anyone from motu-release here? i'd like to inquire whether i can just upload a snapshot of banshee for the time being, and then get 1.5.1 uploaded post-release?
[13:58] <hyperair> from 1.4.3 to 1.5.0 there are approx 139 bugfixes (grepped the BGO keywords from git log)
[13:58] <hyperair> and from 1.5.0 to date is 84 bugfixes
[13:58] <hyperair> s/is/are/
[13:59] <hyperair> and while they say 1.5.1 is going to be released really soon, they haven't yet and won't give a date.
[13:59] <sistpoty> hyperair: you mean to get 1.5.1 in via an sru?
[14:00] <hyperair> yes
[14:00] <sistpoty> hm...
[14:00] <hyperair> well, i'm not sure whether 1.5.1 is going to arrive before or after karmic
[14:00] <hyperair> if before, then sru not needed, i suppose
[14:01] <sistpoty> directhex: what's your opinion wrt. banshee?
[14:02] <joaopinto> sistpoty, when you have some please check 447967
[14:02] <sistpoty> joaopinto: funny, actually I'm already looking at it ;)
[14:02] <joaopinto> I have a FTBFS for a game that will break the -data dependency rule, is there a proper fix apart from replaceing SourceVersion with an hardcoded version ?
[14:03] <joaopinto> otherwise it would require a -data reupload with the newer version
[14:04] <sistpoty> joaopinto: which one is it?
[14:04] <joaopinto> ceferino
[14:04] <joaopinto> ceferino_0.97.8-2.dsc -> ceferino_0.97.8-2ubuntu1.dsc
[14:05] <joaopinto> hum, maybe I can use UpstreamVersion instead ?
[14:05] <ari-tczew> if you want new upstream, you need open a ffe request
[14:06] <joaopinto> it's not a new upstream version
[14:06] <joaopinto> it's a FTBFS fix, which requires a debian version bump, which breaks the depend rule for -data
[14:09] <joaopinto> I beleive there is an UpstreamVersion macro, which could be a solution
[14:12] <ari-tczew> give bug's number
[14:13] <joaopinto> ari-tczew, bug 447994, but I don't need help with the bug per si, just how to address the -data depend change :)
[14:14] <sistpoty> joaopinto: bombardier uploaded
[14:14] <joaopinto> sistpoty, tks
[14:14] <sistpoty> joaopinto: there should be a macro for the upstream version, let me look
[14:15] <joaopinto> tried ${source:UpstreamVersion}, is not it :\
[14:15] <sistpoty> joaopinto:  source:Upstream-Version
[14:16] <sistpoty> joaopinto: see deb-substvars manpage
[14:16] <joaopinto> ops, was missing the -
[14:18] <joaopinto> erm, wait, I am nuts, -data is also built from this source package
[14:18] <sistpoty> that simplifies things ;)
[14:21] <joaopinto> sistpoty, bug 447994
[14:25]  * sistpoty reads the c++ iso spec to find out if that is indeed a bug in ceferino
[14:30] <joaopinto> bbl
[14:30] <sistpoty> yes, looks like grafico overrides the type name in the declarator list, so a bug in ceferino (at least from my interpretation of the c++ spec)
[15:27] <pkern> sistpoty: Hi.  So there is indeed a file conflict on gnome-audio vs. ubuntu-sounds AFAICS (card_shuffle.wav).  How to proceed from there, considering that ubuntu-sounds is in main whereas gnome-audio is not?
[15:27] <sistpoty> pkern: hm... let me recheck
[15:28] <pkern> sistpoty: https://bugs.edge.launchpad.net/ubuntu/+source/ubuntu-sounds/+bug/343288 fwiw
[15:29] <sistpoty> pkern: indeed didn't see card_shuffle.wav
[15:32] <pkern> sistpoty: Shipping the file in the package would of course also fix the problem, but I guess we don't really want that.  Or reusing a sound file from ubuntu-sounds if there's something suitable.
[15:32] <pkern> sistpoty: However in the long term that should be fixed.  \-:
[15:34] <sistpoty> pkern: I guess the best fix would be to move card_shuffle in ubuntu-sounds to the subdirectory.. though I'm not sure what uses the file and would need to be adjusted
[15:38] <sistpoty> pkern: maybe a dirty hack would be to declares replaces on ubuntu-sounds/gnome-audio w.o. conflicts?
[15:39] <sistpoty> pkern: I guess you could also ask seb128 for directions
[15:40] <pkern> sistpoty: Then it would be semi-random, though, who'll own that file.
[15:40] <sistpoty> pkern: yes, that's why I wrote dirty hack
[15:51]  * sistpoty is off again, cya
[15:59] <pkern> TheMuso: ^^
[16:12] <captivus> Hello.  How do I know if a package I am building will need the .ex and .EX files?
[16:15] <hyperair> erm experience?
[16:15] <hyperair> probably
[16:15] <hyperair> heheh
[16:16] <hyperair> well some of them are documented in comments inside them
[16:19] <captivus> Yes, well I was hoping that there was a comprehensive explanation of the files and their use somewhere, but I can't seem to find one on the wiki
[17:02] <directhex> someone rang?
[17:19] <soc> hi
[17:19] <soc> how can i see which libraries are used by an executabke?
[17:19] <directhex> soc, assuming it's an ELF binary, with "ldd"
[17:20] <Laney> directhex: re: uploading a git snapshot of banshee
[17:20] <soc> ldd /usr/bin/hp-setup
[17:20] <directhex> Laney, then SRU to 151?
[17:20] <Laney> yes
[17:20] <soc> not a dynamic executable
[17:21] <directhex> soc, no, it's not. it's a python script.
[17:21] <soc> ah thanks
[17:22] <directhex> Laney, if we can SRU to 1.5.1, do you think a git snapshot is better than 1.5.0?
[17:22] <Laney> yeah for sure
[17:22] <Laney> I've been running the dailies for ages
[17:23] <directhex> either is better than 1.4.3. i just have a general gut reaction to snapshots
[17:23] <Laney> cody-somerville, jdong: Would you agree in principle to a Karmic SRU from a git snapshot of Banshee to the release if it happens after release?
[17:24] <Laney> I reckon that head currently is pretty much what 151 will be anyway
[17:24] <directhex> i think that's quite possibly the case. mac bugs causing delays, isn't it?
[17:24] <Laney> not sure
[17:25] <jdong> Laney: well I would like to see at that point the diff and also what Ubuntu bugs it'd close, but in principle I see nothing wrong with that
[17:25] <funkyHat> nooo inkscape I need you to work properly -.-
[17:26] <directhex> jdong, can you REJECT something from NEW?
[17:26] <jdong> hahaha I'm not that magical :)
[17:27] <Laney> cool beans
[17:27] <Laney> directhex: yay or nay?
[17:28] <Laney> also, did you do it again?
[17:28] <Laney> hahaha
[17:28] <directhex> Laney, i fixed my dput.cf! on, erm, my office pc. then i did it again at home :(
[17:28] <Laney> amazing
[17:29] <jdong> directhex: HAHAHAHA
[17:29] <directhex> Laney, on a related note, i feel *way* more sleepy & headachey than i did when attacking the archive with bad uploads. so better if you coordinate my "yay" with hyperair
[17:29] <sebner> directhex: you should really hide somewhere
[17:29]  * jdong can totally see the archive admins chasing after directhex with a bat
[17:30] <directhex> jdong, apparently slangasek expects beer. beer is an acceptable penance
[17:35]  * james_w takes his archive admin bat and applies it to clr-wallpapers
[17:35] <james_w> and it is out of here!
[17:35] <directhex> ta james_w
[17:35] <directhex> going to the karmic release party in london?
[17:36] <james_w> I reckon you are just trying to catch someone asleep at the wheel so that it ends up in karmic
[17:36] <james_w> not sure
[17:36] <james_w> I have to head down sometime that week
[17:36] <directhex> 'cos i owe you a beer now
[17:36] <james_w> but we haven't arranged the meeting yet
[17:36] <james_w> hah
[17:36] <james_w> clicking a button != a beer
[17:36] <hyperair> directhex: what?
[17:37] <directhex> hyperair, "yes" to banshee snapshot in karmic, but i'm too headachey to check it
[17:37] <hyperair> ah
[17:37] <hyperair> i see
[17:39] <hyperair> well then i'll work on it
[17:41] <hyperair> so.. first step is to file a bug i suppose... what information should i include? diff (debdiff?), list of bugs it'd fix, what else?
[17:42] <hyperair> also, is there an easy way to get the bug # of a launchpad bug linked to a certain BGO bug#?
[17:42] <hyperair> as in, i have the BGO bug #, and i'd like to get the launchpad bug # linked to it
[17:44] <directhex> i don't know if launchpadlib can search on that
[17:46] <hyperair> hmm
[17:53] <ari-tczew> james_w: could you review again drupal's security bug #431080 ?
[18:59] <LtWorf> hello
[19:00] <LtWorf> i am the debian mantainer of a package, and i was sent here from #ubuntu to ask how could it be inserted in ubuntu's repositories too
[19:01] <azeem> it's a pretty bad time right now because AFAIK the Ubuntu repository is frozen for the 9.10 release
[19:01] <azeem> however, in general you can file a sync request bug I guess and it will be acted upon after release
[19:01] <Laney> we'll get it automatically after Karmic releases
[19:02] <Laney> if it's a new package
[19:02] <mok0> LtWorf: it will be sync'ed automatically for lucid
[19:02] <mok0> LtWorf: no need to do anything
[19:02] <LtWorf> mh ok... i'll try to figure out what a sync request bug is :)
[19:03] <mok0> LtWorf: It's just a bug that says: please sync ... blah blah ... from unstable
[19:03] <mok0> LtWorf: but you only need that after "Debian Import Freeze"
[19:05] <LtWorf> mok0: and what "Debian Import Freeze" is?
[19:05] <azeem> the end of automatic syncs
[19:05] <mok0> right
[19:05] <LtWorf> ok thanks to everybody.. goodbye
[19:06] <mok0> LtWorf: In the beginning of a cycle, there are regular imports of packages from unstable
[19:06] <mok0> Bye :-)
[19:48] <RoAkSoAx> ScottK, ping?
[19:48] <RoAkSoAx> ScottK, could you please take a look to bug #430913
[19:59]  * jdong takes a look
[20:02] <jdong> looks good to me
[20:07] <jdong> RoAkSoAx: sponsored
[20:15] <RoAkSoAx> thanks jdong :)