[12:16] <lifeless_> morning
[12:16] <interalia> it sucks to be at work at 8 in the morning
[12:19] <lifeless> its great when that means @home on the couch.
[12:19] <lifeless> kiko: ping
[12:49] <kiko> lifeless, yeah?
[12:49] <kiko> lifeless, my baz situation is terrible :-(
[01:09] <kiko-zzz> lifeless, I issue:
[01:09] <kiko-zzz> baz branch<EMAIL_ADDRESS><EMAIL_ADDRESS>[01:09] <kiko-zzz> lifeless, it eats up 900MB and then blows up
[01:09] <kiko-zzz> with COTM and 1.4.2
[01:16] <lifeless> kiko-zzz: ouch
[01:16] <lifeless> kiko-zzz: do a baz library-add<EMAIL_ADDRESS>[01:26] <dilys> Merge to<EMAIL_ADDRESS>merge in community contributions r=bjornt (patch-27<EMAIL_ADDRESS>[01:43] <lifeless> kiko-zzz: try again now, I've fiddled stuff on chinstrap to help
[03:53] <lifeless> whats the ubuntu keyserver called ?
[04:02] <elmo> keyserver.ubuntu.com
[04:07] <lifeless> elmo: yah, figured that out :0
[04:08] <Lathiat_> Is it known that the various links the launchpad-integration stuff pull up dont work? (cant see a bug but more wondering if its just not implemented yet), ex: https://launchpad.net/distros/ubuntu/breezy/+sources/gnome-panel/+translate
[04:11] <spiv> Looks like a dumb bug, actually :/
[04:11] <Lathiat_> and the firefox link ends up with "page not found"
[04:11] <spiv> AssertionError: No page title in canonical.launchpad.pagetitles for sourcepackage_translate
[04:12] <Lathiat_> ex: https://launchpad.net/distros/ubuntu/breezy/+sources/firefox/+gethelp
[04:20] <stub> Bah - I''ve just been working on improving script logging and realized it is a use case for the old Librarian API where the Librarian creates the LibraryFileAlias and LibraryFileContent records and commits rather than the client :-P
[04:20] <lifeless> rotfl
[04:29] <stub> spiv: Am I correct in that the Librarian will still generate the db records if you don't send the File-Content-Id or File-Alias-Id headers (as the docstring I'm reading suggest)?
[04:32] <stub> spiv: And if so, any thoughts on how to expose this in ILibrarianClient ? addFile returns the LibraryFileAlias, so it isn't approprate and we would need another method to stuff a file into the Librarian and return the URL (which has different transaction semantics of course, since the file will exist in the database but the client can't see it yet)
[04:32] <jblack> which one bet bzr would be dogfooding?
[04:33] <lifeless> jblack: translation ?
[04:33] <jblack> lifeless vs kiko bet. One of you two gets pie in the face, depending upon bzr dogfooding or not.
[04:34] <lifeless> upon canonical dogfooding bzr for rocketfuel development
[04:34] <lifeless> bzr already dogfoods itself ;0
[04:34] <jblack> Yes. Who's bet which way?
[04:34] <lifeless> I'm one the 'it will be done' side of the bet
[04:34] <jblack> Poor kiko
[04:36] <spiv> stub: So, yes, the librarian still supports both ways.
[04:37] <spiv> (although up till now the plan was to slowly phase out the server-side ID generation...)
[04:38] <stub> I'm thinking of adding 'stuffFile' as a method to ILibrarianUploadClient which stuffs a file into the Librarian so it won't get rolled back. I can't think of a better name ;-/
[04:38] <spiv> stub: Yeah, a method that just returns the IDs and/or URL would make sense.
[04:38] <spiv> stub: And to retrieve the file, a 'getStuffed' method ;)
[04:38] <stub> spiv: The use case I have is I want to stuff the tracebacks into the Librarian instead of spitting them out, which will greatly improve our cronjob spam.
[04:38] <stub> hehe...
[04:39] <stub> (so one extra line - the url - insteead of a dozen)
[04:40] <lifeless> or a hundred
[04:40] <lifeless> sweet
[04:40] <spiv> stub: Hey, cute trick :)
[04:41] <stub> Any better names, or will I go with stuffFile (with an XXX saying it should be renamed to something that describes the difference in transaction handling between it and its couterpart addFile, and why they must return different things)
[04:42] <spiv> stub: Hmm.
[04:42] <lifeless> so maybe 'serverAddFile' ?
[04:43] <lifeless> or remoteAddFile
[04:43] <lifeless> or justTakeTheFuckingFile
[04:43] <spiv> Or add a serverOnlyDB=True flag to addFile.
[04:43] <spiv> Although that feels a bit wrong.
[04:43] <stub> storeTheFuckingFileNowDammitSheIsGoingToBlow
[04:43] <lifeless> yes
[04:43] <lifeless> I vote the blow
[04:43] <spiv> Even though it doesn't change the return types at all, just most of the implementation ;)
[04:44] <stub> spiv: We need a new method since the return types will be different (can't return a LibraryFileAlias as it isn't yet visible to the client)
[04:45] <spiv> stub: Hm, it looks to me like it's returning ints, not objects.
[04:46] <spiv> Or I'm looking at the wrong layer :)
[04:46] <stub> eh? Oh. If I returned an int, it would be a useless one. A URL is useful straight away, unlike the id.
[04:47] <spiv> Yeah, if you use getUtility(ILibrarianClient).addFile(...) you'll get an int.  Hmm, annoyingly it ditches the content id, only returns the alias id, so you can't reconstruct the URL... looks like a new method is the way to go, then.
[04:49] <spiv> But a method on ILibrarianClient makes sense, rather than ILibraryFileAliasSet (because you don't want it to return an ILibraryFileAlias)
[05:02] <spiv> stub: Can you make a note somewhere on the LibrarianTransactions spec about this?  The "Future directions" there is assuming this is a YAGNI.
[08:23] <stub> spiv: line 140 of lib/canonical/librarian/web.py seems to indicate that the librarian assumes a 1:1 relationship between libraryfilealias and libraryfilecontent
[08:36] <stub> spiv: Actually, make that lib/canonical/librarian/db.py line 22
[08:36] <stub> That method cannot be implemented with the current signature
[08:37] <spiv> looks, rather
[08:42] <spiv> stub: All that assumes is that (contentID, filename) is unique in LibraryFileAlias.  That's not assuming 1:1 between alias and content.
[08:43] <stub> That is an incorrect assumtion
[08:43] <spiv> Yeah, it is.
[08:43] <spiv> (it used to be ok)
[08:44] <stub> It has never been ok
[08:45] <stub> I'm just poking it a bit on my branch  to see if that is the only case and if it is a simple fix
[08:45] <spiv> Well, it used to be intentional.  The design thinking behind that decision might not have been ok, though ;)
[08:46] <spiv> At a glance, it shouldn't be too hard to fix.
[08:47] <spiv> And will almost certainly involve removing much more code than needs to be added.
[08:48] <spiv> The main addition looks to be that LibrarianStorage will need a 'getAlias(aliasID) -> LibraryFileAlias' or similar method for c.l.web.LibraryFileAliasResource to use instead of getFileAlias.
[09:02] <SteveA> hi
[09:04] <stub> morning
[09:08] <sabdfl> SteveA: morning
[09:08] <SteveA> hi mark
[09:08] <sabdfl> SteveA: is it possible to have a required: for a particular dbschema value?
[09:09] <sabdfl> like context/status/enum:CLOSED
[09:11] <SteveA> do you want to show something on a page only when a dbschema has a particular value?
[09:11] <SteveA> i'm trying to understand what you are asking.  it doesn't make sense to me yet.
[09:12] <sabdfl> yes
[09:13] <sabdfl>
Reopen this Ticket

