[00:19] <MTecknology> Once I finish this package is it possible for me to get it into the karmic universe or will it need to wait until lucid?
[00:32] <RAOF> MTecknology: It won't get into Karmic universe, except possibly via backports.
[00:33] <nigel_nb> maco: http://cinelerra.org/ the one I was hoping to get into the repos
[00:33] <dtchen> nigel_nb: please work with the Ubuntu Studio folks regarding cinelerra
[00:34] <dtchen> #ubuntustudio-devel
[00:34] <nigel_nb> dtchen: oh, its already there?
[00:34] <dtchen> there isn't sense in duplicating work
[00:35] <nigel_nb> dtchen: true. thanks :)
[00:38] <MTecknology> RAOF: When it's finished how do I get it into universe?
[00:39] <RAOF> MTecknology: Upload a candidate package to revu, where it'll (hopefully) be reviewed - however, reviewer's time is limited.
[00:39] <RAOF> MTecknology: Bonus points for submitting the package to Debian as well - mentors.debian.net is what you're after there.
[00:40] <MTecknology> RAOF: Can I upload the candidate to revu or do I need to get temporarily into that team?
[00:40] <RAOF> You upload the candidate to revu.
[00:41] <RAOF> Anyone can upload there.
[00:41] <MTecknology> here? revu.ubuntuwire.com
[00:42] <MTecknology> I thought you meant something like ~revu
[00:42] <RAOF> No, revu.ubuntuwire.com
[00:52] <MTecknology> RAOF: thanks; I'm all setup for when I'm ready for that point :)
[01:01] <dtchen> this "is anyone ever going to fix this major bug?" thread is depressing
[01:02] <dtchen> the implication seems to be that people already involved in development are not doing enough
[01:02] <syn-ack> dtchen, which one is that?
[01:03] <directhex> dtchen, little kids these days feel a sense of entitlement to everything, instantly. i blame the internet
[01:03] <directhex> dtchen, they are entitled to 56 hours a week of your time, no less
[01:04] <dtchen> syn-ack: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-December/010186.html
[01:04] <ajmitch> directhex: I thought the minimum requirement to be a developer was 168 hours a week?
[01:05] <ajmitch> the slight exaggerations about apt-get being more or less unusable on 64-bit systems doesn't help the cause
[01:05] <syn-ack> Pardon my french but no shit is it taking a "long time" with what they're trying to do
[01:06] <RAOF> My guess: that bug would get more attention if there hadn't been a huge debian-devel flamefest about the package being totally broken.
[01:06] <syn-ack> I wouldn't really even consider that bug
[01:06] <RAOF> Also, it's a hack until multiarch support workse.
[01:07] <syn-ack> I mean, it *is* but still
[01:07] <ajmitch> also, is ia32-libs-tools the right package? it was removed from karmic
[01:07] <directhex> dtchen, sounds like you need a killfile to help filter out that kind of thing from your inbox before it falls under your eyeballs
[01:07] <RAOF> ajmitch: It probably is the right package.
[01:07] <RAOF> The guy was complaining about Jaunty, IIRC.
[01:08] <ajmitch> RAOF: so it's fixed in karmic, close the bug! :)
[01:08] <RAOF> Good point!
[01:08] <dtchen> bddebian: hi! thanks for the work on experimental's libsdl1.2. I think there's a stray Depends for libsdl1.2-dev in debian/control, though.
[01:11] <dtchen> bddebian: because experimental doesn't build-dep on libglu1-mesa-dev, it seems odd to have it listed as a dep for libsdl1.2-dev
[01:12] <dtchen> bddebian: If you prefer, I can do the BTS drill :-)
[01:20] <syn-ack> Not to dwell, but I don't believe I ever had that issue with apt-get on Jaunty
[01:21] <syn-ack> anyway. hrm
[01:32] <RAOF> syn-ack: You wouldn't unless you'd installed the package that diverts apt-get in order to download the i386 packages files and convert them to amd64 packages files.
[01:32] <RAOF> Man.  That sentence could have been better written.
[01:35] <syn-ack> It could have but I get it
[01:35] <syn-ack> anyway bbiab
[01:40] <ajmitch> RAOF: the package that was a nasty collection of hacks?
[01:49] <RAOF> ajmitch: Yes, exactly
[02:09] <MTecknology> RAOF: even if the revu-uploaders team isn't used anymore; can I still join the team so I can have that pretty icon?
[02:10] <RAOF> MTecknology: Quite possibly?  Is it an open team?
[02:11] <MTecknology> RAOF: restricted
[02:15] <MTecknology> RAOF: I was just wondering if somebody could add me to it;
[02:15] <MTecknology> RAOF: actually, I often wonder why some of these teams aren't just deleted
[02:15] <RAOF> I'm not sure if it's used anymore; as such, I won't be touching it.
[02:15] <MTecknology> like ~revo
[02:15] <MTecknology> ~revu*
[02:18] <MTecknology> siretart: you around?
[02:27] <foxmike> h
[03:06] <sbalneav> Hey all, I tried asking this before but my lines were being trimmed, so I'll break this up...
[03:06] <sbalneav> I'm both upstream for sabayon, and the packager here in Ubuntu...
[03:07] <sbalneav> When I was doing my testing, I was creating an "upstream" tarball, which in retrospect, I should have called sabayon-xx-prerelease, but instead I was just using the number it was going to have.
[03:08] <sbalneav> I've now actually had the official tarball released through gnome.org, but just before release, news and readme was updated.
[03:09] <sbalneav> So now, when I go to rebuild the package, of course, it complains the tarball's different when I dput, though it's the same name.
[03:09] <sbalneav> is there anyway to delete the tarball from my ppa?
[03:09] <sbalneav> I've already deleted the package.
[03:09] <sbalneav> but no-go so far.
[03:11] <dtchen> crazy versioning tricks are possible
[03:11] <dtchen> e.g., + , epoch, etc.
[03:12] <dtchen> more detail (e.g., the actual versions involved) is necessary
[03:12] <micahg> sbalneav: I think there's a .upload file in the directory where you uploaded the .dsc
[03:13] <sbalneav> ok, the tarball I need to ditch from launchpad is sabayon_2.29.2.orig.tar.gz
[03:13] <sbalneav> micahg: Yeah, I deleted that.  it's complaining about the file on launchpad itself.
[03:14] <sbalneav> somehow it's still hanging about somewhere.
[03:14] <micahg> sbalneav: it can take a little while for LP to delete all the files
[03:14] <sbalneav> ah, ok, so maybe try again in a bit?
[03:15] <micahg> sbalneav: yeah, idk if they made it so that the .orig.tar.gz is never deleted though
[03:17] <sbalneav> Well, this was a few hours ago.  I just got back from my son's christmas concert, so I'll give it a go
[03:21]  * sbalneav slides micahg a beer
[03:21] <sbalneav> Yup that was it.
[03:21] <sbalneav> Patience, virtue, etc.
[03:22]  * micahg offers the beer to someone who needs it :)
[03:22]  * micahg thanks sbalneav graciously
[03:26] <sbalneav> NP!
[03:26] <micahg> how long should I wait before poking someone about approving a package in -proposed?
[03:26] <micahg> approving a sponsored upload that is
[03:45] <pting> so i uploaded a custom php5 ppa deb, but for some reason, i'm getting an error that i'm unsure of how to fix... issuing an apt-get install php5-fpm... i get this... php5-fpm: Depends: php5-common (= 5.2.10.dfsg.1-2ubuntu6.3~ppa1) but 5.2.10.dfsg.1-2ubuntu6.3 is to be installed
[03:46] <micahg> pting: there must be an exact version depends in debian/control
[03:48] <pting> micahg, thanks, i'll double check it
[03:50] <tbielawa> #/join #ubuntu-server
[03:51] <persia> pting: 5.2.10.dfsg.1-2ubuntu6.3 is newer than 5.2.10.dfsg.1-2ubuntu6.3~ppa1
[03:51] <persia> (try dpkg --compare-versions)
[03:51] <persia> You'll need to either clean up and install both, or create a version that is newer than the default (perhaps use '+' instead of '~')
[03:56] <jdong> all you fancy rosetta people, wrt bug 386683, is it safe to handle as a SRU as proposed?
[03:56] <jdong> or is there some magical procedure to follow to update strings?
[03:57] <pting> persia, hum, thanks, i'll try the '+' replacement
[04:19] <pting> so when repackaging a deb with some patches, is it customary to increase the version and add that ~ppaN or keep the same version but use a '+'?
[04:20] <pting> i guess the docs suggest increasing that suffix version number
[04:21] <ScottK> Depends on your goal.
[04:21] <micahg> pting: here's the LP suggested docs: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[04:25] <pting> my goal is just to patch in php-fpm into the current stable php5... dreamcat4 has already created it for an older version (5.2.10.dfsg.1-2ubuntu3~pre18), i'm just trying to patch it again the latest
[04:28] <persia> pting: My recommendation would be to use ${VERSION}-${REVISION}+${EXTRAREVISION} if you're packaging customisations for limited distribution and stuff, and reserve the use of '~' for cases where you're looking for testing (or similar) as a candidate for pushing into the archive.
[04:33] <pting> persia, thanks, that sounds good
[04:34] <micahg> persia: are you an archive admin?
[04:34] <persia> micahg: I am not.  You can check the membership of the team on LP.
[04:34] <micahg> ok
[04:35] <persia> micahg: For what do you need an archive admin?
[04:36] <micahg> oh, I have something that someone sponsored to -proposed and was wondering if I can get it released to -proposed
[04:36] <persia> Oh.  How long have you been waiting?
[04:36] <micahg> it's only been in there 5 days
[04:37] <ScottK> micahg: Is it a Universe package and if so,  did motu-sru approve it?
[04:37] <micahg> yes and I think so
[04:37] <ScottK> What bug?
[04:37] <micahg> bug 477513
[04:39] <persia> People still use uim?
[04:40] <micahg> idk, but I have a feeling it's responsible for quite a few crashes
[04:40] <persia> My understanding was that it had been mostly abandoned upstream
[04:40]  * persia goes to investigate
[04:40] <micahg> but apport has been broke, so I couldn't have people submit their crashes
[04:40] <micahg> persia: a new version was just migrated to debian testing
[04:41] <ScottK> micahg: It's motu-sru approved.  I can accept it.
[04:42] <persia> With lots of new stuff too.  Wow!  I hadn't looked at uim since Feisty or so.
[04:42] <micahg> ugh, it really isn't that used...
[04:42] <micahg> but I still have a suspicion
[04:42] <micahg> thanks ScottK
[04:47] <ScottK> micahg: Done.
[04:47] <micahg> thanks :)
[04:48] <persia> ScottK: On a related note: what's the current status of merging the SRU teams?
[04:48] <ScottK> persia: Decision has been made to do it, specifics TBD.
[04:48] <persia> Then I didn't miss anything :)
[04:49] <ScottK> In the intermin, I've decided to view the lack of mention of motu-sru on the SRU process page as a documentation bug.
[04:49] <ScottK> intermin/interim
[04:49] <micahg> oh, are we still supposed to subscribe motu-sru?
[04:49] <persia> I prefer to think of it as a organisational bug (as in the fix is to merge the teams rather than change the docs)
[05:02] <jdong> persia: pitti sent out mail with intent to merge everyone into ubuntu-sru
[05:02] <jdong> however, it hasn't been done yet
[05:02] <jdong> indeed, micahg, for now if you want attention to be paid, you should continue to subscribe motu-sru
[05:02] <micahg> jdong: ok, I'll fix my other bug
[05:02] <ScottK> jdong: lmms is still sitting there from before release, btw....
[05:03] <micahg> jdong: bug 455089 in case you're interested
[05:04] <jdong> ScottK: from my viewpoint we're still waiting for verification procedure or a good reason why to do it
[05:05] <ScottK> OK
[05:14] <ScottK> jdong: Would you please look at Bug 458129 - it's uploaded already
[05:16] <jdong> ScottK: acked
[05:17] <ScottK> jdong: Bug 491522 too.
[05:18] <syn-ack> Anyone in here have skype account that wouldnt mind giving me a ring? I think I just nailed down the profile
[05:18] <syn-ack> the apparmor profile that is
[05:19] <syn-ack> I've got it running and all that but I want to make sure that everything still works as far as audio and the like
[05:19] <jdong> ScottK: also taken care of
[05:19] <micahg> jdong: I did ubuntu2 because there was no ubuntu2 in lucid...is it always supposed to be a dot release for SRU?
[05:19] <jdong> micahg: yes please
[05:19] <micahg> jdong: got it
[05:21] <micahg> jdong: is it proper to delete old versions of patches (that's what I've been doing)
[05:21] <ScottK> jdong: Up to date now.  Thanks.
[05:21] <jdong> micahg: you don't have to...
[05:21] <jdong> personally I've preferred for and previously asked for the original bug description to include the latest debdiff intended for review linked.
[05:21] <jdong> but if it's obvious from scrolling down what debdiff is the one to review that's a moot point
[05:22] <micahg> jdong: so if I do v1, v2, v3, that's ok
[05:22] <jdong> it gets somewhat irritating for those huge bugs with 100 comments to have to read all of the chatter to find the right patch.
[05:22] <jdong> micahg: yeah that's entirely fine by me
[05:22] <jdong> we're humans :)
[05:22] <micahg> jdong: one nice feature of bugzilla is that you can mark a patch obsolete
[05:24] <micahg> anyone feel like sponsoring an upload? :)
[05:27] <paultag> Any MOTU around to hand-walk me through a question?
[05:27] <paultag> ( regarding control / control.in )
[05:27] <paultag> I'ts simple, I promise ;)
[05:29] <ScottK> paultag: Your odds of getting an answer to a question go up if you ask it.
[05:31] <paultag> Fair enough. Not familiar with MOTU protocol, so I wanted to test first. I'm trying to learn a bit more about control files -- am I able to use variables in a control file ( like ${shlibs:Depends} ) as one was able to do with control.in ?
[05:32] <paultag> ScottK, ^ ( sorry, forgot the ping )
[05:32] <ScottK> That one, yes.
[05:33] <paultag> ScottK, OK. Is there any difference except that of ascetics with control vs control.in ?
[05:33] <paultag> are *
[05:33] <ScottK> All the ${stuff here} ) variables are usable.
[05:33] <paultag> Outstanding. Thank you ScottK :)
[05:34] <ScottK> I'm not a fan of control.in.  I think that if you're changing your control file, you ought to do it on purpose.
[05:34] <paultag> ScottK, Yeah, I'm working with upstream deb, and I asked to take on a bit of a role in the package. I'm moving it from control.in to control now
[05:35] <paultag> Now, to figure out git >:)
[05:36] <paultag> thanks for all the help ScottK :)
[06:02] <tbielawa> Howdy ya'll. I would appreciate any feedback. Jaunty libvirt ftbfs for me using dpkg-buildpackage. http://pastebin.com/m15c980f4  However, if I run the autogen.sh script in the base directory before I run the dpkg scripts I can build it without error.
[06:02] <tbielawa> I'm wonder if this is unusual behavior? I didn't find mention of it in any bug reports or package notes....
[06:04] <tbielawa> The errors are clearly happening within the libtool system, however in a new pbuilder and on my regular shell it won't build without running ./autogen.sh first.... :-\
[06:04] <jmarsden> I'll try it here (are you building Jaunty libvirt on Jaunty, or on Karmic or Lucid?)
[06:05] <tbielawa> building lp:ubuntu/jaunty-updates/libvirt on 9.04
[06:05] <tbielawa> thanks jmarsden for taking a peek
[06:06] <jmarsden> No problem... firing up Jaunty server VM, I switched my host OS on this desktop to Karmic last week...
[06:08] <tbielawa> I'd like to get Bug #368084 closed. I was able to backport the patch for libvirt 0.6.5 to 0.6.1 (Jaunty version).
[06:09] <tbielawa> Now that I've got the package building (took longer than backporting the patch) I'll be able to test it out and get some resolution on this issue, hopefully.
[06:14] <jmarsden> Actually it looks like livirt doe build-depend on autoconf and automake, so using them (via autogen or manually) during the build should work if you end up really needing them...
[06:15] <tbielawa> Hmmm
[06:16] <tbielawa> Policy (4.9) says the build target should "perform all the configuration and compilation of the package"
[06:16] <jmarsden> OK, first I'm building libvirt 1.6.1 from the source package to make sure *that* works for me, then I'll try your version.
[06:17] <jmarsden> tbielawa: RIght, so it can call autoreconf or whatever it needs to, to do that.
[06:18] <tbielawa> What' I'm getting at is that it doesn't do that nor document any required interactive pre-build actions. Is this something worth filing a bug and submitting patches for?
[06:20] <tbielawa> jmarsden: you meant 0.6.1, correct?
[06:20] <jmarsden> well... that depends; it the current unpatched version builds from source, then it does enough preparation for itself so there is no bug in it.
[06:21] <tbielawa> I was just thinking of a bug in the packaging, just a missed step, not upstream
[06:22] <jmarsden> But it's not a packaging bug if the package (as in the 0.6.1-0ubuntu5.1 package) does not need it... it would only be a bug in *your* new pacakage, if that one does need it... do you see what I mean?
[06:23] <jmarsden> And 0.6.1-0ubuntu5.1 builds for me just fine after apt-get source and then cd and debuild -us -uc, no special effort needed with autogen or anything.
[06:23] <jmarsden> Now to try your patched version...
[06:24] <tbielawa> I wonder why I couldn't get 0ubuntu5.1 to build even in a pbuilder.... that's confusing. i'll get a link to my patch in a jiffy
[06:24] <tbielawa> http://csee.wvu.edu/~tbielawa/fix-missing-qemu-img.patch
[06:25] <tbielawa> Thanks for confirming that the current packaged version compiles correctly
[06:27] <jmarsden> tbielawa: OK... I was going to get the patched version from bzr but need to set up the bzr launchpad stuff in the VM to do that, because lzr is braindead about requiring lp logins even for read access... grr...
[06:27] <tbielawa> that bazaar branch I linked is the official branch
[06:27] <tbielawa> it's what I was attempting to build. I was assuming it was == libvirt in -updates
[06:28] <tbielawa> when I apt-get source I am able to build without autogen. different behavior from the LP branch
[06:29] <jmarsden> well, looks like it may not be set up to be == libvirt in updates.  Some projects do expect you tpo run autogen when compiling from version control, but not when compiling from release tarballs.
[06:30] <tbielawa> what you're saying then follows exactly in line with policy. when packaged the interactive steps were taken care of
[06:30] <tbielawa> that was eye opening. I didn't know that before. :)
[06:34] <jmarsden> Right.  I don't know for sure that is how all or most or most Ubuntu etc projects do it, only that some I am a part of which are only very loosely linked to Ubuntu do it :)
[06:35] <jmarsden> Looks like your patch edits some autoconf created files, which is triggering the issues you are seeing.
[06:35] <jmarsden> Did that patch get created on a Jaunty machine or on some other distro with a different autoconf version?
[06:36] <tbielawa> The patch comes from here: http://www.redhat.com/archives/libvir-list/2009-May/msg00615.html most of it applied without rejection. I had to apply two hunks by hand.
[06:38] <jmarsden> Ah... there is some sort of autoconf/libtool intgration in the build process.  If I apt-get install libtool on the build host, it tries to fix things up and gets a lot further with the build...
[06:39] <siretart> MTecknology: yes, but i also *do* read email :-)
[06:41] <tbielawa> I'm going to try adding my patch to the quilt series and building from an apt-get source (0.6.1-0ubuntu5.1)
[06:41] <tbielawa> I've successfully built with my patch in the quilt series on a branch from -updates after running ./autogen
[06:42] <jmarsden> tbielawa: I think that will be easier than starting from the bzr tree, from what I have tried here.
[06:43] <tbielawa> jmarsden: I agree, I lost hours of my day attempting to do that before I tried autogen
[06:43] <jmarsden> :)  There may be some piece of bzr magic neither of us know that would take care of this... I just don't know.
[06:44] <jmarsden> At least you now have a new direction... which may waste a few more of your hours :)
[06:44] <tbielawa> I think it's about done actually.
[06:44] <tbielawa> Just need to do some testing.
[06:45] <jmarsden> Cool.  have fun... Glad to have (somewhat indirectly) helped :)
[06:45] <tbielawa> Maybe you could take a look at this too and tell me what I can do to get action taken on it: https://bugs.launchpad.net/ubuntu/+source/pbzip2/+bug/363793
[06:46] <tbielawa> I hate to see a patch not get acted on. That patch has been tested heavily in my work place. We're rolling out 14 GB compress virtual disk images to labs of machines with my fixed version
[06:50] <jmarsden> tbielawa: Well, that's only a patch, not a debdiff, so the next step for that bug would be to package the software with the patch, create a debdiff, upload the debdiff to the bug, etc etc.  See https://wiki.ubuntu.com/SponsorshipProcess
[06:51] <tbielawa> right on. I forgot about that part. You've been quite helpful. This should provide a few more hours of entertainment for me tonight :)
[06:51] <jmarsden> No problem :)
[07:18] <porthose> slangasek, ping, would you please have a look at bug #486157 :)
[07:32] <slangasek> porthose: hi - not tonight, but I've assigned it to myself to look at tomorrow
[07:33] <porthose> slangasek, ty :)
[08:02] <dholbach> good morning
[08:04] <persia> dholbach: The next MC meeting is moving to January?  I thought we were having one Friday first.
[08:04] <dholbach> hey persia
[08:04] <persia> Good morning :)
[08:04] <dholbach> persia: oops
[08:04] <dholbach> you're right
[08:05] <persia> And you're fast.  You fixed it before I had a chance to edit it :)
[08:05] <dholbach> restored
[08:06] <dholbach> I had it in firefox' awesomebar - most of the time I was waiting for moin to restore the old version :)
[08:22] <micahg> mr_pouit: here's a link to the changelog...I tried to match previous styles: http://launchpadlibrarian.net/36615770/xfce4-power-manager_0.8.4-1ubuntu1.1~karmic~ppa1_source.changes
[08:36] <nigel_nb> dholbach: how often does harvest get updated?
[08:36] <dholbach> nigel_nb: it could be that it's a bit broken at the momen - I really hope we can soon move to http://wiki.ubuntu.com/Harvest/NewUI
[08:36] <dholbach> nigel_nb: the new code will be much easier to maintain
[08:37] <dholbach> but I'll have a look and see what I can do
[08:37] <nigel_nb> dholbach: thank you :)
[08:37] <nigel_nb> just hunting for low hanging bugs
[08:37] <nigel_nb> but I just realized, most of them got plucked :P
[08:38] <dholbach> nigel_nb: there was a problem with its db, I'll rerun the script and everything, will let you know once it's down
[08:39] <nigel_nb> thanks again :)
[08:39] <dholbach> no worries
[09:00] <stochastic> can anyone point me to a waf build system package off the top of their heads?
[09:00] <stochastic> (i.e. one that uses waf to be built)
[09:03] <persia> gnome-format, kupfer, ejecter, and cgmail all look like likely candidates (reverse-build-depends is a lovely tool)
[09:03] <stochastic> thanks persia
[09:36] <dholbach> nigel_nb: done
[09:36] <dholbach> (was out for walking the dog in the meantime)
[12:20] <Quintasan|Szel> Hi there, I have sent my application to MOTU but the next meeting is Friday 7 UTC and it's impossible to for me to attend (school) would it be possible to move meeting to an later hour?
[12:22] <geser> Quintasan|Szel: which time would you suit?
[12:23] <Quintasan|Szel> hmm I'm in Poland, so hmm thant would be 14 UTC
[12:23] <Quintasan|Szel> or later
[12:32] <geser> dholbach: ^^?
[12:32] <dholbach> geser: sure, we can try to attempt an adhoc meeting if we get quorum together
[12:33] <soren> I'm much more likely to make 14 UTC than 7 UTC, FWIW.
[12:33] <dholbach> I'll be there at 14 utc anyway, I have a call two hours later iirc
[12:34] <geser> Quintasan|Szel: ^^ is that ok with you?
[12:35] <dholbach> so we'll try to get quorum together and see wha thappens
[12:36] <Quintasan|Szel> geser: okay
[12:38] <Quintasan|Szel> Thanks for postponing it :)
[12:39] <dholbach> Quintasan|Szel: we'll have the meeting at 7 anyway
[12:39] <dholbach> just do an additional one, if we get enough people together
[12:40] <Quintasan|Szel> dholbach: ah, so that's how it, anyways thanks :)
[12:40] <dholbach> no worries
[12:41] <soren> Err... How do I force bzr to push even though I have uncommitted changes?
[12:41] <soren> Ah, --no-strict
[12:55] <randomaction> there's a package (libjcalendar-java) for which the debian-ubuntu delta is a change of "Recommends: mozilla | www-browser" to "Recommends: www-browser". Can this be dropped?
[12:55] <randomaction> mozilla is a dummy package depending on seamonkey
[12:57] <randomaction> IMO having this alternative doesn't hurt
[13:01] <geser> on one hand it would prefer seamonkey to any other browser if none is installed, but this case is unlikely
[13:02] <geser> if we keep this delta it should be replaced with "firefox | www-browser"
[13:04] <randomaction> it was probably the intention of the packager anyway to install seamonkey in no browser is present
[13:07] <geser> yes, but Debian and Ubuntu might have different defaults
[13:09] <Laney> wouldn't it be best to fix mozilla then?
[13:11] <randomaction> the thing is, mozilla doesn't exist in Debian, so it's not default there
[14:46] <alkisg> While testing a debconf script, how can I select a different debconf frontend? (e.g. with an environment variable or something...)
[14:48] <alkisg> Ah, found it, $DEBIAN_FRONTEND :)
[14:48] <hyperair> man debconf has some interesting things as well
[14:51] <alkisg> I've read the man page, but I can't run my script with debconf in front, I don't know why
[14:51] <alkisg> It runs fine if I do: ./my-script though
[14:52] <alkisg> So I'm not able to put command line parameters to debconf...
[14:56]  * ScottK lol's at http://www.sirena.org.uk/log/2009/12/09/oh-dear/
[15:08] <persia> alkisg: Assuming you're testing a maintainer script, I find it easiest to repeatedly install, configure, uninstall, and purge the package with DEBCONF_DEBUG=developer and watching the syslog.  You can manipulate DEBCONF_FRONTEND for the shell that you're using to manipulate the package (which is also the shell in which you want to set DEBCONF_DEBUG)
[15:09] <bddebian> Heya gang
[15:10] <highvoltage> hey bddebian
[15:10] <alkisg> Thanks, `DEBIAN_FRONTEND=gnome DEBCONF_DEBUG=developer ./sch-client.config` is fine for me so far, I'll keep that in mind for later on :)
[15:10] <persia> Err, s/DEBCONF_FRONTEND/DEBIAN_FRONTEND/
[15:10] <bddebian> Hi highvoltage
[15:14] <geser> Hi bddebian
[15:14] <bddebian> Heya geser
[15:23] <sebner> huhu geser bddebian
[15:27] <bddebian> Heya sebner
[15:32] <mok0> ScottK: why is bug 400839 in the sponsor queue?
[15:33] <ScottK> mok0: I don't recall.  I believe I asked cemc to put it there rather than sponsor it myself so he could get wider exposure among the MOTU.
[15:33] <mok0> ScottK: so this is a request for testing the app?
[15:34] <mok0> ScottK: AFAICS you've already uploaded it
[15:35] <ScottK> mok0: You are correct.  I unsubscribed the sponsors.
[15:35] <ScottK> mok0: Normally fix release stuff stays subscribed since it doesn't show up in the default search.
[15:36] <mok0> ScottK: perhaps there should be a special queue for "please test" requests?
[15:36] <mok0> ScottK: everyone could help out there
[15:36] <MTecknology> Can you guys give me an opinion on how I could handle getting this into the repos without breaking any licensing? bug 120434 - I created the package but there's nothing to handle that in there.
[15:36] <ScottK> We used to have a policy of announcing Universe SRUs on ubuntu-motu ML.
[15:37] <randomaction> mok0: re bug 494384, I agree that the changes are really small, I sent them to Debian, but the package is orphaned so no idea when it'll be incorporated
[15:37] <mok0> ScottK: sure. But it's the sort of thing that other users could help doing
[15:37] <mok0> randomaction: ah
[15:37] <ScottK> mok0: I agree.  IIRC there are some resources for this on qa.ubuntuwire.com that could use wider visibility.
[15:37] <ScottK> randomaction: Talk to bddebian about getting them uploaded.
[15:38] <mok0> ScottK: There could be an LP team that everyone could join
[15:38] <bddebian> randomaction: What package?
[15:38] <ScottK> mok0: Perhaps.  I agree it's a problem.  I don't have a strong opinion on how best to solve it.
[15:38] <mok0> ScottK: alternatively, we should change the workflow so it's like the Unstable -> Testing repo
[15:39] <mok0> s/should/could
[15:39] <randomaction> bddebian: tix, our delta is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449786
[15:39] <bddebian> Hmm, I think I have a new upstream for tix but was having some problems :(
[15:39] <bddebian> Yeah I have an 8.4.3 package but I don't have all the patches merged in yet :(
[15:40] <bddebian> randomaction: Want to finish my work? :)
[15:41] <randomaction> bddebian: well, if I can
[15:43] <bddebian> http://people.debian.org/~bdefreese/tix/tix_8.4.3-1.dsc
[15:44] <randomaction> any pointers on what needs to be done?
[15:45] <mok0> ScottK: I testran gurlchecker and it failed my quality requirements.
[15:45] <bddebian> randomaction: I think all that needs done is checking/updating all of the patches
[15:45] <bddebian> From the current version
[15:45] <randomaction> I'll look into it
[15:46] <mok0> randomaction, bddebian, I just uploaded Tix 8.4.0-7ubuntu1, so there's no rush
[15:46] <ScottK> mok0: What happened?
[15:47] <mok0> ScottK: it crashed :-)
[15:47] <ScottK> cemc: ^^^
[15:47] <ScottK> That's not good.
[15:47] <randomaction> mok0: thanks, we're talking new upstream version
[15:47] <bddebian> mok0: Sure, I just hate leaving packages I started out there :(   :)
[15:48] <mok0> randomaction, bddebian, great, tix is an important package, hope it gets a maintainer
[15:48] <mok0> randomaction: what about tclx btw?
[15:48] <mok0> bddebian: ^^
[15:51] <mok0> ScottK: wait, let me be 100% certain I'm using the version in -proposed
[15:51] <bddebian> mok0: Feel free to maintain it! :)
[15:51] <mok0> bddebian: is it orphaned too?
[15:53] <Laney> hey bddebian
[15:53] <Laney> can you QA poke 521722?
[15:53] <nigel_nb> dholbach: thank you :) (was asleep :))
[15:53] <dholbach> :)
[15:54] <bddebian> mok0: I was talking about tix still
[15:54] <bddebian> Laney: Heya, let me take a look
[15:54] <Laney> ta
[15:54] <mok0> bddebian: ah :-)
[15:54] <mok0> bddebian: I have no personal interest in tix (anymore). But I know it's widely used
[15:58] <bddebian> Laney: Not much I can do about that one unfortunately since it has a maintainer that isn't MIA :(
[15:59] <Laney> guh
[15:59] <Laney> he has been active?
[15:59] <bddebian> Well only on ML, he hasn't uploaded since Oct 2008 :(
[15:59] <Laney> hmm
[16:02] <mok0> ScottK: Sorry I goofed up: https://bugs.edge.launchpad.net/ubuntu/+source/gurlchecker/+bug/400839/comments/11
[16:03] <mok0> BBL
[16:07] <bddebian> Laney: I'm asking around in the QA group.  Unfortunately since morph stepped down, I don't think too many people are doing MIA stuff. :(
[16:08] <Laney> bddebian: yeah, that was a bit sad :( It's quite important imo
[16:16] <alkisg> When are package.config scripts ran? "automatically" when I use dpkg-preconfigure, and also "automatically" when I source confmodule from my postinst?
[16:27] <randomaction> aha, Debian finally got gcc4.4 by default!
[16:36] <postalchris> Anybody free to look at http://revu.ubuntuwire.com/details.py?package=cvc3 ?
[16:51] <postalchris> Am I going about things the wrong way here? How am I supposed to move my package forward on REVU?
[16:53] <ScottK> postalchris: No, but there's just a lot more demand for MOTU to review stuff than there are MOTU to review it.
[16:53] <ScottK> postalchris: You might consider maintaining your package in Debian.  See mentors.debian.net for details.
[16:55] <postalchris> ScottK: That's understandable. I thought Ubuntu -> Debian was an easier path than Debian -> Ubuntu though
[16:55] <ScottK> postalchris: It varies.
[16:56] <ScottK> postalchris: Debian -> Ubuntu is automatic once it gets into Debian.
[16:57] <postalchris> ScottK: It looks like Debian has streamlined their process since the last time I looked.
[16:58] <postalchris> ScottK: It used to be "hang out on the mailing list and try to find a sponsor" right? (Which is kind of like "hang out on #ubuntu-motu and try to find a reviewer" now that I think about it ;-)
[17:01] <highvoltage> has there been any discussions at UDS or otherwise on Chromium and whether that would be included in universe for lucid?
[17:06] <ScottK> It will probably be in Main.
[18:57] <slangasek> porthose: ping
[21:20] <rjnienaber> is there any guidance for packaging a python program?
[21:20] <ScottK> rjnienaber: Yes.
[21:21] <ScottK> rjnienaber: That draft policy in http://lists.debian.org/debian-python/2009/12/msg00009.html is the best document available for Python specific packaging questions.
[21:21] <ScottK> That/The
[21:23] <rjnienaber> cool, i'll give it a read
[21:23] <POX> + /usr/share/doc/python-support/README.gz
[21:23] <rjnienaber> i assume there's no salient information in the diff part of that email?
[21:26] <dfarning> RainCT, Do you have time for some questions about packaging sugar for ubuntu?
[21:29] <ScottK> rjnienaber: No.
[21:30] <rjnienaber> cool, i'll skip over that section
[21:33] <RainCT> dfarning: In a while, I'm finishing some homework right now (unless it's short questions, then I can answer them now, or somebody else here may also be able to help).
[21:34] <RainCT> dfarning: I've got your e-mail, btw. I plan to send the Debian guy a mail to try to coordinate with him.
[21:37] <dfarning> RainCT, Ok thanks.  In the meantime I'll try to learn more about getting  abiword 2.8 into backports.
[21:41]  * RainCT wonders why packages.ubuntu.com is outdated by at least one week
[21:41] <RainCT> ah, abiword 2.8 hasn't build yet for any arch
[21:43]  * sebner is wondering why RainCT is wondering :P
[21:43] <dfarning> RainCT, we are carrying a hacked up version in our ppa at https://launchpad.net/~sugarteam/+archive/0.86/+packages
[21:43] <RainCT> sebner: I like that a lot, I wonder why you don't find wondering great :)
[21:44] <sebner> heh
[21:47] <porthose> slangasek, pong, sorry I was AFK, I agree with your comment and now understand what your looking for :)  I will make the needed changes, I don't have time right now, but I will jump on it later tonight ty :)
[21:55] <RainCT> dfarning: I'm not sure, but I think only stuff in newer Ubuntu releases can be backported, so you'd need to get it working in Lucid first.  (Someone please correct me if I'm wrong).
[21:59] <dfarning> RainCT, just figured that out:-/  I am looking for why libpsiconv-dev, an abiword dependancy, is failing to build in lucid.
[22:02] <geser> dfarning: it looks like libpsiconv-dev build correctly (both binaries and source are in sync)
[22:03] <geser> the problem is: abiword is main while libpsiconv-dev is in universe -> MIR is needed
[22:10] <dfarning> geser, RainCT I needed to look up MIR.  It looks like my next step is file an MIR ticket.
[22:10] <geser> !mir
[22:11] <dfarning> !mir
[22:11] <dfarning> cool
[22:16] <geser> dfarning: an alternative would be to check if abiword can be build without libpsiconv-dev
[22:46] <RainCT> dfarning: OK so what questions do you have?
[22:50] <RainCT> dfarning: (Won't stay long though, I've to wake up in 6 hours. But I'll be around tomorrow starting at 16h UTC+1)
[22:52] <dfarning> RainCT, The biggest question is should we base off of the Debain packages.
[22:54] <RainCT> dfarning: Yeah, I'd be great if we can do that.
[22:55] <dfarning> Ok, I'll try to build them in a ppa.
[22:57] <dfarning> RainCT, What about submitting inclusion request for Sugar- stuff, should we try to get all of the dependency like abiwrord done first, before we even worry about the sugar stuff?
[23:01] <RainCT> dfarning: Well, you can already start submitting those packages which already have all dependencies fulfilled. In any case, getting them into Ubuntu is likely to take some time (which is one of the reasons why working in Debian is better, if we find someone interested there it may be much faster).
[23:05] <dfarning> RainCT, Ok, I'll do a dependency graph.  I'll let you see if you can establish a relationship with the debian maintainer.
[23:06] <RainCT> dfarning: How many packages is the Sugar stuff? Those 30 in the PPA?
[23:08] <dfarning> RainCT, yes the packages starting with sugar in https://launchpad.net/~sugarteam/+archive/0.86
[23:09] <dfarning> RainCT, glucose, fructose, and platform are meta packages