[00:00] <Aloha> geser, ok thnx
[00:00] <matthijs> Aloha, sorry to bother you, but could you initiate a pm?
[00:00] <LaserJock> joejaxx: around?
[00:00] <geser> Aloha: and I doubt you need samba during the build, the samba library should be enough (more precisely libsmbclient-dev which you already list)
[00:00] <Aloha> geser, ok i wasn't sure
[00:01] <vemon> RAOF, it worked! replaced (.*) with ([0-9.]*) and now the rc releases aren't listed anymore
[00:01] <Aloha> geser, thnx for the info
[00:02] <RAOF> vemon: If you'd like to pick up the rc releases, but ensure that they're not considered higher than the final you might want to check out the various "versionmangle" options.
[00:02] <joejaxx> LaserJock: hi
[00:02] <geser> Aloha: if you are missing a build-depends either the package doesn't build in a pbuilder (error during configure or compilation) or an optional feature is missing
[00:02] <joejaxx> LaserJock:  :D
[00:03] <Aloha> geser, i'm pbuilding on hardy but im using gutsy. will apt-get -s install still help me?
[00:04] <vemon> RAOF, well it doesn't feel right to include the rc releases since they are... well.. release candidates :)
[00:05] <geser> Aloha: no, as it will simulate the installation on your gutsy system
[00:05] <geser> Aloha: but can you login into your hardy pbuilder (pbuiler login) if you need to check something in a hardy environment
[00:06] <Aloha> geser, oh sweet, didn't know about pbuilder login feature
[00:07] <matthijs> I have to go now. I'll be back tomorrow... bye!
[00:10] <ScottK> blueyed: Congratulations.
[00:11] <Aloha> jono, Jono! hihi ;)
[00:11] <blueyed> ScottK: thanks :)
[00:11] <jono> hey
[00:12] <jono> hows it going?
[00:12] <Aloha> blueyed, what happened?
[00:12] <Aloha> jono, learning how to build packages for REVU
[00:12] <jono> Aloha: :)
[00:13] <blueyed> Aloha: I'm MOTU now.
[00:13] <Aloha> blueyed, YAY! congratz!
[00:14] <blueyed> Aloha: Thanks :)
[00:15] <geser> Aloha: blueyed can now break packages on his own :)
[00:16] <Aloha> woohoo ;)
[00:20] <Aloha> geser, i found the problem... hardy uses libgtk2.0-dev not 1.2 like gutsy. thnx for the info
[00:20] <RAOF> Oh, have we finally killed libgtk1.2?
[00:21] <Aloha> RAOF, apparently
[00:21] <geser> !info libgtk1.2-dev hardy
[00:21] <ubotu> libgtk1.2-dev (source: gtk+1.2): Development files for the GIMP Toolkit. In component universe, is optional. Version 1.2.10-18.1build2 (hardy), package size 1151 kB, installed size 3788 kB
[00:21] <RAOF> Awww :(
[00:21] <Aloha> hrm
[00:21] <ion_> Both hardy and gutsy have both 1.2 and 2
[00:21] <Aloha> it wouldn't let me install from pbuilder login
[00:21] <ion_> Although the quicker we get rid of 1.2 the better. :-)
[00:22] <ion_> Perhaps you don’t have universe enabled inside the chroot.
[00:22] <Aloha> ion_, is 2.0 under universe?
[00:23] <RAOF> No, but 1.2 is.
[00:23] <RAOF> 1.2 being the ancient version of gtk+ that no one should use :)
[00:23] <Aloha> RAOF, gotcha. howdo i enable universe under chroot?
[00:54] <pochu> TheMuso: I'm now, in case I may be useful
[01:00] <hexmode> I would like to get php-xdebug included in ubuntu.  I have svn commit access for the Debian PHP maintenance team's SVN archive, so I can probably get it into Debian.  Is that the best route to get it into Ubuntu?  Or should I also submit it for REVU?
[01:14] <Aloha> if i'm adding upstream package to REVU and its from tarball i do <version>-0ubuntu1 for package version right?
[01:16] <RAOF> The pacakge version should be $UPSTREAM_VERSION-$DEBIAN_REVISIONubuntu$UBUNTU_REVISION.
[01:16] <RAOF> So, in the case where this version of the package isn't in Debian, you are correct.
[01:18] <Aloha> RAOF, ok thnx
[01:25] <Aloha> how long does it take for upload to show up on REVU site?
[01:28] <Aloha> I uploaded and tried to login but it says No REVU account for tjgillies@gmail.com exists yet.
[01:31] <TheMuso> pochu: As I said, never mind.
[01:33] <ajmitch> Aloha: sadms?
[01:33] <Aloha> ajmitch, yeah
[01:34]  * ajmitch would guess that you're not in the team, or the keyring hasn't been resynced for awhile
[01:34] <Aloha> ajmitch, i'm in the team. can you resynch keyring? dput said it uploaded successfully
[01:35] <ajmitch> dput only knows as much as any ftp server will reply
[01:35] <ajmitch> it doesn't know about the key verification
[01:36] <Aloha> ajmitch, gotcha. do i have to reupload after key sync?
[01:38] <ajmitch> no
[01:38] <ajmitch> the .changes file can just be moved back for reprocessing
[01:39] <Aloha> ajmitch, whats that mean in english? ;)
[01:41] <ajmitch> 20:38 < ajmitch> no
[01:41] <Aloha> ajmitch, i know but i mean what does moved back for reprocessing mean?
[01:41] <Aloha> i don't understand that concept
[01:42] <StevenK> Aloha: As in, no, you don't have to re-upload.
[01:43] <Aloha> StevenK, i understand i don't have to reupload. but where does the file get moved back to?
[01:43] <StevenK> Where it was before it got processed and rejected.
[01:44] <emgent> chiup chiup *
[01:45] <Aloha> StevenK, gotcha. its that automatic or does someone have to manually do it?
[01:47] <Aloha> if not can someone resync it please :)
[01:50] <Aloha> RAOF, welcome back
[01:52] <RAOF> Silly lock-happy mythtv :)
[02:12] <bddebian> Heya gang
[02:14] <rjmyst3> bddebian: thanks for the review
[02:14] <rjmyst3> working on it now ...
[02:15] <bddebian> Hi rjmyst3, np
[02:18] <Aloha> thank whoever resynced the keyserver
[02:18] <Aloha> s/thank/thanks/
[02:19] <ion_> Mr. John Cronjob perhaps. ;-)
[02:19] <bddebian> heh
[02:21] <Aloha> maybe
[02:21]  * Aloha thanks Mr Cronjabbi
[02:52] <rjmyst3> bddebian: you stated "Debian/copyright should list upstream authors and should have dates on the copyright. "
[02:52] <rjmyst3> currently, the copyright file states "Copyright Holder:  Jose Antonio Hurtado"
[02:52] <rjmyst3> that is not sufficient?
[02:53] <bddebian> That's OK but should have copyright dates if available
[02:53] <bddebian> And the authors and copyright holders may or may not be the same so they are usually listed seperately
[02:57] <rjmyst3> bddebian: is this better? https://wxformbuilder.svn.sourceforge.net/svnroot/wxformbuilder/3.x/trunk/install/linux/debian/copyright
[02:58] <bddebian> rjmyst3: Looks good to me.  I suck at the copyright stuff overall though :-)
[02:58] <rjmyst3> lol - me, too
[02:59] <Aloha> http://revu.tauware.de/details.py?upid=1595 --- this is my once per day
[03:00] <rjmyst3> bddebian: you pasted this lintian error "E: wxformbuilder: menu-item-creates-new-root-section Applications /usr/share/menu/wxformbuilder:1"
[03:00] <rjmyst3> i can't get lintian to say that to me
[03:00] <rjmyst3> I tried "lintian -I -i " on my .changes file
[03:01] <rjmyst3> what am I missing?
[03:01] <bddebian> That might be my fault.  That machine is still running gutsy so it might be lintian
[03:01] <bddebian> Anyone good with gtk2/perl/gladexml? :)
[03:23] <Aloha> if someone posts a packaging request and you upload to REVU but its not reviewed/advocated yet, should you change bug status to Fix Committed? or leave in progress?
[03:35] <LaserJock> joejaxx: ping
[03:44] <joejaxx> Laserjock hi
[03:44] <joejaxx> :(
[03:59] <joejaxx> LaserJock: hi :D
[03:59] <LaserJock> joejaxx: hi, still trying to figure out the memory thing
[03:59] <joejaxx> oh?
[03:59] <LaserJock> found it wasn't really so much Gnome
[03:59] <LaserJock> with openbox or other similarly minimal WM I still was runnin ~250MB RAM used
[03:59] <joejaxx> :\
[04:00] <LaserJock> I swear it should be <100MB
[04:00] <joejaxx> yeah
[04:00] <LaserJock> now with Gnome+firefox is >300MB
[04:00] <joejaxx> yeah that is ridiculous
[04:01] <LaserJock> in top it looks like everything has a lot more memory usage than I'd expect
[04:02] <LaserJock> gnome-terminal and xchat are taking 20MB each
[04:05] <rjmyst3> bddebian: I just uploaded a new version that fixes the issues you reported
[04:05] <rjmyst3> If you could find the time to confirm that, I'd really appreciate it.
[04:07] <TheMuso> LaserJock: Is this hardy?
[04:07] <LaserJock> TheMuso: no, gutsy :/
[04:07] <effie_jayx> just firefox takes 90 MB
[04:08] <effie_jayx> and this is not ubuntu specific
[04:08] <LaserJock> I have 2GB of RAM so it's not causing problem yet, but I'm not used to having that much used
[04:08] <TheMuso> LaserJock: Ouch.
[04:08] <LaserJock> effie_jayx: I used to usually have it use 20MB/tab
[04:10] <LaserJock> hmm, my wife's laptop is using 130MB of RAM
[04:10] <LaserJock> she has 512MB total but I wouldn't think that would matter so much for actual used RAM
[04:10] <effie_jayx> LaserJock,  well On my system it is not such a hungry beast
[07:12] <warp10> Hi all
[07:14] <dcmorton> hello warp10
[07:14] <warp10> dcmorton: :)
[07:15] <dcmorton> warp10: have you done anything with the MOTU team?
[07:15] <dcmorton> submitted packages, etc?
[07:16] <warp10> dcmorton: I had. I am a MOTU helpful, and I worked on a number of packages already.
[07:17] <dcmorton> thats interesting... i've been looking for somewhere to get started to help out, but i haven't been sure where
[07:18] <warp10> dcmorton: this channel and this page https://wiki.ubuntu.com/MOTU/GettingStarted are surely a good point to start
[07:19] <warp10> dcmorton: I recommend this page too, it gives a wide overview of the whole development process https://wiki.ubuntu.com/UbuntuDevelopment
[07:20] <dcmorton> thanks warp10, i'll check those out
[07:20] <warp10> dcmorton: :)
[07:30] <dholbach> good morning
[07:31] <Hobbsee> morning dholbach!
[07:31] <warp10> morning dholbach!
[07:31] <dholbach> hey Hobbsee, hey warp10!
[07:45] <superm1> mornin dholbach
[07:45] <dholbach> hey superm1
[07:51] <Aloha> learning cdbs is nuts
[07:51] <Aloha> i think i'm over complicating it
[07:52] <superm1> Aloha, yeah it's supposed to be a minimalistic approach to packaging
[07:52] <Aloha> superm1, i don't get what i'm supposed to do after i put in the *.mk lines....
[07:53] <superm1> Aloha, well in some cases nothing
[07:53] <Aloha> superm1, oh
[07:53] <superm1> for the kinds of apps your were describing earlier, you would only need something there if you had to say adjust permissions
[07:53] <superm1> did you get a chance to look over one of the packages i was describing to you earlier?
[07:55] <Aloha> superm1, i forget if i did. what were they called again?
[07:56] <superm1> Aloha, i was saying you can look at any of the mythtv-theme-* source packages
[07:56] <superm1> they all use cdbs without Makefiles
[07:56] <superm1> and just install pieces into locations
[07:56] <Aloha> superm1, ooh yeah... i knew it was mythtv* forgotthe -theme part
[07:56] <Aloha> superm1, thnx
[07:56] <superm1> no prob
[07:59] <Aloha> superm1, i hope your gmyth REVU gets advocated
[07:59] <superm1> Aloha, well there are a few more pieces that have to come with it too
[07:59] <superm1> i've had to talk to upstream about it
[07:59] <superm1> because they have a really bad .orig.tar.gz for the others
[08:00] <superm1> shipping a debian directory, .svn stuff all over, no licenses on source files
[08:00] <superm1> so i'm more worried about those pieces coming through
[08:00] <Aloha> heh
[08:00] <superm1> and once all that is said and done, all 3 source packages need to have MIR's filed before totem is going to learn to talk mythtv
[08:01] <superm1> a *lot* to happen before a FF
[08:03] <Aloha> yeah heh
[08:11] <Aloha> how do i use debian/watch?
[08:13] <dholbach> Try: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[08:21] <Aloha> dholbach, thnx
[08:22] <Aloha> how do you do a literal character search on google i.e. "debian/file"
[08:23] <Aloha> it wants to ignore the /
[08:46] <superm1> juliank, thanks for getting all that aufs together in lum
[08:56] <huats> morning everyone
[08:57] <RAOF> superm1: Re: gmyth - you're build-depending on libcurl3-openssl-dev, but I haven't seen an openssl exception in the copyright.
[08:57] <vemon> please review:
[08:57] <vemon> http://revu.tauware.de/details.py?package=whysynth
[08:57] <superm1> RAOF, what sort of exception is required for openssl?
[08:58] <vemon> http://revu.tauware.de/details.py?package=ghostess
[08:58] <superm1> i wasn't aware anything was necessary (never had built against it in the past)
[08:58] <vemon> the first is a DSSI synth and the latter a DSSI host for synths
[08:58] <RAOF> superm1: Basically the licence headers have to also say "GPL, but you can link against OpenSSL"
[08:59] <superm1> RAOF, can you think of a package offhand that i can lift some verbatim wordage from on that to drop in place?
[08:59] <RAOF> superm1: It needs to be upstream.
[08:59]  * superm1 shrugs
[08:59] <RAOF> superm1: OpenSSL is *not* gpl-compatible; you can't redistribute it.
[08:59] <RAOF> (At least, according to gnu.org)
[08:59] <superm1> that makes things a little more difficult here i suppose
[09:00] <RAOF> superm1: There's probably a libcurl3-gnutls-dev, which should provide the same functionality?
[09:00] <RAOF> While being GPL-compatible.
[09:00] <superm1> i'll see what i can do with upstream, i already had a few requests I had to send to fix a few more things
[09:00] <superm1> i'll give it a shot
[09:00] <RAOF> Just before I go reviewing it too far :)
[09:00] <RAOF> (Licensing sucks)
[09:01] <superm1> okay well assuming that can work out, let me know anything else you catch
[09:01] <RAOF> Yup.
[09:12] <superm1> RAOF, yeah it appears to work perfectly with gnutls instead
[09:22] <persia> nxvl: Thanks a lot for helping with support.   Would you mind pushing these discussions to ubuntu-users@ or bugreports though?  ubuntu-motu@ isn't really a support channel.
[09:23] <Aloha> whats debian/compat for? kinda find it in debian policy anywhere
[09:24] <Aloha> s/kinda/can't/
[09:24] <slytherin> Aloha: it is for specifying with which debhelper version your packaging is compatible. If debhelper in control file is 5.x then compat file should contain 5.
[09:25] <Aloha> slytherin, so don't delete it?
[09:25] <Aloha> trying to keep a clean debian
[09:25] <slytherin> Aloha: no, don't delete it.
[09:26] <Aloha> slytherin, ok
[09:28] <Aloha> slytherin, what should debian/copyright look like if i _am_ the upstream? Can i delete?
[09:29] <man-di> Aloha: debian/copyright must *always* exist
[09:29] <man-di> and habe proper content too
[09:29] <slytherin> Aloha: Nope. It is a must.
[09:29] <slytherin> Aloha: Check my gnusim8085 package for example.
[09:29] <Aloha> man-di, slytherin, ok thnx
[09:36] <Aloha> slytherin, can you have it autogenerate the license or do you have to copy and paste everytime you make a package?
[09:39] <slytherin> Aloha: What do you mean everytime you create a package. You can take copyright file from previous version of package can't you?
[09:39] <Aloha> slytherin, yeah i guess i mean a package for a different project
[09:40] <persia> Aloha: debian/copyright is typically hand-generated for each new packaging effort.
[09:40] <Aloha> persia, ok thnx
[09:41] <slytherin> Aloha: It actually depends on license. I think for some standard licenses which are installed by default on Debian systems it is enough to give reference to license. Someone please correct me if I am wrong
[09:42] <persia> slytherin: You are correct, although I think you and I are answering different (and complementary) questions.
[09:43] <persia> Well, mostly.  For GPL/LGPL one is still expected to provide the 4-paragraph license header (although the full text of the license is not required in debian/copyright)
[09:43] <Aloha> cdbs is really compact.... i like it
[09:43] <Aloha> this is my first package using it
[09:44] <slytherin> persia: Yes. But the reason i mentioned this is because I thought Aloha was specifically asking about copy/pasting of license text.
[09:48] <persia> slytherin: Right.  Like I said, we're answering complementary questions :)
[09:49] <Aloha> how do i enable universe in pbuilder?
[09:51] <Aloha> n/m found it
[10:07] <persia> Can anyone think of a good reason to keep pine in multiverse?  We've had alpine since feisty, and it's 1.0 in hardy.
[10:07] <persia> (also, pine only apparently builds on sparc)
[10:09] <Aloha> people still use pine?
[10:09] <persia> Aloha: Not everyone likes mutt enough.
[10:10] <Aloha> when running pbuilder i get the error: cp: cannot stat `./misc': No such file or directory anyone know what might be wrong?
[10:10] <Aloha> its when its trying to copy source file
[10:11] <man-di> Aloha: does the file/dir exist?
[10:11] <persia> Aloha: Pastebing your buildlog.  I suspect it's trying to copy the ./misc file which doesn't exist.
[10:11] <Aloha> why would it try to copy misc. thats not even a file i wrote anywhere
[10:12] <Aloha> i have Section: misc in control maybe thats it
[10:18] <Aloha> persia, http://pastebin.ca/884424
[10:20]  * persia blames something odd with one of pbuilder, the manner in which pbuilder was called, or the environment from which pbuilder was called, and suggests asking someone who uses pbuilder about the issue.
[10:21] <persia> Aloha: Actually, it might be something interesting in your .dsc file or your .changes file.  Do either of them mention ./misc?
[10:23] <Aloha> persia, in my files in.changes i have de055ded38b92bb4bc0101fb1b8e78fb 625 misc extra shakabuntu-surf_0.1-0ubuntu1.dsc
[10:24] <Aloha> persia, you think it could be that misc?
[10:25] <persia> Aloha: I suspect so.  I don't use pbuilder, but I suggest passing it the .dsc rather than the .changes file.  I suspect that will work better (and hope someone else will comment if I am mistaken).
[10:26] <Aloha> persia, oh yeah i guess i should pass itthe dsc heh thats probably my problem
[10:26] <persia> Could anyone point me to a get-orig-source for a .zip repack?  I remember there being a recent REVU candidate that did this splendidly, but I cannot remember the affected package.
[10:30] <Aloha> persia, what do you use to build packages?
[10:32] <persia> Aloha: sbuild
[10:32] <Aloha> persia, is it "better"?
[10:33] <persia> Aloha: Yes, and no.  Would you like a full opinion?
[10:33] <Aloha> persia, sure
[10:33] <TheMuso> lol
[10:34]  * persia suspects Aloha has not previously read a "full opinion" in backscroll :)
[10:34] <TheMuso> persia: No, its because I know how detailed your full opinions can be. :)
[10:34] <Aloha> nope
[10:34] <Aloha> is there a wiki page for it?
[10:35] <persia> OK.  sbuild and pbuilder are the two most popular means of building Debian-format packages in a clean chroot environment.  There are also a number of other tools that can do this, all of which currently have smaller userbases.
[10:35] <persia> Aloha: I only put opinions on the wiki page when I get really tired of typing them.  I don't think I've expressed this one before.
[10:35] <slytherin> persia: Doesn't pine have a license problem? Or I have confused it with something else.
[10:36] <Aloha> i mean a wiki page for sbuild. i can't find any docs on it
[10:37] <persia> sbuild is a derivative of the build system used on the debian autobuilders, customised for ease of use by users, rather than the wanna-build system.  As the Soyuz build system derives from the same source, sbuild tends to have greater bug-compatibility with the Soyuz buildds than pbuilder.
[10:37] <persia> slytherin: Alpine fixed that.  pine is in multiverse because of the licensing: I was thinking about removing it, rather than promoting to universe.
[10:38] <persia> Aloha: I'm not sure.  I usually point people at https://help.ubuntu.com/community/SbuildLVMHowto
[10:38] <Aloha> persia, k thnx
[10:39] <persia> On the other hand, sbuild has many limitations: it expects a fully deployed environment in which to work, and in currently common use, expects the user to have provided these environments as LVM volumes from which a snapshot may be taken.
[10:40] <TheMuso> One of the big plusses for sbuild/schroot/lvm for me, is the eas oe which one can use chroots for testing, and don't have to manually clean up afterwards.
[10:40] <persia> As an alternate tool, pbuilder has the inherent advantage of a slightly different build process, which tends to help reduce the number of packages that would build under sbuild but fail under pbuilder.
[10:40] <persia> TheMuso: pbuilder --login
[10:40] <TheMuso> persia: But thats as a root user.
[10:40] <TheMuso> persia: schroot leaves me as my user.
[10:40] <TheMuso> I'd rather that.
[10:40] <TheMuso> Easier access to home dir as well.
[10:41] <persia> Additionally, pbuilder users tarballs for the chroots, which compress well, allowing many different build target environments.  This comes at the expense of some performance, and a requirement for sufficient /tmp space to complete the builds.
[10:42] <persia> TheMuso: I heard there were pbuilder hooks for bind-mounting /home, and su - $user can do it.  Mind you, I've never been a pbuilder user, so I'm advocating something I neither use nor intend to use.
[10:43] <TheMuso> persia: I never see myself changing, so yeah.
[10:43] <slytherin> persia: Do you think we should also preseed the debconf question for j2sdk1.4 package? It will fix at least batik and the other programs like fop depending on batik.
[10:43] <persia> So, if you have the HD space to spare, and want something that mirrors the buildds, sbuild is closer (although the buildds run a different sbuild than is installed by aptitude install sbuild).  On the other hand, if you have a reasonably large /tmp, want to maintain lots of different build targets, or want to participate in the greater QA effort provided by the alternate build, pbuilder is better.
[10:44] <persia> Further, pbuilder is very slightly easier to set up for those who do not already use LVM or do not have available space in any volume groups.
[10:44] <persia> Aloha: I hope that answers your question about which is "better".
[10:44] <Aloha> persia, gotcha so the question is really "is it better for _me_?"
[10:45] <persia> slytherin: I don't really understand why we have all of j2sdk1.4, sun-java5-jdk and sun-java6-sdk.  Is there value in preserving three different non-free Java implementations, which could be considered three releases from a single upstream?
[10:45] <Aloha> i have no clue how to setup LVM so i'll stick with pbuilder ;)
[10:46] <slytherin> persia: I am in favour of dumping sun-java5. But there are some apps for which java5 or java6 are too new and hence won't build with either of them.
[10:46] <persia> Aloha: Maybe.  Also, your needs may change.  I know of several users who switched from one to the other at various points, for various reasons.  sbuild can also be used without LVM, but it's harder to set up that way (there's not a single script that does all the heavy lifting for you).
[10:49] <persia> slytherin: If there's anything which cannot build with any of sun-java6-jdk, gcj, jikes, or iced-tea, I consider that source in need of porting work.  We try to get rid of old versions of gcc, why not javac?
[10:49] <Aloha> persia, got any docs on setting up LVM?
[10:50] <persia> Aloha: repartition a disk to have some free space (I use 20GB for sbuild, but more is better), and run vgcreate.  man vgcreate for details.
[10:51] <slytherin> persia: true. but this needs discussion. But sun-java5 can go for sure since sun-java6 can cover up for that.
[10:51] <persia> Aloha: After this, the mk-sbuild-lv script in ubuntu-dev-tools should take care of things.
[10:52] <persia> slytherin: I'd suggest a mail to ubuntu-motu@ raising the discussion, referencing the FTBFS issues caused by the lack of the preseeding, and asking for opinions on preseeding vs. porting.
[10:53] <persia> For sun-java5-jdk, if nothing really needs it, file a removal bug.  Just be extra sure nothing really needs it.
[10:54] <slytherin> persia: Don't have access to gmail now. Will do it on weekend in worst case.
[10:55] <persia> slytherin: OK.  As long as it gets in before FeatureFreeze, it should be OK.  I don't suspect that sun-java5-* is considered buggy enough to drop thereafter.
[10:55] <Aloha> whens FeatureFreeze?
[10:55] <geser> Aloha: Feb 14th
[10:55] <persia> 14th February
[10:56] <Aloha> valentines day.. heh ironic
[10:56] <Aloha> is that featurefreeze for hardy?
[10:56] <slytherin> persia: I should just check if there are any hardcoded dependencies on sun-java5-* packages, right?
[10:56] <slytherin> Aloha: yes, of course
[10:56] <persia> slytherin: And hardcoded build-dependencies.
[10:57] <slytherin> persia: How do I check that in an easy way?
[10:57] <Aloha> slytherin, whats featurefreeze mean? no more items added to universe?
[10:57] <geser> slytherin: with grep-dctrl on the Sources file
[10:58] <geser> Aloha: no new features like new upstream versions
[10:58] <dholbach> geser, soren: I just thought it might be better to wait for the MC election to end before I set up the motu-uvf poll to avoid confusion
[10:59] <dholbach> (and also to rename the team to motu-ff beforehand)
[10:59] <persia> slytherin: rep-dctrl -FBuild-Depends sun-java5-jdk -sPackage /var/lib/apt/lists/*hardy_universe_source_Sources is probably a good start
[10:59]  * dholbach will follow up to the thread again
[10:59] <Aloha> geser, so only debian packages?
[11:00]  * persia would like to see the polls at least delayed until after the MOTU Meeting deciding the team name
[11:00] <Aloha> anyone got a wiki page to featurefreeze?
[11:00] <soren> dholbach: Sure. One day extra will not matter much :)
[11:00] <soren> I'm guessing http://wiki.ubuntu.com/featurefreeze
[11:00] <dholbach> persia: ok... good point
[11:01] <dholbach> all the freeze pages are linked from http://wiki.ubuntu.com/HardyReleaseSchedule
[11:01] <Aloha> soren, thnx
[11:01] <slytherin> persia: I guess then we will also need some extra porting efforts. Make list of packages that have hard coded build dependency on sun-java5, check if package builds with GCJ/sun-java6/icedtea and then modify the package accordingly.
[11:01] <dholbach> and in http://wiki.ubuntu.com/CategoryProcess AFAIK
[11:02] <geser> persia: not s/universe/multiverse/? I doubt there are many package in universe build-depending on sun-java.
[11:03] <persia> geser: Right.  This is a case of failure to edit sufficiently when pasting from the grimoire.  I expect soon to find myself trapped between a flood and a horde of brooms.
[11:04] <effie_jayx> I have a knack for really long packages
[11:04] <effie_jayx> grrrrrrrr
[11:04] <Aloha> i didn't know hardy was LTS
[11:08] <effie_jayx> :O
[11:08] <RAOF> superm1: Sorry, I'm not going to finish the gmyth review tonight.  Would you like some comments later, here & now, or on revu? :)
[11:08] <superm1> RAOF, on revu probably more appropriate
[11:08] <LucidFox> How regular are the MC meetings? Weekly or biweekly?
[11:08] <effie_jayx> Err http://archive.ubuntu.com hardy/main man-db 2.5.0-4  404 Not Found [IP: 91.189.88.31 80]
[11:08] <persia> LucidFox: weekly
[11:08] <superm1> i fixed the gnutls/openssl issue up there
[11:08] <RAOF> superm1: Yeah.  I'll paste my current notes there.
[11:08] <superm1> and also cleaned the dependencies a little bit
[11:08] <superm1> thanks
[11:09] <persia> effie_jayx: You likely want 2.5.1 anyway.  Lots of good improvements.
[11:09] <Aloha> woohoo it built
[11:11] <RAOF> superm1: There you go.  Some rough notes/revu questions :)
[11:11] <superm1> RAOF, okay
[11:12] <superm1> some of that stuff was for debugging while building the package, so i'll pull it out
[11:13] <RAOF> superm1: I'll check it again tomorrow (and, since it's a library package, work out whether you need a shlibs file/dh_makeshlibs options).  Goodnight for now!
[11:13] <superm1> night
[11:24] <slytherin> effie_jayx: you should really update your pbuilder every day
[11:25] <dcordero> hi
[11:25] <dcordero> i have problems when i create debdiff alway the first line is something like this:
[11:25] <dcordero> diff -Nru /tmp/cPSsxVmdXJ/hubackup-0.0.7/debian/changelog /tmp/ZTVKssgSJB/hubackup-0.0.8/debian/changelog
[11:26] <dcordero> that use /tmp/ ¿?
[11:26] <dcordero> why?
[11:26] <dcordero> i created it with debdiff previous.dsc new.dsc > new.debdiff
[11:27] <persia> dcordero: Install patchutils
[11:28] <dcordero> it's installed
[11:29] <persia> dcordero: My apologies.  reflex response.  The issue is that you have a new upstream.  You like would find https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff interesting.
[11:30] <persia> Note that this is (again) on the agenda for the MOTU Meeting for this Friday, so that page may become less interesting next week.
[11:31] <dcordero> thanks
[11:43] <persia> I seem to be able to use most of the standard tools (including sbuild) with an orig.tar.bz2.  Are these permitted for upload yet?
[11:45] <kiko> hello hello
[11:45] <kiko> which favorite python packager could help us out with bug 187286?
[11:45] <ubotu> Launchpad bug 187286 in ubuntu "Can't run pywings in ubuntu 7.10" [Undecided,New] https://launchpad.net/bugs/187286
[11:46] <kiko> pywings isn't packaged at all, but it's referred to in print books
[11:46] <kiko> would be nice to have it packaged
[11:48] <persia> kiko: Are you sure you wouldn't like to give it a shot?  If it uses distutils, and is fairly well behaved, it can be incredibly easy.
[11:51] <kiko> persia, hmmm. I have never done it before, but maybe it would be fun. I have a weekend in brasilia..
[11:53] <persia> kiko: Give it a shot this weekend then.  Take a look at the CDBS+distutils section of http://wiki.debian.org/DebianPython/NewPolicy as a hint for rules.  use dch for changelog, borrow from http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html for copyright, and review http://www.debian.org/doc/debian-policy/ch-controlfields.html for the control file.  The rest ought nearly do itself.
[11:54] <kiko> okay then.
[11:54] <persia> Of course, if it's not well behaved, doesn't use distutils, has an odd license, or something else, it might be a little harder :)
[11:55] <kiko> it depends on python2.4, that much I know.
[11:55] <kiko> python2.4 got rid of whrandom (thankfully as it was hideous)
[11:55] <kiko> err
[11:55] <kiko> python2.5 did
[11:55] <persia> Not working with python2.5 is one of the things that can easily make it harder.
[11:55] <kiko> there is a great flow to that sentence
[11:57] <tbutter> anyone would like to give http://revu.tauware.de/details.py?package=jodviewer a review?
[12:01] <sistpoty|work> hi folks
[12:01] <persia> kiko: You can look at my crude hack to the gaphor package if you want an example of how to make something python2.4 only.  There may be cleaner ways. http://patches.ubuntu.com/g/gaphor/gaphor_0.12.5-1ubuntu1.patch
[12:02] <kiko> thanks for the hints persia
[12:03] <Hobbsee> gasp!  kiko is in here?
[12:03]  * kiko threatens Hobbsee with a flower
[12:04] <persia> Hobbsee: kiko is planning to join the list of hardy contributors this weekend, with a brand new python package :)
[12:04] <kiko> I wonder if that expression exists in english
[12:04] <Hobbsee> kiko: not really
[12:04]  * Hobbsee attacks kiko with a carrot in return
[12:04] <kiko> crappy unromantic language
[12:05]  * mok0 wonders about the vegetarian warfare
[12:05] <persia> mok0: There's a shortage of mammoth femurs about these days
[12:06] <mok0> persia: they became extinct for their handy femurs
[12:06] <Hobbsee> whos' doing the mentoring stuff again?  is that persia?
[12:06] <persia> No.  That's MOTU Mentoring Reception.
[12:07] <Hobbsee> that's what i meant
[12:07] <Hobbsee> i think, anyway
[12:07] <slytherin> dcordero: It is not a problem. Debdiff always has that format
[12:08] <slytherin> oops, checking old conversation
[12:08] <persia> slytherin: It shouldn't include /tmp.  Either it's something for which we don't typically want a debdiff, or the patchutils package isn't installed.
[12:08]  * persia dislikes running patch -p4
[12:08] <dcordero> slytherin, but with that format when you apply the debdiff always ask you about what file need to patch :/
[12:09]  * Hobbsee still occasionally tries to run patch with reverse numbers.
[12:09] <slytherin> persia: Ahh, right. patchutils is missing
[12:09] <dcordero> but i have patchutils installed
[12:09]  * Hobbsee prefers the good old throwing back of a patch, with a "fix your patch please, so that it can actuallyb e applied, setting the bug to incomplete, then waiting till the person whines at me about it being fixed
[12:10]  * slytherin time for a gutsy -> hardy upgrade on office machine. :-)
[12:10] <persia> dcordero: Yes, but you're running a debdiff against a new upstream.  I don't want to look at the upstream patches when I'm looking at your work.
[12:11] <dcordero> ok, so, always that a newstream is created is needed a interdiff isn't it?
[12:14] <persia> dcordero: For now.  We've been discussing changing that for a while, but will very likely continue to support interdiff at least until FeatureFreeze, at which time new upstreams will be harder to submit.
[12:17] <persia> vemon: whysynth commented.  Please update soonest and ping me: this enables a feature goal for me (and I'll start work on it based on the last candidate, expecting you can finish the packaging).
[12:28] <vemon> persia, should the misc:Depends be added to source or ibinary deps?
[12:28] <persia> vemon: binary
[12:32] <RainCT> Hi :)
[12:32] <geser> Hi RainCT
[12:32]  * persia wonders why automatix is still around.  What is left that can be absorbed to make it less appealing?
[12:33] <Hobbsee> persia: the ability to kill -9 dpkg.
[12:33] <Hobbsee> :)
[12:34] <persia> Hobbsee: I know that was removed for gutsy.  It is now just a medibuntu competitor?
[12:34] <Hobbsee> i've no idea
[12:34] <Hobbsee> persia: did we ever get the source, to check it out?
[12:34]  * persia wonders if anyone feels like finding out.
[12:34] <persia> Hobbsee: It was scripts.  The "binaries" weren't entirely.
[12:35] <Hobbsee> right, true
[12:35] <dcordero> It's normal dont have a original diff.gz when you do a apt-get source. I have read the manual of interdiff and always says you have to have got it
[12:35] <RainCT> saivann: have you already fixed those points I told you yesterday? :)
[12:35] <persia> dcordero: You should really have a diff.gz.  Which package?
[12:35] <dcordero> persia hubackup
[12:35] <RainCT> dcordero: it hasn't one as it's a native package
[12:36]  * persia dislikes native packages harder
[12:36] <dcordero> aham
[12:36] <persia> dcordero: Right.  There's no good solution beyond debdiff -p4.  Go find the original maintainer, and push to the VCS.  If there isn't one, beat them with a stick, and submit the ugly debdiff to the sponsors queue.
[12:38]  * persia fails to see anything particularly Ubuntu-specific in the hubackup long description
[12:39] <RainCT> persia: the author hasn't released any tarball
[12:39] <RainCT> persia: or at least that's whay I could figure out yesterday when I looked at it..
[12:40] <persia> RainCT: Now I'm confused.  Is there an upstream that hasn't done a release (so we have 0.0~0ubuntu7), or is it native (so the Ubuntu package is the release)?
[12:41] <RainCT> persia: the versioning indicates a native package ("0.0.7")
[12:41] <RainCT> and indeed it has no .diff.gz
[12:42] <persia> RainCT: My apologies then.  I thought you'd dug into it a bit more then.  Anyway, I look forward to 0.1-0ubuntu1 when it can become available.
[12:42] <persia> d/then/2
[12:45] <Hobbsee> persia: hubackup's in bzr, last i knew.
[12:45] <Hobbsee> sivang should be able to tell you
[12:45]  * persia thought it might be, hence the earlier bit about the VCS or the stick
[12:46] <RainCT> dcordero: the dh_install for the SVG should be in the "install:" part, no in "binary-indep:"
[12:47] <RainCT> dcordero: and.. did you remove the dh_install for the .desktop?
[12:47] <dcordero> i think that is done but dh_desktop
[12:48] <dcordero> by*
[12:49] <RainCT> dcordero: no, dh_desktop doesn't install it, sorry if I didn't explain it clearly (actually I'm not even sure what it really does, but it does something :P)
[12:49] <janimo> anyone knows what the problem can be with the rejection of a package uploaded for the first time:
[12:49] <janimo> Unable to identify file sugar-artwork_0.40+git20080130.orig.tar.bz2 (x11) in changes.
[12:49] <janimo> Further error processing not possible because of a critical previous error.
[12:49] <RainCT> dcordero: all those dh_* commands have manpages, if you want to read more about them
[12:49] <janimo> is orig.tar.bz2 not an allowed format?
[12:49] <soren> janimo: Not quite yet, afaik.
[12:49] <persia> Should gconf schemas be put in /etc/gconf/schemas or /usr/share/gconf/schemas?
[12:50] <janimo> soren, thanks. So only tar.gz
[12:50] <soren> janimo: I believe lamont was working on it a few days ago. I'm not sure when it's scheduled to happen.
[12:51] <janimo> soren, ok I'll just convert the upstream bz2 tarballs
[12:51] <RainCT> persia: I've 180 files in /etc/gconf/schemas (and /etc/gconf/schemas doesn't exist) here
[12:51] <RainCT> sorry
[12:51] <soren> RainCT: heh
[12:51] <RainCT> persia:  180 files in /usr/share/gconf/schemas I mean :P
[12:52] <persia> RainCT: That's a good enough answer for me.  I've 15 files in /etc/gconf/schemas, which packages may need rebuilds or more.  Thanks.
[12:52] <RainCT> Np :)
[12:54] <persia> gpocentek: Any issues with a rebuild of gnome-translate for gconf & libeel?
[12:55] <slytherin> is there any rebuild going to happen before feature freeze?
[12:56] <persia> slytherin: Not in an automated fashion.  Packages must be manually updated.
[12:56] <persia> slytherin: Note that rebuilds aren't considered feature additions, so rebuilding to fix bugs post-feature-freeze isn't a problem.
[12:56] <slytherin> ok
[12:57] <persia> From my understanding, FeatureFreeze mostly means: No new upstreams, no significant changes to functionality, and no new packages.  It certainly doesn't mean no more work, and many of the activities we do today continue.
[12:58] <slytherin> persia: By the way, AFAIK, doko was working with Debian guys to get icedtea in Debian. Do you have any idea on what is the status?
[12:59] <persia> slytherin: No idea at all.  Sorry.
[13:00] <slytherin> persia: As of now it looks like if we build lucene2 with icedtea then that change can not go in Debian.
[13:02] <persia> slytherin: That's fine.  I want lucene2 in universe for hardy (which means in the next two weeks), so am willing to put up with some deviation from Debian.  I suspect that we can drop that patch for the next cycle, as Debian ought have either icedtea or openjdk working by then.
[13:02] <slytherin> :-)
[13:02] <slytherin> persia: I have debdiff ready
[13:03] <persia> The big issue is that for Ubuntu, primary support is only for three architectures, whereas Debian cannot count the number of architectures on two hands, and has a lot more porting work to do.
[13:03] <persia> slytherin: Does it differ much from Marek's?
[13:03] <slytherin> persia: I didn't check. Where is his debdiff?
[13:05] <persia> slytherin: Posted to bug #185917
[13:05] <ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
[13:07] <\sh> grmpf.
[13:07] <\sh> moins
[13:07] <slytherin> persia: will check and let you know. Currently dist-upgrade in progress. :-)
[13:08] <\sh> effie_jayx, just to tell you, that I was touched by shlibdeps as well in last wine upload...
[13:08] <\sh> effie_jayx, the same issue as you had with kdepim-kresources ;)
[13:08] <effie_jayx> \sh,  did you go around it ?
[13:09] <effie_jayx> I bet it was no cdbs and you could do it
[13:09] <\sh> effie_jayx, I'm trying to now...just preparing something which could help...need some test builds before
[13:09] <\sh> effie_jayx, well, it's debhelper style but the same situation :)
[13:09] <effie_jayx> \sh,  the bug I was working on was invalid
[13:10] <\sh> well, too much to do , too less time
[13:14] <slytherin> persia: He submitted diff.gz an not debdiff. :-P But a quick looks tells that it doesn't have the w3c-dtd-xhtml build dependency, has some get-orig-source mechanism, hard coded icedtea jre runtime dependency and homepage in decription.
[13:16] <persia> slytherin: Right.  Better yours then.  I just wanted to make sure he got a fair review rather than his submission being ignored.  Thanks for checking.
[13:27] <RainCT> dcordero: have you tried if it works if you install it?
[13:35] <dcordero> RainCT,  yep i have
[13:38] <RainCT> dcordero: okay. I've just noticed, why do you add a .desktop file if it's already installing two? (those in build/)
[13:40] <RainCT> dcordero: modify those instead (just edit them directly, as it's a native package it needs no patch system) to add the Icon=hubackup
[13:40] <RainCT> (and update them to the newest standards on the way, like removing Encoding=)
[13:41] <RainCT> dcordero: also, in the changelog leave an empty line before the first point (like in all other entries there), and add "(LP: #43337)" to the line about the icons (to let Launchpad automatically close the bug)
[13:48]  * RainCT will be back in 2-3 hours
[13:55]  * slytherin will be back after a reboot
[13:58] <DktrKranz> persia: I encountered bug 146182. It seems model-builder requires wxwidgets2.6 but we have 2.8. IIRC, there have been similar issues, I don't remember how we fixed them, though.
[13:58] <ubotu> Launchpad bug 146182 in model-builder "PyMB (model-builder) crashes on startup" [Undecided,New] https://launchpad.net/bugs/146182
[14:00] <_MMA_> siretart: Do you know if bug 182773 will get some love?
[14:00] <ubotu> Launchpad bug 182773 in warsow "Warsow version is outdated." [Undecided,New] https://launchpad.net/bugs/182773
[14:00] <ScottK> DktrKranz: We also have 2.6
[14:00] <siretart> _MMA_: in what ways?
[14:00] <ScottK> DktrKranz: You might have a look at recent changes made in spe (SRU) to not go for a later wx than the one it wants.
[14:01] <DktrKranz> ScottK: right, but it prefers 2.8 since it depends on python-{wxtools,versions}, which is greater than those in 2.6
[14:02] <DktrKranz> ScottK: ah, good point. Thanks!
[14:02] <ScottK> spe had the same problem (IIRC).
[14:03]  * DktrKranz kicks at himself since it was me who manage spe SRU upload
[14:04] <ScottK> Should make is easy then ...
[14:04] <_MMA_> siretart: .40 is out. You handle games sometimes right?
[14:04] <DktrKranz> oh, looking again at spe, it's time to have it verified...
[14:07] <saivann> RainCT : ping
[14:08] <siretart> _MMA_: see the related debian bug report
[14:08] <geser> saivann: [14:48:14]             -*- RainCT will be back in 2-3 hours
[14:08] <saivann> geser : Thanks
[14:14] <_MMA_> siretart: Ok so .040 looks like a no-go but the warsow guys are supposed to get things in line for .041. Am I reading that right?
[14:15] <ryanakca> if I have a .desktop file in debian/ , do I need to add anything to debian/rules to install it?
[14:18] <freeflying> ryanakca: cp
[14:19] <ryanakca> freeflying: okies, thanks
[14:19] <freeflying> welcome
[14:21] <ryanakca> freeflying: and I also assume that I'd need to add the reversen to clean/basic256:: ?
[14:21] <freeflying> ryanakca: no
[14:22] <ryanakca> ok. so, if I copy the binary from $(CURDIR)/basic256 to $(CURDIR)/debian/basic256/usr/bin/basic256 , I don't need a rm rule for it either?
[14:28] <freeflying> ryanakca: yes, the clean rule will rm all the tmp dir in debian
[14:31] <dcordero> RainCT, i think that a packager never can touch the original "code" what is why i create my own .desktop
[14:32] <ScottK> RainCT: Congratulations if I didn't say it already (I've lost track).
[14:32] <geser> dcordero: sure it's allowed to touch upstream code. sometimes even necessary
[14:32] <geser> dcordero: why not simply patch the upstream .desktop file?
[14:35] <slytherin> I just updated to hardy. Why does synaptic show firefox as local package?
[14:35] <ScottK> slytherin: #ubuntu+1
[14:41] <Ng> quick question about .desktop files - am I right in thinking that blank translations are a really bad thing? (in that they'll present the user with blank menu items instead of falling back to the default)?
[14:42] <devilsadvocate> hi.. is there any workaround if i cant get dput to work behind my proxy (http, squid, with authentication)
[14:42] <soren> Ng: I wouldn't be surprised if that was the case.
[14:44] <Ng> soren: I have a bug report suggesting it is ;/
[14:45] <Ng> pretty silly of the menus, but whatever, I'll fix appropriately :)
[14:46] <bddebian> Heya gang
[14:50] <proppy> oy
[14:51] <devilsadvocate> hm, let me rephrase - has anyone had any luck getting dput to ork with revu behind a proxy?
[14:53] <slytherin> devilsadvocate: did you try setting proxy config from System->Preferences->Proxy?
[14:53] <ScottK> devilsadvocate: REVU just uses http, so the proxy shouldn't have any REVU specific effects.
[14:53] <jdong> dget uses curl and wget, both of which should respect HTTP_PROXY
[14:54] <devilsadvocate> I've se the proxy in the gnome settings and exported http_proxy as well as ftp_proxy on the terminal in question
[14:55] <devilsadvocate> cursory googling suggests that revu only allows ftp (as opposed to ftp, rsync, etc), although those posts seemed to be slightly dated
[14:55] <devilsadvocate> wget works fine (with http_proxy)
[14:55] <devilsadvocate> i've never used curl ...
[14:56] <geser> Hi bddebian
[14:56] <devilsadvocate> i've never used dput before, on any other server, so i dont know if the effect os revu-specific
[14:58] <Adri2000> bug #184866 < does it look like an apport reported bug? I don't understand the dependencies output. eg. libwxgtk2.8-0 2.8.4.0 has never been in the archive... or is it 2.8.4.0-0ubuntuX truncated?
[14:58] <ubotu> Launchpad bug 184866 in filezilla "Filezilla receives an X Window System error at launch" [Undecided,New] https://launchpad.net/bugs/184866
[14:59] <devilsadvocate> "Connection failed, aborting. Check your network (-2, 'Name or service not known')" is the exact error I get, soo after it says it is sending the file (via ftp)
[15:01] <bddebian> Heya geser
[15:02]  * bddebian hugs geser for being the only one that still says Hi to him.. ;-)
[15:03] <tbutter> devilsadvocate: did you try to set FTP_PROXY ?
[15:03] <paas> Hi, anybody in the mood to look at my first attempt of packaging a shared library? http://revu.tauware.de/details.py?upid=1603
[15:05] <geser> Adri2000: For me it doesn't look an apport generated bug and I'd also say that the libwxbase2.8-0 isn't truncated (the others aren't either, so why here)
[15:06] <devilsadvocate> tbutter, yes, i did
[15:07] <Adri2000> geser: so that user would be using wxwidgets2.8 packages coming from we-don't-know-where?
[15:07] <devilsadvocate> does anyone use dput behind a proxy, so that i can figure out if its a problem on my computer itself or if dput cannot handle this?
[15:09] <tbutter> devilsadvocate: it seems dput uses python ftplib and i can't find any reference that it supports proxies
[15:09] <devilsadvocate> tbutter, so a fix must potentially come from as far upstream as python  ftplib?
[15:10] <Adri2000> geser: I found it. it's the output of apt-cache showpkg. and I have exactly the same
[15:10] <tbutter> devilsadvocate, i did not read the source so i am not sure. dputs ftp code is in /usr/share/dput/ftp.py and it does not have any special proxy handling
[15:11] <devilsadvocate> tbutter, I'll look into it. thanks for the pointer
[15:11] <\sh> Seveas, ping would you like to do me a favour and tell ubotu to join #ubuntu-wine :)
[15:12] <\sh> ftplib doesn't have proxy support looks like
[15:12] <\sh> pydoc ftplib doesn't have any reference
[15:12] <devilsadvocate> tbutter, a little dev question - if i modify /usr/share/dput/ftp.py and then run dput again, the changes should be reflected in the program right?
[15:13] <Adri2000> geser: actually the versions are those from Depends:, not those of the packages installed... I understand it better now :)
[15:13] <ScottK> devilsadvocate: Yes.
[15:13] <devilsadvocate> \sh , tbutter  -  http://mail.python.org/pipermail/python-list/2004-October/288418.html
[15:13] <devilsadvocate> ScottK, thanks
[15:14] <devilsadvocate> i would say ftplib doesnt have proxy support
[15:14] <\sh> devilsadvocate, yes...that's a normal way of connecting ot real site via a proxy
[15:15] <\sh> devilsadvocate, with a ftp client...this should work as well with dput...saying ftp host= <proxy server> username: anonymous@ftp.ubuntu.com or whatever...but this depends as well on your used ftp proxy software
[15:15] <devilsadvocate> that makes it a littletroublesome if the proxy requires authentication of its own ..
[15:15] <devilsadvocate> ok. i'll try to see if i can setup some form of workaround
[15:33] <slytherin> Currently ant has a Depends - java-gcj-compat-dev | java-virtual-machine. Shouldn't it be java-gcj-compat-dev | java2-compiler ?
[15:34] <man-di> slytherin: it should be java-gcj-compat-dev | java2-runtime currently
[15:34] <mok0> wtf does dpatch change the mode of the .dpatch files?
[15:34] <man-di> java2-compiler stands for a compiler without runtime and class library
[15:35] <mok0> damned annoying
[15:36] <slytherin> man-di: Really. But sun-java5-jdk, sun-hava6-jdk and gcj all provide package java2-comiler
[15:37] <man-di> slytherin: I'm working on a proposal to fix this mess once and forever
[15:37] <slytherin> man-di: Thanks. :-)
[15:38] <slytherin> man-di: I understood what you meant by compiler without runtime. You are referring to jikes and kaffe, right?
[15:39] <man-di> jikes, kcj, javac, ecj
[15:39] <man-di> javac as in (a simple java compiler related to nothing else)
[15:40] <frafu> RainCT: thanks for your review of mousetweaks. In your first comment, I suppose that the package has to close the need packaging bug of mousetweaks!? Could you please confirm? http://revu.tauware.de/details.py?upid=1586
[15:41] <LucidFox> frafu> Yes, file a needs-packaging bug if one already doesn't exist, and close it in the changelog
[15:41] <LucidFox> by using the (LP: #xxx) notation
[15:42] <frafu> LucidFox: thanks
[15:42] <rulus> Can someone have a look at gtkvd (http://revu.ubuntuwire.com/details.py?package=gtkvd)? It should be ready for advocation :) Thanks!
[15:44] <LucidFox> Gah, and I won't even be able to apply for MOTU until after the last REVU day :(
[15:46] <RainCT> frafu: indeed
[15:46]  * RainCT is back
[15:52] <frafu> RainCT: And concerning the priority, it should be optional instead of extra. Correct? (I interpreted the "special requirements" in the debian policy with regard to the user, and not with regard to other software).
[15:52] <RainCT> frafu: probably
[15:54] <Coper> Hi can someone look at http://revu.ubuntuwire.com/details.py?package=console-freecell Thanks.
[15:54] <frafu> RainCT: ok; thanks again for the review
[15:54] <RainCT> frafu: thanks for packaging it :)
[16:11] <siretart> sistpoty|work: 'root@sparky:/srv/revu-production# bzr st' is now 'clean'. "bzr merge --uncommitted" works exactly as I expected :)
[16:11] <sistpoty|work> siretart: excellent. Thanks a lot!
[16:11] <saivann> RainCT : ping
[16:11] <sistpoty|work> siretart: will try this tonight or tomorrow evening :)
[16:11] <RainCT> saivann: pong
[16:12] <siretart> sistpoty|work: just remember to never commit in /srv/revu-production. you may edit and pull changes in only
[16:12] <saivann> RainCT : Hi, I worked on the point you told me to fix yesterday, it's on REVU
[16:12] <saivann> RainCT : http://revu.tauware.de/details.py?package=simdock
[16:12] <sistpoty|work> siretart: ok, will obey this
[16:27] <gouki> Can anyone point me to information about the repositories? Number of packages, what software is used to create the repositories... ?
[16:28] <frafu> Could anybody please review mousetweaks: http://revu.tauware.de/details.py?upid=1604  It would be great if it makes it into hardy as the corresponding gui will be in hardy. (a11y tab of the mouse control panel)
[16:32] <saivann> gouki : What do you mean, you want to create a repository on your personnal computer?
[16:33] <sistpoty|work> gouki: you can find out about the number of packages by the packages files under /var/lib/apt/lists (just do a cat source_section-arch_Packages.list | grep Package: | wc -l)
[16:33] <sistpoty|work> that should at least give you an estimation
[16:33] <crimsun> Launchpad also exposes it, e.g., https://launchpad.net/ubuntu/hardy
[16:34] <gouki> Thanks all. That should do it.
[16:35] <gouki> Nice.
[16:36] <tuxmaniac> bddebian, those scripts are necessary to set the environment variables.
[16:41] <RainCT> saivann: have you tried installing the .deb?
[16:45] <RainCT> saivann: W: simdock: spelling-error-in-description Gnome GNOME
[16:46] <saivann> RainCT : Is that what you get when you try to install it?
[16:47] <RainCT> saivann: no, that's what I get if I let lintian check the .deb :)
[16:47] <tuxmaniac> http://paste.ubuntu-nl.org/54074/ can someone give me a hint as to what the problem could be on those lintian warnings, the line numbers mentioned seem to be OK for me
[16:48] <saivann> RainCT : Let me check..
[16:49] <saivann> RainCT : I've installed simdock on Gutsy and Hardy before we changed some details in the package and it was working great, but I'm testing it again now
[16:50] <RainCT> tuxmaniac: perhaps there's some special character on line 13
[16:52] <saivann> RainCT : I don't have that error when I run lintian against the binary deb or the dsc file, what does that error means?
[16:53] <RainCT> saivann: probably because you have an older version (I use lintian and linda from Hardy). Well, it means that "Gnome" should be "GNOME", as that is the official spelling :P
[16:54] <saivann> RainCT : In the control file?
[16:54] <crimsun> yes, in the control file (and/or its template)
[16:55] <RainCT> saivann: yes, in the description. but this isn't that important... tell me once you finished checking if the .deb works right and I'll advocate :)
[16:57] <saivann> RainCT : I've found that linda says that my standard-version in the control file is wrong, I used 3.7.3, should it be 3.7.2?
[16:57] <RainCT> saivann: no, 3.7.3 is right. linda is outdated (there is no version for 3.7.3 yet)
[17:01] <RainCT> saivann: ah btw, if you later change the description, "( like OS X )" should be "(like OS X)"
[17:01] <saivann> RainCT : Great, I just tested simdock on Hardy within virtualbox and in Gutsy. In Hardy, I get a error message saying that the background image is missing ( it seems to be a problem with the alpha 3 release, the background image is indeed missing ), unless that error message, simdock appears and works
[17:01] <saivann> RainCT : On Gutsy there's no problem at all
[17:02] <saivann> RainCT : I can update the description of (like OS X) and GNOME
[17:03] <RainCT> saivann: okay. ping me once the new upload is in REVU
[17:04] <saivann> RainCT : Ok, it's uploaded, I'll ping you once it will appear in REVU
[17:13] <RainCT> saivann: Advocated :)
[17:14] <saivann> RainCT : Thanks very much for your help and your guidance :)
[17:15] <DRebellion> Hi, i'm having some trouble building a source package using debuild. Pasted: http://pastebin.ubuntu-nl.org/54076/
[17:15] <saivann> RainCT : Should I do something else on this or MOTUs will do the next steps?
[17:15] <RainCT> saivann: you still need to fins a second advocate, and he will upload it if he's happy with your package too.
[17:16] <saivann> RainCT : Ok thanks
[17:16] <RainCT> Anyone up for reviewing saivann's package (http://revu.tauware.de/details.py?package=simdock)?
[17:17] <dcordero> RainCT, i have problems changing the .desktop file in build directory, if i do that, everytime that i try to execute debuild. Automately the .desktop files on build/ are downgraded to the original status.  I dont know why
[17:17] <RainCT> saivann: np, thank *you* for contributing to Ubuntu :)
[17:18] <tuxmaniac> RainCT, but doing a nroff, generates the man page cleanly
[17:18] <saivann> RainCT : It's always a pleasure to do so :) I love ubuntu
[17:22] <DRebellion> Fixed problem by changing urgency= in changelog.
[17:26] <yamal> http://revu.tauware.de/details.py?package=sabnzbdplus is looking for reviewers; package should be in quite reasonable shape by now.
[17:28] <RainCT> frafu: «Newest version on remote site is 2.21.90, local version is 2.21.5»
[17:29] <frafu> RainCT: yes, I know, but I was told by another motu to continue with the 2.21.5 version in revu
[17:30] <\sh> hmm..what happend to virtualbox-ose-modules on amd64?
[17:31] <RainCT> frafu: oh.. why?
[17:31] <dcordero> RainCT, sorry i have just found the problem, thanks anyway
[17:31] <RainCT> dcordero: nice, what was is it?
[17:32] <frafu> RainCT: to quote him: " By the way, I would suggest waiting till the package has ben uploaded to the archive, before attempting to get the latest version included. a lot less work that way."
[17:32] <dcordero> RainCT, the original .desktop file are create from a file.desktop.in when the package is compile
[17:32] <dcordero> i had to change the desktop,in file
[17:32] <frafu> RainCT: Or did I get him wrong?
[17:35] <RainCT> frafu: hm.. I don't see how it would make more work. and don't updating it now would mean needing to get it sponsored twice (and FeatureFreeze will soon be here).
[17:35] <geser> \sh: grab them from LP if you don't want to wait till they get NEWed
[17:36] <frafu> RainCT: sponsored twice? what do you mean?
[17:36] <RainCT> frafu: get two advocates in REVU for the current version, and then get another sponsor in LP for the update
[17:38] <frafu> RainCT: In what sense is launchpad involved (apart the need-packaging bug)?
[17:39] <RainCT> frafu: for updating 2.21.5 (once it's in the repos) to 2.21.90
[17:40] <frafu> RainCT: I will package the new version
[17:40] <paas> Hi, I was wondering about the procedure now that I've updated my package to REVU. Should one just wait or should one periodically ask for reviewers on this channel. By the way my package is over herehttp://revu.tauware.de/details.py?package=libtuxcap, :-) thanks
[17:40] <RainCT> frafu: cool. do you know how to do it? (well, just let 'uscan' download the new version and copy the debian/ directory you created there)
[17:44] <frafu> RainCT: but the patches and the manpages in debian are already in the 2.21.90 and running uscan (when I fixed the watch file) did not remove the patches and the manpages in debian. Do I have to remove them manualy?
[17:45] <RainCT> frafu: yes, uscan won't do any change to debian/. you have to copy it into the directory it created and adjust it for the new version manually
[17:47] <sistpoty|work> paas: basically just wait... however being around and asking from time to time might motivate some reviewers ;)
[17:50] <paas> sistpoty: hehe, ok I get it ;-) thanks
[17:50] <sistpoty|work> np
[17:50] <frafu> RainCT: The new version will not need dpatch anymore; can I leave dpatch the rules file even if it is not needed anymore?
[17:51] <RainCT> frafu: sure
[17:52] <frafu> RainCT:  I will give it a try;
[17:54] <Lure> if I am original packager and set Maintainer to my ubuntu.com address, do I still need to update-maintainer?  https://wiki.ubuntu.com/DebianMaintainerField does not say anything about this
[17:54] <Lure> and I get this warning "dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field" when packaging
[17:54] <sistpoty|work> Lure: imho you don't need to do this (would be strange to have xsbc-orig-maintainer==maintainer)
[17:55] <Lure> sistpoty|work: same feeling here (even though Maintainer would be MOTU list, while Original would be me with u.c address)
[17:56] <Lure> sistpoty|work: but then why we have that warning?
[17:56] <sistpoty|work> Lure: well, imho you can list yourself as maintainer to indicate that *you* know the package best
[17:57] <sistpoty|work> Lure: for the warning, I guess only looking at dpkg-source will give the information ;)
[17:57] <Lure> sistpoty|work: I am actually fine going any way, I would just like to know what is expected (not to get some complaint when may package reaches archive)
[17:58] <sistpoty|work> Lure: if the package is buildable as is, there won't be problems just for the maintainer field ;)
[17:59] <tuxmaniac> can someone help out with a second pair of eyes for this package http://revu.tauware.de/details.py?package=alliance
[17:59] <geser> Lure: it's probably to hard to determine if you missed the XSBS-O-M or if you don't need it
[18:00] <Lure> geser: ok, I will probably do update-maintainer just to get rid of dkpg-source warning
[18:01] <Seveas> ubotu, join #ubuntu-wine
[18:01] <Seveas> \sh --^
[18:11] <frafu> RainCT: will dpatch make problems if I remove the whole patches directory in debian, or do I have to leave the patches directory with an empty 00list file?
[18:11] <RainCT> frafu: I'm not sure but I don't think that it will complain
[18:13] <frafu> RainCT: I will try and see
[18:13] <tuxmaniac> frafu, the patches will have to be in debian/patches directory
[18:15] <frafu> tuxmaniac: I am upgrading a package to the new release and the patches are not needed anymore...
[18:16] <tuxmaniac> frafu, then I think you can completely drop patches folder. not sure again
[18:16] <RainCT> is any ~compiz guy around?
[18:17] <frafu> tuxmaniac: ok
[18:17] <crimsun> Amaranth: ^
[18:18] <frafu> I will be back in about an hour
[18:18] <Amaranth> RainCT: What's up?
[18:19] <Kopfgeldjaeger> hi
[18:21] <RainCT> Amaranth: it seems that there's already emerald 0.6, is there any reason why hardy still has a 0.3 snapshot?
[18:21] <Amaranth> RainCT: None of us really care about emerald, I guess
[18:22] <RainCT> Amaranth: ah, great :P
[18:23] <Amaranth> I accept bzr branches :P
[18:23] <vemon> hmm. my pbuilder thinks that libcurl3 is unavailable to "apt-get". i wonder what wrong
[18:23] <vemon> it seems to be in the repositories
[18:24] <RainCT> Amaranth: I'm branching :)
[18:24] <RainCT> btw, do updates need an advocate from another MOTU or does this only apply to new packages?
[18:25] <crimsun> vemon: which release?
[18:26] <geser> RainCT: only new packages need an other ACK, updates (like new upstream version) can be uploaded directly
[18:26] <nixternal> OK, I will put to rest the myth about "Vitamin C and fighting colds"!
[18:27] <nixternal> OK, I will also make sure that I post what I am saying in the correct window too :p
[18:27] <RainCT> geser: thanks
[18:28] <RainCT> omg.. how can I checkout from git? :P
[18:28] <geser> RainCT: nobody stops you from asking for other opinions as you should fix what you break :)
[18:28] <zul> nixternal: i hear beer works good for that
[18:29] <nixternal> I don't even want to think about beer
[18:29] <tuxmaniac> anybody game for reviewing / advocating http://revu.tauware.de/details.py?package=alliance
[18:29] <nixternal> I have been so ill for the past week...I have spent a good 75% of the last week in bed
[18:30] <crimsun> I'm taking a sick day myself, hence my overactivity on IRC.  :-)
[18:30]  * sistpoty|work only gets sick from looking at his code
[18:31] <Kopfgeldjaeger> *updating xmoto package to 0.4.0*
[18:32] <nixternal> crimsun: ya, 2 lines in IRC today for you is definitely overactivity :p
[18:32] <nixternal> I am up to a gallon of OJ a day now
[18:32] <nixternal> I have gone from not liking OJ to absolutely loving it
[18:33] <nixternal> I wonder if that will work with brussle sprouts too :p
[18:38]  * Seveas feeds nixternal a gallon of sprouts
[18:38] <Seveas> nixternal, they're good with madeira sauce and grilled potatoes
[18:38] <nixternal> it is hard for me to believe they are good, but grilled tators sound good to me :)
[18:38] <nixternal> madeira sauce, don't know if I have ever tried it before
[18:39] <nixternal> but anything to mask the taste of them I am sure is an improvement :)
[18:39] <\sh> Seveas, did you get my question some hours ago? :)
[18:41] <Seveas> \sh, about ubotu ?
[18:41] <\sh> Seveas, yepp
[18:41] <Seveas> scroll a bit back :)
 ubotu, join #ubuntu-wine
 \sh --^
[18:41] <\sh> Seveas, hmm...didn't work ;)
[19:06]  * LaserJock grows to dislike Multiverse more every day :-)
[19:06] <sistpoty|work> he
[19:07] <sistpoty|work> +h
[19:07] <LaserJock> these packages don't originate from Debian
[19:07] <LaserJock> and I'm switching "upstreams" whose packaging is completely different
[19:08] <LaserJock> I need to remove 3 packages and add in like 5
[19:08] <sistpoty|work> nice
[19:08] <LaserJock> yeah, and some of the new source packages build binaries with the same name as the old old source package
[19:08] <LaserJock> it's a little confusing
[19:09] <crimsun> I don't think an archive removal is necessary.  See what the Kubuntu guys did to handle KDE 4.
[19:09] <LaserJock> and then I'm gonna try to do some sort of debconf/postinst thing to migrate people
[19:09] <crimsun> However, I did not follow it extremely closely, so there's a good chance I simply didn't see some sort of removal.
[19:10] <LaserJock> well
[19:10] <LaserJock> is it ok for 2 different source packages to build the same binary?
[19:10] <LaserJock> I imagine not
[19:11] <crimsun> "ok" or recommended?
[19:11] <geser> LaserJock: the binary package with the higher versions wins
[19:11] <crimsun> it's perfectly "ok" but not recommended for trivial lack of clarity
[19:12] <geser> it had happened in the past already the two source package build the same binary package
[19:12] <LaserJock> hmm
[19:12] <LaserJock> I would have thought that wouldn't have been allowed
[19:12] <crimsun> it's perfectly allowed.  Keep in mind that you can Conflicts.
[19:12] <ScottK> LaserJock: You might look at what viewvc/viewcvs did in Gutsy.
[19:12] <LaserJock> well yeah, I'd just need it around until I remove the old packages
[19:13] <RainC1> dcordero: you don't need to dh_install the manpages (that's already done by setup.py, which is called above) and please modify your changelog entry ("Added .desktop file" => "Fixed .desktop files") and move the (LP: #xxx) to the point about he icon
[19:15]  * sistpoty|work needs to head home
[19:15] <sistpoty|work> cya
[19:16] <LaserJock> is anybody gonna cry if I don't put these package on REVU?
[19:16] <crimsun> I doubt it.
[19:17] <crimsun> (Recommending things is easier when the source package is available, however.)
[19:23] <\sh> preparing drupal5.7
[19:24]  * LucidFox is still waiting for somebody to package tomcat6 :(
[19:26] <\sh> -ENOJAVA4ME :)
[19:28] <dcordero> RainCT,  ok
[19:29] <\sh> geser, http://lists.gnupg.org/pipermail/gnupg-devel/2008-January/024232.html :) cjwatsons key is somehow a bit strange ;)
[19:37] <rjmyst3> hello
[19:41] <jeromeg> i accidently uploaded a package to upload.ubuntu.com
[19:41] <jeromeg> it was supposed to be for my ppa
[19:41] <jeromeg> what shall I do ?
[19:41] <StevenK> jeromeg: You'll get a nasty e-mail saying don't do that.
[19:41] <jeromeg> StevenK: ok, it will be removed autmatically ?
[19:41] <crimsun> it won't even be processed.
[19:41] <StevenK> jeromeg: Right, so don't worry about it.
[19:42] <jeromeg> ok thank you both
[19:42] <rjmyst3> bddebian: I've fixed the issues that you pointed out, would you mind taking another look?
[19:43] <LaserJock> hmm, I wonder if we would want Soyuz to reject any uploads with "ppa" in the version?
[19:43] <LaserJock> I get worried sometimes that I'm gonna slip
[19:43] <bddebian> rjmyst3: I'm a little swamped today but I will try.
[19:45] <rjmyst3> bddebian: thank you, I know I've been bugging you a lot lately, but I feel like the package is really close, and I want to finish it up
[19:46] <bddebian> rjmyst3: Believe me, I understand that :-)
[19:46] <\sh> LaserJock, well, if your package is named with something line "*~ppa" then everything else is > then ~ppa when I understand the versioning scheme correctly
[19:47] <LaserJock> \sh: not everything is >
[19:47] <LaserJock> if I'm doing a new upstream version in a PPA it's likely to have a higher version than what's in the archives
[19:48] <\sh> LaserJock, yes...but if you have 0.9.53-0ubuntu1 in the archive, your new version is 0.9.54-0ubuntu1~ppa in your ppa...then 0.9.54-0ubutu1 > 0.9.54-0ubuntu1~ppa
[19:48] <rjmyst3> bddebian: now that you're familiar with wxformbuilder, do you know of any other MOTU's that might be interested? - so I can beg them for reviews :)
[19:49] <\sh> LaserJock, so you could be happy to upload a real 0.9.54-0ubuntu1 version directly after your wrong upload
[19:49] <\sh> LaserJock, but I could be wrong, when I see what hacks I'm doing now for wine to fix this crap shlibs problem
[19:49] <LaserJock> \sh: ah, I see. You're saying it's easy to "fix" your mistake in that sense
[19:49] <\sh> LaserJock, yepp
[19:49] <LaserJock> but if you didn't mean to do a new upstream version ....
[19:49] <LaserJock> we're screwed ;-)
[19:50] <\sh> LaserJock, well, yes :)
[19:50] <saivann> Is there someone who will like to take a look at my package http://revu.tauware.de/details.py?package=simdock?  I have already one advocate
[19:50] <\sh> LaserJock, that's why I'm trying to set the default upload path to something insane like /dev/null or so
[19:51] <\sh> oh man...I need a functioning vmware or virtualbox for amd64
[19:57] <\sh> hmm...what was the magic keyboard shortcut to make a screenshot in gnome?
[19:57] <kai^sds> the print key
[19:58] <\sh> yay...that's easy
[19:58] <\sh> ;)
[19:58] <smarter> afternoon everybody ;)
[19:58] <frafu> Could anybody please review the mousetweaks package: http://revu.tauware.de/details.py?upid=1609  It would be great if it makes it into hardy as the corresponding gui will be in hardy. (a11y tab of the mouse control panel)
[19:59] <kai^sds> \sh: you can also press alt-print to make a screenshot of a single window
[19:59] <\sh> kai^sds, well, somehow "Print" doesn't work...at least tells me gimp that...
[20:00] <kai^sds> "print" should open a dialog that asks you for a filename
[20:00] <kai^sds> in contrast to windows where it only copys the screenshot to the clipboard
[20:01] <\sh> kai^sds, ah...now I see it works not when the mouse is in the panel :)
[20:01] <\sh> kai^sds, and this I want to shoot ;)
[20:01] <kai^sds> ok ;)
[20:01] <\sh> kai^sds, so this is something for -desktop ,)
[20:01] <smarter> Could anyone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer It should be good enough now ;)
[20:01] <frafu> I updated the mousetweaks package in revu by using the new upstream release from last sunday
[20:03] <frafu> My question: once in universe, will the package continue to be updated by the archive admin?
[20:04] <james_w> frafu: not if it can't be synced from somewhere else, e.g. Debian.
[20:04] <frafu> it is in gnome
[20:06] <james_w> frafu: yes, but that is upstream, it needs someone to take care of it and update to new upstream versions.
[20:06] <james_w> frafu: Hopefully you would play a part in that, though others may be interested.
[20:06] <james_w> frafu: you say it corresponds to a tab in the mouse preferences of gnome now?
[20:07] <frafu> james_w: yes; the tab will appear in gnome 2.21.5
[20:08] <frafu> hardy still uses the gnome control center 2.21.4
[20:08] <james_w> frafu: and so what happens when your package isn't installed?
[20:09] <frafu> A dialog that tells to install it
[20:11] <frafu> james_w: you said: "yes, but that is upstream, it needs someone to take care of it and update to new upstream versions". Do you mean that it needs someone in ubuntu to take care of it, or were you talking about upstream?
[20:12] <james_w> frafu: yeah, in ubuntu. Most packages can't just be upgraded to a new version in ubuntu when a new upstream is released, they need a manual step.
[20:12] <james_w> I mean it is not possible to do it in practice, and it doesn't work in many cases even in theory.
[20:12] <ryanakca> why does basic256 always go into Lost & Found in the menu? http://revu.tauware.de/revu1-incoming/basic256-0801302110/basic256-0.9.2/debian/basic256.desktop
[20:13] <frafu> james_w: and the person doing the update has to be a motu, I suppose?
[20:14] <james_w> frafu: or a core-dev, or someone who is just sponsored. (e.g. you)
[20:14] <james_w> but the process is much easier in that case.
[20:16] <frafu> james_w: what will be the process if a sponsor does? Will the sponsor have to prepare the package and post it on launchpad?
[20:16] <james_w> ryanakca: http://standards.freedesktop.org/menu-spec/latest/apa.html
[20:17] <RainCT> frafu: yep
[20:17] <frafu> s/does/does it
[20:17] <james_w> ryanakca: that suggests you add Education;Science to the categories. Maybe that will help.
[20:18] <RainCT> frafu: eh, not the sponsor but the person who will be sponsored
[20:18] <frafu> what is the difference?
[20:18] <dcordero> RainCT, are you sure that the setup.py install the manpage? i think that it dont do it :/
[20:19] <RainCT> dcordero: the manpage no, the .desktop files
[20:19] <ryanakca> james_w: ah, lol, I thought it suggested to put ComputerScience to the categories :)
[20:19] <frafu> I suppose that I am currently the sponsor of mousetweaks for ubuntu!?
[20:20] <james_w> ryanakca: yes, it suggests those in addition
[20:20] <ryanakca> oh, ok
[20:20] <james_w> ryanakca: I think it suggests you end up with ComputerScience;Education;Science
[20:20] <RainCT> frafu: no, you are the guy being sponsored :P
[20:20] <james_w> I don't know how that transforms to the menu, perhaps ubuntu only considers the larger categories.
[20:21] <RainCT> frafu: and the sponsors are those who advocate you
[20:21] <dcordero> RainCT, ;)
[20:21] <frafu> RainCT:ah, ok  8-)
[20:24] <RainCT> frafu: I think that the short description has to start with a lowercase letter. Beside that it looks okay to me now :)
[20:25] <dcordero> uff it's hard that tasks of packaging. I am fixing a simply bug and i have a lot of errors
[20:25] <frafu> RainCT:i will change that right away and do a new upload... ok?
[20:26] <RainCT> dcordero: heh well, you will get used to it (to doing it right, not do have a lot of errors :P)
[20:27] <dcordero> when i think about package one big package like kde or something like that, my mind is going crazy haha
[20:30] <RainCT> frafu: ok :)
[20:30] <RainCT> dcordero: haha well, same here :P
[20:30] <RainCT> dcordero: but KDE is actually a lot of packages
[20:37] <frafu> RainCT: upload done;
[20:37] <frafu> Waiting for revu to show it...
[20:39] <ryanakca> Since feature freeze is looming, and last time I uploaded a package to debian, it took a few weeks to process, would it be safe to upload the same package to both Ubuntu & Debian, or would I have to modify the ubuntu copy to -0ubuntu1 ?
[20:40] <RainCT> ryanakca: -0ubuntu1
[20:41] <ryanakca> RainCT: okies
[20:41] <blueyed> If a project uses versions like 4.3pre1 .. 4.3pre13 .. 4.3final, should I use "4.3~pre1-0ubuntu1 .. 4.3~pre13-0ubuntu1 .. 4.3-0-ubuntu1" for the ubuntu package?
[20:42] <RainCT> blueyed: /me thinks so
[20:42] <frafu> To come back to the discussion about the process of updating a package in universe: What happens after the sponsored person has put the update on launchpad? (I suppose that he has to file a bug containing the updated debianized package!?) Does the sponsored person have to notify a motu?
[20:42] <RainCT> blueyed: yes. else 4.3pre1 would be > 4.3 (final)
[20:43] <blueyed> RainCT: ok, will go with that scheme then, thanks.
[20:44] <RainCT> frafu: the process is documented on wiki.ubuntu.com. you have to upload I don't remember what (previously it was an interdiff, but now I think they changed it) and subscribe ubuntu-universe-sponsors
[20:45] <RainCT> dcordero: great, I'm uploading it :)
[20:47] <ryanakca> Can a REVU admin look at http://paste.ubuntu-nl.org/54117/ please? Upload failed and suggests to run dcut, but either I don't have permission to run it, or its not supported
[20:47] <frafu> RainCT: ok, I will have a look at the wiki;  by the way, the updated version has appeared on revu :)
[20:48] <RainCT> ryanakca: iirc it is disabled on REVU
[20:48] <ryanakca> RainCT: so how do I upload?
[20:50] <frafu> ryanakca: https://wiki.ubuntu.com/MOTU/Packages/REVU
[20:52] <geser> \sh: did you get the virtualbox-ose-modules from LP or are you waiting?
[20:52] <blueyed> geser: it's stuck in new..
[20:53] <geser> blueyed: I know but \sh searches them
[20:53] <RainCT> wow, Launchpad Janitor is fast :P
[20:53] <\sh> geser, yeah I found them somehow on LP :)
[20:54] <RainCT> frafu: well, I just did my first upload :)
[20:55] <RainCT> dcordero I mean ^
[20:55] <frafu> RainCT: Do  you mean mousetweaks is now in universe?
[20:55] <RainCT> frafu: advocated :)
[20:56] <RainCT> frafu: no, that was for dcordero, sorry
[20:56] <frafu> ah, ok
[20:57] <RainCT> frafu: but I just advocated mousetweaks (now you just need to find another advocate)
[20:57] <frafu> RainCT: you advocated the wrong version; you advocated the version with the upper short description)
[20:58] <RainCT> damn.. if someone fixes my pidgin crashes I give him a cookie :P
[20:58]  * RainCT just found another bug in REVU
[20:59] <frafu> RainCT: Thanks for advocating and above all thanks for all your help :)
[21:00] <RainCT> frafu: no problem, thanks for contributing to Ubuntu :)
[21:00] <crimsun> jdstrand: if the security team doesn't already have enough work :), there's bug 185534.
[21:00] <ubotu> Launchpad bug 185534 in pulseaudio "[SECURITY] Fix unchecked setuid() return values (feisty-security, gutsy)" [High,Fix released] https://launchpad.net/bugs/185534
[21:01] <jdstrand> crimsun: thanks.  I am aware of it
[21:01] <jdstrand> crimsun: that priority is inflated
[21:01] <joejaxx> that was fun
[21:01]  * joejaxx is happy now :D
[21:02] <crimsun> jdstrand: sure, you guys are the setters of the priority.  I only gave it an initial value.
[21:02] <jdstrand> crimsun: not vulnerable in the default install, and it's questionable we would be with LSMs installed
[21:02] <jdstrand> crimsun: oh no problem, just mentioning it :)
[21:02] <frafu> RainCT: I have to leave now; congratulations for your first upload; bye
[21:03] <RainCT> frafu: thanks, see you :)
[21:05] <frafu> RainCT: cheers :-)
[21:11] <dcordero> how, my first fix :)
[21:11] <RainCT> is there a way to avoid ubotu from telling me stuff following instructions from a certain person (without blocking all ubotu messages)?
[21:12] <RainCT> dcordero: gratz :)
[21:12] <dcordero> thanks RainCT really you has been who has fixed the bug haha
[21:14] <RainCT> dcordero: heh heads up, I'm sure you will need less tries for your next debdiff :)
[21:15] <RainCT> well, /me is going to do homework now..
[21:15] <dcordero> i hope
[21:27] <Coper> If I want to add a new package to ubuntu what version number should it have if it's name is package-1.0?
[21:28] <smarter> Coper: 1.0-0ubuntu1
[21:29] <Coper> hmm okej, i got 1.0-1ubuntu1 then creating it with dh_make
[21:31] <emgent> \sh, here?
[21:31] <\sh> emgent, sure
[21:31] <emgent> like join to ubuntu-pentest ?
[21:31] <\sh> emgent, sure :)
[21:32] <emgent> ok cool, just a moment :)
[21:32] <\sh> emgent, no hurry...I'm just about going off because wife's coming home :)
[21:33] <emgent> \sh, done hehe
[21:33] <emgent> :D
[21:33] <emgent> jdstrand, i can add u too ?
[21:33] <Coper> What should I do with this two warnings? "warning: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" and "warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field" get them when I run debuild -S -sa
[21:34] <\sh> hmm...
[21:34] <james_w> Coper: make MOTU the maintainer, and yourself XSBC-Original-Maintainer
[21:34] <\sh> I'm adding something like debian/<package>.substvars and after debuild -S it disappeared.
[21:34] <\sh> -EVERYSTRANGE
[21:35] <ScottK2> Coper: https://wiki.ubuntu.com/DebianMaintainerField
[21:36] <jdstrand> Coper: use 'update-maintainer'
[21:36] <jdstrand> Coper: it'll do it for you automagically
[21:37] <jdstrand> emgent: sure! :)
[21:37] <emgent> :)
[21:37] <squentin> I'd like a ubuntu package to be updated, I opened a bug (#156886) 3 months ago, but no answer. Would uploading the new package myself to REVU help ? There's really no change that affect packaging.
[21:39] <\sh> ok I'm off now
[21:40] <persia> squentin: Take a look at https://wiki.ubuntu.com/MOTU/Contributing under "Preparing new revisions".  You likely want to attach an interdiff to the bug.
[21:40] <Coper> Must my name be in XSBC-Original-Maintainer or is it just for fun? :)
[21:40] <RainCT> Coper: put it there :)
[21:41] <squentin> persia: thanks, I'll look
[21:41] <RainCT> Coper: I'm not sure if it's a "must", but it does no harm, but anyway it can't do any harm ;)
[21:44] <Coper> I have made a new dput to revu does anyone have a minute over to check it when revu has been updated?
[21:51] <james_w> Could someone clarify? The REVU messages to ubuntu-motu are notices that the package has been uploaded to the archive?
[21:52] <ScottK2> Yes
[21:52] <geser> james_w: yes, send by the MOTU doing the upload
[22:01] <dcordero> if you fix a bug in a package name package-1.0~beta5 what is the version after fixing? package-1.0~beta5ubuntu1 ???
[22:05] <ScottK2> dcordero: Yes.
[22:05] <RainCT> dcordero: yes, but that's an unusual package version..
[22:05] <RainCT> :P
[22:05] <jpatrick> http://paste.ubuntu-nl.org/54132/ - can someone help me with this?
[22:06] <slangasek> dcordero: presumably, "package" is the package name, and "1.0~beta5" is really the upstream version number?
[22:06] <dcordero> slangasek, yep Bug #187420
[22:06] <ubotu> Launchpad bug 187420 in gtwitter ".desktop file missing" [Undecided,Confirmed] https://launchpad.net/bugs/187420
[22:07] <pochu> Anyone could have a look to http://revu.ubuntuwire.com/details.py?package=falconpl ? The package looks fine to me, but I'd like to have a second advocate.
[22:07] <dcordero> jpatrick, /usr/bin/ld: cannot find -ldomino <--- Do you have this library installed?
[22:07] <RainCT> dcordero: that is Version: 1.0~beta-5
[22:07] <slangasek> dcordero: ah, then the version number is "1.0~beta-5", not "1.0~beta5"; there's a crucial difference :)
[22:08] <slangasek> so yes, 1.0~beta-5ubuntu1 for the fixed version
[22:08] <RainCT> dcordero: so 1.0~beta means that it's upstream version 1.0 Beta, the -5 that it is the 5th revision in Debian, and the ubuntu1 that it's the first revision in Ubuntu
[22:08] <TheMuso> n/c
[22:08] <dcordero> ups, sorry i miss a - in the way
[22:08] <TheMuso> ugh
[22:08] <jpatrick> dcordero: that's the thing it's trying to build..
[22:09] <RainCT> dcordero: dh_desktop  should be below
[22:10] <RainCT> dcordero: where most of the other dh_* calls are (sorry, I don't have time to check how that section is called right now)
[22:11] <dcordero> ok
[22:11] <RainCT> dcordero: also, feel free to add this to the manpage   Comment[ca]=Controleu la vostra compta de Twitter    :)
[22:12] <RainCT> *desktop file
[22:12] <dcordero> Viva catalonia !! ;)
[22:12] <RainCT> :D
[22:13] <ScottK2> jpatrick: Do you build-dep on kdebase-devel?
[22:19] <jpatrick> ScottK2: yes
[22:19] <ScottK2> Hmmm.  That's all Google had to offer.  No great ideas then.
[22:20] <jpatrick> Build-Depends: debhelper (>= 6), cdbs, automake1.9, kdebase-dev, libqt3-mt-dev
[22:20] <ScottK2> jpatrick: How about kdelibs4-dev?
[22:21] <jpatrick> ScottK2: pulled in by kdebase-dev
[22:21] <ScottK2> OK.
[22:21] <ScottK2> Back to dunno then.  Sorry.
[22:21]  * jpatrick tests his new rules file
[22:22] <jpatrick> ScottK2: it's a Debian problem, cos on Kubuntu it works fine :)
[22:22] <slangasek> jpatrick: does your debian/rules install target use DESTDIR?
[22:22] <jpatrick> slangasek: no
[22:23] <slangasek> ok, what does your install target look like? are you overriding prefix= instead?
[22:23] <jpatrick> http://paste.ubuntu-nl.org/54136/
[22:23] <slangasek> er, heh
[22:23] <jpatrick> I've added the last three lines since last build failure^^
[22:25] <warp10> If a package is licensed as "public domain" in Debian, should it be synced in universe or multiverse?
[22:25] <slangasek> jpatrick: well, that kind of relinking should only happen when installing with make install prefix= instead of make install DESTDIR=; but as this is outside of your control with cdbs, at best I guess it could be a cdbs bug in Debian
[22:25] <slangasek> warp10: universe
[22:26] <warp10> slangasek: ok, thank you
[22:27] <TheMuso> mousetweaks neesd a second advocate. If a MOTU has time, please look it over.
[22:27] <mok0> jpatrick: is --as-needed kosher?
[22:27] <jpatrick> mok0: kosher?
[22:27] <mok0> is it correct
[22:28] <jpatrick> mok0: no idea but it's how it's done in another debian package
[22:28] <jpatrick> and yay, it still fails
[22:28] <slangasek> jpatrick: please don't cargo-cult build options if you don't understand them :)
[22:28] <mok0> there's been a long debate about it the other day on d-d
[22:28] <slangasek> ISTR that --as-needed and KDE don't get along too well in general...
[22:29] <jpatrick> slangasek: it worked in the other package...
[22:29] <RainCT> what do you guys think about bug 186305?
[22:29] <ubotu> Launchpad bug 186305 in wmaker "Merge wmaker 0.92.0-7 from Debian(Unstable)" [Wishlist,Confirmed] https://launchpad.net/bugs/186305
[22:29] <joejaxx> ohh window maker
[22:29] <RainCT> the only change in -7 is that it has a new maintainer :P
[22:30] <ScottK2> RainCT: I'd say don't bother then if we have -6
[22:30] <RainCT> but -6ubuntu1 has two Maintainer: fields in debian/control (one of which should be XSBC-O-M)
[22:31] <mok0> slangasek: what was the conclusion  on the discussion?
[22:31] <mok0> I didn't read all of it
[22:31] <slangasek> mok0: I think we agreed to disagree ;)
[22:31] <mok0> slangasek: heh
[22:31] <RainCT> ScottK2: still think it isn't worth it?
[22:31] <ScottK2> RainCT: Then that's a bug in -6ubuntu1 that ought to be fixed.  May as well fix it that way.
[22:32] <ScottK2> So I'd go ahead then.
[22:33] <TheMuso> Has anybody ever tried writing a debian/watch file for a googlecode project? From what I've found, its not possible...
[22:37] <RainCT> ScottK2: okay, I'll upload then. Thanks!
[22:41] <ScottK2> RainCT: I didn't look at the debdiff, just commenting in general
[22:44] <LaserJock> TheMuso: what's the problem with it?
[22:44] <TheMuso> LaserJock: Well, if you try and go to the files/ dir of a project, you get a 404.
[22:45] <TheMuso> take http://liblouis.googlecode.com. If you try to go to http://liblouis.googlecode.com/files/ you get a 404, but tarballs are stored in that dir.
[22:45] <ScottK2> TheMuso: Did you check to see if Debian has a special process for googlecode like they do for sourceforge?
[22:46] <TheMuso> ScottK2: No I haven't yet.
[22:46] <TheMuso> ScottK2: I am not sure where I would find such information however.
[22:46] <ScottK2> man uscan is where I'd look
[22:46] <pochu> TheMuso: can't you do the webpage one? there should be a link to the file somewhere
[22:46] <james_w> There's nothing in the uscan code that I can see.
[22:46] <james_w> though the sf handling was external to start with.
[22:46] <vorian> I just had a watchfile for google code
[22:47] <vorian> let me find it
[22:47] <TheMuso> vorian: Ooo sweet, thanks.
[22:47] <vorian> np :)
[22:47] <TheMuso> pochu: There is, but how do you tell uscan to scrape?
[22:47] <james_w> TheMuso: that's what it does anyway.
[22:47] <TheMuso> james_w: Ah ok.
[22:47] <james_w> as long as the links are fairly obvious it should find it.
[22:48] <TheMuso> Hrm ok. I'l give that a try.
[22:48] <james_w> It normally scrapes the directory indices.
[22:49] <TheMuso> vorian: If you can find the one you did however, that would also be great.
[22:49] <vorian> TheMuso: checking :)
[22:49] <vorian> report
[22:49] <vorian> dangit
[22:51] <vorian> no such luck TheMuso, sorry about that
[22:52] <TheMuso> vorian: Its fine, I think I've found what I need in the manpage.
[22:52] <vorian> kk
[22:52] <TheMuso> vorian: Thanks anyway.
[22:52] <vorian> no problem
[22:54] <RainCT> ScottK2: sure, that's all what I was asking for, I'll check it before uploading, of course. :)
[22:54] <mok0> slangasek: --as-needed is not supported by Gentoo
[22:55] <mok0> "this flag is not considered safe for production use and not supported in any way by Gentoo."
[22:55]  * ScottK doesn't know the specifics, but if Gentoo thinks something is unsafe ....
[22:56] <mok0> http://www.gentoo.org/proj/en/qa/asneeded.xml
[22:59] <mok0> http://lists.debian.org/debian-devel/2007/12/msg00265.html
[23:00] <slangasek> mok0: hee
[23:00] <mok0> Just a pointer to the beginning of the discussion :-)
[23:01] <mok0> ... in case anyone here wants to investigate..
[23:03] <Pyromaniac_> wow
[23:03] <Pyromaniac_> im an irc virgin no longer
[23:05] <nixternal> hahaha
[23:22] <blueyed> Does somebody have a ppc for testbuilding around?
[23:22] <blueyed> I might have a fix for 184218
[23:22] <blueyed> bug 184218
[23:22] <ubotu> Launchpad bug 184218 in pbuilder "FTBFS in latest archive rebuild test" [High,In progress] https://launchpad.net/bugs/184218
[23:23] <blueyed> geser: ^^ do you think that is the same s/-a/-s/ issue as with virtualbox-ose-modules?
[23:25] <desertc> *waves*
[23:25] <Seveas> blueyed, I could have if it would boot from an ubuntu cd :/
[23:25] <TheMuso> blueyed: Yes, I have a ppc. Let me boot it, and update its chroots.
[23:27] <desertc> I'm watching a Debian package take shape.  I believe it is already packaged and in their repository (perhaps).  Will Ubuntu necessarily start distributing this package, or are there extra steps to ensure it gets into the Ubuntu repositories, too?
[23:27] <desertc> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444144
[23:27] <ubotu> Debian bug 444144 in wnpp "ITP: adanaxisgpl -- FPS game in 4 spatial dimensions" [Wishlist,Fixed]
[23:27] <TheMuso> desertc: You need to request it be synced.
[23:27] <geser> blueyed: could really fix it as pbuilder is arch:all (build in i386) and pbuilder-uml is i386 and amd64 only
[23:27] <desertc> TheMuso: Is that a wishlist bug, then?
[23:28] <TheMuso> desertc: Yes, but the easiest way to do it, is to file a sync request bug, and subscribe ubuntu-universe-sponsors, for a MOTU to approve it.
[23:29] <blueyed> geser: would be great.
[23:29] <geser> blueyed: but pbuilder-uml is already in P-a-s listed
[23:29] <blueyed> TheMuso: http://codeprobe.de/tmp/pbuilder_0.177ubuntu1.dsc
[23:29] <desertc> TheMuso: Thanks for your advice.  I think this package will be of benefit to the Ubuntu community.  The developer really stands behind his Linux version.
[23:29] <desertc> (The commercial version also runs great in Ubuntu.)  :)
[23:29] <TheMuso> blueyed: But pbuilder is arch all is it not?
[23:30] <blueyed> geser: P-a-s?
[23:30] <geser> blueyed: looking at the build records I guess that bug can be closed as this error happens on ppc and the source package gets only build on i386 and amd64
[23:30] <blueyed> TheMuso: see the bug report.. it fails on ppc (it has binary-arch for != i386/amd64)
[23:31] <geser> Packages-arch-specific: http://cvs.debian.org/srcdep/Packages-arch-specific?root=dak&view=markup
[23:31] <geser> an override on which arch a package should get build
[23:32] <geser> TheMuso: pbuilder is arch all, but pbuilder-uml is i386/amd64
[23:32] <geser> TheMuso: but pbuilder gets also only build on those arch, so I'd say the bug can be ignored (set to invalid)
[23:33] <blueyed> geser: but closing the bug would be wrong, as it seems that pbuilder does not get build for ppc at all..?!
[23:33] <blueyed> geser: isn't "pbuilder" supposed to be available on ppc?
[23:34] <geser> blueyed: the binary package "pbuilder" is arch:all and arch:all packages get build by the i386 buildd
[23:34] <RainCT> good  night
[23:34] <blueyed> geser: ahh.. I see.
[23:34] <geser> the source package "pbuilder" gets tried to build on ppc normally
[23:34] <blueyed> RainCT: sleep well.
[23:34] <geser> *get never tried*
[23:35] <RainCT> :P
[23:36] <TheMuso> ok so I don't need to test anything then.
[23:36] <blueyed> geser: so, the bug is really invalid, but it would do no harm to fix it, correct?
[23:37] <blueyed> TheMuso: please do, as far as I can see.
[23:38] <geser> blueyed: we would carry additional Ubuntu changes without much benefit (it would only benefit those who try to build pbuilder on ppc)
[23:38] <TheMuso> Well I can't do anything, as pbuilder is in main.
[23:38] <TheMuso> geser: And thats just the thng. Wy would you.
[23:38] <TheMuso> thing
[23:39] <fmarier> What's the correct procedure to request a sync from Debian (in hardy) to fix an important bug ?  I'm talking specifically about LP#182745...
[23:39] <geser> bug 182745
[23:39] <ubotu> Launchpad bug 182745 in email-reminder "Configuration file is not read, making it impossible to configure this app" [Undecided,Confirmed] https://launchpad.net/bugs/182745
[23:39] <blueyed> Well, maybe Debian would accept the change? Anyway, ok, mainly I'd be just interested, if the fix works.
[23:40] <fmarier> The fix is in Debian already and I've tested it on Ubuntu using a backport in my PPA
[23:40] <fmarier> (I'm both the Debian maintainer for the package and the upstream developer)
[23:40] <geser> blueyed: you could try, but Ubuntu uses the same P-a-s as Debian (actually it uses the one from Debian)
[23:41] <blueyed> geser: ok, I'll then just drop that patch and close the bug. Thanks for explaining.
[23:41] <LaserJock> fmarier: https://wiki.ubuntu.com/SyncRequestProcess is the formal documentation
[23:41] <mok0> Hmm. Is libgif and libungif compatible?
[23:41] <mok0> s/Is/Are/
[23:42] <blueyed> mok0: yes, as far as I know (for the transition just the deps got swapped - at least the build-deps)
[23:42] <fmarier> blueyed: thanks, let me know if there's anything I can do to help
[23:43] <geser> fmarier: I'm just test-building the Debian package before I request a sync
[23:43] <mok0> blueyed: I can't install it on gutsy due to conflict
[23:43] <mok0> it = libgif
[23:44] <blueyed> mok0: well, the packages conflict - yes. But I've just edited the deps in the .deb once to have them installed side by side or something similar,
[23:44] <geser> fmarier: bug 187455
[23:44] <ubotu> Launchpad bug 187455 in email-reminder "Please sync email-reminder 0.7.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/187455
[23:45] <blueyed> mok0: probably adding libungif (the older one) as Provides in libgif would do the trick. Then remove libungif.
[23:45] <mok0> blueyed: but does that mean that on gutsy, I should depend on libungif, and on hardy, libgif?
[23:45] <blueyed> mok0: yes, probably. But all AFAIK..
[23:45] <mok0> blueyed: I'll try it, thansk
[23:47] <fmarier> geser: thanks, I'll use that format next time
[23:47] <blueyed> fmarier: there's a requestsync script which does this..
[23:48] <fmarier> very nice, I'll add that to my toolbox :)
[23:49] <TheMuso> fmarier: No need. Its in the ubuntu-dev-tools package
[23:53] <dcordero> hi
[23:54] <blueyed> TheMuso: I've reopened the ppc bug.. I think people on ppc should be able to build the package from source. Can you still test building it, please?
[23:54] <TheMuso> blueyed: Why?
[23:54] <TheMuso> blueyed: Why would they want to, when its available from the archive, ready to go?
[23:55] <blueyed> TheMuso: when they are changing (or even fixing) something?
[23:57] <TheMuso> blueyed: But how often woud a ser be doing that who is using PPC?
[23:57] <TheMuso> would
[23:57] <TheMuso> And its in main, so even if it did work, I can't upload it.
[23:59] <blueyed> TheMuso: I don't know.. - it's just another small fix in the debdiff I need to get sponsored, so that isn't the deal.. I can wait for someone to test the patch from the bug report though.. ;)
[23:59] <TheMuso> Lutin: Well, push it to debian.
[23:59] <TheMuso> blueyed: ^^ sorry
[23:59] <TheMuso> Lutin: sorry