[00:00] <lfaraone> wgrant: well, we don't have the source file, so we don't know. it'll probabbly be a few kb less
[00:03] <slangasek> er, what exactly is the plan of action here?  You want to re-encode using a source format that's not available?
[00:03] <lfaraone> slangasek: well, we're wondering if it's recorded anywhere where the file came from.
[00:04] <slangasek> the copyright file states it came from http://librivox.org/
[00:04] <asac> ScottK: unlikely that the regression window really is the latest upload. at least if its a knetworkmanager specific issue
[00:05] <asac> ScottK: read: no dbus api changes in the last upload
[00:05] <lfaraone> slangasek: ah, we got it, it's on archive.org
[00:05] <asac> ScottK: do you use a "hybrid" setup, e.g. one connection managed by ifup/ifdown and the wireless with NM?
[02:26] <bryce> mdz, I've sorted out why the OCD doesn't display - it's a bug in gnome-power-manager
[02:26] <bryce> hmm, no mdz
[02:28] <bryce> cjwatson: so mdz's bug is a combination of two bugs - one is a thinkpad t61 kernel bug, that it's not propagating numlock key changes up properly (verified this with whot upstream), the other bug is local to gnome-power-manager where it's not bothering to grab keys with modifiers (it's grabbing with modmap=0 instead of modmap=AnyModifier)
[02:44] <mathiaz> slangasek: is there a reason why /var/lib/samba is created in the samba package rather than the samba-common package?
[02:44] <mathiaz> slangasek: it seems that libpam_smbpass segfaults if /var/lib/samba doesn't exists - see bug 260687
[04:36] <slangasek> mathiaz: it's a bug that was overlooked until recently; feel free to fix it
[04:36]  * StevenK uploads most of the remaining libbluetooth2 transistion
[04:37] <StevenK> superm1: ^
[04:40] <slangasek> TheMuso: "812KB" - yeah, we don't have that to spare, please solve this another way for intrepid
[04:44] <NCommander> StevenK, how much is left on that transition
[04:48] <StevenK> NCommander: Um. Let me answer that after these process and the publisher finishes, roughly sixty minutes
[04:52] <calc> i sliced the end of my finger with a serated bread knife, oops :(
[04:52] <calc> that'll teach me not to stick my fingers where i can't see what is there
[04:52] <NCommander> ScottK, I'm attacking openexr
[04:52] <NCommander> No promises though, this is an ugly test failure
[04:53] <calc> there was a knife stuck between boxes stacked in my garage, tried to pick up box and ouch
[04:53] <StevenK> calc: You okay?
[04:53] <calc> StevenK: yea it wasn't deep so i just cleaned it well, makes it a little harder to type without using that finger
[04:54] <calc> i'm starting to get the hang of it, heh :)
[04:54] <TheMuso> ouch
[04:55] <calc> i thought i had cut myself on the cardboard until i looked under the box, lol
[05:45] <NCommander> lamont, ping?
[05:48] <StevenK> You know it's nearly midnight, right?
[05:52] <NCommander> StevenK, not really
[05:52] <NCommander> StevenK, time is relative afterall
[05:52]  * StevenK teaches NCommander about "time zones"
[05:53] <NCommander> as I said, time is relative ;-)
[05:53] <NCommander> And there is only one true timezone and UTC is its name
[05:57] <realist> NCommander: some astronomers may disagree with you.
[05:57] <NCommander> *on earth
[05:57] <NCommander> On Mars, UMT rules, and sols define the days ;-)
[05:57] <NCommander> ScottK, I did some initial debugging on openexr; the main issue seems to be a race issue in glibc (it appears to me that some of the pthread() functions aren't working appropriately). I'm running the test suite on glibc as we speak. If you need this package uploaded, and you don't care about it supporting threads (due to the borked glibc), I can give you a patch to prevent it from calling make check on HPPA
[07:14] <StevenK> NCommander, superm1: The last two libbluetooth2 transistion packages are libpam-blue and ussp-push
[07:14] <StevenK> NCommander: If you prepare an upload to Intrepid proper, I'll sponsor it.
[07:14]  * NCommander does that
[07:15] <StevenK> NCommander: Just libpam-blue, since you fixed it, you deserve the upload for it
[07:16] <NCommander> StevenK, http://pastebin.ca/1224354
[07:16] <NCommander> StevenK, I haven't test built it yet (not on my intrepid box)
[07:16] <NCommander> Care to do that for me?
[07:16] <NCommander> ANd yes, its a big diff just because the upstream inlined ****loads of unneeded crap that had to go
[07:18] <StevenK> That's nasty
[07:18] <NCommander> Well, if upstream is willing to inline autotools changes ...
[07:18] <StevenK> I'd prefer you update the date of the changelog, but *shrug*
[07:41] <StevenK> NCommander: libpam-blue uploaded
[07:45] <NCommander> \o\ /o/ \o/ <o> >o<!
[07:48] <pitti> Good morning
[07:49] <StevenK> pitti: I have belted the NBS list down to 7 affected packages
[07:49] <StevenK> It will jump again since 2.6.27-7 got uploaded
[07:50] <pitti> slangasek: samba with -v> WFM
[07:53] <pitti> ScottK: nominated 280997 for intrepid
[07:53] <geser> good morning pitti
[07:53] <pitti> StevenK: rocking
[07:57] <dholbach> good morning
[07:58] <persia> StevenK, As an admin, could you subscribe the Bluetooth team to bluez bugs? ( https://bugs.launchpad.net/ubuntu/+source/bluez/+subscribe )
[07:59] <StevenK> persia: Done
[07:59] <dholbach> ogra: speaking of admins: can you please unsubscribe edubuntu-members from thin-client-manager bugs and subscribe some edubuntu-bugsquad instead?
[08:00] <dholbach> I could unsubscribe edubuntu-members myself, but I'd prefer if some other team was subscribed at the same time
[08:16] <geser> good morning dholbach
[08:16] <dholbach> hiya geser
[08:17] <persia> slangasek, It was suggested that you might have a useful comment for bugs 281135 and 281144
[08:38] <lukehasnoname> Is there a reason linux-generic is being held back on my beta install of 8.10?
[08:39] <persia> lukehasnoname, Have you checked on what it depends?  Is everything available?
[08:39] <lukehasnoname> I'll check.
[08:39] <geser> lukehasnoname: try "sudo apt-get install linux-generic" and it should tell you why it can't be installed
[08:43] <lukehasnoname> geser: I ran the install and I didn't get errors
[08:44] <persia> lukehasnoname, In that case it probably included a new dependency : update-manager won't install those except when doing a distribution upgrade.
[08:45] <lukehasnoname>   bluez-cups bluez-utils evolution evolution-common gimp gimp-data gvfs   gvfs-backends libgimp2.0 libpisock9 linux-headers-generic obex-data-server   totem totem-gstreamer totem-mozilla totem-plugins ubuntu-desktop
[08:45] <lukehasnoname> Those are all being held back, in addition to the linux-generic packages that were previously held back. Any clue on specifics?
[08:46] <geser> lukehasnoname: it probably wants to add or remove packages
[08:46] <persia> lukehasnoname, Try running aptitude or synaptic or similar interactive tool to investigate.
[08:46] <geser> "sudo apt-get dist-upgrade" and check very carefully what it wants to remove (or add)
[08:49] <fabbione> morning guys
[08:49] <lukehasnoname> ehh I already pushed ahead with apt-get upgrade. I'll still check that though.
[08:51] <mvo> cjwatson: are you ok with http://paste.ubuntu.com/55921/ ?
[08:56] <liw> mvo, in update-manager, you seem to be using gettext.gettext rather than gettext.install/gettext.translation. the latter is strongly recommended by the python stdlib docs. do you have a reason to prefer gettext.gettext?
[08:57] <mvo> liw: no strong reason, that I what I used in C and I'm familiar with.
[08:58] <liw> mvo, ack, that's a good reason
[08:58] <mvo> liw: what is the advantage of using the alternative form?
[08:58] <mvo> liw: is there something to read up? pydoc gettext seems to be not that informative
[08:59] <liw> mvo, "more flexibility and greater convenience than the GNU gettext API" says file:///usr/share/doc/python2.5/html/lib/node732.html
[09:00] <liw> mvo, the flexibility probably means just that the newer API allows easily switching between languages, or supporting several concurrently
[09:00] <tseliot> pitti: I have fixed this bug in jockey, can you have a look at my branch? https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/280147
[09:01]  * mvo waves to tseliot
[09:01] <mvo> liw: aha, cool. thanks. I will keep that in mind :)
[09:01] <tseliot> mvo: hi :-)
[09:02] <liw> mvo, I'm not sure the "greater convenience" applies to modules, just for applications, but we'll see; since the new API is the recommended one, I'll do system-cleaner with it, and we can compare notes some day
[09:03] <mvo> liw: sounds good!
[09:03] <liw> I have found a surprising dearth of documentation on this
[09:04] <mvo> liw: gettext in python? yeah, it seems that everybody just copies what he found other code. I find it also slightly anoying that gtk.glade needs its own bindtextdomain() calls (or at least it needed when I wrote the code)
[09:06] <liw> mvo, I think I saw a note somewhere saying that it might not be needed anymore, but who knows... writing such a doc (or a patch to python's stdlib docs) would be a good upstream contribution
[09:06]  * mvo nods
[09:19] <cjwatson> mvo: hmm, disabling cancel altogether sort of worries me. Could you wrap that in an environment variable that update-manager sets for now, and send it upstream to see what Joey thinks of it?
[09:20] <cjwatson> mvo: the rest is OK although would it be worth allowing GDK_FUNC_RESIZE and GDK_FUNC_MAXIMIZE too?
[09:20] <cjwatson> mvo: oh, trivial things: there's some tab damage visible there, and debconf is in bzr (lp:~ubuntu-core-dev/debconf/ubuntu)
[09:21] <StevenK> pitti: What do you think about bugs 281135 and 281144?
[09:22] <cjwatson> liw: I think gettext.translation makes more sense for modules in the same way that C libraries using gettext need to use dgettext - it gives you separate control over the domain in use
[09:23] <cjwatson> hmm, although python gettext offers dgettext too
[09:23] <cjwatson> dunno then :)
[09:24] <cjwatson> lifeless: lock shell script> there's a 'with-lock-ex' command in chiark-utils-bin
[09:24] <mvo> cjwatson: thanks, I will forward it to joeyh and wrap it for now
[09:24] <cjwatson> lifeless: or there's the lockfile-* suite in lockfile-progs; IME those are more annoying to use though
[09:25] <liw> lifeless, I use lockfile(1) from procmail for locking in shell scripts
[09:31] <nijaba> Hey there. Would you think that bug #150872 should be targeted for intrepid?
[09:37] <cjwatson> nijaba: no, it would break things if done for intrepid
[09:37] <cjwatson> nijaba: removable media is listed for a good reason right now
[09:37] <cjwatson> nijaba: apt-cdrom has no way to discover the CD drive dynamically
[09:38] <nijaba> cjwatson: ok, thanks, might be worth mentioning the issue in the release notes then and usb-creator help/doc/whatever as well
[09:39] <cjwatson> nijaba: Evan is already aware of the issue and it's possible that some minor hack just for USB could be possible
[09:39] <cjwatson> but we can't just strip those lines out across the board.
[09:41] <liw> static device names seem to be a problem in every case, these days
[10:03] <cjwatson> mvo: btw, on that debconf patch, wouldn't it be better to attach a realize signal handler rather than calling realize?
[10:04] <mvo> cjwatson: http://paste.ubuntu.com/55931/ <- updated version
[10:04] <mvo> cjwatson: realize-handler> hm, good point
[10:05] <cjwatson> so $this->win->signal_connect("realize", sub { $this->win->window->set_functions(blah); }) or something # TEST THIS
[10:06] <mvo> if we continue this, I will actually lern perl along the way ;)
[10:06]  * mvo adds it
[10:07] <fabbione> cjwatson: do you remember on the fly what source/udeb has partman_devices ?
[10:08] <mvo> cjwatson: thanks, works fine, if its otherwise ok I will upload
[10:10] <pitti> tseliot: bah, this Python unicode() vs. UTF-8 handling keeps driving me nuts
[10:11] <tseliot> pitti: is the error message handled by the kde ui?
[10:11] <tseliot> kde or gtk
[10:12] <pitti> tseliot: why is wrapping the string into unicode() the right fix here?
[10:12] <pitti> tseliot: it looks like a wrong encoding in a translation to me?
[10:12] <tseliot> pitti: kde uses QStrings
[10:12] <pitti> tseliot: but this isn't KDE, this is just simple "print" to stdout
[10:12] <pitti> stderr, but same thing
[10:13] <tseliot> pitti: where do you take the error message from?
[10:13] <cjwatson> fabbione: partman-base
[10:13] <pitti> tseliot: self.string_unprivileged
[10:13] <cjwatson> fabbione: it's parted_devices, BTW
[10:14] <pitti> tseliot: it calls AbstractUI._("english string")
[10:14] <fabbione> cjwatson: oh yes.. parted_devices sorry.. but i know you are much quicker than me there :) thanks
[10:14] <cjwatson> pitti: if this is a Qt frontend, anything you get back from Qt as a QString tends to have to be wrappped in unicode() :(
[10:14] <cjwatson> I ran into that in a big way in ubiquity
[10:15] <pitti> cjwatson: that also affects the standard _() function?
[10:15] <cjwatson> pitti: oh, or for printing to stdout, there is some really annoying stuff you have to do
[10:15] <cjwatson> no, this is separate
[10:15] <pitti> right, I assumed that much
[10:15] <cjwatson> # Avoid having to do .encode('UTF-8') everywhere. This is a pain; I wish
[10:15] <cjwatson> # Python supported something like "sys.stdout.encoding = 'UTF-8'".
[10:15] <cjwatson> def fix_stdout():
[10:15] <cjwatson>     import codecs
[10:15] <cjwatson>     sys.stdout = codecs.EncodedFile(sys.stdout, 'UTF-8')
[10:15] <cjwatson>     def null_decode(input, errors='strict'):
[10:15] <cjwatson>         return input, len(input)
[10:15] <cjwatson>     sys.stdout.decode = null_decode
[10:15] <cjwatson> and then call fix_stdout somewhere
[10:15] <pitti> I'll try to reproduce the error first, I guess
[10:16] <tseliot> pitti: ok, wrong fix then ;)
[10:16] <pitti> cjwatson: thanks; I think I saw that so many times already, but it still didn't settle in my brain
[10:16] <tseliot> pitti: my previous commit is still useful though (to blacklist nvidia 71 and 96)
[10:16] <pitti> tseliot: yeah, I'll merge that
[10:16] <tseliot> ok
[10:18] <cjwatson> pitti: see also http://ewx.livejournal.com/457086.html (read the comments)
[10:19] <pitti> tseliot: hm, I don't get the crash with de_DE.UTF-8 (same as the reporter), and I get proper umlauts on stderr
[10:19] <pitti> tseliot: with both the GTK and KDE frontends
[10:20] <tseliot> pitti: it might depend on the locale. I had a similar problem with Envy with a Turkish guy
[10:20] <pitti> tseliot: right, I know, but I'm using the very same locale as the reporter
[10:21] <tseliot> ah
[10:21] <tseliot> ok, it would be nice if we could reproduce the problem
[10:23] <pitti> tkamppeter: I fixed the hpgl regression and uploaded 1.3.9 to debian and intrepid
[10:23] <cjwatson> pitti: unfortunately python people don't appear to understand how encodings actually conventionally work in Unix and regard all this as not-a-bug
[10:24] <pitti> too many MacOS X programmers amongst them? :-/
[10:24] <tkamppeter> pitti, great, it contains also an important fix in pstops.
[10:24] <cjwatson> specifically they don't understand that stream encodings are supposed to be set by the environment not (in some undefined way) by the terminal [even though in some entirely different ideal world the latter might be how it ought to work]
[10:24] <tkamppeter> pitti, why does "bzr pull"W not show it?
[10:24] <pitti> tkamppeter: I just pushed like 10 seconds ago
[10:25] <cjwatson> and that there have to be ways to override it since the environment can be wrong
[10:25] <tkamppeter> pitti, sorry, I was 1 minute too early
[10:26] <cjwatson> actually, python does set stdout's encoding from the environment, but *only if stdout is a terminal*. This is clearly mad since putting | less after your program can cause it to stop working.
[10:26] <pitti> indeed I just tried that, but it still works
[10:26] <tseliot> pitti: is it worth catching the exception then? (not that I like it...)
[10:26] <pitti> $ PYTHONPATH=. gtk/jockey-gtk --check 2>&1 |cat
[10:26] <pitti> Sie sind nicht berechtigt, diese Aktion auszuführen.
[10:26] <cjwatson> it depends on your environment
[10:26] <cjwatson> the reporter might have the locale set but not in fact have the locale generated, for example
[10:27] <pitti> ah, that's a good thing to ask in the bug report
[10:27] <cjwatson> I really would suggest just clobbering it with something like the rune I suggested above
[10:27] <cjwatson> python is known-broken in this area and you have to set things explicitly
[10:27] <cjwatson> if sys.stdout.encoding were writable it would be much more pleasant
[10:28] <pitti> cjwatson: right, I just don't feel good about hardcoding UTF-8, since users might actually use an ISO, KOI-8, or whatever encoding in their locale
[10:28] <cjwatson> pitti: use locale.getpreferredencoding() in place of 'UTF-8' then
[10:29] <cjwatson> (I haven't tested that but I think it should work)
[10:29] <pitti> this raises a severe deja-vu for me; I think I got that like half a year ago in apport
[10:37] <cjwatson> pitti: confirmed, http://paste.ubuntu.com/55934/
[10:38] <cjwatson> you might want to do the same for stderr
[10:43] <pitti> cjwatson: nice, thanks!
[10:45] <pitti> StevenK: hm, those are duplicates?
[10:45] <pitti> StevenK: looking at checkrdepends bluez-libs intrepid
[10:46] <YokoZar> So, a game I've been preparing for Intrepid for some time (Spring) just made a release, and I have a package ready.  Is there still enough time to upload it to Intrepid, or will it be rejected?  (this is a completely new package)
[10:46] <persia> pitti, Note that libbluetooth3 is now provided by the bluez source.
[10:47] <persia> YokoZar, It's decidedly late.  you might appeal to MOTU SRU, but it's unlikely.
[10:47] <pitti> -- intrepid/universe i386 deps on libbluetooth2:
[10:47] <pitti> ussp-push
[10:48] <pitti> and some in main/universe on eternally-lagging hppa
[10:48] <ogra> mvo, 0.7.8 didnt fix it for me :/
[10:48] <StevenK> pitti: Yup, ussp-push is the last one
[10:49] <StevenK> I fixed the rest today
[10:49] <pitti> however, there are a couple of more unfixed things in bug 276343
[10:49] <pitti> StevenK: so once the transition is complete, then the package can go, sure
[10:50] <pitti> but it seems most of them should be closed?
[10:53] <StevenK> pitti: Yeah, most of the bugs should be sorted. I forgot to add the bug number to the my buildX uploads
[10:54] <StevenK> Hmmm
[10:54] <StevenK> Should do this through the mail gateway
[10:56] <pitti> it just occurred to me that our gnutls13 -> gnutls26 transition is still outstanding, too
[10:56] <pitti> *sigh*
[10:56] <pitti> otherwise we'd again have two gnutls versions in stable
[10:57] <StevenK> What's needed for that?
[10:58] <persia> That's a bundle, including curl
[10:59] <StevenK> Whee
[10:59] <StevenK> pitti: Let me finish dealing with bluetooth first
[10:59] <pitti> I am just doing process-removals, and that reminded me
[11:00] <StevenK> Ah
[11:00] <persia> Is there any good tool that could identify transitions underway?  While completing them all is maybe hard, having a list would be a good start.
[11:00] <StevenK> persia: NBS, mostly
[11:01] <persia> StevenK, That only covers cases where there isn't a source name transition.  I'm wondering if just checking packages that build-depend against a given -dev have binaries that depend on the associated lib.
[11:01] <pitti> the gnutls13 source is still there, so that won't appear as NBS
[11:01] <persia> Same for bluetooth, or other stuff
[11:02] <StevenK> pitti: Right, but we have rdepends
[11:02] <pitti> StevenK: you know checkrdepends?
[11:04] <StevenK> pitti: Of course
[11:04] <StevenK> Right, that mail should set everything aside from ussp-push to Fix Released.
[11:04] <StevenK> Where the ussp-push source has gone, I don't know
[11:07]  * pitti needs to run out for some errands, bbl
[11:08] <ScottK> asac: About NM, not on purpose I don't use a hybrid setup.  Everyone who tried it (there were three of us, IIRC) saw similar issues on Kubuntu.
[11:09] <asac> ScottK: hybrid == /etc/network/interfaces has a configuration ;)
[11:10] <ScottK> asac: It says auto eth0.  Does that count?
[11:10] <asac> ScottK: if there is no iface eth0 ... line then it shouldnt
[11:11] <ScottK> Nope
[11:11] <ScottK> The only iface line I have is for lo
[11:11] <asac> ScottK: please paste your route -n output when you see these packet losses
[11:11] <ScottK> OK.  Will do.
[11:11] <asac> ScottK: i have received other complains, but couldnt reproduce here except for a hybrid setup
[11:12] <asac> ScottK: for me "wired" interfaces always have a metric/prio of "1" and wireless have a metric/prio of "2"
[11:12] <mvo> could some native speaker/UI expert review those strings: http://paste.ubuntu.com/55942/ ? its for the upgrade note about the new fusa applet that replaced the logout button
[11:12] <asac> which should tie-break the path the packages travel - assuming that both interfaces provide a route to the same net
[11:13] <ScottK> OK.
[11:14] <asac> ScottK: are you using NM 0.7 on intrepid right now? if so, please post the routing right away :)
[11:14] <asac> (even if you dont see the package loss right now9
[11:14] <StevenK> asac: gnash is still on your list, right?
[11:15] <ScottK> asac: Will do
[11:16] <ScottK> asac: In the bug or pastebin?
[11:16] <james_w> mvo: http://paste.ubuntu.com/55946/
[11:16] <mvo> james_w: excellent, thanks! is the text ok? understandable etc?
[11:16] <james_w> mvo: "got" -> "has been", "on the standard location" -> "in the standard location"
[11:17] <james_w> mvo: yeah, but you might want a UI review if you can find somebody
[11:18] <mvo> james_w: I will try, I had hoped that mpt is around
[11:18] <ScottK> asac: I added it to Bug #280919
[11:18] <james_w> mvo: yeah, is seele around?
[11:19] <james_w> does anyone know if it's possible to get rmadison to really show me just source records. It seems to recognise "source" as an architecture, and has a "source and binary" option that I'm not selecting, but it still shows me all architectures.
[11:20] <james_w> looking at the php it seems to proxy directly to "dak ls" calls
[11:28] <mvo> ogra: what video driver is this?
[11:29] <ogra> mvo, intel
[11:30]  * ogra goes to debug it more
[11:30] <ogra> might be gpm
[11:30] <ogra> or just a bug in xorg wrt dpms
[11:42] <cjwatson> james_w: it actually proxies to madison-lite for us; it's probably a madison-lite bug if it doesn't work. That said, 'rmadison -a source linux' seems to DTRT. What's your example?
[11:42] <james_w> cjwatson: ah, I was running against Debian
[11:43] <james_w> it does indeed seem to work for Ubuntu
[11:43] <asac> ScottK: thanks. the routing looks fine. but as you said in the bug you didnt have problems with that?
[11:44] <cjwatson> james_w: ahright
[11:44] <ScottK> asac: Yes.  Riddell just reported he has no wired connection either right now.
[11:44] <cjwatson> it's rather unusual for madison-lite to work *better* than dak ls ...
[11:44] <asac> ScottK: ok. you dont see an AP ... but thats a different issue (if not a general knetworkmanager bug)
[11:44] <ScottK> So I think there is a real problem here, not sure exactly what as I couldn't replicate the laggy behaviour I saw yesterday.
[11:45] <asac> ScottK: you could try to load iwl4965 with disable_hw_scan=1 ... and see if you get more reliable scans
[11:45] <liw> davmor2, rumor tells me you have an acer aspire one... does it require non-free drivers?
[11:45] <ScottK> Could be.  Others have no wired at all, so don't take my success as meaningful.
[11:45] <asac> (but thats a different bug)
[11:45] <Riddell> actually my eth0 seems to have disappeared completely
[11:45] <asac> ScottK: others == users that currently see this problem?
[11:45] <ScottK> I think that's probably unrelated
[11:45] <Riddell> dmesg doesn't show it
[11:45] <davmor2> liw: I do indeed, goes and double checks
[11:46] <ScottK> asac: Yes.  Riddell and regreening at least.
[11:46] <asac> Riddell: e1000?
[11:46] <asac> ;)
[11:46] <asac> Riddell: if you see packet loss please put your route -n to the bug
[11:46] <Riddell> asac: fortunately not
[11:47] <asac> Riddell: if eth0 is gone its obviously a driver issue. if wireless is the only iface used, its unlikely that slowness is a NM problem
[11:47] <asac> at least ii dont see how it could be :/
[11:50] <Riddell> I have no eth0 but I have something called pan0
[11:50] <asac> Riddell: but that doesnt show up in NM right?
[11:50] <asac> Riddell: pan0 :(
[11:51] <Treenaks> Riddell: pan0 is bluetooth-related
[11:51] <asac> Riddell: hal-find-by-capability --capability net.80203
[11:51] <Riddell> oh.  bluetooth.
[11:51] <asac> if that doesnt show up anything then NM cannot know your wired
[11:51] <asac> for wireless its: hal-find-by-capability --capability net.80211
[11:51] <Riddell> asac: that shows up nothing indeed
[11:52] <asac> for 3G mdoem its: hal-find-by-capability --capability modem
[11:52] <Riddell> the wireless one shows something
[11:52] <asac> Riddell: yeah. what chipset has your wired?
[11:53] <Riddell> 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection
[11:53] <Riddell> "Kernel modules: e1000e"  erk
[11:53] <asac> ha ;)
[11:53] <asac> i knew it :-D
[11:53] <asac> wasnts e1000e fixed?
[11:53] <asac> Riddell: is that driver loaded (e.g. lsmod | grep e1000) ?
[11:54] <persia> Yes, but the key to restore broken firmware wasn't pushed (IIRC)
[11:54] <asac> oh ... so Riddell has a broken firmware ;) ... not that cool
[11:54] <Riddell> asac: yes
[11:54] <Riddell> shows how often I use ethernet
[11:54] <asac> Riddell: ok i think you should talk to rtg
[11:55] <asac> Riddell: and your wireless issues are?
[11:55] <Riddell> asac: my wireless is all good
[11:55] <asac> ok. then there is no NM regression at least :)
[11:56] <Riddell> well other people have troubles we havn't got to the bottom of yet
[12:13] <liw> if I add translatable strings to my code, the .pot file needs updating; do I just re-create it from scratch using xgettext or what?
[12:14] <cjwatson> gettext supplies a Makefile that can do it
[12:15] <liw> /usr/share/gettext/intl/Makefile.in?
[12:16] <cjwatson> you don't want to copy it around by hand if you can help it ...
[12:16] <liw> or possibly /usr/share/gettext/po/Makefile.in.in, hmm
[12:16] <liw> cjwatson, yeah, I really really don't want hundreds of lines of excessively complicated Makefiles :)
[12:16] <cjwatson> I guess you aren't using automake
[12:16] <liw> this is for a Python program, so no
[12:16] <cjwatson> you could use gettextize
[12:16] <cjwatson> and see what it does and whether you can massage the result to be acceptable
[12:17] <cjwatson> usually you just leave its results in po/ and forget about it
[12:17] <cjwatson> to directly answer your original question, it ultimately comes down to recreating it using xgettext and using msgmerge to update the .po files
[12:17] <liw> . o O (someone needs to document this really well)
[12:18] <cjwatson> info gettext
[12:18] <liw> cjwatson, I have been reading that, and I find it to be confusing
[12:19] <cjwatson> while I sympathise with a detestation of autogenerated Makefiles, in this case it is orders of magnitude less wasted time than doing it by hand, IME
[12:19] <liw> might be because it's a complicated process, of course
[12:20] <liw> cjwatson, that's possibly true, but then I need to deal with the massive headache of keeping the autogeneration of the Makefile working
[12:20] <cjwatson> I find that easier than keeping the .pot/.po files working without that
[12:20] <liw> gettextize won't work without autotools being used, it seems
[12:21] <cjwatson> you could look at how debconf does it
[12:21] <cjwatson> it has a by-hand Makefile for this
[12:21] <cjwatson> copying somebody else's by-hand work is probably easier than duplicating it :)
[12:23] <liw> I return to my point that someone needs to document this well :)
[12:24] <liw> as far as I can see, there needs to be something that updates the .pot file with new strings (and removes old ones?), then based on that updates the .po files (adds missing strings, marks changed strings as fuzzy?); that doesn't sound like it should require autotools or hordes of Makefile magic
[12:28] <cjwatson> update .pot files with new strings => xgettext; update .po files => msgmerge; you also need something to compile .po to .gmo files; you might want to support 'make install' and/or 'make dist'; sometimes people want to disable i18n or enable only certain languages; and some people want to support systems where GNU gettext is not already installed
[12:29] <cjwatson> also some maintainers only want to rebuild .pot manually rather than automatically
[12:29] <cjwatson> or want to update it only if the .pot changed non-trivially (i.e. more than just the creation date or whatever)
[12:29] <cjwatson> (which avoids vcs noise)
[12:30] <liw> are .gmo files the same as .mo files or is this some fourth type of file?
[12:30] <cjwatson> once you do all of that you're actually not that far off the complexity of gettext's po/Makefile.in.in
[12:30] <cjwatson> info gettext C-s gmo
[12:32] <liw> ack, they're gnu's extended and embraced version of .mo, good :)
[12:36] <liw> cjwatson, all that complexity could surely be wrapped in tools less awful than autotools, I'm sure; anyway, I don't want or need most of the complexity, so I'll go some simpler route
[12:39] <mvo> liw: check out python-distutils-extra if you look for something that does the i18n in system cleaner
[12:42] <liw> mvo, that looks like useful for the parts that are involved in installing the .mo files; does it take care of generating the .mo files from .po files, too?
[12:42] <mvo> liw: yes
[12:42] <liw> cool
[12:42] <mvo> liw: it should do all that is required, if not, file a bug against it
[12:43] <mvo> (or let glatzor or me know about the problem)
[12:43] <liw> mvo, is it also involved in updating .po files from .pot?
[12:44]  * liw goes read docs
[12:44] <mvo> liw: yes, it should do all that, check gnome-app-install setup.cfg and setup.py for a example
[12:44] <mvo> liw: + po/POTFILES.in and you should be done
[12:45] <mvo> liw: it also supports desktop files and desktop file i18n
[12:45] <asac> Riddell: if people have troubles ask them if they are running a hybrid setup (meaning: 1 device managed in /etc/network/interfaces and the other in NM)
[12:45] <Riddell> asac: right
[12:45] <asac> Riddell: that setup is know to have metric issues i still have to sort somehow
[13:15] <liw> mvo, "setup.py build_i18n --merge-po" seems to require a po/POTFILES.in, which does not support wildcards; is that intentional?
[13:17] <mvo> liw: po/POTFILES.in is required, not sure about the wildcards, it uses intltool internally, not sure if that supports them or not (I guess not if you have problems with it)
[13:18] <liw> mvo, ah, so it's just intltool-update that uses that, ok
[13:18] <mvo> liw: yeah, its just a (thin) wrapper around the intltool* stuff
[13:19] <alkisg> mvo, has anyone reported that in intrepid beta update-manager  doesn't *ever* close itself but just hangs in the "ldconfig deferred processing" phase?
[13:20] <mvo> alkisg: yes - that bug is milestoned
[13:20] <alkisg> (ogra told me to tell you, he also saw that yesterday)
[13:20] <ogra> mvo, ah, great, i wasnt sure
[13:20] <mvo> bug 280236
[13:21] <ogra> mvo, btw i just removed gnome-screensaver and still see the issue ... i'll run a dbus-monitor session now to see if there are any events keeping it from proerly doing dpms
[13:21] <alkisg> mvo, ogra, thanks.
[13:22] <mvo> ogra: oh, that is interssting
[13:24] <liw> mvo, yay! ./usr/share/locale/fi/LC_MESSAGES/systemcleaner.mo
[13:25] <mvo> liw!
[13:26] <Treenaks> Does anyone know from which package network-manager(-gnome?) gets the available UTMS/GPRS network list?
[13:26] <Treenaks> I can't find it in network-manager{,-gnome}
[13:27] <alkisg> mvo, and another somewhat serious one, gparted (and the installer) can't create smaller partitions on empty disks (tried on different 3 PCs). I had to create 1 full-disk partition, shrink it, then create others and then run the installer...
[13:31] <mvo> alkisg: oh, is that reported already?
[13:32] <alkisg> mvo, I saw something similar reported, but only for the installer, not the backend lib which is used (and I think the fault is there... libparted is it?)
[13:33] <cjwatson> alkisg: I've never heard of such a bug (I co-maintain the installer); it must be hardware-specific. Can you refer me to the bug number?
[13:33] <alkisg> It's usually reported as ubiquity crashed, with auto-collected debug data
[13:34] <alkisg> I've sent one myself, and was considered a duplicate
[13:34] <alkisg> let me find it...
[13:35] <cjwatson> I'm not sure why that would be a crash, unless there's something more than what you described above
[13:35] <lool> liw: Good :)
[13:35] <lool> liw: Do you need sponsoring for system-cleaner with i18n?
[13:36] <liw> lool, when it's done, yes
[13:36] <alkisg> This is the main one: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/260001 (I think it's the same symptoms as mine),
[13:36] <cjwatson> configure_bootloader has nothing to do with creating partitions!
[13:36] <alkisg> And this one's mine: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/278019
[13:37] <alkisg> cjwatson, read mine, I'm not really sure if they're the same
[13:37] <cjwatson> this sounds like the problem where libparted sometimes forgets to change the partition type
[13:37] <alkisg> cjwatson, yes, that's what I got
[13:37] <cjwatson> I've tried to figure that out multiple times and haven't got anywhere; I can give it another shot, I suppose
[13:38] <cjwatson> describing it as "can't create smaller partitions on empty disks" is a bit overly broad though :)
[13:38] <cjwatson> it only happens if you're creating the partition at the same position as something that used to be NTFS
[13:38] <alkisg> But I also tried (in another system) to just create an ext3 partition with 100Gb size (disk = 640Gb), and it couldn't. Not the installer, not gparted.
[13:38] <cjwatson> alkisg: that's a different problem and I'd like to know about it
[13:38] <cjwatson> (with logs etc.)
[13:39] <cjwatson> seriously, I create partitions less than the size of the disk all the time :)
[13:39] <alkisg> cjwatson, ouch, this morning I've setup the system, and it's on a lab I'm not responsible for...
[13:39] <cjwatson> although not on 640GB disks; it could be an overflow of some kind
[13:39] <alkisg> It has 2 disks, I'll remove one and reproduce it, but I can only do it next weekend. Is this ok?
[13:39] <cjwatson> it'll have to be :)
[13:39] <cjwatson> thanks
[13:40] <alkisg> thank you guys.
[13:40] <cjwatson> I'll see if I can replicate the NTFS partition type thing today
[13:41] <Treenaks> (answer to my question: libmbca + mobile-broadband-provider-info)
[13:56] <AnAnt> Hello, how can I make some look at a bug that was filed a month ago: bug #267217
[13:56] <AnAnt> ?
[13:59] <Laney> *make* someone?
[14:00] <kwwii> first he'd have to find me :p
[14:02] <asac> is intltool really not installable on hardy amd64 ;)? my NM ppa build thinks it cannot install it :/
[14:06] <kwwii> seb128: I just put some new packages in my ppa: ubuntu-wallpapers, human-theme, and ubuntu-artwork
[14:07] <kwwii> seb128: so once they are tested a bit I will be bugging you :-)
[14:07] <kwwii> seb128: if nothing crazy happens these will be the last updates
[14:07] <Keybuk> killall pulseaudio
[14:07]  * Keybuk makes the world a better palce
[14:08] <ogra> haha
[14:08] <Keybuk> it was doing that thing where no other application can start, again
[14:08] <seb128> kwwii: ok
[14:10] <ogra> seb128, btw, the volume control applet and brigthness are applet not closing their rulers anymore by default, is that a upsteam decision ?
[14:10] <ogra> meh
[14:10] <ogra> seb128, btw, the volume control applet and brigthness are applet not closing their rulers anymore by default, is that a upsteam decision ?
[14:10] <seb128> ogra: dunno about the brightness but the volume one is an upstream choice
[14:10] <ogra> (you need to click the applet again to close it)
[14:11] <Treenaks> ogra: instead of working menu-like, you mean?
[14:11] <ogra> while i appreciate it on mobile because its helpful if you dont hit the rules first time with your finger, i find it pertty annoying on laptop/desktop
[14:11] <ogra> *ruler
[14:11] <ogra> Treenaks, yep
[14:13] <seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=553249
[14:14] <ogra> doesnt look like anyone will fix it in time, thats indeed quite bad with autohiding
[14:15]  * ogra personally just saw it as an annoyance he could live with, just wanted to know it was intentional
[14:27] <ogra> mvo, sooo, removing gpm fixes the issue, looking at the log i see xorg loads DPMS for the intel driver, i guess we have a concurring situation between xorg and gpm both wanting to handle DPMS (we had that before)
[14:27] <ogra> tjaalton, ^^^
[14:27]  * ogra will now try to put something in place that unsets DPMS for X and instal gpm again and see if that fixes it as well to prove that
[14:29] <tjaalton> ogra: xset -dpms
[14:29] <ogra> tjaalton, ah, right, i was starting to play with hal-set-property stuff in gdm Init :)
[14:30] <ogra> thast easier indeed
[14:31] <ogra> and probably more effective as well :)
[14:33] <mvo> thanks ogra, could you please add that to the bugreport?
[14:33] <ogra> mvo, if i'm sure ...
[14:34] <ogra> i just remembered that clash from before, i'm not sure yet that it is the cause, and compiz surely plays a role as well, as switching to metacity solves it
[14:35]  * ogra twiddles thumbs waiting for gpm
[14:38] <ogra> hmm
[14:41] <ogra> no gpm reaction ...
[14:43] <ogra> hah, now it kicked in
[14:43] <ogra> mvo, so "xset -dpms" makes it work ...
[14:44] <ogra> tjaalton, can we default to have the driver not using it ?
[14:44] <ogra> though i guess that gets us probs in gdm
[14:45] <persia> If the issue only happens in a compiz session, perhaps compiz could xset -dpms ?
[14:45] <ogra> yeah, hat sounds sane
[14:45] <ogra> *that
[14:45] <jcristau> actually it doesn't
[14:47] <persia> jcristau, I trust you more than I when it comes to X.  Why is it not sane?
[14:47] <jcristau> maybe i just don't understand the problem though..
[14:47] <ogra> jcristau, the driver wanting to set xorg dpms values concurring to gpm wanting to do the same
[14:48] <persia> But only with compiz?  With metacity, this issue doesn't exist?
[14:48] <tjaalton> DPMS in xserver has been enabled by default two years ago
[14:48] <Treenaks> ogra: (is this gpm the console mouse thing?!)
[14:48] <ogra> persia, right
[14:49] <ogra> Treenaks, gnome-power-manager ...
[14:49] <Treenaks> ogra: ah, sorry ok :)
[14:49] <emgent> evening
[14:50] <ogra> jcristau, we had that prob before though at times where dpms was handled by gnome-screensaver, that functionallity moved over to gpm within the last year
[14:50] <jcristau> i think it'd be more sane to understand the bug and fix it than to disable dpms..
[14:50] <ogra> you dont disable it
[14:51] <ogra> gpm stil cares, you just move the trigger out of X
[14:51] <persia> Well, you're disabling it in X, and expecting something else to handle it.
[14:51] <ogra> right
[14:51] <jcristau> there's an interface for that in some extension, iirc
[14:51] <persia> On the other hand, if X is doing it, and doing it right, perhaps it makes more sense for other things not to do it.
[14:52] <ogra> persia, that would mean to hack up hal/gpm
[14:52] <ogra> either hal/gpm is broken in combo with compiz and dpms or X is ...
[14:53] <ogra> well
[14:53] <persia> ogra, Indeed.  Something is the culprit.
[14:53] <ogra> s/X/the intel driver/
[14:54] <jcristau> the driver, really?
[14:54] <ogra> i dont care on which side we fix it, atm i'm just trying to nail down the issue properly :)
[14:54] <persia> :)
[14:54] <ogra> jcristau, it could as well be that gpm or hal dont use the right backend interface ...
[14:55] <ogra> if you say there is an interface
[14:56] <ogra> all i can say that switching off either of the dpms handlers fixes the issue
[14:56] <ogra> +is
[14:57] <jcristau> they probably do, if it works without compiz
[14:59]  * ogra looks at compiz plugins
[14:59] <pitti> zul: was linux-xen really meant to be uploaded to intrepid? It's version number is 2.6.27-1~ppa2
[15:00] <zul> pitti: no it wasnt
[15:00] <pitti> zul: if it was a dput error, I can just reject it; if it was deliberate, please fix the version
[15:00] <pitti> ah, ok
[15:00] <zul> misfire on my part
[15:00] <pitti> alright, saves me some reviewing :)
[15:00] <pitti> zul: thanks
[15:00] <zul> np
[15:02] <pitti> so, I accepted libv4l source and binaries in the same publisher cycle; kees, what's necessary now to make v4l work again?
[15:02] <StevenK> pitti: Ah, since you're here. Now do we want to kill gnutls13 dead, or just demote it to universe?
[15:02] <pitti> StevenK: oh, everything in main uses 26 now?
[15:02] <StevenK> pitti: No, there's a bunch of stuff in main that uses 13
[15:03] <pitti> StevenK: I'll demote it for now; if someone wants to do the work of completing the transition, that would be good, but not really critical
[15:03] <StevenK> pitti: All up, it's 59 source packages, main + universe
[15:03] <persia> I think we should target getting it killed completely.  Orphans in universe tend to get the least possible support.
[15:03] <pitti> should be like 5 or 6 packages in main
[15:03] <ogra> hmm, nothing in compiz touches dpms
[15:03] <pitti> persia: true that
[15:04]  * StevenK checks
[15:04] <pitti> StevenK: I just finished doing new, I'm fine with doing the transition for main right now
[15:04] <pitti> oh, erm, cjwatson, do you know whether we have a release meeting today?
[15:04] <StevenK> pitti: Meh, I have a script that can do and upload it in about 5 minutes.
[15:05] <pitti> StevenK: oh, ok, please do that then :)
[15:05] <StevenK> pitti: Longer if you'd rather test them and confirm they don't pull in 13
[15:05] <pitti> StevenK: I don't want to stop you, just wanted to take some bits off your shoulders
[15:05] <StevenK> Shrug
[15:05]  * lamont mutters at NCommander that yes, the current thinking is that there is a bug in the NPTL/hppa implementation
[15:05] <StevenK> I *like* doing NBS
[15:06] <cjwatson> pitti: as far as I know; it's on the calendar
[15:06] <pitti> StevenK: ok, please go ahead then; seems I need to prep for the meeting, and I still need to do SRU, too
[15:07] <pitti> StevenK: that's 59 binaries, sources looks more like 30
[15:07] <StevenK> I had it has 59 sources
[15:07] <pitti> hm, maybe
[15:07] <StevenK> 9 sources in main
[15:08] <pitti> StevenK: anyway, gnutls13 and opencdk10 were removed from Debian long ago, so if anything breaks, they have the patches
[15:08]  * ScottK supports persia's suggestion about killing it.
[15:09] <pitti> agreed
[15:10] <james_w> I think 13->26 might have been one where the API changed but the -dev package didn't change name because the fallout was small
[15:10] <pitti> right, it stayed libgnutls-dev
[15:10] <persia> james_w, That would mean we have about 60 packages that might FTBFS.  Let's try to get them all updated by Monday.  Between StevenK, ScottK, pitti, you, and I we ought be able to do it.
[15:11]  * StevenK has the list
[15:11] <james_w> persia: let me find the transition bug first
[15:11]  * StevenK is about to deal with main
[15:11] <pitti> agreed; upload them all wholesale, and then collect the pieces which broke
[15:11] <StevenK> All sixty of them?
[15:11] <james_w> persia: that should tell us what did in Debian, and whether we have the fixed packages
[15:11] <ScottK> Sure.
[15:11] <StevenK> Okay
[15:11] <StevenK> I can do that soonish
[15:11] <mvo> ogra: I suspect it might be because compiz switches on some 3d stuff that then makes the dpms more sensitive or something
[15:12] <pitti> StevenK: it might be worth going through them and compare if Debian just has a new revision; then we should sync instead
[15:12] <persia> StevenK, Thanks.  And the rest of us will look at FTBFS fallout, and help port.
[15:12] <ogra> mvo, yeah, might be
[15:12] <james_w> pitti: did libv4l go to main?
[15:12] <StevenK> pitti: That's a little harder
[15:12] <pitti> StevenK: unless they did something weird, of course
[15:12] <ogra> mvo, at least in gpm there were no changes to dpms since nearly a year according to the changelog
[15:12] <pitti> james_w: no, universe; is there an MIR for it already?
[15:12] <StevenK> pitti: It's very easy for me to bump them buildX
[15:12] <StevenK> to buildX
[15:12] <pitti> StevenK: ok, do that then; we can check for syncs for the ones which FTBFSed
[15:12] <StevenK> Right
[15:12] <james_w> pitti: I don't think so, so that would be the next step
[15:13] <StevenK> It's a little more work, but not much
[15:13] <StevenK> I'm just going to assume they build
[15:13] <pitti> StevenK: ok, convinced
[15:14] <StevenK> Using changelog entry of "No-change rebuild for libgnutls13 -> libgnutls26 transistion."
[15:14] <StevenK> Unless james_w finds a bug first
[15:14] <james_w> give me two minutes, I should be able to
[15:15] <StevenK> james_w: If I put the bug number in the changelog entry, the janitor will try and close tasks for each of those packages in that bug
[15:16] <StevenK> I'm also ignoring gnash, since I know it FTBFS, and asac will update it.
[15:16] <james_w> http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2008-May/001420.html
[15:17] <james_w> lynx is usually the pain
[15:17] <asac> StevenK: it should work ... try: bzr branch lp:~gnash/gnash/ubuntu.head; cd ubuntu.head; ./debian/build_head
[15:17] <StevenK> I was talking about 0.8.2-0ubuntu3
[15:18] <james_w> StevenK: but I can't find a tracking bug, so please go ahead and we'll work with the fallout
[15:19] <StevenK> james_w: Aye
[15:20] <StevenK> I can make a bug
[15:21] <persia> StevenK, Why not only put the packages that FTBFS in the bug, due to the "Can't unsubscribe" bug in LP.
[15:21] <StevenK> persia: That works
[15:21] <StevenK> I'll make a bug of the ones that FTBFS
[15:22] <persia> Please subscribe the rest of us to it :)
[15:22] <StevenK> Heh, yes
[15:23] <ScottK> Also subscribe NCommander to it.  He loves FTBFS.
[15:24] <StevenK> asac: Or I can just upload the bzr head of gnash to intrepid :-P
[15:24] <persia> Hrm.  Maybe just subscribe cruft-busters : that's most of us, and includes other interested parties.
[15:25] <StevenK> persia: Good point
[15:26] <james_w> StevenK: subscribe me (james-w) as well please
[15:27] <persia> james_w, You're not a cruft-buster?
[15:27] <james_w> nope
[15:29] <cjwatson> bryce: 207881 recently got reopened and is on the release-critical list
[15:32] <cjwatson> TheMuso: are you on top of 204272? it has zillions of duplicates and looks serious
[15:32] <ogra> kwwii, whoops, you renamed NewHuman ?
[15:32] <StevenK> pitti, persia, james_w, ScottK: Uploading
[15:33] <pitti> go, StevenK, go :)
[15:33] <persia> StevenK, Thank you :)
[15:33]  * StevenK grins
[15:33] <persia> Puts you over 200, doesn't it?
[15:35] <StevenK> persia: Or very close ot
[15:35] <StevenK> s/ot/to/
[15:38] <cjwatson> bryce: 274045 appears to have a patch, if you haven't seen it
[15:40]  * StevenK pushes packages uphill
[15:42] <ion_> Does anyone feel like sponsoring http://launchpadlibrarian.net/18250664/iconv.debdiff to fix LP #278195? Thanks.
[15:42] <tjaalton> cjwatson: upstream doesn't test with old chips, so regressions are possible
[15:44] <StevenK> Haha
[15:44] <StevenK> curl has already failed on sparc
[15:46] <StevenK> Right, curl has also failed on lpia and powerpc, so we have our first victum
[15:46] <StevenK> Er, victim
[15:47] <StevenK> configure.ac:105: required file `./config.guess' not found
[15:47] <StevenK> configure.ac:105: required file `./config.sub' not found
[15:47] <StevenK> Sigh
[15:47] <tjaalton> wha-at, we have nouveau now?
[15:48] <ogra> looks like :)
[15:48] <persia> nifty
[15:48] <bugabundo_work1> ogra: hi
[15:48] <tjaalton> well, AIUI it doesn't even build
[15:49] <tjaalton> libdrm-dev(inst 2.3.1-0build1 ! = wanted 2.3.1+git+20080706+401f77a-1)
[15:49] <tjaalton> hehehe
[15:49] <bugabundo_work1> ogra: ping
[15:49] <ogra> tjaalton, well, someone synced it (looks like slangasek )
[15:49] <ogra> bugabundo_work1, yes ?
[15:49] <persia> RAOF, Can this be made to work?
[15:49] <bugabundo_work1> ogra: can you help filipegarcia with his touch device?
[15:50] <filipegarcia> hello
[15:50] <ogra> probably, lets take that to #ubuntu-mobile though
[15:50] <bugabundo_work1> maybe we can go to another #... its kinda offtopic here
[15:50] <bugabundo_work1> ok ogra... thanks
[15:50] <filipegarcia> yes
[15:50] <filipegarcia> thank you
[15:51] <tjaalton> persia: not without a newer libdrm and drm modules for the kernel
[15:52] <persia> tjaalton, That was my previous understanding, but I figured that the maintainer of the nouveau PPA would probably have some idea why we have a nouveau sync :)
[15:52] <StevenK> superm1: Can you track down ussp-push at some point, it's only thing left for bluetooth
[15:52]  * StevenK goes to bed. I'll deal with fallout from build failures in the morning
[15:54] <aliases123> hi um. this might be unrelated but i thought i would raise this anyway here.... some of the pdfs http://www.ubuntu.com/system/files/u35/Openbravo-final.pdf has the title microsoft powerpoint at the top.
[15:54] <aliases123> i'm considering filing a bug.
[15:55] <radix> mvo: hi, can I bug you to take a look at a smart patch?
[15:56] <asac> mdke: there? -> http://people.ubuntu.com/~asac/3g-wizard-screenshots/
[15:57] <tjaalton> persia: I'm trying to find the bug number..
[15:57] <mvo> radix: sure
[15:57] <radix> mvo: it's bug #279343
[15:58] <radix> mvo: it's a debdiff to include an upstream version 1.1.1, which are some fixes that are important for the usage by landscape
[16:00] <radix> (but they're general bug fixes, not really specific to landscape)
[16:03] <mvo> radix: reading it now
[16:03] <radix> awesome, thanks
[16:06] <mathiaz> mvo: could you review the branch I've pushed for bug 84918?
[16:09] <mvo> mathiaz: will do, its on my list for today
[16:09] <mathiaz> mvo: great - thanks !
[16:09]  * mvo just needs to finish a update-manager upload
[16:18] <tseliot> mvo: will my script be included too?
[16:26] <pitti> mdz: TBH, I'd just upload the g-p-m fix; easy enough to revert if it causes regressions...
[16:27] <mdz> pitti: ok
[16:27] <mdz> pitti: done
[16:27] <pitti> mdz: do you want to send the CFT, or shall I take that?
[16:27] <mdz> pitti: if you could do it, I would be grateful, as my wrists are quite sore already after yesterday
[16:28] <pitti> mdz: no problem, consider it done
[16:28] <mdz> pitti: I just saw the "new improved logout button" update-notifier action
[16:29] <mdz> pitti:  but pressing "perform this action now" has no visible effect
[16:29] <mdz> s/perform/run/
[16:29] <pitti> mvo: ^ hmm; shouldn't gconf changes be visible immediately? or does it need a panel restart?
[16:29] <mvo> Riddell: have you made up your mind about kdm-kde4 ?
[16:29] <pitti> mvo: if the latter, mabye that can become part of the script?
[16:29] <pitti> mdz: does killall gnome-panel update it for you?
[16:29] <mdz> pitti,mvo: I just restarted my panel and it is still unchanged
[16:30] <Riddell> mvo: mm, what was the question again?
[16:30] <mvo> mdz: none at all? that is odd, it should present a dialog in both in success or failure case
[16:30] <mvo> mdz: do you have /usr/share/gnome-panel/migrate-fusa-config.py ?
[16:30] <mvo> mdz: is that 755 ?
[16:30] <mdz> mvo: -rw-r--r-- 1 root root 2486 2008-10-10 13:47 /usr/share/gnome-panel/migrate-fusa-config.py
[16:31] <mvo> Riddell: you mentioned earlier it should be purged on upgrade?
[16:31] <mdz> good guess
[16:31] <mvo> mdz: thanks, that explains it :/
[16:31] <mvo> mdz: could you make it 755 and see if that makes it more happy?
[16:32] <mvo> mdz: I will fix this here right away (and wonder why it worked for me)
[16:32] <mdz> mvo: now I get a dialog: "no logout button found"
[16:32] <pitti> mvo: locally built package, I figure
[16:32] <mvo> mdz: aha! what does your panel look like? did you customize it before?
[16:33] <mdz> mvo: I have added some applets
[16:33] <mdz> mvo: but I have a fusa applet and a logout applet
[16:33] <kees> pitti: what's left are the libv4l patches that have been collected for various applications -- I think pgraner and wouter attached details to the bug and sent to ubuntu-devel
[16:34] <Riddell> mvo: kdm (in intrepid) and kdm-kde4 (in hardy) both contain /etc/kde4/kdm.  kdm in intrepid conflicts with kdm-kde4 in hardy.  will kdm-kde4 get removed first then kdm installed?  in which case purge is good
[16:34] <mvo> mdz: it is (currently) very careful, if the logout button is in a different place than in the original config, it will fail. could you sent me a "gconftool --dump /apps/panel" please?
[16:35] <mdz> mvo: it is at the upper right, and I doubt it has moved...
[16:35] <mdz> mvo: but this is a very old install (upgrade from Debian) so anything is possible
[16:35] <mdz> mvo: emailed
[16:36] <mvo> mdz: the gconf dump will tell me I think. I can make the checks less strict I think
[16:36] <pitti> mdz: CFG sent
[16:36] <pitti> mdz: CFT, too
[16:37] <mdz> pitti: thank you
[16:37] <mvo> Riddell: hm, I'm not 100% sure
[16:37] <pitti> mvo: can we replace the logout applet with fusa regardless of its position?
[16:38] <Riddell> mvo: lets not purge then
[16:38] <mvo> Riddell: ok
[16:38] <mvo> pitti: yes
[16:38] <Riddell> I'll make sure to test upgrades do the right thing with init scripts and updating /etc/kde4/kdm
[16:41]  * pitti doesn't envy the buildds now; they got StevenK'ed (gnutls), doko'ed (hardy SRUs for gcc/gcj/gnat), and will now be ArneGoetje'd (langpacks)
[16:42]  * jdong is having his dreams of a non-X11-attached trackerd shattered
[16:43] <jdong> is there a way to start dbus-daemon properly at the CLI?
[16:45] <superm1> wgrant, have you already looked to see if bryce's patch to GPM improved the situation on your hardware?  my mirror will be lagging by a day once it's done building
[16:46] <luisbg_> superm1, <ScottK> Kudos for superm1 for the work he's done so far, but we're still at zero bluetooth capability in KDE currently.
[16:46] <luisbg_> a few minutes ago in #ubuntu-meeting
[16:47] <mvo> pitti: http://paste.ubuntu.com/56025/ is the current text for the notification - do you think there should be more?
[16:49] <mvo> mpt: : I would like your opinion on http://paste.ubuntu.com/56025/  and suggestions for improvements :)
[16:51] <mpt> "functionality", eh
[16:51] <superm1> luisbg, what meeting is going on in there right now?
[16:51] <mvo> mpt: not a good word?
[16:51] <mpt> mvo, no
[16:51] <pitti> cjwatson: I'll change the jockey handler to succeed and display itself only if the version > 2:8.532, FYI; then it will auto-fix itself once we put a fixed one into intrepid-updates
[16:51] <mpt> mvo, why are we even asking this question?
[16:52] <mpt> If we weren't confident that it's a better design, we shouldn't be doing it at all
[16:53] <mvo> mpt: that is a long story, basicly because we don't want to mess with the users configuration automatically without further questions. and also because people might have shared /home paritions where this change breaks when they boot a older version (or a different version) of linux
[16:53] <mpt> mvo, hang on, I need to yell at Ted about this, brb
[16:53] <mvo> mpt: pitti and tedg have more background on this, I'm little more than the messenger
[16:53] <pitti> cjwatson: oh, except that jockey is currently too dumb to do that; but well, we'll need a jockey SRU anyway to add the -modaliases dependency, so it wouldn't actually help
[16:53] <mvo> mpt: haha
[16:54] <stefanlsd> Anyone working on bug #274049
[16:54] <pitti> mvo: I think it should also say "Please note that after that, your configuration will not work any more with earlier Ubuntu releases."
[16:54] <stefanlsd> heh. not the best description :)
[16:54] <cjwatson> mpt: the shared /home thing really is important, and is hard for the software to know about
[16:57] <mvo> pitti: right, that needs to be in too, maybe mpt can come up with a more positive wording for it
[16:57] <mpt> ok, so it's not a new improved logout button, there is no longer a logout button...
[16:57] <pitti> there is, it just became less useful
[16:58] <mpt> There is? Why? What does it do?
[16:59] <dholbach> stefanlsd: updated the bug
[16:59] <dholbach> stefanlsd: nothing life-threatening
[17:00] <stefanlsd> dholbach, cant log into my X
[17:00] <dholbach> stefanlsd: I don't think that's related
[17:01] <seb128> mpt: why? because upstream has applets to open the 2 dialogs they use
[17:01] <mpt> I don't understand
[17:02] <mpt> Ted just told me that the logout button is not an applet, it's compiled into the panel
[17:02] <ogra> yep
[17:02] <mpt> so if we're removing it from the Intrepid version of the panel
[17:02] <mpt> then we don't need to change anyone's configuration at all, it just won't appear in Intrepid.
[17:02] <bluefoxicy> Hey guys
[17:03] <bluefoxicy> Scott Kaplan is willing to give a statement releasing the Wilson-Kaplan algorithm implementations as LGPL
[17:03] <seb128> mpt: we don't want to remove the upstream code because it's creating divergence and some upstream guys like the upstream way and would be complaining if we were doing that in ubuntu
[17:03] <bluefoxicy> these work much better than LZO for compressed memory
[17:03] <ogra> mpt, and what would provide the logout button then ? note that fusa breaks in real multiuser setups like ltsp, most ltsp users i know deliberately remove fusa
[17:04] <seb128> mpt: we don't use it but the code is still there
[17:04] <mpt> ogra, the design is that Log Out, Shut Down etc are in the status menu *instead of* a Log Out button.
[17:04] <mpt> So asking what the Log Out button is a non-sequitur.
[17:04] <mpt> What the Log Out button should do, rather.
[17:05] <ogra> indeed
[17:06] <mpt> seb128, so why don't those upstream guys download and install the upstream version of gnome-panel instead?
[17:07] <mpt> If they didn't say anything when Ted posted about our design originally, why are they trying to mess it up now?
[17:07] <seb128> mpt: are you suggesting we want to discourage upstream hackers to use ubuntu?
[17:07] <mpt> seb128, no, I just don't understand what they're proposing.
[17:07] <seb128> mpt: there is a miscommunication there, that has nothing to do on the design, we just keep the upstream code available but don't use it
[17:08] <mpt> I assume they're not proposing that Ubuntu offer two different panel items for logging out.
[17:08] <seb128> mpt: upstream doesn't use any session or user switching on their gnome-panel layout
[17:08] <seb128> mpt: they don't suggest anything for ubuntu
[17:08] <mvo> even if we compile out the logout button we still need to think about setups without the fusa applet and have a way to auto add it there
[17:08] <seb128> mpt: the green man launcher is an upstream object though
[17:08] <mvo> e.g. I don't have fusa on my laptop and would be suprised if my logout button disappers
[17:09] <mpt> mvo, sure, but that's what the upgrade script does, right?
[17:09] <mpt> it ensures that the menu is there
[17:09] <seb128> mpt: the issue there is upgrade, not new installs
[17:09] <seb128> mpt: right, because we have been abusing the upstream object before to open a custom ubuntu session dialog
[17:09] <seb128> mpt: now we dropped this session dialog so the object opens the upstream dialog
[17:10] <seb128> mpt: we need to figure what to do what the object is in the configuration before upgrade
[17:10] <seb128> mpt: is that clear?
[17:11] <mpt> seb128, not show it when running Intrepid.
[17:12] <wtgee> wow, the latest round of updates absolutely borked my comp
[17:12] <mpt> (But still show it if, for example, using the same home folder with 8.04 or another distribution.)
[17:12] <wtgee> Basically it killed all of gnome
[17:13] <mpt> mvo, are you able to include illustrations in this question? That would really help
[17:14] <mvo> mpt: sure, give me a sec, I can make a screenshot
[17:18] <seb128> mpt: "not show it when running Intrepid.", that's what mvo's tool does basically
[17:19] <mvo> mpt: http://people.ubuntu.com/~mvo/tmp/Screenshot-Untitled Window.png
[17:19] <wtgee> Did anyone else just get borked on updates?
[17:20] <mpt> mvo, http://paste.ubuntu.com/56038/
[17:21] <tseliot> mpt: try with this link: http://people.ubuntu.com/~mvo/tmp/Screenshot-Untitled%20Window.png
[17:22] <mpt> tseliot, thanks, I saw it
[17:22] <mpt> (Deskbar FTW)
[17:22] <mvo> mpt: the tools we have to show this can't handle inline images currently. sorry for this
[17:23] <mpt> mvo, oh, what did you mean by including illustrations?
[17:23] <mvo> mpt: I thought you wanted a illustration about what it looks like currently :)
[17:23] <mpt> ahhh
[17:23] <mpt> :-)
[17:23] <tseliot> it won't look as good as in the screen shot but it's doable with debconf
[17:24] <mpt> mvo, can you at least change the text? "Run this action now" is a bit dire
[17:24] <mpt> the button text, I mean
[17:24] <mpt> (and what does "Close" do?)
[17:24] <mvo> mpt: that needs code changes, but it can be done.
[17:24] <mvo> mpt: close closes the dialog
[17:26] <mpt> Ok, so no illustrations, but the same text: http://paste.ubuntu.com/56040/
[17:30] <bryce> slangasek, cjwatson: regarding the -fglrx issue (bug 247376), if it does come in post-release, there is the question of if we're going to go ahead with an SRU of it.
[17:32] <Keybuk> bryce: I have a very strange error message when trying to run an X application
[17:32] <mvo> mpt: ok, I start adding code to make the button configurable, but it will be "replace" and "close" I'm afraid. I put this on the list of things to discuss at uds so that we can make the whole thing more flexible
[17:32] <Keybuk> "Maximum number of clients reached"
[17:32] <cjwatson> bryce: we should just not promise that we'll do so
[17:32] <cjwatson> bryce: that way we have the flexibility of deciding later
[17:32] <Keybuk> quest scott% xterm
[17:32] <Keybuk> Maximum number of clients reachedxterm Xt error: Can't open display: :0.0
[17:35] <cody-somerville> Keybuk, I had that the other day
[17:35] <cody-somerville> Keybuk, I had to restart to fix it
[17:35] <Keybuk> this is the third of fourth time I've had it in the last few days
[17:35] <mpt> mvo, ok
[17:35] <Keybuk> since upgrading to Intrepid, basically
[17:36] <bryce> Keybuk: yep there's a bug open on that; kees had run into it earlier.  Unfortunately not an easy thing to fix
[17:37] <Keybuk> bryce: why is the maximum number so low?
[17:37] <Keybuk> xlsclients says I have 28 (if I open one more xtern, I can't run xlsclients)
[17:38] <kees> Keybuk: the number is 256; strange that you've hit it so quickly.  I wonder why xlsclients is lying to you so hard.
[17:38] <bryce> Keybuk: I don't remember what the exact number is but it's considerably larger than that
[17:38] <bryce> thousands iirc
[17:38] <bryce> ok, not quite thousands ;-)
[17:39] <mvo> mathiaz: merged with slight adjustment (10auto-update -> 20auto-update to win over 10periodic)
[17:39] <kees> Keybuk: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/260138
[17:39] <Keybuk> I was just looking at 263211
[17:39] <Keybuk> which suggests gnome-screensaver is leaking client connections which it's marked as permanent
[17:39] <mathiaz> mvo: great - thanks.
[17:40] <Keybuk> xrestop does indeed say I have 255 clients
[17:40] <Keybuk> whereas xlsclients clearly lies
[17:40] <Keybuk> bug #263211
[17:40] <Keybuk> Yes, I've been doing some debugging too, and in my setup gnome-screensaver is the culprit as well. Specifically it calls gnome_bg_create_pixmap() (from libgnome-desktop) with root == TRUE, which ends up creating a new connection to the X server, calling XSetCloseDownMode() to change to RetainPermanent, and then disconnecting. And in that case the X server keeps the client data structures around forever.
[17:41] <Keybuk> slangasek: I'd like to raise this as Release Critical ?
[17:41] <kees> Keybuk: ewwww
[17:42] <slangasek> there's a maximum-client limit for X?
[17:42] <slangasek> eew?
[17:42] <cjwatson> Keybuk: I've approved the bug nomination
[17:42] <cjwatson> eww> seconded, I never knew that
[17:43] <Keybuk> I guess in the 70s you couldn't fit 256 windows in memory :P
[17:43] <Keybuk> of course, the fact gnome-screensaver is consuming them all after just a day or so is doubleplusbadw
[17:43] <kees> slangasek: I meant by "eww" in response to the leak, not the rc-request.  :)
[17:44] <mathiaz> what's the state of autopkgtest? Is this still run?
[17:45] <Keybuk> bryce: I don't suppose there's a way to tell X to free a client? :p
[17:47] <persia> mathiaz, It hadn't been run at the time of the last QA Team meeting.  heno was looking into scheduling a run.
[17:48] <slangasek> Keybuk: perhaps it's specific to your screensaver choice?
[17:48] <Keybuk> slangasek: I'm using the F-Spot Photos screensaver iirc
[17:49] <slangasek> I have a theory
[17:49] <slangasek> :-)
[17:50] <mathiaz> persia: ok - the dovecot package has some tests. But the ones in qa-regression-testing are newer/better. So I was wondering if the debian/tests/ could just be dropped from the package.
[17:50] <bryce> Keybuk: not sure.  I'd use pkill myself ;-)
[17:50] <Keybuk> bryce: there's no process for these clients
[17:50] <persia> mathiaz, I'd rather not drop debian/tests, just because I'm a believer in robust QA, with many different ways of testing stuff.  On the other hand, if those tests are broken...
[17:50] <Keybuk> slangasek: I just set the screensaver to blank screen, and activated it a bunch of times
[17:51] <Keybuk> that seems to be still exhausting the clients
[17:51] <mathiaz> persia: well - they're not broken AFAICT.
[17:51] <cjwatson> mathiaz: all other things being equal, it's a better model to have tests in the packages themselves than in some separate repository (that has to be kept in sync as things change, etc.)
[17:51] <cjwatson> mathiaz: so I think we should update debian/tests/ rather than removing it
[17:52] <mathiaz> jdstrand: kees: ^^?
[17:52] <mathiaz> does the current tests in q-r-t work with autopkgtests?
[17:52] <kees> afaik, there is nothing actually _running_ the tests in debian/tests/, so it doesn't do any good there
[17:52] <cjwatson> kees: that would just require starting up autopkgtest again
[17:53] <kees> they're not build-time tests, they're run-time tests, that need all sort of other deps to run, etc
[17:53] <kees> cjwatson: right -- that's the main question I think -- is autopkgtest operational?
[17:53] <cjwatson> kees: heno would know; I don't see an obvious reason why it shouldn't be
[17:54] <mathiaz> kees: if autopkgtest is operational should the tests/ in the package be updated to match the one in q-r-t?
[17:54] <jdstrand> and, I'd have to check for dovecot specifically, many tests in q-r-t are destructive, and not necessarily written for running outside of a chroot/vm
[17:54] <mathiaz> kees: or the tests be moved from q-r-t to debian/tests/ ?
[17:55] <mathiaz> jdstrand: I think that's the environmet autopktest is designed for
[17:55] <kees> mathiaz: yes, until there is a strong censensus about how autopkgtest works, I want all the q-r-t tests in one place: the bzr repo.
[17:55]  * jdstrand hasn't used autopkgtest yet
[17:55] <kees> mathiaz: the security team uses them for testing things all the way back to dapper, so i'm against splitting stuff out into separate packages.
[17:57] <Keybuk> bryce, slangasek: http://paste.ubuntu.com/56045/
[17:57] <Keybuk> gnome-screensaver seems to consume 2 clients every activation
[17:58] <Keybuk> on my laptop it seems to consume 1
[17:58] <kees> Keybuk: yeah, confirmed, I see 1 per activiation.
[17:58] <Keybuk> obvious difference there might be that my desktop has two monitors, so it simply consuming clients twice as fast
[17:59] <cody-somerville> Keybuk, hey, same story here
[17:59]  * cody-somerville has two monitors.
[18:01] <Keybuk> cody-somerville: have you hit a problem recently of apps just failing to start or open windows?
[18:01] <cody-somerville> Keybuk, yes. It says too many clients or something
[18:02] <cjwatson> kees: what's wrong with keeping both?
[18:02] <cjwatson> kees: as persia said, testing often benefits from multiple approaches
[18:02] <mathiaz> kees: ok - so it may be useful to teach autopkgtest about the existance of q-r-t.
[18:02] <Keybuk> bryce: so is there any way to kill things like the following?
[18:02] <superm1> Keybuk, I just hit that situation an hour or two ago too
[18:02] <Keybuk> 44 - <unknown> ( PID:  ?   ):
[18:02] <Keybuk> 	res_base      : ox2800000
[18:02] <Keybuk> 	res_mask      : ox1fffff
[18:02] <kees> cjwatson: I don't mind keeping both as long as the bzr tree is the primary.
[18:02] <superm1> (i've got two monitors here) - so it did happen pretty quick
[18:03] <Keybuk> superm1: how many monitors do you have? :)
[18:03] <mathiaz> cjwatson: in the case of dovecot, I'd be tempted to just merge the tests from q-r-t in debian/tests/.
[18:03] <Keybuk> I guess those with one have 200 screensaver activations before they get DoS'd
[18:03] <Keybuk> which is slightly longer than the kernel team take to upload a new kernel right now :p
[18:03] <Keybuk> those ricers amongst us with two only have 100 screensaver activations, so get more suck and fail
[18:03] <superm1> i've been S3'ing this laptop the last few nights and opting to not do kernel reboots, so that explains things :)
[18:04] <persia> kees, Running autopkgtest takes a lot of resources.  We typically only do one or two runs per development cycle.  This one got missed due to various issues, but we'll try to get it run before release.
[18:04] <jdstrand> mathiaz: if you are going to do that, also consider test-dovecot.py
[18:05] <jdstrand> mathiaz: oh wait, that is 'general'. nm
[18:05] <jdstrand> (though it would all have to be updated it seems)
[18:06] <cjwatson> mathiaz: so, JeOS ...
[18:07] <mathiaz> cjwatson: yes - so I don't know if a new option should be created or existing ones be updated.
[18:07] <seb128> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=555701 ?
[18:07] <Keybuk> seb128: yes, that's linked on the bug
[18:07] <cjwatson> I think it's important to have a minimal install option that isn't just for VMs
[18:07] <mathiaz> cjwatson: my goal here is to have a way to boot the -server iso and get a sytem with -virtual and -minimal installed.
[18:07] <bryce> Keybuk: let me ask around.
[18:07] <cjwatson> I am OK with there also being a minimal install option for VMs
[18:07] <mathiaz> cjwatson: aggreed. Could CLI be used for that ?
[18:07] <seb128> Keybuk: ah ok, I just read that you mentionned the issue, I didn't know that you knew about the bug ;-)
[18:08] <cjwatson> mathiaz: "Install a command-line system" is only present on non-server CDs, because it is a daft question to ask on a CD where the default install gives you a command line
[18:09] <mathiaz> cjwatson: ok - so cli.seed is just for the alternate cd.
[18:09] <cjwatson> why not just "Install a minimal system" and "Install a minimal virtual machine"
[18:09] <mathiaz> cjwatson: WFM.
[18:10] <cjwatson> mathiaz: turning off standard is a bit harder
[18:10] <Keybuk> it appears this code is unchanged since its merge into libgnome-desktop
[18:10] <mathiaz> cjwatson: how was this done in Hardy JeOS ?
[18:10] <cjwatson> mathiaz: tasksel, by design, generally tries to keep standard installed. Can we leave it there for "Install a minimal system"?
[18:10] <cjwatson> mathiaz: HACK OF DEATH
[18:11] <mathiaz> cjwatson: ok - and it would be too late in the release cycle to implement a similar hack for intrepid?
[18:11] <cjwatson> mathiaz: actually, I'm not sure how it was done
[18:12] <cjwatson> mathiaz: don't wanna
[18:12] <cjwatson> mathiaz: oh, we did it by having a separate CD that didn't include standard
[18:12] <cjwatson> mathiaz: so that won't work when merged into the server CD. It sucked as an approach anyway
[18:12] <persia> Doing it right would mean fiddling with debootstrap, wouldn't it?
[18:13] <cjwatson> no, why?
[18:13] <Keybuk> *sigh*
[18:13] <cjwatson> debootstrap doesn't install standard
[18:13] <Keybuk> ok, this wasn't a one-liner that introduced this
[18:13] <persia> Oh.  Hm.
[18:13] <Keybuk> these gnome-screensaver functions didn't even exist in hardy
[18:14] <ogra> Keybuk, note that you might also still have xscreensaver installed
[18:15] <ogra> (which supersedes gss, unless that code changed)
[18:15] <Keybuk> I do not
[18:15] <cjwatson> mathiaz: I'll poke tasksel to export a new interface to make this work
[18:15] <ogra> Keybuk, manually removed it ? it was pulled in until recently
[18:15] <Keybuk> ogra: no, only -data and -glx are installed
[18:15] <mathiaz> cjwatson: is this something that can be implemented for intrepid?
[18:15] <cjwatson> mathiaz: yes
[18:16] <ogra> Keybuk, ah, lucky you ... u-m just removed it for me right now
[18:16] <ogra> i had it since upgrading
[18:16] <mathiaz> cjwatson: great. I'll work on adding the -virtual kernel packages to the server-ship seed.
[18:16] <Keybuk> u-m may have removed it for me when I upgraded to Intrepid last week?
[18:16] <ogra> it didnt with yesterdays run for me
[18:16] <ogra> the fix must be new
[18:16] <cjwatson> mathiaz: "work on"? is it hard? :)
[18:17] <mathiaz> cjwatson: oh no. It just needs to be done :D
[18:17] <cjwatson> mathiaz: remove the jeos seed while you're at it
[18:17] <cjwatson> mathiaz: is this i386 only, or amd64 too?
[18:17] <cjwatson> linux-virtual | 2.6.27.6.7 | intrepid/universe | amd64, i386
[18:17] <cjwatson> apparently both. the jeos seed only had it for i386
[18:18] <mathiaz> cjwatson: right.
[18:18] <cjwatson> mathiaz: is there a bug number for this?
[18:19] <mathiaz> cjwatson: no. Should I file one?
[18:19] <cjwatson> no need, was just wondering
[18:21] <ogra> wow, cool ...
[18:21]  * ogra just noticed #ubuntu-meeting
[18:21] <ogra> that makes me like utf8
[18:21] <ScottK> Interesting to watch even if I can't understand a bit of it.
[18:22] <ogra> yeah
[18:22] <Keybuk> why does their writing change when you highlight it in X-Chat?
[18:23] <ogra> LTS vs RTL setting ?
[18:23] <ogra> *LTR
[18:24] <Keybuk> "Add support for showing the desktop background behind the unlock dialog."
[18:24] <Keybuk> seems to be the culprit commit
[18:30] <Keybuk> seb128: adding a proposed patch to bug #263211
[18:30] <Keybuk> does it look sane to you?
[18:35] <seb128> Keybuk: looking
[18:38] <seb128> Keybuk: looks fine to me if it's working for you just upload ;-)
[18:39] <Keybuk> I certainly don't get the leak
[18:39] <Keybuk> I don't get the background image behind the lock dialog either
[18:39] <Keybuk> but then I didn't before
[18:39] <Keybuk> and it's not clear to me from the code how that is supposed to work :p
[18:40] <seb128> Keybuk: I'm not sure either but I pinged upstream on IRC
[18:40] <Keybuk> I ping'd jon over twitter, since he wrote the patch
[18:41] <Keybuk> k, uploaded
[18:41] <ogra> over twitter ... heh
[18:41] <seb128> Keybuk: I pinged soren on #control-center asking him to have a look at the bug but it doesn't seem to be around
[18:41] <Keybuk> ogra: I don't think that I have his cell number
[18:48] <seb128> Keybuk: ok, upstream bug moved to gnome-screensaver now and the comment suggest your change is correct
[18:48] <Keybuk> yeah, that's what I thought
[18:48] <Keybuk> it looked like g-ss just really wanted a pixmap with the background image, and he passed root=TRUE "because that sounded right"
[18:48] <Keybuk> when root=TRUE seems to really mean "this will be the real and only root window, so make it specially"
[18:52] <dholbach> james_w: will you update launchpadlib before release? :)
[18:53] <james_w> dholbach: done :-)
[18:54] <dholbach> nice
[19:00] <bryce> Keybuk:  try  e.g., xkill -id 0x2800000
[19:09] <lycannyc-work> hey everyone, i just ran the last update and my gdm doesnt have gnome in the sessions so when i log in it just stays in the brown screen
[19:16] <_Zeus_> !support
[19:17] <_Zeus_> !intrepid
[19:17] <_Zeus_> my bad
[19:23] <pitti> slangasek: gimp unwebkitified
[19:24] <pitti> slangasek: if you have a minute, can you please look at my dbus and coreutils (hardy) SRUs? I don't want to process my own uploads
[19:27] <pitti> kees, james_w: v4l promoted, go wild
[19:27] <james_w> thanks pitti
[19:27] <pitti> well, as wild as you can get with basically no buildd power :)
[19:35] <ScottK> pitti: I just noticed there is still a restricted-manager-kde file in my /etc/xdg/autostart (along with the jockey-kde one).  Shouldn't that have been removed at some poiint?
[19:38] <kees> pitti: saweeet, thanks
[19:41] <hwilde> help I need to spike my cpu,   got benchmarks?
[19:42] <slytherin> why is cups-pdf no more in main or installed by default in intrepid?
[19:54] <lool> bryce: i'm pushing a new xorg with a trivial drop of deps of video-all on lpia
[19:54] <bryce> lool, ok
[19:55] <lool> 386473ff0251ff894aa
[19:56] <_Zeus_> ??
[19:57] <slangasek> pitti: unwebkitified> awesome!
[19:57] <slangasek> pitti: yes, looking at those SRUs, thanks
[19:57] <Keybuk> lool: nice passphrase
[19:58] <lool> Keybuk: don't mock git
[19:59] <Keybuk> quite.
[19:59] <Keybuk> why use simple revision numbers when a SHA-1 will do
[19:59] <NCommander> Keybuk, talking about monotone/git?
[20:00] <NCommander> ScottK, I looked at openexr
[20:00] <NCommander> ScottK, its not pretty (and not a problem with openexr itself)
[20:01] <ScottK> NCommander: I saw debian disabled the test suite on some archs.
[20:01] <NCommander> ScottK, the issue is threading
[20:01] <NCommander> Something in glibc broke on 2.8 that causes threads in some situations it seems to not properly lock and respect mutexs
[20:01]  * NCommander had a similar issue with glib and trying to compile it
[20:02] <NCommander> It *might* just be my HPPA box, but looking very closely at the test results, it works fine without threads, or threads that aren't working together
[20:03] <NCommander> ScottK, do you just want to kill the test suite since the issue isn't with openexr specifically? (the test failures go away on glibc 2.7)
[20:04] <ScottK> NCommander: It seems a popular solution, but I'm not qualified to judge.
[20:04]  * ScottK summons the spirit of lamont for an opinion.
[20:05] <NCommander> ScottK, have you prepared the necessary sacrifices?
[20:05] <ScottK> NCommander: I gave a user Postfix advice on #ubuntu-server this morning.
[20:06]  * NCommander reads from the book of HPPA
[20:06] <NCommander> Thou should give advice on sendmail, the most evilest of SMTP daemons. Only then shall the first sacrifice be met
[20:07] <ScottK> Well I think friends don't let their friends use Sendmail.
[20:07] <persia> Erm.  sendmail isn't evil, it just wants to be placated before it will play nice.
[20:07] <NCommander> persia, go write a config file without using M4 macros, then tell me that again with a straight face
[20:10] <persia> Actually, I was opposed to the whole transition to m4 for sendmail config, and stopped being a mail server admin about at that point, as much as possible.
[20:10] <stgraber> slangasek: I'll need a new freeze exception for LTSP, fixing regression from pre-FF that we have now fixed upstream (and were missing in the previous upload)
[20:10] <stgraber> slangasek: I'm test building, I'll then file a bug for it
[20:11] <slangasek> stgraber: is this just fixing the one bug?
[20:11] <slangasek> if so, please just upload
[20:12] <NCommander> persia, you must LIKE pulling teeth. Sendmail's config format makes my brain hurt (its like COBOL. THere is only one sendmail config and its edited and modified millions of times)
[20:13] <stgraber> slangasek: 3 regressions fix, one bug fix and two small upstream changes (and a mythbuntu packaging fix): http://paste.ubuntu.com/56084/
[20:14] <slangasek> stgraber: what do you mean by "pre-FF regression", exactly? "regression that happened before FF", "regression in the current version relative to the version present at FF"...?
[20:14] <stgraber> slangasek: something that was fixed before FF but we broke with the last upload
[20:14] <slangasek> ok
[20:15] <stgraber> basically these changes were done in .diff.gz and didn't get upstream so were missing in the last upload
[20:15] <slangasek> tsk
[20:15] <slangasek> stgraber: from the changelog alone I can't say for sure "this shouldn't need a freeze exception", so please go ahead and file a bug if you believe that's best
[20:16] <ndube> hello all
[20:16] <ndube> i am currently attempting to install 8.10 beta from the alt cd
[20:16] <ndube> The installer does not see any of my HD if I have more than one plugged in. If I have only one HD plugged in, the installer see's it fine. Any Ideas?
[20:17] <stgraber> slangasek: ok, will file a bug and attach the diff.
[20:18] <_Zeus_> !intrepid | ndube
[20:18] <ndube> sorry, wrong irc
[20:23] <slangasek> pitti: I don't see a coreutils SRU in the queue
[20:24] <stgraber> slangasek: bug 281415
[20:32] <NCommander> ScottK, what's your interest in openexr anyway?
[20:42] <ScottK> NCommander: It's a broken build-dep of kde4libs so I need it to build before I can start to get KDE4 building again on hppa.
[20:44] <james_w> kees: hey, do you have hardware to test these patches?
[20:45] <lamont> ScottK: sup?
[20:46] <ScottK> lamont: openexr is FTBFS on hppa.  NCommander says it's broken threading stuff.
[20:46] <ScottK> lamont: So it looks like Debian gave up on the openexr test suite on several archs and so the question is would that be reasonable for hppa.
[20:47]  * ScottK looks at NCommander for details on his threading findings.
[20:47] <lamont> it's kde... :-)
[20:47] <NCommander> lamont, the test suite works fine until it tries to use multiple threads to write out files
[20:47] <NCommander> lamont, probably some mutex fun. I suspect its a glibc problem since it doesn't happen with glibc 2.7, nor does this same behavior manifest on any other architecture where the test suite is run
[20:47] <ScottK> lamont: Yeah, I'm trying to do my bit to help out ports and get KDE built on hppa.
[20:48] <NCommander> lamont, I did manage to get a HPPA box from HP with Ubuntu, so I'm helping with porting issues as well ;-)
[20:49] <kees> james_w: yuppers
[20:50] <kees> james_w: that's why I originally started the thread on u-devel.  I wanted to turn "ack, my webcam isn't working" into something constructive.  :)
[20:50] <james_w> kees: great, I'll defer to the person who is actually able to test them
[20:50] <kees> james_w: that's why I started with xawtv: it's small and easy to test.
[20:50] <james_w> heh :-)
[20:50] <directhex> NCommander, porting work? having fun, i hope? :p
[20:51] <lamont> NCommander: NPTL/hppa haz issues
[20:51] <NCommander> lamont, that's putting it mildly. It would have been nice if they stayed with linuxthreads until the NPTL bugs were ironed out
[20:51] <directhex> NCommander, feel free to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240272 :)
[20:51] <NCommander> mono is in PAS
[20:52] <NCommander> (although there was a WIP port for hppa at some point)
[20:52] <directhex> PAS?
[20:52] <NCommander> Packages-arch-specific
[20:52] <directhex> man, 0.30.2? that bug be OLD
[20:52] <NCommander> directhex, and something like that has to be done in upstream, since porting mono requires writing a new HAL layer
[20:52] <NCommander> Oh
[20:52] <NCommander> wait
[20:52] <NCommander> O_o;
[20:52] <NCommander> Why do we need such an antique?!
[20:52]  * NCommander was thinking 1.32 or something
[20:53] <directhex> i don't know if anyone's tested since
[20:54] <directhex> i was just working on mono bugs today. 6 debian bugs should be closed within hours, and then i'll do a merge
[20:54] <lamont> NCommander: there was a push to move all of ubuntu to NPTL with edgy... that'd be why there's no edgy/hppa or feisty/hppa
[20:55] <NCommander> lamont, even the debian dudes weren't that crazy, NPTL is only just available with lenny, and I didn't think they were making the transition until squeeze
[20:55] <NCommander> I knew there were threading issues with NPTL/hppa, but I didn't realize they were THAT ba
[20:56] <lamont> they knew they could make the transition partially because ubuntu had already
[20:56] <lamont> well, it's probably just one bug. :-(
[20:56] <lamont> OTOH, it seems to be in a very popular place, whereever it is
[20:57] <NCommander> lamont, pthread_join()
[20:57] <NCommander> I was able to get a consistent hang when joining thread without fail
[20:57]  * NCommander notes that didn't happen on the buildds
[20:57] <lamont> see: popular
[20:59] <directhex> popular. on hppa? humour!
[20:59] <lamont> directhex: if all 4 of us use it, it's ubiquitous.
[21:00] <NCommander> lamont, I also got an ia64 box ;-)
[21:00] <NCommander> (there is a port that see absolutely no love at all)
[21:00] <directhex> lamont, i was about to ask if you'd run an unofficial hardy buildd on it for me to use for my third party repo, then i remembered the past few minutes & what's on my repo...
[21:00] <directhex> NCommander, i love itanium!
[21:00] <cjwatson> mathiaz: I've uploaded the unattended-upgrades/enable_auto_updates installer integration
[21:01] <mathiaz> cjwatson: awesome ! thanks :)
[21:01]  * NCommander drops his RS/6000 on directhex 
[21:01] <NCommander> I can understand mono
[21:02] <NCommander> But ia64 is the end result if i386 raped powerpc, and powerpc didn't get an abortion.
[21:02] <directhex> jms@orac:~> mono --version | grep Arch
[21:02] <directhex> 	Architecture:  ia64
[21:02] <directhex> :)
[21:02] <lamont> directhex: give me xen on hppa with a commitment and history of support, and I'll get you a an hppa ppa buildd
[21:03] <directhex> lamont, yeah, about that... :/
[21:03] <lamont> NCommander: ia64 is the result of the hppa engineers meeting with intel engineers and coming up with what hp's engineers thought hppa should have been originally
[21:04] <NCommander> lamont, I dunno, the one look I took at the ia64 instruction set made me think of my x86 ASM book
[21:04] <directhex> jms@orac:~> grep -c IA-64 /proc/cpuinfo
[21:04] <directhex> 256
[21:04] <NCommander> The real problem with that architecture is the mythical compilers that can optimize amazingly well
[21:04] <directhex> jms@orac:~> icc --version | head -1
[21:04] <directhex> icc (ICC) 10.1 20080312
[21:05] <NCommander> directhex, obviously your not too familar with the long development history of the ia64 architecture ;-)
[21:06]  * lamont kinda lived it
[21:06] <directhex> NCommander, i'm aware of performance benchmarks, and i know this box did to the competition what spielberg/lucas did to indianna jones
[21:06] <NCommander> raped and killed it?
[21:06] <lamont> directhex: originally or lately?
[21:06] <NCommander> oh wait, that was star wars
[21:06] <directhex> lamont, lately
[21:06] <directhex> NCommander, no, indy too
[21:07] <NCommander> I could watch the 4th one without puking
[21:07] <NCommander> lamont, BTW, the test suite on HPPA is nice and pretty with glibc
[21:08] <lamont> ok
[21:09] <NCommander> I can see why its disabled by default
[21:11] <persia> Wait, the *gcc* testsuite is disabled by default on hppa?  How can that be safe?
[21:11] <NCommander> persia, glibc
[21:11] <NCommander> persia, and yes it is
[21:11] <NCommander> and no it isn't.
[21:11] <persia> Err, yes, but even so.
[21:11] <persia> Oh, good.
[21:11] <NCommander> persia, glibc FTBFS during its test suite
[21:11] <persia> That's better.
[21:11] <NCommander> (well, technically it hung, but)
[21:11] <slytherin> hi, can anyone please tell me why cups-pdf was moved to universe in intrepid?
[21:12] <directhex> slytherin, a deal with microsoft means ubuntu now only supports the microsoft XPS format instead of PDF!
[21:13] <slytherin> directhex: what deal, no one asked me before making it. :-P
[21:13] <directhex> slytherin, sorry, there was beer, and y'know...
[21:14] <jdstrand> slangasek: do you have a reference as to why ruby1.9 is in main? I can't seem to find one, and http://www.ruby-lang.org/en/downloads/ seems to consider 1.9 'Developer version (experimental)'
[21:15] <slangasek> jdstrand: only by traversing germinate output
[21:15] <NCommander> directhex, you remind me of Miguel de Icaza
[21:15] <jdstrand> slangasek: that should be something I can do, no? (I don't know how, but can learn)
[21:16] <directhex> NCommander, miguel's a nice guy. with me, you need to filter through a few layers of sarcasm to see the point of what i'm saying.
[21:16]  * NCommander watches his sarcasm meter explode
[21:16] <slangasek> jdstrand: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/all , look for ruby1.9
[21:17] <slangasek> looks like we blame rrdtool
[21:17] <jdstrand> slangasek: thanks
[21:18] <directhex> NCommander, i'm currently fighting the most crack-smoking example of debian bickering i could have imagined. it's making me tetchy
[21:20] <slytherin> directhex: still dealing with the moonlight ITP?
[21:22] <directhex> slytherin, the package is ready & functional in its current form (and designed for syncability), but we're leaving it a little for the bunfight over removing anything tangentially related to a software patent somewhere in the world from debian
[21:23] <directhex> ii  libmoon0       0.8.1+dfsg-1   open source clone of Microsoft Silverlight
[21:24] <NCommander> didrocks, link?
[21:24] <NCommander> oh, moonlight?
[21:24] <NCommander> Yeah well, Debian is dyin. Netcraft confirms it */meme*
[21:25] <directhex> NCommander, netcraft? hells, that's it then :|
[21:25] <directhex> NCommander, first they came for BSD...
[21:25] <NCommander> then Debian
[21:25] <NCommander> Then Vista
[21:25] <NCommander> :-/
[21:25] <persia> Debian is *so* not dying.  Debian is more lively and dynamic now than in some time.
[21:25] <directhex> NCommander, explain the "BSD is dying" meme to persia
[21:26]  * NCommander uses his favor you owed me on fixing the mono segfaults on this
[21:26] <NCommander> directhex, please explain the "BSD is dying" meme to persia ;-)
[21:26] <stgraber> slangasek: I just updated the bug to include a new upstream including one more bugfix (and no additional feature this time :))
[21:26] <directhex> persia, slashdot is full of links which are all pretty much like the following: http://bsd.slashdot.org/comments.pl?sid=228247&cid=18495137
[21:26] <NCommander> Neat, I didn't even have to sudo it!
[21:27] <directhex> persia, see http://en.wikipedia.org/wiki/Slashdot#Culture
[21:27] <directhex> persia, "netcraft confirms * is dying" is a meme.
[21:27] <NCommander> persia, generally speaking, when Something is Dying. Netcraft confirms it, it means that pretty much the opposite is true
[21:27]  * NCommander notes Lenny is pretty kick ass. Now only if they would release it ;-)
[21:28] <directhex> NCommander, if the wingnuts actually manage to get their "remove all patent-encumbered software of any kind from the archive" GR approved...
[21:28] <NCommander> Uh
[21:28] <NCommander> So there goes FAT32 support
[21:29] <directhex> and double clicking. and gecko.
[21:29] <NCommander> Booting off a CD, JFS2 (IBM did release that one to the community though)
[21:29] <ScottK> directhex: If they do that, there won't be any left.
[21:29] <NCommander> And it still won't be free to the FSF :-)
[21:29] <directhex> NCommander, releasing things to the community is a trap. don't you know?
[21:29] <NCommander> ScottK, well, thats the current discussion on d-devel
[21:29] <ScottK> Yeah.
[21:29] <directhex> NCommander, fsf's gobuntu installs mono by default :)
[21:29] <bytor4232> Should startupmanager be included as a base (k/x)ubuntu install?  It seems like a very useful package.
[21:30]  * NCommander notes the FSF's crack pipe has to have some serious good **** in it for them to consider Debian non-free
[21:30] <directhex> NCommander, firmware blobs! and fonts!
[21:30] <NCommander> Not in Debian
[21:30] <NCommander> Both are in non-free
[21:30] <NCommander> That's why my laptop runs Ubuntu
[21:30] <jcristau> directhex: there's no such GR...
[21:30] <directhex> jcristau, not yet. read your d-devel.
[21:31] <jcristau> i did. i ^Red that thread
[21:31] <jcristau> :)
[21:31] <NCommander> directhex, I personally think the FSF got pissed since Debian declares GDFL non-free
[21:31] <slytherin> NCommander: directhex: the discussion is becoming off-topic here. :-)
[21:31] <directhex> slytherin, sorry
[21:31] <cjwatson> NCommander: disputes between the FSF and Debian over freeness go back about a decade before that
[21:32] <cjwatson> (I was already typing, figured I'd finish ...)
[21:32] <NCommander> cjwatson, point retracted :-)
[21:32] <Laney> Which VNC server is enabled by the Prefs->Remote Desktop applet? I'd like to enable it from the commandline
[21:33] <slytherin> Laney: vino
[21:34] <slangasek> directhex: um, there's no GR on the table for removing "all patent-encumbered software"
[21:34] <Laney> slytherin: Ah, I thought that was the client. Thanks
[21:34] <slangasek> and why would you think such a GR would pass, anyway?
[21:34] <directhex> slangasek, yet. and because TEH PATENTZ!
[21:35] <slytherin> Laney: client is vinagre
[21:35] <Laney> Just found that out ;)
[21:35] <slangasek> directhex: let me rephrase.  "why do you hold such a low opinion of the Debian community that you think such an insane GR would pass?" :P
[21:35] <directhex> slangasek, i don't, i like to mock
[21:36] <directhex> slangasek, look at it this way. on the scale of hypocrisy, what's the single worst package you could be maintainer for if you were arguing that a browser plugin cloning a non-free  one, which doesn't support all sites & is therefore worthless, shouldn't be permitted into the archive?
[21:37] <slangasek> directhex: SIGVERB grammar overflow
[21:38]  * slangasek grows the stack and manages to parse, but still doesn't know the answer
[21:38] <directhex> slangasek, guy arguing that moonlight should be forbidden from entering the debian archive. package maintainer. argues that it clones a closed browser plugin (which is Bad(tm)) and doesn't work on all sites ever (and is therefore worthless). which is the most facepalm-worthy package he could maintain?
[21:38] <persia> flashflugin-nonfree?
[21:38] <slangasek> ruby?
[21:39] <directhex> persia, gnash. but close.
[22:08] <persia> Could someone please give-back compiz-fusion-plugins-extra on lpia ?
[22:12] <ScottK> persia: Done
[22:13] <persia> ScottK, Thank you.
[22:13] <ScottK> No problem.
[22:14] <ScottK> NCommander: Did you come to any conclusion about openexr?
[22:15] <slytherin> any archive admins around?
[22:16] <persia> slytherin, Generally, you'll do better to request the thing you want, rather than scaring them away like that :)
[22:16] <slytherin> :-)
[22:17] <slytherin> persia: nothing new, same old move to universe bugs. :-)
[23:23] <wgrant> superm1: I'm fairly sure it won't - I know exactly why one of the bugs happens, and the other one is probably a kernel bug.
[23:23] <superm1> wgrant, did you already punt it by rtg?
[23:24] <wgrant> superm1: I haven't, but I will when I see him.
[23:24] <wgrant> superm1: The lots and lots of keypresses seem to be caused by X never seeing the key released, thus invoking key repeat.
[23:25] <wgrant> And I was advised it was probably a kernel bug.
[23:25] <superm1> wgrant, OK, well if you don't get a chance to at some point or get busy with something else, leave the notes on a bug and at least point me at it and I'll bring it up as I talk to rtg weekly
[23:29] <ScottK> I can tell OpenOffice.org has caught up with MS Office.  OOO Writer's autocorrect feature is really annoying me.
[23:31] <wgrant> superm1: Kernel freeze is unfortunately close :(
[23:31] <wgrant> When is your next talk with him?
[23:32] <superm1> thur
[23:32] <superm1> so probably if you talk to him sooner, that's better
[23:32] <wgrant> OK, I'll poke him when I see him.
[23:32] <wgrant> Assuming he is the right person..
[23:33] <superm1> well for reproducing on dell hardware he should be
[23:33] <superm1> he has most interesting platforms
[23:33] <wgrant> Ah, good.
[23:33] <wgrant> Heh.
[23:35] <ScottK> superm1: Any luck on solid-bluetooth yet?
[23:36] <superm1> ScottK, the API changes are rather large.  I'm not sure i'll be able to make enough intelligent changes in a timely fashion.  it would really be a task better for someone more familiar with solid
[23:36] <superm1> ScottK, I'll keep futzing, but I do have other tasks i'm working on concurrently
[23:37] <ScottK> superm1: I get the impression that upstream isn't excited about dealing with it at the moment.  Unfortunately we don't have anyone on the KDE side that understands the API changes.
[23:37] <ScottK> superm1: Perhaps if we could find someone who understands solid to pair your with, between the two of you, you could get to something more than what we have now?
[23:38] <superm1> ScottK, well I'm catching up on all the API changes too, but that would probably be useful.
[23:38] <superm1> ScottK, what i'm wondering is what the F10 folks are planning on doing about this
[23:38] <superm1> ScottK, given they're still broke...
[23:38] <ScottK> I'm not sure they're aware.
[23:39] <ScottK> The one Fedora KDE person that hangs out with us didn't know of problems.
[23:41] <ScottK> superm1: Would you consider idling in #kubuntu-devel and let's see who turns up?
[23:41] <superm1> sure
[23:48] <emgent> heya