[00:00] <handschuh> is someone there to give my package a final review? (http://revu.ubuntuwire.com/details.py?package=uiflite)
[02:25] <smooth> hello motu community
[02:25] <smooth> i was having issues with a package im trying to upgrade...
[02:27] <jmarsden> smooth: Be more specific, just ask your question?
[02:27] <smooth> sorry...im watching the tech OU game...
[02:28] <smooth> after I run  debuild -S -sa
[02:29] <smooth> i get this error: debuild: fatal error at line 1329:
[02:29] <smooth> dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed
[02:29] <jmarsden> The next few lines probably say why... can you pastebin all the output from debuild so we can see it?
[02:30] <smooth> sorry how do i do that?
[02:30] <jmarsden> open a browser to http://paste.ubuntu.com and copy and paste your output there
[02:31] <jmarsden> Then you can give us the link to that web page you just generated.
[02:33] <smooth> http://paste.ubuntu.com/75824/
[02:36] <Elbrus> smooth: did you change the png files?
[02:37] <smooth> no i didn't change anything, i was just trying to apply the new upstream version to the ubuntu package...
[02:37] <Elbrus> smooth: remove them from your source file and you should be fine
[02:37] <Elbrus> (with respect to this error)
[02:37] <smooth> ok
[02:37] <Elbrus> s/file/tree
[02:38] <Elbrus> you leave them in the upstream tar-ball of course
[02:39] <jmarsden> smooth: You're doing an example from one of the packaging guides, right?  So it's odd you'd run into this sort of thing -- did you get the old and new brasero files from exactly where the guied said to get them?
[02:39] <smooth> yeah, i downloaded them straight from the links...its weird...
[02:40] <smooth> i think im just going to start over from the beginning and see if it happens again
[02:40] <jmarsden> OK.  Maybe the guide needs fixup for Intrepid or something??
[02:41] <smooth> yeah...thats what i was thinking, it may be an intrepid issue
[02:41] <smooth> or user error...lol
[02:41] <jmarsden> If your second go-around still fails in the same way, speak up and I'll see what happens when I try it here.
[02:41] <smooth> cool, i appreciate it
[02:48] <smooth> yup same thing
[02:49] <Elbrus> for bug 275688 I am looking into the text on https://wiki.ubuntu.com/StableReleaseUpdates
[02:49] <Elbrus> I guess it should be mentioned that licensing issues also warrant a SRU?
[02:51] <Elbrus> and because the source is re-engineered, it means all releases need updating to the latest version...
[02:51] <smooth> jmarsden I had the same issue
[02:51]  * Hobbsee thought that had an outstanding removal request
[02:51] <Hobbsee> jmarsden: the images probably changed.
[02:51] <Elbrus> Hobbsee: ?
[02:52] <Hobbsee> Elbrus: non-free data in the existing vesrion?  I thought it had a removal request, along with some others.
[02:52] <Elbrus> that means that fpc is going to be removed from the old archives? How can I see that?
[02:53] <Elbrus> Then I am not going to investigate the sru ofcourse..
[02:53] <Hobbsee> it was supposed to be, iirc.  it never was.
[02:53] <Hobbsee> they can't remove packages belatedly.
[02:53] <anakron> HI all
[02:53] <Elbrus> The latest version is free
[02:54] <Elbrus> So I thought that it would be a SRU matter...
[02:54] <Hobbsee> yes, it would be, then.
[02:56] <smooth> jmarsden: i had the same error
[02:57] <jmarsden> smooth: OK, I'm playing with it to see what happened...
[02:59] <jmarsden> smooth: Yes, the png files really are different between the two tarballs.  So all the warnins about that are not your fault.
[03:04] <smooth> jmarsden: I also get these two lines at the end... debuild: fatal error at line 1329:
[03:04] <smooth> dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed
[03:04] <smooth> jmarsden: shouldn't there be a space between -r and fakeroot?
[03:06] <jmarsden> smooth: I just did it (with no errors) with the commands at http://paste.ubuntu.com/75830/
[03:11] <jmarsden> smooth: On my (Intrepid) machine here the process went as shown at http://paste.ubuntu.com/75831/ -- looks good to me.
[03:14] <smooth> jmarsden: got it...could it be because i notice that i needed to change the version in dch -i?
[03:14] <smooth> i didn't notice
[03:14] <smooth> *
[03:15] <jmarsden> Could be.  In packaging, every little detail matters :-)
[03:15]  * jmarsden needs to go eat...
[03:17] <smooth> jmarsden: thanks for helping me out
[03:18] <jmarsden> smooth: no problem, welcome to the world of Ubuntu packaging :-)
[03:53] <anakron> Hi
[03:53] <anakron> how i can determine the right patch system to a bug?
[03:57] <nellery> anakron: do you mean for a package?
[03:57] <anakron> yeah
[03:57] <anakron> i want to start helping in a upper level
[03:58] <anakron> so ill try to get the right patch for a bug
[03:58] <anakron> testing it and making a "patched version"
[03:59] <nellery> anakron: ubuntu-dev-tools has a what-patch script that spits out the patch system in use
[04:01] <Hobbsee> you can usually look at debian/control to find it out, too
[04:02] <Hobbsee> and debian/rules
[05:01] <anakron> hi
[06:29] <Awsoonn> I seem to have messed up my packageing script and am unable to uninstall my package with dpkg --remove, is there a way to manually flush it out of the database?
[06:30] <jdong> how badly is it not uninstalling?
[06:30] <jdong> failing a postrm/prerm script? worse?
[06:31] <Awsoonn> postrm script fails
[06:31] <jdong> Awsoonn: the script is at /var/lib/dpkg/info/your_package_name.postrm
[06:31] <jdong> add exit 0 to the top of the script
[06:32] <persia> Or delete it, or fix the issue.
[06:32] <Awsoonn> that seems easy enough, cool beans
[06:32] <persia> In fact, you've an excellent test case now to chase the postrm bug, and when you get a fix, you could apply it to the packaging so this doesn't happen again.
[06:33] <Awsoonn> yes indeed
[06:40] <Awsoonn> that was perfect, thanks guys!
[06:42] <Awsoonn> dmsuperman: for the futre, there is a script at /var/lib/dpkg/info/package_name.postrm that I added 'exit 0' to teh very top of and was able to force it to remove form dpkg
[06:43] <Awsoonn> wrong window... obviously. :)
[06:44] <persia> heh.  Also, that's not usually the ultimate solution to the problem, as some of postrm probably works
[06:46] <stefanlsd> Laney: you around?
[08:23] <AnAnt> superm1: Hello
[08:24] <AnAnt> superm1: regarding sl-modem, isn't it already pulling the kernel headers as I've seen in the log you sent me ?
[11:00] <slytherin> geser: persia: any of you around (and not busy) for few merges?
[12:12] <guille_> hi
[12:15] <guille_> i've downloaded a package with apt-get source, (actually mysql-server), added an storage engine. and i would like to package it before installing (to have it controlled by the package-manager)
[12:15] <guille_> how can i package it?
[12:16] <leleobhz> dpkg-buildpackage
[12:16] <leleobhz> but you will need to change debian/rules at least
[12:18] <guille_> which file is it? i've tried to man the debian/rules but instead of showing the man page it shows me the perl source
[13:06] <mok0> Please remind me the name of the program that read debian/control and install the build-depends.... I have a hangover
[13:07] <sebner> mok0: apt-get buildep ?
[13:07] <Hobbsee> apt-get build-dep package, afaik.
[13:07]  * sebner ^5 Hobbsee =)
[13:08] <Hobbsee> :)
[13:10] <mok0> ... That's not it, because I am manually building using debuild
[13:10] <StevenK> dpkg-checkbuilddeps
[13:10] <StevenK> Will show you what you're missing
[13:11] <mok0> StevenK: so it does!
[13:11] <sebner> Hobbsee: we loose xD
[13:11] <mok0> Hehe
[13:11] <StevenK> apt-get build-dep will only work if the package is in Sources and hasn't changed since
[13:12] <Hobbsee> sebner: well...my general theory is that the package is usually in the repositories, apart from whatever changes you have made.  Which means you should probably remember, or easily be able to find out, your changes.
[13:12] <Hobbsee> so, it's close enough, most of the time
[13:12] <Hobbsee> short of that...pbuilder.
[13:12] <sebner> heh
[13:44] <persia> the get-build-deps script might be a handy tool when apt-get build-dep isn't right.
[13:45] <sebner> persia: still in town? =)
[13:45] <persia> sebner, Yep.  Another 12 hours or so
[13:46] <sebner> persia: cool :)
[13:47] <Xan3> i have a problem with virtualbox in jaunty, befor open a bug i want are sure that are bug and no my error
[13:48] <Xan3> anyone can listen me?
[13:48] <persia> Xan3, For tracking down a bug, you'd do better in #ubuntu-bugs
[13:48] <Xan3> also for ubuntu beta?
[13:48] <Xan3> i have the problem whith jaunty
[13:48] <Xan3> with
[13:49] <persia> For bug discussions.  If it's support you need, that's harder to find for jaunty now.
[13:50] <Xan3> i dont know if i need support or there is a bug in virtualbox in jaunty
[13:50] <persia> Right.  Someone in #ubuntu-bugs may be able to help you make that decision.
[13:50] <Xan3> ok
[13:50] <Xan3> thz
[14:18] <mok0> Hm. It'd be nice if the debhelper manpages told you what version of debhelper it appeared in.
[14:18] <mok0> was that understandable??
[14:24] <persia> Yes.  Really, the only way to know is to read the changelog.
[14:50] <anakron> HI all
[14:51] <anakron> if i want to become a motu, what i must do
[14:55] <laga> anakron: you need to become an ubuntu universe contributor first
[14:55] <laga> and then go from there
[14:56] <geser> grep-dctrl perhaps
[14:56] <laga> anakron: please, no private message
[14:56] <laga> let me get you that message
[14:56] <laga> err, wiki page
[14:56] <anakron> :O
[14:56] <anakron> ok
[14:56] <anakron> jeje
[14:57] <laga> anakron: https://wiki.ubuntu.com/MOTU
[14:57] <anakron> thanks a lot
[14:57] <anakron> have you seen dholbach around here?
[14:58] <RainCT> anakron: it easier to find him Mo-Fr
[14:58] <RainCT> *it's
[14:58] <anakron> Mo-Fr?
[14:59] <anakron> sorry i dont understand
[14:59] <RainCT> anakron: Monday to Friday, he has weekend now
[14:59] <anakron> a ok
[14:59] <anakron> thanks a lot
[15:08]  * persia notes that it's not required to be an ubuntu universe contributor before becoming MOTU, but that's it is often a step taken along the way.
[15:09] <persia> anakron, Also, MOTU should not be a goal: contribute as you like.  If your contributions indicate you should be MOTU, you will likely become MOTU.
[15:09] <anakron> hello emmet
[15:09] <persia> anakron, It's also worth noting that it's one of the values of Ubuntu that we do things on a team basis: it's rarely useful to seek out an individual, unless you're sure they are the only person who has the knowledge you seek.
[15:10] <anakron> nono
[15:10] <anakron> actually no
[15:11] <anakron> i want to help with package maintenence
[15:11] <persia> Oh, did you get anywhere with the bug I gave you before?
[15:12] <anakron> persia
[15:12] <anakron> i was sleeping
[15:12] <anakron> XD here its 12:12
[15:12] <persia> Sleeping is never a problem :)
[15:13] <anakron> XD
[15:13] <persia> On the other hand, you'd do best to find things about package maintenance that interest you, or ask people for help in getting strategies to find bugs you can fix.
[15:13] <anakron> that could be a way to solve my problem
[15:14] <persia> Helping with package maintenance is very much appreciated.  If you have questions about something you are doing, ask them here.
[15:16] <anakron> ok
[15:17] <anakron> ill read wiki in ubuntu motu section cause i want to help in package maintenance
[15:17] <anakron> :) see you later, i hope ill got some good results
[15:17] <persia> If you like.  There's a *lot* of information in the wiki.
[15:17] <anakron> and thanks for all your time
[15:17] <persia> You'd really do better to pick a bug, try to fix it, and ask here when you get stuck.
[15:18] <persia> People might point you at wiki pages, but at least you'd be pointed at useful things you could apply right away.
[15:18] <anakron> i think that, like a translation training, i could translate that wiki into spanish
[15:19] <anakron> it will be helpful for people that want to help, but dont know lots of english words if they want to read wikis
[15:19] <anakron> some people get stucked only cause they dont know how to read/talk english
[15:19] <anakron> ill try to do it
[15:22] <slytherin> NCommander: there?
[15:24] <RainCT> anakron: I think there's already some translation effort for Spanish (not sure though)
[15:24]  * RainCT asks effie_jayx 
[15:24] <slytherin> NCommander: are you aware of any kernel panics related to any combination of b43, rfkill_input and rfkill? I have unloaded the modules and my ibook does not have freeze problems for last 3 hours.
[15:25] <anakron> ok
[15:25] <anakron> rainct
[15:25] <anakron> RainCT
[15:25] <anakron> but a finished  translation?
[15:26] <anakron> cause some of those projects are not finished
[15:26] <RainCT> anakron: no, I don't think it's finished. but you should look what's done so that you don't repeat the same :)
[15:27] <anakron> :)  thats right
[15:27] <anakron> so, where i can find it?
[15:29] <RainCT> anakron: http://doc.ubuntu-es.org/Traducción  seems like it's only the Packaging Guide
[15:29] <anakron> its more than i expected
[15:29] <anakron> thanks a lot
[15:35] <bmm> I've got an upstream make install that installs the info file and manpage by itself. It seems impossible to disable this using the configure script and the install-info fails during the build (because the build system install-info is different from the GNU autotools version??). What should I do/
[15:35] <bmm> ?
[15:39] <persia> bmm, Build log?
[15:40] <bmm> http://launchpadlibrarian.net/19844176/buildlog_ubuntu-jaunty-i386.lzip_1.1-0ubuntu1_FULLYBUILT.txt.gz
[15:41] <bmm> persia: look for the "too many arguments" with install-info
[15:42] <bmm> There the upstream install does an install-info which fails because the build system install-info is different from the install-info it expects.
[15:42] <persia> Well, sounds like you've two options.  Either patch the build system to not generate the error, or use dh_installinfo to work around the issue.
[15:43] <bmm> persia: I use dh_installinfo, but it seems I need to patch the configure to get it not to include the install-info in it's generated make install
[15:43] <persia> Personally, I'd do both, as you don't generally want to run install-info at build time at all (as the info db on the buildd isn't really the target).
[15:43] <persia> Yep.  You'd have some stuff to comment out.
[15:44] <bmm> persia: ok, so make sure that configure doesn't do the info page and then use dh_install (which will trigger the right db rebuilds etc)
[15:44] <persia> While it's nice that upstream is installing the documentation cleanly, install-info just doesn't do anything useful on a buildd, and the result of having run it usually doesn't achieve the desired result for the end-user in this sort of system.
[15:44] <persia> Not dh_install.  dh_installinfo.
[15:45] <persia> It's important, because it changes the postinst.
[15:45] <bmm> persia: yeah, meant that one, sorry :D
[15:46] <bmm> persia: I'm actually using CDBS and only use it through defining a debian/lzip.info file.
[15:46] <persia> Even easier then :)
[15:46] <bmm> persia: is quilt or something else better to use in combination with CDBS? (or doesn't it matter?)
[15:47] <slytherin> persia: do you have some time for sponsorship?
[15:47] <persia> slytherin, I doubt it, unless it's *really* easy.  Which bug?
[15:47] <persia> bmm, Doesn't really matter: CDBS has rules to handle various things.  If there's not already a patch system in place for a CDBS package, I usually use simple-patchsys.
[15:48] <persia> (note that you *do* have to include the CDBS rules for whichever patch system you use)
[15:48] <bmm> persia: thanks!
[15:48] <slytherin> persia: bug #301224 and bug #300540. The lucene2 may not fall under definition of easy. It takes lot of time to build.
[15:50] <bmm> persia: cdbs-edit-patch seems the easiest, so simple-patchsys it is :) Thanks
[15:51] <stefanlsd> james_w: around?
[15:51] <james_w> hi stefanlsd
[15:51] <persia> slytherin, Both of those fall under "too hard", unfortunately.  I'm fairly certain that you've done jabref correctly, but it's a bit of checking, etc.
[15:53] <anakron> i found (with RainCT as guide) a bug that i can fix
[15:53] <stefanlsd> james_w: hi! since we're both working on ubuntu stuff on a sunday, doing the wordpress merge with the new patch. I would also like to include the CVE that we marked as wont fix. We didnt want to do it for Intrepid as it was a bit of an SRU thing, but I think we should include it for Jaunty and to maintain sync with debian.  bug #269301
[15:53] <james_w> stefanlsd: go for it
[15:54] <stefanlsd> james_w: k. cool.
[15:54] <anakron> is an amarok bug :)
[15:55] <slytherin> persia: ok, no issues.
[16:03] <bmm> Request for comments :) Anybody willing to comment on my newly patched package: http://revu.ubuntuwire.com/details.py?package=lzip
[16:13] <persia> bmm, How is lzip different/better than the other several LZMA implementations already present?
[16:14] <persia> bmm, Also, when there is more permissive licensing for some files, it's polite to list them in debian/copyright to notify users of this, and extend them the more permissive rights.
[16:16] <bmm> persia: I actually started packaging this because it seemed like a simple CDBS try-out package. But it seems the author is pretty against LZMA because of their file format. http://lists.gnu.org/archive/html/lzip-bug/2008-11/msg00012.html
[16:16] <bmm> persia, I'll add a mention of more permissive rights to the copyright...
[16:17] <G__81> whats the channel for ubuntu infrastructure ?
[16:18] <persia> bmm, Hrm.  While I can see the point, I think I become more worried by having multiple lzma compression tools with *incompatible* on-disk formats.  Maybe I'm just conservative.
[16:18] <persia> G__81, Depends what you mean.  Which part do you seek to ask about?
[16:19] <G__81> like the people who maintain and develop the ubuntu tools
[16:20] <G__81> and also maintain the ubuntu servers
[16:20] <persia> G__81, There's no set for that.
[16:20] <persia> The tools are primarily maintained by all Ubuntu developers.
[16:21] <persia> And while there is certain commonality in server maintenance, it's rare that there is a question for which a broad answer is both correct and able to be answered.
[16:25] <gouki> Do I need the ${shlibs:Depends} and ${misc:Depends} under Depends?
[16:26] <bmm> persia, I know, I had the same thoughts, but decided that as OS is also about the freedom to choose it would be a good addition: It's not like there is only one md5sum implementation in the repositories ;)
[16:27] <bmm> gouki: probably, they contain the library dependencies of your generated binary, they are created automatically so it's good to have them there. Is there any reason to remove them?
[16:28] <gouki> bmm, no, not at all. Just wanted to know if they were required.
[16:28] <gouki> Thank you.
[16:28] <persia> bmm, Oh, I agree about choice: on the other hand all the different md5sum implementations in the repos produce the same results.
[16:29] <persia> gouki, If you're not compiling, you don't need ${shlibs:Depends}, and if you aren't using debhelper (note that CDBS depends on debhelper), you don't need ${misc:Depends}
[16:30] <gouki> persia, OK. Thank you.
[16:30] <bmm> persia: haha, yeah that is true. I'll do a new upload in a few minutes. Would you be willing to post your comments on REVU so other people can see? (and comment on it at a later date)
[16:31] <persia> bmm, I don't have time for a proper review.  The philosophical thing is a debate topic.  The licensing change is just being polite (and you're likely to fix it).
[16:32] <bmm> persia, already fixed it. Thanks for your help, I'll see if I can get a full review some other day.
[16:46] <ryanakca> Hmm... I tend to upload new packages to Debian, and then get them synced into Ubuntu, so that both *Ubuntu and Debian benifit from it... would that count towards becomming a MOTU? Or is it only Universe specific contributions that count?
[16:47] <sebner> ryanakca: I'd say you are collecting bonus points
[16:48] <ryanakca> sebner: *nod*, thanks
[16:53] <persia> ryanakca, It definitely counts for technical review (with, as mentioned, bonus points), but doesn't tend to count as much for community integration.
[16:54] <sebner> persia: You are making me nervous. I always think you already left without sending your reviews/votes to the MC   ^^
[16:55] <persia> sebner, No reason to be nervous.  I've left instructions about what is to be done if that happens
[16:56] <persia> Having a browser such that 1) upstream cares enough to make sure that I can upgrade between releases, and 2) doesn't crash every few minutes would help of course.
[16:56] <sebner> persia: sure but not funny if all the work you've done is useless
[16:57] <persia> ryanakca, In your case, you've already got the community integration bit covered, so it's all in your favour.
[16:58] <persia> sebner, It's never useless.
[16:58] <sebner> persia: well, if it's public ...
[16:58] <effie_jayx> RainCT, for?
[16:59] <ryanakca> persia: I do? I've helped out with Kubuntu stuff... and done some merges... but I haven't done a lot to integrate myself into the MOTU yet...
[17:00] <effie_jayx> RainCT, caught up, shall keep and eye for mor translations.
[17:01] <persia> ryanakca, Well, you've been around a bit.  You'll want to get some people to endorse your application, but since you're already an Ubuntu Member, there tends to be slightly less scrutiny on that side.
[17:01] <ryanakca> persia: splendid, thanks :)
[17:05] <slytherin> persia: my ibook is not freezing anymore. The root cause is one of the modules b43, rfkill and rfkill_input. I hope I can figure out and solve the problem. Of course not freezing means that I can now check state of openjdk on powerpc. :-)
[17:21] <persia> slytherin, Cool!
[17:50] <anakron> hi all
[17:50] <anakron> one question
[17:50] <anakron> im fixing a bug, an easy one
[17:50] <anakron> that makes isomaster add two entries into menu
[17:50] <anakron> i solved it editing isomaster.desktop in sourcefile
[17:51] <anakron> but how i can add it into changelog.dch
[17:51] <persia> dch -i
[17:51] <persia> then add a comment explaining what you did, with the bug number
[17:51] <anakron> i add, "*Fix isomaster.desktop, cause it adds two entries in menu"
[17:52] <persia> Well, I'd say "Change .desktop file to only show once in the menu (LP: #nnnnnn)"
[17:54] <anakron> yes
[18:25] <RainCT> uhm.. what is the /usr/share/app-install/desktop/ directory for?
[18:30] <persia> RainCT, To provide .desktop files from app-install-data, to support software installation by icon.
[18:32] <RainCT> persia: That's what I thought, thanks :)
[18:34] <ryanakca> persia: Hmm... I don't think you've sponsored any of my packages yet, but continuing the discussion earlier, I was reading w.k.o/UbuntuDevelopers ... D'you think I'd be able to apply to universe-contributors as I stand, or should I do a few more merges?
[18:35] <ryanakca> My slight problem is that I haven't had a single sponsor, but rather whoever was available / interested in sponsoring <x> package
[18:43] <persia> ryanakca, There's absolutely no benefit for you to apply as a universe contributor, unless you just want an extra emblem on your LP page.
[18:43] <persia> You're already an Ubuntu Member.
[18:44] <Laibsch> james_w: do the latest two debdiffs for hardy and intrepid from bug 227547 look OK to you?
[18:44] <Laibsch> Maybe somebody feels inclined to do that SRU for above bug?
[18:45] <directhex> hm. when's UDS coming back to oxford? i could go during my lunch break! 8D
[18:45] <james_w> Laibsch: hi, the hardy one needs a different version number
[18:46] <james_w> it needs a version number less than anything that will be in Intrepid or later
[18:46] <ryanakca> persia: ah, splendid, ok. Mind if I update the page? I was under the impression that to become a MOTU, one had to become a universe contributor first
[18:46] <Laibsch> 2.3.3-1ubuntu1~hardy1 OK?
[18:46] <james_w> Laibsch: well, sorry, no. We have a convention for version numbers
[18:46] <Laibsch> 2.3.3-1ubuntu2~hardy1 OK?
[18:47] <Laibsch> Where can I read about that?
[18:47] <Laibsch> Those version numbers are a real killer
[18:47] <james_w> and the convention for an SRU is to not use ubuntu2
[18:47] <persia> ryanakca, Which page?
[18:47] <james_w> Laibsch: https://wiki.ubuntu.com/SecurityUpdateProcedures has a guide
[18:47] <ryanakca> persia: https://wiki.kubuntu.org/UbuntuDevelopers
[18:47] <james_w> Laibsch: that's something I can do when sponsoring though
[18:48] <james_w> Laibsch: your intrepid one has the dpatch, plus the change applied in the .diff.gz as well by the look of it
[18:49] <Laibsch> Well, I didn't understand how that happened
[18:49] <persia> ryanakca, Which part would you change, and how?
[18:49] <Laibsch> do you?
[18:49] <james_w> Laibsch: does hardy not use a patch system?
[18:49] <Laibsch> you mean hardy-hardy or wordpress-hardy?
[18:49] <persia> What.  That top part is almost entirely wrong in several annoying ways.
[18:50] <james_w> Laibsch: I'm not sure how it happened, but you have edited the files in the upacked source package, if you undo the change in the unpacked source package, just leaving the dpatch, and rebuild it should work out.
[18:50] <james_w> Laibsch: sorry, wordpress in hardy.
[18:50] <Laibsch> OK, I'll prepare some more debdiffs and publish them for your inspection first
[18:50] <Laibsch> to avoid clutter in the bug report
[18:51] <ryanakca> persia: Under the Ubuntu Contributing Developers header, I'd append a point stating that ``You are not required to become an Ubuntu Contributing Developer if you are already an Ubuntu Member''
[18:51] <james_w> Laibsch: I'm just going for dinner, I'll see about sponsoring whatever you have when I return.
[18:51] <Laibsch> james_w: Cool
[18:52] <Laibsch> james_w: hardy does not yet have a patch system
[18:52] <persia> ryanakca, You're not required to become any of them though.  You could go straight to core-dev.
[18:52] <Laibsch> I'll continue to patch the source and use diff.gz instead of a separate patch as in the case of intrepid
[18:52] <persia> (this is exceedingly rare, and would require a very specific and individual sort of candidate who just completely failed to apply for anything else for an extended period of time)
[18:53] <ryanakca> persia: ah, ok. I see, Thanks.
[18:54] <stefanlsd> Laibsch: if it uses dpatch - i'd really recommend using dpatch-edit-patch
[18:59] <Laibsch> I think you are mistaken
[18:59] <Laibsch> We are talking about the 2.3.3 wordpress package in hardy
[18:59] <anakron> persia, i create my first .debdiff file :)
[19:01] <persia> ryanakca, Is that less confusing?
[19:02] <stefanlsd> Can anyone please explain to me why in our debdiff's between debian and ubuntu the .po files differ? (must be some automated process that does something different)
[19:02] <ryanakca> persia: Yep, thanks :)
[19:04] <persia> ryanakca, I hadn't read that page carefully in a while, and it seemed to have grown several parts that were mostly wrong.  Thanks for pointing it out.
[19:05] <ryanakca> If upstream states that the program can be distributed under GPL version 2 (only), do I have to state in my debian/copyright file that it can be distributed only under version 2? Or can I just say it that it can be distributed under GPL version 2?
[19:05] <persia> Oughtn't really matter, just be careful not to state "version 2 or greater".
[19:06] <ryanakca> ok.
[19:40] <chillywilly> hi
[19:41] <Laibsch> james_w: http://oss.leggewie.org/wip/wordpress_hardy.debdiff
[20:02] <guille_> have you been able to sucessfully package mysql + SphinxSE?
[20:02] <guille_> this is a nightmare
[20:30] <serialorder> sometimes when retrieving a package with grab-merge it will end with ""It looks like this package is maintained in revision control. "You almost certainly don't want to continue without investigating."
[20:31] <serialorder> what should one 'investigate' with those packages?
[20:36] <persia> serialorder, Look in the Vcs-* headers, and check the current contents of the VCS.
[20:41] <serialorder> persia: would you mind elaborating a little bit?
[20:41] <persia> serialorder, Look in debian/control for the Vcs-* headers.
[20:41] <persia> Use those to find the VCS.
[20:41] <persia> Check the Vcs for both Debian and Ubuntu.
[20:42] <persia> If there's a VCS for Ubuntu, you want to commit there, rather than just doing a sourceful upload and moving on.
[20:44] <serialorder> so if debian/control only lists a VCS for debian then does that mean there is not one for ubuntu or is there some standard place i should go check that might not be listed?
[20:46] <persia> Well, you want to check both the Debian and Ubuntu versions.  If they are the same, you probably want to switch to XBCS-Original-Vcs-* during the merge.
[20:55] <serialorder> ok im pretty sure there is only a debian version, so went there and looked at the log and the latest entry in debian/changelog is not in the VCS log
[20:55] <serialorder> im guessing that means i should not bother merging at this point?
[20:56] <persia> Well, it should only show up on MoM or DaD if there is a merge planned.
[20:56] <persia> And if the latest version isn't in the VCS, something has already gone terribly wrong.
[21:02] <ryanakca> Why do some packages have x.y.z-1build1 instead of x.y.z-1ubuntu1 ?
[21:02] <persia> ryanakca, No real patch, just a fresh upload to cause a fresh rebuild.
[21:03] <ryanakca> persia: ah... why would you want to rebuild it without changing anything?
[21:03] <serialorder> yeah the VCS log is definitely one entry behind ./debian/changelog
[21:03] <persia> ryanakca, Say you had a library that changed ABI, but didn't change API, and you wanted to use the new ABI.
[21:03] <serialorder> package is clisp
[21:04] <serialorder> im just going to ignore it =)
[21:04] <serialorder> move on to another package
[21:04] <ryanakca> persia: ah, ok, thanks :)
[21:06] <directhex> does XbuildY get synced automatically still?
[21:07] <persia> directhex, Should.
[21:08] <persia> Anyway: no more IRC for me.  Have fun.
[21:38] <james_w> https://wiki.ubuntu.com/StableReleaseUpdates doesn't say where in the process the motu-sru ack comes. Does anybody know?
[21:39] <james_w> Laibsch: hardy looks good, thanks. Do you have Intrepid?
[21:39] <james_w> Laibsch: if not I can easily make the changes
[21:48] <ScottK> james_w: Usually before upload, but not always.
[21:49] <james_w> should that be on the wiki page?
[21:51] <ryanakca> When merging from Debian, should one update the standards version?
[21:52] <james_w> ryanakca: there's not much point
[21:52] <james_w> I consider it a waste of time
[21:54] <ryanakca> james_w: *nod*, and, will the lintian / etc packages get backported to Intrepid so that we don't get ``bad-ubuntu-distribution-in-changes-file jaunty'' & company?
[21:54] <james_w> I believe that lintian is in -backports
[22:01] <ScottK> Actually we need to backport again.
[22:01] <ScottK> for lintian.
[22:02] <ScottK> ryanakca: One should not update the standards version according to Ubuntu Policy.
[22:03] <ryanakca> ScottK: thanks
[23:16]  * ryanakca now sees the use of a README.source
[23:42] <savvas> does anyone know what's the deal with frostwire packaging?
[23:42] <savvas> something about libraries not being arch specific?