[00:54] <btQuark> hello :D
[00:55] <btQuark> any idea in what ubuntu the a dri2-enabled radeon driver might appear?
[01:16] <RAOF> btQuark: You'd probably be better off in #ubuntu-x, but the answer is "9.10, most likely"
[01:17] <btQuark> w00, there is a channel only for the x nice :D
[01:18] <btQuark> the fglrx is horribly cruel
[01:18] <btQuark> big fail
[03:51] <Dante_J> Greetings room.
[03:51]  * Dante_J waves
[03:56] <RAOF> Dante_J: Incidentally, have you looked for/filed launchpad bugs on these issues?  That'd be the normal way to raise such things.
[03:58] <Dante_J> Hi RAOF, I did scan through launchpad, but these Vuls are rather large one's that are cross distro and in some cases cross platform (Firefox). I took for granted that there would be a Ubuntu security team that would keen on top of vulnerabilities with mitigating patches available.
[04:00] <Dante_J> and when I look at https://lists.ubuntu.com/archives/ubuntu-security-announce/ there are no patches mentioned for All of February, this seemed to be to be highly unusual, as though some kind of infrastructure or process was broken. The patches for Vulns are out there being applied by others.
[04:02] <Dante_J> And as I mentioned in #ubuntu-motu, Hardy is used by corporates and lab maintainers specifically because it's LTS. When you're primary browser is not patched now for about a week after the upstream patch was made available, it seems unusual to me. http://secunia.com/advisories/33799/
[04:03] <ScottK> Dante_J: I think an update is coming soon.
[04:03] <ScottK> LaserJock: I thought Bug #323447 was one you might want to have a look at.
[04:04] <Dante_J> ScottK: for Firefox? thank you. what about sudo, and NSS and others?
[04:05] <ScottK> Yes, for Firefox.  I know our security team keeps track of such things and generally prioritizes them for resolution.  It does take time to integrate the upstream fixes and get them tested.
[04:05] <Dante_J> Regarding sudo: http://www.auscert.org.au/render.html?it=10462
[04:05] <dtchen> (accounting for travel to/from recent sprints)
[04:07] <Amaranth> I wish the sudo one gave more details so you could see how serious the bug actually was
[04:07]  * Amaranth doesn't feel like looking into diffs
[04:08] <Dante_J> In #ubuntu-motu I mooted a comparison of https://lists.ubuntu.com/archives/ubuntu-security-announce/ with https://www.redhat.com/archives/fedora-package-announce/ and that there were a number of packages patched by fedora that have not been in Ubuntu. Firefox & sudo prominent among them.
[04:08] <ScottK> Dante_J: Hardy doesn't have a vulnerable version.
[04:08] <Dante_J> ScottK: of Firefox or sudo?
[04:08] <ScottK> Sudo
[04:08] <ScottK> http://web.nvd.nist.gov/view/vuln/search?execution=e2s2
[04:09] <Amaranth> and firefox updates take some time
[04:09] <ScottK>       sudo | 1.6.9p10-1ubuntu3.3 | hardy-updates | source, amd64, i386
[04:09] <Amaranth> Since we don't just update to the latest version of firefox because they always include non-security changes as well
[04:09] <ScottK> Amaranth: Actually we do.
[04:10] <Amaranth> ScottK: When did that change?
[04:10]  * Amaranth has been gone for a bit
[04:10] <ScottK> We stay within the major version, but Hardy has 3.0, so it'll get the 3.0.whatever.
[04:10] <Amaranth> huh
[04:11] <ScottK> About the time Mozilla corp said you can't ship anything other than what we say you can ship if you want to call it firefox.
[04:11] <Amaranth> So intrepid?
[04:12] <Amaranth> Because I know at least pre-hardy that wasn't how it worked and I thought that was only done once in hardy but I know they got a lot more strict about such things recently
[04:12] <Amaranth> Either way, firefox updates take time, lots of testing needed there
[04:13] <ScottK> Yes.
[04:13] <ScottK> Rmadison says 3.06 is in Jaunty already.
[04:13] <Amaranth> jaunty can break, no one cares that much
[04:13] <ScottK> So I imagine its coming soonish.
[04:13] <Amaranth> sure
[04:13] <Amaranth> Just saying it needs some time
[04:13] <ScottK> Agreed.
[04:14] <ScottK> Also we ended up getting stuck on LTS support for Firefox in Dapper.  Asac is lead of a distro based 'upstrea' project for mozilla 1.8/Firefox 1.5.
[04:15] <ScottK> Add an 'm' in there somewhere.
[04:16] <Dante_J> Amaranth: ScottK: Thanks for the information, I certainly appreciate it.
[04:16] <ScottK> Dante_J: In the future though it'd probably be decent of you to spend a couple of minutes searching the web before getting too excited.
[04:17] <Dante_J> I did, that's why I'm here. Other distros, and not just Fedora have been patching more aggressively than Ubuntu.
[04:17] <ScottK> The CVE that gave the versions affected for sudo was referenced in the web page you gave me.
[04:18] <Dante_J> and the dearth of patches in Ubuntu of _anything_ for February seemed unusual to me. That's all. So I'm here to check nothing is broken and all is ok.
[04:18] <Dante_J> slow is better than broken.
[04:19] <Dante_J> but when things get too laggy, then the difference narrows.
[04:22] <kees> Dante_J: the sudo update is coming, as is firefox.  there was a week-long meeting that ate the first week of Feb with regard to security updates.
[04:22] <ScottK> Reading some of the bugs, I'm not immediately convinced our default configuration in Intrepid would expose this bug.
[04:23]  * ScottK is certain kees knows though.
[04:23] <kees> Dante_J: and, as ScottK just mentioned, the sudo issue isn't very high priority, but certainly will be fixed.
[04:24] <ScottK> That would be another reason it might be delayed.
[04:24] <Dante_J> kees: Thank you kindly for the info. It's appreciated.
[04:24] <kees> Dante_J: the full list for main is here: http://people.ubuntu.com/~ubuntu-security/cve/open.html
[04:24] <kees> each CVE links back to the Ubuntu CVE entry with priorities, notes, patches, bug links, etc.
[04:25] <Dante_J> Wow, I've been looking for the Ubuntu CVE tracker before! Great link, thanks!
[04:25] <Dante_J> A brilliant help!
[04:25] <kees> no problemo.  :)
[04:26] <Dante_J> I'll pass this on to the AusCERT chaps in case they're not aware. Very nice. :)
[04:27] <Dante_J> Do you mind if I pass it on kees ?
[04:28] <kees> Dante_J: sure, doesn't bother me; it's the reality of our tracker.  :)
[04:29] <Dante_J> It's a useful resource, especially for a security group keeping tabs on who has patched what. eg. http://www.auscert.org.au/render.html?cid=1
[04:30]  * kees nods.  The raw data might be interesting too (that's linked from the bzr tree at the top of the url I gave)
[04:30] <Dante_J> and lets face it, Ubuntu is now important infrastructure for a growing number of people, so this information is valuable.
[04:30] <kees> I don't envy cross-distro CVE fix tracking -- it's hard enough just tracking one distro.  :)
[04:30] <kees> indeed
[04:30] <Dante_J> amen brother !
[04:37]  * Dante_J Dips his hat in respect for the good work done here.
[04:37] <Dante_J> Cheers people, thanks for your help.
[04:38] <Dante_J> kees: Thanks to you especially.
[04:39] <LaserJock> ScottK: sorry, was afk, thanks for taking care of it
[04:39] <ScottK> LaserJock: No trouble.  I only hit it because I was intrigued by the tad 'needs kde3'
[04:40] <ScottK> LaserJock: It does seem that someone might want to write up a "If you used to use Klatin ..." wiki page or seomthing.
[04:40] <ScottK> something even.
[04:40] <LaserJock> ScottK: I think I'm going to do that in the Release Notes
[04:41] <ScottK> OK.  Well we'd want it for the Intrepid release notes ....
[04:41] <ScottK> ;-)
[04:41] <LaserJock> ScottK: yeah, well ...
[04:46] <LaserJock> man, I really wish there was a way to extract out separate patches for debian/
[05:28] <dholbach> good morning
[05:31] <ion_> ing
[06:13] <LaserJock> kees: you still up?
[06:22] <nixternal> go to bed LaserJock !!!
[06:27] <LaserJock> pfft
[07:24] <pitti> Good morning
[07:25] <directhex> is it? looks pretty crappy out
[07:26] <pitti> yeah, just starts raining
[07:51]  * lool waves
[08:04] <pitti> hey lool
[08:58] <asac> ScottK: fwiw, the main reason for ffox updates being late this time was us being at a sprint when they released. usually we release the day after upstream releases :)
[08:59] <asac> Amaranth: ^^ ;)
[09:24] <seb128> superm1: hi, why did you open a g-c-c task on bug #319725?
[09:48] <lool> Keybuk: configure.ac:23: error: Autoconf version 2.63 or higher is required
[09:49] <lool> Keybuk: We're lagging!!
[09:49] <lool> :-P
[09:49] <lool> (pulseaudio)
[09:51] <seb128> Keybuk: there is a libtool sponsoring request waiting for you for a while btw
[10:18] <apw> anyone know why we have no alternate installer cd's today?
[10:22] <apw> cjwatson, who 'owns' the iso build process?
[10:24] <amitk> I wish there were jigido images for amd64 desktops too
[10:25] <apw> there are alternate installer jigdo's by the looks fo things for amd64
[10:27] <apw> amitk, though i have found once you have one cd image, they rsync pretty well
[10:31] <maxb> I assume there's no desktop jigdos because so much of the desktop cd is the non-jigdo-able livefs
[10:31] <StevenK> maxb: Right.
[10:32] <StevenK> apw: The 'ubuntu-cdimage' team owns the CD builds
[10:32] <apw> and where does one find them?
[10:32] <maxb> though I'd still find a desktop jigdo convenient for saving the few hundred MB of packages which aren't in the livefs
[10:32] <StevenK> apw: launchpad.net/~ubuntu-cdimage lists the members
[10:33] <StevenK> apw: But I'm checking
[10:33] <cjwatson> sometimes CD builds fail for one reason or another
[10:33] <apw> heh steve and colin ... is there anything they don't do
[10:33] <cjwatson> maxb: it's a few tens of MB, not a few hundred
[10:33] <StevenK> And what cjwatson said
[10:33] <cjwatson> maxb: if it were a few hundred, it'd be worth it
[10:33] <apw> StevenK, apparently you are on the hook too :)
[10:33] <StevenK> apw: Which Steve, there are at least in that team :-P
[10:33] <StevenK> *at least two
[10:34] <apw> indeed.  i was thinking on slangasek
[10:34] <cjwatson> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/jaunty/daily-20090210.log <- today's build log
[10:34] <cjwatson> I expect I broke it in some silly way
[10:35]  * StevenK waits for it to download, fully expecting that cjwatson has fixed the problem before it loads fully
[10:35] <apw> thats like massive
[10:35] <cjwatson> did somebody change the kernel ABI again?
[10:35] <StevenK> Yeah, -7 was ACCEPTed on Friday, I think
[10:35] <cjwatson> yes - and SOMEBODY NBSed the old packages before we updated d-i
[10:35] <cjwatson> please don't do that
[10:36] <slangasek> apw: "is there anything they don't do" - I don't touch the kernel ;)
[10:36] <cjwatson> I'll update d-i now, which will fix it
[10:36] <StevenK> cjwatson: Shall I update the platform seed?
[10:36] <apw> slangasek, cirtainly doesn't include sleeping
[10:36] <cjwatson> StevenK: let me do it together with d-i
[10:36] <slangasek> mumble
[10:36] <StevenK> cjwatson: Sure
[10:37] <cjwatson> StevenK: were you the NBS-remover in this case?
[10:37] <slangasek> cjwatson: no, that was me
[10:37] <StevenK> cjwatson: I've not logged into cocoplum for two days due to flying and such
[10:37] <cjwatson> ok, please be less trigger-happy :)
[10:37] <slangasek> cjwatson: or should I make it a policy to upload d-i at the same time, instead?
[10:37] <StevenK> Why does everyone think NBS is always me? :-)
[10:38] <slangasek> I nuked them because I knew the new kernel was accepted, and having them there makes the NBS list unreadable
[10:38] <slangasek> fwiw, we should probably document the kernel NBS specialness in ArchiveAdministration
[10:38] <cjwatson> slangasek: if you take care of d-i at the same time, certainly - but the old kernel definitely shouldn't be removed until d-i is updated to the new one, otherwise we lose out on daily-build testing time
[10:38] <cjwatson> StevenK: it usually is ;-)
[10:39] <slangasek> cjwatson: well, ok
[10:39] <cjwatson> I'll document that
[10:39] <apw> cjwatson, how come we have live and not alternate cd's i'd expect both to be affected
[10:40] <apw> given that ironically the latter is useful without being bootable and the former not
[10:40] <cjwatson> apw: 'cos the alternate CD requires a package upload to change kernel versions, and the live CD doesn't
[10:40] <StevenK> apw: Since the alternate is locked to the kernel ABI, the live isn't
[10:41] <apw> hmmm ... sounds liek the alternate needs to learn something from the live to me
[10:42] <apw> anyhow, glad its fixed.  i can see why you love it when we bump the abi
[10:42] <cjwatson> it's a radically different build process, not easily changed to take account of this
[10:42] <cjwatson> fact is that the installer ships objects which are on archive.ubuntu.com, and any such object requires an upload to change
[10:43] <cjwatson> we used to have automatic daily builds of the installer, although even those didn't take account of ABI changes so when that broke with the switch to Soyuz we stopped bothering
[10:43] <cjwatson> apw: thanks for the note
[10:43] <apw> is there something the kernel team should be doing there?  as a step after linux-meta or something?
[10:44] <cjwatson> apw: you guys already mail ubuntu-installer - I just hadn't caught up on mail
[10:44] <apw> good enough, as long as we are not failing process
[10:45] <cjwatson> I might do a quick CD rebuild later - I was waiting for today's CDs myself to test some things
[10:46] <cjwatson> slangasek: (in general I have no objection to the set of people who upload d-i all the time not being just me ;-) )
[10:46] <slangasek> right :)
[10:48]  * directhex uploads d-i
[10:51] <cjwatson> ... for a good reason
[11:09] <Keybuk> lool: we could sync that from experimental
[11:10] <lool> Keybuk: I'm happy if you think that's ok
[11:10] <lool> I certainly am not confident to ask that myself
[11:10] <Keybuk> lool: let me look at the changelog, if I'm happy, I'll do it
[11:14] <ogra> cjwatson, is there a reciepe online to properly do a testbuild of d-i locally ? dpkg-buildpackage -b seems to not work for me
[11:14] <ogra> (i just want to have the netboot binary blob for nslu2 in the end)
[11:16] <cjwatson> ogra: how does it fail?
[11:16] <ogra> it cant find anna
[11:16] <cjwatson> do you use a local mirror?
[11:17] <ogra> hmm, and it apparently uses my local sources.list
[11:17] <ogra> heh, yeah
[11:17] <ogra> how did you guess :)
[11:17]  * ogra switches that to ports.u.c
[11:18] <cjwatson> either fix your local mirror to include main/debian-installer, or create a file build/sources.list.udeb.local in the unpacked d-i tree and put 'deb http://archive.ubuntu.com/ubuntu jaunty main/debian-installer' in it
[11:18] <cjwatson> oh, or ports
[11:18] <cjwatson> or perhaps better, copy build/sources.list.udeb to build/sources.list.udeb.local and edit to taste
[11:18] <ogra> i'm fine switching over ... i just reinstall things to often here to not use a local mirror in general
[11:18] <cjwatson> likewise, but my local mirror includes d-i :)
[11:19] <cjwatson> (funny that)
[11:19] <ogra> heh
[11:20] <Keybuk> lool: looks ok, will upload when make check passes
[11:21] <ogra> pfft ... now it fails with bootchart-udeb ...
[11:21] <ogra> but seems to pull properly from http://ports.ubuntu.com jaunty/main/debian-installer
[11:22] <Keybuk> we dropped that
[11:22] <cjwatson> ogra: pull newer source; I removed bootchart-udeb in the most recent upload
[11:22] <ogra> ah
[11:22] <StevenK> I seem to recall bootchart-udeb in NBS
[11:22]  * cjwatson looks at /usr/lib/pkgconfig/gdk* in confusion
[11:22] <cjwatson> /usr/lib/pkgconfig/gdk-directfb-2.0.pc includes cairo-xlib in Requires; /usr/lib/pkgconfig/gdk-x11-2.0.pc doesn't
[11:23] <ogra> OH ! .... i just noticed for the first time that the jaunty-changes mail contains a direct link to the source packages ... how convenient ...
[11:24] <cjwatson> or d-i is in bzr
[11:24] <cjwatson> if you're going to hack on it anyway you might as well just have a checkout
[11:24] <ogra> indeed
[11:24] <ogra> currently i'm blindly poking around anyway testing out some theories
[11:25] <ogra> i'll surely do use bzr for a fix in the end
[11:32] <ogra> ogra@beagle:~$ ls /bin/
[11:32] <ogra> -bash: /bin/ls: No such file or directory
[11:32] <ogra> hmm, i wonder if i should get worried
[11:32] <StevenK> ogra: echo /bin/*
[11:32] <ogra> all there ...
[11:33] <ogra> looks like libc broke during a dist-upgarde
[11:33] <StevenK> Okay, then something /bin/ls links against is missing/broken
[11:33] <ogra> yeah
[11:34] <ogra> it properly unpacked libc6 2.9-0ubuntu7
[11:34] <ogra> in the next line i get: dpkg (Unterprozess): Konnte rm nicht zum Aufräumen ausführen: No such file or directory
[11:34] <ogra> so it cant exec rm directly after unpacking ...
[11:35] <StevenK> Does /lib/ld-linux-*.so exist?
[11:35] <ogra> ogra@beagle:~$ echo /lib/ld-linux-*
[11:35] <ogra> /lib/ld-linux-*
[11:35] <ogra> hmm
[11:37] <StevenK> ogra: That means no. :-)
[11:38] <ogra> i dont really care about the system ... takes me 5 min to uncompress the rootfs tarball on the disk ...
[11:38] <StevenK> ogra: Sure, but I'm curious how it got to that state ...
[11:38] <ogra> but i suspect that shouldnt happen during a dist-upgrade :)
[11:39] <StevenK> ogra: It's recoverable, if you don't mind using echo or a statically compiled cat ...
[11:39] <ogra> http://paste.ubuntu.com/116422/
[11:39] <ogra> sorry, its german ...
[11:40] <ogra> looks like ldconfig is barking at me earlier
[11:46] <ogra> if anybody is interested in gathering more info from that system, i'll keep it around (not needed anyway atm)
[12:16] <cjwatson> seb128: there's something wrong with our gtk+ patches, that isn't broken in Debian unstable/experimental. /usr/lib/pkgconfig/gdk-directfb-2.0.pc includes cairo-xlib in Requires; /usr/lib/pkgconfig/gdk-x11-2.0.pc doesn't
[12:17] <cjwatson> seb128: it looks like this is a bug in debian/patches/003_gdk.pc_privates.patch, which adds cairo-xlib in the non-explicit-deps case (only used by the directfb build at the moment)
[12:17] <cjwatson> seb128: do you know anything about this?
[12:25] <seb128> cjwatson: upstream did add this requirement recently, let me look at how I updated the patch
[12:25] <cjwatson> seb128: I think I might have an idea
[12:25] <seb128> cjwatson: what else would you expect?
[12:25]  * cjwatson waits for dpkg-source to get a move on
[12:27] <cjwatson> seb128: I'm thinking of http://paste.ubuntu.com/116434/
[12:27] <dholbach> kees: tjaalton just told me that you made my laptop give me only black screens if it boots with "splash" - no idea what he exactly means by that... something with initramfs/usplash?
[12:28] <cjwatson> which would result in cairo-xlib ending up in Requires.private of the x11 backend, and not at all in Requires/Requires.private of the directfb backend, which I think is correct?
[12:28] <tjaalton> kees: you updated usplash
[12:28] <Keybuk> doko: so, about the java compiler failure on the buildds
[12:28] <Keybuk> doko: https://launchpad.net/ubuntu/+source/bootchart/0.9-0ubuntu8keybuk3/+build/858530/+files/buildlog_ubuntu-jaunty-i386.bootchart_0.9-0ubuntu8keybuk3_FAILEDTOBUILD.txt.gz
[12:29] <tjaalton> dholbach: the new kernel initramfs got the new usplash first, so the old kernel worked until you regenerated the image
[12:29] <dholbach> tjaalton: ah ok
[12:29] <seb128> cjwatson: yes, that looks good to me
[12:30] <cjwatson> seb128: ok, I'll do a test build to make sure - shall I upload if it DTRT?
[12:30] <seb128> cjwatson: yes
[12:30] <seb128> thanks for spotting the error!
[12:30] <cjwatson> no problem, the d-i buildd spotted it really ;-)
[12:32] <doko> Keybuk: buildd only, or local build?
[12:32] <Keybuk> doko: buildd only
[12:32] <Keybuk> builds just fine locally in a chroot
[12:33] <Keybuk> Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java-6-openjdk/lib/tools.jar
[12:33] <Keybuk> and
[12:33] <dholbach> kees: mjg59 says usplash should do the same thing as "vbetool vgamode 3" *shrug*
[12:33] <Keybuk> /build/buildd/bootchart-0.9/build.xml:41: Unable to find a javac compiler;
[12:33] <Keybuk> com.sun.tools.javac.Main is not on the classpath.
[12:33] <Keybuk> seem to be the key bits
[12:33] <Keybuk> yet it build-depends on java-gcj-compat-dev | java-compiler
[12:35] <cjwatson> isn't that the wrong build-dep now?
[12:35] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000460.html
[12:36] <cjwatson> should use default-jdk-buildddep
[12:36] <cjwatson> default-jdk-builddep
[12:36] <Keybuk> why jdk?
[12:36] <Keybuk> oh, I see
[12:37] <doko> Keybuk: I'll upload a new version using default-jdk/default-jre, and setting JAVA_HOME
[12:42] <Keybuk> ok, thanks
[12:45] <ogra> wow the /usr/share/doc/debian-installer/armbooting.txt really targets ancient stuff :)
[12:47] <lool> ogra: You might be more interested in doc/devel/hardware/arm/nslu2/README
[12:55] <doko> Keybuk: bootchart built
[12:56] <Keybuk> \o/
[13:00] <asac> james_w: hmm. debcommit doesnt do the --fixes lp:xxxx magic for me anymore
[13:03] <pitti> meh, latest X.org updates break X on GM945 (black screen, nothing in log)
[13:03] <pitti> bryce, tjaalton: ^ did you hear similar reports already?
[13:04] <beuno> pitti, same here
[13:04] <beuno> since yesterday or the day before
[13:04] <pitti> vesa works for now
[13:06] <beuno> pitti, BUT, if you login with the older kernel (2.6.24-21), it works
[13:06] <pitti> interesting
[13:06] <pitti> I didn't try 2.6.27-6 yet
[13:06] <beuno> I tried it, and it looks less broken, but still doesn't work
[13:07] <beuno> I've also been having the wierdest problem with the wireless. It intermintently stops working (transmiting) for 4-5 seconds, and then works again
[13:07] <beuno> it does the same thing on different APs/internet connections
[13:11] <tjaalton> pitti: usplash is broken
[13:12] <pitti> tjaalton: happens without usplash, too
[13:12] <ogra> for me it worked after dropping the flash
[13:12] <ogra> *splash
[13:12] <tjaalton> dunno then
[13:12]  * ogra does definately to much ARM work
[13:36] <tjaalton> siretart: you are probably aware of the annoyance in emacs that you cannot turn off the splash screen in site-start.el.. any way to allow that in the ubuntu package?
[13:36] <Mithrandir> tjaalton: you can't?  That's silly.
[13:36] <tjaalton> Mithrandir: it's infuriating..
[13:37] <tjaalton> http://www.gnu.org/software/emacs/manual/html_node/emacs/Initial-Options.html
[13:37] <Mithrandir> I have (setq inhibit-splash-screen t) in my personal .emacs, though
[13:37] <tjaalton> that works
[13:37] <tjaalton> but there are thousands of users here..
[13:38] <bryce> pitti: yes I'm getting the same thing, on -intel
[13:38] <Mithrandir> make /usr/bin/emacs a shell script that calls the real binary with `--no-splash'
[13:38] <bryce> pitti: is there a bug id already?
[13:38] <pitti> bryce: I didn't file one yet; there might be
[13:38] <bryce> I looked yesterday but didn't see one
[13:39] <tjaalton> bryce: there are a couple of issues.. one is that usplash is broken and then the one that pitti is seeing
[13:39] <pitti> tjaalton: in what way? usplash WFM
[13:40] <bryce> the problem I'm seeing is definitely not usplash; also it goes away if vesa is specified
[13:41] <tjaalton> pitti: yes, but it fails to give back the display
[13:41] <tjaalton> Mithrandir: that's a possibility, but a bit ugly :)
[13:41] <bryce> I suspect it must be an update between thursday and yesterday
[13:46] <tjaalton> bryce: have you tried booting without splash?
[13:46] <bryce> tjaalton: not yet
[13:47]  * bryce tries
[13:51] <bryce> tjaalton: huh, came up fine
[13:52] <bryce> pitti: have you tried booting without usplash?
[13:52] <pitti> bryce: yes
[13:52] <tjaalton> bryce: like I said :)
[13:52] <pitti> bryce: same problem
[13:52] <bryce> tjaalton: is there a bug id on the usplash bug?
[13:52] <tjaalton> bryce: not sure
[13:53] <bryce> tjaalton: who all is seeing the usplash issue?
[13:53] <kirkland> pitti: do you happen to know if there's a wake-on-lan package in main?  etherwake and wakeonlan both are in universe
[13:54] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/327230
[13:54] <tjaalton> bryce: dholbach did
[13:55] <bryce> let's see what happens booting an earlier kernel
[13:55] <dholbach> bryce: it will work until you update the initramfs for that kernel
[13:55] <tjaalton> bryce: usplash is included in the initramfs, so an earlier kernel with an earlier usplash works
[13:56] <bryce> ah
[13:56]  * surfaz is away: Estoy comiendo, escribir mi nombre para que el Xchat me avise
[13:57] <dholbach> surfaz: do you think you could turn off auto-away in your irc client please?
[13:57] <bryce> dholbach, tjaalton: you're right; earlier kernel boots fine
[13:59] <bryce> dupes:  #327610 #327505 #327498 #327444 #327286
[14:00] <tjaalton> yay for having no assigned maintainer ;)
[14:00] <bryce> :-/
[14:00] <bryce> is there a usplash change we can revert?
[14:01] <Keybuk> lool: new autoconf in
[14:01] <lool> Keybuk: thanksely
[14:01] <Keybuk> bryce: I think usplash last changed in 1842
[14:01] <bryce> Keybuk: also on Feb 4th
[14:02] <bryce> kees probably isn't awake yet though
[14:02] <Keybuk> hmm, interesting
[14:02] <bryce>   * libusplash.{c,h}, usplash.c:
[14:02] <bryce>     - Move pulsate and animation pipes into libusplash to unblock animations
[14:02] <bryce>       while waiting for stdin (LP: #326709).
[14:02] <bryce>     - Process animations between commands to avoid falling behind when
[14:02] <bryce>       running in verbose mode.
[14:02] <bryce>     - Drop unneeded signal-blocking code.
[14:02] <Keybuk> it could be unrelated to the patch, but a rebuild that caused it
[14:02]  * bryce nods
[14:02] <bryce> however, there was also a change Jan 21st
[14:03] <bryce> so it would have been rebuilt at that point, right?
[14:04] <bryce> I still have the previous deb, let me test that
[14:07] <bryce> interesting that for many, this is indistinguishable from an X blank screen
[14:07] <bryce> yep, earlier .deb boots fine
[14:25] <Fenario> freeflying, ping
[14:30] <cjwatson> seb128: I happened to notice that your Maintainer address in gtk+2.0 is @ubuntu.org rather than @ubuntu.com
[14:30] <pitti> slangasek: oh, just stumbled over https://wiki.ubuntu.com/LaptopTestingTeam/HotkeyResearch ..
[14:31] <pitti> kirkland: WOL> not that I know of
[14:31] <pitti> kirkland: if we need one, there's always the MIR route :)
[14:31] <seb128> cjwatson: ups, I changed the debian to ubuntu too quickly ;-)
[14:33] <lamont> I need a tool to dump a palm-pilot addressbook etc that doesn't blow its brains out when it hits the corruption that is present in my DB...
[14:42] <lool> seb128: Better than debian.com   :-P
[14:42] <seb128> ;-)
[14:42] <seb128> lool: btw since you are there, how busy are you this week? ;-)
[14:43] <lool> seb128: What's the highest level of business you know?
[14:43] <seb128> lool: would be nice to get pygobject and pygtk updated to their current version, since we are mostly in sync with debian experimental and like working on those ;-)
[14:43] <lool> seb128: Ok; I'm noting that down
[14:43] <seb128> lool: thanks ;-)
[14:43] <lool> seb128: I have insurance, trip report, activity report, and 4 interviews to do this week
[14:44] <lool> And I'm on IRC!
[14:44] <seb128> lool: theorically those updates should not be too hard
[14:44]  * lool /quits
[14:44] <lool> Ok
[14:44] <seb128> I say theorically because you had issues on previous rounds ;-)
[14:44] <seb128> thanks!
[14:44] <lool> Yeah, I wasn't really lucky with pygobject/pygtk so far
[14:44] <lool> seb128: I had a conversation at FOSDEM that these will likely be superseded
[14:45] <seb128> lool: what, pyg* using gobject introspection?
[14:45] <lool> Yes
[14:45] <seb128> lool: that will require code changes in applications though I guess, no?
[14:45] <seb128> ie the api will be different
[14:46] <lool> I don't know
[14:46] <pitti> tseliot: bug 287470 is still open for -173 in jaunty; should that be closed, or does it really need an upload?
[14:47] <kirkland> pitti: cool, i'll put one together, thanks ;-)
[14:48] <racarr> lool, seb128: It's not really clear. pybank isn't really actively developed. The API right now is different though
[14:48] <racarr> But very similar, and probably could be the same
[14:49] <lool> I guess we could replace pygtk/pygobject with a thin impedance matching layer and ask people to move to the new API
[14:50] <lool> Anyway, future stuff I'm not working on and wont work on :)
[14:51] <EagleScreen> I have a dude. I am going to do a change in package qtparted, it uses dpatch patches in debian/patches, so I fisrtly will make a dpatch patch with my changes, and later a debdiff with the difference between old and new package, my question is if the changes in the changelog file must go in the dpatch patch, or only in the debdiff patch
[14:52] <bardyr> nden
[14:52] <tseliot> pitti: the bug report can be marked as "fix released" now
[14:52] <lool> EagleScreen: In the debdiff
[14:52] <pitti> tseliot: great, thanks
[14:52] <seb128> tseliot: hey
[14:52] <lool> EagleScreen: The dpatch is to hold upstream changes; anything below debian/ shouldn't be in a dpatch and will appear in the debdiff
[14:52] <tseliot> seb128: hey
[14:53] <EagleScreen> thanks
[14:53] <seb128> tseliot: how is the gnome-desktop update going? need any help on that one?
[14:53] <tseliot> seb128: I'm still fighting with a few patches, I'm trying to solve the problems with the display capplet and I will let you know about the rest
[14:54] <seb128> ok
[14:54] <seb128> tseliot: what problems with the capplet?
[14:54] <tseliot> seb128: the aspect dropdown patch doesn't apply any longer
[14:54] <seb128> tseliot: can you try to get the update done first and then look at the other issues (if that's xrandr 1.2 drivers, etc)? so that would unblock the soname transition and the gnome-settings-daemon and gnome-control-center updates
[14:55] <seb128> tseliot: ok, let me know when the update is ready then, I will do some bug triage until then ;-)
[14:56] <tseliot> seb128: the g-c-c has the highest priority and I can already give you my patches for gnome-desktop but I would really like to get g-c-c to build first
[14:56] <tseliot> also patches for the network capplet fail to apply, etc.
[14:56] <seb128> tseliot: I'm not that much in a hurry, ping me when you will have g-c-c ready and tested
[14:57] <tseliot> seb128: ok
[14:58] <pitti> tkamppeter: interested in joining the desktop team meeting in #u-desktop?
[15:01] <pitti> tkamppeter: (... at 16:30 UTC)
[15:02] <EagleScreen> then ANY change under debian/ in debdiff?
[15:02] <EagleScreen> what about updating debian/patches/00list? also in debdiff?
[15:03] <cjwatson> updating debian/patches/00list in a dpatch would be ... exceptionally twisted
[15:03] <cjwatson> (and generally wouldn't work)
[15:04] <EagleScreen> thanks Colin
[15:06] <EagleScreen> cjwatson dod you remember
[15:06] <EagleScreen> Bug #133072:
[15:06] <EagleScreen> This report is public
[15:08] <cjwatson> EagleScreen: yes - have you tried the update to console-setup that's available in intrepid-updates now?
[15:09] <cjwatson> as of December or so
[15:09] <EagleScreen> surely yes
[15:10] <EagleScreen> console-setup 1.25ubuntu4 (intrepid-updates)
[15:11] <EagleScreen> it fixes the problem, but it is necessary to run it each time I start Ubuntu
[15:12] <EagleScreen> I mean running sudo setupcon each time
[15:13] <EagleScreen> may be some script during boot shuld run it
[15:29] <superm1> seb128, that's the app that is crashing in the current development version, gnome-display-properties in jaunty which is part of gnome-control-center
[15:30] <seb128> superm1: ok, I figured that after pinged, that was confusing to have one gnome-settings-daemon and one gnome-control-center task there
[15:30] <cjwatson> EagleScreen: setupcon's already run at boot, actually
[15:30] <cjwatson> EagleScreen: so yet another thing is going wrong. sigh
[15:31] <cjwatson> EagleScreen: I'm not sure what you mean by "it fixes the problem", then, since you go on to say that it doesn't fix the problem
[15:32] <cjwatson> EagleScreen: and yet we have already confirmed separately that it does fix a very similar problem for other users
[15:32] <superm1> seb128, yeah those other tasks might want to be adjusted as it was found in intrepid initially
[15:32] <EagleScreen> when I boot Kubuntu 8.10, tty console cannot change ñ, vocals with accent and other charactes such as €
[15:33] <lool> doko:   * Use dpkg-architecture -f instead of -a for cross builds.
[15:33] <cjwatson> upgrading to the console-setup in intrepid-updates, and if necessary running update-initramfs -u, should arrange for the console to be set up before usplash starts
[15:33] <cjwatson> EagleScreen: are you using any other unusual customisations, such as splashy?
[15:33] <lool> doko: Are you sure you want to drop -a?  How is the architecture going to be set?
[15:34] <EagleScreen> i am not using splashy
[15:34] <EagleScreen> after I run sudo setupcon tty result fixed, all that characters can be typed and showed
[15:34] <cjwatson> in any case, that bug is only barely comprehensible since several people have added essentially unrelated issues to it
[15:34] <lool> doko: The problem was that in the old code "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -aarmel -qDEB_HOST_GNU_TYPE" would return i486-linux-gnu
[15:34] <cjwatson> (lesson for the future: don't do that)
[15:35] <lool> doko: If you add -f and ignore the env, "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -aarmel -qDEB_HOST_GNU_TYPE -f" returns arm-linux-gnueabi
[15:35] <lool> (which is the fix I proposed)
[15:35] <cjwatson> EagleScreen: I could do with a copy of your initramfs to investigate
[15:35] <doko> lool: please feel free to fix it. I think I misunderstood you.
[15:35] <lool> If you remove -f and -a, then it becomes "DEB_HOST_GNU_TYPE=i486-linux-gnu dpkg-architecture -qDEB_HOST_GNU_TYPE -f" => i486-linux-gnu, where -f is useless and you're not cross-architecturing
[15:36] <EagleScreen> yes I will give you as you want
[15:36] <lool> doko: Sure will do
[15:36] <freeflying> Fenario: pong
[15:36]  * lool sighs at pushing binutils
[15:39] <EagleScreen> cjwatson I have discovered one new thing. I log into tty console, I run sudo setupcon and characters are fixed, but if I log out and I log in again, characters are broken again.
[15:45] <lool> doko: Do you keep binutils in a VCS?  thanks for the other fixes BTW!
[15:45] <lool> doko: pushing
[15:45] <doko> lool: no. I should do that ... started a repo locally, but it's out of date
[15:46] <lool> Ok, just wanted to make sure the Debian tree will get the fix as well
[15:49] <pitti> thekorn: seems bug.subscribers.add() now started giving "Wrong XPath-Expr while parsing Subscribers.__xml.edge.stable" on all bugs?
[15:49] <pitti> thekorn: do you want a bug report for that, or already know it?
[15:49] <cjwatson> pitti: I filed a bug
[15:49] <cjwatson> bug 327620
[15:50] <pitti> ah, thanks
[15:52] <thekorn> pitti, cjwatson, oh, will try to fix it today, thanks for reporting this
[15:52] <cjwatson> I also started writing a launchpadlib version of the same program
[15:52]  * pitti was just going to propose that, too
[16:02] <thekorn> yes, using launchpadlib is a good idea, because the more javascript snippets will be added to launchpad the more likely py-lp-bugs will fail to parse the pages
[16:02] <cjwatson> indeed
[16:06] <kees> bryce, Keybuk: hrm, I can't reproduce the usplash glitch. is it intel only?
[16:07] <Keybuk> kees: I've not reproduced it either
[16:08] <kees> bryce: if you revert my usplash change and rebuild usplash, does it still hang?
[16:08] <tseliot> seb128: some patches: http://albertomilone.com/ubuntu/gnome/jaunty/sebfiles.txt
[16:08]  * kees will be back after breakfast and exercise...
[16:09] <tseliot> seb128: unfortunately I couldn't make g-c-c build because (as you will see) other patches failed
[16:10] <seb128> tseliot: did you work on the gnome-desktop update too (ie packaging changes for the soname update)? or just on the patches update?
[16:11] <seb128> tseliot: you can probably comment the patches which don't apply if you want to test locally
[16:11] <tseliot> seb128: you will find the patches for gnome-desktop there. It builds
[16:11] <seb128> tseliot: I will get mvo to update his proxy changes if those don't apply to the new version
[16:11] <tseliot> seb128: ok
[16:12] <seb128> tseliot: ok, are you interested to do the packaging changes for the gnome-desktop update too or should I pick you patch update and do that now? I'm fine doing it, I just want to get that uploaded to unblock other things ;-)
[16:13] <tseliot> seb128: sure, I can do it myself and ask you to merge from my branch
[16:14] <bryce> kees: if I revert your change and rebuild usplash, it works fine
[16:14] <seb128> tseliot: you want to do it or prefer to work on other thing? I'm fine either way, the annoying part was the patch update ;-)
[16:14] <bryce> kees, good morning
[16:15] <tseliot> seb128: I doubt I'll do anything else today, therefore it's not a problem at all
[16:15] <seb128> tseliot: ok, so feel free to do it and ping me when it's ready I will sponsor the upload
[16:16] <tseliot> seb128: ok
[16:19] <bryce> kees: I've also tried rebuilding debs of your .28 locally and installed and booted them
[16:19] <bryce> kees: which then reproduces the black screen issue on boot.
[16:19] <bryce> brb
[16:22] <LaserJock> mvo: edubuntu ping
[16:24] <mvo> LaserJock: oh, right
[16:31] <LaserJock> kees: what does the "needs triage" bit on the CVE tracker mean exactly?
[16:32] <apw> superm1, this bug #319725 ... got a reference to the bzr branch anywhere
[16:37] <verwilst> info database35
[16:37] <verwilst> oops :D
[16:46] <EagleScreen> how can I apply a debdiff patch?
[16:47] <LaserJock> patch -p1 < <debdiff> I think works
[16:48] <LaserJock> it might be -p0 though, I can never remember
[16:48] <EagleScreen> i am trying that
[16:48] <LaserJock> EagleScreen: so what's it having an issue with then?
[16:50] <EagleScreen> yes, just patch is not being applied
[16:51] <LaserJock> EagleScreen: do you have the right version of the source package you're trying to apply it to
[16:51] <EagleScreen> I think yes
[16:52] <LaserJock> EagleScreen: what kind of errors is it giving? is it unable to find the files or is it missing hunks?
[16:52] <EagleScreen> any output error
[16:53] <EagleScreen> i am in the decompressed folder of the package
[16:53] <LaserJock> oh
[16:53] <LaserJock> do it one level up
[16:54] <EagleScreen> i was running this: patch -p1 < ../qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
[16:55] <LaserJock> so cd ..
[16:55] <EagleScreen> is it always necessary doing it one level up? i also tried -p0
[16:55] <LaserJock> yes
[16:56] <LaserJock> well, I guess it wouldn't *have* to be one dir up
[16:56] <LaserJock> but you might need -p2 or further
[16:57] <EagleScreen> now i am one level up
[16:57] <EagleScreen> i have run patch -p1 < qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
[16:57] <EagleScreen> is it ok?
[16:57] <LaserJock> sure
[16:57] <LaserJock> just play around with the -p until it works ;-)
[16:58] <EagleScreen> but i am reading the sources and they dont seem to be changed
[16:58] <EagleScreen> i will have to play..
[16:58] <LaserJock> you will know when it worked
[17:00] <EagleScreen> i have tested from p0 to p4
[17:00] <LaserJock> and it still gives you errors?
[17:05] <EagleScreen> it doesn't give me any error, just does not change nothing in the sources
[17:07] <LaserJock> if it doesn't give you any errors then it should have applied
[17:07] <LaserJock> EagleScreen: so perhaps the changes aren't where you think they are?
[17:08] <LaserJock> when you apply the patch it should tell you which files it modified
[17:09] <EagleScreen> it tell me nothing
[17:10] <LaserJock> EagleScreen: you're sure you're running it on 0.4.5-4ubuntu2 and not 0.4.5-4ubuntu2.1?
[17:11] <EagleScreen> yes, sure, i tell you that the sources are not changed
[17:11] <EagleScreen> can I make a diff patch against a .dsc file in place of a debdiff patch?
[17:12] <EagleScreen> the decompressed folder is in ~/devel/qtparted-0.4.5
[17:13] <EagleScreen> and the patch is in ~/devel/qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
[17:13] <LaserJock> you can make a debdiff by doing: debdiff <first .dsc file> <second .dsc file
[17:14] <EagleScreen> yes that is the way I made the debdiff
[17:14] <LaserJock> ok, but running patch doesn't give you anything my guess is that you got the wrong version
[17:14] <EagleScreen> lets see..
[17:15] <LaserJock> or perhaps you didn't actually make any changes in the ubuntu2.1 source package
[17:15] <EagleScreen> qtparted has seven patches yet, in debian/patches
[17:15] <EagleScreen> they are in dpatch format
[17:15] <EagleScreen> i have added one more, using dpatch-edit-patch
[17:16] <EagleScreen> and changing with ti the .dektop file
[17:16] <LaserJock> ok, and if you look at the debdiff that shows up?
[17:17] <EagleScreen> yes it is, wait a moment..
[17:18] <EagleScreen> oh no! the patch file is empty!
[17:18] <EagleScreen> I dont undestand why
[17:20] <EagleScreen> a debdiff file is just a plain text file isn't it?
[17:21] <LaserJock> yep
[17:22] <EagleScreen> ok now I have the right patch
[17:24] <EagleScreen> now it is well applied with: $ patch -p1 < ../qtparted_0.4.5-4ubuntu2_to_0.4.5-4ubuntu2.1.debdiff
[17:24] <LaserJock> EagleScreen: great
[17:25] <EagleScreen> thanks
[17:40] <kees> bryce: well, crap.  I did try to split up my changes into logical commits to bzr.  I'll try to reproduce on my intel hw, and if I still don't see it, I'll build some versions of usplash for you with progressively more commits in it.
[17:40] <kees> LaserJock: it means that the given release of a package hasn't been checked for the vulnerability.
[17:42] <LaserJock> kees: and who generally checks? can anybody do that?
[17:43] <kees> LaserJock: absolutely anyone can check.  the whole repository is in public bzr.  There's even an extensive README on how it all works.  https://launchpad.net/ubuntu-cve-tracker
[17:44] <LaserJock> kees: awesome, thanks. I was looking at moodle :/
[17:44] <kees> LaserJock: yeah, moodle is a mess.
[17:44] <LaserJock> kees: I think CVE-2008-5619 should be resolved in jaunty when I merge
[17:44]  * kees nods
[17:45] <LaserJock> kees: but I'll look at the previous releases to see if it's vulnerable
[17:45] <kees> it's the back-porting and testing that's going to be a pain.
[17:45]  * kees nods
[17:46] <LaserJock> kees: luckily Debian has fixed a *ton* of moodle bugs and security issues
[17:47] <LaserJock> kees: I filed a MIR on smarty as Debian has removed the moodle copy and replaced it with a dep
[17:47] <LaserJock> they did the same for yui but I don't see it going into main for Jaunty as it requires javascript-common and wwwconfig-common
[17:48] <LaserJock> for Jaunty+1 maybe we can work with the new Debian maintainers to get rid of more of the embedded libs
[17:50] <bryce> kees: mdz mentioned you also have seen the crash for bug 324368 -- do you have steps to reproduce it?  (just checking for the null ptr doesn't seem to be a sufficient fix)
[17:51] <kees> LaserJock: excellent
[17:51] <kees> bryce: I haven't been able to reproduce it yet.  it only happened once.
[17:52] <kees> bryce: I suspect it was related to me yanking out a projector before/during/after a resume.
[17:52] <bryce> kees: ah
[17:52] <kees> bryce: but, I'm not really sure what the sequence was.  :(
[18:12] <superm1> apw, it's on the bug
[18:18] <superm1> apw, https://code.edge.launchpad.net/~superm1/gnome-control-center/vendor-fallback/+merge/3508
[18:18] <apw> superm1, thanks. being dense clearly
[18:18] <superm1> apw, no, i agree that it's quite easy to overlook the bzr link on bugs.  i've done it myself too :)
[18:19] <apw> so basically its, "yeah ok, but i have some conflicting changes already in the pipe, lets redo it on top"
[18:20] <apw> so i don't need to keep this laptop with the bug, it can come back to you
[18:21] <superm1> apw, if you see anything else on it that you'd like to address in using it you can hang onto it for a little longer, otherwise sure send it back
[18:22] <kees> bryce: hrm, no luck reproducing usplash weirdness
[18:49] <hwilde> anybody have a good tool to view cpu load per thread for multithreaded apps ?
[18:52] <ogra> cjwatson, still around ?
[18:53] <cjwatson> ogra: yes
[18:53] <ogra> cjwatson, i'm trying to find out why our nslug image doesnt work ...
[18:53]  * ogra does a c&p from -arm
 til/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header .... thats debian ...
 util/pad $(TEMP)/initrd.gz.nslu2 5636080 # size of partition - 21 for header .... thats ours
[18:54] <ogra> cjwatson, where does that 21 come from ?
[18:54] <ogra> the partition changes seem all ok, but i dont understand why our header is 21 bytes instead of 16
[18:56] <cjwatson> ogra: bzr up
[18:56] <ogra> (thats from build/config/armel/ixp4xx/netboot.cfg btw)
[18:56] <mnabil> guys , i'm creating custom ubuntu live cd , how can i add a script to be run in the startup ?
[18:56] <cjwatson> ogra: lool pointed that out earlier on #ubuntu-installer; I had understood the 16 to be blocks rather than bytes and so miscorrected it. It's fixed in bzr
[18:57] <cjwatson> mnabil: where in the startup sequence?
[18:57] <ion_> Aah, S:Startup-Sequence
[18:57] <ogra> cjwatson, ah, k, well, i'm not sure yet its the fix we need, i just wanted to know where the 21 comes from :)
[18:57] <ogra> i think the headers are hadcoded in slugimage so the size shouldnt vary
[18:58]  * ogra goes and rolls another testimage
[19:01] <cjwatson> ogra: I set it back to 16, it was just my mistake
[19:01] <ogra> ah
[19:01] <ogra> well, lets see :)
[19:01] <ogra> that whole setup is weird and scary
[19:02] <ogra> as it comes from debian
[19:04]  * ogra wishes LP would actually work :/
[19:10] <mnabil> cjwatson, sorry for late, i mean startup of the shell
[19:10] <mnabil> cjwatson, like clonezilla if you know it
[19:11] <cjwatson> "startup of the shell"?
[19:12] <cjwatson> you mean a rescue shell?
[19:12] <cjwatson> you need to be very very clear on exactly where you want to put it in the startup sequence
[19:15]  * ogra curses ... damned i just deleted my kernel image and inbetween a new d-i built
[19:21] <mnabil> cjwatson, the live cd is without autologin , i need it to login to for example 'ubuntu' and the run the script
[19:22] <cjwatson> mnabil: so you want to put it into the GNOME session?
[19:22] <cjwatson> mnabil: the live CD that *we* ship does autologin; if yours doesn't, then you must have broken something
[19:22] <mnabil> cjwatson, i dun have any GUI installed in the live cd , it gives only a console login
[19:23] <cjwatson> mnabil: we set up autologin on the console too
[19:23] <mnabil> cjwatson, cool, it has already autologin , but i  just wanna script after autologin
[19:23] <mnabil> *wanna run
[19:23] <cjwatson> "want to"
[19:24] <cjwatson> mnabil: perhaps you should create an init script with a symlink to it somewhere in /etc/rc2.d/ that runs whatever you want to run
[19:24] <mnabil> cjwatson, k, "wanna run " :)
[19:24] <cjwatson> mnabil: you don't have to log in for that; init scripts run as root, and if you want to you can drop privileges
[19:24] <allquixotic> Anyone know if UXA will be enabled by default for Intel cards in Jaunty GM? The 2D performance difference is night and day between EXA and UXA with the Xorg/Mesa/DRI stack used in Jaunty.
[19:25] <cjwatson> allquixotic: Bryce has been investigating it, but at the moment it's very unreliable on all but a few cards
[19:25] <mnabil> cjwatson, thanks alot :)
[19:25] <cjwatson> allquixotic: https://wiki.ubuntu.com/X/UxaTesting
[19:26] <allquixotic> cjwatson: Cool. I haven't had a single graphics system related crash and I've been running it for days on a GM965. If it can't be stabilized on all Intel chips, I would want to advocate either a whitelist, a blacklist, or at _least_ a Release Note documenting how to enable it for people who've got the right card(s).
[19:26] <bryce> allquixotic: at this stage it's simply too unstable.  I've emailed keithp and jesse for advice on either improving performance on EXA or improving stability on UXA, but no reply so far.
[19:27] <bryce> allquixotic: look at the url cjwatson posted; there isn't a strong enough correlation to stability and chipset to warrant black/white listing.
[19:28] <bryce> allquixotic: I'm not comfortable listing it in release notes at the current level of (in)stability
[19:29] <bryce> allquixotic: if you would like to help bring UXA up to a point where we can consider it more strongly, I would love having your help in upstreaming the UXA bugs filed against xserver-xorg-video-intel
[19:29] <allquixotic> bryce: Interesting reports in the wiki. The only complaints on any 965 (Crestline) based hardware are that it crashes after resume (and I can't reproduce that), and that it has font issues
[19:29] <bryce> that is currently the gating issue
[19:29] <allquixotic> but the font issues is something like: you minimize Firefox, and for a split-second you see partially rendered window contents as it's coming up
[19:29] <allquixotic> that's minor, I wouldn't even call that a defect, really
[19:29] <bryce> allquixotic: I've seen freezes on 965 as well
[19:29] <allquixotic> Have you? Under what situations?
[19:30] <allquixotic> I've been running it fully loaded on a ThinkPad X61T, uptime 3 days, suspend/resume every few hours, OpenGL 2.1 games, tons of Firefox tabs,...
[19:30] <allquixotic> only crash I had (3 days ago) was Cisco VPN related, not graphics
[19:31] <bryce> allquixotic: also there are only *4* test cases listed there for 965; hardly what I'd call a definitive sampling.  I'd like to see more 965 cases first.
[19:31] <allquixotic> bryce: I will add an entry to the wiki with my findings (very very positive performance-wise, and no stability issues whatsoever) and I might try to reproduce others' problems for the sake of either resolving the bugs if they're valid, or figuring out a different root cause (user could be mistaken about what's causing their woes)
[19:32] <bryce> allquixotic: of the 4 cases, 1 reports freezing, 2 report crashes.  I think you're crazy concluding that there are hardly any stability problems there!
[19:32] <bryce> ;-)
[19:33] <allquixotic> I'm just worried that user testing and reporting problems is a bit slippery because some of their claims of graphics-related issues could be related to other subsystems. My intent would be to get more info from the reporters and try to determine _whether_ their concerns are indeed graphics related.
[19:38] <cjwatson> allquixotic: well, on this 965 system (exact same PCI ID as others that claim to work to a greater or lesser extent), I get a startup sound but a black screen on boot; the system is fine with whatever the default acceleration method is, AccelMethod is precisely the only change
[19:38] <cjwatson> so I can't say I'm terribly impressed so far
[19:38] <allquixotic> cjwatson: Is it a desktop, or a laptop?
[19:38] <cjwatson> laptop
[19:38] <allquixotic> What architecture and how much RAM?
[19:39] <hwilde> so anybody have a good tool to view cpu load per thread for multithreaded apps ?
[19:39] <cjwatson> allquixotic: FWIW, the testing on that page is mostly from developers (albeit not X developers), so they should generally be well-practised at distinguishing issues
[19:39] <cjwatson> allquixotic: i386, 1GB
[19:39] <allquixotic> cjwatson: So you're using the -generic flavored kernel and not server?
[19:39] <cjwatson> allquixotic: yes
[19:40] <allquixotic> Ok. I was just checking -- currently the DRI2/UXA stuff is very broken with PAE
[19:40] <directhex> hwilde, htop i think
[19:40] <directhex> wait, per THREAD? no idea
[19:40] <hwilde> yaeh exactly :/
[19:40] <allquixotic> So even if we did have a whitelist, it would have to be for either i386/4GB, or x86_64
[19:41] <hwilde> directhex, there has to be some way to figure out which thread is cpuing tho ...  i can't be the only one to ever need to debug this
[19:41] <allquixotic> cjwatson: I'm on a GM965 laptop myself, but I'm using x86_64... Much of the code involved _is_ architecture dependent, so maybe that is part of your issue
[19:41] <cjwatson> I'm sure it may be, but I'm on a very common configuration here so I think that is relevant input
[19:42] <cjwatson> code that only works on amd64 is slightly more use than a chocolate teapot, but not really enough to get enthusiastic about :-)
[19:42] <directhex> who uses fringe arches like m68k and i386? o_o
[19:42] <kees> cjwatson, Keybuk: it seems this patch broke usplash for some people: http://people.ubuntu.com/~kees/usplash-testing/sig.patch
[19:43] <kees> cjwatson, Keybuk: any idea why?
[19:43] <allquixotic> cjwatson: Of the entries for PCI ID 8086:2a02 (GM965 Crestline), there is one mixed (bryce), two negative, and two positive. I think I'd like to start with reaching seb128 to debug why it crashed for him on resume, as that's definitely not the case here
[19:43] <kees> drawing is external to the alarm handler now, so it didn't look like those were needed any more
[19:44] <cjwatson> allquixotic: count me as negative for the same ID
[19:45] <allquixotic> seb128 and portis25 didn't file launchpad bugs associated with their negative reports...
[19:45] <allquixotic> or they didn't link them
[19:46] <cjwatson> kees: I'm not sure, but what's the cost of just reverting it?
[19:46] <bryce> allquixotic: thanks for your look at investigating these problems.  Getting seb128's issue captured in a bug report and forwarded upstream would be a good step
[19:47] <cjwatson> I'll file one later, but had better upgrade first
[19:47] <kees> cjwatson: none, it's already going into the archive.
[19:47] <bryce> (cjwatson: your blank screen issue might be the usplash issue kees is presently uploading a fix for)
[19:47] <kees> cjwatson: I just wanted to see if there was some general knowledge in this area I was missing.
[19:48] <cjwatson> bryce: could be, but it doesn't happen with EXA
[19:48] <cjwatson> and usplash itself displays fine
[19:48] <allquixotic> bryce: I was a GM945 laptop owner for 2 years, and almost a full year of GM965 torture... I regularly grab git master from upstream and test things out when Ubuntu isn't on the forefront; I was testing GEM and nagging upstream on crashes when we were still using the grand old aperture rendering mode
[19:48] <allquixotic> So this is very familiar territory to me
[19:49] <bryce> cjwatson: yeah usplash was displaying fine for me, but I could confirm that removing it from the kernel boot line made the issue go away
[19:49] <cjwatson> I see, OK
[19:49] <bryce> cjwatson: OTOH pitti is seeing a similar blank screen issue for which usplash has been ruled out
[19:49] <cjwatson> look, EXA's performance is certainly dreadful at the moment; I just think we should be ironing out a few more problems and *then* talking about making it the default
[19:49] <bryce> allquixotic: excellent, thanks for your help!
[19:49] <cjwatson> just seems like we're putting the cart before the horse a little bit
[19:50] <bryce> allquixotic: fwiw, I too have been very impressed at the performance improvement for UXA, but as X maintainer would like to see the overall stability significantly improved before I'm really comfortable supporting it (even for limited numbers of chips)
[19:50] <allquixotic> my experience is that Zhenyu Wang at Intel is one of the guys assigned to hack on stable, whereas the others are variously working on master, one of the in-development feature branches, or occasionally, stable
[19:50] <allquixotic> so maybe we could also bug him for help
[19:51] <bryce> I am also uncertain I want to support EXA on some chips, and UXA in some others, since that makes twice as much work to manage :-)  (and we already have plenty of bugs against -intel as it is)
[19:51] <allquixotic> going on sheer frequency and content of commits, Zhenyu puts a lot of work into the stable branches of xf86-video-intel
[19:51] <bryce> yep
[19:51] <allquixotic> oh, another relevant data point we need to collect about _any_ -intel problems
[19:52] <allquixotic> is a compositing window manager enabled or no?
[19:52] <bryce> I really wish they had more engineers supporting the stable release.  they seem to pump out releases with what seems like limited amounts of testing (esp. against 8xx chips)
[19:52] <allquixotic> some problems manifest only with, or only without compositing... helps narrow the hunt for upstream, if nothing else
[19:52] <cjwatson> (no, in my case, but not really relevant since the black-screen is at gdm)
[19:52] <bryce> hmm
[19:53] <allquixotic> I think Intel is trying to unofficially deprecate the 8xx chips. I mean, they're old, and using all this transparency and compositing "with" those cards basically throws a large amount of work at the CPU instead... and the associated CPU with an 8xx chip is not going to be stellar either
[19:53] <allquixotic> they support them in spirit, but in practice, their work is gonna go at the latest cards
[19:53] <allquixotic> Nvidia does the same
[19:53] <bryce> that's fine, but it doesn't help us
[19:54] <bryce> a huge chunk of our bugs in -intel launchpad are 8xx stuff
[19:54] <allquixotic> has there been consideration of dropping "official support" for 8xx according to Ubuntu's hardware compatibility list?
[19:55] <bryce> allquixotic: but you're right at Intel's focus; it seems almost not worthwhile to bother forwarding the 8xx bugs.
[19:55] <allquixotic> if not now, definitely in the future that will be something to consider
[19:55] <bryce> allquixotic: I think many people would be upset by that
[19:55] <allquixotic> but unless we want to have 8xx cards load xf86-video-vesa and use DRI's swrast....
[19:56] <bryce> allquixotic: Ubuntu targets educational use cases which have old hardware, as well as server use cases where on-board graphics is not unusual to be 8xx based
[19:56] <allquixotic> if upstream won't fix it, and Canonical doesn't have Intel hardware gurus...
[19:56] <allquixotic> what's to be done?
[19:56] <bryce> yeah I know
[19:56] <bryce> we need community people to step up to the plate, as happens with -ati, -nv, -nouveau, -radeonhd, etc.
[19:57] <allquixotic> -vesa and swrast will always be an "option" to get them a display, but losing 3d rendering because upstream is offering features that are too new for old hardware to support -- where the hardware could do basic 3d just fine in previous releases - is a serious regression
[19:57] <bryce> -fglrx drops support for old chips, but -ati still supports them going all the way back
[19:57] <allquixotic> and I've always been an advocate of software NOT standing in the way of functional hardware for any reason
[19:58] <bryce> true, although a number of the 8xx bugs are even more basic than 3d... like just booting X
[19:59] <bryce> allquixotic: I told Intel (well, jesse) that as a minimum if they do proceed with dropping support for more 8xx chips, that they need to first release docs for the chips, so the community has all they need to do support
[19:59] <allquixotic> well, for now, the best I can do is bring bugs to the attention of upstream, and try to provide focused, verified bug reports... unless the bug is very basic and easy to spot in code... I'm a systems programmer, but I haven't done hardware interface hacking before, either in userspace or kernel
[19:59] <bryce> dropping official support without releasing register documentation ----> FAIL
[20:00] <allquixotic> and I'm sorry to say I can't help at all with the 8xx stuff because I don't own an 8xx
[20:00]  * bryce nods
[20:00] <bryce> yeah same here, just ranting...
[20:00] <allquixotic> they haven't released register docs on 8xx?!
[20:00] <allquixotic> wow.
[20:01] <allquixotic> have they done it for the 915+ chips?
[20:07] <allquixotic> bryce: If upstream were to make a new release, when would be the cutoff for pulling it into Jaunty?
[20:07] <allquixotic> Would be nice to see if Intel pushes 2.6.2 or so to help with these issues
[20:07] <bryce> I would be willing to pull a 2.6.2 even up to beta
[20:08] <bryce> although alpha-6 would probably be the latest I'd be willing to consider defaulting on UXA
[20:09] <bryce> but even that is pushing it pretty late to get adequate testing
[20:10] <allquixotic> bryce: Can we do something similar to what Fedora does with "preview" features, if we can't enable by default? They include it, and mention it, but disavow support etc for those who enable it...
[20:11] <bryce> I guess, what specifically do you have in mind?
[20:12] <bryce> allquixotic: what I want to avoid is that it seems Intel frequently puts out a new tech that is advertised as solving a whole mess of issues, but has lots and lots of regressions, and then they stop giving support for the older tech
[20:12] <bryce> so we get left between the choice of two buggy options, and -intel users find themselves hating the world
[20:13] <allquixotic> bryce: IIRC, Fedora basically discussed Kernel Mode Setting (a different feature, but the same process applies) in Fedora 9 - for ATI - and they told people how to enable it, but turned it off by default
[20:13] <bryce> often we move to the newer tech with the hope that soon upstream will fix all the remaining issues soon enough, but often that doesn't quite happen
[20:14] <allquixotic> bryce: OTOH, I really like the Intel performance on 8.10 :) The -intel desktop experience isn't bad on my mom's GM945 with metacity compositing
[20:14] <bryce> indeed we're still waiting on some issues from the XAA -> EXA issue, and already upstream is moving EXA -> UXA ;-)
[20:14] <allquixotic> I think whatever you went with for 8.10's stack was a win in terms of performance
[20:14] <allquixotic> features, maybe not, but it's silken smooth for Firefox surfing
[20:15]  * ScottK tosses in a grumble about compiz hacks that break other WM.
[20:15] <allquixotic> I see your point about Intel's ever-evolving stream of unstable innovations, and at some point the innovation itself needs to turn toward stability and performance
[20:15] <allquixotic> I have a gut feeling that the GEM/DRI2/KMS plateau will be a point of significant stabilization and performance
[20:16] <allquixotic> but if I were an Intel developer and I have a schedule to (for example) get KMS "ready" by Q1 2009, I would be focusing on dealing with issues related to having the entire feature set enabled
[20:17] <allquixotic> which means that 9.04's feature set becomes the ugly duckling that lacks KMS, and half the Intel guys haven't touched that path for weeks
[20:17] <bryce> here's one UXA bug - 322356
[20:18] <ogra> cjwatson, are there chances that the nslu2 d-i initrd.gz could grow over 4M (its 3.3 currently) i think i found our issue in debian bug 451882
[20:18] <ogra> seems they raised the ramdisk size to 6.2M ... that cuts down the available kernel space to less than 2M
[20:19] <allquixotic> bryce: CONFIG_HIGHMEM64G implies PAE. Intel has been "loudly" proclaiming that users should not try to use UXA with that configuration
[20:19] <allquixotic> So that bug is a "known; being worked high priority" as far as I am aware. Could be ready for 2.6.2, who knows
[20:19] <bryce> allquixotic: ok, can you update the bug to that effect?  If you can include a url to the official statement from them on that, it would help.
[20:19] <allquixotic> it was on the ML, let me dig
[20:19] <bryce> or a link to an upstream bug report would be nice
[20:24] <allquixotic> bryce: Updated
[20:24] <allquixotic> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/322356
[20:24] <bryce> allquixotic: thanks
[20:42] <ryu> hi
[21:05] <LaserJock> slangasek: you around?
[21:05] <slangasek> LaserJock: hi
[21:07] <cjwatson> ogra: hard to say for sure, but I'm sure you could take it back down a bit
[21:08] <cjwatson> hmm, now I get the black screen with EXA too. blast. I'll try with new usplash tomorrow
[21:10] <ebroder> Does anyone know if I can find the git repo for Ubuntu's xserver-xorg-video-ati changes? (I'm trying to track down LP bug #289026)
[21:11] <ebroder> (X fails to start on Radeon HD 2400 Mobility (Ubuntu 8.10 RC)) since ubottu didn't find it)
[21:17] <maxb> Hmm, I just had to do a "Partial upgrade" rather than a normal update-manager run - shouldn't libgpod4 declare "Replaces: libgpod4-nogtk" ?
[21:19] <bryce> ebroder: there is no git repo for -ati
[21:19] <bryce> ebroder: use upstream's git repo for -ati
[21:20] <bryce> ebroder: or look in the xserver git repo (directions for X git usage at http://wiki.ubuntu.com/X/)
[21:20] <bryce> heya Rocket2DMn
[21:20] <ebroder> bryce: Ok. What are your thoughts on trying to track down this particular bug for an SRU? Should we work on the backport instead?
[21:21] <Rocket2DMn> hey bryce
[21:25] <bryce> ebroder: a backport is more likely to go through
[21:25] <bryce> ebroder: however if you can identify a sufficiently minimal patch that can be shown to have no regression risk, then maybe an sru would be doable
[21:26] <ebroder> bryce: Yeah....that, uh, sounds kind of hard. I think I'll probably work on the backport
[21:27] <bryce> sounds goo
[21:27] <bryce> +d
[22:38] <cjwatson> jelmer: I'm trying to GPG-verify your subvertpy sync, but the key used to sign it (060F66E5) doesn't seem to be on the keyservers
[22:38] <cjwatson> jelmer: could you please push it somewhere?
[22:39] <jelmer> cjwatson, it's a subkey that's on my main key (1EEF5276)
[22:39] <cjwatson> ah. funny that subkeys.pgp.net didn't return it
[22:40] <cjwatson> oh, drat, something weird with the firewall
[22:41] <cjwatson> ok, got it now
[22:53]  * ogra gives up in desparation ... 
[22:54] <ogra> :(
[22:55] <Moe> Hello ..
[22:55] <Moe> I'm wondering if pitti is around
[22:56] <Moe> alright, doesn't seem to be the case
[22:56] <Moe> good night
[23:01] <directhex> Moe, pitti occasionally lets his feeble human side show, and succumbs to his biological need to sleep. the plan is to patch that out in the next beta
[23:05] <cjwatson> OTOH, directhex sometimes forgets to read part messages ;-)
[23:06] <directhex> cjwatson, i saw he parted, but decided my reply was too damn good to go unbroadcasted
[23:44] <Caesar> Should I discuss Hardy backport requests here, or in another channel?
[23:52] <maxb> Caesar: Depends whether it's main or universe I guess.
[23:53]  * Caesar checks
[23:54] <Caesar> All three are in universe
[23:55] <maxb> #ubuntu-motu then
[23:55] <Caesar> righto
[23:55] <Caesar> thanks
[23:55] <maxb> (I think)