[12:52] <jblack> Who is the expert on user accounts?
[12:54] <spiv> jblack: How do you mean?  What do you want to know?
[12:54] <jblack> > (By the way, is there any way to change my username to 'jam' or
[12:54] <jblack> > 'jameinel' instead of the full john@arbash-meinel.com?)
[12:55] <spiv> There's a few things here.  Launchpad names don't contain "@".
[12:56] <spiv> But it's possible to login with your email address rather than your username, Launchpad's happy either way.
[12:56] <jblack> He probably thinks this because the login box accepts<EMAIL_ADDRESS>
[12:56] <spiv> Oh, hmm, maybe launchpad itself only takes email address.
[12:57] <spiv> Ah, yeah, launchpad.net only allows email addresses for logging in.
[12:58] <spiv> We could change that, although with browser form autocompletion, it's generally not a big issue.
[12:59] <spiv> (and existing email addresses have the advantage of being easier to remember than yet another login)
[01:01] <spiv> So, he could file a bug on Launchpad asking for it to be logging in by nickname to be allowed, rather than just email address.
[01:02] <spiv> I'm personally a little hesistant to support multiple ways of doing things, it can make things less usuable rather than more.
[01:04] <jblack> Since launchpad doesn't have a habit of allowing long-lived cookies, if his browser doesn't support saving form data then see where he could get annoyed. *Not that he is
[01:05] <spiv> Well, cookie lifetime is about to get bumped up to 60 days, I think.
[01:05] <jblack> 60 days may or may not be reasonable. I think its currently set for browser close.
[01:06] <spiv> It's currently about 12 hours, iirc.
[01:06] <spiv> We recently moved the session data into postgres so that it would be persistent across webapp restarts and the like.
[01:06] <jblack> You look correct. I just double checked.
[01:07] <jblack> "Don't oversleep! You could have to log in again!"
[01:09] <spiv> Heh.
[01:19] <jblack> bradb: ping
[01:21] <mpt> jblack, he's not here
[03:19] <dilys> Merge to devel/launchpad/: Remove an unnecessary LEFT OUTER JOIN from a query generated by the ValidPersonOrTeam vocabulary. r=kiko (r3028: Guilherme Salgado)
[03:44] <stub> lifeless: Is it ok for me to make multiple cherry picks in bzr, followed by a single commit? Or should I still merge, commit, merge, commit, merge, commit?
[03:47] <stub> bzr on balleny seems much, much faster
[03:51] <lifeless> stub: yes, I updated the snapshot
[03:51] <lifeless> late last week
[03:52] <lifeless> uhm, we dont record cherry picks as such at the moment
[03:52] <lifeless> so, do whatever is easiest.
[03:52] <stub> Doesn't really matter now that commit is quick ;)
[03:57] <stub> Does IO wait time (as reported by top) mean *just* sucking stuff from disk, or does it measure more than that under Ubuntu?
[03:58] <stub> c/sucking/sucking and stuffing/
[04:20] <lifeless> you mean the figure up the top ?
[04:24] <stub> Yup. The CPU percentage
[04:28] <lifeless> IIRC the
[04:28] <lifeless> percentage of processes blocked on IO
[04:28] <lifeless> or something like
[04:28] <lifeless> where IO != disk alone
[04:31] <lifeless> thats pretty harsh
[04:31] <fabbione> Launchpad is offline at the moment for maintenance. It should be back, better than ever, soon. Thanks for your patience.
[04:31] <lifeless> its being upgraded
[04:31] <fabbione> should tell me that after i login
[04:31] <lifeless> HOW?!
[04:31] <fabbione> before i enter and change stuff?
[04:31] <fabbione> and push the "commit changes" button?
[04:32] <lifeless> its a web app - it wasn't offline before, now it is
[04:32] <fabbione> WEEEEEE
[04:32] <lifeless> we can't tell how many requests are outstanding
[04:32] <fabbione> you mean you just started the upgrade in the last 2 minutes?
[04:32] <lifeless> yes
[04:32] <fabbione> crap
[04:33] <fabbione> ok how long is going to take?
[04:33] <lifeless> stub: how long is the upgrade looking ?
[04:34] <lifeless> 20 minutes ?
[04:34] <stub> lifeless: Done
[04:34] <lifeless> stub: sweet. fabbione ^^
[04:35] <mpt> if we had ultra-persistent logins implemented, fabbione could now just click "Reload"
[04:35] <mpt> to resubmit the form
[04:35] <stub> I can get the downtime down to about 5 minutes for most upgrades now ;)
[04:35] <fabbione> mpt: that did work.. or it seems so
[04:35] <lifeless> stub: slick
[04:35] <lifeless> stub: benefits of automation ?
[04:36] <stub> lifeless: Benefits of planning, multiple app servers, and a more intelligent full text index rebuilder
[04:36] <mpt> stub, so "soon" can be changed back to "in a few minutes"?
[04:36] <stub> I'll be updating the rollout docs for 8.0 and the procedures
[04:36] <mpt> fabbione, cool
[04:36] <stub> mpt: I can't guarentee that ;) Some upgrades will still take a while depending on how much database stuff needs to happen
[04:37] <mpt> ok, how long is "a while"? :-) Within an hour?
[04:39] <stub> mpt: It really depends. Worst case would be about 1.5 hours I *think*, but I won't know for sure until we actually do that case on this hardware. If we have major data migration work to do, it can still be longer. We had one rollout where it took the scripts about 4 hours to run.
[04:39] <stub> mpt: We do have ultra persistent logins
[04:40] <stub> There is a bug open on that, because they are too persistent for people using shared computers
[04:40] <lifeless> 'logout' ?
[04:41] <mpt> was that introduced recently?
[04:41] <lifeless> yes
[04:42] <stub> mpt: We have had persistent logins for a week or two (persistent cookies, and the credentials remembered over server restarts). They used to time out after 12 hours, but this roll out bumped that up to 60 days.
[04:43] <stub> So if there are any more reports about people getting logged out, either their browser or proxies are screwing them over or we have an undiscovered bug lurking that will be a real pita to find.
[04:43] <mpt> lifeless, most Web apps with a "Log Out" button still have a "Shared computer" or similar checkbox on the login form
[04:43] <mpt> for cases when, for example, you pay for ten minutes of time at a cafe and don't *quite* log out in time
[04:43] <mpt> stub, excellent
[07:21] <fabbione> lifeless: ping?
[07:24] <lifeless> pooong
[07:27] <fabbione> lifeless: i am having a stupid issue with bzr
[07:27] <fabbione> machine1 has the original archive.
[07:27] <fabbione> people.ubuntu.com has a pushed one
[07:27] <fabbione> machine2 branch from people
[07:27] <fabbione> machine2 can't push to people....
[07:28] <fabbione> or i can't figure out how to let machine2 to do it
[07:28] <fabbione> bzr branch sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/
[07:28] <fabbione> works fine
[07:28] <fabbione> whatever i try to say to bzr push towards that archive it ends up in an error
[07:29] <fabbione> note that the archive is perfectly synced
[07:29] <fabbione> no merges or new commits
[07:29] <fabbione> bzr: WARNING: Unable to update the working tree of: sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/
[07:29] <fabbione> what am i missing here?
[07:30] <lifeless> a) #bzr is the right place
[07:30] <lifeless> b) its a UI glitch, its perfectly normal and correct
[07:31] <fabbione> a) ok.. b) what should i do to workaround it?
[07:31] <lifeless> theres nothing to workaround
[07:31] <lifeless> check the exit code - its 0
[07:31] <lifeless> it is giving you a warning, not an error
[07:31] <fabbione> ok
[07:33] <fabbione> thanks mucho
[07:33] <lifeless> np
[08:43] <dilys> Merge to devel/launchpad/: [trivial]  Drop is_person constraints (r3029: Stuart Bishop)
[09:08] <BjornT> stub: ping
[09:09] <stub> BjornT: pong
[09:13] <BjornT> stub: nevermind, i was about to ask you about how to fix something, but i noticed it has already been fixed in rocketfuel
[09:45] <carlos_> morning
[09:51] <SteveA> good morning
[09:55] <SteveA> lifeless: ping
[09:55] <Kinnison> Morning stevea
[09:57] <SteveA> hi Kinnison.
[09:57] <SteveA> That was yesterday.   But it is 30C and the food is good, cheap and plentiful :)
[10:29] <kiko> and what about the production update?
[10:31] <stub> production update all done, patchlevels as discussed
[10:31] <kiko> thanks stub, rock and roll -- perhaps email launchpad and -users?
[10:32] <stub> We need that log of changes for -users announcements, otherwise it would be a bit pointless (?)
[10:33] <kiko> I have a log of changes here, so sure.
[11:19] <SteveA> stub: ping?
[11:19] <stub> SteveA: pong
[11:19] <SteveA> i'm catching up with email
[11:19] <SteveA> has the cached celeb stuff landed yet?
[11:20] <sivang> morning all
[11:20] <SteveA> i was thinking about the cached celeb, and the mail thread about it
[11:20] <SteveA> as sqlobject does cacheing like we want if we get an object by id, and as we want a launchpad instance to fail early if the celebs are not as expected
[11:20] <SteveA> then we could re-do the celebs to do a single query / set of queries by name to look up celeb ids at startup
[11:20] <SteveA> and then use celeb ids from then on
[11:21] <stub> SteveA: Yes
[11:21] <SteveA> and not need fancy cacheing proxies etc.
[11:21] <stub> (landed)
[11:21] <SteveA> __getattribute__ always makes me queasy
[11:21] <Kinnison> SteveA: __get__ makes me more queasy
[11:21] <stub> I took jamesh's approach and simplified it, with comments about possible future enhancements.
[11:22] <SteveA> Kinnison: __get__ ?  as in from a descriptor
[11:22] <stub> __get__ is just downright wierd, and I havn't found good docs on it yet
[11:22] <Kinnison> SteveA: aye, as in to do with how @property is done
[11:23] <kiko> SteveA, I looked at the current solution and it appears to be doing a lot of good in production
[11:24] <SteveA> cool
[11:24] <SteveA> i just read the mail from jamesh
[11:24] <SteveA> i don't understand the part about thread-safety at the end though
[11:25] <kiko> SteveA, can you make it a priority this week to get jamesh' __len__ fix reviewed and landed?
[11:25] <SteveA> ok
[11:25] <kiko> the final important fix we need to do is inTeam caching
[11:25] <kiko> I spoke to salgado about this
[11:25] <SteveA> me too
[11:26] <kiko> and you, I remember now :)
[11:26] <SteveA> we don't want to do inTeam cacheing as such
[11:26] <kiko> right
[11:26] <kiko> you told me
[11:26] <kiko> so I was asking if you don't want to give salgado an idea of how you want this done, and have him implement it for you to review?
[11:27] <SteveA> maybe.  i'll look to see where we're up to with it
[11:28] <kiko> thanks -- I think salgado would appreciate being given that opportunity
[11:39] <spiv> stub: best doc on descriptors I've seen is http://users.rcn.com/python/download/Descriptor.htm
[11:43] <stub> spiv: ta
[11:49] <kiko> stub, is launchpad going down for maintainence?
[11:49] <Kinnison> eight kilobytes is utter shite
[11:50] <Kinnison> Hmm, it's not the buffer, it's that for some bizarre reason it uses nonblocking receive
[11:56] <matsubara> good morning!
[11:58] <stub> kiko: nope
[11:59] <kiko> and the message is gone, too!
[11:59] <stub> you saw a message?
[11:59] <kiko> yeah, on the webapp
[11:59] <stub> bah - one of the appservers hadn't cleared its 'down for maintenance' file
[12:00] <stub> Sorted
[12:00] <kiko> cool.
[12:01] <kiko> SteveA, talk to me, come on
[12:03] <kiko> 36ms  	SELECT private, owner, activitytimestamp, communityscore, datecreated, activityscore, title, duplicateof, description, hitstimestamp, hits, communitytimestamp, name, summary FROM Bug WHERE id = 633
[12:03] <kiko> stub, is there any explanation on why that wouldn't take 1ms? contention?
[12:04] <stub> contention
[12:04] <stub> Or just busy
[12:05] <kiko> 23ms  	SELECT id FROM BugExternalRef WHERE bug = 633
[12:05] <stub> Lots of disk activity
[12:06] <stub> karma updater has kicked in
[12:06] <stub> Which will continue to be slow until my patch is reviewed and landed
[12:07] <kiko> stub, what's blocking your review?
[12:08] <stub> me not nagging anybody?
[12:08] <SteveA> it's in the general queue
[12:08] <SteveA> i'll take a look now
[12:08] <SteveA> i need a change from EMAIL
[12:08] <kiko> SteveA, can you take that..
[12:08] <kiko> cool
[12:08] <kiko> this will be a great week for perf
[12:10] <SteveA> stub: what does WITHOUT OIDS mean?
[12:11] <stub> By default tables get a magic column, but it is only really useful in rare cases (and even then, not strictly necessary). We don't need them anyway.
[12:12] <stub> I'll be updating all the tables at some point to remove them, but it isn't urgent
[12:12] <stub> WITHOUT OIDS is the default in 8.1 (or is it 8.0?)
[12:24] <Kinnison> SteveA: Apparently you were party to some local zope mods on jackass
[12:24] <Kinnison> SteveA: Did those ever make it into rocketfuel?
[12:25] <SteveA> stub: reviewed
[12:25] <SteveA> Kinnison: jackass?
[12:26] <SteveA> what was running there?
[12:26] <Kinnison> SteveA: The poppy instance for dak
[12:27] <SteveA> i don't recall zope mods for that, only poppy mods
[12:27] <SteveA> is there a problem with running poppy?
[12:28] <Kinnison> cprov is encountering issues with some tests running on his laptop needing reconnects mid-upload
[12:29] <cprov> SteveA: yes, maybe you remember something about this issue
[12:29] <SteveA> as far as i recall, all changes to poppy, and workarounds to connections being aborted on long uploads, were done in the poppy code
[12:30] <cprov> SteveA: gustavo added a weird polling on ftp.sock during the upload session, it needs further explanation.
[12:30] <SteveA> what is the problem you're seeing?
[12:32] <cprov> SteveA: aparently the ftp connection drops during the upload session (it's not a long one) and the only way to recognize it is polling the ftp.sock (private attribute) and if it's gone ftp.connect() and ftp.login() again
[12:33] <SteveA> hmm
[12:33] <SteveA> so, there is a problem with the default ftp server code that the ftp connection will be aborted during an upload session, if the upload is long
[12:33] <SteveA> beacuse the control connection will get no data for a while, even though the data connection is getting data
[12:34] <SteveA> so the control connection will figure "oh, nothing happening, i'll disconnect"
[12:34] <SteveA> i wrote a fix for poppy that deals with this
[12:34] <carlos> daf, Seems like tests are not detecting that I don't have installed python2.4-twisted-mail
[12:34] <carlos> daf, what's using it?
[12:34] <cprov> SteveA: and is it applied  jackass instance ?
[12:34] <SteveA> the fix didn't involve polling
[12:34] <daf> carlos: I can't remember
[12:35] <SteveA> it involved correctly resetting the activity timer on the control connection whenever some data arrives on the data connection
[12:35] <cprov> SteveA: the polling is in the client side ...
[12:35] <SteveA> i have no idea what jackass is for, and where the fix was applied
[12:35] <daf> carlos: buildd-sequencer.txt is what failed
[12:35] <daf>     ImportError: You need to have the Twisted Mail package installed to use twisted.protocols.smtp. See http://twistedmatrix.com/projects/mail.
[12:36] <SteveA> the fix was certainly applied for poppy in production
[12:36] <SteveA> because longer uploads would always fail without it
[12:36] <carlos> hmm, I see
[12:36] <cprov> daf: dapper ?
[12:36] <carlos> cprov, yes
[12:36] <daf> cprov: yes
[12:36] <carlos> daf, import_fascist is missing that import then
[12:36] <cprov> cprov: twisted pkg was split in a wierd way, maybe lp-deps isn't up
[12:36] <carlos> daf, it detected the web package
[12:37] <carlos> but didn't complain about the mail one
[12:37] <daf> this was when running python test.py -f yesterday
[12:37] <SteveA> cprov: see poppy/server.py, class STORChannel
[12:37] <cprov> SteveA: I suspect we are talking about the same patch ... elmo just gave it to me ... will isolate the patch an send you, ok ?
[12:38] <daf> carlos: and yes, the fascist does appear in the traceback
[12:38] <SteveA> cprov: ok.  what code are you using? how does it compare to the code in RF?
[12:41] <carlos> daf, hmmm I don't see it, perhaps other failures are hidding it..
[12:42] <cprov> SteveA: so, I have RF HEAD and a kind of special zope+poppy instance from elmo
[12:42] <cprov> SteveA:  I can see the class STORChannel(OriginalSTORChannel):
[12:43] <cprov> SteveA: I can't see where is the respective code in RF
[12:48] <cprov> niemeyer: hey, how is it going ?
[12:48] <niemeyer> Buenos dias!
[12:48] <kiko> fala niemeyer
[12:49] <niemeyer> cprov: So far so good :)
[12:49] <cprov> niemeyer: maybe you have some info to bug # 29645
[12:49] <cprov> niemeyer: this is a sabdfl's phrase, you need to find other ;)
[12:50] <niemeyer> cprov: Ah, didn't know that.. will look for another one :)
[12:50] <niemeyer> cprov: Will check it
[12:50] <cprov> niemeyer: good, thx
[12:56] <niemeyer> cprov: ^
[12:59] <cprov> niemeyer: try again
[12:59] <niemeyer> cprov: Is the backtrace expected?
[12:59] <Kinnison> Umm, given a list L, what's the best way to produce list K which is [ L[0] , L[0:1] , L[0:2] , ..., L ]  ?
[01:00] <niemeyer> [L[:i]  for i in range(len(L))] ?
[01:00] <niemeyer> Perhaps (1, len(L))
[01:00] <cprov> niemeyer: it's not, thought it's been solved, file a bug
[01:01] <Kinnison> niemeyer: (1, len(L)+1) does the trick, ta
[01:01] <niemeyer> Kinnison: The +1 after len(L) shouldn't be needed..
[01:02] <Kinnison> It is
[01:02] <Kinnison> otherwise it stops one earlyu
[01:02] <Kinnison> s/u$//
[01:02] <niemeyer> Kinnison:
[01:02] <niemeyer> >>> L = [1,2,3] ; print L[:len(L)]
[01:02] <niemeyer> [1, 2, 3]
[01:03] <Kinnison> range(a,b) is from a to b-1
[01:03] <Kinnison> range(10) is 0-9
[01:03] <niemeyer> Kinnison: Duh, right
[01:03] <niemeyer> [L[:i+1]  for i in range(len(L))]  would do the trick then
[01:04] <Kinnison> the latter I think
[01:07] <Kinnison> kiko, mdz: on libcommand* in universe sources now
[01:18] <dilys> Merge to devel/launchpad/: [r=SteveA]  Karma cache refactoring (r3030: Stuart Bishop)
[01:18] <kiko> rock and roll stub
[01:20] <Kinnison> kiko, mdz: libxml*
[01:20] <Kinnison> I love the initial publish process
[01:20] <Kinnison> it makes me so happy
[01:21] <kiko> it is so friggin slow
[01:24] <cprov> kiko: it's relative, do you have a faster replacement ? so, current publisher is the fastest ! we can have so much fun watching spn crossing the screen like in a 9600 bps terminal ;)
[01:25] <kiko> like a fast link to QSD in the old days
[01:26] <cprov> malone: why are assigned "needs-info" bug not listed in "My Assigned Bugs" ?
[01:27] <kiko> because they are needs-info.
[01:27] <cprov> kiko: it's unfair IMO, I would like to keep track of my needs-info bugs too
[01:28] <kiko> it's been the subject of some debate
[01:28] <kiko> you can query them using the advanced form if you like
[01:28] <cprov> kiko: uhm ... could be a solution
[01:28] <Kinnison> kiko: If you can work out a faster way to drag a file down from an HTTP server other than using urllib2.urlopen() then you win a prize
[01:35] <kiko> daf, ping?
[01:39] <daf> kiko: pong
[01:51] <kiko> daf, you don't talk to me padrino
[01:52] <daf> oh, bah
[01:52] <daf> I need to register
[01:53] <SteveA> carlos: ping
[01:54] <carlos> SteveA, pong
[02:08] <ddaa> stub: maybe it's me, but when I read your "What is a Product Series" mail, all I see is a barrage of "you're on crack ddaa".
[02:08] <ddaa> makes it difficult for me to reply
[02:10] <ddaa> I'll try...
[02:11] <sivang> bah
[02:11] <sivang> selecting ValidAssignee timed out for me, any idea?
[02:11] <sivang> (I was trying to assigna  bug to Scott)
[02:12] <carlos> spiv, hi, around?
[02:21] <spiv> carlos: Yeah.
[02:21] <carlos> spiv, hi, I'm having problems with your suggested 'self.form.extractOneKey' method
[02:21] <carlos> and I was not able to find any reference to it...
[02:22] <carlos> isn't it just self.form[key]  ?
[02:23] <carlos> spiv, I'm talking about review of PoMsgSetPage
[02:23] <carlos> s/about/about your/
[02:24] <daf> I think fel.form[key]  can contain a list
[02:25] <spiv> carlos: let me look at my review, I think I was proposing that there should be one, rather than there is one..
[02:26] <carlos> hmm
[02:26] <spiv> carlos: right, it was a hypothetical method name.
[02:26] <carlos> ok, I misunderstood you :-P
[02:26] <carlos> daf, really?
[02:26] <daf> sure
[02:26] <carlos> daf, I suppose it depends on the form, right?
[02:26] <spiv> carlos: The thing is, you're doing a fair bit of manual mucking about because you want forms to have more data than simple key/value pairs.
[02:26] <daf> http://launchpad.net/blah?foo=a&foo=b
[02:26] <carlos> if you add twice the same entry
[02:26] <daf> form['foo']  = ['a', 'b']
[02:27] <daf> I think
[02:27] <carlos> daf, right
[02:27] <spiv> Although as daf points out, you can actually include the same key multiple times in the same form.
[02:27] <carlos> spiv, well, our forms should have just one key
[02:27] <carlos> if we have more than one is either bad user input
[02:27] <carlos> or a bug
[02:28] <spiv> carlos: interesting, that wasn't at all clear to me from reading the code.
[02:28] <carlos> so I think is safe to assume it's just one element and show an error if we get a list
[02:28] <spiv> Oh, sorry, I see what you mean.
[02:28] <spiv> I think ;)
[02:28] <carlos> spiv, let me show you the new code
[02:28] <carlos> I changed it
[02:28] <spiv> Sounds good :)
[02:29] <sivang> ddaa: how can I register my a branch of mine with LP ?
[02:29] <sivang> ddaa: I have it published and accessible http, can I do that without an admin intervention?
[02:29] <carlos> spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/fileICjL4I.html
[02:30] <carlos> spiv, I need to change the extractOneKey call with self.form[]
[02:30] <ddaa> sivang: if it's a bzr branch, it's just "add branch" on the corresponding product, or on your person's page if it has no associated product.
[02:31] <carlos> and I suppose that I should also check if 'key' is a list to show an error
[02:32] <spiv> carlos: So, I guess I didn't explain my idea so well.
[02:33] <sivang> ddaa: ok, is it ok to open a project for it, if it's a project based on a specification?
[02:33] <carlos> spiv, I discarded the record idea
[02:33] <spiv> carlos: It looks to me as if it would be simpler if you could pass structs in forms.
[02:33] <carlos> spiv, I have the explanation in my email
[02:34] <spiv> carlos: because really set_1_msgid and set_1_translation_... look like they're effectively different attributes of the same thing.
[02:34] <spiv> Hmm, ok.
[02:34] <spiv> You mean the specific implementation, or the whole concept?
[02:34] <ddaa> sivang: you mean "a product". You can create a product if you want, you do not need to, and I believe you are able to change the product after registration, so you can postpone the product creation.
[02:34] <carlos> spiv, but as a summary, I don't think we need to add support for records just for this part of launchpad, we don't have a hard restriction on them
[02:34] <ddaa> sivang: just do what makes most sense to you, if that's not supported by Launchpad, that's a bug.
[02:35] <spiv> carlos: Well, you're basically doing the same thing ad hoc.
[02:35] <carlos> spiv, you are right, it's a record, the concept is what you said, but the implementation... I'm not sure we should do it now unless other parts of launchpad can reuse it too
[02:35] <daf> spiv: yeah, it's almost like a dum/restore
[02:35] <spiv> carlos: So I'd be tempted to just use the stuff that's already built into zope 3 to ease this stuff.
[02:35] <daf> dump
[02:36] <daf> (written late one night in Mark's flat, IIRC)
[02:36] <carlos> hmm I thought we need to do some changes to launchpad to be able to use it
[02:36] <carlos> spiv, if it's already there... I will try that path then
[02:37] <spiv> carlos: It seems to be in there already, I think, but maybe it needs a small tweak to activate it.
[02:37] <carlos> ok, I need to talk later with SteveA I will check it with him
[02:37] <carlos> to be sure
[02:37] <carlos> spiv, thanks
[02:37] <spiv> carlos: I would like to get a zope expert's opinion on the topic, too, because I'm not sure if that particular feature is considered a good idea in zope 3 or not.
[02:37] <spiv> Yeah, check with Steve.
[02:37] <daf> what code is this, by the way?
[02:38] <spiv> As far as the review goes:
[02:38] <daf> s/code/branch/
[02:38] <carlos> daf, PoMsgSetPage
[02:38] <daf> aha
[02:38] <carlos> daf, chinstrap.ubuntu.com:/home/warthogs/archives/carlos/launchpad/PoMsgSetPage/
[02:39] <spiv> I'm happy enough for that code to be merged with your ad hoc pulling processing of this structured form -- but I strongly suspect this won't be the only bit of launchpad where this may be useful, hence my interest in a more general solution.
[02:39] <daf> let's file a bug on it
[02:39] <carlos> daf, let's ask Steve first ;-)
[02:39] <daf> I think it would simplify the code in a good way
[02:40] <daf> even if it's only useful here
[02:40] <daf> sure, pending Steve's approval
[02:40] <carlos> ok
[02:40] <spiv> carlos: Thanks for describing your use case for me so I fully understand what you need
[02:40] <carlos> spiv, no, thanks for your input ;-)
[02:41] <spiv> daf: I agree it would be nicer, but if it's just for this one piece of code, it may not be worth it.
[02:41] <spiv> Anyway, we have a plan of action now :)
[02:41] <daf> yes
[02:52] <SteveA> spiv: there is various form marshalling stuff in zope3, as in zope2.  but i think it is not the right way to do it -- it leads to more problems than it solves
[02:53] <SteveA> and it is largely unused for that reason, and also because we have forms and widgets now for the same kind of thing
[02:53] <sivang> daf: so, how can I remove the project I've open and open a product instead of it, and associate the bzr branch to it?
[02:53] <daf> sadly, you can't delete projects
[02:53] <SteveA> spiv: we could think about adapting a request to an IFormData kind of thing, and have useful APIs on an IFormData, perhaps
[02:53] <sivang> daf: AFAICT I only need one product with one associated branch
[02:53] <daf> I would just create a product with the same name
[02:54] <SteveA> spiv: including getOneKey or some such
[02:54] <daf> then there should be an "Add Branch" link
[02:54] <sivang> daf: ok, will do, thanks
[02:54] <SteveA> so, we can have a launchpad-specific API on forms without extending the Zope3 request a lot
[02:54] <spiv> SteveA: I thought that might be the case (about the existing form marshalling).
[02:55] <spiv> It would be nice to have a cleaner solution.
[02:55] <spiv> Although I'm not sure if there's any other places we need it.
[02:55] <spiv> It seems like something that would be useful more than once, but maybe not....
[02:57] <sivang> daf: https://launchpad.net/products/launchpad/+bug/29655 <== this is it
[02:57] <Ubugtu> Malone bug 29655: "selecting ValidAssignee times out" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[02:57] <sivang> daf: now , I will go find out what about that meeintg, If I'm cleanred I'll brb, if not it's bbiab
[02:57] <daf> ok :)
[02:59] <SteveA> spiv: can you tell me the outcome of the librarian error stuff?
[03:00] <spiv> SteveA: still unsure what the cause is
[03:00] <spiv> stub: have you updated the staging librarian config to only listen on localhost?
[03:01] <spiv> SteveA: stub was going to change the staging librarian to listen only localhost, which shouldn't break anything that ought to be using it, and hopefully cause errors in a rogue gina or whatever it is that's putting garbage into it from somewhere else.
[03:02] <spiv> SteveA: If that doesn't work, I think your suggestion about getting clients to declare what db they're using when they upload will be needed.
[03:02] <spiv> I guess the clever way to do that would be to figure out a query that gives a unique result on each database we have, so both the client and the server can do the query and check that they're consistent.
[03:05] <SteveA> i think we should have the client say the database details anyway
[03:05] <SteveA> perhaps in an X-whatever HTTP header
[03:05] <SteveA> then at least we can debug this
[03:06] <spiv> (Well, the upload protocol isn't HTTP, it's just something similar but much simpler)
[03:06] <spiv> Yeah, and extra header on the uploads would be the way to do it.
[03:06] <spiv> We'll have to phase it in, though, rather than make the server require it immediately.
[03:06] <SteveA> sure
[03:06] <SteveA> make it optional at first
[03:07] <spiv> We can always make the server log a warning (including source IP) if it doesn't get the header.
[03:08] <SteveA> the other way to do it is to have a table with one col and one row saying the database id
[03:08] <SteveA> and include that instead
[03:09] <SteveA> but that sounds more complicated
[03:09] <SteveA> although maybe needed when we have multiple database back-ends
[03:09] <spiv> If there's a way to query the dbname and/or hostname, that'd probably do.
[03:09] <spiv> I'm sure stub will have a good idea for this.
[03:09] <SteveA> it won't do when we have multiple database back-ends
[03:10] <spiv> Hmm, true.
[03:10] <SteveA> whichever way it happens, please do this soon
[03:10] <spiv> Here's a partial solution:
[03:11] <SteveA> as even being able to log things will allow us to debug it better
[03:11] <spiv> query LaunchpadDatabaseRevision
[03:11] <stub> eh?
[03:11] <spiv> stub: we're discussing how to make sure the librarian server and clients are using the same database, so we don't get id stomping.
[03:12] <spiv> As appears to be happening on staging.
[03:13] <stub> Each of our databases has a unique name, so we can query that
[03:13] <sivang> daf: back for 15 minutes
[03:14] <stub> spiv: SELECT current_database()
[03:14] <sivang> daf: can you try re-assign the bug in question and see if validAssignee times out for you as well?
[03:14] <spiv> SteveA: I can do it on Monday, but can't do it any sooner.  (I'm about to go to bed, then it's a public holiday, a day of leave, then a weekend, and I won't have internet access probably)
[03:14] <daf> sivang: who did you try to reassign it to?
[03:14] <sivang> daf: I searched for Keybuk 's email / account name
[03:14] <daf> oh, to Scott
[03:15] <sivang> daf: yeah :)
[03:16] <stub> spiv: I didn't update the staging librarian to only listen on localhost, as you pointed out that parameter was used by both the client and server and that syntax would only work on the server end.
[03:16] <stub> oh.... I was going to get the port blocked.
[03:17] <spiv> stub: Well, there's ways around that.
[03:17] <stub> Which I won't do now anyway, as staging is being used for testing by the soyuz stuff, so drescher needs to be able to connect
[03:17] <spiv> stub: Are the client and server using the same deployment?
[03:17] <spiv> Ah.
[03:17] <stub> spiv: yes
[03:17] <spiv> Ok, then here's the dodgy way:
[03:17] <sivang> Kinnison: should this imrpove once sessions are stored in pg rather in zodb ?
[03:18] <spiv> directly edit the "uploadPort = str(config.librarian.upload_port)" line of daemons/librarian.tac to have the "tcp:12345:interface=<IP_ADDRESS>" or whatever string.
[03:19] <spiv> But if certain other hosts actually need to connect, a port block is probably better anyway.
[03:19] <Kinnison> sivang: yes
[03:19] <spiv> Ok, it's way too late, I must sleep.
[03:19] <spiv> G'night all.
[03:21] <spiv> stub: If you can try the port blocking solution in the interim until I code up the SELECT current_database() check, that'd be great.
[03:24] <Keybuk> why does Launchpad time out logins?
[03:24] <Keybuk> can't it be set to just remember sessions forever?
[03:25] <Kinnison> IIRC it's not launchpad so much as the session affinity crap on the load balancer
[03:25] <stub> Keybuk: It now should only timeout logins after 60 days or when your browser decides not to bother sending cookies any more. So if you havn't logged in for 12 hours, that is to be expected but it should be sorted as of this rollout.
[03:25] <sivang> daf: let me know ifyou need anything else
[03:25] <stub> Kinnison: That is now off. We no longer need it.
[03:25] <Kinnison> stub: we're finally using the postgres db?
[03:26] <stub> Kinnison: Yes. As of a week or two ago. I just switched the 60 day timeout on today though.
[03:26] <Kinnison> stub: right
[03:26] <Kinnison> stub: and that's 60 days from last use? Not 60 days from login?
[03:27] <stub> 60 days of inactivity (I hope ;) )
[03:27] <Kinnison> good
[03:27] <stub> Back in an hour...
[03:28] <Kinnison> ciau
[03:28] <ddaa> Keybuk: I think your feedback would be useful in the "what is a product series" discussion I'm having with stub on the launchpad mailing list.
[03:29] <Keybuk> ddaa: ok, I'll look at that -- I'm up to date with launchpad atm except any mail that happened while I was at the gym
[03:30] <ddaa> Keybuk: it looks like this discussion is more about what ProductSeries should mean, and why it ended up this way historically. I think you have been an important actor in designing this part, and it has not changed recently.
[03:31] <ddaa> Also, the HCT/Dyson stuff are the primary clients of this data, as I understand the situation.
[03:32] <Keybuk> heh, the only actor who did ProductSeries was Mark :)
[03:32] <Keybuk> it was a surprise to me when it turned up overnight too
[03:32] <ddaa> whatever, if we can agree on a way to get rid of it, I would be happy.
[03:33] <ddaa> hu, that's not what I mean...
[03:34] <daf> sivang: sorry, was on the phone
[03:34] <daf> sivang: which bug were you reassigning?
[03:34] <daf> 29654?
[03:34] <ddaa> If we can figure out what it's really useful for, and provide a model that's more in line with the use cases, i would be happy
[03:35] <ddaa> and less confusing, too
[03:35] <ddaa> (sounds better that way)
[03:40] <ddaa> they more bandwidth and they not needed
[03:44] <jbailey> https://bugzilla.ubuntu.com/show_bug.cgi?id=16216 has a link to https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/16216
[03:44] <Ubugtu> Ubuntu bug 16216: "start week day wrong in Spanish" Product: Ubuntu, Component: locales, Severity: normal, Assigned to<EMAIL_ADDRESS>Status: NEW
[03:45] <jbailey> But this doesn't take me to the right bug in Launchpad, it takes me to the one that pointed me to the bug in bugzilla.
[03:45] <jbailey> help? =)
[03:47] <daf> ?!
[03:48] <daf> searching for site:launchpad.net "start week day wrong in Spanish" yields no results
[03:49] <daf> my primary suggestion at this point is to mail James H
[03:49] <jbailey> daf: Thanks. =)
[03:50] <daf> no worries
[03:51] <daf> ah -- perhaps the redirect just points to the first bug it finds that's watching the bugzilla bug
[03:53] <daf> still can't find the imported bug, though
[03:53] <jbailey> That's a much nicer thought than more dataloss.
[03:53] <daf> sadly, I rather suspect that the bug didn't get imported
[03:54] <daf> on the bright side, importing it should be easy
[03:54] <daf> but on the third hand, this could affect lots of other bugs that we haven't noticed yet
[04:35] <kiko> salgado, did cprov and Kinnison's answers satisfy you?
[04:35] <kiko> daf, jbailey: can you email the list with the evidence so we can deal with that
[04:36] <jbailey> kiko: I've emailed jamesh directly, per dafs notes.  Should I just send the same email to the launchpad list?  It was mostly a snapshot of the IRC conversation.
[04:36] <kiko> please do -- if it's not on-list, it is lost
[04:37] <jbailey> kiko: Also, I was hoping to ping him about the dataloss since the conversion (new comments going into bugzilla)
[04:37] <kiko> jbailey, how have these comments been going in?
[04:37] <kiko> and has it stopped happening?
[04:37] <jbailey> kiko: No idea.
[04:37] <jbailey> Also no idea.
[04:37] <jbailey> Pure fluke that I noticed,  james said he'd run a query to see how bad it was.
[04:37] <kiko> I can do it
[04:37] <jbailey> Usually I disable all bugzilla bugmail.
[04:37] <daf> ouch
[04:38] <salgado> kiko, I haven't reached that point in my inbox yet. :-(
[04:38] <daf> ddaa: I've pushed my o-b-t
[04:38] <kiko> salgado, is it that bad?
[04:38] <daf> ddaa: I think I've covered the major things we talked about
[04:39] <ddaa> daf: that's good news
[04:39] <ddaa> daf: are you asking me to review it?
[04:39] <kiko> daf is giving out copious amounts of good news today
[04:39] <salgado> kiko, not really, I was fixing some issues Bjorn pointed on his review and I'm now reviewing matsubara's branch
[04:39] <kiko> ah, cool.
[04:39] <daf> ddaa: er, I don't know :)
[04:39] <ddaa> daf: that's fine if you don't. I trust you to have the situation better rather than worse.
[04:40] <kiko> ddaa, if you have time, feel free to review it
[04:40] <daf> if ddaa doesn't spiv will be pretty keen, I think
[04:40] <daf> (it's blocking is push-sftp stuff)
[04:40] <ddaa> I think it will land sooner if I do not look at it :)
[04:41] <kiko> okay, send it to spiv
[04:41] <kiko> does anyone know where the debbugs sync tool lives in our tree?
[04:41] <kiko> SteveA?
[04:43] <bradb> kiko: lib/canonical/launchpad/scripts/debbugs.py
[04:44] <kiko> bradb, is that the only thing that exists? nothing uses debbugs?
[04:45] <kiko> didn't jamesh review this?
[04:45] <bradb> This was written long before we did code reviews.
[04:45] <bradb> So I doubt anyone but Mark has read it.
[04:46] <kiko> but I was sure that james had reviewed this.. wtf
[04:47] <bradb> Could be.
[04:47] <kiko> is THAT the only thing that exists?
[04:48] <kiko> mark said "it was nearly ready" 100x
[04:48] <bradb> Only thing I know of.
[04:48] <stub> kiko: debugs was due to be rolled out, but has probably grown some hair
[04:49] <stub> It was ready and waiting but couldn't be switched on until GIna was in production
[04:50] <stub> So now it will need testing against staging by someone to get things working again and confirm it is all happy.
[04:50] <kiko> stub, where the hell does it live in our tree then?
[04:50] <kiko> I mean, I can't find it
[04:50] <ddaa> stub: would you mind checking that PQM is not stuck?
[04:51] <stub> cronscripts/update-debwatches.py and cronscripts/create-debwatches.py
[04:52] <stub> Some tests would be nice too, but that might involve reverse engineering debbugs in order to create some sample data (or bribing colin or ian or whoever to help)
[04:52] <kiko> I disagree with doing a completely different solution to updating watches
[04:52] <kiko> at a glance I say we should adapt this to malone/externalsystem.py
[04:52] <kiko> but..
[04:53] <stub> Currently running buildbot tests...
[04:53] <stub> bug no activity...
[04:54] <kiko> buildbot tests have been caught hanging before
[04:54] <kiko> stub, would it be possible to tail the log output somewhere consistently?
[04:54] <stub> kiko: Could be done in test_on_merge.py I guess - just spool the output to /tmp/whatever and keep flushing
[04:54] <ddaa> stub: please kill that bitch
[04:55] <daf> ddaa: "please" and "bitch" are somewhat incongruous :)
[04:55] <stub> ddaa: Needed a kill -9 again
[04:56] <ddaa> yeah, same as last time... no wonder...
[04:56] <daf> fuxtex
[04:56] <ddaa> fuxtex mean anything...
[04:56] <SteveA> daf: hello.  voice call?
[04:57] <ddaa> any deadlock situation appears to cause a block on a futex call when using strace
[04:57] <daf> SteveA: sure -- mobile or Skype?
[04:57] <kiko> night stub
[04:57] <ddaa> well... not any, but many of them...
[04:59] <SteveA> daf: skype
[05:00] <daf> SteveA: ready
[05:12] <dilys> Merge to devel/launchpad/: [r=spiv]  fix bug 2653, don't show information about email attachments, like GPG signatures, in comments. (r3031: Bjorn Tillenius)
[05:18] <ddaa> sigh
[05:18] <ddaa> it's my cscvs compatibility patch that causes buildbot to hang...
[05:24] <carlos> SteveA, hi, sorry I had some network problems...
[05:31] <Keybuk> https://launchpad.net/distros/ubuntu/+source/ifupdown/+bugs
[05:31] <Keybuk> ^ bradb: the first bug says "in progress (unassigned)" ... but it's assigned to me!
[05:32] <jordi> hello
[05:34] <carlos> jordi, hi
[05:35] <bradb> Keybuk: I'll report a bug, thanks.
[05:35] <carlos> jordi, yesterday I saw that the wiki is not updated with the new procedure to upload new translations
[05:35] <carlos> jordi, and there are some pending imports there
[05:35] <carlos> are you still handling them?
[05:35] <carlos> (the ones from the wiki)
[05:35] <Keybuk> bradb: your new form ... my one main comment is that it's too bunched up
[05:36] <Keybuk> could we have some more whitespace between each row
[05:36] <Keybuk> otherwise the text kinda merges into one, and I have to stare hard to actually tell where one bug begins or ends
[05:36] <Keybuk> another option would be to white/grey the cells
[05:36] <Keybuk> actually, white/grey would probably work nicely
[05:36] <bradb> Keybuk: How do you think it compares to http://flickr.com/photos/84096161@N00/90749634/ ?
[05:36] <jordi> carlos: yeah, there are a few new ones, and others that are cruft (ie, need mailing the requester and telling them that they are being rejected)
[05:37] <bradb> i.e. three-column vs. two-column layout
[05:37] <Keybuk> bradb: that is just a mess, frankly
[05:37] <jordi> carlos: sometimes they need investigation to see if requester = upstream and it takes time
[05:37] <Keybuk> too much information to sift though to find a bug
[05:37] <jordi> I had been focusing on the new quue fir a while
[05:38] <Keybuk> bradb: if the Reported.*EST stuff was in a lighter colour (like silver) it wouldn't be too bad
[05:38] <carlos> jordi, I think you should add a note to the wiki page and update the wiki so the new additions are directly on the new queue...
[05:38] <bradb> Keybuk: If we silvered or removed that row, and removed the "Last Updated" line, which UI do you prefer, the two-column or three-column layout?
[05:38] <dilys> Merge to devel/launchpad/: [r=kiko]  Launchpad FAQ page (/faq) (r3032: Dafydd Harries)
[05:39] <Keybuk> bradb: if the table one had alternate colours for the rows, definitely the table
[05:39] <jordi> yeah
[05:39] <jordi> let me do it now
[05:40] <bradb> Keybuk: ok, thanks. I'm making some small tweaks to the two-column layout and am planning to send the data I've collected to launchpad@
[05:40] <carlos> jordi, thanks
[05:42] <bradb> Keybuk: bug 29671 for what you reported earlier
[05:42] <Ubugtu> Malone bug 29671: "Listing shows bug "unassigned" even when it's assigned" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: Confirmed http://launchpad.net/bugs/29671
[05:42] <Keybuk> ah ok
[05:43] <daf> SteveA: http://www.onlamp.com/pub/a/python/2005/11/03/twill.html
[05:44] <daf> SteveA: skip to page 3
[05:48] <daf> SteveA: even better, http://wwwsearch.sourceforge.net/mechanize/
[05:50] <sadhermi1> hi
[05:52] <seb128> hi
[05:52] <seb128> carlos: around?
[05:52] <SteveA> daf: yes.  this is basically what we'll be using as soon as we get the new zope3.
[05:53] <daf> SteveA: excellent
[05:53] <carlos> seb128, hi
[05:53] <seb128> hey :)
[05:54] <seb128> carlos: a french user pointed https://launchpad.net/distros/ubuntu/dapper/+source/gsmartcard/+pots/gsmartcard/fr/+translate which has 0 string to translate
[05:55] <seb128> carlos: it's not a main package, so it has been imported by somebody?
[05:55] <jordi> seb128: by an accident
[05:55] <seb128> jordi: what kind of accident?
[05:55] <carlos> seb128, any dapper translation resource that we have imported was done by mistake
[05:55] <seb128> change dapper by breezy
[05:55] <seb128> still 0 string
[05:55] <carlos> seb128, we didn't disabled the old import script when dapper was open on production
[05:56] <carlos> seb128, then, it's a bug with that package
[05:56] <carlos> let me check...
[05:56] <seb128> thank you
[05:57] <carlos> seb128, seems like the .pot file was never imported
[05:57] <carlos> I will check why
[05:57] <seb128> ok, thank you
[06:05] <carlos> seb128, that .pot file is completely broken
[06:06] <carlos> seb128, has duplicated entries
[06:07] <seb128> carlos: ah, so that's a package bug?
[06:07] <carlos> seb128, yes
[06:07] <seb128> hum
[06:07] <carlos> I will fix manually breezy's one
[06:07] <seb128> but you import universe to rosetta?
[06:07] <seb128> I thought it was main only
[06:07] <carlos> seb128, the new policy says that we are not going to do that
[06:07] <carlos> but we did it already for breezy
[06:07] <carlos> I will block it for dapper
[06:08] <seb128> ok, thank you
[06:10] <jordi> where's kiko?
[06:11] <SteveA> jordi: london office, which is disconnected right now
[06:11] <jordi> ah
[06:11] <jordi> requirements?
[06:11] <jordi> ~
[06:11] <jordi> damn
[06:11] <jordi> sorry
[06:12] <jordi> https://launchpad.net/malone/bugs/5952
[06:12] <Ubugtu> Malone bug 5952: "Group "owners" should be able to add translators" Fix req. for: rosetta (upstream), Severity: Major, Assigned to: Nobody, Status: Confirmed
[06:12] <jordi> I don't quite understand his last comment
[06:54] <iwj> I sent a mail to malone but haven't had an ack.  What does that mean ?  (Sent at 16:11:25, but against flashplayer-{nonfree,mozilla}).
[07:00] <BjornT> iwj: seems that your signature didn't verify properly. currently you don't get an error message when such errors occurs, which you should.
[07:07] <iwj> My signature didn't verify properly ?  In what way ?
[07:07] <iwj> Hmm.  gpg agrees.
[07:07] <iwj> I made the signature with mailcrypt.
[07:11] <AlinuxOS> carlos, in this "ka" georgian seciton... are there only main packges..
[07:11] <AlinuxOS> ?
[07:11] <carlos> AlinuxOS, talking about rosetta-breezy.tar.gz?
[07:11] <AlinuxOS> yes
[07:11] <carlos> AlinuxOS, yes, there are only translations for main
[07:12] <AlinuxOS> example I have metacity.po file can I put there?
[07:12] <AlinuxOS> every package is tested on my system
[07:12] <AlinuxOS> only gnome-menus dosen't work (a known reason)
[07:13] <carlos> AlinuxOS, if msgfmt -v -c your_file.po -o /dev/null works that's ok
[07:14] <AlinuxOS> carlos, so I can put metacity.po there
[07:14] <carlos> yes
[07:15] <AlinuxOS> ok
[07:15] <carlos> are you going to send a full tarball to pitti?
[07:15] <iwj> Yay, an error message with a comprehensible complaint.
[07:15] <carlos> AlinuxOS, I think it's enough if you just send your files
[07:15] <AlinuxOS> carlos, he told me that I can send only a "ka" seciton to him.
[07:15] <AlinuxOS> yes...
[07:16] <carlos> oh, ok
[07:16] <AlinuxOS> he makes them in this night...
[07:16] <AlinuxOS> :D
[07:16] <AlinuxOS> I'll import them to rosetta too :)
[07:17] <AlinuxOS> carlos, and what about mozilla locales?
[07:18] <AlinuxOS> I have mozilla locales too
[07:19] <carlos> AlinuxOS, not yet integrated with language packs
[07:19] <AlinuxOS> I have ka_GE.xpi
[07:19] <AlinuxOS> ah
[07:19] <AlinuxOS> in breezy or in dapper?
[07:21] <carlos> we will try to have it integrated with dapper
[07:21] <AlinuxOS> ah
[07:21] <AlinuxOS> ok :) mozilla is ready
[07:21] <AlinuxOS> 1.0.7 verison.
[07:22] <ddaa> cool, I can reproduce the buildbot hang here
[07:22] <ddaa> there is still hope
[07:22] <ddaa> (somewhere...)
[07:24] <carlos> AlinuxOS, talk with Martin to include it on dapper
[07:24] <ddaa> basically, it looks like our buildbot has bitrotten into incompatibility with breezy's twisted...
[07:24] <iwj> Woohoo.  Now I have a bug reply mail saying my bug has been filed but the bug doesn't exist.
[07:24] <iwj> Subject: [Bug 29677]  Sound does not work properly in Flash in firefox
[07:24] <iwj> https://launchpad.net/products/launchpad/+bug/29677 = 404
[07:24] <Ubugtu> Error: Error getting Malone bug #29677: Bug does not exist
[07:25] <iwj> https://launchpad.net/bugs/29677 = 404
[07:25] <Ubugtu> Error: Error getting Malone bug #29677: Bug does not exist
[07:25] <iwj> Yes, Ubugtu, I know !
[07:26] <iwj> Oh, wow, one of these bugs has a bit of Emacs mail mode header junk in it.  Oh well.
[07:39] <carlos> SteveA, will we have a skype call today?
[08:00] <zyga> carlos: good day  :-)
[08:00] <carlos> zyga, hi
[10:01] <ddaa> lifeless: buildbot broken
[10:02] <ddaa> lifeless: I'm looking into cscvs right now, removing gnarly cruft as a warm up
[10:03] <ddaa> I'd like to put bzr support in ASAP, and I see no reason to keep on carrying the arch support
[10:03] <Nafallo> bzr sounds good to me. I'm a real bzr-fanboy since today :-)
[10:03] <Nafallo> (before that I was a fake fanboy ;-))
[10:04] <ddaa> how do you feel about a bunch of crack (the whole meta-cvs thing, in fact) getting removed to keep just the bit that matters: the foo->database logic and then the database->bzr logic?
[10:06] <ddaa> Nafallo: lot of work to do to get there, but I'm trying to avoid getting stuck into maintaining an insane cvs->baz->bzr toolchain.
[10:07] <Nafallo> I completly understand why :-)
[10:18] <sivang> ddaa: better kill it when it\'s still young
[10:19] <Nafallo> lol
[10:19] <Nafallo> nice wording :-)
[10:38] <sivang> Nafallo: I know ddaa will like it :)
[10:41] <lifeless> ddaa: not sure what you mean
[10:41] <lifeless> ddaa: FWIW today is a public holiday here
[10:42] <lifeless> if you mean the abstract VCS interface, thats about the only thing that made cscvs bearable to work with when dealing with svn and cvs at the same time
[10:51] <ddaa> ho, no, that's the good part of it
[10:53] <ddaa> I mean stuff like "checkout", "diff", etc.
[10:53] <ddaa> and cmds.todo
[10:53] <ddaa> anyway, have a nice holiday
[10:55] <lifeless> oh
[10:55] <lifeless> well frankly I'd ignore that
[10:55] <lifeless> as it has nothing to do with arch/bzr support
[10:55] <lifeless> and if we ever get to release cscvs again, its kinda useful
[11:18] <ddaa> well, if you say it's useful...
[11:18] <ddaa> and I do plan to get cscvs released, if only because I do want to spend the rest of my career fixing it.
[11:19] <ddaa> lifeless: so, what do you think of rooting out arch support?