[09:13] <sabdfl> is what i'd like
[09:13] <SteveA> i see
[09:13] <sabdfl> though enum: is ugly
[09:14] <SteveA> enum-value-is:CLOSED ?
[09:14] <SteveA> the way you'd do that now is either write a method on the view class to say isClosedTicket(), and use view/isClosedTicket in your tal:condition
[09:14] <SteveA> or use a python: expression in the page template
[09:15] <SteveA> it would be quite easy and quick to add enum:CLOSED or enum-value-is:CLOSED
[09:15] <SteveA> that returns a boolean, etc.
[09:16] <SteveA> say, 50 loc max with another 50 lines of doctest documentation
[09:19] <SteveA> sabdfl: decide on a name, and i'll do it this morning while i'm still waking up properly ;-)
[09:20] <sabdfl> enum-value
[09:26] <SteveA> so, tal:condition="context/status/enum-value:CLOSED"
[09:39] <sabdfl> moin moin, Keybuk
[09:39] <sabdfl> SteveA: yes please
[09:40] <Keybuk> heyhey
[09:41] <SteveA> sabdfl: underway
[09:41] <sabdfl> guys, i need good names for the support ticket tracker, and the spec tracker
[09:42] <sabdfl> are we tracking bugs on rosetta, malone, rest-of-launchpad, or are they all launchpad?
[09:43] <SteveA> i tend to say to people "hey, have you considered using launchpad as your bugtracker for FooProject"
[09:43] <SteveA> but, i say "have you considered using Rosetta to translate BarProject"
[09:43] <SteveA> so, i think launchpad spec tracker, lauchpad ticket tracker, are good names
[09:44] <SteveA> (or other names in that slightly dull ilk)
[09:45] <SteveA> Keybuk: any idea why this might be?
[09:45] <SteveA> steve@zeus8 /scratch/dists/launchpad $ baz archive-mirror
[09:45] <SteveA> corrupt archive found (mname and mirror_of mismatch<EMAIL_ADDRESS>name<EMAIL_ADDRESS>mirror_of sure
[09:45] <SteveA> Unable to connect to any mirror for archive<EMAIL_ADDRESS>[09:45] <SteveA> these seem to involve some of the things i had to change with jblack yesterday, to get my archives resigned
[09:46] <Keybuk> SteveA: the archive is registered in ~/.arch-params/archives/<SOMETHING> but if you go contact the archive, it's =meta-info/name is something else
[09:46] <SteveA> stevea<EMAIL_ADDRESS>cat name
[09:46] <SteveA><EMAIL_ADDRESS>[09:46] <Keybuk> uh
[09:46] <Keybuk> =meta-info/mirror
[09:46] <Keybuk> sorry
[09:47] <Keybuk> $ cp name mirror -- should fix it
[09:47] <SteveA> ok
[09:47] <SteveA> Keybuk: nice.  it works.  thank you.
[09:56] <SteveA> sabdfl: enum values are sometimes None, iirc.  So, you'll want to be able to say enum-value:None I think.
[09:57] <sabdfl> SteveA: as a special case, yes
[09:59] <sabdfl> stub: please could you look at<EMAIL_ADDRESS>?
[09:59] <sabdfl> patch 25-97-0?
[10:00] <sabdfl> adds a few tables, and some minor tweaks (index, and some extra fields on product)
[10:00] <sabdfl> has comments.sql too
[10:01] <SteveA> darn, None is a bit awkward in that it is lossy.  With any other kind of dbschema item, i can inspect it, and ask it for what are valid values for it.  For None, I don't even know that it came from a dbschema value, so it has to just two possibilities: enum-value/None or enum-value/(anything else).
[10:02] <SteveA> on reflection, i'd prefer not to have None in dbschema, but allow the value of a dbschema item to be None, so it is NULL in the database, yet have it refered to in code as a standard dbschema item.
[10:02] <SteveA> (a future refactoring perhaps)
[10:03] <SteveA> still, easy to work around now.  but, we lose some error checking in the case of None.
[10:15] <sabdfl> we don't really need NULL dbschema items
[10:15] <sabdfl> stub: pls ack on the db patch?
[10:23] <carlos> morning
[10:27] <SteveA> hi carlos
[11:29] <SteveA> sabdfl: tracked down the bug in page templates that doesn't allow '-' in page templates.  proposed a fix on the zope3 / page templates list, and with fred drake (maintainer).  enum-values branch up for review.  some minor improvements since you merged.
[11:29] <SteveA> back to menus ;-)
[11:35] <lifeless> damn I'm good. pqm using config-manager now passes tests.
[11:35] <lifeless> kiko-zzz: prepare for a PIE.
[11:39] <lifeless> now for getting configs from bzr branches.
[11:41] <cprov> jamesh: ping
[11:45] <jamesh> cprov: pong
[11:49] <cprov> jamesh: do have any ETA for review my branches in you queue ?
[11:54] <SteveA> aw crap
[11:54] <SteveA> people have added in YET MORE WARNINGS
[11:54] <SteveA> i'm going to fix the existing ones, or get other people to fix them, and make warnings into errors when running tests
[11:57] <lifeless> warnings from your db nazi ?
[11:58] <SteveA> no
[11:58] <SteveA> just warnings
[11:58] <SteveA> warnings about ambiguous sql query results
[11:59] <SteveA> i fixed all of them before brazil
[11:59] <SteveA> well, salgado fixed some
[11:59] <SteveA> now they're back
[11:59] <SteveA> BjornT, bradb-away : these all seem to be in malone code
[12:01] <SteveA> The method BugTaskReleaseTargetingView.createTargetedTasks
[12:01] <SteveA> request url: http://localhost:9000/distros/debian/+bugs/1/+target
[12:01] <SteveA> The method PersonView.setUpAssignedBugTasksToShow
[12:01] <SteveA> request url: http://localhost:9000/people/sabdfl/+assignedbugs
[12:01] <SteveA> The method PersonView.__call__
[12:01] <SteveA> request url: http://localhost:9000/people/sabdfl/+assignedbugs
1: UserWarning: Getting a slice of an unordered set is unpredictable.
[12:01] <SteveA>
[12:01] <SteveA> the last one is almost certainly from a system doc test or a page test
[12:01] <SteveA> the others are in code and need sorting out
[12:02] <cprov> SteveA: Soyuz has some critical queries as well.
[12:03] <SteveA> critical?
[12:03] <BjornT> SteveA: ok. i didn't add those, but i can take a quick look to see if it's easy to fix
[12:03] <SteveA> okay.  do you know if brad added those?
[12:03] <stub> sabdfl: ack.
[12:03] <SteveA> once these are all fixed, we can make the warnings errors so that they won't occur again.
[12:03] <stub> sabdfl: Please stick review requests on the wiki so I can't lose them ;)
[12:04] <BjornT> SteveA: i'm not sure, but he did the release targeting, so i'd assume he added them.
[12:07] <cprov> SteveA: they generate lot of random warnings and are slow, they need polishing
[12:07] <SteveA> cprov: i don't see the warnings when i run tests
[12:07] <SteveA> cprov: are they not in RF yet?
[12:08] <cprov> SteveA: they are, soyuz is not entirely  tested atm.
[12:08] <SteveA> well, that's shite.
[12:09] <SteveA> if there's no tests, then the code is kinda broken by default.
[12:09] <cprov> SteveA: indeed, we can't trust
[12:09] <SteveA> we need to know the extent of the problem
[12:10] <SteveA> like, what modules / classes / functions are not tested
[12:10] <SteveA> list these, so we know how big the problem is
[12:10] <SteveA> right now, i have no idea how much of a problem this is, or how much work it is to rectify
[12:12] <cprov> SteveA: I totally agree and feel the same about soyuz code, it's generally bronken and we don't know it, it's always a surprise.
[12:13] <SteveA> okay.  we must organise an audit.
[12:13] <SteveA> if we don't know exactly what the problem is, we can't fix it
[12:13] <Kinnison> Indeed. Rolling this into the meeting item I suggested in /msg seems like a good plan
[12:15] <SteveA> separate item
[12:15] <SteveA> it
[12:15] <SteveA> is on the agenda
[12:15] <Kinnison> okay
[12:15] <sabdfl> stub: is there a place to stick dba-only reviews?
[12:16] <SteveA> end of PendingReviews page
[12:16] <SteveA> there is a DBA section
[12:16] <sabdfl> ah. cool. thanks
[12:16] <BjornT> SteveA: in PersonView.setUpAssignedBugTasksToShow there's an XXX about the warning, no author, though...
[12:16] <SteveA> argh
[12:16] <SteveA> how does this stuff get past review?!
[12:17] <BjornT> well, it's not impossible that it was one of kiko's trivials
[12:18] <sabdfl> stub: added to wiki
[12:19] <sabdfl> jamesh: ping
[12:23] <jamesh> sabdfl: yeah?
[12:25] <sabdfl> jamesh: howdy. please could you take a look at the Specification infrastructure that i landed last week, and ping me so we can have a quick chat about a bof-o-matic scheduler?
[12:25] <sabdfl> database/specification*
[12:26] <sabdfl> shows up on product and distribution as a "Specs" tab, and also an "Add Feature Specification" action item
[12:26] <jamesh> okay
[12:27] <stub> sabdfl: Do you want constraints on the ticketing table, eg. only assigned to a distribution/sourcepackagename or a product? Or can a ticket be opened on 1 product and 1 sourcepackage/distro simultaneously
[12:32] <BjornT> SteveA: i can fix the first warning. the other i'm not sure exactly how to fix, they were added by salgado, though.
[12:32] <SteveA> okay.  please do fix the first one
[12:33] <SteveA> we can talk together about the others, and with salgado, later today or tomorrow when you're at pov
[12:33] <sabdfl> stub: see the comments :-)
[12:34] <sabdfl> but yes, i was planning to relax that constraint
[12:34] <sabdfl> a sort of "push upstream" feature
[12:34] <jordi> stub: saw my request to remove some English po files from plone?
[12:34] <sabdfl> probably from distro -> upstream more than from upstream -> distro(s)
[12:34] <jordi> stub: please ignore it
[12:37] <stub> jordi: ok.
[12:37] <stub> jordi: I wasn't sure if it was possible anyway without much work ;)
[12:38] <stub> sabdfl: The commends said the constraint, so I just added them in. Shall we leave them there and drop them if we add that feature?
[12:40] <jordi> stub: hmm. that's not cool. At some point i'll need it for real :)
[12:42] <lifeless> jamesh: is your review-branch script source around somewhere ?
[12:42] <lifeless> jamesh: I want to bzrify it
[12:44] <stub> jordi: Probably best if we add a feature to hide or deactivate them (which means we get too keep all the information linked to them).
[12:44] <jamesh> lifeless<EMAIL_ADDRESS>[12:45] <sabdfl> stub: +1 on hiding pofiles rather than removing them
[12:45] <sabdfl> they will Just Come Back (tm)
[12:53] <jordi> yup. As long as people can't click on them to translate the Evil Useless PO.. :)
[01:03] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Final bits for launchpad-buildd package 2 (patch-2336<EMAIL_ADDRESS>[01:04] <Kinnison> Meeting-00:55
[01:06] <jblack> stevea: Here?
[01:06] <SteveA> #canonical-meeting
[01:07] <vinsci> morning, carlos
[01:07] <carlos> vinsci, morning
[01:10] <sabdfl> ddaa: before we meet next week, please could you clear out IBranch so that it looks more like ITicket, and we can start using it immediately?
[01:10] <sabdfl> i think you'll need to move it to IPyBazBranch or something, to free up the namespace
[01:11] <sabdfl> err... no ddaa
[01:14] <sabdfl> morning salgado
[01:15] <salgado> yo sabdfl!
[01:15] <salgado> stub, around?
[01:22] <sabdfl> morning niemeyer
[01:23] <sabdfl> niemeyer: can we take some time to catch up today? in the next two hours or so, before i head to south africa?
[01:23] <stub> salgado: yes
[01:23] <SteveA> launchpad meeting in 25 mins
[01:23] <niemeyer> Good morning!
[01:24] <niemeyer> sabdfl: Sure!
[01:24] <niemeyer> sabdfl: I'll be a little bit off today because I'm installing Ubuntu on the notebook, but we can certainly do that
[01:25] <niemeyer> SteveA: Where's the meeting? Here?
[01:25] <salgado> stub, can you hold the production tag until (your) tomorrow morning, and review the shipit DB patch for me? (I really need to get this in the next rollout)
[01:25] <SteveA> niemeyer: yes, here
[01:25] <SteveA> niemeyer: lasts exactly 45 minutes
[01:25] <niemeyer> Ok.. my /home/niemeyer backup should be finished by then.. :-)
[01:26] <stub> salgado: ok
[01:26] <Kinnison> stub: what is your tomorrow morning?
[01:27] <salgado> stub, here's the last version of the patch. it's not going to be changed before I merge everything. https://chinstrap.ubuntu.com/~dsilvers/paste/fileyzrigW.html
[01:31] <stub> Kinnison: Probably about 16 hours time
[01:32] <niemeyer> sabdfl: Please, ping me when you're ready
[01:32] <Kinnison> salgado: any idea when you'll be okay to merge?
[01:33] <salgado> Kinnison, it has to be in less than 10 hours, so that's what will be
[01:35] <stub> salgado: You got comments for me to look at too?
[01:37] <carlos> stub, did you see my email about the whitespace migration script?
[01:37] <salgado> stub, oh, shit. I forgot that. will write now
[01:37] <stub> carlos: yes, but havn't got there yet sorry.
[01:38] <SteveA> salgado: can you talk with bjorn please about the warnings that some person/bug pages and code is generating?
[01:38] <salgado> SteveA, sure. I do remember we talked about this problem though. and we didn't find what caused them
[01:39] <SteveA> i thought we did, and you had a plan for fixing them
[01:39] <carlos> stub, ok, if you can do that before leaving today that would be really good so I could get some data tomorrow
[01:39] <SteveA> okay, i'll look into it later
[01:39] <SteveA> maybe with bjorn tomorrow
[01:40] <salgado> SteveA, yes, the problem is n PersonView.setUpBugTasksToShow(). there's an XXX there. but as the comment says, everything there has an oderBy
[01:41] <stub> salgado: It all seems fairly clear except for ShockAndAwe, so they can be done later if you have a deadline
[01:42] <salgado> stub, okay. I'll do for the shock and awe and try to do for some others. anyway I'll leave an XXX in the DB patch to remind me to do that. do you think it's a problem?
[01:43] <stub> A bug report is better, and you can just describe shockandawe to me now if you would rather.
[01:46] <salgado> stub, okay. the shock and awe is the name of a program. we'll be sending some computer shops (and maybe other shops?) a letter with some information about shipit and a token. then they'll be able to login with that token (their account is already created by one of the ShipIt admins) and place a request
[01:46] <SteveA> launchpad meeting soon.  /msg me items for the meeting
[01:47] <stub> salgado: But what goes in the table?
[01:49] <salgado> stub, ah, each row contains only the information about a specific shock and awe program, and that can be linked to the ShippingRequest table
[01:53] <sabdfl> bradb: what is your current spec pipeline?
[01:55] <bradb> BugInContext (not yet approved, just wrote it yesterday, blocks BugAndTaskPageURLs) and then implement MaloneSearchResults on the other bug listings (the first merge only implements it on the sp bug listing page.) After that, it depends entirely on what else is part of MaloneOneDotZero (I did extensive gardening lately to make it easy for others to tell me what I understand 1.0 to be, what spec statuses are, etc. but haven't heard
[01:57] <kiko-zzz> GMV
[01:57] <bradb> er, that is, i did extensive gardening to record what I understand MaloneOneDotZero to be, to give others a prelim. list and be able to say "yeah, that looks good" or "add this, remove this, etc."
[02:00] <SteveA> MEETING TIME
[02:00] <kiko> so it is
[02:00] <kiko> and I'm here
[02:00] <SteveA> all present, please yawn^w say Aye!
[02:00] <spiv> Aye!
[02:00] <jblack> Aye
[02:00] <carlos> Aye!
[02:00] <bradb> aye
[02:00] <Kinnison> Aue!
[02:00] <BjornT> aye
[02:00] <Kinnison> erm, s/u/i/
[02:00] <salgado> aye
[02:01] <cprov> here
[02:01] <lifeless> aye
[02:01] <cprov> aye
[02:01] <SteveA> morgs sends apologies
[02:01] <SteveA> daf is off sick
[02:01] <SteveA> niemeyer: around?
[02:01] <kiko> mpt is off sick
[02:01] <SteveA> ddaa is on vacation, isn't he?
[02:02] <SteveA> stub: ?
[02:02] <stub> yer
[02:02] <SteveA> debonzi is at university
[02:02] <SteveA> anyone not accounted for?
[02:02] <SteveA> as usual, /msg me extra agenda items as we go along
[02:02] <kiko> SteveA, I'm giving niemeyer a ring
[02:03] <SteveA> okay.  he had a phone call with mark
[02:03] <SteveA> so, maybe that is still going on
[02:03] <SteveA> he was around a little earlier
[02:03] <jamesh> here
[02:03] <SteveA> hi james
[02:03] <SteveA> jordi?
[02:04] <SteveA> hi mpt.  how are you feeling?
[02:04] <SteveA> let's move onwards
[02:04] <SteveA> == Agenda ==
[02:04] <SteveA>  - roll call
[02:04] <SteveA>  - agenda
[02:04] <SteveA>  - next meeting
[02:04] <SteveA>  - production / staging
[02:04] <SteveA>  - who can work on soyuz ui?
[02:04] <SteveA>  - soyuz not tested
[02:04] <kiko> niemeyer apparently wasn't notified of the meeting, so I apologize for him -- he's currently out getting a hard drive to swap into ubuntu
[02:04] <SteveA>  - defining malone 1.0
[02:04] <SteveA>  - three sentences
[02:04] <SteveA>
[02:04] <mpt> SteveA: a bit light-headed, but better
[02:04] <mpt> thanks
[02:04] <SteveA> we called the roll, displayed the agenda
[02:04] <SteveA> next meeting: same time next week?
[02:05] <kiko> yes
[02:05] <Kinnison> Aie.
[02:05] <carlos> SteveA, yes
[02:05] <kiko> IOW, not 22h ago
[02:05] <stub> yo
[02:05] <cprov> yes
[02:05] <SteveA>  - production / staging
[02:05] <SteveA> stub: ?
[02:06] <stub> The usual. Staging running fine daily updates, production will be tagged when salgados shipit feature branch lands
[02:06] <SteveA>  - activity reports
[02:06] <kiko> stub, the database on staging hasn't been refreshed in a while, right?
[02:06] <stub> so tomorrow or saturday I expect
[02:07] <kiko> lifeless, in this particular instance, we should have -- I miscommunicated with stub
[02:07] <stub> staging db should be refreshed daily
[02:07] <kiko> stub, it would help if you /didn't/ cut exceptions, even for you-know-who -- policy is policy
[02:08] <kiko> stub, interesting -- carlos said it wasn't being refreshed because of the rosetta update
[02:08] <kiko> carlos?
[02:08] <carlos> kiko, I asked stub to refresh it today before next script run
[02:08] <stub> I switched it back on around tuesday
[02:08] <kiko> ah, okay
[02:08] <niemeyer> Here! Here :-)
[02:08] <carlos> perfect
[02:09] <SteveA> hi niemeyer
[02:09] <SteveA> ready to move on?
[02:09] <SteveA> (to stub)
[02:09] <stub> yup
[02:09] <SteveA>  - activity reports
[02:09] <carlos> stub, please disable it again this weekend (at least until Friday night in Europe) so I can get new language packs to test latest changes
[02:09] <stub> carlos: i will
[02:09] <carlos> stub, thank you
[02:09] <SteveA> ugly ducklings vs sailing on swan lake
[02:09] <jblack> uptodate (last 2 went in 5 minutes ago)
[02:10] <bradb> the usual
[02:10] <kiko> ugly as ugly can be, but will this time start over
[02:10] <cprov> stub: any news about gina run in production ?
[02:10] <mpt> up to date
[02:10] <spiv> I'm a few behind.
[02:10] <jamesh> sending in one for yesterday (restarting)
[02:11] <SteveA> zappa!
[02:11] <SteveA> anyone else?
[02:11] <kiko> yourself?
[02:11] <kiko> ah
[02:11] <SteveA> i represented
[02:11] <kiko> sorry, the /mes get me sometimes
[02:11] <SteveA> okay, moving on
[02:12] <SteveA> as there's no bot to help out, if i missed anyone, speak up
[02:12] <SteveA>  - who can work on soyuz ui?
[02:12] <SteveA> so, daf was scheduled to take some time out of rosetta development to improve the soyuz pages
[02:12] <kiko> nobody's really free at the moment
[02:12] <SteveA> but, daf is on sick leave
[02:12] <kiko> I'm interviewing for replacements
[02:12] <SteveA> mark has plans to do some model refactoring in soyuz that makes the pages easier to write
[02:12] <kiko> we have quite a few good prople
[02:12] <SteveA> debonzi is at uni
[02:13] <SteveA> interviews went well?
[02:13] <kiko> prople? where did that come from?
[02:13] <kiko> yes, lots of good people, too.
[02:13] <lifeless> up to date
[02:13] <kiko> we'll have winners declared next week, I'll have them have a phone call with you before approving
[02:13] <SteveA> okay, cool.
[02:13] <SteveA> so, the answer is, no soyuz ui work for a little while
[02:13] <SteveA> but some end in sight
[02:14] <SteveA> cprov, Kinnison: any other points on this issue?
[02:14] <mpt> cprov, I started the build farm work on Tuesday, continuing that this morning
[02:15] <Kinnison> For now it's not too bad
[02:16] <Kinnison> Mark's model refactoring will probably have to happen before someone works on the UI
[02:16] <SteveA> okay, that's at least a week off happening
[02:16] <SteveA> even at mark's speed
[02:16] <Kinnison> Indeed.
[02:16] <SteveA> moving on...
[02:16] <SteveA>  - soyuz not tested
[02:16] <cprov> mpt: great, do what you think is necessary to get it ready for review as soon as possible, I'm having merge conflicts on it
[02:16] <Kinnison> This is a big task
[02:16] <SteveA> large chunks of soyuz are NOT TESTED
[02:16] <SteveA> this is simply awful
[02:16] <Kinnison> As cprov and I sprint, we are improving the tests on the backend
[02:17] <mpt> cprov: I should get it done by the end of today
[02:17] <Kinnison> However the UI is pretty much utterly untested
[02:17] <SteveA> i propose that cprov spend some time on a mini-audit
[02:17] <Kinnison> Which, as stevea says, is utterly awful
[02:17] <cprov> mpt: fantastic ! you rock
[02:17] <SteveA> listing pages, content classes, functions, view classes
[02:17] <SteveA> and whether they are tested or not
[02:17] <SteveA> so we have an idea of what coverage we have
[02:17] <SteveA> and where we need to improve
[02:17] <Kinnison> SteveA: This audit will be a useful thing, and I suggest it should be the first thing cprov does upon his return to brazil
[02:17] <SteveA> what do you think cprov ?
[02:18] <cprov> SteveA: uhm , it's ok
[02:19] <SteveA> bradb developed a naming pattern for the tests of view classes
[02:19] <SteveA> please describe that brad
[02:19] <spiv> There's a "--trace" option in test.py that can apparently generate code coverage stats.  It may assist in the auditing process?
[02:19] <SteveA> yeah, i've used coverage stats before
[02:19] <bradb> I've been calling doctests that test views doc/*-pages.txt
[02:19] <Kinnison> coverage stats would be nice to have
[02:19] <cprov> SteveA: would be nice to do it with the guy who will replace debonzi ... transfering knowledge personally. but I'm not in a position to decide it exactly now (kind of overloaded with buildd stuff)
[02:19] <SteveA> but, i think unless cprov or someone else wants to look into that, we should put that off a little
[02:20] <lifeless> IME writing tests for existing code is _very very_ hard.
[02:20] <SteveA> writing minimal tests is very very easy
[02:20] <bradb> An example of a view test would be bug-release-targeting-pages.txt, if anyone's interested
[02:20] <lifeless> its hard because you don't know what the code is meant to do, or what boundary conditions to expect.
[02:20] <SteveA> writing thorough tests is very very hard
[02:20] <jordi> SteveA: pong
[02:20] <SteveA> we don't even have minimal tests
[02:20] <SteveA> hi jordi.  how are you activity reports?
[02:20] <SteveA> s/you/your/
[02:21] <cprov> SteveA: depends of which kind of code .. soyuz does not support easy tests other than simple pagetest, which doesn't help a lot, IMO
[02:21] <SteveA> so, as bradb indicates, the convention is to have a -pages.txt file in canonical/launchpad/doc/ rather than a ...txt file
[02:21] <Kinnison> pagetests will definitely be good
[02:21] <SteveA> we should have a test of the basic functionality of all database classes
[02:21] <SteveA> and all view classes
[02:21] <jamesh> so that's doc/foo-pages.txt corresponding to browser/foo.py, right?
[02:22] <SteveA> jamesh: yes
[02:22] <lifeless> it would be really really nice if everyone did TDD
[02:22] <niemeyer> Is there any documentation about what soyuz currently does and what we want it to do?
[02:22] <bradb> jamesh: sometimes it makes sense to break it down further than that though, of course
[02:22] <lifeless> its really not slower than code + test.
[02:22] <spiv> lifeless: Something to schedule for UBZ?
[02:22] <jamesh> bradb: okay.  I guess foo-*-pages.txt then?
[02:22] <lifeless> niemeyer: wiki.launchpad.canonical.net
[02:22] <lifeless> erm
[02:22] <cprov> Kinnison: workarround, because when something brake you get the real taste of the bad code, spend a lot of time to fix ...
[02:22] <lifeless> canonical.com
[02:22] <bradb> jamesh: yes, more or less, i think
[02:23] <Kinnison> aye
[02:23] <SteveA> lifeless: we can agree that TDD is a very fine thing, and we should encourage / train people to do more of it.
[02:23] <SteveA> lifeless: i don't want to muddy the current agenda item, though
[02:23] <lifeless> ok.
[02:23] <niemeyer> lifeless: So it does exist? Nice, will have a look at that later.
[02:24] <SteveA> cprov: do you think it is possible to do the following for soyuz:
[02:24] <SteveA>  - every page has a page test that shows at least that it gives the correct HTTP response (200 usually)
[02:24] <kiko> niemeyer, well, /all/ that exists is there (well, there's also the /documentation/, but you knew that)
[02:25] <SteveA>  - every database class (Foo or FooSet) has a test that shows it can be imported, got from the database, and trivially used in some way
[02:25] <kiko> SteveA, shouldn't we use a bot to cover that, though?
[02:25] <kiko> SteveA, is there a way of generating a list of all pages we serve on launchpad?
[02:25] <SteveA>  - every view class has a test that shows it can be imported
[02:26] <SteveA> kiko: for the page tests, we could automate that, but i'm asking cprov if something is feasible, not how to do it.
[02:26] <stub> kiko: That involves writing a bot, whereas typing up a list of 20/30 ceck(url) lines is quick
[02:26] <SteveA> kiko: cprov seemed to say that testing soyuz was not feasible.
[02:26] <niemeyer> kiko: It was just a silly question.. looking for a silly yes/no answer before going out hunting docs. :-)
[02:26] <kiko> oh
[02:26] <SteveA> cprov: do you think those three things are basically feasible ?
[02:27] <cprov> SteveA: looks useful, but I'm about to suggest group the things by functionality in launchpad/doc/ as we are doing ...
[02:27] <SteveA> i'm not talking about where to put things, or how to group things
[02:27] <SteveA> these tests largely do not exist for soyuz
[02:27] <SteveA> so, i'm setting a baseline of test coverage for soyuz
[02:27] <cprov> SteveA:  a minimal of indexing sense, just to make the this easier for future
[02:27] <SteveA> that does not involve any particular reverse-engineering of what the test should be
[02:28] <cprov> SteveA: the simple answer is: yes, something like this is feasible
[02:28] <SteveA> and does not require the bureaucracy of an audit with a wiki page table
[02:28] <SteveA> okay, please file a bug on getting that base-line done.
[02:28] <kiko> stub, well, a bot to access a list of pages and check the error response code is something I could do in a minute
[02:29] <kiko> but my question is -- is there infrastructure to generate a list of URLs for the current instance?
[02:29] <cprov> SteveA: I can file a bug, but I'm not in touch of it until finish the buildd sprint, is it ok ?
[02:29] <SteveA> it isn't really a bot, but something that can import the http() method used in page tests
[02:29] <kiko> right
[02:29] <SteveA> and use it based on some calculation of urls
[02:29] <SteveA> i think that would be useful in addition to the usual page tests
[02:29] <kiko> is the calculation of urls non-trivial?
[02:29] <niemeyer> kiko: There's also mechanoid, if something fancier is needed.
[02:29] <SteveA> but, our page tests have like paragraphs and stuff
[02:30] <kiko> yeah
[02:30] <kiko> I'm talking about a trivial HTTP status reporter
[02:30] <SteveA> we're getting some nice pagetest stuff from upstream zope real soon now
[02:30] <stub> lib/canonical/launchpad/pagetests/standalone/xx-notfound-traversals.txt
[02:31] <kiko> stub, well, that's a manually kept list
[02:31] <SteveA> cprov: yes, filing the bug and doingn later is fine, provided the bug says exactly what the plan is.
[02:31] <kiko> can /anyone/ answer my question?
[02:31] <SteveA> kiko: i have a few suggestions on how to do it
[02:31] <SteveA> kiko: can we takl about it later?
[02:31] <kiko> sure.
[02:31] <SteveA> okay
[02:31] <SteveA> kiko: can you write said "all page status testing" code, and we'll talk about how?
[02:32] <stub> kiko: We want the manual list too to ensure stuff doesn't disappear accidently unless we can generate a list of what shoud be there rather than crawl what is there.
[02:32] <SteveA> i think it will be a valuable thing to catch basic errors where there aren't enough tests
[02:32] <kiko> yes
[02:32] <SteveA> i agree we want a "manual" pagetest in addition
[02:32] <kiko> stub, I understand your point, but we need both, really
[02:32] <kiko> a manual list of URLs is usefu
[02:32] <SteveA> can i move on?
[02:32] <kiko> l
[02:32] <kiko> yes
[02:32] <SteveA>  - defining malone 1.0
[02:32] <stub> kiko: The crawler could generate a list, and we just rerun the crawler to regenerate it occasionally
[02:33] <SteveA> brad asks about defining "malone 1.0" in more detail
[02:33] <SteveA> and pinning things down
[02:33] <kiko> okay
[02:33] <kiko> that's really on my plate
[02:33] <SteveA> can i get kiko and brad to talk about that, maybe next week?
[02:33] <kiko> well
[02:34] <kiko> I haven't concerned myself completely with that yet because I know that brad has enough for the following weeks
[02:34] <kiko> I am concerned however whether BjornT has been helping brad get these tasks done
[02:34] <bradb> I'm free to talk about it whenever. The wiki is yours for the taking.
[02:34] <kiko> I need to move the wiki to the spectracker
[02:34] <cprov> SteveA: bug # 2017
[02:34] <kiko> it's a lot of specs
[02:35] <SteveA> thanks cprov
[02:35] <BjornT> kiko: i've been helping, and i also have a few things assigned to me that i will do this coming week
[02:35] <bradb> kiko: Haven't looked at the spec machine much, but that sounds like it will be a better way to workflow and see this stuff presenting in an easy-to-manage way.
[02:35] <kiko> okay
[02:35] <cprov> SteveA: yup
[02:35] <kiko> BjornT, bradb's been in need of someone to pair on him for a design discussion on how to go forward with the structure for the bug and status pages/portlets
[02:35] <kiko> you know the architecture well and are a smart thinker, you really should be a part of it
[02:36] <BjornT> sure
[02:36] <kiko> BjornT, IOW if bradb's hampered for a lack of design discussion, it's /your/ responsibility <wink>
[02:37] <BjornT> kiko: isn't it better if brad comes to me and ask for help instead? ;)
[02:37] <kiko> no
[02:37] <bradb> I'll have a code snippet added to BugInContext, which will make it easier for others to understand what is one of the most challenging problems to solve in the new URL structure, that I've seen.
[02:37] <kiko> it's better if you stay in touch with him daily -- you are a team, not a helpdesk
[02:37] <bradb> (i.e. I'll have that ready not long after the meeting.)
[02:38] <kiko> I haven't forgotten your specs, bradb -- it's on my desk
[02:38] <kiko> we can move on
[02:38] <bradb> BjornT: One thing that would be really useful is to press for those branches to get reviewed. I think.
[02:38] <bradb> But that's a side discussion, please feel free to continue.
[02:38] <SteveA> okay, last thing on today's agenda:  three sentences.
[02:38] <SteveA> let's go
[02:39] <bradb> DONE: Landed portlet mania, round I. Got round II (edit pages) into a review queue. Landed MaloneSearchResults. Landed a fix for +hctstatus raising an exception (with test.) Some work on URLs. Wrote BugInContext spec after finally having come up with what I think is a sane context for the new bugish/tasky page.
[02:39] <mpt> DONE: bugfixes, LaunchpadMenus specs, actions portlet cleanup, buildfarm work
[02:39] <mpt> TODO: finish buildfarm work, spec tracker cleanup, LaunchpadMenus
[02:39] <mpt> HINDRANCES: none (modulo LaunchpadMenus reimplementation)
[02:39] <bradb> TODO: Get BugInContext approved and land reconstruct Malone from the URL demolition. Possibly/hopefully implement a request/launchbag:foo TALES adapter. Nag BjornT to review portlet mania, round II.
 Past: advocacy (4/5), coding (1/10), support (1/5)
 Future: advocacy (4/5), coding (1/10), support (1/5)
 Blockers: No time for supermirror.
[02:39] <bradb> BLOCKED: BugInContext approval (blocked on whoever is required to review the braindump for approval.) request/launchbag:foo (to help with BugAndTaskPageURLs portlet code on pages hanging off *Set contexts) will require discussion with SteveA.
[02:39] <Kinnison> DONE: Prep, and sprinting
[02:39] <spiv> DONE: Reviews, add --stop-on-first-failure to test.py, figure out how TacTestSetup can fail and fix it, various ad hoc things on irc.
[02:39] <spiv> TODO: Priority: help get through the review backlog.  Work on TeamLogin & SupermirrorFilesystemHierarchy.
[02:39] <spiv> BLOCKED: No.
[02:39] <kiko> TODO: check rosetta diff output, help carlos through the maze of language packs, start using the spec tracker, try and get a baz branch going
[02:39] <Kinnison> TODO: More sprinting
[02:39] <BjornT> DONE: finished making notifications thread properly. reviews. some bug fixes.
[02:39] <BjornT> TODO: Put up documentation for email ui. PreDefinedBugReports. BugCVEREports. reviews.
[02:39] <BjornT> BLOCKED: no
[02:39] <Kinnison> BLOCKED: Reviewers being overloaded
[02:39] <kiko> BLOCKED: lifeless to assist me with baz blowing up past 1gig
[02:39] <salgado> DONE: ShipItNG, some small fixes.
[02:39] <lifeless> DONE: pqm bzr support, bzr merge helping
[02:40] <stub> DONE: Bugfixes, DBA stoof, script logging and librarian fixes
[02:40] <lifeless> TODO: jamesh merge script bzrification, mgmt foo, fly to london
[02:40] <stub> TODO: script logging niceness and crawler in test suite
[02:40] <stub> BLOCKED: Nada
[02:40] <lifeless> BLOCKed: nada
[02:40] <salgado> TODO: ShipItNG, merge basicvoting as soon as I get it reviewed
[02:40] <carlos> DONE: language packs improvements, user support, db data fixes
[02:40] <SteveA> DONE: changed gpg key, resigned archives, enumvalue TALES, menus work, management, code review
[02:40] <SteveA> TODO: menus work, write art.ubuntu.com authentication spec
[02:40] <SteveA> BLOCKED: no
[02:40] <salgado> BLOCKED: Nothing
[02:40] <kiko> DONE: QA, rosetta assistance, migrating server to hoary, some shipit assistance, lots of little b-n-p
[02:40] <jamesh> DONE: land calendar-ui branch, add person merging code to keyring trust analyser and more tests, look at gettext message validation problem, look into some other bugs
[02:40] <jamesh> TODO: reviews, look at Mark's Specs infrastructure, put gpg stuff up for review, update pending-reviews for new page format
[02:40] <jamesh> BLOCKED: none
[02:40] <carlos> TODO: language packs, bug fixes, fix permission problem  for jordi
[02:40] <carlos> BLOCKED: none
[02:40] <lifeless> kiko: have you tried again, I recached rev 2322 which should fix your problem
[02:41] <kiko> lifeless, I tried again yesterday, let me see today.
[02:41] <kiko> lifeless, what was the issue?
[02:41] <lifeless> there is a leak in baz
[02:41] <kiko> ah
[02:41] <SteveA> bradb: we can talk more about BugInContext later today
[02:41] <lifeless> its kinda noticable if you do lots of rev patching
[02:41] <bradb> SteveA: certainly
[02:41] <SteveA> and the other stuff
[02:41] <bradb> yeah
[02:41] <mpool> DONE: refactorings of tests, UI reporting, other things; improved auto-merge; planning of weave-like tree merge
[02:41] <mpool> BLOCKED: no
[02:42] <SteveA> bradb: are you really blocked on that, as in, have no work to do if that doesn't happen?
[02:42] <lifeless> I've fixed in in my 1.5 branch, I'm planning on doing a merge with the new features disabled just to fix that.
[02:42] <SteveA> mpool: the three sentences are DONE, TODO and BLOCKED, btw
[02:42] <kiko> lifeless, maybe I could pull your branch to test?
[02:42] <bradb> SteveA: not in that sense. i have no problems finding other things that can be worked on. but the critical path is blocked on that.
[02:42] <SteveA> bradb: okay, understood
[02:42] <cprov> TODO: continues buildd sprint
[02:42] <cprov> DONE: buildd sprint
[02:42] <cprov> BLOCK: jamesh review queue
[02:42] <lifeless> kiko: uhm, if you want to - you'll need to build it yourself
[02:42] <mpool> TODO: fix merge bugs, 0.0.7 release, new tree format, merge tests
[02:42] <SteveA> Kinnison: do you have other urgent reviews to have done?
[02:43] <kiko> lifeless, is such an undertaking non-trivial?
[02:43] <mpool> oh in that order? ok
[02:43] <Kinnison> SteveA: Myself and celso as a pair have urgent reviews
[02:43] <Kinnison> SteveA: and we'll be generating more and more as the sprint progresses
[02:43] <SteveA> can we get you assigned a reviewer to specifically help with this for the sprint?
[02:43] <SteveA> kiko: what do you think?
[02:43] <lifeless> kiko: non-trivial yes, very hard - no.
[02:44] <Kinnison> SteveA: that would be useful
[02:44] <spiv> SteveA: I'd be happy to do reviews for Kinnison and cprov.
[02:44] <kiko> SteveA, well, yes, it would be useful, but I am blocked with reviewing shipit and the other unreviewed generals
[02:44] <lifeless> kiko: minimally you'd need to deal with my very verbose printf bombs. There is a HOWTO on the bazaar.c.c site, you should follow that but switch the src/baz directory to mine
[02:44] <lifeless> kiko: my bazaar--project-tree-format--1.5 branch, IIRC.
[02:45] <SteveA> kiko: i wasn't asking you to do it ;-)
[02:45] <kiko> lifeless, hmmm, maybe I won't have time for this soonish then
[02:45] <SteveA> just what you thought of the idea
[02:45] <lifeless> kiko: which is why I did not suggest it.
[02:45] <lifeless> kiko: just try again, it should work.
[02:45] <SteveA> okay, spiv, you're assigned as special soyuz sprint reviewer
[02:45] <kiko> SteveA, I know, but there's not a lot of people that can take up that responsibility
[02:45] <Kinnison> spiv: We're on a very tight schedule -- In particular we're generating large numbers of interrelated changes which need to happen. Are you okay to be quick about this?
[02:45] <SteveA> tiem to wrap up
[02:45] <kiko> * spiv grimaces
[02:45] <SteveA> um time
[02:45] <kiko> 5 4 3 2 1
[02:45] <SteveA> countdown of doom, as usual
[02:45] <SteveA> 3
[02:45] <SteveA> 2
[02:45] <SteveA> ...
[02:45] <jordi> nooo
[02:45] <SteveA> 1
[02:45] <kiko> *
[02:45] <SteveA> END OF MEETING
[02:46] <spiv> Kinnison: I can be quick, modulo the timezone difference.
[02:46] <jamesh> cprov: I'll get your first one finished tonight and the second tomorrow morning or tonight
[02:46] <Kinnison> spiv: star
[02:46] <jordi> sorry, I'm at (other) work, wasn't looking
[02:46] <spiv> Kinnison: And I'll warn you as far in advance as I can if that plan goes awry.
[02:46] <Kinnison> spiv: thanks
[02:46] <kiko> stub, have a few minutes to chat?
[02:46] <stub> sure
[02:46] <jordi> DONE: tons of pending requests, more bug filing, lots of email answering
[02:46] <cprov> jamesh: great, there will be new changes, but they are minimal, thank you
[02:47] <jordi> TODO: answer the few last pending emails from<EMAIL_ADDRESS>email; port FAQs to wiki
[02:47] <bradb> BjornT: so, i was thinking, i noticed that there are a few branches of yours in the general queue, that have been there for over two weeks. have you been hassling anyone about those? (and, speaking of hassling, will you get a chance to review portlet mania, round II today? :P)
[02:48] <jordi> BLOCKED: deciding what to do with gnome-glossary (do we want to import it?), some of my tasks need to be proxied via kiko still.
[02:49] <Kinnison> SteveA: where do I get shortlist from?
[02:49] <bradb> s/over two/about two/
[02:49] <SteveA> Kinnison: ctags is your friend!
[02:49] <Kinnison> ctags ate my IO bandwidth!
[02:50] <salgado> Kinnison, it's in helpers, IIRC
[02:50] <Kinnison> ta
[02:52] <bradb> BjornT: also, I notice that it appears that DistroReleaseCVEReport is conflicting
[02:52] <BjornT> bradb: well, i've been reviewing branches to get them on top ;) it was decided that most of the general queue would be gone by tomorrow, but i'm not sure that will happen any more. kiko?
[02:52] <lifeless> night all
[02:52] <BjornT> bradb: yeah, but it's a minor conflict, i think
[02:52] <bradb> BjornT: Hm, I've seen the oldest ones there at the top under daf's branch for several days, IIRC
[02:52] <sabdfl> bradb: i'll take over distroreleasecvereport and take it to south africa over the weekend for some love
[02:53] <kiko> BjornT, it must happen
[02:53] <sabdfl> bradb: what's your pipeline look like at the moment
[02:53] <BjornT> bradb: i won't have time to review your branch today, but tomorrow
[02:53] <bradb> sabdfl: BugInContext (not yet approved, just wrote it yesterday, blocks BugAndTaskPageURLs) and then implement MaloneSearchResults on the other bug listings (the first merge only implements it on the sp bug listing page.) After that, it depends entirely on what else is part of MaloneOneDotZero (I did extensive gardening lately to make it easy for others to tell me what I understand 1.0 to be, what spec statuses are, etc. but haven'
[02:53] <bradb> BjornT: ok
[02:54] <bradb> s/implements it/implemented it/
[02:55] <sabdfl> kiko: will it be easier to manage spec status on launchpad overall, or on rosetta/malone/registry etc individually?
[02:55] <BjornT> kiko: well, it's not much time left, but still a lot of branches to review, and so far i haven't seen much action.  i'll be reviewing one more today, and probably two tomorrow.
[02:56] <kiko> BjornT, I'll do quite a few today
[02:56] <kiko> sabdfl, are you asking where we will attach the specs to -- the launchpad product or the malone/rosetta products?
[02:57] <BjornT> and jamesh, spiv? how are the reviews going?
[02:57] <spiv> BjornT: I'm going to be doing a review blitz pretty much all day tomorrow.
[02:57] <spiv> Right now it's bedtime, I'm afraid.
[02:57] <BjornT> cool
[02:58] <kiko> good question BjornT
[02:59] <bradb> SteveA: At what time do you want to discuss BiC further today, and request/launchbag:foo?
[02:59] <bradb> I guess he's gone for lunch. /me goes to finish waking up, back in 30-45 mins.
[03:18] <mpt> cprov: Will AutoBuilding ever be used by upstreams, or is it only for distributors?
[03:19] <cprov> mpt: both I suspect
[03:19] <mpt> ok
[03:33] <zyga> carlos: ping
[03:36] <zyga> carlos: I'm trying to get language-selector into rosetta, it's there but it needs admin love: https://launchpad.net/products/language-selector/+translations
[03:36] <zyga> the pot file is in mvo's arch repo if you need one
[03:38] <kiko> hmmmm
[03:38] <kiko> jordi?
[03:38] <jordi> kiko: yup
[03:39] <kiko> jordi, so you're basically suggesting rosetta experts be allowed to admin language groups?
[03:40] <kiko> jordi, because the process sould be: ask end-user to create group when necessary, privileged person set up the actual language group link
[03:40] <jordi> kiko: I believe. We're going to populate GNOME and Plone teams very soon. I can proxy, but I think it's something an expert should be able to do.
[03:41] <jordi> nod
[03:42] <zyga> are you guys talking about my issue?
[03:43] <jordi> not sure :)
[03:43] <zyga> I welcome anyone who'd like to help me :)
[03:44] <jordi> zyga: oh
[03:44] <jordi> I can help you with that. Can you get a tar.gz created with all the files that need import?
[03:45] <jordi> zyga: add your request here https://wiki.ubuntu.com/RosettaPendingImports
[03:45] <jordi> I can do it after lunch
[03:45] <jordi> I'ts getting late, gotta leave office
[03:45] <zyga> jordi: tar.gz with what? .pot?
[04:01] <kiko> caaaaaaarlog
[04:01] <kiko> caaaaaaarlos
[04:02] <zyga> khaaaaaaaan... *cough, cough*
[04:09] <mpt> cprov: Sorry, I forgot ... are the build machines ever doing cross-compiling?
[04:10] <cprov> mpt: never, I builder is registered for a specific architecture
[04:10] <mpt> ok, so "architecture" doesn't need to be a column in the table of builds for a builder :-)
[04:11] <cprov> mpt: it does, how to identify a builder-slave architecture
[04:11] <mpt> It's already identified in the builder summary info
[04:11] <mpt> it doesn't need to be repeated for every build on the builder's individual page
[04:11] <cprov> mpt: I need to query it ..
[04:12] <cprov> mpt: summary isn't normalized, what are you suggesting ?
[04:14] <mpt> cprov: On the page for an individual builder
[04:14] <mpt> it displays what architecture that builder has
[04:14] <cprov> mpt: Builder.processor field indetify for which architeture this build works for, no way to remove ;)
[04:14] <mpt> e.g. i386
[04:14] <mpt> So in the table of builds
[04:14] <cprov> mpt: yes, continues
[04:14] <mpt> you don't need to say that every build is an i386 build
[04:14] <mpt> because we already know that
[04:14] <mpt> does that make sense?
[04:15] <cprov> mpt: yes, UI changes always make sense in this context ;)
[04:15] <mpt> We still need the architecture column in the builds page for a distro etc, because there the architecture is going to be different depending on the build
[04:15] <cprov> mpt: indeed
[04:15] <mpt> but not in the builds page for a builder itself.
[04:16] <cprov> mpt: exactly, you can remove that column, easy
[04:17] <sabdfl> bradb, bjornt: were you planning to bring the bug subscription system into line with Brazil soon?
[04:17] <sabdfl> or should i do that?
[04:17] <sabdfl> i've landed very simple and efficient subscriptions for specs, bounties, and soon tickets
[04:18] <bradb> sabdfl: Wasn't planning on doing it before 1.0.
[04:18] <sabdfl> and in fact i think i can simplify it all into a single interface and browser code
[04:18] <sabdfl> i will do it
[04:18] <bradb> ok, great
[04:18] <sabdfl> i'm also going to rework cve reports to meet pitti's initial needs
[04:18] <mpt> sabdfl: that will help the MOTUs, they're having trouble with bug mailing lists vs. privacy right now
[04:18] <bradb> ok
[04:18] <sabdfl> mpt:  i don't follow?
[04:19] <mpt> sabdfl: They were assigning bug reports to a MOTU team, but the team had a public mailing list address as its preferred e-mail address, so "Private" bugs were being made public
[04:19] <sabdfl> nice
[04:20] <sabdfl> but my changes will not prevent that
[04:20] <sabdfl> mpt: did you clean up the calendar pages to remove the tabs?
[04:20] <mpt> sabdfl: if implemented per spec, MaloneBugSubscriptions would solve that by letting the mailing list subscribe to the MOTU packages, and thereby be notified of public bugs but not private ones
[04:20] <sabdfl> that's PackageSubscriptions
[04:21] <sabdfl> all i'm going to do is get rid of the CC/WATCH/IGNORE options, and polish up the web pages
[04:21] <kiko> mpt, to /all/ motu packages?
[04:22] <mpt> sabdfl: MaloneBugSubscriptions has "PackageSubscriptions and ProductSubscriptions are implemented" in its Assumptions, and describes how they work for private bugs
[04:23] <sabdfl> mpt: i'm not implementing the whole spec. part of the malone bug subscriptions discussion was to drop the cc/watch/ignore stuff in favour of a simple subscribe/unsubscribe mechanism. that's all i'm planning to do
[04:23] <mpt> sabdfl: as I understand it, jamesh's calendar-ui branch turns the calendar tabs into application menu, which makes them a portlet in the new layout.
[04:24] <sabdfl> ok, so that was jamesh. looks good. much better
[04:24] <sabdfl> mpt: what's your pipeline look like?
[04:25] <mpt> I'm finishing up the buildfarm stuff at the moment, then giving the spec tracker a once-over, and by then SteveA should have finished the missing bits of LaunchpadMenus
[04:32] <sabdfl> ok
[04:32] <sabdfl> are you working with real pages on the buildfarm, or specs? mpt?
[04:32] <mpt> real pages
[04:32] <mpt> builder-index.pt right now
[04:34] <sabdfl> cool
[04:35] <carlos> zyga, isn't language-selector an Ubuntu package?
[04:49] <zyga> carlos: it is, but pot files are not in rosetta - check out my messages above
[04:49] <zyga> carlos: I've added it here: https://wiki.ubuntu.com/RosettaPendingImports
[04:49] <carlos> zyga, ok, that's not the way to do that
[04:49] <zyga> ah
[04:49] <carlos> zyga, Ubuntu packages are imported automatically
[04:49] <zyga> then what should I do?
[04:50] <carlos> language-selector hadn't any .pot file some time ago and that was the problem
[04:50] <carlos> if mvo fixed it now
[04:50] <sabdfl> BjornT: ok, the conflict in cve stuff was minor, and i have a branch with it fixed
[04:50] <carlos> it should appear soon automatically
[04:50] <carlos> as the other Ubuntu translations
[04:50] <carlos> under launchpad.net/distros/ubuntu/breezy
[04:50] <zyga> carlos: it does now but it's in his arch repo, I'm not sure if that's the 'proper' place
[04:50] <sabdfl> BjornT: could you remove your branch from the review queue, please, i will make my changes in a separate branch and put it up for review next week
[04:51] <BjornT> sabdfl: cool, i'll do that
[04:51] <carlos> zyga, as soon as he uploads that version into Ubuntu's archive, it will appear to be translated from Rosetta, don't worry
[04:52] <zyga> carlos: k, thanks
[04:52] <carlos> you are welcome
[04:53] <zyga> carlos: wait, mvo sais it's there for ages
[04:53] <zyga> says even
[04:53] <zyga> it's been there for ages
[04:54] <carlos> zyga, with a .pot file?
[04:54] <SteveA> sabdfl: how long are you around for today?
 zyga, with a .pot file?
