[00:08] <SEJeff> Questions for lucid
[00:08] <SEJeff> Would it be possible to 1) Get the latest libproxy (0.4) into Lucid and 2) Get a MIR for it?
[00:09] <SEJeff> It fixes a ton of bugs and I personally know the upstream lead developer
[00:12] <persia> You don't need an MIR: libproxy is in main.  MIR is just for transitioning between "universe" and "main"
[00:13]  * persia looks forward to when the distinction no longer exists
[00:13] <SEJeff> persia, Ah ok. Would it be possible to get the latest in for Lucid?
[00:13] <SEJeff> As 0.2.3 is a pretty old version and has many fixed bugs
[00:14] <persia> Doing the update is potentially possible, but Needs someone to test and investigate, and if it's likely to break anything, will probably be rejected.
[00:14] <SEJeff> persia, Ok I'm willing to test and have av, a buddy who is an UD and DD who will help me
[00:14] <persia> It looks to me like you'd want to test the python bindins, and the interaction with libsoup-gnome2.4-1
[00:15] <SEJeff> What is the best way to go about this? I'll be working directly with upstream
[00:15] <SEJeff> Well it changed from c to c++, but the bindings and api are identical
[00:15] <persia> That's the kind of change that's hard to review, and makes it more difficult to get approved.
[00:16] <persia> I'd recommend contacting pochu in #ubuntu-desktop for guidance on a test strategy, etc.  Something that works for some folks is to do a test transition in a PPA and test against that.
[00:16] <SEJeff> persia, How about "Upstream suggests you upgrade to fix the bugs and support the package in the future"? Especially in a LTS?
[00:16] <SEJeff> persia, Perfect. Thanks
[00:17] <persia> SEJeff: Well, it depends.  It's a risk/reward analysis.  I personally like to follow upstream advice, but you really want to work with the Desktop team to come to a safe conclusion.  If there's some end-user software that doesn't work and needs porting, that might be more than we can accomplish in time.
[00:17] <SEJeff> persia, Absolutely understood
[00:17] <persia> If the ABI is truly unchanged, it ought be a fairly easy discussion.  If the ABI changed but the API didn't, not so much worse.  if the API changed, that's more complicated.
[00:17] <persia> Good luck.
[00:19] <SEJeff> persia, I'm not 100% sure, but I don't think it is ABI compatible. The API is the same however
[00:19] <SEJeff> Just a few rebuilds and we're on our merry way
[00:19] <persia> Looks like just a rebuild of the python bindings and libsoup-gnome2.4 to me, but again, it's really a Desktop Team decision.
[00:20] <persia> (and that's one of the areas of Ubuntu which I track the least)
[00:20] <SEJeff> persia, Thanks a bunch for the pointers
[00:20] <SEJeff> pochu left right after I pinged him. Must be busy :)
[00:21] <persia> Well, and it's 2am there :)
[00:21] <SEJeff> sleep is for the weak
[00:31] <SEJeff> pochu, Do you have a minute or two?
[00:32] <persia> SEJeff: You really want to ask in the other channel, as other people who idle there may also be interested.  It's also better to just ask the question rather than asking to ask.
[00:33] <SEJeff> persia, Ok
[00:53] <quidnunc> I have a package that uses OCAML_ABI in rules and it is incorrect. I can't find out how it is set. What sets it?
[02:14] <nigelb> persia: I finally got that boa thing fixed :)
[02:14] <nigelb> took me a lot of pain to get the X stuff working but it was worth the trouble learning that stuff :)
[03:39]  * Zarel places an offering on the offering of the Ubuntu MOTUs.
[03:39] <Zarel> altar*
[03:39] <Zarel> But anyway.
[03:39] <Zarel> I was wondering.
[03:39] <Zarel> I noticed the icon here was outdated: http://blackhalt.files.wordpress.com/2009/12/ubuntu-software-center.png
[03:40] <Zarel> I was wondering who I would contact to get it updated.
[04:10] <paissad_> guys, i 've uploaded temporary a deb package (foo) in my personal repository .. & i don't want other people who already have my repository in their sources.list to download "foo" when the version of "foo" is higher than an official ubuntu/debian repository
[04:11] <paissad_> i have to do a sort o pinning if i understand correclty ...
[04:11] <paissad_> sort of*
[04:18] <Zarel> No MOTUs at this time of day? :|
[04:18] <Zarel> I guess I'll try morning.
[04:20] <RAOF> Zarel: You'd contact people by filing a bug.
[04:20] <RAOF> That's the general way to have changes made.
[04:23] <Zarel> RAOF: Link to a tracker?
[04:23] <RAOF> launchpad.net
[04:24] <RAOF> Or, run “ubuntu-bug warzone”, I think.
[04:24] <RAOF> (Or whatever the package name is.)
[04:24] <RAOF> Hm.. getdeb?
[04:25] <Zarel> What does getdeb have to do with Ubuntu repositories? o_O
[04:25] <RAOF> Indeed!  The version of warzone in that screenshot isn't from the Ubuntu repositories; it's from getdeb.
[04:26] <Zarel> ...really?
[04:26] <RAOF> Check out the version.
[04:26] <Zarel> Oh, I see.
[04:26] <Zarel> Thanks.
[04:27] <RAOF> :)
[04:27] <Zarel> Can you check to see if the one in the Ubuntu repositories has the updated icon?
[04:27] <Zarel> New one looks like this: http://developer.wz2100.net/browser/trunk/icons/warzone2100.large.png
[04:27] <Zarel> (I don't have an Ubuntu partition around to check)
[04:29] <Zarel> Well, it appears launchpad is still using the old icon, too.
[04:29] <Zarel> https://launchpad.net/warzone2100
[04:30] <Zarel> Time to go further upstream and see if Debian needs to be yelled at. :P
[04:30] <RAOF> Zarel: Software centre uses the new icon.
[04:31] <Zarel> Man, Launchpad is _really_ out of date
[04:31] <Zarel> https://launchpad.net/warzone2100
[04:31] <Zarel> Latest version 2.1 RC2? o_O
[04:32] <RAOF> You'd need to take that up with the owner of that project; it's not Ubuntu.
[05:18] <kamalmostafa> hi motu's -- Does bug 521190 need an actual FFe?  This sync would fix an FTBFS in a package that has never built successfully in Lucid.
[05:19] <kamalmostafa> I think it qualifies as a "bug fix only update"
[05:41] <rawang> hi, why i type "debuild -S". it just generate a new tarball, but not a orig tarball + diff.gz?
[05:51] <RAOF> rawang: debuild -S shouldn't generate a new tarball; it should use the existing orig tarball and put the diff in .diff.gz.
[05:52] <RAOF> rawang: If you don't have an existing orig tarball, there's no way for debuild to work out what should be in the orig tarball & what should be in the diff.
[08:14] <sgnb> randomaction: did you see my note about gmetadom / lablgtkmathview?
[08:15] <randomaction> yes, I'll rebuild lablgtkmathview when gmetadom is synced
[08:16] <randomaction> this transition looks much easier now that I have a mass-rebuild script :)
[08:17] <dholbach> good morning
[08:18] <randomaction> good morning dholbach
[08:18] <dholbach> hi randomaction
[09:52] <shadeslayer> whats the difference between pbuilder and debuild?
[09:53] <shadeslayer> both of them create .debs,one in a chroot environment other in the users own machine
[09:53] <shadeslayer> so whats the basic difference
[09:57] <alkisg> shadeslayer: as I understand it, using a clean chroot environment is better because you might find out that you haven't declared the correct dependencies for your application
[09:57] <Rhonda> shadeslayer: debuild does in your current system, pbuilder uses a chroot environment and builds in there.
[09:57] <alkisg> And if you happened to have them in your own machine, debuild wouldn't "tell" you that
[09:57] <shadeslayer> alkisg: thats the only diff?
[09:58] <Rhonda> shadeslayer: The basic difference is exactly what you wrote. :)
[09:58] <alkisg> shadeslayer: no, I'm sure there are lots of other differences.
[09:58] <shadeslayer> Rhonda: ok,i just wanted to know  if theres any other difference
[09:58] <shadeslayer> c_korn: oh hi :)
[09:58] <c_korn> hello shadeslayer
[09:58] <shadeslayer> alkisg: so which is preffered?
[09:58] <Rhonda> shadeslayer: Usually you want to build for a specific target, like lucid. Your system though might run karmic. So you do _need_ a chroot for building for lucid.
[09:58] <shadeslayer> -f
[09:59] <shadeslayer> Rhonda: oh.. and also debuild just build for 64 bit or 32 bit depending on your machine
[09:59] <shadeslayer> i guess pbuilder makes .debs for all systems
[10:00] <shadeslayer> i have a slow internet connection so i only use debuild
[10:00] <Rhonda> It's prefered to build inside such a chroot for various reasons: It also requires proper Build-Depends whare with debuild you can't be sure wether you have the packages "just installed".
[10:00] <shadeslayer> hmm
[10:00] <Rhonda> Not sure what you mean with "for all systems".
[10:00] <shadeslayer> Rhonda: 32 bit,64 bit,lpia
[10:01] <Rhonda> There is no difference with debuild/pbuilder with respect to internet connection.
[10:01] <Rhonda> Erm, no, you don't build for 32 and 64 bit in pbuilder.
[10:01] <Rhonda> You build for the same system that your system is, you don't cross-compile.
[10:01] <shadeslayer> ah
[10:02] <alkisg> What does "dpkg-source: unrepresentable changes to source" mean? That it can't represent the symlink I put in the sources? And if so, is there any way around it?
[10:02] <Rhonda> shadeslayer: pbuilder really is just a "clean" build for a specific target, well defined.
[10:02] <slytherin> alkisg: No it can't represent symlink. Why do you want to add symlink?
[10:03] <shadeslayer> Rhonda: ok
[10:03] <alkisg> slytherin: I have LTSP 5.2 as a starting point, and I put one plugin in the debian-plugins dir, and a symlink from ubuntu-plugins/file to debian-plugins/file (standard practice in ltsp source).
[10:04] <slytherin> alkisg: The question is 'what problem are you trying to solve by putting symlink'?
[10:05] <Rhonda> shadeslayer: And to confuse you even more, I would rather suggest cowbuilder (from the cowdancer package) instead of pbuilder. :)
[10:06] <shadeslayer> Rhonda: 0_o
[10:06] <Rhonda> It's more friendly to your harddisk, and if you have low I/O. pbuilder works with tarballs it extracts all the time, cowdancer just creates hardlink trees and uses copy-on-write (thus cow) facilities.
[10:07] <alkisg> slytherin: I'm trying to add a new feature (=plugin). That feature is common to both debian and ubuntu, so (as usual in LTSP) I need to put the file in the debian-plugins dir and symlink it to the ubuntu-plugins dir. I don't know how else to answer the "what problem are you trying to solve by putting symlink" question...
[10:07] <shadeslayer> Rhonda: but it still downloads all the build depends like pbuilder
[10:08] <Rhonda> Then don't do an apt-get clean. :)
[10:08] <slytherin> alkisg: Ok. Now think aboout it this way. If the feature is common to both Debian and Ubuntu, do you need to have it in two separate folders?
[10:09] <alkisg> slytherin: see the tree in http://paste.ubuntu.com/384259/
[10:10] <alkisg> There are lots of symlinks there in the original tarball
[10:10] <alkisg> So I just want to add another plugin like the 100 existing plugins, by following the same practice...
[10:11] <alkisg> slytherin: the symlink practice is for both the debian + ubuntu developers to maintain the same code
[10:11] <alkisg> The different folders practice is for each distro to have its own plugins
[10:12] <alkisg> And all folders are shipped in the tarball/deb because one might want to make a cross-distro chroot...
[10:12] <slytherin> alkisg: The issue is that your modifications will end in diff.gz and the symlink is not representable in that file. What you can try is convert the package in source 3.0 format. In that case the packaging files are archives in a tar.gz which may be able to encapsulate a symlink.
[10:13] <slytherin> got to go now. I hope someone else will be able to help.
[10:13] <alkisg> Got it. So I'd need to create a new source tarball in any case
[10:13] <alkisg> Thank you
[10:14] <shadeslayer> arddisk, and if you have low I/O. pbuilder works with tarballs it extracts all the time, cowdancer just cre
[10:14] <shadeslayer> geh
[10:15] <alkisg> If a build failed, can I upload the same version to launchpad? Or do I have to increase the debian/changelog?
[10:16] <shadeslayer> c_korn: btw what does this mean ? : E: joschy source: not-binnmuable-all-depends-any libjoschy-dev -> libjoschy1
[10:18] <Rhonda> shadeslayer: From a Ubuntu point of view you can ignore that because Ubuntu doesn't do binNMUs. When it comes to Debian though …
[10:18] <c_korn> shadeslayer: you can run lintian -i *.dsc to see a more detailed description of the problem. mostly also with a fix proposal.
[10:18] <geser> alkisg: once LP knows about a version (independent if it build or not) you need to bump it for a new upload
[10:19] <alkisg> Thank you geser
[10:22] <shadeslayer> c_korn: so if i change Architecture: any in the third stanza to all itll work right
[10:25] <Rhonda> shadeslayer: erm, I highly doubt that that will be proper.
[10:26] <Rhonda> shadeslayer: Because the library files most probably are architecture dependent and thus can't be arch:all
[10:28] <Rhonda> It is more suiting to set the -dev package to arch:any, and I'm not sure if there is any -dev package that is _not_ arch:any
[10:30] <Rhonda> hmmm, but there are.
[10:31] <shadeslayer> Rhonda: so,what do you suggest?
[10:31] <Rhonda> Ah. shadeslayer, if you want to have the -dev package Arch:all you need to make it Depend on libjoshy1 (>= ${source:Version}) instead of (= ${source:Version})
[10:31] <shadeslayer> ill just pastebin the control file
[10:31] <shadeslayer> oh ok
[10:33] <shadeslayer> Rhonda: http://pastebin.ca/1811608
[10:33] <shadeslayer> ill be back in like 10 mins..
[10:35] <Rhonda> shadeslayer: Should fit, binary:Version or source:Version doesn't matter in that case because it's just the same at the time the all package is generated, but source:Version would be more correct. :)
[10:53] <shadeslayer> Rhonda: like : http://paste.ubuntu.com/384278/ ?
[10:54] <Rhonda> No. Arch:all in the libjoshy1
[10:54] <Rhonda> That should be Arch:any there
[10:54] <shadeslayer> oh yeah right
[10:55] <shadeslayer> http://paste.ubuntu.com/384283/
[10:55] <shadeslayer> i guess thats correct then?
[10:55] <Rhonda> And about Maintainer field, that's you I expect? Where do you plan to upload it to?
[10:55] <Rhonda> Looks correct, yes.
[10:55] <shadeslayer> Rhonda: my PPA
[10:56] <shadeslayer> Rhonda: i dont have a @k/ubuntu.com email id ;)
[10:56] <shadeslayer> i want one though :P
[10:57] <Rhonda> Me neither.
[10:57] <Rhonda> What's @k?
[10:58] <hyperair> kubuntu
[10:59] <shadeslayer> Rhonda: like rohangarg@kubuntu.org ;)
[11:00]  * Rhonda is happy with @debian.AT (instead of .org, they won't change my "login")
[11:00] <shadeslayer> Rhonda: this is what ill be using : http://paste.ubuntu.com/384287/
[11:00] <shadeslayer> Rhonda: nice :0
[11:00] <shadeslayer> *:)
[11:00] <Rhonda> What for do you use debhelper >= 7.0.50~? Any special feature?
[11:01] <shadeslayer> Rhonda: yeah debuild -S -sa printed out that error
[11:01] <shadeslayer> Rhonda: more of a warning :P
[11:01] <Rhonda> Especially since I don't find that version mentioned in a changelog?
[11:02] <Rhonda> 7.0 only went to .17?
[11:02] <Rhonda> Oh, wait, found it
[11:02] <shadeslayer> Rhonda: found what?
[11:03] <Rhonda> The changelog and the reason why one would want to use that. :)
[11:03] <shadeslayer> Rhonda: this is the intial release...
[11:03] <shadeslayer> Rhonda: well c_korn just told me what had to be done,im yet to learn why we did that :P
[11:04] <Rhonda> Yeah, perceived that part. :)
[11:04] <shadeslayer> Rhonda: its my first library... so im all in for suggestions ;)
[11:04] <shadeslayer> libs are difficult :P
[11:05] <shadeslayer> Rhonda: i can package small apps fine..
[11:05] <Rhonda> Right, I dumped the two library packages that I had over the time and I'm sure I made a lots of mistakes therein.
[11:05] <shadeslayer> :D
[11:06] <Rhonda> Actually, thinking about, I still maintain sort-of a library. It surely is totally wrong. But only a single package of mine is using it.
[11:06] <shadeslayer> Rhonda: well im just doing this so that there are no suprise questions for me tommorow in the packaging session
[11:07] <Rhonda> Oh, so you are heading for MOTU at fullspeed? :)
[11:08] <shadeslayer> Rhonda: :D
[11:08] <Rhonda> All the best wishes on that. :)
[11:08] <shadeslayer> Rhonda: more like kubuntu member at full speed :P
[11:08] <shadeslayer> doing upstream work and bug triaging in lp :P
[11:08] <Rhonda> I'm still not sure wether I should take that step at this point in time.
[11:09] <Rhonda> I sorta postpone that thought to at least summer, maybe even fall.
[11:09] <shadeslayer> Rhonda: hmm.. well im gaining experience... so meh..
[11:10] <shadeslayer> Rhonda: i also do irc support on #kubuntu ;)
[11:11] <Rhonda> I don't want to sound arrogant, but experience is not the piece I ponder about. ;)
[12:11] <nigelb> duanedesign: See if you've got all the package tools from https://wiki.ubuntu.com/PackagingGuide/Complete . If you do you're good to go
[12:12] <nigelb> duanedesign: I suggest you start creating a pbuilder now, coz thats going to take some time.  In the meanwhile you can get the source and make changes :)
[12:13] <shadeslayer> duanedesign: for pbuilder choose a mirror near you,its *much* faster
[12:13] <nigelb> yes, that too ;)
[12:14] <nigelb> duanedesign: and ask here generally, lots of people will reply (as I learned :) )
[12:15] <shadeslayer> duanedesign: you can just copy the pbuilderrc file from http://pastebin.ca/1811712 << change the mirror to a local one ;)
[12:16] <shadeslayer> duanedesign: also the debmail.. :P
[12:16] <nigelb> shadeslayer: shouldn't the distribution be lucid?
[12:16] <shadeslayer> nigelb: i created it for karmic ;)
[12:17] <nigelb> ah :)
[12:17] <shadeslayer> duanedesign: well if your packaging for lucid change the distro to lucid :P
[12:27] <duanedesign> thank you shadeslayer
[12:40] <shadeslayer> duanedesign: sure no problem
[12:57] <shadeslayer> duanedesign: ill probably be holding a PPA session tommorow at 1700 UTC,you can attend if you want ;)
[12:58] <duanedesign> shadeslayer: in #ubuntu-classroom?
[12:58] <shadeslayer> duanedesign: yes :)]
[12:59] <shadeslayer> duanedesign: oh its confirmed : http://people.ubuntu.com/~nhandler/classroom.html
[13:01] <shadeslayer> dholbach: a one hour session? isnt that a bit big?
[13:02] <shadeslayer> dholbach: i was thinking more on the lines of a 30 min session :P
[13:02] <nigelb> shadeslayer: you can stop early
[13:03] <shadeslayer> nigelb: hehe :)
[13:03] <shadeslayer> nigelb: btw theres a command to authourize uploading to your PPA right? i keep forgeting that :P
[13:03] <nigelb> ugh, wait, I saw that a few days back
[13:05] <nigelb> shadeslayer: dput
[13:05] <shadeslayer> nigelb: nah.. its something with ubuntu-dev-tools
[13:07] <nigelb> shadeslayer: nothing in dev tools https://wiki.ubuntu.com/UbuntuDevTools
[13:07] <shadeslayer> nigelb: http://pastebin.ca/1811767
[13:08] <nigelb> shadeslayer: that is because you get to mark set-lp-dup etc
[13:09] <shadeslayer> nigelb: whut?
[13:09] <nigelb> shadeslayer: a couple of dev tools work directly with lp and need permission, I feel that is because of that
[13:10] <shadeslayer> nigelb: yes,and theres a specifc command for that...
[13:10] <shadeslayer> hold one
[13:27] <persia> kamalmostafa1: Use your best judgement on when something needs an FFe.  If you don't have one and a sponsor thinks you do, you'll be corrected.  If you apply for one and the release team thinks you shouldn't have done so, you'll be corrected.  Along the way, you'll learn the best balance.  If you're unsure, err on the side of bothering the sponsors over bothering the release team (but really try best before submitting to either queue).
[13:38] <nigelb> Any python experts can take a look at failure to build I fixed? bug 527084
[13:38] <nigelb> oh hai persia :)
[13:38] <hakaishi> Hi, is there a way to build multiple packages with different versions out of one source? (I know how to build multiple packages, but they get all the same version number...)
[13:39] <persia> hakaishi: Yes, but you really, really, really, really don't want to do that unless you know so much about how the archive works that you can be absolutely certain there isn't a better way to address the issue.
[13:39] <persia> What problem are you trying to solve?
[13:39] <shadeslayer> hakaishi: this is for a PPA?
[13:39] <hakaishi> shadeslayer: no, it's for debian
[13:40] <shadeslayer> hakaishi: ah no idea then ;)
[13:41] <persia> shadeslayer: Why is the answer different depending on the target archive?
[13:41] <hakaishi> persia: isn't there a simple way to do this in the changelog file?
[13:41] <persia> hakaishi: No, but like I said, you don't want to do it anyway, really.
[13:41] <persia> Again, what problem are you trying to solve?
[13:42] <nigelb> hakaishi: It would help if you mentioned why you want to do it this way.
[13:43] <hakaishi> persia: I have two similar programs, that I want to put in one tarball, but they have two different version numbers...
[13:44] <persia> hakaishi: Are they two different upstreams?
[13:44] <hakaishi> öhm... no
[13:46] <hakaishi> originally I wanted to make two program with each one package, but my Sponsor meant that it would be better to put them in one tarball...
[13:47] <persia> OK.  Is there a really, really good reason why the next release of both programs (which would be that tarball) shouldn't end up with both version numbers bumped to the same value?
[13:48] <hakaishi> -.- I guess not. I just wanted to know if there is a way...
[13:49] <persia> hakaishi: There is.  Don't use it :)
[13:49] <Rhonda> There is. If you have to ask for it you know to little about it to use it. :)
[13:50] <hakaishi> persia: XD okay
[13:50] <hakaishi> Rhonda: -.-'
[13:50] <shadeslayer> Rhonda: is there some kind of command to authorize ubuntu-dev-tools to upload to a PPA?
[13:50] <shadeslayer> or can i upload directly?
[13:50]  * Rhonda unfortunately doesn't know much about PPA or ubuntu-dev-tools yet. :)
[13:50] <persia> Well, or rather, the chances of making a mistake that one can't get out of is high enough that it's generally not safe to use it unless there is no other option (and even the best of us ought have a high level of peer review before using it)
[13:50] <shadeslayer> aw..
[13:51]  * shadeslayer wonders if persia knows...
[13:51] <persia> shadeslayer: ubuntu-dev-tools ought be completely unrelated to PPAs.  If you have authorisation issues, ask in #launchpad.
[13:51] <shadeslayer> persia: they dont have a idea :P
[13:51] <Rhonda> shadeslayer: If you have general questions like these, just ask them regularly without hilighting anyone in particular. It might turn out that someone knows the answer, and the people you hilight might feel being singled out if it's a general question. :)
[13:52] <shadeslayer> any idea about authorizing ubuntu-dev-tools on LP?
[13:52] <persia> shadeslayer: If #launchpad doesn't understand PPAs, wait.  They know more than us.
[13:53] <shadeslayer> afaik : http://pastebin.ca/1811767 : is needed,but i dont remember the command i used
[13:53] <Rhonda> hakaishi: I am packaging for Debian since 10 years with well over 30 source packages that I touched - I hadn't had a single need to use different version numbers for binary packages built from a source. Go figure. You might be trying to fix the wrong issue with the wrong approach. :)
[13:53] <persia> shadeslayer: Really, you need to ask in #launchpad.
[13:53] <shadeslayer> persia: ok
[13:53] <shadeslayer> persia: btw launchpad said i need to ask here :P
[13:53] <persia> shadeslayer: Or file a question against launchpad.  That paste is unrelated to the clients.
[13:54] <hakaishi> Rhonda: okay, thank you
[13:54] <persia> shadeslayer: Then they were wrong.  Please give me the timestamp of the redirect, and I'll sort it.
[13:54] <shadeslayer> persia: 18:52 < wgrant> shadeslayer: ubuntu-dev-tools help is more likely in #ubuntu-motu.
[13:55] <shadeslayer> since the authorization refers to ubuntu-dev-tools
[14:38] <duanedesign> followiing the guide for generating a patch at /Bugs/HowtoFix i noticed in the command to create a patch file that ' xicc_0.2.2ubuntu1.debdiff' is used instead of ' xicc_0.2-2ubuntu1.debdiff'
[14:39] <duanedesign> changing the '-' to a '.', is that correct?
[14:39] <persia> Doesn't matter in the least bit.
[14:39] <duanedesign> persia: thank you
[14:39] <persia> Personally I liked revision 16 of that page, and intend to go put it back that way sometime in the next couple months.
[14:40] <persia> creating a debdiff is the *wrong* way to do it if you're just fixing a bug, because most bugfixes need the patch extracted back out of the debiff to send upstream anyway.
[14:40] <persia> Mind you, a debdiff is a good way to request a sponsored upload, so it's not entirely wrong to suggest doing them somewhere.
[14:48] <duanedesign> persia: good point. You anticipated my next question
[14:48] <duanedesign> persia: i am working on bug 497923
[14:50] <Laney> That's really the kind of thing that should be fixed upstream directly.
[14:50] <duanedesign> so what would be the proper way to fix the bug to allow sending it upstream
[14:50] <Laney> branch from their VCS, hack, test, send patch
[15:04] <debfx> the debian virtualbox-ose package has introduced a new binary package (virtualbox-ose-fuse) in 3.1.4
[15:05] <debfx> I want to merge 3.1.4 (ubuntu currently has 3.1.2) to lucid. should I remove the virtualbox-ose-fuse package for now?
[15:37] <kamalmostafa> persia: thanks for your comment about FFe's -- sounds like i left it in the right state then (subscribed to u-u-s, since I think it doesn't need FFe) -- we'll see what happens
[16:07] <hyperair> when a package in binary-dep is removed from the archives, do we shift it from Depends: to Recommends: or Suggests:?
[16:08] <juli_> Hi everybody!
[16:09] <hyperair> hello
[16:09] <geser> hyperair: why not remove it all as we can't satisfy it anyways (independent on if it's depends, recommends or suggests)?
[16:09] <hyperair> geser: i think it's a temporary thing.
[16:10] <hyperair> geser: this is an ubuntu-specific change for boa-constructor, since pychecker which exists in debian has been removed from lucid
[16:10] <randomaction> hyperair: then you can note it in changelog
[16:10] <hyperair> it depends on python2.5, see?
[16:10] <juli_> I want to localize netbeans package but don't want to create new packages (like openoffice does).. is it acceptable to include localized files in the existing package via patch?
[16:11] <hyperair> randomaction: noting it in the changelog is besides the point. i want to know what's the preferred course of action, with regard to package installation behaviour
[16:11] <geser> hyperair: so you prefer to have an uninstallable recommends instead of an installable depends?
[16:11] <geser> hyperair: we can undo this change later when the package comes back (either with a new upload or a sync)
[16:11] <hyperair> geser: well, if it was previously in depends, it would mean the package was pretty important, and should be installed by default if at all possible, yes?
[16:11] <hyperair> http://launchpadlibrarian.net/39783936/boa-constructor_0.6.1-9ubuntu1.debdiff
[16:11] <hyperair> the debdiff is there
[16:12] <hyperair> i'm just wondering whether it should be in Recommends rahter than Suggests
[16:12] <hyperair> if Suggests is the way to go then i'll sponsor it
[16:12] <hyperair> nigelb: i think this concerns you.
[16:12] <hyperair> nigelb: which do you think would be better?
[16:13] <randomaction> hyperair: I agree that it's best to remove it completely
[16:13] <hyperair> LP #527084 for reference
[16:13] <geser> hyperair: and what do you can by moving it to recommends? that package won't magically reappear
[16:13] <hyperair> geser: er i don't know, maybe it might reappear from some third party repository
[16:14] <hyperair> geser: or since python2.6 is undergoing transition in debian right now, maybe pychecker will be fixed up nicely and reuploaded to lucid?
[16:14] <nigelb> hyperair: yes
[16:15] <nigelb> hyperair: boa constricutor is already patched up to work without pycheker
[16:15] <geser> hyperair: I have my doubts that it will reappear in lucid
[16:15] <nigelb> I read the source
[16:15] <nigelb> hyperair: I'm hoping someone would work to get it to not depend on python 2.5
[16:16] <hyperair> nigelb: well you could always do that, right? =p
[16:17] <nigelb> hyperair: my knowledge it too shallow for that, or I would have tried
[16:17] <geser> hyperair: and as boa-contructor is maintained by a MOTU and DD, I'd at least talk to DktrKranz before uploading it
[16:17] <hyperair> geser: hmm right. good idea.
[16:17] <nigelb> hyperair: but, if you're willing to help and it is manageable I'm willing to put the effort
[16:18] <hyperair> nigelb: i provide no guarantees, but if you're going to make it installable with python2.6, how about contacting the debian python team?
[16:19] <nigelb> hyperair: I'll check out 2morrow (me is about to leave for work)
[16:19] <nigelb> hyperair: btw, is the workflow correct? what I did... moving to suggests
[16:20] <hyperair> nigelb: well, i'm not really sure. i haven't dealt with rdeps of packages removed from ubuntu before..
[16:20] <hyperair> nigelb: like geser said, it's probably better off removed from Suggests even
[16:20] <nigelb> hyperair: oh
[16:21] <hyperair> nigelb: and we should wait for DktrKranz's input, since he maintains it in debian as well. =)
[16:21] <nigelb> hyperair: lemme know if you want me to change something in the debdiff :)
[16:21] <hyperair> nigelb: sure
[16:24] <nigelb> hyperair: DktrKranz is pretty sharp :)
[16:24] <hyperair> ?
[16:24] <nigelb> hyperair: I think he made those changes to the source to make sure it works without pychecker :)
[16:25] <hyperair> perhaps
[16:25] <nigelb> I'm not sure though.  the source is synced from debian
[16:25] <hyperair> he maintains it there
[16:25] <juli_> geser, may be you know? what is localization politics in packaging? Is it acceptable to include all localized files in the package of the application or I have to create a new one for each language?
[16:27] <geser> juli_: don't know of any localization policies. so you can include them in the package itself (but you might split them off into an own arch-indep package if they are large)
[16:30] <micahg> \sh: are you planning on uploading zf 1.10.2?
[16:30] <juli_> geser, thanks! I'm not sure about "large".. in terms of NetBeans they are small:) How do you think I can do this now, after FF? I want to add a patch with the sources for localization and build them right after IDE
[16:30] <hyperair> nigelb: by the way, the right way of marking the bug as "done and awaiting sponsors" is to leave yourself assigned and mark status as "confirmed" or "triaged"
[16:31] <nigelb> hyperair: thank you.  I wasn't sure of that.  Sorry ;)
[16:31] <hyperair> np =)
[16:32] <geser> juli_: adding a patch should be no problem, and adding localization probably doesn't count as a new feature
[16:36] <juli_> geser, thanks!
[16:39] <\sh> micahg: somehow yes :) I'm a bit busy with work...but wanted to do the package during this weekend...and as it is a bugfix release, I don't even need an FFe
[16:39] <micahg> \sh: cool, yeah, I was wondering about the FFe
[16:39] <micahg> \sh: I'll keep an eye out
[16:40] <\sh> micahg: hehe :) thx for the backports :) and yes, we get the latest Zend crack in ;)
[17:08]  * hyperair has sponsored his first package! \o/
[17:09] <DktrKranz> hyperair: it doesn't make much sense to leave pychecker in Suggests if it has been removed from Lucid, I'd say drop it and also exclude ExternalLib/pychecker_custom.py from the resulting package. Other part of the code already handles missing pychecker module.
[17:10] <hyperair> DktrKranz: would you like to take care of it or let nigelb handle it?
[17:10] <DktrKranz> either way is fine to me
[17:10] <hyperair> perhaps you should talk to him directly. maybe drop a message on the bug report =)
[17:11] <DktrKranz> I won't change it in Debian for the time being, it will be probably material for Squeeze + 1
[17:11] <DktrKranz> (in Debian we're close to drop 2.4 :)
[17:11] <MTecknology> Is it possible to make a patch that replaces a binary file?
[17:13] <geser> MTecknology: yes, in v3 it's easy, in v1 you have do uuencode it
[17:14] <MTecknology> geser: is there a howto anywhere for it?
[17:14] <DktrKranz> hyperair: commented
[17:14] <hyperair> =)
[17:14] <geser> for which case v3 or v1? (I don't know of any for either case)
[17:15] <MTecknology> ok, I'll look around - v3
[17:15] <hyperair> geser: you can in v3?
[17:15] <leonel> hello .. I'm porting a package from git.debian.org  to karmic  with  git-buildpackage  and I get this error :   http://paste.ubuntu.com/384497/    but the an in the file  debian/source/include-binaries  there is the file    debian/powered_by_debian.png    help!!!!!
[17:15] <hyperair> geser: i know you can put the binary file in the debian.tar.gz, and manually copy it over, but as a patch?
[17:16] <geser> you are probably right, but with v3 it's much easier to get a new binary file into the debian.tar.gz
[17:17] <randomaction> hyperair, MTecknology: you just replace the file, and list it in debian/source/include-binaries
[17:17] <hyperair> randomaction: ooh interesting.
[17:18] <randomaction> I've never done it, but man dpkg-source says so
[17:18] <MTecknology> thanks :)
[17:20] <hyperair> leonel: where is this package and what exactly does debian/source/include-binaries say?
[17:20] <ScottK> leonel: You need to make sure you have it as a version 3 source package.
[17:20] <hyperair> leonel: actually take a look at this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554612
[17:21] <hyperair> you got truncated.
[17:21] <leonel> hyperair: leonel@vaio:/tmp/c/cherokee/debian/source$ more include-binaries
[17:21] <leonel> debian/powered_by_debian.png
[17:21] <hyperair> http://people
[17:22] <leonel> ScottK:  Hello  .. Long time no ircing ..   version 3 .. checking
[17:25] <leonel> hyperair: that's all the contents for  include-binaries
[17:28] <leonel> ScottK: dpkg-source: info: using source format `3.0 (quilt)'
[17:28] <ScottK> Yeah, that's good
[17:29] <leonel> so I guess I've been bitten by the debian bug 554612 ,,
[17:31]  * hyperair kicks git-buildpackage for not supporting source v3.
[17:32] <hyperair> damnit where's that new shiny git-buildpackage?
[17:33] <leonel> hyperair: what version ??
[17:34] <randomaction> hyperair: it's being merged, bug 525116
[17:34] <hyperair> oh it has?
[17:34] <hyperair> i mean being merged
[17:35]  * hyperair looks
[17:37] <leonel> hyperair: so upgrade to lucid  then do the backports ??
[17:37] <hyperair> leonel: yes, i suppose.
[17:39] <leonel> hyperair , scottk  thanks
[17:44] <shadeslayer> hmm
[17:45] <shadeslayer> so whats the difference b/w indep binary and multiple binaries?
[17:45] <shadeslayer> c_korn: are you free in 20 mins?
[17:46] <c_korn> shadeslayer: I am already here and also will be here in 20 mins
[17:46] <shadeslayer> c_korn: ok :)
[17:46] <shadeslayer> i just need to upload some stuff and then you can start explaining to me what we did yesterday :P
[18:27] <shadeslayer> i can define Section: multimedia in control right?
[18:31] <geser> check the Debian policy manual for all valid sections (I don't know them from top of my head)
[18:32] <c_korn> shadeslayer: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[18:36] <Rhonda> shadeslayer: I can't remember an multimedia section, but http://packages.ubuntu.com/lucid/ (the trailing / is important) should have all the sections listed. :)
[18:36] <Rhonda> There are sound and video sections.
[18:37]  * Rhonda . o O ( and the sorting of that page in languages other than English is *horrible* )
[18:38] <shadeslayer> Rhonda: yeah,actually the section is kde :P
[18:38] <shadeslayer> compared it with another package :P
[18:38] <Rhonda> Don't confuse the package section with the category you would put the menu entry into. :)
[18:42] <shadeslayer> Rhonda: nah.. its a web browser... and this is a multimedia app
[18:43] <shadeslayer> i guess video suits it more
[18:47] <Rhonda> then it should be web
[18:47] <kreuter> persia: around?
[18:47] <Rhonda> shadeslayer: Did you read the description of the video section?
[18:48] <shadeslayer> Rhonda: hmm the official packagers made it kde..
[18:48] <shadeslayer> Rhonda: yeah
[18:48] <shadeslayer> Rhonda: its a desktop recording app
[18:48] <shadeslayer> so yeah it fits in video
[18:48]  * shadeslayer wonders what to do with the .pot files
[18:48] <Rhonda> If it's part of kde then I guess kde fits
[18:49] <Rhonda> Those are required for the translators
[18:49] <shadeslayer> yeah
[18:49] <Rhonda> You don't install them into the binary packages though.
[18:49] <shadeslayer> Rhonda: wierd thing : one of the pot file is in the tar ball but not in the extracted stuff
[18:50]  * sebner waves at Rhonda :)
[18:51] <shadeslayer> oh found it
[18:51] <shadeslayer> Rhonda: so do i delete that folder?
[18:53] <Rhonda> Folder?
[18:55] <kirkland> so i'm working on a package that uses pycentral for debian/rules, and I'm trying to add an empty transitional package
[18:55] <kirkland> when i do so, it zeros out my main binary .deb
[18:55] <kirkland> (i don't have a .install file)
[18:56] <kirkland> suggestions?  (besides "make a .install file")
[18:56] <Rhonda> kirkland: make a main-binary.install file.
[18:57] <Rhonda> Or reorder the sorting of the binary files in debian/control
[18:58] <kirkland> Rhonda: hmm, how so?  (reorder debian/control)?
[18:59] <kirkland> Rhonda: right now, the transitional is last, main-binary is first
[18:59] <Rhonda> If you don't have the files name $binpackage.install and the likes, debhelper puts stuff into the first binary it finds in debian/control. This might be your problem.
[18:59] <shadeslayer> Rhonda: the po folder... should i delete it?
[18:59] <kirkland> Rhonda: hmm, no, it's not doing that
[19:00] <Rhonda> shadeslayer: I wouldn't think so, that might kill translations
[19:00] <shadeslayer> Rhonda: so.. just leave it?
[19:00] <shadeslayer> or do i have to add a rule to install the translations
[19:01] <Rhonda> I would expect that make install would do so.
[19:02] <shadeslayer> hmm.. ok
[19:06]  * sebner feels ignored by Rhonda :P
[19:06]  * hyperair pets sebner 
[19:07] <sebner> only hyperair understands sebner
[19:07]  * sebner hugs hyperair 
[19:07]  * hyperair hugs sebner back
[19:07] <shadeslayer> c_korn: ready?
[19:08] <Rhonda> shadeslayer: I noticed your wave, but … what? :)
[19:08] <c_korn> Rhonda: sebner waved
[19:08]  * sebner still feels ignored by Rhonda :P
[19:08] <shadeslayer> Rhonda: oh c_korn will explain how we packaged the joschy lib
[19:09]  * Laney wonders how to type an ellipsis
[19:09] <c_korn> shadeslayer: I am ready
[19:09] <Rhonda> bleah
[19:09] <c_korn> Laney: just …
[19:09] <shadeslayer> c_korn: ok please explain step by step and slooowly
[19:09] <Laney> haha
[19:10] <hyperair> hmph
[19:10]  * sebner waves at Laney :=)
[19:10] <Laney> I don't have a key to do that
[19:10] <c_korn> Laney: altgr + .
[19:10] <Laney> ·.·.
[19:10] <Rhonda> sebner: I just maintain irssi, I did never claim that I'm fond of its regular tab completion fumbles. :)
[19:10] <Laney> ˙.·
[19:10] <Rhonda> Laney: …
[19:10] <Laney> ÷!
[19:10] <hyperair> with composekey it's supposed to be compose . .
[19:10] <Laney> nope
[19:11] <hyperair> but since hardy or smoewhere around there, some of the combinations disappeared.
[19:11] <hyperair> this one including
[19:11] <hyperair> =(
[19:11] <sebner> Rhonda: GUI, especially GNOME and GTK ftw! ;)
[19:12] <Rhonda> sebner: TUI, especially screen ftw! ;)
[19:12] <sebner> lame
[19:12] <Laney> KUI forever
[19:12] <Rhonda> I don't think so.
[19:12] <hyperair> screen ftw.
[19:12] <shadeslayer> sebner: well if gnome pulls docky off.. ill switch to gnome
[19:12] <Laney> I am just reinstalling Lucid right now
[19:12] <Laney> I think I'll try xmonad instead of metacity
[19:13] <hyperair> xmonad sounds like...
[19:13] <hyperair> ... i dunno, gonads or something
[19:13]  * hyperair puts away the biology textbook
[19:13] <sebner> shadeslayer: heh, still in NEW NEW NEW
[19:13] <sebner> Laney: mutter!
[19:13] <hyperair> compiz!!!
[19:13] <shadeslayer> sebner: well as of now KDE just ricks
[19:13] <shadeslayer> *rocks
[19:14] <shadeslayer> :P
[19:14] <hyperair> ricks indeed= p
[19:14] <hyperair> what a rickety ol DE
[19:14] <sebner> shadeslayer: good joke :P
[19:14] <shadeslayer> hyperair: typo!
[19:14] <sebner> sure
[19:14] <sebner> ...
[19:14] <sebner> :P
[19:14] <hyperair> shadeslayer: ;-)
[19:14] <lbrinkma> I have a problem with my anjuta-extras package: I can't get away the lintian warning: pkg-has-shlibs-control-file-but-no-actual-shared libs. I've no idea how to solve that, please help me. You can get the package at https://launchpad.net/~lbrinkma/+archive/ppa
[19:14]  * shadeslayer throws chunks of his garden GNOME at sebner and hyperair 
[19:14]  * sebner ^5 hyperair 
[19:14]  * sebner hides
[19:15] <shadeslayer> sebner: you cant hide from the garden gnome ;)
[19:15]  * hyperair puts up a vertical trampoline.
[19:15] <hyperair> like whee bounce back at you =p
[19:15]  * sebner hides behind hyperair 
[19:15]  * shadeslayer projects kde plasma shield
[19:15] <sebner> shadeslayer: hyperair's mightyness will block it
[19:15] <shadeslayer> and were going OT :D
[19:16]  * hyperair puts up... hyper... air!
[19:16] <shadeslayer> c_korn: so...
[19:16] <shadeslayer> c_korn: i didnt mean this slowly :P
[19:16]  * hyperair gets banshee to start wailing.
[19:16] <c_korn> shadeslayer: ok
[19:17]  * shadeslayer gets out the amarok hammer and banishes banshee
[19:17] <hyperair> hammer passes through banshee since banshee is a ghost! =D
[19:17] <Laney> Banshee should start supporting the Last.fm 1.0 API again
[19:17] <c_korn> the first we grabbed the tarball and named it properly. package_version.orig.tar.gz because it does not have a version we choose to take the git date of the last commit.
[19:17] <Laney> that would make me very happy
[19:17] <sebner> hyperair: 1.5.4 ftw!
[19:18] <shadeslayer> c_korn: well the part after dh_make -e
[19:18] <sebner> Rhonda: ab sonntag bin ich wieder in wien :)
[19:18] <hyperair> sebner: agreed!
[19:18] <shadeslayer> c_korn: i know about the naming policies ;)
[19:18]  * hyperair tickles directhex
[19:18] <hyperair> directhex: when can we see an upload, o mighty DD? =D
[19:18] <c_korn> shadeslayer: ok, so after dh_make we removed the example files we did not need  (those debian/*.ex ones)
[19:19] <shadeslayer> c_korn: whats the use of those files? ( in one line :P )
[19:19] <sebner> hyperair: use your migthy powers for an ubuntu upload \o/
[19:19] <Laney> no
[19:19] <Laney> dont
[19:20] <sebner> Laney is the fun killer, as usual :P
[19:20] <Laney> :(
[19:20]  * sebner hugs Laney 
[19:20] <hyperair> killjoy ;-)
[19:20] <c_korn> shadeslayer: those are template files for files which have different purposes. the postinst file contains sh commands which get executed after the package has been installed for example. or the debian/watch file looks for new upstream versions
[19:20] <sebner> hyperair: killer fun?
[19:21] <hyperair> sebner: no, the more commonly used term is killjoy
[19:21] <Laney> you should be proud of your MOTU work if most of what you do is sync requests.......
[19:21] <sebner> hyperair: oh, /me makes a note but my dict says: fun killer  [coll.] is valid too :)
[19:21] <hyperair> Laney: heh. i sponsored my first package just now =D
[19:22] <Laney> good man
[19:22] <hyperair> sebner: it doesn't sound as nice =p
[19:22] <hyperair> Laney: are you on lucid?
[19:22] <sebner> hyperair: agreed
[19:22] <sebner> hyperair: me is
[19:22] <directhex> hyperair, sorry, i've been swamped at work this week. i have time this weekend
[19:22] <shadeslayer> c_korn: like if i want to add my ppa after somebody downloads my ppa,the sudo add-apt-repo command goes in the postinit file
[19:22] <hyperair> sebner: ah yes. can you find a working libtool-using package and run libtoolize, autoreconf, and make on it?
[19:22] <hyperair> directhex: sounds good =)
[19:22]  * sebner waves at  directhex 
[19:23] <sebner> hyperair: hmmmmmmmm
[19:23] <c_korn> shadeslayer: well yeah. but you really shouldn't do this. I already hate that opera does that
[19:23] <directhex> although tomorrow lunchetimeish i need to drive to coventry to test-drive a civic hybrid
[19:23] <sebner> hyperair: what do you mean with "working libtoo-using package"?
[19:23] <shadeslayer> c_korn: ok
[19:23] <hyperair> sebner: anything that uses libtool for compiling.
[19:23] <hyperair> sebner: like AC_PROG_LIBTOOL or something.
[19:23] <shadeslayer> c_korn: so what next
[19:23] <sebner> hyperair: aye, give me some minutes
[19:24] <hyperair> sebner: i'm trying to fix cone from the ftbfs list, but for some reason, libtoolize gives me a stupid ./libtool script that dies complaining of version mismatch
[19:26] <c_korn> shadeslayer: we took a look in the CMakeLists.txt file and noticed "find_package(Qt4 REQUIRED)" which brings us to the attention that we have to add libqt4-dev to the build depends. and cmake because it is not build essential
[19:27] <shadeslayer> c_korn: ok
[19:27] <sebner> hyperair: longomatch compiles
[19:27] <hyperair> sebner: okay, weird. =\
[19:28] <c_korn> shadeslayer: then we fixed up the package names. libraries should start with the prefix lib. so we changed joschy to libjoschy and joschy-dev to libjoschy1
[19:28] <c_korn> the 1 in there is wrong to be exact because the lib does not build so files with a soname
[19:29] <shadeslayer> c_korn: so files?
[19:29] <c_korn> shadeslayer: then we just fixed the directory where the libs should be installed to on amd64. it is /usr/lib and not /usr/lib64
[19:30] <c_korn> shadeslayer: dynamic libraries
[19:30] <shadeslayer> oh
[19:30] <shadeslayer> just a sec
[19:30] <shadeslayer> c_korn: we have used the 1 just for the heck of it?
[19:32] <c_korn> shadeslayer: yep. so after I built the package I saw that it just installes files to usr/include (the header files which go to the -dev package) and /usr/lib (the library itself) so we changed the install files accordingly
[19:32] <c_korn> and this is it
[19:33] <sebner> bdrung: will you update eclipse to 3.5.2?
[19:33] <bdrung> sebner: yes
[19:33] <shadeslayer> c_korn: whats the difference b/w the -dev and lib package?
[19:34] <bdrung> sebner: today or tomorrow we will release 3.5.2-1 to debian unstable
[19:34] <sebner> bdrung: great to hear, good work :)
[19:35] <c_korn> shadeslayer: the -dev package should only contain files for developers (header files static libraries and so on)
[19:35] <bdrung> sebner: it needs month longer than we hoped to
[19:36] <sebner> bdrung: I guess a FFe won't be a problem though
[19:36] <bdrung> sebner: yes, especially 3.5.2 is a bugfix release only
[19:37] <shadeslayer> c_korn: ok so /usr/lib has the dynamic libs whereas the dev package has static libs
[19:37] <shadeslayer> correct?
[19:37] <c_korn> yes, and the -dev package contains the header files
[19:38] <sebner> bdrung: even better :=
[19:38] <sebner> :)
[19:38] <shadeslayer> c_korn: hmm.. arent libraries==header files?
[19:39] <c_korn> shadeslayer: also note that we did not touch the most import file. debian/copyright. you have to include the copyright information and license of all files from the tarball there. it is most the time most of the packaging work. but as you said it is only used in a ppa I skipped that part.
[19:39] <c_korn> shadeslayer: no, header files are the .h files in C
[19:39] <shadeslayer> c_korn: so what is the function of the libs?
[19:40] <c_korn> shadeslayer: they are the library itself. but developers need the headers to include them in their program to use its functions. the library itself is only required at linking time. not for compile time
[19:41] <shadeslayer> oh
[19:41] <c_korn> shadeslayer: I have to leave now for about 45 min now. sorry.
[19:43]  * hyperair bangs head on table
[19:43] <hyperair> where the hell does libtool 2.2.6 come from?!
[19:43] <hyperair> it's like it just materializes out of nowhere!
[19:44] <hyperair> i've rm'd it, grepped, but nothing! nothing at all!
[19:45] <shadeslayer> c_korn: no problem
[19:45] <shadeslayer> c_korn: thanks :)
[19:47] <sebner> hyperair: that's the magic of opensource ;
[19:47] <sebner> ;D
[19:47]  * hyperair tapes sebner to the floor
[19:48]  * sebner cries
[19:48]  * c_korn suspects the LHC to be involved
[19:49] <shadeslayer> hehe
[19:49] <shadeslayer> c_korn: oh btw i just need to know about the rules file...
[19:49] <shadeslayer> how we did that hocus pocus :P
[20:15] <micahg> was sun-java supposed to come back in the archive?
[20:15] <Myrtti> I've heard rumours of partner repo
[20:16] <micahg> it was sync'd from debian
[20:20] <micahg> ah, it is in partner now, k
[20:33] <c_korn> is Ubuntu also invloved in the Debian GNOME bug hunt ? http://np237.livejournal.com/27754.html
[20:35] <wrapster> what is the difference between marking a pkg 'important' and 'required'
[20:38] <c_korn> wrapster: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
[20:39] <wrapster> c_korn: thanks
[21:01] <MTecknology> I just fixed up a debian/ directory for xdm. So now it has the ubuntu logo instead of the debian one. Is this anything I could get into ubuntu or is that not something that anyone would want to bring in?
[21:03] <Laney> there's precedent for branding patches
[21:03] <lifeless> if its done tastefully I don't see why not
[21:03] <lifeless> put it up for REVU
[21:05] <Laney> this sounds like a patch to an existing package
[21:05] <Laney> no need for REVU there
[21:05]  * lifeless shrugs
[21:05] <lifeless> review is revu, whatever works
[21:19] <ScottK> MTecknology: Since xdm already has an Ubuntu diff, it's probably a reasonable change.  I'm not sure it's a bugfix though.
[21:22] <MTecknology> ScottK: so just give it an appropriate version and send to revu?
[21:22] <ScottK> File a bug, make a debdiff, attach it to the bug, subscribe sponsorship team
[21:35] <MTecknology> ScottK: there's two binary files added to it - will that show up in the diff?
[21:35] <ScottK> You'll need to uuendcode and uudecode them or something
[21:36] <MTecknology> fun
[21:37] <MTecknology> looks like there's already a bug
[21:49] <MTecknology> ScottK: .xpm files are really really weird - I guess they are easily readable....
[22:37] <bdrung> sebner: found more binary files in the eclipse source. so it will need another week.
[22:37] <sebner> bdrung: grrr, bad upstream! Wondering about "another week"
[22:39] <bdrung> sebner: we repack the upstream's srcIncluded zip file.
[22:39] <sebner> bdrung: sure but why does this take exactly 1 week?
[22:39] <bdrung> sebner: i have to figure out how to rebuild the class files or wait for the others to come back on monday
[22:41] <bdrung> sebner: their srcIncluded zip files contain .exe, .dll, .jnilib, .sl, .a, .so, .so.2, .class, .jar files (maybe i find more)
[22:44] <sebner> bdrung: wow, upstream really fucked up it seems
[22:44] <Lord-Readman> hello
[22:44] <Lord-Readman> hello, i need some help updating a package
[22:45] <bdrung> sebner: yes. without eclipse-build we wouldn't have a eclipse package.
[22:45] <persia> hyperair, geser: Just as a note, the reason I suggested nigelb use Suggests: for pychecker in boa-constructor was so that it would automatically provide a hint again once pychecker was ported (as it would remain useful, did it work), and pychecker is still in Debian.  This also helps document it in a way that doesn't make a later merger decide this is a pointless change if they don't do enough research.  I thought it was a bit of a special case.
[22:46] <persia> Lord-Readman: You know it's past FeatureFreeze, right?  Do you have an FFe?
[22:46] <Lord-Readman> what is an FFe?
[22:46] <sebner> bdrung: another reason why I don't like java. B0rken bei design :P
[22:46] <sebner> !FFE | Lord-Readman
[22:46]  * sebner waves at persia :)
[22:46] <bdrung> sebner: :)
[22:47] <Lord-Readman> the FFe would be to fix a bug
[22:47] <persia> Lord-Readman: What bug?
[22:47] <Lord-Readman> so if the features freeze, when can the package get updated? after the ubuntu release?
[22:48] <Lord-Readman> or until 10.10
[22:49] <Lord-Readman> xz-utils https://edge.launchpad.net/ubuntu/+source/xz-utils the latest upload is 4.999.9 2009-11-16, I contacted the package maintainer, and he said he was unable to help as he is the debian maintainer, not the ubuntu one, (even tho thats what launchpad says) he said to checkout http://packages.debian.org/sid/xz-utils / http://packages.qa.debian.org/x/xz-utils.html and http://ftp.us.debian.org/debian/pool/main/x/xz-utils/
[22:49] <Lord-Readman> you can see there is a 2010-02-13 (a few minor fixes), so I wanted to update the package to the newer version, i.e. upload the deb ones or whatever is required to help out
[22:49] <persia> Lord-Readman: In preparation for the next release.
[22:50] <persia> Lord-Readman: And please file a bug on launchpad about misleading you.
[22:51] <Lord-Readman> it fixes both bugs in the ubuntu xz-ulils package
[22:51] <Lord-Readman> which would be good to be fixed for the LTS
[22:52] <Lord-Readman> one is a reported typo which is fixed, the 2nd is when you go to install the package it gives you a warning that it could break your system as lzma-utils is going to be removed
[22:52] <Lord-Readman> even though lzma support is in xz
[22:52] <Lord-Readman> as lzma is defuct and xz-utils has replaced it
[22:52] <Lord-Readman> it is required to use GNU tar
[22:53] <Lord-Readman> as ubuntu 9.10 ships with v1.22, and 1.22 requires xz to use  the -J option (lzma2 .xz file support)
[22:55] <persia> Lord-Readman: Based on what I see, bug #426086 is already fixed in lucid, and bug #511593 requests a trivial string change, which, if important, could more safely be cherrypicked from upstream.
[22:56] <persia> Lord-Readman: Most of the bugs fixed in the Debian uploads appear to be related to packaging or hurd, and Debian has not yet accepted the current upload of xz-utils into squeeze.
[22:57] <Lord-Readman> https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/426086 is fixed for deb but marked as triaged for lucid in dpkg
[22:57] <Lord-Readman> if you visit https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/426086 it says new against xz-utils on ubuntu
[22:58] <persia> Lord-Readman: Can you replicate that behaviour in lucid?  I can't.
[22:58] <Lord-Readman> aptitude install xz-utils I get you are about to do somthing potentially harmfull
[22:58] <Lord-Readman> and i have to type "yes do as i say"
[22:58] <persia> In a lucid install?
[22:59] <Lord-Readman> to get it to install
[22:59] <persia> Because I don't.
[22:59] <Lord-Readman> alpha3 usb persistant install
[22:59] <Lord-Readman> I will have to test it fully tomorrow after swapping my HDD out then
[23:00] <persia> Or set up a virtual environment, but sure.
[23:04] <hyperair> MTecknology: i noticed a few instances of ubuntubw.xdm in your debdiff. was that intentional?
[23:04] <hyperair> the added file name is ubuntubw.xpm.
[23:04] <hyperair> note xpm != xdm
[23:04] <persia> Lord-Readman: In any case, please work to triage 426086 more closely, and identify precisely whether it's open or closed for lucid, etc.  After having done so, please check if there's a way to simply fix it in lucid without pulling the untested (in either Debian or Ubuntu) new upstreams of xz-utils.  I strongly suspect this can be resolved without needing an FFe or a sync.  Also, as xz-utils is in main, #ubuntu-devel may be a better place to ask
[23:04] <persia>  for information.  It may be that I can't replicate because I have dpkg-dev installed everywhere.
[23:05] <persia> (which isn't necessarily the case for non-developers)
[23:05] <Lord-Readman> ok, I will install and test tomorrow
[23:05] <Lord-Readman> if its still there
[23:06] <Lord-Readman> i will go to devel and explain the full story there
[23:06] <Lord-Readman> many thanks for your help
[23:07]  * Lord-Readman goes back to translating
[23:07] <persia> Lord-Readman: Good luck.  If you don't get useful pointers, feel free to contact me to try to help navigate the maze of getting it sorted.
[23:08] <Lord-Readman> yeah, I am fairly new to it all, translations is probably the best way I can help out, looks like a lot of hastle for getting the package updated
[23:12] <persia> Lord-Readman: Are you going to give it a try, or do you need to hand this over to someone else?  426086 is potentially very important, but looks like it will never apepar on a developer's system.
[23:12] <persia> So if you want to fix it, that'd be great.  If not, it needs looking at separately.
[23:13] <Lord-Readman> I will give it a test tomorrow, its just its 23:12pm and am too tired to put my spare hdd in to install alpha3 properly, however running it from my usb stick the problem is defiantly there with the 64bit version
[23:14] <Lord-Readman> app > terminal
[23:14] <Lord-Readman> sudo su
[23:14] <Lord-Readman> aptitude install xz-utils
[23:14] <Lord-Readman> and makes you type yes do as i say line exactly case sensitive
[23:15] <sgnb> randomaction: any idea on when gmetadom and ocaml-expat will be dealt with?
[23:15] <Lord-Readman> so i thought updating to the latest deb version would be good, as it would fix it, and fix the minor typo error too
[23:16] <Lord-Readman> persia, to be honest I can't see the problem not being there on the full install
[23:16] <Lord-Readman> but I dont want to annoy anyone if we are in a feature freeze
[23:18] <persia> Lord-Readman: Makes perfect sense, and I don't want you to stay up all night :)
[23:18] <Lord-Readman> so should I go to devel and ask them nicely in there?
[23:19] <persia> Let me know sometime this weekend if you have issues with the closer bug triage, but I think it needs sorting.  I just don't want to take away the task if you'd like to use this as an opportunity to learn the processes, etc.
[23:19] <persia> But wait until you're rested :)
[23:19] <persia> (or next week if you don't do Ubuntu on the weekends)
[23:19] <Lord-Readman> hmm, well I plan on getting 15,000 strings translated before Beta1
[23:20] <Lord-Readman> so I can always learn about updating packages and doing patches further down the line
[23:23] <persia> Lord-Readman: heh.  OK.  I've been meaning to do a base install of lucid on one of my machines without any developer tools anyway, so I'll track this bug and see what I can do (or hand it to the next person who admits to being bored).
[23:23] <Lord-Readman> :-)
[23:24] <persia> Thanks for pointing it out.  Next time, check if a package is in universe or main, and if it's in main, ask in #ubuntu-devel for pointers on who should fix it.
[23:32] <hyperair> when a sync request should actually be a merge request, should u-u-s be unsubscribed from the bug until it gets turned into a merge request?
[23:32] <lfaraone> hyperair: Yes.
[23:33] <Laney> I usually unsubscribe and say "please resubscribe the sponsors when ready"
[23:35] <persia> hyperair: That's a complex question :)
[23:35] <hyperair> ookay.
[23:35] <hyperair> so i've got "yes", and "maybe"
[23:36] <persia> hyperair: So, if the submitter is obviously part of the team and wants to work to make it better, Laney's suggestion is best practice (but subscribe to the bug and take over if they go away).
[23:36] <hyperair> who's going to drop by and even out the score by saying "no"?
[23:36] <hyperair> ah.
[23:36] <persia> If the submitter is some random person, just pretend it was a submission to the ubuntu-reviewers team, clean it some, and shove it in.
[23:37] <persia> (or don't, and explain why as if talking to some technically competent user who submitted a patch).
[23:37] <hyperair> persia: another thing.. i don't seem to be getting mail from u-u-s bugs. is the email policy for these bugs different or something?
[23:37] <hyperair> persia: ah, that makes sense.
[23:37] <persia> If the submitter is one of those folk who hyperactively requests too many syncs, gently admonish them in the bug, review, and do the work if it makes sense, or mark the bug invalid if it doesn't.
[23:38] <persia> hyperair: u-u-s bugs are supposed to feed bugmail into a blackhole.  I believe some people have found a way to work around this, but it's not the intended interface.
[23:38] <persia> Individual sponsors are supposed to subscribe to bugs that interest them (when unsubscribing u-u-s).
[23:40] <persia> dholbach is wroking on improved tools for sponsoring, and bdmurray on improved tools for finding review opportunities, and several people on enhancing harvest to cover these cases better, etc. but we're mostly trying to improperly overload LP until those are in better shape.
[23:40] <Laney> I tend to clean up minor things and then say what I did in my "Uploaded, thanks" comment
[23:40] <Laney> but anything which isn't immediately apparent I will flag up and unsubscribe
[23:41] <persia> For me, it depends on the person.  If the submitter is around, I'll often chat with them, and see if they have time to fix it *now*.  If not, I'll do as Laney, and if so, I'll help them understand and let them fix it.
[23:41] <persia> Depending on the submitter, it may be that they really want to learn and do, and it's worth working with them so they can help us do stuff later.
[23:42] <persia> But random drive-by submitters should just have stuff fixed and ignored (which makes it hard the first time, but that's something I haven't been able to figure out how to solve yet)
[23:42] <Laney> oh, yes. I have said that I am available for IRC guidance as well, if I think that would help.
[23:44]  * hyperair nods
[23:44] <hyperair> okay, thanks for the advice =p
[23:45] <Laney> really you'll work out how you best prefer to do it
[23:45] <persia> hyperair: Thanks a lot for helping with sponsoring.  Please also consider working with the Reviewers team.  There's *lots* more stuff needing review than needing sponsoring, you aren't expected to spend the time training the patch submitters (but only getting it fixed locally and upstream (if appropriate), or rejected with clear explanation.
[23:46] <persia> Oh, and right now there's only 13 extremely overworked people working on the reviewers team.
[23:46] <hyperair> persia: ~ubuntu-reviewers?
[23:47] <persia> (note that upload rights are *not* a requirement for the reviewers team: anyone wanting to get more involved with development is encouraged to join: it's a lot easier to learn packaging and bugfixing when you start with random patches and test, rather than needing to write the patches yourself).
[23:47] <persia> hyperair: Yes.
[23:47]  * hyperair joins
[23:47] <hyperair> i see.
[23:49] <persia> hyperair: Just because all our docs are inferior, do remember that the focus of u-r is to help improve communication between users and upstreams and fix as many bugs as possible, which is different from u-u-s, which is more about training new developers and helping current developers who can't (yet) upload to a specific package.
[23:50]  * hyperair nods
[23:52] <MTecknology> hyperair: ya, xdm and debian had a black/white version so I made one too
[23:53] <MTecknology> hyperair: the .xpm is the image format
[23:53] <hyperair> MTecknology: did you mean to add the bw version to the post/preinst as ubuntubw.xdm?
[23:53] <hyperair> note the D
[23:53] <hyperair> it seemed pretty uniformly spread out so i want to reconfirm
[23:54] <MTecknology> hyperair: hrm - I was just hopping on - I need to run for a bit right away - everything I added should be either ubuntu.xpm or ubuntubw.xpm; the .xpm is the image format if I did .xdm I messed up.
[23:56] <hyperair> MTecknology: well then, i'll just correct it and upload. it looks fine.
[23:56] <MTecknology> hyperair: I can check it when I get back
[23:57] <hyperair> MTecknology: ah, okay you do that
[23:57]  * hyperair aborts operation and heads to bed instead