[07:20] <jtv> thumper: you're probably eod, but if not… care to review?  https://code.edge.launchpad.net/~jtv/launchpad/bug-643345/+merge/36258
[07:30] <jtv> Anyone else who could review for me?  stub?
[07:34] <jtv> jml maybe?
[07:50] <jtv> gmb, you perhaps?
[07:53] <jtv> allenap then?
[07:54] <jtv> StevenK?
[07:55] <StevenK> jtv: I can look, but I can only give you code*
[07:57] <jtv> StevenK: theoretically that would slow down the final review, but it's not a very long branch so might as well.
[07:57] <jtv> did noodles775 just join us?
[07:57] <noodles775> Join you for what? ;) Morning!
[07:57] <jtv> morning!
[07:58] <jtv> I'm shopping around for a reviewer for a CP branch… StevenK could do it, but will need a mentor to approve his review.
[07:58] <jtv> It's this branch: https://code.edge.launchpad.net/~jtv/launchpad/bug-643345/+merge/36258
[07:58] <noodles775> Sure.
[07:59] <jtv> \o/
[08:02] <noodles775> jtv: maybe you could help me too? I've got an ec2 test failure email, but the tests pass locally, and the version of db-devel that was most recently merged also went through buildbot fine (r9808: https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/237)
[08:02] <jtv> noodles775: happy to return the favour
[08:02] <noodles775> I've stared at it a bit yesterday, but would love a second pair of eyes?
[08:02]  * jtv looks
[08:02] <noodles775> Thanks, I'll forward the failure email.
[08:03] <jtv> noodles775: I know the feeling—I could do with a new pair of eyes myself.
[08:04] <noodles775> The email has the branch that you should be able to make and test locally. Thanks jtv
[08:06] <StevenK> noodles775: jtv's MP doesn't have any obvious gotchas that I can see.
[08:06] <noodles775> Thanks StevenK
[08:07] <jtv> noodles775: wow, that's not a very informative failure is it?
[08:08] <noodles775> jtv: no, and it's not just one... there's also 2 windmill errors (which also pass locally, at least did for me).
[08:08] <jtv> Yes, I'm looking at them
[08:08] <jtv> noodles775: the test failure (as opposed to the 2 errors) looks familiar
[08:09] <noodles775> I thought so too, but couldn't see any evidence of it on buildbot.
[08:09] <jtv> we had something like that recently…  I think StevenK investigated but the problem was elusive
[08:10] <jtv> IIRC the test had just been converted from using getLatestOops (or something along those lines) to self.oopses (or something along those lines) when that happened.
[08:10] <noodles775> StevenK: http://pastebin.ubuntu.com/498260/
[08:10] <noodles775> ?
[08:12] <noodles775> jtv: did it also fail only on ec2 test and not on db-devel? (that would explain why I can't see it on the recent buildbot runs).
[08:12] <noodles775> jtv: And if that's the case, can you confirm for me that all 3 tests pass for you locally on that branch, and I'll submit it?
[08:12] <StevenK> Funny you should mention that: https://hudson.wedontsleep.org/job/db-devel/44/testReport/lp.services.job.tests.test_runner/TestJobRunner/test_runAll_mails_oopses/
[08:12] <jtv> noodles775: the former is something StevenK can answer better, and the latter is something I'm about to try
[08:13] <noodles775> StevenK: Ah! So it's not just my branch! So why is it failing ec2 test and hudson, but not db-devel?
[08:14] <StevenK> noodles775: To be completly honest, I'm not sure
[08:15] <StevenK> But I am happy that hudson has a test failure that is useful and reproducable
[08:15] <noodles775> Different versions of oops-tools?
[08:21] <jtv> could that make a difference to the running of the tests?
[08:21] <jtv> I thought that was all post-facto processing, not related to actual generation of oopses.
[08:25] <jtv> noodles775: the "failure" one passes for me… trying the "error" ones.
[08:25] <noodles775> Thanks.
[08:26] <jtv> StevenK: found any nits to pick yet? :)
[08:26] <noodles775> jtv: only things I've thought so far are:
[08:27] <noodles775> 1) It wasn't obvious to me without reading the code below that committer_string isn't an actual commit string provided (somehow) by the committer. Not sure if there's a better name, or maybe its just me.
[08:28] <noodles775> 2) In getBzrCommitterID you're using self.committer.preferredemail, even though abentley's change of the related bug title seems to indicate this is wrong?
[08:28] <noodles775> (but I don't know the background)
[08:28] <jtv> noodles775: the first of those errored windmill tests passed for me, but the second crashed firefox.  (I'm on maverick beta)
[08:29] <noodles775> So am I... that's interesting though, I'd not run them together, always separately.
[08:29] <jtv> noodles775: I'd be happy to come up with a better name for 1.  As for 2, that falls under the "laying groundwork" part—there must be better fixes, but for now I just want the failures out of the way.
[08:29] <jtv> noodles775: I'm running the tests separately as well.
[08:30] <noodles775> Yes, but (regarding 2) couldn't you just remove that elif for the moment to get the failures out of the way?
[08:30] <thumper> jtv: reviewed
[08:30] <noodles775> jtv: Ah, another thought... I wonder if the windmill failures are related to the FF version.
[08:30] <jtv> noodles775: well AIUI it's wrong _because_ it's not guaranteed to be present.
[08:31] <jtv> Not inherently wrong otherwise that I know of—people on that end made a deliberate decision to use email addresses, and I don't want to controvert them wholesale.
[08:31] <jtv> thumper: thanks!  I also have noodles775 looking at it just now
[08:31] <thumper> jtv: ok
[08:31] <noodles775> Ah, I'll just add my review so far as a comment FTR - I didn't realise thumper was/had looked at it.
[08:32] <thumper> noodles775: that's fine
[08:32] <jtv> thumper: but very happy to have your view on it
[08:32] <thumper> I didn't read all the comments after jtv pinged
[08:32] <jtv> there were too many :)
[08:32] <jtv> noodles775: the branch puller test leaves a branch locked, but otherwise its test passes for me.
[08:34] <noodles775> jtv: so one windmill test errored for you... which one was it? test_pofile_new_translation_autoselect ?
[08:34] <jtv> yes
[08:35]  * noodles775 runs it locally
[08:35] <jtv> and once Firefox gets involved, I'm not even willing to guess at the moving parts and variables that come into play…
[08:44] <jtv> thumper: pushed changes for your review
[08:44] <jtv> (moving on to noodles' review)
[08:47] <jtv> noodles775: pushed changes for your review
[08:48] <thumper> ack
[08:52] <jtv> noodles775: just pushed another tiny, tiny thing I missed in renaming that parameter.  Nothing you wouldn't expect.
[08:53] <noodles775> Yep, looking now.
[08:53] <jtv> dankeschön
[08:56] <noodles775> jtv: committer_id is much clearer, thanks. And test_pofile_new_translation_autoselect still passes fine for me locally.
[08:57] <jtv> noodles775: maverick or lucid?
[08:57] <noodles775> maverick
[08:59] <jtv> same here :(
[08:59] <jtv> may be a plugin
[08:59] <jtv> phone call…
[08:59] <noodles775> jtv, StevenK: the oops error just appeared on buildbot, so that one seems spurious.
[09:01] <jtv> :/
[09:01] <StevenK> Oooh, so it is real
[09:02] <noodles775> Real in the sense that it happens sometimes even on buildbot, yes.
[09:17] <jtv> noodles775: by the way, sorry about the double-review hassle; I was knocking on doors and moving on when I got no reply.  Are things to your satisfaction now?
[09:18] <noodles775> jtv: no problem! Yep - I only reviewed the code as per my comment, but I'm happy with that (after your variable change).
[09:18] <jtv> noodles775: thanks—then I'll land on devel
[09:39] <jml> *sigh*
[09:39] <jml> no one reviewed my branch yesterday
[09:39] <jtv> jml: as it happens, I'm OCR.  Putting out some fires today, which is why I haven't gotten around to the backlog, but I could do it now.
[09:39] <jml> jtv, that'd be great, thanks.
[09:40] <jml> https://code.edge.launchpad.net/~jml/launchpad/buildd-slavescanner-bustage/+merge/36187
[09:40] <jtv> jml: you're turning into a Hindu god.
[09:41] <jml> jtv, oh?
[09:41] <jtv> Lots of creative destruction and, evidently, more than the normal quota of hands to type with.
[09:42] <jtv> jml: who is "we" in this narrative by the way?
[09:42] <jtv> Royal "we"?
[09:43] <jml> jtv, bigjools & I
[09:43] <jml> jtv, and Shiva
[09:43] <jtv> jml: …and this is why the comma is a bad way to indicate that you're addressing someone directly in IRC.  :)
[09:43] <jml> jtv, I hate it the comma autocomplete
[09:44] <jml> jtv, but xchat doesn't give me a control to change it
[09:44] <jtv> ah!  there are clients that do that?
[09:44] <jtv> a mild bowel discomfort be upon them
[09:45] <jtv> jml: diff line 41 is weird: "Similarly, but"
[09:46] <jml> jtv, oh yeah. I guess "But" will do
[09:48] <jtv> jml: I'm unable to find the connection between the narrative and the test there, but that's probably just me.  If you assume me they match, that's good enough for me—as long as I get you to expend some thought on the matter.
[09:49] <jml> jtv, they do match. the broader narrative is about checking the deb lines.
[09:50] <jtv> jml: I believe you blindly.
[09:50] <jml> jtv, I don't think archive-dependencies.txt is a well-written document, and would rather (one day) move all of those to unit tests.
[09:50] <jtv> I'm glad you're making the effort.
[09:56] <jtv> jml: diff line 698 would read even better IMHO if you switched conditions around to read "... and not ..."
[09:57] <jml> jtv, good call
[09:58] <jtv> jml: also, I see some XXX comments that lack date, name, and bug reference.
[09:59] <jml> jtv, yeah, I'll quickly review those now.
[09:59] <jtv> thanks
[10:03] <jtv> jml: a bit scary that the OkSlave previously did almost nothing but then suddenly Popen'ed in resume()…
[10:05] <jml> jtv, yes, it is.
[10:05] <jml> jtv, lots of this stuff is scary
[10:06] <jml> jtv, maybe in a branch today or tomorrow we'll actually kill all of those mocks and do the mocking at the xmlrpclib layer.
[10:06] <jtv> that sounds like a cool idea… so much of it is no-brainer replication anyway.
[10:06] <jml> exactly
[10:06] <jtv> The call log is quite close to what FakeMethod does, even.
[10:06] <jml> yeah, but we are selective about what we append
[10:07] <jml> the whole thing is really close to niemeyer's mocker
[10:07]  * jtv sobs quietly into a handkerchief, then composes himself
[10:07] <jml> which I'm not sure why we don't use.
[10:07] <jtv> Not in this branch though!
[10:07] <jtv> But yes, if that fits, by all means do it.
[10:09] <jtv> Ah, a meaningful docstring on a test case.  The astrologists always said it would happen, but I didn't expect to see it in my lifetime.
[10:09] <jml> jtv, fwiw, Michael Foord, who was recently hired by Canonical, also has a popular mocking library :)
[10:09] <jtv> TMTM
[10:09] <jml> something like that :)
[10:10] <jtv> jml: why does TestBinaryBuildPackageBehavior.setUp invoke its super, create a factory, and log in?  Doesn't TestCaseWithFactory provide all that?
[10:11] <jml> jtv, TCWF does indeed provide all of that, but we are subclassing Twisted's TestCase, since we need the Deferred support
[10:11] <jml> jtv, and multi inheritance for TestCases is a nightmare.
[10:11] <jtv> jml: I only see it being derived from unittest.TestCase.
[10:11] <jml> jtv, "from twisted.trial import unittest"
[10:12] <jtv> that is obscene
[10:12] <jml> jtv, we all make mistakes in our youth that we later come to regret
[10:12] <jml> jtv, one of mine was calling the main trial module 'unittest'
[10:12] <jtv> jml: was it legal in the country you grew up in?
[10:13] <jtv> ah wait, I'm thinking of drugs there.
[10:13] <jtv> Different mistake.
[10:13] <jml> jtv, yes, but socially frowned upon.
[10:13] <jtv> Good, good.
[10:13] <jtv> How about, in this special case, importing twisted and qualifying as twisted.trial.unittest.TestCase?
[10:14] <jml> jtv, well, we often do "from twisted.trial.unittest import TestCase as TrialTestCase"...
[10:14] <jtv> that'd work too
[10:15] <jml> jtv, but I didn't do that here because it adds TrialTestCase to the test suite
[10:15] <jml> (also my fault)
[10:15] <jtv> Can you "from twisted.trial import unittest as twisted_unittest"?
[10:16] <jml> jtv, yeah, I'll do something like that.
[10:16] <jtv> Thanks.  I sorely need a break; brb
[10:16] <jml> np
[10:27] <jtv> jml: back from break… have you considered taking twisted out of the test altogether?
[10:27] <jml> jtv, no.
[10:27] <jtv> the obvious follow-up: would it be worth considering?
[10:28] <jtv> I did that in one of the slave tests.
[10:28] <jml> jtv, ok, sorry, what I meant was that I considered and rejected it...
[10:28] <jtv> I forget how, sadly.
[10:28] <jtv> Ah :)
[10:28] <jml> jtv, we're changing the BuilderSlave to have a Twisted API
[10:28] <jml> jtv, so that the buildmaster can be properly written
[10:29] <jml> jtv, that API change is going to bubble up and affect all of the *Behavior objects
[10:29] <jtv> ah
[10:29] <jtv> And, I suppose, make it far too risky to try and hack your way out of twisted just for the purpose of this test.
[10:29] <jml> jtv, that's pretty much what's driving this work
[10:30] <jml> jtv, indeed.
[10:30] <jml> jtv, we *might* be able to do something tricky later on
[10:30] <jml> jtv, but until things are stabilized, I'd rather not.
[10:30] <jtv> But Knuth's Law.  Got it.
[10:30] <jml> Yes. That one :)
[10:31] <jml> (as an example, lp.codehosting.vfs has code that works with either a synchronous xmlrpc client or an asynchronous one).
[10:33] <jtv> In ll. 984—992 of the diff, would it perhaps be clearer to use a list comprehension, perhaps even without the nested function definition?
[10:33] <jtv> expected = [
[10:33] <jtv>     ['cacheFile', 'sendFileToSlave', ('ensurepresent', url, '', '')]
[10:33] <jtv>     for url in [chroot.http_url] + extra_urls]
[10:34] <jtv> Oh, you're extending, not appending.
[10:34] <jml> jtv, I'm open for ideas on making that code clearer.
[10:35] <jml> jtv, I had to switch to Haskell mode to be mentally capable of solving the problem
[10:35] <jtv> Good start.
[10:38] <jtv> jml: personally, I've come off the idea of building these great clever assertion methods in tests.  I do like the general approach, but find it better to return something I can compare in a single comparison directly in the test.
[10:38] <jtv> Makes failures much easier to deal with.
[10:39] <jml> jtv, certainly that would be nice
[10:39] <jml> jtv, the current API we're testing is a bit of a blunt instrument. I can't think of anything less bad than the assertion we have now.
[10:41] <jtv> jml: I think this might be clearer… http://paste.ubuntu.com/498340/
[10:43] <jml> jtv, you mean, a) change the function to a list comp; b) change the assertion method into a helper that builds the object to compare against?
[10:43] <jtv> jml: exactly
[10:43] <jml> ok. I'm willing to give that a try.
[10:43] <jtv> (Of course not all of the function will fit into a list comprehension, but forming a list would be the obvious core of it)
[10:44] <jtv> jml: I'd also extract the dict into a variable, which will break down the structure a bit and also allow the contents to follow our syntax guidelines.
[10:45] <jml> how do they break from our syntax guidelines?
[10:45] <jtv> syntax guidelines say dictionary = {
[10:45] <jtv>     'item1': 1,
[10:46] <jtv>     'item2': 2,
[10:46] <jtv>     }
[10:46] <jml> oh right.
[10:50] <jtv> ahhh, looking at the calls, I see why you have the assertion method.  It must be fun debugging this stuff.
[10:51] <jml> jtv, the test failures are relatively easy to grok.
[10:51] <jtv> btw I guess twisted tests are expected to return a deferred, or watchumacallit?
[10:51] <jml> jtv, but, well, big fat APIs that do a lot of stuff are always hard to test.
[10:51] <jml> jtv, yes, they are
[10:52] <jml> jtv, full story: if a trial test returns a deferred, trial will wait for that deferred to fire before moving on to the next test.
[10:52] <jml> jtv, that facility is necessary when dealing w/ async code
[10:52] <jtv> jml: that sort of suggests itself… but makes the naming similarity to unittest all the more unfortunate
[10:53] <jml> jtv, in most ways it's quite similar to unittest
[10:54] <jtv> It's good to follow the same patterns, but awkward to have a different call model in such a close semblance of unittest
[10:56] <jtv> jml: in ll. 1073—1077 of the diff, it may be easier to construct the expected error string outside of the assertion.
[10:57] <jtv> I wish these tests could be shorter, but see no very reasonable way to do it.
[10:57] <jml> sure.
[10:57] <jml> me neither.
[10:57] <jml> I'm hoping that as we push deeper into this stuff something will present itself
[10:59] <jtv> You could extract the chroot-setting part into a helper.  Bit ugly with the commit in the middle (why not transaction.commit, by the way?) but would extract some unhelpful text from the tests.
[11:00] <jtv> I suspect the setup of builder and slave could also be extracted.
[11:02] <jml> maybe.
[11:02] <jml> their construction is parametrized differently in different tests, so I'm a little bit wary of prematurely refactoring.
[11:02] <jml> not transaction.commit() because zopeless.
[11:03] <jml> maybe that doesn't matter these days
[11:03] <jtv> I don't think it does
[11:03] <jml> In that case, layer.txn ought to be hidden.
[11:04] <jtv> I'm not sure but I think layer.txn == transaction
[11:05] <jtv> jml: the archive and the build are parameterized differently, but the builder and slave..?
[11:06] <jml> jtv, parametrized by the archive, arch series, virtualized or not.
[11:06] <jtv> jml: of course there's nothing stopping a helper from accepting similar pameters
[11:06] <jml> yeah.
[11:07] <jml> but then when we add a new test we'll probably need to change the helper
[11:07] <jtv> it's you call though; the question is how relevant it is to the test
[11:07] <jml> I'd like to leave it for now.
[11:07] <jml> where are we at more generally w/ the review? bigjools is doing some stuff that I'd like to stick my nose into.
[11:08] <jtv> jml: I think we're through most of the code you added; after that I'll make one more brief pass to look for lost coverage but I don't expect to find anything.
[11:09] <jml> jtv, cool. thanks.
[11:11] <jtv> jml: I suppose the bit in lines 63—99 is really just unnecessarily duplicating Librarian work?
[11:15] <jtv> jml: I'm saturated, so not much use for me to look through this further.  I'll have to trust that the coverage matches, or if not, that (1) people will be afraid to touch the code anyway or (2) any failures will cause widespread panic and so will be instantly fixed and tested in a modern way.
[11:16] <jml> jtv, understood
[11:16] <jtv> jml: got a revision for me?  I'm EOD'ing as far as all else is concerned.
[11:16] <jml> jtv, the 63-99 is already tested in buildmaster/model/tests/test_builder.py
[11:16] <jml> jtv, http://pastebin.ubuntu.com/498363/
[11:16] <jtv> thanks
[11:17] <jml> jtv, I had to keep the assert helper because the cookie is only created after startJob is called.
[11:18] <jtv> jml: understood, I think… still think you've made an improvement there.
[11:18] <jml> jtv, thanks.
[11:19] <jtv> Brings the interesting part of a failure one level closer to where the reader looks for it.
[11:19] <jtv> In the traceback, I mean.
[11:20] <jml> yeah.
[11:26] <jtv> jml: I've approved.
[11:26] <jtv> On call: - || Reviewing: - || queue: []  || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
[11:27] <jtv> I meant…
[11:34] <jml> jtv, thanks.
[11:34] <jtv> np
[13:37] <deryck> adeuring, hi, can I get a review from you? (he says, picking a bugs guy at random.)
[13:38] <adeuring> deryck: sure
[13:38] <deryck> adeuring, thanks!  https://code.edge.launchpad.net/~deryck/launchpad/displayname-private-team-oops-634847/+merge/36199
[13:48] <jcsackett> MP for me: https://code.edge.launchpad.net/~jcsackett/launchpad/unknown-blueprints-service-597738-2/+merge/36242
[13:54] <adeuring> deryck: r=me
[13:55] <deryck> adeuring, awesome, thanks!
[14:29] <mars> StevenK, still online?
[14:40] <StevenK> mars: I am
[14:41] <mars> StevenK, heya, did you get to any of the reviews that I left in the queue last night?
[14:41] <StevenK> mars: You know, I forgot I was OCR today. :-(
[14:42] <mars> StevenK, no problem, everyone does that from time to time
[14:42] <mars> StevenK, if you would like, there are two reviews in the channel queue, and one in +activereviews.  But I realize it is late there, well past your EOD
[14:43] <StevenK> mars: Yup, I don't think I can think straight enough :-)
[14:44] <mars> StevenK, next week then.  leonardr might be OCR, but we can do the same thing again, and save up some reviews for you.  There are usually a few at the end of the day here
[14:44] <mars> so it doesn't impact the developers if leonardr and I save them for you
[15:15] <sinzui> EdwinGrubbs, ping
[15:16] <EdwinGrubbs> sinzui: hi
[15:17] <sinzui> EdwinGrubbs,  can you review the two sql scripts that Chex and I tested on staging yesterday to clean up deactivated/merged user data? We need another engineer to agree they are sane: http://pastebin.ubuntu.com/498514/ and http://pastebin.ubuntu.com/498518/
[15:18] <sinzui> EdwinGrubbs, Staging ran fine, and the UI looked great after we ran them
[15:32] <EdwinGrubbs> sinzui: wouldn't it be a good idea to check whether Person.merged is not null instead of just trusting the name?
[15:33] <sinzui> Edwin I think that would be a good idea
[15:45] <EdwinGrubbs> sinzui: I don't see any other issues. However, it would be nice if a backup of those tables could be taken just in case some user needs to be reverted however unlikely that is.
[15:46] <sinzui> EdwinGrubbs, since we tested on staging. without any issues. I think I should revise the script, maybe combine the deactivated/merged rule so that it is one script. Then test it on staging next week with fresh data
[15:52] <EdwinGrubbs> sinzui: will removing the team memberships have an adverse affect on the non-human user ~katie, who is suspended and a celebrity in the code.
[15:53] <sinzui> Oh :( I bet it will
[15:53] <sinzui> I need to think about that
[15:58] <sinzui> Edwin do you think is it safe to remove suspended users from the invited and proposed states, but ignore those that are members? I think it is better to leave some cruft behind and run the parts we trust to work
[16:03] <rockstar> abentley, could I get a review of https://code.edge.launchpad.net/~rockstar/launchpad/build-farm-job-constraint/+merge/36219
[16:03] <rockstar> (I was asked to leave it for StevenK so that he could get review experience, but he didn't touch it yesterday)
[16:04] <abentley> rockstar, r=me
[16:06] <rockstar> abentley, thanks.
[16:41] <deryck> adeuring, hi.  So a couple minor thoughts about your branch....
[16:41] <deryck> adeuring, do you really need "We’ve" in place of the plain "We've" in HTML?
[16:42] <adeuring> deryck: I simply copied that from the regular error page
[16:42] <adeuring> but I can change it to a simple "'"
[16:43] <deryck> adeuring, yeah, let's do that.   Unless there's some compelling reason to encode that character.
[16:44] <deryck> adeuring, and then I tend to prefer using ellipses to hide more of that error mesaage in the page test.  In case the template changes it doesn't make the test fragile.
[16:44] <deryck> adeuring, but that's up to you.  Otherwise, r=me.
[16:45] <adeuring> deryck: right using more "..." makes sense
[16:45] <adeuring> deryck: and thanks!
[16:46] <deryck> adeuring, np
[16:46] <deryck> thanks for the fix.
[19:53] <leonardr> EdwinGrubbs, who can do a ui review? i haven't needed one since we instituted the process, but i need one now
[19:56] <EdwinGrubbs> leonardr: I can do it, but I'm not graduated, so you will have to get two reviews. noodles has graduated, and he is oncall tomorrow morning.
[19:56] <leonardr> ok, cool
[19:56] <leonardr> i'll get something ready
[20:13] <abentley> EdwinGrubbs, could you please review https://code.launchpad.net/~abentley/launchpad/fix-groupby/+merge/36360 ?
[20:14] <EdwinGrubbs> abentley: sure, I'll let you jump the queue since the branch is so small.
[20:15] <abentley> EdwinGrubbs, thanks.
[20:20] <jcsackett> EdwinGrubbs: realized i posted this before you came on call: https://code.edge.launchpad.net/~jcsackett/launchpad/unknown-blueprints-service-597738-2/+merge/36242; it's the MP i already put myself in the queue for, when you have time.
[20:21] <EdwinGrubbs> jcsackett: I should get to that in about an hour.
[20:21] <jcsackett> EdwinGrubbs: fantastic. thanks. :-)
[20:44] <leonardr> edwingrubbs: https://code.edge.launchpad.net/~leonardr/launchpad/rename-grant-permissions/+merge/36363
[20:44] <leonardr> if you can't get to it, no big deal
[20:44] <EdwinGrubbs> we'll see
[21:02] <EdwinGrubbs> abentley: r=me
[21:02] <abentley> EdwinGrubbs, thanks.
[21:40] <rockstar> abentley, could you take a look at: https://code.edge.launchpad.net/~rockstar/launchpad/recipe-too-new/+merge/36379
[21:42] <abentley> rockstar, you need to do monkeypatches in a try/finally block; otherwise, they can leak.
[21:42] <abentley> rockstar, or you could use a with statement.
[21:43] <abentley> rockstar, the with statement gives you a little code reuse.
[21:44] <rockstar> abentley, so, you're suggesting creating a contextmanager that does the monkey patch?
[21:44] <abentley> rockstar, yeah, I think that's the cleanest way.
[21:44] <rockstar> abentley, okay.
[21:48] <abentley> r=me with that change.
[21:48] <EdwinGrubbs> sinzui: review sent
[21:50] <rockstar> abentley, where should that context manager live?  lp.code.testing doesn't exist, but that makes the most sense.
[21:50] <abentley> rockstar, we use lp.code.tests.helpers for that kind of thing.
[21:50] <rockstar> Ah, even better.
[21:51] <sinzui> thanks edwin
[22:07] <rockstar> abentley, a cursory review of http://bazaar.launchpad.net/~rockstar/launchpad/recipe-too-new/revision/11608 please?
[22:10] <abentley> rockstar, you should do the assignment to RecipeParser.NEWEST_VERSION before the try.  The only thing in the try should be the yield.
[22:10] <rockstar> abentley, really?  Is there some extra logic in the context manager then?
[22:10] <abentley> rockstar, in this case, it doesn't matter, because the teardown doesn't require the setup to have succeeded.
[22:10] <rockstar> abentley, ah, okay.
[22:10] <abentley> rockstar, no.  This is true of all try/finally blocks.
[22:11] <rockstar> abentley, yeah, I hadn't really thought that through.
[22:14] <EdwinGrubbs> jcsackett: r=me
[22:14] <jcsackett> EdwinGrubbs: thanks.
[22:51] <EdwinGrubbs> leonardr: review sent
[22:58] <leonardr> edwin, thanks


[12:29] <twentyafterfour> channel topic might need an update - doc.ubuntu.com doesn't work
[12:47] <nixternal> it works here
[12:47] <nixternal> they are doing something funky with the servers I think
[12:47] <nixternal> because I did notice yesterday it was having issues of not showing up
[12:50] <twentyafterfour> hmm. ok, no big deal - I just noticed it not loading ;)
[12:50] <twentyafterfour> hey I noticed something else - the online docs at help.ubuntu.com don't include feisty - is that just not ready yet?
[12:55] <nixternal> that is correct
[12:55] <CIA-12> Ubuntu Documentation: nixternal feisty * r4122 / (5 files in 2 dirs): debian updates for kubuntu - update sidebar to point to sysdocs-index
[12:56] <CIA-12> Ubuntu Documentation: nixternal * r4123 kubuntu/debian/ (changelog control postinst prerm rules): merging feisty changes
[08:42] <mdke> morning
[09:00] <Burgundavia> morning mdke
[09:02] <mdke> yo
[10:28] <fijam> hello
[08:10] <ubotu> New bug: #108625 in ubuntu-doc "Feisty: libdvdcss2 said to be in universe/multiverse, but it's not" [Undecided,Unconfirmed]  https://launchpad.net/bugs/108625


[00:42] <pace_t_zulu> hggdh: thanks for your help
[02:40] <pace_t_zulu> hggdh, ping
[03:02] <pace_t_zulu> anyone around?
[03:04] <micahg> pace_t_zulu: yes
[03:04] <Linux000> pace_t_zulu
[03:04] <Linux000> yes
[03:07] <Linux000> does anyone know where the xorg.conf file is for ubuntu 10.04
[03:07] <micahg> Linux000: there's isn't one by default
[03:08] <Linux000> ? How does that work? X is set up default everytime?
[03:09] <micahg> Linux000: idk, I would think it just uses the defaults
[03:09] <Linux000> Okay
[03:23] <pace_t_zulu> micahg: Linux000 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/535297
[03:23] <ubot4> Launchpad bug 535297 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000028 (affects: 13) (dups: 2)" [High,Confirmed]
[05:18] <rockfx01> hello
[05:20] <rockfx01> just wondering - if I want to request a bugsquad mentor, the instructions say i need to create a wiki entry ....
[05:20] <rockfx01> Is that really necessary or can i just change my homepage content in launchpad with the necessary details?
[05:48] <persia> rockfx01: You're going to want to have a wiki page later anyway, so it's best to create it now.  Just add your name, contact details, and a short blurb about yourself or about your involvement with Ubuntu.
[05:48] <persia> rockfx01: This reserves the wiki namespace for you later, for when you need it, allows others to write testimonials to your excellent work, etc.
[05:56] <ddecator> if i've been approved to be a mentor, am i supposed to add myself to the wiki page?
[06:06] <micahg> ddecator: Help -> Report A Bug in Firefox 3.6 is broke until the next ubufox upload to lucid :)
[06:07] <ddecator> micahg, good to know
[06:08] <ddecator> you spend a few days writing papers, and you fall behind o.o
[06:10] <kermiac> pedro - pind re your message earlier
[06:11] <ddecator> hey kermiac
[06:12] <kermiac> hey ddecator - haven't seen you for a couple of days. Congrats mate :)
[06:12] <ddecator> kermiac, thanks =) i've been working on writing papers for my finals. just finishing up tonight so i can get work done again starting tomorrow
[06:13] <ddecator> kermiac, are you talking about pedro v.?
[06:14] <kermiac> yeah, but I just noticed he's not here
[06:15] <ddecator> haha, thought so. he's usually on around 1100 - 2000 utc
[06:16] <kermiac> ah, so at least another 5 hours or so
[06:17] <kermiac> just need to clarify something with him as he sent me a message earlier - nothing major :)
[06:17] <ddecator> most likely. i'm not sure if he gets on consistently at the same time or not, but he's always been on at 1500 when i've been on before
[06:18] <ddecator> come to think of it, i need to talk to him too...
[06:21] <rockfx01> ok done and done
[06:22] <ddecator> not sure what you're talking about, but congrats!
[06:26] <ddecator> micahg, i think that's the first time i've seen 3.7 used as a milestone
[06:30] <ddecator> alright, i should probably get these papers finished so i can finally get some sleep...i'll be back tomorrow night
[07:16] <nonix4> Which would be the recommended method for reporting a bug that is making (still active) firefox infinite-loop?
[07:23] <persia> nonix4: `ubuntu-bug firefox` is a good start.  Attach whatever other useful data you can.
[07:27] <nonix4> With one main caveat: it will try to use firefox, which is in infinite loop. Guess "ubuntu-bug PID" outside X is better?
[07:31] <persia> nonix4: Hrm.  I'm not sure.  I have a feeling that will crash also.
[07:31] <persia> But it ought get you a .crash file, and then you can run apport-bug on the .crash file to make the report (when firefox isn't hung)
[07:45] <nonix4> Managed to submit using w3m from console :)
[07:45] <nonix4> (with w3m being launched by ubuntu-bug)
[07:49] <persia> heh.  Nice.
[07:53] <nonix4> #537158 in case somebody is interested in firefox infinite loops :)
[08:00] <persia> bug #536158
[08:01] <ubot4> Launchpad bug 536158 in widelands "_WIN32 versus __WIN32__ (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/536158
[08:01] <persia> bug #537158 !
[08:01] <ubot4> Launchpad bug 537158 in firefox-3.5 (Ubuntu) "Firefox infinite loop, cursor changing between pointer and hand (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537158
[09:06] <BUGabundo_remote> buns di@s
[09:09] <jibel> bonjour BUGabundo_remote
[12:17] <kamusin> :)
[15:32] <ikt> anyone have a log of the meeting?
[15:33] <persia> ikt: irclogs.ubuntu.com doesn't have it?
[15:33]  * persia does but hopes the public resource avoids the complications of file transfers
[15:39] <ikt> yeah it is, cheers :)
[15:39] <persia> Excellent.
[16:12] <m0ar> Filezilla isn't installable from the repos :c
[16:12] <m0ar> Was a few days ago, but somehow it dissapeared from my system and in addition to that it's unreachable from the repos
[16:12] <m0ar> Can someone try to install it, so I can see if it's my end?
[16:13] <BUGabundo_remote> m0ar: $ dpkg -l | grep fire | pastebinit if you please
[16:13] <m0ar> grep file* ?
[16:14] <BUGabundo_remote> fire
[16:14] <BUGabundo_remote> as in firefox
[16:15] <m0ar> I don't see how that's relevant, but sure
[16:17] <m0ar> http://paste.pocoo.org/show/188425/
[16:17] <m0ar> Says I have got FZ installed, but it can't find it
[16:17] <m0ar> meh
[16:17] <m0ar> or is that from the servers?
[16:18] <persia> m0ar: Try dpkg -L filezilla
[16:18] <m0ar> Package filezilla doesn't contain any files
[16:18] <persia> Note that it says "rc" at the beginning.  That means "removed, config files", roughly.  You likely need to install it again.
[16:19] <persia> (and asking in #ubuntu should have gotten this answer)
[16:19] <m0ar> persia: Yeah, but installing doesn't work
[16:19] <m0ar> Ill pastebin
[16:19] <m0ar> http://paste.pocoo.org/show/188426/
[16:20] <m0ar> I posted here since I wasn't able to install it, look at my first message ;D
[16:20] <BUGabundo_remote> m0ar: try #ubuntu-mozillateam
[16:20] <persia> That's because you're on amd64, and it's not ready yet.
[16:21] <persia> Wait.
[16:21] <BUGabundo_remote> ohh fileziila
[16:21]  * BUGabundo_remote needs rest
[16:21] <BUGabundo_remote> soory m0ar
[16:21] <m0ar> BUGabundo_remote: Np ;D
[16:22] <persia> m0ar: Running `rmadison filezilla filezilla-common` will show why.
[16:22] <persia> (and given the versions, #ubuntu+1 would be better than #ubuntu)
[16:23] <m0ar> persia: True. Stilla bug :D
[16:23] <persia> No.
[16:23] <persia> Just a timing issue.
[16:23] <ogra> but in the archive, not in fileziolla
[16:24] <ogra> persia, its definately a bug of the publisher :)
[16:24] <m0ar> ogra: Wonderful, since this isn't #filezilla-bugs
[16:24] <persia> ogra: Do you really think so?  Why should the publisher track cross-arch dependencies?
[16:24] <ogra> persia, i think cjwatson agrees :)
[16:25] <persia> with?
[16:25] <ogra> persia, it should handle arch all/any
[16:25] <m0ar> persia: But it worked a day ago or so?
[16:25] <persia> m0ar: Yeah, a new version was uploaded.
[16:25] <persia> ogra: What should handle arch all/any?
[16:25] <m0ar> persia: Then it's waiting?
[16:26] <persia> m0ar: As I said "Wait"
[16:26] <ogra> persia, the publisher ... well actually Packages.gz
[16:27] <persia> m0ar: https://launchpad.net/ubuntu/+source/filezilla/3.3.1-1ubuntu1/+build/1555594
[16:27] <persia> ogra: So what happens when e.g. ia64 falls behind?
[16:27] <persia> Or sparc?
[16:27] <persia> Or something FTBFS?
[16:28] <ogra> Packages.gz holds the old packages until all binaries are there
[16:32] <persia> ogra: Thanks for the explanation.  I have mixed feelings about it, because sometimes I catch stuff on i386 before it hits other architectures, but I can see the argument.
[16:51] <jcastro> qense: around?
[16:52] <qense> jcastro: yes I am!
[16:52] <persia> jcastro!  Hey.  Is your "How to deal with bugs" one-page flyer PDF up-to-date?
[16:52] <persia> If so, can you point me at it?
[16:53] <qense> jcastro: I'm just rereading my script for the session.
[16:53] <qense> I was*
[16:53] <m0ar> What PDF? :)
[16:53] <jcastro> persia: I didn't have a bug one, that was someone else's, I can look for it though
[16:53] <jcastro> qense: ok I was just making sure I was in the right place/time. :D
[16:53] <jcastro> persia: mine was kind of a high level workflow thing
[16:54] <qense> persia: Ubuntu One has a very nice work-flow for bugs on one of its wiki pages
[16:55] <qense> the .dia file is provided, so it should be very easy to adapt it.
[16:55] <persia> jcastro: Sorry for the misdirect then.
[16:55] <persia> qense: Thanks : I may grab that, but was hoping for a flyer :)
[16:55] <jcastro> no worries
[16:55] <qense> jcastro: Of course, if I would have forgotten the time the session would have been saved
[16:56] <jcastro> qense: I kind of paniced too when I got the email reminder, hah
[17:02] <seb128> bdmurray, hi
[17:03] <bdmurray> seb128: hello
[17:03] <seb128> bdmurray, is there some documentation on the wiki or somewhere about the json searches you run?
[17:03] <seb128> bdmurray, or how to get some extra ones added
[17:03] <bdmurray> seb128: no, not really.  Is there one I could make for you?
[17:03] <seb128> bdmurray, what sort of criterious can you use for those?
[17:04] <bdmurray> seb128: anything launchpadlib can do
[17:04] <bdmurray> this from arsenal is somewhat similar to what I do
[17:04] <bdmurray> http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/scripts/ls-tag-json.py
[17:04] <seb128> bdmurray, so things like "give me bugs on those <list of ubuntu_sources> which have a lucid task" are easy to do?
[17:05] <bdmurray> seb128: yes, mostly easily
[17:05] <bdmurray> er mostly easy ;-)
[17:05] <seb128> thanks for the arsenal pointer
[17:06] <seb128> can I build and test a .json locally to test that easily and then hand it to you?
[17:06] <seb128> I'm not sure how to build those or the format
[17:06] <bdmurray> lines 41-43 are what shows up in bughugger
[17:06] <seb128> do you have some examples?
[17:06] <seb128> do you start from bughugger to build those?
[17:07] <seb128> I basically know what I want bug not how to transode it in a format your tools can deal with ;-)
[17:07] <bdmurray> no, you'd use ls-tag-json.py and the output would be the json data file
[17:07] <seb128> and is there anything I can give the json data file to locally to check it does what I want?
[17:07] <bdmurray> so ./ls-tag-json.py apport-crash evolution firfox will give you all the bugs tagged apport-crash about evolution and firefox
[17:08] <bdmurray> What you are looking for, lucid only tasks, would take a bit more work
[17:09] <bdmurray> Why don't you send me what you are looking for and I'll whip something up and then in the future you could write it and I'll stick it on qa.ubuntu.com?
[17:10] <seb128> bdmurray, in this case I wanted a dx indicators summary
[17:10] <seb128> so one minute I make a list of sources I'm interested in ;-)
[17:15] <seb128> "ido indicator-applet indicator-application indicator-me indicator-messages indicator-session indicator-sound libdbusmenu libindicate libindicator" + bugs tagged indicator-application if possible
[17:15] <seb128> bdmurray, ^ I would like to list all the bugs with a lucid tasks on those
[17:18] <bdmurray> seb128: okay, I'll have something by the end of my day
[17:18] <seb128> bdmurray, you rock, thanks
[17:21] <jcastro> qense: you're doing great!
[17:21] <qense> jcastro: thanks! :)
[17:22] <dako3256> Could someone set Bug #518865 to wish-list
[17:22] <ubot4> Launchpad bug 518865 in blogtk "Enable customisation of toolbar and date/time button (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518865
[17:26]  * persia looks
[17:28] <persia> You'll want to contact the blogtk team about that.  We only set priorities for Ubuntu bugs.
[17:41] <dako3256> I thought Bug Squad could do that?
[17:42] <hggdh> dako3256: we can, but we should not. This bug is an upstream bug, not an Ubuntu one
[17:42] <persia> actually, we can't.
[17:43] <hggdh> heh. I thought we could -- but never really tried
[17:43] <persia> We only do it for Ubuntu tasks and Ubuntu bugs (and only have permission, as a group, to do it for those)
[17:43] <persia> hggdh: Go visit the bug : I suspect you don't have access (I don't)
[17:49] <hggdh> persia: yeah... I cannot change Importance (but can change Status and package)
[17:50] <persia> hggdh: You can't change the status to Triaged or Won'tFix, can you?
[17:51] <hggdh> persia: indeed I cannot :-)
[17:59] <persia> qense: Great session!
[18:00] <qense> persia: thanks!
[18:01] <qense> afk now!
[18:53] <maco2> what do folks think about adding a "patch-good" tag if a bug report includes people saying they tested the patch or patched-package-in-ppa and found it works, that way people looking for known-good patches to package up have an easier time of it?
[18:56] <persia> maco2: How many patches do we expect to find that are both known-good and don't better belong upstream?
[18:59] <persia> maco2: To put that differently, I think it's a good idea, I'm just unsure how many patches fall into that category, and how many will only be discovered by non-developers.
[19:00] <maco2> persia: oh i do think theyd need to go upstream
[19:00] <maco2> but no harm in putting it in now while waiting for it to be upstreamed, is there?
[19:01] <radoe> persia: many of the patches backported for a SRU? Any one of the "patched-in-debian-unstable-but-too-late-to-wait-for-debian-testing"
[19:01] <maco2> so maybe tag it *and* submit it upstream at the same time?
[19:01] <persia> maco2: I guess.  I'd prefer a tag indicating it was sent upstream if it was.
[19:02] <maco2> persia: there is a tag to say its awaiting upstream input. patch-upstreaminput
[19:03] <persia> radoe: I'd hope that the SRUable bugs and tracking-debian bugs were being given closer review by developers really, where "patch-good" isn't useful when they should just be getting it uploadeed.
[19:03] <persia> maco2: That seems clearer.
[19:04] <maco2> i dont think we have a way of knowing what's SRUable either though
[19:04] <maco2> i mean, read through the whole report...
[19:04] <persia> We have nominations that we ought be using to track that.
[19:05] <maco2> cherry-picks from upstream VCS would be an example of something that we know is already upstream but we cant really find easily in lp
[19:06] <persia> maco2: But why do we even want those in LP in the first place?
[19:06] <persia> Or if we find them, why not have a developer just upload them?
[19:07] <maco2> because the person who finds them may not be a developer?
[19:07] <persia> (and I have a feeling this is on the edge of on-topic here, and probably belongs in #ubuntu-reviews)
[19:07] <maco2> ah that's the channel name
[19:07] <maco2> irssi told me last time i tried /list that i shouldnt do that, so i didnt know how to find other channels
[19:07] <persia> Ah, so you want some escalation path where non-developer reviewers can highlight stuff for higher-priority developer attention?
[19:08] <maco2> right
[19:08] <persia> Generally asking gets channel names :)
[19:09] <persia> OK.  My worry is that by creating that we mind end up with no developers looking at the patches that were not prioritised, and I think we need a mix of triagers and developers looking over *all* the patches.
[19:10] <maco2> i think bugsquad non-devs probably read through more bug reports than devs do as when a dev hits a report they may sit down and spend a few hours fixing it, so probably more people non-devs will see more of these sitting around
[19:10] <maco2> seems like these would be low-hanging fruit
[19:10] <maco2> but right now there's no way to identify them
[19:11] <persia> I see what you're saying.  If you also see what I'm saying then we know the gap :)
[19:12] <maco2> you're saying you hope people don't forget about the higher-level fruit
[19:12] <persia> I'm saying I don't like systems that create distinctions.
[19:13] <persia> And I'm concerned that many patches may be complex enough that non-developers don't know how to review and developers are ignoring them.
[19:17] <maco2> im thinking of throughput
[19:18] <maco2> there's a lot of patches to go through... some are ready to go right now, and some aren't. why not get the ones that are ready uploaded? ...because we can't find them
[19:19] <persia> I'd be willing to consider "patch-good" as a stricltly temporary measure to push through the first bundle, but I think it's a poor solution socially long-term.
[19:19] <maco2> fair enough
[19:21] <persia> As long as we recognise that we're setting a priority because we've only managed to stay even the past year or two, and then we drop it when we get to a manageable point, I think we'll be OK.
[19:21] <persia> But I think the temporary nature of the prioritisation needs to be made clear at the outset.
[19:22] <persia> Otherwise it creates exclusionary boundaries (That's not developer work)
[19:28] <maco2> and see i'm thinking in the other direction as "make it more obvious to non-devs that they can be helpful in this area too, so maybe more of them will do so"
[19:28] <persia> I guess.
[19:29] <persia> I think we have lots of non-devs chasing bugs and making things happen.
[19:29] <persia> I think that developers ignore too much of this.
[19:29] <persia> I think that's part of why we have a backlog.
[19:29] <persia> But I'll agree that the various fusses about "Don't touch workflow bugs" and the like probably complicated matters.
[19:30] <maco2> i still dont quite know what "dont touch workflow bugs" means
[19:30] <persia> I don't think anyone does, which I suspect is part of the problem.
[19:30] <maco2> that greasemonkey script that inserted "WORKFLOW BUG" at the top was useful for knowing what not to touch though :)
[19:36] <persia> Well, no, not really.
[19:36] <persia> Some of that ought get touched.
[19:37] <persia> Others of that ought get moved out of the bugtracker
[19:37] <persia> etc.
[19:37] <persia> Anyway, those are longer-term efforts (but progress is being made).
[19:38] <HandeH> Could somebody help a bit on an odd hardware dependent bug of 3G mobile broadband: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/525049 What do we need more to solve that issue?
[19:38] <ubot4> Launchpad bug 525049 in linux (Ubuntu) (and 1 other project) "3G download speed is very slow compared to Hardy on elderly PIII laptop or Microsoft Windows OSs (affects: 5)" [Undecided,Confirmed]
[19:39] <maco2> O_O the bot now tells the affects count? coooool
[21:54] <blueyed> bdmurray: re bug 514212.. where's the patch? and why ubuntu-reviewers? this is a ffe..
[21:54] <ubot4> Launchpad bug 514212 in jedit (Ubuntu) "Please update jEdit to new stable version 4.3.1 (affects: 1)" [Wishlist,New] https://launchpad.net/bugs/514212
[21:55] <bdmurray> blueyed: because "Upstream changelog diff" was set as a patch once I'd guess
[21:56] <blueyed> bdmurray: no, it said looks like a patch, and asked me.. but that page loaded for trillions of millions of seconds (~30 minutes or so). so in the meantime it was a patch probably.
[21:57] <bdmurray> okay and my script happened to catch it when it was flagged a patch
[21:57] <blueyed> your script subscribes reviewers then, too?
[21:57] <bdmurray> blueyed: yes
[21:58] <blueyed> wouldn't it be easier to search for bugs with a patch (which does not require a tag even)?
[21:58] <blueyed> but ok.. :)
[21:59] <bdmurray> blueyed: well the team is only be subscribed to 'recent' ones and then (in theory) we'll go back and look at older patch attachments
[21:59] <bdmurray> blueyed: the patch was originally only added due to a launchpad notification bug
[21:59] <bdmurray> s/patch/patch tag/
[22:00] <blueyed> I see. Thanks for explaining it.
[22:00] <bdmurray> yep, and I've unsubbed the team
[22:20] <mrmookie> anyone familiar with the following bug? https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/456806
[22:20] <ubot4> Launchpad bug 456806 in mountall (Ubuntu Karmic) (and 1 other project) "mountall vomits a shell onto virtual console when you run vi (affects: 25) (dups: 4)" [High,Fix committed]
[22:20] <mrmookie> it still is not fixed?
[22:21] <charlie-tca> fix committed says there is a fix someplace for it
[22:22] <charlie-tca> It looks to be fixed in lucid, and the fix is pending for karmic
[22:22] <micahg> seems like it was never pushed to -updates after verification
[22:23] <charlie-tca> failed verification on 9.10
[22:23] <mrmookie> lame
[22:23] <charlie-tca> see comment 6, fixed, but a user changed it
[22:26] <charlie-tca> mrmookie: did you try the patch they give?
[22:29] <mrmookie> charlie is that the debdiff?
[22:31] <Linux000> yes, the debdiff is the patch
[22:32] <mrmookie> what's the proper way to patch using the debdiff? I've not patched with one before
[22:34] <mrmookie> I'm pretty new to debian
[22:34] <Linux000> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Applying a Debdiff
[22:35] <mrmookie> thx
[22:41] <mrmookie> says it patched.. rebooting
[22:45] <mrmookie> no change.. :( can't use recovery console.. can't use vi.
[22:46] <mrmookie> "mountall: Cancelled General error mounting filesystems" is overwritten on top of the recovery console when I use the arrow keys
[22:47] <mrmookie> says CONTROL-D will terminate this sheel and re-try but it doesn't do anything
[22:47] <mrmookie> shell
[22:49] <mrmookie> this affects everyone who uses 9.10 server?
[22:57] <mrmookie> wow this is lame.. looks like I can kill mountall and vi works again
[22:58] <charlie-tca> I don't use vi, so it doesn't affect me
[22:58] <mrmookie> it's all editors
[22:58] <mrmookie> and recovery console
[22:58] <mrmookie> not just vi
[22:58] <charlie-tca> I have still never seen the issue
[22:59] <charlie-tca> I have run servers in 6.06, 7.10, 8.04, 8.10, and now in 9.10
[22:59] <mrmookie> strange.. you have a default fstab?
[22:59] <charlie-tca> yup
[23:01] <mrmookie> encrypted home directories?
[23:02] <charlie-tca> no
[23:02] <mrmookie> seems those who are affected are those with custom fstab and/or encrypted home dir's
[23:04] <mrmookie> I still get an error about mounting at boot up but at least now it's not writing over my editor
[23:21] <yofel> hm, anyone familiar with xulrunner?
[23:23] <yofel> (from #ubuntu+1): mediatom-common in lucid depends on libmozjs0d which was part of xulrunner 1.8, that doesn't exist in lucid anymore. In debian testing/unstable there is a libmozjs2d package as part of xulrunner-1.9.1, but that doesn't exist in ubuntus 1.9.1 -> huh?
[23:23] <yofel> the bug in mediatomb-common is clear
[23:23] <yofel> but xulrunner is confusing...


[00:14] <gsilvapt> Also, this error repeats itself in a build log: -- Could not set up the appstream test. appstreamcli is missing.
[00:14] <gsilvapt> What does it mean?
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kreversi build #99: FIXED in 1 hr 1 min: https://kci.pangea.pub/job/xenial_unstable_kreversi/99/
[01:29] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:29] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kreversi build #69: FIXED in 1 hr 1 min: https://kci.pangea.pub/job/artful_unstable_kreversi/69/
[01:30] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[01:30] -kubuntu-ci:#kubuntu-devel- Project zesty_unstable_kreversi build #64: FIXED in 1 hr 1 min: https://kci.pangea.pub/job/zesty_unstable_kreversi/64/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1643: SUCCESS in 1 min 1 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1643/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1643: SUCCESS in 1 min 6 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1643/
[08:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1643: SUCCESS in 3 min 53 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1643/
[09:18] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1643: SUCCESS in 33 min: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1643/
[10:03] <santa_> good morning everyone
[10:04] <santa_> so ... I have already replaced yesterday's gpul's server motherboard
[10:04] <santa_> that will enable me to expand the ram of this machine up to 32gb in the future
[10:05] <santa_> I'm also doing some maintenance changes now, so it will work without an SSD for memory swap (which is a bad thing)
[10:06] <santa_> so I will be able to use that SSD for my laptop to work better and faster \o/
[10:21] <tsimonq2> o/ santa_
[10:21] <tsimonq2> santa_: How've you been?
[10:22] <santa_> great
[10:23] <santa_> tsimonq2: I have been rebuilding frameworks 5.36 against qt 5.9 http://gpul.grupos.udc.es/buildstatus_ubuntu-exp3/ubuntu-exp3_status_frameworks.html
[10:23] <tsimonq2> Ok :)
[10:23] <santa_> I need you guys to sync everything to 5.9.1 and not just some packages
[10:24] <santa_> because that makes some autopkgtests fail
[10:24] <tsimonq2> Sure
[10:24] <santa_> once that's done I will re-schedule a rebuild of everything again
[11:04] <santa_> I'm going to be preparing for that ssd @ my laptop. I will be available on the phone as usual, cu later
[11:23] <BluesKaj> Hiyas all
[11:27] <tsimonq2> @Santa: Ack, sounds fun :)
[11:27] <tsimonq2> ALSO
[11:27] <tsimonq2> I figured out, FINALLY, how to run autopkgtests using the official infra if they're in a PPA: https://wiki.ubuntu.com/ProposedMigration/#Testing_against_a_PPA
[12:27] <tsimonq2> acheronuk, clivejo: Ping
[12:29] <tsimonq2> acheronuk, clivejo: I'd like to clean up https://merges.ubuntu.com/universe.html a bit and I have a couple of questions about some KDE 4 packages.
[12:31] <tsimonq2> acheronuk, clivejo: In fact, I'll prepare an email to kubuntu-devel for you guys.
[13:36] <clivejo> wow kdeconnect can reply to other apps too via the desktop!
[13:38]  * tsimonq2 nods
[13:39] <clivejo> whatsapp, telegram, hangouts
[13:39] <tsimonq2> clivejo: You're on whatsapp? omg omg omg
[13:39] <clivejo> now that is handy!
[13:41] <clivejo> yeah, family and friends use it :/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1644: SUCCESS in 1 min 0 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1644/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1644: SUCCESS in 1 min 18 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1644/
[14:48] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1644: SUCCESS in 3 min 43 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1644/
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-02 build #1644: SUCCESS in 4 min 9 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-02/1644/
 @tsimonq2, I have seen that link too, but we would need to automate it for all of our packages iirc. Also we would be harassing the ubuntu official infra, which sometimes is slow.
