[00:00] <Laney> oojah: Cool. I have a couple of comments but I'll give you a conditional advocation
[00:00] <oojah> Laney: Ok, thanks.
[00:01] <oojah> What's the condition?
[00:01]  * Laney is writing it on REVU now
[00:01] <oojah> Duh, yeah
[00:01] <rmunn> lfaraone, thanks for the advice on Debian package submission about 15 minutes ago. (Was AFK for a bit). Saved an IRC transcript and I'll read it over later -- only mildly confused at this point, which probably goes to show that I don't have my head wrapped around the process yet. :-)
[00:01] <lfaraone> Short descriptions  should almost always start with a lowercase letter, right?
[00:03] <lfaraone> rmunn: no problem. for "normal" non-python packages (or those where you just feel like "being a rebel"), you can upload to mentors.debian.net (like REVU), and search for a sponsor, but with DPMT you're spared the sponsor search and get the benefits from group-maintenance. :)
[00:03] <BlackZ> good night guys ;)
[00:05] <Laney> oojah: go go go
[00:05] <Laney> you can ping me to re-advocate after you fix it if you want
[00:06] <Laney> but it's not really necessary
[00:07] <oojah> Laney: Thanks very much.
[00:07] <oojah> Very good point about the copyright which ought to have been obvious.
[00:08] <Laney> That's fresh in my mind because I did something with some PD work recently
[00:09] <oojah> I'll have to deal with them tomorrow now.
[00:09] <PATX> i made a needs packaging bug a couple months ago but nothing has really been done... how could i get someone to look at it? https://bugs.launchpad.net/ubuntu/+bug/416634
[00:10] <Laney> !revu
[00:10] <Laney> PATX: use revu if you have a package to submit
[00:10] <lfaraone> PATX: you should submit it to REVU :)
[00:10] <PATX> Laney, thanks :)
[00:10] <PATX> thanks everybody :)
[00:10] <oojah> Laney: Come out some time, I'll buy you a beer.
[00:10] <Laney> oojah: I will and maybe even can now that nlug seems to have moved to Wednesdays
[00:11] <lfaraone> hopefully the next US UDS will be on the East Coast <_<;
[00:11] <Laney> I think I'm doing something this week, but maybe that's lies because I don't actually remember what it is
[00:11] <Laney> oh, going to Fun in the Afternoon in London
[00:12] <james_w> lfaraone: if xdgapp is going to be pulled in to groundcontrol and the package is already in Ubuntu then we should remove xdgapp from Ubuntu for this release IMO
[00:12] <oojah> I rarely make it to nlug, but will be meeting former nlug peeps for drinks at some point in the next few weeks.
[00:12] <Laney> oojah: let me know if it's not a monday/thursday and I'll see what I can do
[00:12] <oojah> Will mention it in #nlug.
[00:12] <PATX> How do I upload to REVU?
[00:12] <oojah> Night!
[00:12] <lfaraone> james_w: well, we're still on appeal on that one :)
[00:12] <Laney> cool
[00:13] <Laney> see ya
[00:13] <lfaraone> PATX: see https://wiki.ubuntu.com/MOTU/Packages/REVU
[00:13] <DmitryKurochkin> I am repeating myself, but if someone has time to review a package, please take a look at http://revu.ubuntuwire.com/p/polygraph. The is one advocation already.
[00:15] <bdrung_> oojah: the link in debian/watch should be a comment, too
[00:20] <Laney> oh, rats
[00:20] <Laney> I noticed another thing >:(
[00:20] <bdrung_> Laney: ?
[00:21] <Laney> get-orig-source should always download the same thing
[00:22] <bdrung_> it will get more complex
[00:22] <Laney> so?
[00:23] <Laney> its purpose is to reconstruct the upstream tarball
[00:23] <Laney> oh shit
[00:23] <Laney> !language
[00:24] <Laney> that's actually a lie, and me misremebering policy
[00:24]  * Laney thinks that policy is wrong here
[00:24] <bdrung_> Laney: it has to grep the upstream version from debian/changelog and get the right git revision to checkout
[00:25] <bdrung_> (and not the other way around)
[00:25] <Laney> actually it has to get the most recent version
[00:25] <Laney> but I would rather it got the version that we want to upload
[00:26] <Laney> dpkg-parsechangelog can make this easy enough
[00:30] <PATX> Ok, so how long will it take for two MOTUs to review http://revu.ubuntuwire.com/p/fastpatx ?
[00:31] <Laney> a long time :)
[00:31] <Laney> you might try PAPT in Debian
[00:32] <PATX> PAPT?
[00:32] <bdrung_> PATX: fix all lintian reports and then ask again
[00:32] <PATX> bdrung_ ok...
[00:35] <lfaraone> PATX: example, apparently you're building a debian-native package. Did you forget to include the orig.tar.gz file above where your package directory is?
[00:36] <lfaraone> Laney: oh, that's what policy says? screw policy, then.
[00:36] <lfaraone> Laney: that's really odd.
[00:36] <Laney> yes, it sucks
[00:37] <lfaraone> Laney: here's the get-orig-source rule I used for a git-using package I work on: http://bazaar.launchpad.net/~lfaraone/gtksheet/debian/annotate/head%3A/debian/rules#L19 , that might be useful to borrow from.
[00:38] <Laney> lfaraone: tell it to oojah
[00:38]  * Laney is a mere reviewer here
[00:38] <lfaraone> oojah: here's the get-orig-source rule I used for a git-using package I work on: http://bazaar.launchpad.net/~lfaraone/gtksheet/debian/annotate/head%3A/debian/rules#L19 , that might be useful to borrow from.
[01:18] <PATX> ok one error is that my email is not @ubuntu.com how can i fix this?
[01:20] <persia> PATX: Run update-maintainer in the package directory
[01:20] <PATX> ok thanks then i can use my email?
[01:20] <persia> How do you mean?
[01:21] <StevenK> I think he wants to set the maintainer address to his own e-mail address
[01:21] <PATX> well i do not have a patx@ubuntu.com so when i upload the pkg to REVU i need to use my gmail correct?
[01:21] <PATX> StevenK, could i do anything else?
[01:22] <PATX> but yea thats what i want
[01:23] <persia> PATX: If you're submitting something to be included in Ubuntu, you want to set the maintainer to be an Ubuntu team (all the developers is the default).  The common practice is to set one's own name and email as XSBC-Original-Maintainer.  If you already have your own name and email as the Maintainer, update-maintainer will do this automatically.
[01:23] <PATX> ok
[01:23]  * persia wonders if this remains appropriate default behaviour given the proliferation of third-party repositories for which nobody in Ubuntu wishes to claim any responsibility
[01:24] <PATX> do i run that before or after buildng?
[01:24] <persia> At any point, but you'll want to have run it before you prepare the source package for upload.
[01:25] <PATX> ok
[01:34] <PATX> Ok now how would I go about fixing "This package has no debian/watch file or get-orig-source rule."?
[01:46] <persia> PATX: man uscan to read about watch files
[01:46] <PATX> ok ty
[01:51] <PATX> persia, so i have to make a debian/watch???
[01:52] <persia> That's the best practice, yes.
[01:52] <PATX> would my pkg have any chance of getting in w/ out one?
[01:54] <persia> PATX: How would anyone know when the package needs to be updated without one?
[01:54] <PATX> idk
[01:54] <persia> But that aside, since FeatureFreeze is in a couple days, your application has a decidedly low chance of making it anyway.
[01:55] <persia> But yeah, the watch file is an important component of our ability to make sure the archive is in reasonable shape.
[01:55] <PATX> ok
[01:56] <PATX> so should i just wait to do this untill the next version of ubuntu?
[01:58] <persia> Actually, now isn't a bad time to get a package in shape.
[01:58] <persia> But don't be surprised if it doesn't make the lucid deadline.
[01:58] <persia> My recommendation would be to get the package in the best shape you can, and submit it to Debian.
[01:58] <persia> That way it can be synced when archive opens for the next release.
[01:59] <persia> if it doesn't get into Debian in that time, you can go back to chasing REVU.
[01:59] <PATX> ok
[03:24] <Gaming4JC> I wasn't quite sure where to ask this, but the BZFlag client is out dated in the main repos - since they came out with an entirely new client today. http://sourceforge.net/projects/bzflag/
[03:27] <persia> Today?  Ugh.  That doesn't leave much time.
[03:28] <persia> Please file a bug against bzflag requesting an upgrade.
[03:28] <Gaming4JC> using launchpad?
[03:28]  * Gaming4JC goes there...
[03:28] <persia> ubuntu-bug bzflag is probably the easiest way to file it.
[03:32] <Gaming4JC> ok thanks, and what about another substantially outdated one... Blender?
[03:32] <Gaming4JC> file a bug report for that too? 2.49b has been out for almost a year
[03:32] <Gaming4JC> lol
[03:33] <persia> Blender is kinda special.
[03:33] <wgrant> 2.49.2 is in Lucid.
[03:33] <wgrant> And yes, Blender is a very special thing.
[03:34] <Gaming4JC> really? o.O
[03:34] <wgrant> Ah, and 2.49.2 is actually 2.49b
[03:55] <Gaming4JC> persia: This correct? :) https://bugs.launchpad.net/ubuntu/+source/bzflag/+bug/522448
[03:56] <nigelb> I've been working on fixing a small bug, but I run into issues because the quilt patch is applying changes on a file that gets deleted at build time.  So, how do I go about fixing it?
[03:57] <persia> Gaming4JC: Except I don't know why you've made it private.
[03:57] <persia> nigelb: Why are you patching a file that gets deleted at build time?
[03:57] <Gaming4JC> persia: hmm, I'm unsure as well considering I never checked that option anywhere lol o.O
[03:58] <persia> Gaming4JC: If you make it less private, I'll tell you if it works.
[03:58] <nigelb> persia: I'm still unsure where its being deleted at build time or renamed
[03:58] <nigelb> s/where/whether
[03:58] <persia> nigelb: The build log should tell you.
[03:58] <nigelb> where do I see the build log?
[03:59] <nigelb> ah, the .build file
[03:59] <persia> How did you build it?
[04:00] <nigelb> debuild -S -sa
[04:00] <nigelb> yes, it is getting deleted "rm -f rules/evdev rules/evdev.xml.in"
[04:00] <Gaming4JC> persia: made it public. :)
[04:00] <nigelb> so that means, I can ignore the mistake in that file since its going to be deleted anyway?
[04:01] <persia> nigelb: Maybe: it depends on whether it gets used before it is deleted.
[04:01] <nigelb> Is it possible to figure that out from the logs?
[04:02] <persia> Usually.  Look for previous uses of the filename in the log.
[04:03] <nigelb> only the rm -f statement
[04:03] <persia> Then it's probably not used.
[04:03] <nigelb> so, I can skip patching that file and its okay?
[04:03] <persia> Gaming4JC: Did bzflag do their usual thing and not allow older clients?
[04:03] <persia> nigelb: Test and see :)
[04:03] <nigelb> thank you.  Checking now :)
[04:03] <Gaming4JC> persia: sort of, they still allow the old client but keep telling me to update all the time
[04:04] <persia> Gaming4JC: Hrm.  That's better than it used to be, but still a clear hint.  Thanks.
[04:04] <Gaming4JC> np :)
[04:04] <Gaming4JC> well, 'tis late here
[04:04] <Gaming4JC> ttyl and thank man :D
[04:04] <Gaming4JC> thanks*
[04:26] <nigelb> how do I know pbuilder successfully built a package? lack of errors?
[04:36] <suji11> how to create package for hunspell-ta ? i'm having the dic file and aff file.
[04:49] <suji11> how to i review the packages in revu.ubuntuwire.com
[04:54] <nigelb> I'm looking for a main sponser to review a patch I have submitted :)
[04:54] <nigelb> anyone around?
[04:55] <nigelb> persia: ^^
[04:56] <nigelb> bug 398873
[05:48] <micahg> any ubuntu-sru members around to see if something is SRU worthy?
[05:58] <micahg> nigelb: main sponsors are in #ubuntu-devel
[06:02] <nigelb> oh, thanks micahg
[06:58] <eagles0513875> hey guys i have read through the packaging documentation. how does one determine out of the various packaging methods available which one is the best for that particular package or situation?
[07:15] <toabctl> i try to fill a syncrequest with: requestsync -d unstable -n --lp -s python-pisa lucid
[07:15] <toabctl> but the error is: E: The package 'python-pisa' does not exist in the Debian primary archive in 'sid'
[07:16] <toabctl> but the package is available: see http://packages.debian.org/sid/python-pisa
[07:22] <randomaction> toabctl: this package is very new
[07:23] <toabctl> randomaction, yes. that's a problem?
[07:23] <randomaction> try again in several hours
[07:23] <toabctl> ok
[07:23] <toabctl> thx
[07:23] <randomaction> yes, PTS has no information on it yet: http://packages.qa.debian.org/p/pisa.html
[07:26] <eagles0513875> randomaction: im just wondering. i read through all the packaging guide and im a little lost. how does one determine which method is correct to use or does it depend on what the type of package is
[07:27] <randomaction> eagles0513875: What's your problem?
[07:27] <eagles0513875> randomaction: not a problem im just trying to understand the purpose of having so many different packaging methods and how to choose the right one. im hoping to eventually become an motu but i need to get my packaging skills up to snuff first.
[07:35] <dholbach> good morning
[07:37] <eagles0513875> good morning dholbach
[07:38] <dholbach> hi eagles0513875
[07:38] <eagles0513875> dholbach: are motus responsible for all repos? or just in charge of the packages
[07:40] <dholbach> eagles0513875: as a MOTU you can upload packages to universe and multiverse
[07:41] <eagles0513875> im not motu yet im still trying to figure out packaging. i read through the complete packaging guide yet im confused as to how to determine which out of all the options available for packaging is ideal to use, or is it dependent on the type of package that needs to be created?
[07:42] <dholbach> there's lots of different ways to get a package done
[07:42] <eagles0513875> so it is dependent on what i get used to
[07:42] <dholbach> I learned the most by working on existing packages
[07:43] <dholbach> so you just modify small bits here and there in order to fix a bug and you get exposed to whatever the maintainer thought they'd use for packaging
[07:43] <dholbach> that way you learn multiple approaches
[07:43] <eagles0513875> ok kool will give that a try :)
[07:44] <eagles0513875> question about mentoring. it is where someone takes me for ex under their wing and shows me how to fix the bugs etc?
[07:44] <dholbach> AFAIK the mentoring programme is having difficulties at the moment
[07:45] <dholbach> so it's probably better to start off on your own and just ask questions in here
[07:45] <dholbach> there's always somebody around to help out
[07:51] <iulian> G'morning dholbach.
[07:51] <dholbach> oi iulian! how are you doing?
[07:54] <iulian> dholbach: I'm doing fine.  How about you?
[07:54]  * iulian is doing his physics homework now.
[07:55]  * eagles0513875 is doing programming hw
[07:55] <dholbach> iulian: good - thanks :)
[07:55] <eagles0513875> dholbach: last question. whose in charge over all of maintaining the repositories? cuz im trying to upgrade from karmic to lucid and im getting a 403 on one of the repos
[07:58] <dholbach> eagles0513875: https://launchpad.net/ubuntu/+archivemirrors
[07:58] <dholbach> some mirrors might be a bit out of sync
[07:58] <eagles0513875> this one hasnt been working since yesterday though
[08:03] <slytherin> Does anyone know what does 'Apply to be an official mirror of this distribution' mean when registering new mirror?
[08:11] <eagles0513875> slytherin: you got me curious as well about that
[08:12] <slytherin> eagles0513875: If I understand correctly the official mirror (whichever it is) will be used by installer when doing a fresh install.
[08:15] <eagles0513875> slytherin: i dont quite understand
[08:16] <slytherin> eagles0513875: When I install Ubuntu from scratch the installer will have a list of official mirror for each country. So if the country I selected ininstaller has a official mirror assigned that mirror will be set in /etc/apt/sources.list.
[08:23] <eagles0513875> slytherin: i know that but the one i have i hate using it cuz its on such a slow connection. and there is only one for my country. im wondering if i could setup a virtual machine with another mirror for my country
[08:24] <slytherin> eagles0513875: Or you could buy some hosting space through community funding and manager a mirror.
[08:24] <slytherin> s/manager/manage
[08:24] <eagles0513875> i have a monster desktop that i can run a vm on. thats not a problem for me
[08:26] <slytherin> eagles0513875: Do you own a domain and static IP?
[08:26] <eagles0513875> i do own a domain but its pointed at another server atm :(
[08:31] <slytherin> eagles0513875: you can use services such a sdyndns
[08:31] <slytherin> http://www.dyndns.com/
[08:31] <eagles0513875> slytherin: i already do
[08:32] <slytherin> then setting up the mirror should not be a big trouble.
[08:32] <eagles0513875> slytherin: do you have any documentation or anything for that
[08:32] <slytherin> I believe Ubuntu wiki does have some documentation.
[08:33] <slytherin> eagles0513875: https://wiki.ubuntu.com/Archive/Mirroring
[08:33] <eagles0513875> thanks slytherin
[09:09] <oojah> Laney: I've uploaded a new sqlite3-pcre if you wanted to check the get-orig-source.
[09:29] <Laney> advocated
[09:32] <oojah> Ta
[10:45] <oojah> I'm looking for a second advocate for http://revu.ubuntuwire.com/p/sqlite3-pcre Can anybody help?
[11:21]  * Laney adds a ticker to the agda-stdlib build
[11:21] <Laney> Agda + armel are not friends
[11:22] <persia> Laney: How does the ticker work?  I think schroot suffers from the same issue (although it may be that it's trying to build stuff that shouldn't be built for arch:any)
[11:24] <Laney> persia: it just generates some output so the build isn't timed out
[11:25] <persia> Laney: Does one do this with a parallel process, or just extra noisiness in the part that hits the timeout?
[11:25] <Laney> a parallel process (it's just a simple shell script)
[11:25] <Laney> watches for the build's PID and the creation of the build-stamp file, typically
[11:26] <Laney> http://git.debian.org/?p=pkg-haskell/agda.git;a=blob;f=debian/watcher.sh;h=0de582d7162cd262e89a43dbd19c154d460ca294;hb=HEAD
[11:26] <Laney> like that
[11:26] <persia> Laney: And how does one call it?
[11:27] <Laney> sh debian/watcher.sh "$$PPID" "$(CURDIR)" "$(CURDIR)/build-stamp" 'ghc' &
[11:28] <Laney> the locking part was added by me because I couldn't figure out how to get cdbs not to call it multiple times
[11:29] <persia> So PPID is the PID of the make executing debian/rules?
[11:29] <Laney> yes
[11:30] <persia> Nifty.  I'll definitely have to give that a shot.
[11:30] <Laney> you could definitely make it more specific to your failure case, but this is general enough to work without much effort
[11:31] <Laney> even if it adds some noise to the build output
[11:33] <persia> Laney: That's why I asked :)  I wanted something that didn't require thought to get stuff to compile.  Actually optimising to make it not need to take so long is step two.
[12:01] <lbrinkma> What's the status about the libmysqlclient problem?
[12:02] <persia> lbrinkma: last I saw there was still discussion about how to fix it in an sane manner.  I thought it only affected building packages.
[12:04] <lbrinkma> persia: yes, it's true. But i want to upload a package to REVU that depends on anjuta and anjuta depends on libaprutil, and that on libmysqlclient. So it won't work
[12:04] <persia> REVU doesn't build anything, so it'll be fine.
[12:05] <lbrinkma> persia: but it's hard to test it when i can't build it
[12:05] <persia> lbrinkma: Indeed, and hard to review for the same reason :)
[12:32] <paissad> i know it's not a question related to the channel, but  i just would like to know if ppa lauchnpad accepts uploads of freewares ( i packaged a software whose source code is not available .... it's already built)
[12:35] <slytherin> paissad: The Launchpad usage policy forbid that.
[12:35] <paissad> slytherin, ok thanks
[12:36] <persia> Does it?
[12:36] <persia> I know Ubuntu accepts some freeware under certain conditions (but we don't like it, and drop it if it's buggy)
[12:44] <slytherin> paissad: persia: I remember reading the usage conditions some time back. Can not find a link to it now. Asking on #launchpad for clarification is best.
[12:45] <persia> Generally :)
[12:49] <slytherin> paissad: Found this - https://help.launchpad.net/PPATermsofUse
[12:49] <paissad> ok
[12:52] <om26er> if it want to update a package in lucid what should I do? open [needs packaging] bug or needs update/or something like that?
[12:54] <slytherin> om26er: Are you going to work on update?
[12:54] <persia> om26er: It's not a "needs packaging" bug.  It's an "upgrade" bug.  Just identify the target version, the rationale, and add the upgrade tag.
[12:54] <om26er> persia, ok, thanks
[12:54] <om26er> slytherin, I will try :)
[12:55] <slytherin> as persia said, it is upgrade bug. But if the package exists in Debian then first check if anyone is working on upgrade.
[12:57] <om26er> slytherin, it just released
[12:57] <om26er> like an hour ago
[12:58] <slytherin> om26er: that does not mean you have to update it in Ubuntu first. :-)
[13:23]  * Laney is going to kick off the haskell transition later, probably
[13:23] <Laney> fun fun fun :)
[13:30] <Laney> later = now
[13:30]  * Laney uploads ghc6
[13:32] <persia> Go, Go, Go!
[13:34] <Laney> http://people.canonical.com/~pitti/scripts/syncpackage is a useful script
[13:35] <persia> Laney: Take care: I've seen requests that people not use that.
[13:36] <persia> Laney: It's usually not *too* hard to get a friendly archive-admin to do a batch together.
[13:36] <Laney> persia: how come?
[13:36] <Laney> I will be requesting a *lot* of syncs in the next days
[13:36] <persia> Because, although it does mostly the right thing, it does it in a way that is messy within Soyuz somehow.
[13:36] <Laney> oh
[13:37] <persia> Just find an archive admin, and tell them the plan, and have them run the syncs.
[13:37] <persia> I believe the current script is similar to the one you referenced, but it's designed to be run inside Soyuz, from what I understand.
[13:38] <Laney> it will just look like a normal upload
[13:38] <Laney> maybe syncs have some special processing
[13:38] <persia> They do.
[13:38]  * persia doesn't know the details, but suspects an archive-admin would be willing to explain.  Might ask in -devel
[13:38] <Laney> james_w: ^^^ ?
[13:40] <james_w> Laney: I'd be happy to bulk-sync things for you
[13:41] <Laney> cool. Is it really not advised to use that script?
[13:41]  * Laney mainly does it to avoid hassling people
[13:41] <ripps> Hey, any broken packages that need some packaging fixed? I looking to help a bit
[13:42] <Laney> subject: ghc6_6.12.1-9_source.changes rejected
[13:42] <Laney> :(
[13:42] <Laney> james_w: could you do that sync? ghc6 from unstable
[13:42] <james_w> Laney: I'd only be repeating what others told me if I said that it wasn't advised. I don't know the details
[13:42] <Laney> it's a big orig
[13:42] <james_w> Laney: I can try
[13:42] <Laney> thanks
[13:52] <directhex> what's the best way to turn a normal bug into a requestsync?
[13:52] <Laney> edit the title and description, i'd have thought
[13:52] <Laney> or invalid it and requestsync again
[13:52] <Rhonda> And add the appropirate team.
[13:52] <directhex> & subscribe archive admin, since i'm motu & it's in loonyverse?
[13:52] <Laney> yes
[13:53] <Laney> + confirmed
[13:53] <sebner> persia: urgh, cjwatson is on holidays this week, we have to find someone else to backport it on the buildmachines :\
[13:54] <persia> sebner: Check with jdong about the base backport: he is the backport master (but first make sure a backport to hardy works locally for you)
[13:54] <sebner> directhex: + wishlist if you are motivated :P
[13:55] <sebner> persia: aye
[13:56] <directhex> if --lp is recommended, as per --help, then why isn't it the default behaviour?
[13:56] <Laney> it requires setting up credentials, I guess
[13:56] <Laney> higher barrier to entry
[13:57] <sebner> Laney: funnily that never worked for me ¬_¬
[13:57] <Laney> ~/.udtrc would be good though
[13:57] <Laney> sebner: what's that?
[13:58] <slytherin> ripps: take a look at FTBFS page. http://qa.ubuntuwire.com/ftbfs
[13:58] <sebner> Laney: setting up credentials
[13:59] <slytherin> sebner: What problem did you get?
[13:59] <geser> directhex: mostly historic reason, as requestsync was using mail at first, then later used python-launchpad-bugs (still before the LP API) nobody wanted to change the default of "mail"
[14:00] <sebner> slytherin: hmm, can't remember but I'll give it another try so we can discuss that. Btw, what benefit do I have from it?
[14:00] <slytherin> sebner: When you use --lp it retrives info from Launchpad and hence will skip a few questions.
[14:00] <geser> sebner: you could use "ubuntu-build" for give-backs :)
[14:01] <slytherin> geser: I believe the command is buildd
[14:01] <sebner> ah, yes that's quite something useful :D
[14:02] <geser> slytherin: no, it got renamed to ubuntu-build in lucid since it conclicted with buildd from the package buildd (and I'm sure about it as I did the rename :)
[14:03] <slytherin> Oh. I haven't moved to lucid yet and do not plan to until it becomes final.
[14:03] <sebner> slytherin: ok, how do I set this stuff up? =)
[14:04] <sebner> geser: what about "package-rebuild" or "ubuntu-rebuild" :P
[14:04] <geser> sebner: "man manage-credentials" and c&p the example from there
[14:04] <slytherin> sebner: man manage-credentials, simplest form - manage-credentials create -c ubuntu-dev-tools
[14:05] <sebner> what level of access is common?
[14:06] <geser> write non-private
[14:06] <geser> you need it for filing sync requests
[14:08] <sebner> persia: argh, I just realized that dpkg itself is now also debsrc3.0 -.-
[14:08] <sebner> slytherin: geser: seems to have worked :D
[14:09] <persia> sebner: Well, in that case, find some recipe that allows you to handle the backport.  Passing someone a working recipe and asking them to execute is surely smoother than "Please do this hard thing" :)
[14:09] <sebner> heh
[14:11] <slytherin> sebner: backporting 3.0 package should not be hard. Try changing the 3.0 in format file to 1.0.
[14:11] <sebner> slytherin: well, it's not that easy with dpkg I suppose :P
[14:11] <slytherin> sebner: How do you know, did you try? :-)
[14:11] <sebner> slytherin: I'm currently looking at it
[14:32]  * Laibsch hopes we don't miss the boat again for http://revu.ubuntuwire.com/p/ffgtk
[14:38] <Laibsch> porthose: maybe you can take another look if it meets your requirements now?
[15:05] <oojah> Could someone please take a look at sqlite3-pcre? I'm looking for a second advocate.
[15:27] <Jeeves_> Hi all
[15:27] <shadeslayer> Jeeves_: hi
[15:27] <Jeeves_> I'm building a private package for sophie (sophos libsavi virusscanner)
[15:27] <Jeeves_> that package depends on libsavi, for which there isn't a package available
[15:28] <Jeeves_> now dh_shlibdeps is byting me.
[15:28] <Jeeves_> Any hints on skipping dh_shlibdeps?
[15:29] <geser> Jeeves_: is libsavi part of sophie?
[15:29] <Jeeves_> geser: No
[15:29] <Jeeves_> It is part of a non-packaged piece of software
[15:29] <Jeeves_> I've tried adding --dpkg-shlibdeps-params=--ignore-missing-info to dh in the rules file
[15:29] <geser> then you need to package it first? else how should your sophie package work with it?
[15:30] <Jeeves_> geser: I install the software before building the package
[15:30] <Jeeves_> I cannot package the other software, which is closed source and dynamically updated
[15:32] <geser> Jeeves_: and your user? the expect that "apt-get install sophie" gives them a working software
[15:32] <Jeeves_> geser: We are the only users.
[15:33] <Jeeves_> It's a private package in a completly controlled environment
[15:36] <geser> the best solution would be to also package libsavi for your use (even if it's closed source, you can skip the compilation part)
[15:37] <ari-tczew> please take a look for clean sync @ bug 522700
[15:37] <Jeeves_> geser: There's no way to skip shlibdebs?
[15:38] <geser> Jeeves_: I don't know of any (which would a hack anyways)
[15:54] <jcastro> hyperair, congratulations!
[15:54] <hyperair> jcastro: thanks. =)
[15:54]  * hyperair just saw jcastro's retweet
[15:54] <jcastro> ok so that means I'll get new banshee in lucid ... ? :p
[16:35] <tsmithe> persia, you around?
[16:36] <mr_steve> Hey MOTUs, if someone could have a look at http://revu.ubuntuwire.com/p/cnetworkmanager I'd sure appreciate it. Thanks in advance.
[16:37] <persia> tsmithe: Kinda, but in the middle of three different things.
[16:37] <persia> tsmithe: I presume this is because I didn't actually upload musecore yet?
[16:37] <tsmithe> ok. pisa has just been uploaded to debian; i was wondering if it could be synced; how should i request that?
[16:37] <tsmithe> oh, and yeah :p
[16:37] <persia> tsmithe: File a sync request bug (requestsync is a good tool for this).
[16:37] <tsmithe> ok.
[16:38] <tsmithe> if it gets in before you upload musescore, hold on, and i'll make a new package which employs pisa to generate the offline manauls
[16:38] <tsmithe> *manuals
[16:38] <tsmithe> (do you think that's likely?)
[16:39] <persia> Let's do that as a bugfix later if it all works by feature-freeze.  Adding more coordination increases the risk of failure prior to that.
[16:39] <persia> I presume we can use the same orig.tar.gz?
[16:39] <tsmithe> that's what i thought
[16:39] <tsmithe> and yes
[16:40] <persia> Yeah, let's do it that way then: so we don't hit the wall in 21 hours.
[16:40] <persia> Err, 31 hours.
[16:41] <tsmithe> cool; i was just concerned that you'd "waste" an upload :)
[16:45] <tsmithe> persia, sync request done; thanks. it's bug 522718
[16:50] <mhall119|work> can someone point me to where I can learn about what a package branch is, and how it should be maintained?
[16:54]  * popey also has a question..
[16:55] <popey> I'm looking at packaging something which is mostly just a shell script and a few other support files - source only - is there a package in the repo that i could learn from in terms of debian/rules and debian/install ?
[16:58] <james_w> hi mhall119|work
[16:58] <james_w> https://wiki.ubuntu.com/DistributedDevelopment has some information
[16:58] <james_w> basically a package branch is just using bzr to do packaging
[16:59] <james_w> or indeed any other VCS
[16:59] <james_w> therefore it's basically using bzr, with a few extra commands layered on top for packaging-specific operations
[17:00] <james_w> popey: try ubumirror
[17:00] <popey> thanks
[17:00] <mhall119|work> thanks james_w
[17:00] <mhall119|work> trying to learn the right way of doing all this
[17:06] <hyperair> https://launchpad.net/~ubuntu-motu <-- "Ubuntu MOTU Developers does not use Launchpad ..."
[17:06] <hyperair> heheh
[17:13] <mhall119|work> ok, I'm making package for Qimo (https://launchpad.net/qimo), it has no upstream package, so what should I put in debian/watch to satisfy lintian?
[17:15] <hyperair> # lintian sucks
[17:16] <abogani> mhall119|work: IMHO You should explain it into debian/watch!
[17:16] <james_w> mhall119|work: if you make it a "native package" then lintian shouldn't complain
[17:17] <mhall119|work> james_w: what's the difference in a "native package"?
[17:17] <Laney> I'd just explain it in README.source or elsewhere
[17:17] <Laney> (I presume you are package as a snapshot)
[17:17] <jbernard> james_w: thanks for sync'ing liblua-iconv
[17:17] <mhall119|work> abogani: explain it how?  a # comment?
[17:17] <hyperair> yeah, a # comment
[17:17] <mhall119|work> Laney: I'm the original developer
[17:17] <james_w> mhall119|work: it's a package that is only intended for Debian-based systems, and so doesn't have an upstream releasing tarballs etc.
[17:17] <Laney> mhall119|work: can't you make a release?
[17:19] <mhall119|work> Laney: you mean just a tarball?
[17:19] <Laney> sure
[17:19] <mhall119|work> it has to copy files into /etc/xdg, /etc/X11 and /usr/share
[17:19] <mhall119|work> could I do that with just a tarball?
[17:20] <mhall119|work> the project is hosted on launchpad
[17:21] <mhall119|work> james_w: how do I make a native package?
[17:21] <james_w> a release can just be making a tarball from your bzr branch
[17:21]  * mhall119|work hasn't a bzr branch
[17:22] <mhall119|work> which is why I was asking about making package branches
[17:22] <james_w> however, if there is no reason why anyone would use it outside of Ubuntu then you can just make a native package
[17:22] <mhall119|work> ok, how do I make a native package?
[17:22] <james_w> which you just do by changing the version number to have no "-" in it, so if it's 1.0-0ubuntu1 currently just make it 1.0
[17:22] <mhall119|work> oh, ok, I'll try that
[17:24] <mhall119|work> I get this warning:
[17:24] <mhall119|work> W: qimo-wallpaper: latest-debian-changelog-entry-changed-to-native
[17:24] <mhall119|work> is that okay?
[17:28] <james_w> mhall119|work: that sounds like lintian trying to protect you, but yeah, that's what you intend
[17:31] <mhall119|work> james_w: could you have a look: http://revu.ubuntuwire.com/details.py?upid=7831
[17:31] <mhall119|work> it says it has no .orig.tar.gz, but it's in the file list
[17:39] <persia> hyperair: Just FYI, there's a bit of a technical glitch: you'll be a MOTU soon.
[17:40] <hyperair> persia: okay. take your time =)
[17:45] <DmitryKurochkin> Looking for a second advocate for polygraph package - http://revu.ubuntuwire.com/p/polygraph. Can somebody review it, please?
[17:47] <bdrung_> can one motu have a look at yofrankie: http://revu.ubuntuwire.com/details.py?upid=7812
[17:47] <sebner> bdrung_: uhh, you will win the money :D
[17:48]  * hyperair clicks
[17:53] <hyperair> DmitryKurochkin: the current policy version is 3.8.4.0
[17:56] <DmitryKurochkin> hyperair: lintian compleined about it (I suppose it was not updated), so I uploaded with standards-version 3.8.3. No problem to update it again, no changes required.
[17:58] <hyperair> DmitryKurochkin: this is more of an aesthetic thing, but were the last two lines of debian/copyright intentionally wrapped like that? it looks like premature wrapping
[17:59] <hyperair> DmitryKurochkin: "Documentation, test results, ... available at www.web-polygraph.org" <-- i think you should put the http:// there
[18:01] <lightnin> Please help: I've got a programming language for kids called "Scratch" developed at MIT Media lab that I'm trying to get into multiverse. Needs to be revu 'ed..
[18:01] <DmitryKurochkin> hyperair: wrapping in debian/copyright is intentional, "see" can be moved to the previous line but the file name will have to stay on the second line anyway.
[18:01] <lightnin> http://revu.ubuntuwire.com/p/scratch
[18:02] <hyperair> DmitryKurochkin: ah i see.
[18:04] <DmitryKurochkin> hyperair: I would prefer to leave www.web-polygraph.org without http:// in the description. I think it looks better without http:// in sentences, and better with http:// in tables, etc.
[18:04] <hyperair> hmm
[18:04] <DmitryKurochkin> hyperair: it is a subjective thing, but if there is a policy on it, or recommended style, I will change it.
[18:05] <hyperair> i don't think there's a policy on it, nor do i know if it's a recommended style, but i prefer to have the http:// there, due to strange issues that can arise from stuff ripping out descriptions and linkifying stuff on web pages
[18:06] <hyperair> you know, without the http://, www.web-polygraph.org linkified would end up as http://the-site-you-saw-this-at.com/www.web-polygraph.org which would likely yield 404
[18:06] <randomaction> hyperair: congrats!
[18:06] <hyperair> randomaction: thanks!
[18:08] <hyperair> DmitryKurochkin: that said, i think having the url in the description again is kind of redundant since it's in the Homepage: field. i think it would be better to rephrase the description to remove the url, if possible.
[18:08] <DmitryKurochkin> hyperair: that is not true, take a look at http://revu.ubuntuwire.com/p/polygraph
[18:08] <DmitryKurochkin> it is linked to http://www.web-polygraph.org./ there.
[18:09] <DmitryKurochkin> that is not correct, but http:// would not help here
[18:09] <hyperair> DmitryKurochkin: that's REVU. what about other not-known, crappily-written, not-well-maintained utilities out there that also rip out descriptions from packages?
[18:10] <hyperair> but then again i know of any such utility out there
[18:10] <hyperair> it isn't a major issue, just more of me nitpicking
[18:12] <hyperair> DmitryKurochkin: oh yeah, one more thing.. your debian/copyright is fine as is, but it'd be better if you could follow http://dep.debian.net/deps/dep5/ in the future.
[18:12] <DmitryKurochkin> I can fix it if you insist, removing the link is a better option perhaps.
[18:13] <DmitryKurochkin> hyperair: yes, I have seen dep5 (after I packaged polygraph) and liked the idea. But I hope we can leave copyright as is for the initial upload and fix it later.
[18:13] <hyperair> it's completely up to you. i'd advocate/upload it as is (when my advocating/uploading privileges arrive) already.
[18:15] <DmitryKurochkin> hyperair: thanks! I was worried that I miss the deadline.
[18:16] <lightnin> Is appropriate control file entry for Section: multiverse/devel when submitting to multiverse?
[18:16] <hyperair> oho FF is tomorrow.
[18:17] <sebner> hyperair: that'll be a tough night your you then :P
[18:17] <sebner> *for
[18:17] <DmitryKurochkin> Isn't it on February 18?
[18:18] <hyperair> DmitryKurochkin: it's 17th here.
[18:18] <hyperair> i'll go get some sleep
[18:18] <hyperair> hopefully my uploading privileges arrive when i wake.
[18:18] <oojah> I'm looking for a second advocate for sqlite3-pcre can anybody help?
[18:18] <hyperair> sebner: or do you want to handle this?
[18:18] <DmitryKurochkin> Ihyperair: hope they do :)
[18:18] <hyperair> =)
[18:19] <sebner> hyperair: I'm working on quite some packages right now, so I didn't read your dicussion. what's it about?
[18:19] <hyperair> sebner: polygraph
[18:19] <hyperair> http://revu.ubuntuwire.com/p/polygraph
[18:20] <sebner> hyperair: urgh, I usually don't upload any cdbs packages (lack of knowledge) :P but I'll take a look later and upload it if nobody steps up first
[18:21] <hyperair> sebner: heheh don't worry, that cdbs package is very simple. just three lines.
[18:21] <hyperair> make that 4, with the #!
[18:22] <sebner> hyperair: yeah, so I'm making a special exception for you :P
[18:22] <hyperair> heheh
[18:23] <sebner> what about these spelling warnings?
[18:23] <hyperair> oh yeah, i think it'd be better if it could be patched up =\
[18:24] <sebner> + Standards-Version
[18:24] <DmitryKurochkin> sebner: it will be fixed in the next upstream release.
[18:24] <hyperair> but spelling errors are completely an upstream thing.
[18:24] <sebner> DmitryKurochkin: well, you certainly won't be able to upload a new upstream version (except bugfix only) but such a thing is no stopper bug for now
[18:31] <james_w> mhall119|work: sorry, got distracted. Where did qimo-session_2.0.0.orig.tar.gz come from?
[18:32] <mhall119|work> I just created a tarball of what I was trying to package
[18:32] <james_w> but you don't want to do that in future as an extra step?
[18:33] <mhall119|work> huh?
[18:33] <mhall119|work> I don't understand what you're asking
[18:34] <james_w> we were discussing earlier about whether there was an upstream that does releases
[18:34] <mhall119|work> oh, right
[18:34] <james_w> in effect that is what you did by creating that tarball, so you can continue doing it
[18:34] <mhall119|work> debuild wanted a .orig.tar.gz, so I just make one to make it happy
[18:34] <mhall119|work> ok
[18:34] <james_w> ok
[18:34] <mhall119|work> so is a package branch just a bzr branch of that tarball's content?
[18:35] <james_w> you can just delete it now that you have changed the version number, rebuild and then re-upload and the warning will go away
[18:35] <mhall119|work> or does the branch need to contain the tarball, plus the files it contains?
[18:35] <james_w> or rather, will be less confusing as it won't contradict what is clearly there
[18:35] <mhall119|work> oh, it was only necessary because it wasn't a native package before?
[18:35] <james_w> yeah
[18:35] <mhall119|work> ok, cool, thanks
[18:36] <mhall119|work> do I need to do that now, or is it okay as is?
[18:36] <james_w> debuild said (paraphrasing) "your version number suggests this package should have upstream releases, but you didn't give one of them too me, please do so"
[18:36] <mhall119|work> right, before I changed the version number, makes sense now
[18:36] <james_w> the content will be the same, so there's no real need
[18:36] <mhall119|work> I thought it still needed it to create the diffs
[18:36] <james_w> but if you don't then someone else will probably have this same conversation with you again :-)
[18:37] <james_w> it would, but if you do a native package then there is no upstream to create diffs against
[18:37] <mhall119|work> ok
[18:37] <james_w> it just puts everything in one tarball
[18:40] <lightnin> Please, oh mighty MOTUs: http://revu.ubuntuwire.com/p/scratch
[18:41] <mhall119|work> hey, that takes care of needing a debian/watch file too
[18:41] <mhall119|work> hey lightnin
[18:46] <highvoltage> for packages that contain cc-by-sa work, the full license needs to be included in the debian/copyright file, right?
[18:47] <james_w> highvoltage: yes
[18:48] <quadrispro> hello folks!
[18:48] <sebner> hio quadrispro
[18:48] <quadrispro> does REVU support debian 3.0 (quilt) format?
[18:48] <quadrispro> hi sebner
[18:49] <highvoltage> thanks james_w
[18:49] <sebner> quadrispro: nope
[18:49] <mhall119|work> james_w: how could it be included?
[18:49] <mhall119|work> a link?
[18:49] <quadrispro> :-(
[18:49] <sebner> quadrispro: well, you can upload stuff but you can review it with your browser
[18:50] <mhall119|work> a debian/CC-BY-SA file?
[18:50] <highvoltage> mhall119|work: full text inside the copyright file
[18:50] <quadrispro> sebner, thank you
[18:50] <james_w> mhall119|work: verbatim
[18:50] <sebner> quadrispro: *can't review I men
[18:50] <sebner> *mean
[18:50] <sebner> *arggh*
[18:50] <mhall119|work> is it okay to keep the GPLv2 in debian/COPYING?
[18:54] <mhall119|work> james_w: highvoltage: I'm uploading new packages now
[18:54] <lightnin> Hiya mhall119|work
[18:54] <mhall119|work> highvoltage: are you reviewing the latest?
[18:55]  * abogani is converting to 3.0 (quilt) and find it very cool!
[18:55] <mhall119|work> cause I fixed those warnings in your comment a while ago
[19:04] <oojah> bdrung_: You looked at sqlite3-pcre yesterday. Would you have another look today? I could do with a second advocate.
[19:06] <highvoltage> mhall119|work: I think -wallpapers will be ok now
[19:08] <mhall119|work> thanks highvoltage
[19:08] <mhall119|work> bbl, going to get some lunch, then to work on Qimo 2 Alpha 2 ISO
[19:11] <highvoltage> mhall119|work: ok give me a ping when you're back
[19:21] <Genscher> hey :) i am creating an ubuntu package and wondering where to install non-shared application data where I need read + write access.
[19:22] <Genscher> I just don't know the ubuntu way on this. Is it $HOME/.application ?
[19:22] <Genscher> or /var/lib/application
[19:30] <lightnin> I'm trying to add a programming environment for kids called Scratch - developed at MIT Media lab. We've recently submitted to REVU, please take a look: http://revu.ubuntuwire.com/p/scratch
[19:34] <randomaction> Genscher: maybe you're looking for this? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[19:35] <Genscher> randomaction, indeed I think i am :)
[19:36] <lightnin> Is this an appropriately formatted "original maintainer" line? XSBC-Original-Maintainer: Scratch Team <linux@scratch.mit.edu>
[19:37] <lightnin> I found it here: https://wiki.ubuntu.com/…iew#The%20control%20file
[19:38] <lightnin> But Lintian doesn't like it: W: scratch source: unknown-field-in-dsc original-maintainer
[19:46] <mhall119|work> highvoltage: did you look over the scratch package?
[19:48] <highvoltage> mhall119|work: no, I lost my browser session yesterday!
[19:51] <highvoltage> mhall119|work: I think -session will also be fine
[19:55] <mhall119|work> highvoltage: http://revu.ubuntuwire.com/p/scratch if you wouldn't mind
[20:06] <sebner> DmitryKurochkin: uploaded. I updated the Standards-Version. I'm a little bit worrying about the source files because not a single one contains a license header but that's up to the archive-admins to decide
[20:08] <DmitryKurochkin> sebner: thanks. What happens if archive-admins reject it after the freeze? Will I have a chance to fix and reupload the package?
[20:09] <sebner> DmitryKurochkin: that needs to be fixed upstream and I doubt it'll be reviewed until FF
[20:09] <sebner> DmitryKurochkin: which means *if* it gets rejected you might have to wait until lucid+1
[20:11] <Laibsch> Is do-release-upgrade not yet capable of a hardy -> lucid upgrade?
[20:11] <lifeless> no
[20:11] <lifeless> (gotta love double negatives)
[20:11] <DmitryKurochkin> sebner: what a proper license header should look like? License is mentioned in each source file currently, isn't that enough?
[20:12] <Laibsch> lifeless: when is that scheduled to change?
[20:12] <Laibsch> oops, wrong channel
[20:12] <Laibsch> I hope you don't mind, though
[20:13] <sebner> DmitryKurochkin: I'm not sure but using a full license header is common
[20:13] <jpds> Laibsch: He meant that it is.
[20:13] <sebner> DmitryKurochkin: see your copyright file (License:) but it might be enough as it's currently
[20:14] <Laibsch> jpds: I just tried "sudo do-release-upgrade -d" and it wants to update to intrepid
[20:15]  * Laibsch moves the discussion to ubuntu+1
[20:15] <Laibsch> sorry for initial off-topic
[20:15] <DmitryKurochkin> sebner: ok, I will wait and see. Where should I look at to know when package is accepted/rejected?
[20:16] <sebner> DmitryKurochkin: I think you'll get a mail
[20:17] <DmitryKurochkin> ok. sebner, hyperair, fabrice_sp thanks for review and advocating!
[20:19] <fabrice_sp> kklimonda, ping (about picard)
[20:20] <kklimonda> fabrice_sp: pong
[20:20] <lifeless> Laibsch: oh, I see what you're asking. (Try to provide that additional detail in future ;). I suspect thats worth checking with e.g. mvo
[20:20] <Laibsch> lifeless: what additional detail?
[20:21] <lifeless> Laibsch: the behaviour you observe
[20:21] <fabrice_sp> package is good, but lintian is complaining about big usr/share independent files. What do you think about splitting the package in 2?
[20:21] <fabrice_sp> kklimonda, ^
[20:22] <kklimonda> fabrice_sp: I didn't really want to divert from debian more than necessary to update it. especially this close to the FF date
[20:23] <kklimonda> fabrice_sp: I agree that it should be split in two packages
[20:24] <lifeless> Laibsch: can you pastebin the output ? mvo is here about the d-r-u -d selecting intrepid thing
[20:24] <mvo> Laibsch: and ~/.update-manager-core/meta-release-lts-development too please
[20:25] <Laibsch> lifeless: you're saying you were just suspecting it works and would have been more careful had you understood more clearly that apparently it wasn't working (the way I asked the question should have been enough of a hint).  Maybe you should give a less affirmative statement ("I would think so") when you don't really know because you have not tried.
[20:25] <Laibsch> mvo: just a minute
[20:25] <Laibsch> mvo: you want to continue discussion here or in ubuntu+1?
[20:26] <fabrice_sp> kklimonda, that's also my concern. I'll upload it as-is. Could you contact the Debian maintainer about that?
[20:26] <Laibsch> mvo: no such file
[20:26] <lifeless> Laibsch: I'm saying I didn't even really understand the question; I thought you meant hardy->intreprid etc staged
[20:27] <Laibsch> lifeless: OK
[20:27] <lifeless> Laibsch: the additional detail of what actually happened when you tried made everything much clearer
[20:27] <Laibsch> I meant the straight hardy -> lucid update
[20:27] <kklimonda> fabrice_sp: sure - I'll do that
[20:27] <lifeless> yes, we're clear on that now ;)
[20:27] <fabrice_sp> kklimonda, thanks ;-)
[20:27] <lifeless> (its why I grabbed mvo :) - not being able to test this is a bit of an issue :))
[20:27] <mvo> Laibsch: hm, no file but "do-release-upgrade -d" was run? what is the output of "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d"  ? could you pastebin that for me please?
[20:28] <Laibsch> mvo: OK, I will in a minute
[20:29] <Laibsch> the update aborted anyway because of insufficient space in /var.  I have /var on a separate 1G partition which is usually more than enough.  Is there something that can be done about this or are users like me on their own?  (I don't have a problem recovering from this, others may)
[20:29] <Laibsch> mvo: ^
[20:30] <lifeless> Laibsch: I thought it wasn't selecting lucid?
[20:31] <Laibsch> lifeless: it's selecting intrepid but aborting that update because of insufficient disk space
[20:32] <Laibsch> I have to say, I didn't mind because I don't want to take the long route ;-)  and I also want to use this single chance I have (last computer running hardy) to test for upgrade for the benefit of all.
[20:37] <mvo> Laibsch: the logs in /var/log/dist-upgrade/main.log will tell why it needs so much space. the download of the debs can be pretty heavy. if you can still reproduce theproblem that it selects intrepid instead of lucid, please put the debug output in a pastebin or mail it to me
[20:37] <Laibsch> It's currently running
[20:38] <Laibsch> So far, the system hasn't changed
[20:38] <mvo> ok
[20:43] <fabrice_sp> foolano, ping (about ebox)
[20:51] <Laibsch> mvo: Here it is: http://paste.debian.net/60079/  Not sure it contains much information, but you be the judge
[20:51] <bdrung_> fabrice_sp: can you have a look at http://revu.ubuntuwire.com/details.py?upid=7812 ? it depends on blender >= 2.49.2~dfsg aka 2.49b
[20:52] <Laibsch> mvo: let me know if you want anything from /var/log/dist-upgrade/ as well
[20:53] <fabrice_sp> bdrung_, looking now
[20:53] <fabrice_sp> 156 Mb?!
[20:53] <lifeless> Laibsch: is there a ~/.update-manager-core/meta-release-lts-development now?
[20:54] <lifeless> Laibsch: or /root/.update-manager-core/meta-release-lts-development ?
[20:54] <Laibsch> lifeless: neither
[20:55] <mvo> Laibsch: if you ran it with sudo, please check /var/lib/update-manager/
[20:55] <PATX> can i get some help with making a get-orig-source rule?
[20:55] <PATX> are there any tutorials?
[20:56] <Laibsch> PATX: I was looking for the same thing a while ago
[20:56] <PATX> Laibsch, :) did u find anything?
[20:56] <Laibsch> let me fetch what I did write after some googling
[20:56] <Laibsch> PATX: no
[20:56] <kklimonda> I need a helping hand with bug 482890 - it has to be ACK'd by someone who has supercow powers :)
[20:56] <PATX> ok thanks :)
[20:56] <Laibsch> PATX: it was piece work
[20:56] <kklimonda> it's actually a sync - stupid ubottu
[20:56] <PATX> yea...
[20:56] <Laibsch> PATX: but ultimately, it's not hard
[20:56] <Laibsch> hang on for a minute
[20:57] <PATX> i cant find any help either lol... ok ty
[20:57] <Laibsch> PATX: http://git.debian.org/?p=collab-maint/sqliteman.git;a=commitdiff;h=fabff284aa02e5a967ebdd142b18922b43f4a5fc
[20:57] <Laibsch> ask if you have any further questions
[20:57] <PATX> thanks dude :)
[20:57] <Laibsch> but I think that diff should be enough
[20:58] <Laibsch> Maybe I should write a short tutorial
[20:58] <Laibsch> I was missing it at the time
[20:59] <PATX> yea that would be a good idea
[21:03] <Laibsch> mvo: http://paste.debian.net/60084/ and http://paste.debian.net/60085/ being /var/lib/update-manager/meta-release(-development).  The latter does contain a lucid and the former has no intrepid.  So, I'm not sure what's happening there.
[21:04] <Laibsch> mvo: I'll file a wishlist bug about better handling of situations where space is tight.  Maybe there is something that can be done.  700MB-1G isn't always available in /var for your typical upgrade.
[21:08] <Laibsch> mvo: actually that could be as simple as augmenting the error message with the suggestions a-c) from https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/152580/comments/8
[21:09] <Laibsch> I'll see if I can come up with a patch
[21:09] <mvo> Laibsch: thanks
[21:11] <mvo> Laibsch: does "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d" as a normal user give any hints? I just tried that in a hardy vm and it gives me useful output before the sudo prompt about what its doing
[21:11] <mvo> Laibsch: I'm still puzzled that it wants to upgrade you to intrepid
[21:11] <Laibsch> OK
[21:11] <Laibsch> I'll let that run
[21:11] <Laibsch> normal user, no sudo?
[21:11] <Laibsch> or
[21:11] <mvo> normal user
[21:11] <Laibsch> normal user, gaining root with sudo
[21:11] <Laibsch> OK
[21:11] <Laibsch> I'll leave out sudo
[21:11] <mvo> it will automatically ask for sudo
[21:12] <Laibsch> I see
[21:12] <mvo> yeah, please leave sudo out
[21:12] <mvo> it will call it when it needs it
[21:20] <dooooomi> hi, i'm looking for a second advocate for gtklick, a metronome for JACK, written in python: http://revu.ubuntuwire.com/p/gtklick
[21:28] <Laibsch> mvo: could it be that a line like "deb-src http://ubuntu.intergenia.de/ubuntu karmic main restricted universe" in sources.list throws the update-manager off course?
[21:28] <Laibsch> but even then the next logical step would be lucid and not intrepid
[21:29] <mvo> Laibsch: I doubt that, it looks at the lsb_release output to figure out what version you are on
[21:29] <mvo> Laibsch: nothing useful in the debug output?
[21:29] <Laibsch> OK
[21:29] <Laibsch> still running
[21:29] <Laibsch> it's a slow computer running as a LAN server
[21:29] <DmitryKurochkin> is there a web page where I can see what is in Ubuntu NEW queue? similar to http://ftp-master.debian.org/new.html?
[21:29] <mvo> ok
[21:29] <Laibsch> I'll let you know when it's done and give you the pastebin
[21:32] <Laibsch> mvo: just as we spoke, the program finished: http://paste.debian.net/60091/  and the file you've been asking about is still not there
[21:33] <Laibsch> JFTR, update-manager is the version from hardy-updates
[21:33] <Ubuntuxer> Hi, is it possible to update the exaile package for Lucid yet?
[21:34] <cjwatson> sebner: I'm told that mvo is taking care of it
[21:35] <cjwatson> (dpkg)
[21:35] <lifeless> Laibsch: mvo: fwiw on my hardy server:
[21:35] <lifeless> DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d
[21:35] <lifeless> ...
[21:35] <lifeless> authenticate 'lucid.tar.gz' against 'lucid.tar.gz.gpg'
[21:35] <Laibsch> interesting
[21:35] <lifeless> so its choosing lucid.
[21:35] <Laibsch> thanks for testing
[21:37] <mvo> cjwatson, sebner if we can find someone who enjoys perl more than me I would not mind at all to not do it (dpkg)
[21:38] <mvo> lifeless, Laibsch: same for me in my vm (chosing lucid)
[21:38] <mvo> Laibsch: I need to go to bed soon, can we continue debugging tomorrow?
[21:38] <Laibsch> probably
[21:38] <Laibsch> just try to catch me anytime
[21:39] <Laibsch> I may not be in this channel and I don't run this nick 24/7, but I'm frequently in IRC
[21:39] <lifeless> perhaps file a bug
[21:39] <Laibsch> yeah
[21:39] <cjwatson> mvo: I am happy to do it at some point this week, despite holiday; it shouldn't be hard
[21:40] <cjwatson> mvo: in fact the perl bits of the existing hardy-cat patch apply cleanly, with only a one-line offset
[21:40] <mvo> cjwatson: oh? I must have done something wrong then, when I briefly looked at it, the patch gave me loads of rejects
[21:41] <Laibsch> mvo: one thing that may be different in my installation than on others; I have so far always used aptitude for upgrading to a new release.  It's the first time I use update-manager for it.
[21:41] <mvo> probably some wrong version or something
[21:41] <Laibsch> But it's quite possible that this machine never ran anything but hardy
[21:41] <Laibsch> I don't remember
[21:41] <cjwatson> mvo: lots of rejects, but not in the perl bits, afaics
[21:41] <cjwatson> the man/Makefile.{am,in} changes can be dropped
[21:41] <mvo> Laibsch: that should be ok, lsb_release -a gives you hardy there, right?
[21:42] <Laibsch> yepp, it does
[21:42] <cjwatson> mvo: although I think the Dpkg::Vendor changes may need some tweaks anyway
[21:43] <Laibsch> http://paste.debian.net/60096/ is the full output
[21:46] <mvo> Laibsch: hm, shold be fine. lets continue tomorrow
[21:46]  * mvo waves
[21:46] <Laibsch> sure
[21:46] <Laibsch> thanks
[21:46] <Laibsch> good night
[21:46] <mvo> cjwatson: thanks, I can check it out tomororw, also FF is pretty pressing currently :/
[22:11] <PATX> can someone tell me what the first problem on this page means? http://revu.ubuntuwire.com/revu1-incoming/fastpatx-1002160248/lintian
[22:16] <PATX> i am not getting this i thought i defined this in debian/control...
[22:16] <PATX> Build-Depends: cdbs (>=0.4.49), debhelper (>= 5), python-central (>=0.5.6), python
[22:16] <PATX> debhelper (>= 5)
[22:17] <PATX> ^^^
[22:17] <geser> what value is in debian/compat?
[22:17] <PATX> checks
[22:17] <POX> 7
[22:17]  * POX knows without looking
[22:17] <PATX> 2
[22:18] <PATX> oh...
[22:18] <POX> that's debian/pycompat
[22:18] <PATX> oh
[22:18]  * POX knows without looking
[22:18] <POX> ;)
[22:18] <PATX> yea
[22:18] <PATX> lol
[22:18] <PATX> i dont have a compat...
[22:18] <PATX> should i make one and put 7 in there?
[22:18] <PATX> would that solve problem?
[22:19] <PATX> oh wait nvm
[22:19] <PATX> i have compat
[22:20] <PATX> geser, so the value is 7 now...?
[22:22] <Laibsch> some kind MOTU soul around to review (and hopefully endorse) http://revu.ubuntuwire.com/p/ffgtk ?
[22:22]  * Laibsch is hopeful
[22:23] <Laibsch> porthose?
[22:23] <geser> PATX: depends on what debhelper level you want to use
[22:23] <PATX> geser, 5...
[22:23] <PATX> debhelper (>= 5)
[22:24] <PATX> oh should there be a space there... does it matter?
[22:24] <geser> than put 5 in debian/compat
[22:24] <PATX> ah ok
[22:24] <PATX> debhelper (>= 7)
[22:24] <PATX> or should i use that?
[22:25] <sebner> PATX: you can use it when you delete cdbs and update rules accordingly ;)
[22:25] <PATX> ok
[22:25] <PATX> and then the error:
[22:25] <PATX> W: fastpatx source: native-package-with-dash-version
[22:26] <PATX> how could i fix that?
[22:26] <Laibsch> PATX: google for the error string
[22:26] <PATX> ok
[22:26] <Laibsch> you will usually find plenty of info for lintian errors
[22:26] <RAOF> Also, lintian -i (or -I, I forget precisely which) will give you a big block of text about each error, which usually includes how to fix it.
[22:27] <porthose> Laibsch, I'm busy working on something right now, maybe later if I have time :)
[22:28] <Laibsch> porthose: I'd really appreciate it.  We already missed karmic, I don't want to miss Lucid again.
[22:29] <RAOF> Laibsch: I can give a brief once-over.  Looking at the diff of ffgtk, you've modified a bunch of files from the .orig.tar.gz directly; that would usually be done in a patch with a patch system, although if you're maintaining it in git it can be a bit different.
[22:30] <RAOF> Laibsch: Do you really need the explicit Depends on libgtk2.0-0, libxml, etc?  Why aren't they picked up in ${shlibs:Depends}?
[22:32] <RAOF> Laibsch: Is the packaging already in collab-maint git?  What's the status with its ITP in Debian?
[22:32] <Laibsch> RAOF: package maintenance will be in git (as for all my packages).  You're right, the patches should eventually be in a patch system, dpkg v3 is looming.  The things you raise are likely legacy from the person who did the first draft of the packaging.
[22:33] <Laibsch> I'm sure I already pushed this to git.debian.org
[22:33] <Laibsch> There is no ITP, yet, I'm shooting for inclusion in lucid now and that keeps me busy enough
[22:34] <Laibsch> eventually, I intend to maintain this (as my other packages) in Debian since that is best for Ubuntu, Debian and just everybody.
[22:34] <RAOF> Yup.
[22:34] <Laibsch> but even under best circumstance, this won't hit Debian before the summer
[22:34] <lifeless> its summer now
[22:34] <Laibsch> depends on where you are
[22:34] <Laibsch> ;-)
[22:34] <RAOF> Before *next* summer :P
[22:35] <lifeless> I suggest never ever ever using seasonal terms in global endeavours
[22:35] <Laibsch> well, I'd say, even for you, summer is coming to an end
[22:35]  * Laibsch is feelling springy
[22:36] <Laibsch> lifeless seems to be a little nit-picker, hm?
[22:36]  * ScottK looks outside at three feet of snow on the ground and is not.
[22:36] <ScottK> (feeling springy)
[22:36] <sebner> ScottK: great for staying at $HOME and updating stuff like crazy before FF :)
[22:37] <ScottK> sebner: Fortunately none of it came in the last week, so I'm not trapped.
[22:37] <ScottK> School finally resumes tomorrow.
[22:37] <lifeless> Laibsch: sometimes perhaps. However it really does introduce confusion to say 'summer' or 'winter' in IRC/email etc.
[22:37] <lifeless> it requires more context for recipients at a minimum
[22:37] <RAOF> Laibsch: While my pbuilder is hard-a-work grabbing build-depends, I'd also suggest that you'd want to make an explicit call to autoreconf rather than relying on automake to see the right timestamps.
[22:38] <Laibsch> RAOF: I will check that the dependencies are really necessary. git.debian.org will be updated with git-import-dsc once it has hit either Ubuntu (hoping for the best) or Debian, whichever comes first.  Can you give an endorsement once the dependencies have been double-checked?
[22:38] <lifeless> I don't think its nitpicky to point this out and suggest that its better not to do it.
[22:38] <sebner> ScottK: Everytime I read that or see that in TV (your phrase about school) it makes me kinda feel that parents are happy to get their children out of the house ^^
[22:39] <ScottK> Kinda does not even begin to cover it.
[22:39] <sebner> heh
[22:39] <Laibsch> RAOF: you kind of lost me with that autoreconf.  I'm not a buildmaster, some dummy tutorial somewhere?
[22:40] <Laibsch> RAOF: I promise to fix the issues you raised.  I hope they are not serious enough to block inclusion from lucid and would hope for an endorsement.
[22:40] <RAOF> Laibsch: Ah, well.  You modify configure.ac & Makefile.am (somewhat unnecessarily, but it'll be nice when you submit that patch upstream); this won't actually have any effect unless configure & the various Makefile.in files are regenerated.
[22:40] <Laibsch> that's been done by the guy who actually understands that stuff ;-)
[22:42] <RAOF> Ah.  Your package doesn't build.  Or, rather, it doesn't error but no build system is actually called, so you end up with an empty package.
[22:42] <oojah> Would a motu consider looking at http://revu.ubuntuwire.com/p/sqlite3-pcre ? I'm in need of a second advocate.
[22:43] <RAOF> Oh, of course.  This would be because you don't *have* a configure script, or a Makefile.
[22:43] <RAOF> You probably want an override_dh_auto_configure: target, calling ./autogen.sh
[22:43] <Laibsch> ?
[22:43] <Laibsch> it built fine for me
[22:43] <Laibsch> Are you testing the latest version?
[22:44] <RAOF> Did you build it in a pbuilder, from the source package you uploaded to revu?
[22:44] <Laibsch> http://revu.ubuntuwire.com/details.py?upid=7845
[22:44] <Laibsch> pbuilder
[22:44] <Laibsch> or in this case pdebuild
[22:44] <Laibsch> yes
[22:45] <RAOF> Hm.  Upstream needs to learn to run “make distcheck”.
[22:45] <Laibsch> let me retry, check the depends and ping you after that
[22:45] <Laibsch> thank you for your input
[22:45] <RAOF> It's not the depends that are the problem.
[22:45] <Laibsch> I know
[22:45] <Laibsch> But you raised it and I want to check
[22:45] <Laibsch> "in einem Aufwasch"
[22:45] <Laibsch> "while I'm at it"
[22:46] <RAOF> Also - where are you getting ffgtk 0.7.91?  The tarballs I can find on your upstream link are for 0.7.3
[22:46] <Laibsch> there's a watch file?
[22:46] <Laibsch> there's a watch file ;-)
[22:46] <Laibsch> Let me take a look
[22:47] <Laibsch> http://www.tabos.org/ffgtk/download/
[22:47] <RAOF> True.  It's just not linked from http://www.tabos.org/ffgtk/download.php
[22:50] <Laibsch> no
[22:50] <Laibsch> I'm working closely with upstream
[22:50] <Laibsch> and that tarball was done on my request ;-)
[22:50] <RAOF> Aaah.  Tell them to run “make distcheck” :)
[22:50] <Laibsch> it's also tar.gz and not .bz2
[22:50] <Laibsch> OK
[22:50] <Laibsch> I will
[22:51] <RAOF> Yeah, I noticed that.  With source v3 .bz2 would be fine, but .tar.gz will be more easily backportable.
[22:51] <Laibsch> As you can see on revu, I was aiming for inclusion in karmic
[22:51] <Laibsch> and AFAIK, dpkg v3 wasn't yet widely used back then
[22:52] <Laibsch> I've only become aware of it very recently
[22:52] <Laibsch> (and spent some time getting my hardy build host to understand dpkg v3)
[22:52] <Laibsch> notice about "make distcheck" sent
[22:52] <bcurtiswx> http://paste.ubuntu.com/377966/  anyone know what package i may be missing?
[22:54] <Laibsch> bcurtiswx: cdbs
[22:55] <Laibsch> look at lines 12-14
[22:55] <Laibsch> install apt-file and then you can search for the package that has the file in question
[22:55] <Laibsch> in this case, that's cdbs
[22:55] <bcurtiswx> Laibsch: ty
[22:56] <Laibsch> Interesting to see this question from somebody with @ubuntu.com ;-)
[22:56] <bcurtiswx> Laibsch: i got my membership mainly from my bug triage abilites
[22:56] <Laibsch> nice
[22:57] <bcurtiswx> Laibsch: im trying to see if I can backport empathy for karmic
[23:11] <bcurtiswx> not to be annoying or seem noob-ish.. but anyone know what I do to fix this problem http://paste.ubuntu.com/377979/
[23:16] <Laibsch> RAOF: you're right, I get an empty package, now too
[23:17] <Laibsch> not sure, why it was working nicely before.
[23:17] <RAOF> You had probably run ./autogen.sh in there at one point.
[23:19] <geser> bcurtiswx: either check if your empathy backport work with the versions of the mentioned packages from karmic or backport them too
[23:21] <bcurtiswx> geser, ok
[23:21] <bcurtiswx> geser: trying to find which packages these are
[23:22] <geser> bcurtiswx: line 180-183 of your paste
[23:25] <geser> the source packages are: telepathy-glib, libindicate and nautilus-sendto
[23:28] <bcurtiswx> geser: ty
[23:30] <plars> anyone have time to adv/upload a package (assuming you approve)? I already have one adv
[23:30] <plars> http://revu.ubuntuwire.com/p/moserial
[23:31] <Laibsch> RAOF: can I get an endorsement from you even when not addressing all points (collab-maint, patch-system, ITP)?  The others I consider RC and will of course fix.  I'm quite embarassed about that empty package.
[23:58] <bcurtiswx> geser: as I keep going back and finding packages to backport to get empathy to build ok.. how do I install them to pbuilder if they build OK so the next package can use it to build ?