[00:02] <kyrofa> That type of thing has been pretty handy for me in the past, I'd rather not lose it
[00:05] <kyrofa> Suddenly all commands must be 1) binaries within the snap, and 2) be paths relative to the root of the snap, when historically neither was the case
[00:06] <kyrofa> (from the point of view of a user of the snapcraft CLI)
[00:12] <niemeyer> kyrofa: Historically that was actually the case in the design we discussed at least
[00:12] <niemeyer> kyrofa: It's trivial to have any content inside a script
[00:13] <niemeyer> kyrofa: And the path of the command being relative to the snap just means you know what you are calling
[00:14] <niemeyer> kyrofa: Instead of trusting on the environment of the snap to define what a command even means
[00:14] <niemeyer> kyrofa: The application stanza was supposed to be a way to hook up a script, not be the script
[00:15] <niemeyer> kyrofa: EIther way, we have what we have.. let's catch up next week and spend some quality time to agree on a way to move forward that has more pros than cons
[00:16] <niemeyer> kyrofa: By the way, that's always been part of the reason why I have a deep dislike for wrappers.. it makes it all magical and hard to understand a consistent design
[01:19] <hunterk> hey guys, does vulkan work with snap packages?
[01:27] <hunterk> I ask because I make the snap package for RetroArch and I've been trying to get our vulkan driver to work with it but it's just not coming together
[01:28] <hunterk> I figured I'd check here before continuing to bang my head against it
[01:29] <hunterk> it looks like libvulkan1 is getting included properly...
[07:02] <pstolowski> morning
[07:31] <zyga> hey hey
[07:31] <zyga> boy, what a damp morning it is
[08:03] <Chipaca> moin moin
[08:04] <Chipaca> have you seen https://launchpadlibrarian.net/378130619/journalctl_-u_snapd.txt ?
[08:04] <Chipaca> not sure what to make of it
[08:05] <zyga> good morning Chipaca
[08:05]  * zyga looks
[08:06] <zyga> Chipaca: hmm, we are type: notify
[08:07] <zyga> and it seems we didn't respond in time
[08:07] <Chipaca> zyga: yeah, this is attached to the #1779948 so maybe it's just that
[08:07] <mup> Bug #1779948: Snapd gets stuck when starting Ubuntu. <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1779948>
[08:07] <Chipaca> zyga: the dns thing threw is what puzzles me though
[08:08] <zyga> that dns thing looks like resolved
[08:08] <Chipaca> zyga: did they call it that just to make conversation about its bugs harder
[08:08] <zyga> Chipaca: could it be first boot and seeding and what not on an offline system with super laggy dns
[08:08] <zyga> like I have a dns at home that doesn't work over tcp
[08:09] <zyga> and doesn't work over udp with packet fragmentation
[08:09] <zyga> so stuff keeps falling back to older/crappier version
[08:09] <zyga> but it takes time each time
[08:09] <zyga> actually
[08:09] <zyga> about that:
[08:09] <Chipaca> zyga: it's not first boot (earlier in the log output you see things being fine)
[08:09] <zyga> Chipaca: I read that you can tell systemd that you are alive and still starting
[08:09] <zyga> but not ready yet
[08:09] <Chipaca> zyga: yes
[08:09] <zyga> and then systemd extends the startup timeout
[08:09] <pedronis> anyway reaching notify shouldn't involve seeding or any task really
[08:09] <zyga> maybe we should?
[08:10] <Chipaca> zyga: problem is that the random drain was done from an init() i think, so too early for us
[08:10] <Chipaca> early and in arbitrary order i think (but i'm not sure)
[08:10] <Chipaca> pedronis: mo'in! how're you doing today?
[08:10] <pedronis> could be better, could be worse
[08:11] <pedronis> Chipaca: could you look at #5473 when you have a bit of time
[08:11] <mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
[08:12] <Chipaca> pedronis: yep
[08:12] <pedronis> Chipaca: I suppose, I should look at the warnings PR when I have a bit of time
[08:13] <Chipaca> pedronis: no rush
[08:32] <Chipaca> afk, bbiab (need to go to the boys' school)
[09:07] <pstolowski> need to take my daughter to the doctor, bbiab
[09:15] <mup> PR snapd#5499 opened: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[09:17] <mup> PR snapd#5500 opened: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[09:23] <mup> PR snapd#5501 opened: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <https://github.com/snapcore/snapd/pull/5501>
[09:34]  * Chipaca returns
[09:35] <Chipaca> zyga: did you see what i said yesterday about not trying to start an app with an unconnected daemon-notify?
[09:37] <zyga> mmmj
[09:37] <zyga> maybe/
[09:37] <zyga> I thought that was Samuele
[09:37] <zyga> can you repeat please?
[09:40] <Chipaca> zyga: “what we should do in snapd is not try to start a service if it's type:notify and it's not connected”
[09:40] <Chipaca> that last 'it' is the daemon-notify interface
[09:42] <zyga> mmm
[09:42] <zyga> I didn't see that
[09:42] <zyga> not sure if I agree, we should generalize that to be able to say
[09:42] <zyga> this snap cannot be installed (or perhaps activated) when {set of interfaces} are not connected
[09:48] <zyga> Chipaca: something like: plugs: daemon-notify: required: true
[09:51] <Chipaca> zyga: the problem with generalising it is that then you need to make it general
[09:52] <zyga> well, the problem of specializing it is that then you need to make it general too ;)
[09:52] <Chipaca> zyga: first of all, required:true sounds wrong, like the snap won't install
[09:52] <Chipaca> zyga: but that's just a name
[09:52] <Chipaca> zyga: what happens if you put required:true on an app?
[09:52] <Chipaca> on a plug on an app i mean
[09:52] <zyga> Chipaca: one of the questions is if we want to have partially enabled snaps
[09:52] <zyga> like you have app1 and app2 but not app3
[09:53] <Chipaca> zyga: and it starts to seem more masturbatory than practical
[09:53] <zyga> Chipaca: the syntax won't allow that AFAIK but even if it did my point was to indicate a given plug or slot as required, not the association
[09:53] <Chipaca> zyga: I didn't follow that last bit
[09:54] <zyga> defining a plug or slot on an app does two things:
[09:54] <zyga> defines the plug or slot
[09:54] <zyga> indicates association with an app
[09:54] <zyga> my point was that the attribute ought to be associated with the interface, not with the association
[09:54] <zyga> my gut feeling is this:
[09:54] <zyga> let's sleep over it, think and come up with brainstorm material
[09:55] <zyga> we can implement the subset for daemon-notify once we know where we want to go to
[09:55] <zyga> so that we can implement a slice of the bigger cake
[10:00] <Chipaca> zyga: where is this cake, and does it go well with coffee
[10:00] <zyga> Chipaca: you are tempting me sir ;)
[10:00] <Chipaca> zyga: cakes that don't go well with coffee: https://en.wikipedia.org/wiki/Yellowcake
[10:00] <zyga> there is raspberry cake indoors
[10:01] <zyga> it's raining all night and all morning here
[10:01] <zyga> so mood is perfect for cake
[10:03] <Chipaca> zyga: nice gentle rain in the middle of a forest? heck yea
[10:03] <zyga> Chipaca: heck ...bzzzz (mosquito) yeah :(
[10:03] <Chipaca> cake and spiced tea, or spiced cake and tea
[10:03] <zyga> it's okay but at most 2/3 days a week
[10:04] <zyga> I recall summer holidays when there was really no day without this never-ending rain
[10:04] <Chipaca> zyga: ah, yes, after the second night it suddenly becomes a dystopia
[10:04] <zyga> it's supposed to rain for the next 10 days
[10:04] <Chipaca> "la ciénaga" but with rain
[10:05] <Chipaca> zyga: "oops they moved my flight i need  to leave right now to make it byeeeee"
[10:05] <zyga> hahah
[10:05] <zyga> montreal feels like going to the other hemisphere now
[10:06] <Chipaca> zyga: almost but not quite
[10:06] <Chipaca> vancouver would be
[10:07] <Chipaca> zyga: bah, even montreal gets you from positive to negative longitudes
[10:07] <Chipaca> so technically yes :-)
[10:12] <niemeyer> Mornings
[10:14] <Chipaca> [citation needed]
[10:19] <zyga> my LTE link is down
[10:19] <zyga> not sure if I can do standup video today
[10:19] <zyga> if the weather continues like that
[10:20] <AuroraAvenue> It surprises me that there are no separate ways to flag an issue with the developer with snap - except github or launchpad.
[10:23] <popey> AuroraAvenue: do you have a specific issue to report?
[10:31] <AuroraAvenue> popey, well I am tired, very tired, but if its an issue ya want then its an issue I'll grant you.
[10:31] <AuroraAvenue> Xonotic doesn't open on Solus Os.
[10:31] <popey> is there any kind of error message?
[10:32] <popey> (if launched from the command line)
[10:32] <AuroraAvenue> erm, hangon #fatfingers (me).
[10:33] <AuroraAvenue> https://paste.ubuntu.com/p/Vhs5CgqK2J/
[10:34] <popey> interesting. what's the output of `snap version` please?
[10:35] <AuroraAvenue> I type > snap xonotic , right ?
[10:35] <popey> `snap version`
[10:35] <AuroraAvenue> oh sorry
[10:36] <popey> I just installed it on Solus here and it works.
[10:37] <AuroraAvenue> https://paste.ubuntu.com/p/PdDgrwtjCd/
[10:37] <AuroraAvenue> must be my crud laptop, then.
[10:38] <AuroraAvenue> popey, this isnot a pressing issue by the way.
[10:38] <popey> it is more likely a kernel issue
[10:38] <niemeyer> popey, AuroraAvenue: That looks like a confinement issue.. from the error message, looks like it cannot change to another apparmor profile
[10:38] <niemeyer> zyga ^
[10:38] <niemeyer> zyga: Any ideas?
[10:38] <zyga> looking
[10:38] <AuroraAvenue> right - originally install from solus 3.999 - its updated to past v.4 now - all upto date though.
[10:39] <zyga> AuroraAvenue: hey
[10:39] <zyga> I reported this issue to ikey a few weeks ago
[10:39] <AuroraAvenue> hello
[10:39] <zyga> AuroraAvenue: please run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*
[10:39] <AuroraAvenue> right-oh
[10:39] <zyga> and see if this fixes the issue
[10:39] <niemeyer> AuroraAvenue: Depending on the version of snapd you are using, the snapd there may not be able to tell that the world shifted around it
[10:39] <niemeyer> AuroraAvenue: More recent versions (as of several months now) can tell that, and will recompile things automatically when necessary
[10:40] <zyga> it seems that apparmor in solus stopped loading profiles generated by snapd on boot
[10:40] <niemeyer> AuroraAvenue: But it may always be an unrelated bug, obviously
[10:40] <Chipaca> popey: what was the name of that better zenity you were using for i-don't-remember-which-snap?
[10:40] <popey> yad
[10:40] <popey> (used in tmnationsforever)
[10:40] <Chipaca> popey: care to comment on https://forum.snapcraft.io/t/zenity-dialogs-in-a-snap/6359 about the why?
[10:41] <Chipaca> popey: otherwise I will, and steal your karma
[10:41] <AuroraAvenue> Okay - were rockin' xonotic now :D
[10:41] <popey> woohoo
[10:41] <Chipaca> AuroraAvenue: now put down the fps and get some sleep
[10:41] <AuroraAvenue> yeah - must go to bed, your very true.
[10:41] <AuroraAvenue> okay bye then.
[10:41] <popey> :)
[10:41] <AuroraAvenue> & thank-you
[10:42] <popey> thanks for the report
[10:46] <zyga> I'll ask ikey again
[10:50] <popey> zyga: does this only affect new installs?
[10:50] <popey> my vm works fine, and it's up to date
[10:53] <daniellimws> hi, I know someone that recently received emails regarding snapcraft saying packages from the Ubuntu archive have received security updates, and even after making a small commit to rebuild the snap, he still receives these emails
[10:53] <daniellimws> may I know if there's anything he missed?
[10:54] <daniellimws> https://github.com/dj3500/hightail/pull/105#issuecomment-349701547
[10:54] <mup> PR dj3500/hightail#105: Add snapcraft <Created by daniellimws> <Merged by dj3500> <https://github.com/dj3500/hightail/pull/105>
[10:54] <popey> daniellimws: he probably got multiple emails over a few days
[10:54] <popey> one for libjpeg and another for libcups2 and libpng12
[10:55] <daniellimws> oh, so he does not need to do anything right? it will stop soon?
[10:55] <popey> No, it will not stop.
[10:55] <popey> He only gets one mail per security update.
[10:55] <popey> but there were likely two security mails for different libraries.
[10:55] <popey> He needs to trigger a rebuild and publish it
[10:55] <daniellimws> ok thanks!
[10:56] <popey> no problem
[10:57] <ogra_> i wonder if anything in the mail text isnt clear enough
[10:57] <ogra_> but re-reading the ones i got i personally find it pretty clear and understandable
[10:59] <ogra_> perhaps some hint that this can happen frequently and even frequently in succession might be helpful ?
[11:03] <zyga> popey: I don't know
[11:03] <zyga> popey: perhaps?
[11:03] <zyga> popey: but it was clearly the case that on reboot profiles were not loaded
[11:03] <popey> Strange.
[11:04] <zyga> and the command I gave above was fixing it
[11:08] <niemeyer> pedronis, pstolowski: #4767 reviewed
[11:08] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[11:09] <pstolowski> niemeyer: thank you
[11:09] <niemeyer> pedronis, pstolowski: If possible, please have a look soon over the comments so we can discuss further today
[11:17] <pedronis> I added some more thoughts on one of the main comments
[11:24] <zyga> niemeyer: I pushed to https://github.com/snapcore/snapd/pull/5410
[11:24] <zyga> running with --repeat 50 here
[11:24] <mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
[11:24] <zyga> so far so good
[11:26] <niemeyer> pedronis: +1 on the general idea there
[11:27] <zyga> Chipaca: hey, what's the back story for https://github.com/snapcore/snapd/pull/5494
[11:27] <mup> PR #5494: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494>
[11:27] <zyga> it looks ok but curious?
[11:31] <pedronis> zyga: ?
[11:31] <zyga> pedronis: ?
[11:31] <zyga> are you asking about 5494
[11:31] <pedronis> yes, John said the progress bar messes up the logs
[11:32] <pedronis> not sure what is curious about that
[11:33] <zyga> pedronis: well, that's what I was after
[11:34] <zyga> there was no commit message that would say as much
[11:36] <pedronis> he staid that at standup
[11:36] <pedronis> *said
[11:37] <zyga> must have slipped my mind, thank you
[11:38] <zyga> pedronis: can you have a 2nd look on https://github.com/snapcore/snapd/pull/5492
[11:38] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[11:38] <zyga> I dropped the functions that were problematic now; because of the re-factor in master they are no longer needed
[11:53] <Chipaca> zyga: what pedronis said
[11:53] <Chipaca> zyga: what's the commit message say?
[11:53]  * Chipaca looks
[11:53] <zyga> it says what's changed (-n) not why
[11:54] <Chipaca> zyga: oops. fixed.
[11:54] <zyga> thank you :)
[11:54] <Chipaca> np
[11:54] <zyga> I'll get some warm tea and be back shortly
[11:54] <Chipaca> lunch
[11:54] <zyga> it's so cold and humid today :/
[11:55] <zyga> is damp the best way to express that?
[11:55] <Chipaca> not sure,  i only begin to scratch the surface of the weather vocabulary
[11:59] <pedronis> pstolowski: hi, could you finish looking at #5473 ?
[11:59] <mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
[12:04] <pstolowski> pedronis: will do
[12:24] <zyga> pstolowski: I think you would be a good person to co-review https://github.com/snapcore/snapd/pull/5492
[12:24] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[12:24] <zyga> https://github.com/snapcore/snapd/pull/5499 is trivial an green
[12:24] <mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[12:25] <zyga> https://github.com/snapcore/snapd/pull/5500 is very simple and green
[12:25] <mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[12:40] <zyga> pedronis: I pushed a fix to one of the core18 PRs you reviewed https://github.com/snapcore/snapd/pull/5401
[12:40] <mup> PR #5401: [RFC] asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5401>
[12:42] <pstolowski> zyga: sure
[12:43] <pedronis> zyga: ah, thanks also for checking for classic (it doesn't make sense there)
[13:23] <zyga> jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/5469
[13:23] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[13:30] <hunterk> does vulkan work with snap packages?
[13:56] <jdstrand> zyga: yes (it's on the list already). I looked at it but want to check out a few things
[14:00]  * zyga -> coffee
[14:01] <zyga> jdstrand: super, thank you
[14:01] <zyga> hunterk: hey, I believe it may but we don't have an end-to-end test for that
[14:01] <zyga> hunterk: if you plan to make a snap with vulkan support please stay in touch
[14:01] <zyga> hunterk: if you know of one please share it and try it out
[14:02] <hunterk> eyy, thanks for the response! I added the dependencies to the RetroArch snap and it fails to load. Self-compiled (i.e., non-snap) works
[14:02] <hunterk> but I figured it might need a plug or something, like the way there are Wayland and X11 plugs
[14:02] <hunterk> https://github.com/libretro/retroarch-snap
[14:03] <hunterk> btw, thanks popey for the recent PR!
[14:03] <popey> np :)
[14:05] <jdstrand> roadmr: hey, can you pull r1102? this has the epochs changes and two other bugs reported by the store team (and a fix for arm64)
[14:05] <jdstrand> s/bugs/bug fixes/
[14:05] <roadmr> hi jdstrand
[14:05] <roadmr> sure, I'll do that
[14:06] <jdstrand> roadmr: thanks! :)
[14:13] <jdstrand> sergiusens_: hey, can you remind me about something with the vm work? I have little armhf and arm64 boards with Ubuntu Core that I 'snap install classic' and then install the snapcraft deb in them, then run 'snapcraft'. this has been the recommended way to build snaps for architectures that don't match one's laptop/desktop
[14:13] <jdstrand> sergiusens_: while it is possible to use qemu to fully emulate armhf or arm64, that is painfully slow. will the new vm require a slow vm or can I still use the classic snap in this manner?
[14:14] <popey> jdstrand: surely launchpad is faster?
[14:15] <jdstrand> popey: no, it isn't. my builds won't start for an hour atm for both armhf and arm64
[14:15] <jdstrand> that is pretty common in my experiencce. plus, sometimes you don't want to push something to edge. you want to test before pushing to edge
[14:15] <popey> Sure.
[14:15] <popey> I tend to use a Pi running classic
[14:16] <popey> not core
[14:16] <jdstrand> that's the same question essentially
[14:17] <jdstrand> I don't have vms of armhf and arm64, so what will I have to do in the new world?
[14:20] <zyga> hunterk: do you get any apparmor denials? missing so files on startup?
[14:20] <jdstrand> s/will the new vm/will the new vm work/
[14:21]  * zyga finished some life interrupts and returns to coffee and another patch
[14:23] <mup> PR snapd#5501 closed: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5501>
[14:24] <sergiusens_> jdstrand: there is going to be a I know what I doing kind of toggle where you won't be forced into a VM
[14:25] <sergiusens_> jdstrand: the "I know what I am doing" and the implications of that (also related to buildd, docker and what not) has a session setup for the sprint next week; I suggest you attend :-)
[14:26] <sergiusens_> jdstrand: we have two follow up stories wrt cross compiling and native building which aren't ironed out completely; as a personal sidenote, building using qemu-system-aarch64 for me was faster tha building on a rpi with its really slow i/o.
[14:29] <hunterk> zyga: no, it just says it can't find the vulkan loader, though the vulkan loader lib (libvulkan1) is indeed in the snap's libs
[14:34] <mup> PR snapd#5502 opened: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502>
[14:35] <pedronis> Chipaca: pstolowski:  ^
[14:36] <pstolowski> thanks
[14:36] <Chipaca> pedronis: ack
[14:37] <mup> PR snapd#5503 opened: tests: add missing slots in classic and core provider test snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5503>
[14:41] <zyga> hunterk: hmm, can you wait till next week, we have one person on the team that worked on vulkan lately
[14:41] <zyga> hunterk: just show up on Monday and ask mborzecki here
[14:42] <hunterk> sure thing. I'll just idle in here and they can ping me or I'll ping them
[14:43] <zyga> hunterk: thank you, and welcome :)
[14:44] <zyga> hunterk: we cannot fix and find everything outselves so hands on experiments and feedback like yours is crucial
[14:44] <hunterk> my pleasure. I've been enjoying the snap format so far
[14:45] <popey> <3
[14:46] <zyga> I imagine it's quite like the 0.x days of dpkg :)
[14:46] <zyga> just with different set of issues
[14:51] <zyga> niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/5410 please
[14:51] <mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
[14:56] <pedronis> zyga: is some kind of follow up using #5492 up for review?
[14:56] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[14:56] <zyga> pedronis: yes, there's a PR with everything remaining ...
[14:57] <pedronis> zyga: ?
[14:57] <zyga> pedronis: here
[14:57] <zyga> https://github.com/snapcore/snapd/pull/5491
[14:57] <mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
[14:58] <pedronis> zyga: why is it blocked and not marked core18 ?
[14:59] <zyga> because that is my integration PR and as I said in the description there the point is to review this patch by patch to avoid one big PR it was before
[14:59] <zyga> as for core18, yeah, it should be marked
[14:59] <zyga> if you prefer to review the whole lot we can do that too
[14:59] <zyga> it's the same code
[15:00] <pedronis> zyga: I don't prefer the whole lot, but I prefere something with a bit of usage
[15:00] <pedronis> before approving the other one
[15:00] <zyga> that's why I cross-linked them
[15:01] <zyga> so reviewers can see the code in context
[15:01] <pedronis> ?
[15:01] <pedronis> an integration branch might or might not be context
[15:01] <pedronis> it depends how close to final it is
[15:02] <pedronis> I'm just a bit confused atm
[15:02] <zyga> sorry about that, the cross linked branch is the complete use case
[15:02] <zyga> everything I intended this for
[15:02] <zyga> this is not the huge core18 integration branch that mvo opened, it's scoped and focused for interface remapping alone
[15:03] <pedronis> ok, then there is nothing to split out of it, no?
[15:03] <zyga> that's correct
[15:03] <pedronis> it needs to be marked core18 and reviewed?
[15:03] <zyga> it's just the first patch out of the set
[15:03] <pedronis> which one?
[15:03] <pedronis> are you talking 5491 or 5492 or both?
[15:04] <zyga> the small PR (5492) is just the first patch of the whole feature (5491)
[15:04] <zyga> in reality we could close 5492 and review 5491 but I thought this would be harder
[15:04] <pedronis> but you said there is nothing more to split out of 5491  ?
[15:04] <pedronis> I'm missing what "first" means here
[15:05] <zyga> nothing to split as in split one patch into two
[15:05] <zyga> it's just a way to review patch-by-patch on github
[15:05] <pedronis> you lost me
[15:05] <pedronis> what more patches are coming?
[15:05] <pedronis> things before 5491 or after?
[15:05] <zyga> there are two branches, one with 5 patches, one with 2 patches that are the 2 oldest of the 5
[15:05] <zyga> before nothing
[15:06] <zyga> after all of this lands we need to actually enable "snapd" to host implicit slots, this is not proposed yet as that was blocked by a number of other branches
[15:06] <pedronis> are you saying you will make a PR for each patch in 5491 ?
[15:06] <zyga> that was my plan, yes
[15:06] <pedronis> ????
[15:07] <pedronis> it doesn't seem that big
[15:07] <pedronis> but maybe I'm missing something
[15:07] <zyga> no, that's all really, if you think reviewing 5491 is okay we can just do that instead
[15:07] <pedronis> yes, might be simpler
[15:07] <zyga> I tend do to this because shorter reviews are easier to collect
[15:08] <zyga> pedronis: feel free to close 5492 and let's focus on 91 then :)
[15:08] <pedronis> to be clear  I like patches <300,  I can live with 500+, I find stuff over 600 large, but also dislike reviewing stuff without context
[15:08] <zyga> understood
[15:08] <zyga> I should have communicated that clearer in the PRs
[15:10] <pedronis> yes, the fact that they are obviously out of order and not all tagged confused things a bit more
[15:11] <pedronis> zyga: I'll try to go over 5492 in my morning tomorrow
[15:11] <zyga> pedronis: thank you
[15:12] <zyga> shall I close https://github.com/snapcore/snapd/pull/5492 ?
[15:12] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[15:12] <mup> PR snapcraft#2179 opened: cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2179>
[15:12] <pedronis> zyga: yes
[15:12] <pedronis> sorry, I mean going over 5491
[15:13] <zyga> ah, yes
[15:13] <mup> PR snapd#5492 closed: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5492>
[15:13] <zyga> since the history is the same you can look at how the usage is on either "end" of snapd by looking at
[15:13] <zyga> https://github.com/snapcore/snapd/pull/5491/commits/0a53fdc733ffe1d1ca0fc0bf0d619e333ac73e3b
[15:13] <mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
[15:13] <zyga> https://github.com/snapcore/snapd/pull/5491/commits/24c2448b880321f6bf28da24b3cc7bedfef06ece
[15:14] <zyga> the API tests in the latter patch are interesting, I used a case-swapping mapper to show how things like "snap connect PLUG:SLOT" are handled
[15:15] <zyga> similar approach was used in the state tests
[15:15] <zyga> though there the change is smaller
[15:19] <zyga> thank you pedronis!
[15:19] <zyga> I need to break for a walk with Bit soon
[15:19] <zyga> but expect one more PR from me
[15:19] <zyga> pedronis: and if we can land a support branch for tests I will also have the patch that enables implicit slots on snapd snap
[15:41] <mup> PR snapd#5504 opened: interfaces/pulseaudio: be clear that the interface allows playback and record <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5504>
[16:17] <jdstrand> niemeyer: fyi, https://forum.snapcraft.io/t/pulseaudio-recording/6361. It would be good if someone (I've requested the desktop team) to drive this, but want you to be aware
[16:20] <Saviq> kyrofa: hey, is `snapcraftctl set-version` a thing yet?
[16:50] <niemeyer> jdstrand: Thanks, looking
[16:56] <niemeyer> jdstrand: Commented
[17:07] <jdstrand> niemeyer: thanks, I responded
[17:07] <kyrofa> Saviq, yessir, https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
[17:10] <sergiusens_> Saviq: kyrofa for an easier to read version of that https://snapdocs.labix.org/extracting-information-from-sources-in-snapcraft-parts/4642
[17:11] <niemeyer> jdstrand: re-replied
[17:21] <Saviq> kyrofa, sergiusens_: thanks :)
[17:21] <Saviq> store folk, can you say what does this store upload fail mean: https://launchpad.net/~mir-team/+snap/mir-kiosk-edge/+build/276950 ?
[17:57] <jdstrand> niemeyer: and so did I, twice. and will replied
[18:20]  * zyga returned from a 10km walk :)
[19:19] <zyga> jdstrand: https://lwn.net/Articles/759499/ (!!!)
[19:20] <jdstrand> apparently my subscription has expired
[19:33] <zyga> feels like I could write snap-confine again with those new syscalls
[19:53] <zyga> jdstrand: can you ack trivial https://github.com/snapcore/snapd/pull/5500 and even more so https://github.com/snapcore/snapd/pull/5499
[19:53] <mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[19:53] <mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[20:14] <jdstrand> zyga: done
[20:22] <zyga> thank you
[20:23] <mup> PR snapd#5500 closed: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5500>
[20:24] <mup> PR snapd#5499 closed: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5499>


