[00:15] <doctormo> I'm having a problem with lucid builds on python projects
[00:15] <persia> What sort of problem?
[00:19] <doctormo> persia: The setup.py uses install_lib to do some work, which isn't done on lucid builds.
[00:20] <doctormo> This is the standard python distutils install_lib
[00:24] <persia> doctormo: Hm.  It works for karmic builds?
[00:25] <doctormo> persia: yes, and jaunty
[00:27] <persia> doctormo: Do you happen to have a sid chroot available you could use to see if it's a local issue?
[00:28] <doctormo> persia: this happens via the ppa build system
[00:28] <doctormo> I don't have lucid working yet.
[00:28] <persia> Ah, I thought you might have been trying builds against lucid with pbuilder or sbuild.
[00:29] <persia> But it sounds like there's some difference.  I'd think it would be worth determining if the difference is inherited from Debian, or local to Ubuntu.
[00:29] <persia> If the former, then they python team may have good suggestions to work around the issue.
[00:30] <persia> If the latter, there's probably a bad merge that deserves attention.
[00:41] <doctormo> hmmm, I don't know if I'd know how to test that
[02:42] <freeflying> persia: got some mins?
[02:44] <persia> What's up?
[02:45] <freeflying> persia: if you have time, plz have a look at revu.ubuntuwire.com/p/ailurus
[02:47] <persia> freeflying: You've done a licensing check on all the files?
[02:47]  * persia doesn't have time for that right now
[02:51] <freeflying> persia: did i miss anything?
[02:51] <persia> freeflying: I asked if you've done a full licensing check on all the files.  I don't have time for that right now.
[02:51] <freeflying> persia: I did
[02:52] <persia> OK.  I'll want you to be the second advocate anyway, just because I don't want to answer to an archive-admin having not checked that.
[02:52] <persia> (but I may reject it anyway)
[03:13] <persia> freeflying: rejected with comments
[03:13] <persia> happyaron ^^
[03:15] <freeflying> persia: thanks
[03:16] <persia> freeflying: Any particular reason you picked on me?  I'm slow and lousy with python :)
[03:17] <freeflying> persia: just saw you became active :)
[03:18] <freeflying> persia: I found we don't have too much developer in tz close to you and me :)
[03:18] <persia> Bunch in .au
[03:18] <persia> some in .nz even (albeit fewer)
[03:18] <persia> But very few in +8
[03:23] <YokoZar> persia: Well I'm technically in -8 but I stay up way way too late
[03:26] <persia> YokoZar: well then, you must be in a mood to review http://revu.ubuntuwire.com/p/libprolooks1 :)
[03:26] <YokoZar> right now I'm trying to figure out why lucid is freezing at login regardless of kernel version
[03:27] <persia> (and as a prize, you get to assign the next unsuspecting volunteer a package of your choice, in the vague hope of reviewing some stuff prior to FF)
[03:27] <persia> YokoZar: Uninstall plymouth
[03:27] <YokoZar> We're months behind on review at this point aren't we
[03:27] <persia> (or don't press enter).
[03:28] <persia> We're only about 10 months behind, which is better than it was.
[03:41] <suji11> Anyone advocate/review my package IOK  http://revu.ubuntuwire.com/p/iok
[03:57] <spenser> Hi, I'm working on fixing bug #520240.  This is my first ever attempt at a patch for Ubuntu/Debian.  I updated the rules and added the file that I needed to add,  however when I run debuild -us -uc to build the package I get the following lintian error. Now running lintian...
[03:57] <spenser>  E: libapache2-mod-authz-unixgroup: duplicate-conffile /etc/apache2/mods-available/authz_unixgroup.load
[03:57] <spenser>  Finished running lintian. How can I fix this?
[04:04] <spenser> is anyone here?
[04:04] <crimsun> yes, but I'm updating my schroots. Sec.
[04:04] <spenser> ohh thank you
[04:10] <crimsun> spenser: hmm, what's wrong with the existing debian/authz_unixgroup.load ?
[04:10] <crimsun> spenser: and debian/libapache2-mod-authz-unixgroup.install ?
[04:10] <spenser> its not included in the deb
[04:10] <spenser> so i updated the .install and .dir files to install it.
[04:11] <crimsun> ok, have you regenerated your fixed source package?
[04:11] <spenser> The source package does not need to be regenerated the file is located in the debian/ directory and is created by the patch.
[04:12] <spenser> is that appropriate?
[04:12] <crimsun> is the patch to which you refer the one here? http://launchpadlibrarian.net/39042352/authz_unixgroup.load
[04:13] <spenser> no, when I downloaded the source for the package I found the file in the debian/ directory.  However, the file is not included in the build by default.
[04:14] <crimsun> right, the one you posted is identical to the one in debian/
[04:14] <crimsun> have you posted your patch (to the bug report)?
[04:15] <spenser> not yet, as I'm not completely sure how to create a patch from the work.  Is there a nice script I can run or do I need to it manually?
[04:15] <crimsun> do it manually
[04:15] <crimsun> alternately, you may post your modified .dirs and .install to the bug report, and I'll walk you through it
[04:16] <spenser> that will be easier.
[04:17] <crimsun> BTW, I deleted the authz_unixgroup.load that you attached so that there will be less clutter
[04:18] <spenser> thank you
[04:19] <spenser> alright they are both up there
[04:21] <crimsun> spenser: are you /certain/ that you posted your modified files?
[04:21] <crimsun> spenser: the .dir is identical to the one shipped in the Debian/Ubuntu source package, and the .install only has a whitespace difference
[04:21] <spenser> yes, its a very very simple patch
[04:22] <spenser> maybe its a difference between 10.04 and 9.10
[04:22] <crimsun> yes, it is
[04:22] <crimsun> the one in 10.04 works correctly
[04:22] <spenser> o
[04:22] <spenser> ok
[04:22] <spenser> well I guess there is no need for a patch then
[04:22] <spenser> I'll go ahead and close the bug
[04:22] <crimsun> that's ok; thanks for checking :-)
[04:23] <crimsun> note that the changelog entry for 1.0.2-1 (in 10.04) has this:
[04:23] <crimsun>   * Apache .load file now gets installed
[04:25] <crimsun> OTOH, if you use this package in 9.10, I can walk you through generating a debdiff that you can use for a StableReleaseUpdate (SRU)
[04:25] <spenser> Do you believe it would be accepted?
[04:25] <spenser> If so I'm all game
[04:25] <crimsun> it's pretty trivial, so you have a pretty high probability
[04:26] <spenser> ok sounds great
[04:26] <crimsun> first, do you have the ubuntu-dev-tools binary package installed? If not, take a moment to install it, please.
[04:27] <spenser> It's now installed.
[04:28] <crimsun> ok. Create a new directory and change into it.
[04:28] <crimsun> then, use: pull-lp-source libapache2-mod-authz-unixgroup karmic
[04:28] <crimsun> that command downloads the precise source package from Launchpad associated with Karmic
[04:29] <spenser> E: No credentials found for 'ubuntu-dev-tools', please see the manage-credentials manpage for help on how to create one for this consumer.
[04:29] <crimsun> ah, I suppose you would want to use manage-credentials first as the message says.
[04:30] <crimsun> alternately, extract your existing source package anew
[04:30] <crimsun> do you have it in the parent directory (../) ?
[04:31] <spenser> yes, I did a apt-get source on the package
[04:31] <crimsun> if so, that's dpkg-source -x ../libapache2-mod-authz-unixgroup_1.0.1+svn67-1.dsc
[04:32] <crimsun> then, change into the extracted source directory
[04:32] <spenser> alright, I'm there
[04:32] <crimsun> you'll want to make changes as you did to debian/libapache2-mod-authz-unixgroup.{dirs,install}
[04:33] <spenser> done
[04:34] <crimsun> now you'll need to create a changelog entry, then do the Launchpad administrivia.
[04:34] <spenser> any fancy script to create the changelog entry?
[04:34] <crimsun> so, you can use dch -i -Dkarmic-proposed
[04:35] <crimsun> debchange, or dch, eases manipulating debian/changelog
[04:35] <crimsun> -i -> increment
[04:35] <crimsun> -D -> distribution
[04:36] <crimsun> a proposed SRU will have a distribution of $release-proposed
[04:36] <crimsun> in this case, it's karmic-proposed
[04:36] <crimsun> now, let's look at the top line:
[04:36] <crimsun> libapache2-mod-authz-unixgroup (1.0.1+svn67-1ubuntu1) karmic-proposed; urgency=low
[04:36] <spenser> yes
[04:37] <crimsun> the version in parentheses can be left alone since lucid's version is already higher/greater, but just to be pedantic we'll change it so that it's more attuned to standard versioning for SRUs
[04:37] <crimsun> so 1.0.1+svn67-1ubuntu1 -> 1.0.1+svn67-1ubuntu0.1
[04:38] <spenser> done
[04:38] <crimsun> (note that you could also have used -v to specify this when you used dch)
[04:38] <spenser> cool
[04:38] <crimsun> now, create a succinct message about the changes you've made
[04:39] <spenser>   * added authz_unixgroup.load to apache mods-available dir (Closes: #540240)
[04:39] <spenser> will that work?
[04:40] <crimsun> yes and no
[04:40] <crimsun> it does describe the effect of what you did, but for SRUs try to be very precise
[04:40] <crimsun> also, the changelog-closing syntax is different for Launchpad (it's LP: #foo)
[04:40] <crimsun> Try something like:
[04:40] <crimsun>   * debian/libapache2-mod-authz-unixgroup.{dirs,install}:
[04:40] <crimsun>     - Install authz_unixgroup.load properly (LP: #520240)
[04:41] <lfaraone> persia: new upstream version and should fix all your concerns (groundcontrol) http://revu.ubuntuwire.com/details.py?upid=7663
[04:42] <spenser> I saved the changelog
[04:42] <crimsun> spenser: ok, now you can regenerate the source package
[04:42] <crimsun> spenser: after you regenerate the source package, you can create a debdiff
[04:42] <crimsun> so: debuild -S -uc -us
[04:43] <crimsun> oh, sorry
[04:43] <spenser> alright thats done
[04:43] <crimsun> you probably want to do one more change to debian/control, too:
[04:43] <spenser> bump the version to 3.8.2?
[04:43] <crimsun> since you've modified the source package beyond what Debian's has, you want to be courteous and make the contact reference precise
[04:44] <crimsun> so to do that, you'd:
[04:44] <crimsun> 1) change Maintainer: Hai Zaar <haizaar@haizaar.com> to XSBC-Original-Maintainer: Hai Zaar <haizaar@haizaar.com>
[04:44] <crimsun> 2) add Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[04:45] <spenser> done
[04:45] <crimsun> note that because this is expected practice, you don't need to document this change in debian/changelog
[04:46] <crimsun> now you can regenerate the source package
[04:46] <spenser> I did but I received this error.
[04:46] <spenser> W: libapache2-mod-authz-unixgroup source: out-of-date-standards-version 3.8.1 (current is 3.8.3)
[04:46] <crimsun> which error?
[04:46] <crimsun> spenser: oh, don't arbitrarily bump the S-V
[04:46] <lfaraone> spenser: you can safely ignore that for SRUs.
[04:47] <crimsun> there are requirements for doing so, and as lfaraone mentioned, don't do that for an SRU, which is supposed to be the minimal fix necessary
[04:47] <spenser> I didn't I realized about a split second afterwards what it meant
[04:47] <spenser> Alright the build completed
[04:47] <crimsun> so now you should have two source packages in ../
[04:48] <crimsun> so, back up to the parent dir
[04:48] <crimsun> from there you'll use the debdiff tool to generate a debdiff
[04:48] <crimsun> (which is essentially a unified diff)
[04:49] <crimsun> so, this would be, e.g., debdiff libapache2-mod-authz-unixgroup_1.0.1+svn67-1.dsc libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.dsc > libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.debdiff
[04:50] <crimsun> then, attach this debdiff (libapache2-mod-authz-unixgroup_1.0.1+svn67-1ubuntu0.1.debdiff) to the bug report
[04:51] <spenser> I can't see my changes to the source in the debdiff? is that normal?
[04:52] <crimsun> please pastebin your debdiff
[04:52] <spenser> where is the pastebin?
[04:52] <crimsun> it should resemble http://pastebin.com/f72fc7077
[04:53] <spenser> http://pastebin.com/m31f4238f
[04:54] <crimsun> hmm, did you modify libapache2-mod-authz-unixgroup.dirs and libapache2-mod-authz-unixgroup.install ?
[04:55] <imbrandon> hrm hardy -> karmic directly isnt a good idea ? or is it supported ?
[04:55] <spenser> yes
[04:55] <crimsun> spenser: according to the debdiff, either you didn't save the changes, or you edited some other directory's files
[04:56] <crimsun> imbrandon: it's doable but not recommended
[04:56] <lfaraone> imbrandon: completely unsupported.
[04:56] <lfaraone> imbrandon: if you want to skip releases, wait for lucid.
[04:56] <lfaraone> imbrandon: and then only go LTS->LTS, so hardy->lucid.
[04:56] <imbrandon> crimsun, kk thanks, its a "production" system so i'll go the safe ( abet longer ) route
[04:56] <imbrandon> lfaraone, no time, need upgrade in next 48 hours
[04:56] <imbrandon> :)
[04:57] <imbrandon> btw havent been arround much to say "hi" , hows things crimsun  ?
[04:57] <lfaraone> imbrandon: keep in mind this channel is for development, not support :)
[04:57] <imbrandon> lfaraone, i'm aware :P
[04:58] <crimsun> imbrandon: not bad, yourself?
[04:59] <imbrandon> good, been really REALLY busy last few months, but good
[04:59] <crimsun> spenser: the best course of action is to retrace your edits and regenerate the source package and debdiff
[04:59] <imbrandon> i seen ubuntuwire.com come up for renewal and noticed i hadent been on irc in ages ;)
[05:00] <spenser> Will do
[05:00] <crimsun> imbrandon: cool. (I read your posts on Planet Debian.)
[05:00] <imbrandon> ugh yea , actualy that wasent me
[05:00] <imbrandon> it got hyjacked ( the personal domain )
[05:01] <imbrandon> i removed myself ( well that blog ) from debian and ubutnu planets
[05:01] <lfaraone> imbrandon: can't your provider get that sorted out?
[05:01] <imbrandon> yea it can, and it is, but its sticky
[05:01] <lfaraone> interesting.
[05:02] <imbrandon> somehow ( long story short ) godaddy let the domain be "reregistered" ( e.g. it wasent up for renewal )
[05:02] <imbrandon> so i'm in the SLOW process of reaquireing it
[05:02] <lfaraone> ah, I've heard of those scams.
[05:03] <imbrandon> lucky the other domains ( over 20 of them ubuntuwire.com included ) on the same account are fine, but it still has me looking at better options in the future
[05:04] <imbrandon> anyhow back to my upgrade prep, talk to yall soon, i'll try not to be such a stranger
[05:07] <spenser> ahh much better I think I figured out what I did wrong.  I had rebuilt the package before with the same version number thereby causing the orig files to be overwritten.  By redoing the steps, and incrementing the version number before running the debuild i avoided that issue.
[05:08] <spenser> so here is the new debdiff http://pastebin.com/m680c8d18
[05:08] <lfaraone> james_w: would you consider it a bug that bzr bd, when run in <root-of-bzr-repo>/debian creates a folder buildarea in <root-of-bzr-repo> rather than <root-of-bzr-repo>..?
[05:08] <lfaraone> */..?
[05:11] <lifeless> lfaraone: already filed
[05:11] <spenser> Alright, I posted the patch to launchpad
[05:11] <lifeless> lfaraone: me too it ;)
[05:14] <spenser> crimsun: I uploaded the debdiff to launchpad under the bug i created
[05:14] <crimsun> spenser: yep, now you should amend the Bug Description so that it follows https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[05:16] <lfaraone> lifeless: got a number on that?
[05:16] <lfaraone> lifeless: howabout the "packages with debian files in bzr root and with a debian/ folder symlinked to . cause odd errors"? :P
[05:18] <lfaraone> lifeless: found the first one, nvm.
[05:26] <spenser> crimsun:  How do I upload the package?
[05:27] <spenser> crimsun: step 4
[05:27] <crimsun> spenser: I'll handle that part
[05:28] <spenser> sounds good
[05:28] <spenser> I think everything is in order
[05:31] <crimsun> spenser: uploaded; thank you for your contribution!
[05:31] <spenser> thank you for helping me out.  Couldn't of done it without you.
[05:31] <crimsun> yw
[05:32] <spenser> Does this mean my shiny new package is in proposed?
[05:32] <crimsun> not yet; it has to be accepted by an SRU team member, which may happen by Monday
[05:33] <crimsun> err, in the next couple days
[05:33] <spenser> cool, I'll be watching
[06:13] <fabrice_sp> A package requires locale en_US.UTF-8 to build. Debian added a dependency on locales-all, but we don't have it in Ubuntu (thus the package FTBFS). I added a locale-gen en_US.UTF8 call in debian/rules, but it has to be done as root. Any idea on what else can be done to havethis locale installed?
[06:14] <lifeless> the language pack needs to be installed... smells like a broken package to me
[06:16] <fabrice_sp> it's a brand new one (console-braille). Actually, the package requires an UTF-8 env to build. And buildd have C only
[06:18] <nigel_nb> jmarsden, can you give me a quick overview of fixing a package that uses quilt?
[06:22] <lifeless> fabrice_sp: file a bug on soyuz asking for a UTF08 environment, and modify the package to use locale -a to find any UTF-8 environment
[06:23] <lifeless> fabrice_sp: or build-dep on a utf8 langpack and do the same
[06:23] <jmarsden> Sure... (was AFK...)  what specifically do you need help with?  quilt commands to apply/create/edit patches?  See /usr/share/doc/quilt/README.source for a start... does that help?
[06:23] <jmarsden> nigel_nb: ^^
[06:23] <nigel_nb> jmarsden, that does
[06:23] <jmarsden> Good :)
[06:23] <nigel_nb> jmarsden, when I'm working on a patch, the entire work needs to be done in my lucid vm?
[06:24] <jmarsden> nigel_nb: It's up to you.  You can work in a Karmic environment and then test build in a karmic chroot (pbuilder) if you prefer.
[06:24] <nigel_nb> jmarsden, okay, its embarassing.  I dont know how to set that up
[06:25] <jmarsden> Ah.  Let me find the URL... https://wiki.ubuntu.com/PbuilderHowto
[06:27] <jmarsden> Also look at the pbuilder-dist script and man page for a wrapper that can simplify setting up multiple pbuilders.
[06:27] <nigel_nb> jmarsden, in a karmic environment, I can get pbuilder to build for lucid?
[06:27] <nigel_nb> I just need to follow that page?
[06:28]  * nigel_nb will get disconnected for 1 hour soon :(
[06:29] <jmarsden> Yes, I think so.  I did more, I have a somewhat edited .pbuilderrc based on some stuff from http://wiki.debian.org/PbuilderTricks
[06:29] <jmarsden> You may find you can actually just do man pbuilder-dist and use that, for simplicity.
[06:29] <jmarsden> nigel_nb: Scheduled Internet outages?  Seems odd...
[06:30] <nigel_nb> jmarsden, yep.  everyday 2 hours in noon and evening
[06:31] <jmarsden> nigel_nb: Are you in some "interesting" part of the world, like some tiny island in the Indian Ocean, or something? :)
[06:31] <nigel_nb> jmarsden, well, Indian ocean is named after us ;)
[06:31] <nigel_nb> India, hehe
[06:31] <jmarsden> Ah, OK.  But when I was in Hyderabad a few years back they didn't have scheduled outages...
[06:32] <nigel_nb> bangalore
[06:33] <fabrice_sp> lifeless, will ahve a look at an utf8 langpack. Thanks!
[06:33] <nigel_nb> pbuilderrc should contain my email and what else?
[06:34] <jmarsden> nigel_nb: Mine is a 95 line script!  I'm not sure what the minimum is :)   BTW, I may well be asleep by the time your 1 hour disconnect ends.
[06:35] <nigel_nb> I'm hoping at least someone will be around to help
[06:35] <jmarsden> There's usually someone here, yes.
[06:36] <micahg> nigel_nb: people in europe will be in in a couple hours
[06:36] <nigel_nb> micahg, thats my hope :)
[07:42] <slytherin> Can anyone think of any sensible reasons why rules file would check for architecture to decide whether to apply patches or not?
[07:59] <dholbach> good morning
[08:01] <slytherin> dholbach: good morning
[08:02] <dholbach> hey slytherin
[08:11] <suji11> randomaction: review/advocate my package. i fixed the things http://revu.ubuntuwire.com/p/iok
[08:20] <suji11> how to create package for dictionary files, i'm having ta_IN.dic ta_IN.aff . i have to create package for hunspell-ta how to do that?
[08:27] <slytherin> persia: Can you please explain the version bump for swt-gtk. I am not able to figure out completely from changelog.
[09:06] <thekorn> hey motus, are you using bzr and launchpads merge proposal feature in your sponsorship process to get fixes into ubuntu?
[09:07] <thekorn> if so, is the workflow described somewhere?
[09:17] <dholbach> thekorn: https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[09:17] <dholbach> thekorn: but it's not as widely adopted... yet
[09:17] <dholbach> james_w: ^ right?
[09:18] <thekorn> dholbach, ok, thank. but you did not integrate this into your motu sponsoring process (like crearting a merge proposal, subscribing universe-sponsors etc.) ?
[09:19] <dholbach> thekorn: you mean the sponsoring overview page?
[09:19] <dholbach> working on it
[09:20] <thekorn> dholbach, no, I mean: I created bug 520337, which has a branch, a merge proposal, what's next?
[09:20] <thekorn> do I still have to create debdiff etc.
[09:20] <thekorn> or this is enough to get this landed at some point?
[09:20] <dholbach> thekorn: that should be enough
[09:21] <thekorn> dholbach, great, thanks
[09:42] <ara> dholbach, is there any dev tool to get the source of a debian package from unstable easily?
[09:43] <Rhonda> ara: I think debget should be in that direction.
[09:43] <slytherin> ttx: ping. I have some questions about tomcat6 in repository
[09:43] <ara> Rhonda, thanks!
[09:44] <ttx> slytherin: pong
[09:44] <slytherin> ara: pull-debian-source
[09:44] <Rhonda> ara: Or extract the .dsc URL from http://packages.debian.org/unstable/$PACKAGE and "dget" from there.
[09:44]  * siretart prefers 'schroot -c unstable -- apt-get source $package'
[09:44] <ara> :)
[09:44] <slytherin> ttx: What is the correct way to deploy a WAR file?
[09:44] <ara> thanks all
[09:45] <dholbach> ara: chdist should work too :)
[09:45] <ttx> slytherin: drag-and-dropping it in the webapps directory should be sufficient. If you need special conf, adding a /etc/tomcat6/Catalina/localhost/*.xml deployment descriptor file is the way to go
[09:45] <ttx> (iirc the directory location)
[09:46] <ttx> slytherin: packages usually go the xml descriptor way, on order to install in a separate directory
[09:46] <ttx> ...in order to...
[09:47] <ttx> See tomcat6-{examples,admin} for an example of that
[09:47] <slytherin> ttx: and which directory is the webapps directory? Copying war file to /usr/share/tomcat6/webapps doesn't work.
[09:47] <ttx> slytherin: /var/lib/tomcat6/webapps should be the one$
[09:48] <ttx> (CATALINA_HOME)
[09:48] <ttx> (or is it BASE?)
[09:48] <slytherin> right. I was not looking in this location.
[09:48]  * ttx is confused, long time since I last used it :)
[09:49] <slytherin> directory /var/lib/tomcat6/webapps works
[09:49] <slytherin> first time using tomcat from repository. :-)
[09:50] <Rhonda> oh
[09:50] <Rhonda> oh
[09:50] <ttx> slytherin: we (as in Debian + upstream tomcat + me) are working on a more intuitive tomcat6 package for lucid/squeeze
[09:50] <slytherin> Also IIRC, tomcat provides a ant task for deployment, right?
[09:50] <ttx> slytherin: hmmm... dont know.
[09:51] <Rhonda> ara: dget $package=version  :D   though, I would hope a switch like -s unstable or similar could get added.
[09:51] <^arky^> hi, can anyone help with this error  bzr: ERROR: Cannot lock LockDir
[09:53] <dholbach> ara: first time: chdist create unstable; edit ~/.chdist/unstable/etc/apt/sources.list  - then: chdist apt-get unstable update; chdist apt-get unstable <pkg>
[09:54] <Laney> pull-debian-source foo unstable
[09:55] <Rhonda> ara: Just figured out. Put a deb-src for debian unstable into your sources.list and simple "dget $package" :)
[09:56] <ara> wow, I might remember only one of those
[09:56]  * Rhonda . o O ( It was more curiosity on my part actually that did let me dig that up … )
[09:56] <ara> (if any)
[09:58] <ara> I am merging some changes from debian to lucid. I have seen that they added a debian/source/format file to indicate format 3.0
[09:58] <ara> (as explained at  http://wiki.debian.org/Projects/DebSrc3.0)
[09:59] <ara> should I be merging that as well? is it harmful in Ubuntu?
[10:00] <randomaction> ara: you should, Ubuntu fully supports source format 3.0 now
[10:00] <Laney> I think you have it backwards
[10:00] <Laney> you should be thinking "do I want to keep this *Ubuntu* change?"
[10:01] <Rhonda> randomaction: … for certain definitions of "fully supports". The format is still a bit flakey …
[10:01] <ara> Laney, I don't, that's why I was asking if I should for some other reason
[10:02] <randomaction> Rhonda: sure, it's at least limited to lucid
[10:04] <slytherin> ttx: /usr/share/java/catalina-ant.jar includes various ant tasks to deal with webapps deployment.
[10:05] <Rhonda> ara: You know, in my fromer workplace I had a working collegue who had the initals ara. Confuses me a bit at the moment. :)
[10:06] <ara> Rhonda, I am not him/her
[10:06] <ara> Rhonda, :)
[10:24] <slytherin> ttx: one more question if you are not too busy.
[10:25] <ttx> slytherin: shoot
[10:25] <slytherin> ttx: Is JSTL library part of tomcat installation? I am not able to figure out which jar contains it (if at all).
[10:26] <ttx> hmm
[10:27] <ttx> maybe /usr/share/tomcat6-examples/examples/WEB-INF/lib/jstl.jar
[10:27] <ttx> in tomcat6-examples
[10:29] <slytherin> looks like. I wonder why this is not part of core installation or at least packaged seperately.
[10:30] <ttx> slytherin: I suppose nobody asked for it :) (hint, hint)
[10:31] <ara> standars-version in debian is 3.8.4, but lintian in lucid says it should be 3.8.3
[10:31] <ara> which should I put?
[10:32] <directhex> ara, don't change standards version for merges
[10:32] <ara> directhex, thanks!
[10:32] <ara> directhex, I'll keep that in mind :)
[10:33] <slytherin> ttx: Actually the jar file is /usr/share/tomcat6-examples/examples/WEB-INF/lib/standard.jar. Upstream homepage is - http://tomcat.apache.org/taglibs/standard/
[10:33] <directhex> ara, you want the minimum of changes you can get away with - ideally no changes leading to an effortless sync rather than a timewastey merge
[10:33] <slytherin> I will drop a question on Debian java list and try to get this done in Squeeze/Lucid
[10:33] <slytherin> ara: unless the debian package has changed the version.
[10:33] <directhex> ara, every merge, your question should be "can i drop this ubuntu change" - rarely is "shall i add an ubuntu change" a good idea
[10:34] <ara> directhex, meaning, I should keep 3.8.4 (debian's) or 3.8.3 (lucid's)
[10:34] <directhex> ara, meaning changing standards version is a pointless change which increases workload for literally zero benefit
[10:35] <Laney> you see, that's the same thing I told you about earlier
[10:35] <Laney> copy the Ubuntu changes over to the Debian package
[10:35] <Laney> you don't need to think about reverting their stuff
[10:37] <randomaction> I'm looking to merge ming from Debian, which would start libming0->libming1 transition. I have verified that only one rev-build-dep breaks, and I have a fix for it. Anything else I should check before upload?
[10:38] <Laney> how many packages are affected?
[10:38] <randomaction> five
[10:39] <Laney> easy then, go for it
[10:39] <directhex> five's nothing imho
[10:39] <directhex> i break more by uploading monodevelop 2.2.1
[10:39] <sebner> directhex: do you know when the rest will be compatible?
[10:40] <randomaction> Laney, directhex: ok, thanks :)
[10:40] <directhex> sebner, i haven't uploaded it yet, it's on my TODO
[10:40] <directhex> sebner, i'll try & get all addins done on the same day.
[10:40] <sebner> directhex: aye
[10:42] <slytherin> ttx: Actually both jstl.jar and standard.jar are needed. :-D
[10:43] <slytherin> wow, writing webapp from scratch is fun.
[10:43] <directhex> slytherin, i hear the cool kids use "rails" for that
[10:43] <slytherin> directhex: I admin it. I am not cool. I love java. :-P
[10:44] <directhex> slytherin, that's not just uncool, it's *weird* ;)
[10:45]  * slytherin goes for a tea break
[11:23] <paissad> hi all, i 've uploaded a package to revu.ubuntuwire.com, it's pms-linux ... i hope that someone will give help in order to make the package available into ubntu repositories
[11:28] <paissad> i need to go now, i will be back soon, you can pm me
[11:30] <nigel_nb> just a doubt, when I'm trying to get schroot working, debootstrap needs to built from the source for lucid?
[11:32] <persia> slytherin: The version of swt-gtk in Debian is lower than the last version of eclipse in Ubuntu that built the binary packages that have been transferred.
[11:32] <happyaron> persia: hi, I've made changes on ailurus, could you continue to review it? http://revu.ubuntuwire.com/details.py?upid=7665
[11:33] <sebner> persia: any chance you give it another try?
[11:33] <slytherin> persia: hmm but AFAIK swt packages generated by eclipse have different names.
[11:33] <sebner> persia: + alien arena
[11:35] <persia> sebner: MInd doing happyaron's review whilst I dig into it?
[11:36] <persia> slytherin: eclipse 3.5.1+repack~3-0ubuntu1 provided some binaries also provided by swt-gtk 3.5.1-2, and no longer provided by eclipse 3.5.1+repack~3-0ubuntu2
[11:37] <sebner> persia: trade of work, hmm? Argh, I'll give it a try but in any case I won't ack as I'm not that used python (yet) and especially because of cdbs
[11:39] <persia> sebner: You're at least as comfortable with python as I :)  And if you don't like CDBS, maybe happyaron will change.
[11:39] <persia> (but I don't remember there being anything special about the CDBS stuff)
[11:40] <sebner> persia: I've never and I'll never use it. That's the special thing about cdbs :P But I think it's not the right way to change it because the reviewer wants it because cdbs is (evil) valid
[11:40] <persia> sebner: I agree that it oughtn't change just because you don't like it :)  But really, if there's no hackery, just make sure it works.
[11:41] <persia> If there's hackery, it needs some more attention
[11:41] <sebner> heh
[11:41] <sebner> persia: I'll give it my best ;)
[11:41] <persia> Excellent
[11:41] <slytherin> persia: got it. In any case eclipse will soon stop generating swt-gtk binaries
[11:42] <persia> slytherin: It already has stopped, but because of the version numbers, the old binaries from eclipse were still floating around in the archive and on user systems, and needed *newer* versions from swt-gtk to be viewed as "upgrades", which is why I did the silly +versionbump
[11:44] <slytherin> persia: not a big issue.
[11:45] <persia> slytherin: What?  It would have meant that the binaries we were distributing weren't build from source, which would be bad.  It also would have meant swt-gtk would have been in a failed-to-upload state, so it would never have been delivered with lucid.  Which part of that isn't a big deal?
[11:46] <slytherin> persia: you got me wrong. I am saying that version bump you did is not a big issue. This was in response to "I did the silly +versionbump"
[11:46] <persia> Oh, yeah :)
[11:46] <persia> It's just a little version hack to work around some historical messiness.  We can sync the next upstream.
[11:47] <persia> As an extra bonus, the same folk are now watching eclipse in both Debian and Ubuntu, so this oughtn't happen again.
[11:48] <slytherin> right
[11:48] <nigel_nb> persia, will you able to provide some guidance in setting up schroot so that I can build a package?
[11:48] <persia> nigel_nb: Are you running lucid?
[11:48] <nigel_nb> persia, no karmic :(
[11:48] <persia> Do you use LVM?
[11:48] <nigel_nb> virtual box
[11:49] <persia> Are you handy with partitioning?
[11:49] <nigel_nb> I am, but I dont think I have the space either
[11:50] <persia> Then get someone else to provide some guidance in setting up pbuilder.  lucid schroot/sbuild solves the dependency on lvm, but not karmic, and I'm unsure about backporting the stack.
[11:51] <nigel_nb> so I can't really do it on karmic with schroot?
[11:52] <sebner> persia: I suppose you didn't give it a testbuild?! I fails here
[11:53] <persia> sebner: I did do a testbuild, but that was back when it didn't even try to conform to python policy
[11:53] <persia> nigel_nb: You can use karmic but then the combination is sbuild+schroot+lvm rather than just sbuild+schroot
[11:54] <persia> Which means you either need to have already been using LVM, or you need to make an empty partition to use LVM (20G seems to be about the smallest that is useful)
[11:54] <nigel_nb> persia, I'm just following https://wiki.ubuntu.com/DebootstrapChroot and I'm stuck
[11:54] <nigel_nb> I cant get the soueces updated
[11:56] <persia> nigel_nb: Hrm.  I've never seen that page.
[11:56] <nigel_nb> ouch
[11:56] <persia> nigel_nb: Is it that debootstrap isn't working, or the next steps?
[11:57] <sebner> persia: Was it already using cdbs back then? ^^
[11:57] <persia> sebner: Yes
[11:57] <nigel_nb> persia, I can enter the schroot, but it won't update the sources.list with apt-get update
[11:57] <persia> happyaron: Have you test-built?  Can you help sebner understand why it doesn't build?
[11:58] <persia> nigel_nb: Are you calling `sudo schroot -c ${RELEASE} -uroot`
[11:58] <persia> nigel_nb: You may find that installing sudo in the schoot is convenient.
[11:59] <nigel_nb> persia, I'm calling  sudo chroot /var/chroot/lucid, it enters a root prompt
[11:59] <nigel_nb> persia, i wanted to install ubuntu-minimal inside it
[11:59] <persia> pastebin the error from apt-get update
[12:00] <persia> nigel_nb: And please confirm you've already run debootstrap :)
[12:00] <sebner> happyaron: persia: well, if you give me some more minutes I'll post the build log and some other glitches on revu
[12:01] <happyaron> sebner: persia I will check
[12:02]  * happyaron for now
[12:02] <nigel_nb> persia, well, I built the whole thing again.  Works this time :)
[12:06] <persia> nigel_nb: Excellent :)
[12:06] <nigel_nb> persia, I wanted to correct a spelling error.  Never thought Id be running around this much ;)
[12:07] <happyaron> sebner: the problem might caused by upstream setup.py
[12:07] <happyaron> :(
[12:08] <sebner> happyaron: wondering, persia mentioned that it built at some point in the past
[12:09] <persia> sebner: like I said, that was before it tried to comply with python policy.  I think it was using autotools instead of setup.py
[12:09] <happyaron> sebner: yes it built in the past...
[12:09] <persia> sebner: By the way, I think I've almost tracked down the issue with alien-arena :)
[12:09] <happyaron> persia: the autotools call setup.py
[12:09] <sebner> persia: oh oh oh :D
[12:10] <sebner> happyaron: persia I've posted some other issues. Haven't checked copyright at all yet though
[12:10]  * persia could reproduce in a controlled environment, and is now trying to find the solution
[12:10] <nigel_nb> persia, I can use a simple chroot running as root.  is that okay for building a package?
[12:10] <persia> nigel_nb: It's actively not recommended, because it gets dirty fast.
[12:10] <nigel_nb> hm :)
[12:11] <persia> nigel_nb: Using schroot with lvm-snapshot, or with aufs overlays (available in lucid) throws away the messiness on each package build.
[12:11] <persia> The alternative is to recreate the chroot for each and every package build.
[12:11] <persia> This is why pbuilder is recommended for people who don't have LVM in karmic.
[12:11] <nigel_nb> persia, I dont know how to do the lvm-snapshot
[12:12] <persia> (well, pbuilder might also be recommended because people like it, but that's a different factor)
[12:12] <persia> nigel_nb: You'd need to have at least one partition managed by lvm.  Really, I think pbuilder is better for you with karmic with your setup.
[12:12] <nigel_nb> persia, pbuilder daunts me :(
[12:14] <sebner> happyaron: I also think setup.py is b0rken as I'm not even able to use debuild (How did you get that uploaded O_o)
[12:14] <nigel_nb> persia, I've decided to just keep building schroot every day
[12:14] <nigel_nb> persia, now the question is um, how do I build my package in there
[12:14] <persia> nigel_nb: I believe it's as easy as `pbuilder-dist lucid create`, but I'm not the best person to answer questions about it if it fails.
[12:15] <persia> nigel_nb: You really don't want to do that.  Trust me.
[12:15] <happyaron> sebner: my debuild -S -sa -kxxx works
[12:15] <persia> nigel_nb: sbuild/schroot will handle your use case better in lucid.
[12:15] <happyaron> sebner: I will contact upstream author, maybe he can release another version tomorrow
[12:15] <nigel_nb> persia, okay, trying pbuilder
[12:16] <happyaron> sebner: it built before, so I didn't test build, sorry for that
[12:16] <sebner> happyaron: my debuild looks like this: http://pastebin.com/m10d3cc8b
[12:16] <persia> happyaron: Because it built before and doesn't build now, it might be something about your packaging.
[12:17] <sebner> persia: I'm wondering about setup.py *and* autohell mess
[12:17] <happyaron> persia: yes, I am trying to fix it, to see wether is my fault
[12:22] <sebner> persia: happyaron: I'm really no python expert but the problem is the setup.py script imho. It *must* be run as root and paths are hardcoded (e.g /usr/share/ailurus/)
[12:23] <persia> That sounds like the culprit.
[12:25] <RainCT> sebner: Hardcoded paths (with /usr) in a setup.py? That sounds awfully wrong
[12:25] <persia> RainCT: Maybe you can help suggest what should be right?
[12:25] <sebner> I guess so :)
[12:26] <sebner> yeah, RainCT python expert! \o/
[12:26] <RainCT> I haven't been following (just read the last few sentences), what's the problem?
[12:26] <sebner> RainCT: http://revu.ubuntuwire.com/details.py?upid=7665 , see my comments at the bottom
[12:27] <RainCT> Uhm.. Doesn't Ubuntu Tewaks do the same stuff its description mentions?
[12:28] <sebner> heh
[12:28] <sebner> who knows :)
[12:29] <persia> happyaron: Could you help differentiate?  One of these two should probably go away.
[12:30] <happyaron> persia: I can contact the upstream author to fix it and release a new version, he is one of my friends
[12:30] <happyaron> It won't take too long I think
[12:30] <RainCT> Oh, that setup.py doesn't use distutils at all, it's just a custom script (which would make more sense as a Bash script :P)
[12:30] <happyaron> yup
[12:31] <persia> happyaron: Right, but what's the diffference between ailurus and ubuntu-tweaks (both of which you put on REVU)?
[12:31] <RainCT> happyaron: I'd be great if that setup.py could be replaced with distutils (with python-distutils-extra for i18n)
[12:31] <happyaron> RainCT: yes, and ubuntu-tweak is wanting review
[12:32] <RainCT> (If upstream has any questions on how to use distutils, I'm available here on IRC)
[12:32] <happyaron> persia: ubuntu-tweak has more users, but it is now turning to have more functions intergrated its web service, but ailurus is providing a more pure tool, and providing tips when users doing tweak which will help newbie know more
[12:33] <persia> happyaron: So both should be imstalled?  The descriptions are confusing.
[12:34] <happyaron> RainCT: I will call him soon, maybe he will make the changes tomorrow, it's nearly Chinese Lunar New Year, :)
[12:34] <happyaron> persia: no, either of them is okay, they have different authors
[12:34] <persia> happyaron: Maybe you can get the authors to collaborate?
[12:34] <happyaron> persia: I tried, but failed
[12:35] <happyaron> persia: the author of ubuntu-tweak spend his time on developing web site functions, but the developer of ailurus is against that point
[12:36] <persia> happyaron: OK.  Makes sense.
[12:37]  * happyaron well, ubuntu-tweak is wanting review too as I said just now, :)
[12:38] <nigel_nb> persia, Now I get it.  pbuilder works with chroots but in a better way (I'm in love with pbuilder now ;) )
[12:39] <persia> nigel_nb: Well, kinda.  I actually prefer how schroot works with chroots (because it handles the security stuff), but either of them is better than manually managing chroots.
[12:39] <persia> But schroot is fussy without LVM for karmic.
[12:39] <nigel_nb> persia, all I wanted was a command line way to build packages.  pbuilder works now :)
[12:40] <persia> That it does :)
[13:11] <nigel_nb> persia, still around? need a little help with quilt :(
[13:12] <Rhonda> nigel_nb: Maybe someone else is also able to help you, just ask. :)
[13:12] <nigel_nb> Rhonda, ah, sure :)
[13:13] <nigel_nb> well, I'm trying to correct a spell error bug and I'm not sure how to generate a diff
[13:13] <nigel_nb> I know how to *correct* the bug but not generate the diff
[13:14] <Rhonda> Does the package already use quilt? Then "quilt push" the current patches, "quilt new xx_spellfix" for creating a new quilt patch, and "quilt edit file", fix the typo and quit the editor. Then "quilt refresh" and you have the patchfile there.
[13:14] <nigel_nb> Rhonda, ah, thats what I was looking for.  Thanks :)
[13:15]  * persia thanks Rhonda
[13:16] <Rhonda> After that you might want to "quilt pop -a" to unpatch and rm -rf .pc (quilt doesn't clean up that directory itself)
[13:18] <nigel_nb> quilt edit file takes me to vim, is that normal?
[13:19] <Rhonda> If vim is your editor, yes. :)
[13:19] <nigel_nb> I was hoping to find and replace the error.  It occurs in like 10 files or so
[13:19] <Rhonda> Just set the EDITOR environment variable accordingly if you prefer a different editor - should happen with other tools too.
[13:20] <Rhonda> You can quilt edit file1 file2 file3 and use the full power of your preferred editor. ;)
[13:20] <nigel_nb> so, no find replace in one argument?
[13:20] <Rhonda> But you can also just "quilt add file1 file2 ..." and then call the editor on yourself, if that's what you are looking for.
[13:20] <Rhonda> Ah.
[13:20] <Rhonda> Then "quilt add" all the files and "sed -i" on them. ;)
[13:21] <Rhonda> There are many ways but I hope you get the idea.
[13:21] <nigel_nb> yep.
[13:25] <nigel_nb> once quilt add is used, I can directly sed these files?
[13:25] <Laney> quilt shell is good
[13:27] <nigel_nb> Rhonda, ^^
[13:27] <Laney> yes you can
[13:27] <nigel_nb> ah, thanks :)
[13:32] <\sh> ogra: are you interested in analysing a FTBFS on armel for opensc? ;)
[13:32] <persia> \sh: Can you reproduce it in an emulated chroot?
[13:33] <Rhonda> nigel_nb: Sorry, was distracted by work. Like Laney said, yes. That's what I meant with that. :)
[13:33] <\sh> persia: I don't have any clue about armel ... I don't even know any armel devices :(
[13:33] <BlackZ> I'm not able to do a tab! I have tried with nano, gedit, but nothing..
[13:33] <nigel_nb> Rhonda, unfortunately, that did not work for some reason
[13:33] <BlackZ> it considers the tab 8 charaters!
[13:33] <BlackZ> -> debuild -S
[13:34] <BlackZ> I need the tab for the rules file
[13:34] <persia> \sh: Heh.  There's a way to use binfmt-misc and qemu to have emulated chroots (including pbuilder/sbuild), but ogra might be able to fix it directly :)
[13:34] <slytherin> RainCT: Do you still work on mplayer package in Debian/Ubuntu?
[13:34] <slytherin> oops, wait wrong person
[13:34] <slytherin> siretart: That was a question for you
[13:34] <nigel_nb> Rhonda, I get "Nothing in patch 01_fix3dspell"
[13:34] <\sh> persia: that's what I thought :)
[13:34] <BlackZ> at the start of this line: dh $@
[13:34] <persia> nigel_nb: quilt refresh to update the patch.
[13:34] <RainCT> slytherin: Hehe. Yeah, I don't think I've ever touched that at all :)
[13:35] <nigel_nb> persia, I get that error on quilt refresh
[13:35] <persia> nigel_nb: Also, please ask questions generally.  There's lots of people about, but all of us get distracted here and there by other things.
[13:35] <Rhonda> nigel_nb: Before the sed the quilt add for the files you sed on, and after the sed a "quilt refresh"?
[13:35] <slytherin> nigel_nb: The quilt howto on wiki is very good. Go through it once.
[13:35] <nigel_nb> yep
[13:35] <siretart> slytherin: it's on my todo list, I've done some work at FOSDEM on it in cooperation with upstream
[13:35] <Laney> I really suggest quilt shell
[13:35] <persia> nigel_nb: Are you sure your sed call is changing stuff?
[13:35] <Rhonda> nigel_nb: quilt add adds the _current_ version of the file to its internal staging area, so if you did sed before you did quilt add you already have the changed version in there.
[13:36] <slytherin> siretart: Just curious if you are planning to update it.
[13:36] <nigel_nb> I did a grep before changing and a grep after to confirm
[13:36] <siretart> slytherin: I do have plans, but I'd also appreciate help
[13:36] <siretart> escp. working on bugs woudl help me most, I think
[13:37] <slytherin> Can't make promises. I am already working on more things than I should.
[13:39] <hakaishi> Hi, anyone up to review/advocate qt-shutdown-p? It is a simple Qt tool to shutdown (any) system. http://revu.ubuntuwire.com/p/qt-shutdown-p
[13:44] <nigel_nb> well, instead of sed-ing, I'm just doing a manual replace - tired
[13:45] <persia> nigel_nb: If you're doing it manually, you're likely *sure* that it changed :)  But yeah, you might want to try going through the example on the wiki, and then see how your experience differs.
[13:45] <persia> !patch
[13:45] <nigel_nb> I am going through both those wiki pages and the debian pages
[13:47] <nigel_nb> but it does not seem to be helping much or I'm too much fatigued.
[13:50] <nigel_nb> well, I tried again with quilt add, sed -i, and quilt refresh.  Nothing much happening
[13:50] <nigel_nb> I'm seriously doing something small wrong, but I have no clue what
[13:51] <persia> nigel_nb: You did quilt new, and exported QUILT_PATCHES?
[13:51] <nigel_nb> bingo! didn't do exported .. I am fatigued
[13:51] <nigel_nb> been at this for hours
[13:52] <persia> Take a break, and come back.  The entire thing will take less time (including the break), and you'll feel better.
[13:53] <slytherin> nigel_nb: That is why said read the howto on wiki. :-)
[13:53] <hyperair> nigel_nb: if debian packaging is the only thing you use quilt for, it might be useful to add export QUILT_PATCHES=debian/patches in ~/.quiltrc
[13:55] <nigel_nb> slytherin, I should have read completely
[13:55] <nigel_nb> hyperair, thank you.  I'll do that
[13:55] <hyperair> =)
[13:55] <hyperair> if it isn't already in the howto, it should be added imo
[13:58] <nigel_nb> I'm ready to bang my head against the wall since that didn't fix it
[13:59] <nigel_nb> I still get the "Nothing in patch 104_fixspell3d" after sed-ing and quilt refresh
[13:59] <ogra> \sh, it would be helpful if there was an actual error message
[14:00] <ogra> \sh, but as persia pointed out ... apt-get install qemu-arm-static && sudo build-arm-chroot lucid lucid-chroot :)
[14:02] <persia> ogra: If one is using lucid, one can also just pass --arch=armel to pbuilder-dist or mk-sbuild{-lv,}
[14:03] <ogra> indeed
[14:06] <\sh> ogra: where do i find the armel arch package archive? on ports?
[14:07] <ogra> yes
[14:07] <\sh> ok...this evening I'm mirroring ;)
[14:07] <hakaishi> Hey everyone, the deadline for uploading a package into Ubuntu is the 18th, isn't it?
[14:10] <hakaishi> am I right?
[14:11] <persia> Yes.
[14:11] <nigel_nb> http://paste.ubuntu.com/373976/ is the logs of what I did... what am I doing wrong?
[14:12] <hakaishi> ok... XD I need one more advocate for my package...
[14:17] <rmunn> Speaking of which, I still need advocates for http://revu.ubuntuwire.com/p/python-nltk
[14:18] <rmunn> It's been fairly extensively reviewed by now, so I'm pretty sure I've got all my newbie mistakes fixed
[14:21] <hakaishi> I also have all the mistakes, errors and warnings fixed. I've even got an advocate. Just one more *please*  ';.;'
[14:22] <rmunn> (And you can safely ignore the lintian error on http://revu.ubuntuwire.com/p/python-nltk -- it's a known false positive, check the comments and the lintian-overrides file)
[14:23] <hakaishi> nigel_nb: have you tried checking this page? http://pkg-perl.alioth.debian.org/howto/quilt.html I hope it helps ;-)
[14:23] <nigel_nb> hakaishi, I did.  Didn't help much.  I'm doing something wrong before I get to that stage
[14:25] <nigel_nb> or is it the fact that quilt doesn't let you do sed ?
[14:28] <persia> nigel_nb: Quilt itself doesn't care how to change the files, as long as you tell it which files are being changed with quilt add.  quilt edit combines these two operations.
[14:29] <nigel_nb> can you see the pastebin above to see if I've missed something?
[14:29] <persia> nigel_nb: Setting $EDITOR to something you prefer and using quilt edit is probably easiest.
[14:29] <nigel_nb> for the same change to close to 10 files?
[14:29] <nigel_nb> hey, there should have been an easier way invented
[14:30] <nigel_nb> can i just copy the entire folder tree to another folder make changes on one and generate a diff?
[14:30] <persia> nigel_nb: Nothing seems obvious to me there, no.
[14:30] <hakaishi> nigel_nb: can't you just use po/*.po ?
[14:31] <nigel_nb> actually, there are more files
[14:31] <nigel_nb> the .po was an experiment
[14:31] <nigel_nb> (which didn't work obviously)
[14:48] <nigel_nb> ah, well, bug found.  My find replace statement is defective
[14:48] <nigel_nb> no wonder quilt didn't work
[14:49] <hakaishi> okay ^^'
[14:50] <hakaishi> nigel_nb: and there I thougt of two posibilities: your find replace, or a missing step...
[14:51] <nigel_nb> hakaishi, once i took a break, it just came to me to try and check that part :)
[14:51] <nigel_nb> hakaishi, the string did replace, but I think also replaced in .pc
[14:51] <hakaishi> nigel_nb: okay, nice
[14:52] <nigel_nb> I shoulda done what persia suggested quite some time back
[14:52] <hakaishi> now that this is solved, I'll be going off. cu
[14:53] <paissad> hi all, i 've uploaded a package to revu.ubuntuwire.com, it's pms-linux ... i hope that someone will give help in order to make the package available into ubntu repositories
[14:53] <hakaishi> paissad: a link to your package would be helpful (or one must search for it)
[14:54] <paissad> hakaishi, http://revu.ubuntuwire.com/p/pms-linux
[14:58] <hakaishi> paissad: In your debian/control file: The Maintainer field is invalid. Should be "Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>" and then "XSBC-Original-Maintainer: Papa Issa DIAKHATE <paissad@gmail.com>"
[14:59] <paissad> hakaishi, i packaged originally for debian, (mentors-debian) ... but i will change the control file to make it more ubuntu related ^^
[14:59] <paissad> that's not a real problem,
[14:59] <persia> hakaishi: "invalid" is a bit strong.
[14:59] <persia> paissad: The `update-maintainer` script in ubuntu-dev-tools tends to do the right thing.
[15:00] <hakaishi> persia: It is what the lintian said, I just copyed it ^^'
[15:00] <paissad> hakaishi, lintian returns me no errors !!
[15:00] <persia> paissad: Try `lintian -iIEv --pedantic *.changes`
[15:01] <paissad> ok
[15:02] <hakaishi> persia: okay, I'll leave this to you ;-)
[15:02] <persia> paissad: Also, remember to run on both source and architecture-specific .changes files.
[15:02] <hakaishi> bye bye
[15:02] <persia> hakaishi: Sorry  Please proceed.  Just commenting, but this doesn't have my full attention.
[15:02] <sebner> paissad: and make sure have lintian from lucid
[15:03] <paissad> persia, i just have only on changes file
[15:03] <paissad> sebner, i'm running karmic ^^
[15:03] <sebner> paissad: that's why I told you about lintian from lucid ;)
[15:04] <paissad> am i obliged to do it from lucid ?
[15:04] <paissad> is it a requirement ? or an advice ?
[15:04] <sebner> paissad: well, the newer lintian is the more errors you can catch
[15:05] <paissad> i see
[15:05] <sebner> paissad: you don't need to upgrade your whole system ;) just lintian .
[15:05] <paissad> Lintian v2.2.17ubuntu1.1
[15:05] <paissad> what version do you have ?
[15:07] <sebner> paissad: 2.3.2ubuntu1
[15:07] <paissad> ok
[15:13] <jcastro> dholbach, I have an upstream (mongodb) that wants to get into this LTS.
[15:14] <jcastro> it's a sqlless database
[15:14] <jcastro> they just got into debian unstable, so the correct thing for them to do is file a sync request and hope for the best right?
[15:14] <mathiaz> jcastro: yes
[15:15] <mathiaz> jcastro: they'll have to manually file the request now that the automatic import has been turned off
[15:15] <persia> jcastro: They were here a few days ago, and we helped sort some packaging issues and pushed for the mentors route.  Should be all good to go.
[15:15] <jcastro> persia, !
[15:15] <persia> (modulo the sync request)
[15:15] <jcastro> persia, you always have good news
[15:15] <jcastro> persia, do you know which guy?
[15:16] <persia> jcastro: I'd have to grep logs, and am a bit distracted.  Give me a few minutes.
[15:16] <jcastro> no rush, thank you
[15:17] <l3on> Hi... I've build a package that meets a merge request (ikiwiki). All info here: -> http://people.ubuntu.com/~l3on/pbuilder/ikiwiki/
[15:17] <l3on> what's the next step?
[15:17] <l3on> report a bug ?...
[15:19] <persia> jcastro: I *think* it was kreuter/richard-10gen : there was some issue with REVU that kept getting the package rejected for no reason I could understand.
[15:20] <jcastro> ah ok
[15:22] <hakaishi> how come that revu is unreachable? - Is something wrong with the server?
[15:22] <jcastro> persia, seems every cycle I get one at the last minute asking for a miracle, heh
[15:23] <jcastro> persia, however these days people seem to be going through the debian bits as well, which is nice
[15:23] <persia> hakaishi: Seems so
[15:23] <Laney> jcastro: You shouldn't disregard backports though if the package won't be ready in time
[15:23]  * hyperair prays to jcastro for a miracle
[15:24] <hakaishi> okay, I'll try later again. cu
[15:24] <jcastro> Laney, actually when they first mailed I recommended a PPA
[15:24] <jcastro> but they had already started the debian process so at that point might as well go for it I guess
[15:24] <Laney> well it can still enter lucid-backports even if it doesn't make the release
[15:24] <jcastro> of course I was hoping for them to get there before the day of debian import freeze, heh
[15:24] <Laney> so if they miss it it's not a big deal is what I'm saying
[15:25] <jcastro> I didn't know that
[15:25] <jcastro> I will add it to https://wiki.ubuntu.com/Upstream
[15:25] <Laney> !backport
[15:25] <Laney> ^
[15:25] <jcastro> Laney, is there a page specifically on that? or just the backport page in general
[15:25] <jcastro> ok
[15:26] <Laney> basically you take a package to n-backports from release n+k
[15:26] <jcastro> right but they would still need to be in +1
[15:26] <Laney> yes
[15:27] <Laney> but it gives more time to get the package in shape, go through Debian properly and such
[15:27]  * jcastro updates the page
[15:28] <jcastro> thanks for the tip, that's useful
[15:28] <Laney> np
[15:29] <paissad> i have this warning during lintian run ^^ ... but it's a really important warning i think
[15:29] <paissad> arch-dep-package-has-big-usr-share
[15:30] <paissad> but i think that this one below is not important, ^^ it's the source from the upstream
[15:30] <Laney> it means you should consider splitting out your arch-indep stuff into a separate package
[15:30] <paissad> source-contains-prebuilt-windows-binary
[15:30] <Laney> that is important
[15:31] <paissad> Laney, okay
[15:31] <oojah> Could someone review sqlite3-pcre for me please? http://revu.ubuntuwire.com/p/sqlite3-pcre
[15:32] <Laney> paissad: you should at the very least ask upstream to provide clean tarballs
[15:32] <Laney> and it might be a license problem
[15:32] <paissad> Laney, why a licence problem ? ... the source is from the svn repository
[15:32] <paissad> the license is GPL2
[15:33] <persia> paissad: GPL2 requires stuff be available in the preferred form for modification, which windows executables usually aren't.
[15:35] <paissad> persia, Laney the source contains somes dirs (linux, win32, osx ...) during the deb packaging i don't touch the win & osx dirs, i even do touch the linux ^^ for other reason i won't explain now ... i don't see what's the matter
[15:35] <persia> paissad: Just add the offending file to debian/clean
[15:35] <paissad> everything which is in the package is free & licensed under gpl2
[15:37] <nigel_nb> when I fix a bug and notice that it is present on upstream too, I'm supposed to send a patch upstream?
[15:37] <paissad> persia, sorry, i'm a little confused, i'm not sure what you really mean ... do you advice me to remove the files or dirs for the source that or related to the build
[15:37] <paissad> ?
[15:37] <paissad> that are not related*
[15:37] <Laney> unrelated files are fine, files which break the license are not
[15:38] <persia> It doesn't necesarily break the license, but we can't tell.
[15:38] <Laney> yes, I'm not passing a judgement on this case, just stating the principle
[15:38] <persia> deleting ot prior to building is one way to demonstrate that we don't care about the file, and so we can know were are distributing compliant binaries.
[15:39] <persia> So, by adding prebuilt binaries to debian/clean, we can be sure that every binary we use ends up being built.
[15:39] <persia> Saves repacking.
[15:39] <paissad> Laney, yes indeed, files which break the licensed are not included to the build, .. that's why for example i did not include the linux/ directory ....  knowing that that dir contains another software which is not free & whose source is not available
[15:40] <paissad> i just thought that would be wiser no to delete those files or dirs in order to have a proper orig.tar.gz file ...
[15:41] <oojah> paissad: They aren't talking about modifying the orig.tar.gz.
[15:41] <Laney> persia: Is that OK for ftpmaster/AAs?
[15:42] <oojah> What persia is saying is that whatever you put in debian/clean won't be included in the final .deb.
[15:42] <oojah> Correct?
[15:42] <persia> paissad: That's why I recommend deleting them at build time, with debian/clean.  You get the benefits of a clean orig.tar.gz *and* the benefits of a provable indication that you didn't use the files during the build.
[15:42] <Laney> I mean, distributing a binary in known license violation, even in the source package?
[15:42] <persia> oojah: Right.
[15:42] <persia> oojah: It won't even be available during the build.
[15:42] <oojah> Right
[15:42] <paissad> persia, i understand now ! ..
[15:42] <persia> Laney: For binary blobs that are licensed in a free manner, usually, but, as ever, it depends on the individual concerned.
[15:43] <Laney> It's interesting. I would have repacked.
[15:43] <Laney> (binary built from GPL2 source)
[15:43] <persia> Laney: Having a windows binary of GPL is not necesssarily itself a license violation if we expect to have code for it.  Not building from source when distributing binaries is a failure of due-dilligence.
[15:43] <Laney> but that is just me being extra cautious
[15:43] <persia> Yeah.
[15:44] <paissad> for a 1st build, it's really hard to sync with debian/ubuntu policies ^^ ...
[15:44] <paissad> but i do not blame that, of course
[15:44] <Laney> we do try to give help
[15:44] <paissad> yeah, it's kind , thanks
[15:44] <Laney> persia: I guess if it is alongside the source then it's not a problem
[15:55] <micahg> Ubuntu Mozillateam meeting in #ubuntu-meeting in 5 minutes
[16:05] <spwelton> hi all, I recently added some new features and fixed all the bugs i could find in a program i have on REVU, is there any chance i could get a dev to maybe check it out for inclusion in Universe?
[16:08] <gusnan> If I have a package which I upload to Revu for inclusion to Universe - what email should I put as "mainainer"? - I put myself as XSBC-Original-Maintainer, right?
[16:10] <spwelton> gusnan: you need to put the ubuntu-dev email on there, hold on, let me get the proper name and e-mail
[16:11] <spwelton> gusnan: Use the following name and e-mail: 	Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[16:11] <gusnan> spwelton, Thank you!
[16:11] <spwelton> gusnan: any time! I'm working on a REVU package currently as well
[16:20] <lfaraone> If a blueprint is accepted for lucid, but the reqisit packages aren't uploaded yet, does this require a FFE after FF?
[16:21] <\sh> james_w: where was your documentation about new world merging tutorial with bzr?
[16:21] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[16:22] <\sh> james_w: thx a lot :)
[16:23] <lfaraone> james_w: for debian packages, do you import from SVN if that's what's specified in the package control field?
[16:24] <james_w> lfaraone: no
[16:24] <james_w> not yet
[16:40] <\sh> james_w: is there an actual bzr-builddeb for jaunty so I can bzr merge-package ?
[16:41] <james_w> not that I know of
[16:41] <\sh> that's bad
[16:41] <\sh> grmpf
[16:41] <\sh> I can't upgrade this machine to karmic...it will break my network config
[16:41] <\sh> until karmics ifupdown is fixed
[16:42] <sebner> \sh: upgrade to lucid then :P
[16:42] <james_w> should be quite straightforward to backport
[16:43] <\sh> sebner: ah no..this will break my puppetd ;)
[16:43] <\sh> better to say puppetmaster
[16:43] <sebner> heh
[16:44] <gusnan> hmm, I get revu warning - "unknown-field-in-dsc original-maintainer" - what does this really mean? - as my discussion above with spwelton I thought I had enough maintainers... (This is a new package to Ubuntu, not existant in Debian...)
[16:44] <\sh> james_w: well, actually not, because you need a newer bzr for jaunty...ah well, I'll try to do that merge at home
[16:45] <\sh> gusnan: the right fieldname is XSBC-Original-Maintainer imho...
[16:45] <spwelton> gusnan: I got that error the first time i uploaded, don't remember how i got rid of it
[16:45] <spwelton> Although my current dsc has 'Original-Maintainer'
[16:46] <gusnan> Yeah, I have listed myself as XSBC-Original-Maintainer...
[16:46] <spwelton> Is there some application to get stuff checked in REVU? Or is it kind of a first come-first serve basis?
[16:47] <spwelton> just want to make sure I'm doing this right
[17:01] <oojah> spwelton: My understanding is that you can ask for reviews here, but not more than two or three times a day as described on here: https://wiki.ubuntu.com/MOTU/Packages/REVU/CheckList
[17:04] <spwelton> oojah: Thanks!
[17:05] <persia> Well, you *can* ask more often, but some people might start ignoring you :)
[17:06] <spwelton> haha :D
[17:07] <oojah> I suspect there's an optimal amount of annoyance (and probably time of day - any suggestions as to when?)
[17:07] <spwelton> so following that guide, would anyone mind checking out eggtimer (a simple countdown timer for cooking, etc) at http://revu.ubuntuwire.com/p/eggtimer and let me know if anything needs fixin'? I finally learned how to properly upload to REVU and there are no errors reported.
[17:09] <persia> Seems there's a quickly bug: it uses the "Maintainer" address for changelog entries.
[17:10] <spwelton> in debian/changelog?
[17:10] <persia> debian/copyright doesn't comply with the listed Format-Specification:
[17:10] <persia> spwelton: Yep.
[17:10] <persia> spwelton: I don't think it's something you did: I think quickly is broken.  Please correct me if I'm wrong.
[17:10] <spwelton> i manually wrote most of this, because quickly uses weird version numbering
[17:11] <spwelton> built with debuild and pbuilder
[17:11] <persia> Heh.  Use your own name and email for changelog.
[17:11] <persia> And Fix the copyright file.
[17:12] <jcfp> debian dir seems to be in the orig.tar.gz?
[17:12] <spwelton> where may I find the proper copyright format?
[17:13] <spwelton> jcfp: if you click into the eggtimer-0.5 DIR, its in there
[17:13] <persia> spwelton: Check the URL you put in debian/copyright
[17:13] <persia> spwelton: But If you want DEP5, look at http://dep.debian.net/deps/dep5
[17:14] <spwelton> haha, that copyright file was made by quickly apparently
[17:14] <persia> Maybe another bug.
[17:16] <spwelton> are those the only two problems? I can fix them real quick and re-upload them
[17:17] <oojah> I could be reading it incorrectly, but should the code changes be in a patch rather than modified in-situ?
[17:18] <spwelton> oojah: in my package?
[17:19] <persia> spwelton: Those are the two that are so obvious that I noticed them immediately.  Someone with a bit more of a feel for python packaging would be a better reviewer.
[17:19] <jcfp> spwelton: commented
[17:19] <spwelton> ok, thanks
[17:20] <jcfp> don't be scared, all fixable
[17:21] <spwelton> haha the one that gave me trouble is the uscan one, I must not be writing my watch file correctly, because I always get the 404
[17:23] <spwelton> ok, so I'm fixing the copyright file. I paste the whole text of the GPL-3 in there right?
[17:24] <persia> spwelton: Read the "How to use this license" section at the end of the GPL.
[17:30] <dooooomi> persia: thanks a lot for uploading klick. i have one question regarding your comment: what is the correct value for the maintainer field, and when did that change?
[17:31] <persia> maco2: Saw your patch for JACK.  Are you uploading a fix?
[17:32] <persia> dooooomi: It changed a few months back.  Current correct value is something like "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>".  Preferably use update-maintainer to get the current recommended value.
[17:34] <dooooomi> persia: hm... i tried running update-maintainer on my older version of the package, and it left the maintainer field unchanged
[17:34] <spwelton> so, if I'm thinking correctly... I should include a link to the GPL-3 file and not a full text in the debian/copyright file
[17:35] <persia> dooooomi: Hrm.  I don't know.
[17:35] <persia> spwelton: But you do want to include stuff like the declaration of license and lack of warranty and stuff.  SHould be about three paragraphs.  The template is in that section of the license.
[17:36] <spwelton> ok, thanks, i think i know the part you're talking about now
[17:38] <spwelton> and Upstream-Source would be, for example, the tarball on launchpad?
[17:41] <persia> Or the LP downloads directory, at your discretion
[17:42] <spwelton> ok
[17:46] <kreuter> persia: did you ever hear back about what I did wrong with my package upload into REVU the other day?
[17:47] <persia> kreuter: I don't think you did anything wrong.  I think there was something wrong with the system.
[17:47] <persia> jcastro was around earlier, and reported that you'd managed to get the package into Debian, so a sync request is probably better than REVU.
[17:47] <persia> (because it's already been reviewed by two DDs)
[17:48] <jcastro> hi kreuter
[17:48] <jcastro> kreuter, I was just about to send mitch an email.
[17:48] <jcastro> kreuter, sync request would be best
[17:49] <jcastro> persia, hmm,, seems like 1.3 is in debian, but they want 1.2 to be in lucid.
[17:49] <persia> Why?
[17:50] <jcastro> I believe 1.2 is their stable series?
[17:50]  * jcastro goes to check
[17:50] <persia> squeeze freeze is in like 2 weeks.
[17:50] <persia> It's a *bad* time to put unstable stuff in Debian.
[17:50] <persia> Downgrading in Debian seems the best solution to me, for everyone.
[17:52] <jcastro> kreuter, any thoughts?
[17:53] <persia> Or being sure 1.3 will be stable soon enough to be in both squeeze and lucid.
[17:54] <jcastro> persia, ok I mailed the dude asking when they think 1.3.x will be ready.
[17:54] <jcastro> let's hope it's not like "6 months!"
[17:56] <Laney> persia: is it? (squeeze freeze)
[17:56] <persia> jcastro: Yeah.  lucid gets support through to 2013/2015, and I'd expect sqeeze to last until 2013 as well.
[17:56] <Laney> have you a link?
[17:56] <persia> Laney: I've heard "March" bandied about as a deadline.
[17:56] <persia> But no, I have no link.
[17:56] <Laney> I would have expected more noise
[17:57] <spwelton> do i need to write a man page for my package?
[17:58] <jcastro> persia, I don't see anything on their site of feeds about a release date.
[17:58] <Laney> anyway...
[17:58] <Laney> I would expect most people to want squeeze and lucid to have the same versions
[17:58] <Laney> Debian releases are somewhat akin to Ubuntu LTS releases
[17:58] <jcastro> yes
[17:59] <spwelton> jcastro: yes @ me?
[18:00] <jcastro> spwelton, I was talking to them, sorry
[18:00] <spwelton> oh haha
[18:00] <jcastro> but I can guess that your answer is probably "yes" if it makes you feel better, heh
[18:00] <spwelton> haha well i was just wondering if it's required on REVU?
[18:01] <spwelton> cause I've never written a manpage before.. is it just a text file in the debian folder?
[18:01] <Laney> spwelton: If this is just a small program you are writing for fun, you could consider packaging for a PPA instead
[18:01]  * persia thinks it's duplicate to software already available in Ubuntu
[18:01] <persia> http://alarm-clock.pseudoberries.com/
[18:02] <spwelton> yeah i have it in a PPA, but I'd like to learn to write for packaging in universe.. My goal is to write a larger program, and this little one has been an immense learning experience
[18:02] <Laney> universe is a part of Ubuntu... I'm not sure it is an appropriate place for learning exercises
[18:02] <kreuter> jcastro: so we're sort of in a bit of a bind, time-wise.
[18:02] <persia> kreuter: Essentially.
[18:03] <jcastro> yeah
[18:03] <kreuter> jcastro: the version that got into Debian is a 1.3.x, which is not our stable version.
[18:03] <kreuter> we're planning to have a stable 1.4 out mid-March, but that probably can't make it into 10.04.
[18:03] <spwelton> Laney: understood, but how else would one get started packaging for Ubuntu if they haven't done it before.
[18:03] <kreuter> jcastro: oh, sorry, you already said all of this above.
[18:04] <jcastro> kreuter, no worries
[18:04] <spwelton> I mean, I completely understand that if there's already software in there that does this, one wouldn't want to duplicate it. I didn't see that linked program when i searched apt for what i wanted to do with it
[18:05] <jcastro> so to me the risk is, do we ship 1.2.x for years, or risk trying to 1.4 with the notion that if you guys get behind and we're all doomed.
[18:05] <Laney> we're always happy to help people learn
[18:05] <persia> I think it's the alarm-clock-applet package.
[18:05] <Laney> spwelton: FWIW, I would advice newcomers to work on patches to existing package and build up to packaging an entirely new piece of software
[18:06] <jcastro> kreuter, how long do you plan on supporting 1.2.x?
[18:06] <Laney> universe has a bit of a historical problem with maintaining packages
[18:06] <spwelton> persia: yeah i see that package now, didn't show up in my searches for 'timer' and 'countdown' etc, etc.. when i first wrote this
[18:06] <persia> a bit?
[18:07] <persia> spwelton: I remember discussing this when you first joined the channel :)  But like Laney said, we're always happy to help people learn if we have time.
[18:07] <jcastro> persia, when is the dropdead last day one can request a sync, beta1?
[18:07] <jcastro> persia, or is it FF Feb 18th?
[18:07] <Laney> s/advice/advise/ of course
[18:07] <thekorn> \sh, hey, thanks for sponsoring my python-virtualenv patch ;)
[18:07] <persia> jcastro: I've requested them 4 hours before the final CD spin, but the number of people that need to approve it raises exponentially after FF begins.
[18:07] <spwelton> So do we just not include this in universe since there's kind of already software to do this?
[18:08] <persia> jcastro: In practice, if it's not in by the first beta freeze, it's not going to happen unless it's a stop-ship issue.
[18:09] <jcastro> persia, ok so let's assume they do mid-march, and beta1freeze is on march 11, assuming the debian package is solid ...
[18:09] <persia> jcastro: And new packages  / version changes post FF need approval from the Release Team (which usually only grants it if essential).
[18:09] <kreuter> jcastro: we're willing to support 1.2 for a while...
[18:09] <persia> jcastro: I'd rather see a sync sooner (pre-FF), and some attention to bugfixing as the cycle continues.
[18:10] <persia> jcastro: A cosmetic version number change from 1.3->1.4 pre beta-freeze being mostly bugfixes on the 1.3 trunk will likely get approved.
[18:10] <jcastro> right
[18:10] <jcastro> that's what I was thinking
[18:10] <jcastro> persia, so I think syncing in 1.3.x asap would be best?
[18:11] <jcastro> they're so far along in their release cycle that it's probably nothing but bugfixes at this point
[18:11] <jcastro> kreuter, ^^ is that an accurate assessment?
[18:11] <kreuter> uh
[18:11] <persia> kreuter: Also, are you comfortable with the idea of supporting 1.4.x thorough 2013?
[18:11] <persia> (as compared to 1.2.x)
[18:12] <jcastro> kreuter, sorry, don't mean to come off like we're grilling you. :)
[18:12] <kreuter> we're not going to have 1.4.x out by the Debian or Ubuntu freezes.
[18:13] <kreuter> we're willing to backport serious bugfixes and security things to 1.2.x
[18:13] <kreuter> for the foreseeable future
[18:13] <chx> can an exception be made?
[18:13] <kreuter> hm?
[18:13] <chx> 1.3 included now to keep most of the API stable and get 1.4 in before the release?
[18:13] <persia> kreuter: In that case, my recommendation would be to downgrade in Debian, and sync that.
[18:13] <jcastro> chx, sure, it just gets harder and harder past freeze to get an exception
[18:14] <jcastro> I personally think having 1.2 in both is the way to go, and then offer 1.4 when it's stable as a backport or PPA or whatever.
[18:14] <persia> chx: Exceptions are permitted if well argued,  It's easier if the release team is kept well informed of progress.  But exceptions past beta freeze have very strict criteria, which some of the 1.3.x -> 1.4.x changes may not meet (depends on what you do when)
[18:14] <persia> Yeah, having 1.3 anywhere seems like a recipe for issues.
[18:15] <chx> it would be most onfortunate to miss 1.4 in Lucid for years because of like what two weeks?
[18:15] <jcastro> is it two weeks?
[18:15] <jcastro> our freeze is march 11, so wherever "mid-march" fits into that.
[18:16] <kreuter> chx: fwiw, we (10gen) are expecting to maintain our own apt'able packages for the foreseeable future.
[18:16] <kreuter> (i.e., so there will be 1.4 packages around)
[18:16] <persia> Release team has a meeting in about 22 hours (I think).  It may be able to be raised at the end of that to get clearer guidance, but I'd suggest developing a firm plan first.
[18:16] <chx> kreuter: i understand that, of coure
[18:17] <jcastro> kreuter, since you guys plan to have packages, I think sticking a known-good stable (1.2) in debian/ubuntu is the way to go.
[18:17] <kreuter> persia: I've just emailed Antonin Kral, the Debian maintainer, to downgrade to a 1.2.
[18:17] <chx> jcastro: my (just a user) understanding is that 1.4 is scheduled around april 1.
[18:17] <jcastro> if we try to rush 1.4 in it will end in tears (from past experience)
[18:17] <jcastro> not that I don't enjoy trying to squeeze stuff in at the last minute. :p
[18:18] <spacemonkey> lol
[18:18] <jcastro> kreuter, as soon as that's done just file a sync bug and that'll be that.
[18:18] <kreuter> jcastro: okay.
[18:18] <kreuter> jcastro: where do I file a sync bug?
[18:19] <jcastro> one sec
[18:19] <persia> Probably better to file the sync bug NOW>
[18:19] <persia> And then later sync the downgrade.
[18:19] <persia> Because after the 18th, it needs release team approval to add a new package, which is rarely granted.
[18:20] <persia> The downgrade will also require release-team approval, but that can be justified in terms of upstream support commitments.
[18:20] <kreuter> okay, so how do I file a sync bug?
[18:21] <jcastro> https://wiki.ubuntu.com/SyncRequestProcess
[18:21] <jcastro> aha, there it is
[18:21] <spacemonkey> jcastro: thanks for helping us with this
[18:22] <kreuter> jcastro: yes, thank you.
[18:22] <jcastro> no worries, it's a team effort.
[18:22]  * jcastro high fives persia
[18:22] <jcastro> once you're in debian from now on it will be easy.
[18:22] <jcastro> well, easier
[18:23] <jcastro> I've tried to document these kinds of things here: https://wiki.ubuntu.com/Upstream
[18:23] <jcastro> if you guys have any feedback on how I can improve that documentation for people like you, it would be appreciated!
[18:24] <jcastro> kreuter, when you file the bug please subscribe me to it (top right, "subscribe someone else" and my lp id is "jorge")
[18:24] <persia> jcastro: At some point, I'd like it if some of the best-practices-in-upstream-release-management stuff we've written was merged with your packges.
[18:24] <jcastro> so I can make sure it doesn't fall through the cracks
[18:24] <persia> (but that's an entirely separate bit of feeback on improving the documentation :) )
[18:25] <persia> s/packges/pages/
[18:26] <kreuter> jcastro: will do.
[18:27] <jcastro> kreuter, at your leisure of course, don't let me distract you from releasing 1.4. :p
[18:27] <kreuter> jcastro: no worries on that front.
[18:27] <jcastro> I'm trying to make it so we don't have to put every upstream through a gauntlet.
[18:28] <persia> Some of that gauntlet we can probably document in advance, so that it doesn't feel like complying with silly rules, but makes sense.
[18:28] <kreuter> so, I'm sort of confused by the launchpad web interface.  how do I create a new bug?
[18:28] <persia> Stuff like outlining how to deal with work-in-progress vs. supported releases, licensing, simplified builds, bundling, etc.
[18:29] <persia> kreuter: https://launchpad.net/ubuntu/+filebug
[18:29] <jcastro> https://launchpad.net/ubuntu/+filebug
[18:29] <kreuter> no, I've already read that.
[18:29] <kreuter> I'm not at an Ubuntu machine, so AFAICT, I have to use the Launchpad web interface.
[18:29] <jcastro> yeah that's the web ui to file a bug
[18:30] <jcastro> you're trying to file a sync request right?
[18:30] <kreuter> yes
[18:30] <mathiaz> isn't https://launchpad.net/ubuntu/+filebug redirected to a wiki page to file with apport for the casual user?
[18:30] <kreuter> yes
[18:30]  * jcastro shakes fist
[18:30] <kreuter> ?
[18:30] <jcastro> one sec
[18:32] <persia> mathiaz: Do you know how "casual user" is defined in that context?
[18:32] <mathiaz> persia: hm - I don't exactly know
[18:32] <jcastro> someone not in bugcontrol or a ubuntu-dev afaik
[18:32] <jcastro> is there a work around?
[18:32] <persia> Get someone else to file it.
[18:32] <persia> jcastro: File a bug :)
[18:32] <jcastro> I'll do it!
[18:33] <kreuter> jcastro: thanks!
[18:33] <Laney> you can append ?noredirect to the URL
[18:33] <Laney> or something like that
[18:33] <mathiaz> jcastro: +filebug?no-redirect
[18:33] <Laney> so close :(
[18:33] <jcastro> kreuter, ^^^ there we go
[18:33] <mathiaz> kreuter: try: https://launchpad.net/ubuntu/+filebug?no-redirect
[18:34] <kreuter> right, okay.
[18:34] <jcastro> persia, this will be a great session at UDS. "How we punch upstreams in the face, and other lies the wiki tells you."
[18:34]  * kreuter does indeed feel ever-so-slightly punched in the face.
[18:34] <jcastro> oh dude don't worry, you haven't even gotten to the rest of launchpad yet.
[18:34] <jpds> Or the Launchpad code, haha.
[18:34] <jcastro> (actually this is valuable feedback)
[18:35] <jcastro> kreuter, stepping out for lunch, I'll be around, you're in good hands here.
[18:35] <persia> jcastro: We don't like new software in Ubuntu, because we have enough trouble maintaining stuff in collaboration with Debian.  It's probably better to just improve the documentation.
[18:35] <kreuter> so I keyed in "mongodb sync request" for a summary, and now am facing a blank textarea.
[18:36] <jcastro> kreuter, the "content of a sync request" part of the wiki is what you want here
[18:36]  * jcastro finds an example
[18:36] <kreuter> right, I get that, but there's something about subscribing versus assigning or something, and I don't see how that applies to the form I'm looking at.
[18:37] <spwelton> has anyone here ever gotten a link to launchpad to work in debian/watch?
[18:37] <persia> kreuter: That comes later.  First get the bug filed, and *then* subscribe sponsors.
[18:37] <kreuter> okeedokee.
[18:37] <persia> spwelton: Yes.  There's an example in the packaging guide
[18:37] <persia> !packaging
[18:38] <jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/groovy/+bug/368082
[18:38] <jcastro> how's this an example
[18:38] <jcastro> kreuter, though you will want to say "We are working with debian to downgrade their package to the stable 1.2, this is a placeholder" or something
[18:38] <persia> No.
[18:38] <jcastro> right?
[18:39] <persia> You precisely don't want that, because you want the sync request reviewer to get excited about it.
[18:39] <persia> That may be the long-term plan, but there's enough context it may be difficult to re-explain to some random sponsor.
[18:41] <kreuter> persia: Ack.
[18:50] <kreuter> okay, sync request filed.
[18:50] <jcastro> bug #?
[18:50] <lfaraone> Hi, can someone take a look at http://revu.ubuntuwire.com/p/groundcontrol ? All the concerns about prior uplaods have been fixed.
[18:51]  * Rhonda feels intimidated by LSB init.d requirements.  %-/
[18:52] <lfaraone> persia: heh, I've asked a couple of times over the past few days, no bites.
[18:52] <persia> lfaraone: My problem is that I can't say it's correct with confidence, although I don't remember seeing anything obviously incorrect.
[18:55] <spwelton> problem I'm having right now is that my watchfile has http://launchpad.net/eggtimer/+download/eggtimer-(.+).orig.tar.gz in it, but uscan keeps complaining about no matching href's, and i can't find anything online that's worked :(
[18:57] <lfaraone> spwelton: you want a _, not a -
[18:57] <lfaraone> spwelton: upsream uploads using filenames like "eggtimer_0.5.orig.tar.gz"
[18:57] <spwelton> ohhhh ok yeah you're right.. how did i miss that :D
[19:00] <persia> spwelton: Note that you could just release eggtimer-0.5.tgz upstream, and uscan would automatically convert the file name (with a symlink).
[19:01] <kreuter> persia: is there something I ought to do to delete the stuff I uploaded to REVU on Tuesday?
[19:01] <persia> kreuter: No.  I already deleted it because the import kept failing.
[19:01] <kreuter> okay!
[19:01] <kreuter> thanks.
[19:01] <spwelton> persia: where do i upload to for that? launchpad? are you just talking about the filename?
[19:02] <persia> spwelton: Filenames on launchpad as upstream.  Doesn't matter at all: just wanted to make sure you knew that the packaging stuff didn't restrict upstream formats.
[19:07] <gusnan> So I got the error "sciteproj source: unknown-field-in-dsc original-maintainer" - does anybody have any clues on how to fix that?
[19:09] <lfaraone> gusnan: did you put in the control file "Original-Maintainter:" or "XSBC-Original-Maintainer:"?
[19:09] <gusnan> lfaraone, I've got the "XSBC-Original-Maintainer:" in the control - This is a package that isn't availible in Debian, and I am upstream myself.
[19:10] <lfaraone> gusnan: 'apt-cache source lintian' and tell me the version you have installed.
[19:12] <persia> This is a perfectly normal error, and can be ignored.
[19:12] <persia> It comes from dpkg, not from lintian.
[19:12] <lfaraone> persia: aha.
[19:12] <gusnan> Oh :)
[19:15] <persia> dooooomi: Have you considered working with the Debian Multimedia team to get your applications packaged?  That would reach an even wider userbase (and the freeze has a couple more weeks to go).
[19:16] <gusnan> Alright - then I believe the thing for me to do is ask: Could someone please take a look at my package sciteproj, (a project manager for use with Scite) - upstream at http://sciteproj.sf.net, and revu at http://revu.ubuntuwire.com/p/sciteproj. Thanks.
[19:17] <persia> gusnan: What's the "+nmu1" for?
[19:19] <gusnan> Non-maintainer upload? - I believe I am not supposed to be listed as maintainer?
[19:24] <persia> gusnan: Yes, but Ubuntu doesn't have maintainers, so we also don't have non-maintainer uploads.
[19:24] <persia> Anyway, rejected with a heap of comments
[19:24]  * persia likes easy packages to review
[19:24] <carneades> hi everyone. how do you specify in a .deb that *some* java is a dependency, but it's not important which one (OpenJDK/Sun)
[19:25] <gusnan> Thanks, persia
[19:25] <persia> carneades: Take a look at some other packages: it's usually something like "java2-runtime | default-jre"
[19:25] <carneades> thanks persia. is there any need/way to specify that the java can't be one of the headless ones?
[19:25] <randomaction> carneades: default-jdk or default-jre
[19:27] <persia> carneades: I think that does make that distinction, as opposed to "java2-runtime-headless | default-jre-headless", but it's been a while since I was packaging Java stuff, so you might want to check against other packages.
[19:27] <oojah> persia: If you want an easy one, the one I've been pimping should be. It's already gone through a few rounds of comments by Laney. http://revu.ubuntuwire.com/p/sqlite3-pcre
[19:27] <persia> #ubuntu-java may also be helpful, but it tends to be very time-of-day dependent.
[19:27] <oojah> I'd be particularly interested to know if the watch file is correct.
[19:27] <dooooomi> persia: actually, yes, i was planning to ask them about including the packages in debian. but i'd also like the packages to be in lucid, and the whole process of going through debian seems to take too long for that
[19:27] <persia> oojah: Having been mostly fixed makes it less easy, because I can't come up with > 10 comments just eyeballing the diff :)
[19:28] <persia> dooooomi: I guess.  Some people find the process of getting into Debian faster than getting into Ubuntu.
[19:28] <carneades> okay thank persia and randomaction
[19:28] <persia> dooooomi: May as well submit stuff there: if it gets in, you can sync, if not, maybe you can get through REVU in time.
[19:31] <oojah> persia: :)
[19:32] <dooooomi> persia: i'll write to the debian-multimedia list about it. debian actually has a RFP for gtklick
[19:33] <dooooomi> persia: meanwhile, it would still be great to have it reviewed and uploaded to ubuntu before lucid is frozen :)
[19:33] <lfaraone> dooooomi: main speedup with debian is you only need 1 person to sign off :)
[19:34] <lfaraone> dooooomi: but then you'll either need to wait for it to enter testing + sync automagically, or file a sync request and get a MOTU ACK.
[19:35] <sebner> lfaraone: autosync is off already. Today was/is the last day
[19:36] <dooooomi> lfaraone: seems like the right thing to do, at least for future versions of the package
[19:37] <lfaraone> dooooomi: yep, that's what I've done for all my NEW packages so far.
[19:39] <dooooomi> lfaraone: i guess i'd also have to install a debian system somewhere to test the packages?
[19:56] <maco2> persia: me?? i havent written a JACK patch...
[19:59] <LimCore>  fakeroot debian/rules clean
[19:59] <LimCore> /usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission denied
[19:59] <LimCore> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 126
[19:59] <LimCore> anyidea what is that?
[20:00] <paissad> i don't see debian/clean in debian policy, is it a makefile ?
[20:00] <jpds> paissad: debian/rules has a clean: target.
[20:01] <geser> LimCore: what permissions does debian/rules have?
[20:02] <paissad> jpds, yeah, i do know that, but actually a few hours ago, Laney & persia told me about debian/clean for removing some files & dirs of the source stream before beginning the build (it's about some dirs which are absolutely not concerned to the packaging and cause some lintian warnings !!)
[20:03] <LimCore> geser:   -rwxr-xr-x 1 makedeb makedeb
[20:04] <LimCore> geser: Im tyring to simply rebuild package subversion
[20:05] <LimCore> I simply  apt-get source
[20:05] <LimCore> then     debuild -us -uc
[20:05] <LimCore> and then this error, what is going on
[20:08] <gusnan> I got comments mentioning "validate-desktop-file" on my revu - In what package do I find that?
[20:08] <geser> LimCore: that looks ok, is /usr/bin/make also executable?
[20:09] <LimCore> -rwxr-xr-x 1 root root 165888 2009-06-23 12:28 /usr/bin/make
[20:10] <geser> hmm, that looks also ok
[20:11] <geser> gusnan: desktop-file-utils and the binary is called desktop-file-validate
[20:11] <geser> LimCore: calling make (without any parameters) works?
[20:11] <gusnan> oh, thanks! That explains why I didn't find it.. :)
[20:17] <paissad> i added some dirs in debian/clean ... but during the run of dh_clean, i have the error that says dir1 is a directory , dir2 is a directory, ... then i guess dh_clean does not use rm -rf , but just rm
[20:18] <paissad> how should i proceed then ? ... i don't see further information from the manpage
[20:19] <LimCore> makedeb@jumpi:~/subversion2/subversion-1.6.5dfsg$ make
[20:19] <LimCore> make: *** No targets specified and no makefile found.  Stop.
[20:20] <paissad> LimCore, you get it from apt-get source ?
[20:20] <LimCore> yes
[20:20] <paissad> LimCore, what about "fakeroot debian/rules binary" ?
[20:21] <LimCore> http://pastebin.com/m6eb275bd
[20:21] <LimCore> it gives /usr/bin/fakeroot: debian/rules: /usr/bin/make: bad interpreter: Permission denied
[20:22] <LimCore> btw, my /home is noexec
[20:22] <geser> :) that explains it
[20:22]  * LimCore facepalms
[20:22] <LimCore> why would compling need to execute binary files... :headdesk:
[20:23] <LimCore> we should add a pre-check to produce a meaningfull error message for this condition
[20:25] <geser> how many person mount their /home noexec?
[20:28] <LimCore> geser: it depends on number of ubuntu users, and number of users that are not informed about some security aspects
[20:28] <LimCore> I think this numbers are quite close togeather
[20:28] <bdrung> do someone here has time to review openshot (bug #441678) and give a second ACK for it?
[20:28] <bdrung> fabrice_sp: ^ you maybe?
[20:39] <quadrispro> ehya RoAkSoAx
[20:40] <RoAkSoAx> heya quadrispro
[20:40] <RoAkSoAx> how's it going?
[20:42] <quadrispro> great here, hope the same for you!
[20:43] <RoAkSoAx> quadrispro, yeah kind off... :)
[20:46] <persia> paissad: debian/clean is used by dh_clean
[20:46] <paissad> persia, yeah, i saw it in the manpage, but it does not remove not empty dirs !
[20:47] <persia> That's OK.  The only things you need to remove are the precompiled binaries.  Just leave the rest of the unused stuff in the directory tree unused.
[20:47] <paissad> :/
[20:56] <fabrice_sp> bdrung, will have a look tomorrow (late here)
[20:56] <bdrung> fabrice_sp: thanks
[20:57] <fabrice_sp> if no news within 24 hours, ping me ;-)
[20:57] <fabrice_sp> bye
[20:57] <bdrung> bye
[21:37] <paissad> les gars, je ne comprends pas la raison pour laquelle je reçois toujours le même warning lintian sachant qiue j'ai supprimé les fichiers concernés
[21:38] <paissad> voici mon debian/rules, regardez la cible clean
[21:38] <paissad> http://pastebin.com/f4d174e23
[21:39] <paissad> voci certains warnings conernant le sujet, http://pastebin.com/m436ec776
[21:39] <azeem_> this is an english-language channel
[21:40] <paissad> yeah i know , i mistaken ^^
[21:54] <kamalmostafa> ScottK: Hi
[21:54] <ScottK> Hi kamalmostafa.  I've been mostly offline and busy with work so I haven't had a chance to review anything.
[21:56] <kamalmostafa> ScottK: Understood, but I would really like to get libtifiles/libticalcs resolved -- we have been sitting on it for too long now and its holding up other folks' work.   If you're too busy to review it, perhaps we should consider just putting my completed packages on u-u-s for review?
[21:57] <ScottK> kamalmostafa: I think that's fine.
[21:58] <kamalmostafa> ScottK: Okay very good.  I'll make sure they still build (its been a few weeks!) and release them to u-u-s.   I think I should proceed then to the rest of the libti set -- do you agree?
[22:02] <kamalmostafa> persia: I think you had some interest (?) in the libti stuff also, so heads-up.
[22:03] <persia> kamalmostafa: Feel free to subscribe me to the bug if I'm not already subscribed.  I can't promise I'll get to it soonest, but I'd like to see it sorted.
[22:04] <kamalmostafa> persia: will do.
[22:08] <LimCore> the build command appears to be running some test or something, how to disable that?
[22:08] <LimCore> some stupid unit tests for python, while building subversion
[22:10] <geser> you should better let the test-suite enabled
[22:11] <geser> and those test are probably from the python bindings (python-subversion build from subversion)
[22:11] <ScottK> kamalmostafa: Yes.
[22:25] <asbin> Hi ervybody. I would to have 1 package reviewed ... (enna : http://revu.ubuntuwire.com/details.py?upid=7677 )
[22:26] <asbin> I'm seing on REVU, at the top : "Next REVU Day: TBD", what this means ?
[22:26] <lfaraone> asbin: "to be decided"
[22:26] <asbin> I see
[22:27] <asbin> so, what are the odds to have a new package included in Lucid at time ?
[22:27] <asbin> and thank you lfaraone !
[22:29] <lfaraone> asbin: it depends on whether you can find someone to review it :)
[22:30] <asbin> lfaraone: not only "someone", but 2 MOTUs ! :)
[22:31] <persia> asbin: How does enna perform at 800x480 pixels?
[22:34] <asbin> persia: yes I think so !
[22:34] <persia> asbin: You think it works?  Let me ask this differently: would this be a good thing to install on a handheld?
[22:35]  * persia likes EFL stuff for handhelds, but lots of media stuff expects more processing power than is typically available
[22:35] <asbin> persia: Enna works perfectly on a Nokia N900 !
[22:36] <asbin> for example
[22:38] <MTecknology> !info tetgen
[22:38] <MTecknology> !info tetgen lucid
[22:39] <persia> asbin: That's what I wanted to hear.  I'll add it to my list of stuff to hit as soon as I can get some real REVU time, and take a quick look at the diff now to see if anything pops out.
[22:40] <MTecknology> The latest version of that package is 1.4.3; how do I find out the best way to see that it finds its way into lucid?
[22:40] <asbin> persia: great news ! :) Thank you in advance ...
[22:42] <bdrung> geser: what is P-a-S?
[22:43] <geser> Packages-arch-Specific
[22:43] <geser> a list of overrides for the Architecture field
[22:44] <persia> asbin: I've put up a few minor comments, mostly as points for thought.  I'll give it a real review when I have time, whether you upload it again or not.
[22:47] <asbin> persia: thank you very much ! I will fix this ASAP !
[22:48] <bdrung> geser: bug #519996
[22:48] <asbin> persia: I mean tomorrow ...
[22:48] <MTecknology> !info openoffice.org lucid
[22:49] <persia> asbin: heh
[22:54] <lfaraone> !info python-xdgapp lucid
[22:54] <geser> bdrung: the control file already specifies amd64, i386, ia64 and ppc64 but P-a-S overwrites it currently to only ia64
[22:54] <geser> don't know if ARM == armel and if it should get added there too
[22:55] <geser> see https://code.edge.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu for the current P-a-S list for ubuntu
[22:56] <lfaraone> geser: not all ARM devices can run armel code, but all ARMel devices can run arm code.
[22:57] <persia> Um, not necessarily.
[22:57] <persia> And it gets complicated by Thumb1 and Thumb2 internetworking.
[22:57] <persia> That said, we compile everything afresh, so it doesn't matter that much.
[22:57] <lfaraone> persia: oh? my apologies, I'm not very familiar with the field, just speaking off what I recalled.
[22:58] <persia> In terms of dpkg-architecture, "arm" != "armeb" != "armel".
[22:58] <geser> this is about libunwind saying "ARM, MIPS and PowerPC support added"
[22:58] <persia> And due to massive differences in toolchain defaults, Debian "armel" != Ubuntu "armel".
[22:58] <persia> That's definitely worth a compilation attempt.  Worst case, we end up with a FTBFS package.
[22:59] <persia> Has someone tried a local emulated build?
[22:59] <bdrung> yes, but better a FTBFS instead of not building. and maybe the FTBFS can be fixed easily.
[22:59] <bdrung> persia: emulated build?
[23:00] <lfaraone> persia: hm. has there been effort to synchronize the toolchain settings?
[23:00] <persia> bdrung: Yep.  With lucid pbuilder-dist or mk-sbuild{-lv,}, you can build armel packages on i386 or amd64.
[23:01] <persia> lfaraone: quite the opposite.  Debian targets ARMv4te+ and Ubuntu targets much more modern processors (different set each cycle so far).  So, for newer stuff, Ubuntu is faster than Debian, but for older stuff, Debian works and Ubuntu doesn't>
[23:01] <persia> For example, the SheevaPlug ships with something based on jaunty prerelease, but it can't run karmic.
[23:02] <bdrung> persia: pbuilder-dist can cross-compile?
[23:02] <geser> qemu
[23:02] <persia> bdrung: The lucid one can, but it's not cross-compilation, it's emulated-compilation using a binfmt-misc hack to invoke qemu.
[23:03] <persia> bdrung: I believe it's `pbuilder-dist --arch=armel lucid create` on lucid, but I don't use pbuilder much, so I might have that wrong.
[23:03] <bdrung> k, qemu. for small packages it's ok.
[23:03] <persia> RIght.  Openoffice would take a while :)
[23:04] <bdrung> i don't want to compile eclipse in it.
[23:04] <persia> No :)
[23:04] <bdrung> (except i am one day far away of my computer)
[23:04] <persia> Only one day?
[23:05] <bdrung> persia: times 10 isn't enough?
[23:06] <bdrung> persia: i need 15 mins to compile eclipse on amd64.
[23:06] <persia> bdrung: That's all?  Maybe it is enough.
[23:06] <persia> bdrung: https://launchpad.net/ubuntu/+source/eclipse/3.5.1+repack~3-0ubuntu2/+build/1474867
[23:06] <persia> Or maybe https://launchpad.net/ubuntu/+source/eclipse/3.5.1+repack~1-0ubuntu3/+build/1314062 is more interesting.
[23:06] <lfaraone> did they manage to get the later versions of eclipse to compile?
[23:07] <lfaraone> interesting, last time I checked we had 3.2
[23:07] <persia> lfaraone: It's being sorted ;)
[23:08] <bdrung> lfaraone: thanks to eclipse-build and DOA team we have 3.5.1 in karmic.
[23:08] <bdrung> persia: it's faster than build oo.org: https://launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0~rc4-1ubuntu1/+build/1478069
[23:09] <persia> bdrung: Indeed :)
[23:11] <persia> Too bad the build log didn't capture the error report from the JDK though.  Hard to debug with that information without spending 10 hours running an emulated build.
[23:12] <bdrung> persia: you need a fast hard disk. eclipse produces 20.8 MiB log (there were day where it produced 30 MiB)
[23:13] <persia> Ah, that's not me then.
[23:13]  * persia is disk-limited when running aptitude
[23:15] <gusnan> ls
[23:15] <asbin> persia: I've fixed the package following your recommendations, it's uploading right now :)
[23:16] <lfaraone> persia: is it just me, or has aptitude/apt/dpkg gotten considerably slower in karmic when it reads package lists?
[23:17] <persia> lfaraone: I haven't noticed any special difference, but I've seen that symptom before on a system that was upgraded a lot.  There's a way to dispose of history (which I forget) that speeds it up considerably on systems that have been continuously upgraded for a while.
[23:34] <gusnan> Could someone please take a look on the "sciteproj" package on revu for me? It is availible here: http://revu.ubuntuwire.com/details.py?upid=7682