[12:20] <pochu> hello
[12:20] <pochu> do you know if we will see thunderbird 2.0 in Feisty?
[12:21] <crimsun> not a universe source package.
[12:21] <pochu> yes I know
[12:21] <pochu> it is in main
[12:21] <pochu> isn't it?
[12:22] <pochu> so where should I ask?
[12:22] <crimsun> you've already joined the proper channel
[12:22] <crimsun> (-devel)
[12:23] <pochu> crimsun: as the topic for -devel is not support i didn't want to ask there
[12:23] <pochu> :-)
[12:24] <pochu> crimsun: thanks
[12:43] <Hobbsee> morning all
[12:44] <Nafallo> indeed
[01:38] <bddebian> Heya gang
[01:38] <crimsun> hi.
[01:39] <bddebian> Hi crimsun 
[01:40] <crimsun> I'll be reducing my Ubuntu involvement given job commitments in the coming months, but I feel confident with the teams in place that people will keep universe running smoothly.
[01:40] <bddebian> Noooo
[01:40] <Nafallo> first LaserJock and now crimsun :-P
[01:40] <Nafallo> wow
[01:41] <crimsun> I won't step down completely until there's a capable team triaging audio bugs.
[01:41] <bddebian> Well that will be like never :-)
[01:41] <ajmitch> well there's bddebian to help out
[01:42] <ajmitch> so he can do everything you've been doing
[01:42] <bddebian> Not me, I suck remember :-)
[01:42] <crimsun> sweet
[01:42] <ajmitch> then stop sucking, *quickly*
[01:43] <ajmitch> yeah, not appropriate
[01:43] <bddebian> Man, I haven't run xchat in GNU/Linux in ages
[01:43] <Nafallo> bddebian: oh! anyone willing to suck my dick is a good one :-)
[01:43] <ajmitch> uh..
[01:43] <jdong|laptop> the irony....
[01:44] <jdong|laptop> and Nafallo.... whoa....
[01:44] <Nafallo> hihi
[01:44] <jdong|laptop> Nafallo: we use innuendos in release codenames and artwork to express those feelins
[01:44] <Nafallo> jdong|laptop: ROTFLMGAO ;-)
[01:48] <bddebian> Any of you ever heard of tfdocgen?
[01:48] <bddebian> Oh this ain't my primary machine :)
[01:48] <jdong|laptop> bddebian: that's an ancient city ruins uncovered in Greece. it was on Dateline last week
[01:49] <bddebian> heh
[01:49] <jdong|laptop> :)
[01:50] <bddebian> Well this damn libticonv package does make docs and it tries to run tfdocgen :-(
[01:50] <jdong|laptop> http://svn.tilp.info/
[01:50] <jdong|laptop> that's where the aforementioned script is.
[01:51] <bddebian> lame
[01:51] <jdong|laptop> the wonderful smell of additional build-deps in the morning :)
[01:52] <ScottK2> Perhaps ajmitch would be up for a little REVU while he's away from the channel - http://revu.tauware.de/details.py?upid=4127
[01:52] <bddebian> hehe
[01:55] <ScottK2> Do these evil things include REVUing packages?
[01:56] <jdong|laptop> Nafallo: I've done my share of evil for the day :)
[01:56] <LaserJock> have we firmed up our meeting time?
[01:56] <Nafallo> jdong|laptop: installed firstclass? ;-)
[01:56] <jdong|laptop> heh :)
[01:57] <jdong|laptop> Nafallo: no, but I am toying with ffmpeg-cvs :)
[01:57] <Nafallo> I win!
[01:57] <Nafallo> :-P
[01:57] <jdong|laptop> Nafallo: contest me and the patches will fly YOUR way :P
[01:57] <jdong|laptop> lol
[01:58] <Nafallo> haha
[01:58] <LaserJock> ajmitch: contentless ping?
[01:58] <jdong|laptop> USB atheros is still taboo, right?
[02:27] <ajmitch> LaserJock: similarly contentless & worthless pong
[02:27] <LaserJock> ajmitch: excellent thank you
[02:30] <bddebian> heh
[02:44] <zul> mmmm...UHF
[02:44] <bddebian> stupid package
[03:31] <shawarma> If there's a package that's about to enter the archive for the first time, but there's a community-provided package known to be in wide use with a wrongful higher version number, would you guys think it was alright if an epoch was set on this first official version in order to let the users of the community provided version upgrade smoothly?
[03:31] <shawarma> Theoretically, of course.. :-)
[03:34] <crimsun> no, I think that's bogus.
[03:35] <crimsun> we're not responsible for screwed external versioning
[03:35] <crimsun> and I keep telling the folks who build beryl packages to stop using that crackful versioning, but of course it's in one ear and out the other
[03:35] <jdong> bddebian: upload time? I'm dying of Altivec anxiety :D
[03:36] <jdong> (not really, but I'm about 5 minutes from opening up doom3 and wasting a good working night)
[03:36] <bddebian> jdong: Sure since I seem to suck at getting this libticonv built :-(
[03:39] <shawarma> crimsun: I see your point. However, setting the epoch wouldn't break anything, but it *would* fix the upgrades for quite a few users.
[03:40] <shawarma> crimsun: It think that's also a valid point.
[03:40] <crimsun> if maintaining compatibility with external repositories is a concern, then do what it takes to keep it
[03:40] <jdong> is there any trivial python or gdialog/zenity-like way of triggering libnotify popup balloons?
[03:41] <crimsun> before you trigger those popups, talk to mpt and see if what you want to do is sane UI-wise.
[03:41] <shawarma> crimsun: I happen to know that the external repository will seize to exist the very second this package enters the archive, so it's a one-off thing.
[03:41] <jdong> crimsun: it's more for personal use and not gonna see the public light of day
[03:41] <shawarma> crimsun: I happen to know this as I'm the sucker who made the packages. :-)
[03:42] <ajmitch> poor sucker
[03:43] <crimsun> it almost explodes gracefully when I switch Modes :-)
[03:44] <bddebian> jdong: It's uploading
[03:44] <ajmitch> such hype about it at UDS
[03:44] <ajmitch> & the concern over binary drivers
[03:44] <shawarma> I actually have better experience with beryl than compiz.
[03:45] <jdong> bddebian: yay :)
[03:49] <bddebian> jdong: Now, build libticonv for me :)
[03:51] <Nafallo> backuppc ftw
[04:13] <bddebian> So, who's gonna review MY new package? :)
[04:13] <crimsun> upid?
[04:15] <bddebian> Dunno yet but it's libticonv2
[04:18] <crimsun> do you want a review pass or compilation assistance?
[04:20] <bddebian> review pass
[04:20] <bddebian> It compiles
[04:21] <bddebian> What's weird though is the orig source dir is libticonv-1.0.1 but it complained about SONAME until I made it libiconv2-foo
[04:21] <crimsun> ok. COPYING needs to be updated for the FSF address
[04:22] <bddebian> OK
[04:23] <crimsun> heh
[04:23] <crimsun> README has:
[04:23] <crimsun> Copying is allowed under the terms of GNU General Public
[04:23] <crimsun> License (LGPL). See the file COPYING for more details.
[04:23] <crimsun> that's not what COPYING is
[04:23] <bddebian> Damn, libparagui did the same shit to me :-(
[04:23] <crimsun> so either that 'L' is a typo, or someone forgot to use the correct license
[04:24] <crimsun> s/someone/upstream/
[04:27] <crimsun> docs/ , tests/ look good
[04:27] <crimsun> the FSF addresses in the headers are still the old ones
[04:29] <crimsun> src/ looks good (same caveat RE: old FSF addresses in source files)
[04:29] <crimsun> [note that src/charset.h actually has the correct updated FSF address] 
[04:30] <crimsun> debian/changelog: "Intitial" -> "Initial"
[04:31] <crimsun> debian/copyright says LGPL.
[04:31] <crimsun> so something needs to be clarified w/ upstream
[04:32] <crimsun> if it in fact is to be distributed under LGPL, you'd need to include a full copy of the LGPL
[04:36] <ScottK> crimsun: If you are up for another package... http://revu.tauware.de/details.py?upid=4127
[04:36] <crimsun> I'm not finished.
[04:38] <ScottK> Ah.  Sorry.
[04:39] <crimsun> (np, just wanted to let you know I'm not ignoring you)
[04:43] <ScottK> Thanks.  I appreciate not being ignored.  If you get ambitious, I have a list...  http://spf.pastecode.com/12063 - the one above is the first on the list.
[04:43] <somerville32> ScottK: Are you going for developer?
[04:43] <bddebian> crimsun: Well some of the files in debian/ still need work.  The description isn't even the one for that package ;-P
[04:44] <crimsun> bddebian: I presumed they were WIP
[04:45] <ScottK> somerville32: No.  I just have some stuff I'm trying to get done.  I need software packaged to do it.
[04:45] <ScottK> I have to go AFK and deal with children and bed times...
[04:48] <crimsun> bddebian: what do you plan to do about the binary package names?
[04:50] <Mez> 402 upgraded, 0 newly installed, 0 to remove and 114 not upgraded.
[04:50] <Mez> 406 not fully installed or removed.
[04:50] <Mez> Need to get 341MB of archives.
[04:50] <Mez> hmm
[04:50] <somerville32> gpocentek, Did you package thunar-volman already?
[04:50] <Mez> i may have to have fun and remove everything
[04:51] <gpocentek> somerville32: yes, but I need to fi some copyright issues
[04:51] <gpocentek> fix*
[04:51] <somerville32> gpocentek, ok.
[04:51] <bddebian> crimsun: Probably gonna have to get upstream to straighten it out I suppose
[04:51] <somerville32> gpocentek, Do you know C/C++?
[04:53] <gpocentek> somerville32: C, but I'm really far from being an expert
[04:53] <somerville32> sfflaw rejected my SRU for dubious modifications
[04:53] <somerville32> And I need a second opinion since I don't know C/C++
[04:53] <gpocentek> the mousepad one?
[04:54] <somerville32> Yes.
[04:54] <somerville32> I already removed the comment style change
[04:54] <somerville32> so I dunno what he means there
[04:54] <somerville32> but the function rename might be a valid point
[04:54] <somerville32> but the svn commit log doesn't mention anything else
[04:57] <gpocentek> I'll have a look this weekend
[04:57] <gpocentek> but apparently there's also an UI change in this patch
[04:59] <somerville32> gpocentek, I can modify the patch as he suggests.
[05:00] <somerville32> I just don't want to waste effort removing changes that are required.
[05:03] <gpocentek> somerville32: switching from a xfce file chooser to a gtk file chooser is a big change, I don't think that we need this to fix the bug
[05:04] <bddebian> crimsun: Thanks btw
[05:04] <crimsun> np
[05:04] <gpocentek> somerville32: the xfce filechooser works everywhere, so that's not the problem
[05:06] <gpocentek> bbl
[05:12] <somerville32> gpocentek, ok. I can fix that up then.
[05:20] <somerville32> 0.2.2-2ubuntu5.1~proposed -> 0.2.2-2ubuntu5.1~proposed2 ?
[05:30] <jdong> bddebian: party hat! new x264 built successfully on all arches :)
[05:33] <somerville32> Yea!!!
[05:36] <jdong> which goes to show... the best altivec is no altivec ;-)
[05:38] <bddebian> jdong: :-)
[05:39] <jdong> bddebian: now the other patches shouldn't give you any grief. I expect mplayer to FTBFS but for an unrelated reason :)
[05:40] <Toadstool> agreed :)
[05:40] <Toadstool> 'evening everybody
[05:42] <bddebian> Heya Toadstool 
[05:42] <Toadstool> hey bddebian 
[05:45] <LaserJock> anybody tried bzr-builddeb yet?
[05:45] <somerville32> Whats the command to filter files out of a diff?
[05:45] <LaserJock> filterdiff
[05:47] <somerville32> How intuitive :)
[05:49] <somerville32> Who do I get it to remove two files?
[05:49] <jdong> pipe one to another!
[05:51] <somerville32> lol
[05:51] <somerville32> How do I get it to remove on file? :P
[05:51] <somerville32> *one
[05:54] <jdong> somerville32: give it a regex that only matches one file?
[05:55] <jdong> -x '^filename$' should do it?
[05:58] <jdong> *sigh* I'm bored.... is Feisty released yet?
[05:58] <LaserJock> yes
[05:59] <jdong> yay!
[05:59] <LaserJock> I just *Herd* about it *2* days ago
[05:59] <LaserJock> lame
[05:59] <Toadstool> :)
[05:59] <jdong> Hurd 2 is out already? What? hell froze over twice already?
[06:00] <jdong> and LaserJock, I thought only I made lame herd/knot jokes?
[06:04] <ScottK> Good night all.  I've had enough fun for one day.  
[06:15] <LaserJock> jdong: you certainly aren't the only one
[06:24] <LaserJock> hmm, anybody know vincent untz?
[06:26] <somerville32> Name sounds familiar
[06:26] <somerville32> A gnome developer?
[06:26] <LaserJock> yeah
[06:27] <LaserJock> I wondered if anybody knew where I can find him
[06:27] <somerville32> His... website?
[06:27] <somerville32> lol
[06:28] <somerville32> vuntz.com
[06:28] <somerville32> *.net
[06:29] <LaserJock> seems french, I might try gimpnet during regular French hours
[06:29] <LaserJock> I want a gnome bug fixed
[06:30] <LaserJock> and I feel like poking somebody about it :-)
[06:30] <somerville32> He might be a good person to poke
[06:30] <somerville32> I see his name in the changelogs all the time
[06:31] <LaserJock> yeah, it's a gnome-panel "issue" and he seems to be the guy for that
[06:33] <Toadstool> LaserJock: maybe vuntz on #u-devel ;)
[06:34] <LaserJock> oh wait, maybe I found the solution
[06:35] <LaserJock> well, it sort works
[06:49] <LaserJock> oh geeze
[07:50] <Amaranth> kbuildsyscoa or whatever is the little hack that makes loading KDE apps fast, right?
[08:23] <LaserJock> hi Hobbsee 
[08:23] <crimsun> Amaranth: what are you referring to?
[08:23] <LaserJock> crack, utter crack :-)
[08:23] <Amaranth> crimsun: the little daemon or whatever that makes a KDE app load faster
[08:23] <Amaranth> maybe it's kde-init or something
[08:24] <Hobbsee> hey LaserJock 
[08:31] <Mez> Amaranth, kbuildsycoca rebuilds the KDE system cache
[08:31] <Amaranth> i'm not trying to use it, just an academic question
[08:31] <Hobbsee> isnt that just prelink?
[08:31] <Amaranth> nah, there is some extra magic
[08:32] <Mez> Amaranth, kdeinit will load up dcop server etc etc
[08:32] <Amaranth> because when you login to a KDE session apps start fast, when you use GNOME they take forever
[08:32] <Amaranth> but if you start them again they're just as fast as under KDE
[08:33] <Mez> Amaranth, kdeinit is what you're looking for
[08:33] <Amaranth> alright
[08:33] <Mez> loads kio slaves, kded, scop server etc etc
[08:33] <Mez> s/scop/dcop/
[08:34] <Mez> Amaranth, or just run KDE :D
[08:34] <Mez> :-"
[08:36] <luckyone> hello all - can anyone tell me if there is a bug associated with xsane for edgy? I don't know who to ask about this
[08:37] <luckyone> sorry, not sure if this made it - can anyone tell me if there is a bug associated with xsane for edgy? I don't know who to ask about this
[08:39] <crimsun> https://launchpad.net/ubuntu/+source/xsane/+bugs
[10:10] <owh> Hi folks, I posted an email to ubuntu-devel and after a week to ubuntu-devel-discuss. The message to ubuntu-devel was moderated after about 10 days and came through in a whole bunch of messages. 
[10:10] <owh> The message to ubuntu-devel-discuss was distributed, since it made it to the archives: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-January/000167.html but I have not received any replies. I'm not here to whinge about it, but can anyone point out why it was ignored?
[10:11] <owh> Did I author a completely obtuse message, or was it something else?
[10:11] <somerville32> I read it
[10:11] <owh> Did I break any rules I should be aware of?
[10:11] <somerville32> I don't think so
[10:12] <somerville32> Try bringing it up in #ubuntu-devel during EU business hours
[10:12] <owh> That's an excellent suggestion.
[10:12] <owh> I'm glad that you read it, at least someone did :-)
[10:14] <owh> somerville32: When you read the message, did you think I should have put more time into it perhaps?
[10:14] <somerville32> owh, I thought it should have gone to ubuntu-devel instead of -discuss
[10:14] <owh> That's why I sent it there in the first place.
[10:14] <somerville32> Try to find a core-dev to sponsor it
[10:15] <owh> But it didn't get moderated, and after it did, it was buried.
[10:15] <owh> somerville32: I thought that including sistpoty would have assisted.
[10:16] <owh> somerville32: Thank you for your suggestion on #ubuntu-devel. I will follow that up next week.
[10:16] <somerville32> Awesome :)
[10:16] <somerville32> Thanks for your work!
[10:16] <owh> Pleasure.
[10:16] <owh> Thanks
[10:28] <tsmithe> siretart, you here?
[11:03] <ademan> dumb question, when there's no ./configure in a source tarball but there is configure.in  what do i run?  I tried autoconf but it tripped up on some real basic macros
[11:08] <StevenK> ademan: ./autogen.sh
[11:08] <ademan> :-/ doesnt have one
[11:08] <StevenK> Although, autoconf ought to deal.
[11:09] <ademan> it errors like heck, config.guess and config.sub missing
[11:09] <StevenK> config.guess and config.sub can be copied in
[11:10] <ademan> from any other source tarball?
[11:10] <StevenK> From /usr/share/misc
[11:10] <somerville32> Isn't there a script to autogenerate it?
[11:10] <ademan> ah, thanks
[11:10] <ademan> somerville32: nope
[11:11] <ademan> i guess cause it's cross platform
[11:11] <somerville32> ifneq "$(wildcard /usr/share/misc/config.sub)" ""
[11:11] <somerville32>         cp -f /usr/share/misc/config.sub config.sub
[11:11] <somerville32> endif
[11:11] <somerville32> ifneq "$(wildcard /usr/share/misc/config.guess)" ""
[11:11] <somerville32>         cp -f /usr/share/misc/config.guess config.guess
[11:11] <somerville32> endif
[11:11] <somerville32> You can add that to your clean rule
[11:11] <somerville32> after  -$(MAKE) distclean
[11:11] <somerville32> and before dh_clean
[11:12] <ademan> somerville32: honestly i didn't write the makefile
[11:12] <somerville32> No
[11:12] <somerville32> The debian rules file
[11:12] <somerville32> :)
[11:12] <ademan> oh, haha, well i'm not to the point of packaging it yet, i gotta make sure that the person who submitted for revu didn't get it through (nearly a year ago)
[11:14] <ademan> now automake wants ./INSTALL, ugh, this is EXACLTY why i'm writing a new build system... 
[11:14] <persia> It doesn't belong in clean.  The config{sub,guess} copy should be done in configure, and the files should be deleted in clean.  Otherwise they end up in .diff.gz (and are not required).
[11:38] <geser> _Enchained: hello
[11:38] <_Enchained> hi
[11:38] <geser> that 'h' in the dpkg output stands for a hardlink
[11:39] <_Enchained> ok
[11:39] <_Enchained> What should I do with that ?
[11:39] <_Enchained> for the package
[11:43] <geser> is it really needed that the binary is installed as OOodi and ooodi?
[11:43] <geser> the easiest would be to install only ooodi
[11:44] <_Enchained> yes it's what I think
[11:45] <_Enchained> but it maybe could causes problems in execution
[11:45] <_Enchained> ?
[11:45] <_Enchained> I don't know... maybe if the program call OOodi...
[11:45] <_Enchained> or something like that
[11:46] <_Enchained> I think I'll rename OOodi binary in ooodi and delete the old oodi (link)
[11:47] <_Enchained> Do you know how to fix the linda warning (with config.guess) ?
[11:47] <geser> see the README for autotools-dev
[11:49] <_Enchained> ok
[11:51] <palski> is so that initrd-tools should not be merged?
[11:54] <geser> palski: are the initrd-tools still in use?
[11:55] <palski> well, they are not anymore in debian repos but in feisty repos they seems to be
[11:56] <palski> and by debian repos I mean debian unstable repos =)
[12:00] <geser> ask the kernel people if they have any objections and file a request for removal
[12:04] <palski> bug #79168
[12:04] <Ubugtu> Malone bug 79168 in initrd-tools "initrd-tools: merge new debian version" [Undecided,Rejected]  https://launchpad.net/bugs/79168
[12:06] <geser> oh, we have a "MOTU Merge Team"?
[12:20] <_Enchained> geser: http://revu.tauware.de/details.py?upid=4142 updated
[12:20] <_Enchained> still the problem on cvs files
[12:20] <_Enchained> I think the rest is ok.
[12:51] <afflux> when packaging a java class, do I need to create the -dev package?
[12:52] <afflux> ah, sry for stupid question :/
[01:17] <afflux> problem: I wanna build a package using pbuilder with sun-java5-jdk in the dependencies. while setting up the build-dependendies it fails cause he "couldn't present the license" (we are in non-interactive mode of course). any way to avoid this? (is this even the right place to ask?)
[01:20] <geser> afflux: do you really need the sun-java5-jdk package? doesn't it build with gcj or the other java compilers?
[01:20] <afflux> the original author of the code said it :) i gonna try.
[01:21] <afflux> can i compile a library with gcj and a program that depends on this library with the javac?
[01:29] <afflux> geser: is there any way to do it with the sun packages if I find no other solution?
[01:30] <geser> sorry, I don't know
[01:30] <persia> afflux: pbuilder login --save-after-exec allows you to make manual changes, but I don't know if it works for the buildds.
[01:31] <geser> afflux: just a side note: if your package build-depends on sun-java5-jdk it would have to go to multiverse
[01:31] <afflux> alright, i gonna look.
[01:31] <afflux> thank you two.
[01:34] <afflux> yeah, I have feared this.
[03:34] <davromaniak> any reviewer can take a look at youtranslate please ? : http://revu.tauware.de/details.py?upid=4119
[04:10] <muzzol> hi, i have a dumb question, where do i specify the package name if is diferent from source package?
[04:10] <muzzol> im playing with control file
[04:10] <muzzol> but im not sure
[04:12] <pochu> muzzol: I think you can do that with "dh_make -p <packagename>
[04:12] <persia> muzzol: Does your source package provide more than one binary package?  If not, it is best to have the same name.  If so, you will need to alter both control and rules.
[04:12] <muzzol> well im not sure if i've explained correctly
[04:12] <muzzol> i want to change the original name
[04:13] <muzzol> if i have a source package name a.tgz
[04:13] <muzzol> and want to generate a bin package named b.deb
[04:13] <muzzol> where must i look?
[04:14] <persia> muzzol: The easiest way is `tar xzf a.tgz; mv a b-x.y.z`, and build your package in b-x.y.z.
[04:14] <muzzol> ah! ok, i though i had to edit control file
[04:14] <muzzol> that's really easy
[04:14] <muzzol> :)
[04:16] <persia> muzzol: For single-binary packages, your source and binary package names should match, and the directory be called <pkgname>-<version>.  You will need to put b in your control file to generate b_x.y.z-r_<arch>.deb.
[04:22] <ScottK> persia: Are you familiar with packaging/building C programs in the Ubuntu environment?  I have a question if you are and have a moment...
[04:22] <persia> ScottK: I'm more familiar with C than python or perl.  What's the question?
[04:23] <ScottK> Typing ....
[04:24] <ScottK> I did a packaging fix and rebuilt libspf2.  Here's the debdiff http://librarian.launchpad.net/5800752/Debdiff_rev1.  The trick is that libspf2-1.2.5/src/libspf2/spf_lib_version got added somehow.
[04:24] <ScottK> I guess the question is how do I avoid that?  I think it's not necessary and I don't want to complicate review of the patch.
[04:29] <persia> ScottK: If you really didn't add spf_lib_version.h, then it looks to me like the clean rule doesn't do all it might.  Did you maybe build the package in the tree at least once prior to generating the final source version?
[04:29] <ScottK> No.
[04:30] <ScottK> I actually tried making a new directory, downloading the source package, and rebuilding an unmodified package.  Got the same issue.
[04:30] <persia> ScottK: Hrm.  I'll take a closer look, and see if I can figure out what happened.
[04:30] <ScottK> I'd appreciate it.
[04:31] <ScottK> persia: The other issue that I manually edited out of that particular debdiff is that there are a bunch of windows files in there and rebuilding the package causes all the line endings to get converted to Unix line endings...
[04:31] <ScottK> This makes for a particularly ugly diff.
[04:32] <imbrandon> ScottK, make the post inst run unix2dos or dos2unix ( dependsing ont he need ) 
[04:32] <imbrandon> simple hack to get arround that
[04:33] <imbrandon> ( of course that will add another build dep )
[04:33] <ScottK> But, of course, I don't always get what I want.
[04:35] <persia> ScottK: First pass runs with no diff (output of debuild -S -us -uc on unmodified source).
[04:36] <ScottK> OK.  Well then I think I understand at least a little better.
[04:37] <ScottK> I think I should not do that.
[04:38] <ScottK> Thanks for looking at it.  I'll go try it again....
[04:40] <persia> ScottK: Yep.  It's a bug in the clean rule.  It's a good idea to verify uild first, but afterwards, delete the directory, and rerun dpkg-source -x, as otherwise these bugs can hit you.
[04:41] <ScottK> Thanks again.  I learn something new here every day.
[04:42] <ScottK> persia: Should I write a bug for that (I'm not up to fixing myself - just learning)?
[04:44] <persia> ScottK: It's probably not worth it.  If it is a debian package, it is worth sending a debian bug (wishlist).  If it is in an Ubuntu-only package, just fix it.  To fix it, you only need to add the logic to delete the file either in the debian/rules clean rule, or in the upstream Makefile clean rule.  If it's not obvious, leave it alone: I find bugs like this in about 60% of the packages I touch.
[04:45] <ScottK> It's orphaned in Debian, so writing a Debian bug is of little use in the short term.  Someone is planning on picking it up once they are a DD (hopefully later this year).  Sounds like it's not worth messing with.
[04:46] <ScottK> Appreciate the help.
[04:46] <persia> ScottK: Probably not.  As long as the package builds correctly after downloading, and anyone preparing an NMU or Ubuntu revision is careful to avoid extra material in the changelog, most people should be happy.
[04:47] <persia> s/changelog/debdiff/
[04:49] <ScottK> Good morning Mez.
[05:06] <ScottK> persia: That worked. https://bugs.launchpad.net/ubuntu/+source/libspf2/+bug/79683 - now I've got a fix that's actually correct.
[05:06] <Ubugtu> Malone bug 79683 in libspf2 "spfquery: conflict with libmail-spf-query-perl Debian bug#306875" [Unknown,Unknown]  
[05:09] <persia> ScottK: Glad to hear it.  I'll recommend that you change the bug status to "Confirmed", and the assignee to "Nobody", as the U-U-S member who uploads it will want to be assigned for tracking purposes, and may want to set in-progress if they have other changes to make to the package prior to upload.
[05:09] <jdong> hey jdong, know why udffsck isn't repairing your udf disc?
[05:09] <jdong> because it says int main(){return 0;}
[05:10] <ScottK> persia: Done.  Thanks more.
[05:10] <persia> ScottK: No worries.
[05:21] <crimsun> ScottK: http://librarian.launchpad.net/5805334/corrected_debdiff does not apply against the latest Debian source
[05:21] <crimsun> patching file debian/control
[05:21] <crimsun> Hunk #2 FAILED at 38.
[05:21] <crimsun> 1 out of 2 hunks FAILED -- saving rejects to file debian/control.rej
[05:22] <ScottK> Urgh.
[05:25] <ScottK> It builds here in my Feisty chroot (I just went and built it again).  I'll go look at it some more...
[05:30] <ScottK> After building the binary I get a lintian error on the source package I didn't get before I built the binary: E: libspf2_1.2.5-4ubuntu1_source.changes: md5sum-mismatch-in-changes-file libspf2_1.2.5-4ubuntu1.dsc
[05:36] <Adri2000> crimsun: I have the last guifications version which work with gaim 2.0.0beta6 packaged, can you upload it? or do you prefer to wait for debian (which has not even gaim 2.0.0beta6 yet) ?
[05:38] <crimsun> debdiff.
[05:41] <Adri2000> crimsun: it's a new upstream release, no change except the changelog entry
[05:41] <Adri2000> crimsun: http://adrishost.homeip.net/~adri2000/ubuntu/toupload/
[05:45] <crimsun> Adri2000: tested?
[05:51] <Adri2000> crimsun: yes, works
[05:59] <Adri2000> thanks crimsun 
[06:14] <tsmithe> siretart, here?
[06:14] <tsmithe> hmm
[06:14] <tsmithe> seems to be /away
[06:14] <tsmithe> ah well
[06:29] <jdong> crimsun: can you sponsor all the debdiffs (except the first one; x264 already uploaded) on https://launchpad.net/ubuntu/+source/x264/+bug/80387/comments/1?
[06:29] <Ubugtu> Malone bug 80387 in x264 "Import 20070116 snapshot" [Undecided,In progress]  
[06:29] <jdong> crimsun: they are to rebuild affected multiverse packages against new x264
[06:30] <jdong> crimsun: and the ffmpeg one also closes the wishlist thing about DEB_BUILD_OPTIONS=risky I was nagging you about last month :)
[06:52] <ademan> in a source tarball what does the ./INSTALL file contain?
[06:53] <mr_pouit> usually, instructions to install the program
[06:54] <ademan> so its just human readable stuff?
[06:55] <ademan> ie non-essential?  automake is complaining about a lack of ./INSTALL file, can i just make an empty one?
[06:55] <Adri2000> yes
[06:57] <Adri2000> ademan: there is a generic INSTALL (with ./configure, make, ... instructions) file available somewhere
[06:59] <ademan> hrm ok, now i'm going to be packaging Code::Blocks in the near future assuming that the original package never made it through revu, but i wanted to try just building it first, there's no autogen.sh or anything, so i need to run autotools by hand, i did it in this order: aclocal, autoconf, automake, and autoconf is giving me trouble
[07:06] <ademan> actually, autoconf ran without even this time, automake, however, errored like heck
[08:47] <crimsun> jdong: that's not exactly a "no source change necessary" for avidemux in 80387
[08:47] <tsmithe> since siretart's recently never here... does anyone here have any experience in using bzr whilst packaging?
[08:49] <LaserJock> tsmithe: what do you need?
[08:50] <LaserJock> tsmithe: you guys should lookinto bzr-builddeb that just got into Feisty
[08:50] <crimsun> reinhard blogged about it as well.
[08:51] <tsmithe> LaserJock, yeah
[08:51] <tsmithe> that's why i wanted siretart partly
[08:51] <LaserJock> I might try it out today
[08:52] <tsmithe> thing is; it seems so unclean to have to hack about with the diff or move the .bzr directory when using bzr and debuild
[08:52] <crimsun> some people don't remove .bzr
[08:52] <crimsun> and there's always filterdiff
[08:53] <LaserJock> well, that's why bzr-builddeb does an export
[08:53] <tsmithe> that's what i mean by hacking about with the diff
[08:53] <tsmithe> filterdiff
[08:53] <crimsun> that's moot with 'export'
[08:53] <LaserJock> the thing about using version control is that often times you don't want the meta info in there
[08:53] <tsmithe> hmm
[08:53] <tsmithe> i'll look into it
[08:53] <tsmithe> i don't really know what you mean
[08:54] <LaserJock> tsmithe: just grab bzr-builddeb and try it out
[08:54] <tsmithe> kk
[08:54] <LaserJock> an export is when you take a version control repo and just copy the files to a different dir
[08:54] <tsmithe> ah ok
[08:55] <LaserJock> and by "you" I mean the version control app
[08:55] <tsmithe> i know
[08:55] <tsmithe> :)
[08:55] <crimsun> so, toby, do you want to maintain alsa?
[08:55] <tsmithe> err ok
[08:55] <tsmithe> i could try
[08:56] <tsmithe> would be good experience
[08:56] <crimsun> this is not an off-the-cuff question, btw. It will eat your time alive, and you need to be willing to dedicate approximate 40 hours a week to it.
[08:56] <crimsun> +ly
[08:56] <tsmithe> hmm
[08:56] <tsmithe> lemme work this out
[08:57] <ScottK-laptop> crimsun: When my libspf2 patch failed earlier today....  What tools/commands do you use to apply the patch?  I'm trying to understand what went wrong and would like to try and replicate what went wrong when you did it before I muck with the patch...
[08:57] <crimsun> on the upside, you'll learn git, mercurial, mantis, and much more
[08:57] <tsmithe> yeah
[08:57] <tsmithe> what kind of things are the most time consuming, then?
[08:58] <crimsun> ScottK-laptop: I grabbed the latest Debian source package and applied your debdiff
[08:58] <crimsun> tsmithe: triaging and testing
[08:58] <tsmithe> ok
[08:59] <crimsun> tsmithe: if you're interested, join the ubuntu-audio team
[08:59] <tsmithe> ok
[08:59] <tsmithe> i think i am
[09:00] <tsmithe> testing as in what, however?
[09:00] <crimsun> good question.
[09:00] <LaserJock> crimsun: gathering volunteers *cough* victims *cough*
[09:00] <LaserJock> ?
[09:00] <crimsun> writing fixes, testing them; integrating upstream fixes, testing them
[09:01] <crimsun> LaserJock: it would be discourteous to leave without some infrastructure in place.
[09:01] <tsmithe> crimsun, i love this: "If you are filing a bug pertaining to ALSA, please first read the following URL:"
[09:02] <crimsun> yes, and people _don't_ read it
[09:02] <tsmithe> as if most bug-filers are going to read that! :)
[09:02] <tsmithe> yeah!
[09:02] <tsmithe> :P
[09:02] <crimsun> if they'll read a wiki page, they _might_ read an LP comment
[09:02] <crimsun> it just goes to show that most people simply don't read
[09:03] <tsmithe> yeah
[09:03] <tsmithe> show me an example of a poor bug report then
[09:03] <crimsun> look at the one that that comment is attached to
[09:03] <crimsun> but really, you can look at virtually _any_ bug reported using LP
[09:04] <ajmitch> hello peoples & others
[09:04] <crimsun> hello
[09:04] <tsmithe> hi ajmitch
[09:04] <LaserJock> hi ajmitch 
[09:04] <fernando> hey ajmitch 
[09:05] <crimsun> ScottK-laptop: specifically, dpkg-source -x, then patch -p1 --dry-run
[09:06] <ScottK> Thanks.
[09:09] <enyc> Hrrrm.... does anybody understand why some things in /usr/share/fonts/X11/misc/ but xorg looking in /usr/share/X11/fonts/misc/  ?
[09:09] <enyc> im confused!
[09:11] <enyc> noting this system has been upgraded dapper>edgy i think...
[09:12] <enyc> so might have old xorg conf or other problem
[09:12] <crimsun> it is part of the transition, yes
[09:13] <tsmithe> crimsun, how do you maintain support for dapper, edgy? i assume you run feisty
[09:13] <crimsun> for the most part, because fontconfig is used (see /etc/fonts/fonts.conf ), it didn't matter which dir was used for 6.10
[09:13] <crimsun> tsmithe: I support 5.10, 6.06, 6.10, and 7.04
[09:13] <crimsun> tsmithe: I actually run 5.10
[09:13] <enyc> crimsun: l
[09:13] <enyc> crimsun: erm i didnt seem to get fontconfig until I installed it, I thought
[09:14] <ajmitch> crimsun: still looking for poor suckers for alsa?
[09:14] <tsmithe> ajmitch, yeah ...
[09:14] <crimsun> ajmitch: I'm getting 'em, too.
[09:14] <tsmithe> crimsun, them? anyone else?
[09:14] <tsmithe> he says, hopefully :P
[09:14] <crimsun> of course
[09:15] <crimsun> I wouldn't leave you with people who don't do very much audio triaging 
[09:15] <tsmithe> oh good
[09:15] <tsmithe> that makes me feel better
[09:15] <enyc> hrrm no... i must have had fontconfig
[09:15] <enyc> anyway
[09:15] <enyc> so...
[09:16] <enyc> where do fonts work? which dir is new and old?
[09:16] <enyc> and how do i list which fonts the x-server is actually seeing ?
[09:17] <crimsun> xlsfonts
[09:18] <crimsun> they're both used; see the aforementioned file
[09:18] <crimsun> xorg.conf may list /usr/share/X11/fonts[/...] 
[09:18] <enyc> xlsfonts  cooo! thanks
[09:18] <enyc> right... but it actually reads fonts.conf instead (or in addition) ?
[09:19] <crimsun> fontconfig uses /etc/fonts/fonts.conf
[09:19] <enyc> but what 'uses' fontconfig ?
[09:20] <tsmithe> crimsun, tell me... how should i get started? what's the first thing you do every day in relation to alsa?
[09:21] <tsmithe> i just don't think i have 7 hours every day spare, that's all... but i quite see the opportunity
[09:21] <tsmithe> hmm
[09:24] <crimsun> tsmithe: my workflow is essentially: triage bug mail, update my local git repos against BenC's, trawl upstream bug tracker (mantis), trawl upstream mercurial (hg) alsa-{kernel,driver,utils,lib}, read upstream alsa-devel, read pkg-alsa-devel (on alioth), create/pull any patches in, build+test, solicit testing, etc.
[09:26] <crimsun> tsmithe: if you'd like to ease into it, you could begin by generating a git patch to send to kernel-team@lists.uc containing ac97 quirks that were lost between 6.10 and 7.04
[09:26] <crimsun> (obviously I'll assist)
[09:26] <tsmithe> hehe "ease"...
[09:26] <crimsun> enyc: that would be all GTK+-2 and Qt3+ apps
[09:27] <crimsun> enyc: so for all practical purposes in {Ed,K,X,}ubuntu, just about everything in the shipped CD(s)
[09:28] <tsmithe> quirks? in what sense?
[09:28] <crimsun> tsmithe: now the more interesting side is in userspace, like what will happen with pulseaudio and alsa-{libs,utils}
[09:28] <tsmithe> yeah
[09:28] <tsmithe> that's what i'm interested in :)
[09:28] <enyc> crimsun: i seee but not the x-server itself ?
[09:28] <tsmithe> (of course)
[09:29] <crimsun> tsmithe: most manufacturers never follow the specification
[09:29] <tsmithe> ah
[09:29] <tsmithe> so how do you mean, "lost"?
[09:30] <crimsun> between 5.10, 6.06, and 6.10, we collected a ton of AC'97 quirks
[09:30] <tsmithe> mmhmm
[09:30] <crimsun> various computers need certain quirks to allow binding of volume keys to certain mixer elements
[09:31] <tsmithe> oh right
[09:31] <enyc> the odd thing i noticed (not ubuntu specific) is that OSS sb16 works fine but ALSA sb16 will only work with a pnp sb16/32/64 card............
[09:31] <crimsun> enyc: i.e., "true" PnP cards.
[09:32] <enyc> even if told to use specific settings and everything -- not sure i have tried softconfig'ing the card then loading linux without reboot
[09:32] <enyc> where OSS just works fine on them... bah
[09:32] <crimsun> there are bugs about that; Scott and Matthew have discussed it unceasingly. Blame broken MODALIAS.
[09:33] <crimsun> tsmithe: if you don't have an appreciation for the strong hand that Microsoft forces on developers of hardware to be given driver certification, you'll see its positive sides very quickly
[09:34] <crimsun> there're essentially _zero_ audio chipsets that don't need quirks of some sort
[09:34] <crimsun> hence we have AC'97 quirks, HDA quirks, USB quirks, ...
[09:35] <enyc> crimsun: hrrm what about recent requirments to apparently keep much hardware spec secret to get tilt-bit-support "securty-by-obscurity" drivers-locked-to-hardware-quirks for aacs certification  mess ?
[09:36] <enyc> crimsun: is this going to cause problems in linux-driver-land ?
[09:36] <crimsun> enyc: thankfully not very much has touched audio chipsets
[09:37] <tsmithe> hmm
[09:37] <enyc> crimsun: hrrm bit i wonder where this mess is going
[09:37] <crimsun> that I don't know, else I'd have gotten out of this business a long time ago
[09:37] <enyc> crimsun: ;-)
[09:38] <enyc> crimsun: erm... so why are these font dirs changing? is this changed in debian etch too?
[09:38] <crimsun> yes, we inherited the change from Debian
[09:39] <enyc> crimsun: dapper uses old dirs, edgy usually supports both (fontconfig programs....), feisty only puts files in new location?
[09:39] <tsmithe> so wait... there are quirks even though Microsoft enforces driver certification... i don't quite understand... surely certification should mean conformance to specs, right?
[09:40] <crimsun> tsmithe: it does for "them", yes
[09:40] <tsmithe> ooohhh
[09:40] <tsmithe> right.
[09:41] <crimsun> for the most part, FLOSS doesn't get the benefit of the doubt; there's a lot of poking, proding, trial by error, etc.
[09:41] <crimsun> prodding
[09:41] <tsmithe> that's sad
[09:42] <enyc> well this means FLOSS that is looked-at/used tends to get well-fixed hence reliable ?
[09:42] <crimsun> more reliable, generally
[09:43] <enyc> crimsun: I would like to know if feisty is _supposed_ to only be using /usr/share/fonts/X11 for x11-fonts and no-longer us /usr/share/fonts/X11/
[09:43] <crimsun> enyc: I don't have a fresh 7.04 env; check the Herd-2 desktop CD
[09:44] <tsmithe> hang on...
[09:44] <tsmithe> so you really do run breezy?
[09:44] <crimsun> did you think I was joking?
[09:44] <tsmithe> yes
[09:44] <tsmithe> hence, "/me doesn't believe you!"
[09:45] <crimsun> chroots are good things.
[09:45] <tsmithe> so you run breezy and have a chroot for everything else
[09:45] <enyc> crimsun: fair-enough... thanks for comments ;-)
[09:46] <crimsun> tsmithe: across most computers, either 5.10 or 6.06 is the base; all have 6.10 dist-upgraded to 7.04
[09:46] <tsmithe> but why?
[09:47] <crimsun> ever tried troubleshooting/debugging/testing a fix for a release that you're not running?
[09:47] <tsmithe> ah
[09:49] <crimsun> In any case, I don't plan to leave Ubuntu in the lurch; there's definitely a need for a stronger ubuntu-audio team (essentially it has been me for one year)
[09:49] <tsmithe> yeah
[09:49] <tsmithe> i can see
[09:49] <tsmithe> i'd definitely like to learn how to help out
[09:49] <tsmithe> no...
[09:49] <tsmithe> i definitely will learn how to help out
[09:49] <enyc> crimsun: initial reading file-lists seems to suggest all is in /usr/share/fonts/X11/ -- most likely all put there in debian ...
[09:49] <crimsun> I learned just about everything from watching Thomas Hood, who previously single-handedly maintained ALSA in Debian
[09:50] <tsmithe> ok
[09:50] <tsmithe> i'll watch you
[09:50] <tsmithe> follow you to your meetings
[09:50] <tsmithe> to hong kong
[09:50] <crimsun> nope, don't watch me; track all those resources I've mentioned
[09:50] <tsmithe> ok
[09:54] <tsmithe> right
[11:22] <jdong> crimsun: hmm? what do you mean,  that's not exactly a "no source change necessary" for avidemux?
[11:27] <jdong> crimsun: I'm sitting here puzzled about the FTBFS'es recorded for ffmpeg and avidemux....
[11:27] <jdong> pkgmaintainermangler: Error: /build/buildd/ffmpeg-0.cvs20060823/debian/ffmpeg-dbgsym/DEBIAN/control already contains an Original-Maintainer field; aborting
[11:28] <jdong> and avidemux complains about a translation file missing
[11:28] <jdong> both of which didn't happen in my pbuilders.... :(
[11:30] <geser> jdong: install pkgbinarymangler in your pbuilder and enable it
[11:31] <geser> if you rebuild the package now you should get these messages also
[11:55] <rexbron> any revu admins here?
[11:57] <tsmithe> this file - soma_2.3.1-0ubuntu1.dsc - i take it :P