[00:00] <nhandler> bcurtiswx: paste.ubuntu.com
[00:00] <bcurtiswx> ok, brb
[00:00] <nhandler> It is just a site to upload large ammounts of text
[00:02] <bcurtiswx> oh firefox, why must you freeze
[00:03] <ScottK> That's a bit of a redundant question.
[00:04] <maxb> At least you're not IRCing in Chatzilla :-)
[00:04]  * nhandler is using mibbit in Firefox ;)
[00:05] <bcurtiswx> lol
[00:06] <bcurtiswx> http://paste.ubuntu.com/130404/
[00:06] <bcurtiswx> finally
[00:06] <bcurtiswx> lol
[00:10] <nhandler> bcurtiswx: Why are you packaging it from scratch? We already have octave in the repositories. Why not just do an upgrade?
[00:10] <bcurtiswx> nhandler: is more of a learning process for me
[00:10] <bcurtiswx> nhandler: octave was the first tar.gz file that came to mind
[00:14] <nhandler> bcurtiswx: If you really want to get it to work, you can look at the octave package in the repositories. Otherwise, I would suggest you choose a simpler package as a "learning process"
[00:14] <nhandler> octave isn't the best to begin with
[00:15] <bcurtiswx> nhandler: ok.  any recommendations?
[00:16] <nhandler> bcurtiswx: Have you followed the guides to package 'hello' already?
[00:16] <bcurtiswx> nope
[00:16] <nhandler> bcurtiswx: I would start there. There are some guides on the wiki, do you want a link or two?
[00:16] <directhex> james_w, so. what do you think is the right course of action for monodevelop-debugger-gdb?
[00:17] <james_w> directhex: now the alpha is out you can poke the archive admins to ask who rejected it
[00:17] <bcurtiswx> nhandler: sure
[00:18] <directhex> james_w, which day of the week was it rejected?
[00:18] <james_w> can't remember
[00:18] <james_w> doesn't help that I'm upside down right now
[00:18] <nhandler> bcurtiswx: https://wiki.ubuntu.com/PackagingGuide/HandsOn
[00:18] <StevenK> That must make it hard to type
[00:18] <nhandler> bcurtiswx: http://www.debian.org/doc/debian-policy/
[00:19] <directhex> StevenK, that or he's in australia for some reason
[00:19] <nhandler> bcurtiswx: https://wiki.ubuntu.com/PackagingGuide/Complete
[00:19] <StevenK> I'm in Australia, and I'm not upside down ...
[00:19] <nhandler> bcurtiswx: Those should help get you started. If you need more, just ask ;)
[00:19] <directhex> yes you are! australia is upside-down by definition!
[00:19] <ajmitch> directhex: lies
[00:20] <bcurtiswx> nhandler: ty
[00:20] <cody-somerville> nhandler, how is gnomescan going?
[00:21] <nhandler> cody-somerville: I'm looking it over again now.
[00:22] <cody-somerville> nhandler, thanks. I think its pretty important to get that done for jaunty. Let me know if you need me to assist.
[00:22] <nhandler> cody-somerville: I'll add my comment sometime tonight
[00:32] <tacone> ot: anyone can tell me how to mark a launchpad bug as duplicate ?
[00:32] <tacone> nevermind, found -.-
[02:25] <savvas> do we bump the standards-version for non-debian packages?
[02:29] <nhandler> savvas: If you are making other changes to the package, yes.
[02:30] <savvas> yes nhandler :) gpixpod I'm about to send a patch for python transition
[02:38] <nhandler> savvas: Be sure to make sure that it actually complies with that version of debian-policy. You can also verify that it is lintian clean.
[02:38] <savvas> ok thanks nhandler :)
[02:39] <savvas> Now running lintian...
[02:39] <savvas> Finished running lintian.
[02:39] <savvas> woohoo! :P
[04:15] <fmarier> hi folks, I was wondering if I should be providing any more details here given that the sync I'm proposing is pretty much just a bugfix one: https://bugs.launchpad.net/ubuntu/+source/email-reminder/+bug/342095
[04:17] <ScottK> fmarier: The problem is that for a sync, confirmed == approved, so odds are sponsors weren't looking at it.  I set it to new.
[04:18] <fmarier> ScottK: thanks for letting me know, I didn't know about that...
[04:19] <ajmitch> fmarier: looks like a rather critical update, with ruining marriages & all
[04:19] <superm1> siretart, have you talked with ffmpeg upstream about their commitment to a release schedule?  If they can get some sort of regular cadence going, we can try to get more pressure on these projects to move to using a system library of ffmpeg rather than duplicating the code in their trees (eg VLC, mplayer, xine, mythtv, etc)
[04:19] <fmarier> ajmitch: yeah, I forgot to change the importance while I was filing the bug :(
[04:26] <dtchen> superm1: such an approach has been strongly suggested for several years
[04:26] <dtchen> superm1: leverage corporate pressure would probably make them more amenable
[04:27] <dtchen> leveraging*
[04:31] <superm1> dtchen, yeah, unfortunately a lot of these projects get caught up in "their way of doing things", but definitely seeing a track record develop for the ffmpeg guys will make it easier to apply said pressure
[04:32] <superm1> my own reasoning is I want to see all of these great players leave multiverse and still be functional with ffmpeg-debian or an ffmpeg-multiverse - whatever the user chooses to install
[04:42] <Amaranth> superm1: still need that mplayer release
[04:42] <superm1> Amaranth, ehm? bug #?
[04:42] <Amaranth> superm1: Aren't they the same guys?
[04:43] <Amaranth> They haven't released mplayer in years either
[04:43] <Amaranth> after an mplayer release the only things missing will be duke nukem forever and working audio on linux
[04:43]  * Amaranth hides from dtchen
[04:44] <superm1> Amaranth, you mean a duke nukem forever port to linux that works with pulseaudio by default :P
[04:44] <Amaranth> and nouveau
[04:46] <superm1> Amaranth, oh but there was an RC like a year ago for mplayer. that's some kind of release at least.  it's better than mplayer-1.0~$(random snapshot)
[04:47] <Amaranth> superm1: I thought the last RC was in 2005
[04:47] <superm1> Amaranth, have i been working with ubuntu long enough now that my time scale is off by that much? geez...
[04:48] <Amaranth> superm1: ah, 2007
[04:48] <superm1> Amaranth, no i'm not crazy.  2007-10-07 1.0-rc2
[04:48] <superm1> phew
[04:48] <Amaranth> that wasn't last year :P
[04:48] <superm1> oh yeah, it's 2009. psh
[04:50] <StevenK> Haha
[04:50] <StevenK> "2009? When did that happen?"
[05:09] <fabrice_sp> Hi. How can I know at what time is the motu council for mi? In http://fridge.ubuntu.com/calendar, it's at 6H GMT (so 7H for mi) but in the wiki, it's at 7H UTC (8h for mi)
[05:09] <fabrice_sp> (and I woke up earlier, believing it was at 6h for mi :-/ )
[05:16] <dholbach> good morning
[05:16] <fabrice_sp> Morning dholbach ;-)
[05:18] <dholbach> hey fabrice_sp
[05:21] <fabrice_sp> dholbach, it's also 6:18 for you, right? so at what time is the Motu council meeting? I've not been able to find any consistent information on that
[05:22] <dholbach> https://wiki.ubuntu.com/MOTU/Council/Meeting - no? :)
[05:23] <fabrice_sp> yes: it's 7H UTC, but in  http://fridge.ubuntu.com/calendar, it's  at 6H GMT :-/  And I'm supposed to be at UTC/GMT+1
[05:24] <dholbach> fabrice_sp: oh yes, sorry - seems that Google Calendar got confused when the US moved to DST
[05:25] <fabrice_sp> ok :-)
[05:26] <rgreening> dholbach: hey
[05:26] <dholbach> hiya rgreening :)
[05:26] <rgreening> is the meeting in 30 min ?
[05:27] <fabrice_sp> or in 1h30? ;-)
[05:27] <dholbach> 7 UTC - let's stick to UTC times wherever we have them
[05:29] <rgreening> its 3AM here.. was hoping to get some sleep before work :)
[05:30] <fabrice_sp> ouch!
[05:30] <rgreening> hehe
[05:52] <rgreening> hey NCommander
[05:52] <NCommander> hey rgreening!
[06:05] <fmarier> dholbach: thanks for the ACK
[06:05] <dholbach> fmarier: no worries :)
[06:05] <dholbach> fmarier: thanks for letting us know about it!
[06:06] <dholbach> can somebody of the motu-release team check out bug 340008 please? :)
[06:08] <siretart> morning folks!
[06:08] <fabrice_sp> g'morning siretart
[06:08] <siretart> superm1: this release is more an experiment, a review about that is pending.
[06:09] <siretart> superm1: AFAIUI Diego prefers the next release in 3 or 6 months. and a time based release model
[06:10] <siretart> superm1: as for other projects, at least vlc and xine already use the system ffmpeg. No idea what mythtv does, but for mplayer that's complicated, as mplayer uses too many libavutil internals and therefore requires that the system ffmpeg matches the internal copy
[06:10] <siretart> superm1: diego is working on that, however
[06:10] <siretart> hey fabrice_sp
[06:11] <fabrice_sp> o/
[06:15] <superm1> siretart, ah didnt realize that vlc and xine are already using system ffmpeg.
[06:15] <superm1> siretart, i'll have a pretty good argument finally for mythtv upstream then provided we really do see releases every 3 or 6 months for ffmpeg
[06:16] <superm1> siretart, which if they can sever that tie, can finally get mythtv in debian :)
[06:17] <siretart> superm1: do they use lots of ffmpeg interals, or do they restrict themselves to the external API?
[06:17] <superm1> siretart, they support some demuxers that aren't actually in ffmpeg entirely, but otherwise i want to say for the most part they are using the external API
[06:18] <superm1> i'm going to have a chat with the guy who does the ffmpeg merges into mythtv on a regular basis to get a more clear understanding
[06:19] <siretart> superm1: 2 things to check: they include only headers that are installed in /usr/include/libav* and they don't use any ff_* symbols but only av_* ones.
[06:19] <siretart> superm1: if yes, then you can (and probably should) patch the build system to use the system ffmpeg
[06:19] <siretart> if no, hit upstream with a stick (or better)
[06:20] <siretart> exception from that rule: it does really funny stuff like gst-ffmpeg (which I still haven't really understand yet)
[06:20] <superm1> siretart, well until they can at least get the extra demuxers into upstream ffmpeg, i suspect that using a system ffmpeg will not turn out well.  i'll poke around though for those 2 things you indicated to get a better idea
[06:21] <siretart> oh, wait, they've added demuxers to libavformat?!
[06:21] <superm1> i'm not sure where the demuxers are living, let me see what the quote i just read about it was
[06:21] <superm1> "<iamlindoro> superm1, My understanding (and a little bit of experience in hacking on it) is that the Program Stream and Transport Stream demuxers differ substantially from ffmpeg's own at this point, making using it as an outside lib very very hard"
[06:21] <siretart> that's.. unusual. if that's right, that stuff should definitly go upstream
[06:22] <superm1> yeah that's what i was saying to him, but i'm waiting to hear from the guy normally doing ffmpeg merges to  confirm
[06:23] <siretart> perhaps it might make sense from them to not use ffmpeg directly but use libxine as abstraction. but that might be even more work
[06:23] <NCommander> siretart, and superm1, to add more fun w/ ffmpeg, upstream actually did a stable release :-)
[06:23] <siretart> NCommander: tell news
[06:23] <NCommander> siretart, you didn't see the news?
[06:24] <siretart> NCommander: see bug #340303
[06:24] <NCommander> ah
[06:24] <siretart> ;)
[06:24] <NCommander> siretart, so how did hell freeze over? (what made ffmpeg's devs do a stable release?)
[06:25] <siretart> that's more an experiment than a real stable release.
[06:25] <siretart> read: they don't really support it, and its already outdated
[06:26] <NCommander> siretart, its two days old ...
[06:26] <siretart> the release is from 03/03/2009
[06:26] <siretart> that's over a week
[06:26] <siretart> libswscale can now be compiled as lgpl
[06:27] <siretart> in trunk (not in 0.5 release)
[06:27] <NCommander> o_o;
[06:27] <NCommander> things move fast ...
[06:27] <siretart> that's the problem with ffmpeg releases
[06:27] <siretart> trunk moves that fast (since years) that releases actually don't really make sense
[06:27] <NCommander> siretart, I get it, but it makes downstreams lives harder
[06:28] <siretart> diego decided to make time based snapshot releases. let's see if and how the next one will work out
[06:28] <siretart> NCommander: you now understand why mplayer svn has svn:externals to the ffmpeg svn (and vice-versa, to make the matter more spicy)?
[06:29] <siretart> did I mention at some point that I'd really appreciate help on packaging the two beasts? ;-)
[06:29] <NCommander> siretart, add to the legal status of ffmpeg, and its an entire mountian of fun.
[06:29] <siretart> the legal status is: LGPL, with some (optional) GPL bits
[06:29] <NCommander> siretart, w.r.t. to patents
[06:29] <NCommander> siretart, I'm packaging cross-compilers with newlib being built in a single pass ;-). I know hellish packages.
[06:29] <siretart> superm1: you did most of the works in ubuntus mplayer, right?
[06:32] <siretart> superm1: I've just uploaded http://wiki.tauware.de/~siretart/upload-queue/mplayer_1.0~rc2%2bsvn20090303-1.dsc to debian/unstable (possibly *very* close to the rc3 release)
[06:33] <siretart> superm1: perhaps we can (and should) merge that package to ubuntu as well, checkout the branch on git.debian.org
[06:33] <superm1> siretart, i did a lot of work on it at some point i recall
[06:34] <superm1> siretart, i'm not sure who has kept up with it as of late though
[06:38] <superm1> siretart, git.debian.org? I thought that we were keeping it in bzr in ubuntu though.
[06:38] <superm1> siretart, is there a reason that it cant just be synced from unstable?  i'm assuming it's something related to extra build-depends that we add?
[06:39] <siretart> superm1: 2 reasons: ubuntu started an epoch war, and the debian package does not feature mencoder
[06:39] <siretart> the latter can be fixed by using the 'master.unstripped' branch (as opposed the 'master' branch)
[06:40] <siretart> re git, well pkg-multimedia (the debian multimedia team) settled on using git
[06:40] <superm1> siretart, <shrug> i see
[06:40] <siretart> I'd really appreciate more ubuntu help in pkg-multimedia *hint* *wave*.. we already have there a bounch of ubuntu branches
[06:41] <superm1> i wish i had more time to contribute up that way :( maybe later this year
[06:42] <superm1> jdong, do you want to maybe try to help spearhead pulling in another mplayer snapshot before we close up jaunty?  You like crack dontcha?
[07:02] <iulian> dholbach: Commented.
[07:03] <dholbach> iulian: thanks a bunch
[07:04] <iulian> dholbach: Np.
[07:14] <AnAnt> Hello, I am maintaining sl-modem package. Regarding bug 518694, the co-maintainer suggested that we blacklist slamr, slusb, intel-8x0m & snd_via82xx_modem modules so that they don't get loaded too early during, then the init script will modprobe slamr (or slusb) , is that an acceptable solution ?
[07:15] <AnAnt> debian bug 518694
[07:15] <AnAnt> ubottu: ;)
[07:16] <soren> AnAnt: Why does the time at which they're loaded matter?
[07:18] <AnAnt> soren: well, there's what he said in README.Debian http://pastebin.com/m5ee2d615
[07:19] <soren> AnAnt: Sounds like something that should really be fixed in the kernel.
[07:20] <soren> AnAnt: Failing that, could sl-modem's init script perhaps try rmmod/modprobing the modules? That saves us from having to blacklist stuff.
[07:21] <AnAnt> soren: ok, will try that
[07:21] <AnAnt> ok, another question, I want to create devices for slamr & slusb in postinst, but lintian says I should use MAKEDEV instead of mknod
[07:22] <AnAnt> when I run MAKEDEV slamr, it says that it doesn't know how to create devices for slamr
[07:22] <AnAnt> should I first modprobe slamr before attempting MAKEDEV ?
[07:22] <AnAnt> or what ?
[07:24] <geser> AnAnt: you probably need to get MAKEDEV patched for it
[07:25] <geser> do you need "static" devices? isn't udev created devices enough?
[07:26] <AnAnt> geser: you suggest that I add udev rules to create those devices ?
[07:27] <savvas> the manuals and documentation should be in Recommends or Suggests?
[07:27] <geser> AnAnt: yes
[07:27] <AnAnt> geser: dunno how to do this
[07:29] <geser> AnAnt: look at the existing rules.d files
[07:29] <AnAnt> geser: like this => KERNEL=="slamr", NAME="%k", GROUP="dialout", MODE="0660" ?
[07:30] <geser> AnAnt: I've to look up the syntax myself, but yes, something like that
[07:34] <AnAnt> so, KERNEL= is for loaded module name ?
[07:58] <soren> AnAnt: No, it's for the name the kernel assigns the device.
[07:58] <AnAnt> so, I should use DRIVERS= instead ?
[08:02] <soren> Umm.. Why?
[08:05] <slytherin> hi, anyone having trouble with pull-debian-source in jaunty latest? It asks me to install devscripts which I alreasy have installed.
[08:06] <AnAnt> umm, nevermind, I think it should be KERNEL="slamr[0-9]"
[08:06] <AnAnt> KERNEL="slamr[0-9]*" rather
[08:24] <iulian> slytherin: You might want to talk to nhandler.  He wrote that.
[08:26] <Toadstool> good morning here
[08:49] <dholbach> Toadstool: that was bound to happen on a Friday 13th :-)
[08:53] <Toadstool> dholbach: hehe :)
[08:53] <Toadstool> today is not my lucky day, I guess, I should have stayed in bed
[09:16] <savvas> when I subscribe u-u-s, should I change the "In progress" status to confirmed or new? or just leave it as it is?
[09:24] <iulian> savvas: Confirmed is better.
[09:26] <savvas> iulian: ok, I'll browse through the old ones and set them back to confirmed - thanks :)
[09:27] <savvas> I mean.. the old ones I have assigned on myself heh
[09:27] <iulian> You're welcome.
[09:27] <iulian> Later.
[09:37] <savvas> hot patch right from the oven :P bug 342151 for python transition
[09:56] <sistpoty|work> hi folks
[10:35] <_ruben> i must be blind, but i cant seem to find the variable that i can use in debian/rules which holds the version of the package its building
[10:43] <slytherin> _ruben: you need upstream version or complete version (including debian/ubuntu revision)?
[10:44] <slytherin> _ruben: DEB_UPSTREAM_VERSION should work. I am not sure as I have only used it in CDBS packaging.
[10:48] <_ruben> slytherin: that var doesnt seem to be avail for non-cdbs
[10:51] <slytherin> _ruben: it is actually easy to retrieve version form changelog. you need some head/cut magic. you should find it in many existing packages
[10:55] <_ruben> just found this is a mail archive: dpkg-parsechangelog  | grep ^Version: | cut -f 2 -d \  | cut -f 1 -d -
[11:16] <savvas> if the version is 0.36-5build1, for an ubuntu change I should use 0.36-5build1ubuntu1, right? :)
[11:17] <soren> Probably just 0.36-5ubuntu1.
[11:34] <slytherin> savvas: just ubuntu1
[12:32]  * slytherin wonders if this will make into jaunty - http://www.hadess.net/2009/03/our-new-volume-feature.html
[12:35] <directhex> i could have done with that last week
[12:37] <ripps> I'm trying to build multiple packages from a single source by using the debian/package_name.install method, but the build process fails at the very end, can someone please help me figure this out.
[12:38] <slytherin> ripps: sure, if you tell us what the error is
[12:38] <maxb> ripps: If you pastebin the build log, then yes
[12:39] <ripps> maxb: where does pbuilder store it's build logs?
[12:40] <maxb> uhm. Just copy/paste it from your terminal
[12:40] <slytherin> ripps: it doesn't by default, you have to use option '--logfile filename'
[12:41] <ripps> sigh, I guess I'll have to retry the build. It's a chore though, because it tends to segfault half way through sometimes.
[12:47] <maxb> nice build :-)
[13:27] <ripps> maxb, slytherin: can just give you a tarball with the source package w/ debian directory. My computer is being a jerk and randomly failing.
[13:31] <ripps> maxb, slytherin: http://depositfiles.com/files/7gu4sr9qo
[14:01] <maxb> ripps: Sorry, I don't have time to get a package building right now, you'll need to manage a buildlog yourself.
[15:57] <ripps> maxb: New version of gcc fixed my segfault issue, logfile: http://paste.ubuntu.com/130665/
[15:57] <ripps> It's very long, and it seems to run ./configure on all 20 plugins twice.
[16:02] <maxb> ripps: At the bottom, you can see it runs "
[16:02] <maxb> dh_install -pgmpc-alarm
[16:02] <maxb> and that fails to find a file
[16:02] <maxb> So, you need to investigate why that file does not exist
[16:03] <ripps> maxb: Yeah, how do I do that? Everything seems to be working right.
[16:03] <maxb> Well, the first thing to look for is: Did a file of that name get built at all? Did it get installed in a different directory?
[16:04] <ripps> libtool: install: /usr/bin/install -c .libs/alarmplugin.lai /tmp/buildd/gmpc-plugins-0.18.0/debian/tmp//usr/local/lib/gmpc/plugins//alarmplugin.la
[16:04] <maxb> No package should be installing into /usr/local
[16:04] <ripps> ? it installed it in /usr/local/
[16:04] <ripps> Hmm....
[16:04] <ripps> let me edit the autogen.sh
[16:05] <joaopinto> erm, you shouldnt edit autogen.sh
[16:05] <joaopinto> you should use the --prefix parameter on configure
[16:06] <ripps> This autogen.sh is actually a bash script that clones a bunch of programs from git and runs autogen.sh on them individually.
[16:06] <ripps> Don't blame me, I didn't write it.
[16:11] <ripps> I'm only using this script because I don't want to have to manually update 20 individual plugins (w/ backports) on biweekly basis.
[16:11] <ripps> This way, I can update all the plugins the team ppa with a single source package.
[16:30] <maxb> That still doesn't explain why you'd be editing autogen.sh for this problem?
[16:32] <ripps> maxb: because I don't think the autogen.sh being passed throught he bash script is adding --prefix=/usr.
[16:36] <maxb> autogen.sh is the wrong time to be doing this. It should happen at configure time
[16:38] <maxb> Oh, but gmpc-alarm's autogen.sh doesn't respect NOCONFIGURE. Blech
[16:45] <ripps> I'm going to have to continue this later, I need to go to bed.
[17:08] <DBO> does anyone know how to reach Laney by email?
[17:08] <jpds> He's... here?
[17:09] <jpds> and lp.net/~laney has email details.
[17:09] <DBO> thank you
[17:09] <DBO> hes away =P
[17:56] <savvas> good evening :)
[18:27] <slytherin> savvas: good evening. :-)
[18:46] <joaopinto> hi
[18:46] <joaopinto> dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
[18:46] <joaopinto> is there a way to force dpkg-buildpackage to not set LDFLAGS ?
[18:47] <slytherin> joaopinto: dpkg-buildpackage does not set them. check your debian/rules
[18:47] <joaopinto> slytherin, include /usr/share/cdbs/1/rules/debhelper.mk
[18:48] <slytherin> joaopinto: what about this line?
[18:48] <joaopinto> rewording, to tell CDBS not to touch LDFLAGS :P
[18:48] <joaopinto> slytherin, that line alone causes the LDFLAGS to be set
[18:48] <slytherin> joaopinto: I guess you will have to explicitely unset then in debian/rules
[18:49] <joaopinto> slytherin, already tried that, it introduces another problem, because it overrides LFLAGS during the "make" rule
[18:49] <joaopinto> erm LDFLAGs
[18:49] <slytherin> so what are you exactly trying to do?
[18:50] <joaopinto> I am building a package for an application, using cdbs, the application must not be compiled with "-Wl,-Bsymbolic-functions"
[18:51] <joaopinto> it provides a plugin component, such component does set LDFLAGS on it's make rules, however unseting LDFLAGS on debian/riles will override the plugin build phase also
[18:53] <joaopinto> slytherin, I am reading dpkg-buildpackage man page, it seems those are really defaults from it
[18:53] <slytherin> joaopinto: I don't think I am qualified enough to answer that question.
[18:54] <c_korn> does someone know when mok0 usually comes online?
[18:54] <joaopinto> well, it may be related to bug 138981
[18:55] <slytherin> c_korn: I believe he is there in #ubuntu+1
[18:56] <c_korn> slytherin: no, he isn't. didn't see him online for some time. it is just about uploading sivp to the jaunty queue. it has been acked.
[18:57] <slytherin> c_korn: is it in universe?
[18:57] <joaopinto> hum, this is really a dpkg-buildpackage problem :\
[18:57] <slytherin> c_korn: if uploading is the only thing to be done, I can do that, tell me bug number.
[18:59] <c_korn> slytherin: the package to be uploaded is here http://revu.ubuntuwire.com/p/sivp bug 334362
[19:02] <slytherin> c_korn: I will have to update my chroot. :-( If it is not uploaded within next 24 hours, I will do it.
[19:03] <c_korn> slytherin: thanks
[19:07] <rgreening> hey nixternal
[19:12] <fabrice_sp> rgreening, congrats :-)
[19:12] <rgreening> ty fabrice_sp. gratz to you too :)
[19:13] <fabrice_sp> thanks ;-) And sorry to rush  that way this morning
[19:13] <fabrice_sp> I really had to leave
[19:15] <rgreening> fabrice_sp: yeah. I really had to sleep :)
[19:15] <rgreening> I forgot about DST.
[19:16] <fabrice_sp> lol
[19:16] <rgreening> thought it was for 3:30 localtime, but it was 4:30. I could have went to sleep and got up early.. oops :P
[19:16] <rgreening> oh well, at least I crawled into bed at 5 and slept for a few hours
[19:17] <fabrice_sp> that's what I did (wake up early), but it wasn't that early :-D
[19:17] <rgreening> im a zombie now though.
[19:17] <fabrice_sp> only few minutes?!
[19:17] <fabrice_sp> yeah: I can understand :-)
[19:17] <rgreening> tonight, lots of sleep
[19:19] <rgreening> hmm... quassel crash... hehe
[19:20] <fabrice_sp> rgreening, you should be using gnome >:-)
[19:20] <rgreening> hehe
[19:21] <fabrice_sp> already sponsored your first package?
[19:21] <rgreening> I actually just installed ubuntustudio on my other laptop. it runs gnome
[19:22] <rgreening> not yet. I think I'll be waiting until I have sleep behind me
[19:22] <rgreening> clear head and all required to sponsor.
[19:22] <fabrice_sp> ohh: good :-) I have to install it in a vm, to check the software they ship
[19:22] <rgreening> :P
[19:22] <fabrice_sp> sounds reasonable, yes :-)
[19:22] <rgreening> ubuntustudio seems pretty nice.
[19:24] <rgreening> ScottK-desktop: ty for everything btw
[19:25]  * fabrice_sp is downloading the iso of ubuntustudio
[19:35] <cjwatson> joaopinto: have you tried 'unexport LDFLAGS' at the top of debian/rules? that's the usual workaround for packages that have a problem with -Wl,-Bsymbolic-functions, and is done elsewhere
[19:35] <fabrice_sp> when changing a version to add build1, do we have to update the maintainer field to Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>?
[19:36] <ScottK> rgreening: YW.
[19:36] <ScottK> fabrice_sp: No.
[19:36] <rgreening> ScottK: :)
[19:37] <fabrice_sp> thanks ScottK
[19:37] <fabrice_sp> just wanted to confirm
[19:40] <rgreening> o/ apachelogger
[19:40] <apachelogger> \o rgreening
[19:47] <joaopinto> cjwatson, I did, it didn't work, so I used LDFLAGS=""
[19:47] <joaopinto> which works for the binary, but breaks the plugin
[21:07] <DBO> can anyone help me update our PPA?
[21:07] <DBO> I am not a packager or anything
[21:07] <DBO> but our packager guy is away for a week
[21:07] <DBO> and we need to ship
[21:08] <dtchen> ppa url and new source url?
[21:08] <DBO> https://launchpad.net/~do-core/+archive/ppa
[21:08] <DBO> http://edge.launchpad.net/do/0.8/0.8.1/+download/gnome-do-0.8.1.tar.gz
[21:09] <DBO> and
[21:09] <DBO> http://edge.launchpad.net/do-plugins/0.8/0.8.1/+download/gnome-do-plugins-0.8.1.tar.gz
[21:11] <dtchen> DBO: i presume 9.04 is highest priority, but if you would delineate a decreasing priority, that would be helpful for scheduling
[21:12] <DBO> 8.10 vs 9.04 equal priority
[21:12] <DBO> most of our users are still on 8.10
[21:12] <dtchen> DBO: also, is 0.8.1 slated *only* for your ppa for 9.04, or is there a FeatureFreezeException planned?
[21:12] <DBO> there is a FFE in the works
[21:13] <DBO> 0.8.1 fixes some rather... annoying bugs
[21:13] <DBO> things like stealing your keyboard in rare situations kind of bugs
[21:13] <DBO> (our bad, we are rank amatures after all)
[21:36] <goshawk> can it be possible that a library is in debian and it's not in ubuntu?
[21:37] <RainCT> goshawk: yes
[21:37] <goshawk> well. how do i port it? :)
[21:37] <goshawk> the library is libconfig++6
[21:38] <RainCT> goshawk: that's the case if either it's new and has entered Debian after DebianImportFreeze (and nobody requested a sync) or if it was removed from Ubuntu for some reason
[21:38] <goshawk> RainCT: i think it's the first one, cuz it's only in sid and testing right now
[21:39] <goshawk> should i file a bug requesting a sync?
[21:42] <RainCT> goshawk: Probably not. https://edge.launchpad.net/ubuntu/+source/libconfig
[21:42] <RainCT> it was removed from Ubuntu
[21:43] <goshawk> it's not the same
[21:43] <goshawk> http://packages.debian.org/search?keywords=libconfig&searchon=names&suite=all&section=all
[21:44] <goshawk> RainCT: there is a libconfig0 (the one you are speaking)
[21:44] <goshawk> RainCT: and a libconfig++6
[21:44] <goshawk> libconfig0 version 0.1.5
[21:44] <goshawk> the same version of the launchpad link
[21:45] <goshawk> and libconfig++6 version 1.3.1
[21:45] <RainCT> ehm right
[21:45] <goshawk> ;)
[21:45] <goshawk> am i learning good? :)
[21:45] <goshawk> hihi
[21:45]  * RainCT blames whoever had the idea to give both packages the same name :P
[21:46] <porthose> goshawk: https://wiki.ubuntu.com/FreezeExceptionProcess
[21:46]  * goshawk jumps to FreezeExceptionProcess
[21:47] <RainCT> :)
[22:16] <goshawk> FreezeExceptionProcess says me to include the package, but should i include the orig.tar.gz, the diff.gz the .dsc, the .changes or all? If i should include all, but launchpad makes me upload only one, can i put them in a tar.gz packagE?
[22:17] <Laney> goshawk: debdiff is fine
[22:17] <Laney> or diff.gz for new upstream
[22:17] <goshawk> it's a new package, so diff.gz
[22:18] <Laney> completely new package?
[22:19] <goshawk> https://bugs.launchpad.net/bugs/342530
[22:20] <goshawk> well it's new for ubuntu
[22:20] <goshawk> but not for debian
[22:20] <cjwatson> goshawk: Launchpad may only let you use one attachment at a time, but there's nothing to stop you uploading several attachments in succession
[22:20] <cjwatson> although for a Debian package I'd say that a debdiff against the Debian package would be perfectly fine, if indeed there is any debdiff
[22:21] <cjwatson> (I don't know the MOTU policies on this, this is just what I'd want if I were sponsoring it)
[22:22] <cjwatson> if there's no difference versus Debian I see no reason to bother including the package at all, personally
[22:22] <goshawk> ok uploading a debdiff too and pointing to the debian .dsc as a comment
[22:22] <cjwatson> all that does is create extra work for somebody who has to check that it is the same
[22:22] <Laney> give a link to the debian dsc
[22:22] <cjwatson> goshawk: what changes were necessary for Ubuntu?
[22:22] <Laney> I guess that would be ok
[22:22] <goshawk> cjwatson: just the changelog that fixes the LP bug, and the Maintainer field
[22:22] <goshawk> nothing more
[22:22] <goshawk> i did both
[22:22] <cjwatson> goshawk: no, don't do that
[22:23] <cjwatson> if that's all, we should just sync the Debian package
[22:23] <cjwatson> there is no need to create a delta for just that
[22:23] <goshawk> cjwatson: ok so i'm adding a comment saying to just sync with debian one :)
[22:23] <cjwatson> (the above comments do not constitute a freeze exception ... I haven't looked at it)
[22:24] <goshawk> of course :)
[22:24] <goshawk> done
[22:35] <nhandler> goshawk: Just to clarify, this libconfig is in no way related to the old libconifg that was previously in Ubuntu and Debian, it is a different application that just shares the same name, correct?
[22:36] <goshawk> it seems so for me
[22:36] <goshawk> cuz also the pk provided are different
[22:36] <goshawk> sites are different
[22:36] <goshawk> i mean websites
[22:36] <nhandler> Ok, I just wanted to make sure I understood the wnpp bug correct
[22:36] <goshawk> versions are different too
[22:37] <nhandler> cjwatson: Would we need to do anything special on our end to handle the package?
[22:41] <porthose> would a kind member of MOTU-release please unsubscribe MOTU-release from Bug #338408, as the upstream maintainer is updating the package :)
[22:42]  * nhandler goes to look
[22:42] <adelie42> Hello, I am a long time hobby programmer, but new to this collaborative environment. I just spent today fixing some bugs, but I think I "did it wrong". I used 'apt-get source' to get the package, but now it looks like I should have gotten the source via 'bzr branch'. I have been following http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html but still feel a bit lost. Any assistance?
[22:43] <nhandler> porthose: Done, but FYI, it really isn't a huge deal. Most motu-release members will ignore bugs in the Incomplete state
[22:43] <nhandler> adelie42: What is the package?
[22:43] <adelie42> example-content
[22:43] <porthose> nhandler: thxs good to know :)
[22:45] <adelie42> PDFs were corrupted and there were some typos. Not really 'programming' bugs, but wondering if I used the right source / made the right kind of patch
[22:47] <adelie42> err... ok, I am looking at https://wiki.ubuntu.com/MOTU/Contributing after just noticing it in the title. Think I will get through that first.
[22:52] <cjwatson> nhandler: not if it isn't in Ubuntu right now
[22:52] <cjwatson> nhandler: under the current source package name (which AIUI is libconfig++ not libconfig?)
[22:53] <cjwatson> oh, no, apparently it's libconfig
[22:53] <cjwatson> anyway, if it isn't in jaunty right now, no special action is required
[22:54] <nhandler> Ok, I just wanted to make sure.
[22:54] <cjwatson> might want to make sure it doesn't share the same binary names
[22:54] <cjwatson> which is the only thing that's really significant for upgrade purposes
[22:55] <nhandler> That is on my todo list of things to check
[23:06] <goshawk> nhandler: thanks for the summary change ;)
[23:06] <nhandler> No problem goshawk. It just makes things more clear to people looking at the bug