[05:08] <pitti> Good morning
[06:05] <larsu> good morning!
[06:09] <pitti> hey larsu, wie gehts?
[06:10] <larsu> pitti: gut danke! Hattest du ein schönes Wochenende?
[06:11] <pitti> larsu: ja, sehr ruhig, gut zwischen den ganzen Reisen :)
[06:11] <pitti> und Du?
[06:11] <larsu> schon wieder ein Sprint?
[06:11] <larsu> ja auch ruhig - bisschen Kino und spazieren und so
[06:12] <larsu> und Laney ist hier seit Samstag
[06:12] <pitti> larsu: yeah, Austin next week
[06:47] <darkxst> hey pitti larsu
[06:48] <pitti> hey darkxst, how are you?
[06:48] <darkxst> pitti, sick today ;(
[06:48] <pitti> darkxst: urgh, a cold?
[06:48] <darkxst> yeh, another cold
[06:48] <larsu> hi darkxst!
[06:48] <larsu> oh, get better
[06:48] <darkxst> but that gave me time to track damn a few big crashers
[06:50] <darkxst> including seb128 favourite xorg crash ;)
[06:51] <pitti> darkxst: get well soon then :/ sucks
[06:52] <darkxst> pitti, thanks, flu/cold season should be ending here, but apparently not yet!
[07:09] <seb128> good morning desktopers
[07:09] <seb128> hey pitti larsu darkxst
[07:09] <pitti> bonjour seb128
[07:09] <seb128> darkxst, oh, did you figure it out?
[07:09] <pitti> seb128: as-tu eu un bon w.e.?
[07:09] <darkxst> seb128, yes, it was crashing on shutdown
[07:09] <seb128> hey pitti, passé un bon w.e
[07:09] <darkxst> and the redhat guys already had that one fixed
[07:09] <seb128> pitti, oui, super
[07:09] <seb128> darkxst, k, shame we didn't get it fixed for release :-/
[07:10] <larsu> hey seb128
[07:10] <seb128> did you SRU it?
[07:10] <darkxst> seb128, its completely harmless apart form the spam, and yes Ive filed an sru
[07:10] <seb128> good
[07:10] <seb128> yeah, but apport spam is impacting the user perception of the product
[07:11] <seb128> and it's creating load on retracers&co
[07:11] <darkxst> along with a fix for FTBFS in the mir stuff
[07:11] <pitti> meh :/
[07:11] <seb128> so still good to get fixed
[07:12] <darkxst> robert_ancell doesnt apparently understand autoconf scripts
[07:13] <darkxst> yet it oddly built when uploaded to the archives
[07:14] <darkxst> bug 1509907
[07:14] <darkxst> bug 1237904
[07:15] <darkxst> seb128, and the gjs crash is sorted also
[07:15] <didrocks> good morning
[07:16] <darkxst> last one to go is clutter update, but that wants new cogl major release, which could well just be a micro release ;)
[07:18] <seb128> darkxst, good work sorting out those different issues ;-)
[07:18] <seb128> lut didrocks
[07:19] <darkxst> seb128, was a very productive sick day ;)
[07:20] <didrocks> salut seb128
[07:21] <tjaalton> darkxst: thanks.. too bad xserver git is still not in sync so I'll wait until robert has pushed his branch..
[07:22] <seb128> didrocks, t'as eu un bon w.e de 3j ?
[07:22] <darkxst> tjaalton, yeh, that confused me also
[07:23] <didrocks> seb128: c'était bien, oui, merci ! Et toi, bon week-end ?
[07:24] <seb128> didrocks, oui, tranquille, y a fait beau ;-)
[07:24] <tjaalton> darkxst: that other change.. could it be because mir itself changed? doko filed a bug about it
[07:25] <tjaalton> mesa & xserver ftbfs now
[07:25] <darkxst> tjaalton, yes but robert messed ubuntu the ubuntu9 diff
[07:26] <desrt> good morning desktop!
[07:26] <seb128> hey desrt!
[07:26] <darkxst> PKG_CHECK_MODULES does not understand debian package names ;)
[07:26]  * desrt comes back from insane weekend in zurich
[07:26] <seb128> oh, was that good?
[07:27] <didrocks> hey desrt!
[07:27] <seb128> how many kms did you walk? ;-)
[07:27] <darkxst> tjaalton, I don't know why it even built, unless it landed before the MIR changes?
[07:27] <tjaalton> yeah mir changed only a week or to before release
[07:28] <desrt> not many
[07:28] <desrt> we were mostly playing defence
[07:28] <desrt> it was super military-operation like
[07:28] <larsu> morning desrt
[07:28] <darkxst> tjaalton, ok, well ubuntu9 diff is clearly a typo
[07:28] <desrt> like there was some central control area where they took "intelligence" reports from the agents on the street about what was going on (and how many people of the opposite team were present, etc)
[07:28] <desrt> then made decisions about what to do and report it to team-leads
[07:28] <desrt> who then 'commanded' their troops to new locations or to change tactics or whatever
[07:28] <tjaalton> /usr/lib/x86_64-linux-gnu/pkgconfig/mir-client-platform-mesa-dev.pc
[07:29] <desrt> pretty wild
[07:29] <seb128> tjaalton, 1509005
[07:29] <seb128> regression in the recent mir landing
[07:30] <tjaalton> yeah that one
[07:31] <darkxst> tjaalton, my sbuild refuses to admit the existance of that file!
[07:31] <tjaalton> darkxst: it's not there anymore, my Contents.* are old :)
[07:32] <tjaalton> just saying that it's the same bug
[07:32] <tjaalton> it used to be -dev, the mir renamed it
[07:32] <tjaalton> so the diff is right, fixing xorg-server portion of 1509005
[07:34] <darkxst> tjaalton, k, didnt managed to find that bug report when I searched
[07:34] <tjaalton> it was for mir
[07:34] <tjaalton> added xserver/mesa to it
[07:38] <darkxst> tjaalton, yes I see, but why changing .pc filenames after freeze?
[07:38] <tjaalton> exactly
[07:39] <tjaalton> but looks like rbuilddeps will be fixed instead
[07:49] <darkxst> tjaalton, ok
[07:50] <darkxst> pitti, is there someway apport could flag shutdown bugs?
[07:50] <pitti> darkxst: actually it has tried to do that for a long time already
[07:50] <pitti> data/apport is_closing_session()
[07:51] <pitti> it asks org.gnome.SessionManager if the session is closing, and if so, igonres the crash
[07:51] <pitti> but that's racy and might not always owrk
[07:52] <darkxst> clearly not working here
[07:52] <pitti> l
[07:52] <darkxst> or the other gnome-session bug that was disabling everyones shell extension due to a crash on shutdown
[07:53] <darkxst> or maybe it did work there, and ingnoring the crash wasnt helpful
[07:54] <darkxst> but regardless users get crash reports on login so they think it happen well on login
[08:09] <Trevinho> Morning
[08:11] <darkxst> seb128, is gtk in progress?
[08:11] <seb128> Trevinho, hey Trevinho, how are you?
[08:14] <Trevinho> seb128: getting better, you?
[08:15] <seb128> Trevinho, I'm good thanks, had a good w.e and enjoyed the nice weather, a bit sleepy this morning though ;-)
[08:20] <larsu> hi from Laney
[08:20] <larsu> or better: Laney says hi
[08:20] <larsu> darkxst: yes
[08:21] <larsu> it's in the ppa
[08:21] <darkxst> larsu does laney have a new bot?
[08:21] <seb128> hey Laney
[08:21] <larsu> darkxst: I don't know
[08:21] <seb128> darkxst, desktop ppa has it but I think Laney said it was not ready
[08:21] <seb128> he just got it to build so it can be tested
[08:21] <larsu> it's ready to try
[08:22] <didrocks> hi Laneyrsu :)
[08:22] <seb128> but like the mir patch needs updating
[08:22] <larsu> but there's no mir backend
[08:22] <larsu> (seems like I'm Laney's bot)
[08:22] <seb128> larsu, stop repeting what I say :p
[08:22] <larsu> seb128: complain to Laney - I'm repeating what he says
[08:22] <larsu> didrocks: hahhaaaha nice
[08:22] <larsu> you people are fun
[08:23] <Sweet5hark> moin
[08:24] <seb128> hey Sweet5hark
[08:24] <larsu> hi Sweet5hark
[08:25] <didrocks> morning Sweet5hark
[08:25] <larsu> didrocks: how are you?
[08:27] <Sweet5hark> seb128: heya! so i figured it prolly makes sense for me to make two versions: ubuntu3 for wily to have a new unique verion id and ubuntu4 for xenial where I also switch of the collada, gltf and coinmp stuff ...
[08:27] <Sweet5hark> larsu, didrocks: heya
[08:28]  * Sweet5hark survived hackfest hamburg ;)
[08:28] <seb128> Sweet5hark, how was the hackfest?
[08:30] <Sweet5hark> seb128: I thought it was very good, but as one of the organizers Im likely biased. Still have to write a blogpost about it ...
[08:30] <seb128> mitya57, hey, gnome-applets fails to build in xenial with "Requested 'libpanel-applet >= 3.18.0' but version of libpanel-applet is 3.16.1" ... there is probably a build-depends that need to be updated to 3.18 there
[08:30] <seb128> Sweet5hark, good :-)
[08:31] <seb128> Sweet5hark, for the 2 versions that makes sense, let me know when you get something ready for upload
[08:31] <mitya57> seb128, the problem is that Ubuntu's gnome-panel has epoch number while Debian's doesn't
[08:31] <ricotz> hey desktopers
[08:32] <mitya57> seb128, I will upload new gnome-panel soon anyway
[08:32] <seb128> mitya57, oh, right
[08:32] <didrocks> larsu: starting to get sick, so, we'll see…
[08:32] <seb128> hey ricotz
[08:32] <ricotz> Sweet5hark, hey, is this going to be 5.0.3~rc2?
[08:32] <Sweet5hark> ricotz: nope
[08:32] <ricotz> ah, ok
[08:33] <ricotz> seb128, hi
[08:34] <larsu> didrocks: oh shit. get better!
[08:35] <didrocks> larsu: well, it's the start, so still bearable. Doing as much as possible as long as I feel "good" before it's getting worse…
[08:35] <larsu> drink more tea!
[08:42] <Sweet5hark> didrocks: urgh, all the best for getting rid of that quickly
[08:42] <didrocks> thx
[08:58] <willcooke> morning all
[08:58] <didrocks> hey willcooke
[08:59] <darkxst> hey willcooke
[08:59] <larsu> morning willcooke
[09:00] <willcooke> Stupid daylight savings time
[09:00] <larsu> we're back to normal!
[09:02] <pitti> I'd really like to keep summer time all year aroudn
[09:02] <seb128> hey willcooke
[09:03] <didrocks> same for me, light later during the day…
[09:03] <willcooke> pitti, yes!!  I'd love to move us forward 2 hours.
[09:05] <darkxst> summer is overrated, constant 40C days coming soon here ;(
[10:13] <pitti> tjaalton, darkxst: https://launchpad.net/ubuntu/+source/xorg-server/2:1.17.2-1ubuntu10 is blocked by<EMAIL_ADDRESS>; it fails on unavailable xserver-xorg-legacy, but it seems we've actually never had that
[10:13] <pitti> do you know what's up with that pacakge?
[10:34] <desrt> pop quiz: from your home directory /home/foo you make a symlink /home/foo/x -> /usr
[10:35] <desrt> what does "/home/foo/x/.." now refer to?
[10:35] <pitti> your home dir again?
[10:35] <desrt> nope.  /
[10:35] <desrt> i was surprised by this.
[10:36] <pitti> I guess one coudl argue either way
[10:36] <desrt> but not too surprised.  it actually makes sense when you consider that, internally, ".." is resolved just like any other item in the directory
[10:36] <pitti> resolving links before .. or .. before links
[10:36] <desrt> there is only one rule.  start at the left and move right.
[10:37] <pitti> then this makes sense
[10:38] <desrt> totally
[10:38] <desrt> and even still, i bet you most people answer this question wrong :)
[10:41] <desrt> it's also yet another reason that one cannot blindly simplify the path "/a/b/../c" to "/a/c" without first inspecting the filesystem
[11:04] <larsu> desrt: interesting point. The path/inode relationship is so messed up :/
[11:16] <desrt> larsu: i don't think so.... it sort of has a simple beauty to it, in fact
[11:17] <desrt> the only thing to know is that ".." is very very strange and it doesn't work like most people think it does
[11:28] <tjaalton> pitti: hum, it's provided by 'xorg' (source) which we haven't merged yet
[11:29] <tjaalton> pitti: debian has switched to non-root X
[11:29] <tjaalton> -legacy provides the old run by root
[11:29] <pitti> tjaalton: ah, so that wasn't removed, but newly introduced, and the new virtualbox already uses it?
[11:29] <tjaalton> apparently so
[11:29] <pitti> ah, indeed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#virtualbox
[11:29] <tjaalton> I'll merge xorg then
[11:30] <pitti>  * Add runtime dependency on xserver-xorg-legacy on virtualbox-guest-x11
[11:30] <pitti>     (Closes: #801524)
[11:30] <pitti> tjaalton: thanks for the explanation (and merging)!
[11:46] <larsu> desrt: meh - the concepts of links and the way ".." works get in each others way
[11:47] <larsu> desrt: it would be much simpler if I could simplify *any* path
[11:48] <larsu> (without it being specific to a fs, of course)
[12:24] <tkamppeter> willcooke, hi
[12:25] <willcooke> hey tjaalton
[12:25] <willcooke> oops, tkamppeter
[12:25] <willcooke> sorry tjaalton - ignore
[12:26] <tkamppeter> willcooke, mpt is back to work since today and tomorrow he would be ready to talk about thd print dialog.
[12:27] <willcooke> tkamppeter, great, do you need me to be there?
[12:36] <tkamppeter> willcooke, there is not really a meeting set up yet, I will simply talk with him on IRC and I can ping you then, and/or get a meeting together.
[12:36] <willcooke> perfect, thanks tkamppeter
[12:39] <mhall119> willcooke: can someone from your team to a Convergence track session or two and UDS to talk about the work that is going into bringing Unity 8 and Snappy to the desktop?
[12:40] <willcooke> mhall119, better to speak to someone in the U8 team and the snappy team.
[12:41] <mhall119> already poked them about it too
[12:41] <willcooke> mhall119, as you can imagine, we integrate their stuff in to the desktop, but we're not really qualified to talk about the lower level parts
[12:42] <mhall119> anything you can talk about (or planning that needs to be done) around that integration?
[12:43] <mhall119> bregma: can you host some sessions about puritine and libertine?
[12:43] <seb128> integration of what?
[12:43] <mhall119> seb128: desktop apps with Mir, lifecycle management, confinement, etc
[12:47] <andyrock> good morning all
[13:01] <seb128> hey AndrewMC
[13:01] <seb128> ups
[13:01] <seb128> hey andyrock
[13:01] <andyrock> :sweat_smile:
[13:41] <Trevinho> seb128: can I do direct push to lp:unity only for doing a release?
[13:42] <Trevinho> or to lp:unity/wily...
[13:42] <seb128> Trevinho, why do you need that? shouldn't the train merge/tag things?
[13:42] <Trevinho> I wanted to release unity 7.3.3
[13:42] <Trevinho> So I need to update changelog and stuff like that and do the tarball
[13:43] <seb128> unsure, ask on #ubuntu-ci-eng I guess
[13:43] <Trevinho> ok
[13:43] <seb128> you can bump the changelog in a mp that you ci lande
[13:43] <seb128> unsure about the tarball part
[13:44] <Trevinho> seb128: yeah, but I didn't want to do a "SRU" for wily...
[13:44] <tjaalton> pitti: actually it's xorg-server that will provide -legacy, but I'll wait until ancell has pushed his uploads to git
[13:45]  * Trevinho hates this time-consuming duties
[14:03] <sethj> is the bug scrub still happening? Been too busy the last couple weeks to keep up.
[14:50] <willcooke> seb128, I saw you updated some rls-w-incoming to rls-x-incoming
[14:50] <willcooke> Can we automatically move them all over do you think?
[14:51] <willcooke> Although, I expect it will be hard to know which are ours and which are not?
[14:51] <willcooke> I think we could automatically update the Unity 7, Compiz, Nux ones right Trevinho ?
[14:52] <Trevinho> I think so willcooke
[14:52] <willcooke> Trevinho, I think the bug scrubber script should be able to make light work of that, Trevinho you want to take a look?
[14:52] <willcooke> or I can later on
[14:53] <Trevinho> willcooke: i can do that, once I'm done with the 7.3.3 release and 7.4.0 branch preparation...
[14:53] <willcooke> Trevinho, awesome, thanks
[15:35] <seb128> willcooke, I see no issue moving all those over no
[15:36] <willcooke> cool
[15:36] <willcooke> balloons, created at testing session in Summit :)
[15:36] <balloons> willcooke, excellent, thank you
[15:37] <balloons> should be a lively discussion
[16:38] <seb128> Sweet5hark, is  libreoffice-dictionaries something we could perhaps sync from Debian?
[16:38] <seb128> or is our version different?
[16:39] <Sweet5hark> seb128: not sure, lemme have a look at it.
[16:39] <Trevinho> all dark here...
[16:39]  * Trevinho hates solar time
[16:40] <seb128> yeah :-/
[16:43] <larsu> what is it with people in this channel complaining about dst?
[16:45] <seb128> larsu, we are complaining about winter!
[16:45] <seb128> give us the summer back!
[16:45]  * larsu gives seb128 summer back
[16:45] <seb128> :-)
[16:47] <Sweet5hark> larsu: did you just throw seb128 to the southern hemisphere for a summer experience?
[16:47] <larsu> Sweet5hark: virtually, yes
[16:58] <didrocks> have a good evening everyone
[17:24] <Sweet5hark> seb128: https://bugs.launchpad.net/ubuntu/+source/libreoffice-dictionaries/+bug/1510198
[17:25] <seb128> Sweet5hark, thanks
[18:00] <Trevinho> new libsigc++ causes FTB in unity... Damn it!
[18:00] <Trevinho> (and probably nux as well)
[18:00] <Trevinho> In xenial I mean...
[18:00] <Trevinho> Anyway, things for tomorrow
[18:00] <Trevinho> see you!
[18:09] <willcooke> g'night all
[18:09] <willcooke> sooo dark :((
[21:34] <TheMuso> Morning all.


[12:17] <lifeless> jelmer: whats the branch ?
[12:17] <jelmer> https://launchpad.net/people/jelmer/+branch/samba/svn-4.0
[12:18] <jelmer> It has ~9000 revisions and was added on friday IIRC - launchpad doesn't seem to have problems with the wireshark branch which has 18000+ and has been added later
[12:20] <lifeless> so I wanted to ask you
[12:20] <lifeless> we have a discussion at the moment about 'bzr branch' and formats
[12:20] <lifeless> I think that 'bzr branch' changing formats surprises users
[12:20] <lifeless> and that the default behaviour should always be to preserve the control-dir format
[12:21] <lifeless> i.e. format6 branches stay as format6, metadir stays as metadir, hg stays as hg, git stays as git
[12:21] <lifeless> the branch looks ok to me, its mirrored correctly.
[12:21] <lifeless> can you please file a bug on launchpad-bazaar about it ?
[12:22] <lifeless> but svn can't really branch natively :)
[12:22] <jelmer> lifeless: Sure
[12:22] <jelmer> I think it indeed makes sense to keep the original format in the case of distributed systems
[12:23] <jelmer> All the centralised systems should (imho) use the default bzr format
[12:24] <jelmer> or perhaps, rather, all systems that can't easily build a full branch (all history locally)
[12:24] <jelmer> s/full/heavyweight/
[12:25] <jelmer> What do you think should happen when making a checkout of a .hg branch? What format to use?
[12:26] <lifeless> now *thats* a question :)
[12:26] <lifeless> hg does not have a checkout facility itself
[12:27] <lifeless> (heavyweight or lightewight at the moment)
[12:27] <lifeless> so, I think it needs to convert by definition
[12:27] <lifeless> (because commit is not natively implemented for hg - we use their pythno module to commit
[12:28] <jelmer> hmm
[12:29] <jelmer> So I guess the choice is between always converting foreign branches to a bzr format, or only converting them when the particular method (branch/lightweight checkout/heavyweight checkout) is not supported for the particular foreign branch format.
[12:29] <lifeless> but in theory, we can build the same logic for hg using our implementation, and commit builder
[12:30] <lifeless> and have a 'native commit' which would let us do the local commit, push, finalise sequence. *I guess*. I dont know their smart servers beahviour well enough to know if that would in fact honour our semantics
[12:30] <lifeless> my concern is that conversion takes time
[12:30] <jelmer> But what sort of .hg control dir would you create in the local dir?
[12:30] <lifeless> a real one :)
[12:30] <lifeless> lots of issues to figure out - how to tell .hg its bound etc etc etc
[12:30] <lifeless> more reasons to convert on checkout
[12:31] <jelmer> right
[12:31] <jelmer> so there'll always be cases where conversion will be necessary ('bzr branch' on a SVN branch, etc)
[12:32] <lifeless> right
[12:32] <lifeless> hows your patch to the bzr-hg coming along btw ?
[12:34] <jelmer> I haven't looked at it again yet - got distracted by some other projects
[12:34] <jelmer> with a bit of luck, I'll resend a fixed version before the next weekend
[12:34] <lifeless> cool
[12:34] <lifeless> I am hoping we can reuse the inventory synthesis in bzr-git
[12:36] <jelmer> ah, ok - I haven't looked at your git plugin yet
[12:36] <jelmer> Have you tried it on the kernel yet?
[12:36] <lifeless> they have very similar but not identical models
[12:36] <lifeless> bzr vis on the kernel in git? no
[12:36] <lifeless> I dont have a kernel tree in git format
[12:37] <lifeless> it will be slow though - its a fork() roundtrip per revision access
[12:37] <lifeless> that can be fixed by smarter implementation of the higher order methods like get_revision_graph to query for all the revision data and (shock, horror) cache it
[12:38] <jelmer> There is no library or anything that can read parse gits control format?
[12:38] <lifeless> the official interface is 'git'
[12:38] <lifeless> as opposed to libgit. AFAICT there is no libgit even
[12:39] <jelmer> Ouch
[12:39] <jelmer> I wonder what the darcs folks use - apparently they have git support as well
[12:39] <lifeless> dunno
[12:39] <lifeless> probably they are doing 'conversion' not 'model and access'
[12:40] <lifeless> (baz-import vs the hg/git/svn plugins)
[12:40] <lifeless> conversion is always an easier proposition
[12:40] <lifeless> in that you are expected to cache and stream and take a while
[12:40] <jelmer> looks like they're actually able to use git repositories as if they were darcs branches
[12:41] <lifeless> oh? I take it back then
[12:41] <lifeless> they can commit to them ?
[12:42] <jelmer> apparently - 'darcs record' is supposed to work
[12:42] <jelmer> http://darcs.net/DarcsWiki/DarcsGit
[12:45] <lifeless> get yourself a copy of Git (0.99 or later) and run make; this should build a libgit.a.
[12:45] <lifeless> static library only
[12:45] <jelmer> ahh
[12:45] <jelmer> I guess you can always dlopen() a binary though
[12:46] <jelmer> ;-)
[12:47] <lifeless> holy fuck
[12:47] <lifeless> git-core ships an entire copy of subprocess.py
[12:48] <jelmer> probably because python 2.3 doesn't have subprocess
[12:48] <lifeless> the right answer there is 'depend on python 2.4' ;)
[12:49] <lifeless> theres no mention of it in the debian copyright file. :(
[12:49] <jelmer> you're talking to a poor part-time Debian sid user who is still stuck with python2.3
[12:49] <jelmer> ;-)
[12:49] <lifeless> at a minimum, the debian *package* should not ship like that
[12:52] <lifeless> https://launchpad.net/distros/ubuntu/+source/git-core/+bug/53827
[12:52] <Ubugtu> Malone bug 53827 in git-core "Please ship libgit.a" [Untriaged,Unconfirmed]
[12:56] <jelmer> ah, guess that's probably a better idea than opening the git binary (-:
[12:57] <jelmer> hmm.. when I get the time, I'll have a look at bzr-darcs - apparently it isn't hard to wrap haskell in python
[12:58] <lifeless> well
[12:58] <lifeless> I'd use pyrex and make a git.so plugin for bzr myself
[12:58] <lifeless> no point thunking through haskell, when the darcs and bzr models are also not the same
[12:59] <lifeless> oh, sorry, misread you
[12:59] <lifeless> yes, bzr-darcs would be cute
[01:00] <jelmer> How well does pyrex work? Using SWIG really discouraged me to use binding generators unless I had to create bindings for more than 2 different languages
[01:01] <lifeless> pyrex isn't a binding generator
[01:01] <lifeless> have you read the readdir branch ?
[01:02] <jelmer> ah, looking at the website made me remember. I was confusing it with some ctypes alternatives for Python
[01:02] <jelmer> lifeless: Haven't looked at the code yet, no
[01:03] <jelmer> lifeless: I'm keen to see it go in though.. running 'bzr status' on 5000-file branches very often now that I'm using bzr for my Samba work
[01:18] <jelmer> Only git-core for Python2.3 in Debian.. :-/
[01:19] <jelmer> s/git-core/stgit/
[01:20] <jelmer> s/2.3/2.4/
[01:20] <jelmer> time to get some sleep, apparently.. 'night!
[06:21] <Lord_Athur> hi all
[06:22] <Lord_Athur> how could i be sure that all my installed programs are in my language? can I do it?
[06:30] <mpt_> Gooooooooooooood afternoon Launchpadders!
[06:32] <Lord_Athur> I use kubuntu + edubuntu-desktop, but some sub-menus of the edubuntu programs are in English in the kde menu,How do I make an specification about it in order to show that the language of the menu application is the wrong one?
[06:33] <mpt> Lord_Athur, that seems like a bug, not a subject for a specification
[06:33] <Lord_Athur> ok,
[06:33] <Lord_Athur> so, how do i notify a bug?
[06:34] <mpt> It might be just that they're not translated yet
[06:34] <Lord_Athur> ok
[06:34] <mpt> What is an example of one of the programs?
[06:35] <Lord_Athur> I'm chilean(so my language is Spanish):
[06:35] <Lord_Athur> "entretenimientos educativos" :"languages":"kanagram(juego de .....".
[06:35] <Lord_Athur> in that example you can see a menu which is in English
[06:36] <mpt> ah, so "Languages" is in English but should be in Spanish
[06:36] <Lord_Athur> yes
[06:36] <Lord_Athur> and it could be difficult for young children know what to do in these situations
[06:36] <Lord_Athur> so, I'd like to report that bug or help or help to traslate it
[06:38] <mpt> ok, to start off I'd suggest reporting a bug here https://launchpad.net/distros/ubuntu/+filebug
[06:39] <mpt> Then someone will put the bug report into the correct package
[06:39] <mpt> Then if you want to, you can find the Rosetta translations for that package, and translate it yourself :-)
[06:40] <Lord_Athur> thanks mpt
[06:49] <Lord_Athur> mpt, in a part of the bug reports there are three optios for "asigned to". what may I choose?
[06:49] <Lord_Athur> I mean, do I put "Me"?
[06:49] <ajmitch> only assign to yourself if you'll be the one fixing the bug
[06:49] <ajmitch> generally just leave it as default
[06:50] <Lord_Athur> ok thanks
[06:51] <Lord_Athur> Thanks all, I leave now
[06:51] <Lord_Athur> bye
[07:02] <elkbuntu> wtf.. launchpad still doesnt import my key :|
[07:02] <elkbuntu> "HTTP Error 500: OK at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x940BDA96&op=get"
[09:59] <sabdfl> hey guys, where's the new push location? and has the copy from chinstrap been completed?
[10:39] <jamesh> good morning
[10:40] <Kamping_Kaiser> hi jamesh
[10:57] <carlos> morning
[11:53] <spiv> jamesh: you know what else would be good to randomise to break tests?  os.listdir.
[11:55] <jamesh> spiv: yes, it would :)
[11:56] <spiv> jamesh: I just reviewed a doctest that I think is accidentally depending on ordering of os.listdir (via glob.glob), hence the thought :)
[11:59] <lifeless> rotfl
[12:04] <lifeless> ddaa: meeting time!
[12:12] <SteveA> spiv: hello
[12:13] <spiv> SteveA: Good evening.
[12:29] <malcc> Yeah, sorry about that one, I promise to keep my branches smaller going forward
[12:31] <Kinnison> Pah, I bet it wasn't as bad as the 'OMG, all of soyuz, WTF?!' branch we gave to jamesh
[12:31] <jamesh> no more mega soyuz branches, please
[12:31] <Kinnison> :-)
[12:31] <Kinnison> I promise, I will never give you another mega branch
[12:53] <lifeless> reviewer meeting in 7
[01:01] <lifeless> reviewer meeting time
[01:01] <lifeless>  * Roll call
[01:01] <lifeless>  * Agenda
[01:01] <lifeless>  * Next meeting
[01:01] <lifeless>  * Queue status.
[01:01] <lifeless> who art here ?
[01:01] <spiv> I art.
[01:02] <lifeless> ok
[01:02] <jamesh> me
[01:02] <lifeless> cool
[01:02] <lifeless> bjorn is on leave
[01:02] <lifeless> next meeting:
[01:03] <lifeless> 2006-07-31 at 1100 UTC.
[01:03] <lifeless>  ok?
[01:03] <jamesh> ok
[01:03] <lifeless> queue status
[01:04] <lifeless> so
[01:04] <lifeless> 2 at 5 days old
[01:04] <spiv> process-upload-tidy is reviewed as of nearly an hour ago.
[01:04] <lifeless> spiv and spiv
[01:04] <lifeless> cool
[01:04] <lifeless> 1 at 5
[01:04] <lifeless> 1 at 4
[01:04] <lifeless> and 2 at 3
[01:04] <lifeless> this is all under control IMO
[01:05] <lifeless> lots of stuff at one day
[01:06] <SteveA> hi
[01:06] <lifeless> jamesh: is pending-reviews running ?
[01:06] <jamesh> let me check
[01:07] <jamesh> stale lock on the working repo
[01:07] <lifeless> ah :)
[01:08] <jamesh> also chinstrap's filesystem is mounted read only
[01:08] <lifeless> righto
[01:08] <lifeless> ok, any other business? any new tricks to watch out for ?
[01:09] <lifeless> 4
[01:09] <spiv> My inclination to move some tests from doctests to plain python is growing.
[01:09] <lifeless> ok
[01:10] <lifeless> can you write up your feelings on why? I suspect I'll agree :).
[01:10] <spiv> doctests actually harm readability for sufficiently complex code -- people don't ever seem to use inline comments, even when defining 20 line functions :)
[01:10] <lifeless> lets have a discussion on the list ?
[01:10] <jamesh> doc tests do seem to result in more test dependencies than would be nice
[01:10] <spiv> I'll write up my thoughts for the list.
[01:11] <lifeless> and ok.
[01:11] <lifeless> any other business ?
[01:11] <lifeless> 4
[01:11] <lifeless> 3
[01:11] <lifeless> 2
[01:11] <lifeless> 1
[01:12] <lifeless> thanks for comingg
[01:12] <lifeless> spiv: happy to chat now about it, but didn't want to minute it :)
[01:13] <spiv> lifeless: Ok :)
[01:14] <spiv> The readability thing is funny, because that's the reverse effect to the typical doctest effect, where comments are easier to write than code.
[01:14] <spiv> But you almost never see a helper function in a doctest with a docstring explaining what it does or what args it should take, let alone comments inside them.
[01:15] <spiv> You do sometimes see big paragraphs before them that try to explain everything, and then the large code, where in plain python the comments would be one at a time, right next to the relevant line of code.
[01:16] <lifeless> yah
[01:16] <spiv> Also, complex helper functions don't tend to fit neatly into a doctest narrative.
[01:16] <lifeless> thats my biggest bugbear
[01:16] <lifeless> narrative tests are great for showing people how to use an api
[01:16] <spiv> So they tend to get defined where they're needed, but are more general than that case would seem to need, because actually they're also used 100 lines further down
[01:17] <lifeless> but beyond that I find it quickly becomes harder to grok that a tonne of focused tests
[01:17] <spiv> Whereas in a TestCase, you have an obvious and neat place for a helper: a method on the TestCase.
[01:18] <spiv> Anyway, I guess my concerns are:
[01:19] <spiv>   * helper functions more than 3 lines long are almost always very ugly in doctests
[01:20] <spiv>   * you get long, rambling tests with complex setup, rather than lots of focussed, specific, isolated tests (let alone *unit* tests)
[01:20] <lifeless> yup
[01:21] <spiv> testing.txt is a good counter-example to my concerns.
[01:21] <spiv> It does lots of things, but the individual sections are independent and readable on their own, without 200 lines of context.
[01:22] <spiv> There are other niggles, e.g. I saw this today:
[01:22] <spiv> +  >>> if process.returncode != 0:
[01:22] <spiv> +  ...     print stdout
[01:22] <spiv> +  ...     print stderr
[01:22] <spiv> +
[01:22] <lifeless> right
[01:22] <spiv> Which ought to be just ">>> process.returncode\n0"...
[01:23] <spiv> ...but then you don't get the debugging you need.
[01:23] <lifeless> people want unittest debugging because they are debugging things, not demonstrating the api
[01:23] <spiv> assertEqual(0, process.returncode, "failed, here's more info: %s" % ...) doesn't have that issue.
[01:26] <spiv> The doc/soyuz-*.txt tests I saw in a review today are what brought this on, if you're curious.
[01:29] <gapz> 'lo
[01:32] <lifeless> spiv: just about any unit-as-doctest brings it on for me :)
[01:33] <jamesh> morning bradb
[01:34] <bradb> hey jamesh
[03:23] <Kamping_Kaiser> i'm trying to link a bug in ubuntu to a bug in debian, and i need a 'product' to go with the bug number and remote BTS - what is this 'product' it needs?
[03:24] <LarstiQ> Is that the case?
[03:25] <jamesh> Kamping_Kaiser: use the "also affects: distribution" link rather than "also affects: product"
[03:25] <Kamping_Kaiser> oh ok, i'll have a shot, thanks
[03:26] <Kamping_Kaiser> it says 'upstream', rahter then 'product', thats probably what caused the confusion
[03:27] <Kamping_Kaiser> done, thanks jamesh
[03:28] <jamesh> Kamping_Kaiser: I suppose it is a bit confusing since Debian is a little way upstream of ubuntu :)
[03:28] <Kamping_Kaiser> :)
[04:30] <Kamping_Kaiser> i jsut had an oops - ID  OOPS-205B211
[04:30] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/205B211
[04:30] <Kamping_Kaiser> o_0
[04:30] <Kamping_Kaiser> grrr. that was my good night rejection.
[04:30] <Kamping_Kaiser> it'll wait. gl :)
[04:55] <flacoste> kiko: hi!
[05:07] <kiko> hey flacoste!
[05:07] <kiko> good to see you around
[05:07] <flacoste> how was mallorca?
[05:08] <kiko> it was great
[05:08] <kiko> good work
[05:08] <kiko> just spent about 12h between airports though
[05:08] <flacoste> got a chance to enjoy the mediterranean?
[05:08] <kiko> not really
[05:09] <SteveA> kiko was a crazy cycling dude
[05:09] <SteveA> 0wning the mountains
[05:09] <flacoste> aha! I guess that's as good as the sea for some
[05:10] <kiko> well you have to understand
[05:10] <kiko> there was only from 6am to 8:30am to do anything but work
[05:10] <SteveA> this is true
[05:10] <flacoste> i am sure the sea was nice at 6:30 :-)
[05:10] <kiko> I have no real idea
[05:10] <kiko> jbailey saw the sea I hear
[05:11] <kiko> hey matsubara
[05:11] <SteveA> I photographed it from a distance
[05:11] <SteveA> it was blue
[05:11] <matsubara> yo kiko
[05:11] <kiko> matsubara, nice work on the timeouts eh?
[05:11] <kiko> hey carlos, jordi, salgado
[05:11] <kiko> I was thinking
[05:11] <kiko> you know, now that KarmaContext has landed
[05:12] <kiko> it is actually possible to better track where a person did karma actions
[05:12] <kiko> which could in theory replace the query we do for +translations.
[05:12] <kiko> what do you guys think?
[05:12] <salgado> hey kiko
[05:12] <carlos> kiko: hey dude
[05:13] <carlos> kiko: yeah, I guess we could use it as a kind of cache for that page
[05:13] <kiko> carlos, we would just need to store the template the person was translating
[05:13] <kiko> right?
[05:13] <salgado> you mean, somehow store the bug/spec/whatever that the person created/changed/... ?
[05:14] <kiko> salgado, yes. what do you think of that?
[05:14] <carlos> kiko: we could get it from the context
[05:15] <kiko> carlos, I don't think salgado stores the real "context"
[05:15] <carlos> let's talk later
[05:15] <kiko> he stores the "pillar"
[05:15] <kiko> sure.
[05:15] <kiko> salgado, does that sound possible,reasonable?
[05:16] <matsubara> kiko: Indeed quite a decrease. there are some pages left to improve though.
[05:16] <salgado> it probably is possible, I think. but I don't see how the KarmaContext implementation helps on that front
[05:16] <kiko> matsubara, I'm thinking about +translations
[05:16] <kiko> salgado, well, in karmacontext you already give us some information related to the context, right?
[05:17] <salgado> yeah, the product or distribution
[05:17] <kiko> salgado, so, for instance, it'd be a matter of adding some extra info there.
[05:17] <kiko> salgado, sound.. possible?
[05:17] <kiko> https://launchpad.net/people/sabdfl/+translations
[05:17] <kiko> for instance
[05:18] <kiko> I'd need to store the actual pot translated.
[05:18] <kiko> err po-file
[05:21] <salgado> it should be doable, but I guess we'd need a few extra columns, each one being a foreign key to a different table, no?
[05:24] <kiko> salgado, I guess, yeah. kinda crummy but, well, we could do it just for translations for now. does that sound awful?
[05:24] <kiko> bradb, ping?
[05:24] <salgado> why only translations?
[05:25] <kiko> salgado, to stop +translations from timing out.
[05:31] <carlos> kiko: ok, I'm back
[05:32] <carlos> kiko: you are right, we only have the product or sourcepackage
[05:32] <carlos> kiko: but I guess that good enough to reduce the amount of time we need to calculate their contributions
[05:32] <kiko> carlos, so we'd need to add an extra column there, which would only be not null sometimes. what do you think?
[05:32] <kiko> SteveA, have an opinion?
[05:32] <carlos> kiko: hmm, let's try first without changing our database
[05:32] <kiko> carlos, how would you do that?
[05:32] <SteveA> kiko: yes.  chocolate is better than ice-cream
[05:33] <kiko> SteveA, I meant wrt using KarmaContext to track translations.
[05:33] <SteveA> I haven't given it any particular thought.  What's the problem it can solve or improve?
[05:33] <kiko> +translations timing out. see above.
[05:33] <carlos> kiko: use the same query we have now, but instead of joining all potemplates across all distributions/products, just join the ones that we actually know he worked on
[05:34] <kiko> carlos, I see. that's an interesting idea.
[05:34] <kiko> carlos, using an IN () subselect?
[05:34] <carlos> I guess, yes
[05:35] <carlos> kiko: I think we could try that and if it's fast enough we save some complexity in our database...
[05:35] <kiko> I guess.
[05:35] <salgado> if we do that there may be some contributions not showing up
[05:35] <kiko> salgado, why?
[05:35] <salgado> (not sure how big of a problem that is, though)
[05:35] <kiko> old ones you mean?
[05:35] <salgado> yes
[05:35] <carlos> salgado: we would be interested on latest contributions, say one month or so
[05:35] <kiko> salgado, well, we could also poison the database. :)
[05:36] <SteveA> kiko: I don't see the connection between karma and +translate
[05:36] <SteveA> or +translations
[05:36] <salgado> we'd use the karma as a cache, basically
[05:36] <SteveA> is the idea that the context-specific karma stuff acts as a log
[05:36] <SteveA> of the translations that you have done
[05:37] <SteveA> and so you can rely on that log to display the translations you did
[05:40] <kiko> SteveA, exactly.
[05:42] <kalosaurusrex> hey guys! does launchpad have the ability to run support reports of some sort?
[05:44] <flacoste> kalosaurusrex: what do you have in mind exactly?
[05:44] <SteveA> kiko: I think it makes sense to do that.  I can think of four ways to reasonably achieve it, and two that are actually worth considering.
[05:44] <kiko> SteveA, rock and roll
[05:45] <SteveA> kiko: 1: add a bunch of extra columns to the karma table to link a karma record to other entities.  but even then, the meaning of the link depends on the type of karma
[05:45] <SteveA> 2: keep the karma table simple, without links.  add a new "karma translations" table for the extra info.
[05:45] <kiko> yes, correct.
[05:46] <kiko> SteveA, carlos suggested 3: framing the query for translations into translations that we know the user has actually done (via karma)
[05:46] <kiko> salgado, does karmacontext store the source package?
[05:46] <salgado> yes
[05:46] <kiko> cool
[05:51] <kalosaurusrex> flacoste: well it would be nice to be able to get a report on date issues is open and closed, and be able to get some stats on that. as well as if there was an option to add more fields and could get reports on those it would be useful.  like operating system support reports, and some specific stuff that would be useful to me (what printer, etc.)
[05:53] <flacoste> kalosaurusrex: that's an interesting idea, currently Launchpad doesn't have much in terms of reporting
[05:54] <flacoste> kalosaurusrex: the date open/closed report would be possible to implement
[05:54] <flacoste> kalosaurusrex: but the other stuff (by operating system, printer, etc.) would be more problematic since we don't track that stuff now
[05:57] <kalosaurusrex> flacoste: I gotcha.  well perhaps sometime in the future. but open/closed would be cool :)
[05:58] <flacoste> kalosaurusrex: can you add a bug report to https://launchpad.net/products/launchpad-support-tracker about that?
[06:02] <flacoste> SteveA: do you still plan to do some adapter refactoring this week?
[06:04] <kalosaurusrex> flacoste: sure thanks!
[06:04] <SteveA> flacoste: that would be next week, when I'm not sprinting
[06:05] <SteveA> kiko: if we start using the Karma table as an person's activity log as well as for the Karmic implications of that, we should rename it Activity, and use Activity to calculate Karma.
[06:05] <kiko> why not?
[06:05] <flacoste> SteveA: i thought that it was next week you were sprinting, no problem, I'll ping you again next week :-)
[06:05] <SteveA> kiko: why not what?
[06:06] <kiko> rename it to activity. :)
[06:07] <SteveA> I don't understand what you're asking
[06:07] <kiko> I'm agreeing with you
[06:07] <SteveA> why not?
[06:07] <SteveA> ;-)
[06:08] <kiko> heh
[06:16] <kalosaurusrex> flacoste: https://launchpad.net/products/launchpad-support-tracker/+bug/53913
[06:16] <Ubugtu> Malone bug 53913 in launchpad-support-tracker "[support tickets]  reporting functionality" [Untriaged,Unconfirmed]
[06:16] <kalosaurusrex> hope it makes sense.  not enough coffee yet.
[06:17] <flacoste> kalosaurusrex: thanks!
[06:17] <kalosaurusrex> flacoste: thanks for your time as well!
[06:35] <LaserJock> bradb: around?
[07:10] <Lord_Athur> hi everyone
[07:10] <Lord_Athur> I've asked many times about what karma is, but
[07:11] <Lord_Athur> why do I have many actions in karma, but 0 as number? It doesnt make me be clear about karma :S
[07:13] <flacoste> Lord_Athur: in launchpad karma is aged: after one year it is worth 0
[07:14] <flacoste> Lord_Athur: somebody did a camparison of Launchpad karma with other system: http://alligevel.blogspot.com/2006/07/karma-in-launchpad.html
[07:15] <Lord_Athur> :(, I've understood that karma is gaven by the actions you do in ubuntu/launchpad, am I wrong?
[07:15] <flacoste> Lord_Athur: not, this is true, it's just that karma ages so last years action aren't worth anything anymore
[07:16] <LarstiQ> Lord_Athur: you need to keep active, or your karma will drop to zero.
[07:17] <LarstiQ> Lord_Athur: otherwise newcomers will be hopelessly behind, not very motivating.
[07:17] <LaserJock> I'm not sure if *all* actions give karma either, but I could be wrong
[07:17] <Lord_Athur> lamont, you're right
[07:19] <Lord_Athur> LaserJock, look at this page https://launchpad.net/people/alejandro-leonvega/+karma I've actions that are considered for karma, but no karma.
[07:20] <LarstiQ> Lord_Athur: that is because you all did it today
[07:20] <LarstiQ> Lord_Athur: afaik, karma is updated once per day
[07:20] <LaserJock> Lord_Athur: dude, it takes a while :-)
[07:22] <Lord_Athur> Hahaha, thanks all, I did some things last night in rosetta, but I don't remember in what time exactly, maybe it was this morning.
[07:22] <Lord_Athur> :P
[07:25] <Lord_Athur> thanks launchpad people, see u later
[07:40] <LarstiQ> eek!
[07:40] <LarstiQ> bradb: you seem to still be alive?
[07:40] <bradb> right now, anything i say comes out "balaaahhallblllaaahhablllab"
[07:41] <bradb> LarstiQ: fvdo "alive"
[07:41] <bradb> and i'll be back tomorrow morning for more
[07:41] <LarstiQ> why?
[07:41] <bradb> 2 more fillings
[07:42] <bradb> today was Tooth Reconstruction Day
[07:43] <bradb> kiko: pong
[07:43] <LarstiQ> bradb: good luck
[07:43] <bradb> thanks
[07:49] <jamesh> kiko: replied to your comments about the SF import
[07:57] <Lord_Athur> hi
[08:07] <Lord_Athur> can I change the e-mail which I use for logging in in launchpad?
[08:09] <LaserJock> Lord_Athur: yes, change the prefered email address
[08:11] <bradb> Lord_Athur: You should be able to login with any email address you've registered with Launchpad, preferredemail or not.
[08:12] <Lord_Athur> yes bradb, but can I change the e-mail address used at the moment of the registration in launchpad?
[08:15] <Lord_Athur> thanks all, I solved it
[08:37] <SteveA> lifeless: please see email addressed to you, cc launchpad list "moving from chinstrap to sodium" when you're around tomorrow.
[08:45] <panickedthumb_wo> James Henstridge suggested I post this here
[08:45] <panickedthumb_wo> https://launchpad.net/bugs/53678
[08:45] <Ubugtu> Malone bug 53678 in launchpad "defunct account" [Untriaged,Unconfirmed]
[08:46] <panickedthumb_wo> exactly
[08:46] <panickedthumb_wo> and that an admin here could help me out
[08:46] <kiko> panickedthumb_wo, one sec.
[08:47] <kiko> panickedthumb_wo, done.
[08:48] <panickedthumb_wo> you're quick!
[08:48] <panickedthumb_wo> :)
[08:48] <panickedthumb_wo> one more bug
[08:49] <panickedthumb_wo> https://launchpad.net/bugs/53679
[08:49] <Ubugtu> Malone bug 53679 in launchpad "member email" [Untriaged,Rejected]
[08:49] <panickedthumb_wo> Diogo says I've never signed the CoC, but I have, before Launchpad was created
[08:49] <panickedthumb_wo> signed and sent to Mako
[08:49] <matsubara> panickedthumb_wo: digitally signed?
[08:49] <panickedthumb_wo> yes
[08:50] <flacoste-lunch> ./nick flacoste
[08:51] <panickedthumb_wo> I'm not sure if it didn't get included in Launchpad because I did it before Launchpad was launched or what... and it may be that it was in the account that kiko just closed
[08:51] <kiko> let me see.
[08:51] <matsubara> panickedthumb_wo: you don't appear to have signed. You're not listed as an Ubuntero. What does the https://launchpad.net/people/panickedthumb/+codesofconduct show?
[08:51] <bradb> LarstiQ: How do I manually unlock a branch? I tried break-lock'ing a remote branch, but I still get:
[08:51] <bradb> bzr: ERROR: Could not acquire lock LockDir(sftp://chinstrap.ubuntu.com/home/warthogs/archives/bradb/launchpad/malone-smallfixes/.bzr/branch/lock)
[08:51] <bradb> when I try to push
[08:52] <matsubara> bradb: chinstrap is read only
[08:52] <kiko> bradb, hmmm, when I had that problem I had to end up using rspush.
[08:52] <kiko> panickedthumb_wo, can you try signing again?
[08:52] <panickedthumb_wo> matsubara: shows that I never signed one
[08:52] <kiko> panickedthumb_wo, and uploading the signed document to https://launchpad.net/codeofconduct/1.0.1/+sign
[08:52] <matsubara> panickedthumb_wo: you'll need to sign it again then and re-upload as per kiko's instruction.
[08:52] <bradb> matsubara: hah!
[08:53] <Lord_Athur> hi all
[08:53] <bradb> matsubara: What do we do with our branches then?
[08:53] <panickedthumb_wo> ok, I'll do that when I get home
[08:53] <matsubara> bradb: wait until sodium is ready, I think.
[08:53] <bradb> ok
[08:53] <panickedthumb_wo> thanks guys
[08:53] <kiko> bradb, good point!
[11:21] <lucas> hi
[11:21] <lucas> any idea when bug 44545 will be solved ?
[11:22] <Ubugtu> Malone bug 44545 in launchpad "FOAF Request: make all Teams into email-aliases/mailing-lists" [Medium,Unconfirmed]  http://launchpad.net/bugs/44545
[11:22] <lucas> should I wait or create a mailing list somewhere else ?
[11:24] <bradb> lucas: best to create an ML
[11:24] <lucas> ok
[11:25] <lucas> then what about bug 39260 ? :)
[11:25] <Ubugtu> Malone bug 39260 in launchpad "Extract team members' email addresses" [Medium,Confirmed]  http://launchpad.net/bugs/39260
[11:27] <bradb> lucas: I'm guessing that won't be fixed in the next week or two or three. salgado? ^^