[00:02] <cjwatson> Alt-F2 probably runs things through a shell so that you can do pipes and suchlike
[00:03] <cjwatson> 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] <kirkland> slangasek: wrt to your point about .profile, we could easily add a line to: eval PATH="$PATH"
[00:03] <Tyrone_man> *sigh*, can anyone get this kernel to boot up? Ubuntu keeps spiting it out. It swears profusely
[00:04] <cjwatson> 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] <kirkland> 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] <cjwatson> and then just wait for it to be called
[00:04] <cjwatson> intrepid's kernel works in qemu but not kvm
[00:04] <Tyrone_man> virtualbox here
[00:04] <cjwatson> eval PATH="$PATH"> urgh
[00:05] <slangasek> :-)
[00:05] <kirkland> cjwatson: i thought you'd say that :-)
[00:05] <Tyrone_man> 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] <cjwatson> I suspect this swamp might be why nobody has done this properly yet ;-)
[00:05] <slangasek> yep!
[00:05] <kirkland> cjwatson: yeah, you noticed the bit above where pam_env documentation says stuff like $HOME probably won't be set yet, huh?
[00:06] <kirkland> cjwatson: that sort of knocked me off the horse (again)
[00:07] <cjwatson> kirkland: yeah
[00:07] <cjwatson> I alluded to that earlier, as a wild-ass guess ;-)
[00:07] <cjwatson> 22:55 <cjwatson> 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] <kirkland> cjwatson: ah, so you did ...  :-/
[00:08] <cjwatson> I don't suppose you could draw a diagram of all the possible routes into the system?
[00:09] <cjwatson> annotated with the configuration files read at each step
[00:09] <cjwatson> then we might at least be able to look at it and figure out something better than we have now
[00:10] <kirkland> cjwatson: by routes into the system, you mean, login/ssh/etc?
[00:10] <cjwatson> right, each thing that reads a configuration file and sets environment variables
[00:11] <cjwatson> so sshd -> pam_env -> bash, that kind of thing
[00:11] <cjwatson> if that makes sense
[00:15] <kirkland> cjwatson: and the eval PATH="$PATH" is completely unacceptable?
[00:15]  * kirkland saw cjwatson redirect stdout to "urgh"  :-)
[00:15] <kirkland> which wasn't quite /dev/null :-p
[00:16] <slangasek> augh, gvfsd-smb-browse is going to be the death of me
[00:19] <cjwatson> 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] <cjwatson> or indeed "
[00:20] <cjwatson> 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] <cjwatson> -> might as well not have bothered
[00:21] <kirkland> cjwatson: hmm, except that the desktop managers handle this properly somehow
[00:21] <cjwatson> like I say I bet Alt-F2 goes through the shell
[00:21] <cjwatson> stuff actually execlped by a program straight from the desktop not through a shell probably goes wrong
[00:22] <kirkland> cjwatson: agree with the latter
[00:22] <cjwatson> 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] <kirkland> cjwatson: okay, well, i suppose I'm going to need to politely concede this bug outside of my present fu :-(
[00:29] <kirkland> 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:35] <jdstrand> cjwatson: certainly-- that is what I am talking about. ~/bin first in the path makes that easier
[00:35] <jdstrand> cjwatson: oh sorry, I only caught your 2nd comment
[00:37] <jdstrand> cjwatson: anyway, I am not advocating many users' scripts to protect the few with an open ~/bin
[00:38] <jdstrand> s/many/potentially breaking many/
[00:38] <cjwatson> jdstrand: (I meant a typo-squatting script more than anything else, really)
[00:38] <cjwatson> sl is probably a good candidate ;)
[00:38] <jdstrand> heh
[00:39] <jdstrand> cjwatson: that would work too of course
[00:41] <jdstrand> cjwatson: so I guess, really, the best thing to do is nix ~/bin from the PATH completely :P
[00:42] <cjwatson> ah, now you're twisting my words ;-)
[00:42] <jdstrand> that wouldn't break anything
[00:42] <jdstrand> heh-- only teasing
[01:04] <kirkland> 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] <cjwatson> aye
[01:05] <cjwatson> (er, confirmed; not meaning to slur your PAM understanding :-) )
[01:05] <kirkland> "jotted down" = pen and paper ... i'll have to move them to the wiki
[01:05]  * kirkland didn't take offense ;-)
[01:05] <kirkland> and by "a few others" i mean "lots of others" :-)
[01:06] <cjwatson> hmm, now why is http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html broken
[01:06] <jdstrand> 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] <jdstrand> ah Jun 19
[01:07] <cjwatson> right, out of date, it's supposed to run hourly
[01:07] <jdstrand> gotcha
[01:07] <cjwatson> fails with no output :-(
[01:07] <jdstrand> cjwatson: probably a PATH problem :P
[01:10] <kirkland> jdstrand: LoL
[01:12] <cjwatson> 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] <TheMuso> 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] <cjwatson> just because IIRC you did some Debian bug forwarding for it
[01:13] <TheMuso> Yes thats right, some of which got into Debian.
[01:14] <cjwatson> if you could have a go, it would be very helpful
[01:14] <TheMuso> Ok I'll take a look today at some point.
[01:17] <cjwatson> ooh, a new parted upstream too
[01:20] <slangasek> 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] <slangasek> TheMuso: so I'm happy to hook you two up on this if you do take it
[01:24] <TheMuso> 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] <slangasek> ok :)
[01:24] <slangasek> probably the same one then
[01:25] <slangasek> I don't think anyone besides maks is taking care of it in Debian right now
[01:25] <Twigathy> If you're fixing initramfs-tools stuff, could you poke at the NFS boot stuff in 8.04? :)
[01:25] <Twigathy> ipconfig or something is broken, so getting IP by DHCP for NFS boot is full of fail
[01:26] <TheMuso> slangasek: Right, he's the one.
[01:39] <TheMuso> slangasek: I've also noticed that alsa-lib/plugins 1.0.16 is still in proposed...
[01:39] <slangasek> yah, I'll pull it today yet
[01:40] <slangasek> TheMuso: how are you coming with targeted fixes?  Any progress with bisecting?
[01:40] <TheMuso> Np, was just wondering whether something else came up that I didn't know about.
[01:41] <TheMuso> 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] <slangasek> right
[01:42] <slangasek> 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] <slangasek> how many commits are there between 1.0.15 and 1.0.16 upstream?
[01:42] <TheMuso> 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] <TheMuso> Just a sec I'll check.
[01:47] <TheMuso> slangasek: 74, so when I start the bisect, it starts off cutting that down to 36.
[01:47] <TheMuso> to deal with after the first bisection.
[01:48] <slangasek> 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] <slangasek> uh, < 7 I mean
[01:49] <TheMuso> 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] <slangasek> 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] <crimsun_> TheMuso: which symptoms?  The ones in 221673 or 191027?
[02:19] <cjwatson> I've rebuilt its Python extension and with any luck it'll work now
[02:19] <cjwatson> next run will probably be in 40 minutes or so
[02:19] <crimsun_> 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] <TheMuso> crimsun_: We are not going 1.0.16 wholesale any more.
[02:23] <crimsun_> yes, I advised that doing so would be a bad idea some time ago.
[02:25] <crimsun_> which specific bugs will you attempt to address in alsa-lib?
[02:26] <TheMuso> crimsun_: Well bug 191027 is known to have a fix in 1.0.16 at least for some users.
[02:27] <TheMuso> As for bug 221673 I actually prepared an SRU which is shown in that bug with diffs against plugins and lib.
[02:30] <crimsun_> TheMuso: wrt 191027, which comments?  There are too many unrelated comments cluttering the report.
[02:31] <crimsun_> 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] <TheMuso> crimsun_: From https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/191027/comments/75 downwards.
[02:31] <TheMuso> crimsun_: Yeah I'm aware of the m-audio stuff.
[02:33] <crimsun_> sigh, again, nastiness with snd-hda-intel
[02:33] <crimsun_> that's not alsa-lib; that's l-u-m-2.6.24
[02:33] <TheMuso> right
[02:33] <crimsun_> (referring to comment 88)
[02:33] <TheMuso> The more I work/look at this stuff, the more of a pile of dung I consider alsa to be...
[02:34] <TheMuso> oh ok
[02:34] <StevenK> It's not audio, it's computed gotos!
[02:39] <gnomefreak> 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] <gnomefreak> oops wrong channel
[02:47] <TheMuso> crimsun_: So, do you think 191027 is not worth pursuing in a manner I described above?
[02:48] <crimsun_> TheMuso: afraid I can't answer ATM, haven't finished reading all the comments and possibly related commits
[02:48] <TheMuso> crimsun_: ok
[03:08] <bryce> wow, this is sweet - a color blindness extension http://kaioa.com/node/75
[03:37] <pwnguin> heh
[03:38] <pwnguin> bryce
[03:38] <pwnguin> we had a SoC that did that in compiz
[03:39] <pwnguin> I mean, its a display only affect (unlike inkscape?) but its' been there for ages =/
[03:41] <pwnguin> https://bugs.edge.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/237848
[03:41] <bryce> pwnguin: well cool regardless :-)
[03:42] <pwnguin> its even cooler to try out games / webpages / presentations with
[03:42] <pwnguin> "does my graphic work for colorblind students?"
[03:43] <gnomefreak> 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] <gnomefreak> -?
[03:44] <pwnguin> gnomefreak: you mean besides xen stuff?
[03:44] <gnomefreak> yep
[03:44] <gnomefreak> atleast for me
[03:44] <pwnguin> i wasnt aware xen was fixed =/
[03:44] <gnomefreak> i dont use xen
[03:44] <pwnguin> me either
[03:44] <pwnguin> but its in -generic now?
[03:45] <gnomefreak> oh it is?
[03:45] <bryce> gnomefreak: hmm, not with intrepid so far (a couple reports with hardy, but were probably just mixed installs)
[03:45] <bryce> gnomefreak: is it a kernel ABI mismatch perhaps?
[03:45] <pwnguin> i dont think you'll get many nvidia broken reports until alpha1
[03:45] <gnomefreak> bryce: i didnt have issue in Hardy
[03:45] <gnomefreak> bryce: not sure bug i will look at logs tomorrow and see if anything in there helps
[03:45] <bryce> ok
[03:46] <crimsun_> bryce: (for hardy-*, I've heard of people missing l-r-m deps for linux-image-* dist-upgrades)
[03:46]  * bryce nods
[03:46] <kirkland> TheMuso: ping
[03:50] <kirkland> TheMuso: hey, I have another round of the yaboot-installer merge
[03:51] <TheMuso> kirkland: Ok I'm around.
[03:52] <kirkland> TheMuso: okay, let me push
[03:54] <kirkland> TheMuso: okay, pushed, waiting for LP to catch up ;-)
[03:54] <TheMuso> kirkland: ok
[04:05] <TheMuso> kirkland: kirkland I see it, I'll pull it down and have a look in a bit.
[04:05] <kirkland> TheMuso: i'm not sure it's clean yet
[04:06] <kirkland> TheMuso: i'm very bothered by an error 500 on: http://bazaar.launchpad.net/~kirkland/yaboot-installer/intrepid2/revision/259
[04:06] <TheMuso> Aye. I get it also.
[04:06] <ScottK> slangasek: I have an SRU regression I need to report.  Are you around?
[04:07]  * ScottK guesses the tech board is sleeping.
[04:08] <TheMuso> kirkland: However, I have managed to branch it to my machine here.
[04:08] <kirkland> TheMuso: interesting, okay...  maybe there's a stray character in the changelog or something?
[04:09] <TheMuso> kirkland: Did you consider getting MoN's help to do this merge?
[04:09] <kirkland> TheMuso: you mean MoM?
[04:10] <pwnguin> ScottK: which package?
[04:11] <kirkland> 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] <ScottK> aptoncd.
[04:13] <TheMuso> kirkland: Right.
[04:13] <pwnguin> 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] <pwnguin> that too
[04:17] <kirkland> TheMuso: i'm up for about another 45 minutes or so before I call it a night
[04:17] <kirkland> TheMuso: if you review, and figure out what's wrong, I'm all ears :-)
[04:17] <TheMuso> kirkland: Whats the current problem with it?
[04:17] <kirkland> TheMuso: oh, just the wierdness with the changelog not being visible
[04:18] <kirkland> TheMuso: the error 500 problem, i meant
[04:18] <TheMuso> What do you mean not being visible?
[04:18] <TheMuso> oh right.
[04:18] <slangasek> ScottK: mmm, moderately around
[04:18] <TheMuso> kirkland: Whats with the empty commit?
[04:18] <ScottK> slangasek: bug 242554
[04:19] <kirkland> TheMuso: thought that might solve the 500 error
[04:19] <kirkland> TheMuso: I can uncommit that if necessary
[04:19] <ScottK> Just sent mail to the tech board, devel-discuss, etc.
[04:19] <TheMuso> kirkland: Right.
[04:19] <kirkland> TheMuso: not that I have extensive bzr experience, but i've never seen this sort of thing
[04:19] <TheMuso> kirkland: It may have something to do with that revision being a merge.
[04:19] <TheMuso> at a guess
[04:19] <ScottK> pocket copies aren't so great when the pockets have different versions of the build-depends.
[04:20] <slangasek> ScottK: ok; I'll see if I can't get python-central verified and copied over tonight
[04:20] <ScottK> slangasek: Thanks.
[04:24] <kirkland> TheMuso: okay, i just uncommitted the empty message
[04:25] <TheMuso> 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] <TheMuso> kirkland: in the changelog.
[04:26] <kirkland> TheMuso: right, okay
[04:27] <kirkland> TheMuso: committed/pushed
[04:28] <TheMuso> kirkland: Ok.
[04:28] <TheMuso> 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] <kirkland> TheMuso: sorry, i usually use "update-maintainer", which fixes the maintainer and adds a changelog entry
[04:29] <kirkland> TheMuso: the last one was a mess... i misunderstood his instructions, and did totally the wrong thing
[04:29] <TheMuso> kirkland: Thats fine, but in this case it would not work as the maintainer is already changed.
[04:29] <TheMuso> kirkland: Oh right.
[04:29] <kirkland> TheMuso: right
[04:29] <TheMuso> So its just as easy to put the entry in by hand.
[04:29] <TheMuso> dch -a
[04:29] <TheMuso> Type text
[04:29] <TheMuso> save, exit.
[04:31] <kirkland> TheMuso: I'll add that to my list of things to do differently between a deb/bzr merge
[04:31] <TheMuso> 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] <TheMuso> Regardless whether its a deb only, or involves a vcs branch of some sort.
[04:35] <kirkland> TheMuso: understood.
[04:36] <TheMuso> kirkland: I see what you mean, that original branch is quite big. :)
[04:36] <TheMuso> kirkland: Anyway, it looks fine to me, bar that entry in the changelog.
[04:36] <kirkland> TheMuso: pull revision 260
[04:37] <kirkland> TheMuso: I reverted the empty commit, and added the changelog entry you requested
[04:37] <TheMuso> kirkland: gotcha.
[04:37] <TheMuso> kirkland: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[04:37] <TheMuso> kirkland: I suggest you push --overwrite
[04:37] <TheMuso> since you reverted a commit that was pushed
[04:38] <kirkland> TheMuso: "No new revisions to push." ...  this was why I made an empty commit earlier
[04:38] <TheMuso> kirkland: hrm ok.
[04:38] <wgrant> TheMuso: YOu'll have to recheck it out.
[04:39] <wgrant> Or remove some revisions from your branch.
[04:39] <TheMuso> wgrant: Yeah thats my thought.
[04:39] <TheMuso> ok pulled the empty commit locally and now it pulls successfully.
[04:41] <TheMuso> kirkland: Ok that looks fine to me.
[04:41] <kirkland> TheMuso: cool, what's next?  you merge into main?
[04:41] <kirkland> the main branch i mean?
[04:42] <TheMuso> 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] <TheMuso> s/hardy/intrepid/
[04:42] <kirkland> 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] <TheMuso> 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] <kirkland> TheMuso: okay, so you pull my branch, fix the target release, and you'll push to the main branch?
[04:44] <TheMuso> kirkland: Yes.
[04:44] <kirkland> TheMuso: awesome, thanks for the lesson
[04:44] <TheMuso> kirkland: You're welcome.
[04:53] <kirkland> slangasek: superm1: laga: mythbuntu amd64 8.04.1 installed fine for me ;-)
[04:54] <superm1> great
[04:54] <superm1> thanks kirkland
[04:55] <superm1> just need to generate our live disks then and make sure those are still good too
[04:55] <kirkland> superm1: no prob
[04:55] <superm1> kirkland, hows the ppc build working?
[04:55] <superm1> does your ppc have altivec?
[04:56] <kirkland> superm1: the ppc frontend is working for the first time in months!
[04:56] <kirkland> superm1: how do i tell?  is it in /proc/cpuinfo?
[04:57] <superm1> should be i believe
[04:57] <superm1> what generation of PPC is it?
[04:57] <kirkland> superm1: mac mini, g4, i believe
[04:58] <superm1> oh yeah that'll have altivec
[04:58] <kirkland> superm1: i'm checking
[04:58] <superm1> its the earlier ones that didn't
[04:58] <superm1> w/o altivec, i believe video is practically unplayable on there
[04:59] <TheMuso> G3 == no altivec, G4-G5 == altivec.
[04:59] <superm1> there's the info i was looking for
[04:59] <TheMuso> 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] <kirkland> TheMuso: yeah, sadly i know
[05:01] <kirkland> superm1: yeah, it does have altivec
[05:02] <superm1> 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] <superm1> oh well
[05:03] <TheMuso> superm1: Obscene? What do you mean exactly?
[05:03] <kirkland> superm1: yeah, the form factor is just so attactive
[05:04] <superm1> TheMuso, well people are saying AMD64 5000+ minimum, and high end geforce 9xxx cards w/ hardware assistance
[05:04] <superm1> to be able to handle decoding
[05:04] <RAOF> That seems to be substantially above what I've read.
[05:05] <pwnguin> depends on the quality
[05:05] <kirkland> superm1: i have an amd64 3800 that renders HD just fine
[05:05] <superm1> HD-PVR files are x264 spit out
[05:05] <pwnguin> the super high res stuff i wouldnt doubt
[05:05] <superm1> that's reassuring to me to hear RAOF.  i've not kept up the last week or two
[05:05] <RAOF> 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] <pwnguin> RAOF: i wonder how much that falls with say a 6xxx
[05:06] <RAOF> 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] <RAOF> There just isn't any hardware assist there.
[05:06] <superm1> i'll look for some more accurate benchmarks as the hardware becomes  more prevalent
[05:06] <kirkland> do the new mini's have digital sound out?
[05:07] <TheMuso> kirkland: Yes.
[05:07] <TheMuso> Shared with headphone/line out.
[05:07] <RAOF> superm1: Also, these were Windows benchmarks; it's likely that you'll see close to no hardware assist on linux.
[05:07] <pwnguin> RAOF: my x2 4000+ with a 6600gt does okay, but drops frames / stutters
[05:07] <kirkland> TheMuso: 5.1 coax or optical?
[05:07] <TheMuso> kirkland: Optical.
[05:07] <TheMuso> Amd 5.1 afaik yes.
[05:07] <kirkland> TheMuso: nice!
[05:08] <pwnguin> RAOF: and that's just on 720 =(
[05:08] <TheMuso> kirkland: As I said, only if I don't need to have the tuner card in the frontend.
[05:08] <RAOF> superm1: Unless you'd like to hack on the gallium video decoder state tracker :)
[05:08] <TheMuso> I don't trust USB for anything but keyboard/mouse.
[05:08] <superm1> RAOF, oh! yeah linux requirements are much higher unfortunately
[05:09] <RAOF> 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] <TheMuso> I would also get a mini only if they were updated with better GPU chips, even a higher/more recent intel chip.
[05:13] <TheMuso> 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] <TheMuso> So I can test build.
[05:13] <kirkland> TheMuso: so that's another question i have for you...
[05:14] <kirkland> TheMuso: if this was deb merge, i would have debuild'ed ...
[05:14] <kirkland> TheMuso: what's the build process for this?
[05:14] <TheMuso> 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] <TheMuso> 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] <TheMuso> The exact command I'm using is 'bzr-buildpackage -S --native'
[05:16] <kirkland> TheMuso: ah, cool!  that's the part I was missing....
[05:25] <TheMuso> kirkland: Ok build environment set up, test building.
[05:33] <TheMuso> kirkland: Uploaded.
[05:34] <kirkland> TheMuso: cool, thanks for working me through this one
[05:35] <TheMuso> kirkland: np
[05:35] <kirkland> TheMuso: I'm calling it a night ;-)
[05:35] <TheMuso> kirkland: Good night then.
[06:20] <orbisvicis> why suddenly so many kernel updates ?
[06:21] <RAOF> orbisvicis: Because 8.04.1 is nearly done? :)
[06:22] <orbisvicis> oh. 8.0.4.1 ?
[06:25] <pwnguin> the "now its really stable" release ;)
[06:27] <bluefoxicy> ok, evolution just erased my calendar.
[06:27] <orbisvicis> heh thanks
[06:27] <bluefoxicy> good job
[06:30] <bluefoxicy> so will 8.0.4.1 have a feature in it to prevent anything from STEALING FOCUS ever?
[06:30] <RAOF> bluefoxicy: Evolution isn't capable of doing that to me; it's google-calendar support doesn't work well enough for me :)
[06:31] <bluefoxicy> 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] <orbisvicis> is there a roadmap ?
[06:31] <bluefoxicy> evolution then closed, said it couldn't access my "memo" until it restarted, and then came up with a blank calendar.
[06:31] <bluefoxicy> blank as in tasks from 3 days ago were gone even.
[06:32] <RAOF> bluefoxicy: That sucks a lot.
[06:32] <bluefoxicy> you're telling me?
[06:32] <bluefoxicy> I've had numerous incidents where some application locks up my mouse and keyboard and I can't do anything in X
[06:37] <bluefoxicy> win!
[06:37] <bluefoxicy> I added one new appointment and it ressurected all lost data by magic.
[06:37] <RAOF> Huzzah!
[06:37] <bluefoxicy> I have no way to reproduce this or describe the original bug, or provide explanation for WHY it happened
[06:40] <RAOF> 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] <Amaranth> RAOF: I thought it switched it _out_ of raw mode
[06:42] <Amaranth> bluefoxicy: Do you use compiz? If so, did it happen during a focus change?
[06:42] <bluefoxicy> no compiz
[06:44] <RAOF> 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] <bluefoxicy> I can vt switch
[06:45] <bluefoxicy> and when I switch back to X i'm stuck again
[06:45] <Amaranth> eep, my sysrq is a prtsc
[06:46] <bluefoxicy> 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] <bluefoxicy> for the misfortunate soul who kills qemu when it freezes, you have to run 'DISPLAY=0 qemu <something>' in a real terminal to start a new one to get your mouse back <_<
[06:47] <bluefoxicy> imagine losing it to something that doesn't normally grab, and thus won't be nice and reset control for you
[06:50] <Amaranth> X grabs are broken
[06:51] <pitti> Good morning
[06:51] <bluefoxicy> Amaranth:  is there a program I can run to tell X to reclaim?
[06:51] <Amaranth> bluefoxicy: I don't think so
[06:51] <Amaranth> Otherwise they wouldn't be quite as broken :P
[06:52] <bluefoxicy> 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] <bluefoxicy> 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] <DasKreecH> Hallo
[07:05] <DasKreecH> Is there a public list of Canonical Paid Devs?
[07:05] <dholbach> good morning
[07:05] <DasKreecH> morning
[07:06] <slangasek> Canonical employment records are not public information, no
[07:06] <DasKreecH> ok
[07:07] <DasKreecH> Is there a number?
[07:07] <DasKreecH> We employ 28 People?
[07:08] <slangasek> Canonical employs more people than that, but I'm not aware of any public head count, either
[07:08] <DasKreecH> It's not a public company is it?
[07:08] <slangasek> nope
[07:09] <DasKreecH> Would have been fun to own a bit of history ^_^
[07:11] <pwnguin> there are some LP teams that might suggest some status of employment
[07:12] <pwnguin> but there's likely a few other groups that dont need LP etc.
[07:12] <Amaranth> pwnguin: Not really
[07:13] <pwnguin> webmasters? sysadmins? lawyers?
[07:14] <slangasek> 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] <pwnguin> there's also canonical-qa
[07:14] <pwnguin> 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] <DasKreecH> pwnguin: Or  how many people you would have to attempt at doing so
[07:16] <pwnguin> heh
[07:17] <wgrant> slangasek: Can you please look at bug #206912 and convince Soyuz that vlc really should be in multiverse?
[07:17] <wgrant> It didn't go anywhere.
[07:17] <wgrant> Much like nagios2.
[07:18] <wgrant> Ah.
[07:18] <wgrant> It did get demoted.
[07:18] <wgrant> But then bounced.
[07:18] <slangasek> "bounced"?
[07:19] <wgrant> Yes.
[07:19] <wgrant> The next upload decided to go into universe.
[07:19] <wgrant> (some 12 hours after it was demoted)
[07:19] <DasKreecH> repos are considered demotions? :)
[07:19] <wgrant> Huh.
[07:19] <slangasek> DasKreecH: well, being relegated to the archive for non-free software is definitely considered a demotion...
[07:19] <RAOF> Universe->Multiverse is considered a demotion, yes.
[07:19] <wgrant> Only the source changed.
[07:19] <pwnguin> well multiverse is ;)
[07:20] <wgrant> The binaries are still multiverse.
[07:20] <persia> DasKreecH: There's a concept of mutiverse -> universe -> main being "promotion", and the reverse "demotion".
[07:20] <slangasek> wgrant: yeah, source and hppa... nice :)
[07:20] <wgrant> This is interesting:
[07:20] <wgrant> 2008-04-15 01:02:03 INFO Override Component to: 'multiverse'
[07:20] <wgrant> 2008-04-15 01:02:03 INFO 'vlc - 0.8.6.release.e+x264svn20071224+faad2.6.1-0ubuntu2/multiverse/graphics' source overridden
[07:20] <wgrant> The source looks like it was multiverse initially.
[07:20] <wgrant> So it got overriden to the same place, and then forgot about it 12 hours later.
[07:21] <slangasek> 2008-06-24 06:21:02 WARNING 'vlc' has no binaries published in intrepid

