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