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 | 00:03 |
---|---|---|
=== IVBela1 is now known as IVBela | ||
=== ripps_ is now known as ripps | ||
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. | 01:06 |
=== 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 | ||
dennda | Hi. Any intention of getting the latest VTK (5.4) into karmic? at the moment, there is no vtk at all | 13:12 |
=== RainCT_ is now known as RainCT | ||
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:35 |
Squideshi | Under what circumstances should one seek to have a package included in the Ubuntu repositories, rather than the Debian repositories? | 16:45 |
wrapster | what is the difference in using dpkg-buildpackage -k<keyid> and -p<sign cmd> | 16:46 |
RainCT | Squideshi: almost none :) | 16:48 |
wrapster | didnt quite understand it.. | 16:48 |
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:49 |
Squideshi | RainCT: That's what I suspected, but I wasn't sure. Thanks for the confirmation. | 16:50 |
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:54 |
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:55 |
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:56 |
ScottK | dennda: apt-cache rdepends <packagename> for each binary in VTK will give you a list. | 16:57 |
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:58 |
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. | 16:59 |
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:00 |
=== sbasuita_ is now known as sbasuita | ||
=== freeflyi1g is now known as freeflying | ||
=== azeem_ is now known as azeem | ||
Zhenech | 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 |
ubottu | Launchpad bug 450821 in mini18n "Yabause crashes with segmentation fault on launch" [Undecided,Fix committed] | 17:38 |
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:01 |
dtchen | bdrung_: that's pretty fantastic work RE eclipse | 18:08 |
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:10 |
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:11 |
maco | its hosted on kde.org, so i suppose so | 18:12 |
maco | or at least the svn is on kde.org | 18:12 |
maco | uh... no, no bugtracker | 18:13 |
maco | just svn | 18:13 |
* maco tries to remember kde svn credentials | 18:14 | |
Laney | hey cool | 18:14 |
Laney | does eclipse work now? | 18:14 |
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:15 |
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:16 |
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:17 |
dtchen | interesting, that would mean that restore_levels() fails | 18:18 |
dtchen | i can't reproduce it locally at all | 18:18 |
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:19 |
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:20 |
Zhenech | randomaction, ok, will do | 18:23 |
dtchen | superm1: thanks | 18:23 |
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:27 |
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:28 |
maco | but i still dont understand | 18:29 |
dtchen | it means you have something broken in your CMake infrastructure | 18:29 |
dtchen | aha! indeed Intrepid users aren't experiencing this issue, because init isn't implied | 18:30 |
* dtchen cheers not announcing behaviour changes | 18:31 | |
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:33 |
dtchen | superm1: that's fine, use /var/lib/alsa/ | 18:34 |
dtchen | superm1: ok, so /var/run/alsa isn't populated on a fresh install? | 18:35 |
superm1 | dtchen, /var/lib/alsa isn't, but /var/run/alsa has a notstoredall file in it | 18:36 |
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:37 |
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:38 |
superm1 | dtchen, so you can reproduce it then? would that explain racy behavior re it too? it seems all of a sudden... | 18:40 |
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:41 |
dtchen | superm1: ok, one more test point: if you call alsactl store now, are the levels still not restored on next boot? | 18:43 |
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 | 18:45 |
=== porthose|afk is now known as porthose | ||
dtchen | superm1: sorry, i'll ping you in ~1 hr | 19:03 |
porthose | bdrung_, great I will email david and let him know ty :) | 19:08 |
bdrung_ | porthose: i already talked with him ;) | 19:11 |
porthose | bdrung_, oh ok even better :) | 19:11 |
bdrung_ | :) | 19:11 |
bdrung_ | porthose: he wrote patches for audacity (which i maintain). so i already knew him. | 19:12 |
porthose | bdrung_, cooool :) | 19:13 |
bdrung_ | porthose: i got your mail and i thought that his name seemed so familiar | 19:15 |
porthose | bdrung_, purely luck of the draw :) | 19:16 |
porthose | bdrung_, haha I have a few more if you would like another | 19:16 |
bdrung_ | porthose: one is enough :p | 19:17 |
porthose | :) | 19:17 |
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:53 |
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:54 |
dtchen | superm1: it's in the bug report that you filed | 19:55 |
dtchen | #454265 | 19:55 |
superm1 | cool thx | 19:55 |
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 :) | 19:58 |
=== asac_ is now known as asac | ||
vorian | no body gonna breaka my syle | 20:01 |
vorian | style too | 20:01 |
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:02 |
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:03 |
maco | and his left | 20:04 |
vorian | :o | 20:04 |
vorian | how was OLF? | 20:04 |
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:05 |
vorian | I must say that kne is quite good | 20:06 |
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:07 |
vorian | haha | 20:08 |
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:09 |
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:10 |
superm1 | dtchen, no it would appear it doesn't | 20:11 |
dtchen | superm1: ok, does it give FAILED? | 20:11 |
superm1 | Shutting down ALSA... [fail] | 20:12 |
dtchen | superm1: and what's in /var/run/alsa ? | 20:12 |
superm1 | dtchen, i've been seeing notstored0 sometimes and notstoredall sometimes | 20:13 |
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:14 |
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:16 |
dtchen | superm1: in that case, yes, but the real issue is that you're getting either 0 or "" | 20:17 |
dtchen | superm1: i.e., it's completely legitimate for the sysadmin to use stop 0 | 20:18 |
superm1 | dtchen, right i see | 20:19 |
jetienne | q. i look for example of website installed by .deb. The only one im thinking about is phpmyadmin. any others ? | 20:37 |
jdong | phpsysinfo? | 20:39 |
jdong | squirrelmail? | 20:39 |
porthose | jetienne, ampache, gallery2, drupal5, drupal6 are some others | 20:53 |
jetienne | jdong: porthose: ok thanks | 20:53 |
dtchen | superm1: changes pushed to bzr (r36) | 21:39 |
dtchen | superm1: actually, hang a sec | 21:39 |
dtchen | superm1: ok, r37 is go | 21:41 |
superm1 | dtchen, awesome. just tested it, and it's definitely DTRT now, no more troubles | 21:51 |
superm1 | dtchen, would you like me to sponsor it into karmic? | 21:52 |
dtchen | superm1: yes please | 21:53 |
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:55 |
Zarel_ | Hey, guys. | 21:56 |
Zarel_ | I just realized it's October already. Which stage of releasing Karmic are we at? | 21:56 |
dtchen | TheMuso: ^^^ | 21:57 |
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:58 |
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 | 21:59 |
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:00 |
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:01 |
dtchen | no idea, and i don't care at this point. my plate is overflowing. | 22:02 |
superm1 | :) | 22:02 |
=== micahg1 is now known as micahg | ||
TheMuso | superm1: thanks a bunch for doing that. | 22:32 |
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:33 |
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:34 |
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 | 22:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!