[12:08] <tolgam> ok ! I found it !
[12:08] <tolgam> sorry :p
[01:32] <lifeless> pqm is back
[01:59] <dilys> Merge to devel/launchpad/: [r=jamesh]  reformat all bug listings to a two-column layout. reformat the advanced search and move it to a separate page. (r3202: Brad Bollenbach)
[02:46] <tambaqui> #privmsg
[03:01] <mpt_> Goooooooooooooooood afternoon Launchpadders!
[03:02] <cprov> mpt_: morning
[03:02] <mpt_> cprov, why are you awake? :-)
[03:03] <cprov> mpt: working on AU TZ, with infinity
[03:15] <mpt> ah
[03:17] <cprov> mpt: not that I have a horrible insomnia or something like that ;)
[03:21] <stub> So did neither of you want a 30 hour flight to visit the other in person? Or just not worth doing the trip for a short period.
[03:24] <cprov> stub: uhm .. I'd prefer some nights at office than 30 hour flight and yes, it canbe done with these short (2 days) sprints
[03:25] <cprov> we are trying, let's see
[04:59] <mpt> lifeless, ping
[05:04] <mpt> bzr: ERROR: Error in processing weave: inconsistent texts for version<EMAIL_ADDRESS>when joining weaves
[05:05] <dilys> Merge to devel/launchpad/: [trivial]  Fixes bug 5555 (add branch form has confusing english). (r3203: Matthew Paul Thomas)
[05:17] <irvin> hi all! one quick question... how does rosetta handle merges for translations, e.g., user A downloads the .po, user B uses rosetta to translate then user A uploads the .po later.. will the work done by user B be overwritten?
[05:22] <mpt> irvin, I *think* it's "last person to upload a translation wins"
[05:22] <mpt> so B's work will be overwritten only if A made translations of the same string
[05:23] <mpt> For a more definite answer, you'll need to ask carlos or jordi when they're around in about 8 hours time.
[05:23] <irvin> ok
[05:24] <irvin> hmm... methinks loco groups need to organize translation work so we don
[05:24] <irvin> bummer... we don't overwrite someone else's work
[05:25] <lifeless> mpt: #bzr for that sort of thing please
[05:26] <mpt> ok
[07:57] <cprov> stub: what about the rollout today ? target to r3200 ?
[08:03] <stub> cprov: Yes. r3200
[08:08] <cprov> stub: when are you planning to switch ?
[08:08] <stub> whenever. Should we do it now?
[08:09] <cprov> mdke: hi, did you confirm the fix og bug # 32721 ?
[08:09] <cprov> stub: uhm, if you can wait, let's half hour, would be fine
[08:10] <stub> Sure.
[08:13] <cprov> stub: fine, thanks
[08:23] <Mez> hmm
[08:23] <Mez> is something fscked up ?
[08:24] <Mez> Reinstallation of katapult is not possible, it cannot be downloaded.
[08:25] <sabdfl> hey launchpadders
[08:25] <sabdfl> stub: to create the database, has the process changed since i moved on from lp hacking?
[08:25] <sabdfl> cd database/schema; make
[08:25] <sabdfl> ?
[08:25] <sabdfl> psql:trusted.sql:15: ERROR:  syntax error at or near "$" at character 156
[08:25] <sabdfl> this is with pg 7.4, have we moved on?
[08:26] <stub> sabdfl: We have moved on
[08:26] <sabdfl> 8.0? 8.1?
[08:26] <stub> sabdfl: You need 8.0
[08:26] <stub> (I havn't tested 8.1 yet - next on my agenda)
[08:26] <sabdfl> hmm... the lp dependencies do not appear to have been updated
[08:27] <stub> Do you have both 7.4 and 8.0 installed? You might just need some configuration changes to make 8.0 the default
[08:27] <Mez> morning mark
[08:27] <Mez> long time no speak
[08:27] <sabdfl> odd, i can't find the lp-dependencies package
[08:27] <sabdfl> hey Mez!
[08:28] <Mez> sabdfl, you're no longer LP hacking? what are you up to now then ?
[08:28] <sabdfl> Mez: playing albatross and free software advocate
[08:29] <Mez> sabdfl, albatross?
[08:29] <sabdfl> flying long bloody distances eating fish
[08:30] <sabdfl> and other weird things that come mostly from the sea
[08:30] <Mez> ah - but fish is gooed for your health :D
[08:30] <sabdfl> 'tis certainly goooey sometimes
[08:31] <Mez> lovely...
[08:31] <Mez> the furthest I stretch is haddock and chips
[08:34] <Mez> Mark: will you be appearing at LRL again this year?
[08:36] <sabdfl> Mez: hopefully but the dates aren't so good
[08:36] <sabdfl> stub: worked a treat, thanks, DatabaseSetup is spot on
[08:37] <Mez> sabdfl: same with jdub, well if you're there I'll say hi
[08:37] <Mez> if not I'll stick to annoying^Whelping Riddell
[08:38] <sabdfl> ok. am trying to make it. helicopter may be required >:-)
[08:39] <cprov> stub: soyuz in place for rollout, ping me before start, need to stop cron(s)
[08:39] <stub> sabdfl: Elmo mentioned you wanted some benchmarks of Launchpad running on the new hardware. I'm not 100% sure if you were interestde in Launchpad, the  database backend, or both being benchmarked. And also what to compare it against (staging isn't terribly useful due to the single CPU and little RAM, and production will require downtime)
[08:40] <Mez> sabdfl: lol - that'd be rather cool :D lol - I'd love a "ride" lol - havent been in a helicopter for ages
[08:40] <Mez> actually last time was my 18th birthday
[08:40] <Mez> lol
[08:41] <sabdfl> Mez: where are you based
[08:41] <Mez> sabdfl, Birmingham
[08:41] <sabdfl> oh, bollocks, stub it died
[08:42] <stub> ?
[08:42] <sabdfl> what's the rsync option to delete local files that don't exist on the server?
[08:42] <sabdfl> i have a messed up LP from rsyncing badly
[08:42] <sabdfl> so i have patch-25-foo and patch-40-foo
[08:42] <stub> rsync -a --delete-after
[08:49] <mdke> cprov, yeah the package came through yesterday, thanks!
[08:51] <cprov> mdke: very good, thank you for the precise feedback.
[08:53] <mdke> cprov, np, thanks for fixing it so quick
[08:54] <cprov> mdke: no problem from this side too
[09:04] <dilys> Merge to devel/launchpad/: [trivial]  Fixes bug 1647 (Product series vs. branches confusion in menu), and adds permissions to product menu (r3204: Matthew Paul Thomas)
[09:04] <stub> cprov: Ok if I schedule the shutdown for 15 mins time?
[09:06] <cprov> stub: ok, will switch things off now
[09:08] <stub> Launchpad is going down in 15 minutes time, which will also put the wikis into read only mode. Estimated down time is 10 minutes.
[09:11] <carlos> morning
[09:14] <cprov> carlos: morning dude
[09:14] <carlos> cprov: hi
[09:17] <jordi> hi dudes
[09:33] <stub> cprov: all done. You can restart the soyuz stuff.
[09:35] <cprov> stub: okay, thanks
[10:16] <dilys> Merge to devel/launchpad/: [trivial]  Librarian config updates (r3205: Stuart Bishop)
[10:28] <ddaa> Good morning.
[10:33] <LarstiQ> moin ddaa
[10:44] <dilys> Merge to devel/launchpad/: [trivial]  Makes bug listing CSS consistent with the rest of Launchpad (r3206: Matthew Paul Thomas)
[11:17] <jordi> carlos: ok, so things are developing pretty quickly here.
[11:17] <jordi> carlos: it looks like I'll be all week there.
[11:17] <jordi> can't confirm yet
[11:18] <carlos> jordi: ok
[11:18] <carlos> jordi: you should confirm it as soon as possible to get plane tickets and hotel...
[11:18] <jordi> I know
[11:18] <jordi> I'm on it
[11:20] <slomo_> cprov: pong... yes i already noticed it, sorry... anyway, i'll just upload the next version 1.0.6 in some hours
[11:23] <cprov> slomo_: don't need to be sorry, It's normal, just in case you didn't get the error concept.
[11:25] <slomo_> cprov: ok, thanks for telling me :)
[11:46] <Keybuk> There are 1  problems with the information you entered.   TELL ME!
[11:46] <Keybuk> that's like
[11:46] <Keybuk> "An error occurred. [ OK ] "
[11:46] <Keybuk> "Please fix the error. [ OK ] "
[11:47] <Keybuk> TELL ME WHAT THE ERROR IS, THEN!
[11:48] <Kamion> lp_archive@drescher:~$ python /srv/launchpad.net/codelines/current/scripts/ftpmaster-tools/change-override.py -c universe gtk-sharp-gapi
[11:48] <Kamion> that's hanging; strace shows it's stuck in poll()
[11:48] <Kamion> can anyone help?
[11:50] <BjornT> Keybuk: which page is that?
[11:50] <Keybuk> BjornT: on the +editstatus page
[11:52] <BjornT> Keybuk: right, that's bug 3683.
[11:52] <Ubugtu> malone bug 3683 in malone "Input validation error reported, but problem not indicated" [Normal,Confirmed]  http://launchpad.net/bugs/3683
[11:53] <Keybuk> why isn't it fixed? :)
[11:53] <Keybuk> it was filed months ago
[11:58] <BjornT> good question :) i'll talk with matsubara about it later, it's actually quite easy to fix.
[11:58] <Kamion> ah, there, it finally got out of bed
[12:10] <Kamion> https://launchpad.net/products/launchpad-upload-and-queue/+filebug
[12:10] <Kamion> "Launchpad Upload and Queue system does not use Malone as its bug tracker."
[12:10] <Kamion> I would just like to say "!"
[12:11] <BjornT> Kamion: fixed now
[12:12] <Kamion> ah, thanks, I was just about to file a bug
[12:14] <daf> carlos: yo
[12:14] <carlos> daf: hi
[12:15] <daf> qu tal?
[12:16] <carlos> bien, gracias
[12:16] <BjornT> the problem is that you can specify whether a product uses malone or not, but previously we didn't use that information, expect for displaying it in a tiny portlet, so people usually didn't bother specifying it. now we've started to use that information, so you can't file bugs on products that don't use malone.
[12:16] <carlos> daf: working on the import queue :-)
[12:16] <daf> qu haces hoy?
[12:16] <daf> veo
[12:17] <daf> y despus?
[12:18] <daf> (siguiente?)
[12:18] <carlos> daf: I think it's going to take my whole day
[12:18] <carlos> daf: anyway, I need to do some minor changes for the #1881 fix after steve's answer so that's what I want  to finish later
[12:19] <carlos> s/answer/review/
[12:19] <daf> est cerca completo, no?
[12:19] <carlos> si
[12:19] <daf> gracias
[12:20] <carlos> daf: do you need anything else?
[12:21] <daf> luego, pregunto sobre las OOPS Rosetta
[12:21] <daf> pero ahora, nada
[12:21] <carlos> daf: ok
[12:23] <BjornT> daf: could you please change so that dilys uses malone officially? https://launchpad.net/products/dilys/+launchpad
[12:26] <daf> ciertamente
[12:27] <daf> acabado
[12:53] <carlos> daf: it's better to say 'hecho' than 'acabado'
[12:54] <daf> porqu? :)
[12:57] <daf> stub: https://launchpad.net/distros/ubuntu/+bug/30442 -- it's Fix Committed; presumably the fix has been released by now
[12:57] <Ubugtu> malone bug 30442 in launchpad "Timeout error on +specs page" [Normal,Fix committed]
[12:58] <daf> same for https://launchpad.net/products/launchpad/+bug/30306
[12:58] <Ubugtu> malone bug 30306 in launchpad "Emblems should be inheritable" [Wishlist,Fix committed]
[12:58] <daf> spiv: around?
[01:02] <carlos> daf: it sounds better :-)
[01:02] <ddaa> duh... you know your code is nearing maturing when you start getting lost in your own test suite
[01:03] <daf> carlos: heh, ok
[01:03] <sabdfl> mpt: ping
[01:07] <sabdfl> stub: what's the process to publish code for review now?
[01:07] <sabdfl> push a branch to a particular place? register it for review?
[01:08] <slomo_> hi... tomboy is showed as "failed to build" although it built fine and the buildlog even says "Built successfully"
[01:09] <Kinnison> slomo_: url to build log?
[01:09] <stub> sabdfl: Review queues are at https://wiki.launchpad.canonical.com/PendingReviews . Stick it under General or whichever reviewer you think is best for your code.
[01:09] <slomo_> Kinnison: https://launchpad.net/distros/ubuntu/dapper/+source/tomboy/0.3.5-0ubuntu1
[01:09] <slomo_> Kinnison: http://librarian.launchpad.net/1598329/buildlog_ubuntu-dapper-i386.tomboy_0.3.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:09] <slomo_> Kinnison: http://librarian.launchpad.net/1598337/buildlog_ubuntu-dapper-amd64.tomboy_0.3.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:10] <stub> sabdfl: The branch you reference should be one you have pushed to your area on chinstrap
[01:11] <slomo_> Kinnison: the same for other packages... for example http://librarian.launchpad.net/1598157/buildlog_ubuntu-dapper-powerpc.gaim_1%3A1.5.0%2B1.5.1cvs20051015-1ubuntu4_FAILEDTOBUILD.txt.gz
[01:11] <Kinnison> slomo_: woah woah, one at a time dude
[01:12] <Kinnison> 2006/02/28 12:05 GMT [-]  Iterating with success flag 3 against stage SBUILD
[01:12] <Kinnison> interesting
[01:12] <siretart> http://librarian.launchpad.net/1598354/buildlog_ubuntu-dapper-i386.gdm_<IP_ADDRESS>-0ubuntu1_FAILEDTOBUILD.txt.gz this one as well
[01:13] <Kinnison> I think this is a bug in the recently rolled out slave package
[01:14] <Kinnison> Infinity recently changed the buildd slave software
[01:15] <carlos> stub: hi, around ?
[01:20] <sabdfl> stub: bzr push to chinstrap looks like its going to take a very long time
[01:20] <sabdfl> is there a faster way?
[01:23] <Kinnison> sabdfl: You're using rsync?
[01:25] <sabdfl> Kinnison: bzr push sftp...
[01:25] <Kinnison> sabdfl: use rsync
[01:25] <daf> if you do cp -a rocketfuel/launchpad/devel sabdfl/launchpad/<branchname> on chinstrap, then bzr push --overwrite, that caqn speed it up
[01:25] <Kinnison> it's less "correct" but it's way faster
[01:26] <daf> (push --overwrite just invokes rsync IIRC)
[01:26] <sabdfl> oh, that's pretty cool
[01:26] <sabdfl> thanks daf, Kinnison
[01:26] <Kinnison> daf: only if the push target is formatted right, and you have bzrtools installed
[01:26] <Kinnison> you do
[01:26] <Kinnison> do the cp
[01:26] <Kinnison> then do bzr push chinstrap:/home/warthogs/archives/......
[01:27] <daf> Kinnison: oh, that's a bit icky
[01:27] <daf> I only use the host:path syntax because it's faster to type :)
[01:27] <Kinnison> it's also the rsync format
[01:28] <daf> well, I'm sure bzr will Do The Right Thing in the long term
[01:29] <Kinnison> probably
[01:41] <ddaa> according to lifeless, knit should land within a week
[01:42] <ddaa> this is the new archive format that enables faster pulls and pushes
[01:42] <daf> ooh
[01:42] <daf> does that include pipelining?
[01:42] <ddaa> also, shared repositories should not be very far anymore, which makes it even less of an issue
[01:43] <ddaa> daf: I do not think so. Pipelining is a different sort of issue.
[01:43] <daf> I can't see how the archive format will help the first-time push, though
[01:43] <ddaa> right
[01:43] <daf> but the repository stuff will help that, I imagine
[01:44] <sabdfl> daf: shared storage means your first time push can be just the delta from some existing branch, iirc
[01:44] <ddaa> anyhow, even with pipelining, you can only push stuff so fast... launchpad is large, and most of us have relatively little uplink,.
[01:45] <daf> sabdfl: yeah, that will rock
[01:45] <ddaa> it's actually something Arch supported all along ;)
[01:45] <daf> what's Arch?
[01:46] <sabdfl> should do, though i'm curious how on earth bzr will know where the storage is shared, if you are working locally as well as pushing to a supermirror, say
[01:46] <ddaa> AIUI, a branch will hold the URL of its repository
[01:46] <ddaa> or have a self-contained repository
[01:47] <ddaa> then, there is nothing magical about sharedness, it's just that the repo will turn out to already contain data...
[01:48] <ddaa> The specifics of how the repository URL is assigned to the branch still eludes me (I cannot keep up with the mailing list).
[01:48] <sabdfl> daf: should this push be pushing a working directory as well?
[01:48] <sabdfl> and should it have deleted a bunch of stuff?
[01:49] <daf> I'm pretty sure it doesn't need to push the working copy
[01:49] <daf> so, it's a bug
[01:50] <carlos> daf: the rsync method does it, the sftp one doesn't
[01:50] <daf> fixing it is presumably a matter of getting it to invoke rsync more intelligently
[01:50] <daf> carlos: ok, so a bzrtools bug
[01:51] <carlos> daf: I think it's not a bug but I'm not sure, you need to check with lifeless. I remember that he talked already about that but I don't remember the details
[01:58] <sabdfl> carlos: is sftp smart if you push to an existing repo?
[01:58] <daf> yes, it only pushes new revisions
[01:58] <carlos> daf: but it's still slow
[01:59] <daf> right, hence the move to knits
[02:08] <Kinnison> slomo_: the buildds ahve been updated and the failed builds given back to be retried
[02:08] <slomo_> Kinnison: thanks
[02:10] <slomo_> Kinnison: which builds did you give back? all failed since the last buildd update?
[02:11] <Kinnison> yes
[02:11] <Kinnison> 52 to be exact
[02:11] <slomo_> uh... that's much :) thanks again
[02:50] <stub> carlos: yes
[02:50] <carlos> stub: hi
[02:50] <carlos> stub: I'm working on a patch that is going to add new DB fields to one table and remove some fields from another one
[02:51] <carlos> I need to migrate the data stored on the fields that I'm going to remove into the new fields I'm going to add
[02:51] <sabdfl> carlos: which table is that on?
[02:51] <carlos> and I don't know how to handle that so the migration script can use sqlobject to do it
[02:52] <carlos> sabdfl: From POFile and POTemplate to TranslationImportEntry
[02:52] <carlos> stub: I cannot drop the old fields until the migration script is executed
[02:52] <stub> carlos: ideally it would just be an SQL script.
[02:52] <carlos> stub: ok
[02:53] <carlos> Will try to do it that way then. I was not sure if there is any kind of policy about it
[02:53] <stub> If you need to use SQLObject for the migration, you nede to add the columns in your patch but don't drop the old columns. Dropping the old columns needs to wait until the next rollout, and a different patch.
[02:54] <carlos> stub: ok, that's what I thought. I will try to do it using SQL sentences
[02:54] <stub> I can help formulate the patch as SQL though if it is proving difficult.
[02:54] <carlos> stub: Hmmm, I think it should be doable, I will ping you if I get blocked on it. Thanks
[02:55] <stub> SQL patches can work on sets of rows, rather than one row at a time, so tend to be faster which is now getting to be important.
[02:57] <carlos> see you later
[03:41] <ddaa> mh? What a pleasant feeling to make a test pass, and then think: "so next... hu... it's done"
[03:42] <ddaa> ha no, I still need to do an integration test :)
[04:01] <sabdfl> what timezone is mpt in at the moment?
[04:13] <sabdfl> elmo: ping
[04:29] <jamesh> bradb: did the ability to use an alternative sort order in bug listings get lost with your patch?
[04:31] <bradb> It's temporarily disappeared from the UI, but bookmarks should still work. I intend to add it back as column-click, per kiko's recommendation, and assuming that we're able to show a reasonable number of bugs per page.
[04:32] <bradb> It should be in before rollout, hopefully.
[04:33] <dilys> Merge to devel/launchpad/: [trivial]  Remove dangling symlink (r3207: Stuart Bishop)
[04:33] <daf> r3200 was rolled out; r3202 was the buglist patch
[04:34] <bradb> yeah
[04:35] <bradb> so by next Tuesday the CC sorting should be working in production
[04:35] <jamesh> yay
[04:36] <jamesh> then we can have people argue about whether an up arrow or a down arrow indicates ascending sort
[04:37] <bradb> i'll bring the paint brushes
[04:38] <LarstiQ> jamesh: ugh
[04:38] <jamesh> I was mildly surprised to find that not everyone uses the same direction
[04:40] <LarstiQ> both viewpoints are valid, but I usually don't bother anyway, just look at how the data is sorted
[04:50] <koke> why are there two "Spanish" fields at https://launchpad.net/distros/ubuntu/dapper/+source/nautilus/+pots/nautilus/es/+translate?show=untranslated ??
[05:15] <ddaa> yay! baz2bzr working!
[05:16] <ddaa> daf: spiv: the ball is on your side now
[05:17] <daf> hooray
[05:18] <ddaa> daf: in particular, I am now looking at a superb oops on a productseries index page
[05:18] <ddaa> daf: you know what I mean :)
[05:19] <ddaa> daf: also, my branch depends on the database patch that's in optional-branch-title
[05:19] <ddaa> daf: so, if I can do anything to help you land both fixes, it's the right time to ask
[05:21] <daf> hmm, let's see
[05:21] <daf> o-b-t is merge-conditional
[05:21] <daf> I didn't get around to the productseries fix yesterday
[05:25] <ddaa> daf: unless you say "please do FOO" they are still both yours to land.
[05:25] <ddaa> I still have (less urgent) stuff to keep me busy
[05:29] <daf> ok, swapped o-b-t in
[05:29] <daf> what's left:
[05:29] <daf> get the DB patch blessed
[05:29] <daf> stub: ping
[05:30] <daf> don't allow setting the URL is the URL is None
[05:30] <stub> daf: pong
[05:30] <ddaa> stub: dba pee requested
[05:31] <ddaa> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/daf/launchpad/optional-branch-title/full-diff
[05:31] <daf> what ddaa said
[05:33] <stub> ddaa: approved. patch-40-24-0.sql
[05:33] <daf> thanks stub
[05:34] <ddaa> daf: I know nothing about hacking forms
[05:34] <daf> ddaa: #32117 looks like it should be simple enough
[05:34] <ddaa> Ubugtu: bug 32117
[05:34] <Ubugtu> malone bug 32117 in launchpad "Template productseries-hctstatus-core.pt is wrongly calling getPackageName" [Normal,Confirmed]  http://launchpad.net/bugs/32117
[05:34] <daf> I'd just like to make sure that this portlet is still actually useful
[05:35] <ddaa> it's not used as a portlet
[05:35] <daf> oh, right
[05:35] <daf> anyhow, it might be a case of codectomy rather than fixing it
[05:36] <ddaa> mh... I guess maybe we should ask Keybuk. He should know what is still relevent...
[05:37] <ddaa> that's totally relevent
[05:37] <ddaa> the naming just sucks
[05:37] <ddaa> it's the bit that displays the rcs-imports details on the productseries page
[05:37] <sabdfl> gee whiskers, the whole product series menu system is totally screwed
[05:37] <ddaa> s/menu system //
[05:38] <sabdfl> but, fixed in a branch
[05:38] <ddaa> productseries things are wrong in so many way it's not funny, at all
[05:39] <ddaa> but getting better, slowly
[05:40] <jouston> Hello
[05:41] <jouston> I've got some usage model problem on Launchpad, where can I get help?
[05:41] <daf>
[05:41] <jouston> daf: !
[05:41] <daf> you can ask questions here
[05:41] <jouston> daf: Why you know I can speak Chinese?
[05:42] <daf> telepathy :)
[05:42] <ddaa> daf: please do the form thing on o-b-t. Also, do not forget to rm database/optional-branch-title.sql before merging (it's a script to update the sample data)
[05:43] <ddaa> I think I can deal with the productseries.branch thing
[05:43] <daf> ok, sure
[05:43] <daf> by rm, don't you mean mv?
[05:43] <ddaa> I mean rm
[05:43] <ddaa> there are two sql patches
[05:43] <ddaa> the one stub just approved, that needs to mv'ed
[05:44] <jouston> I am main translator for jpilot. I suppose launchpad will have the most updated translation for zh-TW locale.
[05:44] <daf> right
[05:44] <jouston> But no.
[05:44] <ddaa> and database/optional-branch-title.sql which is a sampledata patch.
[05:44] <jouston> Then I upload my newest po to lauchpad, but nothing happened.
[05:44] <ddaa> daf: I will have to make it depend on o-b-t, so please, please make it land FAST.
[05:44] <daf> jouston: we are currently in the process of updating our translations from Dapper
[05:44] <jouston> How can I do now?
[05:45] <daf> however, importing a PO file should have worked
[05:45] <jouston> the version between mine and po in dapper is not 100% the same.
[05:45] <daf> when did you upload?
[05:46] <jouston> daf: last night I think.
[05:46] <daf> that should be enough time
[05:46] <jouston> daf: https://launchpad.net/distros/ubuntu/dapper/+source/jpilot/+pots/jpilot/zh_TW/+upload
[05:46] <jouston> daf: I use this URL to upload.
[05:46] <daf> that looks good
[05:47] <jouston> daf: I upload twice I think. Not only once.
[05:47] <daf> that shouldn't be a problem
[05:47] <daf> carlos: any idea what might have happened?
[05:47] <jouston> daf: should I merge my work into dapper's PO then upload it or just upload?
[05:47] <sabdfl> is stevea around?
[05:47] <daf> Steve is at Pycon
[05:48] <daf> he was around intermittently yesterday
[05:48] <daf> but hasn't been today
[05:48] <sabdfl> ok
[05:48] <daf> the brazilians are at carnaval
[05:48] <daf> or recovering from it; not sure wihch
[05:51] <carlos> daf: Seems like there are some files that need manual review from a Rosetta Expert even when uploaded directly to an specific POFile
[05:51] <daf> bug?
[05:51] <carlos> daf: yes
[05:52] <daf> can you file it?
[05:52] <ddaa> daf: also, you'll have to merge with rocketfuel, there's a trivial conflict with o-b-t in product.zcml
[05:52] <carlos> daf: and as we don't have access to the import queue, we cannot handle it atm...
[05:52] <daf> ddaa: I need to do that for the psycopg changes anyway
[05:52] <carlos> jouston: it should be imported in the next two days, sorry about that
[05:52] <daf> carlos: fix that queue!
[05:52] <jouston> carlos: No problem.
[05:53] <AlinuxOS> carlos, buenas dias bro :)
[05:53] <carlos> AlinuxOS: buenos dias!
[05:53] <carlos> daf: doing that atm!
[05:53] <ddaa> daf: DOIT (please! SteveA is going to do me very unpleasant thing if bzr imports are not up next week)
[05:54] <AlinuxOS> ;)
[05:54] <daf> ddaa: DOINIT
[05:55] <daf> carlos: how's it going?
[05:55] <dilys> Merge to devel/launchpad/: [trivial]  allow for more concise +bugs search URLs, by not requiring the 'search' parameter (r3208: Brad Bollenbach)
[05:55] <carlos> daf: all db changes done fixing now the UI form
[05:55] <daf> carlos: great
[05:56] <daf> carlos: let's aim to get it cherrypicked tomorrow
[05:56] <carlos> daf: I have pending the migration script. I'm not completely sure how to do it. I will send later an email to stub to get some help for it
[05:57] <daf> stub offered to help earlier
[05:57] <daf> don't be afraid to delegate
[05:58] <carlos> daf: I know, that's why I'm going to ask him for help :-D
[05:58] <daf> stub: still awake?
[06:04] <jouston> hello abelcheung_
[06:05] <sabdfl> anybody feel very familiar with the menu system and willing to answer a few tricky questions?
[06:06] <abelcheung_> jouston: hello, I'm sending you message in #ubuntu-tw
[06:07] <jouston> abelcheung_: I saw your msg. But you point out a great topic to discuss.
[06:09] <abelcheung_> jouston: I'm not sure if rosetta people really plan to upload translations in rosetta to upstream at all
[06:10] <daf> sabdfl: I can try
[06:10] <sabdfl> daf: cool, thanks
[06:10] <sabdfl> i'm working on the spec listings
[06:10] <daf> abelcheung_: we cannot upload translations to upstream, because there isn't a standard way to submit translations back upstream
[06:11] <sabdfl> i want to have a flag that can be toggled, determining whether or not specs that are completed will be displayed
[06:12] <sabdfl> so the url could look like .../sabdfl/+specs?show=all&category=feedback
[06:12] <abelcheung_> daf: yes, and translators are starting to be confused, which one should be done in rosetta, and which one should be submitted upstrewam
[06:12] <sabdfl> i know how to make a menu item conditional
[06:12] <sabdfl> what i don't know is if I can do some work in the __init__ of the menu, to determine the current state of those flags and set things up so the individual menu items can point to the right URL's
[06:12] <daf> but not how to make the link conditional?
[06:13] <daf> yeah, I see
[06:13] <carlos> abelcheung_: by default, all translations must be sent upstream unless upstream is using Rosetta directly
[06:13] <sabdfl> sometimes, the thing should be ...show=all, and sometimes it should not have the show piece
[06:13] <sabdfl> so i can toggle between them
[06:13] <carlos> abelcheung_: the product overview notes if a product is not using Rosetta directly
[06:14] <daf> sabdfl: I imagine you can set an instance variable in __init__
[06:14] <abelcheung_> carlos: yes, however the point is: almost no newcomers know this fact, they think their work will be used upstream too
[06:14] <carlos> abelcheung_: Anyway, the problem is complex and any idea/suggestion to improve it is welcomed
[06:14] <daf> sabdfl: then have each menu link method look at it in order to work out whether to include the show parameter in the link or not
[06:15] <sabdfl> daf: that's what i planned, i just didn't want to do that work only to find there's some zope utility madness going on...
[06:15] <abelcheung_> carlos: highlighting which product is directly using rosetta can be a bit of improvement.... that's the immediate idea I can come up with
[06:15] <carlos> abelcheung_: that's why we changed our import policy to import only the products that upstream agreed to fetch translations from Rosetta
[06:15] <jordi> carlos: si tere any way I can (reasonably) work on the queue this week?
[06:15] <carlos> jordi: I'm trying to have it fixed tomorrow
[06:15] <abelcheung_> carlos: I'll be coming to localization sprint, so we can discuss about it more at that time
[06:16] <jordi> carlos: oh cool
[06:16] <daf> sabdfl: I'm guessing, but I'd think that the menus are instantiated once per request
[06:16] <jordi> carlos: you plan to cherrypick it?
[06:16] <carlos> jordi: it will depend on a code review and database migration so I suppose you will not be able to use it until Thursday
[06:16] <sabdfl> daf: ok, will go ahead and see if this can work
[06:16] <daf> sabdfl: it's Steve who'd know for sure
[06:16] <carlos> jordi: yes, it's a critical thing
[06:16] <jordi> Thursday. That's better than Teusday ;)
[06:16] <carlos> abelcheung_: sure!
[06:16] <daf> abelcheung_: cool
[06:16] <jordi> carlos: I have 3 new language team requests, so it's ok.
[06:16] <jordi> hey abelcheung
[06:17] <carlos> abelcheung_: I'm not sure if I will be for the whole sprint but I will be around at least a couple of days
[06:17] <jordi> abelcheung_: oh, you'll be in London?
[06:17] <jordi> cool, it's very possible that we'll meet
[06:17] <abelcheung_> jordi: yes, I'm coming, it's great oppotunity to see you guys
[06:19] <daf> ddaa: interesting -- this merge from RF moves +addbranch to the overview facet
[06:19] <ddaa> daf: looks like...
[06:19] <ddaa> I guess it's a patch by mpt or something
[06:20] <ddaa> daf: is that a problem?
[06:20] <ddaa> daf: oh, it makes sense, since the action is visible in the overview menu...
[06:21] <ddaa> but also in the code menu...
[06:21] <ddaa> *shrug*
[06:21] <carlos> Is there anyway to render the String value of a DBSchema item?
[06:22] <carlos> so instead of the number, we show the defined name
[06:25] <daf> item.title, IIRC
[06:26] <ddaa> stub: are you sure it's a good idea to shut off the buildbot deprecation warnings?
[06:27] <ddaa> I mean, I like it to remind everyone that we are running straight into a wall with this old code base...
[06:28] <stub> ddaa: It was screwing up the test suite. I don't see how we are going to hit a wall if we never update - it would just mean we need to keep an obsolete revision of twisted around for it.
[06:29] <ddaa> stub: for example because other bits of launchpad will need a newer twisted
[06:29] <ddaa> the sftp server needs SVN twisted.
[06:29] <carlos> daf: yeah, I just found it. Thanks!
[06:29] <stub> ddaa: Sure. So we might need two or more revisions of twisted if nobody ever updates or replaces buildbot.
[06:30] <ddaa> hooo, kay...
[06:31] <ddaa> fine. Anyway, drowning it like the spawn of the devil that it is, is one of my big wishes.
[06:31] <ddaa> i'd just need a large sink of holy water
[06:34] <daf> ddaa: ah, this uses the editform stuff
[06:35] <ddaa> hu? it uses some magic form generation stuff, is all I know.
[06:36] <daf> BjornT: I want the user to be able to edit SomeContentClass.someattribute only if someattribute is not None
[06:36] <daf> BjornT: the +edit page used launchpad_editform
[06:40] <BjornT> daf: with our current security framework, it's not easy to do what you want. the easiest way is to handle it it the handle it in the view class, if someattribute is not None, don't render an edit widget for it.
[06:41] <daf> ok, how do I do that?
[06:41] <BjornT> which view class does the page use?
[06:41] <daf> class BranchEditView(SQLObjectEditView):
[06:41] <daf>     def changed(self):
[06:41] <daf>         self.request.response.redirect(canonical_url(self.context))
[06:41] <daf> ^^^ that one
[06:42] <BjornT> ok, so you could something like:
[06:42] <BjornT> def __init__(self, context, request):
[06:43] <BjornT>   self.fieldNames = list(self.fieldNames)
[06:43] <BjornT>   self.fieldNames.remove('someattribute')
[06:43] <BjornT>   SQLObjectEditView.__init__(self, context, request)
[06:43] <daf> how will self.fieldNames be initialised there?
[06:44] <daf> there == "self.fieldNames = list(self.fieldNames)"
[06:44] <BjornT> it will be initialized via ZCML. that's why you shouldn't operate on self.fieldNames directly, since it will be shared by different instances of the class.
[06:45] <daf> oh, right, magic
[06:45] <daf> that will take care of not showing the field on the form
[06:45] <daf> what will happen if the user submits a url= parameter?
[06:46] <daf> will it be ignored, or will an error happen, or will it be set?
[06:46] <BjornT> it will be ignored, since no widget will be set up to handle the url parameter
[06:47] <daf> excellent
[06:47] <daf> that's just what I need, thanks
[06:51] <daf> hasta luego
[07:01] <unstable> product series is fine, use that name
[07:01] <daf> it is not merely a problem of name
[07:07] <ddaa> it's a problem of unowned code
[07:08] <ddaa> that has drifted on the eddys on launchpad for months
[07:13] <sabdfl> does bzr have the equivalent of baz's message format for commit messages?
[07:13] <sabdfl> i have a lot of changes in one commit and want to give a detailed message
[07:13] <sabdfl> unstable: thanks
[07:13] <ddaa> sure you can write a multi-line commit message
[07:14] <ddaa> just "bzr commit" and it will spawn an $EDITOR
[07:14] <sabdfl> ok, thanks
[07:14] <sabdfl> and do the tools handle that?
[07:14] <sabdfl> is the first line special?
[07:14] <ddaa> by convention, the first line is displayed when a short log display is desired
[07:14] <ddaa> it's not more special than that AFAIK
[07:15] <sabdfl> cool, that's sane, thanks
[07:20] <unstable> sabdfl: thanks?
[07:27] <sabdfl> unstable: for letting us know that the name is not too bad :-)
[07:29] <G0SUB> where can I get hold of some rosetta admins?
[07:29] <SteveA> hello G0SUB.  what's up?
[07:29] <G0SUB> SteveA hello!
[07:30] <G0SUB> I need to get my translation team registered as the official bengali translation team
[07:30] <SteveA> the best way to sort all that out is to mail the rosetta-users list
[07:30] <SteveA> the rosetta admins read that and respond quickly
[07:30] <G0SUB> I have mailed<EMAIL_ADDRESS>... no reponse yet
[07:31] <SteveA> ok.  tell me your email address and the subject line of the email you sent in a private message, and i'll ask the rosetta admins to answer it soon
[07:31] <G0SUB> okay :)
[07:41] <bradb> BjornT: How much longer will you be around? I might have a question for you about the fix for bug 29176 and subscribers in about 10-15 mins.
[07:41] <Ubugtu> malone bug 29176 in malone "Changing source package doesn't notify the new bug contact about the change" [Normal,In progress]  http://launchpad.net/bugs/29176
[07:43] <BjornT> bradb: i'll be around for at least 2 more hours
[07:43] <bradb> ok, cool
[07:49] <alexey__> hi all !
[07:49] <alexey__> I have heard about Rosetta from the KDE FOSDEM website
[07:49] <alexey__> and it look revolutionary translation tool
[07:54] <mdke> alexey__, yes, it's great
[07:56] <alexey__> agreed, but why it's associated with Ubuntu ?
[07:57] <alexey__> Rosetta is revolutionary for *all* software ! Free or not.
[07:57] <alexey__> for Free Software - especially.
[07:58] <alexey__> mdke: also why KDE software is lacking from the list >?
[08:00] <mdke> alexey__, it is associated with Ubuntu because it is sponsored by the company that sponsors Ubuntu, at the moment Ubuntu is the only distribution to use it exclusively
[08:01] <mdke> alexey__, as for kde software, it is missing because it doesn't use gettext if I recall correctly, and support for kde translation has not yet been implemented.
[08:01] <mdke> alexey__, carlos and jordi will be able to answer that question in more detail however
[08:02] <alexey__> I'm non-Ubuntu user, (SUSE actually) - but I feel that everyone can win from that technology.
[08:02] <mdke> i agree
[08:02] <alexey__> ...provided the translations are given back upstream
[08:03] <mdke> the objective of launchpad is to provide a solution between all distributions and upstream
[08:03] <mdke> ideally, upstream would use rosetta too, but we are some way away from that at the moment
[08:03] <alexey__> yes, that would be best
[08:03] <G0SUB> alexey__ Novell won't use launchpad even if it were free
[08:04] <alexey__> Novell -- maybe not. But independent SUSE Linux users, like me - might use.
[08:04] <alexey__> but why not use superior technology is beyond me ... ?
[08:05] <alexey__> why Novell won't use it if it's free?
[08:05] <G0SUB> alexey__ there is no point if only individuals use it ... launchpad is not for individuals per se
[08:05] <alexey__> hmmm - OK, that's for teams - like the whole OSS development process.
[08:05] <SteveA> alexey__: various projects use rosetta.  for example Silva and Zope3 use rosetta for translating their software
[08:06] <mdke> launchpad scales for teams and individuals
[08:06] <G0SUB> alexey__ because Novell won't like the way it's hosted by canonical ... they might want to host a separate instance themselves
[08:07] <alexey__> ok, but SUSE users may help - because they have nothing to do with Novell's politics.
[08:07] <G0SUB> alexey__ possibly
[08:09] <alexey__> I may win nothing from the pro-Ubuntu advertising machine: https://wiki.launchpad.canonical.com/Rosetta
[08:10] <alexey__> but still use it if it improves the software upstream
[08:12] <alexey__> When do you suspect Rosetta will become KDE-compatible ?
[08:29] <jordi> alexey__: hello
[08:30] <jordi> alexey__: it is planned, with no date for now.
[08:30] <jordi> Of course, if KDE decided to use Rosetta officially, that would porbably make things change *fast*
[09:04] <bradb> BjornT: So, I don't want new bug contacts getting change email on bugs they've never seen before (and for which they're about to get a full description of the bug report anyway), so perhaps I should just call my update_bug_contact_subscriptions function from notify_bugtask_edited?
[09:11] <BjornT> bradb: yes, i think calling it from notify_bugtask_edited would be fine, that's probably the easiest solution. that will also avoid issues with the ordering of subscribers.
[09:11] <bradb> sounds good, thanks
[09:52] <carlos> alexey__, mdke: KDE is using gettext but their layout was not supported. This week we are starting with dapper imports and that will import KDE too (talking about Ubuntu packages)
[09:57] <ddaa> did anybody notice that test.py printed the following message:
[09:57] <ddaa> IOError: [Errno 2]  No such file or directory: '/home/david/home/canonical/launchpad/lib/canonical/launchpad/lib/canonical/launchpad/pagetests/branches/xx-team-branches.txt'
[10:07] <BjornT> ddaa: it's because 'canonical/launchpad' occurs twice in the path. i think daf had a patch which fixed that problem, don't know if he's merged it yet.
[10:07] <ddaa> BjornT: I noticed the broken path, but I was unable to figure out where it comes from.
[10:08] <ddaa> BjornT: BTW, where is the new usage of ./test.py documented?
[10:08] <daf> I have a fix
[10:08] <daf> spiv wanted me to add a test before I merge
 (expanded from <david@allouche.net>): delivery temporarily
[10:08] <daf>     suspended: connect to <IP_ADDRESS>[<IP_ADDRESS>] : Connection refused
[10:09] <ddaa> daf: fair enough, it's not terribly urgent to start running that test again
[10:10] <ddaa> re-mail: maybe by ISP is broken ATM. They are reliable usually (my mail server is hosted my web hosting service)
[10:10] <daf> it means you can't run any page tests
[10:10] <BjornT> ddaa: not sure where it's documented, but daf probably knows
[10:10] <ddaa> daf?
[10:10] <daf> I think spiv documented it in the LaunchpadHackingFAQ
[10:10] <ddaa> no page tests?
[10:11] <ddaa> "daf: it means you can't run any page tests" I do not understand what you mean
[10:11] <daf> if you have canonical/launchpad twice in your path, the page test wrapper will ont work
[10:14] <ddaa> haaaa
[10:14] <ddaa> I remember now
[10:14] <ddaa> yup... all my canonical stuff is in ~/canonical
[10:14] <ddaa> and my launchpad tree is ~/canonical/launchpad
[10:15] <ddaa> somebody has been making too many ASSumptions when writing code :( thank you
[10:18] <lifeless> ddaa: heh, that would be me. sorry. It needs a order reversal on the search.
[10:20] <daf> lifeless: I have aptch
[10:20] <daf> lifeless: I mailed it to the list
[10:20] <daf> I didn't get around to writing a test and merging
[10:24] <lifeless> daf: heh
[10:28] <carlos> lifeless: hi, do you know if there is any problem with jbailey's bzr .deb snapshots? last update was four days ago
[10:29] <lifeless> sounds like
[10:34] <mdke> carlos, rocking
[10:39] <bradb> lifeless: I get what appears to be a sporadic test failure from pqm with xx-specs-11-setdistrorelease.txt. Any idea why that might be?
[10:39] <bradb> I'm wonder specifically if it might have anything to do with manual merges, for example.
[10:39] <bradb> s/wonder/wondering/
[10:40] <lifeless> no
[10:40] <lifeless> pqm is disabled during manual merges
[10:40] <lifeless> the test suite resets the database schema and up
[10:41] <bradb> Hm, I guess I'll try a third time.
[10:46] <lifeless> I'd wager 90% probability its something in your branch that the different pqm environment shows up a failure
[10:47] <lifeless> that can be both stuff in head you have not merged to your branch
[10:47] <lifeless> and differences in postgres/platform
[10:50] <bradb> lifeless: How can it be the former? I would have thought that pqm merging it into head to run the tests would negate that possiblity.
[10:51] <bradb> My first instinct is that the test somehow depends on ordering, and it's a postgres thing.
[10:51] <lifeless> so lets say there is an alteration to an existing test in HEAD
[10:51] <lifeless> which when combined with your code fails
[10:52] <lifeless> if you have not merged HEAD, you won't see the failure locally. but you will when you ask pqm to merge you.
[10:52] <bradb> oh, right
[11:18] <ddaa> daf: yay, got a patch for the productseries/+index oops
[11:18] <daf> cool!
[11:44] <sabdfl> lifeless: how are knits looking?
[11:45] <lifeless> sabdfl: coming along well, working on the self check support which was added to weave after they were developed
[11:45] <sabdfl> eta soon?
[11:45] <lifeless> next step is the knit store which should be easy and then we'll have a beta format for experimentation
[11:45] <lifeless> yes, eta this week I hope.
[11:45] <sabdfl> cool
[11:46] <lifeless> fingers crossed yadayadayada
[11:46] <lifeless> anyhow, in deep discussion in #bzr on this, if you'll excuse me ?


[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [amd64] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [armhf] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [ppc64el] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [amd64] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [armhf] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [ppc64el] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted lix [amd64] (disco-proposed) [0.9.23-1]
[01:26] -queuebot:#ubuntu-release- New: accepted lix [i386] (disco-proposed) [0.9.23-1]
[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [arm64] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [s390x] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [i386] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted lix [armhf] (disco-proposed) [0.9.23-1]
[01:26] -queuebot:#ubuntu-release- New: accepted kdesdk-kioslaves [i386] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [s390x] (disco-proposed) [4:18.08.3-0ubuntu1]
[01:26] -queuebot:#ubuntu-release- New: accepted kross-interpreters [arm64] (disco-proposed) [4:18.08.3-0ubuntu1]
[02:26] -queuebot:#ubuntu-release- New binary: med-fichier [ppc64el] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
[02:27] -queuebot:#ubuntu-release- New binary: med-fichier [amd64] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
[02:40] -queuebot:#ubuntu-release- New binary: med-fichier [arm64] (disco-proposed/universe) [4.0.0+repack-5] (no packageset)
[05:32] -queuebot:#ubuntu-release- New: accepted med-fichier [amd64] (disco-proposed) [4.0.0+repack-5]
[05:32] -queuebot:#ubuntu-release- New: accepted med-fichier [ppc64el] (disco-proposed) [4.0.0+repack-5]
[05:32] -queuebot:#ubuntu-release- New: accepted med-fichier [arm64] (disco-proposed) [4.0.0+repack-5]
[06:16] <infinity> Laney: An iputils test wouldn't have caught it, since it works on upgrade.
[06:17] <infinity> Laney: (on upgrade, it attempts to setcap, fails, and falls back to setuid instead, but if it's already fscapped in the filesystem, sucks to be you)
[07:38] <LocutusOfBorg> hello all, so still broken...
[07:39] <LocutusOfBorg> thanks for working on it!
[07:39] <LocutusOfBorg> btw, can any AA around help hdf5 transition move a little bit forward?
[07:40] <LocutusOfBorg> we have a lot of NBS in proposed of old libraries that are preventing britney from showing up some result
[07:41] <LocutusOfBorg> e.g. petsc, hdf5, slepc
[07:41] <LocutusOfBorg> and some "kick out from release" packages that are FTBFS and out from testing
[08:17] <LocutusOfBorg> also various meep* packages needs cleanup
[08:47] <infinity> LocutusOfBorg: petsc, hdf5, slepc, and meep* NBS tidied.
[09:48] <vorlon> stgraber: btrfs on /var/lib/lxd/storage-pools/default and fscaps apparently don't work?
[09:49] <vorlon> ah, no, I was cut'n'pasting a buggy command from a maintainer script
[09:51] <vorlon> ok so the storage backend supports them fine (if I manually set on the filesystem) but if I launch ubuntu-daily:disco it comes in without the fscap
[11:32] <LocutusOfBorg> infinity, <3
[12:13] -queuebot:#ubuntu-release- New binary: python3.6 [s390x] (disco-proposed/main) [3.6.8-1] (core)
[12:40] -queuebot:#ubuntu-release- New binary: python3.6 [amd64] (disco-proposed/main) [3.6.8-1] (core)
[12:44] -queuebot:#ubuntu-release- New binary: python3.6 [i386] (disco-proposed/main) [3.6.8-1] (core)
[13:11] -queuebot:#ubuntu-release- New binary: python3.6 [ppc64el] (disco-proposed/main) [3.6.8-1] (core)
[13:18] -queuebot:#ubuntu-release- New binary: python3.6 [arm64] (disco-proposed/main) [3.6.8-1] (core)
[14:59] -queuebot:#ubuntu-release- New binary: python3.6 [armhf] (disco-proposed/main) [3.6.8-1] (core)
[17:01] <infinity> doko: ^-- python3.6?  That was removed less than a month ago, have you decided we need it back for some reason?
[17:02] <infinity> Oh, that wasn't doko, that was autosync...
[17:02]  * infinity removes again.
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [amd64] (disco-proposed) [3.6.8-1]
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [armhf] (disco-proposed) [3.6.8-1]
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [ppc64el] (disco-proposed) [3.6.8-1]
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [arm64] (disco-proposed) [3.6.8-1]
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [s390x] (disco-proposed) [3.6.8-1]
[17:04] -queuebot:#ubuntu-release- New: rejected python3.6 [i386] (disco-proposed) [3.6.8-1]
[21:26] <stgraber> vorlon: did you try wiping the images that show up in "lxc image list"? so you get a clean download + unpack of the image on the newer LXD?
[21:41] <tsimonq2> infinity, vorlon, xnox: Could I please get eyes on bug 1810123 from someone when y'all are off EOY break? :)
[23:56] <acheronuk> has anyone looked at emacs FTBFS on ppc64el? I ask as that is causing emacs24 (a test dep in the qt transition) to be uninstallable


[09:17] <mup> Bug #1821647 changed: Unclear documentation for machine power parameters <doc> <MAAS:Fix Released> <https://launchpad.net/bugs/1821647>
[09:20] <mup> Bug #1821647 opened: Unclear documentation for machine power parameters <doc> <MAAS:Fix Released> <https://launchpad.net/bugs/1821647>
[09:35] <mup> Bug #1821647 changed: Unclear documentation for machine power parameters <doc> <MAAS:Fix Released> <https://launchpad.net/bugs/1821647>
[09:35] <mup> Bug #1823388 changed: Limit number of simultaneous enlistment/commission operations <MAAS:Invalid> <https://launchpad.net/bugs/1823388>
[09:38] <mup> Bug #1823388 opened: Limit number of simultaneous enlistment/commission operations <MAAS:Invalid> <https://launchpad.net/bugs/1823388>
[09:41] <mup> Bug #1823388 changed: Limit number of simultaneous enlistment/commission operations <MAAS:Invalid> <https://launchpad.net/bugs/1823388>
[09:47] <mup> Bug #1863357 changed: composed KVM guests could be created with maxmem > mem <MAAS:Invalid> <https://launchpad.net/bugs/1863357>
[09:47] <mup> Bug #1887384 changed: Allow user to provide separate storage location for images through GUI <MAAS:Invalid> <https://launchpad.net/bugs/1887384>
[10:17] <mup> Bug #1889118 changed: The number of heartbeats to fail should be configurable <doc> <MAAS:Fix Released> <https://launchpad.net/bugs/1889118>
[10:17] <mup> Bug #1889119 changed: Provide the ability to adjust a script's timeout value <ui> <MAAS:Invalid> <maas-ui:New> <https://launchpad.net/bugs/1889119>
[16:17] <mup> Bug #1999806 opened: INITRAMFS error is happening in ipv6 maas while commissioning <MAAS:New> <https://launchpad.net/bugs/1999806>
[21:51] <mup> Bug #1999827 opened: DNS entries for MAAS servers change to secondary IPs <sts> <MAAS:New> <https://launchpad.net/bugs/1999827>
[21:54] <mup> Bug #1999827 changed: DNS entries for MAAS servers change to secondary IPs <sts> <MAAS:New> <https://launchpad.net/bugs/1999827>
[21:57] <mup> Bug #1999827 opened: DNS entries for MAAS servers change to secondary IPs <sts> <MAAS:New> <https://launchpad.net/bugs/1999827>


[06:11] <Jay____> Hello All
[06:11] <Jay____> I am developer.
[06:11] <Jay____> Previously our application was using Launchpad OpenId login service
[06:12] <Jay____> But that is too old Now we are yet to convert it to OpenID connect
[06:12] <Jay____> I am confused Launchpad still provide OpenID Connect API service for Login?
[06:38] <Jay____> Any suggestion please.
[06:38] <Jay____> Anyone alive?
[06:55] <maxb> OpenID and OpenID Connect are very different protocols, despite the similar names
[06:55] <maxb> There is no reason that a site providing one will necessarily provide the other
[06:56] <maxb> I have not heard of OpenID Connect and Launchpad mentioned together before
[06:56] <maxb> So I'm guessing you should simply continue using OpenID
[06:57] <Jay____> Yes. Thank you for your answer. I know that both technologies are very different.
[06:57] <Jay____> Most popular providers (Which were supporting OpenID) are now providing loging API using Oauth 2.0 combined with OpenID Connect.
[06:58] <Jay____> So I was hopping that Launch pad will do the same.
[06:58] <Jay____> But as you have said I also Google and found no related suggestion regarding Launchpad OpenId connect.
[06:59] <Jay____> Thank you for answering.
[06:59] <Jay____> Bye
[22:46] <sergio_br22> trying to build a package, it works in a clean environment (virtualbox), but not in launchpad: https://launchpadlibrarian.net/203871645/buildlog_ubuntu-trusty-i386.m64py_0.2.2%2Br161~2~ubuntu14.04.1_BUILDING.txt.gz
[22:47] <sergio_br22> .
[22:47] <sergio_br22> UnicodeEncodeError: 'ascii' codec can't encode character '\xa9' in position 1037: ordinal not in range(128)
[22:47] <sergio_br22> E: pybuild pybuild:256: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build
[22:48] <sergio_br22> any idea?
[22:49] <teward> i think you have unicode in there you have to strip out somewhere
[22:50] <teward> but I'm not 100% certain
[22:50] <sergio_br22> you mean, the problem is in the source? Not in the packaging?
[22:51] <teward> not 100% certain, can't attest to either of those myself
[23:04] <sergio_br22> data_files = [
[23:04] <sergio_br22>         ("share/pixmaps", ["xdg/m64py.png"]),
[23:04] <sergio_br22>         ("share/applications", ["xdg/m64py.desktop"]),
[23:04] <sergio_br22> for me, it's right
[23:07] <sarnold> does m64py.desktop contain characters outside ascii limits?
[23:09] <sergio_br22> let me see
[23:10] <sergio_br22> is '\xa9'  an @ ?
[23:11] <sarnold> not @ but ©
[23:11] <sarnold> at least in iso-8859-1 a9 is an ©
[23:12] <sergio_br22> there is a © in src/m64py/ui/license.ui
[23:12] <sarnold> aha; you can try removing it and see if your build progresses further
[23:12] <sergio_br22> but in the log, this file does not appears
[23:13] <sarnold> or you can try figuring out if there's something else you can do to the build environment to let it go further, like it did with your vm..
[23:14] <sergio_br22> well, I installed only these packages: debhelper  dh-python  python3  python3-pyqt5  pyqt5-dev-tools
[23:15] <sarnold> my wild-ass-guess is that you've got your local build running in en_US.UTF-8 and the build is running in C -- but I don't know what to suggest to fix that.
[23:16] <sarnold> .. or local build in pt_BR.UTF-8, or whatever :) hehe
[23:17] <sergio_br22> heh
[23:32] <sergio_br22> ok, it was the  ©, but now it's '\u201c'
[23:40] <sergio_br22> ergh, “ and ”
[23:47] <teward> unicode and bytestryings are a pain aren't they :P
[23:48] <teward> (pytrhon headaches for IRC bot people too xD)
[23:55] <sarnold> what annoys me is that things that worked alright in 2.x broke in 3.x. :(
[23:56] <sergio_br22> yay, worked