[03:33] <dantalizing> anyone awake?
[03:34] <jk-> technically
[03:34] <jk-> but it seems to be a two-coffee morning, and I've only had one
[03:36] <dantalizing> its too late at night to be morning
[08:46]  * smb fetches #2
[08:52]  * apw yawns
[08:52] <smb> apw, Morning
[09:08] <smb> cking, If you did not "hear" a good morning, your mumble is broken. :)
[09:10]  * cking gives it a kick
[09:15] <cking> smb, mumble failed again?
[09:26] <apw> i think smb's router needs rebooting at midnight
[12:17] <apw> bah i hate Qt already
[12:55] <ogra> apw, do you have to add new Qt bits to the kernel now ?
[12:56] <apw> ogra, heh thankfully not ... trying to figure out why mumble is broke on natty
[12:56] <ogra> lol
[12:56] <apw> finally annoyed me enough to try and fix it
[12:56] <ogra> i think we all did already
[12:56] <ogra> and all of us gave up :P
[12:56] <apw> wondering if it is actually a unity related issue
[12:57] <ogra> (at least everyone i talked to up to now had at least one mumble prob)
[12:57] <apw> or perhaps even a qt library issue
[12:57] <ogra> might be compiz, yep
[12:57] <apw> we seem to have asked for the input events, but they are not getting delivered
[12:57] <ogra> try using std. gnome and metacity and see if it fails there too
[12:58] <apw> is there a way to switch live?  i know unity does temporarily when resetting
[12:58] <ogra> hmm, no idea, i usually do it at gdm
[13:02] <amitk> apw: what is the problem? my mumble doesn't read my hotkey anymore
[15:04] <novice27> hi. i am through with all the wiki bug triaging pages. but i am not getting from where to start? how to pick a bug and from where? please suggest.
[15:16] <apw> novice27, hiya, our main trige guy is off today, he would be the best person to help you
[15:16] <apw> novice27, but mostly we start with the 'New' bugs on the 'linux' package
[15:17] <apw> which one can find on launchpad
[15:17]  * apw drops to reboot, in the vein hope that the unity update will help ... i am sick to death of it crashing
[15:18] <novice27> apw: okiez.. thanks... but i dont know how to start practically. but let me check the page :)
[15:20] <apw> novice27, forgot to mention, his irc nick is jFo
[15:20] <novice27> apw: thanks... :)...
[15:21] <novice27> apw:  i want to get into kernel development.. i have decided to start with bug triaging.. can u please some more?....
[15:22] <novice27> apw: *suggest
[15:24] <apw> novice27, we usually suggest that, looking at bugs and gets you to see what areas there are, and what intrests you
[15:24] <apw> and in trying to solve them, which tends to happen with ones you are interested about, you tend to learn new things
[15:24] <apw> which help you as you start to find bugs and write fixes
[15:26] <novice27> apw: do i need to read books on linux kernel programming?
[15:27] <apw> it depends how you find it as you go, some people just read the code around an issue and pick it up that way
[15:27] <apw> its personal preference
[15:27] <apw> reading a book on it is usually interesting, but they do tend to be out of date
[15:30] <novice27> apw: ya.. they are of 2006 edition... i will start with the isues then and try them. thanks for help...:)
[15:36]  * apw whines about unity, impotently
[15:52] <BigRedS> What's the difference between HIGHMEM4G and HIGHMEM64G (besides the '6')? Why would one choose just the 4?
[15:58] <mjg59> Beacause enabling PAE means you take a performance hit
[16:00] <BigRedS> But both are PAE aren't they?
[16:02] <mjg59> No
[16:02] <mjg59> You can access 4G without PAE


