[12:13] <bfree> is launchpad registration "broken" or is it normal to have to wait for the email to come through?
[12:29] <bfree> the mail has arrived now ... 22+ minutes later!   so I guess the wait is normal perhaps ...
[12:33] <LarstiQ> yes, it is.
[12:33] <mpt> bfree, your mail provider might be greylisting, which would cause a delay like that
[08:56] <jamesh> I guess SteveA's vhost stuff didn't get accepted by pqm
[09:17] <carlos_> morning
[09:18] <carlos> stub: hi, around?
[09:32] <SteveA> BjornT: ping
[09:34] <BjornT> hi SteveA
[09:35] <SteveA> hi
[09:35] <SteveA> i have a question about the virtual hosting stuff
[09:35] <SteveA> do we have code that takes the Host header into account, and sets up the virtual-host attributes on the Request based on it?
[09:36] <SteveA> i mean, do you remember implementing that aspect of it?
[09:37] <BjornT> no, i didn't implement that
[09:37] <SteveA> okay.  i don't think it matters too much for launchpad
[09:37] <SteveA> but i'll look at doing this today
[09:38] <stub> carlos: Hi
[09:38] <carlos> stub: staging is broken again
[09:38] <carlos> Do I have enough permissions to fix it?
[09:39] <jamesh> SteveA: I tried following the instructions for setting up Apache from your email, but it errors out.  I assume your vhost changes didn't land?
[09:39] <carlos> I mean, a usual code update after migrating the database would restore it?
[09:39] <stub> carlos: Yup. If you want to wait for the data migration...
[09:39] <carlos> stub: didn't you execute it on production ?
[09:39] <SteveA> jamesh: yes, they didn't land.  there was a semantic-level conflict.  i've fixed and resubmitted.
[09:39] <stub> carlos: Not yet
[09:40] <carlos> oh, I see
[09:40] <carlos> stub: I think I'm going to disable the unique restriction
[09:40] <carlos> I don't mind if staging's rosetta is broken...
[09:40] <stub> Might as well kick it off now those - watching this test run is boring...
[09:40] <stub> Ok
[09:40] <stub> c/those/though/
[09:41] <carlos> stub: also, would be possible to move a spec  from https://launchpad.net/products/rosetta/+spec/gnome-mount to Ubuntu context?
[09:41] <carlos> martin doesn't know how would that spec end in Rosetta's context
[09:42] <carlos> and I was scared that they wanted to use Rosetta as the new HAL frontend ;-)
[09:42] <stub> How should we normally handle this. I assume this means that there is no UI for retargetting specs and there is some reason it just can't be recreated in the correct context?
[09:42] <carlos> stub: well, we could reject it
[09:43] <carlos> and create it in the right context...
[09:43] <carlos> I was just trying to reduce the amount of garbage left behind ;-)
[09:44] <carlos> oh
[09:44] <carlos> stub: dude, I just found a way to retarget it...
[09:44] <stub> I'm more interested in how this is supposed to work in the long term. I don't mind manually fixing things but it generally indicates we need to create a bug report to add the missing UI.
[09:44] <carlos> stub: please, ignore me....
[09:44] <stub> :)
[09:54] <stub> carlos-fix-dupliated-submissions.py ?
[09:55] <carlos> stub: yes
[09:55] <carlos> stub: without arguments, the data will be fixed
[09:55] <carlos> stub: with '-c' the script will check if there is something to fix
[10:05] <spiv> stub: I've updated the DB patch in my disable-accounts branch, including updating the trigger -- I needed the trigger to work for my tests to pass.  Please re-review :)
[10:22] <spiv> stub: Oh, and could I get a real patch number for it, please? :)
[10:24] <carlos> staging is restored
[10:48] <SteveA> lifeless: ping
[10:49] <lifeless> pong
[10:49] <SteveA> hi
[10:49] <SteveA> pqm was merging a branch of mine
[10:49] <SteveA> it finished a while ago
[10:49] <SteveA> but no email
[10:51] <lifeless> its looks like an error, but I just managed to delete the backtrace. dang.
[10:51] <lifeless> please submit it again
[10:52] <SteveA> ok
[11:01] <Kamping_Kaiser> i'll check if no one knows - but is there a bug open about ticking 'subscribe me to this bug' not working? the one when you comment on a bug (not the changing status one)
[12:01] <SteveA> lifeless: ping
[12:01] <SteveA> lifeless: my merge went through pqm again
[12:01] <lifeless> gpg: no default secret key: unusable secret key
[12:02] <ddaa> hello there
[12:02] <lifeless> I've asked elmo
[12:03] <LarstiQ> moin
[12:04] <SteveA> lifeless: so, this is likely blocking all PQM merges right now
[12:05] <SteveA> and everyone who submitted will get no feedback at all that their merge has failed
[12:05] <SteveA> so they won't know to resubmit
[12:05] <ddaa> we learnt to resubmit when receiving no feedback :)
[12:05] <SteveA> if this is so, is there a way for you to list the failed merges, so you can tell people what they need to re-submit, when this is fixed?
[12:06] <SteveA> lifeless: i have an HTTP question, if you have a few minutes.
[12:14] <lifeless> SteveA: yes, its blocking all merges. I am looking at it
[12:14] <lifeless> SteveA: ask away, I will answer as time permits
[12:16] <SteveA> lifeless: okay.  I have a browser that is connecting to an HTTP/1.1 server using HTTPS.  The browser is required to send a Host: header.  Is the value of the Host header required to contain the host and port, or can it contain just the host?
[12:17] <SteveA> in this situation, the https server is listening on the default port of 443
[12:17] <lifeless>       Host = "Host" ":" host [ ":" port ]  ; Section 3.2.2
[12:17] <lifeless>    A "host" without any trailing port information implies the default
[12:17] <lifeless>    port for the service requested (e.g., "80" for an HTTP URL). For
[12:18] <lifeless> if the url being requested is something like '
[12:18] <SteveA> ok.  so, if I just see a Host: header at a server of   Host: foo.com
[12:18] <lifeless> GET /foo/bar HTTP/1.1
[12:18] <lifeless> Host: foo.com
[12:18] <lifeless>
[12:18] <SteveA> then it could be either http for foo.com on port 80
[12:18] <lifeless>
[12:18] <SteveA> or https for foo.com on port 433
[12:18] <SteveA> and i would need to look elsewhere to find out which
[12:19] <SteveA> IOW, i need to know the incoming protocol
[12:19] <lifeless> then it is the default port that should be used - the port you are listening on
[12:19] <lifeless> but if the url was
[12:19] <lifeless> GET htt
[12:19] <lifeless> GET http://fo.com/bar HTTP/1.1
[12:20] <lifeless> Host: fo.com
[12:20] <lifeless>
[12:20] <lifeless> and you were listening on https - the implicit port would be 80
[12:20] <lifeless> AIUI
[12:20] <SteveA> ok thanks
[12:20] <SteveA> sounds flaky enough not to rely on it
[12:21] <lifeless> its only of use for vhosting selection
[12:21] <lifeless> the things relevant for a server implementer are:
[12:21] <lifeless>  * port is optional
[12:22] <lifeless>  * port will match the port on the server the request is meant to be sent to, not the port the client connects to[this is relevant when a proxy is inline]
[12:22] <lifeless>    (if present)
[12:22] <lifeless> i.e. you cant rely on it because itmay not be present.
[12:26] <stub> Are there other headers we can rely on to detect if it is http or https?
[12:27] <lifeless> stub - no
[12:28] <lifeless> you need to record the port the request is accepted on and pass that around for the system to know.
[12:28] <lifeless> i.e. squid has support as an accelerator to add a header to requests marking the SSL port they were received on and the external url that should be emitted for that port.
[12:28] <lifeless> this is used by microsoft exchange server in the same situation
[12:29] <lifeless> SteveA: it is fixed
[12:31] <SteveA> lifeless: thanks.  i'll re-resubmit
[12:32] <lifeless> the key had expired.
[12:32] <SteveA> lifeless: does apache have an option to use this header?
[12:33] <SteveA> what i'm doing now is making launchpad choose an external protocol/host/port from its configuration files, based on the Host header received
[12:33] <lifeless> SteveA: that wont work :)
[12:33] <SteveA> why not?
[12:34] <lifeless> because of what we discussed before :)
[12:34] <SteveA> you're not being clear
[12:34] <SteveA> i see nothing that will fail to work
[12:34] <lifeless> sorry, to determine if it is ssl or not on the outside.
[12:34] <SteveA> that doesn't matter
[12:34] <lifeless> I'm not sure what you are trying to achieve.
[12:34] <SteveA> this configuration is used to set the proto/host/port for use in:
[12:34] <SteveA>  - Location headers
[12:35] <SteveA>  - <base> tags in html
[12:35] <SteveA>  - the base part of URLs that are rendered in pages
[12:35] <SteveA> for a given page, we may not know exactly what external details of request got the request into the app server
[12:36] <SteveA> but we do know where we want to direct people to next
[12:36] <lifeless> ok
[12:36] <SteveA> ideally, i'd like to have more information from the accel. proxy server
[12:36] <lifeless> http://3cx.org/item/46
[12:36] <lifeless> documents how to tell paache to set such headers
[12:36] <lifeless> RequestHeader set Front-End-Https "On"
[12:36] <lifeless>  for instance
[12:36] <SteveA> such as what the exact full URL was from the outside, and the port used
[12:37] <lifeless> the port is doable via the RequestHeader set command.
[12:38] <lifeless> using the vhost on apache.
[12:38] <lifeless> don't know offhand about the url, but if we primarily care about domain based changes, host: will be sufficient.
[12:42] <SteveA> lifeless: thanks.  i'll collect these docs for version 2 of our virtual hosting stuff.
[12:42] <SteveA> my current approach will be enough for now.  we'll want more once we start having more plain http pages in launchpad
[12:49] <lifeless> SteveA: can we create meeting events in launchpad for the launchpad series of meetings coming up ?
[12:50] <lifeless> SteveA: I have a spec I wanted to rpopose for discussion at the lp-bzr meeting.
[12:50] <SteveA> sure, that's a good idea
[12:55] <lifeless> should I do that ? I'm happy to
[12:57] <lifeless> SteveA: ^
[12:58] <SteveA> lifeless: please do
[12:59] <lifeless> are the mainly code focused or spec focused ?
[12:59] <lifeless> I'm presuming planning and speccing
[01:01] <SteveA> specs
[01:01] <lifeless> how does this look: https://launchpad.net/sprints/launchpad-malone-support-2006
[01:03] <lifeless> SteveA: ^
[01:04] <SteveA> ok
[01:04] <SteveA> another way to do it would be to have two concurrent sprints
[01:04] <SteveA> but i think this is fine
[01:06] <lifeless> https://launchpad.net/sprints
[01:06] <lifeless> all added.
[01:07] <lifeless> and there is the spec https://launchpad.net/sprints/launchpad-rosetta-bazaar-2006
[01:37] <SteveA> meeting in 23 mins
[01:56] <kiko_> morninh!
[01:57] <ajmitch> morning kiko_
[01:58] <SteveA> it is almost time
[01:59] <kiko_> morning!
[02:00] <SteveA> LAUNCHPAD DEVELOPMENT MEETING
[02:00] <SteveA> Hello, welcome.  ooo vak welcome in this week's Launchpad development meeting.
[02:00] <SteveA> who is with us today?
[02:00] <mpt> me
[02:00] <kiko_> me
[02:00] <salgado> me
[02:00] <jamesh> me
[02:00] <flacoste> i am here
[02:00] <stub> me
[02:01] <matsubara> me
[02:01] <cprov> me
[02:01] <SteveA> ddaa is on vacation
[02:01] <spiv> me
[02:01] <SteveA> anyone else?
[02:02] <jamesh> are we expecting Paris people?
[02:02] <kiko_> if so there should be malcc and Kinnison
[02:02] <SteveA> for those who are at the conference in Paris, please say if you're not coming to this meeting.
[02:02] <SteveA> okay
[02:02] <SteveA> I'd like to remind you to prepare your three sentences and Keep Bag Change items so that you can copy/paste them onto the channel at the appropriate point in the meeting.
[02:03] <SteveA> this keeps the meeting moving swiftly
[02:03] <SteveA> == Agenda ==
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Actions from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report (Matsubara)
[02:03] <SteveA>  * Sysadmin requests
[02:03] <SteveA>  * Production and staging (Stuart)
[02:03] <SteveA> ----
[02:03] <SteveA>  * PQM failures over last 18 hours (Steve)
[02:03] <SteveA>  * Virtual hosting changes (Steve)
[02:03] <SteveA>  * Meetings registered in Launchpad
[02:03] <SteveA>  * (other items)
[02:03] <SteveA> ----
[02:03] <SteveA>  * Keep, Bag, Change
[02:03] <SteveA>  * Three sentences
[02:03] <SteveA>
[02:03] <SteveA> Next meeting, same time next week.
[02:03] <SteveA> Any objections?
[02:03] <SteveA> it is done.
[02:03] <SteveA> Activity reports?
[02:03] <SteveA> i am still not up to date with these.
[02:04] <mpt> up to date
[02:04] <matsubara> up to date
[02:04] <salgado> up to date
[02:04] <stub> up to date
[02:04] <jamesh> I suck
[02:04] <spiv> up to date.
[02:04] <flacoste> up to date
[02:04] <kiko_> u2d
[02:04] <cprov> not up to date, is the sprint a good excuse ?
[02:04] <SteveA> cprov: yes, the sprint is a reasonable reason
[02:05] <SteveA> anyone else?
[02:05] <SteveA>  * Actions from last meeting
[02:05] <SteveA>  * Matsubara and Stuart to talk on skype about QA and production.
[02:05] <SteveA>  * Malcolm, Celso and Daniel to have a soyuz conf call.  (after paris probably)
[02:05] <matsubara> SteveA: not done yet.
[02:06] <SteveA> third week.  how difficult is it to arrange a one on one call, stub and matsubara ?
[02:06] <stub> I've totally forgotten what was to be discussed too.
[02:06] <SteveA> hello carlos
[02:06] <stub> Huge timezone difference
[02:06] <carlos> hi
[02:06] <SteveA> the notion is that there is much in common between QA processes and production processes
[02:06] <SteveA> so to talk about what you've each been doing, with each other
[02:06] <SteveA> and see what comes out of it
[02:06] <mpt> remember you can use the MeetingTimes page to find the best time for a meeting of any subset of people
[02:06] <SteveA> take 30 mins
[02:07] <SteveA> thanks mpt
[02:07] <cprov> SteveA: bad, we still missing that call (we are together here, anyway), postpone it next week, maybe using TeamSpeak
[02:07] <mpt> provided you keep it up to date :-)
[02:07] <SteveA> cprov: have you three been discussing things together much in paris?
[02:07] <stub> I don't think that notion is correct
[02:07] <SteveA> stub: take 30 minsn to prove me wrong
[02:08] <carlos> SteveA: I'm a slacker with my activity reports...
[02:08] <cprov> SteveA: yes, all the BOFs
[02:09] <SteveA>  * Stuart to have a call with someone re: test runner updates to optimize Librarian startup/shutdown.
[02:09] <stub> I didn't bother with the call - the librarian optimization turned out to be trivial.
[02:10] <SteveA> cool
[02:10] <SteveA> is it landed?
[02:10] <stub> Nope - I've been getting deeper into the test suite and decrufting it.
[02:10] <SteveA> although, i will point out that the point of the call isn't just to get further ideas for yourself, but also to spread knowledge of something around the team
[02:10] <stub> I can land Librarian updates but that alone doesn't actually seem to make much difference in timing.
[02:10] <SteveA> i am suffering daily from slow slow tests
[02:10] <SteveA> oh
[02:10] <spiv> That's a funny kind of "trivial" ;)
[02:11] <stub> Most of the time is spend in db setup and tear down
[02:11] <stub> Which I can have a call with someone about ;)
[02:11] <SteveA> stub: maybe talk over this in the next infra. team call?
[02:11] <stub> Its getting 'ickyer.
[02:11] <stub> Sure.
[02:11] <SteveA> i'm certainly interested
[02:11] <SteveA> ok.
[02:12] <SteveA> MeetingAction: stub to talk about faster test suite kill kill kill in next infra. call
[02:12] <spiv> stub: please land the librarian bits, it may help me next time I run authserver tests, which also suffer from process start/stop overhead.
[02:12] <spiv> (it would have helped me this last week, but I think I'm finished with that branch now)
[02:12] <SteveA> MeetingAction: stub and matsubara to have a 30 min call to talk over what they do about production systems and see how it goes
[02:12] <stub> Ok. But let me know before you optimize that as we are likely to conflict.
[02:13] <SteveA> MeetingAction: soyuz team to have a conf call once they get back home
[02:13] <lifeless> hi
[02:13] <SteveA>  * Launchpad oops milestone report (Matsubara)
[02:13] <SteveA> matsubara: please go ahead
[02:13] <lifeless> just got here, lunch was on
[02:13] <matsubara> Bug 49899, which I think bradb started work on it already. I'll coordinate with him, and if he's too busy, I'll take over on that.
[02:13] <Ubugtu> Malone bug 49899 in malone "Lookup error on bug page" [High,In progress]  http://launchpad.net/bugs/49899
[02:13] <matsubara> that's the top exception
[02:14] <matsubara> since brad isn't here, I'll talk with him later.
[02:14] <SteveA> it says it is in progress
[02:14] <SteveA> is that accurate?
[02:14] <matsubara> SteveA: he changed the status on the 21st
[02:14] <matsubara> SteveA: so I think it is, but I'll confirm with him later.
[02:15] <SteveA> ok
[02:15] <matsubara> Bug 50575, not yet assigned. Can you take that carlos?
[02:15] <Ubugtu> Malone bug 50575 in rosetta "+translate pages crash if you select two alternative languages." [Medium,Confirmed]  http://launchpad.net/bugs/50575
[02:15] <kiko_> matsubara, do you know what causes 49899?
[02:16] <kiko_> carlos, that's a topcrasher, would be great to have a fix today or for you to bounce it back to matsubara
[02:16] <matsubara> kiko_: nope, but bjorn has a hypothesis
[02:16] <kiko_> what's that?
[02:16] <matsubara> kiko_: which I added as comment on the bug.
[02:16] <lifeless> its like a theory
[02:16] <kiko_> k
[02:16] <matsubara> kiko_: it's related to the importance_widget having the unknown status set.
[02:17] <mpt> which shouldn't ever be true
[02:17] <matsubara> but I'm not sure about the details
[02:17] <mpt> but may be if old bug-watch-y bugs weren't changed properly
[02:18] <kiko_> matsubara, there's an UnexpectedFormData exception today that smells like a bug
[02:18] <mpt> iirc
[02:18] <matsubara> that bug also might be causing another bug which is making the bug report disapper from the bug search lsting
[02:19] <matsubara> kiko_: it's not a bug, we raise the correct exception and now show a custom error page.
[02:19] <matsubara> well, we don't yet show it, it's not fix released. :)
[02:19] <kiko_> matsubara, the [u'New']  status is not a bug?
[02:19] <kiko_> sure smells like a bug to me
[02:19] <kiko_> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-06-21/A529
[02:19] <stub> Have we remembered to not log an OOPS since we are handling the exception gracefully?
[02:20] <matsubara> haven't seen the tb yet, but if it's raising an UFD at least we'll return to the user a custom error page
[02:20] <SteveA> we still want to record an OOPS for UFD
[02:20] <kiko_> field.status%3Alist=New&search=Search
[02:20] <SteveA> but to index it separately in the report summaries
[02:21] <kiko_> oh I see
[02:21] <cpro1> I'm back, connection was down at conf
[02:21] <SteveA> horrible zope publisher thing
[02:21] <SteveA> kiko_: it's a zope mis-design, to have :list mean something
[02:21] <kiko_> matsubara, you're right.
[02:21] <kiko_> it's not a bug
[02:21] <kiko_> New is no longer a status
[02:22] <matsubara> moving on then.
[02:22] <mpt> so is it someone using a really really old bookmark?
[02:22] <stub> SteveA: I liked :list, but I won't argue its case in the meeting ;)
[02:22] <kiko> mpt, google then.
[02:23] <kiko> Non-sql time  	24288 ms
[02:23] <kiko> that's distroreleaselang-index.
[02:23] <matsubara> mpt: indeed, it's google
[02:23] <SteveA> matsubara: do you mean you're done with the report, or that you're moving to the next item in your report?
[02:23] <matsubara> moving on the next itm
[02:23] <matsubara> item
[02:23] <matsubara> Bug 45788, which is a bug on the sprint date form validation code. Assigned to me, I'll work on it this week.
[02:23] <Ubugtu> Malone bug 45788 in launchpad "Adding a sprint with a finish date before start date causes error" [High,Confirmed]  http://launchpad.net/bugs/45788
[02:23] <matsubara> but I'm still waiting for carlos_ answer
[02:24] <matsubara> With kiko's patches to SQLObject, the timeouts decreased significantly. The outstanding timeouts now are on +translation and +translate pages, which are bug 2497 and 3991 respectively. Both assigned to kiko. So, what are your plan regarding this, kiko?
[02:24] <Ubugtu> Malone bug 3991 in rosetta "Timeout error on translation page (+translate)" [Medium,Confirmed]  http://launchpad.net/bugs/3991
[02:24] <kiko> matsubara, I have a fix that should make the second problem go away entirely
[02:24] <matsubara> kiko: great!
[02:24] <kiko> matsubara, the first one requires creating a TranslationContributor table
[02:24] <carlos_> matsubara: hi, sorry, could you point me to that bug?
[02:24] <jamesh> matsubara: related to 45788, jdub was getting oops's during last meeting by trying to subscribe to a sprint with finish date < start date
[02:24] <kiko> which I haven't even started yet
[02:24] <carlos_> matsubara: we just got our Internet link back
[02:25] <matsubara> carlos_: bug 50575
[02:25] <Ubugtu> Malone bug 50575 in rosetta "+translate pages crash if you select two alternative languages." [Medium,Confirmed]  http://launchpad.net/bugs/50575
[02:25] <SteveA> matsubara: how many more items do you have in your report?  there are other items i want to get to in the meeting.
[02:25] <kiko> carlos: topcrasher alert!
[02:25] <matsubara> SteveA: I'm done.
[02:25] <SteveA> thanks matsubara
[02:26] <matsubara> SteveA: I can coordinate with carlos after the meeting
[02:26] <SteveA> okay
[02:26] <SteveA>  * Sysadmin requests
[02:26] <SteveA> 5
[02:26] <SteveA> 4
[02:26] <SteveA> 3
[02:26] <SteveA> (say "i have one" to stop the countdown)
[02:26] <SteveA> 2
[02:26] <spiv> rt #11425: bug 33223 is blocked by updating Twisted, which is blocked by RT #11425 -- python2.4-pyopenssl isn't installed whereever pqm is running the tests.
[02:26] <kiko> SteveA, matsubara's requests for access to the database.
[02:26] <Ubugtu> Malone bug 33223 in launchpad-bazaar "SFTP server should give human-friendly errors for name restrictions" [Medium,Confirmed]  http://launchpad.net/bugs/33223
[02:26] <mpt> thanks to Znarl for fixing certificates on chinstrap and l.c.c
[02:27] <spiv> Znarl closed rt #11425, but I discovered today the problem is still there.
[02:27] <lifeless> can I ask that I am cc'd on all rt requests for pqm-related things
[02:27] <jamesh> spiv: should it be a dep of launchpad-dependencies then?
[02:27] <SteveA> spiv: i spoke with karl about this, and i thought it was getting sorted.  there was some confusion about exactly where the package needed installing.  lifeless can talk with karl
[02:27] <carlos_> matsubara: I will take a look to it, I think it's produced by a recent merge I did. It broke also navigation under some circumstances
[02:27] <lifeless> because I had not heard of this request.
[02:27] <spiv> lifeless: Ok, I'll do that in future.
[02:27] <carlos_> SteveA: I still need an answer to the request to get access to drescher
[02:27] <lifeless> spiv: well, this is a request for everyone.
[02:27] <SteveA> kiko: i spoke with elmo about matsubara's request, and he agreed to do it.
[02:27] <kiko> SteveA, thanks.
[02:27] <matsubara> ok, thanks carlos_
[02:28] <spiv> lifeless: Sure, but I can't speak for anyone else ;)
[02:28] <lifeless> SteveA: can I ask that I am cc'd on all rt requests for pqm-related things
[02:28] <matsubara> thanks SteveA and kiko, that will be very helpful
[02:28] <spiv> jamesh: I don't think so -- launchpad-dependencies is for things needed to run and test launchpad, not for things needed for "make check_merge".
[02:28] <SteveA> AgendaItem: everyone to note that lifeless should be cc-ed on PQM-related RT issues
[02:28] <carlos_> SteveA:  #10992
[02:28] <lifeless> thank you
[02:29] <spiv> jamesh: Also, it's really a bug in Twisted that I need this at all, there's just a handful of buggy tests that aren't skipping properly in our snapshot, so it's likely that this is a short-term issue.
[02:29] <SteveA> spiv: i think that's a launchpad dependency, in general.
[02:29] <cprov> carlos: drescher ?
[02:29] <SteveA> spiv: although, i accept the argument about this being a short-term thing
[02:30] <SteveA> carlos: you mean RT 10992 ?
[02:30] <lifeless> we can install and remove it later
[02:30] <SteveA> carlos: please say either "bug 1234" or "RT 1234" so that we have the context clear in the logs
[02:30] <SteveA> carlos: not "#1234"
[02:30] <SteveA> moving along now...
[02:30] <carlos> SteveA: sorry, RT 10992
[02:31] <SteveA>  * Production and staging (Stuart)
[02:31] <stub> Production is being boring. Which is good. Next rollout is expected to be next Tueday with rocketfuel HEAD as of now.
[02:31] <stub> Staging has had downtime due to the updates failing due to needing some data migration run on staging. It might work fine tomorrow if nobody creates some duplicate rosetta submissions before then.
[02:31] <SteveA> stub: assuming i can get my vhosts changes through pqm, i'd like to get those running on staging soon
[02:31] <SteveA> this will require some apache changes on staging too
[02:31] <SteveA> which i will coordinate with karl
[02:32] <SteveA> thanks for keeping production boring.
[02:32] <SteveA>  * PQM failures over last 18 hours (Steve)
[02:32] <stub> Yup. Landing on Friday or Monday preferred to give us a good week to test.
[02:32] <SteveA> because a private key expired, pqm silently rejected merge requests for the last 18 hours or so
[02:32] <SteveA> it is probably working again now
[02:33] <carlos> SteveA: forget that request, celso just explained the usage of that machine and obviously I should not do there what I was told to do there. I will wait until my home server is fixed
[02:33] <SteveA> lifeless: can you get a list of the merges that were silently rejected?
[02:33] <lifeless> SteveA: not trivially.
[02:33] <SteveA> lifeless: can you alter PQM so that when this happens again, you can trivially get such a list?
[02:33] <cprov> carlos: you can use mawson (dogfood)
[02:33] <SteveA> it should be a matter of improving some logging
[02:33] <SteveA> or logging incoming request commands somewhere
[02:33] <lifeless> everything is captured already
[02:33] <SteveA> i ask because this has happened before
[02:33] <lifeless> need to write a grepper for this
[02:34] <SteveA> is there some convoluted log format?
[02:34] <cprov> carlos: point me to the ooffice version you want in mawson, I can copy it from ubuntu-queue and you can play in mawson
[02:34] <SteveA>  * Virtual hosting changes (Steve)
[02:35] <lifeless> SteveA: not that convoluted, but not trivial to pick out what you are asking from from the log.
[02:35] <SteveA> when i get my vhosts branch landed, you'll all need to make some changes to your /etc/hosts and apache configuration to continue developing launchpad locally
[02:35] <lifeless> and a reporting tool is a good thing I think.
[02:35] <stub> Sounds like we just want to dump inbound pqm emails to a mbox file.
[02:35] <SteveA> i'll send an updated email to the list when this is landed properly
[02:36] <SteveA> lifeless: and i repeat my request for pqm to be changed so that it never fails silently.
[02:36] <SteveA> this is a big usability problem with pqm.
[02:36] <lifeless> SteveA: lets talk about this in lithuania
[02:36] <kiko> stub, +1
[02:36] <SteveA> ok
[02:37] <SteveA>  * Meetings registered in Launchpad
[02:37] <SteveA> lifeless has registered the upcoming launchpad sprints as meetings in launchpad
[02:37] <SteveA> thank you lifeless
[02:37] <SteveA> attendees should register for these meetings, in launchpad
[02:37] <SteveA> the URL has slipped off my scrollback...
[02:38] <matsubara> https://launchpad.net/sprints
[02:38] <kiko> lifeless rocks!
[02:38] <mpt> they usually are
[02:38] <SteveA> are they usually?
[02:38] <mpt> well, sometimes they have moss on them
[02:38] <SteveA>  * Keep, Bag, Change
[02:38] <SteveA> 7
[02:38] <SteveA> 6
[02:39] <SteveA> 5
[02:39] <SteveA> 4
[02:39] <SteveA> 3
[02:39] <SteveA> 2
[02:39] <SteveA> 1
[02:39] <SteveA> thanks
[02:39] <SteveA>  * Three sentences
[02:39] <mpt> DONE: Returned to NZ, some menus CSS fixes, bug fixing
[02:39] <mpt> TODO: Finish menus with Steve, DescriptionMarkup, LaunchpadLoginService
[02:39] <mpt> BLOCKED: no
[02:39] <lifeless> I have none prepared sorry, at the sprint in Paris.
[02:39] <carlos> DONE: #35631, More #40550 work, user support, prepared some spec for the UDS-Paris.
[02:39] <carlos> TODO: #40550, Fix some bugs raised by OpenOffice.org exports, Fix navigation issues produced by #35631
[02:39] <carlos> BLOCKED: no
[02:39] <jamesh> DONE: code reviews, minor tickcount tweaks, some last minute sprint scheduler tweaks, branch puller/syncer improvements
[02:39] <stub> DONE: shipit constraints, test suite work
[02:39] <jamesh> TODO: code reviews, subversion symlink support for cscvs
[02:39] <jamesh> BLOCKED: no
[02:39] <stub> TODO: shipit constraints, test suite work
[02:39] <stub> BLOCKED: Nope
[02:39] <flacoste> DONE: fixed three bugs in support tracker.
[02:39] <flacoste> TODO: fix some more, attend Malone and Support Tracker meeting in London
[02:39] <flacoste> BLOCKED: no
[02:39] <matsubara> DONE: fixed bugs (broken template, custom error page for UFD), support requests, some bug triage. TODO: fix more oops bugs (sprint date validation, finish fix for calendar), skype call with stub
[02:39] <matsubara> BLOCKED: no
[02:39] <spiv> DONE: disable-account, bzr smart server work, reviews.
[02:39] <spiv> TODO: bzr smart server, sftp server bugs.
[02:39] <spiv> BLOCKED: RT #11425, as mentioned earlier.
[02:40] <kiko> DONE: 2 day vacation, work on performance (Rosetta and Soyuz), management, launchpad reporting
[02:40] <kiko> TODO: launchpad report, land performance and de-XXX-ifications, travel for sprint, sprint
[02:40] <kiko> BLOCKED: spiv's review of a fix for bug 1555
[02:40] <Ubugtu> Malone bug 1555 in launchpad "BugMessage.selectOneBy doesn't work as expected" [Medium,In progress]  http://launchpad.net/bugs/1555
[02:40] <salgado> DONE: Code review, fixed a bunch of shipit/mirror-management trivial things and landed them, made a new python-codespeak-lib package
[02:40] <salgado> TODO: Code review, random fixes, attend the Malone and Support Tracker sprint
[02:40] <salgado> BLOCKED: No
[02:40] <SteveA> DONE: menus hacking, virtual hosts hacking, insta-reviews
[02:40] <SteveA> TODO: virtual hosts landing, menus landing
[02:40] <SteveA> BLOCKED: pqm *still* hates me
[02:40] <spiv> kiko: Sorry, it's not on pending-reviews, so it hasn't been staring me in the face every morning when I check my review queue.
[02:40] <lifeless> SteveA: https://launchpad.net/products/pqm/+spec/admin-report-tool
[02:40] <spiv> kiko: I warned you :P
[02:41] <lifeless> SteveA: its not personal :)
[02:41] <spiv> kiko: I suggest doing as Steve suggested, and putting it on PendingReviews with a pastebin URL if a branch is too heavyweight for you.
[02:41] <SteveA> lifeless: i don't think i've received a notification from me re-re-resubmission to pqm
[02:42] <kiko> spiv, you're just saying that to make me feel bad.
[02:42] <LarstiQ> SteveA: fwiw, pqm works again for bzr
[02:42] <SteveA> cool, thanks LarstiQ
[02:42] <SteveA> we have 3 minutes of meeting left
[02:43] <SteveA> any blocked items not being dealt with?
[02:43] <SteveA> any further brief points?
[02:43] <stub> I'm hungry
[02:43] <SteveA> stub: then a countdown of doom is in order.
[02:43] <SteveA> 1
[02:43] <mpt> On a miscellaneous note, you can now push branches to chinstrap.canonical.com, rather than chinstrap.ubuntu.com (since Launchpad != Ubuntu) or chinstrap.warthogs.hbd.com (since Canonical != HBD)
[02:43] <SteveA> MEETING ENDS
[02:43] <mdupont> OMG ITS ALIVE!!!
[02:44] <lifeless> mpt: if you do that, and you are not using the pqm-submit plugin, the old pqm submission script *will* get confused.
[02:44] <carlos> SteveA, kiko: I wonder if we should add many specs for Rosetta when we have still some of them pending to be imported...
[02:44] <SteveA> thanks for coming people.
[02:44] <kiko> carlos, you mean implemented?
[02:44] <carlos> kiko: yeah dude, I don't know what's going on with me today....
[02:45] <carlos> s/imported/implemented/
[02:45] <kiko> spiv, added a note, but do you really need a pastebin or can you find the email?
[02:45] <cprov> DONE: queue-ui, publishing prototypes (dak-tools), UDS
[02:45] <cprov> TODO: specs and bug triage/gardening
[02:45] <cprov> BLOCKED: None
[02:45] <carlos> I have some specs I want to work on but I don't know if we should handle all interesting things we could have in mind to fill a week of work for two developers
[02:46] <mpt> SteveA, I'll resume secretarial duties if you wish
[02:46] <kiko> carlos, I don't understand.
[02:47] <kiko> carlos, add the specs you'd like to discuss at the sprint!
[02:47] <spiv> kiko: The main thing is to have an entry on the PendingReviews page I think.
[02:47] <kiko> I have it there spiv. now go review it :-P
[02:47] <spiv> ~
[02:47] <SteveA> mpt: offer accepted.  thank you.
[02:47] <carlos> kiko: that the amount of non implemented specs for Rosetta is growing a lot and some of them are later obsolete because the time we wrote them and when we are going to implement them is so big that many things changed already....
[02:47] <carlos> kiko: at least, that's my feeling
[02:48] <kiko> carlos,  I still don't understand why this is a problem
[02:49] <carlos> well, I was just wondering if we could do a mix of tasks, writing specs and also do some coding to get a new developer more up to date with daily developing in launchpad
[02:50] <carlos> kiko: if we fill the week with specs, we will not be able to implement all those specs before the next conference anyway....
[02:51] <carlos> so I think we could work on the new ones that are high priority and leave the rest of the week to hack
[02:51] <OgMaciel> good morning Carlos...  ;)  Hope all is well in Paris...  any word on those problems we were getting while translating strings by any chance?
[02:51] <lifeless> Kinnison: malcc: cprov: bug 50672 may be of interest to you
[02:51] <Ubugtu> Malone bug 50672 in soyuz "Distribution packages list is incomplete." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50672
[02:51] <malcc> lifeless: Looking
[02:51] <carlos> OgMaciel: nothing more that are actually bugs that I will fix, but nothing done yet, sorry
[02:51] <carlos> s/more that/more than/
[02:52] <OgMaciel> carlos: no prob...  I'll work around them for now...  ;)
[02:52] <carlos> OgMaciel: thanks for your report
[02:52] <OgMaciel> carlos: sure thing... some of the users noticed before I did...  ;)
[02:52] <lifeless> SteveA: kiko: this is for either of you. At what level of 'smallness' is something that I'd like to see changed in launchpad no longer a spec but rather a bug ?
[02:53] <SteveA>   |<------------>|
[02:53] <jsgotangco> hey OgMaciel
[02:53] <kiko> lifeless, it depends. :)
[02:53] <OgMaciel> howdy jsgotangco... am loving your pix in Flickr
[02:53] <jsgotangco> haha
[02:53] <lifeless> kiko: well, for instance, https://launchpad.net/products/gnupg/+distributions has no links to the distro specific pages.
[02:54] <lifeless> kiko: I think it should, but theres probably a group of related changes, and discussion may be needed.
[02:54] <OgMaciel> matsubara: hey bud... any word on the solution to that problem (X crashing when signing the CoC)?
[02:55] <mpt> lifeless, I've reported several "there should be a link from here to there" issues as bugs
[02:55] <malcc> lifeless: If you want a quick hack, make it a bug; if you want to sit down for a review of it and similar UI, knock up a spec and propose it for a discussion
[02:55] <lifeless> malcc: I guess I'm raising this because theres *no guidance in launchpad* as to this.
[02:55] <lifeless> and I think as a result the spec tracker is nearly completely unused for most packages and products.
[02:55] <SteveA> lifeless: would you please look to see what pqm has done to my merge?
[02:56] <malcc> lifeless: Yes I agree. I wasn't trying to suggest you should have known, just making a suggestion for your current issue
[02:56] <lifeless> spiv: is kiko going to take disable-accounts ?
[02:56] <lifeless> malcc: oh, I do that already.
[02:56] <spiv> lifeless: I don't know, is he?
[02:57] <lifeless> malcc: but if we can find a description that is clear, and makes sense for relative newcomers to the system, maybe we can get blueprint some more integration into stuff
[02:57] <lifeless> spiv: you and he were talking about a review
[02:57] <OgMaciel> hey jsgotangco... are you guys still meeting?
[02:57] <matsubara> Hi OgMaciel, sorry didn't have time to look into it, but I suppose the distro guys would know better about it. Try asking on #ubuntu or #ubuntu-bugs
[02:57] <mpt> lifeless, I think it would be good for Launchpad (the product, not Blueprint) to gradually migrate to a standard of one spec per feature, where "feature" is of the magnitude of 1 page in the Web UI
[02:57] <jsgotangco> OgMaciel: just done in my BOF session
[02:57] <spiv> lifeless: he sent me a diff (unrelated to disable-accounts) in email to review, it got forgotten, I told him to put it on PendingReviews.
[02:57] <lifeless> spiv: I've given it to salgado
[02:57] <OgMaciel> jsgotangco: about Edubuntu?
[02:57] <OgMaciel> matsubara: any way we can escalate this?
[02:58] <jsgotangco> OgMaciel: various, most Edubuntu BOFs are already done and just drafting/finishing up specs
[02:58] <lifeless> spiv: indeed, everyone should do that except for blindingly simple specs
[02:58] <OgMaciel> jsgotangco: very nice...  wish I could be there...  :/
[02:58] <AndreNoel> hello og
[02:58] <salgado> lifeless, you gave me a new review? when was that?
[02:58] <lifeless> salgado: 1 minute ago
[02:59] <salgado> ah, okay
[02:59] <matsubara> OgMaciel: I'm not sure, the distro guys are very busy at the sprint.
[02:59] <OgMaciel> hey AndreNoel...  carlos has told me the bugs will be fixed once he gets a chance to work on them
[03:00] <OgMaciel> matsubara: anyone in particular I should talk to?  This bug is preventing people from signing the Coc, and is very frustrating
[03:00] <lifeless> mpt: done https://launchpad.net/products/soyuz/+bug/50674
[03:00] <Ubugtu> Malone bug 50674 in soyuz "product 'distributions' and 'packages' pages need links" [Untriaged,Unconfirmed]
[03:00] <AndreNoel> OgMaciel: good
[03:01] <SteveA> lifeless: i want to go and get some lunch, but if i need to submit to pqm again, i want to do this before i go
[03:01] <lifeless> mpt do you think that the product side bug pages, eg https://launchpad.net/products/gnupg/+filebug should offer a link through to the distro area ?
[03:01] <lifeless> SteveA: looking
[03:01] <SteveA> ta
[03:01] <AndreNoel> OgMaciel: i've signed coc 1.0.1 without problem
[03:02] <OgMaciel> AndreNoel: though X crashed when I clicked on the submit button to sign it, it apparently send the info...  but the bug is very annoying
[03:02] <mpt> lifeless, yes, that's one of the bugs I was referring to :-)
[03:02] <matsubara> OgMaciel: you could try looking for these people: https://launchpad.net/people/ubuntu-x-swat, they were automatically subscribed to that bug though
[03:02] <lifeless> mpt: heh.
[03:02] <kiko> OgMaciel, I have no idea what could cause X to crash. use lynx>
[03:03] <AndreNoel> OgMaciel: i saw it on coc 1.0, but not in 1.0.1
[03:03] <AndreNoel> the coc 1.0.1 don't crash
[03:03] <OgMaciel> kiko: I could... but to someone who's new to Linux and wants to help out, Lynx could be very scary  ;)
[03:03] <matsubara> cprov: ping
[03:04] <cprov> matsubara: even if there is a bug in nvidia driver, do we intend to let the page as it is (horizontally enormous) ?
[03:04] <cprov> matsubara: pong
[03:04] <matsubara> cprov: I was about to ask you about that. :)
[03:04] <kiko-afk> bbiab
[03:04] <mpt> lifeless, actually, I was thinking of bug 3152 and bug 42480, neither of which are the exact thing you've just mentioned
[03:04] <Ubugtu> Malone bug 3152 in malone "Prominently link between product bug listings <-> equivalent package bug listings" [Medium,Confirmed]  http://launchpad.net/bugs/3152
[03:04] <Ubugtu> Malone bug 42480 in malone "Report a bug about product that doesn't use Malone should include link to product's official bug tracker" [Wishlist,Confirmed]  http://launchpad.net/bugs/42480
[03:05] <OgMaciel> cprov: is this then related to a tag in the page?
[03:05] <matsubara> cprov: nope, there's another bug open for that.
[03:05] <lifeless> elmo: https://launchpad.net/distros/ubuntu/+source/gnupg/+bug/50675
[03:05] <Ubugtu> Malone bug 50675 in gnupg "error message when a key has expired is not helpful" [Untriaged,Unconfirmed]
[03:05] <lifeless> mpt: should I open a bug for my suggestion then, or a spec?
[03:05] <cprov> matsubara: good
[03:06] <mpt> lifeless, bug, and cross-reference it with 42480, thanks
[03:06] <matsubara> cprov: were you able to reproduce the bug that crashes X?
[03:06] <cprov> OgMaciel: maybe, could not reproduce it in office machine, well salgado tried (hard)
[03:07] <cprov> matsubara: ^^
[03:07] <OgMaciel> cprov: do you also have a Nvidia card at the machine you used?
[03:07] <matsubara> cprov: btw, the horizontally huge page is bug 38890
[03:07] <Ubugtu> Malone bug 38890 in launchpad "'code of conduct signatures' has formatting issues" [Medium,Unconfirmed]  http://launchpad.net/bugs/38890
[03:07] <lifeless> SteveA: I dont see it at all. did it appear in the webui queue ?
[03:07] <cprov> OgMaciel: yes, I think so.
[03:07] <salgado> OgMaciel, yeah, I've tried it in a box with an nForce card. (tried both the proprietary and the open source driver)
[03:08] <OgMaciel> salgado: have you seen the error message I was able to scrap off the logs?
[03:08] <SteveA> lifeless: i think so, but i don't have browser-client-what-you-see logs.  i'll try submitting again.
[03:08] <salgado> OgMaciel, no, what's that?
[03:08] <cprov> matsubara: thanks, but high priority would be appropriated, it's so easy
[03:08] <OgMaciel> salgado: lemme grab the link
[03:09] <OgMaciel> salgado: https://launchpad.net/distros/ubuntu/+source/xorg/+bug/49789
[03:09] <Ubugtu> Malone bug 49789 in xorg "Clicking on Codes of Conduct link in Launchpad crashes X" [Untriaged,Unconfirmed]
[03:10] <matsubara> cprov: actually that's a dupe, the original one is bug 39995, which is assigned to the great mpt. I'll pester him to try to fix it quickly.
[03:10] <Ubugtu> Malone bug 39995 in launchpad "No Line break in CoC active signatures" [Low,In progress]  http://launchpad.net/bugs/39995
[03:11] <lifeless> SteveA: I just cannot see any sign it reached me.
[03:11] <salgado> OgMaciel, "Caught signal 11. Server aborting" would be the message?
[03:11] <SteveA> lifeless: ok.  thanks for looking.  let's see what happens to this next one.
[03:11] <cprov> salgado: ehe
[03:11] <OgMaciel> salgado: nope... the message above it
[03:11] <cprov> matsubara: perfect, thank you
[03:12] <OgMaciel> salgado: am talking about the backtrace  :P
[03:13] <salgado> OgMaciel, well, I couldn't get my X to crash, so I see no backtrace at all
[03:13] <OgMaciel> salgado: the backtrace is reported in the bug page... my backtrace
[03:14] <salgado> oh, right. I saw it.
[03:14] <salgado> I thought you were asking if I got the same backtrace here
[03:14] <OgMaciel> :)
[03:16] <flacoste> spiv: you were assigned to review my fixes for bug 3849 and bug 50007, do you know when you'll have time to review that?
[03:16] <Ubugtu> Malone bug 3849 in launchpad-support-tracker "No navigation to bug report created from a support request" [Medium,In progress]  http://launchpad.net/bugs/3849
[03:16] <Ubugtu> Malone bug 50007 in launchpad-support-tracker "When filing a bug related to the support tracker, the summary and description should be editable" [Medium,In progress]  http://launchpad.net/bugs/50007
[03:17] <spiv> flacoste: tomorrow morning (my time).
[03:17] <flacoste> spiv: ok, tnx!
[03:18] <cprov> OgMaciel: let me suggest something, centainly there is something wrong in nvidia driver and it might be a major defect, try to reproduce it w/o launchpad (copy the html from lp, for instance) then keep in touch with the distro community in order to fix it. From the LP side we will try to get the CoC page layout fixed ASAP, it may mitigate the issues/blockers for you guys to sign new CoC and keep doing your job. Does it sounds ok ?
[03:18] <spiv> flacoste: We'll see if you're still thanking me after I review your code ;)
[03:18] <spiv> flacoste: Btw, did you figure out what was going on with those weird page test failures?
[03:18] <OgMaciel> cprov: what do you mean by copying the html?
[03:19] <flacoste> spiv: yes, the tests needed change because I've modified LaunchpadView to not call render() when there is a redirection
[03:19] <spiv> OgMaciel: File->Save Page As, or similar.
[03:20] <cprov> OgMaciel: an "ultra-wide" html page should cause the same problem
[03:20] <spiv> OgMaciel: So that you have something to reproduce the X crash with after we fix the page layout in Launchpad.
[03:20] <matsubara> that'd be a bit difficult since when he tries to visit the page the page crashes his X
[03:20] <cprov> spiv: good explanation, thanks
[03:20] <OgMaciel> matsubara: actually, it only crashes when i click on the link
[03:21] <spiv> flacoste: Ah ok, but no insight into why the pagetests weren't matching when they looked like they should.  Ah well.
[03:21] <OgMaciel> spiv: yes indeed... thanks
[03:21] <matsubara> OgMaciel: welll, there you go then. :)
[03:21] <spiv> matsubara: "or similar" :)
[03:21] <flacoste> spiv: no, didn't investigate that issue though
[03:21] <spiv> flacoste: That's fair enough.  Just curious to know if the mystery miraculously explained itself for you :)
[03:21] <OgMaciel> spiv: I thought he meant to use the url somewhere else
[03:23] <OgMaciel> cprov: I will save the html and try to get a hold of someone from ubuntu-devel
[03:23] <cprov> OgMaciel: good
[03:23] <OgMaciel> thanks cprov spiv matsubara
[03:23] <cprov> OgMaciel: thank you, for the valuable feedback.
[03:24] <OgMaciel> cprov: and thank you for handling this with such grace
[03:31] <koni> hi
[03:31] <koni> I have an account on launchpad, but if I try to login into http://wiki.launchpad.canonical.com/ it fails!
[03:32] <koni> Sorry, wrong password
[03:32] <koni> Any help!
[03:33] <lifeless> koni: why do you want to login to that wiki ?
[03:34] <koni> I actually want to login into this wiki: https://wiki.ubuntu.com/, but because it failed too I tried this one
[03:35] <lifeless> they have different ACL's - failures on one mean nothing for failures on the other
[03:35] <spiv> koni: You're using your email address as the username for the wiki?
[03:35] <lifeless> whats your launchpad account ?
[03:35] <koni> konrad
[03:35] <koni> not not using my email address
[03:36] <matsubara> spiv: talking about that, would have some time to fix bug  39814?
[03:36] <Ubugtu> Malone bug 39814 in launchpad "Misleading login hint" [Medium,Confirmed]  http://launchpad.net/bugs/39814
[03:36] <koni> ok, it worked! Thanks a lot!!
[03:36] <koni> e-mail adress is the magical "word"
[03:38] <koni> ok, seen the bug report; yes this would be clearer
[03:40] <spiv> matsubara: Yeah, I'll take another look at that tomorrow.
[03:41] <matsubara> spiv: thanks. where is that code btw? I tried to find it but no sucess.
[03:41] <matsubara> s/sucess/success/
[03:43] <spiv> matsubara: the wiki code?
[03:44] <matsubara> spiv: yes.
[03:44] <spiv><EMAIL_ADDRESS>[03:45] <spiv> (Most of the work done on it was when we were using baz)
[03:49] <lifeless> spiv: convert it!
[03:49] <spiv> lifeless: It's converted.
[03:49] <lifeless> cool then ;)
[03:50] <spiv> lifeless: I just haven't moved it out of the directory it was converted into yet :)
[04:04] <koni> join #kubuntu
[04:10] <mdupont> i added a couple of localdir objects
[04:11] <mdupont> wrong window
[04:46] <ddaa> Kinnison: pingish
[04:54] <kiko> SteveA, lifeless: just got a failure in bzrlib.errors. is that normal?
[04:54] <kiko> AssertionError: Failed doctest test for bzrlib.errors
[05:05] <kiko> has anyone seen this sort of failure?
[05:05] <kiko> perhaps I need to merge RF.
[05:21] <Kinnison> ddaa: I'm about to go into review-joy mode. What can I do for you?
[05:22] <ddaa> tell me about the various cronscripts daemons of buildd, and give me a one sentence summary of what they do relative to each other
[05:22] <ddaa> specifically, the stuff in ./cronscripts and ./daemons that pertains to buildd
[05:22] <Kinnison> buildd-queue-builder -- constructs builds and buildqueue entries and sets the scores
[05:23] <ddaa> build and buildqueue are db tables?
[05:23] <Kinnison> buildd-slave-scanner -- scans each slave in turn and updates the buildqueue records for in-progress, dispatches unbuilt queue entries to idle builders, and retrieves completed builds to pass to process-upload
[05:23] <Kinnison> yes, build and buildqueue are db tables
[05:24] <Kinnison> the buildd-sequencer is a simple daemon which serialises the running of the buildd cronscripts at second-by-second granularity which is needed because the slavescanner runs every 10 seconds which normal cron can't do
[05:25] <ddaa> why are the buildd cronscripts not just a single daemon then?
[05:26] <Kinnison> Hysterical raisins
[05:26] <ddaa> is there any good reason that you are leaving the stuff that way (increased robustness, agility), or is that _just_ historical?
[05:27] <Kinnison> The distro team have discovered that it's useful to be able to invoke the individual behaviours separately at times
[05:27] <ddaa> conversely, is there any drawback to doing things that way?
[05:28] <Kinnison> the major drawback is the incredible startup cost
[05:28] <ddaa> what do you mean?
[05:28] <Kinnison> cpython+initZopeless+execute_zcml_for_scripts can chew upwards of two or three seconds to get going
[05:29] <ddaa> I see, you are doing that twice every 10s...
[05:29] <Kinnison> and when you want to run a script every 10 seconds, that really sucks
[05:30] <ddaa> okay, and buildd-slave.tac is the slave service, that's invoked somehow by the init.d scripts
[05:30] <Kinnison> Indeed
[05:31] <ddaa> Kinnison: can you see any good reason for me to want to reproduce the build/buildqueue tables for vcs-imports?
[05:31] <Kinnison> build I doubt, buildqueue maybe
[05:32] <ddaa> I sortofguess that build is something very specific to what buildd does, relating the package versions or something
[05:32] <Kinnison> indeed
[05:34] <ddaa> Kinnison: thank you
[05:39] <Kinnison> ddaa: you're welcome
[05:52] <LarstiQ> hmm
[05:53] <LarstiQ> I just got confused looking at a bug status that was unconfirmed before I saw it was a duplicate, looking at the other bug it was indeed fixed. Should that be a bug?
[05:56] <matsubara> LarstiQ: you mean the dupe should automatically have the same status of the original bug?
[05:57] <matsubara> LarstiQ: we have bug 3796 open, it's not exactly that, but IMHO is even better, since the status shown would be duplicate.
[05:57] <Ubugtu> Malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Medium,Confirmed]  http://launchpad.net/bugs/3796
[05:58] <LarstiQ> matsubara: yeah, that would be better
[06:00] <LarstiQ> matsubara: any idea what the status is on that bug?
[06:04] <matsubara> LarstiQ: sorry, no ETA for it yet. AFAIK, there are others high priority stuff going on atm. bradb might know better since he's the assignee.
[06:07] <SteveA> aw crap
[06:07] <SteveA> i got failures in pqm from test_reconnector.txt
[06:07] <bradb> I assigned that bug to myself when I used to track bugs via assigning them to me, but I've just unassigned it to not be misleading.
[06:08] <LarstiQ> bradb: was that prior to subscription support?
[06:09] <bradb> LarstiQ: No. I used to just take a lot of bugs as a way of saying that I know I'd looked at it, and it seemed like a sane bug report.
[06:10] <LarstiQ> hmm, that seems slightly weird to me.
[06:20] <ddaa> importd rolled out
[06:20] <ddaa> the sourceforge imports look fixed
[06:21] <ddaa> and it _might_ produce knit branches for new imports, but I have not checked
[07:36] <Oppy> hey, I have a dumb question if anyone's around
[07:37] <Oppy> On https://launchpad.net/products/democracy/trunk/+pots/democracyplayer I want to assign certain people to be owners of their specialty language
[07:38] <Oppy> so they can have the final say on those translations
[07:38] <Oppy> and I can't find whereI do that
[07:38] <kiko> Oppy, aha!
[07:39] <Oppy> lol
[07:39] <Oppy> were you looking for me? ;)
[07:39] <kiko> https://launchpad.net/products/democracy/+translations
[07:39] <kiko> Oppy, visit that page, and then click on "Change Translators"
[07:40] <Oppy> I've been to that page
[07:40] <kiko> you are there able to select a translation team.
[07:40] <kiko> oh, are you looking to create your own team?
[07:40] <Oppy> Yeah, I suppose so
[07:41] <Oppy> where do I do that?
[07:41] <kiko> Oppy, normally we suggest that you try using the Ubuntu translation team first, before creating your own. Do you have a good reason to request your own specific group?
[07:41] <Oppy> I work with a few specific translators who I'd like to give mod priveleges to for their languages
[07:42] <kiko> I see.
[07:42] <Oppy> I don't know if they're all on the ubuntu team or not
[07:42] <Oppy> what do you recommend?
[07:42] <kiko> the advantage of using the Ubuntu translation team is that they have good language coverage and are generally active and knowledgeable.
[07:43] <kiko> you can check with your translators if they are part of the respective teams, and if not, you can either suggest they join the teams, or request your own translation group.
[07:43] <Oppy> okay, thanks
[07:43] <kiko> I can create your group easily, at any rate, if you think it's the right solution. that was my suggestion :)
[07:43] <Oppy> for now I'll select the ubuntu team
[07:43] <kiko> wonderful!
[07:44] <Oppy> now that I've done that, am I able to play around with permissions a little more?
[07:47] <Oppy> also, how do i join the translation group?
[08:23] <SteveA> kiko: do you have a few minutes to double-check something with me?
[08:23] <kiko> SteveA, sure! what's up?
[08:24] <SteveA> remember that possible database stale data issue we were looking at with cprov last week?
[08:24] <kiko> yes, I do.
[08:24] <SteveA> okay
[08:24] <SteveA> i have an idea of what the problem is, but i'd like to explain it to you
[08:24] <SteveA> so that we can see if it makes sense
[08:24] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/file4M5deV.html
[08:24] <SteveA> there's the pastebin of some typical test output
[08:25] <SteveA> find the line with "breezy.releasestatus # 2"
[08:25] <SteveA> we have established here that the data was written correctly after the transaction commit
[08:25] <SteveA> the next test is the failure of "expect_okays('foo_1.0-1.5', False,  upload_policy='sync')"
[08:26] <SteveA> and here's where cprov said the problem lay
[08:26] <kiko> right.
[08:26] <SteveA> because this calls out to a separate process
[08:26] <SteveA> and so on
[08:26] <kiko> right.
[08:26] <SteveA> looking at the code, i don't think this ever gets to making a new process
[08:26] <SteveA>  AssertionError: Rejected should be empty
[08:26] <SteveA> so i think the data shown below is stale data from the last test run, or the last test using uploader_log
[08:27] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/filebPY8yc.html
[08:27] <SteveA> that's expect_okays
[08:27] <SteveA> the assert is actually before the starting of a new process
[08:29] <kiko> SteveA, doesn't process_uploads() start the new process?
[08:29] <SteveA> ah, maybe
[08:30] <SteveA> it is weird having that in an assert!
[08:30] <kiko> yeah, it is.
[08:30] <SteveA> like having essential processing as a side-effect of an assert
[08:30] <SteveA> i'm still against using asserts in tests, btw
[08:30] <kiko> so remove them
[08:30] <kiko> I agree
[08:30] <kiko> they make little sense.
[08:31] <SteveA> well
[08:31] <SteveA> i can think of some reasons to use them
[08:31] <SteveA> like to show you're checking a precondition that you have good reason to assume is true
[08:31] <SteveA> as distinct from checking something as part of the test
[08:31] <SteveA> ok, thanks for pointing that out
[08:31] <SteveA> i'll continue looking into this
[08:32] <kiko> sure thingo
[08:33] <salgado> SteveA, would it be a problem if GFV.fieldNames was immutable?
[08:34] <SteveA> salgado: i have never considered the issue
[08:35] <kiko> salgado, I think it might for bradb's advancedsearch form
[08:37] <SteveA> kiko: another question then
[08:37] <SteveA> https://chinstrap.ubuntu.com/~dsilvers/paste/file4M5deV.html
[08:37] <SteveA> in there
[08:37] <SteveA> that is the original output we were dicussing
[08:37] <kiko> okay.
[08:37] <salgado> kiko, all places I've seen actually make a copy of fieldNames to avoid mutating it
[08:37] <SteveA> what is incorrect about the output of     print open(uploader_log).read()  ?
[08:37] <SteveA> salgado: why do you want to make it immutable?
[08:37] <SteveA> or rather, what prompted your question?
[08:38] <SteveA> salgado: i see that fieldNames is a read-only property
[08:38] <SteveA> salgado: so therefore it is immutable, in a sense
[08:39] <SteveA> salgado: it uses getFieldNamesInOrder, which returns a new list each time it is called
[08:39] <SteveA> so, from that point of view, you can do what you like with the returned value
[08:39] <salgado> SteveA, well, GeneralFormViewFactory() does a "class_.fieldNames = fields"
[08:40] <salgado> the read-only property is just a fallback and I think it can be removed
[08:40] <SteveA> you should be wary of mutating a list that is an attribute of a class
[08:40] <SteveA> because that is essentially a global variable
[08:40] <salgado> right. that's why I want to make it immutable
[08:40] <SteveA> how would you make it immutable?
[08:41] <SteveA> i don't think python has an "immutable list" type
[08:41] <salgado> "class_.fieldNames = tuple(fields)" wouldn't do it?
[08:41] <SteveA> you're changing its type!
[08:41] <SteveA> so, that will cause code that treats it as a list to fail
[08:41] <SteveA> a tuple is not the same as an immutable list
[08:42] <SteveA> you can't do (1, 2, 3) + [4, 5, 6]
[08:42] <SteveA> but you can do [1, 2, 3]  + [4, 5, 6]
[08:42] <SteveA> also, tuples are meant to represent tuple kind of data
[08:42] <kiko> right.
[08:42] <SteveA> whereas lists are meant for list kind of data
[08:42] <salgado> right, I know that. I'd take care of changing existing code and make sure it's properly documented
[08:42] <kiko> tuples are not just "immutable lists"
[08:43] <SteveA> it is sometimes the right thing to do to use a tuple for an immutable list
[08:43] <kiko> they are actually meant to be used more like structs
[08:43] <SteveA> but that needs some careful thought
[08:43] <SteveA> and should be invisible to users of the code you're doing that to
[08:43] <salgado> okay, then what about renaming GFV.fieldNames to GFV._fieldNames and defining a fieldNames property that can be overwritten in subclasses?
[08:44] <SteveA> sure
[08:44] <SteveA> in fact
[08:44] <SteveA> i don't see why this should be a property at all
[08:44] <SteveA> so if you fancy a bit of refactoring
[08:44] <SteveA> make it a method getFieldNames()
[08:44] <SteveA> there would be less confusion all round
[08:45] <SteveA> kiko: any ideas about that test output?
[08:45] <salgado> that would also include a lot of changes in existing code, but it's fine I think
[08:45] <kiko> SteveA, there should be no rejection.
[08:46] <kiko>     + INFO    Rejected:
[08:46] <kiko>     + INFO    Not permitted to upload to the BACKPORTS pocket in a release in the 'EXPERIMENTAL' state.
[08:46] <kiko>     + INFO
[08:46] <SteveA> thanks
[08:46] <kiko> SteveA, the release is no longer in EXPERIMENTAL state.
[08:48] <kiko> we just changed it to CURRENT.
[08:49] <SteveA> pqm loves me again
[08:49] <SteveA> now everyone needs up update their apache setup
[08:49] <SteveA> i'll sort it out on staging when karl is around tomorrow
[08:50] <SteveA> we can also sometime do a mass replace of localhost:9000 for launchpad.dev in pagetests
[08:50] <SteveA> but, this can also be done one test at a time
[08:52] <kiko> SteveA, without updating apache setup will PQM merges fail?
[08:53] <SteveA> no
[08:53] <SteveA> there will be no pqm failures due to this
[08:53] <SteveA> the main thing is, people manually testing launchpad on their local machine
[08:57] <kiko> yeah, gotcha.
[08:59] <kiko> SteveA, have a moment for some rosetta reviewing?
[08:59] <SteveA> maybe in a bit
[08:59] <SteveA> i just run some instrumented soyuz tests, but i need to rest my eyes for a few minutes
[08:59] <SteveA> i'll ping you in a bit
[08:59] <SteveA> these soyuz tests take a while to run, so probably i can do a bit of review
[09:01] <kiko> cool.
[09:01] <kiko> this should fix performance for +translate
[09:01] <kiko> doing some prejoining and avoiding a big IN () query.
[09:02] <kiko> unfortunate that the page will need some more serious work if we are to fix it completely
[09:02] <kiko> the data model requires a lot of shuffling around of data.
[09:03] <kiko> SteveA, is there something like assertRaises() that I can use in pagetests?
[09:22] <flacoste> why were page titles defined in the module pagetitles.py and not as a attribute of the view that render the page?
[09:23] <flacoste> and also what's the status of I18N in launchpad?
[09:23] <flacoste> I see some strings using MessageId (i.e. the _()), but none of the page titles use them
[09:23] <flacoste> should I use it for new code (I did until now)?
[09:26] <SteveA> kiko: no, but i think they should be
[09:26] <SteveA> flacoste: we'll be refactoring pagetitles
[09:27] <SteveA> flacoste: the main reason at present is that views are used for many pages, so it isn't a one-to-one page-to-viewclass mapping
[09:27] <SteveA> flacoste: use MessageId stuff in new code where it makes sense to do so.
[09:27] <flacoste> SteveA: ok
[09:29] <flacoste> btw, I've seen code that use MessageId like this _( 'String with %s') % 'interpolation' where it should be like this _( 'String with $sub', mapping={'sub': 'interpolation'})
[09:30] <kiko> really?
[09:31] <flacoste> yep, that's the zope.i18n.message API
[09:32] <flacoste> sorry, zope.i18nmessageid.message
[09:32] <flacoste> before Zope 3.2, it was: _( 'String with $sub')
[09:32] <flacoste> err, id = _('String with $sub')
[09:33] <flacoste> id.mapping = {'sub': 'interpolation'}
[09:33] <flacoste> but now msgid are immutables, so the mapping has to be given at construction time
[09:50] <kiko> SteveA, salgado: https://chinstrap.ubuntu.com/~dsilvers/paste/filelvbCk4.html
[09:50] <kiko> flacoste, wow, interesting.
[09:50] <kiko> SteveA, salgado: any chance of a review before I take off?
[09:53] <SteveA> +        return list(ret)
[09:53] <kiko> SteveA, yes
[09:53] <kiko> ?
[09:53] <SteveA> if there is a clear reason not to use shortlist there, be explicit about not usingn shortlist
[09:54] <kiko> hmmm.
[09:54] <kiko> well
[09:54] <SteveA> +        translated_pots = set([pofile.potemplate for pofile in self.pofiles] )
[09:54] <SteveA> no need for []
[09:54] <SteveA> it becomes a generator comprehension
[09:54] <kiko> right.
[09:54] <SteveA> +        dummies = []
[09:54] <SteveA> +        for pot in untranslated_pots:
[09:54] <SteveA> +            dummies.append(DummyPOFile(pot, self.language))
[09:54] <SteveA>
[09:54] <SteveA> list comprehension instead?
[09:55] <SteveA> +        assert isinstance(code, (str, unicode)), code
[09:55] <SteveA> use basestring
[09:55] <kiko> ah cool
[09:56] <kiko> about shortlist
[09:56] <kiko> can't use it easily because the batch size can be manually changed
[09:56] <SteveA> +        subs = subs.prejoin(['potranslation', 'person', 'pomsgset',
[09:56] <SteveA> +                             'pomsgset.pofile'] )
[09:56] <kiko> SteveA, is adding a comment okay there?
[09:56] <SteveA> format the list all on one line
[09:56] <kiko> ok.
[09:57] <kiko> (though I never like that)
[09:57] <SteveA> comment is fine, provided it mentions the word "shortlist"
[09:58] <SteveA> well
[09:58] <SteveA> i think the way you have formatted that prejoin call is unclear -- you can easily lose track of that you're looking at list items
[09:58] <SteveA> and not args
[09:58] <SteveA> i think  callname(foo, bar
[09:58] <SteveA>                 baz)
[09:58] <SteveA> is okay
[09:58] <SteveA> (lined up properly)
[09:58] <kiko> but does it matter? prejoin only takes one argument..
[09:58] <SteveA> if it doesn't look too silly
[09:58] <SteveA> so
[09:59] <SteveA> why split the single arg over two lines?
[09:59] <SteveA> you should endeavour to not split an arg over two lines
[09:59] <SteveA> when it will fit on one
[09:59] <SteveA> as it is a single arg
[09:59] <kiko> I see
[09:59] <SteveA> anyway, with all those comments, r=me
[10:02] <kiko> SteveA! rock on!
[10:09] <mpt> LarstiQ, the status, assigneed, importance, and milestone of a bug report probably should be greyed out somehow when the report is a duplicate
[10:09] <SteveA> kiko:
[10:09] <SteveA>  /*-1255022292*/ UPDATE BinaryPackagePublishing SET status = 2, datepublished = CURRENT_TIMESTAMP AT TIME ZONE 'UTC' WHERE id = 24
[10:09] <mpt> assigneed->assignee
[10:09] <SteveA> do you remember what that's all about?
[10:09] <mpt> LarstiQ, that would probably solve the problem you were experiencing
[10:10] <SteveA> *** ProgrammingError: ERROR:  cannot update a view
[10:10] <LarstiQ> mpt: setting the status to Duplicate would also be a clear hint.
[10:10] <mpt> yesssssss
[10:11] <SteveA> kiko: the issue seems to be this: the commit isn't actually working in that test, so the data never gets to the database.  the commit isn't working because of that recurring error when sqlobject writes data to the database.
[10:11] <LarstiQ> mpt: I'm not sure greying out would be clear enough, it could be I just don't have the permissions, or whatever else causes greyings out
[10:11] <SteveA> kiko: for reasons i have not yet uncovered, the commit fails silently.  also, getting the new value from scratch is unreliable, as it is actually getting the old value from the last transaction.
[10:13] <mpt> I can't remember any of those drawbacks
[10:13] <kiko> SteveA, the question is really why is the commit() failing
[10:13] <SteveA> i know why the commit is failing
[10:13] <kiko> oh
[10:13] <SteveA> i don't know why it fails *silently* in the doctest
[10:13] <kiko> because we are writing to a view
[10:13] <kiko> right
[10:14] <mpt> LarstiQ, it helps slightly when a bug is marked as a duplicate by mistake, that it can easily (well, "easily" relative to the Launchpad UI's usual slothiness) be set back to exactly what it was before
[10:14] <mpt> but that's not a very good reason
[10:14] <LarstiQ> eh?
[10:15] <LarstiQ> mpt: Bjorns suggestion is to not store the duplicate state so getting back to the old situation is easy too
[10:15] <LarstiQ> or did you mean uiwise?
[10:16] <mpt> both, really
[10:17] <SteveA> kiko: i'm done for the evening.  see you tomorrow!
[10:17] <LarstiQ> hmm, greying out would be an extra cue, but I'd prefer both rather than only greying
[10:17] <kiko> thanks SteveA
[10:17] <mpt> LarstiQ, you're right, I'll report a bug about it, and hope it doesn't get marked as a duplicate
[10:17] <LarstiQ> mpt: I'd argue you do not need to see the status before you unduplicate
[10:18] <LarstiQ> the original status I mean
[10:18] <LarstiQ> mpt: hah :)
[10:18] <LarstiQ> mpt: bug 3796 has good comments already
[10:18] <Ubugtu> Malone bug 3796 in malone "Duplicated bugs still show up as New in a list of bugs (also affects the Latest bugs portlet)" [Medium,Confirmed]  http://launchpad.net/bugs/3796
[10:19] <mpt> oh
[10:19] <mpt> that's a bit of a misleading summary, then
[10:19] <kiko> it is indeed
[10:19] <LarstiQ> I agree, which is why I couldn't find it scanning the bugs
[10:23] <mpt> fixed
[10:32] <LarstiQ> heh, the mail mentions 'Summary changed', while the activity log thinks the title field has changed
[10:33] <flacoste> title is the name of the field and Summary is its label
[10:33] <flacoste> (that's probably the source of the discrepancy)
[10:35] <LarstiQ> I see.
[11:07] <flacoste> how come bzr log <file> gives me the whole log?
[11:07] <kiko> mmm
[11:09] <flacoste> example: [francis@Bourdieu tt-bug-43759] $ bzr log README
[11:09] <flacoste>     ------------------------------------------------------------
[11:09] <flacoste>     merged<EMAIL_ADDRESS>[11:09] <flacoste>     committer: Bjorn Tillenius<EMAIL_ADDRESS>[11:09] <flacoste>     branch nick: bug-32282
[11:09] <flacoste>     timestamp: Wed 2006-06-21 15:41:15 +0200
[11:09] <flacoste> etc.
[11:09] <kiko> flacoste, it appears to be a bug, but I can't be sure
[11:09] <kiko> it shows the whole log regardless of whether or not the file was changed, right?
[11:09] <flacoste> seemed like it
[11:10] <flacoste> I would have expect only the messages related to the file
[11:39] <carlos> flacoste: I don't know, but it makes sense
[11:39] <flacoste> shouldn't that template be removed or move to not-used then?
[11:45] <LarstiQ> flacoste: hmm, bzr log <file> does only show the revisions that touched file, afaics
[11:46] <LarstiQ> both 0.8 and bzr.dev
[11:46] <flacoste> hmm, doesn't look like it here
[11:46] <flacoste> at least in my Launchpad tree
[11:47] <LarstiQ> flacoste: can you reproduce it with a minimal testcase?
[11:47] <flacoste> I'll try
[11:47] <LarstiQ> (and also, something I'm allowed to look at)
[11:47] <flacoste> I'm using a shared repository with a lightweight checkout, FWIMW
[11:47] <LarstiQ> I'll try that too then
[11:49] <LarstiQ> checkouts inside the repo, or?
[11:52] <flacoste> no, checkout is outside the repository
[11:57] <LarstiQ> flacoste: works for me
[11:59] <mpt> Goooooooooooooooooooooooooood morning Launchpadders!
[12:01] <carlos> flacoste: if there are no references to it, I think you can kill it
[12:02] <carlos> flacoste: is useless to leave garbage behind
[12:02] <flacoste> carlos: rm or mv to not-used?
[12:02] <carlos> and we can always recover it, we are using an SCM system....
[12:02] <carlos> do we have a not-used directory?
[12:02] <carlos> didn't know it...
[12:02] <carlos> mpt: what do you think?
[12:03] <carlos> mpt: we are talking about a template that seems to be useless
[12:03] <flacoste> lib/canonical/not-used/README.txt says:
[12:03] <flacoste> Code is put into lib/canonical/not-used/ rather than archived on some arch
[12:03] <flacoste> branch, so that its existence is still easily noted.
[12:04] <carlos> flacoste: well, the definition of non-used is for untested code or non maintained code


[06:18] <Takyoji_> Woo, I think I might have a good visual representation sheet that describes open source with diagrams and/or analogies
[06:18] <Takyoji_> Still drawing a draft yet, but good results.
[18:26] <Beyecixramd> hiii!


[02:15] <fosburg> I have been playing with 'Linux' and 'Ubuntu' on an old pc for a few months.  Now I want to buy a workstation to do video and 3d modeling. Any suggestions?
[02:18] <pleia2> fosburg: this channel is for classes (you can check out the schedule in the topic), you want #ubuntu for support :)
[02:19] <fosburg> thank you
[16:33] <akgraner> :-)
[18:30] <john___> hi


[02:30] <Eickmeyer> vorlon: Looks like my blacklisting/higher seeding trick worked. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/ubuntustudio/+build/585934
[02:48] <vorlon> Eickmeyer: the higher seeding in principle works yes, glad to hear it also worked in practice
[03:13] <Eickmeyer> vorlon: Was this automatic? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/noble/edubuntu-preinstalled/+build/585949
[03:55] <vorlon> Eickmeyer: yes
[03:55] <vorlon> or at least, it wasn't me
[04:46] <arraybolt3> ubuntu-release: Would like to get some eyes on https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/2055799 (an FFe I just filed that has significant implications for Ubuntu Unity). This is to fulfill a feature goal set by the Ubuntu Unity team lead (rs2009) for 24.04.
[04:46] -ubottu:#ubuntu-release- Launchpad bug 2055799 in calamares-settings-ubuntu (Ubuntu) "FFe: Switch Ubuntu Unity to using Calamares" [Undecided, New]
[05:14] -queuebot:#ubuntu-release- New binary: python-levenshtein [amd64] (noble-proposed/none) [0.12.2-3] (kubuntu)
[05:17] -queuebot:#ubuntu-release- New binary: python-levenshtein [arm64] (noble-proposed/none) [0.12.2-3] (kubuntu)
[05:23] -queuebot:#ubuntu-release- New binary: python-levenshtein [s390x] (noble-proposed/none) [0.12.2-3] (kubuntu)
[05:31] -queuebot:#ubuntu-release- New binary: python-levenshtein [ppc64el] (noble-proposed/none) [0.12.2-3] (kubuntu)
[06:03] -queuebot:#ubuntu-release- New binary: python-levenshtein [riscv64] (noble-proposed/universe) [0.12.2-3] (kubuntu)
[06:26] -queuebot:#ubuntu-release- New: accepted python-levenshtein [riscv64] (noble-proposed) [0.12.2-3]
[06:26] -queuebot:#ubuntu-release- New: accepted python-levenshtein [amd64] (noble-proposed) [0.12.2-3]
[06:26] -queuebot:#ubuntu-release- New: accepted python-levenshtein [ppc64el] (noble-proposed) [0.12.2-3]
[06:26] -queuebot:#ubuntu-release- New: accepted python-levenshtein [arm64] (noble-proposed) [0.12.2-3]
[06:26] -queuebot:#ubuntu-release- New: accepted python-levenshtein [s390x] (noble-proposed) [0.12.2-3]
[06:32] <vorlon> juliank: right, doing a gnutls-less bootstrap build of apt in the bootstrap ppa, so that we can move gnutls to new nettle without having to remove apt...
[06:33] <vorlon> juliank: do you want patches to support this slightly better?
[07:13] <vorlon> anyway, current bootstrap chain is apt -> gnutls28 -> openldap -> heimdal
[08:19] <doko> vorlon, ginggs: can we consider force-migrating python3-defaults? it's dropping python3.11 as supported only, and would allow autopkg tests running against 3.12 only. we can have another python3-defaults upload later, if we want to run the autopkg tests again. Of course, scheduled autopkg tests should be cancelled
[08:20] <vorlon> doko: I think it's reasonable to consider this however I am not going to look into it this evening, I'm only working on time_t stuff and then I'm going to bed
[08:21] <vorlon> apt->gnutls28 is done, waiting for publication so I can copy gnutls28 back to the archive
[08:21] <vorlon> and so I can retry openldap
[08:44] <vorlon> apt->gnutls28->openldap done
[08:50] <ginggs> doko: i've been keeping an eye on python3-defaults; tests are completed on all architectures except amd64 (and i386)
[08:50] <ginggs> most of the test failures turned out to have already regressed in -release
[08:51] <ginggs> only weird one i've seen is parsedatetime/2.6-3
[08:51] <vorlon> but is there any reason to wait for the rest of the test results
[08:52] <ginggs> nah, i will hint it
[08:54] <ginggs> there are still about 1700 tests triggered by 3.12.1-0ubuntu2 for amd64, these could be de-queued (and i386 too)
[08:55] <vorlon> also doing a util-linux bootstrap build without readline
[09:01] <vorlon> someone deliberately trying openldap/armhf in the archive?
[09:01] <vorlon> 'cuz that ain't gonna work
[09:01] <vorlon> <handwaves upwards regarding bootstrap>
[09:02] <doko> yes, I have the impression somebody has auto-retries running
[09:11] <vorlon> doko: is it you retrying builds in the bootstrap ppa?
[09:12] <vorlon> someone is retrying mesa on riscv64 in the ppa which absolutely must not be done
[09:12] <vorlon> well, no; I guess this one isn't being binary copied to the main archive so it's ok
[09:12] <vorlon> but pointless
[09:18] <doko> no, I didn't retry anything today. Yesterday I retried armhf packages in -proposed only
[09:21] <vorlon> ok well someone is retrying things in our ppa that don't need retried
[09:48] <ginggs> vorlon: what state were the builds in?  i believe between is/launchpad, builds are retried if connection is lost to the builder (to mitigate failed builds with no logs)
[09:48] <vorlon> ginggs: cancelled
[09:49] <vorlon> or failed
[09:49] <vorlon> or dep wait
[09:53] <vorlon> doko: ok, checking out for the night; next step is to get heimdal from the archive building https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+build/27867425 , after which this can be binary-copied back to the main archive and I think that unblocks building openldap in the archive, and then cyrus-sasl2
[09:55] <doko> ok. looking. missing bd on libcrypt-dev?
[09:56] <vorlon> possibly
[09:56] <doko> anyway, looking at that
[10:27] <LocutusOfBorg> I didn't retry anything btw :)
[10:27] <LocutusOfBorg> specially not in ppa
[10:27] <LocutusOfBorg> I did a mass retry like 24+ hours ago
[10:35] <ginggs> apparently the parsedatetime test fails when run on February 29
[10:35] <ginggs> https://github.com/bear/parsedatetime/issues/282
[10:35] -ubottu:#ubuntu-release- Issue 282 in bear/parsedatetime "testNextMonth fails on February 29th" [Open]
[10:56] <ginggs> doko: python3-defaults migrated
[13:25] <LocutusOfBorg> vorlon, ginggs llvm-14 15 16 17 uploaded
[13:25] <LocutusOfBorg> please tell me if anything is wrong
[13:25] <LocutusOfBorg> of course couldn't test 32bit builds due to uninstallabilities
[14:58] <doko> vorlon: this is additionally hurting the armhf bootstrap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065371  I think we should turn that off, at least temporarily
[14:58] -ubottu:#ubuntu-release- Debian bug 1065371 in dpkg-dev "unable to disable bug-implicit-func for time64" [Important, Open]
[15:21] <doko> vorlon: I think that should be turned off for now
[15:49] <doko> uploaded
[17:00] <doko> now created: https://wiki.debian.org/BrainDumpT64
[17:17] -queuebot:#ubuntu-release- New binary: rust-endi [amd64] (noble-proposed/none) [1.1.0-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-endi [arm64] (noble-proposed/none) [1.1.0-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-endi [ppc64el] (noble-proposed/none) [1.1.0-2] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: rust-endi [s390x] (noble-proposed/none) [1.1.0-2] (no packageset)
[17:30] -queuebot:#ubuntu-release- New binary: rust-endi [riscv64] (noble-proposed/none) [1.1.0-2] (no packageset)
[17:58] <doko> looks like cyrus-sasl2 has to be built first. resolving the python uninstallabilities first
[17:59] -queuebot:#ubuntu-release- New: accepted rust-endi [amd64] (noble-proposed) [1.1.0-2]
[17:59] -queuebot:#ubuntu-release- New: accepted rust-endi [ppc64el] (noble-proposed) [1.1.0-2]
[17:59] -queuebot:#ubuntu-release- New: accepted rust-endi [s390x] (noble-proposed) [1.1.0-2]
[17:59] -queuebot:#ubuntu-release- New: accepted rust-endi [arm64] (noble-proposed) [1.1.0-2]
[17:59] -queuebot:#ubuntu-release- New: accepted rust-endi [riscv64] (noble-proposed) [1.1.0-2]
[19:26] <vorlon> looks like cyrus-sasl2 needs 3 uploads: one with everything disabled, one after heimdal with gssapi enabled, one with everything reenabled after openldap is rebuilt
[19:51] -queuebot:#ubuntu-release- New binary: imath [i386] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[19:59] -queuebot:#ubuntu-release- New binary: imath [amd64] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[19:59] -queuebot:#ubuntu-release- New binary: imath [s390x] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[20:03] -queuebot:#ubuntu-release- New binary: imath [ppc64el] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[20:11] <vorlon> openldap building now
[20:20] -queuebot:#ubuntu-release- New binary: libslow5lib [amd64] (noble-proposed/universe) [0.7.0+dfsg-2.1] (no packageset)
[20:21] -queuebot:#ubuntu-release- New binary: libslow5lib [ppc64el] (noble-proposed/universe) [0.7.0+dfsg-2.1] (no packageset)
[20:26] -queuebot:#ubuntu-release- New binary: libslow5lib [arm64] (noble-proposed/universe) [0.7.0+dfsg-2.1] (no packageset)
[20:27] -queuebot:#ubuntu-release- New: accepted libslow5lib [arm64] (noble-proposed) [0.7.0+dfsg-2.1]
[20:27] -queuebot:#ubuntu-release- New: accepted libslow5lib [ppc64el] (noble-proposed) [0.7.0+dfsg-2.1]
[20:28] -queuebot:#ubuntu-release- New: accepted libslow5lib [amd64] (noble-proposed) [0.7.0+dfsg-2.1]
[20:28] <vorlon> hmm openldap cleared its build-deps but then had a test failure; retrying
[20:31] -queuebot:#ubuntu-release- New binary: imath [arm64] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[20:43] <Eickmeyer> vorlon: I know it might not be priority, but cdimage wrt edubuntu daily-preinstalled is still sad. Not sure if it's on your radar or not.
[20:45] <vorlon> Eickmeyer: I'm not going to be able to do anything about it myself for at least a week.  Can you open a bug on the project and we'll see if someone can pick it up?
[20:45] <vorlon> openldap failure is reproducible grr
[20:47] <Eickmeyer> vorlon: Sure.
[20:52] <Eickmeyer> vorlon: Might be imprecise, but bug 2055832.
[20:52] -ubottu:#ubuntu-release- Bug 2055832 in ubuntu-cdimage "Edubuntu daily-preinstalled images not populating on cdimage.ubuntu.com" [Undecided, New] https://launchpad.net/bugs/2055832
[21:12] -queuebot:#ubuntu-release- New binary: imath [riscv64] (noble-proposed/universe) [3.1.9-3.1ubuntu1] (i386-whitelist)
[21:16] <vorlon> doko: -Werror=implicit-function-declaration causes unrelated ftbfs but it *also* catches missing prototypes for time_t functions which is why the ARM porters said it should be there
[21:17] <vorlon> is having misbuilds due to missing prototypes really better than dealing with some ftbfs
[22:47] <vorlon> openldap bootstrapped on armhf, copying back to main archive (required ignoring test suite failures)
[22:47] <vorlon> no clue whether the testsuite regressions are due to time_t or not, but openldap test suite fails on the autobuilders and hangs for me in a porter env
[22:48] <vorlon> anyway, https://launchpad.net/ubuntu/+source/openldap/2.6.7+dfsg-1~exp1ubuntu3
[23:18] -queuebot:#ubuntu-release- New binary: php-lcobucci-clock [amd64] (noble-proposed/universe) [3.2.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: php-league-uri-src [amd64] (noble-proposed/none) [7.4.0-2] (no packageset)
[23:58] <vorlon> cyrus-sasl2 building https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+build/27869198