[06:24] <dholbach> good morning
[06:29] <micahg> siretart: are you handling the libav-extra upload?
[06:34] <siretart> micahg: I think I did the most annoying bunch of work here: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/ubuntu.extra
[06:34] <siretart> micahg: I think it even builds properly, but it clearly needs more testing
[06:35] <siretart> micahg: would you have the time to finish/upload that work today? If not, I would eventually get to that during the week (probably not today)
[06:36] <micahg> siretart: I can try in about 21 hours if you don't get to it
[06:36] <siretart> ok. let's coordinate on short notice then
[06:36] <micahg> siretart: do I need to be able to commit or will anonymous access do it for me?
[06:36] <siretart> micahg: if you do commits, just place them somewhere from where I can fetch and push your commits
[06:37] <siretart> micahg: but I can also arrange write access for you, what's your alioth username?
[06:37] <micahg> siretart: I have write access, the problem is I haven;t added a key to alioth yet
[06:37] <siretart> well, that's the trivial part, isn't it?
[06:37] <micahg> yeah, should be :)
[06:38] <siretart> then go for it! :-)
[06:38] <micahg> maybe tomorrow night, about to go to sleep
[06:38] <siretart> rest well!
[06:39]  * siretart fetches coffee (it's 8.38am here)
[06:39] <micahg> siretart: thanks, BTW, xubuntu seems interested in dropping libav support from gegl so it's not pulled in by gimp
=== Guest95641 is now known as Adri2000
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
[13:06] <badfox> Hi I am new merge , i have tried to merge  and getting the problem with debuild -S , here is the link http://pastebin.com/jXaVLrVC
=== vibhav_ is now known as vibhav
=== al-maisan is now known as almaisan-away
=== jokerdino_ is now known as jokerdino
[14:47] <Daviey> dholbach: Hey, do you understand why underscore has a binary new package ?
[14:48] <dholbach> Daviey, it was introduced in Debian
[14:48] <dholbach> yolanda merged it
[14:49] <Daviey> dholbach: right, but the changelog doesn't make it clear why it's a new binary.. do you understand why?
[14:49] <Daviey> Or should i dig in deeper?
[14:49] <dholbach> Daviey, https://launchpad.net/ubuntu/+source/underscore/1.3.3-1ubuntu1
[14:49] <dholbach> → 1.1.6-2
[14:50] <Daviey> doh!
[14:51] <Daviey> i thought it was bin 'underscore' new.
[14:51] <Daviey> which confussled me
[14:51] <dholbach> ah ok :)
[14:51] <Daviey> thanks
=== yofel_ is now known as yofel
[17:46] <cousteau> So...  not sure where to direct this, but here it goes.  The site packages.ubuntu.com seems to default to karmic when searching for package contents, this is, when no &suite=... parameter is in the URL
[17:47] <micahg> cousteau: you must have an old cached version, current default is precise
[17:47] <cousteau> this happens for example when I search from a search engine (one I found on mycroft; not sure how official it is) and then switch "Search package names" to "Search package contents"
[17:48] <micahg> karmic isn't even on the site anymore
[17:48] <micahg> hrm, it's true :(
[17:48] <cousteau> also if I search from the main URL in suite=all then switching to package content just gives an ugly error
[17:49]  * micahg wonders where rhonda is
[17:49] <micahg> that's certainly a lack of sane defaults ;)
[17:49] <cousteau> micahg, well, this is a freshly installed Xubuntu 12.04 on a computer that didn't have any linux before (or if it once had, it was formatted)
[17:49] <micahg> cousteau: no, I confirmed it, it's weird though
[17:49] <cousteau> ...that was it, Rhonda
[17:50]  * cousteau and his memory for names...  "Is here that...  person whose name starts with a capital R...  or B?"
[17:50] <cousteau> micahg, suite=default is precise, however (I think)
[17:51] <cousteau> the problem is that no suite= becomes suite=karmic rather than =default
[17:51] <cousteau> I thought it was because I was using an outdated search plugin (noticed the same behavior at home), but now I confirmed it's from the site
[17:52] <cousteau> s/confirmed/think/
[18:54]  * Elbrus wants to fix bug 1002520 in precise
[18:54] <ubottu> Launchpad bug 1002520 in winff (Ubuntu) "winff can't convert MTS to MPG (PAL DVD Widescreen)" [Undecided,Confirmed] https://launchpad.net/bugs/1002520
[18:55] <Elbrus> it is not really a critical bug, some settings just don't work.
[18:55]  * Elbrus guesses that SRU is too far fetched for this
[18:55] <Elbrus> should I make a backport (seems strange, as I only want to fix this issue)
[18:56] <micahg> Elbrus: how intrusive is the patch?
[18:59] <Elbrus> hardly
[18:59] <Elbrus> it replaces the preset file with updated presets
[18:59] <Elbrus> Winff preset file contains the avconv/ffmpeg commands to run
[19:00] <Elbrus> see debian/presets.xml and debian/presets-libavcodec53.xml in http://code.google.com/p/winff/source/detail?spec=svn646&r=627
[19:01] <Elbrus> (at least debian/presets.xml should be updated)
[19:01] <micahg> Elbrus: IMHO should be fine for SRU, but IANA SRU memebre
[19:01] <Elbrus> ok, I will go ahead with creating a debdif then
[19:02] <micahg> Elbrus: needs to be fixed in quantal first
[19:03] <Elbrus> it is already fixed (always was)
[19:03] <micahg> Elbrus: please comment in the bug to that regard and mark fix released, I"ll give you a precise task
[19:03] <Elbrus> or, I should say, since 1.4.2-1
[19:03] <Elbrus> ok
[19:08] <Elbrus> done
[19:09] <micahg> Elbrus: done as well :)
[19:10] <Elbrus> micahg: thanks
[19:10] <micahg> Elbrus: thank you for working to improve Ubuntu
[19:11] <Elbrus> np
[19:43]  * Elbrus attached the debdiff and subscribed ubuntu-sponsors and ubuntu-sru. hope all is all right now
[20:16]  * Elbrus signs off now
[20:23] <AmberJ_> Why purpose does dh_gencontrol serve?
[20:24] <AmberJ_> manpage says that dh_gencontrol generates control files once for each package
[20:25] <AmberJ_> http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control says: "dh_gencontrol(1) generates DEBIAN/control for each binary package while substituting ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, etc. "
[20:26] <AmberJ_> Does that^ means that for a multi-package debian/control setup which we chose.... there will be multiple packages listed in debian/control created by us (and corresponding *.install files).
[20:27] <AmberJ_> Then for each of package listed in debian/control by us, dh_gencontrol creates a (temporary) control file (?)
[20:38] <arand> AmberJ_: From my understanding it takes the debian/control that you create, reduces it to only concern the binary package currently being acted upon, substitutes the variables, and places the result in said binary package, see debian/binpackagename/DEBIAN/control after you run the build for the result.
[20:39] <arand> If you have a multi-package setup, the end result will be multiple different control files, one in each binary package.
[20:40] <AmberJ_> Oh yes, this explains it. Thanks!
[20:52] <AmberJ_> In a multi-package setup (with a single upstream source repo), if I put ${shlibs:Depends} and ${misc:Depends} under "Depends:" field in entries corresponding to EVERY package
[20:53] <AmberJ_> Will this automatically find mutual dependencies between these packages (based on the contents/libs in these packages)?
[21:03] <arand> AmberJ_: Not as far as I know.
[21:05] <AmberJ_> Ok, I'll do a build and see if putting ${shlibs:Depends} and ${misc:Depends} works...
[21:05] <AmberJ_> Otherwise, I'll have to put mutual deb dependencies manually
[21:16] <AmberJ_> If a package depends on another package in multi package setup, I can simply put the name of package as in filename.install file under Depends:
[21:20] <arand> Well, "package".install links to the "Package: "package"" field in d/control, so all three would be the same.
[22:05] <frcerm> If upstream source has *.h header files, all header files are supposed to be packed in deb (assuming *.so packed in debs have declarations in all *.h)
[22:05] <frcerm> ?
[22:06] <jtaylor> all headers that are needed to develop with the package
[22:06] <jtaylor> those are not necessarily all in the source
[22:06] <jtaylor> normally the source installation method installs what is needed
[22:09] <frcerm> [03:36] <jtaylor> those are not necessarily all in the source  <--  If some headers might not be included in upstream source, how does one gets them?
[22:10] <jtaylor> phrased it badly
[22:10] <jtaylor> not all headers inside the source package are needed by to use the package
[22:11] <jtaylor> the installed headers should only expose the public interface and nothing private
[22:11] <frcerm> got it! Thank you very much...
[22:15] <bobweaver> hello there I am trying to make a video tutorial for a friend on how to package " bakgrounds "  but the dang things will not show up under settings... permissions are correct do I have to make a xml file maybe? here is bzr branch (well pushng now)  https://code.launchpad.net/~josephjamesmills/+junk/backgrounds
[22:16] <bobweaver> package builds great installs to /usr/share/backgrounds/  but will not show up under settings-->appearance->look
[22:17] <arand> Is /usr/share/gnome-background-properties/gnome-backgrounds.xml the crux? (Not sure of equivalent for Unity)
[22:18] <bobweaver> thanks arand
=== julezz is now known as julez
[22:40] <LordOfTime> anyone here familiar with patch tagging guidelines?
[22:48] <arand> LordOfTime: Somewhat, if you mean the dep3 stuff.
[22:48] <LordOfTime> that's what i meant, but mdeslaur beat you to it in -hardened