[00:15] <calc> cjwatson: cool :)
[00:15] <calc> yipee i managed to get OOo to properly build under intrepid now
[01:09]  * milli applauds calc
[01:54] <mathiaz> slangasek: I'm about to upload the openldap merge from debian - considering that the package has been renamed from openldap2.3 to openldap, is there anything to special to do in LP ?
[01:54] <slangasek> mathiaz: hum, the QA folks might have a better idea in that regard than I do; I think they dealt with the similar case of the linux package renames
[01:55] <slangasek> mathiaz: I imagine that all the bugs with open intrepid/openldap2.3 tasks should also have tasks opened for openldap/intrepid, but the doing is tedious without some script help :)
[01:55] <mathiaz> slangasek: I was planning to move all bugs related to openldap2.X package to openldap
[01:55] <slangasek> right, then that's the only special thing I can think of
[01:55] <mathiaz> slangasek: well - there aren't so many of them
[01:55] <slangasek> ok
[01:55] <mathiaz> slangasek: I was more thinking about soyuz
[01:56] <slangasek> nah, we just need to be sure to remove the package as obsolete after openldap has gone through source NEW
[01:56] <slangasek> feel free to file a bug to that effect and subscribe ubuntu-archive
[02:06] <calc> how do you properly branch from bzr.d.o to launchpad?
[02:07] <calc> do i just go into a bzr.d.o checkout and push it to lp?
[02:10] <slangasek> calc: sounds right to me...
[02:11] <calc> ok thanks
[02:11] <calc> i get this error:
[02:11] <calc> bzr: ERROR: Transport operation not possible: http does not support mkdir()
[02:12] <calc> should i be doing something special other than "bzr push lp:~openoffice-pkgs/openoffice/3.0-intrepid"
[02:13] <slangasek> hmm, is your launchpad user ID configured?
[02:13] <slangasek> 'bzr launchpad-login'
[02:13] <slangasek> (I don't know if that makes a difference in how lp: uris are parsed, but it's worth a try)
[02:14] <calc> it seems that using the bzr+ssh bit works but not sure if i have launchpad-login setup right
[02:14] <calc> my local username and lp match though
[02:34] <cjwatson> Lrrr: debian/changelog entries would be appreciated
[02:35] <cjwatson> Lrrr: also would prefer newline-indent after colon as a general rule, rather than packing onto one line
[02:37] <cjwatson> Lrrr: the ".It Fl o Fl Fl output-directory" bit in the man page is wrong formatting - see germinate.1 for examples of how to do that properly (search for .It Xo)
[02:38] <cjwatson> Lrrr: expect I'd be happy to merge after those fixes
[02:44] <Lrrr> cjwatson: noted, I'll fix that tomorrow.
[03:26] <jdong> hmm, anyone know of bug #'s for USB HID devices not working in initramfs
[03:26] <jdong> my macbook internal keyboard is USB, and it's annoying that it doesn't work in initramfs
[03:26] <jdong> i.e. where my encryption passphrase needs to be entered
[03:27] <RAOF> Oh, awkward.
[03:27] <jdong> after udev starts post-rootmount it works, and also one of 3 boots work
[03:27] <jdong> I think it must be a race condition where upon activating the USB bus the keyboard doesn't connect for a second or two
[03:27] <jdong> just enough to miss the point that udevsettle is done during initramfs
[03:27] <jdong> *considers hacking some sleep calls*
[03:28] <jdong> is there a way to inject a premount command rather than dropping to a prompt? break=premount does me no good if I can't actually type anything :D
[03:29] <ion_> Hack /usr/share/initramfs-tools/scripts/init-premount and update-initramfs -u
[03:29] <jdong> well.... that actually requires a livecd so I can have a working keyboard AND a decrypted / :D
[03:30] <jdong> oh well, weekend project
[03:31] <ion_> So, a prompt is shown, but for some reason the keyboard doesn’t become available because it’s discovered after udevsettle? That sounds a bit strange. You’d still expect udev to load the module and the keyboard to start working.
[03:31] <ion_> Are the necessary modules installed to the initramfs for sure?
[03:31] <jdong> right, the symptoms are exactly as you state
[03:32] <jdong> except one of every 3 or so boots, it actually works
[03:32] <ion_> Huh.
[03:32] <jdong> something racy seems t be taking place
[03:32] <jdong> whether that's because of initramfs, or by luck legacy peripheral emulation is still active by apple BIOS emulator...
[03:33] <jdong> the HID modules are definitely in initramfs
[04:04] <TheMuso> jdong: I guess the best way to track that one down is to boot into the initramfs with debugging enabled.
[04:38] <bluefoxicy> BenC:  hey
[04:40] <bluefoxicy> I guess Alpha 2 isn't out yet
[04:41]  * bluefoxicy found some flaws with the current implementation of compcache, but isn't sure the exact impact; thinks it's still overall positive
[04:42] <ion_> What kind of flaws?
[04:42] <ion_> Other than that the newest version (the one that is in the Ubuntu kernel) seems to like to crash on my box. :-)
[04:42] <bluefoxicy> ion_:  Well I haven't been in ANY code for a while, much less kernel code; but at a glance I don't like the memory eviction policy, mainly.
[04:42] <ion_> 0.3 didn’t.
[04:44] <bluefoxicy> lemme get the current code
[04:44] <BenC> bluefoxicy: hey
[04:44] <bluefoxicy> Hi BenC :)
[04:44] <bluefoxicy> (isn't this particular issue assigned to you?)
[04:45] <bluefoxicy> http://code.google.com/p/compcache/source/browse/trunk/compcache.c is what I'm looking at.
[04:46] <bluefoxicy> Lines 185-193 seem to handle freeing a page... which basically entails, "If the kernel just wrote a NEW memory page to that spot in the swap device, then the old one was probably gotten rid of ages ago, so we can safely free it from memory now"
[04:47] <bluefoxicy> so, let's say you kill -9 a process that uses, say, 1000 pages (4MB) of the compcache device for swap?  Those pages will remain in memory, compressed, until something else swaps out overtop of them
[04:48] <bluefoxicy> It makes sense for disk based swap devices:  when you free a page you just note it's no longer used in kernel memory.  The disk doesn't know or need to know about this.  Compressed cache does need to know, but doesn't.
[04:50] <bluefoxicy> I'm GUESSING the impact is going to be that long term usage will cause a chunk of memory to get tied up needlessly; but that it will still be an improvement over not having it.  There's a "worst case" that just simply fills up the compcache device and doesn't use it ever again; I think this WILL occur if the compcache device doesn't have the highest priority (i.e. if you favor filling up a disk-based swap device first, and e
[04:50] <bluefoxicy> nd up spilling over into compcache)
[04:52] <persia> Doesn't the very nature or compcache encourage using it as highest-priority swap?  "disk" i/o is likely to be slower, even when the "disk" is in fact SDRAM.
[04:52] <bluefoxicy> persia:  yes it does.
[04:53] <bluefoxicy> persia:  the very nature of compcache actually encourages it to be an intermediary cache though, i.e. CPU registers > L1 > L2 > L3+ > RAM > compcache > disk swap
[04:54] <bluefoxicy> however, it's lumped in as a disk swap; you'll fill up compcache and then start putting further pages on disk, instead of pushing them out of compcache under the observation that they really haven't been used in a long time (LRU policy on compcache would be more optimal)
[04:54] <persia> Hmm.  Makes sense.  Might be a slot for VRAM swap in there at some point, but that's not heavily used (and compiz discourages it).
[04:55] <RAOF> As far as I'm aware, any form of graphics acceleration discourages it (at least the naieve implementation I've seen on the gentoo wiki)
[04:55] <bluefoxicy> I've actually got a small list that I sent to Nitin; but the eviction issue seems important to me just because you could seriously bone yourself by adding compcache as lowest priority swap
[04:56] <bluefoxicy> other issues included it not being an intermediary cache; compressing one page at a time (the sweet spot, based on tests I did years ago, was groups of between 4 and 8 pages); and not compressing page cache (which effectively "swaps" against the on-disk copy of the data)
[04:58] <ion_> The initramfs stuff for compcache uses -p 100, as well as the compcache-setup package waiting in REVU. I’m not sure users are going to manually swapon it, forgetting to use a high priority. That doesn’t mean the issue is not there, of course.
[04:58] <persia> RAOF: I thought there were some better implementations sorted, but it does require that you've lots more VRAM than you need, and most graphics accelleration wants local textures.
[04:58] <pwnguin> am i crazy, or is this arizona package manager vuln wrong on the details?
[04:59] <bluefoxicy> ion_:  nods.  With it being the first device used, it's a gain over not having it; however, do note that when you fill it up and then "empty" it, it's still holding a chunk of RAM as used, so you'll start swapping to it earlier than you need to.
[04:59] <ion_> Yeah
[04:59] <bluefoxicy> IN THEORY this is PROBABLY not an issue, since that particular operation is cheap.
[05:00] <bluefoxicy> aside from effectively decreasing the amount of physical ram available to things like page cache, which aren't swapped out
[05:03] <pwnguin> Question: does HTTPS really matter for the official -security repo?
[05:04] <foka> freeflying, Hi!
[05:04] <bluefoxicy> pwnguin:  you can MiM stuff and replace packages, but they're signed.
[05:04] <freeflying> foka: hi
[05:04] <bluefoxicy> so I don't really think so :P
[05:04] <foka> freeflying, I think I'm a REVU now.  So, I can already upload packages directly?  What's the procedure?
[05:04] <pwnguin> thats what i was thinking; you dont need an https cert when the metadata and packages are gpg signed themselves by the repo
[05:05] <freeflying> foka: #ubuntu-motu
[05:06] <pwnguin> unless you think https itself is safe but apt-get or gpg is not...
[05:06] <foka> freeflying, Go there?  :-)
[05:06] <freeflying> foka: yes
[05:06] <pwnguin> granted, the author does point out that apt will happily fill your filesystem if the other end just sends you /dev/random
[05:09] <pwnguin> well, at least the paper is intelligent
[05:43] <philsf> does ubuntu releases point releases in a fixed schedule, or when updates get big enough (or the min of those)?
[05:44] <slangasek> point releases for LTS releases are scheduled in advance
[05:45] <slangasek> for 8.04, they're planned at 6-month intervals
[05:45] <philsf> I thought it was strage that https://wiki.ubuntu.com/HardyReleaseSchedule ends at the just release .1
[05:46] <philsf> so the next is due Jan09, right?
[05:49] <slangasek> approximately, yes
[05:49] <slangasek> it hasn't been scheduled precisely yet
[05:50] <philsf> fair enough, thanks for the info
[05:53] <bluefoxicy> yesterday's Intrepid Alpha 2 release is also approximate
[05:54] <ionstorm> was it released?
[05:54] <bluefoxicy> not as of a couple hours ago <_<;
[05:54] <bluefoxicy> or if it was I sure as hell can't find it
[05:58]  * persia comments that the definition of "yesterday" is geographically variable
[05:59] <persia> Someone in UTC +10 and someone in UTC -8 might have very different views of when Thursday happens.
[06:00] <slangasek> it's not released yet because we haven't been getting ISO tests in
[06:00] <slangasek> so it's slipping a day; email to u-d-a will be sent soon
[06:01]  * bluefoxicy somehow tempted to use compcache for a file system, since it doesn't have any code that prevents it from being used as a plain old block device.
[06:02] <bluefoxicy> persia:  where is sabdfl?
[06:03] <bluefoxicy> and is it still thursday there :)
[06:13] <persia> bluefoxicy: Unfortunately, it appears that shoes have been changed since I last emplaced a microdot transmitter: I can't answer that with any confidence.
[06:13] <bluefoxicy> lol
[06:15] <gnomefreak> i guess X is still having issues after i installed nvidia-glx-173 and now i cant get a X session after using nvidia-config
[06:22] <gnomefreak> nevermind its fixed so far
[06:35] <dholbach> good morning
[07:10] <dholbach> hi ara
[07:10] <ara> hey dholbach
[07:34] <pitti> Good morning
[09:21] <asac> pitti: ffox 3.0.1 / xul 1.9.0.1 require your approval ;) (hardy-proposed)
[09:21] <pitti> noted
[09:22] <asac> security-updates through -proposed, yay!
[09:28] <pitti> thekorn: hm, p-lp-bugs broken again, on BugReport.__nickname parsing; known already?
[09:29] <thekorn> pitti: yup, working on it, bug 247498
[09:29] <pitti> thekorn: great, thanks
[09:30] <stgraber> Who broke my fglrx ? :)
[09:30] <pitti> cjwatson, thekorn: btw, any idea about the difference of the main and intrepid.merge branches? someone flipped the default branch to intrepid.merge on drescher
[09:30] <stgraber> I had to spend half an hour and 3 hard reboot to get a working X server again :)
[09:30] <pitti> stgraber: hardy or intrepid?
[09:30] <stgraber> intrepid
[09:30] <pitti> *phew*
[09:31] <stgraber> don't worry, Hardy works fine (including suspend to ram) :)
[09:31] <pitti> thekorn: oh, nice, that looks like test suite output
[09:32] <pitti> thekorn: ok, then I'll just wait with sync processing until it is fixed
[09:32] <thekorn> pitti: yes, py-lp-bugs now has some unittests
[09:35] <ondrej> hi ppl, while it's fine that you removed edgy from mirrors (hmm, what about announcement?), there should be a way how to download update-manager-core for edgy, so people can upgrade long forgotten servers.
[09:36] <persia> ondrej: old-releases.ubuntu.com
[09:36] <pitti> ondrej: edgy and others are still on old-releases.ubuntu.com
[09:37] <pitti> ondrej: also, why do you need u-m for edgy? you certainly don't want to upgrade a dapper to edgy, you want to upgrade it to hardy...
[09:37] <ondrej> pitti: I have server on edgy and it's stuck because I cannot download d-r-u
[09:37] <pitti> d-r-u?
[09:38] <ondrej> do-release-upgrade
[09:38] <ondrej> ie. update-manager-core
[09:38] <pitti> hm, weird; I had always thought that update-manager would download the tarball for the target release
[09:39] <ondrej> it propably would, but since it was minimal install I don't have update-manager{,-core} installed at all
[09:40] <persia> ondrej: http://old-releases.ubuntu.com/ubuntu/pool/main/u/update-manager/ (I don't think -core was split out back then)
[09:41] <ondrej> persia: sure, thanks...  I can handle it from now...  I was just trying to explain problem in more detail (and I will update FeistyUpgrades wiki page to mention that)
[09:41] <persia> ondrej: Thanks for updating the documentation
[09:46] <ondrej> persia: just FYI: update-manager-core is available for edgy
[09:49] <persia> Odd.  I wonder why it wasn't in the same pool directory.  Maybe something special about that package.
[09:54] <ondrej> persia: I think it wasn't part of the same source back then...  anyway this upgrade is non-trivial, you have to change old-releases to archive in sources.lists in the middle of do-release-upgrade script.
[10:02] <ondrej> ok, done, upgraded to feisty, thanks to all
[10:03] <pitti> wonderful
[10:03] <pitti> oh, gone already
[10:10] <slytherin> Can any archive admin please clear xml-commons-external from new queue? An update to batik is dependent on it.
[10:12] <pitti> I'll get to NEW processing in a bit
[10:13] <slytherin> pitti: thanks. :-)
[10:14] <mdz> why does compiz suddenly think it would be a good idea to map my mouse wheel to switching workspaces?
[10:20] <tseliot> ﻿mdz: Compiz does it on Hardy too, when you have the mouse cursor on an empty area of the desktop and use the mouse wheel.
[10:22] <mdz> tseliot: this was on top of firefox
[10:22] <mdz> but I can't seem to reproduce it now
[10:22] <mdz> it was very surprising though
[10:23] <thorwil> mdz, sure you didn't hover the workspace switcher?
[10:23] <mdz> thorwil: yes
[10:23] <mdz> hovering over the switcher doesn't seem to do that when I try it
[10:23] <pitti> ^ that WFM in metacity
[10:23] <mdz> ahh, the keypad state on my keyboard was activated
[10:24] <pitti> (compiz doesn't want to start on -intel apparently ATM)
[10:24] <slangasek> s/start/be useful/?
[10:24] <thorwil> mdz, maybe some modifier-key -weel combo?
[10:25] <pitti> well, whatever it thinks; I just get metacity
[10:25] <slangasek> ah; I thought you meant the bug that I'm seeing here, which is that compiz doesn't fall back to metacity, I just get a blank screen in intrepid
[10:25] <slangasek> (installer testing)
[10:26] <pitti> does anyone know why so many linux-{,headers,image,restricted-modules}-$FLAVOR metapacakges are NBS?
[10:26] <pitti> linux-meta only builds a small subset of the former hardy set
[10:26] <slangasek> because the kernel team has split everything out of the main package
[10:26] <pitti> is that on purpose?
[10:26] <stgraber> tseliot: just wondering, there is currently no fglrx driver working with 7.4 right ?
[10:27] <slangasek> it's on purpose, though I still wonder about the wisdom of it seeing how none of those other packages have gotten done yet
[10:27] <tseliot> ﻿stgraber: no, the xserver broke the ABI compatibility
[10:27] <pitti> slangasek: ATM I'm not sure whether I should kill those NBS or not; I left them last week, and I'm inclined to leave them today, too
[10:27] <slangasek> pitti: yes, I was about to say I think they should be left where they are as a pointed reminder
[10:28] <slangasek> and perhaps we should schedule some time next week to sync up with the kernel team about exactly whose responsibility it is to recover those other packages, so we know who to bug
[10:28] <stgraber> tseliot: ok, so that'll be radeonhd and hoping ATI's next driver will include Xorg 7.4 support :)
[10:29] <tseliot> stgraber: you can try something like this but success is not guaranteed http://www.linuxinsight.com/running-nvidia-display-drivers-with-xorg-7.3.html
[10:29] <tseliot> (to ignore the ABI, I mean)
[10:29] <soren> slangasek, pitti: At least amitk and myself will be taking care of getting the virtual and lpia builds going. I imagine we'll have our own meta packages as well.
[10:29] <soren> Next week, that is.
[10:29] <slangasek> ah, next week, that's good to know
[10:29] <pitti> slangasek: let's, yes
[10:30] <pitti> whoops, I forgot to actually cron the NBS script, doing
[10:30] <stgraber> oh, interesting option I'll give it a try and see how broken it'll be :)
[10:30] <stgraber> thanks tseliot
[10:33] <pitti> soren: virt-viewer wants to pull xen-3.1 into main, but main already has xen-3.2; I hope that can be fixed?
[10:38] <pitti> tjaalton, bryce: xserver-xorg-video-via source is in main, binary is in universe, -all depends on it; shall I promote the binary, or does -all need to be fixed?
[10:38] <mdz> thorwil: my keyboard is a kinesis and has a keypad lock (the numeric pad shares keys with the alphabetic keys)
[10:38] <mdz> thorwil: when that is activated, the mouse wheel switches workspaces
[10:39] <mdz> pitti: nvidia-glx-173 works fine for me, modulo bug 247523 and bug 247527
[10:40] <soren> pitti: Certainly.
[10:45] <cjwatson> pitti: I switched it to intrepid.merge because at the time that was what worked
[10:46] <pitti> Riddelll, nixternal: FYI, I removed the python-kde4 source, because it seems to be superseded by kde4bindings; however, python-kde4 is still in Debian; what's the plan for this?
[10:46] <cjwatson> pitti,slangasek: agreed, I've been avoiding removing those NBS packages too
[10:46] <thekorn> pitti: py-lp-bugs should be fixed now
[10:46] <pitti> thekorn: yay you
[10:49] <pitti> cjwatson: ok, I updated the main branch for this ^ and flipped back, since main works ATM (for syncbugbot anyway)
[10:52] <pitti> bryce, tjaalton: also, xserver-xorg-video-vga wants to go to universe; are we exclusively using -vesa as a fallback now? i. e. is this deliberate?
[10:52]  * pitti tries to reduce the insane size of component-mismatches a bit
[10:53] <cjwatson> pitti: ok, cool
[10:55] <tjaalton> pitti: -all should not depend on it anymore
[10:55] <tjaalton> and vga is dead
[10:55] <tjaalton> it's not included in X7.4 katamari
[10:55] <pitti> tjaalton: ok, so I demote vga, and wait with the -via demotion until -all gets fixed?
[10:56] <tjaalton> pitti: actually, you could just remove via, since it's deprecated upstream, and openchrome is the default anyway
[10:56] <tjaalton> there should be a bug about it too..
[10:56] <pitti> tjaalton: I just don't want to break installability of -all at this point (alpha 2 tomorrow)
[10:56] <tjaalton> via doesn't build against 1.5
[10:56] <pitti> unless you want to fix -all right now
[10:57] <tjaalton> it doesn't break it
[10:57] <tjaalton> openchrome | via
[10:57] <pitti> ah :)
[10:57] <tjaalton> :)
[10:57] <tjaalton> it will be removed completely in the next upload, but that shouldn't be necessary for alpha2
[10:57] <pitti> tjaalton: it's still in Debian, though; will someone file a removal bug there as well, or shoall I blacklist it?
[10:58] <slangasek> pitti: kdesudo-kde4 is missing from the kubuntu desktop images because it's a recommends and has yet to be promoted to main
[10:58] <slangasek> pitti: could we do a quick main promotion of it?
[10:58] <tjaalton> pitti: yes, they don't have the new stuff available yet
[10:58] <slangasek> (breaks ubiquity rather badly)
[10:58] <pitti> slangasek: yep, will do right now
[10:58] <tjaalton> pitti: so it'll get removed when 1.5 hits unstable
[10:59] <pitti> tjaalton: ok, removed; thanks
[10:59] <pitti> slangasek: kdesudo is already in main, so I guess the package should eventually just be renamed
[11:00] <slangasek> perhaps
[11:00] <slangasek> hrm, but kdesudo-kde4 installs its binary under /usr/lib/kde4/bin, what good is that supposed to do? :/
[11:01] <pitti> and kdesudo is still KDE 3 AFAICS
[11:01] <slangasek> yes
[11:01] <slangasek> anyway, kdesudo-kde4 is the one that's seeded, so I guess we should at least get that fixed for now
[11:01] <pitti> slangasek: kdesudo-kde4 hasn't been uploaded in intrepid yet, so I guess that simply needs some work
[11:02] <slangasek> pitti: well, I wonder how burying the binary in /usr/lib was ever supposed to work... it won't work for ubiquity, AFAICS
[11:02] <cjwatson> is there an equivalent in some other package? a lot of the -kde4 packages got replaced
[11:03] <pitti> Tonio_: do you have some insight wrt. kdesudo?
[11:03] <slangasek> I think the equivalent would be kdesudo, but that's the KDE3 version
[11:05] <pitti> how did it work in alpha1? or didn't that have kde CDs?
[11:06] <pitti> slangasek: so, kdesudo-kde4 is derived from kdesudo (one upload) with porting to kde4; I have no problem to quickly promote it at this point, but I have doubts that it will fix the problem?
[11:06] <slangasek> we didn't have desktop CDs
[11:06] <slangasek> pitti: correct, that alone won't fix the problem
[11:06] <cjwatson> we need a ubiquity upload anyway; I'm happy to do a quick path tweak
[11:06] <cjwatson> though I won't be able to test it
[11:07] <slangasek> cjwatson: /usr/lib/kde4/bin, then
[11:08] <pitti> promoted
[11:11] <pitti> lool, StevenK: hm, why does hildon-control-panel{,-l10n} want to go back to universe?
[11:12] <pitti> slangasek: ah, and rightfully kdesudo wants to go to universe; demoting that
[11:13] <pitti> StevenK: and libhildonhelp, too
[11:14] <pitti> in fact, half of the mobile stack is there
[11:16] <cjwatson> pitti: mobile has moved to separate seeds which LP isn't yet taking into account, which probably influences that
[11:17] <pitti> oh, I see
[11:17] <pitti> cjwatson: so component-mismatches is very misleading ATM then
[11:17] <pitti> I guess some of the demotions I just did were wrong them (some were correct, though)
[11:17] <cjwatson> yes, sorry :-/
[11:17] <pitti> s/them/then/
[11:17] <pitti> well, eventually they will pop back
[11:17] <cjwatson> just be careful about mobile things
[11:17] <lool> Hmm
[11:17] <pitti> yes, I didn't demote the obvious ones
[11:17] <ogra> dont we build mobile with universe enabled anyway atm ?
[11:18]  * ogra thought we did
[11:18] <lool> ogra: Ultimately we'd like to change this
[11:18] <cjwatson> ogra: the target is for that stuff to move to main
[11:18] <ogra> right, but for alpha2 it should be ok :)
[11:18] <cjwatson> I'll sort out a bug report about this in a bit - I'm knee-deep in ubiquity at the moment
[11:18] <lool> pitti: (StevenK is in holidays this week BTW°
[11:18]  * lool launches a rope to pull cjwatson out
[11:19] <ogra> asac, could you take a look at https://bugs.launchpad.net/cmpc/+bug/247478
[11:19] <ogra> i'm not sure what i should tell them
[11:20] <ogra> what they do there (playing with roaming mode on a wired connection) seems very weird
[11:23] <asac> ogra: err, if he turns of "roaming mode", then its not network manager anymore
[11:23] <asac> turns off
[11:31] <cjwatson> gar, crash on switch to vt
[11:36] <asac> ogra: the bug is quite hard to read. is that china?
[11:37] <ogra> yep
[11:39] <asac> ogra: what are they trying to achieve? static IP configuration?
[11:40] <asac> ogra: i dont understand why they "check roaming off" in step 2. and do the same in step 3. again :/
[11:40] <asac> i think either 2 or 3 should be "check roaming on"
[11:40] <ogra> hmm
[11:42] <ogra> now that i read it again i dont even understand point 1
[11:42] <asac> yeah ... what is a wired AP?
[11:42] <asac> a hub/router?
[11:42] <ogra> 1. Keep roaming mode enabled and plug in a network cable connected to an AP.
[11:42] <ogra> heh
[11:42] <ogra> they dont say *wired*
[11:43] <asac> ogra: does "click.Click unlock" mean: double click?
[11:43] <laga> maybe ask them for clarification?
[11:44] <ogra> asac, no, the dot ends the forst sentence :)
[11:44] <ogra> *first
[11:44] <asac> ah ;)
[11:44] <asac> ogra: i think they should make more steps out of it:
[11:44] <ogra> could you comment  ?
[11:45] <ogra> so they see that its valuable to use LP :)
[11:45] <ogra> istead of sending spreadsheets around :)
[11:45] <asac> ogra: valuable like: "i mark your bug as invalid" ;)
[11:45] <ogra> no, ask for more or vclearer info
[11:51] <asac> ogra: whats the name of the gnome network admin package again?
[11:53] <ogra> network-admin iirc
[11:53] <pitti> ogra: usb-imagewriter> why not add an option for an alternative output file? -o /tmp/test.img
[11:53] <pitti> ogra: hardcoding that upstream isn't nice either
[11:53] <pitti> ogra: also, please don't use shell=True, just split the args into components (trivial here); better for weird file names
[11:55] <ogra> pitti, ergh, that was fixed upstrem indeed it picks the device from the pulldown menu
[11:55] <pitti> ogra: I have to reject it anyway, I'll mail you
[11:55] <ogra> pitti, plan is to make dd go away completely
[11:55] <ogra> ok
[11:57] <pitti> (sent)
[11:58] <ogra> pitti, there is only one actual application file in there and that has a GPL header ... i thought that suffices
[11:58]  * ogra adds a general license ...
[11:58] <pitti> ogra: thanks
[11:59] <ogra> pitti,  and i suspect debian wouldnt be happy about the branding ;)
[11:59] <ogra> http://people.ubuntu.com/~ogra/ImageWriter/main.png
[12:00] <persia> ogra: That's loaded at runtime, no?  A sufficiently imaginative debian/rules ought be able to allocate the right branding :)
[12:00] <pitti> ogra: nice :)
[12:06] <ogra> pitti, dont wait for it ... just had a discussion with persia, we'll look at it next week at the sprint and rip out dd as well
[12:06] <laga> ogra: what's the replacement for dd?
[12:06] <laga> python magic?
[12:07] <ogra> no idea, persia has one we didnt discuss yet  (next week) .... but i would assume python, yes
[12:07] <_MMA_> ogra: That branding there actually needs a little help. :P I'll help if you want or tap kwwii. Unless he did that one. Then I'll have to have a word with him. ;)
[12:07] <pitti> it should be interesting whether a read()-write() Python loop is significantly slower than dd
[12:07] <cjwatson> so, is it just me, or is klibc's chroot.c on crack?
[12:07] <cjwatson> it does chroot() then execve(), rather than chroot() chdir() execve()
[12:08] <ogra> pitti, speed doesnt really matter ... i took dd because i know for sure it DTRT and isnt buggy :)
[12:08] <cjwatson> unlike every other chroot in existence
[12:08] <ogra> saftey first
[12:08] <pitti> cjwatson: the chroot(2) manpage claims the same (chdir necessary)
[12:08] <pitti> ogra: well, for copying 700 MB speed should matter a bit...
[12:09] <pitti> yay, NEW empty
[12:09] <cjwatson> right, this is why the crackful PATH=/root/stuff was added to casper, I think
[12:09] <persia> I have a solution for dd?
[12:10] <ogra> _MMA_, i wrote that app (including the branding) in less than 8h its only a first shot and was more a fingertraining weekend project .... https://code.launchpad.net/usb-imagewriter has the xcf in the source feel free to do what you like with it :)
[12:10] <ogra> i'll happily merge branches and patches
[12:11] <ogra> pitti, really, doe it mater if it takes 4 or 5 mins ? its slow in any case :)
[12:11] <ogra> *does
[12:11] <pitti> ogra: no, but it would if it takes 4 vs. 20, that's why I'm curious
[12:11] <ogra> ah, yeah, indeed
[12:12] <cjwatson> of course, we could just rip out klibc chroot and use busybox for that instead
[12:12] <cjwatson> since busybox also correctly uses execvp rather than execve
[12:13] <Tonio_> pitti: still writing the code.... should be done this WE...
[12:13] <_MMA_> ogra: Sure. Ill have a go at it.:)  Mind if I mention it on the art list?
[12:13] <ogra> i not at all :)
[12:13] <_MMA_> Cool
[12:14] <nixternal> pitti: I don't know te whole reasoning behind separating pykde4 from the kde4bindings in the past
[12:14] <pitti> Tonio_: so is it the right thing to use kdesudo-kde4 for alpha-2?
[12:14] <ogra> _MMA_, my personal plan was to have fun with it, produce something minimally usable and then throw it at the community ;)
[12:14] <nixternal> Tonio_: do you know why pykde4 was separated from kdebindings?
[12:14] <pitti> (it's still in Debian, apparently)
[12:15] <nixternal> it could have been due to the rest of the bindings not being ready in the past
[12:16] <_MMA_> ogra: Cool. Maybe Ill ask for one with Debian branding also. Maybe it will make it easier to go to them as well.
[12:16] <ogra> feel free ... we should really make more use of the art team for non desktop art
[12:17] <ogra> (that struck me yesterday when we were discussing presentations in the mobile meeting)
[12:18] <ogra> there is so much enthusiasm and so many other areas than the desktop where good artwrok makes sense ... but i only see theme discussions on the artwork ML
[12:32] <Tonio_> nixternal: no idea concerning pykde4.... I still didn't do much on the kde4 side...
[12:32] <Tonio_> pitti: yeah we can make use of it right now, except it has a few bugs fixed in the kde3 version, that I have to fix in the kde4 one
[12:32] <pitti> Tonio_: ok, thanks
[12:32] <Tonio_> pitti: but as kdesu in kde4 is built without sudo support, we have to use kdesudo in any case
[12:37] <cjwatson> Tonio_: is it going to be moved to a more sensible filesystem location?
[12:41] <Tonio_> cjwatson: yeah kde4 will go in /usr afaik
[12:42] <Tonio_> cjwatson: Riddelll would know more on that point, but moving to /usr was decided uring the UDS
[12:42] <Tonio_> s/uring/during
[12:44] <emgent> hello
[13:07] <Karnaugh> is the startup splash graphics stored in the initrd on the livecd?
[13:07] <TheMuso> Karnaugh: Yes they are.
[13:12] <Karnaugh> TheMuso: I see usplash has something to do with it, wandering through the docs for that atm
[13:12] <TheMuso> Karnaugh: Thats correct.
[13:24] <Karnaugh> cool that seems quite trival
[13:24] <Karnaugh> *trivial
[13:25] <DktrKranz> pitti, I think syncs from bug 247481 and bug 247482 were not processed. Packages left incoming this morning and probably didn't reach mirrors in time.
[13:26] <cjwatson> can we make syncbugbot not close bugs when that happens?
[13:41] <cjwatson> pitti: so did you promote kdesudo-kde4 in the end? I just made ubiquity depend on it ...
[13:41] <cjwatson> (I don't seem to have much option)
[13:47] <ogra> cjwatson, seeing all this effort above, do you actually try to get a desktop CD ready for alpha2 ? (i refrained from adding the compcache stuff to casper because we seemed to have none)
[14:00] <cjwatson> ogra: Steve seems to want to try, anyway
[14:00] <cjwatson> and I think it would be good if we could
[14:10] <doko> pitti, kirkland: how much functionality is going away from ecryptfs-utils when removing the two build-deps?
[14:11] <kirkland> doko: hey, we were just talking about this with zul on #ubuntu-server
[14:11] <kirkland> zul: -> move over here
[14:12] <kirkland> doko: libltspi is a library with support for TPM chips on modern motherboards
[14:12] <doko> at least we should document that in the MIR
[14:12] <kirkland> doko: pitti: how about I do that, and ping back here once it's in writing?
[14:13] <kirkland> doko: pitti: on the other hand, shall I just file the MIR for the other build deps, and only remove the deps if there's a problem moving them to Main?
[14:14] <doko> yes, at least libltspi doesn't sound like a problem
[14:15] <kirkland> doko: opencryptoki contains support for some cryptographic accelerator hardware
[14:15] <kirkland> doko: mostly IBM stuff, I think
[14:15] <kirkland> doko: might be nice to have on the server
[14:16] <kirkland> doko: I've already written the MIR for libltspi: https://wiki.ubuntu.com/MainInclusionReportTrousers
[14:16] <kirkland> doko: no bug filed yet
[14:16] <kirkland> doko: see the top of that...  we need library out of trousers, but not necessarily the daemons and such (trousers)
[14:17] <doko> hmm, I don't see a b-d on trousers ..., but on libopencryptoki-dev
[14:18] <kirkland> trousers provides libltspi-dev
[14:18] <doko> isn't this chip in the thinkpad notebooks as well?
[14:18] <kirkland> doko: the TPM (libltspi, trousers) -- yes.   opencryptoki stuff -- no.
[14:19] <kirkland> doko: although we don't have userspace to exploit it, ecryptfs could use a TPM to cryptographically lock a mounted filesystem to a TPM chip (ie, a particular motherboard/machine)
[14:19] <kirkland> doko: or using a keyring, a set of machines
[14:21] <pitti> cjwatson: I did promote kdesudo-kde4, yes
[14:21] <kirkland> doko: also, it looks to me like opencryptoki would also mean an MIR for freetype1
[14:22] <pitti> DktrKranz: sorry, reopened
[14:22] <cjwatson> pitti: ok, cool, thanks
[14:22] <pitti> cjwatson: kdesudo could be demoted, so that seemed like an adequate deal :)
[14:23] <doko> kirkland: freetype1 should be avoided
[14:30] <kirkland> doko: hmm, sorry, i can't find it now...  i swear one of these needed to pull libttf2 for a build dep
[14:30] <kirkland> doko: and it escapes me
[14:31] <pitti> cjwatson: I also promoted gtk-qt-engine-kde4 in exchange for gtk-qt-engine (c-mismatches wanted that)
[14:32] <pitti> cjwatson: but just now, so it will take a while to propagate
[14:33] <tseliot> pitti: can you upload revision ubuntu5 of the nvidia drivers from my PPA to Intrepid (when you have the time), please? It fixes a bug reported by mdz
[14:36] <kirkland> doko: okay, trousers (libltspi): https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/247590
[14:37] <cjwatson> pitti: ok, thanks
[14:48] <cody-somerville> slangasek, ping
[14:49] <davmor2> cody-somerville: shhh sleeping ;)
[14:49] <cody-somerville> ah ;]
[14:53] <pitti> tseliot: hm, the diff changes some i386 to x84_64 paths again; is that just build noise?
[14:54] <tkamppeter> Riddell, ping
[14:54] <pitti> tkamppeter: Riddelll is on holiday, FYI
[14:54] <tkamppeter> pitt, until when?
[14:54] <pitti> this week, AFAIK
[14:55] <tkamppeter> pitti, thank you.
[14:55] <kirkland> doko: okay, i created a MIR for Opencryptoki too... https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/247593
[14:57] <tseliot> pitti: I haven't touched the debian/rules and that line is still commented out
[14:57] <pitti> tseliot: I looked at http://launchpadlibrarian.net/15962949/nvidia-graphics-drivers-173_173.14.09-0ubuntu4_173.14.09-0ubuntu5.diff.gz
[14:59] <tseliot> pitti: I don't see any reference to rules there.
[15:01] <pitti> tseliot: but changed paths
[15:02] <pitti> debian/nvidia-glx-173.examples
[15:02] <pitti> -NVIDIA-Linux-x86-173.14.09-pkg0/usr/share/doc/XF86Config.sample
[15:02] <pitti> +NVIDIA-Linux-x86_64-173.14.09-pkg2/usr/share/doc/XF86Config.sample
[15:02] <tseliot> pitti: the other changes in .sample, etc. were generated automatically and they are harmless
[15:02] <pitti> same in .docs and copyright
[15:03] <pitti> tseliot: it sounds like you generated that tarball from the 64 bit download instead of from the 32 bit one?
[15:04] <tseliot> pitti: I have generated the source with debuild -S on my Intrepid 64 os
[15:04] <kirkland> doko: okay, i think that's all that's needed for ecryptfs-utils
[15:05] <kirkland> doko: if we can get libtspi-dev and libopencryptoki-dev into main, we won't have to carry a delta against Debian
[15:07] <tseliot> pitti: I can apt-get source the version in Intrepid and start from scratch if you wish
[15:08] <pitti> tseliot: well, I primarily want to understand why a mere package rebuild changes debian/copyright, or debian/*.docs
[15:09] <tseliot> pitti: I did a dpkg-buildpackage -rfakeroot && debclean in order to test the packages. This changed those files.
[15:09] <pitti> weird
[15:10] <tseliot> pitti: such files will change again according to the arch of the machine which builds the packages
[15:10] <pitti> tseliot: if the orig.tar.gz didn't change, then it looks like that black magic will break the package?
[15:10] <pitti> debian/*.docs have file paths where to install documentation from
[15:10] <pitti> so if you change that path to a different directory, it will break
[15:12] <tseliot> pitti: no, nothing should break. The nvidia-173-kernel-source.docs.in is a template used to generate a .doc file according to the arch when the packages are built.
[15:12] <tseliot> each path is like #DIRNAME#/usr/share/doc/NVIDIA_Changelog
[15:12] <tseliot> and DIRNAME changes according to the arch in the upstreaminfo file
[15:12] <pitti> tseliot: oh, ugh
[15:12] <pitti> tseliot: ok then
[15:13] <dholbach> somebody please moderate my 'harvest' post through u-d-a
[15:13] <dholbach> thanks in advance
[15:13] <pitti> dholbach: doing
[15:13]  * dholbach hugs pitti
[15:13] <pitti> shouldn't you be in India already? :-)
[15:14] <dholbach> I'll be off in a few minutes
[15:14] <pitti> dholbach: nothing in the queue yet, I'll look again later
[15:14] <dholbach> flight is sunday early, but we'll drive to my parents place tonight to drop off the dog there
[15:14] <tseliot> dholbach: enjoy your vacation then ;)
[15:15] <dholbach> thanks a lot tseliot
[15:15]  * pitti hugs dholbach, enjoy your holidays!
[15:15] <pitti> dholbach: ah, acked now
[15:15] <dholbach> ROCK
[15:16] <pitti> tseliot: do you still have the source.changes files somewhere?
[15:16] <Lrrr> cjwatson: I've fixed my germinate branch as you asked.
[15:17] <pitti> tseliot: copying the package into intrepid proper is always a pain, since it always goes to main first, and then fails to upload
[15:17] <pitti> tseliot: so I'd rather upload it the manual way
[15:17] <pitti> copy-package.py should have a field for the destination component... (the existing option is fairly useless)
[15:17]  * pitti hugs cprov
[15:18] <tseliot> pitti: would you like me to upload all the changes and dsc to my website?
[15:18] <pitti> tseliot: just the .changes are enough
[15:19] <pitti> tseliot: (the ones matching the .dsc in the ppa)
[15:19] <tseliot> pitti: yes, of course
[15:22] <pitti> cprov: filed as bug 247602 now
[15:24] <tseliot> pitti: here are the links http://albertomilone.com/ubuntu/newlrm/pitti/links.txt
[15:25] <pitti> tseliot: thanks; all uploaded
[15:26] <tseliot> pitti: thanks :-)
[15:26] <pitti> thanks to you
[15:28] <cjwatson> Lrrr: thanks; for future reference please use UNRELEASED in the changelog rather than intrepid if you aren't doing the upload
[15:28] <Lrrr> cjwatson: t-y
[15:29] <cjwatson> Lrrr: merged
[15:48]  * freeflying 
[15:56] <freeflying> sorry, type wrong
[16:03] <kirkland> anyone familiar with get_current_dir_name()?  http://ubuntu.dustinkirkland.com/manpages/intrepid/man3/get_current_dir_name.html
[16:03] <kirkland> it should return a char *, but my test program compiles saying that it's returning an int
[16:05] <sistpoty|work> kirkland: are you defining __GNU_SOURCE?
[16:06] <kirkland> sistpoty|work: ah, good catch
[16:06] <kirkland> sistpoty|work: i am not
[16:06] <sistpoty|work> kirkland: you better should then ;)
[16:06] <kirkland> sistpoty|work: thanks for the quick silver bullet ;-)
[16:06] <sistpoty|work> np
[16:21] <Riddelll> tkamppeter: pong
[16:23] <tkamppeter> Riddelll, back from vacation?
[16:24] <cjwatson> kirkland: also sounds like you aren't using -Wall
[16:24] <Riddelll> tkamppeter: for now
[16:24] <cjwatson> k.c:4: warning: implicit declaration of function ‘get_current_dir_name’
[16:24] <tkamppeter> Riddelll, I have filled in the GSoC mid-term questionnaires on your behalf, as pitti told that you are on vacation.
[16:25] <Riddelll> tkamppeter: oh, great, thanks
[16:25] <tkamppeter> Riddelll, can you please look at them and edit or correct if you want?
[16:25] <Riddelll> tkamppeter: ok
[16:25] <tkamppeter> The most important is that I have answered the last question with "Yes" to assure that the students are not kicked off the projects.
[16:55] <ogra> oook .... so "pm-suspend -h" suspends my computer .... great !
[16:56] <ogra> (especially great if you wanted to find out about the available quirks because it hardlocks on resume, *sigh*)
[16:57] <ogra> (and even better that only root can read the help if --help is used )
[16:57] <pitti> ogra: manpages FTW then :)
[16:57] <ogra> well
[16:58] <ogra> one could have programmed that a bit saner :)
[17:00] <ogra> grrrr, and i810 support is deliberately disabled
[17:00]  * ogra wants acpi-scripts back !
[17:21] <ogra> superm1, do you know who currently maintains dkms ?
[17:21] <mario_limonciell> ogra, that would be me actually as of a week or two ago
[17:21] <ogra> (the package, not upstream)
[17:21] <mario_limonciell> the package, that's also me
[17:21] <ogra> great, thanks
[17:22] <mario_limonciell> why?
[18:01] <alex-weej> who's been hacking on NewHuman?
[18:01] <alex-weej> i have my 2p to add
[18:01] <alex-weej> the little stripe at the top of the window frame is way too close to the title text
[18:01] <alex-weej> feels cramped
[18:01] <_MMA_> alex-weej: Go to #ubuntu-artwork.
[18:05] <ramvi> Hi, I'm making Ubuntu eee. I used reconstructor for the last release, but it's not really doing it for me. What's a good way of remastering the ubuntu live iso? What's the "correct" way?
[18:17] <K^> auto-sync is turned off, or only for alpha-2 release?
[18:17] <ramvi>  /ignore ramvi
[18:18] <evand> https://help.ubuntu.com/community/LiveCDCustomization
[18:18] <evand> ramvi: ^
[18:20] <ogra> ramvi, i'm abandoning that code soon, but that can be used to build an image for small notebooks https://code.launchpad.net/~ogra/cmpc/cmpc-gen1-installer
[18:20] <ogra> pfft, to slow
[18:20] <laga> he wants to customize the squashfs i guess
[18:22] <K^> Is auto-sync is turned off, or only for alpha-2 release?
[18:23] <cjwatson> K^: it's turned off. https://help.ubuntu.com/community/Debian/ImportFreeze
[18:23] <K^> cjwatson: thanks
[18:23] <cjwatson> and https://wiki.ubuntu.com/IntrepidReleaseSchedule
[18:24] <cjwatson> K^: by the way, you're evading a ban
[18:24] <cjwatson> I'd have answered you in /msg if you'd been a little more patient
[18:26] <K^> cjwatson: I thought you're not here..
[18:26] <K^> =)
[18:28] <MeniShevitz> hi all
[18:29] <MeniShevitz> is this the place for a noob with a umpc to try and get his ubuntu mid groove going?
[18:29] <MeniShevitz> :)
[18:29] <Lrrr> what...?
[18:30] <MeniShevitz> i have a gigabye u60 UMPC and would love to try out ubuntu mid edition
[18:30] <MeniShevitz> but i haven't a clue where to start
[18:31] <MeniShevitz> it's a via vx700 c7m machine
[18:31] <cjwatson> MeniShevitz: #ubuntu-mobile would probably be better
[18:31] <MeniShevitz> just what i was looking for, didn't see it in the /list :)
[18:31] <MeniShevitz> thanks cjwatson!
[18:31] <cjwatson> you're welcome
[18:31] <mario_limonciell> cjwatson, persia had mentioned that you had initially drafted the proposal that pre-empted bug 134456.  could you comment on the status of the other parts of it, for the UI and for the approval process, what's the plan for now?
[18:32] <persia> I'm not sure about pre-emption, but related.
[18:32] <cjwatson> mario_limonciell: as persia says, my proposal is related to that and somewhat depends on it, but as far as I know does not block implementation at all
[18:33] <cjwatson> mario_limonciell: you'd have to ask the Soyuz team about the rest of it
[18:33] <cjwatson> mario_limonciell: as far as the approval process goes, -> tech board
[18:33] <persia> cjwatson: Aren't we waiting on the TB to determine how to authorise the per-package stuff as well, even in the absence of a UI?  Alternately, are we at the chicken-and-egg stage?
[18:33] <cjwatson> (since it's a matter of granting upload privileges)
[18:33] <cjwatson> persia: snap ;)
[18:34] <cjwatson> a UI would help; the TB probably doesn't want to authorise things that will require somebody to go and poke at the LP database with psql
[18:34] <mario_limonciell> cjwatson, so you think just send a request to TB and until TB decides that they are the wrong set of folks to determine who gets rights where, they decide?
[18:34] <cjwatson> yeah
[18:35] <persia> Heh.  That's one way to define the process :)  I like to write them up first, but...
[18:46] <sistpoty> bryce, tjaalton: from current upgrade: are these fixed already? http://paste.ubuntu.com/26713/ (/me is behind a little bit, due to using a german mirror)
[19:06] <slangasek> cody-somerville: pong
[19:09] <dirker> Hello, I hope this is the right channel. I'm struggling to port the transmission package from debian to hardy, dh_clean complains that 6 is the highest level it supports.
[19:09] <dirker> I have already modified debian/control to my best knowledge and now I dont know where to look for further information
[19:10] <kirkland> dirker: you might do better with packaging questions in #ubuntu-motu, fwiw
[19:10] <dirker> kirkland: thanks, will try
[19:18] <savvas> kirkland: seen mvo around? bug 244093 is still waiting approval :\
[19:19] <kirkland> savvas: you looking for me, or someone else?
[19:20] <savvas> kirkland: i think you mentioned in that bug report that mvo (michael vogt?) should take a look at that debdiff code
[19:21] <savvas> sorry, *in the comments* :)
[19:21] <kirkland> savvas: nope, that was kees
[19:21] <savvas> woops
[19:21] <savvas> i need a new pair of glasses :P
[19:23] <savvas> ah what the heck, he'll see it sometime
[19:33] <slangasek> bryce: in https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/245888/comments/12, you write that there's a known issue causing compiz to fail on intel - is that a known compiz or mesa issue? (bug #245823, trying to figure out if the dup'ing was correct)
[19:37] <ogra> slangasek, "Blank Brown Screen" sonds a lot more like a gnome-session issue to me than compiz
[19:37] <slangasek> it's not
[19:37] <slangasek> everything is started, and killing compiz makes it visible
[19:38] <bryce> slangasek:  "Compiz shows only black screen on i965"
[19:38] <bryce>  http://bugzilla.freedesktop.org/show_bug.cgi?id=14441
[19:38] <bryce>  "full screen is white when use compiz"
[19:38] <bryce>  http://bugzilla.freedesktop.org/show_bug.cgi?id=15477
[19:38] <bryce>  (Also see LP: #245888)
[19:38] <slangasek> bryce: so, where does brown screen fall into this?  different bug, or same bug? :)
[19:38] <bryce> heh
[19:38] <lamalex> slangasek: probably different bugs
[19:39] <bryce> hmm, in this case if its a different color I'd guess different bug
[19:39] <slangasek> bryce: so I should un-dupe 245888?
[19:39] <bryce> looking
[19:39] <lamalex> the full white/black is probably a graphics driver issue, the brown is GNOME failing to load properly
[19:41] <ogra> light bron is usually the leftover of gdm and gnome-session being stuck on something... the white compiz screen is different, but indeed the OP says its the same ... so he probably mixed up the colors
[19:42] <bryce> or he could be confused
[19:42] <ogra> yeah
[19:42] <ogra> thats what i first thought
[19:42] <bryce> I'd say leave it a separate bug, but it needs to be more fully reported - Xorg.0.log, maybe backtraces if there's a crash going on
[19:42] <slangasek> who could be confused?
[19:43] <slangasek> note that I confirmed the brown screen bug
[19:43] <bryce> tenof26
[19:43] <ogra> .xsession-errors for gnome-session helps too
[19:43] <ogra> slangasek, but he agreed in his last comment
[19:43] <bryce> there's a variety of things that break that can lead to the brown screen, so that symptom alone is generally not sufficient for proving dupe bugs.  Usually need an error message or backtrace to be sure
[19:44] <sistpoty> bryce: FYI reported bug #247681
[19:46] <slangasek> bryce: well, I checked for .xsession-errors when I had this, and I don't remember seeing anything at all; and compiz doesn't crash it just never gives me any windows until I kill it; would a backtrace of compiz wherever it is at the time be helpful?
[19:46] <slangasek> s/don't remember seeing/remember not seeing/
[19:47] <slangasek> bryce: in the meantime, if this problem isn't affecting you, perhaps you'd like to try an install with the liveCD so that /someone/ is able to validate that it works :)
[19:47] <bryce> it might; I'm not up on compiz debugging procedures.  You've verified it boots correctly when compiz is disabled I take it?
[19:47] <slangasek> bryce: how do I disable compiz to verify that? (this is all in the liveCD for me)
[19:48] <bryce> slangasek: unfortunately my flight is this afternoon so I'm about to head out in an hour
[19:48] <slangasek> mmk
[19:49] <ogra> slangasek, boot with textmode option, remove compiz, start gdm
[19:49] <bryce> hmm, a brute force method would be to chmod a-x /usr/bin/compiz ;-)
[19:50] <ogra> or that :)
[19:50] <ogra> cheaper than removing for sure
[19:52] <slangasek> ogra: is 'textmode' a literal option name?
[19:53] <lamalex> you don't need to reboot
[19:53] <ogra> i think so
[19:53] <lamalex> just control+alt+f1 into a terminal
[19:53] <lamalex> remove execute from the compiz binary, and then ctrl+alt+f7 back to X and login
[19:54] <ogra> if zapping works with that bug, yeah, thats an option
[19:54] <ogra> though i think steve boots the livecd newly anyway
[19:54] <persia> Or just disable compiz in gconf rather than removing the binaries or chmod -x ing them.
[19:54] <ogra> persia, gconf on the commandline is painful
[19:55] <persia> ogra: OK.
[19:55] <ogra> chmod -x is a very good way if its a livecd anyway i guess
[19:55] <lamalex> oh this is a cd
[19:56] <ogra> right and it boots into the bug since it starts a session right away
[19:58] <lamalex> yeah but cant' you restart X and go back to gdm?
[19:59] <ogra> probably
[20:01] <cjwatson> textmode> I think it's 'textonly'
[20:01] <cjwatson> (cf. bug 65818)
[20:04] <ogra> ah, crap my mind tricked me
[20:07] <ogra> hmm, thats funny ... i have an image build running, run a tail -f on the build log and if i get to mksquashfs i get the percentage bar while building ...
[20:07] <ogra> if the terminal loses focus the progress just stops
[20:08] <ogra> (mksquashfs still running though, i can see the image grow)
[20:10] <ogra> i wonder if thats because of ssh or if its tail's fault
[21:29] <slangasek> bryce, ogra: disabling compiz before the boot, the desktop comes up fine.  As soon as I enable compiz, that's when things go pear-shaped
[21:29] <slangasek> bryce, ogra: and .xsession-errors is entirely empty
[21:29] <ogra> and is it white or brown ?
[21:30] <ogra> white is compiz acting up with the video driver in any case
[21:30] <ogra> brown might not necessarily be video related
[21:30] <slangasek> no, it's brown
[21:30] <slangasek> as it has been all along for me
[21:30] <norsetto> infinity: do you think we could do something about bug 225741 ?
[21:31] <slangasek> I get some error output from compiz on the console; let me see if I can save this somewhere
[21:31] <ogra> slangasek, hmm ... i would rather look in compiz startup procedure then
[21:31] <sistpoty> ogra: based on a color? :P
[21:31] <ogra> yep
[21:31] <sistpoty> heh
[21:31] <ogra> ;)
[21:32] <ogra> sistpoty, my therory is that compiz holds up gnome session from starting but that it isnt a video driver vs compiz issue
[21:36] <YokoZar> kees: *poke*
[21:38]  * sistpoty just giggle at the hint to bug triagers: for compiz/gnome session bugs, please ask the reporter for the color of the screen
[21:39] <ogra> heh
[21:40] <slangasek> ogra: it has nothing to do with gnome-session, compiz breaks the same way if you try to have it replace metacity.
[21:40] <ogra> ok
[22:51] <mathiaz> slangasek: I've got a preliminary patch for the cn=config migration for slapd I'd get some feedback on. Should I file a bug in Debian or can I just send it to the pkg-openldap maintainer list ?
[22:52] <slangasek> mathiaz: sending to the list is fine for starters
[22:52] <slangasek> (or probably, altogether, unless we end up having to defer it for some reason and need a bug to track it)
[22:52] <mathiaz> slangasek: I'll send the patch to the list
[23:58] <kees> YokoZar: heya, what's up?