[00:46] <bluefoxicy> how does totem play midis?
[00:46] <bluefoxicy> O_O
[00:47] <directhex> bluefoxicy, via gstreamer, most likely
[00:47] <bluefoxicy> directhex:  yeah but I mean, midi output?
[00:47] <bluefoxicy> midi doesn't contain sound.
[00:48] <directhex> libwildmidi
[00:48] <directhex> which recommends freepats which has midi voices in it
[00:49] <bluefoxicy> heh
[00:49] <bluefoxicy> so timidity-ish.
[00:49] <directhex> yes
[00:50] <bluefoxicy> k. Same patch set, hmm.
[00:50] <bluefoxicy> I'm assuming nobody gives a crap (I don't) to cut up some high quality samples into patches
[00:51] <bluefoxicy> (yes, there's a pile of public domain very-high-quality instrument samples out there)
[00:51] <directhex> it *must* be DFSG-free
[00:51] <directhex> if so, then freepats accepts patches
[00:53] <bluefoxicy> actually.
[00:53] <bluefoxicy> http://freepats.zenvoid.org/samples/imis/
[00:53] <bluefoxicy> AFAIK nobody's cut these up yet.
[00:54] <bluefoxicy> http://freepats.zenvoid.org/samples/imis/LICENSE
[00:55] <bluefoxicy> there's an http://freepats.zenvoid.org/sf2/acoustic_piano_imis_1.sf2 but that's all I see.
[00:56] <bluefoxicy> it also comes under a license I don't believe has been validated by OSI yet
[00:57] <bluefoxicy> 'You can redistribute it and/or modify it under the terms of the "Do What The Fuck You Want To Public License", Version 2. The license text is reproduced below.'
[00:57] <bluefoxicy> I'm not sure the DWTFYWTPL is officially OSI validated O_o
[00:57] <dhillon-v10> bluefoxicy, lol
[00:58] <bluefoxicy> http://freepats.zenvoid.org/sf2/acoustic_piano_imis_1.txt however here's the full text.
[00:58] <directhex> bluefoxicy, actually, WTFPL 2.0 is explicitly DFSG-free
[00:58] <directhex> and was written by a former debian project leader
[00:58] <bluefoxicy> ... XD
[00:59] <directhex> and the FSF approve it as Free
[00:59] <bluefoxicy> haha
=== bluefox_ is now known as bluefoxicy
=== Quintasan1 is now known as Quintasan
=== Lutin is now known as Guest62637
[03:18] <persia> directhex: bluefoxicy: Try fluid-soundfont-gm if you want decent MIDI samples.  If you find another DFSG-free soundfont, that'd be great, but I'd encourage you to follow the directory convention for fluid-soundfont
[03:20] <persia> maxb: The issue with ${potential-version}~git${date}+${sha} is that there is no guarantee that ${SHA} will increase, which can be annoying when one makes a mistake on upload and needs to wait a day to reupload (and then ends up with a potentially different snapshot, potentially with new bugs)
[03:21] <maxb> I was hoping that no one would ever need to import a new upstream snapshot twice in one day :-)
[03:23] <persia> In an ideal world, every upload is perfect, but we are mostly human, and therefore it remains best to set guidance to allow for mistakes.
=== Lutin is now known as Guest61444
=== Whoopie_ is now known as Whoopie
[04:00] <zooko> Greetings, people of #ubuntu-motu!  I have read the Lucid release plans and https://wiki.ubuntu.com/LTS and I'm wondering what target deadline I should set for the Tahoe-LAFS project to upload a new release of Tahoe-LAFS for inclusion in Lucid.
=== Lutin is now known as Guest50538
=== ripps is now known as ripps|sleep
[05:31] <persia> zooko: For best resuts, you want to make sure it gets uploaded (to Ubuntu or Debian) by 28th January, and I'd recommend giving at least a few days for upload delays, so trying to do something by the 20th or so.  More specifics at https://wiki.ubuntu.com/LucidReleaseSchedule
[05:32] <persia> Note that it is possible to upload stuff past PartnerUploadDeadline (apparently unless one is an "OEM Partner"), but it's decidedly unlikely that it will get into the next release without substantial help at that point (and you'd already be in touch with a developer who was driving it and specifically advised you that a couple more days were safe).
[05:35] <persia> porthose: Don't forget to send the "quick heads-up" to motu-council@l.u.c about your application (this seems to be the most frequently missed step)
[05:37] <porthose> persia, will do :)
[05:40] <ScottK> zooko: How's the feedback on Tahoe-LAFS on Karmic?
[05:41] <zooko> persia: thanks!
[05:42] <zooko> ScottK: fine!  We have a few users who use it in Karmic, and people recommend to each other that they should use that version if they have Karmic.
[05:42] <zooko> For example, here is the ad hoc Tahoe-LAFS grid that has been set up at the Chaos Communications Congress: http://events.ccc.de/congress/2009/wiki/Tahoe-LAFS_Workshop
[05:43] <zooko> Oh wait, I mean here are the installation instructions that these CCC folks give: http://events.ccc.de/congress/2009/wiki/Tahoe-LAFS_Grid
=== asac_ is now known as asac
[07:57] <rawang> hello everyone, anyone have time to look at http://launchpadlibrarian.net/37262448/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz ? I can't figure out what's the problem, thanks a lot!
[08:25] <wrapster> how do i find out the version of the pkg installed on my machine?
[08:27] <_ruben> dpkg -l packagename will show you
[08:34] <rawang> _ruben, hey
[08:38] <wrapster> _ruben: and can i see the full contents of this pkg anyway?
[08:39] <wrapster> _ruben: referring to somethign like dpkg -c pkgname
[08:39] <wrapster> but thats on a newly created .deb how about an isntalled one?
[08:39] <wrapster> installed
[08:39] <_ruben> wrapster: dpkg -L pkgname
[08:40] <wrapster> thanks
[09:09] <rawang> hi anyone has time to look at http://launchpadlibrarian.net/37262448/buildlog_ubuntu-karmic-i386.mono-uia-atkbridge_1.0-2~pre1_FAILEDTOBUILD.txt.gz ? I can't figure out what's the problem, thanks a lot!
[09:28] <randomaction> there were errors during configuration of mono-gac, which is a build dependency
[09:30] <randomaction> but I have no idea why is that
[09:35] <rawang> randomaction, ok, i'm trying to build my pkg on my PPA, seem like my libmono-uia3.0-cil wants to install some files to system the have been denied.
=== Guest50538 is now known as Lutin
[09:43] <rawang> lidaobing, hey
[09:44] <lidaobing> rawang, mail me if have any issue
[09:44] <rawang> lidaobing, ok, thanks :)
[09:47] <rawang> lidaobing, alright, sent.
[09:51] <doctormo_> Does anyone understand why my iscan package would fail to upload?
[09:51] <doctormo_> https://launchpad.net/~doctormo/+archive/doctormo-epson-scanners/+build/1418715
[09:51] <doctormo_> I'm a bit lots trying to pick through the wreckage.
[09:52] <xnox> doctormo_: What's the reject email?
[09:52] <xnox> Ohhh
[09:52] <xnox> that looks weird
[09:52] <wgrant> doctormo_: More of a #launchpad question, but you deleted/superseded the source before the build finished.
[09:55] <wgrant> Oh. No.
[09:55] <wgrant> It's a bug in your package.
[09:55] <wgrant> 2009-12-28 23:07:39 WARNING 	Unable to find source package iscan/2.23.0-4doctormo4.ltdl7 in karmic
[09:55] <wgrant> ".ltdl7"!?
[09:55] <wgrant> That's not in the source version.
[09:58] <wgrant> doctormo_: Also, why is it native, and why on earth are there binaries in there?
[09:59] <doctormo_> wgrant: Your guess is as good as mine, it's LGPL, source, just a matter of pulling it apart, i think I might ditch the debian dir that came with it and use my previous one.
[10:00] <wgrant> doctormo_: The nativity in this case is just because you did not place a correctly named orig.tar.gz in the parent directory.
[10:00] <wgrant> doctormo_: There are binaries matching *.so in the source package. That seems wrong.
[10:00] <doctormo_> wgrant: When I did place one, it couldn't find it.
[10:00] <wgrant> doctormo_: You didn't name it properly, I suspect.
[10:01] <doctormo_> wgrant: No what I mean is, when it had a orig file it was rejected by the ppa upload system, instead of the build system like this example.
[10:01] <wgrant> doctormo_: Rejected how? Checksum mismatch?
[10:06] <doctormo_> wgrant: Rejected: Unable to find iscan_2.23.0.orig.tar.gz in upload or distribution.
[10:06] <wgrant> doctormo_: You didn't debuild with -sa
[10:06] <doctormo_> no
[10:06] <wgrant> That is the problem.
[10:08] <doctormo_> wgrant: debuild -sa fails, says that's not valid args.
[10:08] <wgrant> doctormo_: debuild -S -sa
[10:09] <doctormo_> No wonder this packagaing lark has special people running it, I'd never fit in as a motu ;-)
[10:13] <doctormo_> good, that looks more healthy.
[10:13] <doctormo_> Thanks for your help wgrantand xnox
=== doctormo_ is now known as doctormo
[10:13] <wgrant> doctormo: But there is still the matter of your strange mangling of the binary versions.
[10:13] <wgrant> I haven't looked at that code; it sounds scary.
[10:14] <doctormo> It does, if I had noticed myself I would be scared.
[10:26] <doctormo> wgrant: Same failure in build, I assume it's the binary problem.
[10:28] <wgrant> doctormo: The upload log will tell you for sure.
[10:44] <doctormo> I think I'll give up on the package for now, it's too much trouble for what it's worth.
[10:45] <doctormo> Thanks agaain for your help wgrant
=== Quintasan1 is now known as Quintasan
[11:19] <damo22> how do i build an ubuntu source package with a .dsc file and orig.tar.gz and diff.gz
[11:19] <Laney> debuild -S
[11:21] <damo22> Laney: thanks, do i need to untar and patch first? then copy the dsc into the tree and run it?
[11:21] <Laney> wait, what do you want to do?
[11:21] <Laney> build a deb?
[11:22] <damo22> i want to compile a deb for karmic using a source package
[11:22] <Laney> oh, alright
[11:22] <damo22> actually its a bunch of debs
[11:22] <Laney> the quickest way is to dpkg-source -x foo.dsc, cd into the directory and run debuild
[11:22] <Laney> you'll need the build deps first though
[11:23] <damo22> cool
[11:24] <slytherin> damo22: Ideally you should use pbuilder or sbuild.
[11:24] <damo22> do i run debuild -S or without the s flag
[11:27] <Laney> you don't use -S to build debs
[11:27] <Laney> that is to build the source package
[11:27] <damo22> ahh ok
[11:28] <damo22> it overwrote my source package
[11:28] <damo22> lol
[11:28] <damo22> lucky i have it backed up
[11:28] <damo22> im building an old version of the ATI fglrx driver which doesnt have a package for karmic
[11:31] <rawang> how to trigger ppa rebuild my package?
[11:32] <rawang> Laney?  :)
[11:33] <Laney> there's a button somewhere in the ppa
[11:33] <Laney> probably where it tells you the build failed
[11:34] <rawang> k
[11:42] <damo22> some idiot wrote a deb using sh instead of bash and tried to call pushd/popd from sh
[11:43] <damo22> part of the ATI driver
[11:43] <damo22> :S
[11:44] <damo22> i dont know where to find the script to change it
=== mac_v_ is now known as \vish
=== mac_v is now known as \vish
=== mac_v is now known as \vish
=== \vish is now known as mac_v
=== mac_v is now known as \vish
=== ripps|sleep is now known as ripps
=== thekorn_ is now known as thekorn
=== micahg1 is now known as miCHg
=== miCHg is now known as micahg
[16:11] <kamalmostafa> How can I fetch the "glib2.0" source package with bzr/launchpad?...   bzr branch lp:ubuntu/glib2.0  ... gets an error "glib2.0 in ubuntu has no default branch."
[16:45] <randomaction> according to https://code.launchpad.net/ubuntu/+source/glib2.0, "There are no branches for the “glib2.0” package in Ubuntu in Launchpad."
[16:51] <kamalmostafa> randomaction: so what source package builds the "libglib2.0-0" binary package?  I got "glib2.0" from...  apt-cache showsrc libglib2.0-0
[16:51] <randomaction> that's right, glib2. There's just some problem with its branches.
[16:52] <randomaction> (I mean, glib2.0)
[16:52] <kamalmostafa> ah ha...  Also of note:   bzr branch lp:glib   does fetch a "glib" source package, but it is 9 months stale.
[16:54] <geser> glib2.0 has import failures (see http://package-import.ubuntu.com/failures/.bzr/failures/glib2.0)
[16:57] <randomaction> Don't know whether it's of any help for you, but there's an upstream git repo.
[16:57] <kamalmostafa> randomaction: no, I actually do need the ubuntu source package.
[16:58] <randomaction> you cat "apt-get source" it
[16:58] <geser> you need to use the fallback: apt-get source glib2.0
[17:00] <sebner> geser: when doing a merge, after launching bzr commit I don't need to generate a .changes file etc to upload it with dput? bzr takes care of everything?
[17:00] <randomaction> or you can ask at ubuntu-distributed-devel@l.u.c if you really need the branch
[17:00] <geser> sebner: you still need to do an upload, we don't have BuildFromBranch yet
[17:01] <sebner> geser: until then it smells pretty much like double double work to me :\
[17:02] <dhillon-v10> hi all, I remember reading on the wiki that its possible to perform merges using bzr how is that done
[17:03] <geser> only the "bzr push" and "dput" is double-work, you can use the branch to build the source package
[17:03] <randomaction> dhillon-v10: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[17:05] <ikt> heya, anyone around?
[17:05] <dhillon-v10> randomaction, thanks a lot
[17:05] <geser> ikt: perhaps, perhaps not
[17:06] <matti> dhillon-v10: Hello Sir!
[17:06] <dhillon-v10> matti, hi there :D
[17:06] <matti> ;]
[17:06] <ikt> geser: I'll take a chance on perhaps :P
[17:06] <ikt> https://bugs.launchpad.net/debian/+source/electricsheep/+bug/372040 <- simple program, just want to confirm it'll have the right package in 10.04
[17:06] <ubottu> Ubuntu bug 372040 in electricsheep "Request Package of electricsheep 2.7 due to 2.6 EOL" [Medium,Confirmed]
[17:08] <randomaction> ikt: apparently EzraR is working on it (bug 484013)
[17:08] <ubottu> Launchpad bug 484013 in electricsheep "Please merge electricsheep 2.7~b12+svn20090708 (universe) from Debian testing (main)" [Undecided,In progress] https://launchpad.net/bugs/484013
[17:11] <ikt> cheers randomaction
[17:13] <dhillon-v10> randomaction, i am trying to merge Bug 499335 goldendict, how do I find the URI of this package
[17:13] <ubottu> Launchpad bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New] https://launchpad.net/bugs/499335
[17:14] <randomaction> I think you branch lp:ubuntu/goldendict and merge lp:debian/squeeze/goldendict into it
[17:15] <ikt> https://merges.ubuntu.com/e/electricsheep/REPORT <- :s
[17:16] <dhillon-v10> randomaction, how do we identify that, meaning is there a proper way to a new user to know which one to branch and which one to merge into
[17:16] <dhillon-v10> randomaction, I see that it goes by package name
[17:16] <randomaction> why, you want to merge from Debian testing (squeeze) into Ubuntu, hence these branches
[17:17] <dhillon-v10> randomaction, thanks again
=== kmdm is now known as Guest40572
[17:53] <jjlee> dpkg-genchanges: error: cannot read files list file: No such file or directory
[17:53] <jjlee> what's likely to be at fault there?
[18:09] <dhillon-v10> nixternal, hi :D I was working on this merge for bug #499335 and here's the diff: http://paste.ubuntu.com/348672/ I used bzr to do this and can you tell me if it looks right
[18:09] <ubottu> Launchpad bug 499335 in goldendict "Please sync goldendict (0.9.1~git20091117-1) from Debian Testing" [Wishlist,New] https://launchpad.net/bugs/499335
[18:35] <jjlee> I was missing this line from debian/rules: include /usr/share/cdbs/1/rules/debhelper.mk
=== zooko` is now known as zooko
[20:18] <alex_mayorga> Hi
[20:19] <alex_mayorga> !info virtualbox-ose
[20:19] <ubottu> virtualbox-ose (source: virtualbox-ose): x86 virtualization solution - base binaries. In component universe, is optional. Version 3.0.8-dfsg-1ubuntu1 (karmic), package size 6182 kB, installed size 24292 kB (Only available for amd64 i386 lpia all)
[20:20] <alex_mayorga> what does it mean that it's in "Outstanding merges"?
[20:27] <randomaction> alex_mayorga: Debian has a newer version
[20:28] <randomaction> which may or may not be imported directly because Ubuntu package is modified
[20:36] <zooko> What's thebest URL for the pretty graphic of the Lucid schedule as a garden with flowers and a snail?
[21:02] <zooko> persia: I'm quoting your advice on tahoe-lafs to the tahoe-dev list.  Want to be named "IRC user 'persia'"?
[21:02] <zooko> Or "Emmet Hikory", or something else?
[21:15] <dhillon-v10> hi all, I am trying to build this package in pbuilder, and then I get this "configure: error: The intltool scripts were not found. Please install intltool. make: *** [config.status] Error 1" I did put intltool in the control file but it still doesn't build, any help here
[21:20] <geser> dhillon-v10: could you pastebin your build log?
[21:20] <dhillon-v10> geser, just a sec.
[21:22] <dhillon-v10> geser, this is all I can get out of the cli: http://paste.ubuntu.com/348762/
[21:24] <geser> you added "intltool" to Build-Depends and it didn't help?
[21:25] <dhillon-v10> geser, yah do you want to see the control file
[21:25] <geser> I trust you, but a look doesn't hurt
[21:26] <dhillon-v10> geser, here: http://paste.ubuntu.com/348764/
[21:26] <dhillon-v10> geser, thanks :D
[21:26] <geser> dhillon-v10: why "intltool | libz-dev"?
[21:27] <dhillon-v10> geser, I don't know, I am actually updating a package, so I used the control file from the last package that was debianized, that's how I saw it in the tutorial on wiki
[21:27] <geser> as you have also zlib1g-dev in your Build-Depends which also provides "libz-dev" this dependency is also fulfilled and intltool not installed
[21:28] <dhillon-v10> geser, so its the placement of the dependencies, if I change it, it will work
[21:28] <geser> try using only "intltool" -> "..., zlib1g-dev, intltool, autotools-dev, ..."
[21:29] <geser> it's not the placement but the OR combination
[21:29] <dhillon-v10> geser, OH i just saw that bar, it means this package OR the other one
[21:29] <geser> yes
[21:30] <dhillon-v10> geser, thanks a lot, you are awesome. So what happens after i update this package successfully, does it go to REVU
[21:32] <geser> it's an update of an existing package right?
[21:32] <dhillon-v10> geser, yes
[21:32] <geser> then attach a debdiff to the bug for sponsoring (file the bug if needed)
[21:33] <dhillon-v10> geser, the bug was already filed, but what happens to the new .orig file that I got from upstream
[21:34] <geser> it's a new upstream version?
[21:35] <dhillon-v10> geser, yah the upstream released a new version, someone filed a bug "needs-update" and I packaged it with this new build dependency here: https://bugs.edge.launchpad.net/ubuntu/+source/pcsx-df/+bug/403635
[21:35] <ubottu> Ubuntu bug 403635 in pcsx-df "Please upgrade pcsx-df to 1.10 version" [Wishlist,Confirmed]
[21:35] <geser> I'd say provide the link so the sponsor can get it himself (a verify it's integrity)
[21:36] <dhillon-v10> geser, alright thanks again, I see the package needs some more build depends so I'll just add them :D
[21:39] <randomaction> dhillon-v10: in this case, you should post a .diff.gz, not a debdiff
[21:39] <geser> dhillon-v10: I just saw that the package got removed from Debian (and also already from lucid). Any good reason to have it back?
[21:40] <geser> dhillon-v10: and got Debian bug #514446 resolved? as this was also the reason for the removal
[21:40] <ubottu> Debian bug 514446 in pcsx-df "possible upstream license violation" [Serious,Fixed] http://bugs.debian.org/514446
[21:40] <dhillon-v10> geser, nah, its an emulator, and a lot of people use it, so should I mark the bug invalid and not worry about the package ?
[21:43] <geser> is the issue resolved (I didn't look yet). if it's not then there is no reason to package the new upstream version as it probably won't get accepted into the archive
[21:44] <geser> and as the package has no Debian maintainer anymore, is the package important enough to get packaged by MOTU and be kept maintained (be whom)?
[21:45] <dhillon-v10> geser, alright then, I'll leave the package alone, in Debian they just closed the bug and remove the package from unstable
[21:48] <geser> you can set it to "Won't fix" (with a comment describing the situation)
[21:48] <dhillon-v10> geser, alright did that
[22:01] <dhillon-v10> geser, hey if debian doesn't have a newer package that was released by the upstream, should I bother packaging the newer version
[22:04] <geser> you could try to work with the Debian maintainer on the new package so both Debian and Ubuntu benefit
[22:08] <dabaR> How are you guys finding tasks for yourself to do?
[22:09] <geser> it depends slightly on your interests
[22:10] <dabaR> geser: what do you do in particular?
[22:10] <geser> e.g. the gnome desktop team has a page listing the upstream package version, the debian package version and the ubuntu package version so they know what packages need updating
[22:10] <geser> they also look at bugs, etc.
[22:10] <dabaR> geser: I don't have a specific interest really yet.
[22:11] <dabaR> geser: I would like to shadow someone working on their tasks, and learn from there.
[22:11] <geser> I'm mostly fighting FTBFS, NBS, unmetdeps and use the lists displaying the data or the output of "apt-cache -i unmet"
[22:11] <ScottK> dabaR: http://qa.ubuntuwire.com/ftbfs/lucid.html is a good place to look for things to do.
[22:11] <dabaR> geser: are you working on one of those right now?
[22:12] <dhillon-v10> dabaR, fixing FTBFS is a *huge* pain sometimes, and it needs a lot of love so you could try there
[22:13] <geser> not right now, but I've a small list of packages where I already looked at the build log and have an idea what's need to be done
[22:13] <dabaR> ScottK: Thanks. What do you think, is it realistic to hope that someone would talk along while doing a task? I just think it is too hard for me to pick anything in that list - it is too long.
[22:14] <ScottK> dabaR: Depends on the person.
[22:14] <ScottK> I think it's better to just pick something, dive in, and ask questions.
[22:14] <dabaR> ScottK: what would you do if you landed on that page?
[22:14] <dabaR> ScottK: click on some of the reds in the column for the arch I use?
[22:15] <ScottK> dabaR: Yes, particularly if there is a package there you use or are familiar with.
[22:15] <dabaR> And then read that, and start to understand what those contain, etc. OK, that sounds doable.
[22:16] <EagleScreen> if I know how to compile and install a pieze of software, is it suposed that I can debianize it? or do I need anymore?
[22:17] <dabaR> So, does this error: 'sh: gcc: not found'
[22:17] <dabaR> mean that gcc is not a command recognized on the system in question?
[22:17] <dhillon-v10> ScottK, do you have like 2 mins. I can't find much about v3 package format (the problem you said MoM had) I did google it though
[22:17] <geser> dabaR: you can ignore that line, it's in every build log (even the successfull ones)
[22:18] <geser> dabaR: do you know the basics of packaging python apps?
[22:18] <dabaR> geser: For linux?
[22:18] <dabaR> geser: Either way, no.
[22:18] <geser> dabaR: yes, more specifically as debs
[22:19] <geser> ok, so I try to find an other FTBFS for you to try
[22:19] <geser> C/C++ knowledge?
[22:21] <dabaR> I would not mind learning the basics of packaging python apps.
[22:21] <dabaR> Mostly have interest with python, ruby, php, bash
[22:22] <dabaR> s/with/in
[22:23] <geser> dabaR: then try to look at  http://launchpadlibrarian.net/37025668/buildlog_ubuntu-lucid-i386.atheist_0.20091130-1_FAILEDTOBUILD.txt.gz
[22:23] <dabaR> OK, slightly less huge file. Is there sections of it that I can ignore?
[22:24] <dabaR> I expect these files have a structure...
[22:24] <geser> they have (more or less)
[22:24] <dabaR> Like, <stuff></stuff><some-other-stuff></some-other-stuff>
[22:24] <geser> the first part is the update of the build environment (you can skip over it in most cases)
[22:25] <geser> then the build-dependencies are installed (look for "Build started at 20091221-1944
[22:25] <geser> ")
[22:26] <geser> after that the real interesting part comes: the output of dpkg-buildpackage
[22:26] <geser> and after that the clean up
[22:26] <dabaR> are there any scripts set up to parse these files that any of you commonly use?
[22:26] <geser> so I always jump first to the end (before the clean up part) to see why it failed
[22:27] <geser> I don't know of any
[22:27] <dabaR> That is probably the first thing I will write if there are not any, unless you guys know something I don't
[22:28] <geser> there are many different reasons why a build might fail
[22:29] <dabaR> So, what denotes the start of the dpkg-buildpackage in that file?
[22:30] <geser> look for the line "------------------------------------------------------------------------------" after the installation of the build depends
[22:30] <dabaR> ya, I thought it was that
[22:30] <dabaR> after 'Toolchain package versions:'?
[22:30] <geser> line 611
[22:30] <geser> exactly
[22:31] <dabaR> until ********?
[22:31] <geser> and the reason for the FTBFS can be mostly found a few lines before "dpkg-buildpackage: error: debian/rules build gave error exit status 2"
[22:31] <geser> yes
[22:31] <dabaR> actually, until the next ------
[22:32] <dabaR> Is the error that python2.5 is not installed??
[22:33] <geser> yes
[22:33] <dabaR> OK, slightly odd error....
[22:33] <geser> the package build-depends on python
[22:33] <geser> so python is installed but the default python version in lucid is python 2.6
[22:33] <dabaR> and in Lucid python is 2.6, I get it.
[22:33] <dabaR> So you change the build script to use python instead?
[22:34] <dabaR> or 2.6?
[22:34] <dabaR> And test
[22:34] <geser> yes
[22:34] <dabaR> Or make it build-depend on 2.5?
[22:34] <dabaR> The simplicity of the solution makes me excited....
[22:34] <dabaR> Heh, weird sentence.
[22:34] <geser> that would be the alternative (if using python 2.6 doesn't work out)
[22:35] <dabaR> geser: is this a bug you noticed yourself?
[22:35] <dabaR> I mean, a thing you were gonna fix, that you mentioned previously?
[22:36] <dabaR> You mentioned previously that you reviewed some FTBFSs and have a few you are going to work on. Is this one of those?
[22:36] <geser> yes, it's listed on http://qa.ubuntuwire.com/ftbfs/ (package is atheist) and I look at the build logs to see if I know how to fix it
[22:37] <dabaR> geser: Now, is the bug an Ubuntu only bug, or a Debian bug as well?
[22:37] <geser> I've looked at the build logs once and made me a note (so I don't forget what I already figured out :) but I didn't had time yet to work on it
[22:37] <dabaR> geser: do you happen to know.
[22:38] <dabaR> Meh, stupid question, I guess.
[22:38] <bjsnider> package is atheist? the package doesn't believe in god?
[22:38] <geser> Debian did't switch to python2.6 yet, so for now it's a bug that affects Ubuntu only but will affect Debian later too
[22:38] <dabaR> But, to fix it, you are changing a debian package source, right?
[22:39] <dabaR> OK, sorry to jump from topic to topic so fast...just kinda answering my own questions...
[22:39] <geser> yes, I take the Debian package, patch it, test-build, upload and provide the patch to Debian (if they are affected too)
[22:39] <dabaR> A-ha.
[22:39] <dabaR> OK, just cause if they don't make the change, then it is a merge from there on, right?
[22:40] <geser> yes
[22:40] <dabaR> geser: Great, thanks so much.
[22:40] <geser> and don't forget to check if lucid and Debian has the same package version
[22:41] <dabaR> geser: cause debian could have changed it already?
[22:41] <geser> so you don't waste time to fix something that is already fixed in Debian but got not yet into lucid
[22:41] <dabaR> right right, then you request a sync if it is changed, right?
[22:42] <dabaR> geser: so, do you then basically click each red box in turn, scroll to the deb-buildpackage error message, and read that to see whether you can fix it?
[22:42] <dabaR> Just as a process question...
[22:42] <geser> depends, as we are still in auto-sync mode, I just wait for the next auto-sync (if the change is already in testing) or wait till it gets into testing
[22:42] <geser> dabaR: exactly
[22:42] <dabaR> geser: A-ha, so it is more complex...
[22:42] <dabaR> geser: I think I am totally gonna write me a Mechanize script for these.
[22:45] <dabaR> geser: again, thanks very much. Talk to you again soon.
[22:51] <dabaR> Is my browser unpacking a txt.gz for me? Do you happen to know?
[22:54] <directhex> browsers tend to open .gz due to gzip compressed html stuff
[23:29] <jjlee> I'm packaging a python library and want to build debian packages from a fork of the original git repository.
[23:30] <jjlee> That means that I need to create orig tarballs from the in-development sources in the repository.
[23:31] <jjlee> python's setuptools wants to build tarballs named like this: figleaf-0.6.1.dev-20091229.tar.gz
[23:37] <jjlee> hmm, I was about to ask what I should rename it so that git-buildpackage --git-pristine-tar tries to find the correct pristine-tar tag, but I see the problem is that git-buildpackage is looking for a filename without ".orig" in it
[23:39] <jjlee> so I guess I should rename the tarball to have the ".orig" in the filename
[23:57] <jjlee> is there a command to get the appropriate .orig.tar.gz filename from the changelog?
[23:57] <jjlee> I'm already using dpkg-parsechangelog, but that doesn't give the source package filename
[23:58] <jjlee> is there a better way that just running dpkg-parsechangelog, grabbing the Version: line, splitting off everything after rightmost "-" in that version string, prepending source package name and appending ".orig.tar.gz"?