[12:01] it means "fire in the hole" more or less and it's an inside joke with the sandwich sprinters [12:01] though you were absent from that dinner, when we went to the indian place IIRC and had red-hot curry. [12:02] SteveA actually knows how to pronounce it. [12:36] sabdfl: yes I branched for the production update last night. [12:36] lifeless: ok, pity, quite a lot of useful stuff went in this morning. [12:36] i'm going to have to check the production server to make sure justdave can get going as intended [12:37] any database changes? [12:37] hmm... no i don't think so [12:37] if there are no database changes, I can just merge the lot across. [12:37] (after breakfast :)) [12:37] lifeless: ok, but we'll need to run some tests again [12:38] btw, we have a shithot script we're working on which will autopopulate project / product with freshmeat / sourceforge data [12:38] I thought you didn't want to do that ? [12:39] sabdfl: there are database changes. I'm going to need to cherry pick the updates. [12:40] or do another full update with stub. [12:40] lifeless: it works quite well, and we can clean it up over time [12:40] good. I don't know if you recall, but I was pro this in Oxford. [12:41] ok, i've come around [12:41] yay [12:42] i'd still like a human review of it, so i think we should add a state field to the db, and at least know which ones we've looked at and which not [12:44] thanks ddaa [12:47] does the production server have a url yet? [12:48] kiko: you're welcome pal [01:06] tal experts? [01:06] is there any way to set multiple attributes in a single element using tal:attributes? [01:08] sure [01:09] tal:attributes="href http://foo.com; title Foo Project" [01:09] thanks [02:18] ddaa, don't you think annotation is a valid part of an rcs frontend? [02:18] kiko: thats a loaded question [02:19] thankfully my wrists hurt [02:19] It would certainly by useful, and not complex in the multiple-commiter archive case. [02:19] sabdfl: there were only 4 unmerged patches, I've cherry picked two. (yours and mine) into production [02:19] I can code update whenever you like [02:19] it's significantly more tricky to get right in a distributed development environment. [02:20] kiko: whats the use case that you want to solve - 'being able to run annotate' is not a use case. [02:20] ddaa: thanks for merge that in [02:21] testing it on importd-test now. [02:21] lifeless: I'm not kiko, but it seems that a common use case is "figuring out what the hell this stuff does here". [02:21] ddaa: for annotate ? [02:21] lifeless: great, I was expecting I'd have to do it myself tomorrow. [02:22] lifeless: yes, that's what I think is a common use case for annotate. [02:22] ddaa: your next task should you choose to accept it, is to start working through the info files and testing them, in parallel with proposing more ProjectProduct mappings from the same files. [02:22] only worry about ones with CVS or SVN repositories at this point. [02:22] lifeless, yes. [02:23] lifeless: hu... so I'll need to get the test buildbot up and running anyway. [02:23] ddaa: yes indeedy. [02:23] the latest launchpad & the latest database work fine for me. [02:23] but keep your local hacks handy :( [02:23] :) [02:23] lifeless, ddaa has a very reasonable point. and to be honest, browsing an annotated version of the file is, in itself, a valid use case. just want to see how much of a file has been changed by others, for instance. [02:23] So, my task is to pick e.g. zlib and try to import it, and check the changelog to see whether they look half sane? === kiko uses annotation *every* day on local projects [02:24] ddaa: https://wiki.canonical.com/CscvsChecking [02:24] lifeless: define latest? what local hacks are you talking of? [02:25] didn't you tweak your install slightly for buildbot ? [02:25] latest - in rocketfuel now. [02:25] I mean, latest devel or latest production? [02:25] latest devel [02:25] latest production is (of course) good too. [02:25] see the production-2 config in rocketfuel dists. [02:27] ddaa: yes, the order is : put zlib mapping on the wiki page for sabdfl/I to ok. test zlib in buildbot import + sync in your local repo. then we put it into production. [02:29] Mh... I'll look at it tomorrow. [02:29] we're aiming for 5 into production each day. [02:29] Expect me to come and harass you quite a bit until I get started. [02:30] do so - this is our top priority [02:30] ETA? [02:30] for what [02:30] for bulk imports [02:30] thats what we are doing [02:30] started 3 weeks back [02:31] what is the expected date of completion? [02:31] target is 120 by the release of ubuntu. [02:31] I think we are going to miss that by a mile, but the closer we come the better. [02:36] so far so good [02:36] much better than the crack you had before. [02:36] thank you === lifeless goes to do a little housework whie those 3 test runs run. [02:37] sabdfl: https://www.warthogs.hbd.com/ProjectProductSetup [02:37] sabdfl: still has a huge number not seconded [02:37] And I've much much more to come that I'm waiting for the non-seconded bit to shrink first. [02:45] wtf [02:45] cvs [checkout aborted] : Could not map memory to RCS archive /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c,v: No such file or directory [02:46] ls /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils\@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c\,v [02:46] /srv/importdtest/botslave/buildbot-jobs/coreutils-HEAD-import.job/coreutils@arch.ubuntu.com/coreutils--MAIN--0/cvs_temp_repo/coreutils/lib/offtostr.c,v [02:46] chinstrap does weird-ass shit sometimes. [02:51] ack [02:51] mmap()ing rcs archives is failing? [02:53] not in general. [02:53] that a cvs error fwiw === ddaa [~ddaa@nemesis.xlii.org] has left #launchpad [] === justdave [~justdave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad [08:08] lifeless: I don't think the database schema patches made last night are required for anything that needs rolling out now === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === BradB|Expo is now known as BradB === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:00] lunchpad! === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === Kinnison hugs his star-merge tool [10:20] Kinnison: sabdfl : elmo_ : Can we make the Soyuz Pages Walk-through today, asap ? === Kinnison nods. I guess sabdfl will have to get it another time [10:24] Kinnison: i'm ready when you guys are, the production update went ahead yesterday [10:24] okay; cool [10:24] stub, lifeless: production update all squared away? things I need: === Kinnison is without email today until his home adsl comes back alive [10:25] - ability to create projects and products through the doap interface (works on my system) [10:26] - ability to regiser sources through the doap interface (works on my system) [10:26] Kinnison: fine, so in 10 minutes ? [10:26] - ability to register bug trackers through doap AND malone system (both work here) [10:26] plus whatever you need, of course [10:26] cprov: fine by me. Elmo? sabdfl? [10:26] wfm [10:27] yeah, 'tever [10:36] cprov: Should we head over to you; or will you come to the table? [11:06] stub: ping [11:09] Can we not use _columns to define properties of SQLObject classes? Pretty please? :) === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [11:15] BradB: I don't care much either way. :) [11:16] (I somewhat like the segregation of SQLObject magic and normal attributes/methods, but then our use of e.g. MultipleJoin breaks that anyway...) [11:17] Is there any reason why we don't have the =tagging-method mark .rej files as unrecognised, so that it's harder to accidentallly commit unresolved conflicts? [11:20] SteveA: pong [11:20] BradB: I'd already started migrating ;) [11:21] There is a Style in SQLBase to make it easier === stub reboots [11:21] The SQLObjectGuide on the wiki should probably be updated to reflect that.. [11:21] My Kernel is spinning ;-/ === BradB removes the _columns' from the content classes he's in the middle of writing for infestation === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [11:52] spiv: I'll do that. === BradB todo.append's [12:06] lifeless: ping? [12:15] BradB: Do you think we want to capture when the bugassignment changed, too? [12:20] stub: underscore in "name" columns? [12:20] no dash? [12:20] Dash and undescore too (I thought I said that?) [12:20] [a-z0-9._] , [12:21] that's what your email says [12:21] and, why at least one non a-z digit? [12:21] stub: Maybe, but maybe not yet. [12:21] oh, one non-digit [12:22] okay [12:22] also, they need + don't they? [12:22] gtk+ ? [12:22] but no "+" at the start [12:22] SteveA: Yer - avoid namespace conflicts [12:22] there is a package name that has all digits [12:22] SteveA: At the moment, '+' isn't allowed. I think I need to add that [12:23] SteveA: No numbers-only to avoid namespace conflicts between the numeric id and the name. [12:23] so, realistically, we need [a-z0-9] [a-z0-9.-+] * [12:23] there is a package name that has all digits [12:23] SteveA: So do we change the package name or risk problems down the track? [12:24] I don't see a need for _. Do you? [12:24] We can't change the package name [12:24] that would mean we can't do soyuz / malone / doap for debian [12:24] we can't go around telling debian to change on account of us [12:25] We can ask - it sounded like the debian folk didn't like the idea of an all-numeric package name either [12:25] for numeric ids, we can say something like "+id1234" in urls if necessary [12:25] I'll ask james... [12:26] I don't, but it's allowed by policy and there are existent examples [12:26] so as Steve said, we can't try to enforce a policy on Debian [12:26] we really should comply with the written debian policies [12:27] it is, after all, our Rock [12:27] Ok - but if some nutcase wants non-ASCII in their package name they can get stuffed. [12:27] yes [12:27] we wave the debian package policy at them [12:28] and then politely give them the finger [12:28] Malone requires names don't conflict with id's because you can traverse on either, so the Bug.name will need a special rule. [12:28] I can't call my package "ff"? [12:29] who sets a Bug.name ? [12:29] There is actually a Debian written policy on package name to wave? That allowed all numeric [12:29] where does it come from? [12:29] ? [12:29] yes, there is [12:29] it is linked to the wiki page on tis [12:29] SteveA: Anybody who wants to give a bug a nickname [12:29] ok, that's fine then [12:29] so, a bug's nickname can't start with a number [12:29] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package [12:30] that's binary packages [12:30] Oh - it can start with a number. Just can't be all numbers ;) [12:30] daf: For the same reason I'm not allowed to call mine [12:31] stub: see https://wiki.canonical.com/WebAppProcess [12:31] Kinnison: bah! ASCII fascists! === Kinnison nods [12:31] daf: tree hugging hippy [12:31] censorship! [12:31] stub: search for "debian" in that page [12:31] stub: that lists the rules for url segments / names [12:31] daf: Blame the twonks who forgot to specify encoding in HTTP ;) [12:32] stub: and URLs === stub meant that [12:32] stub: please either stick to the rules on that page, or change the rules on that page [12:33] [12:33] It will follow these conventions: [12:33] 1. [12:33] It will consist of only lowercase letters [a-z] , digits [0-9] , the period[.] , the minus sign [-] and the plus sign [+] . [12:33] Yer - I can read ;) [12:33] 2. [12:33] It will be at least two characters in length. [12:33] 3. [12:33] It will start with either a lowercase letter [a-z] or a digit [0-9] . [12:33] 4. [12:33] It will be unique within some defined space, see the table definitions for details. For example, look for UNIQUE ( project, name ) which would tell you that the name of that item is unique for all projects. [12:34] [12:34] (that was for the benefit of the channel logs) === fabbione [~fabbione@port1845.ds1-khk.adsl.cybercity.dk] has joined #launchpad [12:35] stub: on the cookies problem... any idea how much time it would take to implement decently encrypted cookies, without the need for sessions, in exUF ? [12:35] You can't [12:35] stub: http://www.w3.org/International/O-URL-and-ident -- woo! [12:36] Oh... hangong [12:38] Assuming a descent encryption library is available, an hour or two. [12:39] You just have to find the bit where it sets the cookie and make it set it to crypt(pw) instead, and the bit where it retrieves the cookie and make it do decrypt(pw). [12:39] daf: do you know if lalo left already? should we reassign his bugs? [12:39] carlos: I don't know [12:39] carlos: I was expecting to see him around more this week [12:39] stub: hmm... know of any readily available libraries where we can use a big salt? === fabbione [~fabbione@port1845.ds1-khk.adsl.cybercity.dk] has left #launchpad [] [12:40] SteveA: Not a one way crypt - needs to be two way like rotor. There are python crypto libraries around but I haven't looked into them, [12:41] I think they have AES implementations which would be fine. [12:41] Heck - XOR with the secret would probably be fine. === carlos is going to leave for a while [12:50] stub: depends how secure you want it to be [12:51] stub: We don't need that BugInfestationType table. [12:52] Ta. Almost got that one done before I got distracted by name constraints ;) [12:54] daf: no it doesn't [12:54] daf: this is a one time pad [12:54] with a salt [12:55] oh, I see [01:02] BradB: Do we drop the infestation column too on ProductBugInfestation? [01:04] BradB: oic. Just leave it as an int for dbschema.py to validate [01:11] stub: jabber? [01:11] sometime or other [01:20] Brad - can you live without an official patch to create your requested tables? I've got something urgent to do for Steve. [01:22] I'm working with the mods made locally already. I won't commit anything, of course, until there's an official patch, but I won't be ready to commit anything for a couple of hours I think anyway. [01:23] So yes, I can live without an official patch. ;) [01:23] (for now :) === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad === jdub [~jdub@home.waugh.id.au] has joined #launchpad [01:33] DEBIAN IS OUR ROCK! === jdub [~jdub@home.waugh.id.au] has left #launchpad [] [02:02] Bug 2073 resolved: James Troup(elmo) as Soyuz Tester/Guide [02:02] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2073 === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [02:10] morning pret people [02:18] pizza people today [02:20] wow! [02:21] brad says: "What has 'bilabong' to do with australia?" [02:22] "billabong" [02:22] I mistranscribed [02:30] New bug 2090 for Launchpad/Soyuz: Add Brad's nickname.py lib and CreatePerson() method to FOAF [02:30] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2090 [02:31] cprov, kicking bz's ass :) [02:37] How to I import a tarball into arch? === stub found the answer over 4 different pages of the docs [02:47] you init a tree; unpack the tarball; add the files and dirs; check tla tree-lint is happy; and then to tla import [02:48] (approx) [02:51] New bug 2091 for Launchpad/Soyuz: Create a Soyuz QA branch [02:51] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2091 [02:54] kiko: yep, last day = good results :) [02:55] heh [02:55] wow [02:56] dilys: don't you like it ? btw, I'll try to create not so ugly pages :) [02:57] dilys is one phat chick [03:30] stub: around? [03:31] yo [03:31] Do you want comments when I give schema changes? [03:31] I.E. SQL comments [03:32] gah; I.E. SQL 'COMMENT' commands [03:35] Yes please. Sometime after rollout I'm going to want the entire thing commented (for my benefit if not others - I still don't know what half the tables are supposed to represent :-/ ) [03:39] Okay. [03:54] New bug 2094 for Launchpad/Soyuz: Change to queries inside Soyuz App Components to the properly SQLObject [03:54] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2094 [04:02] New bug 2095 for Launchpad/Soyuz: Use Sourcepackage() instead of SoyuzSourcepage() [04:02] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2095 [04:04] dilys: you "bug broadcast" :) [04:10] dilys: what is tcpwatch (on lp/utilities) for ? === Kinnison wonders why cprov is talking to a bit [04:10] erm, a bot [04:11] cprov: oopps === cprov kicks XCHAT again [04:12] daf: what is tcpwatch (on lp/utilities) for ? [04:12] stub: any chance we can have those lucille DBA requests done soon? [04:15] They are in aren't they? [04:15] maybe I'm missing a star-merge or two [04:15] stub: and I've just posted another one anyway :-) [04:15] database/schema/patch-3-01-0.sql [04:17] cprov, LOL [04:21] stub: aah yes; although that's missing an index on the id column for sourcepackagepublishing :-( [04:21] stub: did I forget to ask for that? === BradB remembers one of the stated goals of Z3 to not require users (i.e. developers) to know the entire framework to be able to use little bits of it. Heh heh. Heh. [04:22] BradB, that assumes users inhabit Jim's mind [04:22] Perhaps "users" was defined as "rocket scientists on their coffee break." [04:23] rocket scientists don't drink coffee. they drink rocketfuel. [04:24] heh [04:24] cprov: it's part of a fish^Wfunctional doctesting framework we're introducing [04:25] daf: tks [04:25] I'll write some documentation for it soon [04:25] daf: great [04:26] New bug 2096 for Launchpad/Launchpad: Schema class needed by Person class but it's not in place [04:26] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2096 === limi [~limi@sparkit.easynet.no] has joined #launchpad [04:32] seems I have a PQM merge failure for my last commit - is there a quick way to compare what I have in my repository with what is at rocketfuel? [04:33] limi: tla star-merge will bring the conflicts to your local tree [04:33] ok [04:34] and they you have lovely .orig and .rej files to play with :) [04:34] and is there then a command to see them, or do I have to hunt for .orig and .rej files? [04:34] tla tree-lint -b will list orig/rej files [04:34] but orig/rej still sucks [04:34] aha, thanks [04:34] limi: pay attention to 'C' infront of files :) [04:34] heh, yes [04:34] limi: do you have a merge tool? [04:35] FileMerge from Apple should work [04:35] limi: if you do, you can "tla get" rocketfuel, and then use a standard merge tool to fix the files that conflict [04:35] I think the PQM error message should say which files conflict [04:35] hm, ok [04:35] I find it easier to use vimdiff than stare at orig/rej files [04:35] anyway, will have to fix it later - on my way home [04:36] see you later [04:36] daf: it does actually says , doesn't it ? [04:36] cprov: the PQM error message? [04:36] daf: yep [04:36] cprov: I can't remember :) [04:37] daf: since last week I'm not receiving success/failure from my PQM requests, I'm doing it in a BLIND way :) [04:37] ! [04:37] mysterious email lossage? [04:37] [04:38] spiv: quite [04:38] Guh.. [04:38] daf: but as far as I can remember, yes , that messages comes with the files state if failure [04:38] spiv: heya ! [04:38] cprov: Hello. [04:39] Is there any reason why we don't have the =tagging-method mark .rej files as unrecognised, so that it's harder to accidentallly commit unresolved conflicts? [04:40] spiv: when will you be able to move the people branch of Soyuz to FOAF ? [04:41] spiv: unrecognized .rej on arch ? nice !!! how ? [04:42] cprov: change {arch}/=tagging-method, but before I blindly do so, I'd like one of our arch gurus to tell me it's a sane thing to do :) [04:43] jblack/ddaa/lifeless: ^ === ddaa is here [04:44] spiv: ddaa : so ?! [04:44] Sounds useful, but you might have surprises. [04:45] tla treats .orig and .rej files a bit specially. [04:45] ddaa: do you know why could be that I cannot use gnome-gpg when creating a new branch with tla? [04:45] Like moving them to "++ignored-conflicts" or something when they get in the way. [04:45] I figure there's probably a good reason why it's not like this by default :) [04:45] ddaa: gnome-gpg is a gnome front end to gpg [04:46] and it fails to connect with X [04:46] ddaa: get in the way of what? another conflict? [04:46] carlos: I am using gnome-gpg right now in my signing rules... [04:46] ddaa: it also works here, except with tla tag [04:46] spiv: I think that's all, yes. But I cannot be positive. [04:47] carlos: just to be sure, you did tell --no-tty? [04:47] nope [04:47] should I? [04:48] I do, it avoids weird things that might happen when spawning gpg from tla. [04:48] ddaa: Ok, sounds like its less surprising than finding you accidentally committed without resolving a conflict. [04:49] spiv: the point is that if you do multiple merges, (e.g. with replay) you might still miss conflicts. [04:49] ddaa: gnome-gpg --default-key 60F957D7 --clearsign --no-tty? [04:49] and the additional confidence might me dangerous. [04:49] ddaa! [04:49] ddaa: But that could happen right now anyway. [04:49] ddaa: And our typical use-cases by far are single merges. [04:50] carlos: yup, that's what I do (except I do not specify the key). [04:50] I appreciate that might not be true for all projects held in arch, but it is true of launchpad. [04:50] ddaa: ok [04:50] So, moving the .rej pattern from backup to unrecognized sounds something reasonable to do. [04:50] Hmm, would marking ++ignored-conflicts as unrecognised work? [04:50] next branch will tell me if that helps :-) [04:50] Nope. [04:50] ddaa: thanks [04:50] Or is that too evil? :) [04:51] spiv: ++* is hardwired precious, and ,,* is hardwired junk. [04:51] ddaa: is there a way to have conflicting files left intact? [04:51] Drat. [04:51] daf: none that I am aware of. [04:51] Ok, well I'll mark .rej/.orig as unrecognised, anyway. [04:51] ddaa: Thanks [04:51] ddaa: e.g. rather than foo{,.rej,.orig}, foo{.mine,.other} [04:52] ddaa: I tink that would make resolving conflicts much easier for me [04:53] daf: I understand, that was thoroughly discussed on gau. A patch in that direction would very probably be accepted easily. [04:54] That's a hook for custom merge tools. [04:54] daf: in the meantime --three-way is your friend. [04:54] ah, good [04:54] --three-way? [04:54] star-merge -H [04:54] sounds like good fun [04:54] use diff3 for merging [04:55] interesting [04:55] a la CVS conflict markers [04:55] It is reputed to be broken though. [04:55] oh [04:55] are you sure it's my friend? [04:55] daf: the reason why it is broken are quite subtle. [04:56] I have found a test case where it seems to do the wrong thing, but I'm not too sure. [04:56] ok, so should I trust it or not? :) [04:56] There is also the fact that it will cause star-merge to ignore changes which seem have been already applied. [04:57] daf: If you cannot use emacs diff mode, or something vim equivalent, and what something nice to fix conflicts, it's your friend. [04:57] I can use vimdiff [04:57] which I like [04:57] but [04:58] I want to be able to use meld to solve tla conflicts [04:58] But you have to be aware it's no magic and needs to me eyeballed. [04:58] meld is cool [04:58] I have to explicitly get the tree I want to merge with in order to get pristine versions of the files I want to merge with [04:58] Kinnison: ++ [04:58] ddaa: ?? [04:58] Kinnison: meld is cool [04:58] yet I'm addicted to emacs diff and ediff modes. [04:59] ediff confuses me [04:59] Emacs sucks, but everything else sucks more :-) [05:01] daf: I understand your problem, and it is valid. There's no easy way to solve it. Look for "custom merge" "diff3" "xml diff" threads in the archive, you should be able to find the relevant data somewhere in the noise. [05:02] But if somebody implements an option, like "star-merge --external-merge" or something, it will probably be easily accepted. [05:02] Mhh... I guess that's also something that might be done in FAI. [05:02] ooops [05:02] RAW [05:02] Heh. [05:03] what does FAI expand to? "forget about it" ? [05:03] fai has already reimplemented it's merge operator. Once you have implemented the star-merge algorithm (finding the common parent) it's trivial to do what you want. Sounds like something we could put in RAW. [05:03] stevea: fully automated installation [05:03] erm; or not [05:03] Friendly Arch Interface. === Kinnison wishes his fingers waited for contact [05:04] s/contact/context/ === Kinnison sighs [05:04] It's looking for a non-conflicting name, though... [05:04] ddaa: FAI is a massively overloaded acronym [05:05] daf: probably you should bring your request to lifeless/scott/bob2. [05:06] FAI is an MOA === Kinnison causes bradb acronym-related pain === ddaa hands a penalty card to BradB === Kinnison subscribes BradB to the AAAAA list. [05:07] "Ouch! You hit me right in the acronym!" [05:07] ARP is a real PITA FYI [05:08] Kinnison: Association des Amateur d'Andouillette Auvergnate Authentique? [05:08] non [05:08] ben oui [05:08]