=== bjf is now known as bjf[afk] [00:08] lool: I've enabled bugs for launchpad.net/packages-arch-specific === jjohansen is now known as jj-afk [00:20] hey yall [00:20] does anyone know if unity is going to be improved upon enough so that it is a usable workstation before the release of natty? [00:24] admins, could you restart Merge-o-Matic? [00:28] does anyone know if unity is going to be improved upon enough so that it is a usable workstation before the release of natty? [00:28] That's certainly the plan. [00:29] And it's not unusable now; it's now the default. [00:30] you can't drag/drop files, you can't select multiple files and move around, not much in the theme customization, etc [00:31] glad there's other options in case this stuff falls through [00:54] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [01:31] cjwatson: Thanks, added first bug task to p-a-s === Amaranth_ is now known as Amaranth [02:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: TheMuso === asac_ is now known as asac === v is now known as stalcup [03:29] * achiang would like to get some guidance on bug #469376 [03:29] Launchpad bug 469376 in udev (Ubuntu) "USB device insertion causes total system lockup on Ubuntu 9.10" [Undecided,Incomplete] https://launchpad.net/bugs/469376 [03:29] my question is, does that bug qualify for SRU process? [03:30] achiang: Almost certainly not a total backport [03:30] admittedly, my fix was somewhat blunt trauma, involving an entire backport [03:30] We don't like blunt trauma for SRUs [03:30] nod [03:31] achiang: its all about risk. [03:31] hm, maybe comment #18 has a clue. i could look in the upstream modem-manager logs to see if there's a fix for "ozerocdoff" [03:31] that would probably be sufficient to cherry pick [03:32] Yeah, that would likely work [03:32] Alternatively, try git-bisect :) [03:33] ebroder: i mean... yeah, but. for each bisection run, i'd have to rebuild the package... [03:33] and i don't think the ubuntu package is setup for that [03:34] so that means grabbing upstream git repo, dropping in the debian/ directory, and then hoping it builds at random bisection points [03:35] not to mention, how do i manage the package on my test system... although i guess i could just fake continuously increase the ubuntuX version number for each bisection run [03:35] ubuntuX~meY ? [03:35] achiang: I would drop the debian directory in, assume that running through the bisection won't touch it, and leave the version number the same the whole time - dpkg -i will gladly install whatever .deb you give it, regardless of the version [03:36] And you can tell git-bisect to skip a revision if it doesn't build [03:36] ebroder: not a bad point... [03:36] The tricky part is because you're trying to bisect a fix, the meanings of git-bisect's "good" and "bad" are reversed [03:36] maco: ah, thanks for the reminder. i always forget the ~ operator in version strings [03:36] ebroder: yep, i'm familiar with that. :) [03:36] achiang: well youd want + if youre using the old ubuntuX number and ~ if youre using the future one... [03:38] ModemManager$ git log 07114d..be28089 --oneline | wc -l [03:38] 384 [03:39] maybe a bisection run is what i want. that's a lot of commits to inspect manually... [03:39] achiang: You know about the pickaxe? :) [03:39] ebroder: hm, what should i be pickaxing for? [03:39] ozerocdoff? [03:40] duh [03:41] first, i need to figure out how to re-install lucid onto this netbook that lacks a cdrom drive. previous attempts with usb-creator on my maverick host system have turned out poorly === Chipaca` is now known as Chipaca [04:07] should i expect to turn the i386 desktop iso here: http://releases.ubuntu.com/lucid/ and create a bootable USB image using usb-creator-gtk? [04:07] yeah [04:08] i keep getting "Unknown keyword in configuration file: gfxboot" and then "vesamenu.c32: not a COM32R image" [04:08] this is with both a USB key and an SD card [04:08] achiang: I think there's an issue with creating Lucid USB keys using Maverick's usb-creator and vice versa [04:09] Related to some changes in our syslinux packages [04:09] ugh [04:09] bug #645818 [04:09] Launchpad bug 645818 in usb-creator (Ubuntu Natty) "10.04.1 image created in Maverick does not boot in my Dell Mini9" [Critical,Triaged] https://launchpad.net/bugs/645818 [04:09] Apparently it was release-noted [04:10] ebroder: thanks. good to know it's not PEBCAK [04:10] But you should get a prompt where you can type "live" or "live-install", depending on what you're trying to do [04:10] nope, i get to neither... see above error message [04:10] Not after the error? [04:10] oh hm [04:11] * achiang reads the bug in more depth [04:11] ok, some workarounds in there... [04:12] wow, the 'help' workaround actually helped. [04:13] ebroder: thank you [04:13] np [04:43] boo. as expected, simply dropping debian/ into upstream ModemManager and trying a pbuild in a lucid chroot experiences a FTBFS. :-/ [05:14] Quick debugging question: Is there any way to get gdb to use symbolic names for #defines? I know that the information no longer exists in the code, but it'd be really helpful to see “GL_LINEAR_MIPMAP_LINEAR” rather than “9987” [05:25] whoo. git bisect going fast now. [05:26] RAOF: I don't think gdb even has that information -- since the #defines are replaced by the C pre-processor [05:27] Yeah. [05:27] It *could* parse out the .h files and match values to #defines though. [05:27] I mean, you'd false-positive quite often, but you could do it :) [05:28] shouldn't that just work though? does gdb know about your source directory? [05:28] compile with -gdwarf-2 -g3 :) [05:28] Sarvatt: Really? That keeps #define information? [05:29] And if so, why don't we build *all* packages with that? [05:30] Probably because it's massive [05:30] I'd trade an order of magnitude bigger -dbgsym packages for #define information. [05:32] Considering that dbgsym packages are only used for debugging, and live in a separate repo, I'd agree. [05:33] * RAOF tries a test-build of mesa with -gdwarf-2 -g3 [05:34] OUCH [05:46] * RAOF is off for some exercise, and will be back on later. [06:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [06:02] TheMuso: Something weird is up with your sbuild. I don't know where it's getting sysvinit from [06:03] ebroder: Hrm ok, my maverick chroots may need a complete rebootstrap. [06:08] ebroder: I am rather busy for the rest of the day, and don't have time to track this down. I'll fix up the bug and comment, leaving it free for the next pilot/another sponsor to pick up. SOrry about that. [06:08] TheMuso: No worries. Thanks for pilotting [06:08] np [06:09] kees: but its back on now [06:19] Good morning [06:21] chrisccoulson: hm, I haven't worked with po2xpi so far, that was between Arne and Alex === LibertyZero is now known as _LibertyZero_ === hunger_ is now known as hunger [07:12] good morning! [07:12] good morning dholbach [07:12] hi ssj6akshat [07:33] good morning === almaisan-away is now known as al-maisan === smb` is now known as smb === jj-afk is now known as jjohansen [09:37] any chance of getting my patches to vifm into the Ubuntu distro ? [09:37] vifm is 0.4 in Ubuntu right now [09:37] and I'm working on some new things for it here https://github.com/wsdookadr/vifm [09:56] spetrea: your best bet is to talk to the debian maintainer for vifm, it looks like he should package up 0.5 as well. We are currently carrying a few patches to it, so some more won't hurt (if they are important) [09:59] cjwatson: could you restart Merge-o-Matic? [10:11] tumbleweed: are you familiar with vifm , can I describe to you my patches ? [10:26] hm, it seems natty's kvm has some serious trouble booting the desktop CDs (also maverick's) [10:34] oh, seems it's the tablet emulation that breaks it === elky is now known as melissa === melissa is now known as elky === ogra_ac_ is now known as ogra_ac [11:13] didrocks: good that we have mutter, wondering if compiz ever will be unb0rken ^_^ [11:19] sebner: mutter is hellspawn that should just die [11:20] hyperair: it works at least :P [11:20] sebner: compiz 0.9 works here [11:20] gnah [11:20] sebner: your machine's screwed ^_^ [11:20] hyperair: compiz is screwed since ~1 week xD [11:20] sebner: probably because compiz++ was uploaded then? [11:21] it's a rewrite. it's bound to be broken. [11:21] sebner: and go complain to smspillaz on #ayatana or #compiz-dev. ;-) [11:21] hyperair: wonderful, I updated mutter and that segfaults now too xD [11:21] sebner: i filed a steady stream of bugs until this thing was usable for me. [11:21] sebner: oh lol. =p [11:28] hyperair: mutter+gtk3 = b0rken. downgrading both fixes mutter at least. debugging compiz now === pedro__ is now known as pedro_ [11:45] spetrea: no, although I've touched it in the past [11:55] anyone an idea what dbg package I have to install for 0x00000001 in ?? () at /usr/include/c++/4.5/bits/vector.tcc:295 ? I already tried gcc4.5-dbg and libstdc++6-4.5-dbg (libstdc-dev seems to include this file) but didn't work [12:12] cjwatson, pitti: Hey there; would you mind NEW-ing three new kernel sources in natty? linux-linaro-{mx51,vexpress,omap} are the source package names; these are going to go through binary NEW afterwards as well === MacSlow is now known as MacSlow|lunch === jjohansen is now known as jj-afk [13:15] lool: hey (sorry, had a long phone call) [13:15] looking [13:16] lool: hm, we already build -omap from the main linux source? [13:17] lool: and also from linux-linaro [13:18] pitti: linux-linaro will go away [13:18] pitti: Main linux source > I think the omap flavor is going away too [13:19] pitti: In any case, the Linaro kernels are different; they are used in the Linaro images and have different config policies and patches etc. [13:19] pitti: In fact, if you look at latest linux source package, it didn't build omap on armel anymore [13:20] So I think linux-linaro-omap is the only remaining one for OMAP3 [13:20] (considering linux-linaro is going away) [13:20] qok [13:20] -q [13:20] lool: (it's a shame, though) [13:20] pitti: Which part? [13:21] I thought the various flavours would be united in one source, not that the one source would be split further [13:21] pitti: It's all generated from a single git tree, but build time was getting an issue [13:21] pitti: But we are working on limiting the number of flavors [13:21] oh, this is just to work around buildd time, it's actually one source? [13:21] pitti: For instance our omap flavors supports OMAP3 and OMAP4 [13:22] pitti: Yes, the main reason for the split is build time [13:22] buildd time === oubiwann is now known as oubiwann_ === oubiwann is now known as oubiwann_ [13:27] pitti: thanks [13:27] lool: de rien === oubiwann is now known as oubiwann_ === MacSlow|lunch is now known as MacSlow === doko_ is now known as doko [13:40] ScottK: are these expected? http://paste.ubuntu.com/538284/ [13:40] Riddell: ^^^ [13:42] doko: I think so, but I'm not certain. [13:44] james_w, heyo about pkgme: is 'description' supposed to spit out a debian/control formatted description? with a shortline and then indented paragraphs? === yofel_ is now known as yofel [14:02] mterry, currently yes, but I'm open to changing it if you would like [14:03] james_w, can you mark https://code.launchpad.net/~nataliabidart/ubuntu/natty/ubuntu-sso-client/ubuntu-sso-client-1.1.4/+merge/42169 as "rejected" or "superseded" or something please? [14:03] hey dholbach [14:03] james_w, or should the branch itself be marked as merged, abandoned or something? [14:04] hey james_w - how are you doing? :) [14:04] dholbach, good thanks how are you? [14:04] dholbach, marked as rejected for you [14:05] good - it's just just gotten a bit cold over here :) [14:05] james_w, I'm not partial... for autotools, there's no well-formatted source for a description. I could gobble up README if it exists, but not guaranteed to have nice summary line or anything. And it would be a pain for each backend to implement the 'make it indented with blank lines being " ."' logic. Maybe pkgme could mangle output of description to the right format? Still doesn't help with not having a good summary l [14:05] ine [14:05] * dholbach hugs james_w [14:05] james_w, thanks muchly [14:05] mterry, yeah, I agree [14:05] pitti: hi [14:06] hello mdz [14:06] pitti: your notes from the previous TB meeting say that sabdfl is supposed to chair this one, but I see he has declined the calendar invite [14:06] james_w, so I'm inclined for vala to not ship a 'description'. 'maintainer' is interesting. There are sources for that information (MAINTAINERS and AUTHORS), but looks like I would need to pull out one email address to use right? Or can that field have commas? [14:06] mterry, I'm not sure about that actually [14:07] mdz: ah, ok; he was the designated chair last time, so I took over and carried over Mark, I didn't actually ask him TBH [14:07] mterry, it does point out the need for some way for the user to give info that the backend can't/won't provide [14:07] james_w, exactly [14:08] james_w, the autotools backend could do a 'dumb' implementation of MAINTAINERS and only provide output if it's exactly one line [14:08] james_w, that way the user could at least enter something. Doesn't fix README though [14:08] no [14:08] maybe we should have a pkgme.info file that is read or something? [14:09] james_w, maybe that would be easiest... or a doap file? That would be nice and standard. Not sure it has fields like we expect, let me check [14:09] XML isn't the friendliest... [14:10] mvo: have you had a chance to consider my brainstorm request? [14:12] mterry, hmm, doap would be cool actually, but I've never used it [14:15] mdz: not yet, sorry. but I push it higher in my todo list [14:16] mvo: if you can't make the time for it, it's OK to suggest someone else who you think could do it [14:18] mdz: thanks, I can create answer from my POV by tomorrow I think and will probably ask mpt to answer on the design questions/ideas [14:20] james_w, well, doap seems like it has several things we want: homepage, maintainer, shortdesc, description. Surprisingly does not appear to have a 'package_name' equivalent (only allows you to specify user-readable name). Not sure that's necessarily worth its complexity? I guess it depends on whether we think using the standard format would make it easier for UIs to generate the file? [14:21] mvo: the text is due in the next week or so; I'm just looking for confirmation that you will be able to do it by the deadline [14:21] mvo: can I put you down as 'confirmed' then? [14:22] mterry, perhaps if the information is there we should make use of it. However, if it doesn't cover all our needs we would need a pkgme.info as well? [14:22] james_w, well, for the autotools case, it would cover all the missing gaps (maintainer, shortdesc, and description) [14:22] mdz: yes [14:22] james_w, I don't know about other buildsystems [14:23] mterry, right [14:23] mterry, this points to another need for layering backends? [14:23] mvo: great, thanks [14:24] james_w, or really probably just providing a library of buildsystem helpers. A vala backend might support both autotools and buildj and cmake, so simple inheritance may not be helpful. [14:25] mterry, hmm, good point [14:25] pitti, about the QT bug [14:25] mdz: yw :) [14:26] james_w, and maybe fake layering by falling back to a default helper for the currently specified 'buildsystem' if the backend doesn't provide it. That way vala backend wouldn't have to specify a stub if it wouldn't add anything [14:26] pitti: About the Qt SRU, I understand it's going to go through, but please don't force the same change into Natty. Let's give upstream some time to work on it first (also due to gcc-4.5 breakage we can't build Qt in Natty right now anyway). [14:26] pitti, could you just accept the SRU into -updates, QT in maverick wont build atm [14:26] ogra_ac: maverick/natty [14:26] err, yes [14:27] ScottK: I wasn't going to; the task is open [14:27] pitti, for natty we would like to leave upstream the opportunity to fix it properly during the cycle ... if that doesnt work we can still apply the same change and have a NEON PPA [14:27] yes, I totally agree [14:27] pitti, we would like to have the STU done [14:27] *SRU [14:27] okay [14:27] but you make that depend on a natty upload [14:27] cool [14:28] yay [14:28] ogra_ac: I think a Neon PPA for Qt for Natty is not an acceptable solution. The runtime detection has to be fixed. [14:28] cjwatson: sabdfl will not be attending TB today, but is scheduled to chair. you're next in the rotation; would you be willing to fill in for him? [14:29] ScottK, i agree [14:29] ScottK, ogra_ac: marking as RC for natty beta, to keep it on the radar [14:29] ScottK, but if its not fixed we need a fallback [14:29] ScottK, static NEON isnt an option either [14:29] ogra_ac: Then put the no-NEON version in the PPA. [14:29] so the PPA is a fallback if upstream doesnt manage [14:30] ScottK, not an option [14:30] yeah [14:30] userspace needs to support all armv7 platforms [14:30] we should never put neon by default, unless it's able to do the runtime detection [14:30] ogra_ac: What supported hardware is it a problem for? [14:30] ScottK, the two options lool noted in the bug are fine [14:31] ScottK, this is not about supported/unsupported HW [14:31] this is about a commitment for our default userspace [14:31] there are people who build community images on top of our archive, and they need no neon by default [14:32] and we said that we would not put neon by default, publicly [14:32] either have proper runtime detection or have a NEON PPA or build QT twice and have two binaries are the options we have [14:32] rsalveti: Who is the "we"? [14:32] canonical arm team [14:32] OK. Not my problem then. [14:32] there are people using ubuntu on non NEON devices [14:33] ogra_ac: As long as I can build an Ubuntu ISO with NEON in Natty, I'm happy. [14:33] It sounds like there are options that support that. [14:33] ScottK, make upstream fix runtime detection is your best bet then === zyga is now known as zyga-sick [14:33] So we can move on and fall back to one of them if upstream doesn't get the runtime detection sorted. [14:33] right [14:33] ogra_ac: I agree that's best. [14:33] we dont want to block you, dont take it personal [14:34] ogra_ac: I'm extremely frustrated that Canonical is making requirements on Ubuntu that aren't communicated to the community. [14:34] the NEON settings are communicated since several releases [14:34] yeah [14:35] that decision was made during januty iirc [14:35] ogra_ac: Where is this documented? [14:35] probably also over uds and etc [14:35] rsalveti, That's not really documentation, as such. Someone needs to turn that into something else to be proper docs. [14:35] there must be mails from lool to ubuntu-devel from that time iirc and meeting logs as well [14:36] there were also specs to research it [14:36] and the outcome is documented somewhere [14:36] iirc also in mails to -devel [14:37] iirc NCommander did speed tests and researched vfp and neon during jaunty or jaunty+1 [14:38] "I think there's some email from two years ago" isn't much in the way of documentation. [14:39] dholbach: What is the procedure of adding a datasource to hall-of-fame.ubuntu.com ? [14:43] ogra_ac: just VFP === freeflyi1g is now known as freeflying === zyga is now known as zyga-bed [15:23] didrocks: hello, I am looking at NUX FTBFS on ARM [15:24] janimo: yes? [15:24] didrocks: shall I provide bugreports to NUX in LP directly or to you? [15:24] and patches [15:25] janimo: just post patches against nux and the dx team or I will review/integrate in nux upstream [15:25] (so bug report against nux) [15:25] ok, thanks [15:25] yw :) === bjf[afk] is now known as bjf [15:28] didrocks, merge proposal! [15:28] dholbach: well, we are good upstream and we look at patch in any form, merge proposal or others :) [15:28] dholbach, pffft, all that progressive stuff [15:29] ogra_ac, grandpa... here's your cup of tea [15:29] :) [15:30] hmm, a hot cup of tea at this weather is pretty nice [15:31] *slurp* [15:31] geser, you're right :) === dholbach_ is now known as dholbach === beuno is now known as beuno-lunch === jj-afk is now known as jjohansen [16:09] wendar, Two packages to look at for some reference are menu-xdg and ubuntustudio-menu. Neither is precisely what you want, but both use conffiles to modify the menu structure, or add new entries. All conforming XDG menu systems (like those in GNOME and KDE) are able to use these files in a sane way, and most of the various menu systems and launchers in the archive work with it (excepting those that use the Debian menu system). === diwic is now known as diwic_afk === amitk is now known as amitk-afk [16:20] persia: great, we'll see if we can use that in the ARB packages for maverick [16:20] doko: yes those missing files are fine [16:20] Riddell: thanks [16:21] wendar, Bug me after taking a look at those, and I'm more than happy to help find a working conffile that extras users ought install. It's probably worth reading the menu spec also, but it's not very rich. [16:23] persia: will do, thanks === tkamppeter_ is now known as tkamppeter [16:52] mvo, hi, should do-release-upgrade work on lucid ppc to upgrade to maverick? [16:53] mvo, I'm getting "No new release found" [16:54] it probably knows that you are ill and wants to make sure you dont work while you shouldnt ;) [16:54] zyga-bed: make sure you have /etc/update-manager/release-upgrades set to normal (instead of lts) [16:54] ogra, hehe [16:54] haha [16:54] (to ogra) [16:54] mvo, thanks :-) [16:54] ogra, I feel horrible doing nothing [16:55] * ogra_ac knows how that feels [16:56] working on atom while being used to work on core i7 is also horrible :D [16:56] zyga-bed: get well [16:56] mvo, thanks, I took medicaments, got a big bowl of warm tee [16:57] the fever is slowly going away but I still have 37,7 [16:57] (funny how most locales use . for decimal point while pl uses ,) [17:00] what the hell is going on with MoM? [17:00] ari-tczew, hi === sanchaz-away is now known as sanchaz [17:00] hi zyga-bed [17:07] anyone know how to get the current virtual terminal ? [17:07] ie, to save so that i can 'chvt X' back to it === beuno-lunch is now known as beuno === al-maisan is now known as almaisan-away [17:17] didrocks, bah, could you what the ayatana team from me for explicitly using x86 assembler in their code ? [17:17] :) [17:18] ogra_ac: just go on #ayatana :) [17:18] the current nux build looked so good [17:18] pitti: where did the configs move for the WI tracker since they're not in the trunk now? [17:19] SpamapS: lillypilly (aka people.c.c); sudo -u platform -i [17:19] SpamapS: then edit them in work-items-tracker/config/ [17:20] SpamapS: I dropped it from bzr since they break using the WI tracker for other projects (at least the all-projects script) [17:21] pitti: ahh.. ok, I will have to finally figure out how to get on that box. ;) [17:23] pitti, hi, how many other similar reports are generated? [17:24] pitti, apart from the work item tracker [17:24] zyga-bed: I don't know, but I heard from at least two other people that they are using this for their projects [17:24] (non-Canonical/Ubuntu, I mean) [17:25] pitti, but are they using the work item data or something entirely separate? [17:25] just the code and scripts, not our data of course [17:25] ok [17:25] the ubuntu-armel report is a community report [17:25] but I don't want to see the entire world's configuration files in upstream trunk [17:25] if we want this stuff in bzr, it shold be in a separate tree [17:25] if anyone wants to set that up, feel free [17:26] pitti, I'm asking because of different context [17:27] * pitti waves good night [17:27] pitti, I wrote django-reports and after the first demo report I'm adding an example report that taps into the data from the work item tracker [17:27] pitti, good night :-) [17:27] zyga-bed: if you actually want to use the Ubuntu data, the .db files are available there as well [17:28] pitti, yeah but for the moment using JSON is better for me _unless_ I can open your database file locally [17:28] pitti, and doing the former makes me more likely to implement proper asynchronous tasks into the system [17:28] pitti, anyway, I'll show you what I have once I get better and finish it [17:29] pitti, the upside to static reports is that it's a live application [17:29] pitti, and that all data it can show on the html page can be accessed via xml-rpc [17:45] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bdmurray === jcastro_ is now known as jcastro === apachelogger is now known as releaselogger [18:34] didrocks: I filed a bug about the latest mutter crash, should I subscribe anyone specific? [18:40] sebner: on natty or maverick? [18:40] didrocks: natty of course [18:41] sebner: nobody then, we dropped our specific patch and I'm not sure who is following mutter on natty [18:41] sebner: I have enough to do with compiz TBH :) [18:42] sebner: I wonder if we should sync from debian as well. Will have a look at the specific patch we still have === releaselogger is now known as apachelogger [18:45] didrocks: uhh, that's bad. hmm, You can look at my compiz bug then :P I'm just using mutter (downgraded) because compiz is b0rken :P [18:46] sebner: compiz broken on natty? yeah, fire the number then :) [18:46] didrocks: bug #683081 , I already subscribed our compiz hero. Not sure how to improve the backtrace though [18:47] Launchpad bug 683081 in compiz (Ubuntu) "Compiz segfaults on start-up" [High,New] https://launchpad.net/bugs/683081 [18:47] known issue? after fresh install today, run updates, no top panel, no dock when restarting [18:47] charlie-tca: might be compiz related ^^ [18:48] Want a bug, then? [18:48] charlie-tca: nvidia card? [18:48] ati radeon 9800 [18:48] hum, no acceleration support? [18:48] I don't know [18:49] charlie-tca: it seems not, you should logout and choose the "gnome classic session" [18:49] got a desktop, just nothing else. [18:49] seems you don't have acceleration support, that will be an alpha1 release note [18:49] logout? got nothing. [18:49] charlie-tca: ctrl + alt + t [18:50] gnome-panel [18:50] and then logout :) [18:50] well, I'll be. It worked [18:50] charlie-tca: but your issue isn't a bug, just a consequence of no fallback support yet [18:51] (when unity can't run) [18:51] Okay [18:51] will come with alpha2 [18:51] but it runs until I update [18:51] sebner: yeah, the stactrakce is small [18:51] charlie-tca: yeah, but we got unity + gnome-panel for normal case [18:51] charlie-tca: which leads to a lot of other issues :) [18:51] Okay [18:51] thanks [18:51] yw :) [18:51] sebner: is apport activated for you? [18:52] didrocks: howto check? [18:52] sebner: you should report the bug with it [18:52] sebner: /etc/default/apport [18:52] * sebner tests [18:52] didrocks: disabled [18:53] sebner: ok, so enable it, reboot or launch apport service and make compiz crash [18:53] then, report the bug :) [18:54] didrocks: mind invaliding the old bug meanwhile? [18:54] sebner: sure [19:00] didrocks: bug# 683293 [19:00] bug #683293 [19:00] Bug 683293 on http://launchpad.net/bugs/683293 is private [19:01] sebner: can you mark it as not private if you have no private data? [19:01] otherwise I'll add sam [19:01] thanks :) [19:01] ok, let's wait apport to retrace it [19:02] didrocks: oh, didn't notice. Is it uploading furthers logs in the background? [19:03] sebner: yeah, but it's ok :) apport will run against it on launchpad and get a nice backtrace with debug symbols [19:03] then, we will have a look at it :) [19:03] thanks! [19:04] didrocks: heh, thanks to you too. Pretty nice to have a contact person =) [19:04] Compiz is nonresponsive on shutdown. Known issue? [19:04] * didrocks runs… [19:04] bilalakhtar: /here too [19:04] bilalakhtar: yes [19:04] so /me is not the only person facing it.. [19:04] * bilalakhtar could help === bilalakhtar_ is now known as bilalakhtar [19:14] kees: ok, its all working and stable now [19:14] kees: I'd expect nice fast responses, consistently. === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === diwic_afk is now known as diwic [19:44] didrocks, nvidia 6200 with hardware driver installed gives blank desktop too [19:44] charlie-tca: hum, you have acceleration support? that's weird? I have a nvidia card there working well [19:45] charlie-tca: glxinfo returns "hardware accelerated" or "software rendered"? [19:45] (have to popout quickly, it's getting late there [19:45] starting it again. [19:45] it is an encrypted install, if it makes a difference [19:46] today's updates did remove "ubuntu-desktop", but that should not have removed everything. [19:47] charlie-tca: do you have compiz and unity installed? [19:47] I did dnot remove them [19:48] All I did is install from today's alternate image, then run "sudo apt-get update" and "sudo apt-get dist-upgrade" [19:48] then I restarted [19:48] charlie-tca: you should get it, and for the glxinfo? [19:48] checking [19:49] (really need to go…) [19:49] dirct rendering yes [19:49] and server glx vendor string ? [19:51] charlie-tca: if it's not "software rendered", please report a bug against unity with a compiz --replace stacktrace please :) [19:51] will do [19:51] thanks [19:52]