[00:08] <cjwatson> lool: I've enabled bugs for launchpad.net/packages-arch-specific
[00:20] <robertzaccour> hey yall
[00:20] <robertzaccour> 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] <ari-tczew> admins, could you restart Merge-o-Matic?
[00:28] <robertzaccour> 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] <RAOF> That's certainly the plan.
[00:29] <RAOF> And it's not unusable now; it's now the default.
[00:30] <robertzaccour> you can't drag/drop files, you can't select multiple files and move around, not much in the theme customization, etc
[00:31] <robertzaccour> glad there's other options in case this stuff falls through
[00:54] <robert_ancell> @pilot out
[01:31] <lool> cjwatson: Thanks, added first bug task to p-a-s
[02:00] <TheMuso> @pilot in
[03:29]  * achiang would like to get some guidance on bug #469376
[03:29] <achiang> my question is, does that bug qualify for SRU process?
[03:30] <ebroder> achiang: Almost certainly not a total backport
[03:30] <achiang> admittedly, my fix was somewhat blunt trauma, involving an entire backport
[03:30] <ebroder> We don't like blunt trauma for SRUs
[03:30] <achiang> nod
[03:31] <lifeless> achiang: its all about risk.
[03:31] <achiang> 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] <achiang> that would probably be sufficient to cherry pick
[03:32] <ebroder> Yeah, that would likely work
[03:32] <ebroder> Alternatively, try git-bisect :)
[03:33] <achiang> ebroder: i mean... yeah, but. for each bisection run, i'd have to rebuild the package...
[03:33] <achiang> and i don't think the ubuntu package is setup for that
[03:34] <achiang> so that means grabbing upstream git repo, dropping in the debian/ directory, and then hoping it builds at random bisection points
[03:35] <achiang> 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] <maco> ubuntuX~meY ?
[03:35] <ebroder> 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] <ebroder> And you can tell git-bisect to skip a revision if it doesn't build
[03:36] <achiang> ebroder: not a bad point...
[03:36] <ebroder> 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] <achiang> maco: ah, thanks for the reminder. i always forget the ~ operator in version strings
[03:36] <achiang> ebroder: yep, i'm familiar with that. :)
[03:36] <maco> achiang: well youd want + if youre using the old ubuntuX number and ~ if youre using the future one...
[03:38] <achiang> ModemManager$ git log 07114d..be28089 --oneline | wc -l
[03:38] <achiang> 384
[03:39] <achiang> maybe a bisection run is what i want. that's a lot of commits to inspect manually...
[03:39] <ebroder> achiang: You know about the pickaxe? :)
[03:39] <achiang> ebroder: hm, what should i be pickaxing for?
[03:39] <ebroder> ozerocdoff?
[03:40] <achiang> duh
[03:41] <achiang> 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
[04:07] <achiang> 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] <maco> yeah
[04:08] <achiang> i keep getting "Unknown keyword in configuration file: gfxboot" and then "vesamenu.c32: not a COM32R image"
[04:08] <achiang> this is with both a USB key and an SD card
[04:08] <ebroder> achiang: I think there's an issue with creating Lucid USB keys using Maverick's usb-creator and vice versa
[04:09] <ebroder> Related to some changes in our syslinux packages
[04:09] <achiang> ugh
[04:09] <ebroder> bug #645818
[04:09] <ebroder> Apparently it was release-noted
[04:10] <achiang> ebroder: thanks. good to know it's not PEBCAK
[04:10] <ebroder> But you should get a prompt where you can type "live" or "live-install", depending on what you're trying to do
[04:10] <achiang> nope, i get to neither... see above error message
[04:10] <ebroder> Not after the error?
[04:10] <achiang> oh hm
[04:11]  * achiang reads the bug in more depth
[04:11] <achiang> ok, some workarounds in there...
[04:12] <achiang> wow, the 'help' workaround actually helped.
[04:13] <achiang> ebroder: thank you
[04:13] <ebroder> np
[04:43] <achiang> boo. as expected, simply dropping debian/ into upstream ModemManager and trying a pbuild in a lucid chroot experiences a FTBFS. :-/
[05:14] <RAOF> 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] <achiang> whoo. git bisect going fast now.
[05:26] <StevenK> RAOF: I don't think gdb even has that information -- since the #defines are replaced by the C pre-processor
[05:27] <RAOF> Yeah.
[05:27] <RAOF> It *could* parse out the .h files and match values to #defines though.
[05:27] <RAOF> I mean, you'd false-positive quite often, but you could do it :)
[05:28] <achiang> shouldn't that just work though? does gdb know about your source directory?
 compile with -gdwarf-2 -g3 :)
