[00:12] <ion_> I wonder why dictd was merged instead of synced. The changelog entry only says “Merge with Debian; remaining changes:”.
[00:14] <persia> ion_: Does the debdiff say anything?  Sometimes people grab from MoM and aren't careful with changelogs.
[00:15] <ion_> persia: I didn’t take a better look, just happened to take a look at the changelog.
[00:19] <jcole> is there a reason why the dhcp3-client dpkg post install scripts dont finish? see here:
[00:19] <jcole> # ls /etc/dhcp3/dhclient.conf*
[00:19] <jcole> /etc/dhcp3/dhclient.conf
[00:19] <jcole> /etc/dhcp3/dhclient.conf.dpkg-dist
[00:20] <jcole> for every fresh install of hardy, i do "mv ﻿/etc/dhcp3/dhclient.conf.dpkg-dist ﻿/etc/dhcp3/dhclient.conf"
[00:20] <jcole> im using the alternate cd
[00:20] <jcole> btw
[00:21] <sjoerd>   
[00:21] <lifeless> back
[00:21] <lifeless> mathiaz: so, can you join #launchpad ?
[01:10] <jelmer> is there a bugtracker for ubuntu-dev-tools ? launchpad says it's not the bug tracker
[01:11] <persia> jelmer: https;//launchpad.net/ubuntu/+source/ubuntu-dev-tools/+bugs
[01:11] <persia> (LP is sometimes a little confused about native packages)
[01:12] <jelmer> persia: ahh, ok. Thanks
[02:21] <emgent> some debian devel up here?
[02:23] <slangasek> yes, though there are more reliable places to look for them... :)
[02:25] <emgent> hehe :)
[02:25] <emgent> slangasek: possible query? :)
[02:25] <slangasek> ok
[03:29] <kirkland> slangasek: hiya, still around?
[06:14] <dholbach> good morning
[06:22] <ion_> Hi
[06:33] <dholbach> hey thekorn, hi ion_
[06:40] <trivial> hello
[06:45] <trivial> I have a problem "request to switch into FULLSCREEN mode failed: too dumb terminal 'xterm' (no cursor move capabilitie)
[06:45] <trivial> " in both Konsole and xterm how can I fix this?
[06:47] <pitti> Good morning
[06:47] <ion_> Hi
[06:48] <pitti> ScottK: merge approvals are mostly a kind of educational measure to encourage people to get them done in time, AFAIUI
[06:48] <ScottK> Agreed.
[06:49] <ScottK> I just don't want to turn this into another bureacracy.
[06:49] <ScottK> Good morning.
[06:51] <trivial> I have a problem "request to switch into FULLSCREEN mode failed: too dumb terminal 'xterm' (no cursor move capabilitie)
[06:51] <trivial> " in both Konsole and xterm how can I fix this?
[06:51] <ion_> Does it echo in here?
[06:51] <trivial> nobody knows?
[06:51] <trivial> hello.........hello............oooooooooo...... hello????????
[06:52] <trivial> lol
[06:52] <ion_> Please read the topic.
[06:52] <trivial> ok you guys develop ubuntu?
[06:53] <trivial> or is it developing applications to run on ubuntu?
[06:53] <pwnguin> develop ubuntu
[06:53] <thekorn> hello dholbach
[06:54] <trivial> sorry wrong link
[07:46] <ScottK> slangasek: RE Bug 207473 - The user complaining the fix didn't help is using Gnome.  Since it's a KDE fix, I think it's not suprising.
[07:48] <slangasek> ScottK: oh, heh
[07:48] <slangasek> so /all/ these people are following up to the wrong bug? :/
[07:48] <slangasek> "Adam" doesn't mention GNOME or not
[07:49] <ScottK> Since it's a two part hal/guidance bug it wouldn't suprise me if there was a gnome impact.
[07:49] <ScottK> But it's the guidance bit that we have a fix for.
[07:49] <slangasek> right
[07:50] <slangasek> and have the affected users verified that the fix works?
[07:50] <ScottK> It should probably also affect some Gnome thing, but I've no idea on that.
[07:50] <slangasek> probably gnome-power-manager as a starting point, sure
[07:52] <ScottK> Sounds reasonable if it does brightness for Gnome.
[07:53] <ScottK> slangasek: It's not clear to me that there is a verification from someone who reported the exact original problem.  It's also pretty clear that none of them are active in the bug either.
[07:53] <slangasek> mm, ok
[07:54] <ScottK> I can verify no regressions and it fixed some problems I was having that I hadn't actually reduced to a bug because I didn't understand it well enough yet.
[07:54]  * slangasek nods
[07:55] <ScottK> My recommendation would be put it in hardy-updates.  The problem isn't totally solved until Hal is fixed in any case and I'm confident this is better.
[08:02] <slangasek> ScottK: no verification on bugs 231163 or 82279 yet, either?
[08:03] <slangasek> oh, 82279 has been verified, n/m
[08:03] <slangasek> silly non-auto-refreshing reports
[08:07] <ScottK> slangasek: I'll make you a deal: if there's a regression found, I promise to take care of it if you go ahead and publish.
[08:09] <slangasek> ScottK: oh, well, I don't think we should be covered for regression-testing now that it's been in for 15 days, but whether I can close the bugs with confidence when copying it over is another question :)
[08:10] <slangasek> but yes, let's go ahead
[08:13] <slangasek> ivoks: hi, I had a question for you
[08:13] <ivoks> slangasek: sure
[08:14] <slangasek> ivoks: https://wiki.ubuntu.com/DistributionDefaultsAndBranding says that for Croatian, "Debianova, Debianove, Debianovu" are ok to replace in translations with just "Ubuntu" - is that right?
[08:15] <slangasek> it seems suspect to me that you would replace an adjective with a noun like that :)
[08:15] <ivoks> slangasek: eh, depends on circumstances... i'll take a look at it
[08:15] <slangasek> basically, this is the guide that gets used to mangle the debian-installer translations when doing merges
[08:16] <ivoks> in most cases you can just apply same rules
[08:16] <ivoks> but with Ubuntu is very hard, cause it ends with a vowel...
[08:16] <slangasek> so there wouldn't be an "Ubuntove" adjective form?
[08:17] <ivoks> so, Ubuntu's would be Ubuntuov, which soulds strange; 'In Ubuntu' is U Ubuntuu - very strange :D
[08:17] <slangasek> heh
[08:17] <soren> I like it!
[08:17] <soren> :)
[08:17] <slangasek> just cheat and claim that Ubuntu is the accusative form of "Ubunta"
[08:17] <slangasek> >:)
[08:17] <ivoks> slangasek: Ubuntuove sounds right
[08:18] <slangasek> ok
[08:18] <ivoks> like Ubuntu's web pages; Ubuntuove web stranice; that's for plural
[08:18] <slangasek> ah, so there's also precedent, excellent
[08:18] <ivoks> but Ubuntu's page; Ubuntu stranica
[08:18] <slangasek> yes, of course
[08:18] <ivoks> slangasek: i'll have to check each phrase...
[08:19] <ivoks> or someone from ubuntu-hr
[08:19] <slangasek> ivoks: well, it should never be /incorrect/ to do s/Debianov/Ubuntuov/, should it?
[08:19] <ivoks> it should be correct, right
[08:31] <LucidFox> seb128> I'm preparing to upload a new debdiff for the f-spot merge
[08:31] <seb128> LucidFox: ah good, I was starting to wonder about this one ;-)
[08:32] <LucidFox> I've dropped the debian/copyright change, FSF address probably isn't big enough of an issue to diverge from Debian
[08:32] <LucidFox> and added the new patch from hardy-updates
[08:32] <seb128> cool
[08:32] <seb128> you can do the new version update too if you want ;-)
[08:32] <LucidFox> to 0.4.4?
[08:33] <slangasek> ivoks: fwiw, here's an example of what we have currently:
[08:33] <slangasek> -msgstr "Provjeravam Debianovu zrcalnu arhivu"
[08:33] <slangasek> +msgstr "Provjeravam Ubuntu zrcalnu arhivu"
[08:33] <slangasek> so. :)
[08:33] <LucidFox> I'd wait for Debian to update first, diocles has said he's going to upload it this weekend
[08:33] <seb128> LucidFox: yes
[08:33] <seb128> alright
[08:34] <seb128> hey slangasek, thanks for accepting the sru uploads ;-)
[08:34] <slangasek> seb128: yep - thanks for uploading... :)
[08:34] <seb128> things look good from my side for 8.04.1
[08:34] <slangasek> excellent!
[08:35] <slangasek> because I don't want to have to approve any more uploads >:)
[08:35] <seb128> right, those were already late
[08:36] <pitti> hi seb128; you pung last night, so that's settled now?
[08:36] <seb128> the only remaining problem now is pulseaudio and the alsa update, right?
[08:36] <pitti> yeah :/
[08:36] <seb128> pitti: did I?
[08:37] <LucidFox> Uploaded to bug #226117
[08:37] <seb128> pitti: anyway that was probably for the sru uploads slangasek accepted so everything is fine now
[08:37] <seb128> LucidFox: looking
[08:37] <pitti> seb128: right
[08:38]  * seb128 hugs pitti
[08:38]  * pitti hugs seb back
[08:41] <ivoks> slangasek: that's ok :) (sorry, i was on the phone)
[08:42] <ivoks> slangasek: both 'Provjeravam Ubuntu zrcalnu arhivu' and 'Provjeravam Ubuntuovu zrcalnu arhivu' are ok, but the first one sounds better and is easier to pronounce
[08:43] <slangasek> ivoks: ok.  well, if you can review my changes in http://bazaar.launchpad.net/%7Eubuntu-core-dev/choose-mirror/ubuntu/ rev. 599, that'd be awesome; c.f. revision 486.1.526 which shows the branding changes vs. Debian's
[08:43] <ivoks> slangasek: i will
[08:44] <slangasek> and if you tell me to, I'll revert the changes, or whatever :)
[08:44] <ivoks> slangasek: ok :)
[08:44] <slangasek> but it's ideal if we have something that can be applied mechanically, since usually that's how these branding changes have to be done
[08:45] <slangasek> (it's interesting that you say "Ubuntu zrcalnu arhivu" sounds better; in Czech this construction sounds very strange to me)
[08:47] <ivoks> slangasek: in 'Ubuntu zrcalna arhiva', everything is object, and in 'Ubuntuova zrcalna arhiva' 'zrcalna arhiva' is object
[08:49] <ivoks> slangasek: meh... just drop 599 revision; it really sounds bad :D
[08:49] <slangasek> ok... :0
[08:49] <ivoks> sorry
[08:49] <slangasek> :)
[08:50] <ivoks> slangasek: thanks for keeping an eye on it
[08:51] <slangasek> n/p
[08:51]  * slangasek still thinks Croatian's choices here are weird ;)
[08:52] <ivoks> i'll take the blame if someone complains, i translated it like that in the first place in d-i
[08:52] <slangasek> actually, I think what really bothers me is that it's "Ubuntu zrcalnu arhivu" instead of "zrcalnu arhivu Ubuntu"
[08:52] <slangasek> but that's not a mechanical change :/
[08:53] <slangasek> and may not even be the correct word order in Croatian, for all I know ;)
[08:53] <ivoks> ubuntuove sounds very czech and it's kind of normal there.. like krusovice
[08:53] <slangasek> heh :)
[08:53] <ivoks> slangasek: you have a point there
[08:53] <ivoks> zrcalna arhiva Ubuntua sounds very good
[08:54] <ivoks> hm... i'll crate a diff and send it to you, if needed
[08:54] <ivoks> ok?
[08:54] <slangasek> well, then we still have the difficulty of whether we can continue to maintain it?
[08:54] <ivoks> right...
[08:54] <slangasek> since it's then not a mechanical translation - one needs to understand the grammar enough to get the word order right
[08:55] <slangasek> so if the current is acceptable, we should probably just leave it alone
[08:55] <ivoks> sometimes i whish we all speek same language...
[08:55] <ivoks> current is ok
[09:20] <pitti> kirkland: I reviewed your program, long answer in your mbox
[09:30] <MacSlow> question about PPAs: although I deleted packages from my PPA, trying to upload revised versions for another distro-series results in LP rejecting it, stating that "the source is already accepted in ubuntu/intrepid..."
[09:31] <MacSlow> What more than delete packages can I do?
[09:31] <MacSlow> Does LP still cache some info about previously uploaded (but now deleted) packages?
[09:33] <wgrant> MacSlow: You really don't want to do that.
[09:33] <wgrant> We bump versions for a reason.
[09:33] <wgrant> What are you trying to upload, though?
[09:34] <MacSlow> wgrant, my own version of upstream clutter & friends
[09:34] <wgrant> If anybody else ever uses your packages, they'll get confused to death if a version is in fact not the same as that same version.
[09:35] <MacSlow> well then
[09:35] <wgrant> Bumping to -0ubuntu3 won't kill anything, I'm sure.
[09:35] <MacSlow> ok... I admit I just wanted a fresh start for "cosmetic" reasons :)
[09:37] <ion_> wgrant: Assuming Ubuntu has e.g. -0ubuntu1, better use something that’s -0ubuntu1 < x < -0ubuntu2, for instance -0ubuntu1.1
[09:38] <wgrant> Ubuntu doesn't have -0ubuntu1, but you're right in that different versioning should be used.
[09:39] <wgrant> Security versioning is not the solution, however.
[09:39] <wgrant> People will often append a +username1 or +ppa1
[09:40] <ion_> I mean, for a < b < c, where a is the current Ubuntu version, c is what the next Ubuntu version for the same upstream release will be and you pick b.
[09:40] <wgrant> Right.
[09:47] <pitti> pycentral pkginstall: not overwriting local files
[09:47] <pitti> dpkg: error processing python-launchpad-bugs (--configure):
[09:47] <pitti> argh
[09:47] <pitti> doko: ^ any idea about why that happens? breaks hardy dist-upgrade
[09:47] <pitti> oh, ENODOK
[09:48] <pitti> seb128: ^ that broke the retracers; fixing (FYI)
[09:48] <seb128> urg, thanks
[09:48] <seb128> that's not the first time that happens
[09:55] <MacSlow> oh why... LP now complains it's missing the *.orig.tar.gz although it's in the same directory from where I issued the dput command
[09:56] <dholbach> debuild -S -sa   vs.   debuild -S ?
[09:56] <MacSlow> but it was obviously not uploaded with the dput command... I'm not doing anything other then...
[09:56] <MacSlow> dholbach, I did dpkg-buildpackage -S
[09:56] <dholbach> right
[09:57] <MacSlow> that's not good anymore?
[09:57] <ion_> mcaslow: Try removing ...orig.tar.gz.uploaded or whatever it was.
[09:57] <dholbach> -sa will add the .orig.tar.gz to the .changes file
[09:57] <MacSlow> dholbach, it only uploads the orig.tar.gz with 0ubunt1 ?!
[09:57] <dholbach> it doesn't care about the version number
[09:57] <ion_> Oh, and yeah, -sa.
[09:57] <dholbach> if you (and nobody else) has ever uploaded the new .orig.tar.gz, use -sa
[09:58] <dholbach> if it has already been uploaded, don't use -sa and save bandwidth and time
[09:58] <MacSlow> ion_, btw I never saw such a *.orig.tar.gz.uploaded before
[09:58] <dholbach> just remove the .upload file, regenerate the source package with -S -sa and try again
[09:58] <MacSlow> dholbach, -sa ?= "source attach"
[09:58] <MacSlow> ok
[09:59] <dholbach> no idea what it stands for
[10:02] <dholbach> thanks mvo for sponsoring! thanks seb128 too!
[10:02] <seb128> ;-)
[10:02] <mvo> cheers
[10:19] <seb128> dholbach: do you consider https://bugs.edge.launchpad.net/ubuntu/+source/courier-authlib/+bug/239643 as a correct bug? I don't know what universe standards are, but is there any need to use revu when a debdiff could be attached?
[10:19] <dholbach> seb128: no, it's absolutely not required to upload to REVU
[10:19] <seb128> and the description is not good either
[10:20] <dholbach> right
[10:25] <wgrant> Is the top (menu bar, tabs) of my gnome-terminal in Intrepid meant to be translucent, while other apps aren't?
[10:27] <seb128> is that really a question? ;-)
[10:28] <seb128> I don't see a reason why one application should behave differently no
[10:28] <seb128> seems to be a bug rather
[10:29] <ion_> In MacOSX, such inconsistencies seem to be the norm. :-)
[10:29] <wgrant> I thought maybe the new theme supported transparency, and some apps would initialise a window with an alpha channel, and those that didn't were the bug...
[10:29] <seb128> ok, if that's the case I don't know about it
[10:30] <seb128> maybe MacSlow knows about that
[10:30] <ion_> Huh, translucent Gtk background by default? Now *that* would be a bug.
[10:31] <MacSlow> ion_, no... it's slick :)
[10:31] <ion_> If by slick you mean less readable. :-)
[10:31] <wgrant> ion_: With blurring it probably won't be too bad.
[10:31] <MacSlow> ion_, it really depends on the opacity and if you happen to have compiz' blur enabled
[10:31] <wgrant> Haha.
[10:31] <MacSlow> ion_, got a screenshot for me to take a look?
[10:32] <MacSlow> wgrant, I meant
[10:32] <MacSlow> sorry
[10:32] <wgrant> MacSlow: Sure, in a sec.
[10:33] <MacSlow> day two of my clutter-PPA efforts and still not done *sigh*
[10:35] <MacSlow> no please don't tell me it failed because of the german-umlaut in my name
[10:35] <MacSlow> if anybody cares to take a look -> http://launchpadlibrarian.net/15472094/6c17UkRT6WzAJ8VPK8kCtoyGGfq.txt
[10:35] <wgrant> MacSlow: What's the error?
[10:35] <wgrant> Ah.
[10:35]  * wgrant tries.
[10:36] <wgrant> My i915 really didn't like turning blur on.
[10:36] <pitti> MacSlow: heh; but it shouldn't matter in the Mainainer: field or anywhere, hmm
[10:36] <MacSlow> it built for hardy... then I copied it to intrepid and there it failed?
[10:36] <pitti> MacSlow: sounds like a cprov problem
[10:36] <seb128> cprov: ^
[10:36] <wgrant> MacSlow: It rejected it, and then failed to generate the rejected message because of your name, I suspect.
[10:36] <MacSlow> wgrant, oh... don't bother with blur if you don't have a GeForce-card
[10:36] <wgrant> But it didn't reject it because of your name.
[10:37] <wgrant> Although, that's a strange character...
[10:37] <MacSlow> pitti, wgrant: but I don't get why for hardy it built and only failed on intrepid
[10:37] <wgrant> MacSlow: Did you upload the same version?
[10:37] <cprov> MacSlow: did you copy only the source ?
[10:38] <MacSlow> wgrant, no... I uploaded it for hardy and after that finished I used the LP/PPA-UI to copy it to another distro-seriies
[10:38] <MacSlow> cprov, yes
[10:38] <wgrant> Aha, 0xFC is ü in latin-1?
[10:38] <MacSlow> cprov, I remember that this is saver to have it actually rebuilt
[10:38] <MacSlow> wgrant, yes... Müller is my surname
[10:38] <wgrant> Shouldn't everything be UTF-8 these days?
[10:39] <cprov> MacSlow: you can't rebuild the same source within the same PPA (archive pools).
[10:39] <MacSlow> wgrant, well I didn't touch/change anything on my system
[10:39] <ion_> wgrant: Definitely yes.
[10:39] <wgrant> cprov: Edge should prevent that nowadays, shouldn't it?
[10:39] <cprov> MacSlow: +copy-packages form should not allow it.
[10:39] <wgrant> Except for that remaining race.
[10:39] <cprov> wgrant: no, edge is frozen  :(
[10:40] <MacSlow> cprov, ehm... but didn't yesterday somebody tell me that this would be ok (moving from distro-series -> distro-series+1 and keep the version number)?
[10:40] <wgrant> cprov: But is it in 1.2.6?
[10:40] <cprov> MacSlow: when you include binaries in the copy, it's fine
[10:41] <cprov> wgrant: yes, the bug is in PQM
[10:41] <MacSlow> cprov, hm.
[10:41] <cprov> the bug fix ...
[10:43] <MacSlow> f**k!
[10:43] <MacSlow> now I deleted the failed versions, and copied (with binaries) from hardy to intrepid... and that failed right away
[10:48] <ogra> pitti, to many kits eh ? (you thanked james for his help on policykit in your last sentence of teh packagekit mail  :) )
[10:49] <MacSlow> how long does it take for a deletion of a package to actually happen?
[10:49] <wgrant> MacSlow: Now that I've got Compiz to go less slothfully - http://qeuni.net/f/1/2008/noblur.png
[10:49] <wgrant> ogra: Can we please rename Nautilus to DirectoryKit?
[10:49] <ogra> yay
[10:49] <MacSlow> wgrant, looks like you're using some murrine-based GTK+-theme-engine
[10:49] <ogra> and kernel to hardwarekit :)
[10:49] <wgrant> MacSlow: It's the default in Intrepid.
[10:50] <pitti> ogra: oh, indeed; PK != PK any more :)
[10:50] <MacSlow> wgrant, that's intrepid?
[10:50] <wgrant> It is.
[10:50] <MacSlow> wgrant, hm... now I'm surprised
[10:50] <ogra> pitti, i'm always confusing all these kits .... they really should stop *now* with inventing new ones
[10:51] <wgrant> GTK+ -> WidgetKit, GDM -> LoginKit. The possibilities are endless and horribly confusing.
[10:51] <ogra> yeah
[10:51] <ogra> but fedora has fun confusing the world at least :)
[10:51] <ion_> GTK+ → Gimp ToolKit ;-)
[10:51] <wgrant> ion_: True.
[10:51] <ion_> Or perhaps GraphicsKit ToolKit :-P
[10:51] <afflux> Pidgin -> ConversationKit, uh yeah :P
[10:51] <ion_> Hehe
[10:51] <wgrant> MacSlow: The panel customisations are mine, but the rest of the theme is stock.
[10:52] <MacSlow> wgrant, the opacity in murrine is a hardcoded-value (at least it was when I last looked at its source)
[10:53] <ogra> wgrant, working on BlingKit with MacSlow ?
[10:53] <MacSlow> wgrant, it should be a settable theme-property-value in the optimal case... so people can have it a bit translucent if they can run with compiz' blur... in that case it's really nice
[10:55] <pitti> slangasek: ah, apparently Debian now has a 'db-defaults' metapackage for libdb-dev
[11:01] <MacSlow> although I deleted packages from my PPA (about 15 minutes ago) they still show up in the "Delete packages from PPA"-page... why's that?
[11:01] <wgrant> MacSlow: Indeed, it looked very good when I had blur on, but it regrettable ran at less than 0.1fps.
[11:01] <wgrant> MacSlow: Try now.
[11:02] <wgrant> s/regrettable/regrettably/
[11:02] <MacSlow> wgrant, the i915 has no hw-accelerated offscreen rendering (FBOs) needed for fast blur
[11:03] <wgrant> wgrant: Publisher only runs every 20 minutes, so trying a couple of minutes after the hour might have made a difference, but cprov would know.
[11:03] <wgrant> MacSlow: Aha.
[11:03] <wgrant> Um. I keep referring to myself for some reason.
[11:03] <MacSlow> wgrant, I think in the case of the i915 it uses the slowest possible option in GL... the only available on the i915
[11:03] <wgrant> MacSlow: Do any newer Intel chips do it well?
[11:04] <cprov> MacSlow: the package will continue to be listed in +delete-package until it is entirely removed from the archive. I usually takes 2 death-row cycles (30 min)
[11:04] <MacSlow> wgrant, on the i965 I saw FBOs finally being exposed by the driver when I did a fresh git-checkout of Xorg, driver & Co at UDS-Prague... even GLSL-examples ran on it... that's a sweet outlook for Intrepid :)
[11:04] <MacSlow> cprov, ah ok
[11:05] <ion_> Wow, a free driver with GLSL and FBO support? I gotta get one of those cards.
[11:05] <wgrant> MacSlow: Nice, nice.
[11:05] <wgrant> GLSL == GL shader language?
[11:05] <ion_> (Are there cards anyway, or are they only available as integrated chips?)
[11:05] <MacSlow> ion_, cool eh?!
[11:05] <wgrant> (fairly random guess)
[11:05] <MacSlow> wgrant, correct
[11:06] <wgrant> ion_: I heard they were coming up with cards eventually.
[11:06] <MacSlow> wgrant, well all chips supported by free drivers should get GLSL-support
[11:06] <wgrant> But not yet that I know of.
[11:06] <wgrant> Unfortunately.
[11:06] <MacSlow> wgrant, but I only have a GeForce and a i965 myself so I cannot tell anything about e.g. ATI-chips
[11:07] <MacSlow> wgrant, I would not be surprised if the nouveau (the free nvidia-driver) will offer all that too at some point
[11:08] <MacSlow> cprov, so for having a package available for <distro-series> and <distro-series+1> I _absolutely_have_ to bump the version?!
[11:08] <wgrant> MacSlow: Nouveau seems like it should be rather good - I wonder how radeonhd will turn out.
[11:08] <wgrant> MacSlow: One would normally upload for distro-series, and then copy it (with binaries) to distro-series+1.
[11:08] <wgrant> Like we do when we create a new release.
[11:08] <wgrant> All the binaries are copied from the previous one.
[11:09] <MacSlow> wgrant, regarding ATI/Radeon I put all my bets on Dave Airlie (!= RadeonHD)
[11:09] <MacSlow> just for the record...
[11:09]  * MacSlow is the bloodiest packageing noob on the planet
[11:09] <wgrant> MacSlow: WRT the Murrine translucency... does it only work on RGBA windows?
[11:10] <cprov> MacSlow: what willian said, binaries normally can be safely carried from series-(n-1) to series-(n)
[11:10] <MacSlow> wgrant, well of course and it needs a working/running compositor
[11:10] <wgrant> MacSlow: So that would explain why most of my windows are opaque. That's what I was initially wondering, thanks.
[11:11] <MacSlow> wgrant, I forgot which widgets murrine draws with some transparency by default
[11:12] <MacSlow> wgrant, it certainly does not create every widget with a RGBA-colormap by default... that would cause some breakage... especially for the tray-icons (notification area)
[11:27] <ogra> seb128, i was told gdm wil drop support for ~/.dmrc, do you know anything about that ? (we just planned ~/.dmrc support in ldm but i dont want manpower being wasted if upstream switches to different ways of setting default lang and session)
[11:28] <seb128> ogra: the new gdm uses gconf
[11:28] <ogra> hmm
[11:28] <cody-somerville> ughh :(
[11:28] <wgrant> seb128: ConfigKit!
[11:29] <ogra> how does that work with KDM, xdm and others then for default session and language ? they require ~/.dmrc .... or does KDM switch to gconf now ? :)
[11:29] <seb128> ogra: that's like asking how evolution read kmail accounts settings ...
[11:29] <ogra> there should be a freedesktop.org standard for that imho ...
[11:29] <ogra> no, its different
[11:30] <seb128> not really
[11:30] <ogra> you might wat to run a desktop that requires that file
[11:30] <ogra> from gdm
[11:30] <seb128> what file?
[11:30] <ogra> or you might want to switch over and expect no regression :)
[11:30] <ogra> ~/.dmrc
[11:30] <seb128> you might want to use your thunderbird accounts in evolution too
[11:30] <ogra> it carries a users default language and session
[11:31] <ogra> as a quasi standard since DMs exist
[11:31] <seb128> don't switch software if you don't want to reconfigure?
[11:31] <ogra> well, why should i switch my default session language
[11:31] <seb128> I don't get the question
[11:31] <seb128> why would an user switch login managers?
[11:32] <ogra> ok, question made easier: why does gdm break common standards ?
[11:32] <ogra> i mean the way to set lang and session is long established
[11:33] <ogra> i dont get why they need to break it and get incompatible with all other DMs
[11:33] <seb128> it doesn't in fact
[11:33] <seb128> I was just looking at the code
[11:33] <seb128> .dmrc is still used
[11:33] <ogra> phew, ok
[11:33] <ogra> warren told e differently
[11:33] <ogra> *me
[11:33] <ogra> he said mccann would remove it or had already
[11:33] <seb128> "	* daemon/gdm-session-worker.c: (_save_user_settings),
[11:33] <seb128> 	(gdm_session_worker_start_user_session):
[11:33] <seb128> 	Save out user settings to ~/.dmrc before starting the
[11:33] <seb128> 	session"
[11:34] <ogra> good
[11:34] <seb128> ogra: I don't know what they will do
[11:34] <seb128> I just know what the current code is doing
[11:34] <seb128> but I'm not sure they consider .dmrc as a standard
[11:34] <ogra> ok, i thought you had any insight in the "why do they want to drop traditional setups" :)
[11:34] <seb128> and that they consider switching dynamically login managers as something that needs to be supported
[11:35] <ogra> thats why i said "quasi" standard :)
[11:35] <seb128> honestly who is wanting to switch between login managers?
[11:35] <ogra> i'm sure its not written down anywhere as "the standard"
[11:35] <ogra> me
[11:35] <ogra> and all my ltsp users do that regulary
[11:35] <seb128> why?
[11:35] <seb128> why should an user care about that?
[11:35] <ogra> depending if you sit on the server directly or on a client you use either ldm or gdm
[11:36] <seb128> that's like saying that grub should use lilo.conf because some users want to switch the boot manager
[11:36] <ogra> and i want them both to have the same settings indeed
[11:36] <ogra> which is what ~/.dmrc was made for
[11:36] <ogra> so DMs can share session and language info
[11:37] <seb128> well, as said the code to support .dmrc is still there
[11:37] <seb128> so let's see what they do
[11:37] <ogra> yeah
[11:37] <seb128> but if mccann said he wants to remove it that's probably true
[11:37] <ogra> well, warren said
[11:38] <ogra> i tend to trust him less and less since i met the people in person he usually proxies to me :)
[11:38] <ogra> (i.e.l lennart or davidz)
[11:39] <seb128> I don't know him so I can't say
[11:39] <ogra> (thas why i picked your brain to gather some more info :) )
[11:39] <seb128> but from the changelog they added code to write and read the .dmrc during this cycle
[11:39] <ogra> good
[11:39] <seb128> so they probably agree with you that's an useful thing
[11:39] <seb128> and I somewhat doubt they will drop that now
[11:39] <ogra> it definately is
[11:39] <seb128> I would not worry to much for now
[11:39] <ogra> thanks :)
[11:42] <wgrant> 5~/win 4
[11:42] <wgrant> Gah.
[12:14] <asac> siretart: is wpa roam feature debian only?
[12:16] <norsetto> asac: any idea why debian bug 415381 hasn'changed ownership? I also tried sending an email to control without results.
[12:17] <asac> norsetto: yeah :)
[12:17] <asac> norsetto: because i forgot the bugnumber ;)
[12:18] <asac> norsetto: you can just send owner 415381 !
[12:18] <asac> if you send from the email you want to use
[12:18] <norsetto> asac: ah ok. I sent it with bugnumber but haven't got any results either :-/
[12:19] <asac> norsetto: debian had some outages recently. try to send again
[12:21] <norsetto> asac: ok, will try again, viel danke
[12:21] <asac> welcome
[12:34] <siretart> asac: no, it is available in ubuntu since ages as well
[12:35] <siretart> bug #44194 makes it quite annoying to use in ubuntu, however. I still didn't understand where the race actually is here
[12:37] <zul> morning
[12:42] <asac> siretart: err, i meant debian/ubuntu only ... as "not in upstream"
[12:45] <MacSlow> hm... locally a package compiled fine, but on LP/PPA it is missing "gtk-doc >= 1.4" thus fails to build (both for hardy)
[12:45] <siretart> asac: err, I think we are miscommunication. I mean with 'wpa-roam' feature the wpa-roam integration in /etc/network/interfaces, which is very specific to debian/ubuntu
[12:45] <siretart> what are you talking about?
[12:45] <asac> MacSlow: missing build-depends :)?
[12:46] <asac> siretart: right thats why i ask. i see that wpa-roam for eni is debian only
[12:46] <asac> siretart: now i wonder about wpasupplicant.conf?
[12:47] <asac> e.g. is that a debian thing? or is that upstream? if its upstream, what happens if you define two configurations in there :)
[12:48] <MacSlow> asac, well in the original package I "lended" the control file from there's not mentioning of gtk-doc in Build-Depends
[12:49] <siretart> asac: what is with wpasupplicant.conf? you terribly confuse me now
[12:49] <siretart> asac: perhaps you want to give me a call?
[12:49] <asac> siretart: yeah ... if you have time now ;)
[12:50] <asac> MacSlow: add it ... and maybe try with pbuilder
[12:50] <asac> MacSlow: maybe you are missing a configure switch to disable docs?
[12:51] <MacSlow> asac, yeah... just checking that
[13:00] <siretart> hosts:          files dns [NOTFOUND=return] nis
[13:22] <emgent> heya pitti :)
[13:22] <pitti> hello again
[13:23] <asac> siretart: /etc/NetworkManager/dispatcher.d/01ifupdown
[13:24] <asac> thats the wrapper
[13:30] <siretart> asac: aah, excellent. is that the only purpose of the NM Dispatcher?
[13:41] <pitti> argh
[13:41] <pitti> apparently 2.6.26 has an alsa driver for the PC speaker
[13:41] <ogra_cmpc> fun
[13:41] <pitti> which makes pulseaudio playback sounds through it
[13:42] <pitti> and as a result, the session startup takes some 10 minutes, while the PC speaker gives really weird noise
[13:42] <pitti> (in vmware, anyway)
[13:48] <asac> siretart: yes i think so
[13:49] <ember> pitti i'm having that on a intrepid machine using pulse
[13:49] <ion_> pitti: :-D
[13:50] <asac> siretart: http://paste.ubuntu.com/21615/ ... you think thats too hacky? :-P
[13:50] <asac> err, s/usr/var/ :)
[13:54] <asac> siretart: not a serious approach. just a poc. to do it right we would have to check if NM is running or something
[13:54] <siretart> asac: I'm not really familiar what this mdns_minimal.so does, but if it really only duplicates the dns module using a custom resolv.conf, it might be an interesting 'hack' for the nm problem :)
[13:54] <siretart> asac: right. you need to consider the cornercases
[13:55] <asac> siretart: yeah. we could put NM logic directly into mdns ... not sure how much cheering that would get though :)
[13:55]  * persia thinks little
[13:55] <asac> e.g. if running -> use this ... otherwise use that
[14:01] <siretart> asac: well, mdns has very little to do with NM. I fear you'll get into unneeded complexity with that.
[14:01] <siretart> asac: however it might be a very good start and source for inspiration
[14:06] <asac> siretart: btw, if you use dhcp in interfaces it will also just overwrite your /etc/resolv.conf, wouldn't it?
[14:16] <siretart> asac: no. why should it?
[14:16] <siretart> err
[14:16] <siretart> wait
[14:17] <asac> siretart: how does it work then?
[14:17] <asac> siretart: doesnt dhclient do that?
[14:17]  * asac confused
[14:18] <siretart> asac: yes, of course it does. sorry. /sbin/dhclient-script to be exact does that
[14:18] <siretart> need to run now however. cu later!
[14:18] <asac> cu
[15:33] <cody-somerville> bryce, Is how we did libxcb in Hardy down in Debian too?
[15:59] <dholbach> mvo: where do I get -virtual?
[16:00] <mvo> dholbach: eh, were did you get 2.6.26 :) ?
[16:00] <mvo> dholbach: I don't have it here in my intrepid VM
[16:00] <dholbach> mvo: are you sure you're on intrepid? :)
[16:01] <dholbach> I tried both 2.6.26-{1,2}-generic - both don't boot up in KVM
[16:01]  * mvo updates
[16:01] <mvo> just to be sure
[16:01] <dholbach> also I have this strange issue with the mouse pointer - it just moves in the upper left 50x20 pixels, really slowly
[16:02] <dholbach> very weird
[16:02] <dholbach> soren: ^ do you know anything about that?
[16:04] <mvo> dholbach: how strange, I do not see 2.4.26
[16:04] <mvo> :/
[16:05] <mvo> soren: did you had a chance to look at this alt-gr patch for kvm that I sent you some days ago via LP?
[16:05] <soren> dholbach: Err... Does it not boot or does the mouse misbehave? It can't be both :)
[16:05] <soren> mvo: I've been away for two weeks. I'm not really caught up on lp bug mail just yet :)
[16:06] <dholbach> soren: with 2.6.26-{1,2}: no boot, with 2.6.24-16: no fun with the mouse pointer
[16:06] <mvo> soren: no problem :)
[16:06] <dholbach> mvo: https://edge.launchpad.net/ubuntu/intrepid/+source/linux/2.6.26-2.6
[16:06] <mvo> geh, since monday
[16:06] <soren> dholbach: Hm... You might be shocked to know that I don't use kvm's graphics capabilities very much :)
[16:06] <dholbach> mvo: using de.archive.u.c?
[16:06] <mvo> no, archive.u.c
[16:06] <dholbach> soren: GAR!
[16:07] <soren> dholbach: Are you using vmmouse in your guest?
[16:07] <dholbach> yes
[16:07] <soren> dholbach: Are you running though libvirt (i.e. using vnc) or are you running kvm from the commandline (and hence probably using sdl)?
[16:07] <dholbach> soren: I tried both
[16:08] <soren> dholbach: Same problem? This is with the kvm from intrepid?
[16:08] <dholbach> host is hardy, guest is intrepid (amd64)
[16:08] <mvo> now I have it, that is *very* mysterious
[16:09] <dholbach> mvo: I'm sure smart would have found it ;-)
[16:09]  * dholbach hugs mvo
[16:09] <soren> dholbach: This only happens with intrepid guests?
[16:10] <dholbach> soren: it's just been happening since a few days - let me try an older hardy image I have
[16:10]  * soren glances at our esteemed X maintainers
[16:10] <dholbach> it just feels that I'm the only one seeing this behaviour :)
[16:10] <dholbach> ... weird ...
[16:12] <mvo> dholbach: joy! it it does no longer find my uuid anymore with the latest -generic kernel too
[16:12] <mvo> is that what you see too?
[16:12] <Koon> soren: I also have no boot on 2.6.26 kernels
[16:12] <dholbach> mvo: I don't get any message at all
[16:12] <dholbach> Koon: cjwatson said he reported the problem to the kernel folks already
[16:12]  * soren tries to install an intrepid guest
[16:13] <dholbach> soren: it works with hardy, doesn't work with intrepid (X mouse, bla)
[16:13] <mvo> dholbach: have you tried to remove the quiet and splash at the bootprompt?
[16:13] <soren> What seems to be the problem?
[16:13] <Koon> soren: looks like it gets stuck in initramfs at boot.
[16:13] <dholbach> mvo: no
[16:13] <Koon> dholbach: cool.
[16:14] <mvo> Koon: for me it can not find my uuid anymore (missing driver or something?)
[16:14] <soren> I'll take a look.
[16:14] <Koon> mvo: yes, same here.
[16:15] <Koon> soren: you might want to pull the latest intrepid branch, otherwise you might get caught by the other issues I ran into (and fixed)
[16:16] <Koon> soren: like lilo being pulled in by the new install-recommends default.
[16:16]  * mvo whistles inocenntly
[16:16]  * Koon hugs mvo
[16:19] <Koon> soren: you might also want to review https://bugs.launchpad.net/ubuntu/+source/ubuntu-vm-builder/+bug/206763/comments/4
[16:20] <Koon> you might disagree with my patch (and you might even be right)
[16:21] <soren> Koon: Heh.. Check this out...
[16:22] <soren> http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/intrepid/revision/soren%40canonical.com-20080604161510-93365utmi0eppjn4?start_revid=nick.barcet%40canonical.com-20080619151306-i0ucr8zdcz13t84s
[16:23] <soren> shorter version: http://surl.dk/4co/
[16:23] <Koon> soren: that's the change I didn't like, and reworked :)
[16:23] <pitti> soren: (btw, revision/1234 works, too)
[16:23] <soren> Koon: Oh, I though you didn't see it.
[16:23] <soren> Koon: :)
[16:24] <soren> kees: But yeah, the install-recommends bit is a good idea, too.
[16:24] <Koon> soren: I saw it and I didn't like it :)
[16:24] <Koon> see http://bazaar.launchpad.net/~ubuntu-virt/ubuntu-jeos/intrepid/revision/107 :P
[16:25] <nijaba> soren: good reason not to like it, it certainly did not work for most of us :(
[16:38] <soren> Er.. Ok, if you say so :)
[16:38] <cody-somerville> Hmm... it seems the dbus issue not only affect Xubuntu but also Ubuntu users.
[16:39] <cody-somerville> I've updated bug #232364 to critical
[16:39] <soren>  
[16:46]  * mvo grabs the dash merge if noone objects
[16:50]  * Lightkey objects to the use of dash as shell
[16:55] <cjwatson> tkamppeter: PostscriptColor.ppd seems to have disappeared from cups-pdf, but the postinst script still relies on it; this causes intrepid CD images to fail to install. What's the right fix?
[16:55] <cjwatson> (cp: cannot stat `/usr/share/ppd/cups-pdf/PostscriptColor.ppd': No such file or directory)
[17:00] <soren> Oh, yay, linux-source is back!
[17:10] <mvo> calc: do you mind if I take lzma?
[17:17] <mon> hi, i just built netatalk with DEB_BUILD_OPTIONS=ssl sudo dpkg-buildpackage -us -uc
[17:17] <mon> still it seems the required modules weren't build. any clues?
[17:18] <james_w> mon: DEB_BUILD_OPTIONS won't be propogated to the subcommand by default.
[17:18] <mon> so i should export it first or something?
[17:19] <mon> i pretty much copypasted it from a howto, seemed to work for the other readers
[17:19] <geser> mon: it's also a good idea to build as a user and use fakeroot
[17:19] <geser> install fakeroot and then "DEB_BUILD_OPTIONS=ssl dpkg-buildpackage -rfakeroot -us -uc"
[17:19] <mon> -rfakeroot?
[17:20] <mon> no space?
[17:21] <cjwatson> no space
[17:21] <cjwatson> I think 'debuild -e DEB_BUILD_OPTIONS=ssl -uc -us' is a bit easier though
[17:22] <cjwatson> (requires installing devscripts)
[17:23] <mon> i'm running the fakeroot version already
[17:23] <mon> though i don't really care whether i build as root or user (yes that's a BAD user!)
[17:24] <mon> this is my testing box and i really want it to "just work" ;)
[17:24] <mon> hm the process quit because it couldnt find libcrack-dev
[17:25] <mon> which was pointed out by the howto but i didnt include because i thought it was for testing passwords only
[17:26] <cjwatson> you do need to install all build-dependencies, as a general rule
[17:26] <cjwatson> or else modify the package to remove the need for them
[17:26] <cjwatson> if you absolutely believe it's not necessary and will build without, add the -d option
[17:26] <cjwatson>        -d     Do not check build dependencies and conflicts.
[17:30] <mathiaz> dholbach: is there a place where you have your really-fix-it script ?
[17:30] <dholbach> no, not right now - in a session, will chat to you about it in a bit
[17:30] <mathiaz> dholbach: great - thanks :)
[17:31] <bdmurray> pitti: still around?
[17:31] <pitti> hi bdmurray
[17:32] <bdmurray> Hi! I ran across bug 230877 and thought it looked like a good thing to fix for Hardy.
[17:32] <bdmurray> Well, or easy at least.
[17:33] <mon> it worked! thanks geser and cjwatson
[17:39] <mon> is there a more general linux-dev channel btw?
[18:06] <jcastro> anyone know the proper url in lp for all the intrepid specs?
[18:06] <pitti> jcastro: https://blueprints.launchpad.net/ubuntu/intrepid/+specs
[18:07] <pitti> jcastro: however, not complete yet (many are still only 'proposed')
[18:07] <jcastro> I see, no way to see the raw list?
[18:07] <pitti> not that I know of
[18:07] <jcastro> k, thanks
[18:08] <seb128> jcastro: what do you call raw list?
[18:08] <pitti> 'proposed' list?
[18:08] <jcastro> seb128: everything proposed
[18:09] <seb128> jcastro: https://blueprints.edge.launchpad.net/ubuntu/intrepid/+setgoals is you have access
[18:09] <jcastro> I don't
[18:09] <seb128> me neither ;-)
[18:09] <jcastro> but if it's not public then that's ok, I am just putting a report together of UDS
[18:09] <jcastro> and want to point people to the list of specs
[18:09] <jcastro> so whatever is available is fine by me
[18:10] <seb128> alright
[18:17] <\sh> didn't we have a spec about a launchpad client? ,)
[19:02] <bryce> cody-somerville: yes, in fact we're getting xcb via a libx11 sync from debian
[19:02] <bryce> cody-somerville: see changelog for libx11 (2:1.1.4-2)
[19:30] <cody-somerville> bryce, Corasc says Debian Xfce isn't experiencing this problem
[19:31] <cody-somerville> bryce, so it is either a Ubuntu delta exposing the libxcb bug or a ubuntu delta agitating it.
[19:37] <bryce> cody-somerville: ok
[19:38] <cody-somerville> bryce, I also feel that due to the nature of the issue a lot of people who experience it just restart x or reboot and continue going
[19:38] <cody-somerville> Clearly how Xubuntu is setup the issue occurs much more frequently which is why we have the bug reports
[19:38] <cody-somerville> but it has taken awhile for it to build up
[19:38] <cody-somerville> It started as a whisper and now it looks like a regression that affects both Xubuntu and Ubuntu.
[19:41] <mario_limonciell> cody-somerville, what's this bug number?
[19:42] <cody-somerville> bug #232364
[19:44] <mario_limonciell> wooh, yuck! :)
[20:32] <pitti> bdmurray: oh, indeed, that looks fine
[20:33] <bdmurray> pitti: should I subscribe ubuntu-main-sponsors then?
[20:33] <pitti> bdmurray: I assigned it to me
[20:33] <bdmurray> okay, great!
[20:34] <pitti> (just commented on the buG)
[20:34] <pitti> bdmurray: thanks for digging that out, that sounds important
[20:45] <BenC> checking for x86_64-linux-gnu-gcc... (cached) gcc checking for C compiler default output file name...  configure: error: C compiler cannot create executables
[20:46] <BenC> anyone know why that would be happening in intrepid amd64/grub builds?
[20:46] <BenC> can't reproduce it locally
[20:46] <BenC> and it seems to be grub specific, but it builds everywhere else fine, and locally fine
[20:46] <BenC> and it was fine in hardy
[21:14] <slangasek> BenC: it may be related to the new default CFLAGS settings
[21:20] <BenC> slangasek: anyway I can get config.log?
[21:20] <BenC> maybe I could hack the build to cat it before failing
[21:20] <BenC> so I can see it in the build.log
[21:20] <slangasek> could do
[21:32] <cody-somerville> So... what is the best course of action? I assume it would be too risky to recompile X11 with libxcb disabled or to apply the experimental upstream patches for Hardy :(
[21:41] <bryce> cody-somerville: well, the experimental patches don't apply.  I think what we need is a git tree we can pull from, or some directions on how to get those patches built
[21:50] <BenC> configure:2984: gcc -m32   -static conftest.c  >&5/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.1/libgcc.a when searching for -lgcc
[21:50] <BenC> slangasek: looks like -m32...not sure where it came from
[21:50] <BenC> maybe I need to do something about getting 32-bit libs in build-deps
[21:51] <slangasek> hrm, I thought grub was always built as 32-bit
[21:51] <slangasek> and I also thought it already had the build-dep on the 32-bit libs
[21:54] <BenC> slangasek: ah, I wonder if gcc-4.2-multilib needs to be changed to gcc-multilib
[21:54] <BenC> in build-deps
[21:55] <BenC> I have that locally, so it would explain it
[21:55] <slangasek> if there's a gcc-multilib available and we're otherwise not using a specific version, then that sounds right :)
[21:56] <BenC> intrepid is using gcc-4.3-multlib, and gcc-multilib is the meta package pointing to the right one
[21:57] <BenC> matching the gcc command
[21:57] <BenC> I'm pretty sure this will fix it
[21:57] <slangasek> sounds like it
[22:15] <cody-somerville> bryce, I don't think those patches would fix the issue anyhow without patching the applications themselves to use the stuff
[22:17] <bryce> ah ok
[22:17] <bryce> cody-somerville: is there anything else I could do in helping resolve this issue?
[22:18] <cody-somerville> bryce, make it work? :P
[22:18] <cody-somerville> lol
[22:18]  * bryce waves a wand
[22:19] <bryce> guess I can re-dig through all the logs and backtraces another time
[22:19] <cody-somerville> Oh, I know what you could do
[22:19] <cody-somerville> First, install Xubuntu and see if you can reproduce it easily enough
[22:20] <cody-somerville> Then you could try recompiling with xcb disabled and see if it still occurs
[22:21] <cody-somerville> btw, Keybuk was convinced that the select it was hanging on was in dbus-launch and not actually libxcb
[22:23] <cody-somerville> However, I'm not so sure because I attached gdb to the other running processes and they all had the similiar backtraces.
[22:23] <cody-somerville> xfce4-session had pretty much the same backtrace as dbus-launch
[22:24] <cody-somerville> the others were in some xcb wait function
[22:25] <bryce> what did Keybuk say exactly?
[22:27] <bryce> the one system I have that I can easily reinstall at the moment is an amd64. have there been reporters seeing the problem on amd64?
[22:27] <cody-somerville> bryce, yes
[22:27] <cody-somerville> http://ubuntu.pastebin.com/m50aa1bc4
[22:29] <bryce> ah thanks
[22:29] <bryce> hmm
[22:29] <bryce> so sort of sounds like debugging from the libxcb side of things is the wrong place to look?
[22:31] <bryce> hmm, scott's comments just give me more questions :-P
[22:32]  * cody-somerville nods.
[22:32] <cody-somerville> I talked to someone else
[22:33] <cody-somerville> and they said the previous write statements do not mean that it isn't in libxcb
[22:34] <cody-somerville> bryce, if you were to attach gdb to X, what would you expect to see?
[22:35] <bryce> since it's a hang, I'd expect it to be stuck somewhere along the waitfor loop
[22:37]  * cody-somerville nods.
[22:37] <cody-somerville> #0 __kernel_vsyscall()
[22:38] <cody-somerville> #1 wait4() from [path to libc]
[22:38] <cody-somerville> #2 ??
[22:38] <cody-somerville> #3 __libc_start_main from [path to libc]
[22:38] <cody-somerville> #4 ??
[22:38] <cody-somerville> But before that
[22:38] <cody-somerville> Er,, sorry
[22:38] <cody-somerville> I tried again and the next time I found it was in ptrace
[22:40]  * cody-somerville ponders.
[22:41] <bryce> well, in case it is an xcb issue, I do know bart massey personally...  I'll drop him an email.  If nothing else maybe he can get some action going on our upstreamed bug.
[22:42] <cody-somerville> Well, the issue seems to be deadlocks involved in waiting for responses from the X server.
[22:45] <cody-somerville> and it has been known since 2004
[22:45] <cody-somerville> Who decided to enable libxcb anyhow?
[22:45] <bryce> now, now
[22:50] <bryce> email sent
[22:50] <bryce> I cc'd you
[22:50] <bryce> I don't think it's productive for you to look for assigning blame, but you can consider it my decision if you want
[22:51] <bryce> of course, the decision ultimately comes from upstream of us
[22:52] <bryce> libxcb had been disabled in debian previously due to problems it caused with java apps, so we did not activate it until after that problem was resolved.
[22:53] <cody-somerville> I'm not looking to "place blame".
[22:53] <cody-somerville> I wanted to discuss with the person (ie. you) if it would be possible for us to disable it again
[22:55] <bryce> of course anything is possible, however do you have proof that the problem goes away when it's disabled?
[22:55] <cody-somerville> bryce, I would ofcourse test the solution before recommending it :)
[22:56] <bryce> there's also the issue if turning it off would cause other problems
[22:56]  * cody-somerville nods.
[22:56] <cody-somerville> Indeed. Very scary prospects all around.
[22:57] <bryce> let's wait on bart's response.  Bart was the one who encouraged us to turn it on long ago, so I'd expect him to supply some help in pointing us towards solutions.
[22:58] <bryce> even if we did shut it off in hardy, though, I'd want to leave it on for intrepid.
[22:58] <bryce> the only way these issues are going to get found and fixed is if people use it and report it
[22:59] <cody-somerville> bryce, In the mean time, I'm going to see if omitting --exit-with-session fixs the hang and just take care of killing dbus manually.
[22:59] <bryce> ok
[22:59] <bryce> I'll see if I can identify what's involved in compiling libx11 without libxcb if you want to also test that
[23:00] <slangasek> isn't that "grab an older version of libx11 before the switch"?
[23:00] <bryce> slangasek: maybe
[23:00] <cody-somerville> bryce, whats the risk associated with the session bus not being terminated at the end of session?
[23:01] <bryce> cody-somerville: I'm not sure...  if the user re-logged in would it result in multiple sessions running?
[23:06] <bryce> cody-somerville: btw have you been able to obtain a full backtrace yet?
[23:06] <cody-somerville> What did you say was the command for that?
[23:07] <bryce> (gdb) backtrace full
[23:07] <bryce> also see https://wiki.ubuntu.com/X/Backtracing
[23:08] <bryce> this looks like maybe the bit keybuk was referring to:
[23:08] <bryce> [pid  7877] read(20, 0x8056f3c, 4096)   = -1 EAGAIN (Resource temporarily unavailable)
[23:08] <bryce> [pid  7877] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfd17a18) = -1 ENOTTY (Inappropriate ioctl for device)
[23:08] <bryce> [pid  7877] select(21, [20], NULL, [20], NULL) = 1 (in [20])
[23:08] <bryce> [pid  7877] read(20, "", 4096)          = 0
[23:13] <bryce> cody-somerville: mm interesting check this search out - https://bugs.freedesktop.org/buglist.cgi?quicksearch=dbus-launch
[23:14] <bryce> "You can look at the environment of your apps with something like
[23:14] <bryce> "ps ewwwww" and everything in your login session should have the same
[23:14] <bryce> DBUS_SESSION_BUS_ADDRESS. If anything has a different (or missing) address,
[23:14] <bryce> that is your problem."
[23:14] <bryce> fdo #8294 looks interesting
[23:15] <bryce> not directly relevant though
[23:17] <bryce> ditto 9884
[23:20] <cody-somerville> hmm
[23:45] <cody-somerville> Weird, a buddy of mine reports those recent updates to gutsy caused his screen to revert to 800x600.
[23:46] <bryce> cody-somerville: the only X updates were some security fixes
[23:46] <bryce> and that was about a week or so ago
[23:48] <cody-somerville> bryce, from the log, it seems like it was after the kernel was updated.
[23:49] <bryce> cody-somerville: was he using -nvidia or -fglrx by chance?
[23:49] <cody-somerville> yes
[23:50] <bryce> which?
 bryyce: Oh what fun.  X is starting up in failsafe mode after rebooting on the new 2.6.24-19 kernel
[23:50] <bryce> * gchaix digs into the logs
 Huh ... comes up in vesa mode thinking the virtual size is only 800
[23:50] <bryce> gchaix was using -nvidia
[23:50] <cody-somerville> He has an nVidia card to the best of my knowledge.
[23:50]  * cody-somerville nods.
[23:50] <cody-somerville> nvidia
[23:51] <bryce> gchaix was on hardy though
[23:51] <bryce> could have been the same update though
[23:51] <bryce> cody-somerville: fwiw, gchaix worked around via use of envyng
[23:52] <bryce> however I'm not sure how safe envy was on gutsy
[23:54] <bryce> anyway, kees thinks it's probably unrelated.  -nvidia troubles are usually caused by "badly installed meta packages or 3rd party drivers"
[23:55] <kees> heh, beat me to it -- was just going to say it here too :)
[23:56] <bryce> kees, while we have your attention, would you mind looking at this xubuntu/xcb bug, that seems to be hanging during a socket() call?  https://bugs.freedesktop.org/show_bug.cgi?id=16420
[23:56] <bryce> kees: we're currently stumped on what to do next to debug it further, and have not yet gotten feedback from upstream