[04:56] <zyga> mvo: does ubuntu archive contain .pot file for language-selector?
[04:56] <sabdfl> niemeyer: ping
[04:56] <SteveA> bradb: ping
[04:56] <bradb> yeah, hi
[04:56] <bradb> i've just finished a small example BiC implementation
[04:56] <kiko> jordi, are there bugs filed on allowing experts to manage language groups?
[04:57] <niemeyer> sabdfl: Pong
[04:57] <zyga> mvo: okay, I'm tracking your progress on #u-devel
[04:59] <carlos> stub, before you leave
[04:59] <carlos> stub, I need that you add a new row to SourcePackageName on production
[05:00] <stub> ok
[05:00] <carlos> INSERT INTO SourcePackageName(name) VALUES('language-selector');
[05:00] <carlos> stub, thank you
[05:00] <stub> carlos: done
[05:01] <carlos> zyga, language-selector should appear soon on Rosetta
[05:01] <carlos> if it's not there tomorrow, ping me back
[05:01] <kiko> carlos, stub: https://launchpad.net/sourcepackagenames
[05:01] <sabdfl> cheers all
[05:02] <zyga> carlos: thanks - will .po uploads work again soon?
[05:03] <carlos> zyga, they should work. Seems like some people have issues with .tar.gz uploads (need to look into it) but the only problem is that with a change in our templates, the links were removed
[05:03] <carlos> zyga, just add /+upload to the URL and you will be able to do the upload
[05:03] <zyga> carlos: no link - confused users (like me)
[05:03] <zyga> carlos: thanks I'll remember now
[05:03] <carlos> zyga, like es/+upload or pt_BR/+upload
[05:04] <carlos> zyga, I know, It was an error not a feature :-P
[05:10] <dilys> Merge to<EMAIL_ADDRESS>[trivial]  Added missing links to upload and admin URLs (Fixes #1996) (patch-2337<EMAIL_ADDRESS>[05:11] <carlos> zyga, there you have
[05:11] <zyga> carlos: great, thanks :)
[05:14] <Kinnison> SteveA: thanks dude
[05:15] <WaterSevenUb> zyga, I missed some of the conversation here.... an URL for language-selector translation available?;)
[05:16] <zyga> WaterSevenUb: it should appear in a moment :)
[05:16] <zyga> WaterSevenUb: it's a nasty translation though :-) be careful
[05:17] <carlos> WaterSevenUb, not in a moment but between today and tomorrow
[05:17] <zyga> carlos: is there any way to know what is the source of a suggestion?
[05:17] <WaterSevenUb> zyga, eheh:)
[05:17] <carlos> zyga, not yet
[05:17] <zyga> carlos: I just ran across some ill-encoded suggestion
[05:17] <WaterSevenUb> carlos, k:)
[05:17] <zyga> carlos: could someone make a select or something? :)
[05:18] <carlos> zyga, open a bug report and I will try to look at it when I have some time
[05:18] <zyga> carlos: okay, thanks
[05:21] <zyga> carlos: bug on launchpad product?
[05:22] <carlos> zyga, rosetta
[05:26] <SteveA> stub: how long are you around for?
[05:53] <SteveA> why do i get 15 errors when running the tests on rocketfuel?
[05:54] <Keybuk> so why can't I log in to launchpad
[05:54] <Keybuk> I click "log in", and I'm still not
[05:55] <Keybuk> weird, it didn't like me doing it in another window
[05:55] <Keybuk> and apparently I can't fix hct bugs because I'm not the maintainer ?!
[05:56] <kiko> Keybuk, waitasec
[05:56] <Keybuk> that's silly ... people other than the maintainer should be able to mark bugs as fixed
[05:56] <kiko> Keybuk, I'll set you as maintainer (would you rather have a group?)
[05:57] <Keybuk> I don't mind either way
[05:57] <kiko> launchpad is slow for me atm
[05:57] <kiko> very slow
[05:59] <SteveA> jamesh: ping
[06:01] <SteveA> bradb, BjornT: I'm getting a test failure in bugtask.txt.  can i get some help debugging it?
[06:01] <bradb> sure, i can help
[06:01] <bradb> SteveA: i just finished some more braindumping on https://wiki.launchpad.canonical.com/BugInContext btw
[06:02] <SteveA> python test.py -f  --test=bugtask.txt
[06:02] <SteveA> what do you get?
[06:05] <bradb> SteveA: it passes, but that's expected
[06:05] <BjornT> SteveA: what failure do you get?
[06:05] <SteveA>     Traceback (most recent call last):
[06:05] <SteveA>       File "/scratch/dists/launchpad/lib/zope/testing/doctest.py", line 1315, in __run
[06:05] <SteveA>         compileflags, 1) in test.globs
[06:05] <SteveA>       File "<doctest bugtask.txt[121] >", line 1, in ?
[06:05] <SteveA>         upstream_task.status = STATUS_ACCEPTED
[06:05] <SteveA>     Unauthorized: ('status', 'launchpad.Edit')
[06:06] <SteveA> this is with a rocketfuel tree
[06:06] <BjornT> hmm
[06:07] <bradb> SteveA: maybe under:
[06:07] <bradb>     >>> sample_person.join(foo_team)
[06:07] <bradb>     True
[06:08] <bradb> throw an sample_person.inTeam(foo_team)
[06:08] <bradb> it should return True
[06:09] <SteveA>     sample_person.inTeam(foo_team)
[06:09] <SteveA> Differences (ndiff with -expected +actual):
[06:09] <SteveA>     - True
[06:09] <SteveA>     + False
[06:09] <bradb> aha
[06:09] <bradb> that's why
[06:09] <bradb> the question is, why isn't it joining the team? hm.
[06:09] <SteveA> any idea why that might happen?
[06:09] <SteveA> i have a place to debug now, anyway
[06:10] <jordi> zyga: tar with pot & po makes our life a lot easier
[06:11] <bradb> SteveA: silly question, but is your database reset as well?
[06:11] <bradb> (for the fresh checkout)
[06:12] <SteveA> yes
[06:12] <SteveA> i rebuilt it
[06:12] <SteveA> anyway
[06:12] <SteveA> joining a team should either cause an error
[06:12] <bradb> and, if it's a fresh checkout, unaltered, how did you discover the test failure? what made you want to run the test suite?
[06:12] <SteveA> or result in the person being in that team
[06:12] <SteveA> i always run the test suite before i cut a branch
[06:13] <SteveA> just to make sure nothing freaky has happened in my own setup
[06:13] <SteveA> or random stuff happening
[06:13] <bradb> ok
[06:13] <SteveA> otherwise, how can i tell that my changed tests are causing a failure
[06:13] <SteveA> ?
[06:13] <SteveA> TDD dude!
[06:13] <bradb> i live by TDD
[06:14] <SteveA> okay, i'll get a cup of beverage, and then get my debugger out
[06:15] <bradb> ok :)
[06:15] <bradb> SteveA: what happens next with BiC, btw?
[06:15] <SteveA> thanks for the help tracking down the location of the problem
[06:15] <bradb> no prob
[06:15] <SteveA> next, i want to get stuart to review it, and perhaps lifeless too
[06:16] <SteveA> so, send out a message to them asking for their review
[06:16] <bradb> ok. warning: it's still in brain dump mode. i can spend more time really crysallizing it if you want it to be draft spec quality
[06:16] <SteveA> and we'll also look at it a bit more later today
[06:16] <SteveA> it is getting good enough to be a useful description of what and why
[06:16] <BjornT> SteveA: i remember having a failure like that before, not fun to debug. sometimes when you change something, it starts to pass...
[06:16] <SteveA> arse
[06:17] <SteveA> bradb: don't spend much more time on it; get on with other stuff.
[06:17] <bradb> right
[06:17] <SteveA> i'll look to give you some more comments
[06:17] <SteveA> but i want stu and lifeless to look next
[06:17] <bradb> I'll mail both of them then
[06:17] <SteveA> cc me please
[06:18] <bradb> ok
[06:18] <SteveA> BjornT: i kind of suspect some exception being swallowed somewhere.
[06:20] <BjornT> SteveA: could be. iirc the sqlobject cache got cleared somehow when i had that failure, but i'm not sure.
[06:20] <zyga> jordi: done, it's on the page
[06:20] <zyga> jordi: but the issue is solved anyway - there was a bug in rosetta
[06:21] <zyga> jordi: it did not scan the package to notice the .pot file
[06:21] <salgado> SteveA, BjornT, could a flush_database_updates() solve that?
[06:23] <bradb> salgado: I think the real problem is to figure out how SteveA's environment differs from pqm's.
[06:23] <BjornT> salgado: well, it might make the test pass. but it'd be good to debug it, there might be a deeper problem with sqlobject, which would be good to fix
[06:23] <jordi> zyga: you still need the import?
[06:24] <zyga> jordi: I'm not sure, carlos did some magic on the production system
[06:25] <salgado> bradb, well, IIRC the problems caused by not having a flush_database_updates() in some places are not always reproducible, like the problems we used to have with the old teamparticipation.txt test
[06:25] <zyga> jordi: the package should appear on its own but I dont know how soon that's going to happen
[06:25] <carlos> jordi, you should reject any request to import .pot files attached to products if that application is Ubuntu specific or the request is to translate a product for Ubuntu
[06:26] <carlos> jordi, all those translations are handled from /distros/ubuntu ...
[06:26] <jordi> carlos: I didn't even know what language-selector was.
[06:27] <jordi> yet. ie, I hadn't looked at it.
[06:27] <bradb> salgado: could be that too
[06:28] <zyga> WaterSevenUb: ping
[06:28] <carlos> jordi, It's just extra information for you so you do some extra questions/test before a new import
[06:28] <carlos> not a big problem
[06:28] <zyga> WaterSevenUb: the best way to translate language-selector is to have wikipedia around, all those countries are there to see :)
[06:28] <WaterSevenUb> zyga, there is one package there with all the coutnries translated already.
[06:29] <WaterSevenUb> zyga, give me one minute.
[06:29] <zyga> WaterSevenUb: ah?!?
[06:29] <zyga> WaterSevenUb: I sure would like to merge if it has .pl stuff
[06:29] <zyga> WaterSevenUb: how about weather applet?
[06:30] <WaterSevenUb> zyga, country-chooser?
[06:30] <WaterSevenUb> zyga, I don0t have time now... check if it's that one...
[06:31] <zyga> WaterSevenUb: I have to go now - I'll check it tomorrow
[06:39] <carlos> zyga, do you have to translate country names?
[06:39] <carlos> that's a bug on language selector....
[06:40] <WaterSevenUb> carlos, what do you mean by bug?
[06:40] <carlos> WaterSevenUb, it should use iso-codes package
[06:40] <carlos> that has translations for all countries and languages
[06:42] <WaterSevenUb> carlos, where is iso-codes in Rosetta? Also, countrychooser has translations of country names.
[06:43] <carlos> WaterSevenUb, not sure if it's imported, if it's not, we should fix that
[06:45] <WaterSevenUb> carlos, well... I'm lost. File a bug on language-selector to use iso-codes? How to tell to import iso-codes to Breezy? (There is one in Hoary that could be possibly reused).
[06:46] <carlos> WaterSevenUb, file two bugs: 1.- language-selector should use iso-codes (against language-selector) 2.- iso-codes is not available for breezy (against Rosetta)
[06:47] <WaterSevenUb> 1. bugzilla 2. malone ?
[06:48] <carlos> WaterSevenUb, yes
[06:54] <zyga> carlos: yes, both country names and languages
[06:55] <zyga> carlos: but I did the translation manualy, outside rosetta
[06:55] <WaterSevenUb> carlos, https://launchpad.net/malone/bugs/2022, http://bugzilla.ubuntu.com/show_bug.cgi?id=14503
[06:55] <carlos> WaterSevenUb, thank you
[06:55] <WaterSevenUb> zyga, so... you have countrychooser in breezy, and iso-codes in Hoary... check for country translations in there;)
[06:56] <carlos> WaterSevenUb, countrychooser should also use iso-codes
[06:56] <WaterSevenUb> carlos, one more bug? eheh.
[06:56] <zyga> WaterSevenUb: I'll merge and that should make my work obsolete, thanks :)
[06:56] <carlos> the point behind that package is to translate those languages/countries in a common place and only once
[06:57] <WaterSevenUb> I see.... so +1 bug?:)
[06:59] <WaterSevenUb> why can't I find countrychooser in packages.ubuntu.com?
[07:02] <carlos> WaterSevenUb, I don't know, ask at #ubuntu-devel
[07:04] <zyga> WaterSevenUb: there is a package localechooser-data
[07:04] <zyga> WaterSevenUb: I cannot check it now
[07:17] <Kinnison> ciao dudes
[07:30] <WaterSevenUb> carlos, no time now... see you.
[07:55] <kiko-fud> niemeyer!
[07:55] <kiko-fud> is that breezy or hoary?
[07:55] <niemeyer> breezy
[07:55] <niemeyer> Some details are still not working, like an empty "Applications" menu, but that's minor
[07:55] <niemeyer> (not working for me, I mean)
[07:56] <niemeyer> Certainly due to past config files I had
[07:56] <carlos> niemeyer, last time I tried to develop launchpad with breezy was a bit difficult and tests didn't work
[07:56] <carlos> that was a month ago
[07:57] <niemeyer> carlos: Ah, looks like I'll have a lot of fun then.. :))
[07:57] <carlos> niemeyer, yeah, the postgres setup changes a bit
[07:57] <carlos> because the paths changed
[07:57] <kiko> carlos, apparently the sab fixed the issues, but I'm not sure he landed them
[07:58] <kiko> niemeyer, is there a way, in xchat, do make a user command issue two IRC commands?
[07:58] <carlos> twistd 2.0 gave me lots of problems with hte tests but Andrew did some fixes for that so it should not be an issue anymore...
[07:58] <carlos> kiko, ok
[07:58] <niemeyer> kiko: If using the Python plugin interface, certainly
[07:58] <kiko> niemeyer, not using the python plugin interface
[07:59] <niemeyer> kiko: Not that I'm aware about it
[07:59] <kiko> sucks to be me
[08:00] <bradb> SteveA: got a moment to discuss request/launchbag:foo?
[08:01] <niemeyer> kiko:
[08:01] <niemeyer> def cmd1(word, word_eol, userdata):
[08:01] <niemeyer>     xchat.command("cmd2")
[08:01] <niemeyer>     xchat.command("cmd3")
[08:01] <niemeyer> xchat.hook_command("cmd1", cmd1)
[08:01] <niemeyer> That should work, ir you're interested
[08:01] <niemeyer> if
[08:02] <kiko> you are such a hacker
[08:07] <niemeyer> .. and shouts in his ear: _why the damn tinyproxy doesn't work?_
[08:08] <niemeyer> [niemeyer@burma ~] % sudo tinyproxy -d
[08:08] <niemeyer> tinyproxy: Unable to find group "nobody".
[08:08] <niemeyer> !?
[08:09] <niemeyer> Ok.. got it
[08:09] <kiko> niemeyer, group nobody missing, obviously
[08:09] <kiko> if it's broken in breezy.. report a bug
[08:11] <niemeyer> kiko: You're such a hacker!
[08:11] <niemeyer> :)
[08:11] <niemeyer> I'll have to nobody -> nogroup on all old conffiles
[08:12] <kiko> ah, old config files from mandriva
[08:12] <niemeyer> Yep
[08:12] <niemeyer> kiko: Is there something like the redhatish rc.local on Debian systems?
[08:12] <niemeyer> (something that is exec'd on startup)
[08:13] <niemeyer> And is supposed to be messed by users
[08:13] <kiko> not that I know of
[08:14] <niemeyer> Keybuk!
[08:14] <Keybuk> niemeyer!
[08:14] <Keybuk> how goes the ubuntu install?
[08:15] <kiko> Keybuk, here's a question from niemeyere
 kiko: Is there something like the redhatish rc.local on Debian systems?
[08:16] <kiko> I didn't know of anything -- do you, Keybuk?
[08:16] <Keybuk> what does rc.local do on RedHat ?
 (something that is exec'd on startup)
 And is supposed to be messed by users
[08:17] <Keybuk> niemeyer: what do you want to do on startup?
[08:17] <Keybuk> because that would probably mean there's a bug in Ubuntu we need to fix <g>
[08:19] <Keybuk> niemeyer: what do you want to do on startup?
[08:19] <Keybuk> because that would probably mean there's a bug in Ubuntu we need to fix <g>
[08:20] <niemeyer_> Keybuk: Sorry.. power problems here
[08:20] <niemeyer_> Keybuk: It's going nicely
[08:20] <Keybuk> (re: rc.local)
[08:20] <niemeyer_> Keybuk: Still polishing a few details, but the core migration is done
[08:21] <niemeyer_> Keybuk: Not really.. just minor personal tasks I'd like to run at startup
[08:21] <Keybuk> just drop a file in /etc/rc2.d named S99whateveryouwant
[08:22] <niemeyer_> Keybuk: Understood
[08:22] <niemeyer_> Thanks
[08:22] <niemeyer_> Btw, do you happen to know what to do with an empty "Applications" menu?
[08:22] <Keybuk> it's empty?!  oops
[08:23] <niemeyer_> Keybuk: Not a fault of ubuntu
[08:23] <Keybuk> try right-clicking on it and choosing Edit Menus and see if you need to turn stuff on
[08:23] <Keybuk> oh, what did you do?
[08:23] <niemeyer_> Keybuk: Migrated my home from Conectiva, to Mandriva, to Ubuntu.. :)
[08:38] <bradb> "In the case where it is given a distribution it will usually behave as though it was workingwith that distributions primarydistrorelease." -- "usually" is an interesting choice of word there.
[08:47] <bradb> Would it make sense to change SourcePackage so that it can only take one of either distribution or distrorelease, and to make the assumption that only .distribution OR .distrorelease will be set?
[08:49] <bradb> Kinnison, cprov: What do you think?
[08:50] <bradb> I'm wondering what kind of explosion this might trigger
[08:52] <bradb> even breaking it up into two pieces, IDistroSourcePackage and IDistroReleaseSourcePackage might make sense, unless you guys can think of another way to be able to render a +index on both kinds of objects without that.
[08:52] <bradb> s/render/register/
[08:54] <kiko> bradb, well, if you look at sourcepackage's methods, the question you want to answer is: do they make sense in a distro context?
[08:54] <kiko> which of them depend on distrorelease?
[08:54] <bradb> yeah, i looked at them
[08:55] <kiko> and if you used the latest release, what impact would it have on the pages you are working on?
[08:55] <bradb> i think they can all make sense, with reasonable assumptions about what not having a .distrorelease means
[08:56] <kiko> what does it mean?
[08:56] <bradb> kiko: I don't think using the latest release makes sense for all of them. e.g. not for bugsCounter, at least.
[08:56] <bradb> kiko: it means different things for different methods, AFAIK
[08:56] <kiko> I agree
[08:56] <bradb> the most important point being that the behaviour is documented, IMHO
[08:57] <bradb> s/AFAIK/AFAICT/
[08:57] <kiko> not so sure
[08:57] <kiko> are most of the methods going to end up being big binary if switches?
[08:58] <bradb> if it remains as one implementation class, then yes, that may happen
[08:59] <kiko> well, s/may/?/ and I'll suggest a course of action
[09:00] <bradb> I can't answer questions about a sourcepackage as though I understand it extremely thoroughly though. I'm sure Kinnison or cprov could illuminate more deeply what impact this other semantic would have on the bowels of Soyuz/LP.
[09:00] <bradb> My initial impression is that it would make more sense to split it into two objects though
[09:01] <kiko> bradb, SourcePackage isn't used in many places
[09:01] <kiko> I'm not so sure K/C will actually know that well
[09:02] <bradb> it isn't?
[09:02] <bradb> bradb@oxygen:~/launchpad/lib/canonical/launchpad $ greppy SourcePackage | wc -l
[09:02] <bradb> 557
[09:02] <bradb> lead me to think otherwise, but looks can be deceiving
[09:03] <kiko> SourcePackageRelease?
[09:03] <kiko> greppy SourcePackageRelease | wc -l
[09:04] <bradb> 171
[09:04] <bradb> indeed, these results are not a count of just the "SourcePackage" class, as it were, but anywhere the word "SourcePackage" is mention suggests to me the potential to break something with this change, be directly or indirectly
[09:05] <kiko> right
[09:05] <kiko> well, no
[09:05] <kiko> SourcePackageRelease will not be affected at all
[09:06] <bradb> bradb@oxygen:~/launchpad/lib/canonical/launchpad $ greppy "\bSourcePackageRelease\b" | wc -l
[09:06] <bradb> 83
[09:06] <bradb> (dunno if writing Perl regex's for grep Just Works, but ... :)
[09:07] <bradb> 67 for \bSourcePackage\b
[09:08] <bradb> it doesn't look to bad though, skimming through less
[09:08] <kiko> bradb, hctapi uses it
[09:08] <kiko> you can be sure that none of the callsites use it without a distro release
[09:09] <bradb> correct, by the looks of it
[09:09] <bradb> that's Very Good News, to my eyes
[09:10] <kiko> bradb, make a separate class, I think
[09:10] <bradb> so, it would appear that adding this new semantic isn't so bad in terms of breaking existing code, but that it does leave the question of if and how to distinguish D SP and DR SP behaviour
[09:10] <bradb> yeah, i'd tend to agree
[09:10] <kiko> there is not a lot of commonality that you can use
[09:10] <kiko> you can however try implementing a subset of the interface
[09:11] <kiko> and making sourcepackage's interface inherit from yours
[09:11] <bradb> right
[09:13] <bradb> one thing that I'm wrestling with here is that, where I think IBugTask, IDistroBugTask, IUpstreamBugTask, etc. communicate very clearly what kind of task one is working with in the code, I don't think sabdfl likes that. so, even though i might take the same approach here (afterall, how do you register a distinct +index page for each, otherwise?), i can imagine what kind of reaction that would cause
[09:13] <bradb> e.g. I was thinking ISourcePackage, IDistroSourcePackage and IDistroReleaseSourcePackage. one base iface and two specializations of that iface for things that are and behave differently.
[09:16] <bradb> kiko: thoughts on that?
[09:17] <kiko> bradb, sounds correct.
[09:18] <kiko> however
[09:18] <kiko> IDRSP I'm not so sure about -- sounds like plain SP
[09:19] <bradb> I'm curious: how would an IDRSP be a "plain SP" anymore than a specific sp release should be a "plain sp"?
[09:20] <bradb> the problem i'm seeing here is that with two iface's, that seems to imply one is going to extend the other, but that breaks in both directions, because each will have different methods that won't make sense for the other, i think
[09:21] <bradb> but, the ideas are still simmering, i'm not fully sure one way or the other on that bit
[09:23] <kiko> oh
[09:23] <kiko> hmmm
[09:23] <kiko> you want to survive the full rename of SourcePackage -> IDRSP?
[09:25] <bradb> if it can work like bug task works, we don't need to actually create a new content class. we could have the core content class be basically just the data, and from there adapt it to the iface it should behave like.
[09:26] <kiko> mark seems to be allergic to adapters :-(
[09:27] <bradb> yeah, i know. hmph. trying to think of how this can be kept clear and simple.
[09:29] <bradb> kiko: what should i do then? maybe keep this idea on low heat and bring it up with SteveA when he's around later?
[09:30] <kiko> I'd do the following
[09:30] <kiko> create a new class
[09:30] <kiko> IDSP
[09:31] <kiko> create the interface split
[09:31] <kiko> don't do any adaptation
[09:31] <kiko> then later talk to stevea about refactoring
[09:31] <kiko> you'll need to do some minor duplication because of this
[09:31] <kiko> but it should be mainly little if clauses in the browser code
[09:32] <bradb> ok, to be clear, which if ISP, IDSP and IDRSP do you think should exist?
[09:32] <bradb> s/if/of/
[09:33] <kiko> I'd do the simplest thing, which is a bit in violation of OOness
[09:33] <bradb> and, which of SP, DSP and DRSP content classes, and how do you picture the inheritance hierarchy working?
[09:33] <kiko> IDSP -> ISP
[09:33] <kiko> no inheritance between the content classes
[09:34] <bradb> ok
[09:35] <bradb> i'll start by modifying doc/sourcepackage.txt
[09:51] <FireRabbit> can i somehow add a little dropdown box where the user can select which operating system they are using in the "Add Bug" page for my project?
[09:53] <bradb> FireRabbit: hm, interesting question
[09:54] <bradb> the direct answer is no, you can't add a little dropdown box to your filebug page for your product. but it's an interesting point.
[09:54] <FireRabbit> what about adding different components to my project like bugzilla has?
[09:55] <bradb> nope, Malone doesn't have components (yet)
[09:55] <bradb> FireRabbit: what project are you referring to? what kind of things did you have in mind for components?
[09:56] <FireRabbit> well, my application has a windows gui, a linux gui, and a common shared backend library. it would be nice to have seporate components for each one
[09:57] <bradb> FireRabbit: who do you envision to choose the "component"?
[09:58] <FireRabbit> well, it would be fine if the user just saw "Which operating system are you using?:" .. one of the developers could then switch it to the backend if it was determined that the bug was not platform-specific
[09:58] <bradb> FireRabbit: i.e. i'm curious if what you mean by component can be handled with keywords instead.
[09:58] <bradb> or if there's a need for both
[09:59] <FireRabbit> hm, i dont know if i saw keywords
[09:59] <bradb> they're not yet implemented
[09:59] <FireRabbit> oh, i see :)
[09:59] <FireRabbit> well, if "keywords" are going to be configurable per-project, and if you will be able to select a keyword when submitting a bug, it would probably do what i am thinking just fine
[10:02] <bradb> ok. we'll do some thinking about your questions/issues. sorry, i can't give any more specific an answer than that right now, but it's always helpful to hear what users are finding confusing/missing/useful/whatever
[10:02] <FireRabbit> thanks a lot
[10:03] <bradb> no prob
[10:03] <FireRabbit> i thought of one more thing, say someone submits a bug for my project and we determine that the bug is actually being caused by one of the shared libraries that the project uses, is there a way to re-assign an existing bug to another project?
[10:04] <bradb> FireRabbit: no, but i agree that it's an issue
[10:04] <FireRabbit> okay, just throwing it out there as an idea :)
[10:05] <bradb> it's a very good idea
[10:06] <FireRabbit> i think it would compliment the whole upstream/distribution seporation malone tries to make quite well
[10:07] <FireRabbit> brb, i need to grab some lunch.. is there a mailing list i should post these suggestions on?
[10:09] <bradb> FireRabbit: I just filed https://launchpad.net/malone/bugs/2030, re: reassignment
[10:10] <bradb> FireRabbit: I haven't announced malone-users officially yet. Planning to do so around the 1.0 release, in the not-too-distant future.
[10:16] <FireRabbit> okay, cool. hopefully ill hear about it
[10:23] <kiko> hey
[10:23] <kiko> does anyone know of a tool to clean up pristine trees automatically?
[10:45] <bradb> kiko: Does this look like what you had in mind for SP? https://chinstrap.ubuntu.com/~dsilvers/paste/fileTEg1KE.html
[10:47] <kiko> bradb, looks good.
[10:48] <bradb> great, thanks. I love science fiction.
[11:09] <niemeyer> Argh.. I hope to keep the same distribution for another 5 years at least. :-)
[11:10] <niemeyer> mvo!
[11:11] <bradb> kiko: doc/sourcepackage.txt passes now, with that snippet included. w00t.
[11:12] <bradb> time for me to head out
[11:15] <bradb> later all
[11:18] <niemeyer> mvo: Today it's the first time I use Smart on Ubuntu by myself. :)
[11:18] <mvo> niemeyer: nice! are you happy with the packaging :)?
[11:19] <niemeyer> mvo: I'm using it from the development tree so far
[11:20] <niemeyer> mvo: But the fact that the package actually exists already makes me happy ;)
[11:33] <lifeless> morning all


