[00:04] <poolie_> whos' the on-call reviewer? does that concept still exist?
[00:06] <lifeless> thumper: http://nosql.mypopescu.com/post/619181345/nosql-graph-database-matrix
[00:06] <lifeless> poolie_: it does, check #launchpad-reviews or the wiki page
[00:07] <poolie_> it's '-'
[00:07] <poolie_> ok
[00:07] <mwhudson> poolie_: that concept exists, but not really in this timezone
[00:08] <lifeless> poolie_: that means noone is on.
[00:08] <mwhudson> poolie_: i can probably take a look for you
[00:08] <lifeless> mwhudson: lp in pypy would be intereseting
[00:08] <lifeless> mwhudson: so would lp in jython
[00:08] <mwhudson> lifeless: right away, you need psycopg2
[00:08] <poolie_> thanks mwh
[00:09] <mwhudson> i'm not sure what else we have in the way of mandatory c extension modules
[00:09] <poolie_> mwhudson, could you sponsor landing https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/32173
[00:10] <mwhudson> poolie_: i think you meant to propose against devel, not db-devel?
[00:10] <poolie_> yes
[00:10] <poolie_> i don't know why db-devel is the defalut
[00:10] <poolie_> (well, i do; i think it's a bad default though)
[00:11] <poolie_> i guess i can re-propose it?
[00:12] <mwhudson> that's probably easiest
[00:13] <poolie_> ok https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
[00:13] <rockstar> wallyworld, I've made myself available for you this evening in case you get stuck, although you may have plenty of people around.
[00:13] <poolie_> hello rockstar
[00:13] <mwhudson> poolie_: ta
[00:14] <rockstar> poolie, hi
[00:14] <wallyworld> rockstar: thanks for the kind offer. i don't think i'll need you. feel free to have a glass or three of good wine without any guilt :-)
[00:15] <mwhudson> that would not be the guilt you are looking for, i suspect
[00:15] <rockstar> Hello quotes page...
[00:16] <mwhudson> poolie: i don't mean to be a pain, but i'm not sure that comment you're adding makes sense, has it lost its first line or something?
[00:20] <mwhudson> make is blowing up for me
[00:20] <mwhudson> IOError: [Errno 2] No such file or directory: 'lazr-js/build/choiceedit/assets/skins/sam/choiceedit-skin.css'
[00:21] <rockstar> mwhudson, is this in launchpad or lazr-js?
[00:21] <mwhudson> rockstar: launchpad
[00:21] <rockstar> mwhudson, shite.
[00:22] <mwhudson> rockstar: ah
[00:22] <mwhudson> $ ls -l lazr-js/build/choiceedit/assets/skins/sam/
[00:22] <mwhudson> total 8
[00:22] <mwhudson> -rw-r--r-- 1 mwh mwh 871 2010-09-24 11:20 choiceedit.css
[00:22] <mwhudson> lrwxrwxrwx 1 mwh mwh 101 2010-02-26 13:42 choiceedit-skin.css -> ../../../../../../eggs/lazr_js-0.9.2-py2.5.egg/lazrjs/choiceedit/assets/skins/sam/choiceedit-skin.css
[00:22] <rockstar> mwhudson, yeah, this is stuff I'm going to attack tonight.
[00:22] <mwhudson> rockstar: i just thought "you know, why don't i delete all these py2.5 eggs"
[00:23] <rockstar> mwhudson, hahaha.
[00:23] <rockstar> mwhudson, I HATE HATE HATE that we have to eggify javascript.
[00:23] <mwhudson> so this is one of those, we use make, kinda sorta problems
[00:23] <mwhudson> rockstar: yeah, i know
[00:23] <wgrant> mwhudson: Local codebrowse worked for me last week.
[00:23] <wgrant> But I haven't tried it since.
[00:23] <mwhudson> wgrant: ok cool
[00:30]  * rockstar relocates
[00:43] <mars> mwhudson, what exactly is a 'we use make' sorta problem?
[00:45] <mwhudson> mars: make traditionally tracks dependencies
[00:45] <mwhudson> so if you edit foo.c, foo.o gets rebuild and the foo binary gets relinked
[00:45] <mwhudson> mars: but if you edit versions.cfg and run make, we don't get that kind of effect
[00:45] <mwhudson> well maybe in that precise case we do, but in general we don't
[00:45] <mars> ah, yes.  foo.js gets lint, minified, concatenated, etc.
[00:46] <mars> yes, that makes sense, especially since most projects treat JavaScript as a compiled language now
[00:46] <lifeless> we could use make properly if we wanted
[00:47] <mwhudson> let's use automake!!1!
[00:47] <mars> as for make versus bin/buildout - that is something I haven't managed to figure out - both have advantages and drawbacks
[00:47] <mwhudson> (not really)
[00:47] <lifeless> mwhudson: I said properly.
[00:48] <mwhudson> one of the things i always liked about the cpython dev community: the appropriate amount of disdain for automake and libtool
[00:50] <mars> lifeless, the problem with Make is that we did use it, but it is a rather special language, and I gather not everyone knows how to use it well
[00:50] <poolie> mwhudson: i'll look
[00:50] <mars> lifeless, so our use of Make was not great
[00:50] <poolie> mwhudson: i have an autographed copy of the autotools goat book saying "I hope you never use this book -- Ben"
[00:51] <mwhudson> :-)
[00:52] <poolie> mwhudson: it's not cropped, it's just not a complete punctuated sentence
[00:52] <poolie> which jml told me the other day is the lp style
[00:52] <poolie> i can fix that
[00:52] <mwhudson> poolie: thanks
[00:53] <mwhudson> poolie: i'm not sure being a grammar nazi to the extent lp does is wise, but i do actually find that comment a bit hard to interpret
[00:54] <poolie>     166     while open_readers:
[00:54] <poolie>     167         # select() blocks for a long time and can easily fail with EINTR
[00:54] <poolie>     168         # <https://bugs.launchpad.net/launchpad/+bug/615740>.  Really we
[00:54] <poolie>     169         # should have EINTR protection across the whole script (other syscalls
[00:54] <poolie>     170         # might be interrupted) but this is the longest and most likely to
[00:54] <poolie>     171         # hit, and doing it perfectly in python has proved to be quite hard in
[00:54] <_mup_> Bug #615740: test_on_merge.py doesn't handle eintr <Launchpad Foundations:In Progress by mbp> <https://launchpad.net/bugs/615740>
[00:54] <poolie>     172         # bzr. -- mbp 20100924
[00:54] <poolie> is that clearer?
[00:55] <mwhudson> poolie: yes, that's much nicer, thanks
[00:55] <poolie> when you start insisting on passive voice i'll worry :)
[00:55] <mwhudson> poolie: i think i just wanted a subject for "blocks" really
[00:55] <poolie> 'lego'
[00:59] <poolie> anything else?
[01:04] <lifeless> how busy is staging db right now ?
[01:06] <wgrant> Hm.
[01:06] <wgrant> Debian just started running apt-ftparchive in parallel.
[01:06] <wgrant> That's actually not a bad idea.
[01:12] <rockstar> bzr is MUCH slower when I run `make schema` at the same time.
[01:12] <mars> rockstar, check your loadavg
[01:13] <rockstar> mars, I'm being a bit facetious.  EVERYTHING is much slower when running `make schema`
[01:13] <mars> :)
[01:13] <rockstar> I just wanted to rag on the bzr team for not being fast enough.
[01:14] <lifeless> :(
[01:15] <rockstar> lifeless, :)
[01:31] <poolie> rockstar: you could iorenice psql
[02:16] <lifeless>     Hard / Soft  Page ID
[02:17] <lifeless>      129 /  224  CodeImportSchedulerApplication:CodeImportSchedulerAPI
[02:17] <lifeless>      108 /   19  DistributionSourcePackage:+filebug
[02:17] <lifeless>      107 /  319  BugTask:+index
[02:17] <lifeless>       58 /   13  Distribution:+search
[02:17] <lifeless>       18 /   15  Archive:+copy-packages
[02:17] <lifeless>       16 /   44  Milestone:+index
[02:17] <lifeless>       16 /    9  DistroSeries:+queue
[02:17] <lifeless>       13 /    5  Person:+bugs
[02:17] <lifeless>       11 /  103  RootObject:+login
[02:17] <lifeless>       11 /   29  Archive:+packages
[02:40] <rockstar> poolie, ah! iorenice is quite cool.
[02:49] <rockstar> For creating new database models, do we still want to use SQLBase?
[02:49] <rockstar> lifeless, ^^ I seem to recall some discussion about performance issues with the sqlobject compatibility layer.
[02:53] <wgrant> All my new stuff has descended from Storm.
[02:53] <rockstar> wgrant, yeah, that's what I was wondering.
[02:54] <lifeless> we need a base class
[02:54] <lifeless> anything using just storm is buggy
[02:54] <wgrant> Even if you're not using cachedproperty?
[02:54] <rockstar> lifeless, ELACKOFCLEARANSWER
[02:54] <lifeless> because it doesn't do IPropertyCacheManager(self).clear() on __storm_invalidate__
[02:56] <lifeless> rockstar: so, I guess I'm saying 'use SQLBase' or 'add a base class we can use with no gunk, and a storm invalidate hook'.
[02:56] <lifeless> it would be nicer still to tell storm to have a global invalidate hook, I guess
[02:58] <rockstar> lifeless, is there an example of a storm invalidate hook somewhere?  I guess I have no idea what that entails.
[03:07] <mars> lifeless, how ofter are you running manual rollouts of revs that have passed QA?
[03:07] <mars> 'ofter' - there's a new word
[03:57] <poolie> "works well with otters"
[04:02] <rockstar> mars, lifeless, the test suite seems to be running faster on ec2.  If you did that, THANK YOU.  If you didn't, say you did.
[04:21] <wgrant> mars: Why are the QA reports private?
[04:21] <wgrant> They aren't for production-stable, so it seems unnecessary.
[04:23] <mars> wgrant, they don't have a good public home yet - we want to set up lp-qa.canonical.com as a public place to publish them
[04:23] <wgrant> Aha.
[04:38]  * stub wonders where last night's ec2 test run ended up
[05:31] <poolie> mwhudson: can you help me understand the failure from mbp-trivial?
[05:31] <poolie> is it spurious?
[05:31] <mwhudson> poolie: hadn't seen it, one sec
[05:34] <poolie> maybe i should keep a count of how many spurious rejections i get? my guess is around 50% of attempted landings
[05:35]  * mwhudson stares at offlineimap
[05:35] <mwhudson> i wonder what it's doing
[05:35] <poolie> i pasted the summary on https://code.edge.launchpad.net/~mbp/launchpad/mbp-trivial/+merge/36515
[05:36] <mwhudson> poolie: what a helpful failure mode!
[05:38] <poolie> yeah, there are some nasty cases in subunit where it falls in to "lost connection" like here
[05:39] <mwhudson> poolie: i have no reason at all to think that this is anything other than spurious
[05:39] <mwhudson> poolie: i can just shove it back in again if you'd like?
[05:39] <poolie> i guess so :(
[05:39] <poolie> thanks
[05:40] <mwhudson> doing so
[05:41] <mwhudson> having stuff like this officially being Someone Else's Problem is one of the nicest things about no longer being an official launchpad developer
[05:41] <mwhudson> :/
[05:42] <poolie> yeah
[05:42] <poolie> i'm especially grateful for you doing it when you don't really have to
[05:44] <poolie> there's no more information in the subunit stream afaics
[05:53] <poolie> lifeless: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/646563 from your comments about testbrowser yesterday
[05:53] <_mup_> Bug #646563: want a way to make a TestBrowser logged in as a particular user <testing> <Launchpad Foundations:New> <https://launchpad.net/bugs/646563>
[06:33] <wgrant> mwhudson: Ahem.
[06:33] <wgrant> Something is wrong with Launchpad, then? :P
[06:34] <mwhudson> wgrant: probably
[06:34] <mwhudson> wgrant: but launchpad at least has the moral position of being large
[06:34] <wgrant> But yes, I don't get that Django thing.
[06:34] <wgrant> It's stupid.
[06:35] <mwhudson> are you criticizing the runserver thing or the whole project? :)
[06:36] <wgrant> The fact that it doesn't serve static media.
[06:36] <wgrant> And its URL system is painfully awful.
[06:36] <wgrant> But apart from that it's not bad.
[06:38] <mwhudson> i think a global settings module is an idea that deserved to be strangled at birth
[06:39] <wgrant> Yes.
[06:39] <wgrant> And its mandatory app structure is inconvenient.
[06:39] <wgrant> I'm struggling with that at the moment.
[07:28] <poolie> if i want to make the feature-rules page visible to only developers, what would be a tasteful way to do that?
[07:29] <poolie> add permission launchpad.Developer and then register an adaptor for it?
[07:32] <wgrant> Hmm.
[07:32] <wgrant> Difficult.
[07:33] <wgrant> Do you have a FeatureFlagSet sort of thing?
[07:33] <poolie> and, to be tasteful, does ~launchpad need to become a celebrity?
[07:33] <poolie> what sort of thing do you mean?
[07:33] <wgrant> ~launchpad should already be a celebrity
[07:33] <wgrant> Well, what does this view live on?
[07:33] <wgrant> ILaunchpadRoot, or something else?
[07:34] <poolie> ILaunchpadRoot
[07:34] <poolie> i'm open to moving it
[07:34] <wgrant> You could for now reuse ILaunchpadRoot's launchpad.Edit
[07:35] <wgrant> It's ~admins + ~registry
[07:35] <poolie> ah yes, so it is
[07:35] <wgrant> It's currently used for managing featured projects.
[07:35] <poolie> ok
[07:35] <wgrant> And is roughtly ~launchpad + ~canonical-bazaar + a few others.
[07:35] <poolie> brilliant
[07:36] <poolie> so it would be launchpad.Edit on the readonly mode
[07:36] <poolie> and launchpad.Admin on the edit mode
[07:36] <poolie> s/mode/form
[07:36] <wgrant> It's a bit of an abuse.
[07:36] <wgrant> Probably.
[08:04] <poolie> wgrant: works for me, thanks
[08:11] <maxb> wgrant: On the offchance you're still around, do you know who needs to be poked about builds that bounce between buildds whilst only pretending to start?
[08:12] <wgrant> maxb: It needs a LOSA to fix, but the first step is to get someone with log access...
[08:12] <wgrant> noodles775: Can you see what's going on?
[08:12] <wgrant> It's been failing like this a bit lately.
[08:13] <noodles775> wgrant, maxb: sure, I'll check the logs - maxb do you have a specific build I can look for?
[08:13] <maxb> noodles775: bzr/proposed PPA, bzr 2.2.1-0~bazaar1~{karmic,jaunty,maverick}1
[08:13] <noodles775> wgrant: do you know the background to the issue (what has been the cause for other builds doing this lately?) - I've been a bit out of the loop.
[08:14] <wgrant> noodles775: I don't know, sorry.
[08:14] <wgrant> adare and ross are known to be problematic, but that doesn't explain PPA builds.
[08:14] <noodles775> Thanks.
[08:15] <noodles775> losa: Hi! is devpad down? I can't ssh to access logs.
[08:16] <spm> yup. probably because yout logged into it noodles775,  you should know by know it's senistive!!!!!
[08:16] <StevenK>   File "/home/steven/launchpad/lp-branches/ids-limit-packagesets/lib/lp/testing/__init__.py", line 78, in <module>
[08:16] <wgrant> devpad seems to have been rather unwell lately.
[08:16] <StevenK>     import fixtures
[08:16] <wgrant> StevenK: make
[08:16] <StevenK> Why does this keep turning up?
[08:16] <wgrant> A new egg was added a few days ago.
[08:16] <noodles775> spm: ;)
[08:16]  * StevenK blames lifeless
[08:16] <wgrant> That's right.
[08:16] <spm> wgrant: indeed it is. I think everything in the h/w has been replaced and it still smashes.
[08:17] <wgrant> spm: Is crowberry at least happy again now?
[08:17] <spm> not sure. I know stuff was done overnight to make things happier.
[08:23] <noodles775> wgrant, maxb: the most recent build of that package that I can see was dispatched to americium without an issue, but then the next entry for that buildd is: 2010-09-24 07:00:49+0000 [-] <americium:http://americium.ppa:8221/> communication failed (User timeout caused connection failure.)
[08:24] <wgrant> Yay.
[08:26] <maxb> "User timeout" ?
[08:26] <noodles775> losa: it looks like the last build that finished on americium was 3 hours ago: https://edge.launchpad.net/builders/americium/+history
[08:27] <noodles775> Do you have instructions for resetting the buildd, or is it something only lamont does?
[08:27] <spm> depends on how wedged they are
[08:27] <noodles775> It's still trying to build new items.
[08:27] <spm> noodles775: but supposedly it started on a new bzr build 8 mins ago?
[08:28] <spm> or is that the problem? starts but barfs?
[08:28] <maxb> ALSO, the PPA publisher hasn't published something that was accepted 88 minutes ago
[08:28] <noodles775> Yeah, it seems to be.
[08:28] <spm> ahh that sounds like the fun we noticed yesterday
[08:29] <spm> noodles775: can you ensure bigjools knows about the repeat of the fun with find/xargs?
[08:29] <jtv> jelmer: did you Q/A your branch for bug 128259?  The bug is still marked qa-needstesting.
[08:29] <_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
[08:29] <noodles775> jtv: jelmer is not available this week.
[08:29] <noodles775> spm: sure, is there a bug we can collect info on?
[08:29]  * noodles775 looks
[08:30] <jtv> noodles775: argh… afaict that branch is probably keeping >200 revisions from being deployed, including a pressing one I'm trying to get in.
[08:30] <spm> noodles775: unsure. he knows what it is tho. i think he emailed the dev list as well
[08:30] <noodles775> spm: great.
[08:31] <spm> basically publishing/cron.daily-ppa is locking and blocking the publishing for 2+ hours
[08:31] <spm> we don't actually know HOW long for, as we kill it before it finishes.
[08:31] <jtv> noodles775: of course there's more branches waiting for q/a, but I think if we could get this one out of the way it'd make a big difference.
[08:31] <spm> maxb: that should happen "RSN" for values of 'soon'
[08:32] <noodles775> jtv: k - let bigjools know, he'll organise QA for it I'm sure (I can't do it right now).
[08:33] <jtv> noodles775: will do, thanks
[08:33] <wgrant> jtv: Last I heard the plan was to QA that, get it individually CP'd on Monday (so we can roll back easily if necessary), then resume normal mass-CPing once we're confident it works.
[08:33] <wgrant> Since it's a big, risky change.
[08:34] <maxb> spm: thanks
[08:34] <maxb> titanium hasn't built anything for four days
[08:34] <jtv> wgrant: I see…  maybe lifeless will make an exception and still let me cherrypick my fix then.
[08:34] <jtv> (There's a few other branches less far behind that are also blocking mine.  I'm Q/A'ing one of them now.)
[08:35] <maxb> charichuelo nothing for 22 hours
[08:36] <maxb> an awful lot of other buildds claim to not have built anything in 3 hours
[08:37] <noodles775> maxb: yeah, I'm just creating a bug listing all the builders showing that same error... I'll ping you when it's done in case you've more to add.
[08:40] <adeuring> good morning
[08:48] <noodles775> wgrant, maxb, spm: bug 646635 - but checking the histories now looks like communication has been restored between the buildds and the buildmaster?
[08:48] <_mup_> Bug #646635: communication failed - user timeout caused connection failure <Launchpad Auto Build System:New> <https://launchpad.net/bugs/646635>
[08:50]  * wgrant blames Nafallo sleepwalking through the DC and tripping over cables.
[08:51] <noodles775> heh
[08:52] <wgrant> It does look fairly happy now.
[08:52] <wgrant> Hopefully on Monday the latency will disappear, and problems will be a lot more obvious.
[08:59] <mrevell> Good morning
[08:59] <jtv> hi mrevell!
[09:17] <lifeless> wgrant: my bugtask:+index is on on prod, if you're interested.
[09:18] <lifeless> 370 queries for bug/1 still
[09:18] <lifeless> jtv: normal process for cp's applies if the cp isn't listed in https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
[09:18] <lifeless> bbiab
[09:19] <wgrant> ,lifeless It was 600, so that's not too bad.
[09:19] <jml> Greetings Earthlings
[09:19]  * noodles775 wonders what the air is like today in "the hut"
[09:21] <wgrant> Heh.
[09:21] <jml> relatively clear.
[09:22] <jml> updateBuild gets called 12 times over the course of 600 lines of doctest.
[09:23] <poolie> hello jml
[09:23]  * jtv wonders if he falls under "earthlings"
[09:23] <jtv> hi jml
[09:24] <wgrant> jml: Please destroy buildd-slavescanner.txt :)
[09:24] <jtv> lifeless: the one I want to deploy (codehosting only) is 11599.
[09:25] <jml> wgrant, that's basically happening slowly.
[09:25] <wgrant> It's soooo big :(
[09:25] <jml> the problem for me is that I'm not sure whether it's testing the builder itself or binary package build behaviour
[09:25] <jml> probably both. :(
[09:25] <wgrant> Well, they were one and the same.
[09:25] <wgrant> So it's both.
[09:27] <noodles775> I'd assume both - when we factored out the separate behaivours I didn't take the time to do more than ensure the current doctests still passed.
[09:28] <jml> yeah. that sounds right.
[09:28] <wgrant> We destroyed bits of it.
[09:28] <wgrant> But there was so much of it there.
[09:32] <jml> yeah.
[09:32] <jml> in our work here we're getting a little bit closer to separating out the tests into the two layers
[09:32] <maxb> noodles775: shipova just ejected my build, it's now starting again on thorium
[09:32] <jml> there's probably still more that could be done to make the separation of concerns clearer for both for tests and for the interfaces themselves
[09:33] <wgrant> jml: Even just splitting it into unit tests would be a huge step forward.
[09:33] <noodles775> maxb: I'll check the log and confirm whether it's the same and updated the bug. Thanks.
[09:33] <wgrant> So you don't move one test out, and find that something breaks 1000 LINES later.
[09:34] <jml> well also, perhaps it will make the intents of the tests clearer
[09:34] <maxb> noodles775: for the record, that build on shipova had most definitely started. It had been running for an hour, and was displaying build log output
[09:34] <jml> that's the biggest problem here
[09:35] <bigjools> we've already murdered a couple of doctests
[09:35] <wgrant> jml: Right, but making the intet of tests clearer is easier if you can actually change them.
[09:35] <bigjools> it felt good
[09:35] <jml> :D
[09:35] <wgrant> Which is much easier when the doctest isn't 3000 lines.
[09:35] <wgrant> Or was that archive.txt? I forget
[09:37] <bigjools> there are problems in the air today
[09:39] <jml> buildd-slavescanner is now ~800 lines
[09:41] <noodles775> maxb: so you build on shipova looks like something went wrong with the builder itself (or it was manually set to not-ok) - 2010-09-24 08:30:53+0000 [-] shipova was made unavailable, resetting attached job
[09:41]  * noodles775 checks for thorium
[09:44] <bigjools> a load of builders went to Enablement not that long ago
[09:45] <noodles775> bigjools, maxb: that would certainly fit with the fact that shipova is no longer listed.
[09:45] <bigjools> they have the ability to pull builders out of the pool at any time
[09:45] <bigjools> the build has to be re-dispatched elsewhere
[09:47] <jtv> Why does this show devel 11566 as the oldest undeployable revision?  AFAICT r11399 hasn't gone through Q/A yet (though at least one branch for the same bug has)
[09:48] <jtv> Damn, lost the bug now.  Maybe I got it all wrong.
[09:48] <lifeless> jtv: so, 11566 is jelmers half-landed branch
[09:49] <lifeless> jtv: julian is cping it monday
[09:49] <lifeless> jtv: your thing you can cp with the normal process; what I'm doing is doing stuff thta passes under the *new process* which is less exception orientated: I'm finding the glitches so we don't have a panic when we start doing more of it.
[09:51] <jtv> lifeless: I guess this is also going to reduce a lot of the risk of conflicts and false conflicts with cp candidates…  I actually based my branch on devel instead of productiond-devel.
[09:51] <lifeless> jtv: it will help, as long as we don't let it fall behind :)
[09:51] <jtv> quite :)
[10:21] <stub> jml: Seen anything like this? http://paste.ubuntu.com/499557/
[10:22] <jml> stub, what in particular?
[10:22] <stub> It exploded and it is very unclear why
[10:23] <jml> stub, oh, I see it's a make run
[10:23] <jml> stub,
[10:23] <stub> its ec2 land output
[10:23] <jml> stub, I've seen errors like "Usage: test [options]" before. That means zope.testrunner has become confused and isn't spawning child processes properly.
[10:24] <stub> I've tried to submit the branch a few times - same failure each time.
[10:24] <jml> hmm.
[10:24] <jml> stub, what happens when you try locally?
[10:25] <stub> I just did test_layers locally - fine.
[10:26] <stub> I'll try ./test_on_merge.py -vv "--subunit -vvv"
[10:26] <jml> stub, may I see the full subunit output?
[10:27] <jml> stub, I'd be surprised if it's an issue with ec2 test per se.
[10:27] <jtv> Is there any way to figure out if the branch scanner on staging is invoking my ITipChanged handler?
[10:28] <stub> http://paste.ubuntu.com/499560/
[10:30] <jml> looks like it fails fast, at least.
[10:44] <jml> stub, when I try to test your branch locally, I get the same crash with or without subunit
[10:45] <stub> Sorry, distracted. Yes. Fails here too with test_on_merge
[10:48] <jml> stub, I tried "./bin/test -vvv" and "./bin/test -vvv --subunit" fwiw.
[11:59] <deryck> Morning, all.
[12:08] <jtv> good night & good weekend, everyone
[13:14] <gmb> So... now that I've put some code in lazr-js - woot, etc. - how on earth do I get my local copy in my LP branches to use that code?
[13:15] <jml> gmb: versions.cfg; ./bin/buildout; see doc/buildout.txt
[13:17] <gmb> jml, Ta.
[13:17] <deryck> gmb, oh but wait ;)
[13:18] <gmb> Oh bother.
[13:18] <deryck> gmb, you'll have to coordinate with rockstar.  He's updated yui in the latest release and there are some blockers to deploying a new lazr-js.
[13:18] <gmb> *facepalm*
[13:18] <deryck> yup
[13:18] <deryck> I've got a fix about to land in lazr-js, too.
[13:18] <gmb> deryck, Okay. I'll hang fire.
[13:19] <deryck> gmb, so I would suggest work on the lp stuff you need to support the widget, and I'll coordinate with rockstar on getting this landed ASAP.
[13:19] <gmb> deryck, Right. Will do.
[13:19] <deryck> gmb, great, thanks.
[13:19] <gmb> deryck, Shall I mark the integration card for the Wizard blocked?
[13:19] <deryck> gmb, yes, indeed.
[13:20] <gmb> RIghto
[13:20] <deryck> gmb, and once you get stuff in lp you want to play with in the widget, you can symlink to your lazr-js build from lp tree, I think.
[13:20] <deryck> just to keep working
[13:20] <gmb> Cool. Will do.
[13:48] <deryck> gmb, regarding bug 575911 and a bugwatch referenced in a bug message with no imported comments.... is this something we're doing when setting up bug watches from links in comments?
[13:49] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/575911>
[13:53] <gmb> deryck, Aaaaah, this is the other half of my problem with the deletion of bug watches. Thanks; I was just trying to debug that.
[13:53] <gmb> deryck, Yes, it's caused by us being too strict about what counts as deletable.
[13:54] <deryck> cool, glad my question helped your thinking then.
[13:54] <gmb> Don't know why it doesn't OOPS, but that blows my theory about mangling the response before the OOPS machinery gets to it away.
[13:54] <gmb> deryck, Amusingly, I triaged it. I appear to have no memory of this.
[13:55] <deryck> heh
[13:55] <deryck> Too many bugs.
[13:55] <deryck> I appreciate you helping triage malone's bugs, though, gmb.
[13:56] <gmb> deryck, Natch. I think it's an easy bug to fix for a Friday afternoon. I'll look into it and if it's as simple as I think, I'll fix it today.
[13:57] <deryck> good deal
[13:57]  * deryck steps away for a few minutes to dress the waking baby and hand her off to grandparents
[13:57] <gmb> deryck, Ah!
[13:58] <gmb> Oh, no.
[13:58] <gmb> Wait.
[13:58] <gmb> Damn.
[13:58] <gmb> Clever thought was not clever.
[13:58] <gmb> Never mind.
[14:06] <gmb> deryck, So, I think the thing that causes the problem is an easy fix, but we'll have to do some data cleanup to make the currently non-deletable watches deletable.
[14:06] <gmb> I'll update the bug once I'm sure, but I'll fix the initial problem now since it's quick and easy.
[14:26] <deryck> gmb, sounds good.
[14:33] <cr3> gary_poster: hey dude, I hope your stack is better now :)
[14:48] <gmb> adeuring, Were you able to solve your OOPS-not-being-raised error?
[14:49] <adeuring> gmb: not really. But spooted another missing OOPS report
[14:49] <adeuring> s/spooted/spotted/
[14:50] <gmb> adeuring, Are you getting the Please Try Again page?
[14:50] <gmb> (instead of an oops)
[14:50] <salgado> sinzui, I'm getting http://paste.ubuntu.com/499723/ when make running.  any idea what's wrong?
[14:50] <gmb> I'm asking because that's what happens when you try to delete a bug watch https://bugs.edge.launchpad.net/malone/+bug/575911, and the error being raised there is an IntegrityError. Don't know if that helps you any.
[14:50] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
[14:51] <adeuring> gmb: the problem appeared in connection with the speical Librarian error message ("feng shui in the server room")
[14:51] <adeuring> that page does not mention an OOPS ID
[14:51] <sinzui> salgado, I have seen that on a dirty shutdown. I kill all procs, then rm /var/tmp/*.pid
[14:52] <adeuring> but an OOPS _should_ have been raised. problem was that I found IIRC one OOPS report where I would have exected 10 or 20
[14:52] <sinzui> salgado, the mailman pid could be from weeks ago if you have not use run all in a while
[14:53] <salgado> sinzui, right, that made it possible to run, but I was wondering about the "ImportError: No module named mailman.monkeypatches.defaults" error
[14:53] <salgado> that one persists
[14:53] <sinzui> salgado, sorry, I see another error. is your trunk up to date. I moved moneypatches to lp/services/mailman a few days ago
[14:54] <salgado> yeah, I just ran rf-get
[14:54] <salgado> sinzui, looks like lib/mailman/Mailman/mm_cfg.py wasn't updated?
[14:55] <sinzui> salgado, I think that is generated
[14:55] <gmb> adeuring, That is indeed "special." Where "Special" translates as "Nutzlos."
[14:56] <adeuring> gmb: exactly ;)
[14:56] <sinzui> salgado, regardless, I have a new pristine branch and will try now
[14:56] <salgado> oh, indeed it is auto-generated.  I'll try removing it
[14:57] <sinzui> salgado, I have from lp.services.mailman.monkeypatches.defaults import *
[14:59] <salgado> can't seem to get it to be generated again, now that I've removed it
[15:00]  * sinzui thinks
[15:01] <sinzui> salgado, make compile should call buildmailman,py
[15:01] <sinzui> salgado, make clean will purge the whole mailman dir
[15:01] <salgado> yeah, but that's called by make run
[15:02] <salgado> I was trying to avoid a make clean because it takes too long to rebuild after that.  I'll live without that file for now and once it causes problems I'll rebuild
[15:02] <salgado> thanks sinzui
[15:02] <sinzui> np
[15:04] <salgado> jcsackett, do you have some sample URLs for the pages you've changed in unknown-translations-service-643545-0?
[15:05] <jcsackett> salgado: yes, i've posted links in the MP
[15:05] <jcsackett> salgado: my last comment on it is a list of links and what's on them.
[15:05] <salgado> jcsackett, oh, as comments, I see them now.  was looking at the description
[15:06] <jcsackett> salgado: ah, yeah. sorry about that.
[15:06] <salgado> no worries.  thanks for adding the demo data to exercise the changes. :)
[15:08] <jcsackett> salgado: thanks for the suggestion of doing that in your last review. :-)
[15:11] <gmb> Ursinha, matsubara: Do either of you have any idea why the OOPS machinery wouldn't catch an IntegrityError raised by BugWatch.destroySelf()?
[15:12] <matsubara> gmb, don't know. how do you know it's raising an IntegrityError and no oopses is being generated?
[15:12] <gmb> matsubara, I'm reproducing it locally and instead of an OOPS page I get a ProxyError.
[15:13] <gmb> matsubara, I can talk you through reproducing it if that helkps.
[15:14] <gmb> (Also, nothing is showing up in my /var/lperr directory)
[15:14] <matsubara> gmb, I can try to reproduce locally
[15:14] <gmb> matsubara, Okay. I'll paste some instructions for you, hang on...
[15:14] <matsubara> thanks
[15:15] <gmb> matsubara, This is https://bugs.edge.launchpad.net/malone/+bug/575911, FTR.
[15:15] <_mup_> Bug #575911: Trying to delete a bug watch results in a non-OOPSing IntegrityError <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/575911>
[15:17] <gmb> matsubara, http://pastebin.ubuntu.com/499735/
[15:22] <sinzui> mars, retarget questions, not assign them. https://answers.edge.launchpad.net/launchpad/+question/126444 need to be in launchpad-registry so that all answer contacts are notified
[15:23] <mars> sinzui, garh, sorry
[15:23] <mars> done
[15:29] <matsubara> gmb, looks like it's failing before the oops code have a chance to log it. line 568 in webapp/publication.py. not sure why though
[15:30] <matsubara> gary_poster, can you help gmb diagnose why an IntegrityError is not being logged correctly as an oops report?
[15:32] <gary_poster> on call will ping
[15:33] <gmb> matsubara, gary_poster: Thanks.
[15:41] <rockstar> deryck, have you landed your patch I reviewed yesterday yet?
[15:42] <deryck> rockstar, yup.  Just did an hour or so ago.
[15:42] <rockstar> deryck, good.  I'm wrangling lazr-js and our launchpad build system as we speak.
[15:43] <deryck> awesome!
[15:51] <bdmurray> as zope's test browser doesn't correctly set the referrer how can I test "ReturnToReferrerMixin" in a story?
[15:53] <gary_poster> bdmurray: have you already surveyed similar tests?  I don't remember if the answer is there, but I remember confronting it. :-/
[15:53] <gary_poster> gmb, ok looking now...
[15:55] <bdmurray> gary_poster: yes, I didn't find anything obvious
[15:55] <gary_poster> gmb, ok so the only way to get a traceback is to dupe, eh?  Trying.
[15:56] <gary_poster> bdmurray: did you find the tests dealing with REFERER, and they used another mechanism, or you didn't find pertinent tests?
[15:59] <bdmurray> gary_poster: All the clicking of Cancel tests I could find didn't seem to use ReturnToReferrer in the view
[16:00] <gary_poster> bdmurray: lemme do a grep; I probably can't help easily, but I'll give it a quick whirl...
[16:04] <gary_poster> bdmurray: see if lib/canonical/launchpad/pagetests/standalone/xx-offsite-form-post.txt helps
[16:10] <bdmurray> gary_poster: looks like it will thanks
[16:10] <gary_poster> cool, np
[16:13] <bigjools> gary_poster: do you know of a context manager (or similar) that does the same as the @write_transaction decorator?
[16:14] <gmb> gary_poster, Yes (sorry, was OTP)
[16:14] <gmb> gary_poster, I don't know why that IntegrityError isn't becoming an OOPS.
[16:15] <gmb> I know why the error is happening, and I'm fixing that, but I think it's worth making sure that this not-oopsing issue doesn't happen elsewhere, too.
[16:16] <gary_poster> bigjools: no, I don't think we have one.  If you look at the write_transaction impl in lib/canonical/librarian/db.py, you can see how to manage it manually.  a context manager might be nice.
[16:16] <gary_poster> gmb: understood and agreed
[16:17] <bigjools> gary_poster: yeah I am going to move it out of that location, it causes circular imports :(
[16:17] <gary_poster> ah :-/
[16:17] <bigjools> (I need it in a database class)
[16:17] <gary_poster> gotcha
[16:17] <bigjools> I'll maybe write a context manager sometime
[16:17] <gary_poster> it would be reasonable to put in the transaction library
[16:17] <gary_poster> as would a CM
[16:17] <bigjools> maybe in the next century when I get some free time
[16:17] <gary_poster> :-)
[16:18] <bigjools> gary_poster: I am looking at putting it in lp/services/database/__init__.py
[16:19] <gary_poster> sounds very reasonable bigjools
[16:19] <bigjools> ok thanks gary_poster
[16:19] <gary_poster> np
[16:20] <gary_poster> gmb, I don't see how to do step 2 in http://pastebin.ubuntu.com/499735/
[16:22] <gmb> gary_poster, Expand the top bug task using the little expander thing on the left hand side
[16:23] <gmb> (Old school, this)
[16:23] <gary_poster> ah@
[16:23] <gary_poster> !
[16:23] <gary_poster> got it thanks
[16:23] <gmb> gary_poster, And yes, "None, the report is updated manually" is listed twice. It's age-old, that bug.
[16:23] <gary_poster> ah ok, so it doesn't matter which one
[16:24] <gmb> gary_poster, Nope. I just use the first one.
[16:24] <gary_poster> cool
[16:24] <gary_poster> ok yay, duped
[16:30] <gary_poster> gmb, the reason is that the error happens within the transaction commit, which is outside of the application code.  This is a bug, though not one that will be solved soon, because it will involve replacing or changing the core Zope publication library (I'd like to replace, but as you might expect, that's not a small project).
[16:30] <gary_poster> I don't think we have a bug for this particular instance of OOPS tools not catching things.  Would you be up for creating one, or shall I?
[16:31] <gmb> gary_poster, Can you do it please? I'm desperately trying to to switch context in the middle of a ZCML horrorshow.
[16:31] <gmb> trying *not
[16:31] <gary_poster> gmb, will do.
[16:32] <gmb> gary_poster, Thanks.
[16:32] <gary_poster> np
[16:35] <EdwinGrubbs> abentley: ping
[16:35] <abentley> EdwinGrubbs, pong
[16:37] <EdwinGrubbs> abentley: hi, I've finally wrapped my head around the TwistedJobRunner, so I wanted to discuss with you the two possible ways I see to have it run multiple different job types in parallel.
[16:37] <cr3> in launchpad tests, should Fake classes for testing purposes be located in the tests themselves, like in test_foo.py, or under a testing directory? does it depend on whether the Fake class can be reused across more than one test module?
[16:37] <abentley> EdwinGrubbs, okay.  Did you want to do this on IRC or voice-to-voice?
[16:37] <jml> cr3, pretty much.
[16:38] <jml> cr3, also you should look for test doubles that already exist before writing your own.
[16:39] <EdwinGrubbs> abentley: mumble might be easier.
[16:39] <cr3> what about Fake implementations for interfaces, so that getUtility(IFoo) returns the Fake implementation in a testing context, I haven't noticed Fake utilities registered in ftesting.zcml
[16:40] <EdwinGrubbs> abentley: I added the ampoule channel to mumble. Can you join that?
[16:57] <salgado> sinzui, deryck[lunch], have you seen that the heading text is broken on https://bugs.edge.launchpad.net/launchpad?
[16:58] <sinzui> salgado, I do not see that
[16:58] <deryck[lunch]> me either
[16:58] <salgado> the "There are currently no open bugs filed against Launchpad itself."?
[16:58] <salgado> might be a chromium isssue
[16:58] <sinzui> that is true
[16:59] <sinzui> salgado, the bugs were retargeted to the app
[16:59]  * deryck fires up chromium
[16:59] <deryck> ah ha
[16:59] <salgado> it works on epiphany
[16:59]  * sinzui is using chromium
[16:59] <deryck> thought this was fixed already.  Must have regressed.
[17:00] <salgado> sinzui, I mean that the sentence is broken here; the first two works show up beside the search form
[17:00] <salgado> and the rest below it
[17:00] <salgado> s/works/words
[17:01] <salgado> deryck, you see that too?
[17:03] <sinzui> epiphany and chromuim look identical to me. I see the search box, and below it I see a bold statement and below that I see a link a report a bug link
[17:04] <deryck> salgado, yes, I see it.  Sorry on call now.
[17:09] <salgado> sinzui, are you on chromium 7.0.531.0 (nightly build)?
[17:18] <deryck> salgado, I'll reopen the bug about float issues in chromium.
[17:23] <salgado> deryck, cool, thanks
[17:23] <deryck> np
[19:19] <abentley> gary-lunch, I have some questions about how view configuration works when there are multiple potential matches.
[19:35] <mars> sinzui, jinx!
[19:36] <sinzui> ha
[19:38] <gary_poster> abentley: having another conversation/pursuing bug, but can follow along here too probably
[19:41] <abentley> gary_poster, We have shared code for "comments", where comments can actually be bug comments, code review comments, revisions, package diffs, and I'm adding incremental diffs to the list.
[19:42] <abentley> gary_poster, There's a "default" comment header that I don't want incremental diffs to use.  But it's being used anyway.
[19:43] <gary_poster> how is it registered, and how is the one you want registered?  Alternatively...
[19:44] <abentley> gary_poster, here are the configurations: http://pastebin.ubuntu.com/499890/
[19:45] <gary_poster> the order of preference for a multi-adapter like a view is to try to match the first element (context in this case) as much as possible, and then go to the second (request).  For eact item, interfaces directly declared on the instance have precedence, after which interfaces declared on the class, in __iro__ order for each interface and standard Python base class resolution order for the bases
[19:45] <gary_poster> looking
[19:46] <gary_poster> abentley: my guess is that class effectively resolves so that lp.services.comments.interfaces.conversation.IComment comes before lp.code.browser.branchmergeproposal.IIncrementalDiffComment
[19:47] <abentley> gary_poster, I will examine that.  It could be that it's declared to implement ICodeReviewComment directly, I guess.
[19:47] <abentley> s/ICodeReviewComment/ICommeng/
[19:47] <gary_poster> k
[19:50] <abentley> gary_poster, thanks.  That looks like it solved it.
[19:50] <gary_poster> great, abentley
[20:25] <cr3> heh, just came across this comment from 2005: if steveIsFixingThis :)
[20:53] <rockstar> gary_poster, if I make a library available in PyPI, do I need to worry about putting an egg into lp-sourcecode-whatever?
[20:54] <gary_poster> yes, but very easy: comment out "install-from-cache = true" from buildout.cfg, specify version in versions.cfg, and run buildout.  Then it will be in lp-sourcecode-whatever
[20:55] <gary_poster> (then uncomment)
[21:04] <rockstar> gary_poster, so then I have to commit the egg in lp-sourcecode-whatever?
[21:04] <gary_poster> rockstar: yes (or if you want to test it on ec2 first there's a flag for that)
[21:05] <rockstar> gary_poster, hm.  I fail to see the benefit in putting it on PyPI then.
[21:05] <gary_poster> sharing?
[21:05] <gary_poster> open source?
[21:05] <gary_poster> collaboration in the Python community? :-D
[21:05] <rockstar> gary_poster, yeah, I'm not sure that these tools would be of use to anyone else.
[21:06] <gary_poster> then there is no benefit.
[21:06] <rockstar> gary_poster, at least in this case, I'm probably going to eggify locally first, and then worry about PyPI later.
[21:06] <gary_poster> cool
[21:06] <rockstar> (I'm sure we can make the tools effective enough to be of value to others)
[21:06] <gary_poster> good.
[21:06] <gary_poster> bye all.  back Wed.
[21:38] <EdwinGrubbs> abentley: did you get a chance to look at my email?
[21:39] <abentley> EdwinGrubbs, I started, but got distracted.  Lemme look again.
[21:39] <mwhudson> poolie: that branch landed the second time :/
[21:42] <abentley> EdwinGrubbs, yeah, that's the basic idea.
[21:42] <EdwinGrubbs> abentley: ok, I'll try to get that into review by Monday.
[21:44] <abentley> EdwinGrubbs, Be careful of lock files.  It would be easy to have each forked process prevent the others from running.
[21:44] <EdwinGrubbs> abentley: good point
[21:45] <abentley> EdwinGrubbs, if you make queued-job-runner a commandline argument, it becomes easy to configure different JobSources for different machines.
[21:47] <abentley> EdwinGrubbs, I might do if getattr(section, 'runner_class', 'JobRunner') == 'JobRunner'.
[21:47] <rockstar> Since when does Launchpad INCORPORATE GAME MECHANICS?
[21:47]  * rockstar goes to a corner to sob.
[21:50] <abentley> EdwinGrubbs, oh, and I think you want to _exit() if pid == 0 after script.lock_and_run
[21:51] <abentley> rockstar, stand-up?
[21:51] <EdwinGrubbs> abentley: yes, there are plenty of bugs in it still.
[21:51] <rockstar> abentley, absolutely.
[21:52] <rockstar> abentley, hm, I seem to have forgotten my skype headset.  Lemme see if it would be cheap to POTS call you.
[21:52] <abentley> rockstar, I can SkypeOUT you.
[21:52] <rockstar> abentley, yeah, but then you have to pay for my absentmindedness.
[21:53] <abentley> rockstar, yeah but so little I don't really care.
[21:53] <rockstar> abentley, if it's alright, then sure.
[22:17] <abentley> rockstar, there's also Truephone, which is a lot like Skype, but supports Android.  We could try that next time you forget your headset.
[22:17] <rockstar> abentley, oh yeah.  That would be good.
[22:18] <rockstar> abentley, I try to come down and cowork on Fridays. Otherwise, I start having long philosophical conversations with my dog.
[22:18] <abentley> rockstar, :-)
[22:56] <poolie> thanks mwh
[22:57] <mwhudson> poolie: actually i didn't land
[22:57] <mwhudson> poolie: because of testfix
[22:58] <poolie> oh ok, but we know it passed
[22:58] <poolie> so lp-land will send mail direct to pqm, assuming that you have already run the tests on ec2 or locally?
[22:59] <mwhudson> poolie: yeah, i think lp-land is the tool for this job


[16:54] <throstur> where can I find what `bzr update` return codes are?
[16:55] <throstur> the reference at http://doc.bazaar.canonical.com/bzr.2.6/en/user-reference/update-help.html doesn't tell me
[16:58] <throstur> trying to scour through the source and I'm not sure where to even start
[16:59] <throstur> ok that's a lie I know where to start but there's a lot of manual tracing :( pls?
[17:01] <throstur> what does it return on a conflict?
[17:04] <verterok> throstur: 0 when all ok, 1 on conflict or error
[17:12] <throstur> thanks verterok
[17:19] <verterok> np


[00:18] <KGB-1> gnome-shell-extension-desktop-icons Gunnar Hjalmarsson 281833 * commented merge request !11 * https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-desktop-icons/-/merge_requests/11#note_281833
[01:06] <callmepk> good morning
[05:24] <KGB-1> vte2.91 pristine-tar ef5e68b Gunnar Hjalmarsson vte2.91_0.66.1.orig.tar.gz.delta vte2.91_0.66.1.orig.tar.gz.id * pristine-tar data for vte2.91_0.66.1.orig.tar.gz * https://salsa.debian.org/gnome-team/vte2.91/-/commit/ef5e68b
[05:24] <KGB-1> vte2.91 upstream/latest 04ce6dc Gunnar Hjalmarsson * pushed 78 commits (first 5 follow) * https://salsa.debian.org/gnome-team/vte2.91/compare/97ae554...04ce6dc
[05:24] <KGB-1> vte2.91 upstream/latest 970ea4e Christian Persch src/vteseq.cc * emulation: Some more docs * https://salsa.debian.org/gnome-team/vte2.91/-/commit/970ea4e
[05:24] <KGB-1> vte2.91 upstream/latest 6460463 Christian Persch src/ cxx-utils.hh vtegtk.cc * widget: Rework exception handling in non-debug builds * https://salsa.debian.org/gnome-team/vte2.91/-/commit/6460463
[05:24] <KGB-1> vte2.91 upstream/latest 1e38c58 Christian Persch meson.build * build: Assert on non-supported option on stable branch * https://salsa.debian.org/gnome-team/vte2.91/-/commit/1e38c58
[05:24] <KGB-1> vte2.91 upstream/latest 0857ff7 Christian Persch (8 files in 4 dirs) * widget: Defer alignment API to next cycle * https://salsa.debian.org/gnome-team/vte2.91/-/commit/0857ff7
[05:24] <KGB-1> vte2.91 upstream/latest ba1e05c Christian Persch (25 files in 3 dirs) * all: Remove SIXEL support from stable branch * https://salsa.debian.org/gnome-team/vte2.91/-/commit/ba1e05c
[05:25] <KGB-1> vte2.91 tags ceddcb3 Gunnar Hjalmarsson upstream/0.66.1 * Upstream version 0.66.1 * https://salsa.debian.org/gnome-team/vte2.91/tags/upstream/0.66.1
[06:29] <oSoMoN> good morning desktoppers
[06:33] <duflu> Hi oSoMoN
[06:34] <oSoMoN> hey duflu
[06:40] <jibel> Good morning
[06:44] <duflu> Morning jibel
[06:46] <oSoMoN> salut jibel
[06:55] <jibel> hi duflu oSoMoN
[07:25] <callmepk> hi oSoMoN duflu jibel
[07:26] <duflu> Hi callmepk
[07:27] <oSoMoN> hey callmepk
[07:33] <jpnurmi> good morning
[07:35] <jibel> Hi callmepk jpnurmi
[07:35] <callmepk> hi jpnurmi
[07:36] <jpnurmi> hi jibel callmepk oSoMoN duflu
[07:36] <duflu> Hi jpnurmi
[08:03] <didrocks> good morning
[08:12] <duflu> Hi didrocks
[08:12] <didrocks> hey duflu
[08:23] <seb128> goood morning desktopers
[08:27] <didrocks> salut seb128
[08:28] <seb128> lut didrocks, en forme ?
[08:29] <jibel> salut didrocks seb128
[08:30] <duflu> Hi seb128
[08:34] <didrocks> seb128: voix un peu rauque, mais c’est ok
[08:34] <didrocks> et toi ?
[08:34] <didrocks> salut jibel
[08:37] <seb128> lut jibel, hey duflu, how are you?
[08:37] <seb128> didrocks, ça va :)
[08:44] <duflu> seb128, it's been quite a day which I can't talk about here. How are you?
[08:52] <oSoMoN> good morning jpnurmi, didrocks, seb128
[08:54] <didrocks> salut oSoMoN
[08:55] <seb128> lut oSoMoN
[08:56] <seb128> duflu, I'm alright, I managed to escape the cold and everyone is in shape again which means hopefully I can have a quiet day and get some work done :)
[08:56] <duflu> \o/
[09:14] <ricotz> good morning everyone :)
[09:16] <didrocks> hey ricotz
[09:20] <seb128> hey ricotz! how are you?
[09:24] <ricotz> hey seb128 didrocks
[09:25] <ricotz> I am fine, thanks :)
[09:29] <oSoMoN> good morning ricotz
[09:35] <ricotz> oSoMoN, hey
[10:56] <PaulePanter> Under *Veröffentlichungshinweise* (release notes) which is shown for the 20.10 upgrade, there are still http:// links listed. (Under feedback and how to help)
[11:04] <PaulePanter> (Feedback and Helping)
[11:10] <KGB-1> gnome-remote-desktop tags 2d57932 Sebastien Bacher upstream/41.1 * Upstream version 41.1 * https://salsa.debian.org/gnome-team/gnome-remote-desktop/tags/upstream/41.1
[11:11] <seb128> PaulePanter, in the distupgrader?
[11:11] <KGB-1> gnome-remote-desktop upstream/latest 71211bc Sebastien Bacher * pushed 28 commits (first 5 follow) * https://salsa.debian.org/gnome-team/gnome-remote-desktop/compare/0943e5d...71211bc
[11:11] <KGB-1> gnome-remote-desktop upstream/latest 88529f0 Pascal Nowack src/ grd-rdp-pipewire-stream.c grd-session-rdp.c grd-session-rdp.h * rdp: Get rid of the grd_session_rdp_resize_framebuffer() API * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/88529f0
[11:11] <KGB-1> gnome-remote-desktop upstream/latest 1aa0507 Pascal Nowack src/ (5 files) * rdp: Allow using custom GMainContext for RDPGFX GSources * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/1aa0507
[11:11] <KGB-1> gnome-remote-desktop upstream/latest acd990a Pascal Nowack src/ grd-rdp-pipewire-stream.c grd-rdp-pipewire-stream.h grd-session-rdp.c * rdp: Run do_render() as GSourceFunc in custom GMainContext * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/acd990a
[11:11] <KGB-1> gnome-remote-desktop upstream/latest 1e8f1a2 Pascal Nowack src/ grd-rdp-nvenc.c grd-rdp-nvenc.h * rdp-nvenc: Add APIs to push and pop current CUDA context * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/1e8f1a2
[11:11] <KGB-1> gnome-remote-desktop upstream/latest c0ae364 Pascal Nowack src/grd-session-rdp.c * session-rdp: Fix small style issue * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/c0ae364
[11:12] <KGB-1> gnome-remote-desktop pristine-tar a7231af Sebastien Bacher gnome-remote-desktop_41.1.orig.tar.xz.delta gnome-remote-desktop_41.1.orig.tar.xz.id * pristine-tar data for gnome-remote-desktop_41.1.orig.tar.xz * https://salsa.debian.org/gnome-team/gnome-remote-desktop/-/commit/a7231af
[11:38] <tjaalton> seb128: hwang will handle alsa :)
[12:02] <seb128> tjaalton, great, thanks :)
[12:17] <PaulePanter> seb128: Yes. Even shown when run from the command line: sudo do-release-upgrade
[12:18] <seb128> PaulePanter, did you report a bug on launchpad?
[12:27] <PaulePanter> seb128: No.
[12:28] <seb128> PaulePanter, could you open one maybe?
[12:28] <PaulePanter> I put it on my to-do list.
[12:28] <PaulePanter> Thank you for giving support in this channel by anwsering quickly.
[13:44] <ricotz> seb128, do you have time to continue the poppler transition? https://people.canonical.com/~ubuntu-archive/transitions/html/auto-poppler.html
[13:55] <seb128> ricotz, I try to squeeze things in between other work but help is welcome if others want to work on it
[14:02] <ricotz> seb128, that sounds good, thank you
[14:14] <seb128> thanks!
[14:16] <seb128> kenvandine, hey, I don't remember if I mentioned that before but the github snaps template seems wrong for launchpad reference, taking https://github.com/ubuntu/evince as an example it has ' a build of the snap that gets published' pointing to https://launchpad.net/~desktop-snappers/evince/+snap/evince-stable
[14:16] <seb128> where the correct url is https://launchpad.net/~desktop-snappers/+snap/evince-stable
[14:16] <seb128> it's true for any of the snaps it seems
[14:16] <seb128> dunno if that's launchpad which changed or if that was always wrong
[14:38] <seb128> oSoMoN, hey, for some reason my firefox (rev701 from stable) is in english now, did you see report about that?
[14:39] <oSoMoN> seb128, no, I didn't, and of course that's unexpected
[14:40] <oSoMoN> seb128, do you have all the language packs listed in about:support, with version 94.0buildid20211012185633 ?
[14:42] <kenvandine> seb128: weird
[14:44] <seb128> oSoMoN, Français Language Pack	locale	92.0buildid20210903235534	false<EMAIL_ADDRESS>[14:44] <seb128> in add-ons
[14:44] <kenvandine> seb128: something else changed... i know the eog link worked before
[14:44] <kenvandine> now it doesn't
[14:44] <seb128> kenvandine, maybe question for #launchpad?
[14:45] <kenvandine> we'll just fix them, simpler url is good :)
[14:45] <seb128> oSoMoN, the add-ons section only lists english CA/english GB and Francais, version 92.0buildid20210903235534
[14:46] <oSoMoN> seb128, there's a version mismatch between the addons and the browser, this looks similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1732676
[14:46] <seb128> oSoMoN, but if that was bug you should see the issue as well?
[14:46] <seb128> oSoMoN, or is that local content I have in my profile?
[14:47] <oSoMoN> seb128, the langpacks are being copied to your profile dir, so your profile became out of sync somehow
[14:47] <oSoMoN> not sure how though
[14:48] <oSoMoN> there's an "extensions" dir under your profile directory, if you delete the langpacks from there and restart firefox the correct versions should be picked up, can you try that after backing up your entire profile (in case we need to debug further)?
[14:50] <seb128> oSoMoN, I restarted firefox without changing anything and now it lists all langpack and it's translated again, weird
[14:51] <seb128> oSoMoN, thanks for the reply though!
[14:53] <seb128> oSoMoN, or it's an user error now, sorry for the noise. I reinstalled the deb to test things and it seems I someone got it opened instead of the snap, probably by clicking on an url in hexchat or something
[14:53] <seb128> my launcher points to the snap
[14:54] <oSoMoN> ah, fun problems to debug, when the deb and the snap get mixed up…
[15:03] <GunnarHj> Good afternoon, seb128!
[15:03] <GunnarHj> I proposed a rather flexible AppArmor rule for the hunspell directory.
[15:03] <GunnarHj> https://bugzilla.mozilla.org/show_bug.cgi?id=1732755#c11
[15:03] <GunnarHj> What's next step? Will you involve security?
[15:17] <PaulePanter> Hi. Upgarding an Dell XPS 13 9360 from 21.04 to 21.10, the graphical login manager has the new background image, but in the bottom left corner it still says 21.04 instead 21.10. (I think it’s lightdm.) `/etc/os-release` contains 21.10.
[15:18] <seb128> GunnarHj, hey, I think someone needs to ask them again about that, either by pinging on forum.snapcraft.io or by doing a merge request with the proposed change
[15:18] <PaulePanter> VA-API with Firefox 94.0 also does not seem to work: [Child 15618: MediaSupervisor #1]: D/PlatformDecoderModule VA-API is disabled by pref.
[15:18] <PaulePanter> I thought it’s going to be enabled by default with that version.
[15:20] <oSoMoN> GunnarHj, thanks for that! I think the fastest way to get security involved is to propose a pull request against snapd to add that rule
[15:23] <oSoMoN> PaulePanter, the fix for this is actually in the gnome platform snap (see https://gitlab.gnome.org/Community/Ubuntu/gnome-sdk/-/merge_requests/31), it was merged but the snap needs to be rebuilt, tested and promoted to the stable channel for the fix to take effect
[15:25] <oSoMoN> PaulePanter, I just checked and it is in the candidate channel, so if you could switch to that, test and report here whether it works, that'd be very welcome: `snap refresh gnome-3-38-2004 --candidate`, then close and launch firefox again
[15:45] <GunnarHj> oSoMoN: Would a snap PR be about a change to /etc/apparmor.d/usr.lib.snapd.snap-confine.real ?
[15:51] <oSoMoN> GunnarHj, no, it would need to be a change to an existing interface, probably the 'desktop' one, in https://github.com/snapcore/snapd/tree/master/interfaces/builtin
[15:53] <GunnarHj> oSoMoN: Ah, thanks. Will submit such a PR then.
[16:03] <PaulePanter> oSoMoN: I ran the snap refresh command, logged out and back in, but Firefox still says, VA-API is disabled by platform.
[16:03] <PaulePanter> Maybe they did not enable it for all. Let me check the Mesa version.
[16:05] <PaulePanter> Robert’s blog post: https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
[16:05] <PaulePanter> > As of Firefox 94, users using Mesa driver >= 21 will get it by default.
[16:09] <oSoMoN> PaulePanter, what's the value of the "media.ffmpeg.vaapi.enabled" pref in about:config ?
[16:13] <PaulePanter> oSoMoN: It’s false.
[16:13] <PaulePanter> Mesa 21.2.2 is installed. No idea, why Firefox does not enable it.
[16:16] <PaulePanter> Does Firefox Snap (94.0.1-1) ship it’s own Mesa libs?
[16:16] <kenvandine> PaulePanter: gnome-3-38-2004 does
[16:17] <oSoMoN> yes, and that's the version of mesa found in Ubuntu 20.04, so VA-API won't be enabled by default
[16:18] <oSoMoN> PaulePanter, can you change the value of the pref, restart firefox and let us know whether hw-accelerated video decoding works for you?
[16:23] <PaulePanter> 21.2.2 ≥ 21, so where is the problem?
[16:24] <PaulePanter> oSoMoN: It probably is going to work, but that’s not about the problem I am trying to solve. I want users to have it enabled by default.
[16:25] <PaulePanter> kenvandine, oSoMoN: Ah, now I parsed it correctly. So how do I check the Mesa version in a snap?
[16:26] <oSoMoN> PaulePanter, you can inspect /snap/gnome-3-38-2004/current/snap/manifest.yaml
[16:26] <oSoMoN> it has 21.0.3, so not recent enough
[16:30] <PaulePanter> oSoMoN: 21.0.3 is also greater than 21?
[16:31] <oSoMoN> d'oh, I'm tired, I hadn't parsed correctly the quote myself
[16:32] <oSoMoN> so, this requires further investigation to understand why it's not enabled by default
[16:33] <PaulePanter> As a side note, setting media.ffmpeg.vaapi.enabled to true, VA-API FFmpeg decoder is initalized and working.
[16:33] <oSoMoN> PaulePanter, I can't look into it right now, would you mind filing a bug at https://bugzilla.mozilla.org/enter_bug.cgi#h=dupes|Firefox to describe and track the problem?
[16:33] <PaulePanter> oSoMoN: Will do.
[16:33] <kenvandine> how does firefox check mesa version?
[16:34] <kenvandine> perhaps the check fails in the snap for another reason so it defaults to false
[16:34] <oSoMoN> (make sure to include "snap" in the bug title, and make it block https://bugzilla.mozilla.org/show_bug.cgi?id=1665641)
[16:34] <oSoMoN> thx!
[16:44] <PaulePanter> https://bugzilla.mozilla.org/show_bug.cgi?id=1740060
[16:45] <PaulePanter> (The blocking number could be set after *Edit Bug* in the section *References*.


[14:17] <persia> Is there a Java meeting today?
[14:17]  * persia hasn't been involved much in the Java team lately, but had news
[14:21] <ScottK> persia: I think anytime you and blackxored are in the same channel, it's a Java Team meeting.
[14:22] <persia> I'm not convinced of that.  I haven't done any Java stuff since May.
[14:22] <persia> slytherin or ttx would likely be as strong candidates.
[14:23] <ScottK> Perhaps, but you seemed the most interested in a team.
[14:24] <persia> I just ended up accepting the action of creating the team at UDS Intrepid.


[01:52]  * daftykins yawns
[01:52] <daftykins> late night pizza time
[01:54] <Bashing-om> cookies for me for the win .
[01:54] <daftykins> :O i am jealous
[01:54] <OerHeks> cookies +1
[01:57] <Bashing-om> I am not supposed to, but a few cookies, what can it possibly hurt ? And they are so satisfing . Maybe just 2 more ?
[02:00] <OerHeks> Don't let them go old.
[02:03] <Bashing-om> OerHeks: No Way ! .. I do take care of what is really important. Zip lock bags ! LOL - No protection, be a shame for good cookies to grow old, there is a fix for that !
[03:41] <lotuspsychje> good morning to all
[03:46] <lotuspsychje> http://www.omgubuntu.co.uk/2015/09/ubuntu-15-10-beta-download
[03:49] <lotuspsychje> !info linux-firmware
[03:49] <lotuspsychje> !info linux-firmware wily
[07:36] <lordievader> Good morning.
[10:18] <MonkeyDust> yes
[12:08] <MonkeyDust> what is ldconfig used for? the man page isnt clear
[12:09] <TJ-> it maintains the system library cache so when executables declare dependencies on shared objects it they can be linked quickly
[12:10] <MonkeyDust> in what way is that useful?
[12:10] <TJ-> "ldd /path/to/binary/executable" will show the shared libraries required
[12:11] <TJ-> It means that ld.so can determine the exact shared object to link in at run-time without scanning the file-system for each executed process
[12:12] <EriC^^> so it's like locate but for libraries?
[12:15] <TJ-> A bit more fundamental. Without the cache ld.so cannot find the libraries, and any dynamically linked executable (99.9999% of them) will fail to start
[23:46] <lotuspsychje> good evening fellas
[23:48] <Bashing-om> shift change already ?
[23:49] <lotuspsychje> yeah its early morning here Bashing-om :p
[23:49] <lotuspsychje> cant sleep
[23:49] <lotuspsychje> 1h49
[23:50] <Bashing-om> Well lotuspsychje ; Here we are once more, keeping company .
[23:50] <lotuspsychje> Bashing-om: hows the channel been behaving so far
[23:51] <Bashing-om> For a weekend .. been real nice . No dramma . Kinda slowed down now .
[23:52] <lotuspsychje> http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Phone-Estimate-25k
[23:52] <lotuspsychje> nice nice
[23:53] <Bashing-om> Maybe, going to have impact yet . Mark may know what he is doing, recon ?
[23:53] <lotuspsychje> lol
[23:53] <lotuspsychje> well i rather trust ubuntu on devices then any other Os
[23:54] <lotuspsychje> i really dont like 'internet of things' goes neither
[23:54] <lotuspsychje> but with ubuntu on it, at least we are pretty safe
[23:55] <Bashing-om> Yeah, I am dyed in the wool - spent the time - and want no other .
[23:55] <lotuspsychje> :p:p
[23:55] <lotuspsychje> Bashing-om: did you see that mycroft thing yet?
[23:56] <lotuspsychje> wileee: good evening to you too
[23:57] <Bashing-om> lotuspsychje: Nope .. may have heard a bit but rings no loud bell ; What's up .
[23:58] <wileee> lotuspsychje, evening
[23:58] <lotuspsychje> philipballew: good evening!
[23:58] <lotuspsychje> Bashing-om: https://insights.ubuntu.com/2015/08/14/meet-mycroft-open-source-artificial-intelligence-powered-by-snappy/
[23:58] <lotuspsychje> internet of things...
[23:58] <TJ-> Do you know why it's called Mycroft?
[23:58] <lotuspsychje> TJ-: no?
[23:59] <TJ-> Sherlock Holmes older, wiser, brother ;0
[23:59] <TJ-> from the stories of Sir Arthur Conan-Doyle
[23:59] <lotuspsychje> never heard of this brother


[00:35] <rww> stop making new nicks Unit193 :(
[00:35] <rww> also, always-opped sounds fine to me
[00:36] <JackFrost> rww: What?  I can't change my nick every so often, but IdleOne gets to change his all the time now?!
[00:36] <JackFrost> :P
[00:37] <rww> IdleOne doesn't change his all the time
[00:37] <JackFrost> Used to be every release, pity he didn't last time.
[01:08] <bazhang> special holiday exemption even?
[01:08] <bazhang>  /nick bakwanza
[01:09] <JackFrost> bazhang: Do it!
[01:09] <JackFrost> /nick bazhang
[01:09] <bazhang>  /regain
[01:10] <IdleOne> JackFrost: I was too busy. I completely missed the release
[01:14] <JackFrost> IdleOne: Ah, that's alright.  There's another here soon.
[01:15] <IdleOne> yeah and with any luck I'll be too busy
[20:59] <k1l_> @mark #ubuntu WLM messaged about his awayscript