[00:01] <porthose> nhandler: Thank you for your mentoring efforts. ;-)
[00:09] <crist1> aloha
[00:10] <crist1> if a package is named 1:0.3.0-14, i should rename after altering 1:0.3.0-15ubuntu1?
[00:10] <crist1> or 1.0.3.0-14ubuntu1?
[00:12] <goshawk> crist1: second form
[00:12] <goshawk> but wait me have a look
[00:13] <crist1> goshawk: thank you
[00:15] <goshawk> yep crist1 second form
[00:57] <nazgand> What are the requirements to become a MOTU member, and how long does it usually take after applying to become a member?
[00:58] <evilv> nazgand: https://wiki.ubuntu.com/MOTU will have the info you are looking for
[00:59] <nazgand> I've already been there, but I applied and I haven't been accepted yet, so I was wondering if I didn't fill a requirement that I didn't read about or if I was just too impatient.
[01:00] <evilv> nazgand: it takes time to go through the process
[01:00] <nazgand> Ok, thank you.
[01:00] <evilv> after having several packages sponsored, your sponsors will tell you when you are ready
[01:01] <nazgand> Ok.
[01:14] <__iron> hi
[01:14] <nhandler> Hey __iron
[01:15] <__iron> i'm just writing a java ftp-client framework
[01:17] <__iron> and i would release it for ubuntu is anybody interessed ?
[01:18] <__iron> hi nhandler
[01:20] <nhandler> __iron: I'm sure some people would be interested in an application like that
[01:20] <__iron> k fine
[01:22] <__iron> thx nhandler
[01:23] <nhandler> You're welcome __iron. If you need any help packaging it, feel free to ask.
[01:24] <__iron> k thx+
[02:46] <ripps> Hey, I'm back and I'm still needing help getting my source package to install correctly.
[02:55] <nhandler> ripps: What is the issue?
[02:57] <ripps> nhanler: I have a source package that runs a script that clones 20 plugins from git, runs autogen.sh in each, and then installs them. The probelm is at the final stage of dh_install, it can't find the files so I seperate them according their debian/package_name.install.
[02:57] <ripps> Hold on, I'm doing a fresh pbuilder build with a logfile.
[03:02] <ripps> Man, it segfaulted again. This is getting pretty annoying
[03:07] <nhandler> ripps: I'm going to head off to bed. I'm sure someone else will be able to help you.
[03:08] <ripps> nhandler: okay, thanks anyway
[04:08] <adelie421> anyone else having connectivity issues with launchpad?
[04:16] <JanC> adelie421: seems t owork for me?
[04:16] <JanC> it's sometimes slow though
[04:18] <wgrant> Production doesn't work, but edge does sometimes.
[04:19] <wgrant> Hmm, prod does too, but very, very slowly.
[05:04] <adelie421> is motu only about packaging, or does it include all direct contributions to ubuntu. Reading the packaging guide right now and trying to get a feel for the scope of motu
[05:12] <ripps> Can someone help me figure out what's wrong with my source package build? I'm using a scritpt that pulls plugins from git, runs autogen.sh in each one, and then builds and installs them. I have it setup for split packages using debian/package_name.install, but something goes wrong at dh_install. Here's the pbuilder logfile: http://paste.ubuntu.com/130899/
[05:46] <adelie421> Anyone free to help a noob? Do I need to register a branch before I use bzr send -o foo.patch?
[05:47] <adelie421> I am feeling a bit overwhelmed here trying to properly submit a patch. I have been following http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
[05:49] <ripps> adelie421: Try asking for help in #bzr as well.
[05:49] <adelie421> k
[06:25] <Ryan52> ripps: did you get it figured out?
[06:25] <Ryan52> (whatever it might be..)
[06:25] <ripps> Ryan52: no
[06:26] <Ryan52> I might be able to help...
[06:29] <Ryan52> ripps: so what was your question?
[06:30] <ripps> Ryan52: Oh, you just logged on, so you haven't seen my post, hold on.
[06:30] <ripps> I'm using a scritpt that pulls plugins from git, runs autogen.sh in each one, and then builds and installs them. I have it setup for split packages using debian/package_name.install, but something goes wrong at dh_install. Here's the pbuilder logfile: http://paste.ubuntu.com/130899/
[06:32] <Ryan52> okay, what do your debian/package_name.install files look like?
[06:32] <ripps> I have 20 of them, but I'll post one of them to give you an idea.
[06:34] <ripps> Ryan52: Here's debian/gmpc-alarm.install: http://paste.ubuntu.com/130916/
[06:35] <ripps> It's based on what dpkg -L says about it as a standalone package.
[06:38] <Ryan52> hmm.
[06:38] <Ryan52> debian/tmp/usr/lib/gmpc/plugins/alarmplugin.la exists?
[06:39] <ripps> Well, according to libtool, it installed the file there. I can't check because this was built in a pbuilder environment
[06:40] <Ryan52> why are you building in pbuilder?
[06:40] <ripps> Ryan52: to keep the build environment clean, and so that I know that it will work when I upload to the ppa
[06:43] <Ryan52> what's debian/compat?
[06:44] <ripps> Ryan52: 5
[06:44] <Ryan52> change it to 7
[06:44] <Ryan52> and see if it works.
[06:45] <ripps> Okay, let me warn you I tend to get segfaults often while building, so it might take awhile
[06:46] <Ryan52> ripps: http://pastie.org/415971
[06:46] <Ryan52> it lookes like that syntax only works with debhelper 7 and up.
[06:47] <ripps> Ryan52: Oh, I wish someone had told me about that sooner
[06:47] <ripps> Every package guide I read said to leave it at 5
[06:48]  * ripps crosses his fingers
[06:48] <Ryan52> :)
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/TODO
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/AUTHORS
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/README
[06:49] <Ryan52> hmm.
[06:49] <Ryan52> is the upstream Makefile actually installing those there?
[06:49] <Ryan52> I doubt it.
[06:49] <fabrice_sp> ripps, when you have problems building a package, you can login to the chroot hidden behind pbuilder and make a manual build
[06:50] <fabrice_sp> this way, you can check where the files are installed
[06:50] <Ryan52> you probably should put the path (in the source, not from debian/tmp/) of those in debian/gmpc-alarm.docs instead.
[06:51] <ripps> Ryan52: I'll do that, if it gets past the point it always fails.
[06:51] <ripps> fabrice_sp: I know I can use pbuilder --login, but how do I move my package source into there?
[06:51] <Ryan52> well, it'll still fail at the same point if those aren't being installed by the upstream makefile.
[06:51] <Ryan52> ripps: cp? wget?
[06:52] <ripps> ... how about a bindmount?
[06:52] <Ryan52> man pbuilder
[06:52] <Ryan52> /--bindmounts
[06:52] <fabrice_sp> --bindmounts option
[06:52] <fabrice_sp> too late :-)
[06:52] <Ryan52> hehe
[06:53] <ripps> I use bindmounts with a hook script to have pbuilder scan it's result directory and import the completed packages into it's database.
[06:54] <Ryan52> pbuilder has a database?
[06:54] <ripps> it's apt database, just like ubuntu has.
[06:55] <ripps> So it'll install packages I built there that aren't included in any repositories (sometimes necesary when I'm testing new packages that have upstream dependencies)
[06:55] <Ryan52> nice.
[06:55] <Ryan52> ripps: could you please share those scripts? :)
[06:58] <ripps> Ryan52: http://paste.ubuntu.com/130928/
[06:59] <ripps> I'll rename it to .D70results when I'm not needing upstream dependencies, because it slows down the package fetching time with apt-get update.
[07:00] <ripps> I commented out lines from an old version of the script that didn't work.
[07:00] <Ryan52> oh, so you're just building an apt repository in your result dir. that seems useful.
[07:00] <ripps> Basically
[07:00] <ripps> very useful
[07:01] <ripps> make sure to have you result directory in you bindmounts, otherwise it's useless
[07:01] <Ryan52> right.
[07:02]  * Ryan52 usually goes through the trouble to build the package, use my custom repository building scripts to build an apt repo, sign it, rsync it to my vps, and manually edit the chroot's sources.list :P
[07:04] <ripps> I tried doing that before I read this: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#usingspecialaptsources
[07:09] <ripps> If you guys are wondering what this is for, it's because I maintain the gmpc-trunk team ppa, and try to keep it updated somewhat close to git upstream. The problem is that it has over 20 plugins that I've had to package and upload individually, and they need to be reuploaded everytime there's been a change to the core program. Not to mention that I backport it to intrepid and hardy.
[07:11] <ripps> Please don't segfault... please don't segfault...
[07:13] <ripps> dammit, signal 11 segfault
[07:13] <ripps> trying again...
[07:26] <fabrice_sp> ripps, what is your memory size? I had this problem when I was compiling huge C++ programs and only 1Gb.
[07:26] <ripps> fabrice_sp: only 512mb.
[07:26] <ripps> But I think it's past the point I usually fail at, the gcc compiling.
[07:26] <fabrice_sp> ripps, that could explain the segfaults...
[07:27] <fabrice_sp> oh
[07:27] <ripps> I closed a bunch of stuff I had open. Probably freed up a little memory
[07:28] <Ryan52> lack of memory causing a seg fault? that's a bug in something. :P
[07:28]  * Ryan52 thinks somebody forgot to check some return codes :)
[07:31] <ripps> fabrice_sp, Ryan52: It went further than it did before, but I still got an error
[07:31] <ripps> cp: cannot stat `debian/tmp/usr/share/doc/gmpc-alarm/TODO': No such file or director
[07:31] <Ryan52> yep, I knew that would happen.
[07:31] <ripps> But I think that's fixable, it's my *.install file's fault.
[07:32] <Ryan52> like I said, do the docs thing.
[07:32] <ripps> Getting on it now.
[07:32] <fabrice_sp> that's why building inside a chroot allows you to check that, and only repeat the install part :-)
[07:33] <Ryan52> that's why ripps shoulda just made the change when I first brought it up :D
[07:33] <ripps> I was impatient, it's gonna take me awhile to change 20+ files
[07:33] <Ryan52> oh, fun.
[07:33] <ripps> (although I could have been doing it while it was compiling)
[07:36] <ripps> Ryan52: what about *.png files?
[07:39] <Ryan52> what do you mean what about them?
[07:39] <ripps> Do they go in *.doc or *.install?
[07:39] <Ryan52> depends.
[07:39] <Ryan52> if upstream Makefile installs them debian/tmp
[07:39] <Ryan52> then specify the path from as if you are in debian/tmp and put it in package.install
[07:40] <Ryan52> if you want them in /usr/share/doc/package/ put them in package.docs
[07:40] <ripps>  /usr/bin/install -c -m 644 'magnatune.png' '/tmp/buildd/gmpc-plugins-0.18.0/debian/tmp//usr/share/gmpc/plugins/magnatune//magnatune.png'
[07:40] <ripps> so *.install
[07:40] <Ryan52> yep.
[07:41] <ripps> Well, let's try this one more time (hopefully.
[07:43] <ripps> I usually do my builds using cowbuilder, but I think the original pbuilder works well with this build, probably because pbuilder doesn't operate within the userspace.
[08:12] <eMerzh> if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman :)
[12:03] <DktrKranz> RainCT, heh :)
[12:03] <DktrKranz> feel free to reupload with suggestion I just mailed ;)
[12:06] <RainCT> lol
[12:07] <directhex> mornin'
[12:10] <DktrKranz> hi directhex
[12:12]  * directhex finds himself unable to test-build things, as his mirror's Packages.gz for universe is busted
[12:14] <directhex> DktrKranz, feel like the adventure of a lifetime? try building http://ftp.de.debian.org/debian/pool/main/b/boo/boo_0.8.1.2865-3.dsc in an up-to-date jaunty pbuilder!
[12:15] <directhex> DktrKranz, oh, and you know the monodevelop FFe was a good idea when you receive lengthy thank you messages from projects, cc'd to miguel de icaza
[12:17]  * wgrant is very concerned about the >100 FTBFSes like http://builder.ubuntuwire.com:9998/job/43267 we are looking at.
[12:17] <wgrant> I have 56 at the moment, with only half of universe built.
[12:33] <c_korn> can a MOTU have a look at sivp and upload it to the jaunty queue if everyting is correct? bug 334362
[13:25] <lfaraone> Is there any utility in attaching a debdiff to a sync request?
[13:26] <RainCT> uhm.. can I install a i386 package on amd64?
[13:27] <lfaraone> RainCT: It'll *run*, if it has all of the compat libs installed.
[13:27] <lfaraone> RainCT: why?
[13:27] <lfaraone> RainCT: as a rule it's a bad idea :)
[13:27] <RainCT> but dpkg won't let me install it :)
[13:28] <RainCT> *cough* because I want to try an applications for which there's only a .deb for i386 and I'm too lazy to compile it myself *cough*
[13:28] <geser> RainCT: use more force (--force-architecture)
[13:29] <geser> and it's not statically build you need all the needed libs as i386 too
[13:30] <directhex> usually by dumping them in /usr/lib32
[13:31] <RainCT> Ah right, thanks. But it conflicts with another package, so I guess I'll wait until someone packages it :P
[13:50] <DktrKranz> directhex, :)
[13:50] <DktrKranz> directhex, still need a testbuild?
[13:51] <directhex> DktrKranz, please. and if it works, you could ack https://edge.launchpad.net/bugs/339808 !
[13:52] <DktrKranz> directhex, I'll fire up my company's server, just some minutes :)
[13:52] <DktrKranz> directhex, it's i386
[13:52] <c_korn> what does this line mean in a diff?
[13:52] <c_korn> ! import_all(tesseract)
[13:53] <directhex> i386? yay, retro!
[13:53] <DktrKranz> intel xeon dual core
[13:53] <DktrKranz> but still i386
[13:53] <pmjdebruijn> hmmm is it already possible to use PPA for Jaunty?
[13:53] <directhex> pmjdebruijn, of course!
[13:54] <pmjdebruijn> do I need to do anything for that? or will it recognize it in the changelog?
[13:54]  * iulian is free to testbuild things.
[13:54] <slytherin> pmjdebruijn: changelog
[13:54] <pmjdebruijn> sweet
[13:56] <pmjdebruijn> I recently got a mail telling my that I was reaching my PPA's 1GB limit
[13:56] <pmjdebruijn> but, I can see why... archived packages?
[13:57] <directhex> iulian, if you have an absolutely up-to-date jaunty environment to hand, can you pastebin the output of apt-cache rdepends libmono-corlib1.0-cil for me?
[13:59] <iulian> directhex: http://paste.ubuntu.com/131065/plain/
[14:02] <ryanakca> Ok, I got a pile of packaging bugs for slingshot fixed in Debian. Is it too late to sync? No changes on the Ubuntu side.
[14:04] <directhex> iulian, neato - log4net is definitely not on that list anymore (1.2.10+dfsg-3 Published in jaunty-release 16 hours ago), so boo is the single remaining 1.0-using source package in the archive (other than mono itself)
[14:05] <DktrKranz> directhex, I haven't it in my list
[14:05] <DktrKranz> apt-get update just two hours ago
[14:06] <iulian> directhex: Ouh, lemme run an upgrade again.
[14:06] <directhex> so if boo gets synced, then the mono transition is over. fini. kaput.
[14:07] <DktrKranz> c_korn, I'll probably have a look at sivp later, unless mok0 is already on it
[14:07] <iulian> It takes much more time to unpack and replace than download packages.
[14:07] <DktrKranz> directhex, what about the remaining packages? Are they going to disappear?
[14:08] <directhex> DktrKranz, the remaining packages are all produced by the mono source package. they're occasionally used for building, and may be of use for compatibility for people running arbitrary .net apps, but no app/lib dep will pull them in
[14:09] <DktrKranz> directhex, so they can be moved to universe?
[14:09] <DktrKranz> (if not already)
[14:09] <directhex> DktrKranz, some, not all, can be (check reverse-build-depends)
[14:10] <directhex> corlib, cairo, and system will resist
[14:10] <DktrKranz> well, if we can move some out of seeds and save some disk space, I think some people could be happy :)
[14:15] <directhex> you'll need to manually check reverse-build-depends on all of them. but a cursory examination suggests that most can be moved to universe
[14:15] <directhex> also check rdepends
[14:16] <directhex> in theory only the ones depended on by mono-devel are needed anymore, i think
[14:16] <directhex> but double-check to be sure
[14:16] <DktrKranz> are the all belonging to mono source package?
[14:17] <directhex> yes
[14:17]  * DktrKranz looks
[14:18] <DktrKranz> directhex, some of them belong to xsp
[14:19] <DktrKranz> apt-cache rdepends libmono-corlib1.0-cil | xargs apt-cache showsrc | grep Package | sort -du
[14:24] <pmjdebruijn> "Rejected: Could not find person ''"
[14:24] <pmjdebruijn> I got that in an email from PPA
[14:24] <DktrKranz> directhex, btw build successful, I'm going to ACK that bug
[14:24] <pmjdebruijn> what could be wrong...
[14:25] <pmjdebruijn> these are packages for Jaunty... not Intrepid
[14:25] <DktrKranz> pmjdebruijn, is Maintainer field correctly formatted?
[14:26] <pmjdebruijn> I think so?
[14:26] <pmjdebruijn> It's not different from when I built  for Intrepid?
[14:26] <pmjdebruijn> have new check/policies been introduced?
[14:26] <DktrKranz> I don't think so
[14:27] <DktrKranz> also check if changelog timestamp entry is ok
[14:27] <pmjdebruijn> it's `date -R`
[14:29] <c_korn> DktrKranz: ok. I did not see mok0 online here for some time. don't know if he is on it
[14:30] <DktrKranz> pmjdebruijn, check the name and email after --
[14:30] <DktrKranz> c_korn, I'll have a look then
[14:30] <c_korn> ok
[14:30] <DktrKranz> btw, it's not necessary using REVU for merges or package updates
[14:31] <c_korn> so the debdiff would have been enough?
[14:33] <DktrKranz> c_korn, yes, it's more evident to see changes introduced, REVU is mainly for new packages, where every bit must be looked
[14:33] <pmjdebruijn> DktrKranz: yep, that's okay
[14:33] <DktrKranz> c_korn, I'm looking at your debdiff in the bug report, you removed .svn directory, isn't it?
[14:33] <c_korn> yes
[14:34] <DktrKranz> pmjdebruijn, did you adjusted your dput.cf file?
[14:34] <DktrKranz> *adjust
[14:34] <pmjdebruijn> the login?
[14:35] <DktrKranz> yes
[14:35] <DktrKranz> errr...
[14:35]  * pmjdebruijn doesn't remember changed that last time... but I'm semi-senile... so that doesn't mean anything
[14:35] <DktrKranz> incoming
[14:35] <DktrKranz> incoming                = ~%(ppa)s/ppa/ubuntu
[14:35] <DktrKranz> that's the default
[14:35] <pmjdebruijn> DktrKranz: yep, that's okayincoming                = ~%(ppa)s/ubuntu
[14:36] <pmjdebruijn> sorry
[14:36] <DktrKranz> you should replace %(ppa)s with your LP id
[14:36] <pmjdebruijn> 'incoming = ~pmjdebruijn/ubuntu' should be okay then?
[14:37] <DktrKranz> c_korn, it's legal to remove it, I'd be more inclined report Sylvestre just to be sure it will removed Debian side too
[14:37] <DktrKranz> pmjdebruijn, incoming = ~pmjdebruijn/ppa/ubuntu
[14:38] <pmjdebruijn> DktrKranz: my stock dput.cf doesn't include /ppa/
[14:39] <DktrKranz> pmjdebruijn, there have been changes in PPA incoming directory, now /ppa/ is part of the path. Not sure if they removed compatibility with old ~LP_id/ubuntu, though, but using new format is safe.
[14:39] <pmjdebruijn> ok
[14:41] <pmjdebruijn> now I have a file conflict
[14:41] <pmjdebruijn> a downstream tarball has changed
[14:41] <pmjdebruijn> aren't packages for intrepid and jaunty seperated?
[14:42] <pmjdebruijn> I need the new tarball, but I don't want to break my Intrepid package
[14:43] <cjwatson> I understand that you can do 'dput ppa:pmjdebruijn' rather than having to edit the default file
[14:43] <DktrKranz> if you have the same .orig.tar.gz name but with different md5 sums, it will get rejected
[14:43] <cjwatson> or 'dput ppa:pmjdebruijn/ppa' if you have it in the form pmjdebruijn quoted
[14:43] <pmjdebruijn> cjwatson: right
[14:43] <cjwatson> http://blog.launchpad.net/ppa/http://blog.launchpad.net/ppa/
[14:43] <cjwatson> oops
[14:43] <cjwatson> http://blog.launchpad.net/ppa/simplifying-dputcf-for-multiple-ppas
[14:43] <pmjdebruijn> I already edited the file, and it's fine now
[14:44] <pmjdebruijn> my problem now is a tarball conflict with an older package
[14:44] <pmjdebruijn> which I do _not_ want to break
[14:44] <directhex> DktrKranz, xsp is in univsre, and it's okay for xsp to have 1.0 deps (xsp2 from the same course package is the 2.0 version)
[14:44] <cjwatson> if the tarball has changed but has the same version number, then you must artificially rename it
[14:44] <c_korn> DktrKranz: I am in contact with Sylvestre. will notify him.
[14:44] <DktrKranz> directhex, cool then
[14:44] <pmjdebruijn> cjwatson: like?
[14:44] <cjwatson> you cannot have two objects with the same file name but different contents in the same archive
[14:44] <cjwatson> pmjdebruijn: up to you
[14:45] <pmjdebruijn> cjwatson: "the same archive" is intrepid and jaunty stuff mixed then?
[14:45] <cjwatson> yes.
[14:45] <pmjdebruijn> ugh
[14:45] <DktrKranz> pmjdebruijn, foo_0.1+repack.orig.tar.gz could go
[14:45] <cjwatson> there's a single pool
[14:45] <pmjdebruijn> hmmm
[14:45] <cjwatson> which will then mean that your package is versioned 0.1+repack-0ubuntu1 or whatever
[14:45] <pmjdebruijn> oh well, too bad for folks still on Intrepid then
[14:45] <cjwatson> why *not* rename it?
[14:45] <cjwatson> it's the right thing to do
[14:46] <pmjdebruijn> is it?
[14:46] <directhex> the root question here is, why do you WANT different orig with the same version?
[14:47]  * cjwatson -> out
[14:48] <DktrKranz> nhandler, bug 266919, is it managed using Rosetta? I can't find it in package list.
[14:49] <slytherin> when specifying CFLAGS, is order of the flags important?
[14:50] <pmjdebruijn> directhex: I'm going to check the differences
[14:52] <pmjdebruijn> directhex: the base directory seems to be the only difference, then I'll stick with the old tarball
[14:53] <pmjdebruijn> won't the common pool mean I can't have identical debian versions in different dists as well?
[14:54] <pmjdebruijn> cd ..
[14:55] <DktrKranz> pmjdebruijn, you can have identical upstream versions, but you have to use a different version for each release
[14:56] <pmjdebruijn> seems rather nasty
[14:56] <DktrKranz> e.g. if you have foo 0.1-1ubuntu1 in jaunty, you can upload foo 0.1-1ubuntu1~intrepid for intrepid, foo 0.1-1ubuntu1~hardy for hardy and so on
[14:57] <DktrKranz> package contents do not change, only version is mangled
[15:03] <directhex> siretart, ping
[15:07] <DktrKranz> c_korn, are bug 340520 and bug 329399 addressed with your upload?
[15:09] <c_korn> DktrKranz: should be fixed in the package. it was because the package did not check if the symlink was there and tried to remove it. (it is not fixed in the debian version yet)
[15:09] <c_korn> I tried updating sivp-4.x to sivp-5.x and removing
[15:09] <c_korn> everything works
[15:09] <DktrKranz> so, it's fixed by new upstream?
[15:12] <DktrKranz> c_korn, --^
[15:13] <c_korn> DktrKranz: yes, I would say so. it is because the install directory detection changed from scilab-4 to scilab-5 so sivp-4.x cannot find scilab.
[15:13] <DktrKranz> ok, I'll mangle your changelog entry to reflect it
[15:33] <slytherin> what is the way to figure out differences between two versions of same library?
[15:37] <eMerzh> if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman
[15:37] <lidaobing> sladen, dpkg-gensymbols works for you?
[15:38] <lidaobing> slytherin,  dpkg-gensymbols works for you?
[15:39] <slytherin> lidaobing: does it work as standalone tool?
[15:39] <lidaobing> slytherin, no, but you can use objdump
[15:45] <siretart> directhex: pong
[15:45] <DktrKranz> c_korn, done
[15:47] <c_korn> DktrKranz: thanks, I currently see it building. looks fine
[15:52] <directhex> siretart, any guesses why i'd see cd /tm
[15:52] <directhex> gah
[15:53] <slytherin> lidaobing: I am using that but not able to figure out the differences.
[15:54] <directhex> siretart, any guesses why i'd see "/tmp/buildd/ffmpeg-0.svn20090303/libavcodec/dsputil.c:2846: error: 'CONFIG_H263_ENCODER' undeclared (first use in this function)" when trying to build unstripped ffmpeg locally?
[15:59] <siretart> directhex: well, see http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/strip.sh;hb=HEAD
[15:59] <c_korn> DktrKranz: because scilab is now free the sivp package can go into universe I think. should I wait until released in multiverse and request a move or can it be released into universe directly?
[15:59] <siretart> directhex: that sed command is removing the h263 encoder, which is required for ffmpeg-debian in main
[16:00] <ScottK> c_korn: Is sivp in New or waiting to be uploaded?
[16:01] <c_korn> ehm, it is currently building: https://launchpad.net/ubuntu/jaunty/+source/sivp/0.5.0-1ubuntu1
[16:01] <directhex> siretart, damn, that's it, i was switching debian/control to build unstripped but hadn't realised orig differed
[16:05] <pmjdebruijn> eh... now I have a bigger issue
[16:05] <pmjdebruijn> I have lensfun_0.2.3.orig.tar.gz in my intrepid ppa, which differs from Ubuntu's master archive lensfun_0.2.3.orig.tar.gz
[16:05] <pmjdebruijn> I can't use either
[16:06] <pmjdebruijn> without renaming
[16:06] <pmjdebruijn> so I can't use the proper tarball, because I used a bad one in the past
[16:07] <siretart> directhex: get the branch from git.debian.org and 'git checkout ubuntu.jaunty.unstripped'
[16:10]  * pmjdebruijn is getting punished for being sloppy in the past :(
[16:21] <maxb> pmjdebruijn: I *think* if you delete things from your PPA and wait long enough for them to be purged completely you can replace the tarball.
[16:21] <directhex> siretart, there aren't any conflicts that would prevent me from installing it alongside lavc51 in intrepid are there?
[16:22] <siretart> directhex: there are. the new libavutil has a Breaks: libavcodec51. On purpose :(
[16:23] <siretart> directhex: see also my PPA. I have backported most packages in intrepid for the new ffmpeg
[16:24] <pmjdebruijn> maxb: yes, but this library is a dependancy for most of my PPA packages for Intrepid, so if I delete the packages, I can basically empty out my entire PPA
[16:28] <directhex> siretart, probably best to wait until jaunty, i fear. i can make do for now
[16:29] <siretart> directhex: or you could help me backporting the rest of the packages, and have then in the motumedia ppa
[16:29] <siretart> s/have/maintain/
[16:30] <directhex> siretart, sorry, i don't have enough free cycles to take that on
[16:31]  * pmjdebruijn is going to purge his entire PPA...
[16:41] <c_korn> hm, does this build hang? https://launchpad.net/+builds/crested/+index
[16:41] <c_korn> others only needed 10minutes
[16:44] <slytherin> any autotools experts here?
[16:48] <slytherin> siretart: remember the discussion about libxine having it's own copy of libdvdread/libdvdnav? What kind of analysis should I do before proposing that we use the external libdvdread/libdvdnav?
[17:24]  * hyperair wonders if anyone can review gtk2-engines-aurora
[19:34] <ryanakca> When trying to make a building chroot, I get W: BAD signature from "Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>"   ... any iedas?
[19:44] <sistpoty> hi fols
[19:44] <sistpoty> +k
[19:47] <iulian> Hey sistpoty.
[19:47] <sistpoty> hi iulian:
[19:48] <sistpoty> iulian, DktrKranz, ScottK, DktrKranz, nhandler: proposal for mail to ubuntu-devel-announce... problem is that I'm not too sure about rebuild statistics yet (which is [4]): http://paste.ubuntu.com/131242/
[19:49] <pochu> DktrKranz: you gotta read it twice :)
[19:49] <sistpoty> damn
[19:51] <sistpoty> slangasek: oh, if the mail proposal finds approval, anything you'd like to add for ubuntu-relelase? (http://paste.ubuntu.com/131242/)
[19:51] <sistpoty> s/relelase/release/
[19:52] <DktrKranz> pochu, I'm like Dr. Jekill and Mr. Hyde, you have to ping me twice in a statement to have my full attention, or you receive just a half
[19:52] <sistpoty> haha
[19:52] <RainCT> lol
[19:52]  * RainCT is happy because he got his boot time from 80 to 50 seconds :)
[19:53] <pochu> huh, 80
[19:53] <pochu> RainCT: is that your Acer eMachines? ;-)
[19:53] <RainCT> yeah.. 20 of those are the X trying to start several times..
[19:53] <DktrKranz> RainCT, have you hamsters instead of CPUs?
[19:53] <RainCT> pochu: No. The eMachines one is really fast :)
[19:54] <iulian> Hamsters... yikes!
[19:54] <RainCT> hah
[19:54] <DktrKranz> sistpoty, what about qa.ubuntuwire.com/ftbs or http://builder.ubuntuwire.com:9998/dist/jaunty/arch/i386/failed ?
[19:54] <iulian> I'd go with the former.
[19:54] <DktrKranz> *ftbfs
[19:55] <RainCT> btw, does concurrency=shell work now? last time I tried the boot would get slighly slower because the laptop did everything twice (once at every CPU) XD
[19:55] <sistpoty> DktrKranz: cool, didn't know about that link... even seems up to date
[19:55] <sistpoty> DktrKranz: thanks
[19:55] <RainCT> (s/CPU/core, of course)
[19:56] <DktrKranz> sistpoty, np, thanks for preparing it :)
[19:56] <RainCT> jdong_: thanks for the readahead tutorial, btw :)  that gave me, together with switching to ext4, 25 seconds
[19:57] <DktrKranz> RainCT, I'll be satisfied when my system will boot in -3 seconds
[19:57] <RainCT> DktrKranz: Heh. How long does it take now?
[19:57] <DktrKranz> about 70 seconds
[19:57] <dtchen> DktrKranz: that's easy - just remove all the hw.
[19:57] <RainCT> DktrKranz: err.. and you complain about my CPU? :P
[19:58] <DktrKranz> dtchen, I was thinking about a system plugged with my brain which interpretes my wish to turn on PC and he starts system in advance
[19:58] <iulian> Hmm, I believe my crappy lappy boots in less than 50 seconds.
[19:58]  * iulian should test it some day.
[19:58] <DktrKranz> RainCT, in two years my PC won't be underage anymore :)
[19:58] <jdong> RainCT: neat :)
[19:59] <jdong> RainCT: another bootup hack to try is to "delay" noncritical bootup services until way after GDM
[19:59] <RainCT> jdong: how is that done?
[19:59] <dtchen> or just drop your rotary disks for SSD
[19:59] <jdong> RainCT: in my system GDM is S13, everything that GDM doesn't depend on is moved to S50 and beyond, and S45 is basically "sleep 120s"
[19:59] <sistpoty> slangasek: around? I'd like to send a mail to u-d-a regarding a new ubuntu-release delegate, which however also mentions common tasks at this point, want to add s.th. for ubuntu in general? (proposal: http://paste.ubuntu.com/131252/)
[19:59] <jdong> (it's a hack but gets me to the login screen ~5s faster)
[20:00] <DktrKranz> lol, my package FTBFS and I wasn't aware of that!
[20:00] <DktrKranz> http://builder.ubuntuwire.com:9998/job/43632
[20:00] <iulian> Heh
[20:00] <RainCT> although I guess I'd already be happy if I got ride of the damn 20 seconds worth in tries to start X.. XD
[20:00] <RoAkSoAx> bug 277648
[20:00] <sistpoty> DktrKranz: that happens... fauhdlc FTBFS'd on anything but i386 and amd64 even though I wrote almost every single line for it
[20:01] <RainCT> jdong: uhm.. wheren't they discussing doing something like that in #ubuntu-devel a few days ago
[20:01] <DktrKranz> sistpoty, I wasn't aware of that because I haven't rebuilt my python packages against 2.6
[20:01]  * DktrKranz should have a run at them tomorrow
[20:02] <sistpoty> DktrKranz: heh... I'm still curious what edos is about :P
[20:02] <DktrKranz> I love edos-debcheck
[20:02] <DktrKranz> it's simply extraordinary :)
[20:03] <sistpoty> (the pasted commands won't work for me... I'm on unstable right now, and don't intent to reboot to jaunty as of speeking)
[20:04] <sistpoty> DktrKranz: what exactly does edos provide?
[20:04] <sistpoty> (or edos-debcheck?)
[20:05] <DktrKranz> sistpoty, it checks for package installability comparing package versions, conflicts or blocks fields
[20:06] <sistpoty> DktrKranz: then it'd be similar as in "apt-cache -i unmet" for a given arch?
[20:06] <DktrKranz> mostly, but it tells you why:
[20:06] <DktrKranz> envyng-qt (= 2.0.1): FAILED
[20:06] <DktrKranz> The following constraints cannot be satisfied:
[20:06] <DktrKranz>   envyng-qt (= 2.0.1) depends on python (<< 2.6) {NOT AVAILABLE}
[20:07] <DktrKranz> e.g.   this one states envyng-qt requires to be rebuilt against 2.5, apt-cache -i unmet tells you it's just uninstallable
[20:07] <sistpoty> DktrKranz: well, apt-cache -i unmet also tells you why... but only for the arch *you are running apt-get on*
[20:08] <DktrKranz> ah, long time I don't use it
[20:08] <sistpoty> DktrKranz: so, it seems like a arch-independent apt-get -i unmet is a *huge* win ;)
[20:08] <DktrKranz> well, edos-debcheck needs Package from mirrors, so you can run it for sparc, ppc or armel
[20:08] <jdong> RainCT: the Dell Mini 9 Ubuntu spin does something similar too
[20:09] <DktrKranz> just fetch Packages.gz files and give it them to eat
[20:09] <sistpoty> sure, the info should be there
[20:09] <sistpoty> still it's a leap jump from checking unstallable package for
[20:10] <sistpoty> + *one* arch, instead of any arch
[20:10] <sistpoty> I guess only britney could do this back then... (or whatever is the name now that debian-release use for their testing-migration script)
[20:11] <DktrKranz> I guess it's britney
[20:11] <sistpoty> heh
[20:11] <DktrKranz> oh, holger is doing amazing job on piuparts these days!
[20:11] <DktrKranz> I'd like to use it more in Ubuntu
[20:12] <ryanakca> I got a pile of packaging bugs for slingshot fixed in Debian (bugs were filed in both Ubuntu and Debian). Is it too late to sync?
[20:12] <dtchen> no
[20:12] <sistpoty> DktrKranz: oh? cool... from my personal setup, it usually bailed out (since I guess I must have been doing s.th. wrong... either wrong .tar.gz or s.th. else)
[20:13] <DktrKranz> sistpoty, I plan to have it working out-of-the-box, it needs some love :)
[20:13] <sistpoty> ryanakca: new upstream release in unstable?
[20:13] <sistpoty> ryanakca: that brings in new features apart from only bug fixes?
[20:13]  * DktrKranz runs now, c u tomorrow
[20:14] <sistpoty> cya DktrKranz:
[20:15] <sistpoty> ryanakca: if it's only bug fixes, there's no problem... otherwise we'd need a feature freeze exception request
[20:21] <ryanakca> sistpoty: No, same old version, upstream is MIA. Just packaging bug fixes (aka, inserted an xpm icon, updated path to GPL, depend on ttf-freefont instead of installing a duplicate, etc)
[20:22] <sistpoty> ryanakca: then that's fine... can you file a sync request?
[20:22] <ryanakca> sistpoty: Sure.
[20:22] <sistpoty> ryanakca: thanks!
[20:23] <c_korn> I don't understand why the build of sivp for amd64 fails: https://launchpad.net/ubuntu/+source/sivp/0.5.0-1ubuntu1/+build/904358/+files/buildlog_ubuntu-jaunty-amd64.sivp_0.5.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[20:23] <c_korn> it succeeds in a PPA
[20:24] <c_korn> (the PPA is here https://launchpad.net/~getdeb.packages/+archive/ppa)
[20:26] <ScottK> c_korn: Put it in a PPA that doesn't have a lot of non-Ubuntu stuff in it and see if it builds.
[20:26] <ScottK> There may be something it builds against in the PPA that isn't in Ubuntu.
[20:26] <c_korn> ScottK: lots of non-ubuntu stuff?
[20:27] <c_korn> there is only vlc in it
[20:27] <ScottK> Oh.  OK.
[20:27]  * ScottK made an assumption that the getdeb PPA would have lots of stuff in it.
[20:27] <ScottK> Nevermind then.
[20:27] <ScottK> Let's give it a retry.
[20:29] <c_korn> ScottK: hrhr. reuploading
[20:29] <ScottK> c_korn: No need to reupload.  I can trigger a retry
[20:29] <ryanakca> sistpoty: Hmmm... ``The versions in Debian and Ubuntu are the same already (0.8.1p-1). Aborting.'' ... however, http://packages.debian.org/sid/slingshot shows 0.8.1p-2 ... give it a few hours?
[20:29] <c_korn> ScottK: I mean I reupload it to the PPA. just for testing
[20:30] <ScottK> c_korn: Ah.  OK.  Makes sense.  I just retried it too, so we'll see.
[20:31] <c_korn> ScottK: actually there was scilab before in the PPA (when scilab was not yet in ubuntu). but the same version has been published in jaunty
[20:31] <ScottK> OK.
[20:32] <sistpoty> ryanakca: ubuntu doesn't have -2, so at this point of time, you'd need to file a sync request for -2
[20:32] <sistpoty> ryanakca: only before debian import freeze, packages are synced automatically (if these don't have ubuntu changes)
[20:33] <ryanakca> sistpoty: *nod*, ... so, shouldn't ``requestsync -k E95EDDC9 slingshot jaunty'' do it?
[20:33] <sistpoty> ryanakca: no idea, haven't use requestsync myself yet (I'm always filing these by hand *g*(
[20:34] <ryanakca> *nod*, thanks :)
[20:37] <jacob> would patching mail-notification to work well with notify-osd be something that would require a FFe? I ask because the proposal on https://wiki.ubuntu.com/NotifyOSD suggests UI changes if notify-osd is in use
[20:57] <c_korn> ScottK: it still builds fine in the PPA https://launchpad.net/~getdeb.packages/+archive/ppa/+build/904630
[21:09] <wgrant> apachelogger: kde-i18n-* all seem to FTBFS like http://builder.ubuntuwire.com:9998/job/43356.
[21:11] <apachelogger> wgrant: --without-arts needs to be added to the configure arguments
[21:12] <wgrant> apachelogger: I presume there's some way to do it to all of them?
[21:12] <apachelogger> not really
[21:12] <apachelogger> I'd recommend to write a simple script apt-get source'ing through apt-cache search kde-i18n- and then edit all of them
[21:13] <wgrant> I don't really care about them - I'm just triaging all of the rebuild failures - but I'll do them if nobody else wants to.
[21:13] <apachelogger> JontheEchidna: pling
[21:16] <apachelogger> wgrant: I'll mail kubuntu-devel
[21:16] <wgrant> apachelogger: Thanks.
[21:17] <wgrant> Similar failures make up about 10% of the failures so far.
[21:17] <wgrant> Most of those being langpacks.
[21:18] <adelie421> ok, finally figured out how to do a simple patch, but when I run 'debuild -S' I get " clearsign failed: secret key not available". I have a registered key. Any help? I am new
[21:19] <adelie421> I am following this guide given to me by the maintainer: https://wiki.ubuntu.com/Bugs/HowToFix
[21:19] <JontheEchidna> apachelogger: plong
[21:19] <maxb> adelie421: Are you actually trying to prepare an upload, or just test the build?
[21:20] <apachelogger> JontheEchidna: do we have a minion to address the kde-i18n ftbfs?
[21:20] <JontheEchidna> hrm...
[21:20] <adelie421> I am trying to prepare an upload
[21:20] <JontheEchidna> apachelogger: not that I know of
[21:21] <adelie421> It was mostly spelling errers / typos in documentation
[21:21] <JontheEchidna> but I would rather not fancy getting 13K emails by doing it myself
[21:21] <apachelogger> JontheEchidna: lol
[21:21] <apachelogger> JontheEchidna: you must triage your mails I say
[21:21] <wgrant> Why 13K?
[21:21] <maxb> adelie421: Run 'gpg --list-secret-keys' and check whether any of the printed user IDs corresponds to the user ID of the top entry in the debian/changelog
[21:21] <wgrant> Since they're not in main...
[21:22] <JontheEchidna> oh, I was confusing them with kde-l10n
[21:22] <adelie421> gpg --list-secret-keys
[21:22] <adelie421> ha ha, doh
[21:22] <JontheEchidna> which are in main
[21:23] <JontheEchidna> That being said kde-l10n needs an upload too, bug 330069.
[21:24] <apachelogger> JontheEchidna: maybe batl10n-edit is of need
[21:24] <JontheEchidna> apachelogger: I already blackhole everything from rosetta@launchpad.net :P
[21:24] <adelie421> is the name supposed to be under the date?
[21:25] <adelie421> err... email does not match. must be it
[21:25] <apachelogger> JontheEchidna: actually it could share most stuff with batl10n anyway ... so batl10n just needs to be copied and modified and the appropriate stuff moved to bat.rb
[21:25] <apachelogger> JontheEchidna: then it would also be mostly useable for kde-i18n
[21:25]  * JontheEchidna nods
[21:27] <adelie421> that was the problem. Thanks! btw, how do I change it so 'dch -i' uses the right email address?
[21:27] <maxb> export DEBEMAIL=....
[21:27] <c_korn> ScottK: I don't know why it hangs again https://launchpad.net/+builds/yellow
[21:28] <adelie421> maxb: will that fix it permanently?
[21:28] <apachelogger> anyway
[21:28] <apachelogger> wgrant, JontheEchidna: mail sent
[21:28] <c_korn> ScottK: exactly the same package has been built successfully here: https://launchpad.net/~getdeb.packages/+archive/ppa/+build/904630
[21:29] <apachelogger> JontheEchidna: also, I am not sure kde-l10n should be changed to resolve that bug ... rather kde 3 should be using a different path for it's localized content, one really might want kde-l10n-de and kde-i18n-de for example
[21:30] <JontheEchidna> true
[21:30] <apachelogger> JontheEchidna: also-ng, you should blackhole everything from rosetta@launchpad.net that contains "successfully imported" or something ;-)
[21:31] <JontheEchidna> what do I with failure though? lol
[21:31] <JontheEchidna> bring a sacrificial goat next time?
[21:31] <apachelogger> JontheEchidna: poke launchpad guys and tell them their product is broken ;-)
[21:32] <wgrant> apachelogger: The success notifications are disabled.
[21:33] <wgrant> But they probably won't actually go away until the next release, unless somebody can convince them a cherrypick is justified.
[21:34]  * apachelogger thinks that new contributors might get easily annoyed
[21:35] <adelie421> ok, after running debdiff, at the top it says "gpg: Can't check signature: public key not found". Is that ok, or did I miss something?
[21:41] <ScottK> wgrant: That's an odd definition of disabled then.
[21:41] <ScottK> c_korn: No idea then.
[21:41] <wgrant> ScottK: Disabled in trunk.
[21:41] <ScottK> is/will be then.
[21:41] <wgrant> Much that we mark as fixed many bugs that won't be fixed in a release for several months.
[21:41] <wgrant> s/that/like/
[21:42] <ScottK> Trunk is a VCS, not a developemental release.
[21:42]  * ScottK thinks it's rather different.
[21:42] <wgrant> A development release here will be a VCS within a few releases, I suspect.
[21:43] <ScottK> Also with Ubuntu one could choose to run the developmental release.  With a service like LP, no such choice exists.
[21:43] <wgrant> Mm, edge, but that doesn't help for this particular change.
[21:43] <ScottK> Right.
[21:48] <jmarsden> I've made a versioning mistake in my PPA.  It thinks 1.7rc1 is newer than the final 1.7 release, and so won't accept the upload of the "final" version... is there a way to fix this?  I'm seeing: Rejected:
[21:48] <jmarsden> bibletime_1.7-1ubuntu1~jmarsden1.dsc: Version older than that in the archive. 1.7-1ubuntu1~jmarsden1 <= 1.7rc1-1ubuntu1~jmarsden1
[21:49] <wgrant> jmarsden: You wanted ~rc1. There's no clean way to fix this, but using 1.7.0 instead will work.
[21:50] <jmarsden> Thanks, yes, I realise (now) the value of the ~ :)   I'll go with 1.7.0.
[22:04] <c_korn> ScottK: who should I ask about then?
[22:04] <c_korn> it is very odd
[22:13] <c_korn> is this move request allright? bug 342954
[22:15] <c_korn> I have an odd situation: sivp compiles fine in a PPA for amd64. but the build on the official build machines just freezes for amd64. who should I contact about that?
[23:25] <ScottK> c_korn: Someone who has amd64 (not me) and someone who understands java stuff (not me).
[23:31] <c_korn> ScottK: I contacted someone from #launchpad . he wants to investigate. thanks
[23:31] <c_korn> need to sleep. bye
[23:34] <meoblast001> hi
[23:34] <meoblast001> you guys here make debs regularly correct?
[23:37] <joaopinto> meoblast001, yes
[23:37] <meoblast001> ok
[23:38] <meoblast001> i'm trying to become fluent at deb building and i've ran into a wall
[23:38] <meoblast001> http://rafb.net/p/vB4wRZ75.html
[23:38] <meoblast001> dpkg-source is failing
[23:39] <joaopinto> meanburrito920_, the error message tells it all :)
[23:39] <meoblast001> you mean meoblast001?
[23:39] <joaopinto> ops :P
[23:39] <joaopinto> I do
[23:39] <joaopinto> your clean rules is not cleaning what it should
[23:39] <meoblast001> joaopinto: i'm sort of new at deb building (only built 2 packages before) so that error message isn't registering with my brain
[23:39] <meoblast001> sounds to me like something exists now that didn't exist before?
[23:40] <joaopinto> meoblast001, yes, something that resulted from building, which means, it should be removed, at your clean rule
[23:40] <joaopinto> usually with a -make distclean
[23:40] <meoblast001> joaopinto: would that delete the entire compile?
[23:40] <meoblast001> it took some time to compile audacity on this pentium m
[23:40] <meoblast001> i don't want to recompile it all
[23:41] <meoblast001> should i just remove the files it's speaking of in the error? that sounds like it would break audacity
[23:42] <joaopinto> it would not break, they will be rebuilt
[23:42] <joaopinto> you just want to build a .deb for your own use ?
[23:43] <meoblast001> joaopinto: well... basically... for learning purposes
[23:43] <meoblast001> ugh.... the Do Not Eat on the package that came with this beef jerky is tempting
[23:43] <meoblast001> oh wait.... ontopic
[23:43] <meoblast001> debs
[23:44] <meoblast001> joaopinto: ok thanks... let me try that real quick
[23:49] <meoblast001> joaopinto: something makes me want to think it's remaking everything
[23:49] <meoblast001> joaopinto: well... looks like i'll be waiting a while
[23:49] <joaopinto> meoblast001, if you didn't use -nc, it did
[23:49] <meoblast001> joaopinto: thanks for the heads up :P
[23:50] <meoblast001> joaopinto: so i have to use -nc for it to not rebuild everything?
[23:50] <meoblast001> or -nc makes it rebuild everything
[23:54] <meoblast001> joaopinto: ?
[23:55] <_Groo_> meanburrito920_: me? nope, but i know him :)
[23:56] <_Groo_> meoblast001: sorry i sent to meanburrito920_
[23:56] <meoblast001> _Groo_: ?
[23:57] <_Groo_> meoblast001: never mind :D
[23:57] <meoblast001> am i supposed to -nc my dpkg-buildpackage for it not to rebuild everything?