[00:11] <bcurtiswx_> hey all, im trying to upgrade empathy for lucid since upstream came out with 2.30.3, i got the new source, copied the debian direc over from the pervious one and my debuild -S says it can't find debhelper.mk among other .mk files.  anyone know what i'm doing wrong?
[00:14] <bcurtiswx_> possibly a package i'm missing?
[00:21] <bcurtiswx_> maco, ty
[01:19] <bcurtiswx_> what might stop debdiff from working ?
[01:20] <bcurtiswx_> http://paste.ubuntu.com/483168/
[01:22] <persia> bcurtiswx_, That's very unexpected.  Maybe try a update of that environment, in case there's some odd skew?
[01:23] <steve|m> hi.. does anybody know why the btrfs support for the alternate installer has gone in the current daily image?
[01:24] <bcurtiswx_> persia, you mean upgrade the OS?
[01:25]  * bcurtiswx_ is, anyway
[01:26] <persia> bcurtiswx_, I hadn't meant an upgrade, just an update.  If you're mid-upgrade, then you might have caused skew that would generate that.
[01:26] <bcurtiswx_> persia, I am, <crosses fingers> thx
[01:27] <persia> Aha, then that's it :)  You've swapped the library under devscripts, and apt allowed this because you're doing a larger upgrade.
[01:27] <bcurtiswx_> persia, I mean, i am updating.  It is maverick so <shrugs>
[01:27] <bcurtiswx_> i wasn't mid update.  unless i missed something and needed a -f
[01:28] <bcurtiswx_> but it should take care of it now anyways i believe if that was it
[01:28] <persia> Hrm.  That's a narrower case then.  But yeah, get updated, try again, and if it's still broken, try to narrow when it breaks :)
[01:30] <bcurtiswx_> maybe a --reinstall will help if this doesn't do it
[01:30]  * bcurtiswx_ goes to reboot due to kernel update
[01:34] <bcurtiswx_> which package is debdiff a part of?
[01:35] <bcurtiswx_> ah ha
[01:35]  * bcurtiswx_ learned apt-cache search
[01:35] <persia> dpkg -S is also useful...
[01:36] <bcurtiswx_> persia: would the fact that i'm using debuild -S on maverick trying to upgrade a lucid package cause it?
[01:36]  * bcurtiswx_ still has the debdiff issue
[01:36] <persia> Shouldn't.
[01:37] <persia> Although, depending on the change in the build-deps, and the things that run at source-build-time, you may want to take care with building lucid source packages on maverick.
[01:38] <bcurtiswx_> persia, what do you mean by take care?
[01:40] <persia> For example, if your package runs something in the clean: rule (e.g. copying config.{guess,sub}), and it runs locally on your maverick system, the results may differ from that run on a lucid system, which can potentially affect how a package ends up building on the buildds.  This is rare, but it's worth being sure you know the changes in your tools (especially debhelper, CDBS if you use it, etc.)
[01:41] <bcurtiswx_> Steps done so far: grab tar.gz from debian, rename .orig.tar.gz, unpack, copy debian/ from previous version, i had to remove a patch that faied because I believe its fixed in the changes to the new package,
[01:41] <bcurtiswx_> i've debuild -S successfully, i've pbuilder-dist lucid successfully
[01:41] <bcurtiswx_> i was trying to debdiff for the SRU request, but it doesn't want to work :(
[01:43] <bcurtiswx_> pbuilder-lucid build successfull.. sorry if that was confusing
[01:47]  * bcurtiswx_ will start again, maybe i'll notice something
[01:48] <persia> I wouldn't.  there's no point there, really.
[01:49] <persia> But in general, 1) debdiff isn't very useful for new upstream versions and 2) if you're using a tar.gz from Debian, you'd do better to do a merge, rather than a new upstream upload.
[01:51] <steve|m> okay, http://cdimage.ubuntu.com/daily-live/20100823/ is the last available build with enabled btrfs in the alternate-installer
[01:59] <bcurtiswx_> persia, how would I do a merge?
[01:59] <bcurtiswx_> maybe i know, but didn't know it was a merge
[02:01] <persia> Workflows differ, but the idea is to start from the Debian package for the upstream version you want, and patch it to contain any useful fixes from the Ubuntu package, update the changelog to give appropriate credit for everything, and ensure that you have identified the Ubuntu delta to make it easier for the next merger.
[02:02] <persia> If you use debdiffs, the interesting debdiff is typically that between the Debian version on which you're basing and your proposed version.
[02:02] <persia> You may want to ask in #ubuntu-desktop for more specific instructions, as there are some additional preferred workflow actions for working on empathy.
[02:03] <bcurtiswx_> persia: OK thx
[02:04] <ion> The merge function in a decent VCS may automate a portion of the merge.
[02:07] <persia> Indeed, although it depends on whether one can construct branches that are apparently compatible for merge.
[02:50] <bcurtiswx_> persia, bug #623657
[02:51] <bcurtiswx_> i got debdiff to work somehow
[02:51] <persia> bcurtiswx_, I can't do anything with that, but I'm glad you got debdiff to work.  That said, I find debdiffs of that nature completely useless, and always request folks to upload the new diff.gz instead (although this works less well for Format: 3.0 packages)
[02:52] <persia> My recommendation would be to work with the #ubuntu-desktop folk to update their bzr branches, and seek a sponsor, perhaps by subscribing ~ubuntu-sponsors.
[02:52] <bcurtiswx_> i can do that if needed :) i greatly appreciate your help, thx persia
[02:52] <persia> Best of luck :)
[02:53] <persia> But really, you want to find someone who *can* sponsor this, and put it in the format they prefer, rather than blindly uploading my preferred format.
[02:53] <bcurtiswx_> persia: yup, i will surely need to add/remove/change something, but you've helped me greatly
[03:54] <papertigers> hey does anyone know where I can find the dbus commands for rhythmbox
[03:55] <RAOF> papertigers: Yup!  By installing d-feet and browsing Rhythmbox's dbus entries.
[03:57] <papertigers> RAOF: Thanks!
[03:57] <bcurtiswx_> g'nite all
[03:58] <papertigers> RAOF: gonna release and android app to control rhythmbox :)
[03:58] <RAOF> papertigers: I'd look into mpris, then.
[03:58] <RAOF> That'll cover all the major players in Ubuntu.
[04:00] <papertigers> RAOF: but then how could I connect to it? If I make a rhythmbox plugin I can create a socket for local wifi control
[04:01] <RAOF> Hm.  There's a control protocol… DACP (and Apple's extensions to it which drive iTunes)?  From memory there's a GSoC implementing it in Rhythmbox.
[04:04] <papertigers> RAOF: hmm wonder if that would be better
[04:10] <papertigers> RAOF: looks like a guy is working on DACP for rhythmbox and has applied to get a patch approved
[04:10] <RAOF> There's your winner.
[04:13] <papertigers> RAOF: well its a waiting game for it to get included
[04:20] <johanbr> papertigers, you could also use DLNA
[04:21] <johanbr> http://coherence.beebits.net/wiki/RhythmBox
[04:22] <papertigers> johanbr: thanks Ill look at this
[04:23] <papertigers> johanbr: I am just playing around right now, but do you know if in my plugin I create a socket
[04:23] <papertigers> will it stay open as long as rhythmbox is open
[04:24] <johanbr> I believe so, not sure though
[04:29] <cjwatson> steve|m: btrfs support hasn't been deliberately removed.  file a bug on the debian-installer package in Ubuntu with your logs
[04:30] <cjwatson> (please)
[06:53] <idlogin> how would one resize and ext4 partition? is it possible live? for a non-lvm system?
[06:53] <idlogin> by live i mean online while i'm running it
[07:08] <RAOF> That's not really a question for #ubuntu-devel, and you can increase (but not decrese) the size of an ext4 filesystem live, but not (easily?) the partition it's on.
[07:28] <pitti> Good morning
[07:30] <micahg> good morning pitti :)
[07:31] <pitti> hey micahg, how are you?
[07:31] <micahg> pitti: good, and you
[07:31] <pitti> I'm great, thanks
[08:09] <micahg> pitti: BTW, I took care of the ubufox upload for you and asac
[08:09] <pitti> ah, thanks
[08:17] <dholbach> good morning
[08:19] <ion> hi
[08:47] <ari-tczew> pitti: please upload package also to jaunty and karmic - bug 393923
[08:47] <pitti> ari-tczew: see my question on the bug -- this doesn't look like the kind of thing that we should fix in jaunty now IMHO
[08:49] <ari-tczew> pitti: listen, someone reported the bug, give the patch for fix, so someone is waiting for resolve problem. I spent time on this, so I look forward for upload.
[08:50] <persia> Still needs a rationale on the bug, regardless of the final decision.
[08:50] <pitti> we have an SRU policy for a reason, though
[08:51] <pitti> we already stretch the scope of SRUs quite high for lucid, with it being an LTS and still pretty fresh and all that
[08:51] <pitti> but for jaunty we don't get a lot of testing any more, so chances of getting regression reports are very close to 0
[08:51] <pitti> and this isn't a data loss/security/etc. class of thing
[08:51] <ari-tczew> pitti: I tested package and it works
[08:52] <ari-tczew> pitti: what about karmic? it's freshly than jaunty
[08:52] <pitti> ari-tczew: I can be talked into karmic, although it's also outside the SRU criteria
[08:53] <pitti> and once LP starts working again for me, I'll continue SRU stuff
[08:53] <ari-tczew> pitti: do you know, that this is funny?
[08:53] <pitti> seems it broke for me some minutes ago, pages are utterly distorted
[08:54] <wgrant> pitti: edge update broke CSS. Fix in progress.
[08:55] <wgrant> Should be fixed in a few minutes, otherwise use production.
[08:55] <pitti> wgrant: hm, but I disabled edge redirect already
[08:55]  * pitti tries again
[08:55] <pitti> wgrant: thanks
[08:55] <pitti> ah, production works now
[08:55] <geser> how many +1 does a MIR need? one or more?
[08:55] <wgrant> production should never have been broken.
[08:56] <pitti> geser: one
[08:56] <geser> then what's the next step for bug 614000?
[08:57] <ari-tczew> pitti: more important developers want to see bug fixing, so I'm doing this. when I prepare patches, then I got information - sorry, SRU is not necessary. this is comedy.
[08:57] <ari-tczew> and again I wasted my time
[08:57] <pitti> ari-tczew: no, it's not comedy, it's how stuff works, sorry
[08:58] <Chipzz> ari-tczew: there's an SRU policy for good reasons
[08:58] <pitti> ari-tczew: there's always a nonzero regression potential, just look at the wxwidgets disaster from yesterday
[08:58] <pitti> which was a no-change rebuild
[08:59] <wgrant> pitti: Fixed now.
[08:59] <pitti> those rules weren't made out of thin air, we learned them the really hard way
[08:59] <pitti> wgrant: cheers
[08:59] <pitti> ari-tczew: and your work wasn't wasted -- after all, it does get fixed at least in lucid
[09:00] <ari-tczew> pitti: wow! but I spent 4 hours for adjusting patch to karmic and jaunty
[09:00] <Chipzz> pitti: otoh, if it was broken before, a patch to fix it can hardly make it worse ;)
[09:01] <pitti> Chipzz: well, that's pretty much what I was asking for -- a rationale why it needs to/should be fixed in jaunty/karmic
[09:01] <Chipzz> ari-tczew: 4 hours? seriously? how does adding 2 lines to file take up 4 hours? :)
[09:01] <pitti> Chipzz: it's not at all clear to me that the package is entirely broken -- it might work for other use cases than the one in the bug
[09:01] <persia> Chipzz, But the "package is completely broken" rationale for SRU was dropped in the most recent policy update (likely due to painful experience).
[09:01] <pitti> and I can't know the details of all packages
[09:02] <pitti> so if someone explains that the jaunty package is totally useless, then the regression potential is 0
[09:02] <ari-tczew> Chipzz: you didn't working on it, so please hold on - saying culturally
[09:02] <maco> persia: does "it ftbfs anyway" still count?
[09:02]  * pitti points out that he didn't say "no way" in the bug, but "why?"
[09:02] <Chipzz> maco: except it doesn't (I think)?
[09:03] <maco> Chipzz: im just asking for future reference, not related to your thing
[09:03] <persia> maco, Last time I read the page (a rew minutes ago), FTBFS was listed, but "completely broken" was gone.  I haven't been following SRU policy changes closely though.
[09:03] <Chipzz> maco: ari-tczew' thing, not mine :)
[09:03]  * persia cheers pitti for requesting rationales, so people *understand* why they get updates.
[09:03] <ari-tczew> pitti: could you update SRU policy in wiki including text: ok, please working on bugs, this is very important, but your patch won't be accepted, because SRU is unecessary
[09:04] <ari-tczew> pitti: enough reason for me is someone is waiting for this
[09:04] <ari-tczew> and you can see this in bug
[09:04] <Chipzz> ari-tczew: why are they waiting for a fix in an ubuntu release that's neither LTS  nor up to date?
[09:05] <pitti> ari-tczew: the SRU policy already points out very clearly when to do an SRU; also, please read what I just said
[09:05] <maco> persia: now i wonder how "completely broken" was defined, because ftbfs was my definition
[09:05] <ari-tczew> Chipzz: I don't know. I only want help.
[09:05] <Laney> while we're on SRUs, could 539814 be sponsored/accepted? :)
[09:05] <pitti> ari-tczew: I asked for a rationale and a regression potential analysis on the bug, I didn't say "no" outright
[09:05] <pitti> maco: no, FTBFS is far from "completely broken" -- the archive will have the previous binaries
[09:06] <directhex> i don't think that's ever useful. if it can't be built, how can people exercise their right to modify it?
[09:06] <maco> pitti: mmm i was thinking "if it doesnt even build, you cant make it any worse"
[09:06] <pitti> maco: oh, sure you can :)
[09:06] <pitti> directhex: well, obviously it is a problem
[09:07] <pitti> but saying that fixing an FTBFS will never cause regressions is wrong
[09:07] <persia> maco, Completely broken used to include stuff like fails-to-run, due to incomplete library transition, etc.  I think the lucid-supportibility spec just removed all the binary packages we didn't know about it, so the number of fails-to-work packages ought be fairly small now.
[09:08] <directhex> anyone in the mood for a security fix? hot off the presses
[09:08] <ari-tczew> pitti: okay, well done. you fine demotivated me. I won't prepare any SRU anymore. it's non-sense.
[09:09] <pitti> ari-tczew: frankly, I don't quite understand your reaction
[09:09] <pitti> ari-tczew: but if you can't give me an answer about an SRU rationale, but instead just act grumpy, I can't help it, I'm afraid :/
[09:10] <pitti> I can't know the details about all 25000 packages in the archive, so the SRU team needs to have information like that
[09:11] <ari-tczew> pitti: because this is frustrated, when I know that patch works and won't go.
[09:11] <pitti> ari-tczew: it's in your hands to make it go
[09:13] <diwic> ari-tczew, the bureaucracy around making a patch go in can be frustrating sometimes, I've been there a few times myself
[09:15] <diwic> ari-tczew, but people on the other side have been burned many times by letting patches in that cause regressions, and so they come up with rules which are meant to minimize that risk
[09:16] <ari-tczew> diwic: ok, so let's don't making any SRUs. risk will be zero !
[09:16] <diwic> ari-tczew, those rules are not perfect and probably won't ever be.
[09:21] <seb128> there is plenty of SRU done each cycles
[09:21] <seb128> it's not hard to do those, you just need to justify the need for change and describe how to test
[09:21] <pitti> if you can't explain why an SRU should be done, and what can possibly go wrong, we won't do it
[09:21] <seb128> it's a reasonable requirement
[09:22] <diwic> ari-tczew, so if you were in pitti's shoes right now, what can you tell him about your patch that makes him reasonably sure that your patch won't cause regressions?
[09:23] <ari-tczew> pitti: bug updated. bug 393923
[09:23] <dholbach> maybe we could put a few good sru examples on the sru wiki page to illustrate what's required?
[09:23] <pitti> dholbach: https://wiki.ubuntu.com/StableReleaseUpdates#Examples
[09:24] <dholbach> pitti, oops :)
[09:24] <vish> dholbach: we have two examples already :)
[09:24] <vish> pff, pitti is too fast ;p
[09:39] <mvo> bdmurray: could you please add glatzor to the group so that he can manipulate bugs in aptdaemon? he is upstream, iirc he just needs to be added to the bug-control tream, right?
[09:45] <ari-tczew> pitti: so what's the final conclusion from your comment? yes or not?
[09:46] <pitti> ari-tczew: still waiting for an answer to https://bugs.edge.launchpad.net/ubuntu/+source/agg/+bug/393923/comments/12
[09:46] <maco> hahaha i remember that one
[09:46]  * pitti glares at ubottu -- "this is not the bug you are looking for"
[09:47] <maco> yeah....
[09:48] <maco> i reported a "ktouch lessons include things that arent really words" one before too...i think its not allocating space for the null byte.... should fix that at some point
[09:54] <ari-tczew> by the way - why developers don't respect rules with merging? current apt update -   * merged from debian/unstable
[09:54] <ari-tczew> where is rest?
[09:55] <dholbach> mvo, ^ you're fired!
[10:14] <baptistemm> hi there
[10:15] <baptistemm> I submitted a patch for lucid-proposed, and the ia64 build fails https://edge.launchpad.net/ubuntu/+source/collectd/4.8.2-1ubuntu0.1/+build/1933596 . is it something related to my patch ?
[10:15] <persia> baptistemm, Hey.  I think you'll find there was some toolchain change between http://launchpadlibrarian.net/38028946/buildlog_ubuntu-lucid-ia64.collectd_4.8.2-1_FULLYBUILT.txt.gz and http://launchpadlibrarian.net/54344381/buildlog_ubuntu-lucid-ia64.collectd_4.8.2-1ubuntu0.1_FAILEDTOBUILD.txt.gz : you can disable -fstack-protector globally for the build on ia64, *OR* (better) track down the toolchain change, and troubleshoot how to fix it (this
[10:15] <persia> may require ia64 hardware)
[10:16] <baptistemm> hi persia
[10:29] <ari-tczew> pitti: answered in agg bug
[10:43] <vish> dholbach:  before you do that, can we first take some tissue samples to clone mvo first? ;)
[11:46] <ari-tczew> vish: did you mean issue instead tissue?
[11:49] <vish> ari-tczew: nah, real flesh-n-blood , gives us better clone quality! ;p
[11:50] <ari-tczew> vish: sorry, I'm not in the context
[11:51] <vish> ari-tczew: nvm, it was just a follow up to dholbach's comment.
[11:51]  * vish silent mode :)
[12:08] <ara> pitti, hi
[12:08] <ara> pitti, how can I bypass the "not a genuine ubuntu package" when testing an apport hook?
[12:08] <ara> (I promise to not filing the bug) :D
[12:13] <pitti> ara: set report['CrashDb'] = 'ubuntu' in your package hook (temporarily)
[12:14] <pitti> ara: sorry, 'CrashDB'
[12:14] <ara> pitti, thanks!
[12:14] <pitti> (upper case 'B')
[14:02] <ogra> cjwatson, hmm, your dropping of -marm in busybox seems to have removed the ability to reboot from initrd prompt
[14:03] <cjwatson> ogra: if you can debug it, I'd welcome it.  feel free to put -marm back if need be, but be sure to add a detailed changelog comment so that we know what to look for the next time we try to drop that delta
[14:04] <cjwatson> the changelog entry just said "Using -marm due to gcc thumb2 compile issue", and the linked bug wasn't much more informative.  There's a serious problem with changelog entries like that ...
[14:04] <ogra> at least i suspect its busybox, the other explanation i would have would be a kernel change, but we see it on both omap3 and 4 and they are different kernel versions
[14:30] <ari-tczew> pitti: around?
[14:40] <mathiaz> SpamapS: hi!
[14:41] <mathiaz> SpamapS: what was the outcome of the php5-sybase discussion?
[14:44] <Adri2000> doko: in bug #623267, are you saying that bug #570147 got fixed? also, I'm not sure of the link in the bug description: it points to a french forum thread, not to an ooo bug report
[14:47] <doko> Adri2000: yes, that should be the bug from the forum
[14:48] <ScottK> doko: python/python3-defaults are done.
[14:48] <Adri2000> doko:  the forum thread lists some issues with OOo in lucid, but it doesn't specifically talk about the translation issue and doesn't seem to mention it at all actually
[14:49] <doko> Adri2000: it's one of the issues afaiu
[14:59] <ScottK> pitti: It looks like codeblocks should be on the rebuild list for the wx issue: See bug 623989
[14:59] <ScottK> ttx, jibel: ^^^
[15:01] <jibel> ScottK, I'm testing codeblocks in lucid.
[15:02] <ScottK> jibel: Would you please comment in the bug and reassign it to codeblocks then.
[15:02] <jibel> ScottK, sure.
[15:03] <ScottK> Thanks.
[15:08] <Daviey> cjwatson, Has "d-i apt-setup/local0/repository" changed?  Adding a local repo, doesn't seem to working anymore :(
[15:09] <Daviey> or am i be a numnut?
[15:09] <pitti> ari-tczew: hello (sorry, in meeting, but I responded to the bug some minutes ago)
[15:10] <pitti> ScottK, jibel: ah, want me to do a rebuild then?
[15:11] <cjwatson> Daviey: not aware of any changes there
[15:12] <Daviey> cjwatson, , thanks
[15:12] <ScottK> pitti: I'd say let's wait to hear the results of jibel's testing, but probably.
[15:13] <pitti> ... and this time with a Breaks: (thanks slangasek for pointing out)
[15:13] <jibel> ScottK, I cannot reproduce with wxwidget in -release or -updates and codeblocks has not changed since the release of lucid
[15:13] <ScottK> jibel: Right, but wx has.
[15:14] <ScottK> jibel: You're sure it was using 2.8 when you were testing, right?
[15:14]  * jibel checking again.
[15:14] <ari-tczew> pitti: OK, tested, works fine. so jaunty won't go?
[15:17] <Daviey> cjwatson, Scrub what i said.. is working ;)
[15:23] <ari-tczew> pitti: so in current SRU policy, ubuntu-sru is deprecated?
[15:31] <jibel> ScottK, I really cannot reproduce.  tests done with wxwidget2.8 in lucid and -proposed, codeblocks without then with codeblocks-contrib.  Could it be a specific codeblocks plugin ?
[15:34] <ScottK> jibel: It may be arch specific.  I'd ask the reporter what arch they are using.
[15:35] <pitti> ari-tczew: deprecated how? (it's not -- it's the team who reviews/handles all SRUs)
[15:57] <ari-tczew> pitti: because now sponsors are uploading SRU patches. then is test and if it's fine, then you are moving to -updates. I don't see work for ubuntu-sru.
[15:59] <pitti> while ~ubuntu-sru also has been sponsoring packages, it's not their main role; that is to review the queues and patches, follow up on discussions, regressions and coordinate moving to -updates
[16:05] <jdstrand> mvo: hi!
[16:05] <mvo> hey jdstrand
[16:06] <jdstrand> mvo: I wanted to bring your attention to bug #614589
[16:07] <jdstrand> mvo: it is fairly annoying, and it breaks several scripts the security team has. I imagine it affects others too. It isn't a 'drop everything' and fix now bug cause I know you are busy and we can work around it. but I wanted to make sure you saw it
[16:09] <SpamapS> mathiaz: php5-sybase stays. As slangasek pointed out, its probably easier for us to find a sybase server if we ever need one, than to maintain a massive delta w/ debian. ;)
[16:10] <mathiaz> SpamapS: ok - thanks for the summary
[16:10] <mvo> jdstrand: thanks, I have a look
[16:10] <jdstrand> mvo: thanks! :) did you have a nice vacation?
[16:11] <mvo> jdstrand: yes, *very* nice. just ended too early ;)
[16:12] <jdstrand> mvo: glad you enjoyed it, and glad to have you back, even if it was earlier than you might have liked :)
[16:16] <mvo> jdstrand: :)
[16:16] <mterry> pitti, how bad are multiple shared libraries in one binary package?  I'm looking at a MIR that has such, but not sure how much of a stickler about it I should be.
[16:19] <Chipaca> mvo: ping
[16:19] <mvo> Chipaca: hello
[16:19] <pitti> mterry: at least bad enough to require further justification
[16:20] <pitti> mterry: we have some special cases, if they all share the exact same SONAME and are always bumped together, it's ok
[16:20] <pitti> mterry: but if it's different SONAMEs, then it's a major bug
[16:21] <mterry> pitti, like, 4/5 are SONAME 2, one is SONAME 1
[16:21] <mterry> pitti, apparently the MIR submitter talked to Debian maintainers and they weren't sold on unbundling.  Will try to find out why
[16:21] <pitti> mterry: then that package deserves to get shot in the head and removed from the archive; definitively a MIR blocker
[16:21] <pitti> (IMO)
[16:22] <mterry> pitti, OK, good.  I don't like wielding MIR blockage power, so good to get confirmation that bundled libs suck
[16:22] <pitti> it's a disaster waiting to happen whenever the ABI changes
[16:40] <ScottK> jibel: Thanks for following up on codeblocks.
[16:45] <papertigers> Hey guys I am writing an android app to control rhythmbox, I have a rb plugin i wrote that starts the server.  Anyone know if I can get a list of all artists from dbus ?
[16:52] <mathiaz> james_w: hi!
[16:52] <mathiaz> james_w: is there a reason why the puppet pkg branch hasn't been imported yet?
[16:52] <mathiaz> james_w: there is a new version in the archive, however puppet doesn't show up on http://package-import.ubuntu.com/status/#stats
[16:53] <mathiaz> james_w: and the puppet pkg branch is not up-to-date
[16:56] <james_w> mathiaz: hmm, it looks like lp is refusing to tell us about that new version
[16:58] <mathiaz> james_w: that's ... not nice of LP :/
[16:59] <fta> micahg, hi, you missed a bunch of emails from me in the last few hours. someone apparently decided it was a good idea to make a package add the hostname to 127.0.0.1 in /etc/hosts, leading my SMTP servers to send emails with localhost.localdomain as FROM (in the SMTP envelope). this is plain wrong
[17:00] <fta> not sure which package did that though
[17:02] <Chipzz> papertigers: this is not the channel for these kind of questions, pls refer to the topic
[17:10] <james_w> mathiaz: I don't know what happened, but somehow we missed the creation of the publication record. This shouldn't happen unless LP's clock jumps backwards.
[17:11] <james_w> mathiaz: I'm going to make it more robust against that, and ask it to import puppet now. Please let me know if you see this again and I will look again for ways we can miss the publication of something.
[17:12] <mathiaz> james_w: great - thanks for following up!
[17:26] <micahg> ari-tcz
[17:26] <micahg> oops
[17:26] <ari-tczew> micahg: hm?
[17:26] <micahg> ari-tczew: sorry, wrong field
[17:27] <ari-tczew> yhym ok
[17:41] <james_w> mathiaz: now up to date
[18:11] <lanoxx> mvo, are you there?
[18:12] <mvo> lanoxx: yes
[18:13] <lanoxx> mvo, could you add "Christian Klein" to the commit messages of my xdg fixes? after all parts of my patch are from his branch
[18:14] <lanoxx> mvo, or do you think thats unneccessary given the size of the patch?
[18:18] <mvo> lanoxx: thanks, I will do that
[18:19] <mvo> lanoxx: its always good to give credit, even if its a small change
[18:19] <mvo> lanoxx: so thanks for this reminder :)
[18:19] <mvo>   * updated to use xdg config dirs (thanks to Christian Klein)
[18:19] <mvo> ^--- good?
[18:19] <lanoxx> mvo, yeah i thought so, and you can drop his branch after wards, or mark it was obsolete, i didnt have the right to do that
[18:19] <lanoxx> sure
[18:21] <vlada> hi ppl. I might be at the wrong place, but counting on you to redirect me ;) How can I debug indicator applet thing. There is a bug nobody pays much attention, so I'm guessing not many experience it. I'd like to redirect debug output to terminal. Is there a way to do that?
[18:21] <lanoxx> mvo, https://code.launchpad.net/~cristiklein/update-notifier/use-xdg-folders/+merge/15038 <-- currently the branch is still set to: needs review, but i cant change that
[18:22] <mvo> lanoxx: I set it to "merged" now
[18:22] <vlada> https://bugs.launchpad.net/ubuntu/+source/indicator-applet/+bug/621838 to be precise!
[18:23] <SpamapS> vlada: you can attach the debugger (gdb) to any running process, though in Maverick you'll need to either be root or enable a sysctl to do that.
[18:23] <lanoxx> mvo, great, im looking forward to write some more xdg-patches, thank for taking the time and mergin my patches :)
[18:23] <mvo> lanoxx: thank you for writing them in the first place :)
[18:24] <lanoxx> mvo, not at all, is this going to land in maverick?
[18:25] <dobey> any python packaging gurus around?
[18:26] <dobey> pysupport seems to only be setting up the stuff in /usr/share/pyshared for me, in a package that also has a .so in /usr/lib/pyshared :-/
[18:26] <dobey> wondering what i'm doing wrong (since pycairo seems to work ok)
[18:26] <mvo> lanoxx: yes
[18:26] <SpamapS> dobey: I believe pysupport is deprecated
[18:26] <SpamapS> but I could be confusing it with pycentral
[18:26] <SpamapS> or dh_python
[18:26] <dobey> pycentral is deprecated afaik
[18:27] <vlada> SpamapS, hi. and hmmm. Applet doesn't really crash. Not sure my gdb skills are that good to trace running process execution.
[18:27] <jcastro> vlada: find someone in #ayatana, they can help you with indicators
[18:27] <dobey> which is why i'm trying to move stuff over to pysupport
[18:27] <jcastro> vlada: I think there's a debugging tool somewhere but they will know for sure
[18:27] <SpamapS> vlada: gdb -p 12345      where 12345 is the pid of the process running your applet.
[18:28] <SpamapS> dobey: I believe there's a new kid in town, dh_python2, that is supposed to be "the one ring to bind them all"
[18:28] <SpamapS> dobey: but, I'm a python packaging novice
[18:28] <lamont> doko: pycentral or pysupport is deprecated?
[18:28] <SpamapS> dobey: #debian-python on OFTC is full of python packaging wizards.
[18:29] <vlada> great! thanks both of you
[18:29] <doko> lamont: dh_python[23] is the future
[18:29] <lamont> doko: meaning both support and central are to be shunned?
[18:29] <dobey> boo
[18:29] <doko> lamont: I only can speak for one ...
[18:29] <SpamapS> vlada: if you haven't also tried 'strace' and 'ltrace', they're useful when you're not quite sure what it is the thing is doing.
[18:30] <dobey> and i was recently told to use pysupport instead of pycentral
[18:30] <dobey> but i somehow doubt that just switching to use dh_python2 is going to fix my problem
[18:31] <SpamapS> dobey: I also made a package about 3 months ago and used pysupport, without knowing that dy_python2 existed.
[18:31] <SpamapS> dobey: actually I'm using pysupport and my .so is copied into the right place just fine
[18:32] <dobey> my problem is not that the package doesn't include the files, it's that pysupport is only creating symlinks for the .py files during postinst
[18:32] <dobey> (this is an automake based package, and not setup.py)
[18:33] <dobey> but i'm at a bit of a loss as to why
[18:34] <SpamapS> ah.. setup.py seems to be the generally accepted way to distribute/package python apps/libs .. never would have thought to use pure automake.
[18:38] <dobey> well it's a c/gtk+ based lib, with python/mono bindings
[18:39] <dobey> (and if it were up to me, nobody would use setup.py) :)
[18:39] <SpamapS> Heh.. the gearman-interface package builds python libs from swig interface files.. it also builds a setup.py ;)
[18:40] <SpamapS> setup.py is just a nice uniform way to distribute apps.. just like automake..
[18:40] <dobey> i know what setup.py does, is capable of, etc...
[18:41] <SpamapS> But you don't like it?
[18:41] <dobey> no
[18:41] <SpamapS> Got a grudge against pypi?
[18:41] <dobey> no
[18:42] <SpamapS> alrighty then... err.. how 'bout them Meerkats?
[18:42] <dobey> it's fine for shipping simple python scripts and modules
[18:42] <dobey> it sucks for real apps that have config files, data, etc...
[18:43] <dobey> and i don't have time to fix it
[18:43] <dobey> but that doesn't tell me why pysupport isn't working as expected
[18:44] <SpamapS> dobey: maybe it relies too heavily on setup.py .. dh_python2 seems to have a lot more options.
[18:48] <highvoltage> Anyone have some trouble booting dailies? Edubuntu doesn't boot properly currently
[18:49] <cjwatson> highvoltage: have you checked the build logs to see whether it's actually building?  I've seen a lot of build failure mails from Edubuntu, but not really looked into the reasons
[18:49] <highvoltage> cjwatson: I did indeed, nothing stands out
[18:49] <cjwatson> doko: is it safe to convert to dh_python2 right now in unstable?  looking for some sort of policy guidance to tell me whether I've got it all right ...
[18:49] <highvoltage> the previous build problems earlier this week has been fixed at least
[18:51] <highvoltage> cjwatson: btw, it might be nice if those build logs could be gzipped when they are written, I'm just saying :)
[18:53] <dobey> SpamapS: i don't think that's true
[18:53] <highvoltage> cjwatson: hmm, I guess this could be a problem?
[18:53] <highvoltage> ls: cannot access /build/chroot-livecd/usr/sbin/mkinitrd.livecd: No such file or directory
[18:53] <SpamapS> dobey: bummer. ;)
[18:54] <cjwatson> highvoltage: url for that log?
[18:54] <highvoltage> cjwatson: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/edubuntu-dvd/20100825/livecd-20100825-i386.out
[18:54] <cjwatson> (the build log publishing is held together with wet string, I don't want to stretch it too much!)
[18:54] <highvoltage> heh :)
[18:55] <cjwatson> I don't think that message is a problem.  in what way does it fail to boot?
[18:55] <highvoltage> I get busybox
[18:56] <cjwatson> is this on a live-style boot?
[18:56] <highvoltage> yes
[18:56] <cjwatson> ok, I'll see if it reproduces on a desktop CD
[18:57] <highvoltage> I'll try to quiet plymouth or check for logs from inside busybox in the meantime
[18:59] <highvoltage> well what do you know... with plymouth disabled it boots just fine
[19:00] <doko> cjwatson: for packages managed by pycentral, it should be safe. the location doesn't change
[19:18] <highvoltage> cjwatson: it seems like it's intermittent, seems to boot fine now with plymouth enabled
[19:32]  * highvoltage guesses that pybootchartgui is something new