[12:15] <pete_> sorry if people think I'm being over reactive about this.....
[12:15] <pete_> wont somebody please think of the children
[12:15] <pete_> hehehe
[12:16] <jdong> I side with pete_ on this one
[12:16] <jdong> I defintiely wouldn't want my younger siblings seeing this
[12:16] <jdong> and before today I'd have no problem recommending the Planet to a elementary school age audience
[12:16] <pete_> yup
[12:16] <pete_> my problem.....i already have people reading it
[12:17] <pete_> i feel ashamed to be honest
[12:17] <Burgundavia> look, you two have explained your issues
[12:17] <Burgundavia> it is off topic for this channel, so please take it elsewhere
[12:17] <jdong> right
[12:17] <pete_> sorry Burgundavia 
[12:17] <jdong> no use in continuing this
[12:17] <pete_> my only issue is that the post persists
[12:17] <pete_> I will talk no more about it here
[12:18] <ScottK> jdong: Back on topic... gnash feisty-backport FTBFS on ia64.  Any thoughts?
[12:18] <jdong> hmm
[12:19] <jdong> *looks*
[12:20] <jdong> ScottK: oh feisty shipped with broken xulrunner on ia64
[12:20] <jdong> ScottK: hence anything remotely mozilla-related won't go
[12:23] <ScottK> jdong: OK.  So does that mean don't backport such, backport it and oh well for ia64, or feisy ia64 xulrunner needs fixed?
[12:23] <jdong> ScottK: I wouldn't worry about it
[12:24] <jdong> ScottK: basically oh well for ia64
[12:24] <jdong> especially ince it doesn't mean any regression to the existing ia64 feisty
[12:24] <ScottK> OK.
[12:24] <ScottK> You're the boss.
[12:30] <koke> cbx33: hi, what's wrong with the planet post?
[12:30] <cbx33> koke, I find it rather, inappropriate
[12:31] <cbx33> I have sent young people to view planet......
[12:31] <koke> because of the image or the text? or both?
[12:31] <cbx33> the image mainly
[12:31] <cbx33> link to it please.....
[12:31] <cbx33> but don't embed it
[12:31] <cbx33> with a not saying that it's Not Safe for Work
[12:31] <cbx33> or Adult Content
[12:31] <koke> that may work
[12:31] <cbx33> or something ;)
[12:31] <cbx33> I'm not trying to stifle your free speech dude
[12:32] <cbx33> :)
[12:34] <koke> ok, fixe
[12:34] <koke> d
[12:35] <cbx33> dude you're a star
[12:35] <koke> still, I don't know how but in planet mysql they have some filter to show only mysql related posts
[12:35] <cbx33> wow
[12:35] <koke> but I don't think they're using planet as an agregator
[12:35] <cbx33> well, what do you use to blog?
[12:35] <koke> wordpress
[12:35] <cbx33> you can tag
[12:35] <cbx33> and then you can get a tag specific feed
[12:36] <cbx33> so you could tag posts as ubuntu
[12:36] <cbx33> and change the planet feed to pick up only ubuntu posts
[12:37] <koke> ok, going to bed, unwanted wedding tomorrow :)
[12:38] <koke> bye
[12:38] <cbx33> unwanted wedding??
[12:38] <cbx33> hehe
[12:38] <cbx33> thanks koke
[12:38] <koke> I don't even know them
[12:38] <cbx33> hehe
[12:43] <lucas> svn st
[12:43] <lucas> oops :)
[01:04] <geser> Hi persia
[01:04] <persia> hey geser
[01:05] <geser> I've tested the scons patch on PPA and the ardour build get a little bit further
[01:06] <persia> Do you have a build log?
[01:07] <geser> http://librarian.dogfood.launchpad.net/7771202/buildlog_ubuntu-gutsy-i386.ardour_1%3A2.0.2-2ubuntu2%7Eppa3_FAILEDTOBUILD.txt.gz
[01:07] <geser> it fails due to errors about flac
[01:08] <geser> I assume it unrelated to the scons change
[01:10] <persia> Hmmm.  It needs an extra B-D on libusb-dev, oddly reports it will install to /usr/local, and fails the flac transition.  I'd agree this is unrelatd to scons.  What did you do to fix it?
[01:11] <geser> I applied the patch from bug #87077 to scons
[01:11] <ubotu> Launchpad bug 87077 in scons "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,Confirmed]  https://launchpad.net/bugs/87077
[01:14] <persia> That appears to do it (and now I need to look at ardour again to fix it).  Will this move to the archives soon?  I think it will fix aqsis as well.
[01:15] <geser> I have uploaded now aqsis to my ppa to test it with the patched scons and if the build succeeds I'll prepare a debdiff for scons and look out for a sponsor
[01:17] <persia> geser: Does the debdiff in the patch not already work?  I suspect Daniel would sponsor with confirmation that it solves the problem.
[01:18] <geser> the debdiff needs one fix: the maintainer change
[01:18] <geser> and the proper syntax for automatic bug closing (but that's only minor)
[01:20] <persia> Ah.  RIght.  Minor things are important.  I'll look out for the new revision, and send a new ardour (that actually compiles) once complete.
[01:21] <TheMuso> Hey folks.
[01:22] <geser> Hi TheMuso
[01:22] <persia> Good day TheMuso
[01:22] <geser> TheMuso: the scons problem is nearly fixed, doing now the last testbuild
[01:22] <TheMuso> Nice.
[01:23] <TheMuso> Does this mean we have to patch the source packages to do stuff?
[01:23] <TheMuso> Or to set up stuff properly
[01:24] <geser> Only scons need patching to not import the current environment (till a proper fix is made upstream)
[01:25] <persia> Is that not the proper fix?  Would one actually wish to export the parent environment to the build under some circumstances?
[01:26] <geser> doesn't passing CFLAGS work that way?
[01:27] <geser> I don't know what other packages might need in the environment to build
[01:29] <persia> No, that's right, standard make also passes the environment.  Now I'm wondering why scons fails under this circumstance, and how one is supposed to pass compiler flags, but scons is deeper magic than I understand...
[01:31] <geser> scons passes the environment unfiltered and also this broken HASH() variable upon which dash stumbles
[01:31] <geser> I don't know if passing CFLAGS currently still works (probably not)
[01:33] <persia> Hmmm...    If we get a proper fix in before UVF, we probably want to rebuild these apps, as otherwise I'm not sure they'll have ideal behaviour.
[01:52] <StevenK> Heh, and overnight, everything bar sparc has caught up.
[01:52] <StevenK> Yay for the flood of uploads come unfreeze
[01:52] <TheMuso> Morning StevenK.
[01:54] <RAOF> Morning StevenK, TheMuso 
[01:54] <TheMuso> Hey RAOF.
[02:03] <StevenK> persia: Ping, re: bug 117094
[02:03] <ubotu> Launchpad bug 117094 in freqtweak "When launched from the menu, freqtweak silently fails" [Wishlist,Confirmed]  https://launchpad.net/bugs/117094
[02:04] <persia> geser: I've just tried a local build again (against flac 1.1.4-3ubuntu1), and it built fine.  I'll look into the buildlog in a bit more detail, but I think we're still seeing something scons related.
[02:05] <TheMuso> another sconz package.
[02:05] <TheMuso> Lovely
[02:05] <jdong> http://sharkattack.media.mit.edu/inventory/check_builds/25
[02:05] <jdong> iceape built.
[02:05] <jdong> ScottK: ^^ hey you think we want iceape? :)
[02:05] <persia> StevenK: Yep.  Can't fix that in Ubuntu: it requires jack to autosense and autostart when jack clients start.  Bart claims it's fixed in Debian, but I can reproduce (but am unhappy enough with the Debian freqtweak not to bother).
[02:06] <persia> TheMuso: Not a new one - still ardour
[02:07] <TheMuso> right
[02:08] <StevenK> persia: So it really isn't fixed in Debian?
[02:08] <geser> persia: ok, can you reproduce that build failure if you apply that patch to scons?
[02:09] <geser> persia: aqsis build successfully on PPA with the patched scons
[02:09] <persia> StevenK: It depends on how one looks at it.  If a user has previously configured Jack to do the right thing, or actually checks the console output or the manpage, and starts jack beforehand, everything works great.  If a user starts with an etch base install, installs freqtweak, and launches from the menu, there is no GUI response.
[02:10] <persia> geser: I'll give that a shot, and let you know.
[02:10] <persia> StevenK: For reference, this was originally found with the Ubuntu freqtweak (version numbers adjusted) against sid, although the current Debian freqtweak exhibits much the same behaviour.
[02:13] <TheMuso> persia: I wonder whether apps shouldn't give a GUI message about jack not running.
[02:13] <geser> persia: did you test with ardour 2.0.2 or already 2.0.3?
[02:14] <geser> I've still 2.0.2 in my PPA
[02:14] <persia> TheMuso: The argument from my freqtweak sponsor was that they should (and many do), hence me opening the bug.  The argument from the current freqtweak maintainer is that it cannot be reproduced, so it doesn't need a message.
[02:14] <persia> geser: 2.0.3
[02:15] <geser> ok, I will upload 2.0.3 to my PPA and see if it builds
[02:17] <StevenK> persia: Just because he can't reproduce it doesn't mean it isn't a bug.
[02:17] <TheMuso> right
[02:18] <persia> StevenK: I'd agree, but have found collaboration with this maintainer less than ideal, and would rather do other things.  It is a valid point that some of the 64studio work has come into Debian, and a properly configured jack environment will autostart, but such configuration is not the default for us. 
[02:19] <TheMuso> I might need to get another damn network switch.
[02:20] <TheMuso> One of mine decides to keep dying randomly.
[02:20] <TheMuso> And I have to unplug it, and plug it back in.
[02:20] <StevenK> persia: According to my Feisty machine, freqtweak is orphaned.
[02:21] <persia> StevenK: In feisty is was.  During the gutsy cycle, there was some competition for becoming the Debian maintainer (it suddenly became interesting, for some reason).
[02:23] <persia> geser: Yep.  The flac API change was fixed with 2.0.3 (and breaks with the old scons with 2.0.2).  Looks like it's just the scons patch to fix it.
[02:23] <persia> geser: Just to verify, does ardour 2.0.3-1 break on your PPA without the scons patch?
[02:23] <TheMuso> Actually... It could just be the cable between the two switches
[02:24] <StevenK> TheMuso: I prefer my setup, with one 16 port gige switch. :-)
[02:25] <TheMuso> StevenK: But they are probably not cheep.
[02:25] <StevenK> You're right, it wasn't.
[02:26] <TheMuso> Mind you, at least a 16 port 100 switch doesn't sound a bad idea.
[02:27] <StevenK> TheMuso: $300-$400 looks to be about it for 16 port Gigabit. 
[02:27] <TheMuso> Ouch.
[02:28] <StevenK> ~ $100 for 16 port 10/100.
[02:28] <TheMuso> I've only got 1 machine that can do Gig so its not worth it atm.
[02:29] <geser> persia: the normal builds of ardour failed, therefore they will also fail on PPA as the buildds are similar
[02:29] <harrisony> does anyone here use /debian/menu.ex
[02:29] <StevenK> debian/menu.ex is an example file
[02:29] <persia> geser: That would be my assumption, but I just wondered if the buildds were actually the same.
[02:30] <persia> harrisony: I've used it (when drafting debian/menu).  What about it?
[02:30] <StevenK> persia: They ought to be. The only difference I've noticed is the PPA buildds are Xen
[02:30] <geser> the first test with ardour (before the patched scons) failed at the same place as the official ones
[02:30] <harrisony> persia, how do i use it :P 
[02:30] <persia> geser: In that case, all is good.
[02:31] <harrisony> persia, is it only used to make .desktop for debian menu or does it make freedesktop or both
[02:32] <persia> harrisony: Copy it to debian/menu, and edit to make your menu file.  Reading the menu manual can help (in the menu package).  The file is put in /usr/share/menu, and generates the Debian menu (which can generate .desktop files using the menu-xdg package).
[02:32] <harrisony> thanks persia 
[02:43] <harrisony> persia, ok, i got menu and menu-xdg, how do i convert the debian to freedesktop
[02:43] <persia> harrisony: What are you trying to accomplish?
[02:44] <harrisony> persia, making a .desktop file that ubuntu can use
[02:45] <persia> harrisony: Ah.  Is there already a Debian menu file?  If not, it's easier to make both by hand.
[02:45] <harrisony> persia, i made a debian menu file
[02:47] <persia> harrisony: OK.  I'd recommend making a .desktop file by hand, using something in /usr/share/applications/ as a reference, and making sure it validates with desktop-file-validate.  If you really want, and you have menu-xdg installed, you can install your candidate package, and look at the .desktop file generated in /var/lib/menu-xdg/applications/menu-xdg, but this will require manual editing.
[02:48] <harrisony> ok thanks persia 
[02:58] <harrisony> ok say i get a package from Debian, and there is a patch for it and i want to do some ubuntu modifications on it. whats the best way of applying the debian patch on to the original and then doing some ubuntu on it
[03:00] <persia> harrisony: Is the package already modified in Ubuntu?  If so, process as a merge, and add your new changes.  If not, just modify the new Debian version for upload to Ubuntu.
[03:04] <StevenK> cmake does that
[03:04] <TheMuso> Right.
[03:06] <RAOF> Woo!  I shouldn't have been trying to fix xgl's make distclean.  I should just have tried using automake1.9 instead.
[03:06] <TheMuso> hahaha
[03:06] <TheMuso> There is automake 1.10 as well I think.
[03:07] <RAOF> Yes, I know.  That's our new default, and what fails
[03:07] <TheMuso> ah
[03:07] <TheMuso> Well sounds like a problem with Makefile.am/configure.ac files.
[03:07] <TheMuso> c
[03:07] <TheMuso> ugh
[03:08] <RAOF> Indeed.  There's a reason why we have 5 separate automake versions in the archives
[03:08] <TheMuso> True.
[03:09] <persia> RAOF: Really, we just need 1.4, 1.6, 1.9, and 1.10.  Things that work with 1.7 should work just as well with 1.6 or 1.9.
[03:11] <RAOF> persia: You obviously know more auto* than me :)
[03:13] <persia> RAOF: Unfortunately, my info is not up to date - apparently 1.6 is gone.  I don't know about the differences between 1.7 and 1.8 (I thought the big change was 1.6 -> 1.9, with 1.5 being buggy)
[03:33] <harrisony> i need to find some good packaging music to listen to 
[03:37] <nixternal> beethoven does it for me
[03:55] <harrisony> there should be the Ubuntu soundtrack with CC or GPL music on it
[04:27] <RAOF> Hm.  Should xserver-xgl's base version be 7.2 or the 1.1.99.1 that is the server version it's based on?
[04:33] <bryce> RAOF probably the latter
[04:34] <bryce> 7.2 is the old numbering scheme style, that xorg is moving away from
[04:35] <RAOF> Yeah, I'll follow the rest of xorg.  Should I match the epochs (the rest of xorg has an epoch of 3)?
[04:46] <bryce> 3?
[04:47] <bryce> from what I've seen the epochs are set rather randomly between 0-2 at the moment.  Haven't seen 3 yet so far.
[04:47] <RAOF> Heh.  I was looking at xserver-xorg-core, I believe
[04:48] <RAOF> I'll use the minimum necessary epoch of 1
[04:49] <bryce> that should be a good choice I think
[04:49] <bryce> -> dinner
[05:09] <Jazzva> Any reviewer who has a bit of spare time to look at http://revu.tauware.de/details.py?upid=6117 :)?
[05:10] <TheMuso> Will look in a bit.
[05:10] <Jazzva> TheMuso: Thanks :)...
[05:49] <harrisony> persia, you still arount
[05:54] <persia> harrisony: Yes, but distracted.
[05:55] <harrisony> lol, quick question i made my desktop file, were should i shove it and should i add anything to make CDBS install it
[05:56] <persia> harrisony: The .desktop file belongs in /usr/share/applications/, and you probably want to store it in debian/ and install it with debian/install (don't forget to add /usr/share/applications to debian/dirs).  Also, for that sort of question, you'll likely get a faster answer by asking the channel generally, rather than a specific person.
[05:57] <harrisony> hehe ok :P
[05:57] <harrisony> thx
[06:00] <RAOF> Would it be too much to ask for there to be a git revision of Xgl that builds against mesa 7.0?
[06:46] <StevenK> TheMuso: Hrm?
[06:46] <TheMuso> StevenK: A clueless person putting a package on revu.
[06:46] <StevenK> Ah
[06:47] <TheMuso> haha
[06:48] <persia> One might wonder if it would be appropriate to ask for multiple bugfix uploads prior to a REVU submission, but that may discourage some.
[06:50] <TheMuso> One also might wonder whether its worth putting desktop-file-validate support into linda...
[06:50] <TheMuso> Mind you, package submitters need to use lintian/linda in the first bloody place.
[06:51] <StevenK> TheMuso: Patches welcome.
[06:51] <persia> That'd be a possibly annoying extra dependency, but would certainly improve the quality of .desktop files.
[06:51] <TheMuso> StevenK: I know. I may take a look actually.
[06:55] <TheMuso> I am now in two minds about whether I continue to review.
[06:55] <TheMuso> i.e look at more packages in the future.
[06:55] <persia> TheMuso: Consider updating some of the documents that lead people to submit.  I've listed my recommendations in MOTU/Contributing, but there are lots of other pointers to REVU.
[06:56] <persia> Separately, if you decide not to REVU now, please consider doing so at least during REVU days :)
[06:57] <TheMuso> persia: Yeah I know. The thing is, do people even read the docs? Its all well and good to have them, but if they aren't being read...
[06:58] <persia> TheMuso: I'm really not so sure anymore.  I wrote a few, and edited some others, and received general agreement that things were good, yet don't see as many results as I'd like.
[07:06] <TheMuso> hehe
[08:35] <Hobbsee> TheMuso: oh *dear*.  discouraged from REVU'ing already, hey?
[08:49] <Hobbsee> heya white!
[08:51] <Hobbsee> heya tuxmaniac 
[09:16] <harrisony> anyone around
[09:20] <white> harrisony: always :)
[09:21] <harrisony> white, do you know much about packaging plugins for stuff?
[09:21] <white> harrisony: i don't know about a lot about packaging, just hanging around here a bit
[09:22] <white> and neither do i know how to proofread a sentence :(
[09:22] <harrisony> ahh
[09:22] <white> harrisony: i recommend that you ask specific questions, if you need any help
[09:24] <harrisony> hehe
[09:30] <tupa> hey, I hope this is the developer corner?
[09:31] <tupa> flashplugin-nonfree does not install because of a md5sum mismatch
[09:31] <tupa> I searched the downloaded package install_flash_player_9_linux.tar.gz, and installed the plugin with it, but sure it's not doable by a newcomer
[09:32] <tupa> should I file this somewhere, or can you fix it?
[09:32] <TheMuso> tupa: I would check to see if a similar bug has already been filed against the package in Launchpad.
[09:33] <TheMuso> https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree
[09:34] <DarkMageZ> tupa, there's a fixed version in the -preposed section.
[09:37] <StevenK> tupa: So to help along the process, test the fixed version in feisty-proposed.
[09:39] <tupa> Okey dokey
[09:41] <StevenK> tupa: There is also a bug around that would have led to the update in -proposed. If you comment saying whether it worked or not, that will also help.
[09:42] <StevenK> tupa: Once an update in -proposed has recieved enough testing, it gets promoted from -proposed to -updates.
[09:43] <tupa> excuse me, what is feisty-proposed for?, I'm a newcomer to Ubuntu, but familiar with linux and apt
[09:43] <StevenK> feisty-proposed is for testing updates to see that they behave, fix the problem and don't cause regressions.
[09:49] <StevenK> joejaxx: You need to regenerate the upload stats page. :-)
[09:58] <joejaxx> StevenK: yeah i am doing that now
[09:59] <joejaxx> StevenK: i need to fix it because i broke its cronjob setup
[09:59] <abelli> hi there
[09:59] <enyc> meep moop
[10:00] <abelli> problem: how do i use the rtai-package?
[10:01] <StevenK> joejaxx: Cool. I don't mean to pressure or bug you. :-)
[10:02] <joejaxx> ok
[10:02] <joejaxx> all updated :)
[10:04] <StevenK> Awww, I dropped to 5th.
[10:05] <abelli> let's try again: who has packaged rtai?
[10:10] <joejaxx> abelli: apt-cache show rtai-source | grep Maintainer
[10:11] <abelli> you're doing just the sync from debian?
[10:11] <abelli> no one in here has tested it?
[10:12] <abelli> joejaxx: ^^
[10:12] <abelli> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[10:12] <abelli> Original-Maintainer: Edelhard Becker <edelhard@debian.org>
[10:13] <abelli> ..
[10:17] <minghua> abelli: Yes, it's just synced from Debian and not necessarily tested.
[10:17] <minghua> abelli: You are welcome to help testing and maintaining it though.
[10:18] <abelli> minghua: by now im installing it by hand ...
[10:19] <abelli> minghua: I'm going to try to setup a metapackage to install a complete rtai-comedi system, it's going to be hard .. but in the end i'll be obliged to test that package.
[10:23] <minghua> abelli: Help testing, reporting bugs, improve packaging, any kind of help is appreciated.
[11:04] <Q-FUNK> morning!
[11:05] <Q-FUNK> any other opinions about http://revu.tauware.de/details.py?upid=6120 ?
[11:14] <geser> persia: ardour 2.0.3 build successfully in my PPA
[11:14] <persia> geser: Cool!  So we just need the scons patch up, and xmms2, aqsis, and ardour given-back?
[11:15] <geser> yes, except xmms2 as xmms2 doesn't use scons anymore
[11:15] <persia> geser: Even better :)
[11:16] <RAOF> Q-FUNK: I'm not a motu, but an my initial sweep says "why aren't you using a patch system?"
[11:19] <geser> persia: but linuxdcpp can be added to the list of give-backs (that would also close bug #78111)
[11:19] <ubotu> Launchpad bug 78111 in linuxdcpp "[Sync Request]  Include linuxdcpp from Debian in Ubuntu" [Undecided,New]  https://launchpad.net/bugs/78111
[11:23] <joejaxx> geser: what timezone are you in? :P
[11:24] <joejaxx> persia: :P that you all are still up :P
[11:25] <persia> joejaxx: It's a circular thing.  geser and I are about 7 hours apart :)
[11:25] <joejaxx> lol
[11:26] <joejaxx> :P
[11:27] <geser> joejaxx: CEST (GMT + 2)
[11:27] <joejaxx> ah ok :)
[11:27] <joejaxx> i am EST (GMT-5)
[12:28] <Q-FUNK> RAOF: because I'm wondering if overhauling the whole upstream make system might be simpler than patching it.
[12:30] <persia> Q-FUNK: Either way, it shouldn't affect the decision of patch system vs. no patch system.  Patch systems are nice because it allows one to easily extract individual patches when feeding upstream, so that they can be dropped with the next release.  Not having a patch system is nice because grep and friends make checking for security problems easier.
[12:31] <Q-FUNK> yup
[12:31] <Q-FUNK> it's a 50/50 situation
[12:32] <Q-FUNK> but really, this package probably has the crappiest autotool implementation I've ever seen.
[12:50] <zorglu_> q. there is a bug in ffmpeg shipped by gutsy, and which is no more in svn (aka ffmpeg unable to handle flv file if they are coming from http, but handle it ok from disk), is it still time to update the gutsy package ?
[12:50] <persia> zorglu_: Yes (until UVF).
[12:50] <zorglu_> UVF=?
[12:50] <coNP> zorglu_: I guess you can either wait for next release (if it is planned to happen before UVF) or apply a patch from SVN
[12:51] <persia> zorglu_: Upstream Version Freeze.  See https://wiki.ubuntu.com/GutsyReleaseSchedule
[12:52] <persia> Actually, that's a good point.  If upstream isn't planning a release soon, pulling the patch may be worthwhile (although I think it's better to wait for upstream until release is imminent)
[12:56] <zorglu_> ok i will fill a bug
[12:58] <zorglu_> hmm launchpad doesnt support to report bug on ffmpeg :) https://bugs.launchpad.net/ffmpeg/+filebug
[12:58] <zorglu_> and ffmpeg is use 'mailling list' as bugtracker :)
[12:59] <zorglu_> ok im a moron and should read the screen :)
[12:59] <coNP> zorglu_: you can file a bug for ffmpeg source package in ubuntu 
[01:00] <zorglu_> coNP: yep this is what i discovered only after i read the screen :)
[01:00] <coNP> zorglu_: https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+filebug
[01:00] <coNP> okay, sorry zorglu_ :)
[01:03] <minghua> persia: Come on, it's ffmpeg.  They haven't had a release in years.
[01:04] <minghua> Although I doubt a bug without a patch would help much.
[01:04] <persia> minghua: Sshhh.  You're exposing my ignorance :)
[01:06] <coNP> filing a bug is good to level your lp karma
[01:06] <coNP> creating a patch is good to fix a bug
[01:06] <RAOF> Heh.  I watch the ffmpeg devel list for some reason, and they're vhermantly anti-release.  They'll have one, as long as it doesn't affect them in any way :)
[01:07] <persia> antirelease?  I'm confused by that.  Perhaps they should go for quarterly snapshots?
[01:08] <coNP> we seem to have a cvs snapshot in gutsy btw
[01:09] <minghua> Wasn't comments on ffmpeg's attitude towards release all over various Planets a few days ago?
[01:10] <minghua> I suspect we have cvs snapshots in gutsy, feisty, edgy, all the way to dapper and before.
[01:10] <coNP> minghua: sure
[01:10] <coNP> all of them seems to originate from debian, though
[01:11] <minghua> We have 1:0.4.9-pre1-0.2 in warty though.  Nice surprise. :-)
[01:11] <zorglu_> minghua: the bug is no more in the current cvs of ffmpeg. to get rid of it in gutsy require to only update the gutsy package
[01:11] <zorglu_> https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/127349 <- the bug i filled about it
[01:11] <ubotu> Launchpad bug 127349 in ffmpeg "flv succeed from file, fails from http" [Undecided,New]  
[01:12] <persia> zorglu_: Updates may work (still better to wait for Debian, even if there won't be a release), but a small patch is easier to apply, if it's important in gutsy now.
[01:13] <zorglu_> persia: i dont understand. currently ffmpeg in gutsy is a cvs snapshot, why not take a more recent snapshot ? i mean which patch are you talking about ?
[01:13] <RAOF> persia: Anti-release, as in they (1) Don't want to "slow down development" by having to do release work and (2) Don't want to *have* a release without work being done to support it
[01:13] <coNP> zorglu_: the problem with a package update is that current CVS might contain many more serious bugs...
[01:14] <coNP> this flv issue is quite a light one
[01:14] <zorglu_> coNP: ah ok
[01:14] <persia> RAOF: Ah.  That makes sense.  Odd, but at least comprehensible.
[01:14] <zorglu_> coNP: well it is big for me :)))
[01:14] <zorglu_> but i understtand :)
[01:14] <RAOF> And will *undoubtedly* contain regressions, and will almost certainly break anything depending on ffmpeg
[01:14] <coNP> sounds cool
[01:14] <coNP> :)
[01:14] <minghua> I see that ffmpeg builds dynamic libraries now.
[01:15] <RAOF> Yeah.  Debian's got fed up with *every* project using ffmpeg having it's own static snapshot.
[01:15] <minghua> So I STRONGLY suggest nobody attempting to upload a new cvs snapshot without asking around (the media team?) and make sure he/she knows what he/she is doing.
[01:16] <minghua> Otherwise you risk breaking all multimedia packages.
[01:18] <minghua> RAOF: Yeah, I heard those discussions.  I didn't know it already happened.
[01:19] <minghua> There are probably still packages not using the ffmpeg dynamic libraries but their own private copy though, I suppose.
[01:19] <RAOF> Undoubtedly.  They change API every so often, so many packages probably *can't* use the dynamic libs
[01:35] <Kmos> someone who uses kopete can check this one..
[01:35] <Kmos> bug 46657
[01:35] <ubotu> Launchpad bug 46657 in kdenetwork "Kopete gives error when you're on your own contact list" [Medium,Incomplete]  https://launchpad.net/bugs/46657
[02:10] <RAOF> Hey Hobbsee
[02:11] <RAOF> Xgl is almost bent to my will!
[02:11] <DarkSun88> Hi all
[02:11] <Hobbsee> heya RAOF!
[02:11] <TheMuso> Hey RAOF.
[02:11] <RAOF> Hi TheMuso :)
[02:12] <DarkSun88> TheMuso: Thank you for upload. :)
[02:13] <TheMuso> DarkSun88: No problem.
[02:13] <DarkSun88> :)
[02:40] <porthose> Hello MOTU's:  Could you please comment/first advocate Ampache thank you.  http://revu.tauware.de/details.py?upid=6125
[02:40] <Hobbsee> !sourceomatic
[02:40] <ubotu> source-o-matic is a webpage where you can (re)generate your sources.list - http://www.ubuntu-nl.org/source-o-matic
[02:42] <imtheface> ,
[03:01] <RAOF> Is there any particlar reason I shouldn't merge Azureus tomorrow sometime?
[03:02] <Hobbsee> RAOF: you have some shred of sanity remaining?
[03:02] <StevenK> Yeah. It's Azureus
[03:02] <Hobbsee> oh wait, you just did democracy player.  you like crack.
[03:02] <StevenK> It isn't called Democracy Player any more. :-P
[03:02] <RAOF> A nice change of pace.  Swapping Python crack for Java crack
[03:02] <TheMuso> haha
[03:02] <TheMuso> RAOF: Have fun.
[03:03] <Hobbsee> StevenK: whatever it is now
[03:03] <TheMuso> RAOF: You will enjoy dragging one of us into reviewing it however.
[03:03] <RAOF> Indeed, it's Miro, and the debian maintainer's gonna have a package any day now :)
[03:03] <Hobbsee> TheMuso: is volunteering
[03:03] <RAOF> Heh!
[03:04] <TheMuso> I never said such thing.
[03:04] <Hobbsee> [23:03]  <TheMuso> RAOF: You will enjoy dragging one of us into reviewing it however.
[03:04] <Hobbsee> you're that one.
[03:05] <StevenK> RAOF: Hah
[03:05] <TheMuso> Hobbsee: ahem.
[03:05] <Hobbsee> TheMuso: consider yourself voluntold, by She Who Must Be Obeyed.
[03:05] <TheMuso> *cough*
[03:06] <Hobbsee> persia: that might come next
[03:06] <Hobbsee> TheMuso: no dying.
[03:06] <TheMuso> I would rather not be the one who ends up loosing their sanity thanks.
[03:06] <Hobbsee> sure you would!
[03:06] <Hobbsee> you mentioned the sponsoring...
[03:07] <TheMuso> Yes, but I didn't say I would be the one who would.
[03:07] <TheMuso> I was hoping it would make some others around here cringe a little. :p
[03:07] <RAOF> Yes! Drive the core-dev insane!
[03:08] <StevenK> Hobbsee doesn't do the work. She just tells us to do it.
[03:08] <TheMuso> RAOF: Thanks for the support.
[03:08] <Hobbsee> StevenK: exactly.  it's called delegation.
[03:09] <TheMuso> Well its obvious Fujitsu doesn't want it.
[03:09] <Hobbsee> RAOF: there are 2 talking...
[03:10] <StevenK> I could be co-erced to do one, being there are only three of them.
[03:10] <Hobbsee> StevenK: good man.  then you can have the satisfaction of yada out of main.
[03:10] <StevenK> Hobbsee: I'm about to run off, tell me one to do via privmsg, and add it to my list of stuff to do when I get home.
[03:11] <RAOF> Excellent!  xsession-xgl-gnome now actually has files in it.  Strangely, it takes longer to grab-merge azureus than it does to build xgl.
[03:11] <Hobbsee> StevenK: heh :)
[03:11] <StevenK> I have a better idea. I'll do a merge of yada that renames the binary package to 'complete-piece-of-crap' and then yada can be killed since it's NBS.
[03:12] <TheMuso> Who wants to bet on who reviews RAOF's nerge.
[03:12] <StevenK> Which?
[03:13] <TheMuso> oooops
[03:13] <TheMuso> *merg
[03:13] <StevenK> Heh, I see it
[03:13] <RAOF> "nerge".  It sounds vaguly perverted
[03:13] <TheMuso> *merge
[03:13] <TheMuso> ugh
[03:13] <StevenK> Hah
[03:13] <Hobbsee> StevenK: haha
[03:13] <Hobbsee> it seems that RAOF has a dirty mind here...
[03:14] <RAOF> "Perverted" wasn't quite the word I was after, it was just close enough :P
[03:15] <TheMuso> Must be a sign that I should crash.
[03:16] <RAOF> Oh, bother.  Azureus was a repack, so every file and it's dog is in the mom-generated patches.  Ug
[03:16] <TheMuso> ooooooooooooooooooooahhhhhhhhhhhhh
[03:18] <RAOF> Also, I'm going to have to write like a hundred man pages for xgl.
[03:18] <TheMuso> RAOF: Why are you working on XGL?
[03:19] <TheMuso> Is it not already packaged?
[03:19] <RAOF> It ftbfs
[03:19] <RAOF> Care of the new Mesa we've got
[03:19] <TheMuso> ah
[03:19] <RAOF> Also, I want to ship some xsession files, so people don't have to manually write them
[03:20] <TheMuso> ah
[03:20] <RAOF> Interestingly, there is *no* git revision of xgl which builds against our mesa.
[03:20] <RAOF> And the current Xgl package doesn't ship any man pages.  Naughty
[03:21] <TheMuso> fun.
[03:22] <Hobbsee> jdong: must have made it
[03:23] <RAOF> Well, he removed the existing man page (which was conflicting with xserver-xorg-core's page).
[03:25] <persia> Isn't that what dpkg-divert is intended to address?
[03:26] <RAOF> Yes.  But diverting is wrong in that case anyway.  I think the manpage Xgl ships with is the same as the Xorg one.
[03:27] <persia> RAOF: Now I'm confused.  I thought there was supposed to be a one-to-one mapping between the executable namespace and the manpage namespace.  If there is a manual page conflict, is there not a binary conflict?  If the packages conflict, yet take the same arguments, options, etc., should not the same manpage be shipped in two places?
[03:30] <RAOF> persia: No.  The xgl source builds the same man page as normal a normal Xorg server (because it's a branch and no-one has bothered changing it, I suppose).
[03:31] <persia> RAOF: For a different executable name?  Hmmm..  That's probably leftovers, but it still doesn't sit well.
[03:32] <RAOF> Hm.  Actually, xserver-xorg-core doesn't have a 1:1 mapping - it ships a bunch of binaries, but it seems only one man page (Xserver, which doesn't correspond to a binary at all)
[03:34] <persia> RAOF: In that case, it's an informational manpage (and the others are missing, or there should be lots of symlinks).  For these, I'd argue it's still appropriate to include them multiply if the core packages conflict (or otherwise would never be installed in parallel).  The alternative is to have one package depend on the other to ensure that the manpage is available.
[03:35] <RAOF> persia: xgl depends on -core, which contains that manpage.
[03:35] <persia> RAOF: Right.  Nevermind then :)
[03:36] <RAOF> Xgl (currently) doesn't work without an underlying X server anyway :)
[03:37] <RAOF> Anyway, that's a night for me.  Testing is for the morning!
[03:44] <jussi01> persia: hello!
[03:44] <persia> jussi01: Hello
[03:46] <jussi01> persia: you notice mnemosyne is sitting in new? :)
[03:46] <persia> jussi01: Yep.  Thanks for investigating the source.  One hopes memaid can go away soon
[03:46] <jussi01> persia: yep.. :)
[03:51] <jussi01> persia: I was worried about it for ages, but in the end, it was quite simple.
[03:52] <jussi01> wow, nuber 13 in the queue. yay!
[03:55] <tuxmaniac> whats fabian rodrigues nick/
[03:55] <tuxmaniac> ?
[03:55] <tuxmaniac> aah ok magicfab
[04:26] <tuxcrafter> hello guys why is the spamassassin version of ubuntu 3.17 while the stable on the spamassassin webstite is 3.2.1
[04:27] <Hobbsee> spamassassin | 3.2.1-1ubuntu1 | gutsy/universe | source, all
[04:27] <Hobbsee> spamassassin | 3.2.1-1ubuntu1~feisty1 | feisty-backports/universe | source, all
[04:27] <Hobbsee> probably because 3.17 was the last version released, before feisty feature freeze
[04:28] <ScottK> 3.2.0 was released after Feisty was released.
[04:28] <StevenK> Which is a good reason to not include it.
[04:30] <ScottK> Yes.
[04:31] <ScottK> I asked for the backport and I've been monitoring it.  There've been no bugs filed that definitely relate to upgrading to 3.2/3.2.1.  There was one pyzor bug that may or may not (I'm guessing not) be related.
[05:02] <ScottK> Any thoughts of if we should apply the patch in Bug #127389?
[05:02] <ubotu> Launchpad bug 127389 in pdftk "pdftk enforces lame pseudo-drm" [Undecided,New]  https://launchpad.net/bugs/127389
[05:10] <persia> ScottK: I'd call that an upstream decision.  It's trivial to extract from a PDF with other tools, but there are perhaps deployment use cases where someone would prefer the honoring of that flag.
[05:12] <ScottK> Maybe you would comment on the bug then (if you haven't).
[05:12] <persia> ScottK: Sure.  It's mine :)
[05:13] <ScottK> Yours?
[05:14] <persia> ScottK: The bug.
[05:15] <ScottK> As in you'll deal with it?  Sorry, still on the first cup of coffee here.
[05:17] <persia> ScottK: Yes.  Annoyingly, there's not an upstream bugtracker I can find, but http://www.lagotzki.de/pdftk/index.html#FAQ clearly states that there was thought behind the decision to honor the flag.
[05:18] <ScottK> K.  Thanks.
[05:19] <sacater> has gutsy's apt problems been fixed?
[05:19] <persia> Now if I could only find the equivalent in English...
[05:19] <Hobbsee> yes
[05:21] <sacater> Hobbsee: great, so is gutsy stable enough for me to use safely
[05:22] <Hobbsee> sacater: depends on the day
[05:22] <peanutb> LOL. this is starting to sound like another project I have heard about
[05:22] <sacater> Hobbsee: i suppose
[05:23] <peanutb> and acknowlages that he found a headset
[05:23] <sacater> ah
[05:23] <sacater> peanutb: skype?
[05:23] <peanutb> shure 1 sec
[05:24] <StevenK> There isn't really
[05:25] <ScottK> OK.  Then I feel better not being able to find it.
[05:25] <StevenK> low is the usual, medium if it fixes an important bug, high if it's an RC bug, and emergency if the sky is falling
[05:25] <Nightrose> persia: need someone to translate from german? or was that just asking for a link?
[05:26] <StevenK> The only thing that the urgency is used for is how soon is the package considered for demotion to testing.
[05:26] <tuxcrafter> ScottK: oke so with gusty we get the newest version again?
[05:26] <ScottK> StevenK: OK.  I've a package that failed a periodic rebuild in SID and the bug's marked RC, so High then?
[05:26] <StevenK> ScottK: Did the last version hit testing?
[05:26] <shriphani> hello.
[05:26] <ScottK> Yes
[05:26] <ScottK> tuxcrafter: Newest as of today.  I can't promise what'll happen between upstream version freeze and release.
[05:26] <shriphani> volunteers wanted ?
[05:26] <persia> Nightrose: A link in English would be nice.  I'd rather point to someone else's thoughts as to why it should be implemented as reasoning to not fix it, and German isn't appropriate for LP.
[05:26] <StevenK> ScottK: I'd suggest medium. high if you wish
[05:26] <tuxcrafter> ScottK: newest version of spamassassin because it know says SpamAssassin 3.1.7-deb (2006-10-05 ) and that looks old
[05:27] <ScottK> StevenK: Thanks.
[05:27] <Q-FUNK> ScottK: RC bugs are high, annoyances that are not catastrophic or RC bugs whose fixes might be worse than the bug medium, everything else is low.
[05:27] <ScottK> tuxcrafter: If you want the newest version use feisty-backports.  
[05:28] <StevenK> Meh. I think I've used a urgency that isn't low about four times
[05:28] <ScottK> tuxcrafter: What I'm saying is that today, Gutsy has the latest, but if spamassassin releases a newer version after our freeze, Gutsy won't have it.
[05:29] <ScottK> Since there's a built/functional .deb for testing and we are nowhere near releasing Lenny, it seems there's no great rush.
[05:29] <persia> shriphani: Yes.  See the topic for links/
[05:30] <Nightrose> persia: ah ok it states at the top that it's only a translation of an english version of the helptext of pdftk though I can't find the english version right now
[05:31] <persia> Nightrose: That was my problem too :)  I'm especially interested in the FAQ section, as I believe that pdfcrack is the recommended solution by the tkpdf team, but I'd like a verifiable reference :)
[05:31] <persia> s/tkpdf/pdftk/
[05:31] <Q-FUNK> ubuntu needs a volatile repo
[05:31] <Nightrose> ah ok ;-) - will google a little persia
[05:31] <persia> Q-FUNK: backports
[05:31] <Q-FUNK> persia: ah yes, close enough
[05:32] <persia> Nightrose: OK.  If you're chasing this, would you mark bug 127389 "Won't Fix" with the link when you find it?
[05:32] <ubotu> Launchpad bug 127389 in pdftk "pdftk enforces lame pseudo-drm" [Undecided,New]  https://launchpad.net/bugs/127389
[05:32] <Nightrose> persia: will do but son't expect to much ;-)
[05:33] <persia> Nightrose: OK.  Thanks.  I'll put in something generic in a while if you don't find it.
[05:36] <persia> I see a libode0debian1 installing in gutsy.  Did we have a plan for the libode transition, or are we just following Debian (and need to merge/sync all the updates)?
[05:36] <shriphani> persia: i volunteer.
[05:37] <persia> shriphani: Great.  Thanks.  Did you pick a bug to start yet?
[05:37] <shriphani> not et.
[05:38] <persia> shriphani: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize is probably a good list to start from.
[05:38] <shriphani> okay.
[05:39] <geser> persia: looks like we follow Debian
[05:40] <persia> geser: OK.  Thanks.  I think Steve is already on some of it, but I'll follow that.
[05:41] <StevenK> The libode transition is done
[05:41] <StevenK> I finished it over five hours ago
[05:41] <Nightrose> persia: reading the FAQ again i'd say they don't recommend  pdfcrack - they rather state that there is such a programm but it's useless since you can alter the pdf anyway if you know the password
[05:41] <StevenK> It was a whole four packages
[05:41] <Nightrose> but I will try to find a english version anyway
[05:42] <persia> StevenK: It's the indirect dependencies that are annoying: xmoto, slune, etc.
[05:43] <geser> Nightrose: on that page I can only find that the help text (pdftk --help) got translated to german but not that the page is translated from english to german
[05:43] <persia> Nightrose: I'd agree with your gloss, but would argue that it's evidence that the pdftk team doesn't want to ignore the password by default.
[05:43] <Nightrose> persia: yea right
[05:43] <Nightrose> geser: hmm you might be right
[05:44] <StevenK> persia: xmoto has a direct dependancy. slune I wasn't aware of.
[05:44] <persia> StevenK: No worries.  slune has other issues (python-psycho)
[05:45] <StevenK> Hah, yeah, well.
[05:45] <persia> StevenK: Anyway, that's why we have a few months of integration time left - eventually things get caught by unmetdeps processing even when direct rdepends doesn't work :)
[05:47] <Q-FUNK> Sid Vicious
[05:48] <StevenK> persia: Right. :-)
[05:49] <ScottK> Q-FUNK: Wrong Sid.
[05:50] <Q-FUNK> naa. sid _is_ vicious.  he broke all the toys.
[05:50] <Nightrose> persia: /me gives up - I think geser is right and there is no english version of the FAQ
[05:51] <persia> Nightrose: No worries.  Thanks for looking.
[05:51] <Nightrose> yw
[06:28] <AndyP> http://revu.tauware.de/details.py?upid=6127 new gmusicbrowser candidate, i submitted a comment with more info
[07:14] <ScottK> doko: Why is python-profiler in multiverse?  Looking at the license, http://changelogs.ubuntu.com/changelogs/pool/multiverse/p/python-profiler/python-profiler_2.4.4-3/python-profiler.copyright - I don't understand what's wrong with Universe?
[07:18] <AndyP> ScottK: here's your answer http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293932
[07:18] <ubotu> Debian bug 293932 in python "profile.py has non-free license" [Serious,Fixed]  
[07:23] <ScottK> AndyP: Thanks.  That was it.
[07:24] <ScottK> doko: Nevermind.
[07:48] <man-di> wasabi: hello
[07:48] <man-di> wasabi: not seen for a long time
[07:50] <Jazzva> Umm, if I have a source file that does the make clean and I need to compile it and run from rules, can I do something like this?
[07:50] <Jazzva> gcc -o $(CURDIR)/cbuild $(CURDIR)/cbuild.c
[07:50] <Jazzva> ./cbuild.c clean
[07:50] <Jazzva> rm $(CURDIR)/cbuild
[07:53] <man-di> hello Zic
[07:53] <man-di> Zic: you uploaded jedit to REVU?
[07:55] <Zic> yeah, long time ago, I just come back of my holidays
[07:56] <Zic> and iirc, upload is wrong
[07:56] <man-di> Zic: when you have time, I would like ro through the package with you
[07:56] <man-di> there are several issues in ti
[07:56] <Zic> man-di: ok, np
[07:56] <Zic> yes, I know :(
[07:56] <man-di> and I cant comment on REVU
[07:57] <man-di> Zic: or do you want to fix the issues you know already first?
[07:59] <Zic> man-di: I can't tonight, but if you can, send me an e-mail to zic AT ff-irc DOT net
[07:59] <Zic> I 'revu' myself tomorrow
[08:00] <Zic> with your help, if you are here ;)
[08:00] <man-di> I'm here (just sometimes afk)
[08:00] <man-di> just ping me when you updated the package
[08:00] <DarkSun88> Hi
[08:00] <Zic> let me "re-learn" azerty keyboard first xD
[08:01] <Zic> (I'm just returning of my holidays at Palma, remixed qwerty keyboard of Spanish is baaad :))
[08:01] <man-di> Zic: hehe
[08:01] <man-di> Zic: take your time
[08:01] <man-di> DarkSun88: hi
[08:02] <DarkSun88> man-di: Hi :)
[08:02] <Zic> I'm here all of August anyway
[08:02] <Zic> :)
[08:02] <Zic> first month, real holidays, second moth, geek holidays
[08:06] <DarkSun88> In August I will go to Praga, maybe.
[08:17] <davromaniak> hi everybody
[08:18] <davromaniak> I've just uploaded kitsune to REVU, if anybody of the MOTU team can review it when he will have some time, it would be great, thx : http://revu.tauware.de/details.py?upid=6128
[08:20] <coNP> what happened to the ubuntu wiki?
[08:20] <coNP> is it so slow only for me?
[08:21] <Jazzva> coNP: It doesn't work here, too...
[08:21] <ScottK> coNP: Launchpad is down entirely right now, so they may be having data center problems.
[08:21] <coNP> yes, I also noticed that
[08:21] <coNP> thanks ScottK 
[08:23] <davromaniak> argl
[08:27] <davromaniak> apparently, it's a problem with the database
[08:27] <ScottK> LP is coming back up now.
[08:46] <Seveas> imbrandon, prod 
[09:52] <geem> those bastards
[10:05] <Q-FUNK> ubunut:  what?  they killed kenny?  again?
[10:33] <jdong> !ftp
[10:33] <ubunut> ftp://meklort.isa-geek.com user:star + pass:star
[10:33] <ubotu> FTP clients: !Nautilus, !gFTP (for !GNOME) - !Konqueror, !Kasablanca, !KFTPGrabber (for !KDE) - See also !FTPd
[10:33] <jdong> the fsck...
[10:33] <jdong> !ops
[10:33] <ubotu> Help! Hobbsee, Riddell, sladen, or fbond
[11:06] <norsetto> package http://revu.tauware.de/details.py?upid=6130 is looking for a sponsor :-)
[11:30] <zul> afternoon