[12:12] <kiko> Z3 uses interfaces to specify elements in a form 
[12:12] <flacoste> sivang: it's normal, they are confusing but the relationship is that a form (or view) usually uses a schema (an interface) to specify the fields it contains as well as the validation constraints of that schema
[12:12] <kiko> I'm not sure that is conflating
[12:13] <flacoste> or like kiko said in less word :-)
[12:13] <kiko> the launchpad tree makes it confusing though
[12:15] <matsubara> sivang: i think the bug you just reported is a dupe of bug 52330, could you check?
[12:15] <Ubugtu> Malone bug 52330 in launchpad "Reassign bug to binary package should just work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52330
[12:15] <flacoste> sivang: in an edit form each field in the schema will have a corresponding widget and the widget usually delegates validation to the field (that's the Choice in your case)
[12:15] <sivang> matsubara: /me checks
[12:16] <matsubara> or perhaps bug 1922
[12:16] <Ubugtu> Malone bug 1922 in malone "Unhelpful "Invalid value" error when requesting fix for non-existent package/product" [Medium,Confirmed]  http://launchpad.net/bugs/1922
[12:16] <matsubara> but i'm outta here
[12:16] <matsubara> see you guys tomorrow
[12:16] <sivang> matsubara: laters
[12:16] <matsubara> good night all
[12:17] <flacoste> sivang: another important thing you will want to know:
[12:18] <flacoste> field validation will raise an exception when the value is incorrect
[12:19] <flacoste> each errors can be rendered differently based on its type
[12:20] <flacoste> the widget will try to find a view registered for the specific type
[12:22] <sivang> flacoste: thanks, see you later then.
[12:22] <flacoste> sivang: feel free to ping me tomorrow if you need further clarifications on how all of this fits together
[12:23] <sivang> flacoste: will do, many thanks.
[12:42] <sabdfl> kiko, flacoste: it's absolutely conflating the two
[12:42] <sabdfl> interfaces have Attribute's too
[12:42] <sabdfl> which have no place in a schema
[12:43] <kiko> sabdfl, doesn't it seem that way just because we store them all in the same place? I get that impression at least
[12:43] <sabdfl> the worst example of this is cases where the same attribute needs to be on multiple forms, with different help-text
[12:43] <kiko> if we had a place for forms/ and another for interfaces/..
[12:43] <kiko> hmm
[12:43] <kiko> yeah, I don't know!
[12:43] <sabdfl> for example, the new SpecSubscription.essential field
[12:44] <sabdfl> when you are editing YOUR subscription, the text wants to be different to when you are editing that of someone else
[12:44] <sabdfl> z3 does so many things the hard way, it still amazes me that people fell for this conflating short cut
[12:45] <sabdfl> kiko: that was a very good reply to the pythonista's again - thank you!
[12:46] <kiko> sabdfl, trying hard to give us a really good public impression
[12:46] <sabdfl> also, since you are Mr Review, there's this little branch i worked on over the weekend...
[12:46] <sabdfl> *most* of the 3,000 lines are [trivial] 
[12:46] <sabdfl> ;-)
[12:46] <kiko> oh that's what that praise was about!
[12:47] <kiko> well
[12:47] <sivang> sabdfl: somewhere in the phillikon book, I think it explains that Views (= forms?) Are basically another type of interface?  But it's late so I may be remembering it backwards
[12:47] <kiko> I have to finish catching up with commits
[12:47] <sabdfl> kiko: praise was genuine, kidding about the review
[12:47] <sabdfl> i'll put it in the queue, it's nice but nothing essential
[12:47] <sabdfl> and i have a few tests left to add
[12:47] <kiko> and then I will do two days of reviews
[12:47] <kiko> well, one day
[12:47] <sivang> and also, "haha" for the 3,000 [trivial]  lines :-)
[12:47] <kiko> two days is hard because my inbox just goes boom
[12:48] <kiko> but I'll start tomorrow afternoon if possible
[12:48] <sabdfl> kiko: you're a hero for tackling the reviews, but it may be worth figuring out where the bottlenecks in our review team are
[12:49] <kiko> I think rob manages them well -- main bottlenecks are when branches get assigned to me! :)
[12:49] <kiko> (just ask flacoste)
[12:49] <sabdfl> i'm a bit worried about this bradb-flacoste adapter love-fest
[12:49] <sabdfl> bye-bye readability...
[12:50] <sabdfl> "I've got an IFoo adapted to a IBar being passed to an IBaz through a security adapter and something's not working"
[12:50] <sabdfl> help
[12:51] <kiko> I think it depends on where and how it's used
[12:51] <kiko> IBugTarget is something that would clean up some 200 LOC
[12:51] <kiko> which is currently spread around separate classes
[12:52] <kiko> keeping it together would be a maintenence plus
[12:52] <kiko> would need to consider how it's used more carefully though
[12:59] <sivang> going to sleep, night all
[01:18] <sabdfl> night folks
[01:21] <kiko> night
[02:32] <bimberi> hi all, i've committed a fix to bug 55534, yet its importance remains at "Untriaged".  I don't seem to be able to edit that.  Should I be able to?  Does it matter?
[02:32] <Ubugtu> Malone bug 55534 in language-pack-gnome-en ""Select Folders" in en_GB translation should read "Search Folders"" [Untriaged,Fix committed]  http://launchpad.net/bugs/55534
[02:40] <bimberi> ... or should i ask in #ubuntu-bugs ;)
[02:42] <dsas> bimberi: You need to be in the ubuntu-qa team to change the importance.
[02:43] <bimberi> dsas: righto, thanks
[02:43] <dsas> bimberi: As far as I know rosetta commits are automatically imported into the repositories every once in a while.
[02:44] <dsas> bimberi: So there's probably no need to worry :)
[02:45] <bimberi> dsas: kk, thanks again :)
[04:02] <bmonty> is there a way to get an easily parseable version of the information at https://launchpad.net/distros/ubuntu/+archivemirrors?
[04:04] <spiv> bmonty: I don't think so, unfortunately.
[04:04] <bmonty> is the format of the current page likely to change?
[04:04] <bmonty> I have a program that would parse the mirrors list in the wiki and then test them for the fastest one (like apt-spy)
[04:05] <bmonty> I gave up on it because the mirror list format was changing and I had to keep reworking the parsing code
[06:49] <mpool> hi 
[06:49] <mpool> could we please have a list of milestones on pages like https://launchpad.net/products/bzr/+bugs
[06:49] <mpool> ?
[06:59] <mpt> Gooooooooooooooooood evening Launchpadders!
[06:59] <ajmitch> evening mpt
[07:03] <mpool> hello mpt!
[07:04] <mpool> where are you now?
[07:10] <sivang> morning!
[10:06] <carlos> morning
[10:09] <ddaa> Good morning.
[10:21] <carlos> stub: hi
[10:21] <stub> hi
[10:22] <carlos> did you have time to review my translation migration branch?
[10:36] <stub> carlos: I need to do the code review do I? There doesn't seem to be a db patch in there.
[10:37] <carlos> stub: the code review has a lot of SQL queries
[10:37] <carlos> in fact most of the patch are raw sql queries
[10:39] <stub> carlos: So when we create a new distro release, we need to insert maybe 10 million new rows into the DB?
[10:40] <carlos> kind of, yes
[10:40] <carlos> it took around 2 hours
[10:40] <carlos> that's why I want a review from you, to see if you can give us more hints to improve its performance
[10:41] <carlos> Steve told us to introduce a small delay between queries so we don't lock the whole database
[10:42] <carlos> it will take more time to complete, but we don't need to close launchpad
[10:42] <carlos> anyway, it will be executed only once every 6 months so I guess another option is to close it while doing the migration
[10:43] <spiv> Without understanding the problem at all, it sounds like the ideal solution would be to not need to insert the 10 million rows at all ;)
[10:44] <spiv> This sort of problem suggests that the data structures could be better.
[10:44] <carlos> spiv: that would mean that any translation in dapper will not be reused in edgy ;-)
[10:45] <carlos> spiv: we have an idea to implement a kind of inheritance
[10:45] <carlos> so we don't need to do that amount of inserts
[10:45] <carlos> but that's not viable in the near future
[10:49] <jamesh> spiv: you borked the "state age" column on the pending-reviews page
[10:49] <jamesh> spiv: should be fixed for the next update though
[10:51] <plaes> Q about the Rosetta's database layout, how are the plural strings stored?
[10:51] <Keybuk> checkrdepends on drescher appears to be broken ... it's exiting with an "unexpected end of file" error from gunzip
[10:51] <spiv> jamesh: oops, thanks.
[10:52] <jamesh> spiv: there is a pickled dictionary to keep track of that info, keyed off the branch URL
[10:52] <Keybuk> oh, ignore me, -ENOCOFFEE
[10:52] <spiv> jamesh: yeah, makes sense.
[10:54] <carlos> plaes: as any other translation with the index it has
[10:54] <carlos> plaes: why?
[10:55] <plaes> carlos: I'm thinking of writing smth on my own ;)
[10:56] <carlos> plaes: we map more or less the same information the .po file format defines + some extra metadata
[10:57] <plaes> so, if there isn't any plural form, then the "msgid_plural" column is just empty?
[10:57] <carlos> no, we use indexes for that
[10:57] <carlos> 0 is singular and 1 is plural
[10:57] <carlos> is much more simple
[10:58] <carlos> is the way translations are handled
[10:58] <plaes> what about languages with 3 plural forms?
[10:59] <carlos> 0, 1, 2
[11:01] <plaes> heh.. It seems that I need to take some "thinking simple" classes :)
[11:01] <plaes> thanks, carlos :D
[11:01] <carlos> plaes: do you really think you need a new project?
[11:02] <carlos> there are some projects already out there with source available
[11:02] <carlos> plaes: np
[11:02] <plaes> carlos: well, I'm not the one who decides.. :(
[11:02] <carlos> I see
[11:03] <plaes> but the work you have done with Rosetta is awesome :)
[11:07] <carlos> plaes: we have already 2 years of development ;-)
[12:05] <carlos> stub: aren't we updating every day staging's database?
[12:05] <stub> carlos: There is an RT job that needs sorting first (603? 605?)
[12:06] <carlos> I see
[12:06] <carlos> ok
[12:06] <carlos> stub: is ok If I merge my translation migration branch?
[12:06] <carlos> or should I wait too ?
[12:06] <stub> To staging? Or to rocketfuel?
[12:06] <carlos> to staging
[12:07] <carlos> I want to do more timings
[12:09] <stub> carlos: Go for i
[12:10] <stub> t
[12:10] <carlos> ok, thanks
[12:10] <stub> If you need a new db, I can push one out but it will take a few hours to load.
[12:10] <carlos> **** Staging will be down in 5 minutes for 5 - 10 minutes ****
[12:10] <carlos> stub: no, I don't need a new database
[12:10] <carlos> thanks
[12:11] <carlos> is just that we are doing some migration testing and I found that the migration from yesterday was still there
[12:11] <carlos> the migration is done, I'm just waiting for the OK of the product maintainer
[12:12] <Yannig> Hello
[12:13] <Yannig> Another dumb question: how is the translation memory organized as far as updating is concerned?
[12:14] <Yannig> Sometimes, I find proposed something I've just translated, great. But it often occurs that something I know I translated weeks ago is not proposed ("yes" or "no" for example)
[12:15] <carlos> Yannig: we only show suggestions that are newer than the translation that is being used
[12:15] <carlos> Yannig: btw, hi :-P
[12:15] <Yannig> Hi carlos :)
[12:16] <Yannig> Yes but I'm just talking about untranslated strings
[12:16] <Yannig> So there should be nothing newer :)
[12:16] <carlos> that's a bug then
[12:17] <Yannig> For example, I'm in front of Thunar translation, string #306, I'm pretty sure "General" was already translated yesterday and nothing proposed
[12:17] <Yannig> (the same for the following one: "Name:"
[12:18] <Yannig> I don't know how to report that kind of bug: I just can't find a rule when it works and when it doesn't :(
[12:18] <carlos> Yannig: https://launchpad.net/products/rosetta/+bug/45196 ?
[12:18] <Ubugtu> Malone bug 45196 in rosetta "Suggestions appear too late" [High,Confirmed]  
[12:19] <Yannig> carlos> Let's see :)
[12:20] <Yannig> But some do appear almost at once (I saw it when I translated simultaneously about-ubuntu and about-kubuntu)
[12:20] <carlos> Yannig: is easy to know if it's that bug
[12:20] <Yannig> But it may be that, I'll have a look at it now
[12:21] <carlos> click over the save & continue button
[12:21] <carlos> without adding any translation
[12:21] <carlos> and return to that page
[12:21] <carlos> if you see the suggestions, is the same problem
[12:21] <Yannig> Fair enough, I'll try this next time :)
[12:21] <carlos> ok ;-)
[12:22] <Yannig> carlos> The same :)
[12:23] <carlos> ok
[12:25] <Yannig> Thanks a lot :)
[12:49] <malcc> stub: Ping
[12:49] <stub> yo
[12:49] <malcc> Hi
[12:49] <sabdfl> malcc: commented on the signed-PPA's thing
[12:49] <malcc> We'd like to rollout to drescher including r3855, which had a database permission change
[12:50] <sabdfl> malcc: main thing that will help us tomorrow is if you have a good visual representation of the Soyuz data model, in detail, showing all tables and columns
[12:53] <malcc> sabdfl: I'll do my best; we might have to settle for a good visual representation showing the main columns, and a messy one we can refer back to for the full column list
[12:53] <sabdfl> ok, thanks
[12:55] <Yannig> And btw, if someone knows how my Karma was multiplied by 10 during my holidays (without any translation from me)... :D
[01:18] <mdke> Yannig: oh yeah, karma seems to have gone up a lot. It is pretty unpredictable
[01:18] <Yannig> Mine or all Karmas?
[01:18] <mdke> all, I think
[01:21] <Yannig> OK
[01:31] <carlos> Yannig, mdke: I guess it's because all my karma was removed
[01:31] <Yannig> carlos> It's not removed: you have more than 600,000
[01:32] <carlos> I think we have a fixed amount of karma to share between users and all my karma was removed, we split it between all accounts
[01:32] <carlos> Yannig: sorry, I'm talking about my karma for translations
[01:33] <Yannig> OK
[01:33] <carlos> I got a bunch of it because some oo.org work
[01:33] <carlos> and we removed it a couple of weeks ago
[01:34] <carlos> Yannig: look at the karma like stock options ;-)
[01:34] <carlos> they change every day up and down
[01:34] <carlos> depending on the 'market' :-)
[01:35] <Yannig> :D
[01:35] <carlos> see you later!
[01:42] <danilos> bzr ate all of my memory getting my system to a crawl, will fix for bug 50290 be in dapper soon?
[01:42] <Ubugtu> Malone bug 50290 in bzr "Creating a branch in a repository chews up huge amounts of memory" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50290
[03:44] <kiko> SURF
[03:44] <kiko> IS
[03:44] <kiko> UP
[03:44] <lucasvo> surf?
[03:45] <kiko> how's it going up north
[03:46] <kiko> hey matsubara 
[03:46] <kiko> how's london
[03:48] <matsubara> hey kiko, sunny day! 
[03:48] <kiko> wow, that's a first :)
[03:48] <mdke> 22 degrees of sunny
[03:54] <jamesh> kiko: "not a very fast box"?
[03:58] <kiko> jamesh, <wink>
[03:58] <kiko> stub!
[03:58] <kiko> how goes it up north
[03:58] <stub> Thrilling as always
[03:58] <kiko> yes london is the edge
[03:59] <kiko> stub, did you manage to finish the bug cleanup?
[03:59] <kiko> oh I see one bug left
[03:59] <kiko> and one source package name
[04:00] <kiko> cool
[04:07] <kiko> stub, is there a way to discover what's holding on to a source package name reference?
[04:09] <jamesh> kiko: we've updated the way the oops summaries group timeout errors
[04:10] <kiko> jamesh, ah, really? tell me
[04:10] <jamesh> kiko: it now groups them by the SQL statement pattern with the highest cumulative runtime
[04:10] <jamesh> kiko: previously it was grouping by exception name/value, which was essentially by the last statement run
[04:10] <jamesh> (which might not have been the problem statement)
[04:10] <kiko> right, that's quite common
[04:10] <kiko> great idea
[04:15] <kiko> stub, ping?
[04:15] <SteveA> kiko: hi
[04:15] <kiko> hello SteveA 
[04:15] <kiko> how's the sun
[04:17] <SteveA> apparently somewhere outside.  it looks nice outside
[04:17] <SteveA> it casts laser-sharp light on the proceedings
[04:18] <kiko> SteveA, does stub not want to talk to me? ;)
[04:18] <SteveA> stub is kinda busy
[04:18] <SteveA> what's up?
[04:18] <kiko> read up
[04:19] <SteveA> summarize
[04:20] <sivang_> re folks
[04:21] <kiko> SteveA, ffs. there's still a bug needing cleaning up.
[04:22] <sivang> flacoste: morning/afternoon :)
[04:22] <flacoste> sivang: morning!
[04:22] <SteveA> kiko: the database package cleanup stuff?
[04:22] <kiko> SteveA, yes.
[04:22] <sivang> flacoste: how are you? 
[04:22] <SteveA> kiko: I'll interrupt stu soon
 oh I see one bug left
 and one source package name
 stub, is there a way to discover what's holding on to a source package name reference?
