[00:03] <dcordero> hi
[00:31] <aquo> is there any reason to prefer dput over dupload or vice versa?
[01:08] <zul> evening
[01:08] <persia> morning
[01:27] <sistpoty> hi folks
[01:30] <bddebian> Heya sistpoty
[01:30] <sistpoty> hi bddebian
[01:31] <bddebian> Is it too late to request syncs for Hardy?
[01:31] <sistpoty> bddebian: we're not yet in a feature freeze, so anything may still go in
[01:32] <sistpoty> at least until 14th, then FeatureFreeze applies
[01:35] <asantoni> bi-daily package badgering: if any MOTU feels like reviewing my package, I'd appreciate it: http://revu.tauware.de/details.py?package=mixxx
[01:35] <asantoni> :)
[01:36] <sistpoty> asantoni: give me a few minutes, then I'll take a look
[01:36] <asantoni> thanks sistpoty!
[01:37] <persia> asantoni: mixxx is already inthe repositories.  Is this an new upstream, or just a patch?
[01:37] <asantoni> Yes, new upstream
[01:39] <persia> asantoni: The best way to get that approved and uploaded is to attach the diff.gz to a bug and subscribe ubuntu-universe-sponsors, rather than pushing to REVU.
[01:39] <persia> asantoni: There are also some other bugs for that package (https://launchpad.net/ubuntu/+source/mixxx/+bugs): maybe some of them are fixed by your new upload?
[01:39] <asantoni> Yes, most of those should be fixed
[01:39] <asantoni> (if not all)
[01:40]  * persia seeks a second advocate for http://revu.ubuntuwire.com/details.py?package=whysynth as step 3 in the plan to enable gstreamer-midi for hardy
[01:40] <asantoni> persia: What do I open the bug against?
[01:40] <persia> asantoni: Would you mind testing, and adding (LP: #nnnnnn) in your changelog for the bugs that will be closed?
[01:40] <asantoni> (mixxx in Launchpad? or the mixxx package in Launchpad?)
[01:41] <persia> asantoni: The bug should be opened against the mixxx ubuntu package in launchpad.
[01:41] <asantoni> persia: They were fixed in upstream... is that still relevant for the ubuntu changelog?
[01:41] <asantoni> Ok, thanks
[01:42] <persia> asantoni: Only in excerpted fashion, and to help identify when and how the bugs were fixed.  You might add extra indented lines under the New Upstream Release indicating which specific things were fixed, and which bugs those close.
[01:43] <asantoni> persia: ok... I'll try... This is rather awkward though, because we've fixed like 100 bugs that are in our SourceForge tracker
[01:43] <persia> Also, mixxx in hardy is currently 1.6.0~beta1-1ubuntu2: it looks to me like your changelog lost sync with development at some point.  Perhaps it's worth a check?
[01:44] <asantoni> and we do packaging for Windows and OS X as well (so it adds up)
[01:44] <asantoni> persia: I pushed the changes that were in that hardy version into upstream
[01:44] <sistpoty> persia: since you advocated extremetuxrace, I assume that you've checked the orig.tar.gz? (then I won't do the check again *g*)
[01:45] <persia> sistpoty: Err.  I'm guilty today.  Let me check again...
[01:45] <persia> sistpoty: Yep.  orig.tar.gz is clean.
[01:45] <sistpoty> persia: heh, np... I'll just download the orig.tar again
[01:45] <sistpoty> ah thanks
[01:45]  * persia checked the last version, but forgot to doublecheck the md5sum for the updated version
[01:45] <asantoni> ah crap, I can't attach the diff.gz, I'm at my parents for the weekend :/
[01:46] <asantoni> I've just linked to it
[01:46] <persia> asantoni: Perhaps a different question: is there a newer version than 1.6.0 beta1 out?  If not, we've that already in hardy, so perhaps you don't need to update?
[01:46] <asantoni> persia: Yes, we just released beta2
[01:47] <asantoni> and we absolutely DO need the update - beta1 has some critical stability issues
[01:47] <asantoni> (I really don't want to screw our users over)
[01:47] <persia> asantoni: Completely understood.
[01:47] <asantoni> thanks
[01:47] <rhpot1991_laptop> does anyone know how I include a file with a space into debian/docs?
[01:48] <asantoni> (I didn't even intend for beta1 to get into Universe. It was packaged by someone non-official in Debian, and got slurped up through that)
[01:48] <rhpot1991_laptop> I tried \ before the space and 's around the name, both failed
[01:48] <persia> Anyone have a some time to review the updated mixxx, take care of LP bug cleanup, and submit a diff.gz to help asantoni?
[01:50] <sistpoty> rhpot1991_laptop: though I'm no perl expert (dh_installdocs is perl), I guess just putting the name with spaces in there might eventually do it
[01:51] <rhpot1991_laptop> tried that too actually
[01:51] <rhpot1991_laptop> though you give me an idea
[01:54] <asantoni> persia: so is something like this correct? http://pastebin.ca/898098
[01:54] <asantoni> and will Launchpad automatically close those bugs for me then?
[01:56] <sistpoty> asantoni: iirc you'll need a # before the bug number (as in LP: #number)
[01:57] <sistpoty> asantoni: if you build the source package (i.e. generate a changes file), the changes file should have s.th. like "launchpad-bugs-fixed: number, number, .." in there
[01:57] <persia> asantoni: Looking at some of these bugs, it appears they were closed long ago.  In general, I'd prefer something like "Updated playlist handling (LP: #122476)", but in this case, you might just want to ignore some of them (e.g. 75037 may not even be a bug in mixxx).
[01:58] <asantoni> I feel like I may not be able to figure all of this out
[01:59] <asantoni> In a perfect world, I just want to say "New upstream release" , and close the bugs that I know this fixes, lol
[01:59] <asantoni> ok, so I'll look at the changes files though to make sure this changelog works
[02:00] <persia> asantoni: Thanks for trying.  If you get stuck, just ask here for someone to take over bug #190589 to get it in.
[02:00] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589
[02:00] <asantoni> ok, thank you very much persia, I'll try my best
[02:13] <RAOF> Right.  Let's see if this only-somewhat-uuuuurgly multi-arch alsa-plugins builds right.
[02:49] <RAOF> It's alive!  It's _alive_!
[02:50] <sistpoty> hm?
[02:50] <sistpoty> self-modifying code? *g*
[02:51] <RAOF> I can now build lib32asound2-plugins in a less than totally evil way.
[02:51] <sistpoty> excellent!
[02:51] <RAOF> And if I had access to any of the other archs, it should build lib64asound2-plugins, too.
[02:53] <RAOF> Oh, I suppose I should build it under Sid, too.
[02:54] <RAOF> Pulseaudio support for wine is now mine!
[02:54] <sistpoty> RAOF: maybe ubuntuwire has an arch you could need? (not too sure for which arches we have servers, I only know of sparky, which shouldn't be used for building, because then revu goes down *g*)
[02:55]  * RAOF actually *looks* at debian/control.
[02:56] <RAOF> So, I should be able to test the build at least; it'll build lib64foo on i386, powerpc sparc and s390
[02:59]  * RAOF checks whether he's got an i386 sid build environment
[03:04] <sistpoty> asantoni: sorry for the delay, I'm just looking at the .diff.gz... seems like you dropped changelog entries from the current hardy version in debian/changelog
[03:08] <sistpoty> asantoni: also, please describe your changes in debian/changelog (e.g. what patches you dropped, what build-dependencies you updated etc.)
[03:22] <bddebian> I think I've finally figured it out.  I think MOTU generally has a better sense of humor than Debian. :-)
[03:22] <sistpoty> heh
[03:22] <bddebian> I'm serious, it's kind of sad.
[03:24] <sistpoty> bddebian: btw.: why aren't you a DD yet, seeing so many qa or games uploads from you?
[03:24] <sistpoty> (then I could ask you for sponsoring debian uploads *g*)
[03:24] <bddebian> heh
[03:24] <bddebian> I dunno man, I'm starting to think I should withdraw my app
[03:24] <bddebian> And go back strictly to Ubuntu
[03:25] <persia> bddebian: No point withdrawing the application.  Even if you focus on Ubuntu, DD can be useful.
[03:26] <sistpoty> strange enough, I'm even further below in the nm list than bddebian, and feel guilty, since I didn't do anything but bug forwarding since quite some time
[03:26] <bddebian> I don't know, maybe it's because I'm some "evil American" or something, I just don't get the "culture".   Everyone takes everything so damn seriously, yet pukes like are can spout nothing but useless drivel all day long..
[03:26] <sistpoty> (maybe the caveats of FIFO *g*)
[03:27] <bddebian> s/are/ari/
[03:28] <sistpoty> heh, /me is reminded by some of Reinhard's postings to debian-devel, which are much less forgiving (dunno the right word) than to ubuntu mailing lists *g*
[03:30] <sistpoty> asantoni: can you run lintian on the resulting debs? should give you some hints on what still needs fixing
[03:34] <Legendario> good evening. i would like to see if someone could gimme some help
[03:34] <LucidFox> I got up expecting some Ubuntu mail, and all I got were notifications of spam in my blog :(
[03:34] <bddebian> sistpoty: Farther up the list how?
[03:34] <Legendario> how to pack a package without a make file?
[03:34] <sistpoty> bddebian: https://nm.debian.org/nmlist.php
[03:35] <bddebian> Legendario: Just build the way upstream builds
[03:35] <LucidFox> Legendario> What build system does it use?
[03:36] <bddebian> sistpoty: Isn't that just alphabetical?
[03:36] <Legendario> when, i don't know if i understood the question, but the tar.bz2 file the author offers has already a binary in it...
[03:36] <sistpoty> bddebian: doesn't seem like it... at least not to my known alphabet *g*
[03:36] <bddebian> Well I never looked that closely :-)
[03:37] <sistpoty> heh
[03:37] <bddebian> Legendario: It shouldn't, that's bad form.  You should build the package from "source"
[03:38] <bddebian> Of course you can just mv/cp the files around
[03:38] <Legendario> bddebian, i know, but it only offer an rpm package and one like i've told you
[03:39] <Legendario> bddebian, but when i ask pbuilder to build it, it says no make file was found.
[03:39] <bddebian> Kick upstream :-)
[03:40] <Hobbsee> Legendario: does it claim to be gpl?
[03:40] <Legendario> bddebian, sure
[03:40] <Legendario> http://checkgmail.sourceforge.net/#download
[03:40]  * Fujitsu notes that's already packaged.
[03:40] <Hobbsee> checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Packages
[03:40] <Hobbsee> checkgmail | 1.13-1ubuntu1 | http://archive.ubuntu.com hardy/universe Sources
[03:41] <bddebian> Yeah, I thought that sounded familiar
[03:41] <persia> Further, upstream is very active with https://launchpad.net/checkgmail
[03:41] <persia> Err.  Maybe not any more.  Used to be, but that only has 1.12 and hardy has 1.13
[03:42] <Legendario> yeah, i want to make a 1.13 gutsy version to place on my PPA
[03:42] <persia> Legendario: If it works in gutsy, why not just request a backport?
[03:44] <bddebian> Heya LaserJock
[03:44] <Legendario> persia, how is it?
[03:44] <sistpoty> hi LaserJock
[03:44] <persia> !backports | Legendario
[03:44] <ubotu> Legendario: If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[03:45] <LaserJock> hi all
[03:46] <Legendario> persia, it's because the actual 1.12 version on gutsy is not working anymore
[03:47] <Legendario> hi | LaserJock
[03:47] <persia> Legendario: That would be a bug, and likely sufficient for an SRU.  Have you reported a bug?  If not, please do so: this ought be fixed for everyone, rather than just in a PPA.
[03:47] <persia> !sru
[03:47] <ubotu> Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[03:52] <firefly2442> how do I find the standards-version via the commandline again for the control file?
[03:54] <sistpoty> firefly2442: zless /usr/share/doc/debian-policy/changelog.gz | head -1 | cut -f 2 -d'(' | cut -f 1 -d ')'
[03:54] <sistpoty> (assuming, you have an up to date hardy installed)
[03:55] <firefly2442> I'm in gutsy
[03:56] <sistpoty> firefly2442: then look at http://www.debian.org/doc/debian-policy/, version (at the bottom of the page)
[03:57] <firefly2442> thanks
[03:59] <LaserJock> sistpoty: apt-cache show debian-policy | grep Version: ?
[03:59] <sistpoty> LaserJock: heh, my command is much longer, and hence more geeky *g*
[03:59] <LaserJock> I'll give you that
[04:00] <Legendario> persia, ok. thanks for the explanation. I got to understand all the stuff about the backports and sru. But one thing still intriges me: I have downloaded the orig.tar.bz2 file on from the hardy repository and it is exclaty the same one i have and it does not contain the source. I contais the same binary on it
[04:00] <Legendario> how could it be packed?
[04:02] <sistpoty> Legendario: if it is gpl, then it must contain the sources (or include a document which points to the sources)
[04:04] <squentin> Legendario: it's a perl script, there is no difference between source and executable
[04:07] <Legendario> squentin, so if i uncomment the perl line on the debian/rules script i should be able to package it?
[04:09] <squentin> Legendario: you just have to copy the perl file to its right place, dh_perl will just calculate perl dependencies, it won't install anything
[04:10] <firefly2442> how do I create these "postinst and prerm" from scratch?
[04:11] <Legendario> squentin, what place would it supposed to be?
[04:11] <squentin> /usr/bin/ I think
[04:13] <bddebian> Ah well this cold/flu is finally catching up to me, gnight folks
[04:15] <squentin> Legendario: btw, there is already a package in ubuntu, so you should start from it
[04:17] <Legendario> squentin, i have downloaded it. Is that what you mean?
[04:20] <squentin> Legendario: well, the latest is already in hardy
[04:22] <Legendario> squentin, well i know it now, and there is already a bug asking to backport it. [Bug #189795]
[04:22] <ubotu> Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795
[04:23] <Legendario> but now i am only interested on learning how to pack something that does not have a make file just like this package
[04:23] <squentin> well you can look at this package to see how it's done
[04:24] <sistpoty> Legendario: basically it's just a copy the files in debian/rules. however for some languages, there exist specific policies (e.g. python, perl)
[04:25] <jdong> Legendario: do you know of the scale of the changes required to fix Gutsy's version?
[04:25] <squentin> a make file is not magical, instead of calling the makefile, you just copy the needed files
[04:25] <jdong> how DARE you!
[04:25] <jdong> a makefile is magic!
[04:25] <jdong> 100% magic.
[04:25] <Legendario> jdong, i guess the new 1.13 version corrects it
[04:25] <squentin> :)
[04:25] <jdong> automake is.... err.... that really subpar harry potter novel.
[04:26] <jdong> the 2nd one.
[04:26] <jdong> Legendario: well... yeah... but how big were teh changes that actually corrected it?
[04:26] <squentin> the package is simple, there is only a few file, only the perl file is important
[04:26] <jdong> Legendario: I'd like to consider it for the -updates repo if at all possible
[04:27] <Legendario> this is something i can't tell you. But i consider yours a good idea
[04:28] <squentin> it doesn't work at all with the 0.12 version ?
[04:28] <squentin> 1.12
[04:29] <Legendario> squentin, no. it stopped to work about a month ago
[04:30] <Legendario> sistpoty, but how does it go on the rules file itself?
[04:30] <Legendario> squentin, it used to work very well until then
[04:31] <squentin> sounds like a good reason to put it in updates
[04:31] <sistpoty> Legendario: debian/rules is just a makefile, which has a few specific targets. basically, the binary target must ensure that a complete package falls out
[04:32] <sistpoty> Legendario: to do so, e.g. debhelper can be used (there are various dh_* calls, that make creating a .deb easier)
[04:33] <sistpoty> Legendario: usually you install everything that should go into the deb package in an install rule in there (and could do a cp there)
[04:34] <sistpoty> Legendario: which of course must be aligned to the debhelper calls, that build the binary (not too sure which dh_ call it is, but one expects all files to install under debian/<binarypackagename>
[04:34] <sistpoty> (imo it was dh_installdeb)
[04:35] <Legendario> sistpoty, what does imo mean...?
[04:35] <sistpoty> hm... where should I start... maybe we'll look at the current hardy package, ok?
[04:36] <squentin> imo=In my opinion
[04:37] <sistpoty> Legendario: if you look at debian/rules there, binary depends on binary-indep, which depends on install
[04:38] <sistpoty> Legendario: so install will basically install all files that should be part of the debian package inside debian/checkgmail (relative from the top source dir of the package)
[04:39] <sistpoty> Legendario: then later (in the binary-indep target), there are the debhelper commands, to generate a .deb from what's in debian/checkgmail
[04:40] <sistpoty> Legendario: there's even a cp command in install, to just put a file to the right directory
[04:40] <sistpoty> Legendario: for each debhelper (dh_*) command, you can look at the manpage what it does
[04:44] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[04:45] <Legendario> sistpoty, is it too different if i try with the cdbs?
[04:45] <sistpoty> Legendario: cdbs will basically only have rules which call debhelper under the hood
[04:46] <sistpoty> Legendario: which hides some abstraction, but limits your flexibility
[04:46] <Aloha> under the hood. heh i like that
[04:46] <sistpoty> Legendario: the problem here is, that a SRU should impose *minimal* changes
[04:46] <sistpoty> Legendario: so changing from debhelper to cdbs is a no go for an SRU
[04:47] <persia> Aloha: That looks like an entire comprehensive collection of stuff.  Might it not be a good idea to break it down into several binary packages?
[04:48] <Aloha> persia, what do you mean?
[04:48] <sistpoty> Legendario: the best try for an sru, is to look which minimal changes are needed of the source, and to apply these... you should be able to explain every changed line
[04:49] <persia> Aloha: There seem to be daemons, pam bits, guis, etc.  Seems like a lot of different things in a single package.  On the other hand, maybe that's the right way to do it (I'm not an expert when it comes to those things).
[04:49] <sistpoty> (otherwise it wouldn't be a valid sru, but maybe things changed nowadays)
[04:49] <persia> No, it's still minimal changes preferred.
[04:49] <sistpoty> heh
[04:49] <Aloha> persia, thats the way upstream put it together.
[04:50] <Aloha> persia, they have the most odd build system
[04:50] <persia> Aloha: The oddities of the build system, and the nature of the included docs is what made me think breaking it into a number of smaller binary packages (from one source package) might be best.
[04:52] <Legendario> sistpoty, i guess i am not the best person to tell u the reason "for every changed line"
[04:53] <Legendario> i do no programing.... ;-(
[04:54] <Legendario> i am just a computer enthusiastic who wants to contribute with the community by making some basic packaging and increasing his knowledge a little bit...
[04:57] <sistpoty> Legendario: there's still the option to request a backport... jdong should now the procedure ;)
[04:58] <Legendario> but in this case of packaging scripts, i am complitely lost
[04:58] <jdong> sistpoty: well, I'd like for *someone* to try investigating it as a SRU first
[04:58] <jdong> sistpoty: at least figure out what upstream did exactly to fix the problem
[04:58] <jdong> sistpoty: considering the current package is basically USELESS, I think we can argue even for a partly invasive SRU.
[04:58] <jdong> where "invasive" refers to the package's own codebase of course
[04:59] <sistpoty> jdong: I guess motu-sru should decide on what's appropriate ;)
[04:59] <ScottK> SRU should be minimal, but minimal to do the job may be large.
[05:00] <jdong> ScottK: agreed
[05:00] <ScottK> On Thursday we SRU'ed clamav from 0.88.2 to 0.92 in Dapper because there was no other way.
[05:00] <ScottK> err ... Friday
[05:01] <jdong> right. I'm curious about what the fix for this entails. It bugs me when the supported repo version of the package is entirely useless.
[05:01] <LaserJock> jdong: what package is this?
[05:02] <jdong> LaserJock: checkgmail
[05:02] <jdong> bug 189795
[05:02] <ubotu> Launchpad bug 189795 in checkgmail "[Backport] CheckGmail 1.13-1ubuntu1 to Gutsy" [Undecided,New] https://launchpad.net/bugs/189795
[05:02] <jdong> classic gmail-changed-api-so-scraper-doesn't-work.
[05:02]  * sistpoty just wanted to express that I don't want to make a decision if a backport or sru is right *g*
[05:02] <squentin> I took a quick look at the diff, there is lot of small changes, most of them probably unrelated to the fix
[05:04] <jdong> sistpoty: so you're dragging me into this? :D
[05:04] <sistpoty> jdong: sure... or anyone else wanting to jump in :P
[05:04] <LaserJock> if it's a fairly clean patch I think an SRU would most likely be appropriate, if it's gonna be useless it's pretty low risk to attempt a fix
[05:05] <jdong> LaserJock: right, and I doubt anything that is involved with the fix can blow up any other chunk of universe either.
[05:06] <jdong> At this point, my thinking is, if checkgmail can't check gmail, it can't get much worse.
[05:06] <LaserJock> :-)
[05:06] <LucidFox> Is there some program to access Gmail directly without using POP3/IMAP?
[05:06] <LucidFox> (Apart from a web browser :p)
[05:06] <sistpoty> persia: whysynth rejected, sorry
[05:07]  * persia goes to investigate why, and considers fixing it directly
[05:07] <sistpoty> persia: changing source license in packaging
[05:07] <sistpoty> (didn't check further than that though)
[05:08] <persia> sistpoty: Upstream doesn't want to release a new version right now, but has tracked down all the patch contributors and gotten them to agree to the PD dedication.  Any suggestions?  Without this, midi won't work in hardy again.
[05:08] <jdong> LucidFox: this thing I believe scrapes basically html gmail
[05:09] <jdong> LucidFox: but other than that, there is no other Gmail API publically published
[05:09] <sistpoty> persia: update debian/copyright with pointers instead, maybe even include mail messages in there
[05:09] <asantoni> Ok, someone help me here
[05:09] <LucidFox> :(
[05:09] <persia> sistpoty: Makes sense.  I'll fix that.  No other issues?
[05:09] <asantoni> I've got a workflow problem with this DEB thing
[05:09] <persia> jdong: I think it gets it from the atom feed.
[05:09] <persia> asantoni: Where are you?
[05:09] <sistpoty> persia: as I wrote, I stop checking then.. but I can do a more thorough check if you want
[05:10] <jdong> persia: ah, ok, that sounds much more reasonable :)
[05:10] <asantoni> We've got targets in our SCONS setup to build packages for every platform
[05:10] <asantoni> (Windows, OS X, and Ubuntu)
[05:10] <asantoni> every time we do a release, I update our Ubuntu package, which we host on our own site
[05:10] <persia> sistpoty: If you would.  I'll sort out the licensing, but I'm very interested in getting this in for hardy so that we can undisable the gstreamer-midi build.
[05:10] <asantoni> so we have our own "debian" directory that sits in our source tree, which contains our own changelog
[05:11] <sistpoty> persia: sure, will do
[05:11] <persia> sistpoty: Thanks.
[05:11] <sistpoty> persia: I won't do a complete license check then ;)
[05:11] <asantoni> so now I'm trying to figure out what the best way to deal with having to merge the universe package's changelog with my own
[05:12] <asantoni> all of the patches to our package in universe have been pushed upstream
[05:12] <persia> sistpoty: I think the only issue is with the patches: I looked at the other files.  Upstream shipped them without any licensing information.  I'll review again, carefully, before uploading (or getting vemon to upload) a new candidate.
[05:12] <sistpoty> persia: thanks
[05:12] <asantoni> but I guess it matters to you guys that the changelog be kept intact (I can understand that)
[05:13] <sistpoty> asantoni: imo your (upstream-wise) changelog and the ubuntu changelog are two different things... maybe a branch could help?
[05:14] <asantoni> sistpoty: hmmm, maybe
[05:14] <persia> asantoni: Officially, upstreams are encouraged not to host a debian/ directory.  Of course, this can make it awkward to create Ubuntu packages external to the repositories.  I'd suggest tracking a separate branch (as sistpoty suggests), and merging.  Maybe pushing the packaging for mixxx into a Vcs could help.
[05:14] <asantoni> persia: yeah, it's just too awkward
[05:14] <asantoni> persia: What do you mean by pushing the packaging into a VCS?
[05:14] <asantoni> (it's already part of our build system, but that's why we need to have our own debian directory)
[05:15] <asantoni> the thing that really kills me is that people don't push their patches upstream to us
[05:15] <asantoni> we don't have it nearly as bad as other projects though, so I should hold my tongue
[05:15] <Legendario> i gotta go now guys.
[05:16] <persia> asantoni: Hmm.  I was suggesting moving the debian/ directory to somewhere non-upstream, making it accessible to Ubuntu developers (LP is good for this), and then sharing from this.  For getting the patches back, it's a little harder.
[05:17] <sistpoty> asantoni: technically, it's actually that debian has created a fork, and ubuntu has created a fork of that fork. however debian realigns (rebases?) every file not under debian/* to the new upstream version.. and ubuntu tries to rebase everything to the new debian fork if possible
[05:17] <asantoni> persia: any specific ideas for where this debian directory should go? I've never seen this problem addressed before, but it's making this impossible to streamline
[05:17] <asantoni> (I think it'd be a great idea for you Ubuntu guys as well as our dev team to be able to modify it somewhere)
[05:17] <persia> The general recommendation is to work with a maintainer to ensure that the latest versions are available.  There could likely be better coordination between Ubuntu and Debian, but I'd suggest coordinating with the Debian maintainer to seek things up to date, and then syncing Ubuntu from Debian.
[05:19] <persia> Does anyone have a good example of a Vcs managed package for asantoni to review as a model?
[05:19] <asantoni> persia: Yes, I haven't been in contact with Free Ekanayaka (Debian) maintainer... I should though
[05:19] <persia> I thought it was Paul Brossier.  Likely my mistake.
[05:19] <asantoni> it used to be
[05:20] <asantoni> at some time in the past
[05:20] <asantoni> but on Debian the package was unmaintained for at least the last two years
[05:20] <asantoni> Free just kind of showed up out of the blue recently, and has never been in contact with us
[05:20] <persia> Ah.  The "used to be" is a common cause of the beginning of confusion.  If Free is taking over, that's the best way to keep things up to date.  Free tends to be very good about making things work for both Debian and Ubuntu.
[05:21] <asantoni> Ok, I'll write him an email right now to try to sort this out
[05:22] <persia> asantoni: Thanks a lot.  If it takes a while, feel free to come back here, and we'll try to sort you.  The goal is to find a process that works well in the future, but maybe this time shortcuts would not be inappropriate.
[05:23] <asantoni> no, thank you persia - you MOTU have a generous amount of patience, and I appreciate your help. :)
[05:30] <sistpoty> persia: more comments to whysynth
[05:30] <persia> sistpoty: Thank you.
[05:30] <sistpoty> np
[05:31] <sistpoty> persia: in general, it looks pretty good :)
[05:31] <persia> sistpoty: SONAME is so that when gstreamer-midi gets built against it, we can track transitions sanely.  Maybe it belongs in /usr/lib?
[05:31] <sistpoty> persia: it's a plugin for gstreamer, right?
[05:32] <persia> sistpoty: whysynth is a DSSI plugin.  gstreamer can build against it, so that gstreamer-midi calls out to whysynth to render sounds.
[05:33] <sistpoty> persia: does gstream link against it then? or will it dlopen it?
[05:33] <sistpoty> +er
[05:33]  * persia looks into the gstreamer-midi source to try to answer that
[05:34] <sistpoty> persia: if it will just dlopen (my guess for a plugin), /usr/lib/<packagename> should be right, (even if it has a SONAME)
[05:35] <sistpoty> otherwise (to link against it), there must be some headers to include (of course very ugly workarounds to define the headers -- basically what dlopen does exists)
[05:38]  * Hobbsee test out gweled
[05:38] <persia> sistpoty: Nevermind.  Thanks for making me check.  I confused wildmidi with whysynth for some reason.  It's dlopen(), but I need to package something else in a hurry :)
[05:39] <sistpoty> heh, /me just remembered a different dssi-plugin from very long ago which seemed to also get dlopen'ed *g*
[05:39] <Hobbsee> yay, it works
[05:40] <sistpoty> Hobbsee: ?
[05:41] <persia> Hobbsee: music as well?
[05:41] <Hobbsee> persia: yeah
[05:41] <sistpoty> oh, cool... btw.: will there be a gstreamer-sid plugin as well (listening to 8bit sound the whole night)
[05:42] <asantoni> :D
[05:42]  * persia cheers effie_jayx for clearing all the bugs from such a lonely package
[05:42] <asantoni> gahhh, Free made the Debian package use our old icon :S
[05:42] <persia> sistpoty: Not on my list of things to do by Wednesday.  Feel free to add it if you have time :)
[05:42] <sistpoty> heh
[05:42] <persia> asantoni: patches to the BTS are generally welcome.  Upstream .desktop files even moreso.
[05:43] <asantoni> heh, we do have an upstream .desktop file
[05:43] <asantoni> which is even more confusing
[05:44] <persia> asantoni: So the upstream .desktop file is being patched to use the old icon?  Very odd.  Maybe submitting a 32x32 xpm for the menu file would help.
[05:44] <asantoni> persia: I think he patched the debian/mixxx.desktop
[05:44] <asantoni> so it appears we have two upstream mixxx.desktop files, which neither of us noticed before
[05:44] <asantoni> lol
[05:45]  * ScottK notes torque is now looking for a second advocate.
[05:45] <persia> Ah.  That's one of the arguments against upstream debian/ :)
[05:45] <asantoni> haha
[05:45] <asantoni> :)
[05:45] <asantoni> point taken
[05:45] <asantoni> any hints on how I should tell our rules file to use the mixxx.desktop file in our "src" directory?
[05:46]  * squentin wonders if someone will review/sponsor bug #156886 before the feature freeze (it's just a simple update)
[05:46] <ubotu> Launchpad bug 156886 in libgtk2-trayicon-perl "Transparency not working with Gtk2::TrayIcon" [Low,Confirmed] https://launchpad.net/bugs/156886
[05:47] <ScottK> squentin: Without looking at the bug, that doesn't sound like something that needs to be done before FF.
[05:47] <persia> asantoni: Just install it in /usr/share/applications from your normal build system, and remove it from debian/rules
[05:47] <asantoni> persia: aha, we already install that there! :)
[05:48] <persia> squentin: That's exactly the sort of bug which we try to address post-feature freeze.  No rush for the deadline, and feel free to fix more like that later in the month and all through March.
[05:48] <asantoni> so out it goes from the debian/rules
[05:48] <persia> asantoni: You may also want to delete debian/mixxx.desktop to avoid future confusion.
[05:49] <squentin> ok, just though it would be easier to get in before the FF, it's basically an upgrade to the latest upstream version
[05:49] <asantoni> will do
[05:51] <persia> squentin: Ah.  If that bug is solved by the new upstream, then yes, it is easier to get it in soon.  The right groups are subscribed, so you've a good chance.
[05:51] <sistpoty> damn, danw is already breaking...
[05:51] <sistpoty> dawn even
[05:52]  * sistpoty is off to bed
[05:52] <sistpoty> gn8 everyone
[05:52]  * persia thought sistpoty was traveling to be up at this hour
[05:52] <asantoni> good night!
[05:53] <squentin> persia: ok thanks
[05:54]  * ScottK advocates clipper (looking for #2) and heads to bed.
[05:54] <LucidFox> Is "diff.gz not identical after binary build and clean" a valid objection on REVU?
[05:55] <persia> It's certainly an odd behaviour.  It should be the same.  Probably worth determining the cause: it may just be that the diff.gz on REVU is dirty, but the packaging is acceptable.
[05:56] <ScottK> persia: torque and clipper are both packages that I think we want (even if they need a little cleanup after FF).  Please have a look and see if you can manage to advocate either.
[05:57]  * ScottK going to bed really now.
[05:57] <persia> ScottK: OK.  Any chance you could look at libini4j-java and libnb-platform7-java?  Last two pieces before netbeans can be pushed.
[05:58] <ScottK> persia: Not tonight.  Perhaps tomorrow or Monday.
[05:58] <persia> ScottK: Thanks.
[05:59] <persia> minghua: If you really want a versioned conflict between falconpl and falcon, wouldn't it be easier to just upload a patched version?
[06:00] <ScottK> persia: He's not on right now..
[06:00] <ScottK> Good night.
[06:00] <persia> ScottK: Yes, and hasn't been whilst sending email :)  good night.
[06:30] <asantoni> persia: as I'm working on updating all this debian directory stuff, it's becoming much more clear that having it in a separate repository that's accessible to package maintainers would save us a lot of hassle
[06:31] <persia> asantoni: Check with Free, but I suspect http://svn.debian.org/wsvn/demudi is likely the right place for that.
[06:33] <asantoni> persia: ah, I see... I wish this sort of stuff was communicated better (a fault of the process perhaps)
[06:34] <persia> asantoni: Mostly a lack of documentation.  FOSS tends to accumulate developers rather than UI specialists or documentation people :(
[06:34] <asantoni> haha, that I cannot deny :)
[06:34] <asantoni> I'll keep that in mind
[06:36] <persia> asantoni: In this case, unless there is objection from one of the involved parties, I'd think the best workflow would be for your team to have access to the alioth SVN repo, and for Ubuntu to sync from Debian (and interested Ubuntu people to coordination with the Debian Multimedia Team to work in the same SVN).
[06:36] <asantoni> persia: yes, I think that's reasonable
[06:37] <asantoni> in the interest of getting Mixxx 1.6.0beta2 into universe before the freeze, I may have to forgo efforts to that end for a bit though
[06:38] <persia> asantoni: Right.  I'd suggest you first contact Free, and if you can get it there, we pull a sync.  If not, maybe someone here can help you get it it.  Try catching warp10 for the update, if nobody else.
[06:39] <asantoni> ok, thanks for the tips
[06:43] <warp10> Good morning
[06:44] <persia> warp10: Good morning.  asantoni is here representing mixxx upstream, and looking for a bit of help integrating the latest release.  Do you have some time to help with that?
[06:44] <persia> (or am I confused by reading too many changelogs today?)
[06:45] <warp10> Heya persia! Sure, I have some time for asantoni's issue.
[06:45] <paas> Hi, could a MOTU please have a look at my package http://revu.tauware.de/details.py?package=libtuxcap. It's ready for advocation, thanks!
[06:46] <asantoni> warp10: I'm just trying to sort out and streamline our packaging process a bit more at the moment
[06:46] <asantoni> I'm going to upload one more attempt at the mixxx package hopefully soon
[06:47] <warp10> asantoni: great! so you uploaded mixx on revu alread?
[06:47] <asantoni> warp10: yes, twice
[06:48] <asantoni> warp10: I've just fixed the things sistpoty pointed out in the comments
[06:48] <asantoni> lintian (on my machine) says I botched one last thing though:
[06:48] <asantoni> W: mixxx source: newer-standards-version 3.7.3 (current is 3.7.2)
[06:49] <asantoni> but it takes about 30 mins to rebuild the package on my machine, and it's getting late (I need to sleep fairly soon)
[06:50] <warp10> asantoni: don't care too much of that warning. latest standards version is 3.7.3 and linda is not updated (lintian should not raise any warning about that)
[06:50] <asantoni> warp10: ah, ok, perhaps this package will be good then (I'm uploading as we speak)
[06:51] <warp10> asantoni: if lintian and linda don't show anything else, and you addressed all sistpoty comments, looks like you are close to get an advocacy! :)
[06:53] <asantoni> warp10: thank you, updated package is uploaded: http://revu.tauware.de/details.py?package=mixxx
[06:53] <asantoni> (launchpad bug #190589)
[06:53] <ubotu> Launchpad bug 190589 in mixxx "New upstream release (in REVU)" [Undecided,New] https://launchpad.net/bugs/190589
[06:54] <warp10> asantoni: you should update the bug report on launchpad
[06:54] <asantoni> warp10: the diff.gz?
[06:54] <warp10> asantoni: assign it to yourself, and set status to "in progress"
[06:57] <asantoni> warp10: done, thanks
[06:57] <warp10> asantoni: great. Just the keep Launchpad up-to-date...
[06:57] <asantoni> warp10: ok, will do
[06:57] <asantoni> I need to head to bed now though
[06:57] <asantoni> but the latest upload is there, if anyone has time to review it
[06:58] <asantoni> thanks again for all of your hard work!
[06:58] <asantoni> good night!
[06:58] <warp10> asantoni: Thank you for helping to improve Ubuntu! :)
[06:59] <rhpot1991_laptop> what is the width limit for a manpage?
[07:00] <method> What causes cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted after dh_installchangelogs?
[07:00] <method> Using pbuilder
[07:02] <warp10> rhpot1991_laptop: should be 80.
[07:02] <rhpot1991_laptop> figured so, thanks
[07:15] <method> Has anyone ever seen a problem with permissions on changelog.Debian?
[07:20] <RAOF> Does anyone here have an {i386,PPC,sparc, s390} sid or hardy build environment and want to test building multiarch alsa-plugins?
[07:21] <RAOF> PPC64 is also testable!
[07:52] <method> Anyone know what this is about? install: cannot change ownership of `debian/readinglist/usr/share/doc/readinglist/changelog.Debian': Operation not permitted. I found a thread on Google that mentioned the same problem, but no one replied.
[07:53] <RAOF> method: Sounds like a problem with your local build system (pbuilder or whatever).
[07:53] <method> RAOF, yeah I'm using pbuilder
[07:53] <RAOF> method: You'll need to provide more information for me to provide a more useful answer.
[07:54] <method> RAOF, it's in dh_installchangelogs
[07:55] <RAOF> So, "operation not permitted" suggests that the pbuilder process doesn't have sufficient privs to chmod (unlikely) or that the device you're building on doesn't support chmodding.
[07:55] <RAOF> Where is your /tmp?
[07:55] <method> Hmm...
[07:56] <method> \/tmp is /tmp?
[07:56] <method> (Might not understand the question) :)
[07:56] <method> pbuilder goes into fakeroot.
[07:56] <method> This is pbuilder on Hardy, btw.
[07:56] <RAOF> Last time I used it (some time ago), pbuilder was building stuff in /tmp.
[07:56] <method> RAOF, yes, it is.
[07:57] <RAOF> Right.  So /tmp is on what sort of device?  What sort of FS?
[07:57] <method> RAOF, should just be part of the same EXT3
[07:58] <RAOF> Is something doing strange things to the permissions above there?
[07:58] <method> Do you know what green highlighting in the ls -la means?
[07:58] <method> . is green.
[07:59] <method> tmp is, yeah.
[08:00] <method> tmp is drwxrwxrwt, anyway.
[08:00] <RAOF> Right.  That's the sticky bit.  I don't think it should be a problem, though.
[08:05] <method> RAOF, it's the same behavior when I run ./debian/rules install, without sudo.
[08:06] <RAOF> How about fakeroot debian/rules install?
[08:06] <method> RAOF, yeah that worked.
[08:07] <RAOF> method: So, it seems that pbuilder is sucking in some way.
[08:07] <RAOF> method: Does a plain dpkg-buildpackage -rfakeroot work?
[08:08] <method> RAOF, no!
[08:08] <RAOF> method: So it seems that something done by building kills it.
[08:09] <method> RAOF, or -rfakeroot isn't working properly.
[08:09] <RAOF> Possibly.
[08:10] <method> sudo dpkg-buildpackage -rfakeroot works
[08:10] <emgent> heya people
[08:10] <RAOF> Heh.  sudo trumps fakeroot, I'd guess :).
[08:11] <RAOF> emgent: You look like someone with an i386 hardy build environment!  Care to try building my multi-arch alsa-plugins?
[08:11] <method> RAOF, I have one.
[08:12] <emgent> RAOF, not now, sorry :)
[08:12] <DarkMageZ> i've got one as well
[08:12] <RAOF> DarkMageZ: You don't happen to have a sid one as well?
[08:12] <DarkMageZ> nope. don't play with debian.
[08:13] <RAOF> Right, anyway, http://cooperteam.net/alsa-plugins_1.0.15-2.dsc should be dgettable.
[08:13] <RAOF> Build away my minions!
[08:14] <DarkMageZ> dget ?
[08:14] <RAOF> Gets the dsc & all the files referenced in it.
[08:14] <RAOF> You will learn to love it :)
[08:14] <DarkMageZ> i already now love it
[08:14] <DarkMageZ> and here was me using wget to get all 3 files...
[08:15] <RAOF> dget -x is download & unpack with dpkg-source, too.
[08:16] <DarkMageZ> build started
[08:17] <RAOF> Hm.  It suddenly occurs to me that ia32-libs is unlikely to exist on PPC64.
[08:17] <method> dpkg-checkbuilddeps: Unmet build dependencies: lib64asound2-dev (>= 1.0.12) libpulse-dev libsamplerate0-dev | libsamplerate-dev libavcodec-dev ia64-libs libc6-dev-amd64 lib64gcc1 gcc-multilib
[08:18] <RAOF> Ok, that's what I was afraid of.
[08:18] <RAOF> We don't build 64bit i386 binaries :)
[08:19] <RAOF> That should work in Sid though, which is the incidental target of this patch.
[08:22] <RAOF> ls
[08:22] <RAOF> NO!  My perfect irssi-is-not-a-shell record is ruined!
[08:30] <persia> So after sistpoty corrected me about the difference between whysynth and wildmidi, I'd like to ask for someone else to take a look at http://revu.ubuntuwire.com/details.py?package=wildmidi .  I'm not 100% sure on the licensing (mixed license in source, re-separated for binary packages), and always like for libraries to have multiple eyes.
[08:32] <RAOF> persia: I'll trade you.  Build my multiarch alsa-plugins in an i386 sid environment, I'll check wildmidi. :)
[08:32] <persia> Err.  I don't have an 1386 sid environment :(  Anything else I can trade for?  (I'll make an i386 sid environment if the answer is no)
[08:33] <RAOF> I'll trade you for a gnome-do & do-plugins check, but I haven't finished those yet. :)
[08:34] <persia> RAOF: That works for me.  Let me know when they are ready.
[08:36] <RAOF> Gah!  Stupid mk-sbuild-lv!
[08:37] <method> do-plugins! Yay!
[08:38] <RAOF> Now that I've bashed various things into a state where a useful package can be made from them, yes.
[08:39] <RAOF> dget, you are my only friend in a world filled with copyright problems.
[08:39] <warp10> MOTUs, my package gbemol (a graphical frontend for MPD) is on REVU and waits for your reviews. http://revu.ubuntuwire.com/details.py?package=gbemol
[08:40] <emgent> heya warp10
[08:40] <emgent> persia, ping
[08:40] <warp10> hi emgent ;)
[08:40] <persia> Aren't there already a plethora of MPD front-ends in the repos?  What makes this one special?
[08:40] <persia> emgent: I don't play virtual table tennis
[08:41] <emgent> O_o
[08:41] <emgent> lol
[08:41] <emgent> persia, http://rafb.net/p/T9Mxid83.html
[08:41] <emgent> it's ok or I should use [...]edgy2 ?
[08:42] <persia> emgent: No idea.  I'm not a security person.  Ask someone in MOTU-SWAT.  This is a strong argument against pinging specific people when you have a question.
[08:42] <emgent> i asked to kees now in jabber
[08:42] <persia> Also, why base a security upload on a backports upload?  That seems odd.
[08:42] <emgent> but i dont know very well
[08:42] <emgent> he _THINK_ 1.2.6-0ubuntu1~edgy2
[08:42] <persia> emgent: This is a good place to ask, I'm just not a good person to ask.  Asking the question to the channel generally will likely get you a good answer.
[08:43] <emgent> hehe ok, thanks
[08:43] <warp10> persia: well, this is just the frontend I use. Since it isn't in our repos and has been asked to be packaged on launchpad, I did it.
[08:43] <persia> Wait, is this security applied to a backport?  That would likely benefit from coordination with the backports team, to push a backport from the -security
[08:44] <emgent> yes persia
[08:44] <persia> warp10: OK.  Just checking.  If it was super-cool and nifty, and washed my socks, I'd be tempted to postpone by queue.  As it is, I'll take a look if I do another REVU pass.
[08:45] <persia> emgent: I'm not part of the backports team either, but I suspect that 1.2.6-0ubuntu1.1~edgy1 is the correct version (new backport).
[08:45] <warp10> persia: ok, thanks anyway :)
[08:46] <emgent> i saw https://help.ubuntu.com/community/UbuntuBackports, but there isnt info about it...
[08:46] <persia> Further, I don't believe that an updated backport belongs in edgy-security, as that would force non-backports users to use the backport.
[08:46] <persia> emgent: The backports documentation team needs help :)
[08:46] <emgent> ehhehehe :)
[08:47] <emgent> u-backports irc room too :P
[09:03] <HighNo> g'morning eveerybody. I was just reading backporting policy and as I get it know - if my package won't make it into hardy and the next REVU day would be in may - my package can also not be integrated in backports as it has to be in the official universe first. It might even say (though unclear) it has to be in a released versions universe which would delay it even more in backports. Am I right here?
[09:08] <RAOF> HighNo: Yes to the first, no to the second.  It has to be in Hardy's universe before it can be backported anywhere, but Hardy doesn't need to be released before you can backport it.
[09:10] <persia> An alternate reading is that once it gets into the universe repository for hardy+1, it can be backported to hardy.
[09:10] <persia> (which may be three or four weeks after hardy release)
[09:14] <RAOF> persia: Would you like comments on revu, or here?
[09:14] <RAOF> Stupid question.  On revu they go.
[09:14] <persia> RAOF: either works :)  REVU is likely better, as it keeps a record.
[09:21] <HighNo> *sniff* this takes sooo long - unless someone quickly advocates my package 'blueproximity' of course :-) (sorry, couldn't resist...)
[09:22] <RAOF> persia: Commented.  Stop trying to close Debian bugs with Ubuntu uploads :)
[09:23] <emgent> ugh
[09:23] <persia> HighNo: Simply put, you've missed new package season.  If you check the channel logs, you'll see even MOTU are begging for reviews at this point.
[09:23] <persia> RAOF: Thanks :)  Also, lintian disagrees with you about = vs. >= ${source:Version}
[09:24] <RAOF> persia: Fair enough.  This isn't based on an understanding of policy, just what I've seen other library packages do.
[09:24] <persia> Also, do you expect the archive-admins to have an issue because ./COPYING is only GPL, and most of the source is LGPL?
[09:25] <persia> The way you recommend is how I did it at first, but it makes it non-bin-NMUable, as the arch:all package wouldn't be able to handle a version bump on a binary.  Not that it really matters in Ubuntu or anything :)
[09:25] <emgent> uhm
[09:25] <emgent> http://rafb.net/p/TAIdMy20.html
[09:25] <emgent> we are exploitable
[09:26] <RAOF> persia: Oh, sorry: {binary:version}!
[09:26] <emgent> GRSEC ++
[09:26] <RAOF> The capitalisation there is incorrect, I think.
[09:26] <persia> emgent: We are usually exploitable in several different ways.  We typically avoid advertising that whilst working on patches.
[09:27] <emgent> launchpad bug is open
[09:27] <persia> RAOF: /usr/share/lintian/checks/version-substvars.desc says ${source:Version}
[09:27] <emgent> debian people too working on this
[09:27] <persia> Err..  ${binary:Version}
[09:28] <RAOF> GAH!  Why must mk-sbuild-lv take so long to FAIL?
[09:28] <RAOF> Bah!  That patch can get sent without i386 testing.  It *should* work.
[09:29] <persia> RAOF: Once you have the majority set up, it may be easier to do it manually.  Just add a stanza to schroot.conf, add a LV, and debootstrap.
[09:29] <RAOF> Yeah, possibly.
[09:31] <HighNo> persia: yes, I know. I am just sad, because I didn't know before and worked very hard as someone told me FF is on 14th, so I've had the hope. The information that it packaging is over came later on when I was almost done with the package. This is of course no offense to anybody, you guys work hard and do a great job. Good thing is I can create a new nicer upstream package with more languages supported.
[09:32] <HighNo> I know that packaging is faster once a package is in debian, but does also debian packaging get faster if one makes it into ubuntu?
[09:32] <persia> HighNo: I suggest you see if you can find out who typically handles the bluetooth stuff.  They may be very interested, and try to push it through.
[09:33] <RAOF> HighNo: It doesn't, except that you've already got a (presumably) archive-worthy package available.
[09:33] <persia> Ideally, packaging is only done once, for either Debian or Ubuntu.  After that, it is either a sync, or maybe small bugfix-type changes.
[09:33] <RAOF> HighNo: And the work you've done need not be wasted; you can get the package into Debian, they don't usually bite off people's heads.
[09:34] <HighNo> RAOF: hehe, that's what I thought too. I was just wondering if there's a two way road between the both
[09:35] <RAOF> HighNo: There's not nearly as much Ubuntu->Debian traffic as the other way around.  Partially because there are *lots* of Debian maintainers.
[09:35] <persia> Depends on the package.  I see lots of Ubuntu->Debian traffic, of various sorts.
[09:35] <RAOF> Oh, certainly.
[09:36] <persia> There's just no automated upload of Ubuntu updates for things not recently updated in Debian :)
[09:36] <HighNo> persia: (and anybody else) ho you know who is into bluetooth among the MOTUs? Are there MOTUs especially for the UbuntuMobile thingy?
[09:36] <RAOF> Yes.  There is no UbuntuImportFreeze :)
[09:37] <RAOF> Anyway.  Time to do a Gnome-Do release so I can package it and hurl it at persia with high velocity!
[09:37]  * persia dons the appropriate protective equipment
[09:38] <persia> Well, rather, there is a constant UbuntuImportFreeze: everything is by manual action.
[09:38] <RAOF> Do is a fine way to discover bugs in Metacity's compositor.
[09:38] <RAOF> Right.
[09:40] <RAOF> For example: in some (rare) instances triggering Do will make every window with an ARGB pixmap disappear (including Do) until Do is hidden.  It's fun.
[09:41] <persia> RAOF: And this is something you want to add to the repos?
[09:41] <RAOF> persia: Works fine with Compiz.  It's a metacity bug.
[09:42] <RAOF> Or with xcompmgr, for that matter.
[09:42] <RAOF> I don't imagine many people have metacity's compositor turned on.
[09:43] <persia> Well, me, but my system is not exactly standard :)
[09:43] <RAOF> Me too, obviously.
[09:45] <RAOF> I want shiny composite eye-candy & don't Compiz because I test nouveau.  What's your excuse? :P
[09:46] <persia> RAOF: My case has insufficient airflow for my GPU
[09:46] <RAOF> Whoops.
[09:47] <persia> Works OK in the winter, but better to not run compiz than have lockups on warm days.
[09:49] <RAOF> Oooh, I get to check my watch file handles a new upstream version correctly.  Yay!
[09:51] <persia> What's best practice when upstream sends a patch to fix licensing stuff and doesn't want to do a new release?
[09:54] <RAOF> I don't know.  The only time that's happened to me recently, Miro spent a week trying not to link to openssl, then made a new release with the exception clause everywhere.
[09:55] <persia> RAOF: That would make life easy.  In this case, upstream sent a patch against their release tarball with the changes they want, but didn't want to update the actual release tarball.
[09:55] <RAOF> Repack?  That seems really ugly, though.
[09:56] <persia> That's what I thought.  Putting it in debian/patches recently got rejected from REVU because we shouldn't patch licensing though.
[09:58] <RAOF> Yeah.  Then the source package has a misleading license in it.
[09:59] <persia> That was the issue.  During packaging it was discovered that some of the licensing for some of the files was unclear.  This was resolved now, but I'm not sure how the resolution should be structured for inclusion.
[10:00] <RAOF> I think you'll have to repack the tarball, with the licensing patch applied.  The .orig.tar.gz has to have the right licensing, yes?
[10:02] <persia> I guess.  Perhaps applying the patch in get-orig-source, although such a construction likely needs a README.Debian-source to explain just how it got that way.  Thanks.
[10:02] <RAOF> That would work, yes.
[10:09] <RAOF> Why did I think Sid had an ia64-libs package?
[10:15] <persia> Does anyone know anything about a libgmyth-dev package?
[10:16] <persia> superm1: gst-plugins-bad0.10 FTBFS for me.  Any suggestions on how to fix that?
[10:16] <jpatrick> persia: W: Unable to locate package libgmyth-dev
[10:17] <RAOF> persia: It's a new build-dep of plugins-bad, to allow gstreamer apps to connect to mythtv hosts.
[10:17] <persia> jpatrick: That was my experience.  Which arch?
[10:17] <RAOF> It'll be sitting somewhere in NEW right now...
[10:17] <persia> RAOF: Why can't I find it in apt-cache?
[10:17]  * persia grumbles that one last-minute update to gst-plugins-bad0.10 is colliding against another and hunts NEW
[10:18] <RAOF> https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=gmyth
[10:18] <jpatrick> persia: x86
[10:18] <persia> RAOF: registration block :p
[10:19] <persia> jpatrick: Thanks.  That means it's definitely caught somewhere.
[10:33] <emgent> Hobbsee, can i work to fbi package ?
[10:39] <\sh> moins
[10:40] <\sh> does anyone know the replacement binary for `arch` from util-linux?
[10:44] <persia> \sh: What did it do?
[10:44] <\sh> persia, printing out the real architecture ;)
[10:45] <\sh> persia, yes...it's wrong
[10:46] <persia> \sh: Ah.  Don't know then, sorry.  /proc/cpuinfo might have some of what you want.
[10:46] <HighNo> uname -m ?
[10:47] <persia> HighNo: That only checks what kernel is installed
[10:47] <HighNo> true
[10:47] <HighNo> would arch really do something different?
[10:48] <persia> HighNo: Ideally, it would check the CPU, and report something else when e.g. running i386 on amd64 hardware.
[10:48] <persia> (and yes, it is wrong)
[10:48] <emgent> jdong, ping
[10:49] <persia> emgent: It's not just for me.  You'll always get a better, faster answer when you ask a question than when you ping someone.
[10:49] <\sh> persia, well, the problem is...arch would give me e.g. i686 on pentium and not i386 as dpkg-architecture ;)
[10:50] <persia> \sh: You want the dpkg-architecture?  That's entirely different.
[10:50] <\sh> persia, no :) I need `arch` ;) I'm trying to build cinelerra...
[10:51] <HighNo> hal-device  | grep i686  wold only give what the kernel is built for or does it check the real thing?
[10:51]  * persia hides from cinelerra
[10:51] <\sh> bah...cinelerra is totally wrong with its usage of arch
[10:56] <persia> Grr..  The gmyth-dev addition to gst-plugins-bad0.10 causes it to FTBFS, and 01_gmyth_configure.patch breaks build-twice-in-a-row :(
[12:00] <RAOF> Alright.  Any idea why dh_clideps would be throwing me a warning about no build-dep(-indep) on cli-common-dev when I *have* a build-dep-indep on cli-common-dev?
[12:02] <persia> RAOF: dh_clideps?
[12:05] <persia> RAOF: Do you build-dep-indep on "cli-common-dev \(>= 0\.4\.4\)".  It seems to want the version (at least from my reading of the source: I haven't done any Mono packaging)
[12:05] <persia> Well, actually, that should be unescaped, but still.
[12:14] <RAOF> I build-dep-indep on c-c-d (>= 0.5.4).  There's some newer stuff I want.
[12:14] <RAOF> But that's as much time as I can give it tonight.
[12:14] <persia> RAOF: File a bug :)
[12:20] <mok0> DaveMorris: you've been doing a great job helping HighNo getting blueproximity sorted out
[12:21] <HighNo> ture
[12:21] <HighNo> true
[12:21] <mok0> Hi HighNo
[12:21] <HighNo> hi mok0
[12:22] <mok0> HighNo: I saw you managed to get at least 1 MOTU to lookt at it!
[12:22] <HighNo> mok0: i did?
[12:22] <mok0> Yep. Those are the guys with the fancy icons on REVU
[12:23] <HighNo> mok0: might be michael - sadly their irc names don't pop up there
[12:23] <HighNo> mok0: ahh, that's that the icon is for
[12:23] <mok0> HighNo: yeah.
[12:23] <persia> HighNo: You can usually get IRC <-> email translation from https://launchpad.net/people
[12:24] <HighNo> mok0: ok, thanks. Anyway I learned it wouldn't help anyway. There's no way to make it into hardy now
[12:24] <mok0> HighNo: It's from the orig. cartoon "He-man and Masters of the Universe" :-)
[12:24] <mok0> HighNo: They are still working to get processed as much as possible before the hard freeze
[12:24] <HighNo> mok0: aaaah, hehe - cool.
[12:25] <mok0> HighNo: you are right, it would be nice if people's nicks were also mentioned on revu
[12:26] <HighNo> mok0: so launchpad would be eternia :-)
[12:27] <HighNo> mok0: acutally i liked that series a lot and watched many episodes - too many as i can still know the intro song by heart
[12:27] <mok0> HighNo: hehe, it's been a while since I've seen them on tele.
[12:29] <mok0> HighNo: http://www.he-man.org/cartoon/cmotu/index.shtml
[12:30] <mok0> That must be a site for you :-)
[12:31] <HighNo> mok0: yes - it's been a while. thanks for indirectly mention I am an old guy :-) (31 that is)  btw, just dropped a blueprint in launchpad for adding the irc names
[12:32] <DaveMorris> HighNo: it might not make it in, but a.) you've fixed the bugs on hardy. b.) You've improved the packaging etc, which can be applied to your PPA's
[12:33] <DaveMorris> 31, a bit older than me ;)
[12:33] <mok0> HighNo: I'm older than you :-)
[12:34] <HighNo> DaveMorris: that's true too. I also started a translation session so it would come in > 10 languages. (I think I got the most people if jp and ch will finally be added) I have 8 so far :-)
[12:34]  * mok0 wonders in "Masters of the Universe" is a registered trademark...
[12:35] <mok0> DaveMorris: Remind me, what is your package?
[12:35] <HighNo> DaveMorris: And I will at least try to use the launchpad project infrastructure more so translations could be made via rosetta
[12:35] <DaveMorris> http://revu.tauware.de/details.py?package=gtkglextmm is the current one needing review
[12:35] <HighNo> mok0: it s a registered trademark afaik
[12:36] <mok0> I guess they haven't heard of Ubuntu Universe's MOTUs...
[12:36]  * persia notes that in the jurisdiction in which that trademark is registered, trademarks are only valid for a specific line of business.
[12:37] <persia> Software Development being different than either "entertainment" or "toys", it would take significant work to justify a complaint.
[12:38] <DaveMorris> so as long as we don't start selling dolls of the various MOTU's ;)
[12:38] <HighNo> mok0: http://tess2.uspto.gov/bin/showfield?f=toc&state=1n9h70.1.1&p_search=searchss&p_L=50&BackReference=&p_plural=yes&p_s_PARA1=&p_tagrepl%7E%3A=PARA1%24LD&expr=PARA1+AND+PARA2&p_s_PARA2=masters+of+the+universe&p_tagrepl%7E%3A=PARA2%24COMB&p_op_ALL=AND&a_default=search&a_search=Submit+Query&a_search=Submit+Query
[12:38] <mok0> DaveMorris: lol
[12:39] <mok0> HighNo: that's hilarious...
[12:39]  * DaveMorris thinks of voodoo dolls of motu's to get his packaged reviewed :)
[12:39] <mok0> DaveMorris: looks like yours is getting close
[12:39] <HighNo> persia: they registered it for computer game software too - let's not talk of games here :-)
[12:40] <DaveMorris> mok0: yeah, I only picked up Friday night when I realised the previous guy gave up
[12:40] <mok0> DaveMorris: great! There is a lot of good stuff sitting in the queue
[12:40]  * HighNo remarks that you also should not explicitly create toothbrushes  - they are registered too :-)
[12:40] <DaveMorris> HighNo: can your program handle different devices with different actions for the devices?
[12:41] <mok0> HighNo: Of course, MOTU means: Meisters of the Universe...
[12:41] <mok0> ... or Misters if you will...
[12:41] <HighNo> DaveMorris: I was thinking of it. It already can with a hack - run it multiple times with different config files - but that's dirty. I think there is already a blueprint - written by me for doing that
[12:41] <HighNo> mok0: hehe
[12:42] <HighNo> DaveMorris: you have more than one boss? :-)
[12:42] <DaveMorris> yeah, I work in a Uni
[12:42] <mok0> HighNo: although I think we can aggree that they are sometimes "Monsters of the Universe"... ;-)
[12:42] <DaveMorris> got my linemanager and the dean.  I report to them both really
[12:45] <HighNo> DaveMorris: Now if you were a MOTU I would make a deal... But this way, I'll have to see what I can do here. There are some points I have to check first to get that done. Like how to efficiently store/read multiple entries with configObj, how to make a simple config dialogue without having a new window pop up for every config and stuff like that. the backend is not really ready for that but can be changed without big problems. Let's put t
[12:46] <jpatrick> win 33
[12:46] <jpatrick> with "/" this time irssi ;)
[12:47] <HighNo> mok0: see how elegantly I covered your back by not going into you being even older than me? :-)
[12:47] <mok0> HighNo: A true gentleman
[12:48]  * DaveMorris needs to learn more before been a MOTU
[12:49]  * HighNo pads DaveMorris on the back and tells him gently "then learn - but do it FAST!" :-)
[12:49] <mok0> Have you been following effie_jayx's progress on the wiki?
[12:50] <chazco> Hi... can anyone tell me if Truecrypt 5 is planned to go into any of the repos?
[12:50] <effie_jayx> mok0, ?
[12:50] <hellboy195> effie_jayx: now you are famous ^^
[12:50] <mok0> effie_jayx: I was asking HighNo and DaveMorris if they'd been following your progress
[12:50] <effie_jayx> hellboy195,  oh dear...
[12:51] <effie_jayx> I only hope I can live up to it
[12:51] <mok0> effie_jayx:It can develop into a true motu program that others can use
[12:51] <DaveMorris> If thats the one syndicacted on one of the ubuntu planets then yeah
[12:51]  * effie_jayx is currently trying to upgrade a package that has "dead end" written all over it
[12:52] <DaveMorris> is there a checklist of the various things you need to learn to know your at a `certain level'
[12:52] <mok0> effie_jayx: what's wrong with it?
[12:52] <mok0> effie_jayx: it upstream has abandoned it, I would skip
[12:52] <HighNo> mok0: oh, i didn't know I was meant by that question - the answer would be no
[12:53] <effie_jayx> mok0,  1) orphan, 2) version jumped from 0.1.1 to 0.2.2 without any changelog entries to it
[12:53] <DaveMorris> do you need it then?
[12:53] <HighNo> mok0: do i make an idiot of me if i asked what wiki?
[12:53] <mok0> HighNo: http://wiki.ubuntu.com
[12:53] <effie_jayx> mok0,  and upstream seems to release a new version when he comes back from war (he is in the military)
[12:54] <HighNo> mok0: ok, the answer is yes then :-)
[12:54] <mok0> effie_jayx: yikes. Let's hope he does come back
[12:54]  * mok0 looks for effie_jayx's motu log
[12:55] <effie_jayx> mok0,  I have found a way to build the package. but it makes no sense uploading it... upstream is really not makig that software distributable enouh
[12:55] <HighNo> effie_jayx: what software exactly?
[12:55] <effie_jayx> kipina
[12:55] <effie_jayx> mok0, https://wiki.ubuntu.com/EfrainValles/MOTUJourney
[12:55] <mok0> effie_jayx: I've had that problem with a couple of my packages. Finally, I decided to make my own distribution
[12:55] <DaveMorris> effie_jayx: email him re your concerns, with suggestions on how it can be improved
[12:55] <mok0> HighNo: https://wiki.ubuntu.com/EfrainValles/MOTUJourney :-)
[12:56] <effie_jayx> DaveMorris,  I am not sure his email is still current
[12:56] <effie_jayx> DaveMorris, I will email him today. thanks
[12:56] <mok0> effie_jayx: but those kinds of troubles don't help you much in  your quest
[12:57] <effie_jayx> mok0,  they are real issues though
[12:57] <mok0> effie_jayx: ok
[12:57] <effie_jayx> I have a knack for this kinda bugs
[12:57] <mok0> effie_jayx: hehe
[12:58] <DaveMorris> I need to learn how to do merges and syncs next cycle, as I've only done new packages this cycle (all libs as well)
[12:58] <effie_jayx> HighNo, hey are you starting as well ?
[12:58] <mok0> As late as this morning I was wondering if there's a document that we could point upstreams to, saying how they should organize their distribution to make it easier to get it packaged
[12:59] <mok0> An Upstream Guide
[12:59]  * DaveMorris volunteers mok0 to make one :)
[12:59] <persia> mok0: You could write one?
[12:59] <effie_jayx> mok0,  it would be interesting to see the reaction
[12:59] <mok0> I could make something on the wiki, if you all promise to contribute
[12:59] <DaveMorris> mok0: if you pm the link I can add the problems I've had and the fixes
[13:00] <mok0> DaveMorris: cool
[13:00] <persia> Things like distribute as tar.gz, license all the files, provide a flexible build system that allows customised installation, don't build stuff on clean, don't download from the net, etc.
[13:00] <HighNo> effie_jayx: hehe, starting - yes, as a MOTU - not quite yet. I still try to get my first package into hardy
[13:00] <persia> mok0: Please post your link here when you get a draft up, so everyone can add :)
[13:01]  * mok0 goes off to generate a wiki page.
[13:01] <DaveMorris> have proper clean and dist-clean tagets
[13:01] <persia> Support translated strings
[13:01] <effie_jayx> HighNo, well bug fixing is really simple.
[13:01] <effie_jayx> that's how I have started
[13:01] <effie_jayx> I am doing and upgrade
[13:03] <persia> Is anyone familiar with dh_gstscancodecs?  Any ideas on what magic might be required to get the inspection to work properly?
[13:03] <mok0> Bookmark this: https://wiki.ubuntu.com/UpstreamGuide
[13:04] <mok0> I will write something when I've thought about it
[13:05] <HighNo> effie_jayx: I am the upstream author of that particular package so I have special feelings on my package :-) but afterwards - and after my final exams - I will have more time. I'll have to see how things turn out to be after I get my degree. I am willing to support and sometimes do so in the #ubuntu channel. I have answered some questions on answers too. Hey - I am an official Ubuntu Instructor... (Really!)
[13:05] <effie_jayx> HighNo,  wow :D
[13:08] <HighNo> btw. Greetings to the Canonical Trainings Crew like the charming Billy Cina and of course Master of Desaster Chris Brown - he led my Train-the-Trainer event in  Stuttgart last year - a cool guy, 3 days of pure fun.
[13:10] <LucidFox> https://wiki.ubuntu.com/UpstreamGuide <-- not much content, ne? :)
[13:16] <HighNo> mok0: should we make a list on there with points it should have on it - just to make certain things not forgotten?
[13:16] <mok0> HighNo: go ahead and put random thoughts. I will organize it later
[13:16] <HighNo> mok0: fine
[13:21] <HighNo> ok, wiki updated. That's the first thing I had to learn :-)
[13:23] <HighNo> oh, btw. does anyone else have this problem? If I update a wiki page on wiki.ubuntu.com it will take a very long time during which firefox is hanging. I may be just my setup but it's quite annoying. Most of the times I kill it and restart firefox - the changes on the wiki page are saved anyway. :-/
[13:31] <Iulian> HighNo: It happens to me sometimes.
[13:32] <warp10> Anyone having problems opening qa.ubuntuwire.com?
[13:32] <Iulian> warp10: Yes
[13:33] <warp10> Iulian: mmm... too bad. Hope it will be up again ASAP
[13:34] <Iulian> Indeed.
[13:40] <shibata> hi all.
[13:42] <shibata> persia, RainCT, ScottK: thank you for advocating of termlauncher-applet, kita2.
[13:47] <persia> mok0: If I upload torque, will you keep working on a patch to clean up the manpages for inclusion before hardy release?
[13:48] <mok0> persia: I did clean the manpages... what are you referring to?
[13:48] <mok0> persia: there's a fixhyphens patch
[13:49] <persia> mok0: The latest revision on REVU still gets lots of missing manpages and minus/hyphen issues, on top of your patch.
[13:49] <mok0> persia: missing manpages I'm aware of. How can I reproduce the minus/hypen issues?
[13:49] <persia> Everything else is clean, so I'm willing to upload if you're willing to hunt down all the remainders and make sure it's 100% before release.
[13:50] <mok0> persia: I promise
[13:50] <persia> All I did was build in a hardy chroot, and run lintian.  Does that not work for you?
[13:50] <persia> mok0: OK.  Uploading.
[13:50] <mok0> persia: I don't get any reports on hypens
[13:51] <LucidFox> When subscribing sponsors to a sync request, should I set it to confirmed?
[13:52] <persia> mok0: Odd.  I get http://paste.ubuntu.com/4410/
[13:52] <mok0> LucidFox: I think so. You'd think that Malone was intelligent enought to do a lot of this bookkeeping on its own.
[13:52] <mok0> persia: hmm. something is fishy
[13:52] <persia> LucidFox: Please don't.  You are asking for the sponsor to confirm (and yes, LP is annoying about sponsorship: there is a bug)
[13:53] <mok0> persia: e.g. line 253 should not be there, because I now have an override
[13:53] <persia> mok0: That's what I thought.  I remembered you fixing them before, and was surprised to see it.  On the other hand, I don't want to review again (it's a large and annoying package).
[13:54] <mok0> persia: tell me about it
[13:54] <persia> mok0: You have a linda override?
[13:54] <mok0> persia: no
[13:54] <persia> mok0: line 253 is from linda.
[13:54] <persia> Line 217 is the result of your override
[13:55] <mok0> persia: right
[13:56] <mok0> persia: the annoying thing is that the linenumbers given for the man pages are incorrect
[13:56] <persia> That is indeed annoying
[13:57] <shibata> About sponsorship process, what should I attach file which is diff between old package and new one instead of InterDiff? Does ".diff.gz" mean "PACKAGENAME_NEWVERSION.diff.gz" which is created by debuild? Or any other file?
[13:58] <persia> shibata: Is it a new upstream, or just a patch to an existing package?
[13:58] <shibata> new upstream
[13:58] <persia> shibata: Please attach PACKAGENAME_NEWVERSION.diff.gz (and yes, I will get around to updating the documentation sometime)
[13:59] <shibata> persia: thank you.
[14:00] <mok0> persia: are you using flags to make lintian more picky?
[14:00] <persia> mok0: Of course.  As picky as I can make it.
[14:01] <mok0> persia: which ones?
[14:01] <persia> -iIv
[14:01] <mok0> persia: Value "v" invalid for option l (number expected)
[14:02] <persia> mok0: Use 'I' instead of 'l'.
[14:02] <mok0> persia: Ah :-)
[14:03] <mok0> persia: Yep, I get those hyphen messages now.
[14:03] <persia> mok0: Likely be a week or so before the package gets through NEW, but you'll want to have a debdiff ready then.
[14:03] <mok0> persia: ok, will do
[14:05] <persia> LucidFox: tovid rejected because it breaks icon themes as well as having manpage issues.  I'd be willing to advocate tomorrow if you can't find two other victims.
[14:05] <LucidFox> All right, I'll look into it.
[14:06] <bigon> slomo: no news about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354876 ?
[14:06] <LucidFox> As for desktop files, is it now a requirement that upstream desktop should be patched if it exists?
[14:06] <ubotu> Debian bug 354876 in wnpp "ITP: notify-sharp -- CLI bindings for libnotify" [Wishlist,Open]
[14:06] <LucidFox> for all packages/
[14:07] <persia> LucidFox: It's best practice to patch what can be patched, rather than creating new files.  This makes it easier to pass back upstream.
[14:07] <persia> A recent example of what can happen when this isn't done is the .desktop file for mixxx, where upstream had one version, and there was also one in debian/ and upstream was confused as to how the icon was still the old one.
[14:09] <bigon> could some kubuntu guy have a look at https://bugs.edge.launchpad.net/ubuntu/+source/decibel/+bug/180344 ?
[14:09] <ubotu> Launchpad bug 180344 in decibel "[FTBFS] decibel (0.5.0+svn737972-2) fails to build in hardy" [Low,Confirmed]
[14:11] <LucidFox> Debian bug name: "RM: xmms -- RoM; unmaintained" - what does RoM mean?
[14:11] <persia> Request of Maintainer
[14:12] <LucidFox> Thanks.
[14:12] <bigon> gtk1 will be removed from debian before the lenny release I think
[14:13] <persia> That's the goal.
[14:13] <LucidFox> persia> As for tovid manpages, upstream generates them in an extremely awkward way, and the sections are non-standard. I'll probably have to remove all upstream manpages in postinstall and provide my own manpages in debian/
[14:14] <persia> LucidFox: Can you not just force something in docs/src/* to generate the .SH NAME section?
[14:16] <LucidFox> the manpages are generated with txt2tags, which apparently has no concept of .SH :(
[14:16] <LucidFox> it inserts .SS Name, .SS Description, etc
[14:17] <LucidFox> (it's supposed to convert to many different formats, but doesn't do a very good job with this particular format)
[14:18] <persia> That's truly unfortunate.  If you really can't find a way around it, then such is life.  My main objections were about duplication and the bad .desktop file, but the manpages pushed me from soliciting your promise to asking for another revision.
[14:18] <persia> If you can find a way to make it work, it would be ideal, of course :)
[14:18] <tuxmaniac> grr manpages and upstream!!!
[14:18] <LucidFox> of course, I could patch generated manpages...
[14:20] <LucidFox> or do sed s/\.SS/\.SH/g
[14:20] <persia> See, there is usually a solution once you start working on it :)
[14:21] <ion_> The second parameter is not a regexp. No need to escape dots.
[14:26] <ScottK> persia: I just advocated clipper.  I forgot to actually push the button last night.
[14:34] <shibata> persia, ScottK: I reupload poppler-data to modify debian/copyright. pleasee revu: http://revu.tauware.de/details.py?package=poppler-data
[14:46] <smarter> anyone willing to review my qdevelop package? :) http://revu.ubuntuwire.com/details.py?package=qdevelop
[14:48] <bddebian> Heya gang
[14:56] <LucidFox> seconding smarter's request, I would also like to see qdevelop in the archive
[14:56] <tuxmaniac> can some re-re-review http://revu.tauware.de/details.py?package=alliance. Hope it gets advocated this time around. fingers crossed.
[14:57] <tuxmaniac> s/some/someone
[14:57] <tuxmaniac> dinner brb
[15:08] <superm1> persia, install gmyth
[15:08] <superm1> which is in NEW
[15:09] <spectie> can i request importing a package from debian unstable into ubuntu here ?
[15:10] <spectie> ideally to make the hardy release
[15:10] <spectie> the package is apertium-dbus
[15:11] <superm1> spectie, so what you should do is see if the source package builds cleanly on hardy
[15:11] <superm1> in a pbuilder or sbuild
[15:11] <superm1> if that's the case, than you can request a "sync"
[15:11] <spectie> i don't know anyone running hardy
[15:12] <spectie> i know it doesn't build clean on gutsy
[15:12] <spectie> as there is a conflict in the dbus versions
[15:12] <superm1> spectie, well hardy may be a little different
[15:12] <spectie> the ubuntu one is named 1.1.1+ubuntu3 something
[15:12] <superm1> that sounds like you were installing the deb
[15:12] <superm1> not building the source package
[15:12] <spectie> hmm, perhaps he was
[15:12] <superm1> eg dsc, diff.gz, orig.tar.gz
[15:12] <spectie> (i asked a friend to check it)
[15:13] <spectie> i thought i'd told him to do it from source though ;)
[15:13] <superm1> spectie, so what you can do is either you or your friend install pbuilder
[15:13] <superm1> gutsy is fine to install it on
[15:13] <superm1> and prepare a hardy pbuilder
[15:13] <spectie> well, i can't as i don't have ubuntu
[15:13] <superm1> !pbuilder > spectie
[15:13] <superm1> well its on debian too
[15:13] <spectie> or i can set up a hardy pbuilder on my deb box ?
[15:14] <spectie> yes i know
[15:14] <superm1> yeah you can set up a hardy pbuilder on any box that you install pbuilder on
[15:14] <spectie> debian or ubuntu?
[15:14] <spectie> cool i didn't know that
[15:14] <superm1> several folks here have debian and ubuntu pbuilders setup locally
[15:15] <superm1> for similar purposes
[15:15] <superm1> so once you see if that package builds in the hardy pbuilder alright, check back in here and we can teach you how to request the sync, where to file the bug and who to subscribe etc
[15:16] <dcordero> hi
[15:16] <superm1> ideally if you can save a build log from the pbuilder that would be good to attach to the bug
[15:17] <dcordero> hi DktrKranz  ;)
[15:17] <spectie> superm1, thanks
[15:17] <crevette> hello
[15:18] <DktrKranz> hey dcordero :)
[15:18] <crevette> someone could review 3 Packages I did
[15:18] <crevette> http://revu.tauware.de/details.py?package=obex-data-server this one is a brand new one
[15:18] <crevette> http://revu.tauware.de/details.py?package=bluez-gnome
[15:18] <crevette> http://revu.tauware.de/details.py?package=gnome-bluetooth
[15:19] <superm1> crevette, for package upgrades, traditionally a bug is filed with u-u-s subscribed
[15:19] <superm1> rather than using revu for such thing
[15:20] <superm1> additionally bluez-gnome is in main
[15:20] <crevette>  u-u-s ?
[15:20] <superm1> sorry, ubuntu-universe-sponsors
[15:20] <crevette> okay
[15:20] <superm1> for bluez-gnome, you would need a core-dev to upload it
[15:20] <superm1> which not everyone who is a MOTU has core-dev privs
[15:20] <superm1> so ubuntu-main-sponsors would need to be subscribed
[15:21] <HighNo> crevette: great - bluetooth packages
[15:21] <crevette> yeah, I just wanted at least review to know if my package is okay, uploading in aonther question :)
[15:21] <crevette> HighNo: yes, I packaged the obec-data-server which replace gnom-obex-sebd
[15:21] <superm1> crevette, i'll take a quick look at obex-data-server and see if anything stands out
[15:21] <superm1> in the meanwhile, can you file the appropriate bugs for the other two?
[15:21] <crevette> HighNo: I've have a ppa if you're interested with
[15:22] <crevette> superm1: thanks, I'll do, the address to suscribe is ubuntu-universe-sponsors@ubuntu.com ?
[15:22] <superm1> crevette, when you file the bug, click "subscribe someone else"
[15:22] <superm1> and then just type
[15:22] <superm1> ubuntu-universe-sponsors
[15:23] <superm1> and it will resolve it
[15:23] <crevette> okay, this is not an address
[15:23] <superm1> nope
[15:23] <crevette> ocky docky
[15:24] <HighNo> crevette: that's not my point. I am looking for MOTUs that are into bluetooth to get package advocated
[15:24] <superm1> HighNo, i've got an apple bluetooth keyboard and mouse.  That's why bluetooth stuff stuck out to me :)
[15:25] <crevette> superm1: hewww
[15:25] <crevette> I pass
[15:25] <crevette> :)
[15:25] <crevette> I just use it for my phone
[15:25] <HighNo> superm1: are you a motu?
[15:25] <superm1> HighNo, yeah
[15:25] <HighNo> superm1: whooohooo. Could you please look at http://revu.tauware.de/details.py?package=blueproximity ?
[15:25] <crevette> I did a debdiff in https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/190405 but I think I've screwed somewhere
[15:26] <ubotu> Launchpad bug 190405 in bluez-gnome "please package bluez-gnome 0.17 " [Undecided,New]
[15:26] <superm1> HighNo, yeah i can take a look after i look at obex-data-server
[15:26] <HighNo> superm1: you are my hero :-)
[15:27] <HighNo> superm1: yesterday I even sponsored a pizza for advocating :-)
[15:28] <HighNo> superm1: without effect cause no motu with bluetooth interest was around.
[15:28] <superm1> haha
[15:29] <crevette> HighNo: no one was interested in #ubuntu-mobile to look at tit ?
[15:30] <HighNo> crevette: do they have motus there?
[15:30] <crevette> I don't know, I just wen there for the 1st time 10 minautes ago, but no one answers
[15:31] <superm1> !weekend
[15:31] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[15:31] <superm1> ^crevette, HighNo
[15:32] <crevette> superm1: yeah yeah I know
[15:32] <crevette> :)
[15:32] <HighNo> :-)
[15:32] <crevette> this is just I have no time during the week to work on what I want
[15:32] <crevette> I am shifted
[15:34] <superm1> crevette, is gnome-obex-sebd leaving the archive?
[15:34] <superm1> or will both be available?
[15:34] <crevette> gnome-obex-send is just one binary of gnome-bluetooth
[15:35] <superm1> okay just by the wording above you made it sound like this package was superseeding it
[15:35] <crevette> it was removed from upstream starting 0.11 in favor of the bluez-gnome which now feature the wame type of app
[15:35] <crevette> superm1: ah true
[15:35] <crevette> I made a mistake
[15:41] <crevette> thanks superm1
[15:43] <LucidFox> persia, jdong and others, I've reuploaded http://revu.tauware.de/details.py?package=tovid
[15:43] <webwolf_27> would someone be kinf enough to tell me what this lintian error "no-copyright-file" means and maybe how I might fix it
[15:44] <smarter> webwolf_27: run lintian with -Ii
[15:44] <LucidFox> webwolf_27> it means debian/copyright is not present
[15:44] <crevette> webwolf_27: you must have a file copyright in the folder debian
[15:44] <LucidFox> I typically run lintian with -iIv
[15:44] <webwolf_27> smarter, LucidFox, There is a debian/copyright
[15:45] <LucidFox> webwolf_27> then maybe your debian/rules is missing dh_installdocs?
[15:45] <webwolf_27> LucidFox, thanks
[15:45] <LucidFox> check the deb file to see if the file /usr/share/docs/(package)/copyright exists
[15:45] <webwolf_27> I think that may be it
[15:46] <webwolf_27> Ok time to rebuild the deb
[15:47] <crevette> superm1: how can I check myself with lintian / linda
[15:47] <LucidFox> crevette> run them over the resulting deb files
[15:47] <superm1> crevette, you can run linda and lintian on directly the .dsc and the resultant .deb
[15:47] <crevette> ah okay
[15:47] <crevette> thanks a lot
[15:49] <superm1> HighNo, okay left you a few comments, both very minor things
[15:50] <HighNo> superm1: if changed would you be advocating it=
[15:50] <webwolf_27> LucidFox, Thank you very much that was it
[15:51] <HighNo> superm1: DaveMorris would - but then he is no motu :-)
[15:51] <superm1> HighNo, well i'm still a little wary on this pysupport usage, i mean i suppose it works for this case
[15:51] <superm1> HighNo, i'll have to think about it for a few minutes
[16:14] <HighNo> if debian/docs is empty, should I omit it=
[16:14] <HighNo> ?
[16:14] <superm1> yeah
[16:19] <HighNo> superm1: could you look at debuild's output please? http://pastebin.com/d76d44ec0  This just doesn't look right, it's too short, and I only should sign it twice, had to do it four times earlier
[16:19] <HighNo> doh, never mind
[16:20] <HighNo> superm1: i should have done a debuild without -S -sa beforehand.
[16:22] <superm1> HighNo, are you building via ssh?
[16:23] <HighNo> superm1: no, I build within an pbuilder environment for hardy, i have feisty installed
[16:24] <HighNo> superm1: new version is dput'ed and awaits appearance in revu soon :-)
[16:26] <HighNo> superm1: doh, didn't see your man page info, how could I change that?
[16:31] <HighNo> superm1: I can't confirm it installs wrong. Looking into the .deb package it shows up under /usr/share/man/man1/blueproximity.1.gz
[16:36] <superm1> HighNo, well it showed up there and in doc/
[16:37] <superm1> but in an uncompressed form in doc/
[16:37] <HighNo> superm1: ahhh, ok, I guess it's in the .install file
[16:37] <JediMaster> Hey all, don't suppose anyone knows the name of the little program that looks for certain text from a program and enters responses?
[16:39] <JediMaster> trying to write an installer that runs "pecl install apc" for php, but it needs two keys to be pressed
[16:49] <sistpoty> hi folks
[16:50] <sistpoty> persia: just looking at wildmidi ...
[16:50] <jpatrick> hi sistpoty !
[16:50] <sistpoty> hi jpatrick
[16:50] <tuxmaniac> can someone please review http://revu.tauware.de/details.py?package=alliance? thanks in advance
[16:50] <sistpoty> persia: the wildmidi dependency libwildmidi0 (= ${binary:Version}) seems wrong to me (still looking)
[16:51] <HighNo> superm1: just takes another minute, I screwed my pbuilder again...
[16:51] <sistpoty> persia: since wildmidi has a NEEDED entry, this should come from shlibs:Depends instead of handcoding it
[16:55] <sistpoty> persia: also, I guess you really want = ${binary:Version} for the -dev package dependency on the library (which imo should be the right thing to make it binNMU-safe)
[16:56] <geser> Hi sistpoty
[16:56] <sistpoty> hi geser
[16:56] <geser> sistpoty: I see you found the button to prolong your MOTUship :)
[16:56] <sistpoty> geser: yes... I got the expiry reminder mail that contained the link :)
[16:58] <geser> JediMaster: are you looking for expect?
[17:01] <HighNo> superm1: the package is back at  http://revu.tauware.de/details.py?package=blueproximity
[17:01] <bluefoxicy> now that's interesting.
[17:02] <bluefoxicy> using the change nickname box instead of /nick in xchat-gnome crashes it.
[17:08]  * sistpoty is off again... cya
[17:14]  * HighNo is sad that he immediately knows what this is: 18:11:19) jdong_ hat den Raum verlassen ("FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8").
[17:14] <jdong> HighNo: :)
[17:15] <HighNo> btw, do motus like to hide (to get more work done)? It would be easier to identify them if e.g. they had voice in this channel
[17:15] <jdong> HighNo: there was a mailing list discussion about that
[17:15] <jdong> HighNo: it was ultimately agreed that wouldn't be a good idea
[17:16] <jdong> HighNo: (1) because they would be more regularly harassed for questions (2) There are plenty of non-MOTUs around here who provide excellent help and should not be treated as lessers
[17:17] <HighNo> jdong: I knew it - "(get more work done)"... but really true - I've gotten great help from the people around and was kind of surprised they are no motus :-)
[17:18] <jdong> HighNo: I was hanging around here helping people and doing various contributions as a non-MOTU since pretty much the formation of the MOTU team.
[17:20] <HighNo> jdong: maybe you could also take a look at http://revu.tauware.de/details.py?package=blueproximity ? I hope superm1 does advocate it, chances are it might go into hardy then. I tried very hard to get rid of every error...
[17:21] <jdong> HighNo: I've got a busy schedule today, but I'll look at it if I have a chance. I understand the urgency of feature freeze being around the corner :)
[17:22] <method> Is it possible that fakeroot is broken in Hardy?
[17:25] <geser> method: in what way?
[17:25] <method> geser, well fakeroot dh_testroot works, so maybe not...
[17:30] <superm1> HighNo, just looking at the diff i can still see a problem
[17:31] <superm1> you are still installing ChangeLog via the .install
[17:31] <superm1> it should only be installed by the line you had in debian/rules
[17:31] <superm1> because that will gzip it
[17:34] <method> geser, my problem is that I can run debuild -S -sa, but when I run sudo pbuilder build *.dsc, it complains that I'm not fakeroot.
[17:35] <HighNo> superm1: I'll have a look
[17:35] <Iulian> jdong: Damn MS
[17:35] <jdong> Iulian: hehe, it's my old xchat client, being brought in for unrelated amusement purposes
[17:36] <method> (which is the same failure as on the Launchpad build server)
[17:36] <Iulian> jdong: yea, I noticed ;)
[17:38] <frafu> Hello, I am preparing a package for a new revision and I am using dh_gconf to register and unregister the schemas. What I find strange with the autogenerated scripts is that they do not unregister the schemas with the purge command from apt-get, but with the remove command. Should it not be the other way round?
[17:38] <HighNo> superm1: I also have the README installed via .install. is that an error too and should be moved to debian/docs again?
[17:40] <LucidFox> jdong, could you please re-review tovid?
[17:41] <frafu> I assumed that purge would remove and unregister the schemas!?
[17:42] <tsmithe> can i use a string like "r3" for the upstream version of a package?
[17:42] <tsmithe> lintian says no
[17:45] <paas> Hi, Can a MOTU please have a look at http://revu.tauware.de/details.py?package=libtuxcap, It's ready for advocation, thanks
[17:50] <HighNo> superm1: the newest version is online, changelog corrected. Please check it and if nothing harmful is stopping you from, please advocate it :-) am away for 1 hour now, be reading everything. drop a note on revu. Thanks!
[17:55] <geser> method: which failure do you get? or the buildd?
[17:58] <method> geser: dh_testroot: You must run this as root (or use fakeroot).
[17:58] <method> make: *** [clean] Error 1
[17:58] <method> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[17:58] <method> With sudo pbuilder build *.dsc
[17:59] <geser> method: in which target is dh_testroot called in debian/rules? as not all targets are run as root
[17:59] <method> geser, ah.
[18:00] <method> geser, in install
[18:00] <method> I have build: install
[18:02]  * DaveMorris pokes superm1 for not looking at his package like he promised to do.  
[18:06] <geser> method: "The build target must not do anything that might require root privilege." from http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[18:07] <method> geser, I see it's usually not stated explicitly, instead being called after binary-indep and binary-arch. What does it do by itself?
[18:07] <crevette> what the maintainer name for MOTU package? I set the address but I assume I must set a name
[18:08] <geser> crevette: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[18:08] <crevette> tx geser
[18:12] <tsmithe> is there a limit to package size on revu? i've got a soundfont i'd like to get in that's 129MiB
[18:17] <tbutter> anyone would like to give the package http://revu.tauware.de/details.py?package=jodviewer a review?
[18:27] <DaveMorris> tsmithe: try it
[18:28] <tsmithe> DaveMorris, might take a while, but i'll give it a go!
[18:28] <DaveMorris> is that a source file that big, or the generated package size, as I've done a set of packages which have come in close to there
[18:29] <tsmithe> DaveMorris, source file: the samples that make up a general midi soundfont take up a lot of space
[18:49] <HighNo> superm1: no comment yet so I guess you didn't find the time.
[18:51] <HighNo> DaveMorris: superm1 seems busy...
[18:54] <ScottK> persia: I'm not able to build libnb-platform7java (I'm java impaired and aim to stay that way).
[19:02] <DaveMorris> it doesn't build with the blackdown jdk?
[19:07] <steveire> Hi. I want to build xine-lib and hopefully get https://bugs.launchpad.net/gutsy-backports/+bug/188340 confirmed. Should I remove some libxine from my gutsy install before doing that?
[19:07] <ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New]
[19:12] <ScottK> jdong: What's you're position on baltix using backports bugs?  Personally I think it's bogus.
[19:13] <ScottK> DaveMorris: I've no idea (see my previous note about Java ignorance and my determination to maintain it).
[19:14] <steveire> ScottK: What's baltix? I want the package backported so I can build an uncrippled kde4 easily.
[19:14] <firefly2442> I just tried making a simple package with checkinstall but it didn't grab any of the dependencies
[19:15] <ScottK> steveire: It's an Ubuntu derivative.  Note the bug is open against gutsy-backports too.
[19:15] <ScottK> !checkinstall | firefly2442
[19:15] <ubotu> firefly2442: checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
[19:16] <steveire> ScottK: too? In addition to what? That bug is in -backports.
[19:16] <ScottK> Both
[19:17] <ScottK> This is why I asked jdong the question.  I think baltix people using -backports bugs is bogus and confusing.
[19:17] <firefly2442> does checkinstall look in the debian/control file for dependencies?
[19:18] <ScottK> firefly2442: This isn't a good place for checkinstall help.  We avoid it.
[19:18] <DaveMorris> I thought you meant to wanted to avoid the sun JDK
[19:18] <steveire> ScottK: OK, well I've done configure and make. Should I remove anything (libxine) before make install?
[19:19] <ScottK> steveire: The easiest way to make .debs for backports testing is to use prevu.
[19:19] <ScottK> I'd use that if I were you.
[19:20] <steveire> Do you guys avoid prevu? I'd prefer to get it backported for everyone, not just me.
[19:21] <crevette> superm1: I corrected my package
[19:21] <ScottK> steveire: Right, but if you're trying to test it so we can do that, use prevu to make your test .debs, report your results in the bug and we'll take it from there.
[19:23] <steveire> OK, so how do I use it?
[19:23] <rhpot1991_laptop> can anyone recommend any good manpage tools, trying to format this by hand is kinda a pain, or does everyone just do it by hand?
[19:23] <ScottK> !prevu | steveire
[19:23] <ubotu> steveire: prevu is an automated, personal backporting utility. Check out https://wiki.ubuntu.com/Prevu for more details
[19:24] <ScottK> rhpot1991_laptop: Do it in docbook and use docbook2man
[19:24] <ScottK> I tend to hand edit them, but I'm a masochist.
[19:25] <rhpot1991_laptop> alright thanks, I'll back this guy up and see how that works
[19:32] <superm1> rhpot1991_laptop, there is also manedit
[19:33] <hefe_bia> docbook2x-man if you prefer the xml version AFAIK.
[19:34] <rhpot1991_laptop> help2man looks like it might be useful too
[19:35] <jdong> ScottK: it's definitely confusing, though I don't know how to deal with it -- I mean, Also Affects: is one of the key launchpad features (that they advertise) and for us to say "don't use it" is awkward
[19:35] <steveire> Why is prevu retrieving bash? Why does it need all those packages?
[19:36] <steveire> It's getting apt as well.
[19:36] <jdong> steveire: that's probably debootstrap running -- they are required components of a base Ubuntu install.
[19:36] <steveire> But I already have them.
[19:36] <jdong> steveire: that's on your parent system. Prevu (and pbuilder) work in their own chrooted environment.
[19:36] <ScottK> jdong: Except I'd say that it's inherently invalid.  *-backports are defined as backports to specific Ubuntu repositories.  Not baltix.
[19:37] <tsmithe> could someone review a large but simple package for me?: fluid-soundfont, the fluid gm/gs soundfont. thanks: http://revu.tauware.de/details.py?package=fluid-soundfont
[19:37] <jdong> ScottK: agreed, but then he's gonna start registering baltix-backports and we're back at square one.
[19:37] <ScottK> steveire: ^^^ is the developer of prevu.
[19:37] <ScottK> jdong: Fine.  Then he can file his own bugs.
[19:38] <steveire> jdong: I would have prefered to just install the package I'd just made. Seems overkill to get a whole chrooted environment.
[19:38] <jdong> ScottK: Yeah, it can be argued as a misuse of the launchpad definition of "bug also affects"
[19:38] <ScottK> steveire: It may seem that way, but it's a much safer way to do it.
[19:38] <steveire> If I build it can I mark the above xine bug confirmed?
[19:38] <ScottK> jdong: That's my view.
[19:38] <jdong> steveire: using a pbuilder environment such as the one prevu is setting up is one of the only acceptable build environments
[19:39] <ScottK> steveire: Yes and if you install it and test that it actually works, then you can set it to Triaged.
[19:39] <jdong> steveire: remember that prevu was designed first as a backports triage tool, and any backports testing not done in a clean environment is basically useless for QA purposes
[19:41] <jdong> ScottK: hmm I concur too. Perhaps we should send him a mail and ask nicely
[19:41] <ScottK> jdong: I know if you mark them invalid against baltix he gets upset.  Maybe that's best.
[19:42] <ScottK> Confusing our users and all that.
[19:42] <steveire> Is it a chrooted gutsy or hardy env?
[19:42] <DaveMorris> superm1: that linda warning is bogus btw
[19:42] <jdong> ScottK: better to communicate than play launchpad status tag.
[19:42] <jdong> steveire: depends on how you invoked prevu-init
[19:42] <DaveMorris> since if I fix the shlibs file to solve that, then lintian complains about it been wrong
[19:42] <jdong> prevu can build environments for every release of Ubuntu
[19:42] <steveire> jdong: No args
[19:43] <jdong> steveire: then it's a gutsy env
[19:43] <jdong> it defaults to your running distro
[19:43] <steveire> OK
[19:43] <ScottK> jdong: Agreed.
[19:44] <jdong> steveire: the problem with using the present environment is almost EVERYONE has a non-default configuration, so it's not very useful for answering if (1) a package builds (2) a package works.
[19:45] <superm1> DaveMorris, okay i wasn't too sure, i'm still not confident though on the 2 libraries to one package approach.  others may feel differently
[19:47] <method> Does this make sense?     -> copying [./gnome]
[19:47] <method> cp: cannot stat `./gnome': No such file or directory
[19:47] <method>  -> Aborting with an error
[19:47] <DaveMorris> k
[19:48] <jpatrick> method: pbuild the *.dsc
[19:48] <method> At the end of a pbuilder run?
[19:48] <jpatrick> method: you are not pbuilder building the .dsc file :)
[19:48] <jdong> method: wait a second....
[19:48] <jdong> method: what distro are you running?
[19:48] <jdong> wait nvm
[19:49] <method> No, jpatrick's right.
[19:49] <jdong> that only applies to pdebuild-internal.
[19:49]  * jpatrick wins \o/
[19:49] <jdong> method: sorry, gutsy pbuilder has a very similar bug that affects unknown control tags in .dsc
[19:49] <jdong> long story, I'll spare you the trauma
[19:50] <pochu> Is python2.5 installed by default in the buildds? It seems to be in my hardy pbuilder
[19:50] <DaveMorris> superm1: I've just checked in the pkgconfig for the files, and the libs are both used when you compiling against them
[19:50] <ScottK> Anyone here who's set up for GCC 4.3 test building that would be willing to do a build test for me?
[19:51] <JediMaster> Hey all, don't suppose anyone knows the name of the little program that looks for certain text from a program and enters responses?
[19:51] <ScottK> pochu: It's not essential, so you can't assume it will be there.  You actually need the depends
[19:51] <pochu> ScottK: this is more about Build-Conflicts rather ;)
[19:52] <ScottK> Ah
[19:52] <pochu> ScottK: I was wondering whether I need to put them for an Ubuntu package, or if they won't be there
[19:52] <steveire> From the wiki page :
[19:52] <steveire> Prevu may also ask to add a development line for backporting, answer yes to this as well. If Prevu doesn't automatically add the line for backporting, you will have to add it yourself. Open your /etc/apt/sources.list file, and add the line
[19:52] <ScottK> Why would it need to build-conflict?
[19:52] <steveire> Do I need to do anything? The page is clearly outdated.
[19:53] <pochu> ScottK: well I could probably s/python/python2.4/, but that would need patching and the former is easier ;)
[19:53] <ScottK> pochu: In general since Ubuntu buildd's use a clean chroot for each build, build-conflicts aren't needed.
[19:53] <ScottK> pochu: Unless it needs zope, please don't be adding stuff that needs Python 2.4.
[19:53] <ScottK> please fix it to work with python 2.5
[19:54] <ScottK> You shouldn't need to build-conflict 2.5 anyway, just build-dep on python2.4
[19:54] <pochu> ScottK: alright, thank you
[19:54] <blueyed_> Is there a wrapper script that either calls kdesudo or gksudo, based on the environment?
[19:54] <jdong> steveire: you probably don't
[19:54] <steveire> I've put in a deb-src line for hardy. I shouldn't?
[19:54] <jdong> steveire: depends on where you want prevu to get its source from.
[19:54] <pochu> blueyed: su-to-root
[19:55] <pochu> blueyed: in the menu package
[19:55] <jdong> steveire: it's convenient but not necessary :)
[19:55] <steveire> I want to get libxine source from hardy.
[19:55] <ScottK> pochu: Are you working on pychecker?
[19:55] <blueyed> pochu: great, thanks.
[19:56] <steveire> jdong: To use this method, you must have the deb-src line of a future Ubuntu release in your /etc/apt/sources.list.
[19:56] <steveire> From the wiki
[19:57] <jdong> steveire: correct. to use "prevu pkgname" you need that sources.list entry
[19:57] <jdong> steveire: but, as noted, it is not the only way to invoke prevu
[19:57] <jdong> hence why I said it's not absolutely necessary to have that line
[19:57] <ScottK> jdong: Do you have time for package reviews today?
[19:57] <jdong> ScottK: later in the day, I've been trying to leave my room but people keep pinging me :D
[19:57] <steveire> jdong: Another method (apt-get source name_of_package) needs that line AFAIK?
[19:58] <jdong> steveire: prevu lp:foo does not need any lines
[19:58] <jdong> steveire: alternatively you can go to packages.u.c to get a dsc URL
[19:58] <jdong> which also doesn't need any source lines
[19:58] <ScottK> jdong: I think clipper is in good shape and a worthwhile thing to get into the archive.  I also see mok0 is around and can answer questions if needed.
[19:58] <jdong> prevu lp:foo only works with hardy's version of prevu
[19:58] <jdong> thanks to LP changing their url scheme
[19:58] <ScottK> Or maybe blueyed will get to it first ^^^
[19:58] <mok0> Yep, I'm here
[19:59] <blueyed> ScottK: what? package clipper?
[20:00] <ScottK> blueyed: Yes.  On REVU
[20:01] <ScottK> mok0: Would you please look into merging claws-mail while your waiting? http://dad.dunnewind.net/universe.php
[20:01]  * mok0 looks
[20:01]  * ScottK needs to run out for a while.
[20:01] <ScottK> Thanks
[20:01] <ScottK> mok0: This one's easier than courier
[20:01] <ScottK> ;-)
[20:01] <mok0> ScottK: phew :-)
[20:01] <steveire> Why does all this need to be installed just to build libxine? http://rafb.net/p/BzuSsq76.html
[20:07] <steveire> I mean c'mon xcomposite etc?
[20:09] <steveire> This is quickly filling up my hd. Someone already built the package. Can it be backported without me building it?
[20:11] <steveire> All gone?
[20:12]  * sladen looks around
[20:13] <sladen> steveire: lots of people here
[20:14] <HighNo> superm1: thanks for reviewing. I'll do it right away...
[20:15] <mok0> ScottK: huh? The Ubuntu merged version of claws-mail contains a dozen packages named sylpheed-claws-* that are not in the Debian version
[20:16] <HighNo> is debian/docs the same format as .install or would it just list one entry per line which files to be considered as docs?
[20:17] <hefe_bia> steveire: I think libxine can make use of a lot of libraries and therefore needs all the headers, etc. You can delete the packages after you built it to your satisfaction. I think they will be cached in /var/cache/pbuilder/aptcache
[20:17] <mok0> ScottK: n/m. They are dummy packages
[20:18] <steveire> hefe_bia: Will it be backported whether I build it or not?
[20:20] <hefe_bia> steveire: I don't know (didn't follow the whole discussion)
[20:22] <hefe_bia> Is there a backport request bug filed?
[20:24] <steveire> hefe_bia: https://bugs.launchpad.net/gutsy-backports/+bug/188340 <<< It's old. I think it should be moved along. What has to happen?
[20:25] <ubotu> Launchpad bug 188340 in baltix "backport xine-lib 1.1.10-1 from hardy - there are several security, flash playing and other important fixes" [Undecided,New]
[20:25] <steveire> It should be confirmed, right?
[20:26] <HighNo> superm1: the new package is dput'ed and will show up at http://revu.tauware.de/details.py?package=blueproximity , any other motu is greatly appreciated
[20:26] <hefe_bia> I'm quite new to this, but I think somebody has to attach a log from a successful prevu or pbuilder build before it gets confirmed.
[20:27] <steveire> jdong: Can you confirm that? Or anyone?
[20:27] <steveire> Where do I get the log?
[20:28] <crevette> superm1: I look at debian/rules, and I don't understand why linda warns about athe space
[20:28] <superm1> crevette, check the last line for a trailing space
[20:28] <crevette> the diff deosn't show that problem neither
[20:28] <crevette> okay
[20:29] <crevette> superm1: where I find an example for the Homepage field ?
[20:29] <hefe_bia> steveire: You'd have to do the build in prevu and copy from your terminal or better do a "prevu package.dsc > buildlog"
[20:30] <superm1> crevette, its just adding "Homepage: www.blah.org" (without quotes)
[20:30] <superm1> in the debian/control file in the source area
[20:30] <crevette> superm1: there is no really an hompage
[20:30] <crevette> just a blog
[20:30] <superm1> crevette, well link to the blog then
[20:30] <superm1> that's fine
[20:30] <steveire> hefe_bia: Far too late for that. There's about a million lines of output, it's almost finished, and I didn't redirect to a file.
[20:31] <hefe_bia> hm... I don't know whether it writes a log somewhere...
[20:31] <crevette> superm1:  about the version problem, will i be allowed to re-uploaded a version ubuntu1 whereas I alrealdy uploaded an ubuntu1 and an ubuntu2 ?
[20:31] <DaveMorris> superm1:  you catch my comment about the libs?
[20:32] <superm1> crevette, you can upload an ubuntu1 to revu again
[20:32] <tsmithe> superm1, are you reviewing?
[20:32] <hefe_bia> steveire: but maybe the last few lines are o.k.
[20:32] <crevette> okay, thanks for all thal explanation; I Hop I won't bother you again
[20:32] <superm1> tsmithe, i was for a little bit but i'm working on a patch for something else right now
[20:32] <crevette> superm1: Homepage can be anywhere in the file ?
[20:32] <hefe_bia> steveire: Are yor familiar with https://help.ubuntu.com/community/UbuntuBackports section Backport Process?
[20:32] <superm1> crevette, no
[20:33] <superm1> just in the top section
[20:33] <superm1> like under the build depends
[20:34] <hefe_bia> It doesn't clearly state that the whole log is needed. But I think some kind of "evidence" of a successful pbuilder or prevu build would speed things up ;)
[20:34] <superm1> DaveMorris, yeah i saw it.  i'm still at a bit of a loss, i'd prefer that a motu who is better seasoned in library type stuff make a call on it though
[20:34] <DaveMorris> sure
[20:34] <superm1> sistpoty or persia should be good to make that call
[20:34] <DaveMorris> thanks for poking them for me :)
[20:35] <tsmithe> superm1, ok, don't worry then :)
[20:35] <steveire> hefe_bia: I'm not familiar with it. I've been working off instructions I've been getting here (which seem to have dried up)
[20:36] <tsmithe> superm1, (but fluid-soundfont is the package if you get a spare moment; it's very simple, but quite large due to the nature of soundfonts)
[20:37] <hefe_bia> it's a short section describing the "administrative process" Users are allowed to set the bug status to confirmed following these guidelines.
[20:40] <crevette> superm1: if you have some time for a last review (I hope) I'll be happy
[20:40] <crevette> thanks
[20:41] <DarkSun88> Hi all
[20:42] <HighNo> crevette: hehe "the last review" - very funny :-) I think I used that term last time 5 uploads ago. First advocation will be marked in my calendar and a holiday for my family over the next ten years :-)
[20:42] <hefe_bia> steveire: When your build succeeds copy the last few lines to a file and attach it to the bug. AFAIK you can then set the status to confirmed.
[20:42] <crevette> :)
[20:43] <DaveMorris> HighNo: lol
[20:43] <HighNo> yeah, DaveMorris knows what I am talking of - he wrote half of the comments :-)
[20:43] <steveire> hefe_bia: There's nothing of interest in there.
[20:44] <hefe_bia> steveire: but if there was an error it would be there -> so there's the positive confirmation if there is nothing there ;)
[20:45] <HighNo> DaveMorris: what do you think - is 13 a lucky number? it is my 13th upload now :-/
[20:47]  * hefe_bia has to do some stuff for a pending exam...
[20:47]  * hefe_bia is away for a while
[20:48] <warp10> Debian has http://packages.debian.org/changelog:foo to search the changelog for the package "foo". Does Ubuntu have something like that?
[20:48] <steveire> Where can I put the debs so that people can test them>
[20:48] <steveire> ?
[20:49] <ion_> !away | hefe_bia_away
[20:49] <ubotu> hefe_bia_away: You should avoid changing your nick in a busy channel like #ubuntu - it causes unrequired scrolling which is unfair to new users.  (Please set your preferred nick in your client's settings instead.)  The same goes for using noisy away messages; use the command "/away <reason>" to set your client away silently.  See also «/msg ubotu Guidelines»
[20:52] <mok0> ScottK: I've finished claws-mail. Is there a bug report for it?
[20:56] <steveire> Can I send the debs to someone to put in a PPA?
[20:56] <mok0> steveire: why don't you get your own?
[20:56] <steveire> Don't you have to be a MOTU?
[20:56] <mok0> steveire: nope
[20:57] <mok0> steveire: it's open to mortals
[20:59] <steveire> I don't have a GPG key. I'm not sure I want the hassle of maintaining one yet.
[20:59] <steveire> I'm the kind of person who'd need to read up extensively on it.
[21:00] <mok0> steveire: it's not difficult, and you'll need it all the time
[21:00] <steveire> IF I want to be a ubuntu devel. I'm just trying to build kde trunk...
[21:00] <steveire> mok0: I'm not saying it's difficult, I just don't know what it means
[21:02] <mok0> steveire: you need to generate a (private, public) key pair. You submit the public one to Launchpad
[21:02] <mok0> The private one you keep very private
[21:02] <steveire> Yeah, aren't there legal bindings to them too?
[21:02] <mok0> steveire: no
[21:03] <mok0> steveire: it's in your own interest to guard your private key, in case someone want to impersonate you
[21:05] <steveire> mok0: And back it up etc. It'll take prep. I'll also have to read that CoC thing and see if I agree.
[21:05] <mok0> Yep :-)
[21:09] <HighNo> steveire: I strongly recommend the use of gpa - the gnu privacy assistant. Makes creating and handling of keys a breeze.
[21:09] <steveire> HighNo: Note that I use kde
[21:10] <HighNo> steveire: ok, it would run anyway but likely not really look and feel like a KDE program then, it's all gtk2
[21:11] <HighNo> steveire: but kgpg should fit equally well
[21:11] <steveire> I've just installed it and I see I already have Dennis Kaarsemaker's key in there
[21:12] <dcordero> hi
[21:12] <HighNo> steveire: you might have installed it when installing signed software from a different repository
[21:12] <steveire> HighNo: Yes. Seveas repo  I guess
[21:13] <steveire> What expiration should I put on this?
[21:13] <HighNo> steveire: though I am not sure as that key should not go into your user's keyring
[21:13] <rhpot1991_laptop> how do I put a ' into a manpage
[21:13] <rhpot1991_laptop> \' doesn't seem to do the trick
[21:13] <HighNo> steveire: whatever you like. 2 years is ok, some put it unlimited which is not ideal
[21:14] <steveire> I'll go for 1 year, 4096 bit, RSA mode
[21:15] <Seveas> steveire, you'll want to remove that key from your user keyring, you should only have that in the apt keyring
[21:15] <HighNo> hm, anybody here - I've read somewhere along with REVU it should contain an ElGamal key - which mine doesn't and (if that is not the reason my package isn't advocated yet) still everything works=!
[21:15] <blueyed> pochu: do you think changing the default of su-to-root to use "sudo" instead of "su" makes sense in Ubuntu?
[21:16] <HighNo> Seveas: thanks for putting that right, I am wondering how the key could have gotten there...
[21:17] <Seveas> HighNo, he might have followed ancient instructions on how to add the key rto the apt keyring
[21:17] <HighNo> Seveas: I am thinking of a setup where the key would have gotten in the users keyring - maybe I do that too seldomly
[21:18] <Seveas> HighNo, gpg --import $keyid && gpg --export --armor $keyid | sudo apt-key add -
[21:18] <Seveas> HighNo, that used to be the quickest way of getting the key
[21:19] <HighNo> Seveas: ahh, ok
[21:19] <HighNo> Seveas: now THAT is obvious :-)
[21:21] <steveire> Seveas: I wonder how it got there...
[21:22] <steveire> I added it with sudo at-key add
[21:22] <steveire> apt*
[21:23] <HighNo> steveire: anyway having anothers key is nothing bad. I doesn't hurt either side - as long as it's the public key :-)
[21:27] <pochu> blueyed: su-to-root is mostly to be used in menu and .desktop files. I can't see a need to use it in scripts, as those can directly use sudo. But if there are scripts from devscripts or somewhere else using it, then I think it makes sense.
[21:28] <steveire> I deleted the other key. I'm having to generate my keypair again. Somehow my password didn't work to create the revok cert.
[21:28] <blueyed> pochu: It would make sense now for the apt-file update-notifier I'm doing, but there are others in /usr/share/menu/ which are likely non-functional in Ubuntu..
[21:28] <blueyed> See "grep su-to-root /usr/share/menu/*"
[21:29] <steveire> Strange. Same thing happened again. I know the password is right...
[21:32] <HighNo> steveire: does it require you to generate a revocation ceritficate?
[21:33] <steveire> No, but my password must work or the key is useless.
[21:33] <pochu> blueyed: I see. We don't use the menu system though, but I guess some window managers (fluxbox maybe?) use it. So then yes.
[21:38] <HighNo> steveire: if nothing else works - start a terminal and type gpg --gen-key
[21:40] <rhpot1991_laptop> anyone have any idea how I get a single quote to show up properly in a man page?
[21:40] <steveire> HighNo: I'm putting in the right pw, but it fails every time, maybe due to special characters. How do I 'open' the key in the terminal. Ie, anything that requires me to put in the password.
[21:43] <HighNo> rhpot1991_laptop: \*(lq Left angled doublequote: ' \*(rq Right angled doublequote: '
[21:43] <HighNo> steveire: using your password would be required if you sign something, otherwise your password is never needed
[21:45] <rhpot1991_laptop> HighNo: looking for a single quote
[21:46] <HighNo> steveire: I believe I had the problem too. I'm not using very special chars anymore. It's a passphrase anyway. You should make it long and memorable. Long is good, complex is not a real need.
[21:46] <DaveMorris> I tend to use snippets out of songs :)
[21:46] <steveire> I'm trying to generate it on the cmd line now
[21:46] <steveire> Heh, I need to generate more bytes of entropy
[21:48] <vemon> https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball <- does anyone see a severe conflict between the first and the uscan approach?
[21:48] <HighNo> rhpot1991_laptop: try \e'
[21:48] <HighNo> steveire: then do it :-)
[21:48] <vemon> the first one get's the upstream source currently compatible with the package and the uscan approact just gets the newest source available
[21:49] <vemon> i can't get over this :)
[21:49] <cbx33> hey guys
[21:49] <cbx33> howz it going
[21:50] <rhpot1991_laptop> HighNo: still getting a bunch of giberish
[21:50] <RAOF> vemon: The uscan approach is correct.  get-orig-source should get the latest upstream version.
[21:52] <rjmyst3> superm1: I just uploaded a new package with the licensing issues fixed.
[21:53] <rjmyst3> superm1: would you mind taking a look at it?
[21:53] <vemon> RAOF, what if i post a diff with changes for a new upstream version to launchpad?
[21:53] <JediMaster> how would you go about running an expect script from within a postinst script?
[21:54] <vemon> RAOF, shouldn't the motu's reviewing my changes get the original source using either uscan or get-orig-source?
[21:54] <RAOF> vemon: That doesn't change what get-orig-source should do.
[21:54] <vemon> ok. :)
[21:54] <vemon> i'm happy enough if it's clearly defined to always work like that
[21:54] <RAOF> You can use uscan to get a particular version (IIRC), or they can just go to the website from debian/copyright and download the right version.
[21:54] <shibata> rhpot1991_laptop: How about "`"?
[21:55] <vemon> RAOF, true
[21:55] <HighNo> rhpot1991_laptop:  hm, all I can see by reading other man pages is '
[21:55] <RAOF> The watch file is there to be machine-readable.  People can be more flexible :)
[21:55] <n3t_decrip70r> se la comen re doblada
[21:55] <n3t_decrip70r> .xD
[21:55] <n3t_decrip70r> lol
[21:55] <HighNo> rhpot1991_laptop: do you write it by hand?
[21:56] <rhpot1991_laptop> it keeps replacing them with an a with  ^ over it, and 2 boxes
[21:56] <vemon> RAOF, thanks. i found my peace now and can maybe get some sleep now =)
[21:56] <rhpot1991_laptop> right now I am in manedit, but its been doing the same when I write them in vi
[21:57] <rhpot1991_laptop> shibata: not liking that either
[21:58] <HighNo> rhpot1991_laptop: but there is no encoding problem here - right? I mean your tools are not generating like utf-8 and man/groff likes plain ascii only, stuff like that
[21:58] <vemon> RAOF, btw. do you know if there is a target for repacking the source package when needed? get-orig-source doesn't seem like the right place if it's meant to get the latest upstream version
[21:59] <vemon> i have a special need to unpack, patch and repack the upstream tarball with a package called whysynth
[21:59] <RAOF> vemon: There's not a standardised place that I know of.  "get-pkg-source", or some similar target, might do.
[21:59] <vemon> persia probably talked to you about that earlier
[22:00] <rhpot1991_laptop> looks like plain ascii to me
[22:01] <shibata> rhpot1991_laptop: FYI, I have found "`" in cpufreq-selector.1.gz.
[22:02] <rhpot1991_laptop> where abouts?
[22:02] <rhpot1991_laptop> I see it doing the same thing here where text rolls around too
[22:02] <rhpot1991_laptop> cpufreq-selector is a command-line tool for choosing CPU frequency setâ
[22:02] <rhpot1991_laptop>        tings.
[22:02] <rhpot1991_laptop> like that
[22:03] <rhpot1991_laptop> are there supposed to be quotes around powersave, and performance?
[22:03] <superm1> rjmyst3, i still dont see a COPYING file, and the diff.gz is now empty?
[22:04] <rjmyst3> the diff.gz has been empty
[22:04] <rjmyst3> the GPL is in output/license.txt
[22:04] <rjmyst3> it should be called COPYING?
[22:04] <superm1> wow. i'm surprised that we never caught that
[22:04] <rjmyst3> ok
[22:04] <superm1> it should be COPYING
[22:04] <superm1> the debian/ directory should be in the diff.gz
[22:04] <superm1> it shouldn't be in the upstream directory
[22:05] <rjmyst3> ok
[22:05] <shibata> rhpot1991_laptop: yes. single quotes is used around powersave, performance.
[22:05] <superm1> rjmyst3, and put the COPYING file at the root of the .orig.tar.gz'
[22:05] <vemon> RAOF, just to explain this to myself better: shouldn't the get-orig-source actually be get-latest-orig-source?
[22:05] <rjmyst3> ok
[22:06] <RAOF> vemon: Yes.  That's what it means.
[22:06] <cbx33> anyone here recompiling after the vmsplice bug notice?
[22:07] <RAOF> vemon: On the other hand, it's meant to make it easier to package new upstream versions; you don't need to repack the existing tarball, since that's in the archives (is the thinking).
[22:07] <rhpot1991_laptop> shibata: this is what it shows on mine: CPU governor to use, such as ââpowersaveââ, ââperformanceââ.
[22:08] <shibata> rhpot1991_laptop: "`" seems to be replaced to U+2018 man page.
[22:09] <soto> Is there a way to automatically adjust patch files to the correct offsets when they apply with some fuzz?
[22:09] <sladen> soto: patchutils has some stuff for doing 3-way diff updates without the original
[22:10] <sladen> soto: but if you get it to apply with the fuzz, you can then generate a new diff from the result
[22:11] <vemon> is it possible to patch a tar file with a normal diff?
[22:12] <soto> sladen: Okay thanks
[22:13] <HighNo> superm1: I added the COPYING stuff on the UpstreamGuide - I'll try to listen to problems regarding upstream packages and fill things in there...
[22:14] <superm1> okay HighNo, i'll get a chance to look again at your package in a bit
[22:15] <shibata> rhpot1991_laptop: How about that? $ LANG=C man cpufreq-selector
[22:16] <HighNo> superm1: cool, take your time (as long as get a little advocation there ... :-) )
[22:21] <rjmyst3> superm1: is the COPYING file just supposed to be a copy of the GPL, or should it also say something like "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License..."
[22:25] <rhpot1991_laptop> shibata: bash: en_US.UTF-8=C: command not found
[22:29] <superm1> yes
[22:29] <superm1> rjmyst3, copy of the GPL
[22:29] <rjmyst3> ok
[22:30] <HighNo> I am totally freaking out now - who stole my COPYING file? I swear it has been there... grrrr. superm1 please wait a sec. I have to create another upstream release WITH the COPYING file. Iknow I had done it before - this is so strange...
[22:32] <shibata> rhpot1991_laptop: sorry, please remove "$"
[22:33] <rhpot1991_laptop> shibata: that looks much better
[22:33] <rhpot1991_laptop> fixes mine up too
[22:38] <dcordero> hi
[22:42] <rjmyst3> superm1: i've made those changes and uploaded a new one
[22:46] <HighNo> superm1: the newest version of blueproximity with COPYING in upstream has been dput'ed. REVU appearance will be delayed as usual...
[22:47] <steveire> I've just made a PPA, and it says my repo is deb http://ppa.launchpad.net/steveire/ubuntu hardy main. Shouldn't that be gutsy?
[22:48] <DaveMorris> HighNo: you gonna update your backports once it's accepted for hardy?
[22:48] <hexmode> steveire: have you uploaded any packages yet?
[22:48] <steveire> hexmode: Nope
[22:49] <steveire> I want to make packages for use by gutsy though
[22:49] <hexmode> on my ppa, it didn't say gutsy till after I uploaded some pkgs to be built for gutsy
[22:49] <hexmode> https://launchpad.net/~hexmode/+archive/ # for example
[22:51] <HighNo> DaveMorris: ??? I'd like to see it backported for gutsy and feisty - yes, but do I make them? If I can help with that sure.
[22:51] <steveire> hexmode: OK, cool. Just trying to figure out how to upload a package now...
[22:54] <steveire> hexmode: Do I put my password in  ~/.dput.cf under login or what?
[22:54] <steveire> https://help.launchpad.net/PPAQuickStart
[22:56] <DaveMorris> HighNo: well you can do them in your ppa, whilst waiting for the backports team to do them (after you've requested a backport)
[22:58] <HighNo> DaveMorris: I'll have a look at it after tomorrows exam and my package being accepted...
[22:59] <steveire> I want to upload xine-lib-1.1.10 to my ppa. What package name and version should I give it?
[22:59] <hexmode> steveire: sorry, kids acted up
[22:59] <hexmode> steveire: you need to dput a source package
[23:00] <steveire> It's in hardy, but not gutsy, and there's an old backport request I want to outrun
[23:00] <hexmode> in the dist portion of your changelog put gutsy
[23:00] <steveire> hexmode: Yep, it's package name and version convention I need now
[23:00] <steveire> hexmode: I'm not changing the package at all/
[23:00] <hexmode> same as always ;)
[23:00] <hexmode> just change hardy to gutsy
[23:00] <steveire> changelog?
[23:00] <hexmode> and ppa will target for gutsy
[23:01] <DaveMorris> HighNo: you noticed the new versions of bluetooth packages on revu?
[23:01] <hexmode> steveire: debian/changelog
[23:01] <steveire> xine-lib-1.1.10-1.dsc?
[23:01] <steveire> OK
[23:01] <emgent> heya people
[23:01] <HighNo> DaveMorris: not yet.
[23:01] <DaveMorris> at the bottom of the page
[23:03] <HighNo> DaveMorris: oh, yes. I noted them - that's why I know that superm1 is my man, my personal hero, my advocate :-)
[23:03] <RAOF> persia: http://revu.ubuntuwire.com/details.py?package=gnome-do is available for your reciprocation :)
[23:04] <RAOF> Or anyone else who wants to review a cool launcher app, of course.
[23:04] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[23:05] <HighNo> DaveMorris: superm1 wanted to think about advocating it. I was never so close :-)
[23:05] <DaveMorris> HighNo: just tell him you can make it do something fancy for Mythbuntu, and he'll do it ;)
[23:06] <HighNo> superm1: you heard DaveMorris ? :-)
[23:06] <ScottK> mok0: Those packages are transitional to support Dapper --> Hardy upgrades
[23:06] <HighNo> I guess I shouldn't ping him all the time...
[23:06] <mok0> ScottK: I figured
[23:07] <DaveMorris> hehe
[23:07] <mok0> ScottK: bug 190764
[23:07] <ubotu> Launchpad bug 190764 in claws-mail "[needs-merge] claws-mail_3.3.0-1" [Undecided,New] https://launchpad.net/bugs/190764
[23:08] <mok0> ScottK: I set the bug to "confirmed" and att: me, but that was reverted shortly after. I thought that was the way it was done, but apparently not
[23:09] <ScottK> Did you subscribe UUS?
[23:09] <mok0> ScottK: yes
[23:09] <ScottK> Good.
[23:09] <ScottK> I'd have thought confirmed was good, but what do I know....
[23:09] <mok0> ScottK: LP should do all this automatically
[23:10] <steveire> hexmode: Pattern not found: hardy. What line do I change?
[23:10] <mok0> ScottK: it knows you're uploading a patch, it knows who you are.
[23:10] <mok0> ScottK: It should have buttons where you could define that it's a merge, etc.
[23:11] <ScottK> Don't wine to me about LP or you'll end up with a multi-hour rant on using non-free tools to develop free software.
[23:11] <mok0> ScottK: heh
[23:11] <ScottK> But do file bugs.  They actually pay attention to them sometimes.
[23:11] <mok0> ScottK: LP is a piece of c**p
[23:12] <steveire> grep -ri hardy * <<< Also returns nothing
[23:12] <ScottK> ;-).  File bugs.  It's all you can do.
[23:12] <mok0> ScottK: yeah... *sigh*
[23:13] <steveire> Can I get some PPA help? I have the source of xine-lib-1.1.10 and I want to upload it to my PPA for gutsy. What should I use for P and V as described here: https://help.launchpad.net/PPAQuickStart
[23:14] <mok0> ScottK: anyway, that claw-mail package builds just fine under hardy, and the diffs to debian are limited to those dummy compat packages plus the changelog
[23:14] <mok0> ScottK: It can be a straight sync in hardy+1
[23:15] <steveire> Is there a better channel for PPA help?
[23:15] <ScottK> steveire: #launchpad
[23:15] <steveire> ScottK: Cheers
[23:16] <hefe_bia> P: xine-lib V: 1.1.10-something
[23:19] <steveire> hefe_bia: I'm still stuck on the changelog bit. Any idea?
[23:24] <steveire> I did a `dch -i -D gutsy` to add a gutsy line
[23:26] <hexmode> steveire: sorry, I was out.  That's the right thing.
[23:26] <hexmode> do you know how to build a source pkg?
[23:27] <steveire> hexmode: Yes, but I upload the source, right? LP builds the package.
[23:28] <hexmode> yes, sign the src changes file and dput that
[23:28] <HighNo> could another motu please check http://revu.tauware.de/details.py?package=blueproximity for advocation? got one by superm1 already!
[23:28] <shibata> rhpot1991_laptop: I think that it is problem of your terminal. Please select Terminal > Encode > UTF-8, then do man. If encode was ISO-8859-*, single quote became â in my environment.
[23:30] <steveire> Does the note about debuild -S -sd instead of -sa apply to me?
[23:31] <hexmode> steveire: where do you see that note?
[23:32] <steveire> https://help.launchpad.net/PPAQuickStart <<< Halfway down
[23:33] <hexmode> steveire: probably not if your email is in the changelog file (which, if you just used dch, it probably is)
[23:33] <rhpot1991_laptop> shibata: already at UTF-8 actually
[23:33] <hexmode> steveire: actually, if you want to experiement, try -sd first
[23:33] <hexmode> if it fails, do -sa
[23:34] <steveire> hexmode: OK, finally, for P should I use xine-lib or libxine1?
[23:34] <steveire> updating while using my ppa should update xine
[23:34] <hexmode> xine-lib
[23:35] <hexmode> that's just the name of the file
[23:35] <geser> steveire: xine-lib as that's the source package name
[23:35] <hexmode> so use the name of the source.changes file
[23:36] <steveire> where is the source.changes?
[23:36] <geser> steveire: debuild -S will create one
[23:36] <steveire> OK
[23:38] <shibata> rhpot1991_laptop: Hmm,,, Sorry, I do not seem to be able to help...
[23:55] <persia> superm1: Installing gmyth doesn't actually fix everything.  It also needs an extra '/' removed, and the patch needs work to actually unpatch cleanly.  I'm working on it for something else anyway, and will upload those fixes with my stuff (or if I fail, upload with only those fixes).
[23:55] <persia> ScottK: OK.  Taking a look at clipper soon.
[23:55] <persia> ScottK: For libnb-platform7-java, you may need to pull some build-deps from NEW
[23:55] <persia> RAOF: Thanks.  On the shortlist.
[23:55] <superm1> persia, intersting, it built fine as it was for me previously
[23:55] <superm1> okay thanks persia
[23:57] <persia> superm1: I suspect it has something to do with the autogeneration of the install file.  The version I downloaded didn't actually pull gmyth, and regenerating install broke from an extra '/'.  Anyway, trivial.  The fact that I can't initialise the plugin I want is more annoying.
[23:57] <superm1> understandable