[10:17] <peppe84> https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/748673
[10:17] <ubot2> Launchpad bug 748673 in ubuntu-docs "Natty & Yelp/Desktop help: strange mix of info refering to Gnome 3 & 2, but not to Unity" [Undecided,Confirmed]
 tagging  .... man there is a lot of work to do


[00:17] <davido> Odd_Bloke, thanks for pointer to docs
[13:30] <beantaxi> Morning all! Question on testing ... from reading the readthedocs, I see that both pytest tests and unittest.TestCase tests are supported. I'm not savvy enough about Python testing to know if this is clearly a Good Thing, or if it's just sort of how things are because in early days some folks used pytest, some used UnitTest.TestCase, and you were happy enough they were writing tests at all to not
[13:30] <beantaxi> worry about it till a future date to be named later. Thanks!
[13:46] <meena> beantaxi: i think it's that we started out with x because that's what people knew,  or what was available, and then later as they got smarter about testing we did y
[13:46] <meena> you fill in the variables
[13:51] <beantaxi> I'm not qualified to fill those blanks in, but if x or y is better/newer/preferred, I'm happy to use that one, since I have nothing invested in either
[13:53] <beantaxi> Meanwhile I'm in "How does anyone figure out how anything works in Python" mode. I've been trying to find where in pytest.org it documents what (eg) @pytest.mark.user_data(USER_DATA), specifically how the USER_DATA argument is used, but I can't find anything
[13:54] <chillysurfer> hey, all! it appears as though this pr keeps getting closed: https://github.com/canonical/cloud-init/pull/780 could i get it reopened? thanks!
[14:25] <Odd_Bloke> beantaxi: We moved to using pytest over the last year and a bit, so that's preferred; the integration tests are entirely written using pytest.  Some marks have specific meaning in pytest by default (e.g. @pytest.mark.skip), but it's a generic tagging mechanism, which allows you to store data along with the tag: that's how we're using the user_data mark.
[14:26] <Odd_Bloke> beantaxi: Most of the integration tests use the `client` (or `class_client`) fixture defined in https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py; these are all wrappers around `_client`, which uses the user_data mark: https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py#L202
[14:27] <Odd_Bloke> beantaxi: But, basically, it's passed into the instance however user-data is passed into instances for the cloud under test.
[14:29] <Odd_Bloke> chillysurfer: Done; sorry!
[14:29] <chillysurfer> Odd_Bloke: no problem! and thank you!!
[14:34] <beantaxi> Odd_Bloke: Thanks very much for that. So @pytest.mark.user_data(USER_DATA) is sort of like DI, and it allows you to pull the value of a 'user_data' setting from the ether in an unrelated part of code, instead of explicitly passing in a reference. So to speak. I'm not sure why I could not find that in the pytest docs but perhaps I was overlooking something obvioius. Thanks!
[14:48] <Odd_Bloke> beantaxi: In pytest terms, fixtures are closer to dependency injection than marks.  Marks are just metadata on tests: at their most basic, they can be used to select tests (e.g. "don't run 'slow' tests").  However, test framework code can also use them programmatically: pytest knows how to handle some of them itself (i.e. it skips tests marked with "skip"), and we've written framework code that knows how
[14:48] <Odd_Bloke> to handle others (including `user_data`).
[14:48] <Odd_Bloke> In our case `user_data` is used to mean, "please pass this user-data into the instance that you launch as a result of running this test".
[14:57] <beantaxi> Odd_Bloke: That sounds more accurate. I was using 'DI' as a minumum for 'all the things Spring does for Java', which includes decorating variable declarations with annoations that result in those variables being assigned values pulled from property files, without an explicit assignment in the code. So you can look forever for that assignment and never find anything, but it doesn't mean you're crazy.
[14:57] <beantaxi> Thanks for the insight.
[15:00] <beantaxi> It also looks like running integration tests requires logging into a VM, and specifying that VM as your platform one way or another when running integration tests, unless you want lots of failures. So among other things, if I were running an on EC2 instance, pytest integration_tests is going to invoke pycloudlib which will dynamically create, snapshot, and destroy a new VM ... or possibly do all that
[15:00] <beantaxi> on the existing VM, which would save on EC2 charges I suppose
[15:02] <beantaxi> (fyi for fun I tried to run integration_tests inside my Docker image, which required adding git and gcc, and then when I ran pytest integration_tests I think literally every test failed. That wasn't unexpected; I just wanted to see what happened.)
[15:32] <Odd_Bloke> beantaxi: The integration test framework will launch instances in the target platform: by default it uses LXD containers.
[15:33] <Odd_Bloke> It just requires credentials for the platform in question, you don't need to be running there.
[15:34] <Odd_Bloke> And it won't use existing VMs in its default configuration, so it _will_ try to launch things which cost you money (hence defaulting to containers, which don't :).
[15:34] <Odd_Bloke> (The support for using an existing VM is really intended for test development, or specific manual cases: for clouds which we don't have automated integration with, for example.)
[15:53] <beantaxi> Odd_Bloke: Gotcha, I did look at the code and I saw the default was lxd. So I can run integration_tests on any linux system with lxd installed? Eg if I run from an EC2 instance I can just run pytest integration_tests from the command line and be good. Do I need to uninstall the lxd apt package and install from snap? Or does the installed version work from a default EC2 Ubuntu instance. I guess I'm
[15:53] <beantaxi> assuming y'all have ttried this and the answer is well known to you.
[16:40] <Odd_Bloke> beantaxi: I just run it locally mostly, on my (Ubuntu 20.10) desktop; I have no reason to think that LXD on an EC2 instance shouldn't work, though.
[16:40] <Odd_Bloke> (It's possible that the LXD in xenial is older than we need for some of the tests, I'm unsure.)
[17:01] <beantaxi> I just tried on an EC2 instance I had up. My naive invocation fails -- here are the first 50 lines of output -> https://paste.ubuntu.com/p/wzpbWdTSMY/ -- but perhaps my unadorned `pytest tests/integration_tests` is missing something
[17:08] <blackboxsw> oops had to correct the UTC time typo  15:15 -> 17.15. Yes officially we will host cloud-init office hours today. starting in about 7 mins.
[17:09]  * blackboxsw is putting up the discourse post content now with high level status update content
[17:16] <Odd_Bloke> beantaxi: I'd expect that to work; try running `pytest tests/integration_tests/modules/test_runcmd.py` and letting it complete: that way we'll get more info about what that error is.
[17:19] <blackboxsw> #startmeeting cloud-init bi-weekly office-hours
[17:19] <meetingology> Meeting started at 17:19:08 UTC.  The chair is blackboxsw.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[17:19] <meetingology> Available commands: action, commands, idea, info, link, nick
[17:19] <blackboxsw> #char Odd_Bloke falcojr
[17:19] <blackboxsw> #chair Odd_Bloke falcojr
[17:19] <meetingology> Current chairs: Odd_Bloke, blackboxsw, falcojr
[17:20] <blackboxsw> hi cloud-init, sorry for the confusion on the UTC time that I posted in the topic. I had incorrectly set 15:15 UTC instead of 17:15.
[17:20] <blackboxsw> welcome to the bi-weekly cloud-init office hours
[17:21] <blackboxsw> This cloud-init status meeting has moved to a more asynchronous posting of high-level happenings in cloud-init to discourse to support timezone differences for all cloud-init developers.
[17:23] <blackboxsw> We plan on continuing to host these office hours to provide a means for quick communication, questions and discussions with a couple of upstream developers present to help facilite any questions or discussions of interest to folks.
[17:23] <blackboxsw> For reference, here are the high-level "happenings" in cloud-init upstream over the last two weeks.
[17:23] <Odd_Bloke> o/
[17:23] <blackboxsw> #link https://discourse.ubuntu.com/t/cloud-init-status-03-09-2021/21309
[17:26] <blackboxsw> As of last office-hours I belive upstream had just cut the first 21.1 release in the tip of cloud-init. Canonical will be starting the SRU process this week I believe to publish the 21.1 release (plus a couple of extra fixes which just landed in tip) into Ubuntu Xenial, Bionic, Focal, Groovy and Hirsute.
[17:41] <beantaxi> Odd_Bloke: I tried your command and it was helpful. It complained about a missing ssh key, so I shrugged, tried ssh-keygen -t rsa and reran the test, and it passed. I've kicked off a run of all the tests, which I assume will take a bit.
[17:55] <Odd_Bloke> beantaxi: Great, thanks for the update!  A full run in LXD containers takes ~12mins locally (though I'm probably running on beefier hardware than you're paying EC2 for so YMMV :p).
[17:55] <Odd_Bloke> beantaxi: Once you had the output, was it clear that the missing SSH key was the issue?
[17:55] <blackboxsw> setting the appropriate time for next office hours
[17:56] <blackboxsw> setting the appropriate time for next office hours Mar 23 17:15 UTC
[17:57] <beantaxi> ERROR tests/integration_tests/modules/test_runcmd.py::TestRuncmd::test_runcmd - FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/.ssh/id_rsa.pub'
[17:57] <beantaxi> That was the error message
[17:59] <falcojr> tests require an ssh keypair. It'll use your user one by default or you can specify one manually in the integration settings config
[17:59] <falcojr> do an `ssh-keygen`
[17:59] <beantaxi> The full test failed with 7 failures: https://paste.ubuntu.com/p/hcYN7ZDvbs/
[18:00] <beantaxi> falcojr: Thanks ... I was just showing Odd_Bloke the error message I got before running ssh-keygen, which did indeed solve most of my issues
[18:01] <beantaxi> falcojr: Also, this is just me running the existing integration tests on an EC2 instance. Without any of my changes
[18:01] <falcojr> not sure the cause of that first one, but the rest are for code not in ubuntu images yet
[18:03] <falcojr> the version of cloud_init to use is specified by the CLOUD_INIT_SOURCE variable (integration_settings.py...copy this to user_settings.py to easily override defaults)
[18:03] <falcojr> it defaults to NONE which means use whatever image has been released on this platform
[18:04] <falcojr> to test non-released code, changing it to IN_PLACE (only works on LXD) should work
[18:08] <falcojr> you can also set it to ppa:cloud-init-dev/daily , but that won't contain any changes that you're trying to test
[18:18] <beantaxi> falcojr: Copying integration_settings.py to user_settings.py and setting CLOUD_INIT_SOURCE=IN_PLACE made all the test_keys_to_console errors clean. There's still that simple_streams error. Do I just need to add a PPA for simplestreams? It looks like requires a file in /etc/apt/sources.list.d, but mine is empty
[18:23] <falcojr> Not sure off the top of my head. Did you pip install the integration_requirements.txt?
[18:38]  * blackboxsw thinks I should about wrap up office hours. Thanks falcojr Odd_Bloke and beantaxi for the discussion there
[18:38] <blackboxsw> #endmeeting
[18:38] <meetingology> Meeting ended at 18:38:08 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/cloud-init/2021/cloud-init.2021-03-09-17.19.moin.txt
[19:47] <beantaxi> falcojr: Yes, I ran this command: pip install -r ./requirements.txt -r test-requirements.txt -r integration-requirements.txt
[19:48] <Odd_Bloke> beantaxi: falcojr: That simplestreams error looks to me like we're assuming that we'll detect an Ubuntu release to look for.
[19:49] <Odd_Bloke> Let me explain that better. :p
[19:50] <Odd_Bloke> In your first log, I see "ubuntu-distro-info (from the distro-info package) must be installed to guess Ubuntu os/release" followed by "Detected image: image_id=focal os=None release=None".
[19:52] <Odd_Bloke> In test_apt.py, we look for .release to determine the file to read: https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/modules/test_apt.py#L145
[19:53] <Odd_Bloke> Which leads to "/etc/apt/sources.list.d/simplestreams-dev-ubuntu-trunk-None.list" being looked for; "None" being the problem here.
[19:53] <Odd_Bloke> (The fact that it's simplestreams is a coincidence: that's just the PPA the test author chose to use for the test.)
[19:55] <beantaxi> $ ls -1 /etc/apt/sources.list.d | wc -l return 0 for me ... the folder is empty. Would that be resolved by installing (ubuntu-)distro-info? Or am I reading that wrong
[19:56] <Odd_Bloke> The two fixes: manually specify the OS and release by setting CLOUD_INIT_OS_IMAGE=focal::ubuntu::focal in your environment (or OS_IMAGE = "..." in your settings), or install distro-info.
[19:56] <Odd_Bloke> beantaxi: You are reading it a little wrong: the path in question is within the system-under-test.
[19:56] <Odd_Bloke> The two fixes I suggested would mean that it would look for the correct path.
[19:56] <Odd_Bloke> (It's a minor bug in the test, to be clear.)
[20:01] <beantaxi> Odd_Bloke: I seem to recall this from the integration_tests instructions, something about how if you are too vague in specifying a variable, you will get errors when the wrong tests are run, but if you're more specific that won't happen
[20:07] <beantaxi> Odd_Bloke: Making that change to user_settings.py cleaned up the test_apt.py error. So if I just wanted a one liner, and not touch any files, I could do CLOUD_INIT_OS_IMAGE focal::ubuntu::focal CLOUD_INIT_SOURCE=IN_PLACE pytest tests/integration_tests should work?
[20:09] <Odd_Bloke> beantaxi: You're missing an = after OS_IMAGE but otherwise, yeah, that should run all the integration tests that apply to Ubuntu focal using the code in your cloud-init tree.
[20:10] <Odd_Bloke> beantaxi: Oh, no, you need CLOUD_INIT_CLOUD_INIT_SOURCE, actually.
[20:10] <Odd_Bloke> (CLOUD_INIT_ is stripped off the environment variables.)
[20:13] <beantaxi> Yes I'd read that and thought I understood it, but then I say CLOUD_INIT_SOURCE in the settings file and figured I'd misunderstood. Ok, that's nice I can do it as a one-liner without touching any settings files.
[20:27] <Odd_Bloke> Yep, that's what I do.
[23:22] <beantaxi> Odd_Bloke: falcojr: I finally got test to complete without my ssh session dying before I checked. I'm getting a clean run with this command:
[23:22] <beantaxi>  CLOUD_INIT_OS_IMAGE=focal::ubuntu::focal CLOUD_INIT_CLOUD_INIT_SOURCE=IN_PLACE  pytest $HOME/src/github.com/canonical/cloud-init/tests/integration_tests
[23:22] <beantaxi> There are some warnings, mostly deprecation I think. Any objection to my fixing those while I'm in the area?


[10:25] <Ubugtu> New bug: #64502 in xorg "desktop-cd ubuntu 6.10 beta boots but 'blank screen' only" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64502
[07:36] <Ubugtu> New bug: #64567 in xserver-xorg-video-ati "[r128]  Driver does not support internal CRT of iMac on PPC" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64567
[10:45] <Ubugtu> New bug: #64585 in xserver-xorg-video-ati "Ati X800 GTO doesn't work" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64585
[11:00] <Ubugtu> New bug: #64589 in xserver-xorg-video-ati "Problem with Radeon9000 and ati/radeon driver" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64589


[16:31] <rapidwave> Is Lubuntu IRC specific to Lubuntu or is it just a Ubuntu operated server/network for connecting to IRC?
 This is the support channel for problems with Lubuntu
[16:53] <teward> rapidwave: the Lubuntu channel is on the Freenode IRC network, as is the rest of the Ubuntu IRC channels.
[16:53] <teward> rapidwave: Freenode is not operated by Ubuntu or Canonical or Lubuntu, but Lubuntu, Ubuntu, Xubuntu, etc. all have channels here.
[19:53] <Guest53152> bona sera