[05:01] <bjsnider> fta, that last chromium-browser update introduced an odd bug where the browser window becomes as long as the webpage it is displaying
[07:44] <fta> bjsnider, did you search for an existing bug?
[07:53] <crimsun> shlibs bump in alsa-lib
[07:54] <crimsun> time to hang on for the ride
[08:09] <fta> bjsnider, btw, if it's http://ubuntuforums.org/showthread.php?p=8550907, i think i saw it once ~2 days ago, but it's gone for me (or at least i'm not able to reproduce anymore after the last upgrade)
[09:02] <RAOF> crimsun: Bring on libasound3! :)
[09:03] <crimsun> heh
[09:03] <crimsun> I truly fear that day, because it likely brings an entirely new mixer infrastructure
[09:04] <RAOF> Where all your carefully collected quirks no longer apply?
[09:06] <crimsun> hah, I wish
[09:06] <crimsun> no, two things, more than likely: 1) scenarios, 2) simplified structure
[09:07] <crimsun> (1) would be similar to PA's profiles
[09:07] <crimsun> (2) would be similar to PA's simplified mixer interface
[09:07] <crimsun> the driver of (1) is largely embedded devices
[09:08] <crimsun> and (2), well, has long been a feature request, but there's a worry about backward compatibility
[09:09] <crimsun> we're now at the point where things have to be carefully coordinated, since distros have such tightly integrated stacks :/
[09:17] <RAOF> Tightly integrated, with PA providing both (1) and (2)?
[09:18] <crimsun> PA would be a superset of both (1) and (2)
[09:19] <RAOF> So basically it's only people who care about embedded systems who'd want it?
[09:19] <crimsun> no, not really
[09:20] <crimsun> think of it this way: suppose you have a laptop without headphones plugged in, and your laptop only has stereo ("front") speakers. So the mixer only exposes playback controls for them.
[09:20] <crimsun> now you plug in your headphones, which are also stereo, and so the mixer now exposes only playback controls for the headphones.
[09:21] <crimsun> now you unplug your headphones and plug in a subwoofer, so the mixer now exposes playback controls for the front and the sub ("LFE")
[09:22] <crimsun> OS X does something similar already though in limited fashion from what I understand
[10:10] <surfzoid> Hi
[10:11] <surfzoid> I'm learning ubuntu packaging and see in an example, the directory debian in sources contain .install files to split in multi package (lib, doc ....), this files are write by hand or there a tools to generate them, let say from an schema or other ?
[10:19] <jpds> surfzoid: By-hand, basically make the one big package, get a file listing with dpkg -c package.deb and then write the .install files.
[10:20] <surfzoid> i see
[10:20] <surfzoid> thanks :-)
[10:21] <jpds> Or at least, that's how I do it.
[10:22] <surfzoid> jpds: i m packaging mono 2.6.1(240 mega) who is pretty long, if i took few hours to make a big .deb to list files, after i need to restart the whole process to split in several deb or i have a quickest way ?
[10:22] <jpds> surfzoid: Doesn't mono have .install files already?
[10:22] <surfzoid> yes but several are wrong or obsolete
[10:22] <jpds> surfzoid: directhex is your friend.
[10:23] <surfzoid> i guess it is not so easy for him, mono need to be "inside " from the start to the end :-)
[10:24] <surfzoid> long long ..... :D
[10:24] <surfzoid> i will increase the price of the beer
[10:25] <surfzoid> jpds: in fact more generally, there is possibility to comment some rules, to don't compil each time and directly go to the split step ?
[10:26] <surfzoid> or perhap's don 't clean ?
[10:47] <geser> dpkg-buildpackage -nc (or even debian/rules binary)
[10:47] <surfzoid> thanks
[11:19] <Lutin> asac: all EFLs are built and in the archive
[11:59] <CosmiChaos> hello
[11:59] <CosmiChaos> gimp-plugin-registry depends on libcv1, libcvaux1 and libhighgui1 but new sivp 0.5.0-1ubuntu3 upgraded packages to libcv4, libcvaux4 and libhighgui4
[12:04] <jibel> CosmiChaos, which version of gimp-plugin-registry ?
[12:05] <CosmiChaos> well wait latest in lucid... its 2.2-1.1
[12:05] <CosmiChaos> oh hmmmm wait i got a third party package i guess
[12:06] <CosmiChaos> 2.2-1ubuntu2 works xD
[12:12] <CosmiChaos> when xul-ext-adblock-pluslately was upgraded to 1.1.2-1 according to adblock-plus it requires to remove the old mozilla-firefox-adblock 1.1.1-0ubuntu4. all packages are in universe, distribution is lucid.
[12:13] <CosmiChaos> i gues mozilla-firefox-adblock was left for upgrade to 1.1.2
[12:14] <CosmiChaos> but on the opposite, mozilla-firefox-adblock has no specific version of adblock-plus and xul-ext-adblock on dependency list
[13:01] <imexil> Hi I'm trying to get a new software packaged. So far everything looks good but when I finally trigger "debuild" I get permission violations to some of the make file "cp" statements. I thought to  something like this is taken care of by fakeroot
[13:03] <ScottK> What's the exact error?
[13:03] <imexil> The statement in the original Makefile.am looks like this: cp $(abs_top_srcdir)/foo/bar.baz $(prefix)/lib/
[13:05] <imexil> and the error message then is: cp: can not create file /usr/lib/bar.baz
[13:08] <ScottK> The problem is you want to create usr/lib/bar.baz, not /usr/lib/bar.baz
[13:09] <cratylus> ScottK: since it's not in the real FHS but the mimicked debian/packagename directory structure  ?
[13:09] <ScottK> Yes.
[13:09] <imexil> so I have to check that $(prefix) is not set to /usr but usr
[13:09] <ScottK> That should be it.
[13:09] <imexil> OK then I have to do some greping
[13:11] <imexil> Thanks ScottK
[13:11] <ScottK> You're welcome.
[13:14] <maxb> Shouldn't that say $(DESTDIR)$(prefix)/lib/ ?
[13:15] <maxb> imexil: $(prefix) should be set to /usr
[13:15] <ScottK> If $(DESTDIR) is there, that should work.
[13:16] <matti> imexil: If you want to so this in bash, you have to use ${} instead of $().
[13:17] <matti> imexil: ${prefix} is not the same as $(prefix), unless inside the variable "prefix" there is a locaton stored to some binary that bash can execute and evaluate or it is a binary on its own.
[13:18] <imexil> matti: So $() will *execute what ever is within ()
[13:21] <matti> imexil: $() is the proper/correct replacement (so to speak) for `` - back-ticks.
[13:21] <maxb> It depends whether we are talking about shell or makefiles
[13:21] <matti> Oh yes.
[13:21] <maxb> since we are talking about makefiles here, $() is fine
[13:21] <matti> That is why I have said "If you want to do this in bash ..."
[13:21] <matti> ;
[13:22]  * imexil wonders if also ${} would be allowed in Makefiles
[13:22] <maxb> It is allowed, but is not the normal convention
[13:22] <matti> I am sorry for interrupting :)
[13:23] <matti> maxb: In regards to the Makefile you are of course right :) I had a glance at the channel and made wrong guess :)
[13:23]  * matti is sorry...
[13:24]  * imexil is now testing with $(DESTDIR)$(prefix)
[13:28] <imexil> darn, DESTDIR seems not be used by configure so it's simply empty. OK gonna complain to upstream
[13:34] <Laney> imexil: the debian build process sets it
[13:34] <Laney> for example "make -j1 install DESTDIR=/tmp/buildd/monodevelop-vala-2.1.1/debian/monodevelop-vala" from a build I just did
[13:42] <imexil> Laney: How exactly is it set. It's not defined by "dpkg-buildpackage -rfakeroot -D -us -uc "
[13:43] <Laney> well your install target should ensure that it is
[13:43] <Laney> poke your rules file to make it so
[13:43] <Laney> (you can use $(CURDIR))
[13:44] <imexil> the rules file uses currently cdbs
[13:49] <imexil> Laney: Just added "DESTDIR=$(CURDIR)" to debian/rules but still the same .. DESTDIR stays empty
[13:54] <tseliot> imexil: maybe try with "make prefix=/your/destination/path install" ?
[13:55] <Laney> imexil: if you add export DH_VERBOSE=1 you will be able to see what goes on
[13:55] <Laney> maybe the build system isn't getting it somehow
[13:55] <tseliot> example: make prefix=$(CURDIR)/debian/$(PKG_name)/usr install
[14:00] <imexil> tseliot: a manual make --prefix=... install is not the problem. It's the debuild process that needs to be aware of DESTDIR
[14:01] <imexil> Laney: Sorry but DH_VERBOSE=1 gave exactly the same output. No more information :(
[14:13] <imexil> OK, I have to leave now. Thanks for trying and merry christmas
[14:37] <bjsnider> fta, ping
[17:04] <micahg> do we ever backport a new package to a previous release?
[17:13] <ScottK> Certainly.
[17:14] <ScottK> !backports
[17:21] <micahg> ScottK: not a new version, but a new source
[17:21] <ScottK> micahg: In backports its fine.
[17:22] <micahg> ScottK: ok, so something like bug 500168 should be moved to jaunty-backports
[17:22] <ScottK> Yes.
[17:23] <micahg> ScottK: thanks
[19:38] <foxbuntu> bjsnider, ping
[19:39] <foxbuntu> bjsnider, I am intrested in testing the drivers in https://launchpad.net/~nvidia-vdpau/+archive/ppa and was wondering if you could tell me how stable the packages are (since I want to test their fixes on a semi-prod machine)
[19:42] <foxbuntu> bjsnider, the nvidia 190.53 and vdpau to be specific
[20:15] <bjsnider> foxbuntu, they are stable
[20:15] <foxbuntu> bjsnider, cool, I just installed them and they seem to work pretty well
[20:15] <bjsnider> lol
[20:16] <bjsnider> so you installed them anyway
[20:16] <foxbuntu> bjsnider, its a mythtv box...
[20:16] <bjsnider> i don't have a patched mythtv in there
[20:16] <foxbuntu> I figured "wth"
[20:17] <foxbuntu> bjsnider, thats ok, I am on the Mythbuntu project
[20:17] <foxbuntu> bjsnider, it actually plays pretty well with the current build of Myth
[20:18] <bjsnider> myth would have to be built against libvdpau-dev instead of nvidia-libvdpau-dev
[20:18] <bjsnider> but i guess it is in this case
[20:18] <superm1> if you are using the daily builds of myth at mythbuntu.org/auto-builds, they're built against libvdpau-dev
[20:19] <Daviey> foxbuntu: If it has ABI changes needed to myth, then build a custom myth based from the current packages you are using and build against ~nvidia-vdpau PPA packages.  That way, if it doesn't work out, you can easily roll back as the DB schema will be the same.
[20:20] <matti> Daviey: ;]
[20:20] <superm1> we might need to put a newer libvdpau in the auto-builds ppa, but it requires some testing at a staging ppa first to make sure it's not going to break everyone
[20:20] <Daviey> hey matti
[20:21] <bjsnider> superm1, just build-depends it to the nvidia-ppa since i've got the latest libvdpau1 in there
[20:21] <Daviey> foxbuntu: If you build it in your ppa, i would like to test it after the holidays aswell :).
[20:21] <superm1> bjsnider, there's some logistical problems with doing it that way (eg everyone needs to add that nvidia-ppa too)
[20:21] <foxbuntu> Daviey, Yea, I will send it out when I build it
[20:22] <Daviey> foxbuntu: good stuff.
[20:22] <bjsnider> superm1, would it install libvdpau with myth even if you weren't on an nvidia platform?
[20:22] <superm1> yes it does
[20:22] <Daviey> superm1: That would also mean we'd need to track updates to nvidia-ppa aswell?
[20:23] <superm1> right, which becomes troublesome quickly
[20:23] <superm1> for lucid it will be less of a problem since libvdpau is in the archive
[20:23] <superm1> and things can be more decoupled
[20:24] <Daviey> superm1: we like tight coupling! :)
[20:24] <superm1> but at least for karmic builds we need to stage the new libvdpau in a PPA with a myth build against it and nvidia 190.53 on it.  if the whole combo works out well from an upgraded from the current auto-builds PPA, then can move it into autobuilds
[20:26] <superm1> the first time libvdpau was added to the auto-builds PPA that's the way it was done, and it helped to catch a few problems
[20:28] <bjsnider> i haven't gotten any email complaints in a few days. that's my unscientific way of judging whether the ppa packages are stable
[20:29] <bjsnider> there's something missing from the ppa system when there are different builds of the same package in different repos for the same reasons
[20:29] <bjsnider> it should be easier to link them together
[20:30] <superm1> yeah
[20:34] <foxbuntu> superm1, so do we just need to add these packages into our auto-builds and change the depends for libvdpau then?
[20:35] <superm1> foxbuntu, please test in a staging PPA first
[20:35] <superm1> the packages in auto-builds already build-dep on libvdpau-dev
[20:35] <foxbuntu> superm1, well thats fine
[20:35] <superm1> but a more modern version is necessary likely
[20:36] <bjsnider> foxbuntu, you're running a myth based on which version of libvdpau?
[20:37] <foxbuntu> bjsnider, the one in your ppa
[20:37] <foxbuntu> er...that ppa
[20:37] <bjsnider> the myth ppa?
[20:38] <foxbuntu> libvdpau1:
[20:38] <foxbuntu>   Installed: 0.3-2ubuntu1~nvidiavdpauppa4
[20:38] <foxbuntu> thats the one I am using
[20:38] <bjsnider> no, but i mean mythtv was built against an older version right?
[20:38] <foxbuntu> oh, right
[20:38] <foxbuntu> I dont know which one it was built against
[20:39] <bjsnider> which one is in the myth ppa?
[20:39] <foxbuntu> superm1, do you?
[20:39] <foxbuntu> let me look
[20:40] <superm1> foolano, it was built against an older version yes
[20:40] <superm1> so we need to make sure it can build against the newer one (even though it clearly links fine against it)
[20:40] <superm1> foxbuntu, ^
[20:41] <foxbuntu> superm1, ah
[20:41] <foxbuntu> superm1, well I will work with you to build it in my ppa against this one
[20:41] <foxbuntu> ...or in testing
[20:42] <foxbuntu> either way
[20:43] <superm1> bjsnider, you shouldn't have set the version to 0.3-2ubuntu1, it should have been 0.3-2~ubuntu1 since it doesnt exist in lucid as 0.3-2ubuntu1 yet
[20:43] <superm1> and we are syncing 0.3-2 (bug 499725)
[20:44] <bjsnider> brb
[20:45] <bjsnider> superm1, but it is going to be called 2ubuntu1 when it is in lucid right?
[20:45] <superm1> bjsnider, no, it will be called 0.3-2
[20:45] <superm1> because we're syncing it
[20:46] <bjsnider> when does the ubuntu part of the string get attached or why?
[20:46] <superm1> when there is a delta to debian
[20:46] <bjsnider> if you make huge changes that are out of sync with debian?
[20:46] <bjsnider> i see
[20:46] <superm1> any changes, not just huge ones
[20:46] <bjsnider> well, i made a couple of changes
[20:46] <superm1> if we dont have ubuntu in the version string, we'll be autosyncing from debian
[20:47] <superm1> what changes?  we shouldn't be needing any delta for 0.3-2 afaik
[20:47] <bjsnider> there needs to be a provides: libvdpau
[20:47] <superm1> why?
[20:47] <bjsnider> because the package is libvdpau1, and i think it was the nvidia driver is looking for libvdpau
[20:48] <superm1> then the nvidia driver package should be fixed (imo)
[20:48] <bjsnider> i had to change one or the other so i changed both to be safe
[20:48] <superm1> please submit your changes to debian if you think they are good to have
[20:48] <bjsnider> i added libvdpau|libvdpau1
[20:48] <superm1> but we really dont want to carry a delta on libvdpau
[20:49] <bjsnider> well, the debian nvidia blob is a million miles away from what you and alberto are going to be doing, so i don't want in on that fight right now
[20:49] <bjsnider> you're putting everything into one package and debian is splitting it all up
[20:50] <superm1> yeah
[20:50] <superm1> well but the open source library, libvdpau we want to try to keep in common
[20:50] <superm1> and eventually get debian to pick up our changes to the nvidia blob
[20:51] <bjsnider> yes but do you really think it's smart to not have libvdpau referenced in the control file like it is? that just doesn't make sense to me
[20:51] <superm1> for what libvdpau does, i dont think its needed
[20:51] <bjsnider> what if somebody lazily adds libvdpau as a build-depends on something and doesn't realize it has to be libvdpau1?
[20:52] <superm1> build-depends should be libvdpau-dev
[20:52] <superm1> which depends on libvdpau1
[20:52] <bjsnider> yes, but a dependency to a binary package like gnome-mplayer for instance
[20:52] <superm1> it shouldnt be directly added to it there even
[20:52] <superm1> because build-depending on libvdpau-dev will cause shlibs to resolve libvdpau1
[20:53] <bjsnider> but not in the case of the nvidia blob
[20:53] <bjsnider> because i had to change that
[20:53] <bjsnider> although i see your point
[20:53] <superm1> for the nvidia blob vdpau library that's a whole different problem, but yeah
[20:53] <bjsnider> didn't you ahve this debate with somebody in debian in a mailing list? i thought i read that
[20:55] <superm1> yeah
[20:55] <superm1> and thankfully they saw my point and changed it
[20:55] <superm1> which is why there is no longer a metapackage for libvdpau-driver
[22:29] <dabaR> Super quiet
[22:29] <dabaR> Not the way I remember this channel.
[22:29] <dabaR> Maybe I am just joining at the wrong times.
[22:30] <dhillon-v10> dabaR, its usually super quiet
[22:30] <dabaR> Are you working on some Ubuntu motu work?
[22:30] <dabaR> Right now, that is.
[22:30] <dhillon-v10> dabaR, yup, looking at bugs that need packaging and discarding the ones that are already done
[22:31] <dabaR> One day I want to shadow someone who is doing that.
[22:31] <dabaR> Is there a name for that in here?
[22:31] <dabaR> Sponsoring?
[22:31] <dabaR> Mentoring?
[22:31] <dhillon-v10> dabaR, I guess you need a mentor, to help you out
[22:31] <dhillon-v10> dabaR, yup
[22:31] <dabaR> MOTU mentors, eh?
[22:32] <dhillon-v10> dabaR, yes, indeed :D
[22:32] <dhillon-v10> dabaR, are you a debian maintainer
[22:33] <dabaR> Nope.
[22:33] <dabaR> I am a software developer/db&sys admin
[22:33] <dabaR> Sorta all around IT guy.
[22:33] <dabaR> Just a couple of years of work experience with it all, though.
[22:33] <dhillon-v10> dabaR, ahh nice, most of my work is in coding as well, I just started packaging a while ago, not very good at it
[22:34] <dabaR> I understand a bit of that too.
[22:34] <dabaR> I mean, I have in the past done a bit of it.
[22:34] <dhillon-v10> dabaR, so what are you working on now
[22:34] <dabaR> I am about to leave work.
[22:34] <dabaR> I am not involved in Ubuntu development at all right now.
[22:34] <dhillon-v10> dabaR, ahh, I am a student so yay!!
[22:35] <dabaR> Anyhow, hope to speak to you soon again. What time-zone are you in?
[22:35] <dhillon-v10> dabaR, I am in GMT -5, I live in Florida, United States, what about you
[22:36] <dabaR> I am in Manitoba Canada.
[22:36] <dabaR> -6 I guess.
[22:36] <dhillon-v10> dabaR, nice talking to you
[22:36] <dabaR> So hopefully you can show me what you do one of these days.
[22:36] <dhillon-v10> dabaR, sure :D
[22:36] <dabaR> Nice talking to you too. Merry Christmas.
[22:36] <dhillon-v10> dabaR, yah same to you
[22:41] <dhillon-v10> hi all, hope everyone is doing good, I want to package this: https://bugs.edge.launchpad.net/ubuntu/+bug/110418 can anyone walk me through how to do this, I know the basics of packaging but I don't know how to do this one
[22:50] <bjsnider> dhillon-v10, there is no upstream debian package for that?
[22:51] <dhillon-v10> bjsnider, the link on sourceforge does that count as upstream
[22:52] <dhillon-v10> bjsnider, sorry not sourceforge, the other website that the bug mentions
[22:53] <bjsnider> no it doesn't
[22:55] <bjsnider> you'd need to move into the directory and run dh_make
[22:55] <bjsnider> to create the basic debian files
[22:55] <bjsnider> then deal with build-dependencies
[22:56] <dhillon-v10> bjsnider, so is that it, what about debian/rules
[22:56] <bjsnider> if you wash the resulting package through pbuilder a bunch of times you'll sort through the various issues that might arise
[22:57] <bjsnider> the rules file is created by the dh_make command
[22:57] <dhillon-v10> bjsnider, would that file be enough
[22:58] <bjsnider> not if you're building ffmpeg or something, but for a small package, probably
[22:58] <bjsnider> it automatically adds the --prefix=/usr flag
[22:58] <dhillon-v10> bjsnider, thanks a lot :D nice talking to you
[22:58] <bjsnider> np
[22:59] <bjsnider> i could probably phony something up here in a half hour that would work
[22:59] <bjsnider> if you want me to take a crack at it
[23:00] <dhillon-v10> bjsnider, I would learn really quick if you can do that, then I won't bother anyone else :P but that's only if you have some time
[23:01] <bjsnider> it says it uses tcl/tk, which means it will be as ugly as sin
[23:01] <dhillon-v10> bjsnider, can we just put > some_version tcl in the control file and make it work
[23:03] <bjsnider> no
[23:04] <dhillon-v10> bjsnider, oh
[23:29] <bjsnider> there's hardly anything in this tarball
[23:29] <bjsnider> there's no gpl or any other license
[23:30] <dhillon-v10> bjsnider, that's okay
[23:30] <bjsnider> no changelog
[23:30] <bjsnider> well, i don't think dh_make is going to work in this case
[23:30] <bjsnider> this thing does not actually contain the source code
[23:30] <bjsnider> this stuff is already built
[23:31] <dhillon-v10> bjsnider, why is dh_make not working
[23:31] <bjsnider> there's a couple of binaries, a shell script, some config files and icons and that's all
[23:31] <bjsnider> well, i think because it's not the source code
[23:34] <bjsnider> it's highly questionable whether the author wants this thing published as a package. it seems like he wants to hang onto it himself
[23:35] <dhillon-v10> bjsnider, so just leave it alone then
[23:47] <bjsnider> approximately when would libfuse be merged from upstream debian into lucid?