[02:48] <bjsnider> i'm getting a barrage of emails from apparently different users complaining about the keyserver failing on ppas
[03:04] <wgrant> Yes, it is somewhat unwell at the moment :(
[03:04] <wgrant> Has been for a few hours, by the look of things.
[05:13] <maco> lifeless: halp!
[05:14] <maco> lifeless: bzr is doing things different and confusing now :(
[05:14] <wgrant> maco: What's it doing?
[05:15] <maco> its acting like svn instead of bzr
[05:15] <wgrant> Howso?
[05:15] <maco> commit auto-pushed
[05:15] <maco> i know lp's docs say there's a mode like that
[05:15] <maco> how do i make it go back to distributed mode?
[05:15] <wgrant> See 'bzr help checkouts'
[05:15] <wgrant> Quick fix: bzr unbind
[05:16] <wgrant> 'bzr checkout' creates a bound branch by default. 'bzr branch' creates an unbound one.
[05:16] <wgrant> You switch between the two modes with 'bzr bind' and 'bzr unbind'.
[05:16] <maco> oh
[05:16] <maco> ok
[05:16] <maco> i think i was trying to use bind to change where the push-place was
[05:17] <wgrant> Did you mean 'bzr push --remember some://url'?
[05:17] <maco> yeah probably
[05:17] <maco> i dont recall seeing --remember in "man bzr" though
[05:17] <maco> thank you wgrant
[05:17] <wgrant> The manpage is not exhaustive.
[05:17] <wgrant> bzr help push
[05:18] <wgrant> Oh, it is pretty exhaustive now.
[05:18] <maco> so treat bzr like chanserv. ok.
[05:18] <wgrant> And --remember is there.
[05:18] <maco> yes it is. oops
[05:18] <wgrant> I forgot the manpage was autogenerated.
[05:18] <wgrant> ... and is 2500 lines long. Ouch.
[05:18] <maco> i probably expected it to be near "push" and it wasnt and so i then assumed some other command would do it
[05:19] <micahg> bzr help CMD is usually pretty useful
[05:19] <maco> um yeah 2500 manpages arent the sort you read..they're the sort you grep and hope you're grepping the right words
[05:19] <wgrant> Er, well, it is in the push section.
[05:19] <wgrant> micahg: The manpage appears to be a combination of most of the the 'bzr help' output.
[05:20] <micahg> wgrant: makes sense
[05:20] <maco> oh they have sections
[05:20] <maco> ok. lets just all remove 10 of my geek points now
[05:20] <maco> i think i looked at "command overview" and assumed that was it
[05:20] <wgrant> Heh, not quite :P
[05:22] <maco> i was trying to figure out how to make my branch be a team branch instead. i did a LOT of weird/wrong things to it in the meantime. then nigelb found the "change owner" option in the "branch details" section and so i went and used that and filed a bug saying it was too hard to find the "change owner" thing
[05:22] <micahg> maco: I thought you just push under the team in LP
[05:23] <maco> the team didnt have a branch yet and i was confused
[05:23] <maco> and when i tried doing that it said it was "stacking" the team branch on top of my branch
[05:23] <maco> and then i got more confused
[05:23] <wgrant> You can either move it or just push to a location that doesn't exist yet.
[05:23] <wgrant> Ah, well, it will indeed stack if your branch is set as the development focus.
[05:23] <maco> where "move it" means "find that change-owner thingy" right?
[05:23] <micahg> that's one feature I love about bzr is the autocreation when pushing
[05:24] <wgrant> Right.
[05:24] <wgrant> micahg: Yeah, the combination of bzr and LP there is pretty awesome.
[05:24] <maco> oh is THAT why it did that??
[05:24] <wgrant> Yes.
[05:25] <maco> well now i have things a bit muddled in gally & gally-asl. at least one of them has its development branch stacking on my branch now because i couldnt figure out how to move it
[05:25] <wgrant> So, you want the team branch to be the dev focus?
[05:25] <maco> yes
[05:25] <maco> i have it pointed that way now
[05:26] <maco> but because when i made the team branch, mine was the dev focus, the current-dev-focus one stacks on top of mine
[05:26] <wgrant> There are only two gally branches.
[05:26] <wgrant> Neither is stacked.
[05:26] <maco> gally-asl then, i guess
[05:26] <maco> i got one of them right and one of them wrong
[05:26] <wgrant> Are you sure you didn't delete the newly created team branch, then rename the old one?
[05:26] <maco> thats what i did with gally
[05:27] <wgrant> See, gally-asl has only one branch.
[05:27] <maco> oh or maybe i repeated that on gally-asl now too
[05:27] <wgrant> So it's not stacked.
[05:27] <maco> bah im so confused
[05:27] <wgrant> Moving the dev focus around, when combined with stacking, can be pretty confusing, yes.
[05:28] <maco> the last 2 days' worth of launchpad & bzr usage have been weeeeird
[05:29] <maco> by the way, when creating a team, there's no way to set its owner at that point right? you just create it, then use the change-owner thing for the team then (if youre in the team that you made be owner) delete yourself?
[05:29] <wgrant> Right, you can't set the owner at creation time.
[05:30] <wgrant> Which is perhaps slightly inconvenient.
[06:56] <wgrant> lamont: Hmm. Build farm disaster?
[06:56] <wgrant> A few 'No route to host's, and lots of Fault 8002s on i386, which makes me suspect that a recipe build might have somehow made it through.
[11:25] <daker> hello @all
[11:26] <daker> is there any way to remove a translation template?
[13:42] <kalib> Hi there. Created a project in launchpad yesterday at morning. Wanna translate using it. I did upload 4 files and is still as "Nees Review". How long it will take?
[14:36] <FullFlannelJacke> Getting rejections to my ppa uploads and dont know why.
[14:37] <FullFlannelJacke> I uploaded it once and it was rejected because of my Changelog.  Then, after a lot of searching, i fixed that and uploaded it again.
[14:37] <FullFlannelJacke> Now it says that my package is "is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution."
[14:38] <FullFlannelJacke> anyone anyone?
[14:44] <FullFlannelJacke> I believe it is still an issue with ym changelog.  Can anyone please explain how in the world a changelog is supposed to look?  this is irritating that such a small thing is causing such a PITA
[14:44] <FullFlannelJacke> I am trying to package code I have written and I have no idea how the changelog should look when i have no bug reports, etc..
[14:47] <aakef> Hello all
[14:47] <aakef> Any one here who could help me with launchpad ppa uploads?
[14:48] <FullFlannelJacke> aakef: Im here for the same reason no one seems to be here
[14:48] <aakef> I registered a ppa page, uploaded to it with dput, but nothing happens
[14:48] <aakef> tell FullFlannelJacke: Hmm, thanks. Do you know a mailing list to ask on?
[14:48] <FullFlannelJacke> aakef: check your email.  Your package probably got rejected and you will get an email telling you why
[14:49] <FullFlannelJacke> aakef: if you have even a tiny error in one of the files in /debian, it will get rejected automatically
[14:50] <aakef> tell FullFlannelJacke: I don't get a single mail
[14:50] <FullFlannelJacke> and sometimes it can take 10-15 minutes to get the email
[14:50] <geser> aakef: is the gpg key you used for signing attached to your LP profile?
[14:50] <FullFlannelJacke> then if you got no email, then its likely your package is being "processed" by the server still
[14:50] <aakef> tell FullFlannelJacke: And as unionfs-fuse is already in Debian and Ubuntu, I don't think there is a packaging error
[14:51] <aakef> tell geser: Also already checked that, yes
[14:52] <FullFlannelJacke> GRRR.  My package just got rejected AGAIN.  Can anyone please tell me why my changelog keeps getting rejected?
[14:52] <geser> FullFlannelJacke: what error message?
[14:53] <FullFlannelJacke> saying that instabUnable to find distroseries: unstable
[14:53] <FullFlannelJacke> Unable to find distroseries: unstable
[14:53] <FullFlannelJacke> But if I put lucid in there I get yet another error message
[14:53] <aakef> tell FullFlannelJacke: That would be Debian upload
[14:53] <geser> PPA know only about Ubuntu release names, not Debian ones
[14:53] <FullFlannelJacke> Yeah but if I put lucid in there, it gets rejected still
[14:54] <aakef> tell FullFlannelJacke: I think you need to specify the Ubuntu distro, its in the lauchpad help page
[14:54] <FullFlannelJacke> if I put "lucid" there, i get this error:
[14:54] <FullFlannelJacke> is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.
[14:54] <geser> what's the package name and the version you try to upload?
[14:54] <wgrant> FullFlannelJacke: You need to increment the version.
[14:54] <wgrant> You can't upload the same version twice; that doesn't make sense.
[14:55] <FullFlannelJacke> This is MY package.  i wrote the code.  And it is version 1.0
[14:55] <FullFlannelJacke> And I have not yet uploaded it
[14:55] <wgrant> You did upload it.
[14:55] <FullFlannelJacke> so even if it gets rejected, i have to change the version?
[14:55] <wgrant> No, it must have been accepted at some point.
[14:56] <wgrant> Rejected versions do not count for the purposes of the version check.
[14:56] <geser> not for rejects, but once it accepted you have to even if the build fails
[14:56] <FullFlannelJacke> Well, I did upload it many months ago, but I deleted it because of a bug..So, i have no idea what version I should be using..
[14:56] <FullFlannelJacke> I guess I will try something like 1.2
[14:56] <geser> LP still remembers this old version
[15:01] <FullFlannelJacke> OK yes, I found it in LP..I will have to upload v1.02 or greater
[15:01] <FullFlannelJacke> I figured it only kept track if the package was *still* there.
[15:12] <aakef> When I got to my launchpad page, it does not even show "Technical details". Any idea? https://launchpad.net/~aakef/+archive/ppa
[15:13] <wgrant> aakef: There are no packages to install from it, so it does not show installation instructions.
[15:14] <wgrant> Did you sign the .changes file with the correct GPG key?
[15:14] <aakef> wgrant: I only have one key for the package mail adress
[15:15] <aakef> wgrant: If it at least would send me a single mail what is going wrong...
[15:15] <wgrant> aakef: If it's not signed properly, it cannot determine who to send an email to!
[15:20] <aakef> gpg: Good signature from "Bernd Schubert<EMAIL_ADDRESS>[15:20] <aakef> Successfully uploaded packages.
[15:21] <aakef> Arg, and now suddenly I got a mail
[15:26] <aakef> wgrant: Thanks, it worked! Seems the reason was that I had an old mail address in my key, but I recently deleted that key from launchpad
[15:26] <aakef> I mean i deleted that mail address from launchpad
[20:55] <ochosi> hi everyone
[20:56] <ochosi> is it possible to make launchpad automatically build packages from a git repo?
[20:56] <ochosi> on a regular basis
[21:16] <directhex> how come so many i386 ppa builders are disabled?
[22:02] <FullFlannelJacke> How long does it usually take for a package to be built?  Mine has been waiting 6 hours.
[22:12] <oojah> FullFlannelJacke: It varies greatly depending on what else has been submitted.
[22:12] <oojah> FullFlannelJacke: But at the moment it looks as though there is a problem. See: https://launchpad.net/builders/
[22:12] <FullFlannelJacke> Must have been a lot of submissions today
[22:13] <directhex> FullFlannelJacke, depends on the size of the queue. or, in today's case, whether 80% of i386 PPA builders are disabled
[22:14] <FullFlannelJacke> hmm i wonder why so many are disabled?
[22:20] <wgrant> FullFlannelJacke: A network glitch, it appears.
[22:20] <wgrant> An admin should be around in a couple of hours; I'll poke them.
[23:33] <FullFlannelJacke> can anyone tell me why my build is failing?
[23:34] <FullFlannelJacke> it is saying something about it cant find the data files because they dont exist
[23:34] <FullFlannelJacke> even though they do