[00:02] Alt-F2 probably runs things through a shell so that you can do pipes and suchlike [00:03] jdstrand: ack, though I'm sure there must be cases where that goes along with other ability to insert shell configuration; being able to set aliases is just as good [00:03] slangasek: wrt to your point about .profile, we could easily add a line to: eval PATH="$PATH" [00:03] *sigh*, can anyone get this kernel to boot up? Ubuntu keeps spiting it out. It swears profusely [00:04] jdstrand: all you need to do is write a program in ~/bin that, when called, writes some shell configuration to ~/.bashrc and then rewrites itself to erase its trail. This is standard, crackers have been doing that kind of trick since practically the dawn of Unix [00:04] Tyrone_man: i've been trying Intrepid's kernel's in KVM's, no success yet, seems it's a known issue (at least on KVM at the moment) [00:04] and then just wait for it to be called [00:04] intrepid's kernel works in qemu but not kvm [00:04] virtualbox here [00:04] eval PATH="$PATH"> urgh [00:05] :-) [00:05] cjwatson: i thought you'd say that :-) [00:05] I actualy got it going, but the system only installed part ways, not up to pkg select. So then I manualy rebuilt it from cd, and it seemed fine, killed it to reboot, and bam. can't handle it, not synching [00:05] I suspect this swamp might be why nobody has done this properly yet ;-) [00:05] yep! [00:05] cjwatson: yeah, you noticed the bit above where pam_env documentation says stuff like $HOME probably won't be set yet, huh? [00:06] cjwatson: that sort of knocked me off the horse (again) [00:07] kirkland: yeah [00:07] I alluded to that earlier, as a wild-ass guess ;-) [00:07] 22:55 kirkland: /etc/environment makes sense if $HOME expansion is possible there and if PAM clients actually handle that properly (i.e. have set $HOME when they run pam_env) [00:08] cjwatson: ah, so you did ... :-/ [00:08] I don't suppose you could draw a diagram of all the possible routes into the system? [00:09] annotated with the configuration files read at each step [00:09] then we might at least be able to look at it and figure out something better than we have now [00:10] cjwatson: by routes into the system, you mean, login/ssh/etc? [00:10] right, each thing that reads a configuration file and sets environment variables [00:11] so sshd -> pam_env -> bash, that kind of thing [00:11] if that makes sense [00:15] cjwatson: and the eval PATH="$PATH" is completely unacceptable? [00:15] * kirkland saw cjwatson redirect stdout to "urgh" :-) [00:15] which wasn't quite /dev/null :-p [00:16] augh, gvfsd-smb-browse is going to be the death of me [00:19] kirkland: I'd be worried that the potential behaviour change is rather worse. wanting a literal ${...} is pretty unlikely, but I can imagine somebody putting an environment variable containing (say) ` in /etc/environment ... [00:20] or indeed " [00:20] kirkland: also, doing that in .profile takes you right back to where you started; now the environment variables are only properly expanded for things that descend from .profile [00:20] -> might as well not have bothered [00:21] cjwatson: hmm, except that the desktop managers handle this properly somehow [00:21] like I say I bet Alt-F2 goes through the shell [00:21] stuff actually execlped by a program straight from the desktop not through a shell probably goes wrong [00:22] cjwatson: agree with the latter [00:22] shoving command lines through shells is so common that you may have to look reasonably carefully to find real counterexamples, but I'm confident they'll exist and they'll be basically unfixable [00:26] cjwatson: okay, well, i suppose I'm going to need to politely concede this bug outside of my present fu :-( [00:29] cjwatson: the change adding ~/bin to the end of PATH is present in Intrepid's PAM, 0.99.7.1-6ubuntu1 ... That change was sponsored on Friday. You may want to back that out, and bug 64064 needs to be reopened [00:29] Launchpad bug 64064 in pam "would be nice to add ~/bin to the default PATH" [Wishlist,Fix released] https://launchpad.net/bugs/64064 [00:35] cjwatson: certainly-- that is what I am talking about. ~/bin first in the path makes that easier [00:35] cjwatson: oh sorry, I only caught your 2nd comment [00:37] cjwatson: anyway, I am not advocating many users' scripts to protect the few with an open ~/bin [00:38] s/many/potentially breaking many/ [00:38] jdstrand: (I meant a typo-squatting script more than anything else, really) [00:38] sl is probably a good candidate ;) [00:38] heh [00:39] cjwatson: that would work too of course [00:41] cjwatson: so I guess, really, the best thing to do is nix ~/bin from the PATH completely :P [00:42] ah, now you're twisting my words ;-) [00:42] that wouldn't break anything [00:42] heh-- only teasing [01:04] cjwatson: i took a look at documenting entry points to the system, i jotted down some notes. it'll need to be a wiki document with contributions by others, in that my pam understanding is somewhat limited compared to a few others [01:04] aye [01:05] (er, confirmed; not meaning to slur your PAM understanding :-) ) [01:05] "jotted down" = pen and paper ... i'll have to move them to the wiki [01:05] * kirkland didn't take offense ;-) [01:05] and by "a few others" i mean "lots of others" :-) [01:06] hmm, now why is http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html broken [01:06] cjwatson: how so? (I've never looked at it, but it popped right up here) [01:06] * TheMuso noticed that it was out of date yesterday but wasn't sure how regularly it was supposed to run. [01:07] ah Jun 19 [01:07] right, out of date, it's supposed to run hourly [01:07] gotcha [01:07] fails with no output :-( [01:07] cjwatson: probably a PATH problem :P [01:10] jdstrand: LoL [01:12] TheMuso: did you get as far as merging initramfs-tools? it's in the updated merges section, but only because I had to fix it up a bit for the new busybox and some others touched it in intrepid too [01:13] cjwatson: I hadn't looked at it, as I wasn't the last one who touched it in hardy, but I can have a look if you'd like. [01:13] just because IIRC you did some Debian bug forwarding for it [01:13] Yes thats right, some of which got into Debian. [01:14] if you could have a go, it would be very helpful [01:14] Ok I'll take a look today at some point. [01:17] ooh, a new parted upstream too [01:20] fwiw, I've gotten a private inquiry from a member of the Debian kernel team (maks) about initramfs-tools resyncing, he was interested in seeing that get done [01:21] TheMuso: so I'm happy to hook you two up on this if you do take it [01:24] slangasek: I've already had some contact with an initramfs-tools maintainer in the past when I filed bugs in Debian to get some of our changes back to Debian. [01:24] ok :) [01:24] probably the same one then [01:25] I don't think anyone besides maks is taking care of it in Debian right now [01:25] If you're fixing initramfs-tools stuff, could you poke at the NFS boot stuff in 8.04? :) [01:25] ipconfig or something is broken, so getting IP by DHCP for NFS boot is full of fail [01:26] slangasek: Right, he's the one. === cjwatson_ is now known as cjwatson [01:39] slangasek: I've also noticed that alsa-lib/plugins 1.0.16 is still in proposed... [01:39] yah, I'll pull it today yet [01:40] TheMuso: how are you coming with targeted fixes? Any progress with bisecting? [01:40] Np, was just wondering whether something else came up that I didn't know about. [01:41] slangasek: I have to work out a way that won't take too much time, yet allow users to test revisoins. Note that I don't experience any issues myself, so I need affected users to test revisions taken from the upstream git repo... [01:41] right [01:42] well, the nice thing about a binary search is that it reduces the number of iterations you have to go through to find the fix log2(n) [01:42] how many commits are there between 1.0.15 and 1.0.16 upstream? [01:42] Yeah I know. The fun bit is running a bisection test for several kinds of bugs, both of which will likely be fixed by different revisions [01:43] Just a sec I'll check. [01:47] slangasek: 74, so when I start the bisect, it starts off cutting that down to 36. [01:47] to deal with after the first bisection. [01:48] TheMuso: well, log2(74) < 6, so 7 is the maximum number of builds you'd have to get any one user to try in order to pinpoint their bug fix [01:48] uh, < 7 I mean [01:49] slangasek: Yeah I figured. What I am thinking is to publish one package, get several users to test, and keep two trees, so I can track bisection for different issues, so I can mark one as bad and the other vise versa if I have to... Unless a better idea is forthcoming. [01:50] that sounds like the right track to me [02:16] * cjwatson bets the problem with testing/intrepid_probs is that that timestamp was about when drescher was upgraded to hardy [02:19] TheMuso: which symptoms? The ones in 221673 or 191027? [02:19] I've rebuilt its Python extension and with any luck it'll work now [02:19] next run will probably be in 40 minutes or so [02:19] TheMuso: note that 1.0.16 is insufficient for at least one comment in the former. That's a dmix issue fixed in -lib hg. [02:22] crimsun_: We are not going 1.0.16 wholesale any more. [02:23] yes, I advised that doing so would be a bad idea some time ago. [02:25] which specific bugs will you attempt to address in alsa-lib? [02:26] crimsun_: Well bug 191027 is known to have a fix in 1.0.16 at least for some users. [02:26] Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed] https://launchpad.net/bugs/191027 [02:27] As for bug 221673 I actually prepared an SRU which is shown in that bug with diffs against plugins and lib. [02:27] Launchpad bug 221673 in alsa-plugins "ALSA failing with PulseAudio in Hardy" [Undecided,Fix committed] https://launchpad.net/bugs/221673 [02:30] TheMuso: wrt 191027, which comments? There are too many unrelated comments cluttering the report. [02:31] for instance, the maudio one(s) are not alsa-lib; they're pulseaudio not handling channel mapping. Difficult issue that can't really be addressed aside from altering /etc/pulse/default.pa [02:31] crimsun_: From https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/191027/comments/75 downwards. [02:31] Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed] [02:31] crimsun_: Yeah I'm aware of the m-audio stuff. [02:33] sigh, again, nastiness with snd-hda-intel [02:33] that's not alsa-lib; that's l-u-m-2.6.24 [02:33] right [02:33] (referring to comment 88) [02:33] The more I work/look at this stuff, the more of a pile of dung I consider alsa to be... [02:34] oh ok [02:34] It's not audio, it's computed gotos! [02:39] Dont we have skype in repos? all i can find is skytools but im not sure if that is full skype type package [02:39] oops wrong channel [02:47] crimsun_: So, do you think 191027 is not worth pursuing in a manner I described above? [02:48] TheMuso: afraid I can't answer ATM, haven't finished reading all the comments and possibly related commits [02:48] crimsun_: ok [03:08] wow, this is sweet - a color blindness extension http://kaioa.com/node/75 [03:37] heh [03:38] bryce [03:38] we had a SoC that did that in compiz [03:39] I mean, its a display only affect (unlike inkscape?) but its' been there for ages =/ [03:41] https://bugs.edge.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/237848 [03:41] Launchpad bug 237848 in compiz-fusion-plugins-main "colorfilter colorblind simulations not accessible in CCSM" [Undecided,Confirmed] [03:41] pwnguin: well cool regardless :-) [03:42] its even cooler to try out games / webpages / presentations with [03:42] "does my graphic work for colorblind students?" [03:43] bryce: have you heard of an issue with Intrepid nvidia drivers not working after the update of the restricted kernal package? For me i had to re write my xorg.conf to get it to work and others have stated they had issues? [03:43] -? [03:44] gnomefreak: you mean besides xen stuff? [03:44] yep [03:44] atleast for me [03:44] i wasnt aware xen was fixed =/ [03:44] i dont use xen [03:44] me either [03:44] but its in -generic now? [03:45] oh it is? [03:45] gnomefreak: hmm, not with intrepid so far (a couple reports with hardy, but were probably just mixed installs) [03:45] gnomefreak: is it a kernel ABI mismatch perhaps? [03:45] i dont think you'll get many nvidia broken reports until alpha1 [03:45] bryce: i didnt have issue in Hardy [03:45] bryce: not sure bug i will look at logs tomorrow and see if anything in there helps [03:45] ok [03:46] bryce: (for hardy-*, I've heard of people missing l-r-m deps for linux-image-* dist-upgrades) [03:46] * bryce nods [03:46] TheMuso: ping [03:50] TheMuso: hey, I have another round of the yaboot-installer merge [03:51] kirkland: Ok I'm around. [03:52] TheMuso: okay, let me push [03:54] TheMuso: okay, pushed, waiting for LP to catch up ;-) [03:54] kirkland: ok [04:05] kirkland: kirkland I see it, I'll pull it down and have a look in a bit. [04:05] TheMuso: i'm not sure it's clean yet [04:06] TheMuso: i'm very bothered by an error 500 on: http://bazaar.launchpad.net/~kirkland/yaboot-installer/intrepid2/revision/259 [04:06] Aye. I get it also. [04:06] slangasek: I have an SRU regression I need to report. Are you around? [04:07] * ScottK guesses the tech board is sleeping. [04:08] kirkland: However, I have managed to branch it to my machine here. [04:08] TheMuso: interesting, okay... maybe there's a stray character in the changelog or something? [04:09] kirkland: Did you consider getting MoN's help to do this merge? [04:09] TheMuso: you mean MoM? [04:10] ScottK: which package? [04:11] TheMuso: I did it that way originally, but cjwatson asked me to use the bzr merge method. This is the first time I have used bzr for Ubuntu package merging. [04:11] * pwnguin isn't on the tech board or anything like that, but if it's about glchess / gnome-games, I think slasgsek knows about it [04:12] aptoncd. [04:13] kirkland: Right. [04:13] ScottK: i think you're supposed to highlight trigger everyone on the TB if its important [04:14] * ScottK is writing mail currently. [04:14] that too [04:17] TheMuso: i'm up for about another 45 minutes or so before I call it a night [04:17] TheMuso: if you review, and figure out what's wrong, I'm all ears :-) [04:17] kirkland: Whats the current problem with it? [04:17] TheMuso: oh, just the wierdness with the changelog not being visible [04:18] TheMuso: the error 500 problem, i meant [04:18] What do you mean not being visible? [04:18] oh right. [04:18] ScottK: mmm, moderately around [04:18] kirkland: Whats with the empty commit? [04:18] slangasek: bug 242554 [04:18] Launchpad bug 242554 in aptoncd "hardy-proposed packages built against python-central uninstallable in hardy-updates" [Critical,Confirmed] https://launchpad.net/bugs/242554 [04:19] TheMuso: thought that might solve the 500 error [04:19] TheMuso: I can uncommit that if necessary [04:19] Just sent mail to the tech board, devel-discuss, etc. [04:19] kirkland: Right. [04:19] TheMuso: not that I have extensive bzr experience, but i've never seen this sort of thing [04:19] kirkland: It may have something to do with that revision being a merge. [04:19] at a guess [04:19] pocket copies aren't so great when the pockets have different versions of the build-depends. [04:20] ScottK: ok; I'll see if I can't get python-central verified and copied over tonight === shadowxp is now known as shadow [04:20] slangasek: Thanks. [04:24] TheMuso: okay, i just uncommitted the empty message [04:25] kirkland: One thing that you should do is document the maintainer field change. [04:25] * ScottK ponders if he should add 'ping the archive admin who is most likely to be awake' to the SRU regression procedure. [04:25] kirkland: in the changelog. [04:26] TheMuso: right, okay [04:27] TheMuso: committed/pushed [04:28] kirkland: Ok. [04:28] kirkland: It looks ok to me, I'm just pulling your previous branch to see what Colin was getting at with his comments. [04:29] TheMuso: sorry, i usually use "update-maintainer", which fixes the maintainer and adds a changelog entry [04:29] TheMuso: the last one was a mess... i misunderstood his instructions, and did totally the wrong thing [04:29] kirkland: Thats fine, but in this case it would not work as the maintainer is already changed. [04:29] kirkland: Oh right. [04:29] TheMuso: right [04:29] So its just as easy to put the entry in by hand. [04:29] dch -a [04:29] Type text [04:29] save, exit. [04:31] TheMuso: I'll add that to my list of things to do differently between a deb/bzr merge [04:31] kirkland: Its not a matter of doing things differently. Even when doing a merge, the changing of the maintainer field should be documented in the changelog entry for the merge. [04:31] Regardless whether its a deb only, or involves a vcs branch of some sort. [04:35] TheMuso: understood. [04:36] kirkland: I see what you mean, that original branch is quite big. :) [04:36] kirkland: Anyway, it looks fine to me, bar that entry in the changelog. [04:36] TheMuso: pull revision 260 [04:37] TheMuso: I reverted the empty commit, and added the changelog entry you requested [04:37] kirkland: gotcha. [04:37] kirkland: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [04:37] kirkland: I suggest you push --overwrite [04:37] since you reverted a commit that was pushed [04:38] TheMuso: "No new revisions to push." ... this was why I made an empty commit earlier [04:38] kirkland: hrm ok. [04:38] TheMuso: YOu'll have to recheck it out. [04:39] Or remove some revisions from your branch. [04:39] wgrant: Yeah thats my thought. [04:39] ok pulled the empty commit locally and now it pulls successfully. [04:41] kirkland: Ok that looks fine to me. [04:41] TheMuso: cool, what's next? you merge into main? [04:41] the main branch i mean? [04:42] kirkland: The next thing is for you to update the changelog from UNRELEASED to hardy, then I'll merge it into the core-dev branch and upload. [04:42] s/hardy/intrepid/ [04:42] TheMuso: hmm, okay... at what point do I do that? cjwatson asked me to set it to UNRELEASED... was that just long enough to get it vetted by you guys? [04:43] kirkland: Hrm ok. He told me to upload once I was done, so I guess me merging and doing that myself makes sense. [04:44] TheMuso: okay, so you pull my branch, fix the target release, and you'll push to the main branch? [04:44] kirkland: Yes. [04:44] TheMuso: awesome, thanks for the lesson [04:44] kirkland: You're welcome. [04:53] slangasek: superm1: laga: mythbuntu amd64 8.04.1 installed fine for me ;-) [04:54] great [04:54] thanks kirkland [04:55] just need to generate our live disks then and make sure those are still good too [04:55] superm1: no prob [04:55] kirkland, hows the ppc build working? [04:55] does your ppc have altivec? [04:56] superm1: the ppc frontend is working for the first time in months! [04:56] superm1: how do i tell? is it in /proc/cpuinfo? [04:57] should be i believe [04:57] what generation of PPC is it? [04:57] superm1: mac mini, g4, i believe [04:58] oh yeah that'll have altivec [04:58] superm1: i'm checking [04:58] its the earlier ones that didn't [04:58] w/o altivec, i believe video is practically unplayable on there [04:59] G3 == no altivec, G4-G5 == altivec. [04:59] there's the info i was looking for [04:59] kirkland: Note that the Minis, even the 1.42 model can't play HD video, since the CPU just can't hack it. [05:00] TheMuso: yeah, sadly i know [05:01] superm1: yeah, it does have altivec [05:02] kirkland, i was actually considering an apple tv for a frontend until i heard the obscene specs that are going to be necessary for HD-PVR support [05:02] oh well [05:03] superm1: Obscene? What do you mean exactly? [05:03] superm1: yeah, the form factor is just so attactive [05:04] TheMuso, well people are saying AMD64 5000+ minimum, and high end geforce 9xxx cards w/ hardware assistance [05:04] to be able to handle decoding [05:04] That seems to be substantially above what I've read. [05:05] depends on the quality [05:05] superm1: i have an amd64 3800 that renders HD just fine [05:05] HD-PVR files are x264 spit out [05:05] the super high res stuff i wouldnt doubt [05:05] that's reassuring to me to hear RAOF. i've not kept up the last week or two [05:05] I seem to recall benchmarks of the 8xxx/9xxx hardware assistance taking some 10% CPU on a not-too-super core2 with h.264 1080p [05:06] RAOF: i wonder how much that falls with say a 6xxx [05:06] Totally. [05:06] * TheMuso is thinking of using an intel mini for his frontend when he moves, as long as his server will have a tv port nearby. [05:06] There just isn't any hardware assist there. [05:06] i'll look for some more accurate benchmarks as the hardware becomes more prevalent [05:06] do the new mini's have digital sound out? [05:07] kirkland: Yes. [05:07] Shared with headphone/line out. [05:07] superm1: Also, these were Windows benchmarks; it's likely that you'll see close to no hardware assist on linux. [05:07] RAOF: my x2 4000+ with a 6600gt does okay, but drops frames / stutters [05:07] TheMuso: 5.1 coax or optical? [05:07] kirkland: Optical. [05:07] Amd 5.1 afaik yes. [05:07] TheMuso: nice! [05:08] RAOF: and that's just on 720 =( [05:08] kirkland: As I said, only if I don't need to have the tuner card in the frontend. [05:08] superm1: Unless you'd like to hack on the gallium video decoder state tracker :) [05:08] I don't trust USB for anything but keyboard/mouse. [05:08] RAOF, oh! yeah linux requirements are much higher unfortunately [05:09] pwnguin: Right. dual-core isn't very useful for decoding, so you're better off with really fast single threaded performance, which is expensive. [05:10] I would also get a mini only if they were updated with better GPU chips, even a higher/more recent intel chip. [05:13] kirkland: heh won't be uploading it just yet, need to set up a PowerPC build environment for intrepid, something I've been meaning to do for a while now. :p [05:13] So I can test build. [05:13] TheMuso: so that's another question i have for you... [05:14] TheMuso: if this was deb merge, i would have debuild'ed ... [05:14] TheMuso: what's the build process for this? [05:14] kirkland: IMO its better to always build in a chroot, unless you need to step through a package's build process step by step to find an FTBF. [05:15] kirkland: What I'm doing for this, is fixing the branch up appropriately, i.e UNRELEASED to intrepid, and committing. Then I use the bzr-buildpackage ocmmand to export to a source package format, i.e .dsc file and .tar.gz file. [05:15] The exact command I'm using is 'bzr-buildpackage -S --native' [05:16] TheMuso: ah, cool! that's the part I was missing.... [05:25] kirkland: Ok build environment set up, test building. [05:33] kirkland: Uploaded. [05:34] TheMuso: cool, thanks for working me through this one [05:35] kirkland: np [05:35] TheMuso: I'm calling it a night ;-) [05:35] kirkland: Good night then. === Zic_ is now known as Zic [06:20] why suddenly so many kernel updates ? [06:21] orbisvicis: Because 8.04.1 is nearly done? :) [06:22] oh. 8.0.4.1 ? [06:25] the "now its really stable" release ;) [06:27] ok, evolution just erased my calendar. [06:27] heh thanks [06:27] good job [06:30] so will 8.0.4.1 have a feature in it to prevent anything from STEALING FOCUS ever? [06:30] bluefoxicy: Evolution isn't capable of doing that to me; it's google-calendar support doesn't work well enough for me :) [06:31] RAOF: I tried to type a note and the keyboard stopped working, then pasted a date field. I hit ctrl+alt+arrows and couldn't switch desktops. I couldn't click other windows. I hammered around on alt/ctrl/shift/etc to see if a key was stuck, no such luck [06:31] is there a roadmap ? [06:31] evolution then closed, said it couldn't access my "memo" until it restarted, and then came up with a blank calendar. [06:31] blank as in tasks from 3 days ago were gone even. [06:32] bluefoxicy: That sucks a lot. [06:32] you're telling me? [06:32] I've had numerous incidents where some application locks up my mouse and keyboard and I can't do anything in X [06:37] win! [06:37] I added one new appointment and it ressurected all lost data by magic. [06:37] Huzzah! [06:37] I have no way to reproduce this or describe the original bug, or provide explanation for WHY it happened [06:40] You probably could have rescued it with a magic-sysreq combination; Whatever it is that switches the keyboard back to "raw" mode would probably have let you VT switch. Where you could have made a guess as to what was holding things hostage. [06:40] RAOF: I thought it switched it _out_ of raw mode [06:42] bluefoxicy: Do you use compiz? If so, did it happen during a focus change? [06:42] no compiz [06:44] Amaranth: It's a _magic_ sysrq key. Maybe it swiches me to raw, and you out of raw? :) I'm really not sure, though. [06:45] I can vt switch [06:45] and when I switch back to X i'm stuck again [06:45] eep, my sysrq is a prtsc [06:46] the problem is having 20-30 windows and effectively killing random ones and/or X, depending. If you kill a holding program it might not return control to X; Qemu for example does this (hence why I don't run it anymore) [06:47] for the misfortunate soul who kills qemu when it freezes, you have to run 'DISPLAY=0 qemu ' in a real terminal to start a new one to get your mouse back <_< [06:47] imagine losing it to something that doesn't normally grab, and thus won't be nice and reset control for you [06:50] X grabs are broken [06:51] Good morning [06:51] Amaranth: is there a program I can run to tell X to reclaim? [06:51] bluefoxicy: I don't think so [06:51] Otherwise they wouldn't be quite as broken :P [06:52] heh I was going to suggest watching the event device but whether it's /proc or /dev or actually works anymore i can't tell [06:53] you used to be able to read raw keyboard (console) events from some interface, and so pick up key combinations like alt+sysrq+x ;) [07:05] Hallo [07:05] Is there a public list of Canonical Paid Devs? [07:05] good morning [07:05] morning [07:06] Canonical employment records are not public information, no [07:06] ok [07:07] Is there a number? [07:07] We employ 28 People? === tkamppeter_ is now known as tkamppeter [07:08] Canonical employs more people than that, but I'm not aware of any public head count, either [07:08] It's not a public company is it? [07:08] nope [07:09] Would have been fun to own a bit of history ^_^ [07:11] there are some LP teams that might suggest some status of employment [07:12] but there's likely a few other groups that dont need LP etc. [07:12] pwnguin: Not really [07:13] webmasters? sysadmins? lawyers? [07:14] well, there's at least one LP team whose members consist entirely of Canonical employees (canonical-kernel-team), but that doesn't give you a very good overview of the on-staff developers :) [07:14] there's also canonical-qa [07:14] but i dont think it would be healthy for canonical to publish a list of "people to hire away to cripple our company" [07:16] pwnguin: Or how many people you would have to attempt at doing so [07:16] heh === thegodfather is now known as fabbione [07:17] slangasek: Can you please look at bug #206912 and convince Soyuz that vlc really should be in multiverse? [07:17] Launchpad bug 206912 in vlc "Demote vlc and rdepends to multiverse" [Medium,Fix released] https://launchpad.net/bugs/206912 [07:17] It didn't go anywhere. [07:17] Much like nagios2. [07:18] Ah. [07:18] It did get demoted. [07:18] But then bounced. [07:18] "bounced"? [07:19] Yes. [07:19] The next upload decided to go into universe. [07:19] (some 12 hours after it was demoted) [07:19] repos are considered demotions? :) [07:19] Huh. [07:19] DasKreecH: well, being relegated to the archive for non-free software is definitely considered a demotion... [07:19] Universe->Multiverse is considered a demotion, yes. [07:19] Only the source changed. [07:19] well multiverse is ;) [07:20] The binaries are still multiverse. [07:20] DasKreecH: There's a concept of mutiverse -> universe -> main being "promotion", and the reverse "demotion". [07:20] wgrant: yeah, source and hppa... nice :) [07:20] This is interesting: [07:20] 2008-04-15 01:02:03 INFO Override Component to: 'multiverse' [07:20] 2008-04-15 01:02:03 INFO 'vlc - 0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu2/multiverse/graphics' source overridden [07:20] The source looks like it was multiverse initially. [07:20] So it got overriden to the same place, and then forgot about it 12 hours later. [07:21] 2008-06-24 06:21:02 WARNING 'vlc' has no binaries published in intrepid [07:21] [07:21]