[00:01]  * cheguevara kindly asks for review of http://revu.tauware.de/details.py?package=kcoloredit-kde4
[00:05] <imbrandon> cheguevara: have you looked at the lintian and linda warnings ?
[00:05] <cheguevara> yeah
[00:05] <cheguevara> all bogus
[00:05] <imbrandon> newer-standards-version 3.7.3 (current is 3.7.2)  <-- isnt exactly bogus
[00:06] <imbrandon> i havent verified the rest
[00:06] <imbrandon> ahh wait
[00:06] <cheguevara> the server is wrong :P
[00:06] <imbrandon> i read that backwords
[00:06] <imbrandon> right i thought you had .2
[00:06] <cheguevara> :)
[00:07] <imbrandon> is there a reason you have cdbs makefiles in the debian/tree ?
[00:08] <cheguevara> its how all kde4 packages are I believe
[00:08] <cheguevara> Riddell would know better
[00:08] <imbrandon> no, *some* where in gutsy because it wasent in cdbs in gutsy yet, but hardy includes those
[00:09] <imbrandon> and you also have some in the debian/cdbs tree that arent even used, looks like you only use kde.ml
[00:09] <Riddell> the kde 4 kde.mk file isn't in cdbs
[00:09] <imbrandon> kde.mk*
[00:09] <persia> imbrandon: hardy doesn't have all of them yet (but it does have kde.mk)
[00:09] <imbrandon> Riddell: it looks like its the old one /m looks
[00:10] <cheguevara> imbrandon, cmake.mk should be used as well
[00:10] <imbrandon> right i see its refrenced in the kde.mk
[00:10] <imbrandon> hrm
[00:12] <imbrandon> cmake and kde are both in cdbs, Riddell is that a diffrent kde.mk and cmake.mk ?
[00:12] <Riddell> imbrandon: yes
[00:13] <Riddell> kde 4 has an entirely different build system to kde 3
[00:13] <imbrandon> hrm seems like they should be renamed to debian/cdbs/kde4.mk then to avoid confusion
[00:13] <imbrandon> Riddell: i know that
[00:13] <imbrandon> but i thought the mk file was smart enough
[00:14] <Riddell> we don't want to rename it, that would be unnecessary diff from debian
[00:14] <imbrandon> ahh it was -0ubuntu1 i assumed it wasent in debian
[00:14] <cheguevara> but main ones are
[00:14] <cheguevara> main kde 4 packages that is
[00:15] <cheguevara> in experimental
[00:15] <imbrandon> cheguevara: is this package in debian ?
[00:15] <Riddell> no
[00:15] <cheguevara> no
[00:15] <imbrandon> umm then ..... /me is confused
[00:16] <imbrandon> how would it be a diff from debian if its not in debian ?
[00:16] <cheguevara> kdebase, kdelibs, etc are in debian though
[00:16] <imbrandon> right
[00:16] <cheguevara> and its kinda strange to use diff names for .mks across different kde 4 packages
[00:16] <Riddell> because the packaging he's using comes from our main kde 4 packages, and that comes from debian
[00:16] <imbrandon> ahh i see now
[00:16] <imbrandon> ok
[00:18] <imbrandon> cool ok other than that looks good to me, let me poke one last thing then i'll advocate
[00:18] <imbrandon> cheguevara: ^^
[00:18] <cheguevara> imbrandon, cool, thanks
[00:21] <cbx33> ping nixternal
[00:22] <nixternal> yo yo pete
[00:22] <cbx33> howz it going
[00:22] <cbx33> so just saw your blog about kde4
[00:22] <cbx33> can i try rc2 on gutsy?
[00:22] <nixternal> working on a java project that is whooopin' my arse
[00:22] <cbx33> is it easy?
[00:22] <cbx33> oh
[00:22] <nixternal> yes you can use rc2 on gutsy
[00:22] <cbx33> easily?
[00:22] <cbx33> howto anywhere
[00:22] <nixternal> kubuntu.org
[00:22] <cbx33> it's 0:22 and I'm a little beat
[00:23] <cbx33> thanks
[00:23] <nixternal> under the release announcement
[00:23] <nixternal> should be one of the top stories if it isn't the top story
[00:25] <cbx33> thanks
[00:25] <cbx33> got it
[00:25] <cbx33> just been writing a howto on maemo and scratchbox
[00:25] <cbx33> :)
[00:29] <cbx33> does that get dolphin too?
[00:46] <harrisony> Im packaging a python program and is pysupport better than pycentral or it doesnt really matter or the other way around
[00:50] <somerville32> I prefer pysupport
[00:50] <LaserJock> I like pycentral
[00:51] <LaserJock> I think it really doesn't matter so much which you choose
[00:51] <txwikinger> anybody ever tried to use pbuilder on a mounted drive?
[00:51] <harrisony> Hmm, guess its pycentral, as pysupport is not working :)
[00:52] <somerville32> txwikinger, You kind of have to :P
[00:54] <txwikinger> somerville32: :P
[00:54] <persia> harrisony: The only useful argument I've ever seen between the two is that pycentral allows you to specifically exclude some directories from byte-compilation at install-time (but this was in the past, so pysupport may have caught up)
[00:54] <txwikinger> I get an error when Iuse it on a sshfs mounted drive
[00:54] <somerville32> pysupport is cleaner in my mind
[00:56] <harrisony> pysupport works now, so i guess its that :)
[01:01] <harrisony> err
[01:02] <harrisony> what do you add to debuild -S to make it include the orig.tar.gz
[01:03] <LaserJock> -sa
[01:09] <pwnguin> woa. tracker config applet
[01:16] <harrisony> can i get someone to look at this and tell me why pbuilder isnt building me a deb i used debuild -S -sa and then pbuilder-dist hardy ../*.dsc
[01:16] <harrisony> http://pastebin.ca/819545
[01:17] <LaserJock> harrisony: it looks like it worked
[01:17] <LaserJock> harrisony: where are you looking for the .deb
[01:17] <harrisony> ls .. that has the orig.tar.gz and the changes files but no deb
[01:17] <harrisony> Oh wait
[01:17] <harrisony> stupid me
[01:17] <harrisony> hahahahah
[01:18] <harrisony> sorry for got to look in ~/pbuilder
[01:18] <harrisony> There it is hehe
[01:24]  * harrisony makes first revu upload
[01:31] <harrisony> oops, uploaded the wrong version of the package
[01:31] <persia> harrisony: parcellite?
[01:32] <harrisony> persia: yep
[01:32] <persia> harrisony: Are you a member of contributors to Ubuntu universe?
[01:33] <cheguevara> imbrandon, you still around
[01:33] <harrisony> persia: yep
[01:33] <persia> harrisony: Odd.  The package got rejected.  Usually that's a keyring issue.
[01:34] <harrisony> persia: i did change my gpg key 2 days ago
[01:34] <persia> harrisony: That might be it.  Is the new key in LP?
[01:34] <harrisony> persia: yea
[01:35]  * persia syncs the keyring, just in case
[01:36] <LaserJock> persia: did you go to bed?
[01:36] <persia> LaserJock: For a bit: I needed to retrieve my Zaurus.
[01:40] <persia> harrisony: 3A161F13?
[01:40] <harrisony> persia: yep
[01:51] <persia> harrisony: Imported.  Unfortunately, I don't seem to be cool enough to delete your packages from the incoming directory, so it might need someone else before you can upload.
[01:51] <harrisony> persia: thanks, and ahh, i see
[01:52] <imbrandon> cheguevara: yea
[01:52] <imbrandon> cheguevara: i had to reboot
[01:52] <cheguevara> imbrandon, cool, just wanted to say i uploaded a new revision
[01:52] <persia> imbrandon: Can you delete from /srv/uploads on revu?
[01:52] <cheguevara> 'cause Riddell fount some stuff
[01:52] <imbrandon> persia: yea, why ?
[01:53] <persia> imbrandon: parcellite needs to die
[01:53] <imbrandon> k one sec
[01:53] <harrisony> DIE!!! I TELL YOU DIE!!!!!!!!
[01:53] <persia> cheguevara: You'll get the best quality package if you have lots of different reviewers.  Best to ask for someone new, rather than checking back with the person who reviewed the package last time.
[01:54] <cheguevara> persia: just trying to get people that know about kde packaging most of the time, ie Riddel 'cause some kde related things
[01:54] <imbrandon> persia: done
[01:54] <persia> cheguevara: Understood,  Still, more eyes is better, and there's bunches of things that aren't KDE that are easy to miss :)
[01:54] <persia> imbrandon: Thanks.
[01:55] <persia> harrisony: Try uploading now.
[01:55] <imbrandon> cheguevara: then ScottK hobbsee and others as well as myself are kde people :)
[01:55] <imbrandon> harrisony: be sure to rm *.upload localy first too
[01:55] <persia> cheguevara: apachelogger also, and a very active reviewer.
[01:55] <cheguevara> yep i always get apachelogger to review my uploads
[01:55] <harrisony> persia and imbrandon: thanks
[01:55] <imbrandon> np
[01:56] <harrisony> didnt apachelogger have surgery
[01:56] <harrisony> or something and was in hospital
[01:56] <imbrandon> bbiab , videocard issues <detaches>
[01:56] <cheguevara> but yeah kcoloredit-kde4 is there for review :)
[01:58] <persia> cheguevara: You've modified the upstream tarball without a get-orig-source rule.  This means it's hard to reconstruct.  Please add such a rule.
[01:59] <LaserJock> hmm, and why is the upstream tarball modified?
[01:59] <persia> LaserJock: licensing from SVN.  Unfortunately necessary.
[02:00] <LaserJock> eww
[02:00] <persia> LaserJock: Why?  Better than a SVN snapshot, no?
[02:01] <LaserJock> yeah, but messing around with licensing isn't nice
[02:01] <cheguevara> persia, do you have an example rule please
[02:01] <cheguevara> or is it just a @wget
[02:03] <persia> cheguevara: https://wiki.ubuntu.com/PackagingGuide/Basic#ChangingOrigTarball has a few examples for repacks.  Add additional steps as required.  In your case, I'd recommend adding a watch file, and starting with a uscan call.
[02:03] <cheguevara> persia, is it really worth the effort? because RC 2 of all KDE will be out pretty soon and tarball won't have to modified anymore
[02:04] <cheguevara> i mean RC 3
[02:04] <persia> cheguevara: depends on whether you think it will get through revu before RC 3 is out.  Not many will advocate without checking your upstream tarball, and if it's known modified, without at least some description of the process to create it.
[02:04] <somerville32> Is anyone working on the u-u-s queue?
[02:05] <persia> somerville32: Several people.  Why?
[02:06] <cheguevara> persia, i already got one package through revu  with the same thing (a COPYING file) added + plus Riddell said it was fine to just modify it
[02:06] <cheguevara> I don't mind doing it though, if you think its a good idea :)
[02:06] <somerville32> persia, More specifically, is anyone working on the u-u-s queue at the moment? If there are, I'd stay up a bit incase they get to my items and if not then I'll go to bed.
[02:06] <persia> cheguevara: You got lucky, and Riddell would be one of the "Not many" mentioned above.
[02:06] <somerville32> *than
[02:07] <persia> somerville32: Go to bed.  The queue is currently at around 9 hours since the bug was last touched.
[02:07] <LaserJock> cheguevara: you should at least document it somewhere, at a minimum
[02:07] <cheguevara> its in the debian/changelog
[02:08] <somerville32> cheguevara, Put a note in readme.debian or smething
[02:08] <cheguevara>   * Upstream tarball modified to include copyright files from svn
[02:08] <somerville32> cheguevara, Yes but the changelog will get populated and that note might be harder to spot later on.
[02:09] <persia> cheguevara: That you modified it is in debian/changelog.  Policy says that modified orig.tar.gz must be described in debian/copyright, and that packagers may optionally provide a get-orig-source rule rather than a shell script in debian/copyright.  Whether you have get-orig-source or not, you want a watch file.
[02:09] <LaserJock> and you should say specifically what files where changed
[02:11] <cheguevara> right
[02:11] <cheguevara> so add a watch file and put the changed files in copyright?
[02:12] <persia> cheguevara: That's the quick & dirty way to be policy compliant.
[02:12] <persia> (which might be fine, given that RC 3 is out soon).
[02:13] <cheguevara> is there good example of a watch file somehwere as well
[02:13] <cheguevara> *somewhere
[02:14] <cheguevara> or is it just version=x and url on the next line
[02:15] <cheguevara> plus the stuff from ChangingOrigTarball
[02:15] <persia> cheguevara: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch is an overview.  man uscan for details
[02:16] <cheguevara> thanks
[02:16] <cheguevara> also got http://revu.tauware.de/details.py?package=kmldonkey-kde4
[02:33] <gouki> imbrandon: pong
[02:38] <cheguevara> persia, re-uploaded kcoloredit
[02:46] <imbrandon> gouki: heya
[02:47]  * Hobbsee waves
[02:47]  * Fujitsu waves.
[02:47] <bddebian> Hello Hobbsee :-)
[02:48] <Fujitsu> Hi bddebian, imbrandon, Hobbsee.
[02:48] <bddebian> Heya Fujitsu :)
[02:48] <Hobbsee> heya Fujitsu, bddebian, imbrandon
[02:48] <harrisony> hey /names
[02:49] <imbrandon> heya all
[02:49] <LaserJock> hi Hobbsee
[02:49] <Hobbsee> heya LaserJock!
[03:14] <LaserJock> hmm, Georgia?
[03:14] <crimsun> eh?
[03:15] <LaserJock> imbrandon said he changed his font to Georgia
[03:15] <imbrandon> yea all but my mono spaced font is georgia now
[03:16] <imbrandon> i love that font, and my mono spaced one is Dejvu Sans
[03:16] <crimsun> I use Calibri for all but the fixed width, which is Consolas
[03:17] <Fujitsu> Those are Vista core fonts, aren't they?
[03:17] <imbrandon> not that i'm aware
[03:18] <imbrandon> they are probably msttfonts because i use them both on windows too though
[03:18] <Fujitsu> Calibri would be the Office 2k7 interface font.
[03:18] <imbrandon> ahh i thought you ment mine
[03:19] <crimsun> yes, they are core Vista fonts AFAICT
[03:19] <jcastro> crimsun: I do the exact fonts
[03:19] <jcastro> calibri is quite awesome
[03:20] <harrisony> If only pbuilder told me how much it needed to download left before i can build this package
[03:20] <StevenK> jcastro: But it isn't free to distribute?
[03:20] <crimsun> I don't believe it's Free.
[03:20] <jcastro> StevenK: I am pretty sure it is not.
[03:21] <jcastro> I am actually kicking the tires on the Liberation ones right now
[03:21] <StevenK> jcastro: Tut tut. :-P
[03:21] <crimsun> Liberation is pretty nice.
[03:21] <jcastro> yeah, they're not bad at all
[03:22] <crimsun> I've been digging through fonts ever since Kees's post
[03:22]  * imbrandon dident see kees post
[03:22] <imbrandon> blog or ML ?
[03:22] <crimsun> (http://www.outflux.net/blog/archives/2007/12/12/search-for-a-crisp-monospace-true-type-font/)
[03:22]  * imbrandon looks
[03:22] <LaserJock> crimsun: that kinda messed me up
[03:23] <LaserJock> I must have done something wrong
[03:23] <Fujitsu> LaserJock: The code just doesn't like the lack of ponies, sorry.
[03:23] <cheguevara> :P
[03:23] <imbrandon> really i just love the numerals in the MS TT Core font Georgia, if i could have another font for the letters and the numerals Georgia it would rock
[03:34] <cheguevara> imbrandon, the "W" is a bit funy
[03:34] <imbrandon> StevenK / jcastro / crimsun : see how it blurs real bad in the blogpost ( but not most anywhere else where georgia or mono is used )
[03:35] <imbrandon> like the words "hinting" and "lines" on the last sentance in the blogpost
[03:36] <imbrandon> cheguevara: heh thats Georgia ( I assume you mean the "W" on the program interfaces )
[03:36] <cheguevara> yeah :)
[03:46] <LaserJock> imbrandon: hmm, but you like the serif font everywhere?
[03:46] <imbrandon> yea
[04:24] <LaserJock> interesting, just saw an OLPC commercial on TV
[04:25] <StevenK> LaserJock: Ponies!
[04:27] <Burgundavia> LaserJock: http://www.youtube.com/OLPCFoundation
[04:28] <harrisony> Hmm, im trying to build a package for this python application but it wont run and i think its a bug in the program
[04:28] <harrisony> can i get someone try install the program and tell me if its a bug in the program or me
[04:46] <LaserJock> hmm, I wonder if this laptop harddrive Load_Cycle thing is really an issue
[04:47] <persia> LaserJock: Yes and no.  Depends on the specific hardware.  It's a moving part, so can wear out.
[04:48] <jdong> LaserJock: yeah it definitely shortens disk life, but to what extent, I don't know.
[04:48] <LaserJock> in Ubuntu Daemon's blog it says I shouldn't have more than like 90-160 cycles/day
[04:48] <jdong> LaserJock: I have a mobile terminal (laptop in a high-shock environment) that I put on -B 1 and it has 4.5 million load cycles
[04:48] <LaserJock> my laptop is getting 3k
[04:48] <jdong> LaserJock: it's "supposed" to last 600,000 load cycles
[04:48] <jdong> LaserJock: yet it still works. Be the judge :-/
[04:49] <LaserJock> jdong: what do you mean by -B 1
[04:49] <persia> It's a MTBF sort of thing.  Due to the number of DOA devices, the tail is fairly long.  Backups are good.
[04:49] <jdong> LaserJock: most aggressive power mgmt setting
[04:49] <jdong> LaserJock: basically park the head as soon as activity is done
[04:49] <LaserJock> ah
[04:50] <jdong> what the blog article complains about
[04:50] <persia> jdong: Do you also have aggressive caching, or do you restart whenever anything happens?
[04:51] <jdong> persia: just generic laptop-mode, it doesn't feel terribly aggressively cached
[04:52] <persia> jdong: Ah, so maximum park frequency :)
[04:53] <jdong> yeah, because I'm too lazy to tune it
[04:53] <jdong> my rationale is, the parking makes the data safer when the machine gets bumped, which happens a lot
[04:53] <minghua> Well, my Load_Cycle is at 634,000 mark, and my smartctl tests now fails. :-(
[04:53] <jdong> minghua: I've had 5 maxtors fail on me within 4 months of purchase, none of which were subjected to any power management settings :)
[04:53] <jdong> I don't think there's a strong load_cycle to disk death correlation
[04:54] <minghua> jdong: I know, I know, I've had horror stories with IBM Caviar disks as well.
[04:55] <minghua> I'm not saying my Load_Cycle count is the reason of the test failure, but I suspect they are related.
[04:55] <persia> Well, I'd suggest that the higher the load_cycle, the higher the chance that the little arm breaks, but the chance may remain completely miniscule.
[04:55] <jdong> it might be a small contributing factor...
[04:55] <minghua> (I have been running Debian on that laptop, by the way.)
[04:56] <minghua> Hmm.  I wonder what else is wrong with my harddrive, then.
[04:57] <jdong> random chance....
[04:57] <minghua> It's an uneasy feeling to know you laptop hard disk can fail anytime.
[04:57] <LaserJock> I'm up to 467059
[04:58] <LaserJock> and a short scan worked fine, but the indepth one seemed to fail
[04:58] <LaserJock> I suppose compiling a lot will affect it
[04:59] <minghua> Like persia said, backup is always good. :-)
[04:59] <LaserJock> yeah
[05:00] <LaserJock> I've been doing that more often lately
[05:00] <LaserJock> I hope it doesn't die during christmas, I'd be upset
[05:00] <persia> LaserJock: Add a heap of RAM and compile in cache :)
[05:00] <LaserJock> although with no sales tax in Montana it might be a good time to pick up a harddrive
[05:03] <minghua> A 90% sale would offset the sales tax, so it's never a factor to consider for me.
[05:06] <LaserJock> is it worth getting a 7200rpm hard drive for laptops?
[05:07] <crimsun> well, what's important to you?
[05:07] <crimsun> frankly, battery life is to me, so I don't care if it's slower
[05:07] <LaserJock> well, a  pbuilder *not* taking over 1min to unpack would be cool
[05:08] <StevenK> LaserJock: Use sbuild, then
[05:08] <harrisony> cowbuilder pbuilder with copy on write
[05:08] <persia> LaserJock: sbuild helps.  more RAM helps (bad for battery).  Solid-state disk helps.
[05:09] <StevenK> I've never managed to get cowbuilder working to my satisfaction.
[05:09] <StevenK> sbuild with keescook's lovely script just works
[05:10] <LaserJock> StevenK: doesn't that take LVM?
[05:10] <StevenK> In fact, slangasek, keescook and I were having a talk about improving the script at AllHands
[05:10] <StevenK> LaserJock: Right. But you don't have to set your whole machine up as LVM
[05:11] <persia> LaserJock: Yes, but you can do a fair bit with LVM only for that.  I have all my sbuild stuff in a 20GB VG, and can run two simultaneous builds against sid, hardy, or gutsy.
[05:11] <persia> (mind you, I can't build wxwidgets2.8)
[05:12] <StevenK> I have one 250Gb VG, but my machine uses LVM for everything
[05:13] <harrisony> would be nice if pbuilder-uml was fixed, has a broken dep. on rootstrap
[05:13] <harrisony> because pbuilder-uml sounds neat
[05:25] <persia> Could anyone suggest why "ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-?_?([\d+\.]+|\d+)\.tar.* debian uupdate" is failing to match in a watch file?
[05:33] <minghua> persia: What does ?_? mean?
[05:34] <persia> minghua: I believe "-?_?" means zero or one '-' characters followed by zero or one '_' characters.
[05:35] <minghua> persia: I see now.  That a rather complicated regex...
[05:36] <ember> it's appears almost to be a sf.net regex for watch files
[05:36] <Flannel> its gopersist with - and/or _ followed by zero or more numbers with decimals, followed by a number, followed by .tar with anything afterwards.
[05:36] <Flannel> Where "number" is any number of digits
[05:37] <minghua> persia: Can you enlighten me about [\d+\.]+ as well?  I don't understand why + is in the middle.
[05:37] <persia> Flannel: Right.  Somehow it isn't matching anything on ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1 , and I don't understand why.
[05:37] <Flannel> persia: thats because / isnt _ or -
[05:37] <persia> minghua: One or more sets of digits and decimals, followed by one or more digits.
[05:37] <ember> ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-(.*)\.tar\.gz
[05:37] <ember> isn't enough?
[05:37] <persia> ember: .* is not a good idea in perl
[05:37] <minghua> persia: Why are they in the [] brackets then?
[05:38] <Flannel> Oh, right, [ ] isn't right
[05:38] <StevenK> .* in Perl is greedy by default
[05:38] <StevenK> It's better to use a character class
[05:38] <persia> minghua: [baz] means any of 'b', 'a', or 'z'
[05:38] <Flannel> what those brackets should be is [0-9.]
[05:39] <persia> Flannel: Surely you mean \.
[05:39] <StevenK> Heh heh
[05:39] <persia> Anyway, why is "0-9" better than "\d"?
[05:39] <minghua> I don't think you need to escape . in [].
[05:39] <StevenK> persia: It isn't
[05:39] <Flannel> persia: \d can't be used inside of []
[05:39] <ember> ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-([\d.]+)\.tar\.gz
[05:39] <persia> Flannel: Works for all my other watch files :)
[05:39] <minghua> But then again, RegExp is not my native language... :-P
[05:39] <Flannel> ember: [\d.] isn't right
[05:40] <Flannel> (\d|\.)
[05:40] <Flannel> would be what that is properly
[05:40] <Flannel> or rather (\d+|.)
[05:40] <StevenK> [\d\.]+
[05:40] <Flannel> StevenK: Escaping inside of square brackets?
[05:40] <persia> StevenK: So just drop the final [\d]+ ?
[05:41] <StevenK> I'm digging through perlre
[05:41] <Flannel> There is no escaping inside of square brackets
[05:41] <ember> regex is evil
[05:41] <persia> Flannel: Yes.  It needs escaping there too.
[05:41] <Flannel> both of those \ are literal \s
[05:41] <persia> ember: Only because there are so many flavours
[05:41] <minghua> So debian/watch uses the Perl version?
[05:41] <StevenK> Flannel: No, they aren't. I have perlre in front of me now
[05:42] <minghua> s/version/flavor/
[05:42] <persia> Flannel: I know \d inside square brackets works, so I'm sure I don't agree with that.
[05:42] <Flannel> . isnt
[05:42] <Flannel> \d works
[05:43] <persia> minghua: Yes.  Debian watch is interpreted by uscan, which is in perl.  Amusingly enough, you can execute almost anything in a watch file if you are careful.
[05:43] <Flannel> special characters inside of [ are \ ] ^(when at the beginning) and -
[05:43] <Flannel> . isnt, nor is *, etc
[05:43] <StevenK> steven@liquified:~% echo 0000 | perl -ne 'if (/[\d]+/) { print "Flannel is wrong\n"; }'
[05:43] <StevenK> Flannel is wrong
[05:43] <Flannel> \d works . doesnt
[05:43] <Flannel> you dont escape . inside of square brackets
[05:44]  * persia does, successfully
[05:44] <Flannel> of course [\.] will work, but it'll also match \
[05:44] <persia> Flannel: But [.(that other thing) doesn't work.
[05:45] <Flannel> \. thats ecaping the ., but its a regular ., so it may still work, but I wouldnt bet on it working everywhere
[05:45] <persia> Flannel: Sure.  I only expect it to work that way in perl.
[05:45] <Flannel> Ah
[05:45] <Flannel> POSIX has \ not being a special character inside of square brackets
[05:46] <Flannel> so it depends on whether youre using POSIX or PCRE
[05:46] <persia> Flannel: Right.  For sed, awk, etc.  You'd have been correct, except we should have been using \( and \) for the match string :)
[05:46] <minghua> persia: The "+" in bracket in your original pattern still doesn't make any sense to me.
[05:47] <Flannel> minghua: Thats because it shouldnt.  He meant one or more of \d, but its inside of brackets, so it doesnt work like that
[05:47] <persia> minghua: I believe it is a literal '+'.  I'm not sure.  That regex was generated by watchwiz.
[05:47] <minghua> persia: I read it as a literal +, too.
[05:48] <Flannel> Its treated as a literal, whether thats what you want or not...
[05:48] <persia> Flannel: It oughtn't break anything, right?
[05:49] <Flannel> persia: it'll only give you a false positive
[05:49]  * persia would be happy with any positive match, even false
[05:50] <Flannel> What are you trying to match on?
[05:50] <persia> ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-0.1.1.tar.gz
[05:50] <persia> (or whichever version they put there tomorrow)
[05:51] <Flannel> gopersist[-_](\d+\.?)+tar\.gz
[05:51] <Flannel> that's how I'd write it
[05:52] <minghua> If you don't mind false positive, what is wrong with ([\d.]+)
[05:52] <minghua> ?
[05:52] <persia> Flannel: That doesn't match 0.1.1
[05:52] <Flannel> persia: Why not?
[05:52] <persia> Flannel: Well, it does, but it matches in three chunks.  I need a single chunk (as I'm not writing the perl code that uses it)
[05:53] <persia> minghua: I might try that (with the missing \ restored
[05:54] <Flannel> Oh, you need to match the whole file number as $1?
[05:54] <persia> "ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-([\d\.]*)\.tar.*" doesn't work either :(
[05:54] <persia> Flannel: Yep.
[05:54] <Flannel> persia: So, well, you could do this:
[05:55]  * persia tries escaping the / characters
[05:55] <Flannel> gopersist[-_]((\d+\.?))+\.tar\.gz
[05:55] <minghua> persia: Curious.
[05:55] <Flannel> That'll put the whole thing in $1, then you'll have $2, $3, $4 ... for the pieces
[05:56] <persia> Flannel: I'm writing for interpretation by uscan.  I'm not able to do cool nifty thngs, unfortunately (despite you being mostly correct).  Further, I think you meant gopersist[-_]((\d+\.?)+)\.tar\.gz
[05:57] <Flannel> Isnt that what I... oh, no its not, but yes, thats what I meant
[05:58] <LaserJock> persia: and you want watch files for everything? ;-)
[05:58] <persia> Although this would be useless for the intended purpose, "ftp://ftp.gnome.org/pub/GNOME/sources/gopersist/0.1/gopersist-(.*)" doesn't match either, which I find very odd.
[05:59] <persia> LaserJock: Yes, so we can keep track.  Most just work.  This one is annoying for some reason.
[06:00] <Flannel> But yeah, I'd just move to character classes.
[06:00] <Flannel> persia: Do you need to escape anything?
[06:00] <Flannel> As in, escape for the parser
[06:00] <persia> Flannel: I tried escaping the '/' characters, but then it couldn't figure out the protocol.
[06:00]  * persia goes off to read uscan source
[06:03] <minghua> persia: Maybe try http:// protocol?
[06:04] <persia> minghua: Interesting idea.  Doesn't match debian/copyright (but that can be fixed).  Also means I can separate the URL from the regex, making it easier.  Thanks.
[07:12] <warp10> Hi all!
[07:17] <\sh> moins
[07:23] <LaserJock> woah, crimsun's got a lot of uploads
[07:23] <LaserJock> 10x as many as I do
[07:24] <TheMuso> c
[07:24] <StevenK> Way cool, I'm still in the top ten
[07:24] <TheMuso> wrong tab
[07:25] <LaserJock> shesh, dholbach's got 40 times as many as me
[07:25] <persia> LaserJock: For big counts, chase NBS, watch files, or source-maintainer-mangling.  Usually pretty fast (although I like to make the watch-files also lintian/linda clean)
[07:26] <StevenK> LaserJock: Is that ever, or Hardy?
[07:26] <LaserJock> ever
[07:27] <persia> For hardy, I think TheMuso has the lead
[07:27] <StevenK> LaserJock: Then I suspect I have a lot more than you do as well
[07:27] <TheMuso> persia: Not for long though.
[07:27] <LaserJock> I'm doing some -changes greping
[07:27] <TheMuso> And really, I don't care about upload stats.
[07:27] <LaserJock> StevenK: umm, yeah ...
[07:27] <persia> TheMuso: You're high enough you might make top-ten for hardy: seems to be a big gap between around 100 and around 250.
[07:28] <TheMuso> Yeah, if I keep up contributions top ten is possible, but again, I don't care.
[07:28] <TheMuso> Its not how many uploads one does, but the quality of those uploads.
[07:29] <LaserJock> if only we had a good metric for quality
[07:30] <LaserJock> haha
[07:30] <LaserJock> not included Hardy, doko has 5073 uploads
[07:30] <persia> TheMuso: I'd agree with that.  In some ways, lots of uploads might well mean uploading the same thing over and over to get it right.
[07:31] <TheMuso> persia: Yeah, and the only reason I lead is due to the libglib1.2 transition.
[07:32] <persia> TheMuso: That's a good reason.  NBS is something we should all do more to fix.
[07:32] <superm1> persia, well it can also mean lots of bug fixing on the same thing though too
[07:32] <TheMuso> Its actually scary just how many packages use that dated library.
[07:33] <persia> superm1: If I test something, and fix all the bugs, and it takes me three weeks, then I only need to upload once.  If the changelog tends to have batches of three or four uploads every day or two for a while, that indicates weak testing (see some of the changelogs of the top 10 updated packages).  Note that in many cases, it's easier to test with an upload than to test locally (especially for odd-arch things).
[07:34]  * TheMuso finally managed to get hardy synced today. I now have a full gutsy+hardy i386+powerpc+source local mirror.
[07:34] <\sh> so
[07:34] <superm1> persia, ah i see.  the way i've been doing things (with my limited time this cycle at least) has been going through and picking a selection of bugs to fix for a given package, say mplayer.  fix those 5-10 bugs, test and upload.  i don't know for sure when i'll get back to more bug fixing, so i see it as better to upload them at that point
[07:35] <persia> superm1: I can understand that workflow, and think it's good if there is uncertainty as to when you get back to it, but I suspect those uploads are of lower quality than if you fixed and tested all in one session (assuming you had the time)
[07:37] <superm1> LaserJock, well developing a metric wouldn't be very difficult I suspect though.  Assuming everyone is properly putting in (LP: #XXXX) in their bugs, parsing changelogs to find out how many launchpad bugs are closed could be a good metric
[07:39] <persia> superm1: Skews for people without upload access, who always get an extra bug closure.
[07:40] <superm1> well if people would consistently accredit [ Name ] in their changelogs that can be adjusted could it not?
[07:40] <Hobbsee> persia: prevents people working in tandem, or with the updated sourc,e though
[07:40] <Hobbsee> persia: isn;'t that the reverse idea of bzr?
[07:41] <dholbach> good morning
[07:42] <TheMuso> Hey dholbach.
[07:42] <superm1> Hobbsee, well that would depend on how long that "one session" was i'd have to say
[07:42] <superm1> Hobbsee, and how religiously items are committed to bzr (eg commit for every bug fix or what not)
[07:42] <superm1> morning dholbach
[07:42] <dholbach> hey TheMuso, hey superm1!
[07:43] <Hobbsee> superm1: well, of course
[07:50]  * persia notes that with more attention, Hobbsee would have been advised that it depends on what one is doing: in the case of a BZR like-system, makes sense for everyone to commit their changes and decree it good before someone uploads to the archive.  In the case of lonely universe packages, maybe it doesn't matter.
[07:50] <persia> (more attention on my part)
[07:50] <\sh> hey dholbach
[07:51] <dholbach> heya \sh, hey persia
[07:51] <persia> Hi dholbach
[08:04] <\sh> oh well, all my christmas present are already delivered.....new job, money, new kitchen ;)
[08:06] <gouki> \sh: Congratulations :)
[08:07] <\sh> gouki, thx :)
[08:07] <\sh> from the 1st of February I can call myself a senior it systemadministrator...FUN !
[08:09] <gouki> Unix administrator, \sh ?
[08:13] <slytherin> Hi. I want to add watch file for an application which is hosted on sourceforge. Can anyone provide sample watch file?
[08:15] <warp10> slytherin: https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch
[08:26] <slytherin> warp10: Thanks. :-)
[08:45] <\sh> gouki, yepp and cisco stuff
[09:10] <geser> morning
[09:23] <TheMuso> Could anybody point me to the logs from the session that persia ran about reading stack traces?
[09:30] <Flannel> Why am I getting X11 errors when trying to prevu libode back to dapper?  All of the sudden it tries to grab x11 packages, and I can't see why on earth it wants them.
[09:33] <huats> dear motus good morning
[09:34] <dholbach> hey huats
[09:34] <huats> hey dholbach
[09:35] <BugMaN> dholbach: hi :)
[09:35] <dholbach> heya BugMaN
[09:36] <txwikinger2> hi dholbach
[09:37] <dholbach> heya txwikinger2
[09:37] <dholbach> how are y'all doing?
[09:37] <txwikinger2> I am working on this dependency issue for hardy
[09:37] <txwikinger2> and the source does not even compile and is >14 month old
[09:37] <txwikinger2> ans cvs
[09:37] <dholbach> dependency issue for hardy?
[09:37] <txwikinger2> well a package
[09:38] <txwikinger2> attal or soemthing like that
[09:38] <dholbach> ah I see
[09:38] <txwikinger2> there is a new rc on the homepage
[09:38] <txwikinger2> which actually compiles
[09:38] <txwikinger2> shouldn't we use that instead?
[09:39] <txwikinger2> It is a game .. beta-version as it seems
[09:43] <txwikinger2> hehe debians version is even older than ours :)
[09:44] <txwikinger2> I would put this new version on revu, right?
[09:44]  * persia has lost context, but is this is an updated package, an interdiff in a bug is preferred,
[09:44] <persia> s/is/if/1
[09:45] <txwikinger2> ok.. can do that
[09:45] <txwikinger2> I will do some testing of the game itself first though
[09:46] <txwikinger2> or better I let my son do that :D
[09:46] <persia> That's always good.  Which game?
[09:46] <txwikinger2> attal
[09:46] <txwikinger2> Have to first check if it is age-appropriate though
[09:49] <LucidFox> KDE applications can't be under GPLv3 or later, can they?
[09:50] <TheMuso> persia: Was there ever a log made of that session about reading stack traces? Or did that session not occur?
[09:50] <persia> TheMuso: There was a log, but only on irclogs.ubuntu.com.
[09:50] <persia> TheMuso: Are you chasing one now, and want another pair of eyes?
[09:51] <TheMuso> persia: No, I'd like to read the log to see what was covered in the session.
[09:51] <TheMuso> As I wasn't there, and would like to have a read.
[09:52] <txwikinger2> We made should have a references from the Debugging Page or the MOTU School to it
[09:53] <txwikinger2> s/made/maybe/
[09:53] <persia> Ah.  I'll dig it up then.  At a quick overview, I introduced what stacktraces were (badly).  We walked through one until most people had some idea where the problem was.  We then looked at a couple more (which had no clear solution) to experiment with the techniques and see what we could discover.
[09:53]  * txwikinger2 thought the session was very helpful
[09:53] <TheMuso> persia: ah ok
[09:54] <txwikinger2> .. and still thinks so
[09:55] <persia> TheMuso: http://irclogs.ubuntu.com/2007/11/17/%23ubuntu-classroom.html starting from the top.  For value, you'll want to also be looking at the mentioned traces, and walking through the code.
[09:56] <persia> txwikinger2: Have you successfully debugged a crash using those techniques?
[09:56] <txwikinger2> persia: I haven't really found a suitable bug afterwards
[09:56] <persia> txwikinger2: Are you a member of crash bug triagers for universe?
[09:56] <TheMuso> persia: Yeah I thought so, but wanted somewhere to start, to learn more about them. Thanks.
[09:57] <txwikinger2> THe ones I saw didn't have the trace created yet when I looked at them
[09:57] <persia> txwikinger2: The trick is to subscribe to the bug, and hit the trace when it comes :)
[09:57] <txwikinger2> However, I feel comfortable they I know what to do when I see one :)
[09:57] <txwikinger2> persia: ok.. I will do that from now on
[09:57] <persia> TheMuso: I'd be happy to walk you through one that is happening in your code (or a pet bug) if you like.
[09:57] <persia> (takes about an hour to track one down, usually)
[09:58] <persia> txwikinger2: Good luck :)
[09:58] <TheMuso> persia: There is one that would be good, let me dig it up after I'm off the phone.
[09:58] <txwikinger2> I think I do some paid work for a change... four days left
[09:58] <persia> TheMuso: Sure.
[10:25] <TheMuso> persia: bug 147969  is a crash bug that I reported via apport a while back, and would like to investigate.
[10:25] <ubotu> Bug 147969 on http://launchpad.net/bugs/147969 is private
[10:26] <TheMuso> wha
[10:26] <TheMuso> didn't notice that
[10:29] <TheMuso> Ok. bug 147969
[10:29] <ubotu> Launchpad bug 147969 in speech-dispatcher "sd_espeak crashed with SIGSEGV in snd_pcm_state()" [Medium,New] https://launchpad.net/bugs/147969
[10:30] <persia> TheMuso: OK.  Looking now.
[10:31] <persia> First, does anyone mind if TheMuso and I trace this bug in-channel?
[10:32]  * persia takes silence for assent
[10:32] <persia> OK.  We'll start with Stacktrace (retraced), which tends to be most informative.
[10:32] <TheMuso> ok
[10:33] <persia> This is a pretty simple one, with only 9 frames.  Each frame represents a point on the stack, so the program called #9, which called #8, etc. until the crash at #0.
[10:33] <persia> I usually like to start about #3 or #4 to build some context.  This is the espeak package?
[10:34] <TheMuso> No, a package that uses espeak. The executable links libespeak
[10:34] <TheMuso> so sd_espeak links against libespeak.so.1
[10:35] <persia> TheMuso: OK.  So which is likely to be the relevant source to start?  The top looks like alsa, so I think we want to start around #6 or #7.
[10:35] <TheMuso> persia: THis problem lies within the speech-dispatcher code.
[10:36] <persia> OK.Let's start at #7 then (espeak.c:615)
[10:37] <TheMuso> ok
[10:38] <persia> So, the starting point should be far enough back that you're sure you're not in a library, and far enough forward to understand what is happening.  YOu might be able to start further up, but please have patience for my unfamiliarity with the code.
[10:38] <TheMuso> sure
[10:38] <persia> So, when starting, one tries to understand the context of what is happening.  In this case, we're calling a stop_or_pause, and will want to check under what conditions this is called.
[10:39] <TheMuso> right
[10:39] <persia> espeak.c:615 is the point from which we call the listed function.
[10:39] <TheMuso> yep
[10:40] <persia> Err.. I seem to have the wrong version of the code :(  Hold on a bit...
[10:40] <TheMuso> pull gutsy's
[10:40] <TheMuso> and its src/modules/espeak.c
[10:41] <TheMuso> THis problem has not been fixed since then, I am certain of that.
[10:41] <persia> The newer code looks different enough that I was having trouble following, so I think you are correct.
[10:41] <TheMuso> right
[10:42] <TheMuso> THere are some patches in the speech-dispatcher package but they don't go anywhere near that code
[10:43] <persia> So to me it looks like we're polling a lock every 5milliseconds to see if the audio stopped properly, and we're passing the ID that we want to stop.  Does that match your understanding of this bit?
[10:43] <TheMuso> yea
[10:44] <persia> OK.  That's a nice safe place to be: not a lot of conditions.  Looking back at the stacktrace, we can see that espeak_audio_id was null (0x0) for the call that crashed.
[10:45] <persia> So, moving to #6, let's look at spd_audio.c
[10:45]  * persia applies all the patches, just in case
[10:45] <TheMuso> I can't find espeak_audio_id in the trace
[10:47] <slicer> Today is revu day, right?
[10:47] <persia> The trace says "_espeak_stop_or_pause (nothing=0x0)", which means that the function was called with the arguments in the parentheses.  At the time of passing, it's anonymous (pass by value), but we know it was espeak_audio_id from espeak.c:615, as that was what it was called.
[10:47] <persia> slicer: Yep.
[10:47] <TheMuso> persia: ah ok.
[10:48] <persia> So, looking at spd_audio_stop (src/audio/spd_audio.c:234), it's a fairly simple function.
[10:48] <TheMuso> yep
[10:50] <persia> Since we're told it's line 234, and #5 is alsa_stop, it's probably safe to say it is the ->stop call that causes the problem.  In this case, we're passing an id, which is probably a pointer to the new value for espeak_audio_id.
[10:50] <TheMuso> right
[10:51] <persia> Now one of the things we look for when we move through the stack is branches and conditionals to build context.  In this case, we know it means the minimal interface, so somehow (0x0)->function->stop has been instantiated.  Perhaps through the nature of the AudioID type.
[10:52] <TheMuso> right
[10:53] <persia> We'll keep in mind that AudioID when initialised with null becomes 0x8087500 (taken from the stacktrace), and look at it later if we think the initialisation routines might be the issue.
[10:53] <TheMuso> ok
[10:53] <persia> So, do you want to lead us into #5, od shall I do another first?
[10:54] <TheMuso> persia: Another please, I still don't quite get the hang of this.
[10:54] <persia> Sure.  You're with it so far for #6 right?
[10:54] <TheMuso> All I can tell from 5 is that the same id gets passed to alsa_stop
[10:54] <TheMuso> Yes.
[10:55] <persia> That's as much as the stacktrace tells us about #5 :)  We'll want to look at the code to figure out what is happening.
[10:56] <TheMuso> righ
[10:56] <TheMuso> right
[10:56] <persia> So, `find . -name alsa.c -print` from the package directory tells me we can find alsa.c in ./src/audio/alsa.c, and the stack trace tells me we want to be looking around lije 738
[10:57] <TheMuso> yep I gathered that much as well
[10:58] <persia> So, opening that source, we read the alsa_stop function to see what is happening.  The stacktrace reports buf = 42, and we can see that in the code, so we've entered the if statement.
[10:58] <TheMuso> right
[11:00] <persia> Line 738 is actually a MSG, which is likely a log note of some sort, and #4 tells us that the problem is in snd_pcm_state().  The address tells us that id->alsa_pcm is a pointer to 0x80a03d0.
[11:00] <TheMuso> right
[11:00] <persia> There's still not much branching or anything that could be a clear issue (our data is valid, we're using it, etc.).  So, we move to #4.  Give it a shot.
[11:02] <persia> Err.  My apologies: this is maybe a hard boundary to try.  We'll need to pull a different source :)
[11:02] <TheMuso> alsa-lib I presume.
[11:02] <persia> Sounds like a good candidate
[11:02] <slicer> Oh, the horror.
[11:03] <persia> slicer: Which?
[11:03] <slicer> persia: alsa-lib.
[11:03]  * persia is not doing very well at avoiding alsa today
[11:03] <TheMuso> heh
[11:03] <TheMuso> ok got it up here
[11:03] <persia> TheMuso: Yep.  ./src/pcm/pcm.c in alsa-lib (1.0.14)
[11:04] <TheMuso> yep
[11:05] <persia> So tell me about it.  What can we learn from here?
[11:06] <slytherin> ideally what should be name of .orig.tar.gz if it is a beta version?
[11:06] <TheMuso> that something is being returned to the calling function, which is alsa_stop in speech-dispatcher, something to do with fast ops.
[11:06] <TheMuso> so far I can't work out more than that without digging deeper
[11:06] <persia> slytherin: I like goodstuff_7.2.8~beta1.orig.tar.gz
[11:07] <slytherin> persia: thanks
[11:07] <TheMuso> persia: So snd_pcm_state is being given the alsa client id I presume it is.
[11:07] <persia> TheMuso: Right.  One of the key skills with reading stacktraces is not to care what things mean too much, as long as you can make a guess.  When you find the crash, then you start understanding the pieces you need.  Otherwise, one has to learn the whole body of source.
[11:08] <TheMuso> right
[11:08] <TheMuso> Which gets assigned by alsa-lib when things are initialized.
[11:09] <persia> The only thing to note is that espeak_audio_id->alsa_pcm->fast_op_arg is 0xb5e00468
[11:09] <TheMuso> ok
[11:09] <persia> (just to keep track of our variable)
[11:09] <TheMuso> yes
[11:10] <persia> So, let's go to #3: your lead.
[11:11] <TheMuso> looking...
[11:13] <TheMuso> Ok. in pcm_rate.c:1117 snd_pcm_rate_state is being passed a value I don't know about...
[11:14] <persia> TheMuso: OK.  Let's look at the function step-by-step.  First, we initialize snd_pcm_t = espeak_audio_id->alsa_pcm->fast_op_arg (0xb5e00468)
[11:14] <persia> Err, that shoud be "pcm = espeak_audio_id->alsa_pcm->fast_op_arg (0xb5e00468)"
[11:15] <TheMuso> Right.
[11:15] <persia> Then, we set rate = pcm->priivate_data which is espeak_audio_id->alsa_pcm->fast_op_arg->private_data
[11:15] <persia> Then we check to see if it is in a pending state, and it's not (or we would have been bounced back to #4 from line 1116)
[11:16] <TheMuso> Right. Sorry, got slightly confused that we were dealing with function pointers.
[11:16] <persia> Then we call snd_pcm_state with espeak_audio_id->alsa_pcm->fast_op_arg->private_data->gen.slave
[11:16] <persia> (0xb5e00810)
[11:17] <TheMuso> right
[11:17] <persia> And that pushes us to #2 (as we're now in a new function call)
[11:17] <TheMuso> yep gathered that
[11:19] <persia> It's the same call we saw before that told us almost nothing, except that we now have the extremely ungainly espeak_audio_id->alsa_pcm->fast_op_arg->private_data->gen.slave->fast_op_arg (0xb5e00810)
[11:19] <persia> And that sends us to #1.  You again.
[11:21]  * TheMuso finds his head start to spin with all these function pointers.
[11:21] <dfiloni> persia: if I do a package for a single pidgin plugin do you know if the package will be add to the repository?
[11:22] <persia> TheMuso: Yep.  As you've just seen, we're further building the stack, and bounce back to snd_pcm_state where we finally die, perhaps from having too much recursion :)
[11:22] <persia> dfiloni: I'd suggest asking in #ubuntu-desktop.  They may have good advice about how to bundle the plugin to get it accepted to the repository.
[11:22] <TheMuso> so we add generic-slave to that long stack
[11:23] <dfiloni> persia: ok thanks
[11:23] <persia> Well, generic is pcm->private_data, so we get ...->private_data->slave, and then pass that back to the calling function.
[11:23] <TheMuso> err generic->slave
[11:24] <TheMuso> ah right
[11:24] <persia> Right.  generic->slave == pcm->private_data->slave == espeak...
[11:24] <persia> (= 0xb5300710)
[11:24] <TheMuso> right
[11:25] <persia> So, now we get the fun part: deciding where to fix it.
[11:25] <TheMuso> I guess thats why I'm still slightly confused as to what the problem actually is.
[11:26] <TheMuso> besides a null id being in #6
[11:26] <persia> It looks to me like ALSA is hopelessly confused by the object at 0x80a03d0, which likely means something wrong with espeak_audio_id (0x8087500)
[11:26] <TheMuso> #7 even
[11:26] <TheMuso> right
[11:26] <persia> Well, we had a value by #6, so I'm guessing that the AudioID initialiser set that somehow.
[11:26] <TheMuso> Whats even more interestnig though, is that this is a rare crash. I don't have apport on to ensure this at the moment, but the ods of it happening are low.
[11:26] <persia> I expect so, yes.
[11:27] <persia> When it's an easily reproduced crash, the solution usually leaps out before one gets this deep, often a set before use, or parsing failure or bad size assumption or something.
[11:28] <persia> In this case, I think we have three choices: 1) wade into ALSA and somehow force it to provide useful error messages instead of segfaulting when given data that causes annoying recursion.
[11:28] <TheMuso> yeah I thought as much.
[11:28] <persia> 2) Hunt down the AudioID initialisation routines and add more safety checks to make sure we only generate a useful value that ALSA can handle,
[11:29] <TheMuso> 2) in alsa?
[11:29] <persia> or 3) (my favorite) add an exception handler to alsa_stop that catches the segfault, and warns the user that the device could not be stopped.
[11:29] <persia> 2) in speech-dispatcher
[11:30] <persia> (also 3) in speech-dispatcher)
[11:30] <TheMuso> right
[11:30] <albert23> persia: thread 2 also works on the same pcm value: #3  0xb7bf0a92 in snd_pcm_close (pcm=0xb5e00810) at pcm.c:710 Could that be a problem?
[11:31]  * persia notes that albert23 is reading http://launchpadlibrarian.net/9669460/ThreadStacktrace.txt
[11:31] <TheMuso> right
[11:32] <albert23> especially since the crash occurs random, could that be a race condition?
[11:32] <persia> albert23: I do believe you're right.
[11:32] <TheMuso> Thats what I thought as well.
[11:33] <persia> In that case, maybe the exception handler should just trap the segfault, wait 5 milliseconds, and try again?
[11:34] <persia> (in alsa_stop)
[11:35] <TheMuso> Yeah that could be done, now I'm just working out where the exception would go, and in what form.
[11:36] <persia> Or would the exception handler properly belong in espeak_stop_or_pause, so as to keep sending null IDs until one works?
[11:36] <TheMuso> persia: The things is, this race condition is likely to be a problem for all drivers that speech-dispatcher has that use the alsa_stop function.
[11:37] <TheMuso> If we fix it in alsa_stop, it benefits at least 3 drivers.
[11:37] <persia> TheMuso: Quite possibly true.
[11:38] <persia> TheMuso: before you get all arms deep in the code developing the solution, do you have any questions about reading a stacktrace?
[11:39] <TheMuso> persia: At this point no. I've a log of the channel and the stacktrace file, I just got a little lost with the pointers, but it makes sense. If I was to read it again along with the channel log, it will be clearer.
[11:40] <persia> TheMuso: don't worry too much about the pointers.  We went down a rabbit hole :)  As long as you now understand the frames, and how to trace them, I'm happy.  Feel free to ask me again if you have any troubles in the future.
[11:40] <TheMuso> persia: Ok thanks for your help, and yes, I now understand the frames.
[11:41] <TheMuso> I guess the only question I do have is, whats the point in having the other threads traced above this one? WOuld have they been useful in tracking this down?
[11:41] <TheMuso> I am guessing they're there for cross-threading issues that could be a problem.
[11:41] <persia> Generally I find that the thread that generates the segfault usually has the error, but the ones I find that I can do anything about are always coding mistakes.
[11:42] <persia> For a race condition, or other cross-threading issue, the other threads can provide clues (as albert23 found the same address being used by the other thread in this example)
[11:42] <TheMuso> right
[11:42] <TheMuso> Right.
[11:43] <LucidFox> TheMuso, what's the status of bug #175937?
[11:43] <ubotu> Launchpad bug 175937 in qink "Please sync qink 0.3.4-1 from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/175937
[11:44] <TheMuso> LucidFox: I'll get to it right away. At the time, I wasn't sure whether the autosyncer would get run another time before DIF.
[11:44] <LucidFox> Ah.
[11:45]  * persia encourages bug comments to communicate this type of information.
[11:45] <TheMuso> Yeah, I should have done that, but I wasn't even sure whether DIF had kicked in etc, and I asked in here about it and got no response. Then I got sidetracked.
[11:46] <persia> heh
[11:47] <TheMuso> persia: WOuld I be checking for a NULL value for id->alsa_pcm?
[11:47] <persia> TheMuso: Depends on how you want to handle it.
[11:48] <TheMuso> persia: I was thinking about within alsa_stop.
[11:48] <persia> Method 1 is proscriptive: make sure everything is set correctly before you pass the data.
[11:48] <persia> Method 2 is reactive: as you know this call might get a segfault, trap it and do something else when it happens.
[11:48] <_ruben> question.. openswan is currently at 2.4.6 in gutsy, the latest openswan release is 2.4.11 .. the 2.4.x tree contains only bugfixes .. any chance newer versions will be made available for gutsy? or does this also fall outside the scope of 'no version changes within releases'?
[11:50] <persia> I tend to code in Method 1 for simple stuff (do I exist?  am I the right type?), and Method 2 for tricky stuff (this sometimes breaks: I don't know why, therefore I'll just expect it to break sometimes and handle it gracefully)
[11:51] <TheMuso> right
[11:51] <TheMuso> I'll dig deeper into the code then. I've found where the audio_id gets initialized, so will have a poke.
[11:51] <TheMuso> persia: Thanks again.
[11:51] <persia> _ruben: That would fall under "no version changes within releases".  However, each of the individual bugs fixed by the newer versions may be considered for application to the version released in Gutsy.  Someone would need to document the bugfixes, work with the sru team to determine which are appropriate for a stable release, and prepare a patch containing those fixes to be applied to 2.4.6 in gutsy (wcich would still be 2.4.6)
[11:52] <persia> TheMuso: I'm very happy to share: more people reading stacktraces means more people chasing apport bugs means better quality code.  Maybe enough will happen that my system won't crash anymore :)
[11:53] <TheMuso> heh yeah
[11:54] <_ruben> persia: hmm ok.. 2.4.x is concidered stable by both dev'ers and users of openswan, so i guess they (the dev'ers) would say all changes between versions are candidates for inclusion in stable releases .. guess i'll go bug the dev'ers as well .. their debian/ dir got stuck at 2.4.0 :p
[11:54] <TheMuso> Hrm no. I am still thinking within alsa_stop may be better, since its an alsa recursion craziness issue, as espeak_audio_id gets opened at the start of the session, and remains current till the process is killed.
[11:54] <TheMuso> ...or segfaults. :p
[11:56] <TheMuso> LucidFox: Just test-building qink now.
[11:56] <persia> _ruben: It's not about being considered stable, it's about maintaining the same interface and changing as little as possible to avoid introducing any new bugs.  IF upstream is maintaining as a stable release, then it's likely that some of the upstream bugs may meet the critera of "data loss, severe regression, or security issue" that is required for an update to an Ubuntu stable release.
[11:57] <_ruben> ah
[11:57] <persia> TheMuso: That makes sense to me.  I didn't look at the AudioID initialisation code, but I think we would have seen a more significant issue earlier up in the stack if the initialisation failed.
[11:57] <TheMuso> persia: yeah
[12:00] <persia> _ruben: Just to expand on that a little, Ubuntu does have a backports repository.  If 2.4.11 gets into hardy, and someone can verify it builds & works on gutsy, and submits a bug to the backport team, and the backporting process gets several testers from the official backport build, it can go into the gutsy-backports repository, which tends to contain as much of the newest versions that have been requested for backporting.
[12:01] <TheMuso> persia: You said earlier that it could perhaps trap the segfault, wait 5 seconds, and try again. What form would the try again take? Since it is multi-threaded, is it that the variable will likely have a value in it due to another thread's activities?
[12:01] <persia> !backports | _ruben
[12:01] <ubotu> _ruben: If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[12:01] <TheMuso> So that would be tried
[12:01] <_ruben> persia: ah ok, but that'd take a while i guess? even the "if 2.4.11 gets into hardy" part ..
[12:02] <persia> TheMuso: Remember at the beginning where we were in a loop polling every 5 milliseconds for the stop?  I was just thinking to repeat that lower in the stack if we only got part way.  I didn't really analyse it too deeply.
[12:03] <TheMuso> persia: ah ok.
[12:03] <persia> A basic "try again" would be something like "Try this catch segfault sleep 5000 try this exit".
[12:04] <persia> An alternate way to do it would be to catch the segfault, and return a value such that the earlier loop repeated again.  This allows different drivers to handle the polling in different ways.
[12:04] <TheMuso> Right
[12:04] <persia> _ruben: Takes a couple weeks if there are testers willing to verify the application.
[12:05]  * TheMuso looks at alsa_stop again, noticing that it only ever returns 0.
[12:05]  * persia thinks "0" means "success" in this context
[12:05] <TheMuso> Yet the ret is checked for anon-zero value in espeak.c, and one will never ever come.
[12:05] <TheMuso> Yes it does, but there is no other value returned in the event of any failure.
[12:05] <TheMuso> Its like they don't think it will ever fail
[12:06] <persia> TheMuso: in which case espeak.c is written properly, and alsa_stop should trap the segfault and return a non-zero value (42?)
[12:06] <TheMuso> Yeah.
[12:06] <_ruben> persia: an alternative would be to roll my own package (im aware of the risks), that is: take existing package and "upgrade" it to newer version .. any hints/tips/urls on best-practices in that area?
[12:06] <TheMuso> Anyway, this is a task for tomorrow. Night folks, and persia, thanks once again for your assistance. Much appreciated.
[12:07] <persia> _ruben: There's a page on the wiki describing the process.  I'd suggest submitting the result for sponsors review, which helps you learn, reduces the risk of danger, and is part of the path towards a backport.
[12:08] <_ruben> persia: i'll have a look, thanks
[12:08] <persia> Were I doing it, I'd rather cherrypick the SRU-worthy bugs from 2.4.11 and apply them to 2.4.6 than try to manage the new upstream.  Helps millions of people that way.
[12:09] <persia> TheMuso: Could I ask you one small question about speech-dispatcher before you go?  Specifically, how to you maintain speech when using JACK?
[12:09]  * persia currently stops speech-dispatcher, does JACK stuff, restarts speech-dispatcher
[12:10] <TheMuso> persia: Well since I don't use jack very often, I don't worry about it. Secondly, I've a large monitor, so any jack stuff is done without speech, and 3rdly, I've more than one card. I use my onboard card for speech, and my envy24-based cards for jack.
[12:10] <persia> TheMuso: Ah.  It's probably the third part I want then :)  Thanks.
[12:10] <TheMuso> I actually hope to get speech-dispatcher to replace gnome-speech in Ubuntu in the future, as its more flexible.
[12:11] <persia> TheMuso: is gnome-speech the thing I've been hearing about that locks /dev/dsp exclusively?
[12:11] <TheMuso> persia: Its more portaudio v18 and espeak. V19 has alsa issues.
[12:12] <TheMuso> Gnome-speech doesn't deal with sound cards, it lets the synth drivers do what the hell they want.
[12:12] <persia> Ah.  Right.  Portaudio18.
[12:13] <TheMuso> And so far, wrapping it in padsp has not yielded very good results.
[12:13]  * persia hasn't tried gnome-speech: speech-dispatcher just looked like the right thing.
[12:13] <TheMuso> persia: THe only drawback for the gutsy version at least, is that it has to run system wide.
[12:14] <TheMuso> However, for 0.6.5, they have added options to run it per user.
[12:14] <TheMuso> I plan to more tightly integrate it with a user's session.
[12:14] <TheMuso> and use its pulseaudio backend.
[12:14] <TheMuso> that it now has.
[12:14] <persia> TheMuso: That will be interesting.  Not important to me (I don't share), but I suspect it suddenly makes it possible to support e.g. LTSP.
[12:14] <TheMuso> Exactly.
[12:15] <TheMuso> And luckily, all Linux synths, whether open source or proprietary, allow passing audio back to the calling application in their callback.
[12:15] <persia> And given the plans for pulse & JACK, things should work semi-smoothly for hardy (although I should probably also use the onboard for speech).
[12:15] <TheMuso> persia: What pulse and jack plans?
[12:15] <mruiz> hi all
[12:16] <persia> TheMuso: A special whitelist of apps like JACK, skype, etc. that could circumvent pulse trapping to access HW directly, without needing to manually intermediate which devices have what sort of access to the card.
[12:16] <TheMuso> ah
[12:17] <TheMuso> persia: But as it is, I still think speech-dispatcher long term is more flexible, and provides several audio backends. Once a few things are sorted with orca, I'm going to push it to replace gnome-speech, maybe not for hardy, but hardy+1.
[12:18] <persia> No big rush.  By the way, does the new orca that just went in fix the does-not-install issue?
[12:18] <TheMuso> No, that is waiting on brltty, specifically python-brlapi
[12:19] <TheMuso> but that will be sorted in the next day or so I'd say, it needs to be binary newed.
[12:19] <persia> Ah.  Too bad.
[12:19] <persia> Oh.  That's easy then :)
[12:19] <TheMuso> but brltty has been uploaded as well
[12:19] <TheMuso> binary newed, and placed in main.
[12:20] <TheMuso> Anyway, really out of here now.
[12:23] <persia> Good night, and thanks for the advice about speech + jack.
[12:25] <TheMuso> persia: np
[12:57] <zul> freaking snow
[12:59] <txwikinger2> where?
[12:59] <txwikinger2> I want some
[13:00]  * persia is also experiencing a snow shortage: please throw it back up, so it has a chance to get a little further around the globe
[13:00] <txwikinger2> If we get snow now, we will get early holidays
[13:01] <zul> sure you can have 31cm of what we got last night
[13:02] <txwikinger2> I take it
[13:02] <zul> oh sorry 37cm of snow
[13:03] <txwikinger2> take that too :)
[13:04] <txwikinger2> No snow in the forecast here ;(
[13:05] <txwikinger2> Well, I guess this means 3.5 more working days
[13:06] <ScottK> Good morning all.
[13:06] <txwikinger2> Hi ScottK
[13:06] <ScottK> If anyone is looking for an easy merge to do (or perhaps one for their mentee), peercast is available...
[13:06] <ScottK> Hello txwikinger2
[13:07] <txwikinger2> cool... we might have a withe christmas
[13:08] <txwikinger2> white even
[13:49]  * dholbach hugs the MOTU Heroes
[13:51] <imbrandon> moins dholbach ScottK txwikinger2 zul persia and *
[13:51] <imbrandon> ( wow everyone got hilighted )
[13:51] <DaveMorris> would appear son
[13:51] <ScottK> heya imbrandon.  How's the snow?
[13:52] <imbrandon> none new comming, we dident get as much as expected
[13:52] <imbrandon> and still cold as h*ll so its staying on the ground
[13:52] <imbrandon> hehe
[13:52] <ScottK> Good.
[13:52] <imbrandon> but good news is its only 2 or 3 inches and no mroe comming ( soon )
[13:52] <imbrandon> hehe
[13:53] <ScottK> We're heading that way on Thursday and our 13 year old is really hoping for a white Christmas.
[13:53] <ScottK> That should be enough if it stays cold.
[13:53] <imbrandon> yup, it should still be here thursday
[13:53] <imbrandon> the roads are all cleared off now but everywhere else its sticking arround
[13:54] <effie_jayx> ok I am back from my trip and I need a little help
[13:54] <ScottK> Well we're leaving Thursday.  It's a ~21 hour drive, so we'll be there on Friday...
[13:54] <effie_jayx> I want to learn how to read reports from merges
[13:54] <effie_jayx> I was trying to merge mgetty but It got done
[13:54] <imbrandon> ScottK: if your in town for a few days and have time we should grab that coffee/beer while your here
[13:54] <effie_jayx> I have read https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing
[13:55] <effie_jayx> and I get stuck in the part where they start reading the changes
[13:55]  * imbrandon 's birthday is wednesday
[13:55] <ScottK> imbrandon: Definitely.  Gate Bar-q-que
[13:55] <imbrandon> yup yup
[13:55] <ScottK> Gate/Gate's
[13:56] <effie_jayx> http://merges.ubuntu.com/m/mgetty/REPORT no problems where encountered during the merge
[13:56] <ScottK> effie_jayx: Do you want an easy one that still needs doing?
[13:56] <effie_jayx> now If I understand this well I must test the merger by generating a patch and applying it and seeing if it works?
[13:57] <effie_jayx> ScottK,  mmmkeyy
[13:57] <imbrandon> ScottK: heh wife just looked over my shoulder and said "Tell Him Jack Stack is better"
[13:57] <ScottK> You must also review each of the changes and make sure they are still needed.
[13:57] <effie_jayx> but let me  see if I understand how I go about them
[13:57] <zul> snow sucks
[13:58] <ScottK> imbrandon: Jack Stack seems very corporate to me.  Personally, I like Arthur Bryant's the best, but it's on the other side of town.
[13:58] <ScottK> zul: Either get over it or move.
[13:58] <imbrandon> :)
[13:58] <imbrandon> ScottK: yea jack stack was great when it was just "smoke stack" in martin city, but i havent been lately
[13:58] <zul> ScottK: oh i wish i could move
[13:59] <ScottK> effie_jayx: peercast needs doing and only has one small Ubuntu change.
[13:59] <imbrandon> zul: come to KC :)
[13:59] <effie_jayx> ok
[13:59] <zul> imbrandon: not from what I seen on "Cops" ;)
[13:59] <imbrandon> zul: there is plenty of jobs here for your field, i could hook you up with some
[13:59] <effie_jayx> ScottK,  ok.
[13:59] <imbrandon> zul: hahah
[14:00] <ScottK> imbrandon: My actual favorite is a small place in Kansas City, KS called "The Hickory Log".  You won't have heard of it.  I lived near there growing up and we used to go regularly.
[14:00] <imbrandon> ahh yea, no idea about that one
[14:00] <ScottK> zul: You wouldn't want life to be to boring.
[14:00] <ScottK> zul: Oh, wait.  You're Canadian.  ;-)
[14:00] <zul> ScottK: its a national past time to complain about the amount of snow
[14:01] <imbrandon> my actualy fav resturant here in town is Buldogs, its like applebys+bbq but good
[14:01] <imbrandon> lol
[14:01] <imbrandon> bulldogs*
[14:01] <ScottK> Where is that?
[14:01] <imbrandon> 18th and Main
[14:01] <imbrandon> downtown
[14:02] <ScottK> Ah.  I haven't been there.
[14:02] <imbrandon> ( few blocks from where i work hehe )
[14:02] <imbrandon> so we go quite a bit
[14:02] <ScottK> I see.  That makes it easier.
[14:02] <imbrandon> i work just off 20th and broadway, next to the orig Herferd House
[14:03] <imbrandon> and all that stuff
[14:03] <ScottK> Right.  I know just where that is.
[14:03] <ScottK> My Dad's company (when I was growing up) was just across the river in Riverside, MO.
[14:04] <imbrandon> btw where are you now? i thought you were closer than 21 hours away
[14:04] <imbrandon> heh
[14:04] <ScottK> Outside Baltimore, MD.
[14:04] <imbrandon> ahh
[14:04] <effie_jayx> ScottK,  this is the bit I am trying to figure out "You should compare the generated patch against the patch for the Ubuntu version given above and ensure that there are no unexpected changes..." <---- debdiff?   "...You should also sanity check the source package. ..."
[14:05] <imbrandon> for some reason i thought you were on the far side of KC
[14:05] <imbrandon> err kS
[14:05] <ScottK> imbrandon: Heading west we just take turns driving, hand the children to the Grandparents when we arrive, and then go crash.
[14:05] <imbrandon> heh yup
[14:06] <ScottK> effie_jayx: Debdiff is a good way to do it.
[14:06] <ScottK> effie_jayx: Also then look at the updated package from Debian and see if there are any obvious problems with then (generally not).
[14:08] <imbrandon> ScottK: btw i just got done talking to pitti about flash, looks like i'll be doing a modified version of your sugestion, and the current stuff in -porposed just got removed
[14:08] <imbrandon> ScottK: e.g. do the 60mb thing for dapper to gutsy, and new stuff for hardy
[14:08] <imbrandon> not new for hardy + gutsy
[14:09] <imbrandon> i'm actualy working on the script now to do that
[14:10] <ScottK> Cool.
[14:12] <imbrandon> btw before i whip up a shell script anyone know of a cli mass id3 tagger based on filename ?
[14:13] <imbrandon> e.g. where i have the files in "%artist - %song.mp3" and want it to mass remove existing tags and update based on filenames
[14:15] <_ruben> hmm .. wonder what im (obviously) missing here .. i cant get pbuilder to install stuff from universe
[14:16] <imbrandon> _ruben: you have to enable universe in the chroot something similar to ... "pbuilder login --save-after-login" and edit the /etc/apt/sources.list and apt-get update, then exit
[14:16] <_ruben> imbrandon: lets give that a try
[14:19] <_ruben> imbrandon: worked like charm, thanks
[14:20] <imbrandon> np
[14:20] <imbrandon> ( probably want to do multiverse too if you dident , and $dist-updates )
[14:20] <effie_jayx> ScottK, when I read  the REPORT file... and it reads http://merges.ubuntu.com/p/peercast/REPORT
[14:20] <effie_jayx> I get a little lost reading the report and that is bad
[14:20] <imbrandon> $dist-updates only if you are working on a release thats not hardy
[14:22] <effie_jayx> I should compare the generated patch ="generated: 0.1217.toots.20060314-5ubuntu1"
[14:22] <effie_jayx> the ubuntu version prior to that "0.1217.toots.20060314-4ubuntu1"
[14:22] <effie_jayx> am I right?
[14:25] <ScottK> effie_jayx: Yes.  Also look at -4 to -4ubuntu1 to make sure nothing bad got added by the merge scripts.
[14:27] <effie_jayx> ScottK,  and I should look at -5 as wel?
[14:28] <ScottK> effie_jayx: Sorry.  I meant -5 to -5ubuntu1.
[14:28] <ScottK> Got lost in my revisions there.
[14:28] <mruiz> hi all. I need a review for the bug 176714, please ...
[14:28] <ubotu> Launchpad bug 176714 in vpnc "Please merge vpnc 0.5.1r254-1 (universe) from Debian (unstable)" [Wishlist,Triaged] https://launchpad.net/bugs/176714
[14:30] <effie_jayx> ScottK, then I generate one debdiff between patches the old and the new
[14:31] <effie_jayx> when you say check... you man generate a debdiff to see any things added in the debian package that is not in the patch?
[14:35] <ScottK> effie_jayx: Yes.  Look at the debdiff and make sure you understand what changes are there and why (for the Debian changes it's enough to make sure they are documented in debian/changelog).
[14:35] <effie_jayx> ScottK,  fine...
[14:36] <effie_jayx> thanks
[14:39] <ScottK> effie_jayx: You might also look at the change that caused an Ubuntu unique package and see about filing a bug in Debian about it.
[14:40] <ScottK> The goal being to get rid of the diff and go back to being able to use the Debian package unmodified.
[14:41] <effie_jayx> ScottK, debdiffs are long
[14:41] <effie_jayx> most of the changes refer to changes in directories...
[14:41] <effie_jayx> and some depend libs
[14:41] <ScottK> effie_jayx: Even the -5 to -5ubuntu1 diff?
[14:41]  * effie_jayx thinks
[14:41] <effie_jayx> ScottK,  no... just old package to new package
[14:42] <ScottK> effie_jayx: Look at the debian/changelog entry and see if it makes sense.  From reading the changelog, I suspect it does.
[14:47] <effie_jayx> ScottK,  I can see changes done to debian/rules so I guess the -5ubuntu must contain the postrm script...
[14:47] <effie_jayx> should I unpack to check the change in rule?
[14:48] <effie_jayx> the rest of the changes are there
[14:48] <ScottK> Sounds reasonable.
[14:48] <effie_jayx> dependency change
[14:48] <ScottK> Yes.
[14:48] <effie_jayx> and the change of standards
[14:48] <effie_jayx> ScottK,  so unpack and check?
[14:48] <ScottK> Yes.
[14:48] <effie_jayx> ok
[15:04] <hippu> hippu, could someone review my patch to bug #176736?
[15:04] <ubotu> Launchpad bug 176736 in tuxguitar "Tuxguitar isn't building, missing dependency" [Undecided,In progress] https://launchpad.net/bugs/176736
[15:05] <hippu> ugh, i meant hi instead of my own nick
[15:31] <brettalton> have I come to the right place for information on how to make my own repository?
[15:46] <effie_jayx> ScottK2,  I saw the diference in the patches ... everything is there... all changes in the debian/control from the debian source
[15:46] <nxvl_work> Riddell: around?
[15:47] <Riddell> hi nxvl_work
[15:47] <nxvl_work> Riddell: hi, i have a problem with qt4-x11
[15:47] <nxvl_work> Riddell: i have seen it's reported on LP but not worked
[15:48] <nxvl_work> bug #115970
[15:48] <ubotu> Launchpad bug 115970 in qt4-x11 "qtconfig-qt4 doesn't start" [Undecided,Confirmed] https://launchpad.net/bugs/115970
[15:50] <Riddell> nxvl_work: yep, looks like a problem
[15:50] <Riddell> I'm a bit busy for it currently
[15:52] <nxvl_work> Riddell: that ok, did have any idea where the problem can be, so i can check it?
[15:52] <ScottK> effie_jayx: Then I'd say test the new revision, prepare a debdiff, and attach it to a bug.
[15:53] <effie_jayx> ScottK,  cool
[15:54] <Riddell> nxvl_work: could try reverting to an older version of qt4
[15:55] <nxvl_work> Riddell: i mean on the source
[15:56] <Riddell> nope
[16:02] <effie_jayx> ScottK,  ok.. I am building a package
[16:03] <effie_jayx> ScottK,  there is no major bug fix in this one... shall I just report a sync from debian kinda stuff?
[16:05] <ScottK> Does the Debian package have the change that we made in Ubuntu?  If not it's still a merge.
[16:09] <effie_jayx> ScottK,  I tried looking into the change that generated the merges
[16:09] <effie_jayx> but It was only the epiphany sugest
[16:10] <effie_jayx> for epiphany-browser
[16:10] <ScottK> effie_jayx: Yes.  That's the change.  So your debdiff for the merge would include that and the debian/changelog entries.
[16:18] <pochu> Hey MOTUs and MOTU padawans! :)
[16:18] <huats> hey pochu
[16:19] <mruiz> hey pochu :-)
[16:19] <pochu> hey huats and mruiz
[16:19] <RainCT> hi pochu
[16:20] <slicer> If anyone can do a review update of http://revu.tauware.de/details.py?package=mumble , I'm around for the next few hours.
[16:20] <pochu> heya RainCT :)
[16:22] <bddebian> Heya gang
[16:24] <pochu> howdy bddebian
[16:28] <bddebian> Hi pochu
[16:42] <mruiz> bye all
[16:43] <effie_jayx> ScottK, should I add my name to the changelog then?
[16:44] <effie_jayx> new upstream version and that's it?
[16:45] <effie_jayx> ScottK,  just checked debian/control and the epiphany change is there now
[16:49] <ScottK> effie_jayx: It's not a new upstream version, just a new Debian revision and yes, your name should be in debian/changelog
[16:50] <effie_jayx> ScottK,  so... what do I write in the changelog entry.. do I specify all the debian changes...
[16:50] <effie_jayx> ?
[16:51] <pochu> effie_jayx: All the changes you have done.
[16:51] <pochu> effie_jayx: do you know dch? :)
[16:51] <effie_jayx> pochu,  I did nothing
[16:51] <effie_jayx> just test
[16:51] <effie_jayx> the debian mantainer made a lot of changes... I did nothing
[16:52] <pochu> Then it's a sync, isn't it?
[16:52]  * pochu reads backwards
[16:52] <effie_jayx> pochu,  yes
[16:52] <effie_jayx> it was a merge but now the change that originated the merging has been reflected on debian
[16:52] <ScottK> effie_jayx: Did the Debian Maintainer make the dependency change (I don't see it in his debian/changelog)?
[16:52] <pochu> effie_jayx: is the epyphany suggest included in the debian package?
[16:53] <effie_jayx> pochu,  it is not
[16:53] <effie_jayx> there isn't a suggests line
[16:53] <effie_jayx> ScottK,  there isn't a suggests line
[16:53] <effie_jayx> sorry
[16:53] <pochu> effie_jayx: then you need to add it, and document it in debian/changelog
[16:54] <pochu> effie_jayx: for modifying debian/changelog, use the dch tool. It's in the devscripts package.
[16:54] <effie_jayx> pochu,  got it
[16:54] <effie_jayx> pochu,  I know it
[16:54] <pochu> Cool :)
[16:54] <effie_jayx> so let me see...
[17:00] <leonel> scottK hello !  new clamav 0.92.0  Looks like  it's not a  security  update
[17:01] <ScottK> leonel: Thanks for checking.  I looked for you when I got the message.
[17:01] <ScottK> leonel: I agree from looking at the Changelog.  I'm updating the package now.
[17:02] <leonel> ScottK upgrading for hardy ?
[17:02] <ScottK> Yes
[17:02] <leonel> SWEET!
[17:02] <ScottK> We'll let it settle a bit and then do a backport in a few weeks I'd think.
[17:03] <leonel> scottK if you need to test it  just let me know
[17:03] <ScottK> leonel: Will do.
[17:04] <leonel> scottK and not only  for clamav  if there's a package  I can test  just let me know
[17:05] <ScottK> Sure.
[17:14] <effie_jayx> ScottK,  the suggests: is in peercast-handlers where in what file do I add the change
[17:15] <ScottK> effie_jayx: debian/control.  Have a look at the current Ubuntu package to see exactly how.
[17:26] <Kopfgeldjaeger> when i specify a command that deletes a folder in a postrm file (because its not removed automatically), the folder is not there after a reinstall of the package
[17:27] <Kopfgeldjaeger> why?
[17:34] <effie_jayx> ScottK,  I saw it... :D
[17:35] <effie_jayx> ScottK,  sorry... the change is there
[17:37] <effie_jayx> pochu,  the hange is there...
[17:38]  * effie_jayx was looking in the wrong pacage in debian/control
[17:38] <effie_jayx> is there a need for my changelog entry still
[17:38] <effie_jayx> ?
[17:39] <pochu> If all the changes are included in Debian now, then not. You should request a sync instead.
[17:39] <pochu> effie_jayx: ^
[17:40] <effie_jayx> pochu, ok
[17:40] <effie_jayx> pochu,  should I test the package first?
[17:41] <pochu> effie_jayx: a test-build would be nice. If you can test it too the better :)
[17:42] <effie_jayx> pochu,  I'll do both
[17:45] <effie_jayx> thanks ScottK  and pochu ... I learned lots
[17:52] <Ubulette> good, i've fixed my "internal error, failed to initialize HAL!".  no more reboot for a month, at least :)
[17:55] <leonel> scottK just warming up  ..  when I builded  clamav 0.92rc2 no problems now  we got libclamav.so.3
[17:55] <leonel> scottK should all be named  libclamav3 ?
[18:12] <ScottK> leonel: Probably.  Urgh.
[18:14] <\sh> remoins
[18:14] <\sh> ok...now my homedatacenter is ready to rumble....
[18:14] <\sh> /dev/sda6             322G  3,4G  318G   2% /home
[18:15] <\sh> /dev/sdb1             466G  544K  466G   1% /mnt
[18:15] <\sh>  I think that should be enough for hosting some ubuntu archives
[18:17] <warp10> Hi all!
[18:18] <Ubulette> yesterday, i had a dedicated 320G filled with mostly mozilla builds
[18:18] <ScottK> \sh: Have you had a chance to look at the newer WINE package on REVU?
[18:19] <\sh> ScottK, nope...I thought scott ritchie is valuable enough for not having any review at all....
[18:19] <\sh> looks really like that I have to reapply for motuship and push those stuff in
[18:19] <Riddell> nxvl_work: https://bugs.edge.launchpad.net/ubuntu/+source/qt4-x11/+bug/115970/comments/2
[18:19] <ubotu> Launchpad bug 115970 in qt4-x11 "qtconfig-qt4 doesn't start" [Undecided,Confirmed]
[18:19] <ScottK> \sh: OK.  Please do.
[18:19]  * ScottK hasn't had a lot of time to look at stuff recently.
[18:21] <nxvl_work> Riddell: replied, i think it's maybe a depend problem
[18:24]  * RainCT wonders wheter there is a way to filter bugs about crashes to see only those for Python applications
[18:27] <tsmithe> anyone want to review a package for me? mscore (music notation program a la sibelius) is welcome for some love: http://revu.ubuntuwire.com/details.py?package=mscore
[18:29] <joumetal> I have a question about motu-security.
[18:30] <\sh> ok...debmirror --nosource --method=rsync dapper, edgy,feisty gutsy --section=* --arch=i386,amd64 and go
[18:30] <\sh> joumetal, fire
[18:32] <joumetal> there is one bug comment about dapper that says one program has vulnerable version in dapper.
[18:32] <joumetal> I could give number or any information.
[18:32] <\sh> joumetal, which one?
[18:34] <joumetal> bug 117395
[18:34] <ubotu> Launchpad bug 117395 in alsaplayer "Alsaplayer crashes" [Undecided,New] https://launchpad.net/bugs/117395
[18:35] <\sh> joumetal, so , do you have any CVE IDs for those security issues? if there are security fixes for it, we can fix this, but no new upstream version for dapper, sorry
[18:36] <Riddell> nxvl_work: that's old versions of qt, upgrade to the newest
[18:38] <joumetal> CVE-2007-5301?
[18:38] <ubotu> Buffer overflow in the vorbis_stream_info function in input/vorbis/vorbis_engine.c (aka the vorbis input plugin) in AlsaPlayer before 0.99.80-rc3 allows remote attackers to execute arbitrary code via a .OGG file with long comments. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5301)
[18:38] <nxvl_work> Riddell: i have my system up to date
[18:38] <nxvl_work> Riddell: i'm using gutsy
[18:39] <joumetal> smart bot :)
[18:39] <\sh> joumetal, please add this information to the bug report (link CVE) and subscribe motu-swat thx
[18:40] <joumetal> thanks.
[18:41] <\sh> joumetal, and please set the report to a security bug report via set privacy/security...
[18:43] <joumetal> ok done that.
[18:43] <Riddell> nxvl_work: oh, hrm
[18:43] <\sh> joumetal, thx
[18:48] <leonel> scottK many  many  references to libclamav2   those should be changed to  libclamav3  right ??
[18:50] <ScottK> leonel: I haven't had time to really look into it, but I believe that's the case.
[18:51] <leonel> I know  just  guessing  ...
[18:51] <leonel> and tryng to make the new deb  ..  let's see how it goes ..
[19:07] <\sh> hmkmm...does anyone see this,too ? apt-get install linux32 and then it tries to remove ubuntu-minimal?
[19:07] <ScottK> leonel: Because of the soname bump, I'm not going to upload this one right away.  I'm going to wait for Debian to upload it to make sure we don't get cross-threaded.
[19:09] <slangasek> ScottK: which is coming soon, http://lists.debian.org/debian-release/2007/12/msg00113.html
[19:09] <slangasek> (it's already in Debian new queue)
[19:09] <ScottK> slangasek: Thanks.
[19:10] <ScottK> slangasek: I can tell you for one item on that list (klamav), then Debian version in Sid/Lenny is already hopelessly broken so there's no need to even bother with a rebuild.
[19:10] <slangasek> heh
[19:13] <ScottK> slangasek: Do you know the Klamav maintainer: Florent Bayle http://packages.qa.debian.org/k/klamav.html - he seems to have lost interest in Klamav.
[19:13] <Adri2000> Hippuu: around?
[19:15] <slangasek> ScottK: can't say that I do, no
[19:16] <ScottK> slangasek: OK.  I'll see if I can generate some interest around maintaining our package in Debian and if he's willing to give it up.
[19:16] <ScottK> Thanks
[19:17] <Adri2000> Hippuu: I don't know if you were seeking sponsoring for the tuxguitar bug (as u-u-s is not subscribed), but I anyway added a comment about your debdiff
[19:28] <leonel> scottK  clamav 0.92  debs  done  :)  My  first  big update  i mean   changing things in   debian/*   let's see if it installs  and  works  ...
[19:47] <sommer> hey all, is there going to be a qa session on friday?
[19:48] <geser> sommer: iirc will dholbach hold them every friday
[19:48] <sommer> geser: cool just wanted to make sure... with x-mas and all
[19:49] <geser> sommer: try asking dholbach (here during the european day)
[19:49] <sommer> geser: okay, will do
[19:50] <johnny> is the channel meant to be used to just packaging for ubuntu upstream? or also for those who might need help making custom packages until fixed upstream versions are released?
[20:25] <ScottK> RainCT: I'm not sure about the maintainer thing.  I'd send a mail to devel-discuss asking.
[20:26] <poOrBOon> hi
[20:26] <poOrBOon> Everything works :D
[20:26] <poOrBOon> But
[20:26] <poOrBOon> I want my ubuntu look like vista, I just mean the transparent window borders
[20:27] <poOrBOon> do I need emerald?? people don't recommend it
[20:27] <geser> compiz should be enough
[20:28] <poOrBOon> I have compiz.. but do you know a theme that makes my windows look like vista??
[20:28] <poOrBOon> There is none that has transparency
[20:28] <geser> for transparency in the window borders you need emerald
[20:28] <leonel> ScottK there's a new  lib  for   libclamunrar    for clamav   should I :  1  include in  libclamav3.install  or   2  do a   libclamunrar3.install and add  it to debian/rules  ??
[20:29] <poOrBOon> people in #compiz-fusion don't recommend it
[20:29] <geser> have they a better suggestion?
[20:29] <ScottK> leonel: The new Clamav is in Debian NEW right now.  I'd suggest we just wait for it.
[20:30] <leonel> scottK PLOP   ok  but for learning  thing .. what should be better ?
[20:30] <leonel> ScottK the package build now and installs but needs   libclamunrar  that gets generated with the new clamav ...
[20:30] <ScottK> leonel: Dunno.  I think I'd include it in libclamav3.install.
[20:30] <leonel> scottK OK
[20:30] <leonel> thanks
[20:31] <poOrBOon> No the didn't say anything
[20:31] <johnny> isnt' this the wrong channel for questions about making ubuntu look like vista?
[20:32] <johnny> considering more relevant questions are not being answered
[20:32] <poOrBOon> motu? I thought you know everything :D
[20:32] <pochu> We know.
[20:32] <pochu> ;-)
[20:32] <poOrBOon> hihi
[20:32] <_MMA_> poOrBOon: Search Ubuntu Forums or Gnome-Look. You should find all yo uneed.
[20:32] <pochu> Well not me, but MOTUs :-)
[20:32] <poOrBOon> I searched gnome-look, that why I am here dudes
[20:32] <leonel> ScottK if this package works like  debian's   will be  a great step for me   thank you
[20:32] <poOrBOon> only the emerald themes look good
[20:33] <_MMA_> poOrBOon: This isnt a support channel. ;)
[20:33] <poOrBOon> but, I heard emerald and compiz hate each other.. not recommended
[20:33] <Kopfgeldjaeger> to whom should i assign a bug like "xy outdated" ?
[20:33] <pochu> Kopfgeldjaeger: tag it as 'upgrade'
[20:33] <Kopfgeldjaeger> ok, thx
[20:33] <geser> nobody unless you have a new package for sponsoring
[20:34] <RainCT> poOrBOon: emerald works good here
[20:35] <Kopfgeldjaeger> there is a package on revu (by me, and anyother by somebody else), geser
[20:35] <poOrBOon> with compiz-fusion??
[20:36] <poOrBOon> @RainCT I don't want to f*** my supa os by doing stupid things. that's why I ask the MOTUs. if installing a+b ist dumb or absoluteley ok a=compiz ; b=emerald
[20:37] <_MMA_> poOrBOon: Please take it to a support channel or a PM. This isn't a support channel.
[20:37] <poOrBOon> ok ok
[20:37] <poOrBOon> exit
[20:45] <harrisony> If a package has a missing reccomeded dependency would I create a debdiff and upload it to the report and then assign the bug to a team?
[20:55] <imbrandon> never assign anyone
[20:55] <Nafallo> imbrandon: yourself?
[20:55] <imbrandon> subscribe possibly, NEVER assign
[20:55] <imbrandon> Nafallo: bah
[20:55] <imbrandon> lol
[20:55] <Nafallo> imbrandon: I assign myself anyway :-)
[21:05]  * pochu lols at http://ubuntuircstats.org/ubuntu-motu.html
[21:05] <pochu> Most used words word	occurrences
[21:05] <pochu> 1	"persia"	215
[21:05] <pochu> persia: told you :P
[21:09] <ikonia> I'd appriciate an update on bug https://launchpad.net/~ubuntu-hawaii/+members
[21:09] <ikonia> oosp
[21:09] <ikonia> oops
[21:09] <ikonia> 173890
[21:09] <pochu> bug 173890
[21:09] <ubotu> Launchpad bug 173890 in flashplugin-nonfree "flashplugin-nonfree fails to install... new version?" [Undecided,Confirmed] https://launchpad.net/bugs/173890
[21:09] <ikonia> imbrandon has put in a lot of effort but I'd like to understand the current development brandon is working on
[21:09] <ikonia> pochu: yes, I've read the bug report
[21:10] <pochu> ikonia: It was for me and others :)
[21:10] <ikonia> ahh
[21:10] <ikonia> sorry
[21:10] <imbrandon> ikonia: i put an update on it, and refrenced a devel thread
[21:10] <johnny> so, would you say this is a channel that supports ubuntu packagers
[21:10] <imbrandon> explaining the sate and an eta
[21:10] <johnny> but does it also support those who are learning to build ubuntu packages for personal usage until proper patches are submitted upstream?
[21:10] <ikonia> imbrandon: yeah, I read the update, seems reasonable I'm trying to understand the failures in konqueror and opera
[21:11] <ikonia> imbrandon: I assume you read my comments on the bug about seperating the checksum issue and the functionality issues
[21:11] <imbrandon> they are explained in the devel mail, they dont support XEmbed
[21:11] <imbrandon> ikonia: yea i read it, its not fesable
[21:11] <ikonia> yes, I picked up on that, but they do actually install sucssesfully
[21:11] <ikonia> imbrandon: ok, perfect, thank you
[21:11] <johnny> yes or no? so i can start asking questions or go somewhere else
[21:12] <imbrandon> yes it installes, but i cant push an update that segfaults on those browsers
[21:12] <johnny> and hopefully help others
[21:12] <johnny> here that is
[21:12] <ikonia> imbrandon that was where I was going
[21:12] <ikonia> imbrandon: as the origional bug was the checksum failure, the actual plugin issues are a different issue
[21:12] <imbrandon> johnny: you can ask here but we wont support anything thats not the proper way
[21:12] <ikonia> imbrandon: but I of course will assist and follow your suggestion
[21:13] <johnny> the "proper way"
[21:13] <johnny> what's that?
[21:13] <imbrandon> ikonia: right but as part of the sru team i refuse to knowingly break the others
[21:13] <ikonia> imbrandon: and I support that
[21:13] <ikonia> imbrandon: my only query on that was it's currently broke anyway
[21:13] <imbrandon> so the bugs have to both be fixed
[21:13] <ikonia> ok, fair enough, if thats the root you want to take, sounds good
[21:13] <imbrandon> ikonia: and it will stay that way untill i prepare the new solution as stated in the bug and devel ml
[21:13] <ikonia> ok, no problem
[21:14] <imbrandon> ikonia: its not just what i want, its the only way
[21:14] <ikonia> I'm catching up on the mailing archives
[21:14] <ikonia> imbrandon: bad choice of wording
[21:14] <imbrandon> :)
[21:14] <imbrandon> johnny: as in the way it would need to be to go into the archive
[21:14] <ikonia> imbrandon: also that should be route, not root
[21:14] <imbrandon> :)
[21:16] <johnny> i'm more interested in interacting with upstream
[21:16] <johnny> rather than just packaging upstream
[21:16] <johnny> to make it possible that the patch can be integrated into the archives
[21:16] <johnny> err package
[21:17] <leonel> scottK  clamav 0.92 builded  installed and working  now  here ..   now let's check  debian's package
[21:17] <johnny> for example
[21:17] <johnny> i have some issues with sabayon , and i'm trying to interact with upstream, but i need to know how to use ubuntu packaging to be able to test it
[21:17] <johnny> and then the ubuntu packagers can take a tested deb and just use it
[21:18] <imbrandon> your definition of "upstream" is not clear enough for me to tell what you mean, upstream can mean many things, upstream as in debian?
[21:18] <johnny> aha
[21:18] <johnny> no.. upstream upstream
[21:18] <johnny> the real package upstream
[21:19] <imbrandon> package != upstream
[21:19] <johnny> application upstream
[21:19] <johnny> application/library/script, etc
[21:19] <imbrandon> terminoligy conflict here, ok go back to basics and tell me exactly what you want even with programs names and i'll atleaste get you pointed in the right direction
[21:20] <johnny> well, the package can vary, since i'm using lots of applications inrelation to ltsp
[21:20] <johnny> so, that's gnome, ltsp, and other random supporting programs
[21:20] <imbrandon> ok right, but as an example you have libfoo on sourceforge
[21:20] <imbrandon> start there
[21:20] <johnny> i know how to talk to devs :)
[21:21] <imbrandon> ok talk to me
[21:21] <johnny> i have spoken to federico for example
[21:21] <johnny> who maintains sabayon
[21:21] <johnny> he told me that he will accepted my tested patches
[21:21] <imbrandon> sure
[21:21] <johnny> so, i need to know how to properly use the ubuntu packaging env , so i can deploy and test the fixed packages
[21:22] <johnny> after which, the patches will be accepted
[21:22] <ikonia> johnny: there is a great guide on https://help.ubuntu.com
[21:22] <imbrandon> ok so why not take it the last step if your going that far ( monhs of work ) and just upload it to the dev release
[21:22] <johnny> i will be
[21:22] <imbrandon> months*
[21:22] <johnny> oh wait
[21:22] <johnny> dev release?
[21:22] <johnny> which dev release? :)
[21:23] <imbrandon> e.g hardy, we do just exactly what you are wanting
[21:23] <johnny> but hardy is not in my env
[21:23] <imbrandon> its our job as motu
[21:23] <johnny> and won't be
[21:23] <johnny> hardy will get the fixed upstream eventually i'm sure
[21:23] <johnny> either through debian or not
[21:23] <imbrandon> ok then why mess with the deb packages just work pure upstream
[21:24] <johnny> because i need to deploy it in my ubuntu env
[21:24] <johnny> so i can test the packages
[21:24] <imbrandon> then you need to be working in a hardy env
[21:24] <imbrandon> thats the only way really
[21:24] <johnny> my packages will be gutsy, but the patches will make it upstream, and then to hardy i'm sure
[21:24] <ajmitch> but being able to test out patches in a real environment is also rather useful
[21:24] <johnny> i will not be distributing the packages
[21:24] <johnny> outside of my env
[21:25] <imbrandon> johnny: ok then ... your kinda going about it backwords but ...
[21:25] <johnny> only due the fact that hardy is currently undeployable
[21:25] <johnny> but when it is.. you guys will already be working on something else :)
[21:26] <johnny> and i know the patches will be too big to make it into gutsy itself
[21:26] <imbrandon> i'm on hardy right now , what do you mean undeployable? use in a stable env yes, but your not going to be in a stable env your going to be applying untested patches
[21:26] <johnny> sure.. but that's only for one application
[21:26] <johnny> instead of the entire env
[21:27] <imbrandon> hrm ok anyhow it matters not if you arent going to pass them out, the exact same proceedures apply
[21:27] <imbrandon> just look at the hardy process and aply it to gutsy
[21:27] <johnny> if i end up having to deploy more things,i will try to do the leg work to get it accepted for hardy
[21:27] <johnny> but first i have to know what i'm doing :)
[21:28] <imbrandon> err
[21:28] <imbrandon> ok
[21:28] <imbrandon> however you want to look at it
[21:28] <johnny> i had quite a time just learning to run pbuilder and friends
[21:28] <johnny> i cme from a slightly different process background when it comes to deployment
[21:29] <johnny> i've been using gentoo for 5 years.. and packaging for it is dead simple
[21:29] <johnny> ebuilds are much easier than running all the pbuilder stuff
[21:29] <johnny> and apt-get source etc
[21:29] <imbrandon> right all the more reason to learn the development way , but if you just want to hack then there is no reason to even make debs
[21:29] <johnny> because that's the way to get me started in learning to package other ubuntu apps
[21:29] <johnny> like our point of sale program
[21:29] <imbrandon> just hack the source, install and pass patches
[21:30] <johnny> our point of sale program is currenly unpackaged
[21:30] <imbrandon> learing to package on a stable release is not recomeneded, thats what i'm trying to explain
[21:30] <imbrandon> later you can apply those same ideas to stable
[21:30] <johnny> sure, but i need fixes in my stable release :)
[21:30] <johnny> sabayon is completely busted in stable
[21:31] <johnny> if you use it for even longer than few minutes
[21:31] <imbrandon> ...
[21:31] <johnny> but that's not due to ubuntu tho
[21:31] <johnny> that's gnome itself
[21:31] <johnny> upstream gnome bugs prevent the application from working even after a few changes
[21:32] <johnny> save your profile, don't kow which files not apply, and bam.. it'll crash
[21:32] <johnny> when you reopen it
[21:32] <johnny> so folks who do use gutsy and require sabayon, might want something that does work
[21:32] <johnny> but i do know gutsy devs will never accept it
[21:33] <johnny> so i will want it fixed in hardy for sure :)
[21:33] <imbrandon> johnny: sure but i've tried to explain to you the way to acheve that is fix it in the dev release and have it backported
[21:33] <imbrandon> we are all the same devs
[21:33] <johnny> aha.. backports.. i meant to ask about that
[21:33] <johnny> is there a list of what is acceptible to backport?
[21:34] <johnny> vs what can be pushed idrectly into a stable release?
[21:34] <imbrandon> what is in the dv release can be considered for backport
[21:34] <imbrandon> and stable updtaes only gets major regression fixes
[21:35] <johnny> how about a feature that was explitly mentioned as working in the uhmm "press release" but doesn't
[21:35] <johnny> like autologin in the edubuntu press release
[21:35] <imbrandon> depends on how invasive the fix is
[21:35] <johnny> aha.. good to know
[21:36] <johnny> thanks for your time imbrandon , trying to reconcile a no real "release" distro vs this situation was kinda difficult
[21:36] <johnny> i think i have a better handle on it
[21:36] <imbrandon> and nothing gets pushed directly into stable releases, it all goes into the dev release and then -proposed then backports or -updates
[21:36] <johnny> i'll try to get a hardy setup going at some point in virtualbox
[21:36] <johnny> when i make my own hacked debs
[21:37] <imbrandon> good call :)
[21:37] <imbrandon> you could also make a hardy pbuilder on gutsy
[21:37] <imbrandon> that will do most of that for you
[21:38] <johnny> there are almost too many cross purpose tools in .deb creation/maintenence
[21:38] <johnny> at least some of them are just frontends for others
[21:38] <johnny> but it is confusing for n00bs
[21:38] <johnny> even experienced linux users
[21:39] <johnny> but are just n00bs to debian packaging
[21:50] <effie_jayx> ScottK,  the package worked ok
[21:50] <effie_jayx> ScottK,  I am requesting a sync since the change is already in debian
[21:52] <effie_jayx> it is missing the browser bit
[21:53] <somerville32> Should I remove Vcs- fields from debian?
[21:57]  * effie_jayx is not being carefull enough
[22:32] <dx9s_work> have a simple question .. (sort of) ... but I expect a more complicated answer?
[22:33] <dx9s_work> actually a list of questions...
[22:34] <dx9s_work> is there a way to automatically install the "-dev" packages (aka the headers files) in any way based on some list or criteria or system wide?
[22:34] <dx9s_work> (that was #1)
[22:34] <dx9s_work> #2) is there a way to rebuild a list of packages from source?
[22:34] <dx9s_work> and #3) get a list off all things installed that depend on a particular library
[22:35] <dx9s_work> what I want to do is rebuild everything from source that depends on a library I've manually updated to a newer library (and headers)... in this case libjack
[22:36] <dx9s_work> (my complaint with "debian" packages is that it normally doesn't install the headers files for a library... this is different from what I am used to with slackware packages... which always installs the header files with a "dependable" package
[22:37] <gilir> Hi :)
[22:38] <dx9s_work> hello
[22:39] <gilir> is there someone available and very nice to review awn-extras-applets on REVU ? :)
[22:43] <Fujitsu> dx9s_work: That is ugly, not a development question, and will not be supported here.
[22:44] <dx9s_work> Fujitsu, what tools are used for scripting the build process (for .debs) ... curious It is really easy with SlackBuild (DL the slackbuild files and run the build script).
[22:44] <dx9s_work> I am sure somebody in the ubuntu world has automated this.. I just want access to those files!
[22:44] <dx9s_work> and the tools
[22:44] <Fujitsu> dx9s_work: It is particularly evil because you have left the package system.
[22:44] <Fujitsu> *packaging
[22:44] <dx9s_work> If I could get the package for libjack.. I would update it first
[22:44] <geser> dx9s_work: the buildds use the published debs to build/compile a package
[22:45] <TheMuso> dx9s_work: Slack build scripts do not in any way check for failure to build from source.
[22:46] <TheMuso> dx9s_work: Debian/Ubuntu package building has strong error checking, so if a part of a apckage build fails, the package does not get built.
[22:46] <dx9s_work> right .. I am an old slackware guy.. about 6 month w/ ubuntu.. and there are things I like and dislike..
[22:46] <TheMuso> dx9s_work: I used slackware for 3 years.
[22:46] <TheMuso> dx9s_work: Some of that time was spent maintaining a slackware package repository.
[22:46] <dx9s_work> (well since 0.99rX days go me)
[22:46] <dx9s_work> for me that is
[22:47] <TheMuso> Once I got involved with Ubuntu development afterwards, I was amazed at how poor the general quality of building slackware packages was, especially when it came to 3rd-party packages.
[22:47] <dx9s_work> I am interested in the scripting used w/ ubuntu for maintaining the repo... if I have to make my own and then upgrade to newer stuff -- but interested in getting changes done within the .deb system
[22:47] <TheMuso> Pat's packages were ok, and the build scripts were written with the assumption that the package would build successfully.
[22:48] <TheMuso> !packagingguide | dx9s_work
[22:48] <ubotu> dx9s_work: packagingguide is The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[22:48] <TheMuso> dx9s_work: Will show you how its done
[22:48] <dx9s_work> there are "okay" getslack tools . .but yeah I like the depos for .deb and ubuntu .. but still yearn for the days of having my own customized repos...
[22:49] <StevenK> Creating your own repository for binary and source packages is fairly simple
[22:49] <TheMuso> dx9s_work: Well its more complex than just throwing tarballs in a directory.
[22:49] <dx9s_work> is there any short cuts... like instead of building .deb ... going directly from some "deb-src" to installing?
[22:49] <TheMuso> Since you have to take care of metadata and dependencies
[22:49] <Fujitsu> TheMuso: Not much more.
[22:50] <TheMuso> Fujitsu: Yeah I know. But it depends on how much like the main repos you want your personal one to be.
[22:50] <dx9s_work> I'd be happy installing from source via some semi-structure dependency thing... more like Gentoo's process when installing from source but not as overkill!
[22:51] <dx9s_work> no "command -blah libjack" to cause the system to download the source and recompile against a new library
[22:51] <dx9s_work> recompile and install (skipping .deb)
[22:51] <StevenK> Skipping .deb? How else do you install it?
[22:52] <dx9s_work> inside or outside a packaging system.. outside .. ./configure ... or scons .. or whatever
[22:52] <Fujitsu> Ew. Why?
[22:52] <StevenK> What Fujitsu said
[22:52] <Fujitsu> We have a packaging system for a reason.
[22:52] <dx9s_work> directly from source.. but the packaging system never learns you updated a dependency and MAY want to recompile against new headers/libs
[22:53] <TheMuso> ewwwww
[22:53] <dx9s_work> I am curious.. there is NO way to install from some "deb-src" .. you hafta make a .deb?! (or temporarily make one and discard post install)
[22:53] <StevenK> Er, if you don't update the Debian packaging the automatically generated Depends won't get updated
[22:53] <TheMuso> dx9s_work: No, its not like slackware where all the "package tracking system" does is keeps a record of what files belong to what package.
[22:54] <StevenK> If you bump ABI and don't change shlibs, things might break
[22:54] <dx9s_work> exactly.. I am sure... the way the dependencies are done.. that a little change in updating one library will / can? cause a ripple effect and automatically recompile other stuff. I wanna USE those scripts and processing within the .deb system... I will read the packaging system .. but was wondering if there is way to install from deb-src directly (skipping .deb files all together while updating the database of installed stuff)
[22:55]  * Fujitsu is confused. The source packages exist to build the debs.
[22:55] <TheMuso> dx9s_work: No, thers not.,
[22:55] <dx9s_work> what.. people have to manually update each .deb from deb-src?
[22:55] <Fujitsu> ... yes.
[22:55] <dx9s_work> then what good is a packaging system?
[22:56] <StevenK> It makes certain that those .deb's will work together with some semblance of sanity?
[22:56] <Fujitsu> Right, you've thoroughly confused me now.
[22:56]  * TheMuso laughs out loud. This is exactly why I left slackware.
[22:56] <TheMuso> Well, one of the reasons.
[22:57] <Fujitsu> TheMuso: You have recovered well.
[22:57] <dx9s_work> with slackware it doesn't attempt to match depends .. and often things work just fine...
[22:57] <Fujitsu> `often'
[22:57] <Fujitsu> With a sane packaging system like Debian's, it *will* work just fine.
[22:57] <dx9s_work> but when it doesn't take much (ldd for example is a wonderful tool) to figure out what you are missing
[22:57] <TheMuso> nxvl_work: And often they don't.
[22:58] <TheMuso> dx9s_work: Sorry, ^^
[22:58] <dx9s_work> well not.. I've had issues with .deb .. having to manually fight it..
[22:58] <dx9s_work> I am not here to flame a which is better
[22:58] <TheMuso> nxvl_work: I spent half a day once trying to work out why cups didn't work, having to crank up debug logs just to get can't find shared library errors.
[22:58] <dx9s_work> stop that
[22:58] <dx9s_work> now
[22:58] <dx9s_work> I am wanting to know the process
[22:58] <dx9s_work> for .deb from src
[22:58] <Fujitsu> dpkg-buildpackage -rfakeroot
[22:58] <nxvl_work> TheMuso: ah!?
[22:58] <TheMuso> nxvl_work: Sorry, wrong person.
[22:58] <nxvl_work> TheMuso: heh, k
[22:59] <nxvl_work> :D
[22:59] <nxvl_work> *HUGS*
[22:59] <dx9s_work> okay.. how does the package system know (or not) to update other things?
[22:59]  * StevenK moves TheMuso's gun barrel to point at dx9s_work 
[22:59] <Fujitsu> TheMuso: Are you using inverse tab completion, or something.
[22:59] <Fujitsu> dx9s_work: You do it manually.
[22:59] <TheMuso> Fujitsu: No, slight confusion as to the two starting letters of the nick.
[22:59] <dx9s_work> okay so still some manual work like in slackware .. -k-
[22:59] <Fujitsu> TheMuso: Remarkably similar suffixes.
[22:59] <TheMuso> Fujitsu: Yes.
[22:59] <TheMuso> But that day with slackware and cups was just about the final straw for me
[22:59] <StevenK> dx9s_work: Yes, but if you do the work, no one else has to.
[22:59] <dx9s_work> I was hoping the system had SOME automation...
[23:00] <TheMuso> Dependency hell indeed.
[23:00] <Fujitsu> dx9s_work: It is not a normal use case to bump a library ABI on a local system.
[23:00] <dx9s_work> well getting a list of all things that *CAN* depend on a .deb (library) and then further seeing what's currently installed is a simple task
[23:01] <dx9s_work> well libjack 0.103.0 is flaky.. updating to ~0.107.7 (in my case) solved a lot of things.. just wanna grab all the sources that depend on the 0.103.0 and recompile them
[23:01] <Fujitsu> Does it change ABI?
[23:02] <dx9s_work> there is a break in backwards compatibility between 0.102.20 and 0.103.0 if that is what you are asking
[23:02] <dx9s_work> for example the latest version of "0.100.0" is 0.102.20
[23:02] <dx9s_work> (like a virtual thing)
[23:03] <slangasek> no, it's not a virtual thing, it's an soname
[23:03] <slangasek> the latest version of libjack0.100.0-0 in Ubuntu is version 0.103.0
[23:04] <slangasek> they're forwards-compatible, or so say the upstream build rules
[23:04] <dx9s_work> yeah.. well once you jump to 0.103.0+ (until they change the headers and calls significantly).. ... bins that depend on the "soname" 0.100.0 will not work.. have to go to 0.103.00 . and no they DON'T work ... old bins old libbs.. new bins new libs... there is a break at 0.103.0
[23:04] <slangasek> ./usr/lib/libjack-0.100.0.so.0 -> libjack.so.0
[23:04]  * StevenK blinks.
[23:04] <slangasek> that's in the Ubuntu package
[23:04] <StevenK> Parse error
[23:05] <Fujitsu> We would have bumped the SONAME if that was the case.
[23:05] <slangasek> so actually, it looks to me like upstream changed the soname gratuitously
[23:05] <TheMuso> Or Debian would have.
[23:05] <Fujitsu> slangasek: Aha.
[23:05] <slangasek> and the Debian maintainer corrected for it
[23:05] <slangasek> (possibly at my advising, for all I know)
[23:06] <dx9s_work> I know that programs compiled against the headers/libs in 0.100.0-0.102.20 cannot enumarate some calls correctly.. and visa versa .. programs compiled against newer headers/libs cannot used older libs
[23:06] <dx9s_work> but the latter makes more sense
[23:06] <slangasek> heh, no, not me in this case but Mario Lang
[23:06] <dx9s_work> the first one doesn't .. you would think compiling against older libs means newer ones should be fine..
[23:06] <slangasek> (delYsid++)
[23:06] <dx9s_work> in any case
[23:06] <dx9s_work> I'll read the package guide.. I was hopeing for a shortcut
[23:07] <TheMuso> slangasek: He really knows his stuff.
[23:07] <slangasek> yes, we have a packaging system, therefore programs compiled against newer headers/libs being run against older libs are not an issue
[23:07] <dx9s_work> ??
[23:07] <slangasek> dx9s_work: "versioned dependencies"
[23:08] <dx9s_work> you mean program compiled against older headers/libs should work with newer libs .. that is normally true.. except libjack 0.103.0 has backwards problems
[23:08] <slangasek> it doesn't
[23:08] <dx9s_work> yes it does
[23:08] <slangasek> not when packaged correctly. :)
[23:09] <dx9s_work> I've upgraded the libjack to 0.103.0 and a distro ardour2 STOPPED being able to enumerate.. jack-rack complain about no pcm ins/outs.. etc.. it's an issue with the library not being completely backwards compatibale with older bins
[23:10] <slangasek> ok
[23:10] <dx9s_work> that is why I am using a few things from source.. because what's in the depos are a bit old and flaky!
[23:10] <StevenK> "depos"
[23:10] <dx9s_work> I'd like to figure out how to get the deb-src.. update them and the meta data with newer stuff and make newer .debs but
[23:11] <dx9s_work> talking offical ubuntu repo . (depos is a term from HP-UX I accidentally slipped on that .. sorry)
[23:12] <slangasek> dx9s_work: "using a few things from source" - it would be nice if you would also submit bug reports against the packages, if you have evidence that they're broken. :)
[23:13] <slangasek> the enumeration error is only an ABI problem if rebuilding the app fixes it, though; it could just be breakage in the library, not backwards-incompatibility
[23:13] <dx9s_work> well I've spoken with some of the ardour folks as well and it's not just me .. most have no problems working from source... I was curious as to the scripting process for making .deb's from deb-src .. I've many times have grab (in slackware world) the slackbuilds and just updated the source and changed (enabled different compile-time options) then pushed out the .tgz to several servers.
[23:14] <slangasek> well, you were already given the answer for making .debs, dpkg-buildpackage -rfakeroot
[23:14] <dx9s_work> ty
[23:15] <dx9s_work> just now need to learn a few other tools to get a list of all things that depend on libjack (it's in there someplace :P )
[23:15]  * TheMuso bets a million bucks that very few people in the slackware community kow what a chroot is.
[23:15] <TheMuso> in relation to building packages
[23:15] <dx9s_work> use it many times to fix  unbootable machines
[23:15] <dx9s_work> from a recovery cd
[23:16] <StevenK> "in relation to building packages"
[23:16] <TheMuso> dx9s_work: sudo apt-get build-dep jack-audio-connection-kit
[23:16] <TheMuso> Will get you jack's build dependencies.
[23:17] <Fujitsu> Note that you'd best properly package the new jack libs first.
[23:17] <slangasek> I think what he's asking for is "apt-cache rdepends libjack0" or "apt-cache rdepends libjack0.100.0"
[23:17] <TheMuso> StevenK: Well people may know what chroots are in terms of chroot jails etc, and for installing systems, but not how useful t hey are for package building, and making sure you have the dependencies just right, but oh thats right, slackware frees you from dependency hell.
[23:17] <StevenK> "Apparently"
[23:17] <dx9s_work> seen them used in rpmbuilds and a few slackbuild scripts .. (a few)
[23:19] <dx9s_work> the biggie thing I saw was building QT ... it's done in place because how QT is path sensitive.. but they installed to "QT" then /usr/lib/qt then move to /usr/lib/qt* with sym link so the link controls what version
[23:19] <dx9s_work> (that was when I looked at the slackbuilds for qt, was a learning process)
[23:20]  * TheMuso decides to refrain from making any more slackware comments, pointing out that if people haven't got it already, he is very bitter about slackware.
[23:21] <dx9s_work> I don't care really what distro... in the end.. gimme the source... and I'll be happy... packaging systems have a learning curve all their own!
[23:21]  * Fujitsu points dx9s_work at LFS.
[23:22] <TheMuso> c
[23:22] <Fujitsu> Ugh.
[23:22] <TheMuso> ugh that should be for mutt
[23:22] <dx9s_work> I know about linux from source! heh.. I've actually made stuff a long time ago run from USB drive that didn't like too!
[23:22] <dx9s_work> remember I started with slackware back in the 0.99rX days
[23:23] <dx9s_work> I've been using .deb's for close to 6 months now and like most of them and see many advantages over slackware's tgz's
[23:24] <dx9s_work> I just wish there was some system flag I could set to have it automatically install the "*-dev"'s
[23:24] <dx9s_work> apt-get install libblah.... then try to compile against that library... and oops.. forgot.. apt-get install libblah-dev..
[23:24] <slangasek> dx9s_work: I've just installed the hardy ardour package here; how would I reproduce this problem you're describing?  where would I see the enumeration?
[23:25] <slangasek> dx9s_work: that system is called apt-get build-dep
[23:25] <dx9s_work> you installed all from current? (7.10) Gutsy?
[23:26] <slangasek> no, I installed from hardy.  If I need the gutsy version of ardour to reproduce the problem I can do that, but please tell me what I'm looking for first
[23:27] <dx9s_work> not up to hardy yet.. .but post 7.10 "fresh" works .. upgrading has problems.. it leaves bins compiled against older libjack ..
[23:30] <dx9s_work> try to run a binary that requires >=0.100.0 against libjack 0.103.0 ... make sure the program was compiled again (say 0.102.20) .. if the depends list >= 0.103.0 then you will not have a problem.. it is in those older binaries that claim >= 0.100.0 .. they need to be a range >= 0.100.0 and < 0.103.0
[23:30] <slangasek> yes, and if I have the problem, what does it /look/ like?
[23:31] <dx9s_work> well the dependent program will not be able to enumerate the PCM channels the jack daemon has to offer
[23:32] <dx9s_work> run a jackd (0.103.0) w/ libjack 0.103.0 and a program compiled against older libjack (and headers) and it can't enumerate the pcm channels
[23:32] <dx9s_work> if you installed from anything current you won't be able to reproduce because the current stuff is compiled against newer headers
[23:34] <slangasek> how do I run jackd, and where in ardour would I see that it can't enumerate the PCM channels?
[23:34] <slangasek> I'm a library guy, not a sound guy
[23:34] <dx9s_work> np
[23:34] <dx9s_work> the first place I noticed was running older qjackctl (gui for jackd) but
[23:34] <dx9s_work> jackd -R -d alsa
[23:35] <dx9s_work> will start up standard server w/ conservative settings against the "default" alsa sound card
[23:35] <slangasek> as root?
[23:35] <slangasek> (wants realtime scheduling)
[23:35] <dx9s_work> oh
[23:35] <dx9s_work> right
[23:35] <dx9s_work> leave -R off
[23:35] <slangasek> ok
[23:36] <dx9s_work> if you have security settings in /etc/security/limits.conf to allow realtime for a group .. sorry
[23:36] <zul> evening
[23:36] <Fujitsu> Hey zul.
[23:37] <zul> Hey Fujitsu how goes it?
[23:37] <Fujitsu> Fairly good Yourself?
[23:37] <Fujitsu> +.
[23:37] <zul> good
[23:38] <dx9s_work> slangasek, it's not really a library issue (that you can fix aside from possibly flaging somehow the 0.102.20<->0.103.0 break in protocol support in the dependency database)... it's the newer librarys don't support older protocols (jackd -V) well..
[23:45] <dx9s_work> I am interested in the build process for ubuntu.. so I'll have more questions.. eventually.. perhaps I might even get into unoffical .debs for people (not bleeding edge, but wanting newer src to fix problems -- like http://tracker.ardour.org/view.php?id=1928 )
[23:45] <TheMuso> dx9s_work: We have a backport repository.
[23:45] <TheMuso> s/backport/backports/
[23:46] <dx9s_work> (still new .. I can guess that means porting things back from / or forward to some "release")
[23:46] <TheMuso> Porting things bac from the development release to the stable release.
[23:47] <dx9s_work> ah
[23:48] <dx9s_work> well I am not a developer, but a loose tester and finder of bugs for the ardour project (closely related to jack) ... however I have submitted one feature patch to the group
[23:52] <dx9s_work> anyways.. i have some serious reading to do and experimentation/testing .. thanks for your help and direction
[23:52] <dx9s_work> was hoping there might be a way to update the dependency database to reflect some break so older bins don't run with newer libs (at the aforementioned 0.102.20<->0.103.0)
[23:54] <slangasek> by not listing the library under the same package name
[23:57] <Fujitsu> slangasek: Can you see anything wrong with a mass-giveback in the near future?
[23:57] <slangasek> Fujitsu: no
[23:58] <Fujitsu> There are less than 200 on !(lpia|hppa), so it shouldn't be too bad.