[22:17] <santa_> so I have the ssd pluged into the laptop now
[22:19] <santa_> the boot goes faster but I was expecting more improvement in that regard. I guess it's ok
[22:19] <santa_> so tomorrow I hope to cotinue with more kubuntu stuff
[22:19] <santa_> gn everyone


[02:14] <lotuspsychje> good morning
[10:54] <cartdrige> Hey.
[10:54] <cartdrige> Is Wayland the default on the last Ubuntu version?
[10:56] <oerheks> yes
[10:56] <oerheks> but xorg session is also available from login screen
[22:29] <sarnold> https://twitter.com/popey/status/1590736097604149253?cxt=HHwWioCx0a-Dt5MsAAAA  :(
[22:58] <ravage> he will be fine
[23:02] <sarnold> yes, probably. but it's still not fun.
[23:35] <Gameboy> Hello
[23:36] <sarnold> hey


[08:12] <ricotz> good morning desktopers :)
[08:13] <ricotz> seb128, hi, https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+sourcepub/14443372/+listing-archive-extra
[08:13] <seb128> goood morning desktopers!
[08:14] <seb128> hey ricotz, thanks, I noticed the new version thanks to the snap auto updates :)
[08:15] <ricotz> seb128, there were some more changes required to adjust for the new comm-l10n repository
[08:15] <ricotz> https://paste.debian.net/plain/1267501
[08:15] <seb128> ricotz, ok, I will review the debdiff ... do you have a vcs for your changes?
[08:17] <ricotz> seb128, I could push them directly to the packaging repo
[08:18] <ricotz> I kept the changes minimal so there is likely room for improvement
[08:20] <seb128> ricotz, feel free to push to the vcs if you want otherwise I will do that later
[12:10] <GunnarHj> On a freshly installed and updated lunar in VirtualBox it doesn't let me log in to Ubuntu on Xorg. I'm just bumped back to the login screen.
[12:10] <GunnarHj> On my regular (updated) lunar install, logging in to Ubuntu on Xorg works fine. But that's anything but a fresh install.
[12:10] <GunnarHj> Missing dependency?
[12:11] <seb128> GunnarHj, hey, unsure, do you have a journal log?
[12:12] <GunnarHj> seb128: Well, not easily available since it's VirtualBox. Not sure how I best could show it...
[12:14] <seb128> GunnarHj, well if it go back to the login screen and you can log into a wayland session you can do journalctl | pastebin from there
[12:15] <GunnarHj> Will try that.
[12:29] <GunnarHj> seb128: https://pastebin.ubuntu.com/p/9NhtrH9qGG/
[12:34] <seb128> GunnarHj, thx, unsure why it's exiting from the log but maybe Trevinho or jbicha have a clue there
[12:52] <seb128> hum, thunderbird on arm fails to build due to DEBUG: llvm_objdump: Looking for llvm-objdump :/
[12:55] <seb128> ricotz, the create-tarball.py update is following upstream vcs changes right? which means technically we should do the same to stable series?
[13:00] <ricotz> seb128, yes, create-tarball.py should be kept in sync in all thunderbird stable repos
[13:00] <seb128> ricotz, thanks
[13:01] <seb128> ricotz, also any reason to not move those repository to git? do you know why Olivier did do it?
[13:02] <ricotz> not sure, maybe there was some trouble with the export/import scripts
[13:02] <ricotz> preserving the history seems not trivial with all the branches
[13:06] <seb128> ricotz, those are debian/ dir only vcs-es so I would expect it to be not too complicated, I will give it a try :)
[13:39] <ricotz> seb128, ok :)
[13:55] <bandali> good morning
[13:56] <bandali> hey ricotz, so i followed your lto-related rules.mk change from firefox-beta.bionic in firefox.bionic as well, but it seems that for some reason the rule is being invoked twice:
[13:56] <bandali> https://launchpadlibrarian.net/646393129/buildlog_ubuntu-bionic-i386.firefox_109.0+build2-0ubuntu<IP_ADDRESS>_BUILDING.txt.gz
[13:56] <bandali> and we apparently end up with multiple 'lto = "thin"' which is seemingly problematic
[13:58] <bandali> i'm not super familiar with all of those make targets, but i'll investigate a bit, and either make that sed invocation more robust so it doesn't add a duplicate, or try reverting that bit from 'pre-build' back into 'debian/stamp-mach-configure' and see if it helps
[13:58] <ricotz> bandali, hi, this some race condition which already happened without the syncing this change with focal
[13:58] <ricotz> bandali, re-try the build please
[14:00] <bandali> ricotz, ah ok i see :) thanks, sure i'll retry it
[14:00] <bandali> but yeah it might be worth making that sed invocation look ahead and make sure there's no lto = "thin" in that section already before it adds another one
[14:04] <ricotz> bandali, there is already a "stamp" file (Cargo.toml.bak) as guard, seems the i386 builders are way faster while this doesn't happen on arm64/armhf
[14:22] <dob1> hi, I am using i3 as my wm and I have problem with firefox: for example when I upload a photo to gmail and I want to see it it gives me the option to use "System handler" or download it,  the problem is that "System handler" fails, it does nothing and I have to download the photo to see it.  The same for pdf.... I am sure that on gnome this works but I am not using gnome
[14:23] <dob1> even if I set a specific command to handle photo or pdf it doesn't work because it can't access to them
[14:24] <dob1> I had no problems with the no-snap version of fireforx when it was available
[14:54] <bandali> ricotz, hmm i see
[14:55] <bandali> hi dob1, just to confirm, do you use i3 from ubuntu's repos? and do you log into it via gnome's display manager gdm (i.e. login screen)?
[14:55] <dob1> bandali: yes
[14:56] <bandali> dob1, i see, thanks for confirming. i haven't tried the firefox snap outside the gnome desktop, but i've been meaning to install i3 on this machine and try it. i'll see if i can reproduce the issue
[14:57] <dob1> bandali: if you have an email on gmail with a pdf try to see it not with gmail preview or firefox preview but with system hanlder, or  create a draft upload a photo and try to view it in the draft, it gives the option for system handler and it fails
[14:58] <bandali> dob1, right. i don't really use gmail, so i'll probably have to try with another upload/download site, but if absolutely necessary, i should be able to try on gmail too
[14:59] <bandali> but taking a guess, i believe the firefox snap uses the xdg-desktop-portal to communicate with the outside world for the most part, and perhaps your i3 environment doesn't have that process running
[14:59] <ogra> IIRC the "system handler" should just make it call "xdg-open /path/t👋file" ... have you tried running that manually for a file type you see issues with ?
[14:59] <ogra> tsk ... silly emoji plugin
[15:00] <ogra> i.e. does it open the file with the default app for that mime type ?
[15:02] <dob1> if I run firefox on console and I try to view a pdf via system handler I get  env: ‘/snap/bin/firefox’: Permission denied
[15:02] <ogra> not what i asked 🙂
[15:03] <ogra> xdg-open /fo👋bar/mydoc.pdf ... does that open your default pdf viewer with the file you gave it
[15:03] <dob1> /path/to/file what is in my case?  I didn't have download the file
[15:03] <ogra> download a file then 🙂
[15:03] <dob1> ah ok! sorry now it's clear
[15:03] <ogra> it is to test if the expected mechanics outside of firefox work at all
[15:04] <dob1> it works
[15:04] <dob1> it open it
[15:04] <ogra> good, so that bit at last works ...
[15:04] <ogra> so the issue must be between FF and xdg-open ... do you have the xdg-desktop-portal* packges installed ?
[15:05] <ogra> they should handle that communication bit on a desktop level
[15:05] <ogra> though not sure if that can work with just plain window manager witout proper session mgmt
[15:06] <dob1> yes
[15:07] <dob1> this is what I have https://termbin.com/srz14
[15:09] <ogra> yeah, i guess the session management is the issue here ...
[15:10] <dob1> I would like to understand where firefox store the file, if it store it somewhere or it's in ram, when I use system handler.  and then use xdg-open file to that file
[15:12] <ogra> it ands it t the portal ... and IIRC that stores it somewere in a privat area of /tmp or so
[15:12] <ogra> *hands it
[15:12] <dob1> no /tmp
[15:13] <dob1> on /tmp there are few dirs owned by my user so I don't consider them
[15:15] <dob1> imho it cannot store the file (hence the permission errror) so it cannot open it
[15:17] <ogra> ah, it seems to not be /tmp but XDG_RUNTIME_DIR (i.e. /run/user/$UID/)
[15:18] <dob1> I found the file there and xdg-open can open it
[15:19] <ogra> right, proves my point from above ... communicaion error wih the session mgmt somewhere
[15:20] <nteodosio> I use dwm and `. /etc/X11/Xsession.d/*dbus*` solves many of these kind of problems.
[15:20] <ogra> ah, sourcing the dbus address ?
[15:20] <nteodosio> Though you mention that you start i3 via GDM, I'd bet it would do it for you
[15:21] <ogra> it should ... theoretically ... but there might also be logind involved and whanot
[15:21] <dob1> no it's the same
[15:22] <dob1> source if from a terminale, launched firefox from the same terminale and still this     env: ‘/snap/bin/firefox’: Permission denied
[15:22] <dob1> no infos about this "permission denied"
[15:24] <ogra> run journalctl -f alongside and reproduce it ... see if there are any denials/errors
[15:26] <dob1> ok more infos https://dpaste.org/qr0nV
[15:26] <dob1> it still doesn't explain
[15:27] <dob1> (at least to me)
[15:27] <ogra> looks like gdm actually tries to exec firefox for some reason ... not sure that should run through gdm at all
[15:28] <dob1> I have no clue
[15:28] <ogra> file a bug and attach that info ...
[15:28] <dob1> or at least what change on gnome when you do the same operation
[15:28] <dob1> where to file it? ubuntu bug?
[15:29] <ogra> well, in gnome gdm hands over authority to gnome-shell i think
[15:29] <ogra> yeah, start with "ubuntu-bug firefox" i should DTRT (it at least does on gnome 😛 )
[15:29] <dob1> DTRT stands for?
[15:30] <ogra> do the right thing ...
[15:32] <ogra> *it should ... btw my keyboard is solwly giving up
[15:33] <dob1> here https://bugs.launchpad.net/ubuntu  ?
[15:33] <ogra> "ubuntu-bug firefox" ... run that in a terminal
[15:34] <dob1> it says I can'ut use it
[15:34] <dob1> because it is published by mozilla (I am translating)
[15:34] <ogra> it should give you a url
[15:34] <dob1> https://support.mozilla.org/it/kb/segnalare-bug-richiedere-funzionalita
[15:35] <dob1> it's not the right place on mozilla imho
[15:35] <bandali> yeah i think we currently ask that people file firefox snap bugs against mozilla, on bugzilla.mozilla.org
[15:35] <ogra>  right, but we usually provide the correct URL to do that
[15:36] <dob1> so it's mozilla where to file the bug for this?
[15:36] <bandali> unfortunately it seems 'ubuntu-bug firefox' doesn't do that when choosing the snap package for the affected package, it directs people o the above mozill akb page
[15:37] <ogra> well, and thats a 404 here on my german install UGH !
[15:37] <bandali> dob1, https://bugzilla.mozilla.org
[15:38] <ogra> oh, LOVELY ! there is a dot at the end of the line here for me ... which indeed ends up as part of the url if i click it
[15:38] <ogra> sigh
[15:38] <ogra> https://support.mozilla.org/de/kb/file-bug-report-or-feature-request-mozilla.
[15:38] <ogra> this is what i get when clicking what apport gives me ...
[15:39]  * ogra wonders if thats an apport or mozilla bug now ...
[15:39] <bandali> the ubuntu bug tracker for firefox is at https://bugs.launchpad.net/ubuntu/+source/firefox/+bugs?orderby=-id&start=0 and you can report a bug from https://bugs.launchpad.net/ubuntu/+source/firefox/+filebug but i think you should report the bug to mozilla's bugzilla i linked above
[15:39] <bandali> ogra, right :p i was gonna ask if you know whether that string/dialog is coming from
[15:39] <ogra> haha, i wish i did
[15:40] <dob1> ok I will file it on bugzilla
[15:40] <bandali> dob1, thanks :) feel free to drop a link to it here as well
[15:40] <dob1> I will do later when I am home
[15:41] <bandali> ty
[15:41] <bandali> *thank you
[15:49] <bandali> fwiw the message is indeed coming from apport https://git.launchpad.net/ubuntu/+source/apport/tree/apport/ui.py?h=ubuntu/lunar#n1580 and looks fine in english, so i would guess it's the particular translation that's problematic
[16:06] <ogra> bandali, yeah
[16:07] <ogra> (and thanks for looking it up)
[16:11] <ogra> hmm, though the string "snap["contact"]" comes from somewhere else
[16:13] <ogra> (seemingly something somewhere calls "snap info firefox" and grabs the "contact:" string from there ... but thats also untranslated if i manually call snap info ...)
[16:14] <KGB-0> gnome-shell signed tags 46d755f Jeremy Bicha ubuntu/43.2-1ubuntu1 * gnome-shell Debian release 43.2-1ubuntu1 * https://deb.li/31nHd
[16:14] <KGB-2> gnome-shell ubuntu/master a0cdd83 Jeremy Bicha * pushed 39 commits (first 5 follow) * https://deb.li/3pApF
[16:14] <KGB-2> gnome-shell ubuntu/master 250b730 Florian Müllner js/ui/overview.js * overview: Don't block on wayland popovers * https://deb.li/7NKi
[16:15] <KGB-2> gnome-shell ubuntu/master 0149558 Alessandro Bono js/ui/overviewControls.js * overviewControls: Group prepare to enter/leave overview code * https://deb.li/3rlah
[16:15] <KGB-2> gnome-shell ubuntu/master dab3632 Alessandro Bono js/ui/ overview.js overviewControls.js * overview: Make preparation to enter/leave overview explicit * https://deb.li/ij2b1
[16:15] <KGB-2> gnome-shell ubuntu/master 000c678 Alessandro Bono js/ui/overview.js * overview: Start animation after setting coverPane initial state * https://deb.li/xbNe
[16:15] <KGB-2> gnome-shell ubuntu/master 3d638cb Jonas Ådahl js/perf/basic.js * perf/basic: Toggle quick settings instead of old menu * https://deb.li/3lnE0
[16:15]  * ogra wishes olivier was sill here 😞
[16:16] <ogra> *still
[16:17] <nteodosio> Yes
[16:17] <nteodosio> ogra, that's Apport
[16:18] <nteodosio> https://github.com/canonical/apport/blob/75540cb0f665e50495d994b529c8418a1ebca178/apport/report.py#L449
[16:18] <nteodosio> Ah Amin had already answered that :p
[16:20] <ogra> right, i just dont know where that string lives .... i see the code that processes it
[16:25] <nteodosio> ogra, ah, OK, pretty sure it's https://github.com/canonical/apport/blob/f0386909272207593f1baa5fee900ac387ca04fa/apport/fileutils.py#L184
[16:25] <ogra> oh ! a direct store query !
[16:26] <ogra> but i think that is still untranslated ... hmm
[16:26] <bandali> how about https://translations.launchpad.net/apport/main/+pots/apport/de/68/+translate
[16:27]  * ogra hugs bandali
[16:27] <ogra> you'Re a hero !
[16:27] <bandali> =) you're too kind ogra :p
[16:28] <bandali> hmm, so, looking at that translation, i'm guessing whatever code is linkifying URLs is buggy and inclues that period right after the %s ?
[16:28] <ogra> well, credit where credit is due 🙂
[16:29] <ogra> right, the dot needs to be dropped
[16:29] <bandali> right
[16:29] <nteodosio> The terminal emulator is at fault for making URLs clickable. Use Xterm. :P
[16:30] <ogra> well, it is actually a GTK popup window ...
[16:30] <KGB-2> gnome-remote-desktop signed tags 965912c Jeremy Bicha upstream/43.3 * Upstream version 43.3 * https://deb.li/ilbFx
[16:30] <ogra> (try yourself "ubuntu-bug firefox")
[16:30] <KGB-2> gnome-remote-desktop upstream/latest 0984992 Olga Smirnova po/ LINGUAS ie.po * Add Interlingue translation * https://deb.li/3xzPC
[16:30] <KGB-2> gnome-remote-desktop upstream/latest e17336c Nathan Follens po/nl.po * Update Dutch translation * https://deb.li/bEOh
[16:30] <KGB-2> gnome-remote-desktop upstream/latest aab4317 Jonas Ådahl meson.build * build: Bump version to 43.3 * https://deb.li/39Amc
[16:31] <KGB-2> gnome-remote-desktop upstream/latest 8086b28 Jeremy Bicha meson.build po/LINGUAS po/nl.po po/ie.po * New upstream version 43.3 * https://deb.li/3CQJd
[16:31] <KGB-2> gnome-remote-desktop pristine-tar a27d840 Jeremy Bicha gnome-remote-desktop_43.3.orig.tar.xz.delta gnome-remote-desktop_43.3.orig.tar.xz.id * pristine-tar data for gnome-remote-desktop_43.3.orig.tar.xz * https://deb.li/s6KF
[16:34] <ogra> LOL
[16:34] <ogra> okay ... so sad ... but the bug is already reported and a fix was applied ... sadly rejected because the bug # was not mentioned in the changelog
[16:34]  * ogra head -> wall
[16:34] <ogra> https://bugs.launchpad.net/apport/+bug/1978301
[16:34] -ubottu:#ubuntu-desktop- Launchpad bug 1978301 in apport (Ubuntu Jammy) "Broken contact URL in German translation" [Undecided, Confirmed]
[16:37] <ogra> https://github.com/canonical/apport/commit/e0a90520b84d8c46b1474fb3c9421d72e3a99960
[16:37] -ubottu:#ubuntu-desktop- Commit e0a9052 in canonical/apport "apport-gtk: Exclude trailing dot from URL links"
[16:37] <ogra> heh, even a code fix, not just dropping the dot from the translation
[16:39] <bandali> ah
[16:40] <ogra> not sure if bdrung plans to re-submit it though
[16:54] <bdrung> ogra, on 2022-12-15 I uploaded apport 2.20.11-0ubuntu82.4 to jammy to fix this bug. It is waiting in the unapproved queue.
[17:01] <ogra> bdrung, awesome ! thx !
[19:42] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 06f2352 Jeremy Bicha * pushed 15 commits (first 5 follow) * https://deb.li/3QDTV
[19:42] <KGB-0> gnome-shell-extension-desktop-icons-ng pristine-tar 48809ed Jeremy Bicha gnome-shell-extension-desktop-icons-ng_46+really47.0.2.orig.tar.bz2.delta gnome-shell-extension-desktop-icons-ng_46+really47.0.2.orig.tar.bz2.id * https://deb.li/1xY1
[19:42] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 40aeca6 Sergio Costas HISTORY.md metadata.json * Removed "session-modes" * https://deb.li/fJRs
[19:42] <KGB-0> pristine-tar data for gnome-shell-extension-desktop-icons-ng_46+really47.0.2.orig.tar.bz2
[19:43] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 98fb585 Sergio Costas desktopManager.js * Fix incorrect call * https://deb.li/3Yu6U
[19:43] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 0169c70 Sergio Costas createThumbnail.js * Fixed thumbnail generation when using external program * https://deb.li/348vn
[19:43] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 8047a4c Sergio Costas extension.js * Fixed bug * https://deb.li/iWxt7
[19:43] <KGB-2> gnome-shell-extension-desktop-icons-ng upstream/latest 863544f Sergio Costas fileItemMenu.js * Fixed another bug * https://deb.li/iMrd
[19:43] <KGB-0> mozjs signed tags 854b79b Jeremy Bicha upstream/102.7.0 * Upstream version 102.7.0 * https://deb.li/3VJON
[19:43] <KGB-2> mozjs upstream/102 b06f1f1 Jeremy Bicha config/milestone.txt js/src/devtools/automation/autospider.py mozglue/build/TsanOptions.cpp * New upstream version 102.7.0 * https://deb.li/DJfc
[19:43] <KGB-0> mozjs pristine-tar ec700b5 Jeremy Bicha mozjs102_102.7.0.orig.tar.xz.delta mozjs102_102.7.0.orig.tar.xz.id * pristine-tar data for mozjs102_102.7.0.orig.tar.xz * https://deb.li/3RM3y