[00:03] <mrooney> yeah, well I saw YokoZar seems to be a maintainer of the PPA but also works on the Ubuntu package, so I thought I'd ask how to handle it
[01:06] <YokoZar> mrooney: jdong: If it's a packaging bug it's basically my problem alone so wherever I see it would be good.  I look at launchpad more than winehq so i would prefer it there.
[13:12] <dennda> Hi. Any intention of getting the latest VTK (5.4) into karmic? at the moment, there is no vtk at all
[16:35] <ScottK> dennda: We do have VTK: https://launchpad.net/ubuntu/+source/vtk/5.2.1-10ubuntu1 - At this point the only way I think we'd update is if it fixed the build failures with 5.2 and someone could test the reverse depends.
[16:45] <Squideshi> Under what circumstances should one seek to have a package included in the Ubuntu repositories, rather than the Debian repositories?
[16:46] <wrapster> what is the difference in using dpkg-buildpackage -k<keyid> and -p<sign cmd>
[16:48] <RainCT> Squideshi: almost none :)
[16:48] <wrapster> didnt quite understand it..
[16:49] <RainCT> Squideshi: basically only if the package is Ubuntu specific or it has some weird licensing which Debian doesn't accept but Ubuntu does
[16:50] <Squideshi> RainCT: That's what I suspected, but I wasn't sure. Thanks for the confirmation.
[16:54] <dennda> ScottK: reverse depends?
[16:54] <ScottK> dennda: Packages that use VTK
[16:54] <dennda> ScottK: i imagine that's quite a few packages
[16:54] <dennda> what does 'testing' include here?
[16:54] <dennda> i'd be happy to help if we can get it into karmic
[16:55] <dennda> ScottK: i guess python-vtk are the python bindings for vtk?
[16:55] <ScottK> Yes
[16:55] <dennda> it wasn't shown to me for karmic on packages.ubuntu.com
[16:55] <RainCT> wrapster: -k is used to specify with which key you want to sign the package, -p is used to tell it what gpg binary to use
[16:55] <dennda> perhaps i forgot to adjust it
[16:55] <RainCT> (according to the manpage, had never heard about -p before)
[16:56] <dennda> ah yes, my fault, karmic has it
[16:56] <wrapster> RainCT: actually im a little confused myself.. thats y asked.
[16:56] <dennda> ScottK: well i can help with testing if you have a list of programs that use it and some 'testing means this, styleguide'
[16:57] <ScottK> dennda: apt-cache rdepends <packagename> for each binary in VTK will give you a list.
[16:58] <dennda> for each binary? Oo
[16:58] <ScottK> dennda: Also reverse-build-depends <packagename-dev> for the -dev packages (reverse-build-depends is in ubuntu-dev-tools)
[16:58] <ScottK> Yes
[16:58] <RainCT> wrapster: well, you shouldn't need -p for anything, and unless you're a MOTU you don't need -k either (you just need to export DEBEMAIL and DEBFULLNAME variables in your ~/.bashrc)
[16:58] <ScottK> The way I'd do it is put the new VTK in a PPA and rebuild the reverse-build-depends in the PPA, install and test all the rdepends.
[16:58] <wrapster> ok
[16:59] <ScottK> dennda: I don't have a specific "test means X", but it doesn't need to be extensive.
[16:59] <ScottK> dennda: I'm going to be offline for the next several hours, so I can't give more specific advice than that.
[17:00] <dennda> ScottK: i'm neither a motu nor am I by any means familiar with packaging, so *I* can't do that ppa
[17:00] <ScottK> dennda: Perhaps someone here can help you.
[17:00] <dennda> ScottK: well it's not *that* urgent
[17:00] <ScottK> OK.
[17:00]  * ScottK really away now.
[17:00] <dennda> thanks
[17:38] <Zhenech> could anyone have a look at https://bugs.launchpad.net/debian/+source/mini18n/+bug/450821 and pull the fixed package from Debian sid?
[18:01] <dtchen> jdong: ugh, that "how-to" page is so bad. don't they know that they can just use hda-analyzer and hda-emu?
[18:08] <dtchen> bdrung_: that's pretty fantastic work RE eclipse
[18:10] <maco> dtchen: you were right. file not found.
[18:10] <dtchen> toldya.
[18:10] <maco> so what do i do? try a newer svn snapshot?
[18:11] <dtchen> well, if you want to dig in upstream's VCS, you could read the commit logs if you're really sick. Does upstream have a bug tracker?
[18:12] <maco> its hosted on kde.org, so i suppose so
[18:12] <maco> or at least the svn is on kde.org
[18:13] <maco> uh... no, no bugtracker
[18:13] <maco> just svn
[18:14]  * maco tries to remember kde svn credentials
[18:14] <Laney> hey cool
[18:14] <Laney> does eclipse work now?
[18:15] <dtchen> superm1: ping, what's the issue with mixer levels not being restored? What audio codecs are in use? Can you drop in http://kernel.ubuntu.com/~dtchen/alsa-utils for /etc/init.d/alsa-utils and paste the output in the bug(s)?
[18:16] <dtchen> superm1: ("the output" -> /var/run/alsa/timestamp)
[18:16] <superm1> dtchen, well it's been reported with a variety of machines, but i was able to just reproduce it on a virtualbox install
[18:16] <superm1> dtchen, you go and say set master to 91% w/ alsamixer, and then click applications->logout->restart, and check alsamixer and it's not 91%
[18:17] <superm1> it's back to the 80something
[18:17] <superm1> other people have been reporting it in the fashion of they set IEC958, and it won't stick
[18:18] <dtchen> interesting, that would mean that restore_levels() fails
[18:18] <dtchen> i can't reproduce it locally at all
[18:19] <maco> same with both gdm and kdm
[18:19] <maco> ?
[18:19] <dtchen> maco: and with startx
[18:19] <dtchen> about the only vector i haven't tested is ltsp
[18:19] <randomaction> Zhenech: request a sync (https://wiki.ubuntu.com/SyncRequestProcess)
[18:20] <superm1> dtchen, i'm doing a fresh install in vbox with last night's daily, i'll attempt reproduce it again with your alsa-utils script and attach that output to the bug
[18:23] <Zhenech> randomaction, ok, will do
[18:23] <dtchen> superm1: thanks
[18:27] <maco> dtchen: nothing in the svn changelog saying "created Darkroom.cpp" :-/ also the svn snapshot is almost a year old
[18:27] <maco> (it does exist in current svn)
[18:28] <dtchen> maco: so, build infrastructure mess
[18:28] <maco> that's not a sentence
[18:28] <dtchen> oh, ouch. upstream changed the semantics for alsactl restore!
[18:28] <dtchen> maco: sure it is. "so, [there is] build infrastructure mess"
[18:28] <maco> ah see, now you have a verb!
[18:29] <maco> but i still dont understand
[18:29] <dtchen> it means you have something broken in your CMake infrastructure
[18:30] <dtchen> aha! indeed Intrepid users aren't experiencing this issue, because init isn't implied
[18:31]  * dtchen cheers not announcing behaviour changes
[18:33] <superm1> dtchen, /var/run isn't a persistent fs, so that file isn't going to stick post reboot
[18:33] <superm1> dtchen, but indeed /var/lib/alsa/asound.state isn't getting made
[18:34] <dtchen> superm1: that's fine, use /var/lib/alsa/
[18:35] <dtchen> superm1: ok, so /var/run/alsa isn't populated on a fresh install?
[18:36] <superm1> dtchen, /var/lib/alsa isn't, but /var/run/alsa has a notstoredall file in it
[18:37] <maco> dtchen: i think its more like "that file should exist, but the orig.gz is busted"
[18:37] <maco> because it DOES exist in current svn
[18:37] <dtchen> heh
[18:37] <dtchen> this is so ugly
[18:38] <maco> er...oh
[18:38] <dtchen> so it's because we umount stuff before it can write
[18:38] <maco> nevermind. none of the cpp's are in there in pbuilder though theyre there in the extracted source :(
[18:40] <superm1> dtchen, so you can reproduce it then?  would that explain racy behavior re it too?  it seems all of a sudden...
[18:41] <bdrung_> dtchen: thanks
[18:41] <dtchen> superm1: I can't reproduce it, but it's pretty glaringly obvious now that I stare at /etc/rc[06].d
[18:43] <dtchen> superm1: ok, one more test point: if you call alsactl store now, are the levels still not restored on next boot?
[18:45] <superm1> dtchen, just tried.  calling alsactl store manually, they are indeed properly restored on the next boot
[18:45] <dtchen> ok, right, so i need to make two changes to debian/init
[18:45] <dtchen> i'll have a test deb in a few minutes
[19:03] <dtchen> superm1: sorry, i'll ping you in ~1 hr
[19:08] <porthose> bdrung_, great I will email david and let him know ty :)
[19:11] <bdrung_> porthose: i already talked with him ;)
[19:11] <porthose> bdrung_, oh ok even better :)
[19:11] <bdrung_> :)
[19:12] <bdrung_> porthose: he wrote patches for audacity (which i maintain). so i already knew him.
[19:13] <porthose> bdrung_, cooool :)
[19:15] <bdrung_> porthose: i got your mail and i thought that his name seemed so familiar
[19:16] <porthose> bdrung_, purely luck of the draw :)
[19:16] <porthose> bdrung_, haha I have a few more if you would like another
[19:17] <bdrung_> porthose: one is enough :p
[19:17] <porthose> :)
[19:53] <dtchen> superm1: changes are in my alsa-utils branch
[19:53] <dtchen> superm1: if that still fails, i'll just make a specific -save upstart job
[19:54] <dtchen> the latter would be a crackload easier to debug than this mess
[19:54] <superm1> dtchen, what's "your alsa-utils branch" url?
[19:55] <dtchen> superm1: it's in the bug report that you filed
[19:55] <dtchen> #454265
[19:55] <superm1> cool thx
[19:58] <jdong> heh something seems to have left a udevadm.upgrade dangling on this machine...
[19:58] <jdong> kinda scary when udev tells you on bootup that trigger can't be used when udev is unconfigured :)
[20:01] <vorian> no body gonna breaka my syle
[20:01] <vorian> style too
[20:02] <vorian> a week and a half more of moving/training and I should be settled in our new home
[20:02] <dtchen> well, that's easy. you have no syle!
[20:02] <vorian> true enough
[20:02] <vorian> I'm stuck in denver at the biggest and loudest ariport on earth
[20:03] <vorian> and a lot of people smell too
[20:03] <dtchen> I used to think that, too, and then I realized that it was just my computer burning my pants.
[20:03] <vorian> oh crap!
[20:03] <vorian> your right
[20:04] <maco> and his left
[20:04] <vorian> :o
[20:04] <vorian> how was OLF?
[20:05] <maco> good
[20:05] <vorian> i was tres sad to miss it
[20:05] <maco> i stayed up til 3 saturday night watching doctor who with some folks in the hallway :P
[20:05] <vorian> haha
[20:06] <vorian> I must say that kne is quite good
[20:07] <vorian> I was worried about not bringing the full size lappy, but kne is doing very well so far
[20:07] <vorian> it will be nice to actually be nice to help work on it with lucid
[20:07]  * vorian says nice too much
[20:07] <dtchen> huh? no, my right is still my right.
[20:08] <vorian> haha
[20:09] <maco> dtchen: yeah so i dont see anything in the CMakeLists.txt that says "rm *.cpp"
[20:09] <superm1> dtchen, well do you want the good news or the bad news?
[20:09] <dtchen> superm1: bad first
[20:10] <dtchen> (do i have a choice?!)
[20:10] <superm1> dtchen, haha trick question.  it's all bad
[20:10] <superm1> didn't work still :)
[20:10] <dtchen> superm1: does alsa-utils stop work?
[20:11] <superm1> dtchen, no it would appear it doesn't
[20:11] <dtchen> superm1: ok, does it give FAILED?
[20:12] <superm1> Shutting down ALSA... [fail]
[20:12] <dtchen> superm1: and what's in /var/run/alsa ?
[20:13] <superm1> dtchen, i've been seeing notstored0 sometimes and notstoredall sometimes
[20:14] <dtchen> ok, and now i begin the initscript-sectomy
[20:14] <dtchen> basically, /etc/init.d/alsa-utils is useless. we don't need it to be an initscript at all.
[20:16] <superm1> dtchen, well before you go into breaking that down and switching everything into upstart, it looks like you are assuming that TARGET_CARD gets set by "$2" right?  well stop isn't normally called with any arguments like that I thought?
[20:16] <superm1> so surely rm -f $FLAG$TARGET_CARD isn't going to DTRT
[20:16] <superm1> er rm $FLAG$TARGET_CARD
[20:17] <dtchen> superm1: in that case, yes, but the real issue is that you're getting either 0 or ""
[20:18] <dtchen> superm1: i.e., it's completely legitimate for the sysadmin to use stop 0
[20:19] <superm1> dtchen, right i see
[20:37] <jetienne> q. i look for example of website installed by .deb. The only one im thinking about is phpmyadmin. any others ?
[20:39] <jdong> phpsysinfo?
[20:39] <jdong> squirrelmail?
[20:53] <porthose> jetienne, ampache, gallery2, drupal5, drupal6 are some others
[20:53] <jetienne> jdong: porthose: ok thanks
[21:39] <dtchen> superm1: changes pushed to bzr (r36)
[21:39] <dtchen> superm1: actually, hang a sec
[21:41] <dtchen> superm1: ok, r37 is go
[21:51] <superm1> dtchen, awesome.  just tested it, and it's definitely DTRT now, no more troubles
[21:52] <superm1> dtchen, would you like me to sponsor it into karmic?
[21:53] <dtchen> superm1: yes please
[21:55] <superm1> dtchen, okay uploaded.  you may want to merge lp:~superm1/alsa-utils/new-release to  your branch (it's just s/UNRELEASED/karmic and tagging the release)
[21:56] <Zarel_> Hey, guys.
[21:56] <Zarel_> I just realized it's October already. Which stage of releasing Karmic are we at?
[21:57] <dtchen> TheMuso: ^^^
[21:58] <superm1> dtchen, oh i had thought your branch was the main one getting tracked.  is it an ~ubuntu-dev branch somewhere?
[21:58] <superm1> i'll merge it in there if so
[21:58] <superm1> nothing is listed in debian/control
[21:59] <Zarel_> Hmm, the website says "11 days to go". Is there still time to update a package to the latest version?
[21:59] <Zarel_> http://packages.ubuntu.com/karmic/warzone2100
[22:00] <dtchen> superm1: ~ubuntu-core-dev/alsa-utils/ubuntu.new IIRC
[22:00] <dtchen> been a while since I had commit privileges to ~ubuntu-core-dev ;)
[22:01] <superm1> dtchen, how come you don't reapply for them?
[22:01] <dtchen> no time, really
[22:01] <dtchen> the process is a hindrance, and i'd rather just fix the bugs
[22:01] <superm1> says the man who is spending eons of time on audio :)
[22:01] <superm1> i thought for people who had them previously it's not much of a process, but i dont know for sure
[22:02] <dtchen> no idea, and i don't care at this point. my plate is overflowing.
[22:02] <superm1> :)
[22:32] <TheMuso> superm1: thanks a bunch for doing that.
[22:33] <superm1> TheMuso, np.  is there a particular reason that bzr branch isn't advertised in debian/control?  would have avoided the confusion in the first place
[22:34] <TheMuso> superm1: hrm I thought we had it there, so probably just hat we have never added it in, or if we did, it got dropped along the way.
[22:57] <quentusrex> Anyone know how to get a package to STOP trying to fix permissions???
[22:57] <quentusrex> I have configs on an NFS server, and they are set to full permissions, but the package upgrades keep failing because it can't fix the permissions