[05:28] <RAOF> Sarvatt: Really?  That keeps #define information?
[05:29] <RAOF> And if so, why don't we build *all* packages with that?
[05:30] <StevenK> Probably because it's massive
[05:30] <RAOF> I'd trade an order of magnitude bigger -dbgsym packages for #define information.
[05:32] <TheMuso> 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] <TheMuso> OUCH
[05:46]  * RAOF is off for some exercise, and will be back on later.
[06:02] <TheMuso> @pilot out
[06:02] <ebroder> TheMuso: Something weird is up with your sbuild. I don't know where it's getting sysvinit from
[06:03] <TheMuso> ebroder: Hrm ok, my maverick chroots may need a complete rebootstrap.
[06:08] <TheMuso> 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] <ebroder> TheMuso: No worries. Thanks for pilotting
[06:08] <TheMuso> np
[06:09] <lifeless> kees: but its back on now
[06:19] <pitti> Good morning
[06:21] <pitti> chrisccoulson: hm, I haven't worked with po2xpi so far, that was between Arne and Alex
[07:12] <dholbach> good morning!
[07:12] <ssj6akshat> good morning dholbach
[07:12] <dholbach> hi ssj6akshat
[07:33] <didrocks> good morning
[09:37] <spetrea> any chance of getting my patches to vifm into the Ubuntu distro ?
[09:37] <spetrea> vifm is 0.4 in Ubuntu right now
[09:37] <spetrea> and I'm working on some new things for it here https://github.com/wsdookadr/vifm
[09:56] <tumbleweed> 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] <ari-tczew> cjwatson: could you restart Merge-o-Matic?
[10:11] <spetrea> tumbleweed: are you familiar with vifm , can I describe to you my patches ?
[10:26] <pitti> hm, it seems natty's kvm has some serious trouble booting the desktop CDs (also maverick's)
[10:34] <pitti> oh, seems it's the tablet emulation that breaks it
[11:13] <sebner> didrocks: good that we have mutter, wondering if compiz ever will be unb0rken ^_^
[11:19] <hyperair> sebner: mutter is hellspawn that should just die
[11:20] <sebner> hyperair: it works at least :P
[11:20] <hyperair> sebner: compiz 0.9 works here
[11:20] <sebner> gnah
[11:20] <hyperair> sebner: your machine's screwed ^_^
[11:20] <sebner> hyperair: compiz is screwed since ~1 week xD
[11:20] <hyperair> sebner: probably because compiz++ was uploaded then?
[11:21] <hyperair> it's a rewrite. it's bound to be broken.
[11:21] <hyperair> sebner: and go complain to smspillaz on #ayatana or #compiz-dev. ;-)
[11:21] <sebner> hyperair: wonderful, I updated mutter and that segfaults now too xD
[11:21] <hyperair> sebner: i filed a steady stream of bugs until this thing was usable for me.
[11:21] <hyperair> sebner: oh lol. =p
[11:28] <sebner> hyperair: mutter+gtk3 = b0rken. downgrading both fixes mutter at least. debugging compiz now
[11:45] <tumbleweed> spetrea: no, although I've touched it in the past
[11:55] <sebner> 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] <lool> 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
[13:15] <pitti> lool: hey (sorry, had a long phone call)
[13:15] <pitti> looking
[13:16] <pitti> lool: hm, we already build -omap from the main linux source?
[13:17] <pitti> lool: and also from linux-linaro
[13:18] <lool> pitti: linux-linaro will go away
[13:18] <lool> pitti: Main linux source > I think the omap flavor is going away too
[13:19] <lool> 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] <lool> pitti: In fact, if you look at latest linux source package, it didn't build omap on armel anymore
[13:20] <lool> So I think linux-linaro-omap is the only remaining one for OMAP3
[13:20] <lool> (considering linux-linaro is going away)
[13:20] <pitti> qok
[13:20] <pitti> -q
[13:20] <pitti> lool: (it's a shame, though)
[13:20] <lool> pitti: Which part?
[13:21] <pitti> I thought the various flavours would be united in one source, not that the one source would be split further
[13:21] <lool> pitti: It's all generated from a single git tree, but build time was getting an issue
[13:21] <lool> pitti: But we are working on limiting the number of flavors
[13:21] <pitti> oh, this is just to work around buildd time, it's actually one source?
[13:21] <lool> pitti: For instance our omap flavors supports OMAP3 and OMAP4
[13:22] <lool> pitti: Yes, the main reason for the split is build time
[13:22] <lool> buildd time
[13:27] <lool> pitti: thanks
[13:27] <pitti> lool: de rien
[13:40] <doko> ScottK: are these expected? http://paste.ubuntu.com/538284/
[13:40] <doko> Riddell: ^^^
[13:42] <ScottK> doko: I think so, but I'm not certain.
[13:44] <mterry> james_w, heyo about pkgme: is 'description' supposed to spit out a debian/control formatted description?  with a shortline and then indented paragraphs?
[14:02] <james_w> mterry, currently yes, but I'm open to changing it if you would like
[14:03] <dholbach> 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] <james_w> hey dholbach
[14:03] <dholbach> james_w, or should the branch itself be marked as merged, abandoned or something?
[14:04] <dholbach> hey james_w - how are you doing? :)
[14:04] <james_w> dholbach, good thanks how are you?
[14:04] <james_w> dholbach, marked as rejected for you
[14:05] <dholbach> good - it's just just gotten a bit cold over here :)
[14:05] <mterry> 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] <mterry> ine
[14:05]  * dholbach hugs james_w
[14:05] <dholbach> james_w, thanks muchly
[14:05] <james_w> mterry, yeah, I agree
[14:05] <mdz> pitti: hi
[14:06] <pitti> hello mdz
[14:06] <mdz> 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] <mterry> 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] <james_w> mterry, I'm not sure about that actually
[14:07] <pitti> 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] <james_w> 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] <mterry> james_w, exactly
[14:08] <mterry> james_w, the autotools backend could do a 'dumb' implementation of MAINTAINERS and only provide output if it's exactly one line
[14:08] <mterry> james_w, that way the user could at least enter something.  Doesn't fix README though
[14:08] <james_w> no
[14:08] <james_w> maybe we should have a pkgme.info file that is read or something?
[14:09] <mterry> 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] <mterry> XML isn't the friendliest...
[14:10] <mdz> mvo: have you had a chance to consider my brainstorm request?
[14:12] <james_w> mterry, hmm, doap would be cool actually, but I've never used it
[14:15] <mvo> mdz: not yet, sorry. but I push it higher in my todo list
[14:16] <mdz> 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] <mvo> 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] <mterry> 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] <mdz> 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] <mdz> mvo: can I put you down as 'confirmed' then?
[14:22] <james_w> 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] <mterry> james_w, well, for the autotools case, it would cover all the missing gaps (maintainer, shortdesc, and description)
[14:22] <mvo> mdz: yes
[14:22] <mterry> james_w, I don't know about other buildsystems
[14:23] <james_w> mterry, right
[14:23] <james_w> mterry, this points to another need for layering backends?
[14:23] <mdz> mvo: great, thanks
[14:24] <mterry> 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] <james_w> mterry, hmm, good point
[14:25] <ogra_ac> pitti, about the QT bug
[14:25] <mvo> mdz: yw :)
[14:26] <mterry> 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] <ScottK> 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] <ogra_ac> pitti, could you just accept the SRU into -updates, QT in maverick wont build atm
[14:26] <ScottK> ogra_ac: maverick/natty
[14:26] <ogra_ac> err, yes
[14:27] <pitti> ScottK: I wasn't going to; the task is open
[14:27] <ogra_ac> 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] <pitti> yes, I totally agree
[14:27] <ogra_ac> pitti, we would like to have the STU done
[14:27] <ogra_ac> *SRU
[14:27] <pitti> okay
[14:27] <ogra_ac> but you make that depend on a natty upload
[14:27] <rsalveti> cool
[14:28] <ogra_ac> yay
[14:28] <ScottK> 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] <mdz> 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] <ogra_ac> ScottK, i agree
[14:29] <pitti> ScottK, ogra_ac: marking as RC for natty beta, to keep it on the radar
[14:29] <ogra_ac> ScottK, but if its not fixed we need a fallback
[14:29] <ogra_ac> ScottK, static NEON isnt an option either
[14:29] <ScottK> ogra_ac: Then put the no-NEON version in the PPA.
[14:29] <ogra_ac> so the PPA is a fallback if upstream doesnt manage
[14:30] <ogra_ac> ScottK, not an option
[14:30] <rsalveti> yeah
[14:30] <ogra_ac> userspace needs to support all armv7 platforms
[14:30] <rsalveti> we should never put neon by default, unless it's able to do the runtime detection
[14:30] <ScottK> ogra_ac: What supported hardware is it a problem for?
[14:30] <ogra_ac> ScottK, the two options lool noted in the bug are fine
[14:31] <ogra_ac> ScottK, this is not about supported/unsupported HW
[14:31] <ogra_ac> this is about a commitment for our default userspace
[14:31] <rsalveti> there are people who build community images on top of our archive, and they need no neon by default
[14:32] <rsalveti> and we said that we would not put neon by default, publicly
[14:32] <ogra_ac> 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] <ScottK> rsalveti: Who is the "we"?
[14:32] <rsalveti> canonical arm team
[14:32] <ScottK> OK.  Not my problem then.
[14:32] <ogra_ac> there are people using ubuntu on non NEON devices
[14:33] <ScottK> ogra_ac: As long as I can build an Ubuntu ISO with NEON in Natty, I'm happy.
[14:33] <ScottK> It sounds like there are options that support that.
[14:33] <ogra_ac> ScottK, make upstream fix runtime detection is your best bet then
[14:33] <ScottK> So we can move on and fall back to one of them if upstream doesn't get the runtime detection sorted.
[14:33] <ogra_ac> right
[14:33] <ScottK> ogra_ac: I agree that's best.
[14:33] <ogra_ac> we dont want to block you, dont take it personal
[14:34] <ScottK> ogra_ac: I'm extremely frustrated that Canonical is making requirements on Ubuntu that aren't communicated to the community.
[14:34] <ogra_ac> the NEON settings are communicated since several releases
[14:34] <rsalveti> yeah
[14:35] <ogra_ac> that decision was made during januty iirc
[14:35] <ScottK> ogra_ac: Where is this documented?
[14:35] <rsalveti> probably also over uds and etc
[14:35] <persia> rsalveti, That's not really documentation, as such.  Someone needs to turn that into something else to be proper docs.
[14:35] <ogra_ac> there must be mails from lool to ubuntu-devel from that time iirc and meeting logs as well
[14:36] <ogra_ac> there were also specs to research it
[14:36] <ogra_ac> and the outcome is documented somewhere
[14:36] <ogra_ac> iirc also in mails to -devel
[14:37] <ogra_ac> iirc NCommander did speed tests and researched vfp and neon during jaunty or jaunty+1
[14:38] <ScottK> "I think there's some email from two years ago" isn't much in the way of documentation.
[14:39] <bilalakhtar> dholbach:  What is the procedure of adding a datasource to hall-of-fame.ubuntu.com ?
[14:43] <NCommander> ogra_ac: just VFP
[15:23] <janimo> didrocks: hello, I am looking at NUX FTBFS on ARM
[15:24] <didrocks> janimo: yes?
[15:24] <janimo> didrocks: shall I provide bugreports to NUX in LP directly or to you?
[15:24] <janimo> and patches
[15:25] <didrocks> janimo: just post patches against nux and the dx team or I will review/integrate in nux upstream
[15:25] <didrocks> (so bug report against nux)
[15:25] <janimo> ok, thanks
[15:25] <didrocks> yw :)
[15:28] <dholbach> didrocks, merge proposal!
[15:28] <didrocks> dholbach: well, we are good upstream and we look at patch in any form, merge proposal or others :)
[15:28] <ogra_ac> dholbach, pffft, all that progressive stuff
[15:29] <dholbach> ogra_ac, grandpa... here's your cup of tea
[15:29] <didrocks> :)
[15:30] <geser> hmm, a hot cup of tea at this weather is pretty nice
[15:31] <ogra_ac> *slurp*
[15:31] <dholbach> geser, you're right :)
[16:09] <persia> 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).
[16:20] <wendar> persia: great, we'll see if we can use that in the ARB packages for maverick
[16:20] <Riddell> doko: yes those missing files are fine
[16:20] <doko> Riddell: thanks
[16:21] <persia> 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] <wendar> persia: will do, thanks
[16:52] <zyga-bed> mvo, hi, should do-release-upgrade work on lucid ppc to upgrade to maverick?
[16:53] <zyga-bed> mvo, I'm getting "No new release found"
[16:54] <ogra_ac> it probably knows that you are ill and wants to make sure you dont work while you shouldnt ;)
[16:54] <mvo> zyga-bed: make sure you have /etc/update-manager/release-upgrades set to normal (instead of lts)
[16:54] <zyga-bed> ogra, hehe
[16:54] <mvo> haha
[16:54] <mvo> (to ogra)
[16:54] <zyga-bed> mvo, thanks :-)
[16:54] <zyga-bed> ogra, I feel horrible doing nothing
[16:55]  * ogra_ac knows how that feels
[16:56] <zyga-bed> working on atom while being used to work on core i7 is also horrible :D
[16:56] <mvo> zyga-bed: get well
[16:56] <zyga-bed> mvo, thanks, I took medicaments, got a big bowl of warm tee
[16:57] <zyga-bed> the fever is slowly going away but I still have 37,7
[16:57] <zyga-bed> (funny how most locales use . for decimal point while pl uses ,)
[17:00] <ari-tczew> what the hell is going on with MoM?
[17:00] <zyga-bed> ari-tczew, hi
[17:00] <ari-tczew> hi zyga-bed
[17:07] <smoser> anyone know how to get the current virtual terminal ?
[17:07] <smoser> ie, to save so that i can 'chvt X' back to it
[17:17] <ogra_ac> didrocks, bah, could you what the ayatana team from me for explicitly using x86 assembler in their code ?
[17:17] <ogra_ac> :)
[17:18] <didrocks> ogra_ac: just go on #ayatana :)
[17:18] <ogra_ac> the current nux build looked so good
[17:18] <SpamapS> pitti: where did the configs move for the WI tracker since they're not in the trunk now?
[17:19] <pitti> SpamapS: lillypilly (aka people.c.c); sudo -u platform -i
[17:19] <pitti> SpamapS: then edit them in work-items-tracker/config/
[17:20] <pitti> SpamapS: I dropped it from bzr since they break using the WI tracker for other projects (at least the all-projects script)
[17:21] <SpamapS> pitti: ahh.. ok, I will have to finally figure out how to get on that box. ;)
[17:23] <zyga-bed> pitti, hi, how many other similar reports are generated?
[17:24] <zyga-bed> pitti, apart from the work item tracker
[17:24] <pitti> 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] <pitti> (non-Canonical/Ubuntu, I mean)
[17:25] <zyga-bed> pitti, but are they using the work item data or something entirely separate?
[17:25] <pitti> just the code and scripts, not our data of course
[17:25] <zyga-bed> ok
[17:25] <ogra_ac> the ubuntu-armel report is a community report
[17:25] <pitti> but I don't want to see the entire world's configuration files in upstream trunk
[17:25] <pitti> if we want this stuff in bzr, it shold be in a separate tree
[17:25] <pitti> if anyone wants to set that up, feel free
[17:26] <zyga-bed> pitti, I'm asking because of different context
[17:27]  * pitti waves good night
[17:27] <zyga-bed> 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] <zyga-bed> pitti, good night :-)
[17:27] <pitti> zyga-bed: if you actually want to use the Ubuntu data, the .db files are available there as well
[17:28] <zyga-bed> pitti, yeah but for the moment using JSON is better for me _unless_ I can open your database file locally
[17:28] <zyga-bed> pitti, and doing the former makes me more likely to implement proper asynchronous tasks into the system
[17:28] <zyga-bed> pitti, anyway, I'll show you what I have once I get better and finish it
[17:29] <zyga-bed> pitti, the upside to static reports is that it's a live application
[17:29] <zyga-bed> pitti, and that all data it can show on the html page can be accessed via xml-rpc
[17:45] <bdmurray> @pilot in
[18:34] <sebner> didrocks: I filed a bug about the latest mutter crash, should I subscribe anyone specific?
[18:40] <didrocks> sebner: on natty or maverick?
[18:40] <sebner> didrocks: natty of course
[18:41] <didrocks> sebner: nobody then, we dropped our specific patch and I'm not sure who is following mutter on natty
[18:41] <didrocks> sebner: I have enough to do with compiz TBH :)
[18:42] <didrocks> sebner: I wonder if we should sync from debian as well. Will have a look at the specific patch we still have
[18:45] <sebner> 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] <didrocks> sebner: compiz broken on natty? yeah, fire the number then :)
[18:46] <sebner> didrocks: bug #683081 , I already subscribed our compiz hero. Not sure how to improve the backtrace though
[18:47] <charlie-tca> known issue?  after fresh install today, run updates, no top panel, no dock when restarting
[18:47] <sebner> charlie-tca: might be compiz related ^^
[18:48] <charlie-tca> Want a bug, then?
[18:48] <didrocks> charlie-tca: nvidia card?
[18:48] <charlie-tca> ati radeon 9800
[18:48] <didrocks> hum, no acceleration support?
[18:48] <charlie-tca> I don't know
[18:49] <didrocks> charlie-tca: it seems not, you should logout and choose the "gnome classic session"
[18:49] <charlie-tca> got a desktop, just nothing else.
[18:49] <didrocks> seems you don't have acceleration support, that will be an alpha1 release note
[18:49] <charlie-tca> logout? got nothing.
[18:49] <didrocks> charlie-tca: ctrl + alt + t
[18:50] <didrocks> gnome-panel
[18:50] <didrocks> and then logout :)
[18:50] <charlie-tca> well, I'll be. It worked
[18:50] <didrocks> charlie-tca: but your issue isn't a bug, just a consequence of no fallback support yet
[18:51] <didrocks> (when unity can't run)
[18:51] <charlie-tca> Okay
[18:51] <didrocks> will come with alpha2
[18:51] <charlie-tca> but it runs until I update
[18:51] <didrocks> sebner: yeah, the stactrakce is small
[18:51] <didrocks> charlie-tca: yeah, but we got unity + gnome-panel for normal case
[18:51] <didrocks> charlie-tca: which leads to a lot of other issues :)
[18:51] <charlie-tca> Okay
[18:51] <charlie-tca> thanks
[18:51] <didrocks> yw :)
[18:51] <didrocks> sebner: is apport activated for you?
[18:52] <sebner> didrocks: howto check?
[18:52] <didrocks> sebner: you should report the bug with it
[18:52] <didrocks> sebner: /etc/default/apport
[18:52]  * sebner tests
[18:52] <sebner> didrocks: disabled
[18:53] <didrocks> sebner: ok, so enable it, reboot or launch apport service and make compiz crash
[18:53] <didrocks> then, report the bug :)
[18:54] <sebner> didrocks: mind invaliding the old bug meanwhile?
[18:54] <didrocks> sebner: sure
[19:00] <sebner> didrocks:  bug# 683293
[19:00] <sebner> bug #683293
[19:01] <didrocks> sebner: can you mark it as not private if you have no private data?
[19:01] <didrocks> otherwise I'll add sam
[19:01] <didrocks> thanks :)
[19:01] <didrocks> ok, let's wait apport to retrace it
[19:02] <sebner> didrocks: oh, didn't notice. Is it uploading furthers logs in the background?
[19:03] <didrocks> sebner: yeah, but it's ok :) apport will run against it on launchpad and get a nice backtrace with debug symbols
[19:03] <didrocks> then, we will have a look at it :)
[19:03] <didrocks> thanks!
[19:04] <sebner> didrocks: heh, thanks to you too. Pretty nice to have a contact person =)
[19:04] <bilalakhtar> Compiz is nonresponsive on shutdown. Known issue?
[19:04]  * didrocks runs…
[19:04] <sebner> bilalakhtar: /here too
[19:04] <didrocks> bilalakhtar: yes
[19:04] <bilalakhtar> so /me is not the only person facing it..
[19:04]  * bilalakhtar could help
[19:14] <lifeless> kees: ok, its all working and stable now
[19:14] <lifeless> kees: I'd expect nice fast responses, consistently.
[19:44] <charlie-tca> didrocks, nvidia 6200 with hardware driver installed gives blank desktop too
[19:44] <didrocks> charlie-tca: hum, you have acceleration support? that's weird? I have a nvidia card there working well
[19:45] <didrocks> charlie-tca: glxinfo returns "hardware accelerated" or "software rendered"?
[19:45] <didrocks> (have to popout quickly, it's getting late there
[19:45] <charlie-tca> starting it again.
[19:45] <charlie-tca> it is an encrypted install, if it makes a difference
[19:46] <charlie-tca> today's updates did remove "ubuntu-desktop", but that should not have removed everything.
[19:47] <didrocks> charlie-tca: do you have compiz and unity installed?
[19:47] <charlie-tca> I did dnot remove them
[19:48] <charlie-tca> All I did is install from today's alternate image, then run "sudo apt-get update" and "sudo apt-get dist-upgrade"
[19:48] <charlie-tca> then I restarted
[19:48] <didrocks> charlie-tca: you should get it, and for the glxinfo?
[19:48] <charlie-tca> checking
[19:49] <didrocks> (really need to go…)
[19:49] <charlie-tca> dirct rendering yes
[19:49] <didrocks> and server glx vendor string ?
[19:51] <didrocks> charlie-tca: if it's not "software rendered", please report a bug against unity with a compiz --replace stacktrace please :)
[19:51] <charlie-tca> will do
[19:51] <didrocks> thanks
[19:52] <charlie-tca> server glx vendor string: NVIDIA Corporation
[19:52] <charlie-tca> server glx vendor string: NVIDIA Corporation
[19:56] <bdmurray> @pilot out
[20:12] <SpamapS> hmm... I have a dpkg process from inside a schroot just sitting there stuck in D+ stat...
[20:13] <SpamapS> getting the "process blocked for more than 120 seconds" message ....
[20:13] <SpamapS> and I'd swear the disk is churning but I have no HDD light on my mac to prove it.. I just hear ticking.
[20:13] <SpamapS> iotop doesn't show any IO though
[20:15]  * SpamapS is pondering a reboot.. but ugh
[20:18] <SpamapS> ah.. it finally died
[20:19] <kirkland> what setting (or lack of setting) in setup.py causes libraries to get installed into /usr/local/lib/python2.6/dist-packages/ ?
[20:19]  * kirkland is trying to fix some packaging
[20:20] <SpamapS> kirkland: IIRC, the dh python helpers call setup.py with the appropriate args to install things in the right place
[20:20] <ebroder> It's something like passing --install-layout=deb, I thought
[20:21]  * xnox nods in agreement with ebroder
[20:23] <kirkland> SpamapS: hmm, it ain't apparently
[20:27] <didrocks> charlie-tca: thinking about it, did you have the "desktop effects enabled"?
[20:28] <kirkland> ebroder: xnox: to dh_python, or dh_pysupport?
[20:28] <xnox> kirkland to setup.py =)
[20:28] <didrocks> charlie-tca: can you please ensure you have gnomewm or compiz to gconftool-2 -g /desktop/gnome/session/required_components/windowmanager ?
[20:28] <xnox> do not use dh_python. dh_pysupport and dh_python[2|3] do it automatically
[20:29] <xnox> kirkland, what's the package?
[20:29] <kirkland> xnox: cobbler
[20:29] <kirkland> xnox: i'm creating the packaging
[20:29] <xnox> %:
[20:29] <xnox>    dh $@ --with pysupport
[20:29] <xnox> should be enough =)
[20:30] <xnox> as the starting point.
[20:30] <xnox> let me file a bug. And I'll look into cobbler in a sec
[20:30] <kirkland> xnox: thanks
[20:31] <xnox> sorry I'm wrong kirkland
[20:31] <xnox> it's --with python-support
[20:31] <xnox> for the old-style python packaging.
[20:32] <kirkland> xnox: okay;  lp:~kirkland/+junk/cobbler if you're interested
[20:32] <xnox> If you are ready for both python2 and python3. You should be using --with python2[,python3]
[20:32] <xnox> =))) branching
[20:32] <ScottK> kirkland: For new stuff dh_python2 is preferred.  It should be trivial to switch.
[20:34] <kirkland> ScottK: that seemed to do it.  thanks.
[20:35] <bdmurray> @pilot in
[20:41] <charlie-tca> didrocks, did not enable anything myself. Did not disable anything myself, either
[20:41] <didrocks> charlie-tca: sure, but some defaults can change, especially with the nvidia card
[20:41] <didrocks> charlie-tca: hence the output pour gconftool-2 -g /desktop/gnome/session/required_components/windowmanager can be useful
[20:41] <didrocks> for*
[20:42] <charlie-tca> okay. I am not very good with this, let me look
[20:43] <charlie-tca> that says gnome-wm
[20:43] <didrocks> ok, should be fine then :/
[20:43] <charlie-tca> :-(
[20:44] <charlie-tca> I fail miserably getting the stacktrace
[20:44] <didrocks> charlie-tca: let's apport catching it
[20:44] <didrocks> charlie-tca: enables apport and report the bug
[20:44] <charlie-tca> I tried. bug 683349
[20:45] <didrocks> yeah, it's not enough :)
[20:45] <charlie-tca> enhable it? I will go back and do that and attach the missing things, then
[20:45] <charlie-tca> sorry
[20:46] <didrocks> charlie-tca: https://wiki.ubuntu.com/Apport#How to enable apport
[20:46] <charlie-tca> Thank you
[20:46] <didrocks> that should help you :) setting it as incomplete waiting for the additional info :)
[20:46] <didrocks> yw
[20:46] <didrocks> thank you :)
[20:47] <charlie-tca> No problem. I am persistent, even if a bit slow sometimes
[20:48] <didrocks> :)
[20:53] <xnox> kirkland I have something that at least builds a little bit.
[20:53] <kirkland> xnox: i have it going now
[20:53] <kirkland> xnox: thanks
[20:53] <kirkland> xnox: on to the next suite of problems
[20:54] <xnox> kirkland, well make sure you do $ echo "2.6" > debian/pyversions && bzr add debian/pyversions
[20:54] <xnox> cause there is no python-yaml with 2.7 in natty =)
[20:55] <ScottK> xnox: That's just because we didn't rebuild it yet.
[20:55] <ScottK> Fixing that is a better solution.
[20:55] <xnox> kirkland, my branch is here: lp:~dmitrij.ledkov/+junk/cobbler
[20:56] <xnox> this is my debian/rules
[20:56] <xnox> #!/usr/bin/make -f
[20:56] <xnox> # -*- makefile -*-
[20:56] <xnox> %:
[20:56] <xnox> 	dh $@ --with python2 -Spython_distutils
[20:56] <xnox>  
[20:56] <xnox> works like a charm =) for the most part
[20:56] <xnox> now it needs to be made policy compliant =)
[20:58] <xnox> Anyone wants to look at bug #683347 ? It might be toolchain/as-needed, binutils, lintian or simple packaging bug.
[20:59] <ScottK> xnox: Also I think it's generally better to use XS-Python-Version than debian/pyversions since all Python helpers support XS-P-V.
[21:00] <xnox> ScottK true =) except that piotr won't sponsor that =)
[21:00] <ScottK> xnox: He will.  He won't sponsor pycentral.
[21:00] <ScottK> Debian Python Policy also prefers it.
[21:08] <xnox> Good to know. Will do that then.
[21:16] <highvoltage>  /win 16
[21:46] <bdmurray> @pilot out
[22:09] <ScottK> pitti: I'm looking at removing HAL from Kubuntu as we have upstream support in KDE for that now.  From your work on this for Ubuntu Desktop, do you recall if it's a problem for HAL to remain installed (do I have to ensure it gets removed on upgrade)?
[22:16] <bdrung> \o/ 42 sponsor requests!
[23:05] <achiang> can someone refresh my memory? does update-manager call out critical vs. non-critical updates?
[23:27] <ebroder> achiang: It separates security from non-security. We don't have a distinction between "critical" vs. "non-critical" SRUs (we don't use the priority field in debian/changelog)
[23:27] <achiang> ebroder: ah, ok. that's good enough for me, thank you