[00:01] <blueyed> TheMuso: the point is, I'd like to get it verified first.. I thought it wasn't a big deal from what you've said.. nevermind..
[00:03] <TheMuso> Alright, I'll test build i.
[00:03] <TheMuso> it
[00:07] <rjmyst3> any wxWidgets fans in here?
[00:11] <mok0> rjmyst3: what's up
[00:21] <dcordero> why some packages has as maintainer a @ubuntu.com email? who are that people?
[00:22] <dcordero> why dont use motu?
[00:23] <ScottK2> dcordero: It means that individual has chosen to take responsibility for the package.
[00:23] <ScottK2> Why varies per person.
[00:23] <blueyed> ..or left-overs from dh_make..
[00:24] <ScottK2> Although that won't usually give you an ubuntu.com address.
[00:24] <blueyed> from DEBEMAIL?
[00:25] <dcordero> ok i think that motu has ubuntu.com address
[00:25] <dcordero> i was mistake
[00:29] <TheMuso> blueyed: Pbuilder builds fine without your patch on ppc.
[00:30] <TheMuso> This is the version in hardy.
[00:30] <blueyed> TheMuso: so you've tested 0.176ubuntu1, or the .dsc I've given? Ok.. thanks.
[00:30] <TheMuso> 0.176ubuntu1.
[00:30] <TheMuso> Just pulled from repo, and built.
[00:30] <TheMuso> Note that I am using sbuild.
[00:31] <blueyed> hmm.. that might make a difference then.. the bug is for the same version. It's getting ugly.. I'll leave this patch out and request sponsorship for the more important ones. Thanks again.
[00:34] <TheMuso> np
[00:34] <pochu> Would you say a 2GB ddr2 533mhz module for 39€ is a good buy? Or is it expensive?
[00:36] <pochu> err, offtopic here, sorry
[00:37] <pochu> although I want it to be able to build wxWidgets3.0, so not that offtopic ;)
[00:37] <ScottK2> pochu: I'd worry more about the quality than price myself.  Bad RAM can cause a lot of trouble.
[00:37] <geser> pochu: still offtopic but I bought 2 x 2 GB DDR2 PC6400 for 90€
[00:38] <pochu> ScottK2: It's Kingston, which is a good manufacturer, isn't it?
[00:38] <TheMuso> The prices you guys have overseas makes me jellous. :p
[00:38] <TheMuso> Although ours aren't too bad.
[00:38] <mok0> Can I do a sid build on the ppa?
[00:38] <pochu> ScottK2: and I have to worry about the price... my money isn't ilimited
[00:38] <geser> pochu: afair kingston has a good reputation
[00:38] <pochu> mok0: nope
[00:39] <mok0> pochu: didn't think so :-)
[00:39] <mok0> I'd love to be able to provide packages for my Debian friends...
[00:40] <pochu> mok0: report a bug against soyuz
[00:41] <mok0> pochu: I've reported lots of bugs against LP, they tend to be ignored
[00:41] <pochu> I think I'll see if I find this one or something similar cheaper in another store. Otherwise I'll buy it.
[00:41] <geser> pochu: isn't there a price search site for online shops from your country?
[00:41] <pochu> Thanks for the advice
[00:41] <pochu> geser: not that I know of...
[00:41] <pochu> mok0: not mines
[00:42] <mok0> pochu: ok, I'll do it. Wrt. RAM, I prefer Corsair
[00:48] <geser> pochu: I don't know how the german prices compare to the spanish ones, but a Kingston KVR533D2N4/2G costs around 35-40€ in german online shops
[00:50] <rjmyst3> mok0: you replied to me earlier, but I had stopped watching, sorry
[00:50] <mok0> rjmyst3: wxwidgets?
[00:50] <rjmyst3> yes
[00:50] <mok0> rjmyst3: you were asking about it
[00:51] <rjmyst3> i'm looking for reviews of my package for a wxWidgets GUI builder - wxformbuilder
[00:51] <rjmyst3> http://revu.tauware.de/details.py?package=wxformbuilder
[00:51] <mok0> rjmyst3: I'm not a motu
[00:51] <rjmyst3> that's too bad
[00:52] <rjmyst3> but, if you like widgets, you might like the software
[00:52] <rjmyst3> wxformbuilder is a good tool
[00:52] <mok0> rjmyst3: is it an IDE?
[00:53] <rjmyst3> mok0: no, it is GUI layout + code generation - it generates C++ and XRC
[00:53] <mok0> rjmyst3: ok, that's an ide ;-)
[00:53] <rjmyst3> mok0: the generated files can then be used on your platform of choice
[00:53] <mok0> Integrated Developemnt Environment
[00:53] <rjmyst3> mok0: ok, then it is :)
[00:53] <rjmyst3> mok0: but it does not compile the code
[00:54] <mok0> rjmyst3: debian/changelog: (LP: #181412)
[00:54] <mok0> rjmyst3: not closes
[00:55] <rjmyst3> mok0: i see you've found a bug already! - I am not sure what you are saying, though
[00:56] <mok0> rjmyst3: In your file debian/changelog, there's a bug in the line with bg#.... it should be like ^^^
[00:57] <rjmyst3> mok0: is this the correct syntax: "* Initial Release. (LP: #181412)" ?
[00:57] <mok0> yes
[00:57] <rjmyst3> what does LP mean?
[00:58] <mok0> Launchpad. It's Ubuntu's bug tracking system
[00:58] <rjmyst3> oh!
[00:58] <mok0> ubotu, ! Launchpad
[00:58] <ubotu> Launchpad is a collection of development services for Open Source projects. It's Ubuntu's bug tracker, and much more; see https://launchpad.net/
[00:58] <rjmyst3> i'm familiar with Launchpad - I opened the bug
[00:58] <rjmyst3> i just didn't put 2 and 2 together
[00:59] <mok0> rjmyst3: In debian, it's true you write (closes: #nnnnn)
[00:59] <rjmyst3> i was reading the debian policy manual when i wrote that
[00:59] <rjmyst3> i'll fix that right now, thank you
[01:00]  * ScottK2 says what the heck and uploads.
[01:00] <mok0> rjmyst3: there are a few minor differences. The changelog file is scanned by the build system, and it would not work because Ubuntu adn Debian have different numbers
[01:00] <mok0> bug numbers
[01:00] <rjmyst3> right, I understand
[01:00] <rjmyst3> is there a list of differences for ubuntu that I should read?
[01:00] <mok0> I've never seen one
[01:01] <ScottK2> Version numbering and bug numbering are the ones that usually matter for packaging.
[01:01] <mok0> .... and the mainainer thing
[01:01] <rjmyst3> I am familiar with the version number and bug numbering (now) - what is the maintainer thing?
[01:01] <ScottK2> The other major one is that Ubuntu will accept GFDL invariant documentation in it's main repositories.  Debian considers them non-free
[01:02] <mok0> ubotu, ! maintainer
[01:02] <ubotu> The "Maintainer" field in a package's information (debian/control) should indicate the Ubuntu team responsible for the Ubuntu specific changes to a package (often the !MOTU for !Universe packages). The original maintainer is preserved in the field "XSBC-Original-Maintainer".
[01:02] <ScottK2> https://wiki.ubuntu.com/DebianMaintainerField
[01:02] <mok0> !MOTU
[01:02] <ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
[01:02] <mok0> !Universe
[01:02] <ubotu> The packages in Ubuntu are divided into several sections. More information at https://help.ubuntu.com/community/Repositories and http://www.ubuntu.com/ubuntu/components - See also !EasySource
[01:03] <mok0> HM
[01:03] <rjmyst3> that bot is cool
[01:04] <mok0> rjmyst3: you should write a man page for wxFormBuilder
[01:04] <mok0> rjmyst3: yeah
[01:04] <rjmyst3> there is a man page
[01:04] <mok0> ah
[01:05] <rjmyst3> in the source tree, it is in install/linux/data/wxformbuilder.1
[01:05] <mok0> rjmyst3: I will check out the program tomorrow. Right now I am tired (02:00 here)
[01:05] <rjmyst3> (or something)
[01:05] <rjmyst3> but the .deb puts it in th right place
[01:05] <rjmyst3> mok0: sounds good, thanks for your help
[01:05]  * mok0 is just browsing the source on revu
[01:06] <mok0> rjmyst3: my pleasure :-)
[01:09] <rjmyst3> ScottK2 or mok0: there is no debian package - my ubuntu package is the first
[01:09] <rjmyst3> what should the Maintainer field say?
[01:10] <mok0> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[01:10] <rjmyst3> "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" ?
[01:10] <rjmyst3> ok
[01:10] <mok0> ... and put your own name in XSBC-Original-Maintainer:
[01:10] <mok0> name <email>
[01:11] <rjmyst3> ok
[01:12] <rjmyst3> while i'm in the control file, should I use the VCS-Browser and VCS-svn fields? - are they worthwhile to anyone? still too new?
[01:12] <mok0> rjmyst3: no
[01:12] <rjmyst3> ok :)
[01:12] <mok0> rjmyst3: they are special to Debian
[01:12] <rjmyst3> oh!
[01:12] <rjmyst3> ok
[01:13] <mok0> rjmyst3: it has to do with the code management system DD's use
[01:13] <nxvl_work> ScottK2: around?
[01:14] <rjmyst3> mok0: ok, the debian policy manual did not make that clear
[01:14] <mok0> rjmyst3: heh, no
[01:14] <rjmyst3> mok0: they implied that a tool like GDebi would show the URL for the end user
[01:14] <mok0> rjmyst3: there's a lot of info on wiki.ubuntu.com, it has a search function
[01:15] <rjmyst3> mok0: lol, i am sufficiently rebuked
[01:15] <mok0> rjmyst3: I don't know too much about how it works
[01:15] <mok0> rjmyst3: hehe
[01:16] <mok0> rjmyst3: I don't know if the Ubuntu developers have similar fields. They use bazaar for code management
[01:17] <rjmyst3> mok0: it didn't look like the fields would be particularly useful to me, i'm just trying to do the right thing
[01:17] <ScottK2> nxvl_work: Sort of
[01:17] <mok0> rjmyst3: I understand
[01:18] <nxvl_work> ScottK2: about the libdb4.2, i only need to check is the packages build, didn't i?
[01:18] <ScottK2> nxvl_work: No.  It's more complex as some are affected by on disk DB format changes.
[01:19] <ScottK2> So for upgrades, the format change needs to be detected/handled.
[01:19] <nxvl_work> ScottK2: so they may build, but not work as spected?
[01:19] <ScottK2> Yes
[01:20] <nxvl_work> mm, ok ok
[01:21]  * mok0 wishes the distribution was not encoded in changelog
[01:21] <ScottK2> nxvl_work: I wrote the upstream of onak earlier today and he's got dealing with it on his TODO list.
[01:22] <ScottK2> mok0: It has to be somewhere in the source package to get into .changes.
[01:22] <nxvl_work> i have already change some of them, also correct a mistake you make on the wiki, openldap2.3 was listed 3 times
[01:22] <mok0> ScottK2: Yes but it could be in a separate fiel
[01:22] <mok0> file
[01:22] <ScottK2> nxvl_work: Thanks for fixing.
[01:23] <ScottK2> mok0: Yes.  Lots of arguing about future source package formats in Debian recently.
[01:24] <nxvl_work> ScottK2: i also make the changes on some of them and listed the LP bugs on the wiki
[01:24] <mok0> ScottK2: I am in the process of building a bunch of my packages for hardy, and it's a drag to have to go in and edit the changelog
[01:24] <ScottK2> mok0: dch -r can probably solve that for you.
[01:25] <mok0> ScottK2: I'll give it a look. But in principle, it should be possible to tell the ppa to compile the same source packages in the new distribution
[01:26] <ScottK2> True.
[01:26] <mok0> I have to do it every 6 months.. :-(
[01:27] <ScottK2> Get them into the official repositories and it's automatic.
[01:27] <ScottK2> ;-)
[01:27] <mok0> :-D
[01:28] <mok0> That's the plan, of course
[01:29] <ScottK2> Seems like you're making decent progress on that.
[01:29] <mok0> ScottK2: yes I am quite happy
[01:29] <mok0> I still have 3 sitting in revu, though
[01:29] <mok0> I worried they won't make it for hardy
[01:32] <mok0> Well, time for bed. G'night, everyone!
[01:36] <ScottK2> nxvl_work: You didn't need to file that openldap bug.  For that, efforts are already underway.  It's the others I'm worried about.
[01:36] <nxvl_work> heh, i have already file and patch the 2 openldaps :P
[01:37] <nxvl_work> ScottK2: which ones?
[01:37] <nxvl_work> btw
[01:37] <nxvl_work> how would it be with libdb4.2-ruby?
[01:37] <nxvl_work> doesn't need to be upgraded the whole package?
[01:39] <ScottK2> nxvl_work: There are performance issues with migrating openldap.
[01:40]  * slangasek links the Debian and Ubuntu bugs...
[01:40] <Legendario> hi everyone! What does this mean: Add LP: #xxxxxx, where xxxxxx is needs-packaging bug
[01:40] <ScottK2> lidbd4.2-ruby will get removed when 4.2 goes.
[01:40] <Legendario> It is in my REVU review
[01:40] <nxvl_work> ScottK2: so it need to be move out the list
[01:41] <nxvl_work> Legendario: which is the bug number on LP of your request'
[01:41] <nxvl_work> ?
[01:45] <Legendario> nxvl_work, I guess I got it. But i can't find it on LP
[01:46] <nxvl_work> Legendario: what's your lp page?
[01:47] <Legendario> nxvl_work, ~kemelzaidan
[01:48] <nxvl_work> Legendario: you are packaging liberation fonts?
[01:48] <Legendario> no, odfviewer
[01:49] <nxvl_work> did you fiel the bug?
[01:50] <nxvl_work> file*
[01:50] <nxvl_work> is not on you assigned bugs
[01:51] <ScottK2> nxvl_work: It needs to be on the list.  It's just being worked on already.
[01:51] <nxvl_work> ScottK2: ok
[01:52] <nxvl_work> Legendario: you need to file the bug and put that bug number on the changelog
[01:55] <nxvl_work> ScottK2: so, i need to build them and test? or which are the steps it takes?
[01:55] <Legendario> nxvl_work, found it: #95664. How should you write on the changelog.
[01:56] <nxvl_work> bug #95664
[01:56] <ubotu> Launchpad bug 95664 in ubuntu "[needs-packaging] OpenDocument Viewer" [Wishlist,Fix released] https://launchpad.net/bugs/95664
[01:56] <slangasek> hmm, there's no libdb4.6-ruby?
[01:56] <nxvl_work> you need to put at the end of the line (LP: #95664)
[01:59] <ScottK> nxvl_work: It doesn't have to be at the end of a line.
[01:59] <ScottK> slangasek: It's not like anyone actually uses this newfangled Ruby stuff, right?
[01:59] <nxvl_work> scottK: it's a matter of style
[02:00] <ScottK2> nxvl_work: Then say "I consider it nice for it to be at the end of the line".  It's not an actual requirement AFAIK.
[02:00] <Legendario> nxvl_work, great dude. thanks a lot
[02:00] <joejaxx> are the kubuntu ppa's the preferred place for the kde4 packages for hardy? or are the official ones the regular again?
[02:00] <nxvl_work> ScottK2: ok i will do it next time :D
[02:00] <joejaxx> the usage of ppas are really throwing me off :\
[02:01] <ScottK2> joejaxx: I think for Gutsy.
[02:01] <LaserJock> joejaxx: for Hardy the archives, for gutsy PPA
[02:01] <ScottK2> joejaxx: But I'd ask in #kubuntu-devel
[02:01] <joejaxx> ok
[02:01] <LaserJock> or rather -backports is good enough
[02:01] <LaserJock> I can't remember
[02:02] <ScottK2> I think they're waiting for 4.0.1 to fix backports, but I don't recall for sure.
[02:03] <LaserJock> ah
[02:03] <slangasek> ScottK: well, I sure don't use ruby; and I don't know why you would want more than a single libdb-ruby at a time either :)
[02:15] <ScottK2> slangasek: Dunno, but I'd guessed so you could use a specific one if you needed to.
[02:17] <slangasek> ScottK2: that's where half our problems with bdb have come from.. :)
[02:39] <Hobbsee> polls done yet?
[02:39] <Hobbsee> hah!  nice!
[02:40] <Hobbsee> nixternal: persia well done!
[02:40] <TheMuso> Congrats persia, nixternal.
[02:40] <bddebian> What'd I sleep through now?
[02:40] <joejaxx> polls?
[02:42] <crimsun> for MC
[02:42] <Hobbsee> MC
[02:43] <ajmitch> oh, congrats, new people
[02:44] <LaserJock> indeed
[02:46] <bddebian> Ah congrats persia, nixternal
[02:52] <jcastro> congrats guys
[02:53] <cheguevara> congrats :P
[02:55] <LaserJock> I for one welcome our new MC overlords ;-)
[02:55]  * bddebian cowers in fear
[03:17] <ScottK2> Congratulations persia and nixternal
[03:17] <ScottK2> Better you than me.
[03:18] <ScottK2> slangasek: I was just looking at the bdb docs on upgrading and it's, um, daunting.
[03:25]  * TheMuso goes to take care of those ttf-* sync requests.
[03:28] <nixternal> umm, thanks :)
[03:48] <jdong> persia: at the next time of your convenience, can you take a look at clutch again? I'd really love for it to meet the FF deadline
[04:02] <slangasek> ScottK2: unless you find references to transactions, the upgrade from db4.2 to db.4.6 reduces to "rebuild". :)
[04:02] <ScottK2> slangasek: Thanks.
[04:15] <ScottK2> kolab-cyrus-imapd goes on the painful list then
[04:19] <ScottK2> jabberd2 too
[04:21] <slangasek> if we're lucky, some of the transaction-using packages that require handling already have handling in the package that just needs to have the version numbers bumped
[04:32] <Legendario> one more question before going to sleep... what if the package i want to pack does not have a make file?
[04:38] <RAOF> Legendario: It doesn't matter particularly.  You just need to call whatever buildsystem the package has in debian/rules.
[04:40] <Legendario> RAOF, what if it is a java program? Any difference? If I don't have a make file, how do i get to know the build dependecies?
[04:40] <RAOF> Magic ):
[04:41] <RAOF> I very rarely determine the build dependencies from a makefile, anyway :)
[04:41] <RAOF> Legendario: Does upstream tell you what you need to build it?
[04:42] <Legendario> RAOF, don't believe so...
[04:43] <RAOF> An alternative question: *how* do you build it?
[04:45] <Legendario> RAOF, what do you mean?
[04:46] <RAOF> I mean: You get a source tarball from the website.  How do you turn this into a program, and how do you install it?
[04:48] <Legendario> RAOF, well usually i install it by "configure, make, make install" but this package doesn't have one...
[04:49] <RAOF> Right.
[04:49] <RAOF> So, the first thing you need to do is to work out how to build the source.
[04:50] <RAOF> Until you can do that, you can't package it, obviously!
[04:50] <Legendario> RAOF, they offer a .deb file on the site, but there is a request on LP asking to place it on the universe...
[04:51] <RAOF> Legendario: The .deb file is useless.  We don't do binary uploads, and the binary debs don't contain any information as to how to build them.
[04:51] <Legendario> RAOF, what should i do? Ask the author to include a make file?
[04:51] <RAOF> Are there source packages (as in deb-src) anywhere?  Where is upstream?
[04:52] <RAOF> They obviously can build their source.  All you need is for them to share that state secret :P
[04:57] <Legendario> RAOF, the source is on sourceforge. I guess there is only a source rpm, besides the tar.gz i've downloaded
[04:58] <RAOF> There are other ways of building a project other than make; basically you need to find the "how to build this project" documentation.
[04:59] <Legendario> RAOF, where can it be?
[05:00] <RAOF> I don't know?  On the project's website?
[05:02] <Legendario> RAOF, thanks a lot. i'll see what i can do... gotta go to the bed
[05:47] <superm1> RAOF, I was going to switch to svn co's while fixing all the extra debugging stuff in the package and ran into issues with autotools.  i'll let you know when i get gmyth resolved
[05:49] <RAOF> superm1: If you want some autofoo smashing, I've unfortunately got recent experiecnce with it.
[05:50] <superm1> RAOF, well i'll push what i've got then thus far
[05:50] <superm1> perhaps you'll have some more ideas than I have
[05:50] <RAOF> For reference, you're trying to check out svn, run autogen.sh, and make dist?
[05:50] <superm1> yeah
[05:50] <superm1> that's what the newer get-orig-source does in there now
[05:55] <RAOF> Is there much value in pulling from svn?
[05:55] <superm1> a few fixes that appear may be necessary for trunk usage
[05:55]  * RAOF hunts for a web browser that doesn't crash as soon as I close a load/save dialog.
[05:55] <RAOF> That seems reason enough.
[05:56] <superm1> and ease to add to trunk patches in the next months
[05:56] <superm1> by a simple new get-orig-source
[05:56] <RAOF> Yeah.
[05:56] <superm1> i just uploaded all the trunk stuff today
[05:56] <RAOF> I noticed, both on hardy changes and on my myth box ):
[05:56] <superm1> there is stuff that hasn't cleared NEW though yet
[05:56] <RAOF> Hm.  Not having a good day with smilies.
[05:57] <superm1> i dont want to be a pest, but i hope that archive admins ack the NEW packages sooner rather than later
[05:58] <superm1> i'd like to get the upgrade bugs for people ironed out before FF
[05:58] <superm1> if there are any
[05:59] <RAOF> Where have you pushed the gmyth thingy to?
[05:59] <superm1> revu again
[05:59] <superm1> so whenever that revu cron job pulls it in
[05:59] <RAOF> Ah, right.
[06:00] <RAOF> Hm.  What's the status of libgnomevfs2-mythtv WRT gvfs/gio?
[06:01] <superm1> well it just adds an extra handler for myth:// stuff
[06:01] <superm1> just like a uri handler
[06:01] <superm1> and didn't break anything when i used it
[06:01] <TheMuso> But GNOME is ditching gnome-vfs afaik.
[06:01] <superm1> still worked for now at least.
[06:01] <RAOF> Yes, that's what I was referring to.  Nautilus isn't built against gnomevfs anymore, right?
[06:02] <superm1> well one sec, let me see if its really gstreamer doing the legwork or if that gnome-vfs piece is necessary then
[06:04] <superm1> yeah totem uses that uri handler when you open a recording
[06:04] <superm1> and passes it on to the appropriate gstreamer handler
[06:04] <superm1> (which comes when gstreamer0.10-plugins-bad is rebuilt against gmyth)
[06:05] <superm1> get a cryptic message like this other wise : "The playback of this movie requires a MYTH protocol source plugin which is not installed."
[06:08] <RAOF> Urgh.  Autotooling in the build process is generally considered a Bad Thing (tm)
[06:08] <superm1> no you know what, i spoke preemptively
[06:08] <superm1> i had the wrong build installed
[06:08] <superm1> i'm gonna nuke that other upload for libgnomevfs2-mythtv
[06:08] <superm1> its not needed
[06:08] <RAOF> You only need the gstreamer-mythtv source built & installed?
[06:08] <superm1> its already in the version we have in apt
[06:08] <RAOF> Score!
[06:09] <superm1> ( just needs to be build against gmyth )
[06:10] <RAOF> Why is it += all the way through debian/rules?
[06:10] <superm1> you mean the get-orig-source?
[06:10] <RAOF> Yeah; the variables for it.
[06:11] <superm1> that's just the way i do my get-orig-source targets
[06:11] <superm1> because in some apps i chain more lines together
[06:11] <superm1> and debug that way
[06:11] <superm1> doesn't break anything in the process
[06:11] <RAOF> (It does the wrong thing, incidentally.  It should get the latest version)
[06:13] <superm1> well not necessarily, if someone runs the get-orig-source 5 years from now on this package version, you dont want the latest version
[06:13] <superm1> you want the checkout that was associated with this package version
[06:13] <RAOF> That would be a get-pkg-source target.  Debian policy says get-orig-source gets the *latest* upstream version.
[06:14] <RAOF> (I know that what you've got is useful, it's just not get-orig-source as defined by policy)
[06:14] <superm1> hmph.  then i've been doing these wrong for almost a year :)
[06:14] <RAOF> I'm sure I've had this discussion with someone here before.  Possibly persia?
[06:15] <superm1> but incidently its a two line change in all the apps i use to add the proper rule and checkout either a revision or the latest
[06:15] <superm1> incidentally even
[06:15] <superm1> i'll keep that in mind whenever i'm touching up versions on stuff i've got up already
[06:28] <RAOF> Wow.  libcurl4-gnutls-dev brings in a big bunch of dependencies.
[06:29] <amarillion> Shit. Here I am, waiting three weeks for a review of my package
[06:29] <amarillion> only to have a debian developer come in and do the same package all over again
[06:30] <amarillion> and in the process making mine obsolete
[06:30] <superm1> RAOF, somehow i had most of them already in my apt cache.  sorry in .au :)
[06:31] <RAOF> amarillion: That sucks.  At least the package you're after should get in, though.
[06:31] <RAOF> superm1: Hm.  make distcheck fails.  Awkward.
[06:31] <amarillion> Yeah... but my days of work are practically wasted
[06:32] <superm1> amarillion, but you learned in the process more about packaging that can be applied to other packages hopefully
[06:32] <amarillion> hehe, that's right
[06:32] <RAOF> amarillion: Well, you've almost certainly learned something.  And you can possibly contact the debian maintainer and offer to help maintain it.
[06:33] <amarillion> Yeah... you're right.
[06:33] <amarillion> Sorry, I just needed to complain a bit
[06:33] <RAOF> Certainly.  It *is* annoying.
[06:33] <RAOF> We could perhaps mention that filing a Debian ITP can be a good idea.
[06:34] <RAOF> Or, at least, that since we're going to suggest you get it into Debian anyway you should consider filing an ITP at the start of the process.
[06:41] <amarillion> I knew there was a lesson in this somehow
[06:45] <RAOF> superm1: You don't mind if I mangle get-orig-source/get-pkg-source into something I'd write?
[06:45] <superm1> RAOF, i'd be open to that
[06:45] <superm1> especially if its an improvement
[06:52] <RAOF> Gah.
[06:52] <jdong> superm1: thanks for ipod-convenience :)
[06:52] <RAOF> I don't much feel like wrestling with make tonight.
[06:52] <superm1> glad it works for you :)
[06:52] <jdong> superm1: just worked up the effort to jailbreak and am enjoying it
[06:53] <superm1> jdong, did you jailbreak into 1.1.3?
[06:53] <superm1> or 1.1.2
[06:53] <RAOF> superm1: I'd suggest that, rather than svn-exportng, you run a nice simple "make dist"
[06:54] <superm1> RAOF, okay.  i'm going to trhow a little more effort at fighting this, but i might end up falling back to that
[06:54] <jdong> superm1: 1.1.3
[06:54] <superm1> its gotta be somethign silly for why it wont build
[06:54] <superm1> jdong, any issues with ipod-convenience and symlink locations or anything
[06:54] <jdong> superm1: downgrade to 1.1.1, jailbreakme.com, installer.app now has a streamlined automatic 1.1.3 jailbreaker
[06:54] <superm1> since everything runs as the user mobile instead?
[06:54] <superm1> woah really?
[06:54] <jdong> superm1: yep
[06:55] <superm1> without any computer necessary?
[06:55] <jdong> superm1: right
[06:55] <superm1> wow that's incredible
[06:55] <jdong> superm1: only computer interaction was for the initial 1.1.1
[06:55] <superm1> 1.1.2->1.1.3 too you know?
[06:55] <superm1> or only from 1.1.1
[06:55] <jdong> superm1: see http://rupertgee.wordpress.com/2008/01/26/jailbreak-ipod-touch-113/
[06:56] <jdong> superm1: I believe there's also a 1.1.2->1.1.3 jailbreak in installer.app, but I cannot say for sure
[06:56] <jdong> I haven't tested that path
[06:56] <superm1> if so, i'll be doing that shortly :)
[06:56] <jdong> superm1: at any rate, my only bug I noticed with ipod-convenience...
[06:56] <jdong> superm1: I was bold enough to try to do it all separately, so rhythmbox created a virgin ipod_control structure over sshfs
[06:56] <RAOF> superm1: What build failure are you seeing?  I've just run "./autogen.sh --prefix=/usr && make dist && tar xzvf gmyth-0.4.1.tar.gz && cd gmyth-0.4.1 && ./configure --prefix=/usr && make", and that worked.
[06:57] <jdong> superm1: ipod-touch-mount was not smart enough to detect this scenario and failed to alert me or correct it with a symlink
[06:57] <superm1> RAOF, really?  right at autogen.sh it's failing
[06:57] <RAOF> Hm.  Not for me.
[06:57] <superm1> RAOF, i'll toy it a little more
[06:57] <superm1> maybe i've got a defunct pbuilder here
[06:57] <RAOF> Possible.
[06:58] <superm1> jdong, patches welcome :)
[06:58] <jdong> superm1: haha, when are they not? :D
[06:59] <jdong> superm1: actually, I meant to link to http://rupertgee.wordpress.com/2008/01/30/ijailbreak-method/
[06:59] <jdong> that method is a lot more streamlined
[06:59] <superm1> yeah it is
[07:00] <superm1> no mentions of 1.1.2 ways though
[07:00] <jdong> superm1: I see in installer.app a 1.1.2->1.1.3 entry
[07:00] <jdong> superm1: idn how well it works though :D
[07:00] <superm1> well worst comes to worst, i'll have to dig up a windows disk and setup a vm then to fix things
[07:00] <superm1> but i'm really interested to try this
[07:01] <superm1> i'm gonna run to the car and grab my touch
[07:01] <jdong> superm1: yeah, I'm sure you can do it all from the iPod with a bit of ingenuity
[07:01] <TheMuso> superm1: Have you by chance included the patch from the pulseaudio site to make mythtv's alsa output work with the alsa pulse plugin?
[07:01] <jdong> superm1: as far as I can tell, the 1.1.1->1.1.3 thing is just a sh script using wget, dmg2iso, and a few other tiny hacks
[07:01] <superm1> TheMuso, it should be in trunk now
[07:01] <TheMuso> superm1: Ah ok.
[07:01] <superm1> TheMuso, i've had it in the gutsy and hardy builds for a while
[07:01] <TheMuso> superm1: Ok, just checking.
[07:01] <superm1> and it no longer applied when i switched to trunk today
[07:02] <superm1> TheMuso, pulseaudio and i don't get along though still
[07:02] <superm1> so i'm not able to test for sure
[07:02] <TheMuso> superm1: oh ok.
[07:02] <superm1> she seems to think that i want all audio routed through a usb headset for flash apps, but through my sound card for other apps
[07:02] <superm1> so away with her i said.
[07:03] <jdong> superm1: my first post-jailbreak project: lighttpd+safari based flat-file video browser :)
[07:05] <superm1> next should be installing mobilescrobbler
[07:09] <Aloha> please review http://revu.tauware.de/details.py?package=sadms
[07:09] <superm1> jdong, okay well here we go.  i'll see you on the other side 35-45 min from now :)
[07:10] <jdong> superm1: hahaha
[07:10] <jdong> superm1: NOW you have perfectly usable time to REVU for me!
[07:10]  * superm1 hides
[07:10] <superm1> jdong, what you need?
[07:11] <jdong> superm1: clutch on REVU, need someone to critique it :)
[07:11] <jdong> I'd love to get it in by FF so Hardy users have a modern alternative to torrentflux
[07:11] <superm1> alright i'll take a gander
[07:12] <Aloha> do MOTU's have to get REVUed?
[07:12] <superm1> RAOF, i think i'm missing a build depend on gmyth - and that's the real issue.  it builds on my hardy laptop, but not in the pbuilder
[07:13] <superm1> so it is probably killing autoconf for a really silly/stupid reason
[07:13] <superm1> Aloha, yeah
[07:13] <jdong> Aloha: yes, but we only need one advocating rather than two
[07:13] <jdong> Aloha: btw, I'm reviewing your package at the moment
[07:14] <Aloha> jdong, thank you :)
[07:15] <Aloha> jdong, its my first package attempt on REVU so please highlight stuff that i need to pay attention to in future packages. I used deb helper on that one but i'm learning CDBS lately
[07:15] <dholbach> good morning
[07:15] <Aloha> dholbach, morning!
[07:16] <dholbach> congratulations persia, congratulations nixternal
[07:16] <Aloha> dholbach, even though its only 9:16 at night here
[07:17] <Aloha> persia, nixternal , are you guys MOTU?
[07:17] <dholbach> hey Aloha
[07:17] <dholbach> it's 08:17 in the morning here :)
[07:17] <Aloha> dholbach, are you in france?
[07:17] <dholbach> Germany :)
[07:17] <Aloha> dholbach, gotcha
[07:18] <Aloha> i know france is like 12 hours difference, somewhere around there. i guess so is germany
[07:19] <TheMuso> Except for GNOME being borked after an upgrade, I'm liking hardy.
[07:20] <jdong> Aloha: commented.
[07:20] <Aloha> jdong, thnx
[07:20] <LucidFox> Alooha> persia is a MOTU, don't know about nixternal
[07:20] <dholbach> TheMuso: what's wrong?
[07:20] <dholbach> LucidFox: both are
[07:21] <jdong> Aloha: that should give you a good TODO list for now, I won't guarantee that's all the things that need work, of course :)
[07:21] <LucidFox> ah, yes, I see - just checked on nixternal's LP page
[07:21] <Aloha> jdong, its probably not. thanks for your effort though
[07:21] <Aloha> jdong, what is "boilerplate"?
[07:22] <jdong> Aloha: a generic formatting left by dh_make's sample output
[07:22] <jdong> Aloha: in particular, your package has a single author, so it should just say Author, not Author(s)
[07:22] <Aloha> jdong, understood. thank you
[07:22] <jdong> sure thing
[07:23]  * jdong looks at clock
[07:23] <TheMuso> dholbach: Nautilus crashes with an unexpected error, and panel crashes with fatal error, according to the dialogs that pop up. Mind you this is off my lcal mirror, so may not have the absolute latest updates yet.
[07:23] <jdong> it's 2:23AM. yikes!
[07:23] <superm1> jdong, fsck, it's warning me i'm low on space in the middle of progress.
[07:23] <jdong> superm1: yikes!
[07:23] <superm1> oh man this ain't good ..
[07:23] <dholbach> TheMuso: did you restart your session and everything?
[07:23] <TheMuso> jdong: If you still feel like reviewing, I ask that you give mousetweaks a look over. I've advocated it, and it would be nice to get in for accessibility reasons.
[07:24] <TheMuso> dholbach: Yep the lot. Even whiped the home dir. (fresh install on spare box)
[07:24] <dholbach> TheMuso: URGH!
[07:24] <dholbach> TheMuso: I'm sure seb and pedro will be interested in the backtrace
[07:25] <TheMuso> dholbach: No backtraces so far as I've found, but as I said, I'll give the mirror a while...
[07:25] <dholbach> alright
[07:25] <Aloha> can i delete debian/dirs or is it needed by policy?
[07:25] <jdong> TheMuso: well, it looks good to me, but I don't feel confident enough as a new REVUer to throw it an advocating vote...
[07:25] <TheMuso> jdong: sure.
[07:26] <jdong> and with that, I really need to get off to bed
[07:26] <dholbach> good night jdong
[07:27] <jdong> night dholbach
[07:30] <Coper> hmm good night? :) Here it's 8:30am.
[07:38] <warp10> Good morning
[07:38] <Aloha> warp10, morning!
[07:38] <warp10> Hey Aloha!
[07:41] <Aloha> if i already uploaded to REVU and i'm reuploading a change, should so do debuild -S, or debuild -S -sa?
[07:41] <Aloha> s/so/i/
[08:10] <LucidFox> Aloha> -sa
[08:10] <Aloha> LucidFox, thank you :)
[08:10] <LucidFox> to my knowledge, the orig.tar.gz doesn't get reuploaded to REVU
[08:10] <LucidFox> so you need to always upload it
[08:10] <LucidFox> by the way, jdong, do you feel like reviewing tovid? since it was your initiative in the first place :)
[08:13] <Aloha> LucidFox, i figured that out the hard way ;)
[08:13] <Aloha> LucidFox, its confusing because if you use -sa twice on PPA it rejects it
[08:13] <LucidFox> on PPA, you need to always increment the version number
[08:14] <LucidFox> just like in Ubuntu itself
[08:14] <Aloha> LucidFox, good point
[08:16] <Aloha> LucidFox, <jdong> and with that, I really need to get off to bed
[08:17] <LucidFox> ah, sorry :)
[08:19] <TheMuso> jdong has gone to bed
[08:35] <huats> morning all
[08:36] <Aloha> huats, morning
[08:38] <jekil>  i need a list of all ubuntu default usernames that be setted in /etc/passwd, there is one?
[08:48] <frafu> Hello, could anybody please review mousetweaks: http://revu.tauware.de/details.py?upid=1612 It would be great if it makes it into hardy as the corresponding gui will be in hardy. (new a11y tab of the mouse control panel) And since it already has one advocation, it might not be far from making it into universe. :-)
[08:50] <superm1> is there an easy way to call another rule in cdbs as soon as one finishes?
[08:50] <superm1> just putting the name at the end of the list of commands run in the rule doesn't seem to do it
[08:53] <man-di> superm1: either use "superrule: yourrule anotherrule"
[08:53] <man-di> superm1: or a hack like $(MAKE) anotherrule
[08:53] <man-di> but I would strongly prefer the first
[08:53] <superm1> so superrule is a recognized statement you are saying?
[08:54] <superm1> oh not literally
[08:54] <superm1> i see what you mean
[08:54] <man-di> no, its a name
[08:54] <superm1> oh
[08:54] <man-di> or even better: anotherrule: yourrule
[09:07] <Aloha> jono, hihi!
[09:09] <jono> hey Aloha
[09:11] <superm1> thanks man-di.  i sorted out something similar to anotherrule: yourrule
[09:12] <slomo> siretart: gst-ffmpeg fails to run with ffmpeg from experimental... looks like abi breakage :)
[09:29] <persia> superm1: My apologies.  Prior to the adoption of get-orig-source in Debian policy, I understood it differently, and so instructed you.  RAOF is correct as to policy, which may mean correction of past packages.
[09:30] <persia> jdong: You may be new to REVU, but you've been reviewing packages for suitability for upload for years.  Trust your own judgement when advocating.  Also, get someone else to review clutch: there's still a bunch of packages I haven't looked at yet, and the best packages come from multiple eyes.
[09:30] <superm1> persia, not a big deal.  i've adopted such rules in a lot of packages, so as i come across them when updating them, i'll use the new rule i'm crafting right now that does both get-pkg-source and get-orig-source then
[09:31] <superm1> jdong, i took a look at clutch and left you a small comment on it
[09:35]  * persia asks someone to provide a second review for the advocated java libraries on REVU
[09:35] <superm1> persia, i'm going to head to bed after i finish off the rest of gmyth, but i should be able to do so tomorrow morning if no one else has yet
[09:35] <persia> superm1: That'd be great.  Thanks.
[09:37] <man-di> persia: I really wonder why Marek never sent the java libraries to me for uploading into Debian
[09:38] <persia> man-di: Mostly because he thought you'd be busy, wanted to get things in before Feature Freeze, and they represent only part of the packaging effort.  Please take a look if you have time: sending -1 versions would be fairly easy.
[09:39] <persia> Note that for Debian, they'd still be non-free, and might need some tweaking to use sun-java6 rather than icedtea (unless you already fixed that since I last looked).
[09:53] <man-di> persia: not non-free, but contrib
[09:53] <man-di> if it really doesnt work with java-gcj-compat
[09:55] <superm1> okay i'm finished up with gmyth.  once the revu collector goes around and catches my update it will be available for revu by anyone at http://revu.tauware.de/details.py?package=gmyth  . g'night
[10:03] <vemon> anyone care to revu: http://revu.tauware.de/details.py?package=lashwrap
[10:03] <vemon> probably doesn't need many adjustments since it's been iterated a few times already
[10:04] <LucidFox> persia> icedtea is currently in NEW, the packagers could just wait for it to pass
[10:04] <LucidFox> (in Debian, that is)
[10:07] <persia> man-di: It really doesn't work with java-gcj-compat :(, but yes, contrib.
[10:07] <persia> LucidFox: I'm certain the libraries in question will be sent to Debian shortly after the NEW queue clears.
[10:58] <frafu> Could anybody please review the mousetweaks package: http://revu.tauware.de/details.py?upid=1612 (it is the complement of the mouse accessibility tab that has now appeared in hardy)
[10:59] <minghua> Is mousetweaks the new module in GNOME 2.22?
[11:02] <smarter> morning everyone (:
[11:04] <smarter> Could someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer (all the issues raised have been addressed)
[11:07] <frafu> minghua: asthe mousetweaks module has been accepted for GNOME 2.22, its gui has been split from the module integrated in the mouse control panel (gnome control center). However, I have been told that the corresponding module (that does the job) has to pass revu and afterwards the main inclusion process to also arrive in Ubuntu. Is this what you were asking?
[11:08] <frafu> minghua: that is what I am trying to do
[11:08] <minghua> frafu: Yes that's what I'm asking, and I think it makes more sense for a desktop team member (who deals with gnome-control-center) to review the package, then.
[11:08] <minghua> frafu: Are you a member of desktop team?
[11:10] <frafu> minghua: No, I am not a member of the desktop team.
[11:11] <frafu> minghua: is seb128 not a member of the desktop team? It is seb128 that told me to go the revu and mir route?
[11:12] <minghua> frafu: I'm pretty sure he is.  If he told you to go through the MIR route this way, it's fine.
[11:14] <frafu> minghua: ok
[11:41] <LucidFox> Hmm, so alpha 4 has not been released yet?
[11:43] <persia> LucidFox: Soon...  It's still not very much into Thursday in Portland :)
[11:44] <LucidFox> That's what I thought :)
[11:53] <warp10> Hi all!
[12:07] <siretart> slomo: could you please elaborate (testcase, how to reproduce) in a bugreport please?
[12:13] <shibata> Hi, all.
[13:15] <dcordero> hi
[13:29] <tuxmaniac> can someone please review http://revu.tauware.de/details.py?package=alliance
[13:31] <warp10> I am having a weird problem with dget -x and dpkg-source -x: they freeze while building the source tree. The only thing I can do is ctrl+c. Any hint?
[13:34] <dcordero> warp10, dpkg -x give you the package extracted. Why do you use dpkg-source -x then?
[13:35] <warp10> dcordero: If I use dpkg-x, it downloads the files fine, then when it should build the tree it freezes. If I ctrl-c it and try to build the tree by-hand with dpkg-source -x, it freezes anyway
[13:36] <warp10> and this happen both with native and non-native packages, coming from both debian and ubuntu
[13:36] <warp10> s/dpkg -x/dget -x
[13:41] <shibata> warp10: Do you apply dget -x to dsc file?
[13:42] <warp10> shibata: I do, of course. It worked fine up to a few minutes ago, I was working on some syncs. Now it doesn't work anymore :S
[13:43] <persia> warp10: Check your I/O load while you unpack: there may be a disk, memory, or similar type of issue causing the block or hang.
[13:44] <soren> strace ftw
[13:45] <warp10> persia: cpu and memory stay low, hard disk doesn't work at all
[13:46] <geser> warp10: does it perhaps want to fetch the gpg key to verify the dsc signature?
[13:46] <warp10> soren: mmm... maybe I found it with strace
[13:46] <persia> warp10: One of the following is true: 1) I don't understand your phrasing, 2) You have so much RAM in comparison to the package size that you need tools with finer granularity to see the issue, 3) your hard drive is broken.
[13:46] <warp10> it hangs on read(3, "gpg: waiting for lock (held by 1"..., 4096) = 58
[13:48] <warp10> It could a be a gpg issue, since thunderbird freezes when I open an encrypted e-mail
[13:48] <warp10> I tought they could be two different problems, probably there is a common cause
[13:49]  * persia hasn't seen a recent gpg update, and is confused
[13:49]  * warp10 is a little confued too :S
[13:50] <geser> warp10: kill all running gpg and try again
[13:51] <warp10> geser: I tried: doesn't work :(
[13:53] <minghua> warp10: Any gpg-agent stuff running?
[13:53] <persia> warp10: check lsof for ~/.gnupg
[13:53] <warp10> minghua:  killed it as well
[13:55] <warp10> persia: "lsof | grep gnupg" doesn't anything
[13:55] <warp10> doesn't show anything
[13:55]  * minghua is surprised not to find any way to tell dpkg-source skip the signature checking.
[13:56] <minghua> I think you can always strip the signature from the .dsc first, then run "dpkg-source -x".
[13:56] <zul> jdong: ping
[13:58] <geser> warp10: after you killed all running gpg, have you checked for remaining lockfiles and removed them manually?
[14:01] <warp10> minghua: your solution works indeed. geser I removed a lock file in ~/.gnupg and now it works fine :)
[14:03]  * warp10 is happy he can work again on packages :)
[14:06] <\sh> nixternal, persia congrats :)
[14:07] <persia> \sh: Thanks.
[14:08] <\sh> hmmm...is it a normal way that debian/<packagename>.substvars is disappearing when building a source package?
[14:08] <jdong> zul: pong
[14:09] <jdong> LucidFox: I'll take a look at tovid sometime today
[14:09] <zul> jdong: gimme a sec..
[14:09] <zul> oh yeah is #160106 actually been worked on?
[14:09] <zul> for hardy at least
[14:10] <LucidFox> jdong> Thanks!
[14:10] <zul> jdong: https://bugs.edge.launchpad.net/ubuntu/+source/iscsitarget/+bug/160106
[14:10] <ubotu> Launchpad bug 160106 in iscsitarget "/etc/init.d/iscsitarget broken with migration to /bin/dash" [Low,In progress]
[14:11] <persia> zul: Please send the bug number rather than pasting the bug URL for those of us not members of the launchpad-beta team.
[14:11] <jdong> zul: good question; I haven't been following that bug lately
[14:12] <zul> persia: sorry
[14:12] <jdong> seems like, as always, persia was the driving force behind the bug :D
[14:12]  * persia just happened to be the sponsor that caught it.
[14:13] <persia> I haven't heard from Alvin in quite a while.  Note that the solutions for gutsy and hardy are completely different, as the API change was reverted for .24
[14:13] <jdong> persia: based on your judgement do you think alvin intends to continue the work?
[14:13] <zul> persia: i already ported it to 2.6.24 because its going into linux-ubuntu-modules
[14:13] <jdong> I mean, I'd be happy to pick up where he left off, but I'd hate to steal a sponsorship opportunity from him...
[14:14] <persia> jdong: I don't.  He was interested before, but after the random QA Comment, seemed to disappear.
[14:14] <minghua> : Yes.  I believe dh_clean deletes it.
[14:14] <minghua> \sh: ^^
[14:14] <zul> basically its suppose to be going into main so I want to get it into shape
[14:15] <\sh> minghua, grmpf....
[14:15] <persia> zul: Ported?  I thought the number of arguments was the same for feisty and hardy.  Anyway, cool.
[14:16] <\sh> minghua, well, I don't read anything about <package>.substvars..just debian/files
[14:16]  * jdong runs the attached diff.gz through interdiff
[14:17] <persia> jdong: Maybe send him a quick email, and if you don't hear back by the weekend, submit a candidate to another member of ~motu-sru?
[14:17] <\sh> grmpf-..
[14:18] <\sh> minghua, forget about that..found the bugger...it's dh_clean and it looks like that I mistakenly read dpkg-gencontrol totally wrong
[14:18] <minghua> \sh: I believe *.substvars count as "any detritus left behind by other debhelper commands"
[14:18] <\sh> minghua, yepp..
[14:19] <jdong> persia: hmm why does he have two different init files to install?
[14:19] <minghua> Okay.  (And you don't need a *.substvars in source package anyway.)
[14:19] <\sh> minghua, I need it :)
[14:19] <jdong> persia: All I saw wrong were three s/==/=/ bashisms
[14:19] <minghua> \sh: Use a different name. :-)
[14:19] <\sh> minghua, wine has shlibs:Depends in its debian/control
[14:20] <\sh> minghua, but ia32-libs shlibs handling is broken for some ia32 libs so I need to set it manually for amd64
[14:20] <persia> jdong: He cp'd Debian's to Ubuntu, and edited Ubuntu, to support bash in Debian and dash in Ubuntu.  In external communication, I asked him to consolidate, but I'm not sure he did.  Please don't use all of that :)
[14:21] <minghua> \sh: Well, hardcoded debian/*.substvars doesn't sound like the proper solution to me.
[14:21] <minghua> Or even the correct workaround.
[14:21] <\sh> minghua, dh_gencontrol -- -V helps
[14:22] <persia> jdong: My memory is vague, but I think that was it.  Setting it up to have two different init files was an overengineered solution :)
[14:25] <jdong> persia: haha ok I'll do it cleaner :)
[14:26] <zul> persia and jdong: thanks i appreciate it
[14:27] <jdong> zul: sure. Thanks for your kernel-foo for the other side of the bug :)
[14:27] <zul> no problem
[14:27] <jdong> persia: he also changed restart|force-reload) to restart) in a case clause.... the former should be sh-complaint, no?
[14:28] <jdong> seems to work locally
[14:29] <\sh> well..wine is building again..time to take a shower :)
[14:29] <jdong> \sh: should give you time for a really nice shower :D
[14:30] <jdong> speaking of long builds... did I ever remember to upload that thing kano was bugging me about?
[14:31] <\sh> jdong, ;)
[14:34] <Lutin> geser: forgot to Cc you, but I answered debian 447248
[14:34] <ubotu> Debian bug 447248 in fusd-kor "fusd-kor - FTBFS: failure: cannot read files list file: No such file or directory" [Serious,Open] http://bugs.debian.org/447248
[14:38] <neuroStuMIT> Is this the place to ask questions about making .deb files?
[14:39] <geser> Lutin: are you going to upload the fixed package to hardy?
[14:40] <geser> neuroStuMIT: yes
[14:41] <RainCT> Heya
[14:41] <neuroStuMIT> well the the package I am tyring to make is not for the general ubuntu population
[14:41] <geser> Hi RainCT
[14:41] <neuroStuMIT> its some highly speciallized software that we use for research
[14:42] <Lutin> geser: I'll wait a couple days to see if the maintainer reacts, and if not I'll upload
[14:42] <geser> neuroStuMIT: I guess there is already other specialised software in the archive, so this shouldn't be blocking it
[14:43] <geser> Lutin: thanks
[14:43] <neuroStuMIT> ok...  well I am first just trying to figure out how to build the deb file
[14:43] <jdong> whoa, ubuntu's upload queue accepts duplicate orig.tar.gz's?
[14:43] <neuroStuMIT> i have followed just about every walkthrough i can find including https://wiki.ubuntu.com/PackagingGuide/Basic
[14:44] <jdong> I accidentally did a -S -sa and was just about to re-upload proper packaging when I got an accepted mail
[14:44] <ScottK2> jdong: It does.
[14:45] <jdong> cool
[14:45] <ScottK2> jdong: Also (if I understand the backscroll correctly) do keep in mind that dash as default shell is a release goal for Lenny, so Debian stuff should be bashism free too.
[14:45] <jdong> now it'll bork out if my orig.tar.gz wasn't the sme as the one in the archive, right?
[14:45] <jdong> ScottK2: yeah I made the init script bashism-free
[14:45] <ScottK2> Great.
[14:46] <jdong> neuroStuMIT: hey, another MIT student!
[14:46] <geser> neuroStuMIT: where are you stuck?
[14:46] <neuroStuMIT> i'm not sure
[14:46] <frafu> Hello RainCT: Yesterday your advocation of mousetweaks ( http://revu.tauware.de/details.py?package=mousetweaks ) went to the upload of 20h40 instead of the upload of 21:40. So I suppose that I need another advocation from you or somebody else for 21h40?
[14:46] <slangasek> jdong: IIRC, if it wasn't the same orig.tgz it gets rejected up front
[14:46] <neuroStuMIT> but right now I have a .dsc file and I am trying to run pbuilder
[14:47] <neuroStuMIT> and it says I don't have boostlib >=1.34 but I do i have already run $sudo apt-get install libboost*
[14:47] <neuroStuMIT> yes i'm at mit
[14:47] <RainCT> frafu: I know, there was some problem with REVU
[14:47] <RainCT> :S
[14:47] <RainCT> frafu: I tried 3 times an all got to the previous upload (deleted the after that)
[14:47] <geser> neuroStuMIT: pbuilder uses a clean chroot build from the created base.tgz everytime you use it
[14:48] <ScottK2> RainCT: Then I'd leave a comment to the effect that you advocate the later upload so it's clear.
[14:48] <geser> neuroStuMIT: you need to list the correct libboost*-dev packages in Build-Depends in debian/control
[14:48] <jdong> neuroStuMIT: what year are you
[14:48] <geser> pbuilder will install them then before trying to build your package
[14:49] <neuroStuMIT> i'm a 1st year grad student.
[14:49] <jdong> neuroStuMIT: cool. I'm a 2nd year undergrad :)
[14:49] <neuroStuMIT> I've only been using linux for about 4 months so if you can explain a little more
[14:49] <geser> jdong: so you could do local support?
[14:49] <jdong> geser: haha
[14:49] <jdong> geser: unfortunately (or fortunately?) I'm not local ATM :)
[14:49] <neuroStuMIT> ha ha
[14:50] <frafu> RainCT: yes, you told me yesterday that there was a bug. I am asking because I wonder whether I have to ask for another review!?
[14:50] <RainCT> frafu: no, I'll upload it :)
[14:51] <frafu> RainCT: ah, ok
[14:51] <neuroStuMIT> so if the package i am trying to make into a deb file has an autogen.sh and configure scripts that are used to create a make file do I have to run those to create the make file?
[14:51] <neuroStuMIT> when I am trying to package?
[14:51] <geser> neuroStuMIT: yes
[14:51] <RainCT> To upload a package from REVU, do I need to "debuild -S -k<...>" it or can I just upload it directly?
[14:52] <geser> RainCT: you need to re-sign them
[14:52] <frafu> RainCT: thanks. ;-)
[14:53] <LucidFox> frafu> Congratulations with passing REVU! :)
[14:53] <neuroStuMIT> so how do I list the corret libboost*-dev packages in the Build-Depends ?
[14:54] <geser> neuroStuMIT: when build in a pbuilder your packages sees only what's installed inside the pbuilder and this is usually only the a minimal system
[14:54] <rulus> Can someone have a look at gtkvd (http://revu.tauware.de/details.py?package=gtkvd)? It should be ready for advocation :) Thanks!
[14:54] <neuroStuMIT> the only thing listed under Build-Depends is debhelper >=5
[14:54] <geser> neuroStuMIT: a chroot is an small "embedded" system
[14:54] <frafu> LucidFox: thanks; it is first :)
[14:55] <frafu> package that I submitted
[14:55] <geser> neuroStuMIT: so you need to add the boost packages you need to build (the -dev packages as you need the headers) separated with ,
[14:55] <neuroStuMIT> ok
[14:55] <neuroStuMIT> i'll try that out
[14:55] <LucidFox> frafu> Well, there's still NEW
[14:56] <LucidFox> although pitti usually gives NEW major cleanups on Fridays, so you probably won't have to wait for too long
[14:58] <RainCT> frafu: Uploaded. Gratz :).
[15:00] <frafu> LucidFox: Do you mean by NEW that it is in the queue of new packages and that it has to pass the archive admins review? Friday?
[15:00] <geser> jdong: have you an idea why the transmission backport for gutsy for i386 is still in NEW and the one for amd64 is already published?
[15:00] <neuroStuMIT> ok so I added the boostlib (>= 1.34.1) to the dependencies and now it get: Build dependencies/conflicts unsatisfied; aborting.
[15:01] <neuroStuMIT> sorry if this stuff is really rudimentary if this isn't the place to get support let me know
[15:01] <LucidFox> frafu> yes
[15:01] <LucidFox> https://launchpad.net/ubuntu/hardy/+queue
[15:01] <geser> neuroStuMIT: you need to list the package like it is in the used in the archive
[15:02] <frafu> RainCT: thanks, and congratulations to you for your (I suppose) second upload. :)
[15:02] <LucidFox> hmm, I don't see mousetweaks in the queue
[15:03] <frafu> LucidFox: thanks for the link
[15:03] <zul> jdong: thanks
[15:05] <jdong> geser: no idea :( Perhaps poke an archive admin?
[15:06] <sistpoty|work> hi folks
[15:07] <geser> Hi sistpoty|work
[15:07] <sistpoty|work> hi geser
[15:07] <ScottK2> Hello sistpoty|work
[15:07] <sistpoty|work> hi ScottK2
[15:07] <ScottK2> neuroStuMIT: This is the right place.
[15:07] <jdong> sistpoty|work: there was something I wanted to tell you.... but forgot....
[15:08] <sistpoty|work> jdong: heh... maybe regarding revu and the reload-thingy?
[15:08] <jdong> sistpoty|work: WOW you're psychic!
[15:08] <sistpoty|work> *g*
[15:08] <jdong> sistpoty|work: but then I also remembered after not finding you here, I put my comments on vorian's bug ticket
[15:08] <jdong> so all's well :)
[15:10] <neuroStuMIT> ok so when I run dh_make it says "Please edit the files in the debian/ subdirectory now. <PackageName> uses a configure script, so you probably do't have to edit the Makefiles.
[15:10] <sistpoty|work> jdong: saw that... it needs some rewriting, not too sure when I've finished it... but the plan is to accept the comment and then set the location in the header to a clean page (at least I vaguely recall that it should be done that way)
[15:10] <neuroStuMIT> what kind of edits is this refering to?
[15:10] <sistpoty|work> neuroStuMIT: as in install into a different location than the default
[15:11] <\sh> ok...one more wine build for i386 to check that I didn't break i386 and then upload
[15:12] <neuroStuMIT> sistpoty|work: would that edit be in the rules file?
[15:12] <sistpoty|work> neuroStuMIT: no.. let me try to explain
[15:13] <sistpoty|work> neuroStuMIT: you'll have to edit the rules file anyway
[15:13] <sistpoty|work> neuroStuMIT: however all sane upstream packages will install themselves to somewhere under /usr/local if you call "make install"
[15:14] <sistpoty|work> neuroStuMIT: if you want to build a debian package, you'll need to change this path to somewhere like ./debian/somewhere
[15:14] <sistpoty|work> neuroStuMIT: so that it will get picked up and get put in the package
[15:14] <sistpoty|work> neuroStuMIT: hence I guess the "edit" is referring to upstreams Makefile to adjust pathes there
[15:15] <sistpoty|work> neuroStuMIT: which you don't need to do with a package using autotools (i.e. having a configure)
[15:15] <ScottK2> slangasek: I'm working on updating heimdal and cyrus-sasl2-heimdal from libdb4.2 to something vaguely modern.  Unfortunately, cyrus-sasl2-heimdal needs the exact same binary version as cyrus-sasl2, so I was wondering if (after the alpha) you would sponsor a no change cyrus-sasl2 upload so we're in sync?
[15:15] <sistpoty|work> neuroStuMIT: because you can simply change the path it will install to via ./configure --prefix=somedir/usr
[15:16] <neuroStuMIT> so I need to run ./configure that comes with the src but I need to change the folder where everything gets built to somehting like ~/package/debian/something
[15:17] <slangasek> ScottK2: hrm, are you saying that the versions of the cyrus-sasl2 and cyrus-sasl2-heimdal binaries need to be the same?
[15:17] <RainCT> frafu: third :)
[15:17] <ScottK2> Yes
[15:17] <sistpoty|work> neuroStuMIT: where it gets installed, but yes
[15:17] <slangasek> ScottK2: maybe we should fix that instead :)
[15:17] <RainCT> frafu, LucidFox: ok, now it's really uploading :P
[15:17] <neuroStuMIT> ok let me work on this for a while. Thanks
[15:17] <sistpoty|work> np
[15:18] <ScottK2> slangasek: OK.  Let me look into that then.
[15:19] <geser> slangasek: cyrus-sasl2-heimdal uses ${binary:Version} to specify a dependency on packages build by cyrus-sasl2
[15:19] <slangasek> geser: which is clearly wrong since they're not from the same source package...
[15:19] <neuroStuMIT> so do I need to run make before I package
[15:19] <neuroStuMIT> ?
[15:19] <frafu> RainCT: so I am still part of the first trilogy;)
[15:20] <sistpoty|work> neuroStuMIT: no, you run make during the package builds (from debian/rules)
[15:21] <neuroStuMIT> ok so dh_make runs make?
[15:22] <\sh> neuroStuMIT, nope..it creates the debian/ dir framework inside your source tree
[15:22] <RainCT> frafu: heh. it's in the queue now :)
[15:23] <neuroStuMIT> so then I wouldn't want to use ~/package/debian/install as the dir for the configure script?
[15:24] <\sh> neuroStuMIT, nope...:)
[15:24] <frafu> RainCT: cool B-)
[15:24] <jdong> sistpoty|work: that sounds like a reasonable solution
[15:24] <geser> slangasek: is there any easy way to fix it without adding a big Ubuntu delta?
[15:25] <sistpoty|work> jdong: it's anyway cleaner to separate actions (as in add comment) and display pages functionality... but it needs some rewriting :(
[15:26] <jdong> sistpoty|work: yeah :( I feel your pain
[15:26] <sistpoty|work> heh
[15:31] <sistpoty|work> nixternal and persia: congrats!
[15:34] <neuroStuMIT> so I am getting some linker erros
[15:34] <neuroStuMIT> errors
[15:35] <neuroStuMIT> when I run dpkg-buildpackage -rfakeroot it gives me errors with libboost
[15:36] <slangasek> geser: sure, thwapping the Debian maintainer to not abuse ${binary:Version} :)
[15:36] <RainCT> nxvl, nxvl_work: hi, why is u-u-s subscribed to bug 181362?
[15:36] <ubotu> Launchpad bug 181362 in pypy "pypy FTBFS" [Medium,Incomplete] https://launchpad.net/bugs/181362
[15:37] <nxvl_work> RainCT: https://bugs.edge.launchpad.net/ubuntu/+source/pypy/+bug/181362/comments/1
[15:37] <ubotu> Launchpad bug 181362 in pypy "pypy FTBFS" [Medium,Incomplete]
[15:38] <RainCT> nxvl_work: but https://bugs.edge.launchpad.net/debian/+source/pypy/+bug/181362/comments/4, and anyway the bug has not enough information for a sync request (changelog and such are missing)
[15:38] <ubotu> Launchpad bug 181362 in pypy "pypy FTBFS" [Medium,Incomplete]
[15:40] <neuroStuMIT> how do I add libboost to the dependencies in the debian/control file?
[15:40] <sistpoty|work> neuroStuMIT: did you try to compile the package as is beforehand? That's usually a good start to see if/where there might be problems or if anything else works ok
[15:40] <sistpoty|work> neuroStuMIT: erm... I meant just compile what you want to package by hand...
[15:40] <nxvl_work> RainCT: those are on the duplicate https://bugs.edge.launchpad.net/ubuntu/+source/pypy/+bug/185713
[15:40] <ubotu> Launchpad bug 185713 in pypy "Please sync pypy 1.0.0-svn50146-2 (universe) from Debian unstable (main) (dup-of: 181362)" [Undecided,New]
[15:40] <ubotu> Launchpad bug 181362 in pypy "pypy FTBFS" [Medium,Incomplete]
[15:41] <neuroStuMIT> I've already got the packaged installed and working on several machines.
[15:41] <neuroStuMIT> including the machine I'm using to make the deb
[15:43] <sistpoty|work> neuroStuMIT: you'll need to add libboost-dev to Build-Depends: in debian/control (though that doesn't explain why it won't work from dpkg-buildpackage)
[15:44] <neuroStuMIT> what would be causing the dpkg-buildpackage to fail?
[15:45] <neuroStuMIT> rather what could
[15:46] <jdong> well... anything.
[15:46] <jdong> what part is failing?
[15:46] <sistpoty|work> neuroStuMIT: s.th. wrong in debian/rules for example... the difference is, that dpkg-buildpackage will build the package in the environment of your system (i.e. can use every package that you've got installed there), while pbuilder will work in a clean chroot and only install what's in build-depends
[15:47] <neuroStuMIT> .libs/libsomanetwork_1_0_la-fakenetwork.o: In function `~TSPipeFifo':
[15:47] <neuroStuMIT> /home/acq/deb/network-0.1.0/src/tspipefifo.h:34: undefined reference to `boost::mutex::~mutex()'
[15:47] <neuroStuMIT> /home/acq/deb/network-0.1.0/src/tspipefifo.h:34: undefined reference to `boost::mutex::~mutex()'
[15:47] <jdong> neuroStuMIT: whoa, use pastebin for that
[15:47] <jdong> !paste
[15:47] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[15:48] <neuroStuMIT> ok sorry
[15:49] <neuroStuMIT> here's a full log
[15:49] <neuroStuMIT> http://paste.ubuntu-nl.org/54224/
[16:00] <neuroStuMIT> any help?
[16:01] <\sh> neuroStuMIT, looks like you need a newer boost somehow?
[16:02] <neuroStuMIT> but i have tried running $sudo apt-get install libboost*
[16:02] <neuroStuMIT> i'm also running to most up to date version of gutsy
[16:03] <\sh> neuroStuMIT, na.the version in the archive is older then that what you need, i mean
[16:03] <geser> neuroStuMIT: looks like it's missing some #include in the sources
[16:03] <\sh> or what geser said, broken source
[16:04] <neuroStuMIT> but the weird thing is that I have made and installed the source before
[16:04] <neuroStuMIT> on the same machine
[16:06] <neuroStuMIT> let me try something
[16:09] <LucidFox> jdong> Wait a minute... ffmpeg in Ubuntu doesn't depend on libfaac and libx264, does it?
[16:10] <jdong> LucidFox: I don't know what I was thinking when I put that :D
[16:10] <neuroStuMIT> ok I guess it just worked... nevermind.. THANK YOU SO MUCH!
[16:10] <LucidFox> ffmpeg (3:0.cvs20070307-5ubuntu5) hardy; urgency=low
[16:10] <LucidFox>   * Rebuilt against new libx264
[16:10] <LucidFox>  -- Anthony Mercatante <tonio@kubuntu>   Sun, 02 Dec 2007 21:20:07 +0100
[16:11] <LucidFox> ^ x264 isn't even in build-depends... what was he rebuilding against? :)
[16:11] <jdong> lu	I guess he made the exact same mistake as me
[16:11] <LucidFox> heh
[16:11] <jdong> LucidFox: that is, he has medibuntu enabled, and typed apt-cache rdepends....
[16:12] <\sh> phew...wine is working again...
[16:12] <LucidFox> I think this double ffmpeg issue should be rectified at least in hardy+1, if it's too late to fix in hardy
[16:15] <ScottK2> slangasek: The fundamental probelm between cyrus-sasl2 and cyrus-sasl2-heimdal is that they come out of the same upstream tarball, but are split into two source packages.  Not sure what to do about that.
[16:15] <jdong> LucidFox: yea, though IANAL to understand why we have to strip source code of mpeg4 encoders
[16:17] <jdong> superm1: hey you around? how's your videotranscoding-foo?
[16:18] <slangasek> ScottK2: why should they need such a strict versioned dependency anyway, though?  what's supposed to change in a Debian point revision that could make them incompatible?
[16:19] <neuroStuMIT> sorry one more stupid question
[16:19] <ScottK2> slangasek: I'm not sure.  It's not like it's in there by accident (the Debian maintainer put in a lintian over-ride for it).
[16:19] <neuroStuMIT> once I have my .deb file I can install it with dpkg -i <packagename>.deb right? Well how do I check to see where the package iwll be installed?
[16:20] <neuroStuMIT> ok that was technically 2 questions
[16:20] <slangasek> ScottK2: yeah, I still think this is the wrong way to go about it
[16:20] <ScottK2> Given it's been years since an upstream release, I'm guessing the risk of relaxing the dependency is low.
[16:20] <minghua> neuroStuMIT: dpkg-deb --contents <foo>.deb
[16:20] <ScottK2> slangasek: I agree, but don't really feel like reworking the whole mess just to get off of libdb4.2
[16:21]  * ScottK2 decides to return to his sick bed and take a nap.
[16:23] <slangasek> ScottK2: fair enough
[16:24] <neuroStuMIT> ok so if stuff isn't installing where I want it to install what do I edit to change that?
[16:24] <nixternal> thanks everyone </stuffy headed voice> :)
[16:31] <geser> neuroStuMIT: set the correct prefix when calling configure in your debian/rules (or whatever is needed to convince it to install in the correct location)
[16:32] <neuroStuMIT> so the rules file tells it where to install not something in the source?
[16:45] <geser> neuroStuMIT: not directly, it's in the source Makefile but can be often configured when calling the configure script (e.g. in debian/rules)
[16:46] <\sh> oh people, why can't we stop sending mails about the kmos issue...it's getting into a religious debate :(
[16:48] <neuroStuMIT> so i have a line that looks like $(MAKE) DESTDIR=$(CURDIR)/debian/<packagename> install
[16:48] <neuroStuMIT> that is in the install:build section
[16:48] <neuroStuMIT> is that what i need to change?
[16:49] <geser> neuroStuMIT: do you need to call configure or a similar script before building?
[16:49] <neuroStuMIT> yes I do
[16:52] <sistpoty|work> interesting hostname, freeflying ;)
[16:53] <\sh> sistpoty|work, indeed ;)
[16:53] <geser> neuroStuMIT: does the configure accept --prefix=something (probably --prefix=/usr)?
[16:54] <neuroStuMIT> let me check
[16:55] <geser> neuroStuMIT: if it doesn then modify your configure call in debian/rules to specify the --prefix you want it to install
[16:58] <neuroStuMIT> some if I want the binaries to end up in /usr/bin/ and the libs to end up in /usr/lib/ do I just specifiy /usr/ as the prefix?
[16:59] <neuroStuMIT> ok so configure does take a --prefix=something
[16:59] <Hobbsee> hurrah.  just what we need.  MOTU being compared to witch burning.  *sigh*
[16:59] <geser> neuroStuMIT: yes, as the other use $prefix/bin/ and $prefix/lib/ as default for the install destination
[17:00] <Hobbsee> from a place called "religious tolerance", no less.
[17:00]  * sistpoty|work tries hard to resist to reply
[17:00] <neuroStuMIT> ok so what do I need to edit as configure takes the --prefix=/usr/  ?
[17:01] <Hobbsee> sistpoty|work: something about ubuntu not being a religion?
[17:01] <geser> neuroStuMIT: can you pastebin your current debian/rules?
[17:02] <sistpoty|work> Hobbsee: no, i just try to resist to reply to that mail
[17:02] <Hobbsee> sistpoty|work: obviously, but i'm trying to figure what youd' reply, if you were to
[17:03] <neuroStuMIT> http://paste.ubuntu-nl.org/54235/
[17:04] <sistpoty|work> Hobbsee: well, I won't tell, otherwise I could just reply on the ML :P
[17:04] <Hobbsee> hehe
[17:04]  * Hobbsee really doesn't care anymore, but still thinks that's slightly over teh top
[17:05]  * sistpoty|work just wants the good old times back, where motu stuff was just big fun (and I could stay up all night and sleep half of the day *g*)
[17:05] <Hobbsee> that would be nice
[17:06] <LucidFox> sistpoty|work> good old times?
[17:07] <sistpoty|work> LucidFox: yeah...*getting nostalgic* *g*
[17:07] <sistpoty|work> as in breezy or dapper
[17:07] <sistpoty|work> +cycle
[17:08] <geser> neuroStuMIT: so you currently don't call configure in your debian/rules? Try adding "./configure --prefix=/usr" after line 26
[17:09] <neuroStuMIT> ok
[17:09] <neuroStuMIT> so when I run dpkg does that run configure?
[17:09] <neuroStuMIT> or do I have to run configure befor I run dpkg
[17:09] <geser> sistpoty|work: what stops you to stay up the whole night and sleep during the day?
[17:10] <sistpoty|work> geser: just look at my nick, after the | ;)
[17:10] <geser> neuroStuMIT: it will be called during the build as it's a dependency on the build target
[17:10] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[17:11] <geser> sistpoty|work: change to the night shift :)
[17:12] <sistpoty|work> heh
[17:12] <\sh> ok..since I'm starting my new work tomorrow morning, I'm trying to get as many merges/syncs as possible into our archive this evening until my wife comes ;)
[17:13] <LucidFox> Aloha> looking
[17:13] <Aloha> LucidFox, thank you :)
[17:18] <neuroStuMIT> geser: Awesome that worked. Thanks so much!
[17:19] <LucidFox> Aloha> commented
[17:19] <Aloha> LucidFox, thank you :)
[17:26] <Aloha> https://wiki.ubuntu.com/BuildingCommunity/TeamReporting
[17:26] <Aloha> oops wrong chan window sorry
[17:26] <LucidFox> heh
[17:26] <Aloha> bddebian, hi :)
[17:27] <geser> Hi bddebian
[17:27]  * RainCT is also checking sadms :)
[17:27] <sistpoty|work> hi bddebian
[17:27] <bddebian> Heya gang
[17:27] <bddebian> Hi Aloha, geser, sistpoty|work
[17:28] <RainCT> hi bddebian
[17:28] <bddebian> Heya RainCT, congrats! :-)
[17:28] <RainCT> bddebian: thanks :)
[17:31] <LucidFox> RainCT> Do you happen to need some practice in sponsoring interdiffs?
[17:31] <LucidFox> :)
[17:31] <neuroStuMIT> Everybody thanks again
[17:31] <jdong> LucidFox: that's a nice way of putting it :D
[17:32]  * jdong looks for a main sponsor too
[17:32] <LucidFox> jdong> yes, I saw :)
[17:32] <jdong> any core-dev need some practice dgetting? :D
[17:32] <LucidFox> for transmission
[17:32] <RainCT> LucidFox: hm.. yes :P
[17:32] <RainCT> heh
[17:34] <LucidFox> you could look at bug #187576 - the package is simple enough, and the changes are mostly trivial
[17:34] <ubotu> Launchpad bug 187576 in smplayer-themes "Upgrade to smplayer-themes 0.1.15" [Wishlist,Confirmed] https://launchpad.net/bugs/187576
[17:36] <RainCT> LucidFox: how can I get the (uncompressed) source?
[17:37] <jdong> RainCT: I'm guessing it has a watchfile or debian/rules file for doing so
[17:37] <LucidFox> yes, there is get-orig-source
[17:38] <LucidFox> you should first reconstruct the diff.gz and from it, the debian/ directory, using instructions here: https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff
[17:38] <LucidFox> after that, you can use debian/rules get-orig-source
[17:38] <RainCT> alright, thanks :)
[17:38] <\sh> hmmm..libfaad is back to universe, so we can build against it without having an issue, right?
[17:38] <LucidFox> universe? o_O
[17:39] <\sh> Filename: pool/universe/f/faad2/libfaad2-0_2.6-1_all.deb
[17:39] <LucidFox> hmm... libmad is in main o_O
[17:39] <\sh> Filename: pool/universe/f/faad2/libfaad0_2.6-1_amd64.deb
[17:40] <\sh> who is pedro fragoso <emeberez@gmail.comcom> ???
[17:41] <\sh> ah ember_
[17:41] <\sh> ember_, ping mpd :)
[17:42] <\sh> ah the changes came from gutsy these days...
[17:44] <paas> Hi all, I've read through the online lesson about packaging shared libraries, which is great btw, and I've uploaded my first shared library package. Does anybody want to review it, thanks in advance, http://revu.tauware.de/details.py?package=libtuxcap
[17:45]  * minghua sees CMake and CDBS and stays away.
[17:51] <\sh> ember_, I've updated bug #187392 if you want to have your name tag on this upload, please :)
[17:51] <ubotu> Launchpad bug 187392 in mpd "Please merge mpd 0.13.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/187392
[17:52] <paas> minghua: didn't mean to scare you :-)
[17:52] <\sh> persia, please add me to universe-sponsors pls :)
[17:53] <Aloha> what are the role of universe sponsors?
[17:54] <sistpoty|work> Aloha: to sponsor uploads (updated packages, bug fixes) for universe
[17:54] <Aloha> sistpoty|work, how does that differ from advocating?
[17:55] <minghua> Advocating doesn't involve actual uploading.
[17:55] <sistpoty|work> Aloha: advocating happens on revu. ubuntu-universe-sponsors deals with patches/debdiffs on launchpad
[17:55] <Aloha> so sponsership is what happens after advocation?
[17:56]  * minghua thinks it's okay to call uploading an REVU package sponsoring.
[17:56] <minghua> (I think) I am not a universe-sponsor, though.
[17:58] <sistpoty|work> sponsoring in general == uploading a package for someone who cannot. However as I wrote, the uus team is used to manage sponsoring all patches/debdiffs in lp. for revu, there is no need to be in that team
[18:06] <Aloha> gotcha. so sponsoring is for merging code from launchpad, while revu is for package uploads?
[18:08] <sistpoty|work> right
[18:09] <Aloha> gotcha.
[18:10] <Aloha> so sponsorship is for people who can program but not package
[18:11] <pochu> It's for people who cannot upload packages to the archive
[18:12] <smarter> Could someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer (all the issues raised have been addressed) thanks ;)
[18:12] <Aloha> can't anyone upload packages to archive?
[18:12] <jpatrick> Aloha: no
[18:13] <RainCT> where can I vote against interdiff's? :P
[18:13] <Aloha> gotcha
[18:13] <sistpoty|work> Aloha: no... e.g. I cannot upload to main, so I need a sponsor for bug #178255
[18:13] <ubotu> Launchpad bug 178255 in nvidia-settings "NVCtrl.h and NVCtrlLib.h should be installed in /usr/include/NVCtrl not /usr/include" [Undecided,Confirmed] https://launchpad.net/bugs/178255
[18:13] <LucidFox> Aloha> Only Ubuntu developers can upload directly to the archives. Others need to get their changes uploaded via sponsorship.
[18:13] <sistpoty|work> (hint, hint, to any core-devs *g*)
[18:14] <LucidFox> There are two groups of developers: core developers and MOTUs.
[18:14] <Aloha> so whats "archives" is that main?
[18:14] <LucidFox> MOTUs can only upload to universe and multiverse. Core developers can upload to main and restricted.
[18:15] <geser> core-devs count also as motus
[18:15] <Aloha> gotcha so sponsorship is getting a core developer to sponsor your package into ubuntu proper?
[18:15] <jpatrick> Aloha: or MOTU's to universe
[18:16] <Aloha> jpatrick, isn't that advocating though?
[18:16] <jpatrick> nop
[18:16] <LucidFox> Advocating is for REVU.
[18:16] <LucidFox> Where new packages go.
[18:16] <LucidFox> Updates to existing packages, as well as Debian merges, are sponsored.
[18:17] <pochu> !sponsorship
[18:17] <ubotu> Sorry, I don't know anything about sponsorship - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[18:17] <sistpoty|work> Aloha: advocating means that s.o. is happy with a new package. We have the rule, that any package from a non-motu needs two people that are happy with it. Usually the second advocate also sponsors the upload of the new package
[18:17] <Aloha> LucidFox, i mean from REVU to universe do you need sponsorship?
[18:18] <LucidFox> Aloha> To get a package from REVU, you need two MOTUs to advocate it
[18:18] <Aloha> sistpoty|work, Oh! Second advocator sponsors it... i get it now
[18:18] <geser> Aloha: for a new package you go through REVU where two MOTU need to ACK (advocate) your package. Once it's in the archive and you need to update it (apply a patch, fix a packaging mistake, update to a new version, etc.) you go through the sponsoring queue
[18:22] <LucidFox> RainCT> I heard persia lobbied to allow sponsoring new upstream versions with just the diff.gz
[18:22] <LucidFox> I might have misinterpreted him, though
[18:23] <Aloha> that would make sense
[18:26] <geser> LucidFox: it's on the agenda for the next MOTU meeting (this Friday, 20:00 UTC)
[18:26] <LucidFox> ah
[18:28] <LucidFox> anyway... I'm off
[18:34]  * sistpoty|work heads home
[18:34] <sistpoty|work> cya
[18:40] <jdong> superm1: and btw, did you ever get your jailbreak working? :D
[18:40] <Lure> any motu willing to revu this package for me - bug 103324
[18:40] <ubotu> Launchpad bug 103324 in ubuntu "[need-packaging] QLandkarte" [Wishlist,In progress] https://launchpad.net/bugs/103324
[18:53] <mcisbackuk> Evening all. What are these sync requests to update with upstream? Are contributors allowed to help out or is it purely Sponsors work?
[18:53] <mcisbackuk> What I mean is do we give the debdiffs and Sponsors sort it from there or?
[18:54] <jpatrick> mcisbackuk: contributors can request, only MOTU can confirm
[18:55] <mcisbackuk> jpatrick: OK, but am I allowed to go ahead and create defdiffs for the differences and upload them, then subscribe the unvierse sponsors, or is that not the way it works?
[18:55] <jpatrick> mcisbackuk: yes
[18:55] <mcisbackuk> jpatrick: OK cool, thanks :)
[18:55] <mcisbackuk> jpatrick: Was just checking the workflow of things lol :)
[19:00] <RainCT> bah, stupid interdiff's :P
[19:00]  * RainCT goes back to REVU :P
[19:01] <mok0> evening
[19:12] <ryanakca> can someone look at http://revu.tauware.de/revu1-incoming/basic256-0801302110/basic256-0.9.2/debian/basic256.desktop and help me figure out why the package always ends up in lost and found?
[19:13] <mok0> ryanakca: things are put in lost+found by fsck
[19:13] <mok0> ryanakca: It means your filesystem is in poor shape
[19:13] <ryanakca> mok0: no, in the menu
[19:13] <RainCT> Aloha: I just commented on sadms
[19:13] <geser> mok0: I've heard KDE has also a lost+found section in the menu
[19:14] <mok0> Ah, I misunderstood
[19:15] <geser> ryanakca: basic256.desktop: error: value "ComputerScience" for string list key "Categories" in group "Desktop Entry" does not have a semicolon (';') as trailing character
[19:15] <geser> after adding it desktop-file-validate was happy
[19:15] <RainCT> ryanakca: I don't think ComputerScience is a primary category, try adding one (all .desktop files must have a primary category, plus optionaly secondary categories like I think this one is).  Also,   test: error: value "ComputerScience" for string list key "Categories" in group "Desktop Entry" does not have a semicolon (';') as trailing character
[19:16] <ryanakca> geser, RainCT: okies, thanks... and where /how do you get that output?
[19:17] <RainCT> ryanakca: desktop-file-validate <filename>
[19:17] <ryanakca> ah, thanks.
[19:17] <geser> ryanakca: reading http://standards.freedesktop.org/menu-spec/latest/apa.html you should perhaps also add Education as main category
[19:18] <ryanakca> And if I get my package sponsored into Debian today, do you think I'd have time to get it synced into Ubuntu before the 14th?
[19:18] <ryanakca> geser: so, Categories=Education;Science;ComputerScience;
[19:18] <ryanakca> ?
[19:18] <\sh> AndyP, do you still know why you removed the build-dep of libsnmp*-dev from nagios-plugins?
[19:19] <ryanakca> or should I upload to Ubuntu & Debian, and then at hardy+1, just sync from the debian copy?
[19:19] <RainCT> ryanakca: Might be, but I wouldn't take the risk. In my experience, NEW processing normally takes some weeks..
[19:19] <ryanakca> okies
[19:19]  * ryanakca updates the copy on REVU then and will give you guys the link :)
[19:20] <ryanakca> s/unstable/hardy/ in changelog?
[19:20] <geser> ryanakca: yes, that Categories looks ok now
[19:20] <RainCT> ryanakca: right
[19:20] <ryanakca> kk...
[19:21] <geser> ryanakca: if you s/unstable/hardy/ then you probably also want to update the versioning
[19:21] <ryanakca> from 0.9.2-1 to 0.9.2-0ubuntu1 ? already done :)
[19:21] <mok0> I did the merge of xtide from sid before christmas, but now -- via discussion with the Debian maintainer -- some of the edits I made to the package needs to be changed. How should I do that, as a bug patch, or as another merge?
[19:22] <\sh> mok0, xtide has a new upstream version handy..
[19:22] <\sh> mok0, please check the package and merge
[19:22] <\sh> mok0, if you can't upload, give me a ping and I'm happy to sponsor
[19:22] <Lutin> based on http://bugzilla.gnome.org/show_bug.cgi?id=508642 , do you guys think asking an archive removal for gst-editor would be correct ?
[19:22] <ubotu> Gnome bug 508642 in gst-editor "It doesn't use gstreamer0.10" [Normal,Resolved: notabug]
[19:22] <\sh> mok0, debdiff against latest debian package appreciated
[19:22] <mok0> \sh: ok, thanks
[19:23] <mok0> \sh: I have packaged some additional data, it's on revu now
[19:23] <\sh> mok0, link? :)
[19:24] <mok0> http://revu.ubuntuwire.com/details.py?package=xtide-wvs1-data
[19:25] <\sh> mok0, looking
[19:25] <mok0> \sh: I was hoping the debian xtide maintainer would do it, but apparently he hasn't had the time. I'd like the extra data to go in hardy, so I packaged it
[19:25] <mok0> \sh: also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456979
[19:25] <ubotu> Debian bug 456979 in xtide "Please make wvs data available for xtide" [Wishlist,Open]
[19:27] <mok0> ubotu, shut up
[19:27] <ubotu> Sorry, I don't know anything about shut up - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[19:28] <\sh> mok0, the package data is just lowres? 3.8MB != 37MB reading debian/copyright :
[19:29] <mok0> \sh: I checked all of them, this one gives t he best performance/size ratio
[19:29] <mok0> \sh: the high res ones are much slower to load, and they dont give you better information, unless you zoom in a lot
[19:30] <\sh> mok0, the date of the files are always 20020219?
[19:30] <mok0> \sh: that's the date on the ftp server
[19:31] <mok0> Is that a problem?
[19:32] <\sh> mok0, well, it's not changing that much it seems?
[19:32] <mok0> exactly
[19:32] <mok0> not before the icecaps start melting for real
[19:32] <mok0> ;-)
[19:32] <\sh> rotfl
[19:35] <\sh> mok0, ok you need at least one advocation more...and bump compat/debhelper dep to 6
[19:36] <mok0> OK
[19:36] <mok0> Let me re-upload, before you advocate
[19:37] <mok0> is compat 6 general for hardy?
[19:37] <\sh> mok0, well, find another reviewer :) and I'll sponsor the upload :) I don't revoke my advocation :)
[19:37] <\sh> mok0, debhelper 6 is in hardy, so yes
[19:37] <\sh> mok0, and also in debian
[19:37] <mok0> \sh: isn't the advocation rejected when there's a new upload?
[19:38] <\sh> mok0, well, I don't care :) get the second reviewer on it and ping me
[19:38] <mok0> \sh: sure. Thanks!
[19:38] <\sh> mok0, nope thank you :)
[19:52] <ryanakca> geser, RainCT: http://revu.tauware.de/details.py?package=basic256 , if you have time, please :)
[19:54] <ryanakca> the offers open to everybody else too :)
[19:56] <RainCT> ryanakca: I'll look at it in a moment :)
[19:56] <ryanakca> RainCT: thanks :D
[20:05] <RainCT> ryanakca: it's recommended to start the Description in .desktop files with a verb
[20:06] <RainCT> ryanakca: also, an icon would be nice
[20:09] <ryanakca> RainCT: ok, I'll update the .desktop file
[20:10] <dcordero> hi
[20:10] <ryanakca> as for the icon... my graphics skills are non-existent, and upstream doesn't supply one
[20:10] <dcordero> is down launchpad?
[20:10] <RainCT> ryanakca: I've some more comments, writting them on REVU to don't SPAM the channel :P
[20:10] <ryanakca> dcordero: not to my knowledge
[20:11] <dcordero> my mistake, i was trying to access to launchpad.com :)
[20:14] <mok0> \sh: xtide-vws1-data is ready
[20:14] <mok0> I also added a Build-Depends-Indep:
[20:15] <RainCT> ryanakca: http://revu.tauware.de/details.py?package=basic256    about the icon, can't you find any (in Google or wherever)?
[20:15] <\sh> mok0, cool...find another reviewer then :)
[20:15] <ryanakca> RainCT: I can find an unrelated one
[20:15] <ryanakca> RainCT: I could also use the favicon, but I think those are 16x16 or something of the sort
[20:16] <mok0> RainCT: As a newly appointed MOTU, will you do me the honor of being the second sponsor?
[20:16] <squentin> Anyone interested in reviewing mine : http://revu.tauware.de/details.py?package=gmusicbrowser ?
[20:17] <RainCT> mok0: hehe. URL? :)
[20:17] <mok0> http://revu.ubuntuwire.com/details.py?package=xtide-wvs1-data
[20:17] <\sh> RainCT, add my advocation to it :)
[20:18] <\sh> RainCT, if you are ok with it, upload on your command ;)
[20:18] <ryanakca> RainCT: As for the 'extra' if I'm not mistaken, thats a Debian thing I forgot about... I might be completely wrong though
[20:18] <RainCT> ryanakca: you can cut a bigger version of the favicon from http://kidbasic.sourceforge.net/kbsshotsm.png, but well.. I think it'll look better without an icon :P
[20:19] <ryanakca> lol
[20:20] <ryanakca> RainCT: also, should I use 'desktop-file-install' instead of the manual cp?
[20:26] <rjmyst3> bddebian: thanks for the advocate
[20:27] <ryanakca> RainCT: also, how does this sound? 'Comment=Learn BASIC in an environment designed for young children' ?
[20:27] <superm1> jdong, argh
[20:27] <superm1> jdong, yeah you know 1.1.3 finally got on there, but all my old apps are fsck'ed
[20:27] <superm1> jdong, and all this weird stuff happened to the new apps, random crashes
[20:27] <superm1> missing libraries
[20:28] <superm1> so somehow i'm going to have to find someone with OSX or windows to bring me back to 1.1.1 so i can redo the whole thing
[20:30] <rjmyst3> any wxWidgets fans in here, today?
[20:36] <rjmyst3> eat m&ms
[20:38] <\sh> wxWidget?
[20:38] <rjmyst3> yes?
[20:39] <\sh> for what? :)
[20:39] <rjmyst3> i've packaged a wxWidgets GUI designer, I'm looking for a MOTU to review it
[20:39] <rjmyst3> i've been advocated by one MOTU, already
[20:39] <rjmyst3> http://revu.tauware.de/details.py?package=wxformbuilder
[20:41] <joejaxx> superm1: ?
[20:41] <superm1> you joejaxx
[20:41] <\sh> sry..not this evening anymore..I'm waiting still for one build to finish...and then hepp into bed...tomorrow my new job starts
[20:42] <joejaxx> superm1: lol why do you need someone with osx or windows? :D
[20:42] <superm1> joejaxx, well there is no way to roll the firmware on an ipod touch back otherwise
[20:42] <rjmyst3> \sh: congratulations on the new job! thanks, anyway
[20:42] <joejaxx> superm1: ah
[20:42] <superm1> an jdong convinced me to try something that fsck'ed mine
[20:43] <rjmyst3> \sh: although, if wanted to take a look at it tomorrow, that would be cool, too :)
[20:43] <\sh> rjmyst3, I can do some reviewing tomorrow evening when I'm coming home...so that's on my todo
[20:43] <RainCT> hi again
[20:43] <RainCT> modem died and didn't want to connect :(
[20:43] <rjmyst3> \sh: great! thanks
[20:43] <RainCT> mok0: do you still want me? :P
[20:43] <RainCT> >> ryanakca: you can cut a bigger version of the favicon from http://kidbasic.sourceforge.net/kbsshotsm.png, but well.. I think it'll look better without an icon :P
[20:43] <RainCT> >> ryanakca: extra is for packages that are dangerous or are an uncommon replacement for some other package (iirc)
[20:43] <mok0> RainCT: If you would like to co-sponsor xtide-wvs1-data with \sh
[20:43] <mcisbackuk> Guys I've just updated something from upstream, what do I need to include in the LP bug? interdiff debdiff dsc files, what? :)
[20:44] <\sh> RainCT, check the xtide* package and advocate it when you ok with it...and upload pls :)
[20:44] <\sh> RainCT, my approval is upgrade compatible ;)
[20:44] <RainCT> mcisbackuk: theoretically interdiff but .diff.gz is also ok
[20:45] <RainCT> \sh: ok, cool :P
[20:45] <mcisbackuk> RainCT: OK I'll do the interdiff then, probably cleaner way of doing it anyway :)
[20:50] <\sh> ok guys...good night ... /me's off until tomorrow evening it seems
[20:50] <RainCT> \sh: good night
[20:51] <mcisbackuk> Damn! pbuilder failed saying dh_iconcache: Command not found.....any ideas anyone?
[20:52] <geser> mcisbackuk: dh_iconcache is dh_icons since hardy
[20:53] <mcisbackuk> geser: So I just change the rules file to dh_icons **BLAH** instead of dh_iconcache?
[20:54] <geser> yes
[20:54] <mcisbackuk> Should have Googled that lol Sorry, and thanks :)
[20:54] <blueyed> Is there anything special to take care of when upgrading a package in multiverse (new upstream release, Debian does not appear to be ready yet for it yet and it's unclear how they fix it. The package has FTBFS in Ubuntu since always) - see bug 150484. Is it safe to upload it?
[20:54] <ubotu> Launchpad bug 150484 in batik "batik has FTFBS forever" [High,In progress] https://launchpad.net/bugs/150484
[20:55] <mcisbackuk> geser: Do I have to do debuild after changing the rules file or pbuilder straight away?
[20:58] <geser> mcisbackuk: you need a new source package, so first debuild -S and then pbuilder
[20:58] <mcisbackuk> geser: OK gotcha cheers :)
[20:59] <geser> blueyed: talk to slytherin once he is here again, as he was looking at that issue
[21:02] <RainCT> mok0: control, line 16, + "is" on the end :P
[21:03] <TheMuso> \sh_away: Thanks for doing gnunet. Feel free to do my other updated merges if you are looking for something to do.
[21:03] <mok0> RainCT: I will look
[21:03] <mrr64> I've been working with the morse_2.1-2 package that I downloaded as 'apt-get source morse' on a gutsy distribution. I'm a little confused. The makefile is broken (ie, it doesn't compile and/or install the program). Fixing it isn't a major issue BUT, and this is my question: If the source package is broken, where did the binary install package come from? (I got that from a 'sudo apt-get install morse')
[21:04] <blueyed> geser: ok, I've left a comment on the bug - unfortunately he's not subscribed. I'll try to catch him..
[21:04] <mok0> RainCT: Arrgh
[21:04] <RainCT> mok0: and I think that the "to" on the last line should be a "with"
[21:04] <ryanakca> 15:20:10 < ryanakca> RainCT: also, should I use 'desktop-file-install' instead of the manual cp?
[21:04] <ryanakca> 15:26:50 < ryanakca> RainCT: also, how does this sound? 'Comment=Learn BASIC in an environment designed for young children' ?
[21:04] <mok0> RainCT: hmm. Are you native englishspeaker?
[21:04] <ryanakca> (dunno if you got those two since your modem died)
[21:05] <RainCT> mok0: no
[21:05] <mok0> RainCT: "of 1 to 1000000"
[21:05] <RainCT> mok0: sound better :)
[21:05] <Coper> If I want to create a new package for ubuntu should it be gutsy or hardy in changelog?
[21:06] <mok0> RainCT: resolution to one to 1million? Nah
[21:06] <mok0> RainCT: I don't agree
[21:06] <mcisbackuk> Coper: hardy and use pbuilder when building for hardy
[21:06] <mok0> Any native english speaker here?
[21:06] <mcisbackuk> mok0: Yes
[21:07] <mok0> mcisbackuk: will you help decide a language problem?
[21:07] <mcisbackuk> mok0: Sure
[21:07] <RainCT> ryanakca: didn't got them. no, cp is fine (or even better dh_install). (and if this was a "normal" you would need to call dh_desktop, but as you are using cdbs (like I always do :)) that's not needed)
[21:07] <mok0> Which is correct: "This package contains map data to a resolution of 1:1,000,000
[21:08] <mcisbackuk> mok0: use 'with' instead of 'to'
[21:08] <mok0> or: "This package contains map data to a resolution to 1:1000000
[21:08] <Coper> okej, how do I make pbuilder update for hardy?
[21:08] <mok0> mcisbackuk: with, ok
[21:08] <mcisbackuk> mok0: i.e. "this package contains map data WITH a resolution of 1:1,000,000
[21:09] <mok0> mcisbackuk: fine. The question was about the "of"
[21:09] <mcisbackuk> Coper: Have a look at https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate
[21:09] <mcisbackuk> mok0: lol It's no problem :) Glad I could help :)
[21:10] <mok0> mcisbackuk: but you haven't yey
[21:10] <mok0> yet
[21:10] <mcisbackuk> mok0: What you mean?
[21:10] <mok0> "of 1:1,000,000" or "to 1:1,000,000"
[21:11] <mcisbackuk> mok0: this is how I would probably put it "This package contains map data with a resolution of 1:1,000,000"
[21:11] <mok0> mcisbackuk: Thank you!
[21:12] <mcisbackuk> mok0: You're welcome :)
[21:12] <mok0> RainCT: heh, we were both wrong :-)
[21:12] <Coper> but when i run pbuilder it create is for gutsy
[21:12] <mcisbackuk> lolz it just sounds better like that :)
[21:12] <RainCT> mok0: lol :)
[21:12] <mcisbackuk> !pbuilder | Coper
[21:12] <ubotu> Coper: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
[21:12] <mcisbackuk> Thanks ubotu lol
[21:13] <ryanakca> RainCT: and the translations?
[21:13] <mok0> RainCT: if that's the only comment, perhaps you can fix it and upload?
[21:14] <mcisbackuk> mok0: If you ever need help with wording things in English just give me a shout I'll gladly help :)
[21:14] <Coper> mcisbackuk: yes but by default my pbuilder is building for gutsy and not hardy that the guide says.
[21:14] <mok0> mcisbackuk: thanks a lot
[21:15] <mcisbackuk> Coper: On the guide it should tell you the options for setting pbuilder to a hardy chroot environment
[21:15] <mok0> RainCT: But perhaps the Build-Depends-Indep be deleted again
[21:15] <RainCT> ryanakca: uops, sorry.   Comment[ca]=Apreneu BASIC en un entorn dissenyat per a nens.     Comment[es]=Aprende BASIC en un entorno diseñado para niños.
[21:15] <mrr64> Coper: 'pbuilder --distribution hardy --override-config'  will redo the base.tgz file
[21:15] <RainCT> mok0: right
[21:16] <Coper> ahh sry that working now, before i got a warning that hardy didn't exsist.
[21:16] <RainCT> mok0: ok, I think that's all
[21:17] <mok0> RainCT: cool
[21:17] <slangasek> RainCT: "Aprende a machacar su cerebro en un entorno diseñado para niños"
[21:17] <RainCT> slangasek: haha :D
[21:17] <slangasek> sorry, s/su/tu/
[21:17] <mok0> RainCT: OK I will upload another version to revu
[21:19] <mok0> RainCT: done
[21:20] <LaserJock> Coper: you need to make sure to get debootstrap from gutsy-backports
[21:22] <mok0> That's a pretty impressive list of packages on REVU!
[21:22] <mcisbackuk> What is this REVU thing that I keep hearing about?
[21:22] <RainCT> !revu > mcisbackuk
[21:22] <mok0> mcisbackuk: What are you hearing?
[21:23] <mcisbackuk> mok0: lol.....figure of speech
[21:23] <mcisbackuk> !revu
[21:23] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[21:23] <mok0> :-D
[21:23] <mcisbackuk> Is revu for upgrades as well or ust new packages?
[21:24] <mcisbackuk> *just
[21:24] <mok0> mcisbackuk: It's for everything
[21:25] <mcisbackuk> mok0: But if it's used for upgrades, wouldn't it deviate from launchpad's bug system for uploading changes?
[21:25] <LaserJock> it's primarily for new packages
[21:25] <mok0> mcisbackuk: launchpad is only for bug reports, not uploads
[21:26] <mcisbackuk> LaserJock: OK I'll stay away then I wanna stick to interdiff jobby's lol
[21:26] <LaserJock> sometimes people use it for big upgrades when a debdiff would be not as productive
[21:26] <LaserJock> mcisbackuk: yeah
[21:26] <mok0> ... I guess even motus sometimes like a second opinion
[21:26] <mcisbackuk> LaserJock: Like major changes not minors i.e. 1.0 -> 2.0 not 1.0 > 1.0.2
[21:26] <LaserJock> yeah
[21:26] <mcisbackuk> cool cool
[21:27] <LaserJock> it's a place to stick a whole source package
[21:27] <mcisbackuk> I will get used to all this soon don't worry ;) hehe
[21:27] <LaserJock> if debdiffs or interdiff/diff.gzs work then I lean towards using those
[21:28] <mok0> LaserJock: but you get those on revu, too :-)
[21:28] <mok0> Although they are backwards..
[21:28] <ScottK2> Generally REVU is just used for new packages, but there are exceptions.
[21:28] <mcisbackuk> But what I'm saying is, wouldn't it be easier to stick them small files on LP?
[21:29] <ScottK2> mcisbackuk: For upgrades that's the general process.
[21:29] <mcisbackuk> kks :)
[21:30] <mok0> Another thing is that revu is community run, and LP is Canonical
[21:30] <mcisbackuk> GRRRR OK, why the hell is pbuilder still bitchin about my rules file saying dh_iconcache, I changed it to dh_icons AND saved it, and done debuild -S -sa again and it still says same error :S
[21:30] <ScottK2> mcisbackuk: Did you pass the correct .dsc to pbuilder?
[21:30] <pochu> mcisbackuk: change it in debian/control.in too
[21:30] <pochu> err
[21:31] <mcisbackuk> yeah the .3 not .2
[21:31] <pochu> ignore me
[21:31] <mcisbackuk> control??
[21:31] <mok0> pochu: we are
[21:31] <geser> pochu: debian/control.in? how does it relate do debian/rules?
[21:31] <mok0> :P
[21:31] <RainCT> ryanakca: Comment[de]=Lerne BASIC in einer Umgebung, die speziell für die ganz Kleinen entwichelt wurde.
[21:31]  * pochu isn't here anymore O.o
[21:31] <mcisbackuk> geser: Even I was thinking that.... lol
[21:32]  * mok0 hugs pochu
[21:32]  * pochu hugs mok0 back :)
[21:32] <geser> RainCT, ryanakca: "entwickelt" not "entwichelt" but otherwise looks good
[21:32] <pochu> mcisbackuk: what's the output of "zgrep iconcache *.diff.gz" ?
[21:33] <RainCT> ryanakca: new one.. Comment[de]=Lerne BASIC in einer Programmierumgebung speziell für die ganz Kleinen
[21:33] <mcisbackuk> !paste
[21:33] <ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[21:34] <RainCT> ryanakca: (I've asked a German friend to translate it as my German is quite forgotten :P)
[21:34] <mcisbackuk> pochu: http://paste.ubuntu-nl.org/54251/
[21:34] <mcisbackuk> I speak German, not PERFECTLY but good enough
[21:35] <mok0> mcisbackuk: Mein Gott!!!
[21:35] <mcisbackuk> mok0: lol Ja ja, es ist gut! lol
[21:36] <geser> das ist hier nicht #ubuntu-motu-de :)
[21:36] <mcisbackuk> pochu: I think I realised whats wrong, I need to delete the .diff.gz that pbuilder created last time don't i?
[21:37] <mcisbackuk> geser: I'm english, born i london lol! i just speak german as well lolz
[21:37] <geser> mcisbackuk: if debuild -S succeeds, then you should have a new diff.gz
[21:37] <slangasek> geser: aber gibt's kein #ubuntu-motu-de :(
[21:38] <mok0> Perhaps #ubuntu-de-motu? :-P
[21:38] <mcisbackuk> geser: should I delete the newer one anyway just in case its not overwriting it?
[21:38] <mcisbackuk> the .diff.gz i mean
[21:38] <geser> mcisbackuk: is doesn't hurt
[21:39] <geser> at least you will that something didn't work if you don't get a new diff.gz
[21:39] <mcisbackuk> geser: OK ill try that maybe it'll stop winding me up lol
[21:39] <mcisbackuk> geser: true
[21:41] <Coper> Can someone check so I haven't make any big misstakes? http://revu.ubuntuwire.com/details.py?package=console-freecell
[21:41] <RainCT> slangasek: wie viele Sprachen kennst du den? :P
[21:42] <pochu> Coper: http://revu.ubuntuwire.com/revu1-incoming/console-freecell-0801312240/lintian
[21:42] <mok0> slangasek knows a bunch of wicked finnish words
[21:43] <mcisbackuk> RainCT: Nur 2 :(
[21:43] <geser> Coper: you don't need to list libncurses5 in Depends, dh_shlibdeps should add it through ${shlib:Depends}
[21:43] <slangasek> RainCT: moltes ;)
[21:44] <RainCT> heh
[21:46] <ryanakca> RainCT: thanks :)
[21:46] <geser> Coper: and for the short description see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis
[21:46] <Coper> pochu: is it just to update standard-version?
[21:47] <pochu> Coper: no. I'm doing a full review.
[21:47] <geser> Coper: is there a need-packaging bug for it? if yes, you should close it in the changeloge ("(LP: #xxx)")
[21:48] <RainCT> mok0: sorry for the wait.. pbuilder is running now
[21:48] <mok0> RainCT: great
[21:50] <persia> \sh_away: You should apply to join the group.  One of the admins will likely welcome you :)
[21:50] <pochu> Coper: review posted.
[21:50] <persia> RainCT: Come to the next MOTU Meeting (1 February) and complain.  Maybe interdiffs can go away.
[21:51]  * persia drops back into deep idle
[21:51] <RainCT> persia: Sure :).
[21:51] <RAOF> persia: Congratulations, incidentally.
[21:52] <CyberMatt> can somebody check http://revu.tauware.de/details.py?package=jailkit
[21:52] <Coper> pochu: Thanks. :)
[21:52] <superm1> hey RAOF i cleaned up gmyth and have a much nicer build on that .orig.tar.gz now
[21:57] <RAOF> superm1: Cool.  I'll probably get time to look at it sometime today.
[21:59] <LaserJock> man, git is cool
[21:59] <RAOF> Cooler than svn, certianly.
[22:00] <RAOF> Have you just played with git-bisect?
[22:00] <ion_> raof: Not only cooler, but insanely faster.
[22:00] <ion_> And git-bisect is a lifesaver. :-)
[22:01] <LaserJock> RAOF: no, git-cvsimport
[22:01] <mcisbackuk> How do I become a MOTU? I lready help out with bugs (that I can) and have done a couple of upstream upgrades :)
[22:01] <LaserJock> mcisbackuk: just keep working
[22:01] <ryanakca> mcisbackuk: look at the topic
[22:01] <jdong> superm1: I've heard all apps need reinstalling after a firmware upgrade
[22:01] <jdong> superm1: (and they say Ubuntu upgrades are messed)
[22:01] <LaserJock> mcisbackuk: usually people will start poking you to apply when you're ready
[22:02] <TheMuso> ember_: I would ask that when the new version of orca comes out, that I take care of it, as I have one or two extra things I need to do.
[22:02] <mcisbackuk> LaserJock: I doubt I'm ready just yet, I mean yeah I've learnt a hell of a lot since coming on here and packaging and stuff, but I dunno - I'd be stumped if there was a test lmao
[22:03] <ember_> TheMuso: okidoki
[22:03] <LaserJock> mcisbackuk: yeah, just keep working on it :-)
[22:04] <mcisbackuk> LaserJock: I intend to :) New skills and learning stuff is always good :)
[22:04] <LaserJock> mcisbackuk: and you will continue learning after you become a MOTU
[22:04] <mcisbackuk> Kewl :)
[22:05] <LaserJock> nothing makes you learn like having to review/sponsor other people's work
[22:05] <mcisbackuk> LaserJock: I'll bet lolz
[22:06] <TheMuso> ember: Thanks.
[22:06] <the_belgain> hi there - i was wondering if anyone could review my fuppes package in REVU: http://revu.tauware.de/details.py?package=fuppes
[22:07] <the_belgain> it's been in there for a few days but there aren't any comments on the latest version - i'd quite like to try and get this into hardy if possible..
[22:08] <mcisbackuk> It's STILL coming up with dh_iconcache command not found i changed the rules file ANd deleted the diff.gz
[22:08] <LaserJock> now I gotta figure out git-buildpackage
[22:09] <CyberMatt> the_belgain, i'm not a motu but it seems to me like you need a better long description
[22:09] <LaserJock> mcisbackuk: zgrep the diff.gz for dh_icon
[22:09] <mcisbackuk> k
[22:10] <mcisbackuk> I think i missed one in rules somehow lol *blush*
[22:10] <CyberMatt> the_belgain, also debin/coyright should wrap at 80 chars
[22:11] <mcisbackuk> Yup, looks like I did lol stupid me
[22:11] <LaserJock> mcisbackuk:  well, usually pbuilder doesn't lie ;-)
[22:11] <ryanakca> RainCT: http://revu.tauware.de/details.py?package=basic256
[22:11] <mcisbackuk> Nah i knew it would be something really stupid, just didn't know where it was, but thanks laserjock :)
[22:11] <CyberMatt> you can use fmt to do that :-)
[22:11] <ryanakca> Also, if anybody else is willing and has has time, could the review it please? (basic256)
[22:12] <the_belgain> CyberMatt: thanks, I'll make those two changes
[22:13] <the_belgain> are any MOTUs able to review (and potentially advocate)?
[22:13] <mok0> the_belgain: all MOTUs have gone into hibernation
[22:14] <RainCT> mok0: I guess you have already noticed it, but the package is uploaded :)
[22:14] <mok0> errrh, hi RainCT
[22:15] <mok0> :)
[22:15]  * RainCT was having dinner :P
[22:15] <mok0> uhm
[22:15] <Aloha> RainCT, thanks for commenting. i was away
[22:16] <mok0> RainCT: now I should merge the latest xtide
[22:16] <rulus> Can someone have a look at my package (http://revu.tauware.de/details.py?package=gtkvd)? It should be ready for advocation :)
[22:18] <RainCT> rulus: well, you really shouldn't ask if it wasn't ready ;P
[22:19] <rulus> RainCT: yes, true :p
[22:19] <mok0> rulus: there's always that one. last, bug
[22:20] <Aloha> RainCT, what priority should sadms be?
[22:20] <Aloha> RainCT, optional?
[22:20] <rulus> mok0: yep, software is never finished I guess
[22:20] <the_belgain> i'm about to upload an updated version of fuppes with the markups CyberMatt pointed out above, unless anyone else is taking a look at this in which case i can roll in other updates?
[22:20] <RainCT> Aloha: yes
[22:20] <mok0> rulus: heh
[22:20] <Aloha> RainCT, thnx
[22:20] <mok0> RainCT: don't forget to change the status of the LP bug
[22:21] <Coper> hmm I get a warning: unknown information field 'L Launchpad-Bugs-Fixed' in input data in parsed version of changelog.
[22:22] <mok0> RainCT: bug 187762
[22:22] <ubotu> Launchpad bug 187762 in ubuntu "[needs-packaging] xtide world vector shoreline data" [Undecided,Confirmed] https://launchpad.net/bugs/187762
[22:22] <RainCT> mok0: Janitor didn't change it?
[22:23] <mok0> RainCT: Its still "confirmed"
[22:23] <mok0> RainCT: should be fix committed, right?
[22:23] <RainCT> mok0: yes, changed it.
[22:24] <mok0> RainCT: great. Pleasure working with you :-)
[22:25]  * mok0 carves another notch
[22:25] <the_belgain> i've uploaded another fuppes package - any reviews would be welcome (i'll check revu tomorrow)
[22:26] <LaserJock> Coper: that's ok
[22:26] <blueyed> Is there some better documentation of get-orig-source than the one at https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball ?
[22:27] <mok0> blueyed: what's wrong with it?
[22:28] <mok0> A bit brief, perhaps
[22:28] <blueyed> yes, also unclear about where the orig.tar.gz should land (seems different between 2 and 3)
[22:29] <blueyed> Also, no mentioning about how and when to invoke it.
[22:29] <RainCT> mok0: Thanks. /me thinks the same :)
[22:29] <RainCT> (with you, not with myself :P)
[22:29]  * mok0 hi-5's RainCT 
[22:31] <blueyed> Does my first get-orig-source look sane? http://pastebin.com/m3420b7ab
[22:31] <mok0> blueyed: I don't really see the point of the get-orig-source target.
[22:31] <mok0> blueyed: A script in debian/ would suffice
[22:33] <TheMuso> mok0: If there is a debian/watch, get-orig-source is not needed.
[22:33] <mok0> TheMuso: exactly
[22:33] <TheMuso> If a debian/watch is not possible, then get-orig-source is needed.
[22:34] <Coper> To close a bug in changelog is it just to add (LP: #xxxxxx) ?
[22:34] <RainCT> Coper: yes
[22:34] <mok0> TheMuso: Yeah, but can it be done without human intervention? I don't think so, because often you have to edit the version anyway
[22:34] <crimsun> personally, apparmor's debian/rules has a nice get-orig-source:
[22:34] <Aloha> Coper, i don't think you even need the ()
[22:35] <TheMuso> mok0: Not entirely no, but all thats needed is the latest changelog entry to have the version that is desired.
[22:35] <crimsun> also, I think get-orig-source: is useful in situations where we have to recreate the orig.tar.gz tarball from tar.bz2, e.g., alsa-*
[22:35] <mok0> TheMuso: yes, but human intervention is needed
[22:35] <TheMuso> For example, look at the way that the gnome-pkg-tools gnome-get-source.mk does it.
[22:36] <mok0> crimsun: yes for repackaging it is needed
[22:36] <Coper> added a new version for revu and fix all problems.
[22:37]  * mok0 thinks that if only upstream authors would maintain sensible standards things would be easiy
[22:37] <mok0> easy
[22:37] <ScottK2> Yep.
[22:38] <mok0> Apropos: is there a document with recommendations for upstream authors?
[22:38] <mok0> There must be a vast amount of experience in the packaging community that could benefit upstreams
[22:38] <blueyed> mok0: I need to pull in a directory from svn.. or at least that's what the debian maintainer did.. I've just automated it. Do you think adding a script to the (also existing) watch file would be better instead?
[22:38] <CyberMatt> mok0, then whats the fun in packageing
[22:38] <Aloha> apt-file is a nice package... i can't believe i lived without it
[22:39] <ScottK2> slangasek: I think I found a small missing bit in the cyrus-sasl2 libdb transition that would make it not unreasonable to do another upload after the alpha freeze is over.  It still build-dep's on libdb-dev with the versioning on 4.4, not 4.6.
[22:39] <ScottK2> So we can keep the version numbers in sync in good consciense.
[22:39] <blueyed> Aloha: unfortunately it does not work for development branches, does it?
[22:39] <RainCT> ryanakca: in the spanish comment, you wrote a "si" in the middle, remove that :P. also, I recommend writting all the Comment[xx] entries in alphabetic order (ca,de,es,fr) as if the file gets longer it will be easier to find a certain language that way
[22:40]  * blueyed has some apt-file bugs assigned still..
[22:40] <Aloha> blueyed, i don't know i got it from repo not from cvs
[22:40] <RainCT> ryanakca: and don't use "rm" for clean:, but "rm -f" instead, otherwise cleaning if it's already clean will fail
[22:40] <blueyed> Aloha: I mean, it does not work for Hardy, does it? Only Gutsy..
[22:40] <mok0> blueyed: Hmm. I think a standalone script in debian/ is the clearest way to do it. I don't see the advantage of the extra "debian/rules get-orig-source" requirement
[22:40] <Aloha> blueyed, not sure i don't run hardy
[22:40] <mok0> blueyed: basically, it's just wrapping a script inside a makefile
[22:41] <ScottK2> mok0: What difference is it if it's a script or a target in rules?  It works out the same.
[22:41] <mok0> ScottK2: exactly.
[22:41] <mok0> ScottK2: why wrap it in a makefile?
[22:41] <blueyed> You have some additional vars set there..
[22:41] <Aloha> target in rules probably looks better aesthetically
[22:41] <ScottK2> So Debian policy says put it in rules.  Is there a strong motive to change?
[22:42] <mok0> a makefile is a bad place to have a script. For example, each line is a separate process
[22:42] <superm1> jdong, well the thing is i reinstalled them, but its keeping binaries in all these weird places on the system now
[22:42] <mok0> if you need to work in another dir, you have to cd in every line
[22:42] <superm1> jdong, its a really bad upgrade
[22:42] <superm1> it needs to be wiped
[22:43] <blueyed> mok0: it's all one line.. "\" at the end.. imho it's just messier in rules.
[22:43] <mok0> _that_ is aesthetically _not_ pleasing
[22:43] <geser> blueyed: there are already Content files for hardy on the archive so apt-file might work now again
[22:43] <RainCT> mok0: you can call another script from inside the makefile
[22:43] <mok0> blueyed: ok,ok,
[22:43] <blueyed> My question rather is if it should get included in the watch file (you can call scripts from there, can't you)?
[22:43] <mok0> blueyed: don't know, honestly
[22:44] <blueyed> geser: great! A good reason to fix it.. :)
[22:44] <mok0> why not have a script "debian/get-orig-source" ??
[22:44] <geser> blueyed: but I didn't check yet
[22:45] <slangasek> ScottK2: not particularly relevant given that the only "libdb-dev" that can satisfy any versioned build-deps is the one from db4.6; but IMHO it's a bad idea to use libdb-dev anyway, rather than the libdb4.6-dev virtual package
[22:46] <mok0> My basic view is that using a makefile as a process launcher is abuse of make
[22:48] <mok0> make is about resolving dependencies, and doing only what's necessary. It shouldn't be used as a manifold for spawning processes
[22:48] <ScottK> slangasek: Agreed it's a nit, but may as well get it right.  And if that cyrus-sasl2 were backported it could end up using multiple libdb versions for different things.
[22:49] <blueyed> mok0: I see. But AFAICS it's common sense to do it that way.. but there's not much documentation about it.. (w.r.t. usage)
[22:50] <slangasek> ScottK: not sure what you mean, there; there's no libdb-dev real package in the archive that isn't db4.6
[22:50] <ScottK> Ah.
[22:50] <mok0> blueyed: well, it keeps things in one place.
[22:51] <mok0> blueyed: anyway, get-orig-source is not called by any of the dpkg tools
[22:51] <ScottK> slangasek: OK.  I made the assumption that it existed in earlier releases.
[22:51] <mok0> so  it doesn't really matter
[22:52] <slangasek> ScottK: nope, it's a neologism resulting from the db maintainers being sick of having to maintain old versions for all eternity; but IMHO it's a wrong fix
[22:53] <ScottK> Thanks.
[22:54] <Coper> I have some problem with standard version, if I set it to 2.7.2.2 lintian is complaning that it's not 2.7.3 and if I set it to 2.7.3 linda complance that it's to new.
[22:55] <geser> Coper: ignore linda in this point
[22:56] <RainCT> ryanakca: you've more comments on REVU
[23:00] <matthijs> Aloha? hello.
[23:01] <RainCT> good night
[23:01] <matthijs> Is there someone here that would want to help out creating packages for our project?
[23:02] <matthijs> The project is "veejay", currently located on http://veejayhq.net
[23:02] <matthijs> We have a small, but loyal userbase, and some press coverage trough the piksel festival in norway
[23:03] <matthijs> however, things have been quiet since all of the development team has dayjobs now, and we do not have time to work on packages
[23:03] <mok0> matthijs: First step is to file a needs-packaging bug on launchpad.net
[23:03] <matthijs> We would like to have the 1.0 in Synaptic, possibly generating more momentum to finalize the 1.1 release
[23:04] <dcordero> hi
[23:04] <matthijs> Launchpad? I'm taking a look now.
[23:05] <matthijs> But anyone here, that could help us out creating an initial set of binaries to host on our site, to "ease" the introduction?
[23:05] <dcordero> where is the protocol for fix a bug that need change code for the original developer?
[23:07] <mcisbackuk> matthijs: Launchpad is Ubuntu's bug tracking service, any prblems with Ubuntu, or any packages within it are filed on there. also any new Open Source projects which users/project owners feel would be good enough to go into Ubuntu get filed on Launchpad with the tag [needs-packaging], for help on using Launchpad, please visit the wiki at http://wiki.ubuntu.com/
[23:07] <mok0> matthijs: does the build use gnu autotools?
[23:07] <StevenK> matthijs: So, why are you trying to poach people that work on Ubuntu?
[23:07] <matthijs> mok0, yes, it builds perfectly on ubuntu :)
[23:08] <matthijs> StevenK, what do you mean?
[23:08] <mok0> StevenK: He needs help to package his software
[23:08] <mcisbackuk> matthijs: OK, well then that needs to be confirmed by a MOTU, please file a request at http://www.launchpad.net
[23:08] <StevenK> I didn't read it like thatr
[23:08] <StevenK> s/tr/t/
[23:09] <matthijs> I'm asking for help, because I got stuck trying to package things a week or so and I *really* don't have any more time... even if I would like to
[23:09] <matthijs> And I want to produce quality stuff, not something made by checkinstall - also, I'm on really old hardware so it's a pain.
[23:09] <mcisbackuk> Well there are plenty of people within the Ubuntu community that can help, ut just asking here is not usually enough, if you file a request on Launchpad, then everyone can see it.
[23:09] <matthijs> I'm just about to :)
[23:10] <mcisbackuk> cool :)
[23:10] <mok0> matthijs: we're just a handful awake here
[23:10] <mcisbackuk> matthijs: that normally gets people to look, I mean I myself like the look of the project at a quick glance, I think it may come in useful someday to the Ubustudio team :)
[23:10] <mok0> matthijs: ... and most of us are busy, feature freeze for 8.04 is just a few days ahead
[23:11] <RAOF> You could also file a Debian RFP (request for package) I suppose.
[23:11] <mcisbackuk> That's true RAOF, since Ubuntu tends to take from the Debian packages hehe
[23:11] <matthijs> ah, well, I'm on launchpad, I registered, and I pressed the big red button -
[23:12] <mcisbackuk> matthijs: Hope it didn't blow up!
[23:12] <mok0> Arrrrhhhh noooooo
[23:12] <mcisbackuk> lol
[23:12] <matthijs> nope. everything still working
[23:12] <matthijs> pfew :)
[23:12] <mok0> matthijs: put "[needs-packaging]" before the text of your bug
[23:13] <mcisbackuk> hehe
[23:13] <avoine> Someone know if it's possible in a rules file to tell to cdbs to not run dh_shlibdeps for example in the building of the package?
[23:14] <mcisbackuk> matthijs: Just put something like [needs-packaging] XXXnameXXX version x.x.x, please make sure you put a link to the download page of the project within the bug report.
[23:14] <mok0> matthijs: ... furthermore, once you've completed the entry, add a needs-packaging tag to it
[23:14] <mcisbackuk> avoine: I would assume you just don't call it?
[23:14] <matthijs> ah ok, that's clear - so I file an ubuntu bug and write a good summary
[23:15] <james_w> matthijs: are all the dependencies already packaged?
[23:15] <avoine> the only line I have in the rules file is: include /usr/share/cdbs/1/rules/debhelper.mk
[23:15] <mok0> avoine: use the DEB_SHLIBDEPS_ARGS variable
[23:15] <mcisbackuk> matthijs: Basically yeah, and also if possible put what your dependencies are - that would save a bit of work :)
[23:16] <james_w> matthijs: from a quick look it looks pretty clean, so it shouldn't be too fiddly, but the large number of dependencies might be a bit of a headache.
[23:16] <geser> avoine: why do you don't want dh_shlibdeps run?
[23:17] <mcisbackuk> Guys if I get this message after pbuilder finishes, does that mean there are hardly any changes, and I don't need to include the diff.gz, and just upload the interdiff? dpkg-genchanges: not including original source code in upload
[23:17] <mcisbackuk> dpkg-buildpackage: binary and diff upload (original source NOT included)
[23:18] <dcordero> mcisbackuk, what bug?
[23:19] <mcisbackuk> Ermmmm I'm updating an upstream release : bug #113653 apart from that all seems fine
[23:19] <dcordero> Bug #113653
[23:19] <james_w> mcisbackuk: that will happen for a non -1 upload. Sometimes you will need to force the inclusion of the upstream source (if the place you are uploading to doesn't have it already, or they always require it for other reasons). You can do this with the -sa flag.
[23:19] <mcisbackuk> ubotu hello?
[23:19] <dcordero> ubotu is sleeping :)
[23:19] <jdong> mcisbackuk: routing issue
[23:20] <mcisbackuk> james_w: I used -sa when I done the debuild
[23:20] <jdong> backup bots en route
[23:20] <avoine> geser: I'm trying to package a XO activitie and It have a .so file in it that prevent him to build: http://launchpadlibrarian.net/10805976/buildlog_ubuntu-hardy-i386.sugar-paint-activity_13-1.1_FAILEDTOBUILD.txt.gz
[23:20] <geser> mcisbackuk: that only means that the .changes file has no reference to the .orig.tar.gz (and uploaded get only the .dsc, .diff.gz and .changes files)
[23:21] <mcisbackuk> geser: Sorry can you dumb it down just a bit for me lol only a bit
[23:22] <ScottK2> avoine: Do you build-dep on libgtk2.0-dev?
[23:22] <avoine> no, I should?
[23:22] <ScottK2> Yes.  That's what's missing there.
[23:22] <mcisbackuk> geser: Do I still need to create an interdiff then since it's a new upstream release, and if so, what files do I upload?
[23:22] <avoine> ok thanks
[23:22] <matthijs_> wowsers my laptop just crashed due to excessive scrolling - that's what I mean by old hardware...
[23:23] <mcisbackuk> matthijs: Maybe you should be running Ubuntu yourself then ;)
[23:24] <geser> mcisbackuk: I'm not sure about the process for updating upstream versions and which file should be added to the LP bug
[23:24] <matthijs_> er. I AM running ubuntu - but packaging is just too hard for me :)
[23:24] <mcisbackuk> geser: OK no worries
[23:24] <mcisbackuk> matthijs: Don't worry, just fiel the bug and let one of the guys do it :)
[23:24] <emgent> Fujitsu, heya
[23:24] <matthijs_> during the time the chroot comes up, I can make and drink a tea.
[23:24] <geser> avoine: from the build log I don't see nothing compiled. Does your package include pre-compiled code?
[23:25] <avoine> yeah geser
[23:27] <geser> avoine: bad, everything should be rebuild to a) know that it build (important for applying patches) and b) the source matches the binaries
[23:30] <avoine> ok, I have the source code and the makefile for the .so file
[23:30] <avoine> I just need to tell cdbs to remove the lib and recompile it
[23:32] <geser> yes
[23:44] <joejaxx> Good Evening ALl
[23:44] <joejaxx> All*
[23:44] <joejaxx> :)
[23:54] <matthijs_> hi everyone - I had to feed a baby in between - I reported the bug!
[23:54] <matthijs_> So I gues now I wait? ( sleep)