[07:21] <wgrant> I did just upload a new one which depwaited.
[07:21] <slangasek> is 0.8.6.release.e+zdebian-2.3ubuntu1 yours?
[07:21] <wgrant> That's why I noticed that the source was in universe.
[07:21] <wgrant> It is.
[07:21] <slangasek> ok
[07:22] <slangasek> well, I think the source override has been fixed now, which should unstick the dep-wait (?)
[07:22] <wgrant> Thanks.
[07:22] <wgrant> I'll throw it back now.
[07:22] <wgrant> Hopefully it will work.
[07:23] <wgrant> I suppose this deserves a Soyuz bug.
[07:23] <wgrant> I wonder if the binaries will go into the right place now (particularly hppa).
[07:23] <slangasek> they might have to be kicked again once they're up-to-date, given the above warning
[07:23] <slangasek> I don't think the "source+binaries" override took effect on the binaries because soyuz couldn't see that they were related, I guess
[07:24] <wgrant> Right.
[07:24] <wgrant> Hmmm.
[07:24] <wgrant> The hppa binaries that existed when you overrode it all last time are odd.
[07:24] <wgrant> There are only two of them.
[07:24] <wgrant> When they should be a dozen or so.
[07:24] <slangasek> I see the full set here
[07:25] <wgrant> Oh.
[07:26] <wgrant> Right, those are only the arch: all ones (the names confused me), as hppa failed.
[07:26] <wgrant> Shall I file a bug about the source promoting itself?
[07:28] <slangasek> by all means; I don't have a clue how to track that bug down, but it certainly appears to be a bug
[07:29] <wgrant> Right, will do.
[07:40] <wgrant> slangasek: Thanks. It's building fine now, and I've filed the bug.
[07:47] <dholbach> hi mvo
[07:49] <wgrant> Urgh, of course it all failed to upload. Forgot about that bug.
[07:58] <mvo> hi dholbach
[08:15] <slangasek> bryce: I wonder if you might be familiar with a bug which, when closing the lid on a laptop with a monitor hooked up to the VGA port of the 945GM, causes the machine to hard-lock... :)
[08:16] <bryce> slangasek: ah you mean the pipe-a quirk bug?
[08:17] <bryce> one sec
[08:17] <slangasek> heh
[08:17] <slangasek> so is that what that pipe-a quirk thing is about
[08:17] <bryce> yep
[08:17] <bryce> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/138256
[08:18] <pwnguin> heh, i saw that on LP and wondered what on earth it meant :)
[08:19] <slangasek> bryce: ok; so I should test out the option, and if it fixes the problem for me, file a new bug with all my details for quirking?
[08:23] <bryce> slangasek: yepamundo
[08:52] <dholbach> thekorn: woah! activity log reading in pylpbugs! :)
[08:53] <thekorn> dholbach, worked for ages, but was not documented ;)
[08:53] <dholbach> thekorn: I didn't know! :)
[08:54]  * wgrant notes that it might be more useful if the activity log itself was actually a proper log of the activity.
[08:56] <thekorn> wgrant, I agree, it is unfortunate that not all events are listed there
[08:58] <wgrant> thekorn: I suppose we'll see some happenings there post-2.0... for the moment one has to check archives on ubuntu-bugs@l.u.c if one wants to work out what happened to a bug.
[09:06] <szonek> how can i get SHARE tab in properties of folder (nautilus) i know it's in ubuntu.. i wan't to get have this on Gentoo..
[09:06] <szonek> i know it's not support channel but can't find this package
[09:06] <wgrant> szonek: By talking to the Gentoo people, I would presume.
[09:07] <szonek> wgrant: right, but i'm looking for a package/project(or something) name and that's universal i think..
[09:08] <wgrant> szonek: You might be looking for nautilus-share.
[09:11] <szonek> wgrant: okay, thanks
[11:06] <sebner> seb128: are you uploading ipe or waiting? Because at least the colormap change was refused several times by the debian maintainer
[11:28] <wgrant> Hmm, I see that nagios2 was promoted to main and then removed fairly soon after - should nagios3 be promoted in its place?
[11:35] <seb128> sebner: I just commented on some of the bugs, I didn't mean to upload those
[11:36] <seb128> sebner: any reason why we need this change if debian refuses it? I'm just trying to reduce the useless deltas
[11:57] <jdstrand> cjwatson, kirkland: fyi, I reverted the patch for bug #64064 , and adjusted the bug accordingly. Please add additional comments as necessary.
[11:58] <jdstrand> cjwatson: hi btw! :)
[12:01] <sebner> seb128: ah ok, because you uploaded lasso (maintainer already responed =)). To behonest I have no idea why the maintainer refuses it. Some time ago we sent an ubuntu patch for icon,desktop file and this colormap and in the changelog he mentioned: "   * debian/rules: Install desktop file and icon.  Note that I'm not applying the stylesheet part of the patch.
[12:16] <CR17> lu
[12:17] <siretart> sebner: is there a corresponding bug about that in the debian bts?
[12:18] <sebner> siretart: debian ##451022
[12:19] <sebner> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451022
[12:20] <mvo> is someone looking at powernowd?
[12:20] <mvo> (the merge)
[12:20] <siretart> intersteing
[12:20] <mvo> if not, I will take it
[12:21] <sebner> siretart: yep ^^, you may want to upload my merge then or anything else todo?
[12:34] <james_w> seb128, asac: any opinion on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460691
[12:36] <ogra_cmpc> james_w, not sure we care in intrepid with NM7
[12:37] <asac> james_w: we have worked around that bug
[12:38] <asac> james_w: err, cant really identify how the upload fixes it (at least from changelog)
[12:39] <ogra_cmpc> well, he talks about the etch version of NM
[12:39] <ogra_cmpc> thast years old
[12:40] <ogra_cmpc> asac, you culd just ask lool who made that upload ;)
[12:40] <asac> ogra_cmpc: the upload closing that bug happened in may
[12:40] <asac> ogra_cmpc: i didnt ask about that bug ;)
[12:46] <doko> heh, somebody must have an alarm set for sync requests ;)
[12:56] <cjwatson> doko: just reloading the page after doing the last lot ;-)
[13:02] <cjwatson> soren: vgabios looks syncable?
[13:05] <soren> cjwatson: Let me check..
[13:06] <soren> cjwatson: Yup, looks like it.
[13:09] <soren> Oh..
[13:09]  * soren just realises he never finished the iptables merge
[13:09] <soren> How odd.
[13:09] <cjwatson> vgabios done
[13:10] <soren> cjwatson: Thanks very much.
[13:10] <emgent> morning
[13:14] <seb128> james_w: the split should be no issue for ubuntu, we were speaking about deprecating network-admin if network-manager 0.7 does every required anyway
[13:42] <dholbach> bryce, soren: Laney could confirm the "mouse-cursor-only-moving-in-the-top-left-corner" problem in intrepid
[13:45] <james_w> seb128: hi, so I should not take that change from Debian?
[13:48] <soren> dholbach: Mkay.
[13:49]  * Laney nods
[13:53]  * ogra wonders if pitti and Q-Funk shouldnt better talk by IRC that geode bug explodes :)
[13:54] <pitti> ogra: we do, on jabber
[13:54] <pitti> but I think it's sorted out now
[13:54] <ogra> heh
[13:54] <ogra> yay
[13:54] <ogra> that'd be cool
[13:54] <ogra> we have so many unhappy ltsp users
[13:54] <pitti> just waiting for slangasek's sru freeze exception yay or nay now
[13:54] <seb128> james_w: either way, that doesn't make a big difference
[13:55] <seb128> james_w: the split doesn't create an issue, we just need to install the new package if we want it
[13:55] <seb128> james_w: I would take the change for ubuntu
[13:55] <james_w> seb128: ok, thanks.
[14:16] <seb128> zul: hi
[14:16] <zul> seb128: hi there
[14:16] <seb128> zul: you did this socks4-server upload right?
[14:16] <zul> seb128: yep
[14:16] <seb128> zul: did you consider bug #241012 before uploading?
[14:17] <zul> seb128: no I didnt
[14:17] <seb128> zul: the bug states it could have been synced because the shlibs already adds the depends
[14:17] <zul> seb128: sorry about that
[14:17] <seb128> zul: would be a good idea to look at open bugs before uploading something ;-)
[14:17] <seb128> zul: no problem, could you comment on the bug and close it now?
[14:17] <zul> sure..
[14:17] <seb128> maybe verify if the package can really be synced next time
[14:18] <seb128> thanks!
[14:53] <dholbach> bryce: just drop our patch on xserver-xorg-input-vmmouse (a similar fix was applied upstream already)
[14:53] <dholbach> soren, Laney: ^
[15:03] <soren> dholbach: Oh, cool.
[15:05] <dholbach> Laney: so building just the debian version of it and using that should make it work again
[15:07] <jcastro> slangasek or pitti: wrt. SRU discussion at UDS, at the time it was pending approval by the TB or something, has that been resolved?
[15:10] <pitti> jcastro: hm, which discussion in particular?
[15:10] <jcastro> pitti: the one we had with murray, the glom maintainer
[15:10] <jcastro> basically, the new policy meets all his needs but it hadn't gone official yet
[15:10] <pitti> AFAIK, the current wiki page is fully TB-ack'ed
[15:11] <jcastro> ok
[15:11] <pitti> admittedly we have been pretty liberal in the interpretation of "non-critical fixes which do not have the potential to ruin your system" for hardy so far
[15:11] <pitti> jcastro: since we had so many people to throw at hardy SRUs
[15:11]  * jcastro nods
[15:16] <Laney> dholbach: That seems to work well, nice one!
[15:16] <dholbach> ROCK
[15:18] <ogra> pitti, are you playing the NEW queue jockey today ? i just split ldm into binary and theme package, the theme package will need NEWing (once built) and main promotion
[15:19] <pitti> ogra: not normally, only when being asked nicely :) (my archive day is Friday)
[15:19] <ogra> ah, k
[15:19] <pitti> sounds easy, though
[15:19] <pitti> is it already in NEW?
[15:20] <ogra> just uploaded i only wanted to check my opportunities ;)
[15:20] <ogra> its binary NEW ... source is still ldm
[15:21] <ogra> but ldm depends on it and i want to avoid uninstallability
[15:31] <cocoa117> hello, any idea how to contact ubuntu backports developer in IRC?
[15:31] <cocoa117> to asking questions about the issue
[15:33] <jdstrand> pitti: hi!
[15:33] <pitti> hey jdstrand
[15:35] <jdstrand> pitti: pam-pgsql needs to be sync'd from debian in intrepid. however, the base version is 0.6.3, but the orig.tar.gz is different in intrepid and debian. is the proper procedure to update the orig.tar.gz then use a build1?
[15:36] <jdstrand> pitti: well, just rebuild the source pacakge using build1, use -sa and upload
[15:38] <wgrant> jdstrand: You want to grab the Debian source package, extract that, replace the Debian upstream tarball with the Ubuntu one, create a build1 fakesync changelog entry, and build the new source package.
[15:39] <wgrant> Do not use -sa.
[15:39] <pitti> jdstrand: exactly
[15:40] <jdstrand> asac: ok cool
[15:40] <pitti> jdstrand: right, -sa won't help; you can't overwrite the one in the archive
[15:40] <pitti> jdstrand: I usually unpack the Ubuntu orig.tar.gz, apply the debian diff.gz (zcat ../diff.gz | patch -p1), debuild
[15:40] <pitti> jdstrand: but wgrant's approach works as well
[15:40] <asac> jdstrand: huh?
[15:41] <pitti> jdstrand: oh, before debuild, of course dch with a build1 changelog
[15:41] <jdstrand> asac: sorry
[15:41] <asac> k
[15:41] <jdstrand> s/asac/pitti and wgrant/
[15:41] <jdstrand> Koon: ^
[15:41] <asac> yep
[15:41] <jdstrand> pitti: right
[15:42] <Koon> jdstrand: we'd do that even if the Ubuntu 0.6.3 orig.tar.gz is badly done ?
[15:42] <cjwatson> Koon: Launchpad (rightly) won't let you overwrite it with the same file name, no matter what
[15:42] <Koon> (includes a whole debian/ dir)
[15:42] <pitti> Koon: unfortunately we have some broken stuff like that, yeah
[15:43] <pitti> weird, I had that two or three times when doing merges
[15:43] <cjwatson> there are some edge cases where you might want to change the upstream version number (0.6.3fixed or something), but bear in mind that that will mean you won't get the benefit of merge-o-matic any more
[15:43] <cjwatson> so that should be reserved for when you have no other choice
[15:43] <pitti> jdstrand: in this case, wgrant's approach is definitively more robust
[15:43]  * wgrant had to do that this evening.
[15:43] <Koon> cjwatson/pitti: ok, thx
[15:43] <wgrant> (rename the upstream tarball)
[15:57]  * ogra scratches head about LPs interpretation of long changeogs like https://launchpad.net/ubuntu/intrepid/+source/ldm/2:2.0.6-1ubuntu1
[15:57] <ogra> seems it wipes all contributor names and just attaches my name at the bottom ?
[15:58] <ogra> that seems wrong
[15:59] <cjwatson> ogra: is that bug 55795?
[16:00] <ogra> yeah, looks like it, thanks
[16:00] <ogra> i was just about to file a duplicate :)
[16:01] <ogra> wow, thats old
[16:08] <Keybuk> bryce: can't update -intel due to conflict on -i810 (dep of -all)
[16:09] <ogra> sholdnt that be a recommends ?
[16:16] <ogra> nice, only 68 merges left
[16:16] <ogra> (main)
[16:25] <cjwatson> we're getting there ..
[16:25] <cjwatson> ArneGoet1e: are you already part-way through your fontconfig merge?
[16:26]  * ogra wonders if tedg will do rss-glx (its tagged with slangasek's name though)
[16:28] <ArneGoet1e> cjwatson: let's say I have it on my plate right now
[16:28] <Keybuk> hmm
[16:28] <Keybuk> quite annoying
[16:28] <Keybuk> after an upgrade, my laptop panel no longer works
[16:28] <cjwatson> ArneGoet1e: ok, cool
[16:32] <SEJeff> How are seperate distributions created? In porting oVirt (http://ovirt.org) to Ubuntu we need a livecd-creator ish command for Ubuntu
[16:33] <cjwatson> the livecd-rootfs package in Ubuntu is what we use to build our live filesystems
[16:33] <cjwatson> though of course you need to wrap an ISO round it too
[16:33] <SEJeff> Sure
[16:34] <cjwatson> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ (and the stuff in configs/devel having checked that out) is our CD creation software
[16:35] <SEJeff> cjwatson, Is that packaged?
[16:35] <SEJeff> Because I'm porting scripts over to create oVirt appliances so they can run on Ubuntu. Having them apt-get a package would be nice
[16:38] <cjwatson> SEJeff: no, I'm afraid it isn't
[16:38] <cjwatson> 'bzr get' it for the meanteim
[16:38] <cjwatson> meantime
[16:39] <cjwatson> it's not really in packageable form at the moment (hardcoded paths) and the obvious ways to fix that would make other things awkward, so it's not made it very high up the to-do list ...
[16:39] <siretart> one might want to give 'live-helper' a shot. I was told it at least used to produce working live cds.
[16:40] <cjwatson> ArneGoetje: (m17n-db is also on your list)
[16:40] <ArneGoetje> cjwatson: yep
[16:40] <cjwatson> siretart: I'd just like to completely disclaim any interest in supporting people building Ubuntu CDs with live-helper; they can sort themselves out
[16:41] <cjwatson> (simply because I haven't looked at it, I expect it's missing lots of little bits and pieces that will cause subtle issues simply because it's not actively used by Ubuntu)
[16:42] <doko> seb128: how familiar are you with scrollkeeper? The unmodified package from hardy ftbfs in intrepid
[16:42] <siretart> cjwatson: right, ok
[16:42] <Koon> pitti: for a fake sync do you keep the combined changelog ? the Ubuntu Original-Maintainer ?
[16:42] <seb128> doko: not so much, what is the issue?
[16:43] <seb128> doko: let me try
[16:47] <seb128> doko: weird, no idea about this one
[16:48] <MacSlow> dholbach, so from https://bugs.edge.launchpad.net/ubuntu/+source/planner/+bug/219109 I take that debian suggests to have gda/database-support enabled again?!
[16:48] <doko> seb128: yeah, will look at it tomorrow again
[16:48] <dholbach> MacSlow: yes, the trouble is that it does not build right now in the pure debian form
[16:49] <MacSlow> dholbach, there's a fix in in place (in Ubuntu now) due to the merge that makes it compile
[16:49] <dholbach> MacSlow: nice
[16:49] <MacSlow> dholbach, the cdbs-based patch for that is tiny
[16:50] <MacSlow> it belongs upstream so I'll send it right there instead of debian?!
[16:50] <dholbach> best to both
[16:50] <MacSlow> so soon we should be able to just drop it and debian will add --enable-database=yes to their debian/rules again too
[16:50] <MacSlow> dholbach, ok then
[16:50] <dholbach> ROCK
[16:52] <Daviey> ON
[16:53]  * dholbach hugs Daviey
[16:53] <Daviey> :)
[16:54] <bliZZardz> got a quick Q on python : is it possible to encrypt the py files(modules) and load them dynamically(and hence decrypt at run time)
[16:55] <bliZZardz> (am not sure about the relevance of the Q with the forum, but would be interested to know as there are many devs around)
[16:55] <ion_> The topic’s got a quick A.
[16:57] <cjwatson> Koon: I wouldn't bother keeping the combined changelog, and keeping Original-Maintainer isn't necessary (dpkg-source only enforces it if the changelog contains 'ubuntu')
[16:58] <Koon> cjwatson: yes, and pitti did it this way with an openvpm fakesync.
[16:58] <Koon> cjwatson: thx for the advice.
[16:58] <cjwatson> no problem
[17:27] <kirkland> pitti: ping
[17:34] <jdstrand> kirkland: pitti left a little while ago
[17:34] <kirkland> jdstrand: ah, okay, thanks.  i'll catch him later.
[17:35] <kees> slangasek: heads-up, we need to get bug 219914 fixed before 8.04.1 goes out
[17:35] <ogra> gone dancing :)
[17:35] <kirkland> pitti is a regular Patrick Swayze :-)
[17:37] <ogra> haha
[17:42] <tedg> Okay, so why doesn't apt know the number of files it's going to get on an update?  Why can't it cache that value?
[17:51] <seb128> tedg: does it matter?
[17:52] <seb128> tedg: what do you call files? the packages content? or the number of updates to download?
[17:53] <tedg> I don't know, I'm guessing they're indexes.  I know when I click update manager it starts with "1 to 55" and changes to "154 of 154" when complete.
[17:54] <seb128> ah, right, that's a well known issue
[17:54] <seb128> dunno why it's hard to get the correct count
[17:54] <seb128> but I've been bugging mvo about it almost every cycles ;-)
[17:54] <tedg> Heh, good.
[17:54] <tedg> :)
[17:54] <mvo> *cough*
[17:55] <mvo> seb128: that reminds me, have you seen anything like: bug #240806 yet? it seems to make gconf crash and that in turn makes update-manager crash :/
[17:57] <seb128> mvo: no, that seems to be local corruption or something
[17:58]  * mvo nods
[18:51] <slangasek> kees: mm, tagging 219914 for .1; who's taking responsibility for the update?
[18:51] <kees> slangasek: I'm volunteering zul or mathiaz for the moment, but I can do it later today if they don't have time.
[18:52] <kees> slangasek: when is freeze again?
[18:52] <slangasek> kees: in the past?
[18:52] <slangasek> i.e., anything you ask me for is an exception here
[18:52] <kees> slangasek: that's what I feared.  :P
[18:52] <kees> slangasek: we'll get something cranked out before EOD.
[18:53] <kees> slangasek: the reason it's important to get in is that it's really only triggered by dapper->hardy upgrades, and there isn't a good way to automatically fix the problem afterwards.
[18:53] <kees> anyway, I'm out for a few errands, back in a bit.
[18:54] <slangasek> kees: right, understood, that's why I'm marking it for .1 without further quizzing ;)
[18:56] <bryce> Keybuk: I've got a change pending for xorg that I think will fix those -all settings.
[19:03] <cjwatson> siretart: can you confirm your ack on bug 242711?
[19:03] <cjwatson> the activity log doesn't currently allow me to verify emgent's comment
[19:04] <slangasek> kees: gar why is that bug marked as a security vuln
[19:09] <mathiaz> slangasek: is there any alpha1 iso required to do iso testing ?
[19:09] <mathiaz> zul: are you working on bug 219914 ?
[19:09] <slangasek> mathiaz: I'm going to be sorting through the alpha1 ISO status today, so I don't know the answer to that yet
[19:10] <mathiaz> slangasek: ok - I'm writing up the server minutes, and I mentionned there that we're doing iso testing for alpha1
[19:10] <slangasek> mathiaz: last I saw there were some uninstallability problems in general yet, which may not affect -server but in any case need to be resolved before we go for widespread ISO testing for alpha1
[19:11] <mathiaz> slangasek: ok - so there is no point in asking for alpha1 testing now ?
[19:11] <mathiaz> slangasek: better focus on 8.04.1 testing ?
[19:11] <slangasek> there are no candidate ISOs posted currently...
[19:11] <slangasek> aside from the alternate CDs, but I don't know who posted those or how usable they actually are
[19:11] <slangasek> 8.04.1 testing is a good focus for today; tomorrow would be good for focusing on alpha1, if everything goes well :)
[19:13] <cjwatson> I've been working on alpha-1 installability; we're mostly there, but there are one or two open issues
[19:13] <cjwatson> I wouldn't object to testing so that we don't have to serialise it all
[19:13] <slangasek> ok
[19:14] <cjwatson> xserver-xorg-video-all being uninstallable ain't gonna help
[19:14]  * slangasek nods
[19:14] <cjwatson> but I think that's a trivial archive issue and I'll fix it now
[19:14] <ogra> Mithrandir, do you plan to do the matchbox merge ? (seems easy and small, i could quickly do it)
[19:14] <cjwatson> oh yes, waiting on NEW
[19:15] <cjwatson> ogra: hmm, I looked at it briefly and it looked enormous, but maybe I misread
[19:15] <ogra> cjwatson, well, tollefs changes got cleanly carried over, all that changed in debian is the dep on xsettings ... the merge is actually only to clean up control and add a changelog entry
[19:16] <cjwatson> ah
[19:16] <cjwatson> right, accepted xserver-xorg-video-intel, so I think that should leave us with no uninstallables that cause ISO problems
[19:16] <ogra> i can cleanly unapply the 1.2-1ubuntu1 patch apart from these two files :)
[19:17] <ogra> but i dont want to just grab it in case tollef wanted to do it
[19:17] <cjwatson> desktop CDs are, I think, unlikely to be ready for alpha-1
[19:17] <cjwatson> ogra: at this point, I suggest just doing it
[19:17] <ogra> oki
[19:17]  * ogra does
[19:17] <cjwatson> the mobile team can clean it up afterwards if they want/need to
[19:18] <cjwatson> I think Tollef was doing that in his capacity as mobile tech lead rather than out of personal interest
[19:19] <ogra> yeah, thought so
[19:20] <slangasek> cjwatson: what are the problems with the desktop CDs right now (so we make sure we're on track to resolve those for alpha2)?
[19:21] <cjwatson> slangasek: ubiquity, ubiquity, and ubiquity
[19:21] <slangasek> ok :)
[19:21] <cjwatson> slangasek: evand is working on updating it for the major state machine rework in localechooser, but isn't done yet
[19:21]  * slangasek nods
[19:21] <cjwatson> slangasek: that's the only major problem I'm aware of so far, though it's not impossible that there are others
[19:22] <pitti> kirkland: pong
[19:23] <kirkland> pitti: hiya...  you had a bit of feedback on mount.ecryptfs_private.c, asking me to use fputs() rather than fprintf()
[19:23] <kirkland> pitti: i think you had suggested fputs() such that I would have to append '\n
[19:23] <kirkland> pitti: which is somehow troublesome for i18n
[19:24] <kirkland> pitti: but in my testing, fputs() doesn't not append a newline character, (though puts() does, strangely)
[19:24] <pitti> kirkland: right, I mixed that up, sorry
[19:24] <pitti> kirkland: but another reason is that fputs() runs much less code than fprintf(), thus it's faster and less prone to injection of % macros
[19:24] <kirkland> pitti: okay, so i left the fputs(), but I did have to append the '\n', for readability
[19:25] <kirkland> pitti: fair enough, i left the fputs()
[19:28] <mathiaz> kees: re bug 219914 - I agree with you - the best option is to not enable any caching by default
[19:29] <mathiaz> kees: I don't think we should fix the upgrade code - the mod_disk_cache module still has to be enabled (as mentionned in the debian bug)
[19:30] <mathiaz> kees: we should remove the CacheEnable directive in disk_cache.conf and mem_cache.conf
[19:44]  * slangasek solicits a second opinion on bug #99489
[19:51] <SEJeff> slangasek, Maybe a avahi-autoipd should have a special case?
[19:51] <SEJeff> To not add a route when no other ones exist?
[19:51] <ScottK> slangasek: I don't suppose just nuking avahi is an option?
[19:51] <SEJeff> That doesn't help a mobile user, but would fix one case
[19:51] <slangasek> SEJeff: the route in question is added *only* when there are no other routes on the interface
[19:51] <ScottK> Personally I don't consider my computer hunting around for other computers to talk to a feature.
[19:51] <slangasek> so I agree, it should not add a route when no other ones exist :)
[19:52] <ScottK> slangasek: I agree.
[19:52] <slangasek> "just nuking avahi" - that's not a very satisfying solution, given that it's a recommends of ubuntu-desktop
[19:53] <slangasek> and I am in favor of the ad-hoc functionality in general, just not this particular feature
[19:53] <slangasek> ScottK: agree enough that, as core-dev, you think we should deviate from upstream's (Trent's) opinion here?
[19:55] <ScottK> I guess I don't see the point of adding an infinite route when there is no one to talk to.
[19:55] <ScottK> If it's interfering with other packages, I think it should go.
[19:55] <slangasek> the point is that it means you can magically reach any host on the local segment, regardless of its IP address
[19:56] <slangasek> but not without its down-side
[19:56] <ScottK> Right.
[19:56] <SEJeff> magic is bad
[19:56] <ScottK> Since almost everything these days seems to have link-local, I think it's OK.
[19:56] <slangasek> well, I have older Linux hosts that don't
[19:56] <ScottK> How old?
[19:57] <ScottK> The one Windows 2000 box we still have will do it.
[19:57] <slangasek> 3- to 4-year-old installs; server installs without avahi
[19:57] <slangasek> yes, Windows has actually been doing link-local for yonks
[20:02] <ScottK> I don't think it's unreasonable to assume that anyone not doing link-local doesn't really care to talk that way.
[20:03] <slangasek> well, that doesn't help sorting out this bug
[20:03] <slangasek> note that it's only the hosts that *do* have link-local turned on that are reachable by this method
[20:03] <slangasek> since hosts without link-local addresses will return their packets via their default route, not to the host that sent them
[20:04] <slangasek> hrm - except, the host that Patty was IRCing from doesn't have avahi, so now I'm confused :)
[20:53] <[Relic]> Hello :)
[21:08] <[Relic]> Anyone know if they will add the coretemp.c from the 2.6.25 kernel to the 2.6.24 one ubuntu uses in the very near future (next kernel update) so we 45nm users can watch our coretemp and use very heavy load programs w/o worrying about burning out our cpus?
[21:18] <joaopinto> [Relic], have you checked for bug reports about it ?
[21:57] <kees> run avahi config defaults past lennart -- he's the one that originally specified them.
[21:57] <mathiaz> kees: what's the reason to not enable cache on / ?
[21:58] <kees> mathiaz: because it saves all kind of things like cookies, etc without additional tweaks, AIUI.  elmo might be able to speak more to this
[21:58] <elmo> mathiaz: wtf - seriously?
[21:58] <mathiaz> kees: one of the debian maintainer commented on bug 219914 and suggested another approach
[21:58] <mathiaz> kees: https://bugs.launchpad.net/debian/+source/apache2/+bug/219914/comments/8
[21:59] <elmo> mathiaz: a2enmod cache should not start caching all my sites
[21:59] <elmo> mathiaz: the fact that it does so currently is insane
[21:59] <elmo> mathiaz: apache has a very powerful vhost-based config system for a reason
[22:00] <elmo> mathiaz: (have you got a single counter-example of 'a2enmod' that globally changes behaviour?)
[22:02] <elmo> (and FTR, Debian #407171 doesn't require CacheEnable /, it simply requires that the module be available
[22:02] <elmo> )
[22:02] <mathiaz> elmo: right - I still think that we should *not* enable the cache by default
[22:02] <mathiaz> elmo: just trying to figure out why it's so bad
[22:03] <mathiaz> elmo: most of the modules enable things globally - such as negociation, etc...
[22:03] <mathiaz> elmo: but this highly depends on the type of modules
[22:04] <elmo> hmm, ok true
[22:04] <mathiaz> OTOH the proxy.conf disables proxy requests by default
[22:05] <elmo> right, for similar reasons
[22:05] <mathiaz> for security reasons IIUC
[22:05] <elmo> the reason it's so bad to enable caching is because it has security implications
[22:05] <YokoZar> Why is http://cdimage.ubuntu.com/daily/current/ empty with broken links but http://cdimage.ubuntu.com/daily/20080624/ has isos for download?
[22:05] <mathiaz> elmo: right - that would is the main point then - disk_cache should treated as mod_proxy because of the security implications
[22:13] <mathiaz> kees: what do you think about the debdiff: http://people.ubuntu.com/~mathiaz/apache2_2.2.9-2ubuntu1.debdiff ?
[22:15] <kees> mathiaz: I like it.  Good changelog.  :)
[22:15] <mathiaz> kees: ok - I'll upload a new version of apache2 in intrepid
[22:16] <kees> mathiaz: okay, great.  From there, SRU for slangasek?
[22:16] <mathiaz> kees: yop
[22:16]  * kees hugs mathiaz
[22:17] <elmo> FWIW, in intreprid, it'd might be nice to do what sf suggested
[22:17] <elmo> simply because enabling (in the mods-enabled/ symlink sense) disk cache means htcacheclean gets run
[22:18] <elmo> which is surprising for folks who used proxy but not disk cache (the majority of folks coming from dapper where mod cache was essentially useless)
[22:18] <elmo> but maybe sf will do that in Debian and so it's moot
[22:21] <norsetto> kees: do you know why debian bug 374568 has been marked as won't fix?
[22:24] <kees> norsetto: openssl isn't compatible with GPL.  code needs exceptions, and eggdrop author doesn't want it.
[22:24] <kees> norsetto: if it could get ported to gnutls we'd be golden.
[22:25] <kees> norsetto: I haven't had time to do that, so I just compile it myself every release.  one of these days I'll get fed up with it.  ;)
[22:25] <norsetto> kees: yes, I was wondering about that :-)
[22:27] <norsetto> kees: I guess having two flavours of eggdrop doesn't make any sense then (one with and one without ssl support)
[22:27] <slangasek> kees: how do I reach lennart to run this by him?  Another member of upstream is tracking that bug, but I don't see that Lennart subscribes to the ubuntu bugmail
[22:28] <pitti> slangasek: mezcalero in #avahi
[22:28] <slangasek> ok
[22:29] <slangasek> when's a good time to catch him?
[22:29] <pitti> slangasek: he just seems to do some commits, so I think he might still be awake
[22:29] <slangasek> hmm, I'm on my way out the door in just a minute, though :)
[22:29] <slangasek> I'll try tomorrow
[22:44] <emgent> cjwatson: i think that Reinhard confused bug to ACK, see Bug #242550
[22:46] <cjwatson> emgent: look, I'm sorry, but some MOTU needs to put an ack in the actual sync bug itself or else we have to review it ourselves and personally I don't have time
[22:46] <cjwatson> siretart: would help if you used full sentences rather than "ack" :-)
[22:46] <emgent> sure np :)
[22:47] <cjwatson> emgent: I'm more than happy for us to process properly-formed bugs, but the thing is that dealing with ones that aren't properly-formed takes time away from the others and I don't think that's fair
[22:49] <mathiaz> kees: here is a debdiff for hardy-proposed - http://people.ubuntu.com/~mathiaz/apache2_2.2.8-1ubuntu0.3.debdiff
[22:49] <mathiaz> kees: this one includes sf suggestion to not enable disk_cache on upgrade if it's not used in the configuration
[22:50] <mathiaz> kees: as suggested by elmo, even if we disable / caching by default, htcacheclean would still be started every time
[22:51] <mathiaz> kees: I'm not sure if it's acceptable for an SRU
[22:53] <cjwatson> pitti: if you're still around, apparently chiark is having problems with piware.de's slave NS arrangements
[22:54] <cjwatson> pitti: I'm told piware hasn't responded correctly since 24 May
[22:58] <kees> mathiaz: I'd like to slangasek's input on it, but if it's tested, I'm happy.
[23:01] <mathiaz> kees: ok - I'll attach the debdiff to the bug and ask for review by the SRU team
[23:01] <kees> mathiaz: thanks :)
[23:05] <mathiaz> slangasek: pitti: could you have a look at bug 219914 and comment on whether the changes in the debdiff are acceptable for an SRU ?
[23:36] <mathiaz> kees: I'm about to leave for the day - do you plan to finish the apache2 sru today ?
[23:36] <mathiaz> kees: or this is work from tomorrow ?
[23:47] <kees> mathiaz: I can work with slangasek to finish it up -- thanks for getting it prep'd