[04:23] <kiko> SteveA, thanks.
[04:23] <flacoste> sivang: fine, i'm enjoying the speed up brought by my new laptop
[04:23] <sivang> flacoste: oh nice, what kind of a machine is it? (/me has T43p)
[04:25] <flacoste> it is bigger but a lot more performant
[04:25] <sivang> oh, cool. I should also extend to 2G ram, currently I have 1GB it starts to not be enough...
[04:25] <sivang> I just wish I had an nVidia GFX chipset, rathen then ATI
[04:27] <stub> kiko: Getting there
[04:27] <kiko> thanks stub 
[04:34] <sivang> flacoste: so anyways, you've started explaining something to me yesterday, and as you offered, I'm highly interested to hear more, and try to solve at least partially, the bug from yesterday. Hm.., seems salagdo's commment sheds more light on this as a system wide issue..
[04:34] <sivang> malone #4576
[04:34] <Ubugtu> Malone bug 4576 in launchpad "It's not easy to attach a custom error message to a field that uses a Choice widget and a vocabulary" [Medium,Confirmed]  http://launchpad.net/bugs/4576
[04:37] <flacoste> sivang: salgado is right, it is a system wide issue
[04:40] <sivang> flacoste: how hard do you thik it will be to fix it?
[04:42] <flacoste> sivang: it won't be trivial, let's say challenging :-)
[04:42] <kiko> carlos, ping?
[04:42] <carlos> kiko: pong
[04:43] <kiko> carlos, can you explain to me what bug 35631 was about?
[04:43] <Ubugtu> Malone bug 35631 in rosetta "Karma handling on Rosetta is broken" [High,Fix released]  http://launchpad.net/bugs/35631
[04:43] <kiko> the description is very unclear
[04:43] <flacoste> sivang: I think we are already using a custom widget there, that would be the place to fix it
[04:43] <carlos> kiko: that's already fixed ....
[04:43] <kiko> carlos, that's why I said "was" about.
[04:44] <carlos> kiko: hmmm the description is good enough, isn't it?
[04:44] <carlos> in fact that was exactly what I fixed ;-)
[04:44] <kiko> carlos, no, it's not. can you explain what the bug was about?
[04:44] <kiko> and how we fixed it?
[04:44] <carlos> we were giving karma to people that don't have an active launchpad account
[04:44] <kiko> ah.
[04:44] <carlos> and that weren't using launchpad to do translations
[04:45] <flacoste> bradb: ping
[04:45] <sivang> flacoste: I see, could you please direct me to find it's implementation and/or example code where we already did that?
[04:45] <kiko> so now we do not assign karma to people without valid accounts, ever?
[04:45] <bradb> flacoste: pong
[04:45] <carlos> kiko: as a side effect, yes
[04:45] <kiko> carlos, side effect? 
[04:45] <carlos> kiko: we give karma only to people that use rosetta ui or the upload form as a user upload
[04:45] <carlos> and to do that, they should have valid accounts
[04:46] <carlos> so it's a side effect ;-)
[04:46] <flacoste> bradb: what is the widget used to select the source package (in bug task)?
[04:46] <kiko> carlos, ah. so we no longer assign karma for imports, is that it?
[04:46] <kiko> I'm certainly confused
[04:46] <bradb> flacoste: ISinglePopupWidget. your vocab has to implement IHugeVocabulary.
[04:46] <carlos> kiko: we do, but only when the translations are not comming from upstream
[04:47] <carlos> so if someone does an offline translation and uploads it, we give karma
[04:47] <carlos> but the automatic imports doesn't give karma
[04:47] <kiko> carlos, I /still/ don't understand :-(
[04:47] <kiko> either this is very complicated or I am very dull
[04:47] <flacoste> sivang: so the fix should go into canonical.widgets.popup.SinglePopupWidget
[04:48] <carlos> kiko: Is not complicated at all....
[04:48] <carlos> we have two sources for translations:
[04:49] <carlos> - The ones comming from upstream.
[04:49] <flacoste> sivang: you could override the _toFieldValue method (from SingleDataHelper) to raise a subclass of ConversionError instead of the generic one
[04:49] <carlos> - The ones translated using Rosetta (either using the web UI or offline translations and later uploads)
[04:49] <flacoste> sivang: after that, you can define a view for that specific error type which would display the error message
[04:50] <kiko> carlos, what do you mean by "coming from upstream"?
[04:50] <carlos> kiko: dude... do you really know how Rosetta works?
[04:50] <mdke> those upstreams that don't use rosetta
[04:50] <carlos> kiko: I think that's the problem here...
[04:50] <carlos> kiko: any translation that come directly from source tarballs
[04:51] <carlos> and that upstream already has (GNOME, KDE, etc...)
[04:51] <kiko> carlos, oh. well, that's not "upstream" to me.
[04:51] <carlos> the ones that doesn't come from upstream are the ones new that we get from Rosetta users
[04:51] <carlos> kiko: that's upstream to me...
[04:51] <kiko> carlos, surely you mean package imports?
[04:51] <carlos> no
[04:51] <carlos> that's just a small portion of upstream
[04:51] <carlos> well...
[04:52] <carlos> it's a big portion now
[04:52] <kiko> hmmm?
[04:52] <carlos> but shouldn't 
[04:52] <carlos> when we start importing GNOME's CVS/SVN or KDE one
[04:52] <carlos> directly
[04:52] <kiko> do we import any upstream tarballs directly?
[04:52] <kiko> I thought we only imported them via the buildds
[04:52] <carlos> kiko: yes, all products with translations, for instance
[04:52] <kiko> i.e. via packages
[04:53] <carlos> not automatically, but we do such imports
[04:53] <kiko> carlos, oh. where do we pull them from?
[04:53] <carlos> kiko: atm, the maintainer upload them manually
[04:53] <kiko> when the end-user requests an import, you mean?
[04:53] <carlos> right
[04:53] <kiko> hmmm
 - The ones translated using Rosetta (either using the web UI or offline translations and later uploads)
