[00:02] <st33med> Well, I am looking to help
[00:14] <st33med> Laney, hmm, what about this bug
[00:14] <st33med> bug 343979
[00:14] <st33med> Help me learn with that?
[00:36] <nhandler> st33med: That bug is a duplicate
[00:37] <st33med> nhandler, yeah, thanks for the update
[01:09] <ryanakca> If I only have one binary package (produced by the source package), and it has ``Architecture: all'', do I need Build-Depends? Or can they all go in Build-Depends-Indep?
[01:18] <Ryan52> ryanakca: you need Build-Depends for the things needed for the clean target.
[01:18] <Ryan52> so probably cdbs, debhelper, &c.
[01:20] <ryanakca> Ryan52: So, http://pastebin.com/f2f604696 is fine?
[01:24] <Ryan52> maybe? :P
[01:24] <Ryan52> looks okay. I dunno about cmake or python packaging, tho.
[01:25] <ryanakca> Ok, thanks
[01:28] <st33med> So uh...
[01:29] <st33med> I am a new-ish Ubuntu Member looking to help in Python areas for Jaunty
[03:06] <TomJaeger> Could someone upload the updated thinkfinger package attached to bug #311732 ?
[03:06] <TomJaeger> Thinkfinger doesn't currently work on jaunty.  Thank you.
[03:25] <stgraber> TomJaeger: is there a way you can provide a debdiff with only the needed changes ? the .diff.gz I saw on that bug report seems huge
[03:26] <stgraber> stgraber@sahal:~/code/thinkfinger$ debdiff thinkfinger_0.3+r118-0ubuntu3.dsc thinkfinger_0.3+r118-0ubuntu4.dsc | wc -l
[03:27] <stgraber> 7438
[03:27] <stgraber> TomJaeger: that's a lot more than it should for a bugfix
[03:27] <TomJaeger> stgraber, The version that's currently in ubuntu contains all sorts of junk files that have been deleted
[03:29] <TomJaeger> Check out the diffstat
[03:29] <TomJaeger>  61 files changed, 21 insertions(+), 7123 deletions(-)
[03:31] <TomJaeger> As far as I understand it, a .debdiff can't represent deletion of files, that's why I posted the .diff.gz
[03:32] <stgraber> What's the package like in Debian ? our general goal is to avoid unnecessary delta with Debian as it'll only make it harder for the next release (having to merge the changes) ?
[03:35] <TomJaeger> I think we already diverged.  Debian's not going to have the fixes, though, since we're on a newer kernel.
[03:37] <TomJaeger> stgraber, http://packages.debian.org/changelogs/pool/main/t/thinkfinger/thinkfinger_0.3+rev118.2-4/changelog
[03:55] <ScottK> TomJaeger: At this point in the release cycle 'cleaning up the package' is not something we want.  We want to limit changes to minimally invasive ways to fix problems.
[03:58] <TomJaeger> ScottK, these are .svn files and leftover dependencies files, they won't affect the package in any way.
[03:59] <ScottK> They don't particulalry hurt to leave them either.
[04:00] <TomJaeger> It'd probably take me at least 10 minutes to put them all back in and prepare a new .debdiff
[04:00]  * ScottK is just off to bed, so not in a sponsoring mood.  Take my advice for what you will.
[04:04] <TomJaeger> I really don't have time for this kind of busywork right now.  So it's either the package I posted, or someone else will have to put the junk back in, or we won't have a working thinkfinger package in jaunty.
[04:06] <fabrice_sp__> TomJaeger, why don't just just redownload he original package, apply your diff, and reget the debdiff?
[04:06] <fabrice_sp__> debdiff would ignore deletion
[04:08] <TomJaeger> No, the debdiff will represent deletion as removing the content of the files.
[04:09] <TomJaeger> Anyway, my standpoint is that my time is too valuable for these kind of antics.
[04:10] <rgreening> TomJaeger: I dont see this as antics. sry you feel that way
[04:11] <rgreening> during freeze, we need to minomize changes.
[04:11] <rgreening> minimize even
[04:11] <rgreening> it's more of a 'cover your butt' scenario :P
[04:11] <TomJaeger> Since the deleted files don't affect the package build in any way, there's no change
[04:12] <ScottK> TomJaeger: And no file deletion ever had an inadvertent effect?
[04:12] <rgreening> And I agree thazt that clean-up should get done after freeze
[04:13] <rgreening> It's easier to 'oops' when you have 7000 lines to review in changes.
[04:13]  * ScottK decides to quit arguing and play killbots instead.
[04:14] <TomJaeger> ScottK, the deletion of .svn directories? please
[04:15] <TomJaeger> rgreening, geany is really nice to review diffs
[04:15] <rgreening> TomJaeger, in the time you spent arguing over this, you could have made the changes requested by the sponsor.
[04:15] <rgreening> :)
[04:15] <rgreening> just to be facitious :P
[04:15]  * rgreening ducks
[04:16] <TomJaeger> the thing is, I've already made up my mind.  I'm not going to make the changes
[04:16] <rgreening> oh well....
[04:17] <TomJaeger> I'd argue that it's much more likely that I'd screw up re-adding those files than that the deletion causes a regression.
[04:20] <wgrant> We need to ensure that diffs are easy to review.
[04:20] <wgrant> We really do not want to break things at this point.
[04:20] <TomJaeger> there are easy to review for anyone who's ever heard of diffstat
[04:20] <TomJaeger> thinkfinger is _completely broken_ at this point anyway
[04:21] <wgrant> Even if I use diffstat, I have to work out which files are actually entirely gone and which aren't and blah blah blah.
[04:21] <wgrant> With a proper diff, I can just glance at it and see that it's not doing anything stupid.
[04:22] <rgreening> TomJaeger: wheres your debdiff and bug report
[04:22] <TomJaeger> bug #311732
[04:24] <rgreening> hmm.. reading this looks like simply getting a clean package via apt-get source and grabbing the patch from the kernel bug is easy enough.
[04:25] <TomJaeger> There's quite a few fixes in that package, not just that one that the bug is about
[04:26] <rgreening> oh, then you probably should file a seperate bug report asking for the update and all your changelog entries for every single change will need to be documented to get accepted.
[04:27] <TomJaeger> There are bugs filed for all of them
[04:27] <rgreening> Having accurate changelog entries is a critical part of updating any package
[04:27] <TomJaeger> Did you even look at the changelog?
[04:28] <TomJaeger> comment #19
[04:30] <bdrung> ScottK: https://bugs.launchpad.net/bugs/340435
[04:32] <rgreening> TomJaeger: yes I read it. And yes I saw the changelog entry and my comment stands. You don't meantion zapping the changelog entries which differs from upstream.
[04:32] <rgreening> for one
[04:32] <TomJaeger> zapping the changelog entries?
[04:32] <rgreening> anyway, a debdiff would be nice.
[04:35] <ScottK> bdrung: It's not bug fix only.
[04:35] <ScottK> asac: I thought we agreed you weren't going to shove unsupported Firefox versions in Universe anymore?
[04:35] <ScottK> asac: Does mozillateam intend to support Firefox-3.1 though the life of Jaunty?
[04:36] <TomJaeger> rgreening, posted a .debdiff
[04:36] <rgreening> TomJaeger: Let me have a peek
[04:36] <fabrice_sp> ScottK, did you had time to have a look at Bug #343851
[04:36] <fabrice_sp> ?
[04:36] <ScottK> fabrice_sp: I did.  I'm uncertain how to tell if you fixed the FTBFS since the previous version works in a PPA.
[04:37] <ScottK> fabrice_sp: I'm considering maybe this is a packagebinarymangler bug.
[04:38] <fabrice_sp> ScottK, I far I understand this package, in each binary, it's trying to check and create debian/stamp/binary if not exist. I could happen that it enters at the same time in the condition and try to create it
[04:38] <fabrice_sp> by moving the creation outside of the binaries target, it should work
[04:38] <ScottK> OK.   I didn't have more to do than toss it at my PPA.
[04:38] <ScottK> have time to do more than ...
[04:39] <fabrice_sp> I think build machines are too fast :-)
[04:39] <fabrice_sp> are the ppa ones slower?
[04:41] <bdrung> ScottK: updated bug title. something missing?
[04:48] <rgreening> TomJaeger: ok, so you definately have something funky in the diff. At one point the thinkfinger.orig is the first entry and sometimes the second, which leads me to believe you cat'd these together. not such a big deal, but does make it easy for you to remove the .svn parts which all apear at the beginning.
[04:48] <rgreening> :)
[04:49] <rgreening> TomJaeger: and it appears you made changes directly in the source rather than via patching
[04:50] <TomJaeger> The debdiff was created using the debdiff command from the two .dsc files
[04:51] <XiXaQ> is there any way to get a list of completely new packages in one distro from another? That is, packages that aren't just new versions, but that haven't been in the repos before at all? And packages that have been promoted or demoted?
[04:51] <rgreening> TomJaeger: and they should still yield whether a patch was used. I don't see that.
[04:51] <rgreening> unless I missed something...
[04:51] <TomJaeger> I figured changing the source directly is less intrusive than adding a patch system
[04:52] <rgreening> TomJaeger: completely the opposite
[04:52] <rgreening> for us
[04:52] <TomJaeger> Patch systems are kludges anyway
[04:52] <rgreening> As a rule of thumb, never change the source. Always generate a patch. submit the debdiff . pass the patch upstream.
[04:53] <rgreening> TomJaeger: if you are interested in learning the ropes, and how we work, there are some processes we have to follow.
[04:53] <rgreening> and patch systems are not kludges.
[04:53] <TomJaeger> They are. Horrible kludges.
[04:54] <TomJaeger> PITA to deal with.
[04:54] <rgreening> do I sense any undue hostilities? cause, I am quite willing to walk away...
[04:54] <rgreening> rather than help
[04:54] <TomJaeger> Put the source package under proper version control
[04:55] <TomJaeger> Well, I've wasted a lot of time dealing with patch systems.
[04:55] <rgreening> TomJaeger: we don't own the source, and therefore we patch and pass upstream. if/when upstream accepts the patch, we update the package and remove the patch. this keeps things much cleaner and much easier to modify or remove a patch when required.
[04:56] <rgreening> Tell me, how easy is it to back out your change? with a patch system, I comment out a single entry in a file and let it rebuild. done.
[04:56] <TomJaeger> Well, a .diff.gz is a patch, too
[04:57] <rgreening> TomJaeger: no, not in the strict sense we are looking for here. Patches goe in the debian/patches dir and are part of a patch system like quilt, dpatch, etc.
[04:57] <TomJaeger> It's as easy as removing a .orig and a .rej file after running uupdate
[04:57] <rgreening> Anyway, if you wish to have patches/diffs reviewed and uploaded, it will go a lot easier if you follow the ubuntu packaging guide.
[04:58] <rgreening> making life easy for your uploader/sponsor is in your and the packages best interest.
[04:59] <rgreening> but I digress... its late here... and Im much too tired...
[04:59] <TomJaeger> At this point, I'm really fine with keeping the package in my PPA.
[04:59] <fabrice_sp> Woah! We still have 128 packages that cannot be installed, 48 of which are from python (that's what apt-cache -i unmet tell me...).
[05:00] <fabrice_sp> and Beta is in 3 days? That will be hot!
[05:02] <punkrockguy318> Can someone try to get the latest version of my NES emulator into intrpeid?  http://fceux.com .  It version 2 of fceu and gfceu, but it does not replace them , since its called (g)fceux.  it's works a lot more nicely with ubuntu 8.10/9.04 and it would be a shame to see only the ancient 0.98 release in the archives
[05:11] <TomJaeger> rgreening, again, I don't have the time for this busywork.  It's late here, too and I still have 3 hours of work ahead of me.  If you want changes to the package to be versioned, I would suggest to adopt a solution centered around a version control system.  Patch systems are extremely difficult to work with when you're tracking upstream changes.
[05:13] <rgreening> TomJaeger: it's not me, its policy. I think you really need to read up on how packages are done in debian and Ubuntu
[05:13] <TomJaeger> I don't seem to remember that patch systems are a hard requirement.
[05:14] <TomJaeger> As a matter of fact, I've gotten packages in that didn't use a patch system...
[05:14] <rgreening> TomJaeger: If there's no good reason to not use a patch system, then we use it. We avoid patching the source directly.
[05:15] <rgreening> if the source has issues and MUST be modified directly, then this is a case-by-case review. in this case, It is not warranted.
[05:16] <rgreening> and wehat happens for the next person who wishes to fix? What happens when a source update occurs and the change disappears...
[05:16] <TomJaeger> What's troubling me here is that there is a lack of a sense how things should be properly done
[05:16] <rgreening> thats what patch systems are useful..
[05:16] <rgreening> TomJaeger: I think you are really failing to understand.
[05:16] <TomJaeger> What don't I understand?
[05:18] <TomJaeger> There's a tradeoff here: Patch systems are a considerable amount of work to set up and maintain, and the benefits are not worth it in this case, at least not for me.
[05:18] <rgreening> TomJaeger: If it was my source tree, then it would be in bzr. This is an upstreams source, and presumably its in an rcs of some kind. a proper patch should be provided to them, and they will updates thier rcs. we maintain only small diffs/patches and re-sync with debian and upstream at various times.
[05:18] <rgreening> considerable amount of work? not at all.
[05:19] <TomJaeger> Small patches, huh?  This is the reason why everybody runs autoreconf on the source tree and then sticks the result into the .diff.gz?
[05:19] <rgreening> TomJaeger: that shouldn't occur (on reasonably new packages)
[05:20] <rgreening> TomJaeger: I take it you've never used quilt.
[05:21] <rgreening> quilt is a dream.
[05:21] <wgrant> Which is why the new source format is based on it.
[05:22] <rgreening> TomJaeger: https://wiki.kubuntu.org/Kubuntu/Ninjas/QuiltMagic
[05:22] <TomJaeger> I've used quilt, and I can tell you, it just doesn't interoperate with git very well.
[05:23] <rgreening> I can see this discussion is circular, and Im feeling quite dizzy. so adieu
[05:23] <wgrant> TomJaeger: Is the thinkfinger packaging in a VCS?
[05:25] <TomJaeger> I do know what I'm talking about, I've developed all the patches that I got into the X Server before 1.6 came using a git archive with a debian/ directory in it.  It was not very pleasant, but it beats setting up an upstream X build system any day.
[05:25] <TomJaeger> wgrant, upstream uses svn
[05:26] <wgrant> TomJaeger: If the packaging doesn't use a VCS, there is little excuse not to use a patch system.
[05:26] <rgreening> upstream != packaging
[05:31] <TomJaeger> wgrant, except that it would probably take me an hour to separate the changes into patches and setting everything up, time that I don't have.  And the patch system won't be of much use anyway if the is ever merged with debian again.
[05:32] <rgreening> TomJaeger: actually the 3 changes are in patch format already here: http://bugzilla.kernel.org/show_bug.cgi?id=12301
[05:32] <rgreening> which is where you got them
[05:32] <wgrant> TomJaeger: You had to apply the changes as patches in the first place.
[05:33] <wgrant> And I hadn't noticed before that it was derived from Debian in ancient times.
[05:33] <rgreening> and TomJaeger we sync/merge with debian after each release
[05:34] <TomJaeger> exactly, so right now, we should only be worrying about fixing the bugs, and not duplicating work
[05:35] <rgreening> maybe getting the patch into the original code would be more your style :) I hear they have a vcs
[05:35] <rgreening> :)
[05:36] <wgrant> Since it is in fact somewhat derived from Debian, and it doesn't appear to have a patch system at the moment, AND it's raw old-style debhelper, applying the patches inline isn't an entirely terrible crime.
[05:36] <TomJaeger> The patch was written by the thinkfinger author, so, yes, I'd expect it to become available upstream sooner or later
[05:36] <rgreening> ew...
[05:36] <rgreening> old debhelper is god awful
[05:59] <TomJaeger> rgreening, since you said earlier that quilt was so easy to use and set up, I've had a quick look at how things work (maybe the impression that I got when I first dealt with this a long time ago, was wrong after all)
[06:00] <rgreening> awesome
[06:00] <rgreening> quilt is powerful
[06:00] <TomJaeger> So I checked the PackagingGuide, and they explain how to use it.
[06:01] <TomJaeger> It seems a little complicated to my, I will definitely continue to create my patches with git and then stick them into the debian/patches directory
[06:01] <TomJaeger> I'd also be worried about forgetting the add step and creating inline patches by accident.
[06:02] <TomJaeger> But the packaging guide says nothing about how to set it up.  But they give an example package, xterm.
[06:03] <TomJaeger> So I checked out the xterm package and looked at their debian/rules file
[06:03] <TomJaeger> The file is 231 lines long and contains a lot of quilt boilerplate.  Not exactly what I'd call easy to set up.
[06:04] <rgreening> It's simpler than that
[06:04] <rgreening> 1. add a dep on cdbs and quilt in the build-deps
[06:05] <rgreening> 2. add the patch to debian/patches and add the name to debian/series
[06:05] <TomJaeger> maybe that should be explained in the packaging guide?
[06:05] <TomJaeger> What if my package doesn't use cdbs?
[06:05] <rgreening> 3. add include /usr/share/cdbs/1/rules/patchsys-quilt.mk to rules
[06:05] <rgreening> thats it
[06:06] <rgreening> cdbs is for step 3.
[06:06] <rgreening> and it's onlt for build dep and not run=time
[06:06] <TomJaeger> And it'll work with a debhelper package?
[06:06] <rgreening> most newer packages will likely work with this 3 step
[06:06] <rgreening> yes
[06:07] <rgreening> add the step 3. just after tyhe debhelps like in rules
[06:10] <rgreening> TomJaeger: in this package, since its an real old debhelper, two ways to update... 1) use quilt and update the rules file to work with cdbs (doesn't appear to at the moment). 2) add patch definitions to rules and forget quilt.
[06:10] <TomJaeger> Is there a reason why the simple patchsys and dpatch are featured more prominently in the packaging guide than quilt
[06:11] <TomJaeger> dpatch should be deprecated in my opinion, I've had nothing but trouble with it.
[06:11] <rgreening> look at balder2d. I recently updated it in this way
[06:12] <rgreening> TomJaeger: http://paste.ubuntu.com/132323/
[06:12] <rgreening> add that to rules and forget adding cdbs and quilt deps.
[06:13] <rgreening> you won't need a series file either with that
[06:13] <TomJaeger> In this particular instance, I really don't think it's worth it, though.  The package should be fixed properly before any more work is done on it.
[06:13] <rgreening> but you still copy the patch to debian/patches and nam,e .patch
[06:14] <rgreening> ading the paste I supplied and http://paste.ubuntu.com/132324/ as the patch should do it
[06:15] <rgreening> (I was working on it at the same time here...)
[06:20] <TomJaeger> rgreening, is anyone working on updating the packaging guide?  It seems like quilt is superior to the alternatives, yet it's not at all obvious from the guide that you should use it or how you should use it.
[06:21] <rgreening> not that I am aware.
[06:28] <a|wen> this looks pretty much like af rebuildd hick-up http://builder.ubuntuwire.com:9998/job/47540 ... can we do anything to get the rebuildd to try again?
[06:48] <TomJaeger> rgreening, as much as I'm sympathetic to your cause, I really can't justify any work on the thinkfinger package at the moment.  I'm pretty caught up in real life right now, and I've got other linuxy things to worry about that are more important to me, for example I've got patches related to bug #217908 that I've been meaning to send to the cairo list for weeks.  If this means that we're not going to see an update to the thinkfin
[06:48] <TomJaeger> ger package, then that sucks for the people that want to use their fingerprint reader on a jaunty system.  I've gotten used to maintaining packages outside the distribution in various PPAs anyway, one more package won't hurt.
[06:59] <wgrant> a|wen: It was sort of a hiccup, but not really - the package was actually deleted from Jaunty after the job was created.
[06:59] <wgrant> So a few days later it tried to build, and BOOM.
[06:59] <wgrant> a|wen: But please ping me with any issues with the rebuild.
[07:00] <a|wen> wgrant: okay, that's makes sense; is there any way to get it off the list?
[07:00] <a|wen> and i'll ping you if i see any other strange things through the list
[07:00] <wgrant> a|wen: Nothing that makes sense. But I intend to improve the listing some time this week to only show failures for current sources.
[07:01] <wgrant> At the moment it will show all failures for the distroseries.
[07:01] <a|wen> wgrant: okay; that would solve the purpose :)
[07:01] <wgrant> Which isn't too useful if it is fixed later.
[07:04] <wgrant> Also, I can give people tarballs of failed build logs to grep through for common issues.
[07:04] <dholbach> good morning
[07:04] <wgrant> Like the 70 distutils /usr/local-related ones I grepped into recently.
[07:05] <wgrant> Morning dholbach.
[07:05] <dholbach> hi wgrant
[07:06] <fabrice_sp> hi dholbach ;-)
[07:07] <dholbach> hiya fabrice_sp
[07:07] <a|wen> wgrant: we probably still have a number of "use --without-arts" ... that is those i'm on lookout for now
[07:07] <wgrant> a|wen: Yes, around 56 at last count.
[07:08] <wgrant> But that was about 2500 builds ago.
[07:08] <wgrant> I can give you a list in a minute or so...
[07:08] <a|wen> wgrant: i've fixes 68 of those within the last 3 days ... so should be lower now :)
[07:08] <a|wen> wgrant: that would be cool with a list, thx
[07:11] <wgrant> a|wen: http://paste.ubuntu.com/132329/
[07:12] <a|wen> wgrant: don't they disappear from the list, when they get fixed ... or how often are they updated?
[07:12] <wgrant> a|wen: No, they stay there forever at the moment. That's what I plan to fix.
[07:13] <wgrant> But the rebuild only started 6 days ago, so it's not too bad yet.
[07:13] <a|wen> okay, i've got it now ... the good news is that all the kde-i18n-* from that list is fixed
[07:16] <iulian> Good morning dholbach.
[07:17] <dholbach> hiya iulian
[07:44] <RAOF> Hello everyone!  I now have internet again!
[07:47] <wgrant> RAOF: I'm sure I can get Telstra to fix that.
[07:48] <wgrant> Although I probably don't need to intervene for it to happen.
[07:48] <RAOF> Probably not.  Apparently the main problem was that the wiring in this building is corroded to buggery.
[07:49] <RAOF> Netting me the lightning fast download sync speed of 4Mbit/sec.
[07:49] <wgrant> Excellent.
[07:49]  * RAOF goes back to ensuring the en_AU translation of GNOME Do isn't in Arabic.
[07:53] <slytherin> RAOF: which Telstra service are you using?
[07:55] <RAOF> slytherin: None.  Only the local loop that they own.
[07:55] <slytherin> oh
[07:55] <RAOF> I've got me an Internode "please, don't make me have to contact Telstra" naked DSL plan.
[07:57] <savvas> Depends: python (<< 2.7), python (>= 2.5), python-central (>= 0.6.11), python2.6
[07:57] <savvas> is there any way to make 2.5 and 2.6 libs, but not to add python2.6 ?
[07:58] <Toadstool> g'morning
[07:59] <savvas> here's the pbuilder log: http://paste.ubuntu.com/132335/
[08:00] <maxb> savvas: grep for any #!/usr/bin/python2.6 lines that might inadvertently be present
[08:01] <savvas> maxb: none unfortunately
[08:01] <savvas> I think it has to do with the fact that it builds libs for 2.6: -rw-r--r-- root/root     70488 2009-03-17 08:51 ./usr/lib/python2.6/dist-packages/imgSeekLib/imgdb.so
[08:01] <savvas> but then again, what do I know :P
[08:02] <maxb> hm
[08:03] <savvas> here's the debdiff I'm preparing: http://paste.ubuntu.com/132337/
[08:10]  * savvas bbl
[08:47] <Laney> I have 123 emails from LP since last night...
[08:48]  * Laney eyes rosetta
[08:58] <binarymutant> ]3.
[08:58] <binarymutant> 0+69-00
[09:11] <soren> Laney: Lucky.
[09:14] <Laney> Did I get off lightly?
[09:28] <directhex> MD2 beta 2 is out. i shall prep a merge
[09:32] <soren> Laney: I think you did. I wish I only got that many a day :)
[09:35] <geser> good morning
[09:35] <slytherin> geser: good morning
[10:14] <directhex> grr, gnomish things going on mean i can't test-build monodevelop 2 beta 2
[10:22] <slytherin> directhex: test build where? on your machine or ppa?
[10:23] <directhex> slytherin, local machine. looks like not all deps have caught up yet (libfontconfig1 is the current baddie)
[10:24] <slytherin> directhex: hmm
[10:24] <directhex>   libfontconfig1: Depends: fontconfig-config (= 2.6.0-1ubuntu7) but 2.6.0-1ubuntu9 is to be installed.
[10:24] <directhex> it'll right itself in a few hours. the timing just sucks
[10:25] <DktrKranz> directhex: if it blocks you, ask a buildd-admin to rescore it a bit, so it will be mirrored sooner
[10:26] <directhex> DktrKranz, nah, not that urgent - anyway, it's a test build for the most recent monodevelop 2 beta, some poor bugger would still need to sponsor the merge
[10:27]  * DktrKranz hides
[10:27] <DktrKranz> :)
[10:37]  * slytherin wishes eclipse's latest release was in repos to give tough competition to monodevelop.
[10:37] <directhex> slytherin, not happening for jaunty? :/
[10:38] <slytherin> directhex: Nope. The Debian java packages who used to work on eclipse are MIA.
[10:38] <directhex> slytherin, gah!
[10:38] <directhex> slytherin, something to aim for for karmic, perhaps?
[10:39] <slytherin> directhex: yes, sure. And by that time eclipse will have added another bunch of build deps. eclipse is becoming mammoth.
[10:40] <directhex> slytherin, far be it for me to ever consider using words like "bloat" in the same sentance as "java" ;)
[10:40] <directhex> slytherin, i really hope java 7's reshufflinf of the class library can help bring some of this crap back under control
[10:42] <directhex> and it's pretty unfortunate for dev tools to EVER be outdated in a release - that's one reason i pushed for MD2 FFe: MD1 in <=intrepid sucks
[10:44] <slytherin> directhex: at least we have netbeans updated.
[10:46] <directhex> slytherin, are there any qt-java apps in the archive, out of interest?
[11:14] <savvas> is it normal for pycentral to request in "Depends:" a specific python version, i.e. python2.6 when it packages a 2.6 library ?
[11:15] <savvas> (there's no python2.6 hashbang as far as I can see)
[11:16] <slytherin> directhex: don't think so. I don't even know if there are any java bindings for Qt
[11:17] <directhex> slytherin, there are - the recent announcement was that nokia were dropping them, so the community would need to maintain them if they care
[11:18] <directhex> slytherin, i ask as the first ever real Qyoto app has surfaced, an XMPP client written in C# for Qt4
[11:19] <savvas> qyoto?
[11:20] <savvas> I hope that's a typo :P
[11:20] <directhex> savvas, current Qt CLI bindings project
[11:20] <savvas> oh, hehe
[11:20] <directhex> libqyoto4.3-cil - CLI bindings for the Qt 4 toolkit
[11:21] <directhex> also, a monodevelop addin to generate c# from Qt Designer files
[11:21] <Laney> "Looks sexy, very alphaish" was my assessment of Synapse
[11:21] <Laney> <3
[11:21] <savvas> * libqyoto4.4-cil
[11:22] <savvas> :)
[11:22] <directhex> Laney, yes
[11:22] <directhex> Laney, but points for sheer awesomeness
[11:23] <directhex> Laney, need to start thinking about karmic mono goals
[12:00] <slomo> slytherin: ping
[12:02] <slytherin> slomo: hi, long time no see. I wanted to discuss the broken dvd playback on jaunty. Had some discussion with seb128. I have even mailed debin maintainer of libdvdread but yet to receive the reply.
[12:03]  * directhex puts his net gun away
[12:03] <slomo> slytherin: ok, give me some details please :)
[12:04] <directhex> "configure2 sucks"
[12:04] <slytherin> slomo: currently all apps that link against libdvdread4 are broken. This includes totem with gstreamer backend, mplayer, vlc, thoggen etc.
[12:05] <slomo> slytherin: why?
[12:05] <slytherin> slomo: The upstream libdvdread4 is shipping some script configure2 and a Makefile which seem to be creating some problem. I am not sure what the problem is exactly.
[12:07] <slomo> slytherin: hm, ok... so "something is broken"? :) there's no known fix yet? and is the problem in libdvdread or in the using applications?
[12:08] <slytherin> slomo: I know a workaround. The problem is in using all applications that use libdvdread4.
[12:09] <slytherin> slomo: I initially thought this snippet in dvd_input.c was causing problem.
[12:09] <slytherin> /* dlopening libdvdcss */
[12:09] <slytherin> #ifdef HAVE_DLFCN_H
[12:09] <slytherin> #include <dlfcn.h>
[12:09] <slytherin> #else
[12:10] <slytherin> but the Makefile has ﻿HAVE_DLFCN_H defined, so this should not be the problem.
[12:12] <slomo> slytherin: so what's the workaround?
[12:13] <slytherin> slomo: workaround is to use the old configure script, which needs to be generated with autogen.sh
[12:16] <slomo> slytherin: but you don't know the difference between the configure scripts?
[12:17] <slytherin> slomo: No. I tried hard to figure out. :-(
[12:21] <slomo> slytherin: no differences in config.h for example?
[12:21] <slomo> slytherin: also, is this bug already filed in debian or known by the maintainer?
[12:21] <slytherin> slomo: I wasn't sure if the bug is present in Debian. Hence I mailed the maintainer offline.
[12:22] <slomo> slytherin: ok, i don't know either because i have no dvds here :)
[12:24] <white_> slomo: just replied to your email, thanks for working on it :)
[12:24] <slytherin> slomo: I will see if any of my friends have Debian unstable system
[12:25] <slomo> white: np... it's only glib that is affected btw, libsoup is fixed since 2.2.101 (by using glib functions) and gst-plugins-base 0.10.19 and before in stable are also not affected
[12:25] <white> slomo: did you check oldstable as well?
[12:26] <slomo> white: libsoup in oldstable has the bug, right... so that's glib for stable and oldstable and libsoup for oldstable... debdiffs will follow in some minutes ;)
[12:27] <white> slomo: much appreciated :), i suppose gst-* in oldstable is not affected either?
[12:27] <slomo> white: no
[12:45] <slomo> white: i've sent you the three debdiffs
[12:51] <slomo> white: if you're confused by the uploaders changes in the debdiffs, that's caused by the gnome-pkg-tools uploaders.mk
[13:03] <white> slomo: just for the record, gst-plugins-base uses glib?
[13:04] <slomo> white: yes (and the version i've uploaded to unstable today fixes the base64 CVE, should move to testing asap)
[13:07] <white> slomo: ok, i am always getting confused by the various gst* packages and their versions and where the plugins are ..., but if you say they are not affected in stable/oldstable, then that's even better :)
[13:10] <slomo> white: the problem was a feature that was added in 0.10.20 of gst-plugins-base (images in vorbis tags) and it used the glib base64 functions ;)
[14:17] <bddebian> Heya gang
[14:17] <directhex> afternoon, bazza
[14:18] <bddebian> :)
[14:51]  * RainCT can't boot with the latest kernel (jaunty) :(
[14:53] <soren> This feels like a silly question, but what is the functional difference between the Apache license and the BSD license?
[14:54] <ScottK> Which BSD license?
[14:55] <soren> /usr/share/common-licenses/BSD
[14:55] <ScottK> A quick read leads me to believe the patent grant and the requirement to document what you've changed are the major differences.
[14:57] <ScottK> IIRC the patent grant is what makes the Apache license GPL v2 incompatible.
[14:57] <soren> Oh, right. The patent thing.
[14:57] <directhex> yay, patents
[14:57] <ScottK> You would say that.
[14:58] <directhex> of course!
[14:58]  * directhex patents IRC
[15:02] <soren> So if I'm reading the legalese correctly, if you contribute to an ASL licensed project something that is covered by a patent you hold, you implicitly grant the project a patent license?
[15:02] <ScottK> That's pretty much my reading.
[15:03] <ScottK> And you get patent licenses for anything anyone else contributed.
[15:03] <soren> That doesn't offer much of an incentive to contribute those patches back to the project.
[15:03] <ScottK> Which vanishes as soon as you sue someone.
[15:03] <ScottK> So it's a bit of an enforced patent peace.
[15:03] <ScottK> So making the contribution gets you some protection too.
[15:04] <soren> Ah, I see.
[15:05] <soren> ScottK: Thanks!
[15:05] <ScottK> soren: yw.
[15:40] <mok0> Argh we have no latex equation editor for Ubuntu... :-(
[15:43] <directhex> DktrKranz, if it helps, MD2 beta 2 is a pure bugfix release - 130 closed tickets. so no FFe worrying this time \o/
[15:44] <DktrKranz> directhex: well, I think it has been approved anyway
[15:45] <directhex> just sayin'...
[15:45] <directhex> should mean a simple uupdate-only update, but i can't test until mirror.ox.ac.uk stops sucking
[15:51] <DktrKranz> directhex: don't worry, just ping when ready :)
[15:53] <adelie42> I hope someone can help... I just discovered that, evidently, I have two launchpad accounts.  When I discovered it, it says there had been no activity in over 3 years, now it is gaining as a contributor. I am VERY confused. It says I am making bazaar revisions, but the account doesn't even have any registered keys.
[15:54] <ScottK> adelie42: #launchpad is the place to ask.
[15:54] <adelie42> k
[15:54] <mok0> adelie42: or post a question on LP... I believe your accounts can be merged
[15:55] <adelie42> that would be nice
[15:57] <mok0> adelie42: You're not the only one who has had that problem :-)
[15:58] <adelie42> It is a little funny to see myself as #2 and #4 contributor in a project...
[16:12] <RoAkSoAx> Hi guys. how can i create a jaunty pbuilder on debian?
[16:14] <maxb> At a guess, install jaunty's debootstrap .deb ?
[16:15] <maxb> Assuming Debian's debootstrap doesn't already handle jaunty?
[16:17] <maxb> Actually all ubuntu since gutsy have used the same debootstrap script
[16:17] <maxb> so you can probably get away with just adding another symlink to /usr/share/debootstrap/scripts/
[16:31] <ScottK> Either way shoule be fine.
[16:31] <ScottK> shoule/should
[16:32] <cjwatson> RoAkSoAx: debootstrap >= 1.0.11 in Debian supports jaunty
[16:32] <RoAkSoAx> thanks cjwatson :)
[16:32] <cjwatson> as of a while back we've been making efforts to keep debootstrap pretty much in sync
[16:32] <cjwatson> in fact, I was just going to sync it up again now
[16:33] <RoAkSoAx> ok :) great to hear :D
[16:35] <AnAnt> Hello, is Scott James Remnant here ?
[16:36] <cjwatson> AnAnt: try #ubuntu-devel
[17:16] <savvas> james_w: bug 297847 - is there a reason shares-admin / "shared folders" was disabled in the menus and not shown in gnome? :)
[17:46] <vadi2> Hi, I have a question - a certain package is broken and is unusable in jaunty. How can I get it looked at if its not too late?
[17:50] <maxb> File a bug to start with
[17:50] <vadi2> where?
[17:50] <vadi2> the offending project was tagged as affected, but I doubt anyone will see it anytime soon.
[17:51] <maxb> Why are you avoiding mentioning what the package/project is?
[17:52] <vadi2> er, because it was not asked for?
[17:52] <vadi2> the project is gnome-web-photo and here is the report: https://bugs.launchpad.net/shutter/+bug/342408
[17:55] <maxb> vadi2: You could make a fixed package and follow http://wiki.ubuntu.com/SponsorshipProcess
[17:57] <vadi2> and what is the success rate of that? (I just have a very poor experience when dealing with debian/ubuntu packagers, so just inquiring before I commit time)
[17:58] <maxb> Dunno, but I'd imagine "greater than the success rate of hoping someone will make the fix for you"
[17:58] <vadi2> heh
[17:58] <vadi2> that's fine then I guess. breaking & not caring about it ftw :)
[17:58] <adelie42> I made a merge proposal of a branch that fixed a bunch of minor bugs. My proposal is still pending review, but I found another bug on launchpad that I believe I can fix.  Are merge proposals are on a per revision basis, or per branch, and if I want to make further contributions, do I need to start a new branch, or can I keep working on the current one?
[18:01] <adelie42> basically, does merge say, "This is stable and complete enough of a revision point to add" or "I'm done, lets move this into the trunk"
[18:03] <joaopinto> maxb, was your answer expected to provide motivation for someone asking how to followup a problem resolution ?
[18:08] <maxb> It was an attempt to be truthful, in the face of a fairly unanswerable question
[18:17] <jpds> adelie42: You should have a separate branch per fix/feature.
[18:23] <adelie42> jpds: According to the documentation, it says it is easier for maintainers to do a branch merge than apply a debdiff. bzr has the latest development editions while apt-get source is the lastest stable. Should I really be registering a new branch for every minor fix?
[18:25] <jpds> adelie42: Well, you could have all the fixes in one branch.
[18:26] <c_korn> can bug 344168 be acked?
[18:26] <adelie42> ok, but once I make a merge proposal, that means any additional work should go into a new branch, not the old one?
[18:26] <soren> adelie42: That's the general idea, yes.
[18:27] <soren> It allows work to continue on the two different features in parallel if they for some reason are not going to get merged in the order in which they're implemented, for instance.
[18:29] <adelie42> So if I got new feature A v1.0 and want to get it merged, I should open a new branch for feature A v1.1?
[18:29] <soren> I would, yes.
[18:30] <soren> Don't be afraid of branches. They're your friend :)
[18:30] <iulian> c_korn: Could you please give me a link to the upstream ChangeLog?
[18:30] <adelie42> Ok, thanks!
[18:31] <iulian> c_korn: I see that it's a new upstream release.  If it's a bug fix only release, it does not need an exception.
[18:31] <c_korn> the source is here: http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/apt-cacher-ng_0.3.4.orig.tar.gz
[18:32] <c_korn> iulian: http://pastebin.com/d3a955dd6 changelog in the tarball
[18:32] <adelie42> I think I just have a fear someone is going to say "What, he started a whole new branch for THIS? wtf, stop with all the branches!"
[18:33] <iulian> c_korn: It does need a FFe, please subscribe motu-release.
[18:34] <c_korn> iulian: done
[18:34] <iulian> c_korn: See https://wiki.ubuntu.com/FreezeExceptionProcess
[18:35] <c_korn> oops, I missed the first point
[18:36] <iulian> c_korn: I've unsubscribed u-u-s for now.
[18:44] <Laney> right, cool
[18:44] <Laney> I think I can push a python 2.6 miro
[18:44] <Laney> it seems pretty solid
[18:45] <savvas> always expect a bugstorm hehe :P
[18:45] <Laney> I'd rather have that than it not working at all
[18:54] <Laney> I'm after an FFe on bug 336029. New features are minor compared to the amount of bugfixes
[18:54] <adelie42> So my branch fixing several bugs was merged recently, should I go back to all those bugs and mark them as "fix committed"? Further, I am looking for bugs I can fix, but keep looking through "new" bugs to find that there are already patches submitted. Can these be marked as something other than 'new'? Would 'in progress' be more appropriate, or would it be helpful to round these up as branches, test them, and propose merge?
[18:55] <Laney> adelie42: There's a --fixes option to bzr which I think automatically changes the status
[18:56] <Laney> aaaaaand have you heard of harvest for finding things to fix?
[18:56] <adelie42> I could not figure out the syntax for --fixes based on the info in the man page, and no, have not heard of harvest
[18:57] <Laney> http://daniel.holba.ch/harvest/
[18:59] <savvas> darn, pastebinit doesn't work with http://paste.ubuntu.com anymore :\
[19:00] <adelie42> Laney: So if I failed on the '--fixed' part, then I should go back and mark those as 'fix committed' for branches that have already been merged?
[19:00] <Laney> savvas: the author is here!
[19:01] <Laney> adelie42: If they're going to be uploaded to Ubuntu and the task is against an Ubuntu package then yes
[19:01] <Laney> I usually set fix committed after I sponsor an upload from a debdiff
[19:01] <savvas> Laney: actually, ignore that comment, the problem seems to be with characters in the text :)
[19:01] <adelie42> Laney: and for patches submitted, if there is no related branch, then that means it has not yet been applied and some work of a maintainer could be saved by turning the patch into a merge proposel after testing the patch?
[19:02] <Laney> adelie42: branch merges aren't the normal way of sponsoring yet
[19:02] <Laney> there's not much point converting a debdiff to a bzr branch really
[19:03] <adelie42> if a reasonable enough looking patch has been submitted, can at least mark the but as 'in progress'?
[19:04] <Laney> no, that's not what in progress is for
[19:04] <Laney> https://wiki.ubuntu.com/Bugs/Status
[19:09] <adelie42> laney: ok, so if I fixed a bug in my own branch, bug can be marked 'fix committed' even before it is merged into the main project. If a patch has been submitted, but bug is still marked new, then I could independently confirm the bug and mark as 'confirmed'.
[19:09] <Laney> erm
[19:09] <Laney> I would only mark fix committed once it gets merged
[19:10] <adelie42> ok
[19:11] <adelie42> Laney: err... than what does '--fixes' change the status to?
[19:11] <Laney> not sure how it works
[19:17] <cristi> hy, realated to the python transition, should i change in debian/pyversions from 2.4- to 2.6- ?
[19:17] <Laney> no
[19:17] <jpds> adelie42: It just links the branch to the bug report.
[19:17] <cristi> Laney: ok, thank you
[19:18] <adelie42> Laney: Read through the 'bug status' page you sent me. It looks like if someone else confirmed the bug in comments then it is reasonable to set the status to confirmed even if it wasn't confirmed yourself. Is that too liberal? I am reading through harvest, but I am still get used to launchpad. Trying to make myself useful  :)
[19:19] <Laney> that sounds right
[19:19] <Laney> by the way, #ubuntu-bugs is better for bug triage questions
[19:19] <adelie42> jpds: thanks, that makes sense. can you give an example if --fixes syntax for launchpad?
[19:20] <adelie42> Laney: ok
[19:20] <jpds> adelie42: bzr commit --fixes lp:bug###
[19:20] <adelie42> jpds: ha ha, I was very close  :)
[19:22] <jpds> adelie42: Now try: "bzr rocks"
[19:22] <adelie42> ha ha
[19:22] <Laney> Purpose: Statement of optimism.
[19:22] <adelie42> nice
[19:22] <Laney> haha
[19:47] <Turl> hi
[19:47] <Turl> in CDBS, how can I add a rule post-make install ?
[19:47] <Laney> binary-post-install/foo::
[19:47] <Laney>   bar
[19:48] <Laney> (iirc)
[19:48] <Turl> and install/foo:: is pre-make install?
[19:49] <Laney> binary-install
[19:49] <Laney> not sure, check the manual
[19:49] <Laney> it's something like that
[19:49] <Laney> actually, maybe binary-install is what you want
[19:56] <RainCT> (wow, I've reinstalled Jaunty and now the laptop boots 30 seconds faster)
[19:58] <Laney> :O
[19:59] <jdong> zero length files speed bootup??
[19:59] <jdong> (kidding!)
[20:02] <JontheEchidna> ha
[20:02] <RainCT> either there's something really wrong with updating or ext4 is awesome (I already had ext4 before, but without reformating) :P
[20:03] <jdong> RainCT: without reformatting you don't get the extent allocation benefits
[20:03] <jdong> that makes a huge difference on even modestly sized files
[20:04] <RainCT> jdong: I see.. I've heard that there's some "online defrag" tool, is that available on Jaunty? (I guess /home would like it too :P)
[20:06] <jdong> RainCT: it's not available yet AFAICT
[20:06] <jdong> I believe there isn't solid consensus on the API yet
[20:06] <jdong> i.e. you can probably find some git patchset if you dare
[20:06] <RainCT> nah, I'll wait
[20:07] <jdong> IMO the fragmentation on ext4 is not nearly that bad to warrant defragging any time within the next 6 months anyway!
[20:07] <RainCT> but /home is upgraded from ext3 :)
[20:09] <jdong> RainCT: home tends to be easy. Tar up its contents and unpack it.
[20:09] <jdong> or rsync shuffling
[20:09] <jdong> I had the rsync shuffling method described in my ext4dev howto
[20:09] <jdong> it more or less, on my volume with 70% free space, gives clean ext4 performance
[20:10] <RainCT> jdong: URL? :)
[20:11] <NCommander> hey RainCT, can I steal you for a REVU?
[20:11] <NCommander> (ecosconfig-imx was ACCEPTed on the first go today :-))
[20:11] <RainCT> cool
[20:11] <jdong> RainCT: http://ubuntuforums.org/showthread.php?t=973701
[20:11] <NCommander> RainCT, http://revu.ubuntuwire.com/p/redboot-imx
[20:11] <jdong> see "OPTIONAL: Converting all files to extent format"
[20:11] <NCommander> jdong, also, if your interested?
[20:12] <RainCT> jdong: thanks
[20:12] <RainCT> let me reboot, I want my proprietary driver! :P     /me hides
[20:12] <jdong> haha
[20:12] <NCommander> REDboot :-P
[20:21] <RainCT> ....   apt-get and aptitude are segfaulting now at "generating dependencies..." if I try to install/update something
[20:22] <RainCT> anyone seen this before?
[20:25] <fabrice_sp> RainCT, do you have debug repository enabled?
[20:25] <RainCT> fabrice_sp: what is that? :P
[20:25] <RainCT> wait, it's fixed now
[20:26] <RainCT> weird
[20:26] <RainCT> and now it happens again
[20:26] <fabrice_sp> yes :-/
[20:26] <RainCT> sudo dpkg --configure -a  fixes it for the next run
[20:26] <fabrice_sp> it's http://ddebs.ubuntu.com
[20:27] <RainCT> nope
[20:27] <RainCT> apport tries to file a bug about it but crashes :/
[20:30] <fabrice_sp> it is similar to Bug #341402 ?
[20:31] <RainCT> I don't know, but it's like bug #163316
[20:32] <fabrice_sp> not the same backtrace, so it's not the same bug
[20:32] <RainCT> ok, removing those .bin files mentioned in the first report fixed it
[20:33] <fabrice_sp> Really? So it was a pb with the mirror, then
[20:38] <RainCT> cool, Launchpad has "Klingon" in the languages list :P
[20:39] <NCommander> It does?
[20:39] <NCommander> neat
[20:41]  * RainCT cries
[20:42] <NCommander> RainCT, ?
[20:42] <RainCT> my Development folder (which contains all coding stuff) is empty . . .
[20:42] <NCommander> O_O;
[20:42] <NCommander> Are you running ext4?
[20:43] <RainCT> yes
[20:44] <NCommander> Ouch :-/
[20:46] <Laney> backups?
[20:46] <RainCT> No.
[20:46] <Laney> Best way to learn is to be burned ;)
[20:47]  * Laney offers RainCT sympathies
[20:47]  * NCommander guesses this isn't a good time to ask for a REVU :-/
[20:48] <RainCT> Luckily, much of the stuff is online (bazaar branches and stuff) or are abandoned projects..
[20:49] <RainCT> ehmmmmm
[20:49] <RainCT> mkdir: cannot create directory `Python': File exists          mkdir: cannot create directory `hi': Input/output error
[20:50] <RainCT> looks like everything is still there, but I can't see it
[20:51] <NCommander> RainCT, fsck?
[20:52] <RainCT> unmounting home, see you later
[20:57] <jdong> ouch am I seeing ext4 trashing?
[21:01] <nxvl> ScottK: ping
[21:01] <RainCT> it's back :D
[21:04] <NCommander> RainCT, BTW, did the PPA improt feature ever get turned on?
[21:04] <NCommander> (and can we get a link to the mian index?)
[21:06] <RainCT> NCommander: Yes, it's running (imports are processed every 5 minutes; uploads every 3, and I'll get that down to "as soon as they're complete" -with inotify :)-).
[21:07] <NCommander> very impressive
[21:07] <NCommander> Now I can just suck download from ym PPA :-)
[21:08] <RainCT> NCommander: about the link, sure, but import.py still needs some polish (like actually implementing the check that ensures that the package builds, or remove the text about that)
[21:08] <NCommander> RainCT, well, implementing that requires parsing Packages.gz; not difficult, but I haven't touch REVU in ages
[21:08] <fabrice_sp> Should I fix this error: pycentral: pycentral debhelper: missing XB-Python-Version attribute in package ?
[21:08] <fabrice_sp> or it's not important
[21:08] <NCommander> fabrice_sp, yes
[21:08] <fabrice_sp> ?
[21:08] <fabrice_sp> ok
[21:12] <RainCT> NCommander: I see you've got the copyright file sorted out.. :)
[21:13] <NCommander> RainCT, it grew expontentionally
[21:13] <NCommander> It was over 1000 lines, but Apache 2 is a common license so I was able to cut some fat out
[21:20] <RainCT> NCommander: well, I've no further comments about the packaging, and I can't build nor test it :P
[21:20] <NCommander> RainCT, well, you need an iMX51 babbage board to test, and ARM hardware just to build, but I can point you to a PPA with it built
[21:22] <RainCT> NCommander: the output of  dpkg-deb -c *.deb  will do
[21:23] <NCommander> RainCT, http://paste.ubuntu.com/132701/
[21:23] <NCommander> ah ****
[21:23] <NCommander> I just saw a mistake :-)
[21:24] <RainCT> hehe
[21:29] <NCommander> RainCT, http://paste.ubuntu.com/132702/
[21:31] <NCommander> RainCT, new version uploading
[21:35] <RainCT> NCommander: tell me when it's up
[21:36] <NCommander> RainCT, its up
[21:36] <joaopinto> bug 344500 should be a Xorg bug, right ?
[21:39] <joaopinto> should a X app be able to override xorg events for the other windows and preventing screen redraw ?
[21:39] <RainCT> NCommander: (advocated)
[21:39] <NCommander> RainCT, O_O; so the copyright looks ok to you?
[21:40] <RainCT> NCommander: I'd have written which files belong to whom, but well..
[21:40] <NCommander> RainCT, its a little crazy to do that
[21:40] <NCommander> like a few thousand lines crazy
[21:41] <RainCT> wildcards exist
[21:41] <RainCT> but yes, /me is a bit crazy :)
[21:49] <NCommander> RainCT, so you think its good to upload?
[21:49] <NCommander> RainCT, and the copyright is serviceable?
[21:51] <Laney> ScottK: Responded to you on the miro ffe
[22:23] <albertico> hi, where can I look for info/tutorials in order to learn how to create a debian package for an application
[22:23] <albertico> ?
[22:23] <ianto> albertico: What sort of tutorials are you interested in? Text or video?
[22:24] <albertico> anything useful  :)
[22:24] <ianto> https://wiki.ubuntu.com/MOTU/Videos
[22:24] <albertico> ianto, both are fine
[22:24] <ianto> And the rest of the /MOTU section too :)
[22:24] <albertico> ianto, thanks, looking into it
[22:25] <ianto> Have fun with the videos :)
[22:25] <albertico> ianto, another thing, how are packages mantained on ubuntu?
[22:25] <ianto> By the MOTU team, they get uploaded to the repositories
[22:25] <albertico> ianto, I mean, how is the package updating handled in regards to new versions?
[22:26] <ianto> Oh anyone can come along and update it, just make sure that others know that you are so the effort isn't duplicated
[22:26] <albertico> ianto, so the MOTU team uploads new versions of a new program
[22:26] <ianto> albertico: If it is a Universe application yeah
[22:26] <ianto> Universe as in free as in beer ;)
[22:27] <ianto> If it's main, the core-devs do it, or so I recall
[22:27] <ianto> And the other two, I can't remember who does them for the life of me :)
[22:27] <albertico> ianto, so an update to the nginx package, which is on universe, must be uploaded by a MOTU team member
[22:28] <ianto> albertico: Basically, you can make the changes yourself just notify a member when you are done
[22:28] <albertico> ianto, how can I know who is maintaining that package?
[22:28] <ianto> And they will look over and see if it is good or bad
[22:29] <ianto> albertico: There aren't maintainers are there are  in debian, but you can check the changelog and ask the last uploader to see if they know of the newer version and don't mind you working on it
[22:29] <ianto> *like there are
[22:29] <ianto> You are asking about the nginx package then?
[22:30] <albertico> ianto, yeah
[22:30] <albertico> ianto, btw, does it work the same for the server and desktop distros?
[22:30] <ianto> Yeah they use the same mirrors/repos
[22:31] <ianto> Jose Parrella was the last uploader on 14th Sep 2006
[22:31] <ianto> *contributoor
[22:32] <ianto> albertico: Have you packaged before by the way?
[22:32] <albertico> ianto, the debian packages web page shows Jose Parrella and Fabio Tranchitella
[22:32] <ianto> is there an updated version in Debian?
[22:33] <albertico> ianto, nope, I want to learn how to package... and then, try to see if my work can contribute somehow
[22:34] <adelie42> So I have noticed when I push a branch for the first time, I always get: 'Target directory ... already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.' Is that just normal, or is there something else it was anticipating me doing first?
[22:34] <albertico> ianto, nginx on lenny stable is a little bit old
[22:34] <ianto> It may be what Debian call an "orphaned project", I'm not a Debi guy but regardless, if you feel that you can update it, do it but I recommend doing instead a new simple package
[22:34] <ianto> Something like mv in other words ;)
[22:35] <albertico> ianto, jeje, will take that into account... better start simple  ;)
[22:35] <ianto> albertico: Nederlander? :p
[22:36] <albertico> ianto, nope, Puerto Rico
[22:36] <ianto> I just assuumed from the j instead of h
[22:36] <ianto> Could've been a  typo though ;)
[22:37] <ianto> https://wiki.ubuntu.com/PackagingGuide/Complete
[22:37] <ianto> That will also help when starting to package 6
[22:37] <ianto> ^
[22:37] <albertico> ianto, hehe... in spanish we put the j instead of the h... my fingers work faster than the translation part of my brain
[22:38] <adelie42> Is 'Target directory already exists, but does not have a valid .bzr directory.' normal for a first push just to inform the user that there has never been a push to that directory before?
[22:41] <albertico> ianto, many thanks!  going to start reading and watching the tutorials  :)
[22:42] <ianto> albertico: Have lots of fun
[22:59] <RainCT> NCommander: copyright should be OK if you've listed everything
[23:00] <NCommander> Thanks
[23:00] <RainCT> NCommander: and whether I think if it's good to upload, I do think so if you do :P
[23:01] <RainCT> and your previous upload has also got an advocate from someone else
[23:01] <RainCT> I'm off now, good night :)
[23:02] <binarymutant> is there a pidgin team?