[04:53] <kiko> and that's different from what you wrote there ^ ?
[04:54] <kiko> ah, I think I see
[04:54] <carlos> kiko: when you do an upload
[04:54] <kiko> these people are uploading on a single pofile
[04:54] <carlos> right
[04:54] <carlos> and that they got from Rosetta
[04:54] <carlos> and they update offline
[04:54] <kiko> whereas the maintainer uploads a tarball with multiple pofiles and potemplate.
[04:54] <kiko> I see
[04:54] <carlos> that already have and that will be released with next tarball rollout that they release
[04:55] <kiko> I see
[04:55] <kiko> so I can see more than two ways of getting translations into rosetta, though:
[04:55] <kiko> 1. end-user translates using the web application
[04:55] <kiko> 2. end-user downloads pofile, translates and uploads
[04:56] <kiko> 3. maintainer uploads tarball with template and translations
[04:56] <kiko> 4. buildd assembly generates a tarball with template and translations
[04:56] <kiko> 3 affects only upstream translations and 4 affects only distribution translations
[04:56] <kiko> carlos, is that correct?
[04:56] <carlos> yeah, you can split them that way too
[04:57] <kiko> ok so far.
[04:57] <carlos> 3 and 4 are handled the same way
[04:57] <carlos> 1 and 2 are handled the same way
[04:57] <kiko> well except that they go to different targets.
[04:57] <kiko> so which of those 4 cases assign karma?
[04:57] <carlos> 1 and 2
[04:58] <kiko> I see.
[04:58] <kiko> thanks, I'll update the bug.
[04:58] <carlos> kiko: also, take a look to the doctest 
[04:58] <carlos> I tried to document it
[04:59] <stub> kiko: Email
[04:59] <carlos> and feel free to improve it if you think it's not good enough
[04:59] <carlos> kiko: rosetta-karma.txt
[04:59] <doko> carlos!
[05:00] <carlos> doko: !
[05:00] <carlos> I didn't forget you
[05:00] <carlos> don't worry
[05:00] <carlos> ;-)
[05:00] <carlos> I'm just trying to handle all things I left open before my vacations
[05:01] <kiko> stub, there is still one bug left.
[05:01] <kiko> (as I said above)
[05:01] <kiko> stub, ah, I think I see what happened -- somebody added it since yesterday :-(
[05:01] <stub> Yup
[05:02] <kiko> stub, can you nuke it too?
[05:02] <stub> Yes. As can you I think ;)
[05:03] <kiko> stub, the source package name? 
[05:03] <kiko> I don't have root!
[05:03] <stub> kiko: You are a launchpad admin, no?
[05:03] <stub> It needs to be done though the web ui
[05:03] <kiko> stub, I am, but AFAIK we can't delete source package names
[05:04] <kiko> stub, no, this bug will require a DELETE
[05:04] <stub> So I will need to run that delete statement from the bug (?)
[05:04] <kiko> if you look at it
[05:04] <kiko> yeah
[05:04] <kiko> bug 48263
[05:04] <Ubugtu> Malone bug 48263 in linux-image-2.6.15-23-386 "[regression]  Wired ethernet (VIA VT6102 Rhine II) and Wireless (RaLink 2500) no longer work under 6.06 (needs acpi=noirq blacklisting)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/48263
[05:04] <stub> Yup. One row nuked.
[05:05] <kiko> ROCK ON!
[05:05] <kiko> whew
[05:05] <kiko> only 18 SPNs left to nuke
[05:05] <kiko> stub, you know that query you did that said what tables referenced what?
[05:06] <stub> I suspect I should nuke all the supportcontacts to invalid sourcepackages. yes?
[05:06] <kiko> stub, is that something I can do as well?
[05:06] <kiko> stub, yes.
[05:07] <stub> kiko: https://sodium.ubuntu.com/~andrew/paste/fileJPSRgi.html
[05:08] <kiko> stub, I nuked the ticket link there as well
[05:08] <kiko> stub, so feel free to nuke those contacts
[05:08] <kiko> and then the remaining SPNs
[05:09] <stub> I've nuked the contacts
[05:10] <kiko> stub, and now, just 17 SPNs remaining
[05:11] <kiko> kill those and we can all go home!
[05:11] <malcc> kiko: I hope you mean just 17 bad ones remaining, otherwise Ubuntu just got a lot smaller
[05:11] <stub> kiko: All done
[05:11] <kiko> malcc, oops, NOT THAT BUTTON!
[05:11] <jamesh> that should make it a lot quicker to install
[05:12] <kiko> jamesh, even quicker on those fast boxes you have in australia
[05:12] <kiko> stub, thanks a million, owe you 10 beers
[05:12] <jamesh> kiko: the fast box is in London
[05:12] <kiko> stub, is it possible to produce a database constraint that requires a sourcepackagerelease for a source package name?
[05:13] <kiko> and malcc, cprov-away: would soyuz work if we had something like that?
[05:14] <malcc> kiko: We'd need the constraint deferred until commit time, as you can't have a sourcepackagerelease without a sourcepackagename - we'd get a chicken and egg job
[05:14] <kiko> right. hmmm.
[05:14] <malcc> Do we do deferred constraints in these parts?
[05:15] <stub> I think we can make an INITIALLY DEFERRED foreign key constraint
[05:15] <stub> malcc: Not yet - we haven't needed them yet.
[05:16] <stub> kiko: Please file a bug and assign it to me or it will get lost in the sprint
[05:16] <malcc> stub, kiko: If we have an initally deferred foreign key constraint, I'm pretty sure Soyuz will work; I can't see any reason we'd be creating the spn in a different transaction than the spr
[05:16] <stub> malcc: If we care, the test suite should pick it up anyway ;)
[05:16] <kiko> malcc, there is UI to create standalone SPNs, but that should also go away because it can cause pain (as we've seen).
[05:17] <malcc> kiko: Cool, as a side effect we'll break some UI we don't want :)
[05:17] <sivang> flacoste: thanks, I'll try to combine this explenation with some reading of the code there.
[05:18] <kiko> heh
[05:18] <flacoste> sivang: you'll also need to find a way for client of the widget to customize the error message: that could be an attribute set on the widget on initialization
[05:21] <sivang> flacoste: so the attribute will be used to determine if to react to the error in a webish way (form notification) email , or xml rpc error etc?
[05:22] <flacoste> sivang: no the attribute would be more like the vocabulary description: what values are expected
[05:22] <sivang> flacoste: ah , I see.
[05:23] <flacoste> sivang: otherwise the widget will still be limited to a generic 'Value not in vocabulary' message
[05:24] <sivang> flacoste: ah cool, so that attribute will be set up with the proper error message and each client (bugtask, support etc) will set it accordignly 
[05:24] <flacoste> sivang: yes, something like that
[06:11] <kiko> BjornT, ping?
[06:12] <BjornT> hi kiko 
[06:12] <kiko> how's it going BjornT 
[06:12] <kiko> and what are you up to this week
[06:14] <BjornT> quite good, thanks. currently i'm working on finishing up the bug tags implementation, and if you give the final ok, i was planning to fix bug 30225.
[06:14] <Ubugtu> Malone bug 30225 in malone "Attach files via email" [High,Confirmed]  http://launchpad.net/bugs/30225
[06:15] <salgado> hey kiko! are you going to have some time for that shipit review today?
[06:16] <kiko> BjornT, ah great -- see my email to mpt (about to go out) on the subject of tags then. Sounds good. I just want to make sure we are on track for the upstream bug workflow implementation!
[06:16] <kiko> salgado, in the end of the afternoon possibly
[06:17] <flacoste> salgado: kiko needs to finish my reviews first ;-)
[06:20] <laszlok_work> jordi: ping
[06:21] <BjornT> kiko: ok, i should be able to start doing some work on bug forwarding workflow next week.
[06:23] <kiko> BjornT, cool.
[06:23] <laszlok_work> carlos: ping
[06:24] <kiko> BjornT, read my email -- suggestions in there for tags work! :)
[06:25] <BjornT> kiko-fud: ok, reading it now :)
[06:35] <flacoste> woohoo, running a page test went from 120s to 15s!!!
[07:13] <LarstiQ> flacoste-lunch: nice :)
[07:14] <kiko> flacoste-lunch, how?
[07:19] <carlos> laszlok: pong
[07:39] <flacoste> kiko: how I manage to reduce the pagetest run from 120s to 15s: easy: laptop upgrade!
[07:40] <kiko> heh
[07:49] <bradb> kiko: Will you have a chance to look at the RM UI?
[07:49] <kiko> bradb, yeah, as soon as I catch up with reports)
[07:49] <bradb> ok
[08:16] <flacoste> anyone has an idea why i'm not receiving pqm's replies?
[08:17] <flacoste> my requests get in the queue, but I don't get any reply back once they are out
[08:17] <kiko> hey jamesh 
[08:19] <flacoste> even weirder, if I send a bogus request - i do get a reply back
[08:20] <jamesh> kiko: hi
[08:20] <flacoste> (this seems to exclude a mail communication problem)
[08:20] <jamesh> bradb: looks like mdz tripped over the "include attachment" checkbox
[08:20] <kiko> jamesh, what was the last bug ID we imported from ubuntu?
[08:21] <jamesh> kiko: from the main import, or overall?
[08:22] <kiko> jamesh, from the ubuntu bugzilla import
[08:22] <flacoste> kiko: who is responsible for pqm?
[08:22] <jamesh> we missed a few bugs in the first import and had to import them afterwards
[08:22] <kiko> flacoste, lifeless and stub mainly
[08:22] <stub> lifeless is resposible, I'm irresposible
[08:23] <flacoste> i'll mail robert then
[08:25] <bradb> jamesh: context?
[08:25] <kiko> ddaa, ping?
[08:26] <jamesh> bradb: https://launchpad.net/products/malone/+bug/55698
[08:26] <Ubugtu> Malone bug 55698 in malone "Attachment is silently ignored if description is left blank" [Untriaged,Unconfirmed]  
[08:26] <mdz> jamesh: approximately, though, what's the bug number after which it's a safe assumption that the bug didn't come from bugzilla?
[08:26] <mdz> it's ok if there are a few stragglers
[08:26] <jamesh> kiko: from the look of it, bug 36280
[08:26] <Ubugtu> Malone bug 36280 in gtk+2.0 "gnome-background-properties crashes on selecting a directory to add new file" [Medium,Fix released]  http://launchpad.net/bugs/36280
[08:27] <kiko> jamesh, can you grok what this landing means:
[08:27] <kiko>   [r=BjornT]  importd CVS recheckout preserves Catalog.sqlite
[08:27] <kiko> or BjornT 
[08:27] <jamesh> there are twobugs with higher numbers with ubuntu bugzilla bug watches but they look like they were added manually
[08:28] <jamesh> mdz: so anything higher than 36280 shouldn't be a bugzilla bug
[08:28] <jamesh> (originally)
[08:28] <bradb> jamesh: ah, strange, the cb is auto-checked for me. thanks for the heads up.
[08:29] <jamesh> bradb: it is when the file entry field loses focus, but hitting enter in that field can submit the form
[08:29] <jamesh> bradb: in which case the JS doesn't kick in
[08:30] <jamesh> if the checkbox wasn't there, we wouldn't have a problem :)
[08:30] <kiko> we could ignore the checkbox
[08:30] <kiko> and we could use JS to enable/disable the fields
[08:31] <kiko> jamesh, the problem is that the lack of checkbox can communicate a "you need to fill  these fields in" model to the user.
[08:31] <jamesh> kiko: really?
[08:31] <kiko> jamesh, and we don't really want bogus attachments..
[08:32] <jamesh> kiko: how about using a collapsible field set?
[08:32] <kiko> jamesh, well, yeah. put 4 fields in the for the end-user to fill in and part of the population will feel obligated to fill it in.
[08:32] <kiko> jamesh, that might be a simple solution as well
[08:32] <kiko> perhaps a better one
[08:32] <jamesh> nothing extra sent back to the server, and they'll either see the colleciton of fields together, or none of them at all
[08:32] <kiko> I don't know how well that would work given the fact that we already have a disclosure triangle there
[08:32] <kiko> it's mostly a user perception thing
[08:33] <jamesh> the JS should be able to handle it
[08:33] <kiko> well I mean end-user wise
[08:33] <kiko> two collapsed sections
[08:33] <kiko> where do you put the button?
[08:33] <jamesh> where the field set is currently
[08:34] <kiko> jamesh, the fieldset is currently encapsulated by the expandable area for commenting, though
[08:34] <kiko> my meaning is: will you have nested disclosure triangles? or something else?
[08:36] <bradb> we could also just fix the auto-select behaviour to also select the cb when a filename is manually entered
[08:36] <kiko> bradb, that's easy to do you know
[08:37] <bradb> yeah, i'll fix it now
[08:37] <bradb> unless somebody screams
[08:37] <jamesh> kiko: nested disclosure triangles.
[08:37] <kiko> ah.
[08:37] <kiko> I don't know if I like that very much :-P
[08:37] <kiko> jamesh, did you see my other question above?
[08:37] <kiko>   [r=BjornT]  importd CVS recheckout preserves Catalog.sqlite
[08:38] <kiko> do you know what that was about?
[08:39] <jamesh> kiko: I can guess about it.
[08:39] <kiko> jamesh, oh! please do
[08:40] <jamesh> kiko: cscvs maintains a catalogue of the changesets it has previously imported from the CVS module
[08:40] <kiko> jamesh, okay so far
[08:40] <jamesh> it needs this because CVS doesn't have tree-wide revisions, and due to race conditions you could get different results if you run imports at two different times
[08:40] <jamesh> (if you are doing an import while a checkin is in progress)
[08:41] <kiko> I see.
[08:41] <jamesh> so the catalogue is important when updating the import
[08:41] <kiko> so does this mean that the catalogue is preserved when doing an update, or what is the "recheckout" part there?
[08:42] <jamesh> I guess "recheckout" is something to get a CVS clean working copy, and you want to make sure the cscvs catalogue isn't lost
[08:42] <jamesh> BjornT might be able to give a better answer, since it appears he reviewed it
[08:42] <kiko> yeah, but he's awol and I want to finish this report. thanks!
[08:46] <BjornT> jamesh, kiko: i forgot exactly when you do a 'recheckout', but it could be when the cvs location changes. then you need to checkout the tree again, and you want to make sure that your changeset catalogue remains the same. i'm not sure, though, it was a while since i reviewed that branch.
[08:46] <kiko> BjornT, that's fine. thanks!
[08:47] <solleth> hello
[08:47] <mdz> jamesh: thanks
[08:48] <solleth> hello
[08:48] <solleth> can i request
[08:49] <bradb> mdz: for bug 55698, did you manually type the filename in the field?
[08:49] <kiko> request?
[08:49] <kiko> bradb, no, I think he selected a filename and then just typed enter -- never leaving the field.
[08:51] <bradb> kiko: i can't reproduce what i think you mean. what key sequence are you describing that will reproduce this?
[08:52] <bradb> in epiphany, FF, and Safari, the cb is selected as soon as a choose a file from the File Upload dialog
[08:52] <kiko> bradb, click on button. select file. press enter.
[08:53] <bradb> wfm
[08:53] <kiko> mdz?
[08:59] <mdz> bradb: yes
[08:59] <mdz> I typed it in
[08:59] <bradb> kiko: so, my change fixes the problem mdz describes
[08:59] <kiko> mdz, I don't think typing in the filename ever works on firefox, but ok.
[09:00] <kiko> bradb, so r=kiko, update bug with information.
[09:00] <mdz> kiko: sure it does; I did it the second time too
[09:00] <bradb> kiko: thanks
[09:00] <mdz> type in filename, tab to description(checkbox gets checked here), press enter
[09:00] <mdz> bug #55695
[09:00] <Ubugtu> Malone bug 55695 in linux-source-2.6.17 "BUG when inserting PCMCIA flash adapter" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55695
[09:00] <mdz> attachment seems to have arrived intact
[09:29] <solleth> hallo
[09:29] <sebastienserre> bonsoir ;-)
[09:39] <solleth> can i ask something bro
[09:39] <solleth> please
[09:40] <sebastienserre> bro ?.
[09:40] <sebastienserre> i don't know what its means !
[09:40] <sebastienserre> i'm sory, i'm a newbie here ..
[09:40] <solleth> brother
[09:40] <bradb> sebastienserre: bro == mec
[09:41] <solleth> where i can get linux cd
[09:41] <solleth> for free
[09:42] <bradb> solleth: https://shipit.ubuntu.com/
[09:45] <solleth> wait i see 
[09:45] <solleth> thats for ubuntu 
[09:46] <solleth> i looking for sunOS
[09:46] <solleth> :(
[09:47] <solleth> please help me Bradb
[09:49] <ddaa> kiko: importd does recheckout when
[09:49] <ddaa> changes are detected in the cvs tree (should not ever happen)
[09:49] <kiko> solleth, SunOS is not linux, and you are not in the right channel. 
[09:50] <ddaa> or when the cvsroot changes
[09:50] <ddaa> that fix was prompted by the sourceforge cvsroot mass change
[09:50] <ddaa> although it was needed anyway
[09:51] <ddaa> kiko: do you have enough information now?
[09:51] <solleth> how about suse 
[09:51] <kiko> ddaa, yes.
[09:51] <kiko> solleth, you are in the wrong channel
[09:51] <kiko> solleth, try #suse
[09:51] <solleth> thanks you
[09:51] <ddaa> kiko: that's pretty old stuff, like a couple of months ago
[09:52] <kiko> ddaa, yeah, from june.
[09:52] <kiko> jamesh, tell me about this formlib-based-launchpadformview?
[09:53] <bradb> that sounds like a hint that we should start using formlib
[09:53] <kiko> heh
[09:55] <ddaa> kiko: in short, that patch was needed to preserve correctness when a cvs repo we are importing from migrates
[09:55] <kiko> ddaa, understood. I fudget the line a bit but you might find it interesting even so
[09:55] <ddaa> I always read the highlights and the Bazaar section of your report with great interest
[09:56] <ddaa> as I expect it's the primary source of information about launchpad progress for sabdfl
[09:56] <ddaa> and other top mgmt
[09:57] <kiko> ddaa, one thing that would be a major help to me would be slightly more end-user-oriented merge messages
[09:57] <kiko> I know how you feel about large ones
[09:57] <ddaa> I dislike long ones on multiple lines
[09:57] <ddaa> on a single line, I mean
[09:57] <kiko> but it really would help to have an idea of what the end-user could expect from that landing -- or just text that made it easier for me to add it to the report
[09:58] <ddaa> yeah, I guess i should look at sending multi-line commit messages to pqm
[09:59] <kiko> it will help me and you'll end up with better feedback as a result
[09:59] <ddaa> kiko: but more often than not, in my work, it's hard to give a short summary of what the patch does to the user
[10:00] <ddaa> I'll try to think of you the next time I use pqm-submit
[10:02] <kiko> thanks
[10:22] <jamesh> kiko: the c/l/doc/launchpadform.txt file describes how to use the new form
[10:22] <kiko> jamesh, is this rearranging form layout as well?
[10:23] <jamesh> kiko: it can be used in pretty much all cases GeneralFormView is being used, and can replace the edit and add form views
[10:23] <jamesh> kiko: we haven't changed the appearance of the forms
[10:24] <kiko> jamesh, ohhhh. what about the FormLayout spec?
[10:26] <jamesh> kiko: I think that kind of thing will be addressed later
[10:26] <flacoste> jamesh: what's the advantage for using LaunchpadViewForm over formlib directly?
[10:27] <jamesh> kiko: there are plans to use new widgets eventually
[10:27] <jamesh> flacoste: it fits in with our existing view base class
[10:27] <kiko> jamesh, that spec was to do with the layout of fields on the form.. 
[10:28] <jamesh> flacoste: you can look at formlib as a construction kit for implementing view classes + a few sample view classes
[10:29] <jamesh> flacoste: LaunchpadFormView is just integrating formlib with LaunchpadView, and make it not too difficult to migrate existing code over
[10:29] <flacoste> jamesh: yes, but I don't see how the LaunchpadViewForm simplify things over formlib
[10:29] <jamesh> flacoste: also, it should make it possible to add some interesting features to all forms later on
[10:29] <flacoste> jamesh: ok, migration seems a valid point
[10:30] <jamesh> e.g. on-the-fly validation
[10:31] <jamesh> kiko: sure.  The stuff I landed is mainly infrastructure, so hasn't addressed the FormLayout spec yet.
[10:31] <kiko> yeah.
[10:31] <flacoste> jamesh: what would be on-the-fly validation? there is already automatic validation in formlib
[10:31] <jamesh> flacoste: validation without hitting the submit button
[10:31] <flacoste> jamesh: that would nice!
[10:35] <BjornT> flacoste: one thing to consider also, is that we'll probably move away from the current formlib some time, in order to switch to a better widget framework. that will be much easier to do if all code uses the same base class.
[10:44] <jamesh> kiko: for what it is worth, the new form base class does let you customise the submit button text
[10:45] <jamesh> or easily handle multiple submit buttons
[10:46] <laszlok> carlos: ping
[10:47] <salgado> jamesh, is it possible to disable some of these submit buttons conditionally?
[10:47] <kiko> jamesh, and does it fix the tab ordering as well?
[10:49] <jamesh> kiko: not in the initial landing. The sketch in the FormLayout spec is close to what I was considering
[10:52] <kiko> jamesh, ah, ok.
[10:55] <flacoste> salgado: should be, that is part of formlib: you can put a condition on every button
[10:56] <salgado> flacoste, hmmm. I asked because the buttons are created with a decorator, so I was wondering how to do it
[10:56] <flacoste> salgado: @form.action(_('Label'), condition='name_of_condition_method')
[10:57] <salgado> ah, cool!
[10:57] <flacoste> salgado: other keywords are 'success' (method to invoke when the validation succeeded), 'failure' (method to invoke when the validation failed) and 'validate' (custom validation method)
[10:58] <flacoste> salgado: beware though that there is a bug with the 'failure' parameter: you can't use a method name, you have to pass the reference directly
[10:58] <flacoste> flacoste: that is zope issue 573
[10:59] <salgado> only with the failure parameter? weird...
[10:59] <jamesh> flacoste: we're using @action() directly, so that should work fine here.
[10:59] <jamesh> the condition bit, that is
[11:00] <flacoste> salgado: it's because of the parameters required by the failure handler, that issue is fixed in 3.3.0b1 and 3.2.1
[11:02] <flacoste> salgado: there is a little gotcha with the condition, it is invoked before validation and as such it not only remove the action from rendering, it also prevents the action from being considered as submitted
[11:07] <flacoste> bradb: does IBugTarget.searchTasks uniquefy its results based on bugs? or should the client do that?
[11:08] <flacoste> bradb: I mean, if I do a text search and there are multiple bug tasks on the same bug will all bug tasks be returned?
[11:08] <bradb> flacoste: yes
[11:09] <bradb> kiko: https://chinstrap.canonical.com/~bradb/upstream_status.png
[11:09] <kiko> bradb, checkboxes?
[11:09] <flacoste> bradb: is there an existing way to just get the bugs?
[11:09] <kiko> flacoste, yes, all bug tasks will be returned, but it is likely that you want that anyway.
[11:10] <kiko> flacoste, I mean, the bug doesn't have a lot of interesting information attached to it.
[11:10] <bradb> flacoste: no. why do you want just bugs?
[11:10] <bradb> kiko: yeah, i think cb's might be easier to understand
[11:10] <flacoste> kiko, bradb: IBugLinkTarget links to bugs not bugtasks, so no reason to present the same bug multiple time in the selection list
[11:11] <bradb> kiko: and more flexible
[11:11] <kiko> bradb, s/that have been/already/ ?
[11:12] <bradb> kiko: right. maybe just "Show bugs fixed upstream" and "Show bugs not reported as affecting upstream" too?
[11:13] <bradb> not report as, or not know to
[11:13] <bradb> not known to
[11:13] <kiko> bradb, yeah, maybe less text will be less daunting
[11:13] <kiko> (I find those options long!)
[11:13] <bradb> me too
[11:14] <kiko> bradb, have an idea for a person whose account is not enabled yet?
[11:14] <kiko> maybe an empty or faint outline of our regular ninja icon?
[11:14] <bradb> kiko: an idea for what aspect of that problem?
[11:15] <kiko> bradb, I would like a special icon to indicate somebody who doesn't have an active account
[11:15] <kiko> essentially
[11:15] <kiko> the main issue is that that person will not get emailed
[11:15] <matsubara> what's the ninja icon?
[11:15] <kiko> so maybe an email with a slash icon
[11:15] <kiko> matsubara, our current person icn
[11:15] <matsubara> the little guy without eyes?
[11:16] <kiko> yeah.
[11:16] <kiko> ninjas have no eyes
[11:16] <bradb> right, that's hard to communicate in an icon
[11:17] <flacoste> bradb: is ILaunchBag.user the right thing to pass as user parameter to BugTaskSearchParams? i.e. is it None when the user not logged in?
[11:18] <bradb> kiko: https://chinstrap.canonical.com/~bradb/upstream_status.png
[11:19] <bradb> flacoste: docstrings dude! :)
[11:19] <bradb>       user is an object that provides IPerson, and represents the
[11:19] <bradb>       person performing the query (which is important to know for, for
[11:19] <bradb>       example, privacy-aware results.) If user is None, the search
[11:19] <bradb>       will be filtered to only consider public bugs.
[11:20] <bradb> flacoste: and it's a required arg, to ensure you don't accidentally forget it
[11:20] <flacoste> bradb: my question was more about: is ILaunchpad.user = None when the user isn't logged in
[11:20] <bradb> flacoste: in a view, you should pass self.user
[11:21] <flacoste> bradb: thnx, that answers my question
[11:22] <bradb> np
[11:46] <lifeless> flacoste: 'devpad.canonical.com' please, not 'devpad'
[11:47] <flacoste> lifeless: yes, i changed that and it worked. but why didn't i get any message?
[11:48] <lifeless> you tripped an unhandled exception, which I've added to my to-handle list
[11:49] <flacoste> lifeless: nice to know :-) also do you think it would be possible for PQM to send in the reply the revision number that was commited with the merge?
[11:50] <lifeless> please do
[11:50] <flacoste> lifeless: in bazaar or launchpad?
[11:50] <lifeless> are you subscribed to the commits list ?
[11:50] <lifeless> pqm has its own product 'pqm'
[11:50] <flacoste> lifeless: there is a commit list?
[11:51] <lifeless> heck yes
[11:53] <lifeless> arch-commits@l.c.c