[00:34] <lifeless> I wonder
[00:34] <lifeless> are implicitly created accounts subject to the name blacklist ?
[00:42] <cjwatson> How long does qastaging take to update after a buildbot run finishes?
[00:42] <wgrant> 40ish minutes
[00:42] <wgrant> Let's see how it's going.
[00:43] <wgrant> Bah
[00:43] <wgrant> buildbot poller missed it.
[00:43] <wgrant> So it won't start for another 5 minutes.
[00:44] <wgrant> And it will take 30 minutes to update.
[00:44] <cjwatson> OK, I can probably get some QA done tonight then
[00:45] <wgrant> What do you have that's QAable on qastaging?
[00:45] <cjwatson> It's pretty much all dogfood, but it's easier to wait for qastaging so that the deployment report is up to date ...
[00:46] <wgrant> Heh
[00:46] <wgrant> That's what I thought.
[00:46] <lifeless> gmb: https://bugs.launchpad.net/launchpad/+bug/484712
[00:46] <_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/484712 >
[00:46] <lifeless> gmb: would like feedback/status update (if only to unassign yourself and say that it hasn't been tested...)
[00:48] <cjwatson> wgrant: Speaking of which; can I commandeer mawson in a bit, after I'm done with a couple of chores?  You seem to be the only other person logged in.
[00:48] <wgrant> cjwatson: Sure, I'm just abusing its database.
[00:48] <wgrant> Nothing that should affect you.
[00:49] <cjwatson> That won't get clobbered by a code update?
[00:49] <wgrant> No.
[00:49] <cjwatson> Oh, of course, NDT means obviously not
[01:04] <wgrant> Query count test failures are a little painful now...
[01:04] <wgrant> They include full tracebacks :)
[01:25] <lifeless> heh, bad linkificaition on https://bugs.launchpad.net/launchpad/+bug/499438
[01:26] <_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
[01:27] <lifeless> cjwatson: what do you think the reaction would be to disabling anonymous ftp uploads ?
[01:29] <cjwatson> Hard to say
[01:30] <cjwatson> from a quick look at cocoplum:~lp_queue/ubuntu-queue/, it looks as though the bulk of our uploads are FTP right now
[01:30] <lifeless> yes, I would expect that
[01:30] <cjwatson> lp_archive@cocoplum:~$ grep --count upload-ftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
[01:30] <cjwatson> 68268
[01:30] <cjwatson> ^- unscientific check
[01:30] <cjwatson> lp_archive@cocoplum:~$ grep --count upload-sftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
[01:30] <lifeless> the reason to suggest this is that a lot of the UI poorness around uploads is coupled to depending on good package metadata (including signatures) for error notifications
[01:30] <cjwatson> 4789
[01:31] <cjwatson> perhaps we should find out why most people aren't using sftp uploads first
[01:31] <lifeless> if we knew that 'user foo' did the upload, we could always notify use foo, regardless of the package metadata status
[01:31] <wgrant> SFTP provides no progress information.
[01:31] <wgrant> And client support in Ubuntu is recent.
[01:31] <cjwatson> our current dput.cf defaults to FTP
[01:31] <cjwatson> I don't think it's reasonable to disable it in LP until and unless that's changed, at the very least, including in stable releases
[01:31] <lifeless> I think we should simplify our upload processing code for SFTP
[01:32] <lifeless> and then get Ubuntu to change (or try changing) to SFTP
[01:32] <cjwatson> wgrant: in principle SFTP supports progress information
[01:32] <cjwatson> wgrant: what makes you say that?
[01:33] <wgrant> cjwatson: The current client does not.
[01:33] <cjwatson> YM dput?
[01:33] <wgrant> The vast majority of current uploads, both PPA and Ubuntu, are FTP
[01:33] <wgrant> Yes.
[01:34] <wgrant> I'm not sure the default dput.cf even has an SFTP PPA section.
[01:34] <wgrant> Because it requires configuration.
[01:34] <wgrant> (we rely on username matching, not just key)
[01:36] <cjwatson> oh, and Debian's dput doesn't have SFTP support yet
[01:36] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505173
[01:36] <lifeless> does that matter particularly?
[01:37] <cjwatson> it's another data point, and I'm sure it affects some percentage of users
[01:37] <wgrant> It would be pretty unpleasant to make it impossible to upload to PPAs except from Ubuntu.
[01:37] <wgrant> People do use Debian, you know :)
[01:38] <lifeless> wgrant: it wouldn't be impossible: lftp etc can do it, and folk can apply the patch
[01:38] <lifeless> https://bugs.launchpad.net/launchpad/+bug/499438 is what sparked these questions
[01:38] <_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
[01:39] <lifeless> cjwatson: whats the right way forward to get Ubuntu to promote SFTP for uploads - I'm primarily concerned with new PPA users, the set of folk most likely to make packaging fubars anyhow
[01:39] <cjwatson> I doubt I'm capable of thinking of a problem that complex at 1:40
[01:39] <cjwatson> am
[01:39] <lifeless> fair enough
[01:40] <lifeless> I will probably raise it again
[01:40] <wgrant> lifeless: Initial config is the difficult bit.
[01:40] <cjwatson> right
[01:40] <wgrant> We can't provide a default config, so we have to tell people to edit their dput.cf
[01:40] <wgrant> Like we did 4 years ago :/
[01:40] <lifeless> or get credentials from lptools, which we use for a bunch of other things too
[01:40] <cjwatson> unless we're very careful, all we achieve is rearranging the deckchairs on the UI.
[01:41] <wgrant> lifeless: lptools?
[01:41] <cjwatson> lptools, which ~nobody has installed
[01:41] <StevenK> bzr launchpad-login ?
[01:41] <wgrant> Exactly.
[01:41] <wgrant> Nobody uses lptools.;
[01:41] <lifeless> cjwatson: thats true, OTOH deckchairs the user can see are easier to examine than ones they cannot :)
[01:41] <lifeless> didn't a bunch of ubuntu-dev-tools get shuffled over to lptools ?
[01:41] <lifeless> I was fairly sure they did, during the last cycle
[01:42] <cjwatson> ubuntu-dev-tools declares no package relationships on lptools
[01:42] <cjwatson> so if they did, it was shuffled out of sight
[01:42] <StevenK> lifeless: All I can see that is doing is having more people ask "Why can't I just upload using dput?"
[01:42] <lifeless> yeah, I can see
[01:42] <lifeless> could use ubuntu-dev-tools
[01:42] <wgrant> Other sites seem to rely on uniqueness of SSH keys.
[01:42] <lifeless> StevenK: a) experienced folk can, b) new folk follow docs on the wiki, and *then* also mess up
[01:43] <cjwatson> It's true that a few tools were moved, but they were the sorts of things only pretty LP-aware people used anyway
[01:43] <cjwatson> lp-get-branches, lp-grab-attachments, lp-project-upload, lp-list-bugs, lp-set-dup, lp-shell
[01:43] <lifeless> you didn't want to reason about this at 1:40am
[01:43] <lifeless> so don't :)
[01:43] <cjwatson> you asked me to come up with a solution :)
[01:43] <cjwatson> picking holes is easier ;)
[01:44] <lifeless> heh
[01:44] <wgrant> cjwatson: qastaging update finished 4 minutes ago, btw.
[01:44] <cjwatson> thanks.  upgrading mawson
[01:44] <lifeless> so, as long as we never need to go spelunking on germanium again to determine what went wrong, I will accept nearly any hole you care to poke
[01:44] <lifeless> I think pushing it back onto the users machine where they can locally diagnose and get up-front errors is a good thing
[01:45] <cjwatson> I wonder if there's any way to push errors over the FTP session
[01:45] <wgrant> There is.
[01:45] <wgrant> We do it already.
[01:45] <StevenK> Which we don't do for SFTP
[01:45] <wgrant> But lifeless knows that well, so I assume he a reason to ignore it.
[01:45] <wgrant> +has
[01:45] <lifeless> it has limits, and we will happily email the wrong person if the package is a plain copy from e.g. Debian
[01:46] <lifeless> one of the limits is that core twisted tries very hard to turn such events into OOPSes
[01:46] <lifeless> (oh no something went wrong, must alert the admin)
[01:46] <lifeless> thats probably fixable, but even then we still can't notify *anyone else* that the problem occured.
[01:47] <lifeless> e.g. via upload subscriptions
[01:47] <cjwatson> I agree in principle that SFTP is a good thing to use; the road to making it mandatory probably isn't short though.
[01:47] <cjwatson> I guess that's all I'm really saying
[01:47] <lifeless> making it the default for new users would go a long way
[01:47] <cjwatson> Yes
[01:47] <lifeless> we could just say 'try over sftp' to any experienced user with an undiagnosable problem
[01:47] <lifeless> e.g. deprecate but not disable ftp
[01:48] <cjwatson> Or if we can't figure out the user's LP login, fall back to FTP
[01:48] <wgrant> The experienced users aren't going to have trouble :)
[01:48] <cjwatson> You'd still win if we reduced the incidence of spelunking significantly
[01:48] <cjwatson> Just not as much
[01:48] <lifeless> mmm, I'd like something more aggressive than 'if we can't figure it out'
[01:48] <lifeless> e.g. opt-in to ftp
[01:48] <cjwatson> "What's your LP login?  Type 'lifeless' to use FTP"
[01:49] <lifeless> (remember too that we have folk dealing with private packages etc, so the default really wants to be non plaintext
[01:49] <lifeless> cjwatson: :)
[01:49] <lifeless> cjwatson: put that in for april 1st please
[01:49] <cjwatson> I have a better April 1st way ahead of that, which I've been failing to implement for five years :)
[01:50] <cjwatson> Actually, seriously, interactivity wouldn't be awful
[01:50] <lifeless> poor andi
[01:50] <lifeless> still confused by LP's UI.
[01:50] <wgrant> Again?
[01:50] <cjwatson> just have /usr/share/dput/sftp.py ask you and save the answer somewhere
[01:50] <lifeless> 3 imports one project
[01:50] <lifeless> cjwatson: +1
[01:50] <cjwatson> enhancement: figure it out automatically without asking.  but that's nice-to-have.
[01:51] <cjwatson> (I'm assuming sftp.py gets a terminal.)
[01:51] <cjwatson> And then have sftp.py fall back internally to FTP on abject failure.
[01:51] <cjwatson> (With loud warnings.)
[01:51] <StevenK> mwhudson was talking about anonymous-ssh, so we could utilise that too ...
[01:51] <lifeless> StevenK: not useful here
[01:51] <cjwatson> Let me not attempt to figure out the confidentiality properties of anonymous SSH
[01:52] <lifeless> StevenK: the point is knowing the user so we can notify sensibly
[01:52] <StevenK> cjwatson: Or fall back to trying $USER ?
[01:52] <lifeless> StevenK: fixes a raft of corner cases that we have today, anonymous-ssh wouldn't do that
[01:52] <cjwatson> StevenK: *handwave* that kind of thing
[01:52] <cjwatson> I wonder what the performance difference is for large uploads over SFTP vs. FTP
[01:53] <StevenK> lifeless: SFTP for uploads still doesn't solve notifications for syncs ...
[01:53] <lifeless> cjwatson: SFTP should be faster (tcp window already open)
[01:53] <cjwatson> Syncs will all be API soon enough, so you'll at least have a username
[01:53] <cjwatson> lifeless: haha my bugmail disagreed last I checked
[01:53] <lifeless> indeed, and *I'm not talking about syncs* :P
[01:54] <lifeless> failing to fix problem B doesn't make a solution to problem A better or worse
[01:54] <lifeless> having a single solution to A and B is nice, of course.
[01:54] <cjwatson> (the HPN people talk about FTP as a comparator for their none-cipher work)
[01:55] <lifeless> but you need to demonstrate a link between them for it to be worth considering - whats the link between syncs, where we know all the package data is intact, and uploads, where its all arbitrary
[01:55] <cjwatson> comparand.  blah.  I keep getting that wrong.
[01:55] <lifeless> cjwatson: interesting
[01:55] <cjwatson> Ur, help.  What does http://paste.ubuntu.com/792323/ mean when upgrading dogfood?
[01:55] <lifeless> you keep both pieces?
[01:56] <lifeless> the dogfood config has old and deleted config keys
[01:56] <StevenK> Haha
[01:56] <wgrant> Ah, yes, let me fix that.
[01:56] <StevenK> Yeah, wgrant broke it
[01:57] <wgrant> I don't think it's the DF config that's broken. It's just that the prod configs are out of date.
[01:58] <wgrant> cjwatson: Should be fixed.
[02:01] <cjwatson> wgrant: Thanks; should I carry on with the build or did you do that?
[02:02] <wgrant> cjwatson: I didn't touch it.
[02:02] <wgrant> Come on, do you think it can build that quickly? :)
[02:02] <cjwatson> Heh
[02:04] <mwhudson> inferring username from ssh key is technically easy i guess
[02:04] <mwhudson> and that UNIQUE constraint on sshkey would have been interesting a few years back :-)
[02:04] <wgrant> Now that there's more than just a few keys, yeah...
[02:05] <cjwatson> I thought that's why we added the UNIQUE constraint
[02:05] <wgrant> There isn't one, AFAIK.
[02:05] <wgrant> Indeed not.
[02:06] <cjwatson> Adding one might not be a terrible idea.
[02:07] <wgrant> There is one key with 19 links, another with 20...
[02:07] <wgrant> 650ish with 2 links, 40 with more than 2
[02:10] <cjwatson> :-(
[02:10] <cjwatson> That doesn't block lifeless' project though; we have the username to work with, not just the key
[02:10] <wgrant> Yeah
[02:13] <micahg> lifeless: also, about owners and notifications, some people want to be owners to just administer and not have rights
[02:14] <lifeless> micahg: yes, thats why we have separate roles, though wgrant is campaiging that this doesn't make sense
[02:14] <wgrant> lifeless: No.
[02:15] <wgrant> lifeless: I'm campaigning that the owner special case doesn't make sense.
[02:15] <wgrant> I am campaigning that admin+membership should be separated.
[02:15] <wgrant> Currently you have a list of members, and a list of admins who are members, and a single not-quite-admin-but-not-member.
[02:16] <wgrant> When a list of members and a list of admins who may also be members would work fine.
[02:16] <lifeless> with the recent change to admins promoting admins, hmm
[02:16] <lifeless> perhaps
[02:18] <micahg> that would solve the DMB use case as well
[02:18] <wgrant> Yup.
[02:20] <wgrant> Morning jtv.
[02:20] <jtv> hi there wgrant, happy 2012
[02:21] <wgrant> Likewise.
[02:21] <jtv> thank you
[02:27] <wgrant> lifeless: So, how do you propose to find transitive dependencies without a resolver? :)
[02:29] <lifeless> wgrant: I thought you meant something different apparently
[02:36] <lifeless> jtv:  https://bugs.launchpad.net/launchpad/+bug/506497 - is that more done now?
[02:36] <_mup_> Bug #506497: import-queue-gardener gives file path a higher priority than a manually assigned template <import-queue> <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506497 >
[02:36] <lifeless> jtv: also would like your input on https://bugs.launchpad.net/launchpad/+bug/506516
[02:36] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
[02:37] <jtv> lifeless: probably not done, but I'm not even sure those tools still work.
[02:37] <lifeless> jtv: should I invalid it? or incomplete?
[02:39] <jtv> lifeless: incomplete.
[02:41] <micahg> lifeless: what would you think of marking bug 529957 invalid since we build translation packages out of the Firefox/Thunderbird sources now?
[02:41] <_mup_> Bug #529957: XPIPO file uploads should be disabled <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/529957 >
[02:42] <lifeless> micahg: have we ditched the XPIPO support?
[02:42] <lifeless> micahg: should we drop it?
[02:43] <lifeless> micahg: (also does that mean thunderbird is not translatable in Ubuntu using LP?)
[02:43] <micahg> lifeless: I should check with chrisccoulson first, but I think so, at least once the Firefox migration in lucid/maverick is complete which should be some time this month
[02:43] <micahg> lifeless: thunderbird actually never was IIRC
[02:43] <lifeless> so I don't think we should invalidate the bug while we have the code it talks about around
[02:43] <lifeless> but we could change it to be 'this code can be deleted'
[02:45] <micahg> well, I guess one day if we ever get a way to push translations back upstream, we could import from the source uploads and push changes upstream, but I guess in that scenario, we don't need the xpipo code either
[02:54]  * StevenK stabs the screwed up security model SPRBs use.
[03:06] <lifeless> jtv: so, thoughts on bug https://bugs.launchpad.net/launchpad/+bug/509109 and https://bugs.launchpad.net/launchpad/+bug/506516 ?
[03:06] <_mup_> Bug #509109: Deadlock in message-sharing-merge while migrating brasero <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/509109 >
[03:06] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
[03:07] <jtv> “If they're really a problem, they'll come back.”
[03:07] <lifeless> jtv: they were both migration stuff; thats done, right ?
[03:08] <jtv> Yes, though the code may still be in use.
[03:08] <lifeless> ah
[03:08] <lifeless> the question is, should the maintenance squad sit down and work on them ?
[03:10] <jtv> Not based on these reports, no.  I'd just close them.
[03:11] <jtv> Too much has changed since those bugs were reported.  If they're really a problem, they'll come back.
[03:12] <lifeless> thanks, done.
[03:13] <lifeless> hmm, something is seriously odd with multi-project -importance bug sort order
[03:18]  * StevenK stabs diff generation and/or longpoll
[03:20] <lifeless> I wonder that noone has hacked https://bugs.launchpad.net/launchpad-buildd/+bug/516208 into the thing already
[03:20] <_mup_> Bug #516208: disable Automake's silent rules <feature> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/516208 >
[03:26] <cjwatson> Right, mawson is all ... whoever-cares' again.
[03:27] <StevenK> cjwatson: Did you QA mvo's rev, or is that his to do?
[03:28] <StevenK> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.
[03:28] <StevenK> Blink
[03:28] <cjwatson> StevenK: I did his
[03:28] <cjwatson> So it's just jelmer's recipe format thing left
[03:28] <StevenK> Indeed. Thanks.
[03:47] <StevenK> jtv: O hai. I'd like a review, but the branch scanner has de-pramed its toys while scanning my branch. The diff is at http://pastebin.ubuntu.com/792375/
[03:47] <jtv> StevenK: working on a long one right now, but you'll be next.
[03:47] <wgrant> StevenK: Make it rescan?
[03:48] <StevenK> wgrant: By pushing agai
[03:48] <StevenK> n?
[03:48] <wgrant> Yes.
[03:48] <wgrant> You may have to push -r-2 then push again, I forget.
[03:48] <StevenK> I thought we worked out that -r-2 doesn't work?
[03:48] <wgrant> It can't not.
[03:49] <StevenK> % bzr push -r-2
[03:49] <StevenK> Using saved push location: lp:~stevenk/launchpad/hide-forbidden-sprbs
[03:49] <StevenK> No new revisions to push.
[03:49] <wgrant> --overwrite
[03:49] <StevenK> And then bzr push quickly?
[03:50] <wgrant> No need to be quick.
[03:50] <wgrant> But if you want.
[03:51] <StevenK> The branch scanner should log branch.unique_name
[03:51] <wgrant> Yes.
[03:55] <StevenK> Bleh, job logging is complete crap
[03:55] <StevenK> You can't get at the logger in the actual job's run() method.
[03:58] <StevenK> wgrant: Looks like the scanner choked on it again
[03:58] <wgrant> Yay
[04:00] <lifeless> StevenK: its not on an attribute? Also why would you need to, thats not the logging API
[04:03] <StevenK> -        return '%s (ID %d)' % (class_name, ijob_id)
[04:03] <StevenK> +        return '%s (ID %d) %s' % (class_name, ijob_id, repr(job))
[04:03] <StevenK> I think that will help
[04:08] <lifeless> StevenK: wgrant: is  https://bugs.launchpad.net/launchpad/+bug/525749 part of disclosure, do you think ?
[04:08] <_mup_> Bug #525749: A Branch's visibility setting page contain the word 'visibility' <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/525749 >
[04:10] <wgrant> lifeless: Probably, yes.
[04:10] <wgrant> Although the summary seems to be inverted.
[04:10] <lifeless> indeed
[04:12] <lifeless> will you fix?
[04:13] <lifeless> wgrant: is https://bugs.launchpad.net/launchpad/+bug/527550 still ?
[04:13] <_mup_> Bug #527550: CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527550 >
[04:13] <wgrant> That hasn't been touched recently.
[04:13] <wgrant> So yes.
[04:14] <StevenK> lifeless: So to answer your question, it is not on a attribute. And it would be very useful for say, IDSJ.
[04:26] <lifeless> StevenK: but why? logger = logging.getLogger('lp.jobs.foo')
[04:26] <lifeless> done
[04:26] <lifeless> wgrant: and  https://bugs.launchpad.net/launchpad/+bug/527551?
[04:26] <_mup_> Bug #527551: Intra-archive copying of a source with a failed build may leave that source uncopyable <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527551 >
[04:29] <wgrant> lifeless: Still there.
[04:30] <lifeless> wgrant: and https://bugs.launchpad.net/launchpad/+bug/528459 ?
[04:30] <_mup_> Bug #528459: PPA does not delete old packages after new build <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/528459 >
[04:30] <wgrant> lifeless: Likewise.
[04:30] <wgrant> NBS
[04:30] <StevenK> lifeless: Because I prefer it was in the same log as the job runner uses
[04:31] <lifeless> StevenK: and? thats orthogonal
[04:31] <lifeless> StevenK: logger objects are not intended to be passed around willynilly
[04:45] <lifeless> StevenK: fixtures.FakeLogger may help you
[04:46] <StevenK> jtv: Still dealing with the large review?
[04:46] <jtv> Yes
[04:46] <jtv> But the first container of coffee has arrived, which should speed things up.
[04:47] <jtv> We're slightly hung over (in the non-imbibed sense) from an all-night drive during the holidays.
[04:47] <jtv> (“The holidays” for us being January 2 & 3)
[04:51] <micahg> the lpia PPA queue does not seem to be dispatching to the buildd
[04:53] <wgrant> webops: please stab gold and restart buildd-manager
[04:53]  * wgrant throws some builders at lpia.
[04:53] <spm> this is terrible. I can nearly do this from memory.
[04:54] <micahg> wgrant: I would just give it one, no one should be using lpia anyways
[04:56] <lifeless> wgrant: so this bug - https://bugs.launchpad.net/launchpad-buildd/+bug/533583
[04:56] <_mup_> Bug #533583: build fails where no error is present <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/533583 >
[04:57] <lifeless> what is the defect/problem ?
[04:57] <wgrant> micahg: Since there seem to be about 30 Mozilla builds on the virt builders at the moment, sounds like a good plan.
[04:58] <micahg> it's that time of day :)
[04:58] <wgrant> lifeless: sistpoty disagrees with Ubuntu policy.
[04:58] <wgrant> Needs to be argued with lamont.
[04:59] <micahg> ISTR another bug to make that not fatal
[05:00]  * micahg thinks it's a lack of scrolling to the bottom :)
[05:04]  * lifeless tosses oil on the fire
[05:05] <micahg> lifeless: you didn't have to toss wgrant in as well :)
[05:05] <lifeless> he is the oil ?
[05:06] <micahg> nah, I think he was holding it :)
[05:16] <lifeless> didn't poolie do this? https://bugs.launchpad.net/launchpad/+bug/547036
[05:16] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
[05:17] <StevenK> jtv: Just how big is this branch? :-P
[05:17] <spm> wgrant: btw, that ppa et al reset is done and done
[05:17] <wgrant> spm: Thanks.
[05:51] <StevenK> wgrant: Since jtv appears to be AWOL, would you mind reviewing the diff at http://pastebin.ubuntu.com/792375/
[05:53] <lifeless> wgrant: StevenK: opinions on  bug 547036 ?
[05:53] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
[05:54] <wgrant> lifeless: poolie fixed it months ago?
[05:54] <wgrant> StevenK: He might be back now :)
[05:54] <lifeless> wgrant: thats what I thought, was seeking confirmation
[05:57] <lifeless> StevenK: see bug https://bugs.launchpad.net/launchpad/+bug/551414
[05:57] <_mup_> Bug #551414: log messages in jobs are discarded <jobs> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/551414 >
[06:00] <StevenK> jtv1: Still fighting with the large branch? How large is it?
[06:00] <jtv1> StevenK: it's not the branch, it's the interruptions
[06:02] <lifeless> boo!
[06:12]  * StevenK nails wgrant to IRC.
[06:14]  * wgrant kicks Optus in the face :)
[06:15] <nigelb> I love that those of us in the 3rd world have better internets.
[06:15]  * nigelb waves to jtv1
[06:15] <jtv1> Hi nigelb
[06:15] <jtv1> Happy new year etc!  No time to chat further right now, sorry :)
[06:15] <nigelb> heh
[06:22] <StevenK> nigelb: What do you call an Indian cricketer with a century next to their name?
[06:23] <StevenK> nigelb: A bowler.
[06:24] <lifeless> jtv1: what is 'pottery' ?
[06:25] <wgrant> We do not speak its name.
[06:25] <jtv1> lifeless: it's the code for generating POTemplates from branches.  Runs in the build farm.
[06:25] <lifeless> thanks
[06:25] <jtv1> wgrant: yes we do.  I just did.  Robert just did.
[06:28] <wgrant> Bah
[06:33] <lifeless> LaunchpadTimeoutError: Statement: 'UPDATE Project SET max_bug_heat=(SELECT COALESCE(MAX(heat), 0) FROM
[06:33] <wgrant> Yes :)
[06:33] <lifeless> staaaaaaaaab
[06:33] <wgrant> I've been saying that for well over 18 months now.
[06:48] <lifeless> is there a better way?
[06:48] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805https://bugs.launchpad.net/launchpad/+bug/582805
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[06:48] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[07:05] <lifeless> 1123 high bugs, and counting
[07:08] <wgrant> 330 critical bugs
[07:09] <wgrant> what's your point?
[07:09] <micahg> lifeless: are you counting up or down?
[07:09] <wgrant> 330 critical bugs and 4 people, even.
[07:10] <lifeless> micahg: our bug handling policy says we have three groups of bugs
[07:10] <lifeless> the great unwashed
[07:10] <lifeless> 6 months of todo (high)
[07:10] <lifeless> as much zomg as there is (critical)
[07:10] <micahg> lifeless: I'm familiar :), just wondering which way you're counting on the 6 month pot :)
[07:11] <wgrant> lifeless: Huh
[07:11] <wgrant> How is high 6 months?
[07:11] <wgrant> Given that we have 4 people...
[07:11] <wgrant> That's like 10 bugs.
[07:11] <lifeless> micahg: and that every quarter we'll review the high to keep it trim; its a year overdue. The first one is a doozy
[07:11] <lifeless> wgrant: yes, I'll be doing a couple of passes I suspect
[07:11] <micahg> lifeless: ISTR you doing this recently
[07:11] <lifeless> micahg: that was eliminating mediums
[07:11] <micahg> ah
[07:11] <lifeless> micahg: which were stuck in limbo, some were crits, some high, many/most low
[07:12] <micahg> wgrant: only 4 people on highs now?
[07:13] <stub> For the next few months at least.
[07:20] <wgrant> Evening stub.
[07:20] <wgrant> stub: personless accounts: why do we still have them?
[07:20] <stub> morning
[07:21] <stub> Possibly placeholder people generated when we import stuff like translations etc.
[07:21] <stub> Not sure what does an ensurePerson or whatever the call is any more.
[07:21] <wgrant> personless accounts, not accountless persons.
[07:22] <stub> Yer... backwards.
[07:22] <wgrant> We have 3 million personless accounts.
[07:22] <wgrant> From SSO
[07:22] <stub> Didn't I clean them out already?
[07:22] <wgrant> No.
[07:22] <wgrant> We cleaned out the people from shipit.
[07:22] <wgrant> But not the accounts from SSO, or the accounts that were left over from deleted ShipIt people.
[07:23] <stub> k. more cleanup needed then. They just waste space I think.
[07:23]  * stub looks for other Account references
[07:23] <wgrant> openididentifier, emailaddress and person should be all
[07:24] <wgrant> I have a branch to delete EmailAddress.account, which depends on all those emailaddresses and accounts being gone :)
[07:24] <stub> Ok.
[07:24] <stub> So we need to trash emailaddresses and openididentifiers not linked to a person and accounts not linked to a person.
[07:25] <wgrant> Yep.
[07:25] <wgrant> Ah, accountpassword too
[07:25] <wgrant> Not that it's used any more except by tests.
[07:28] <jtv> StevenK: gasp!  Finally getting to yours now.
[07:30] <jtv> StevenK: I don't suppose check_permission might do any de-pramming of its own when presented with a None?
[07:31] <StevenK> jtv: Oh, in initial_values?
[07:31] <jtv> I think so — name not included in diff context.
[07:31] <jtv> Line 32 of your diff.
[07:32] <jtv> (By the way, updating copyrights is easy: just run utilities/update-copyright just like you do utilities/format-new-and-modified-imports.
[07:33] <StevenK> Which is what I did
[07:33] <StevenK> :-)
[07:33] <wgrant> Also, if people don't run format-new-and-modified-imports in all their branches now I will be very upset :)
[07:33] <wgrant> Since they're all in good order now.
[07:33] <jtv> So will I, but there is one problem: lp.codehosting.
[07:33] <wgrant> I fixed most of those.
[07:33] <wgrant> There's only like 3 places that need it.
[07:33] <jtv> I thank you.
[07:33] <wgrant> and they all have FIRST comments now
[07:34] <wgrant> Which format-imports handles nicely.
[07:34] <wgrant> I also made it handle _pythonpath properly.
[07:34] <jtv> Oh, there's a convention for that?  Great.
[07:34] <wgrant> And then ran it over the whole tree.
[07:34] <jtv> All wonderful.  I suppose _pythonpath still elicit lint warnings?
[07:34] <wgrant> An import preceded by a comment starting "# FIRST" will be put after the stdlib imports, but before the third-party ones.
[07:34] <wgrant> Yes.
[07:34] <wgrant> Not sure how to suppress those globally.
[07:35] <jtv> This will also make my megalint branches a bit less mega.  :)
[07:35] <wgrant> This one touched about 1200 files.
[07:36] <StevenK> jtv: Does http://pastebin.ubuntu.com/792471/ make you less nervous?
[07:36] <jtv> StevenK: wasn't saying nervous.  You should see the review I just finished.
[07:36] <StevenK> jtv: That should make certain check_permission() doesn't get a None.
[07:37] <jtv> It does make me feel slightly safer, as well as appreciated.  :)  Thanks.
[07:37] <StevenK> I'm actually more comfortable with how I've written it now.
[07:39] <jtv> That's good too.
[07:39] <jtv> You've got my vote, with one additional note.
[07:40] <StevenK> jtv: If we say something other than "This recipe has not been built yet" we may leak the existance of the private PPA
[07:41] <StevenK> Pretending the build doesn't exist if they can't see it is safest.
[07:41] <jtv> And the recipe needs to remain visible?
[07:42] <jtv> What about "this recipe has not been built yet (or if it has, you are not permitted to see the builds)"?
[07:42] <StevenK> We do not support private recipes or recipes making use of private branches.
[07:42] <wgrant> We'd have to add that disclaimer to practically every list in Launchpad.
[07:43] <jtv> I see.  Nasty problem.
[07:43] <lifeless> yes the recipe has to stay visible
[07:43] <jtv> Then again, I suppose it's a bit of a tree falling with no-one to hear.
[07:43] <lifeless> because it may be owned by e.g. you
[07:44] <StevenK> jtv: It's a rabbit hole. wgrant, sinzui, wallyworld, jcsakett and I have been arguing about problems like that for months.
[07:44] <StevenK> lifeless: At the moment, it doesn't. :-)
[07:45] <StevenK> But sinzui agreed it's a disclosure bug.
[07:45] <jtv> I suppose the only relevant information to an unprivileged user would be "yes, this recipe can build" and they'll find out eventually if that's not the case.
[07:46]  * StevenK checks the scanner choked on the branch again.
[07:49] <StevenK> Pity. It does.
[07:49] <lifeless> StevenK: doesn't your branch make the recipe stay visible ?
[07:50] <StevenK> lifeless: Yes. I was making a joke that it doesn't on production.
[07:50] <lifeless> ah, heh
[08:00] <stub> How much work did you guys land over the break? New Year branch pulling just keeps going and going...
[08:02] <StevenK> stub: wgrant and sinzui's fault. They effectively emptied lib/canonical
[08:04] <wgrant> stub: We moved a couple of hundred thousands lines of lib/canonical remnants, and properly formatted the imports in every file.
[08:04] <stub> I wonder if you could compile a diff to a regexp search and replace?
[08:04] <wgrant> Heh
[08:05] <lifeless> yes, you can
[08:05] <wgrant> stub: Also, I reverted the EmailAddress.{person,account} consistency patch, as it was going to take 3-4 minutes to apply.
[08:05] <lifeless> wgrant: do you think https://bugs.launchpad.net/launchpad/+bug/566339 is fixed, or not ?
[08:05] <_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
[08:06] <stub> wgrant: Really? What was it doing besides adding the triggers?
[08:06] <wgrant> stub: Not triggers, but check constraints.
[08:06] <stub> oh... ic. hmm...
[08:06] <wgrant> Apart from the questionable sensibility of having cross-table functions in check constraints, before pg 9.1 they can't be added without a full scan.
[08:07] <wgrant> So, instead of turning them into triggers I decided to fix the inconsistencies by dropping EmailAddress.account instead.
[08:07] <stub> Yes, that would have been my preferred approach but gmb thought this was a quicker fix and wanted the quicker fix.
[08:08] <StevenK> wgrant: You managed to drop it?
[08:08] <wgrant> The actual code changes were reasonably shallow. But the tests, oh god the tests.
[08:08] <wgrant> All fixed now, anyway.
[08:08] <stub> Main goal being to locate the code generating the inconsistent data.
[08:08] <wgrant> In a final ec2 run before being split into 4.
[08:08] <StevenK> wgrant: Four now?
[08:08] <wgrant> StevenK: Yes.
[08:08] <wgrant> Mailing list refactorings are being split up separately.
[08:08] <StevenK> Ah
[08:09] <wgrant> Because the queries and tests were awful.
[08:09] <StevenK> s/were/are/ ?
[08:09] <wgrant> stub: I never tracked down exactly what it was, but I believe it's in the code around reconciling openididentifiers, persons and accounts on login when there are conflicts and the account needs reactivating.
[08:10] <wgrant> But account has basically had all its functionality ripped out in this branch, so it doesn't matter.
[08:10] <stub> Need to convince bzr that removing a directory containing nothing but garbage is fine
[08:10] <wgrant> stub: bzr clean-tree
[08:10] <wgrant> Will ask you if you want to remove unknown files/directories
[08:10] <wgrant> It's how I get around these conflicts, and tends to work pretty well.
[08:11] <stub> yer. I know why the guard is there, but so far it has only been false positives.
[08:11] <wgrant> Yeah
[08:11] <wgrant> pyc ftl.
[08:12] <stub> bzr knows about files to ignore, we could teach it about garbage in a similar fashion.
[08:12] <stub> I guess it doesn't matter that much
[08:12] <lifeless> bzr resolve --take-other should clean them up
[08:14] <stub> Just complaining that it is my responsibility to fix things up that aren't really broken, but bzr isn't intelligent enough to know if this case is potential data loss or noise.
[08:14] <StevenK> wgrant: r14625 is ready for you to QA.
[08:14] <lifeless> wgrant: so, can has answer to last two q's?
[08:14] <StevenK> jelmer: Can haz QA for r14620?
[08:15] <wgrant> lifeless: What was the one that wasn't bug #566339?
[08:15] <_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
[08:15] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
[08:15] <wgrant> I don't believe that one is fixed.
[08:15] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[08:15] <wgrant> StevenK refactored that code, but didn't change it much.
[08:16] <StevenK> Let's just delete it instead.
[08:16] <wgrant> lifeless: Commented and closed.
[08:19] <lifeless> thanks
[08:20] <wgrant> stub: So, do you want me to write the SQL to clean up the accounts, or can you do it?
[08:20] <stub> wgrant: It needs to be a garbo job, and I was going to do it when my branches have synced.
[08:20] <stub> Unless you want to... just a couple of BulkPruner tasks I think.
[08:20] <wgrant> Mm, I think the references are few enough that you could do it without garbo.
[08:20] <wgrant> But I guess it's the same as PersonPruner, really.
[08:22] <stub> We don't want to block creating new accounts while the SQL runs...
[08:23] <lifeless> pruners are easy
[08:24] <stub> bah... launchpaddatabaseupdatelog.end_time isn't being populated :-P
[08:24] <wgrant> stub: It's also crashing with dupe ids.
[08:24] <wgrant> On staging restores.
[08:25] <wgrant> Which is a little bit odd.
[08:26] <adeuring> good morning
[08:28] <stub> wgrant: Because it gets populated when we build the database schema, then we attempt to repopulate it by restoring the similar data from production.
[08:28] <wgrant> Ah!
[08:28] <stub> hmmm...
[08:28] <stub> ?
[08:29] <stub> oh... full updates should work, but code updates can fail like that.
[08:29] <stub> no..
[08:29] <stub> hmm...
[08:29] <stub> need to look over the scripts.
[08:29] <wgrant> Code updates work, AFAICS.
[08:29] <wgrant> Hm
[08:29] <wgrant> Although they've been failing early.
[08:29] <wgrant> Because of the bad patch.
[08:29] <wgrant> So maybe not.
[08:31] <lifeless> stub: remember we're dropping the updatelog
[08:31] <lifeless> stub: (and trusted.sql etc) - moving to just patch applications
[08:32] <stub> oh right, so I'll ignore the missing field for now and maybe trash it if it is the best way to fix staging.
[08:32] <wgrant> stub: Hopefully _new is salvagable.
[08:32] <wgrant> But I'm not sure.
[09:04] <stub> wgrant: Any particular reason you decided to drop EmailAddress.account rather than Person.account? You can argue either way.
[09:05] <danhg> morning
[09:05] <wgrant> stub: EmailAddress.{account,person} could still be inconsistent, as there can be multiple email addresses.
[09:05] <stub> I guess we might end up with Person records with no emailaddresses once we start adding other contact mechanisms
[09:05] <stub> Good point.
[09:06] <wgrant> And Account is hopefully not long for this world.
[09:10] <lifeless> wheee
[09:10] <lifeless> https://bugs.launchpad.net/launchpad/+bug/599377
[09:10] <_mup_> Bug #599377: FilebugShowSimilarBugsView.show_duplicate_list treats contextUsesMalone as a property but it's a method <dhrb> <dupefinder> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/599377 >
[09:10] <stub> AssertionError: Can't create a Person for an account which has no email.
[09:12] <wgrant> stub: Where'd you run into that?
[09:12] <wgrant> Tests?
[09:12] <wgrant> I assume that's from Account.createPerson?
[09:13] <stub> wgrant: Yup. test_garbo
[09:13] <stub> Think it is on trunk
[09:13] <stub> test_RevisionAuthorEmailLinker is one of two
[09:13] <wgrant> What have you changed to trigger that?
[09:15] <stub> Two new daily jobs. Hmm... might be my change actually. A lot of the tests just run 'all daily jobs', and I might be destroying the data in a way the test does not expect.
[09:15] <wgrant> Heh, yes.
[09:15] <wgrant> That sounds likely.
[09:15] <stub> ok... leave this until after lunch then before wife gets antsy
[09:16] <wgrant> IIRC test_RevisionAuthorEmailLinker relies on an unlinked Account surviving a garbo run.
[09:16] <wgrant> For one of its cases.
[09:16] <wgrant> But that can probably go, since it's no longer a valid data state.
[10:41] <stub> Has lp hung or my censorwall screwing up?
[10:41] <stub> oh... there it is
[10:42] <wgrant> stub: There weren't parens in the original, so I didn't add them. Although I wonder if that's just how it rendered it, as it seems to change whitespace.
[10:42] <wgrant> I shall fix it, anyway.
[10:42] <stub> wgrant: They get stripped by PG, which always worries me
[10:43] <wgrant> Oh, that is rather awful.
[10:43] <stub> It gets it right, but I know *I* will mess things up without them.
[10:43] <wgrant> I noted their absence and considered fixing them. But then decided to make minimal changes.
[10:43] <wgrant> Didn't think it would strip them...
[10:44] <stub> it is reconsituting the expression that was compiled I think, sans comments etc.
[10:44] <stub> not sure
[10:45] <wgrant> Yeah, I was thinking it couldn't do that, but of course this is a view not a function.
[10:45] <wgrant> Thanks lifeless.
[10:48] <wgrant> frankban: I'd remove the request for 11239, as it is redundant and likely to confuse.
[10:49] <wgrant> stub: As for the merged check, the more likely reason for its omission is the preferredemail check.
[10:49] <wgrant> Since a merged account will never have an email address, let alone a preferred one.
[10:50] <frankban> wgrant: let me guess, applying 11275 also means applying my patch, am I right?
[10:50] <wgrant> frankban: Yep.
[10:50] <frankban> wgrant: ok thanks
[10:50] <stub> True. Probably me prematurely optimizing.
[10:51] <wgrant> frankban: That revision will be checked out, and all of the patches in that tree applied if they aren't already applied.
[10:51] <wgrant> frankban: So all changes from current production to that revision will be applied.
[10:53] <frankban> wgrant: very clear, request removed
[10:53] <wgrant> frankban: Looks good, thanks.
[11:08] <Laney> Remind me about teams: are administrators members?
[11:09] <wgrant> Laney: At present yes.
[11:09] <wgrant> Laney: Owners are not.
[11:09] <Laney> OK, and what can the owner do that administrators cannot and vice-versa?
[11:10] <wgrant> Today, owners can do everything admins can, plus change the owner, promote members to admins, and change their own expiry date if they are a member.
[11:10] <Laney> uh, thought I was asking this in #lp, sorry
[11:10] <wgrant> But this will change tomorrow.
[11:10] <wgrant> As admins are gaining the ability to promote others to admins, and to change their own expiry date.
[11:11] <wgrant> So the only things special about the owner are that they aren't necessarily a member, and that they can change the owner.
[11:11] <wgrant> s/are that/will be that/
[11:12] <Laney> and that they don't get all of the mail that admins do (#908144 prompted my questions).
[11:12] <_mup_> Bug #908144: No way to customise receipt (or not) of team membership expiry/join emails <email> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/908144 >
[11:12] <wgrant> Ah, yeah, that too.
[11:12] <wgrant> But that's not meant to be a privilege :P
[11:14] <Laney> I was trying to figure out if having non-member administrators would be a better fit than subscribing to administrator mails
[11:14] <Laney> thanks for the info
[11:15] <wgrant> I would like to remove owners, and instead have non-member administrators.
[11:15] <wgrant> It is somewhat controversial, however.
[11:30] <stub> owner is needed as a defence against rogue administrators. We don't want to have to arbitrate in feuds.
[11:30] <stub> wgrant: https://code.launchpad.net/~stub/launchpad/garbo-bulk-pruner/+merge/87461
[11:36] <wgrant> stub: Do openididentifier and accountpassword cascade?
[11:36] <wgrant> Ah, yes.
[11:37] <wgrant> Handy.
[11:38] <stub> yes, although looptuner tuning would be more predictable if those rows were purged in separate jobs.
[11:38] <wgrant> Mmm.
[11:38] <wgrant> Only slightly.
[11:38] <wgrant> It should be pretty much 1-1-1
[11:38] <stub> yer. don't think anyone would notice.
[11:41] <StevenK> stub: I'm nitpicking, but you should update the copyright years. :-)
[11:42] <wgrant> stub: What does SELECT COUNT(*) FROM emailaddress JOIN person ON person.id = emailaddress.person WHERE emailaddress.account IS DISTINCT FROM person.account; say on prod?
[11:42] <wgrant> s/IS DISTINCT FROM/!=/ was 0 yesterday, but this is probably closer to what we actually care about.
[11:46] <stub> wgrant: 0
[11:47] <wgrant> Surprising!
[11:47]  * wgrant approves
[11:47] <wgrant> Thanks.
[11:48] <stub> What is the script that does the copyright stuff automagically?
[11:48] <wgrant> utilities/update-copyright
[11:54] <stub> wgrant: Long term, I think it would be good to have both Account and Person. I don't like bots and things claiming to be people. We collapsed the concepts unfortunately (along with teams for even more fun).
[11:55] <wgrant> stub: Possibly.
[11:55] <wgrant> It's hard to say what we should do.
[11:55] <wgrant> Person is really Principal.
[11:55] <wgrant> Or Role.
[11:59] <stub> Yes, and if we had called it something like that at the time things would be nicer now.
[11:59] <wgrant> Anyway, we can easily shuffle these things around later on once we don't have a conflict-happy model :)
[13:48] <benji> hmm, someone is looking for JS injection points: https://answers.launchpad.net/launchpad/+question/183686
[13:52] <rick_h__> benji: heh, yep
[13:53] <rick_h__> man, junk ppa and everything
[14:28] <abentley> rockstar: About bug 911090: I know that Launchpad should be robust against 16 MB code review comments, but I also think tarmac should not be making 16 MB code review comments, because they make code review hard to read.
[14:28] <_mup_> Bug #911090: merge proposal is broken with consistent timeouts <timeout> <Launchpad itself:Triaged by abentley> <Tarmac:New> < https://launchpad.net/bugs/911090 >
[14:33] <cr3> odd, launchpad.net/projects seems to be forbidden now :(
[14:35] <jelmer> cr3: probably something private on that page
[14:36] <cr3> jelmer: is that expected behavior or should I report a bug against launchpad itself?
[14:37] <stub> That would be a bug.
[14:37] <jelmer> cr3: that's a bug
[14:37] <jelmer> presumably those private items that you're not allowed to view should just be hidden rather than making the entire page inaccessible
[14:37] <stub> Projects lists 'latest teams', and should be hiding private teams you shouldn't be able to see rather than making the page fail
[14:40] <cr3> jelmer, stub: reported bug #911794
[14:40] <_mup_> Bug #911794: /projects page now returns forbidden <Launchpad itself:New> < https://launchpad.net/bugs/911794 >
[14:41] <rick_h__> benji: https://bugs.launchpad.net/launchpad/+bug/911632
[14:42] <benji> rick_h__: I guess he found one.
[14:43] <rick_h__> yea, checking it out.
[15:08] <abentley> frankban: Please target your reviews to "canonical-launchpad-reviewers" (which is the default-- you can just leave it blank in the web form) rather than "launchpad"
[15:08] <frankban> abentley: ok, thank you
[15:09] <abentley> frankban: Thanks.
[15:51] <deryck> abentley, is there a bug, either upstream or in lp, about pystache and scoping issues?
[15:52] <abentley> deryck: I don't think so.
[15:53] <deryck> abentley, do you mind filing an lp bug at least?  Should be a high bug, but we can work on it on maintenance, to avoid the tech debt in our code.
[15:55] <flacoste> deryck: from a maintenance point of view, bug 911520 seems really terrible :-/ we should probably disable oops pruning until it's fixed
[15:55] <_mup_> Bug #911520: Pruning fails to find any references, deleting all OOPSes older than a week <python-oops-tools:Triaged> < https://launchpad.net/bugs/911520 >
[15:55] <abentley> deryck: However, I did report it to the author of pystache, who agreed it was a bug.
[15:55] <deryck> abentley, ah, ok.  Do you mind filing the lp bug for us, too?
[15:56] <deryck> flacoste, ack, I'll add the bug to the backlog and have oops pruning disabled.
[15:56] <deryck> or the next lane rather.
[15:56] <flacoste> deryck: thx
[15:58] <flacoste> deryck, mrevell: when are we releasing bug-columns?
[15:58] <abentley> deryck: As soon as I make sure it's still present...
[15:59] <deryck> abentley, ah, ok.  Thanks!
[16:00] <mrevell> flacoste, danhg is preparing the announcement.
[16:00] <mrevell> deryck, do you have time for a call?
[16:00] <flacoste> mrevell: great!
[16:02] <deryck> mrevell, I do shortly.  give me 10-15 minutes to finish the stuff I'm on.  it's a bit interrupty :)  hard to just drop.
[16:02] <mrevell> thanks deryck
[16:07] <flacoste> gary_poster: we did complete the work to make apache serves the wadl right?
[16:07] <gary_poster> flacoste, yes
[16:12] <abentley> rick_h__: I'm filing a new bug, and when I start to type in "Further information:", the box gets longer immediately.  Is this fallout from your work?
[16:12] <rick_h__> abentley: probably
[16:13] <abentley> rick_h__: This is on Firefox 8.0
[16:14] <rick_h__> abentley: ok
[16:18] <abentley> deryck: bug 911840
[16:18] <_mup_> Bug #911840: Launchpad works around pystache scoping bug <bug-columns> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/911840 >
[16:19] <deryck> abentley, awesome, thanks!
[16:24] <deryck> mrevell, we can chat now if you like.
[16:24] <deryck> mrevell, Skype?
[16:32] <deryck> rick_h__, and I understand our card titled: "Refactor bug listing ordering history code out of the template file" ….
[16:32] <deryck> rick_h__, this would help prevent any other oops with history handling, if this was moved out to a separate js file, yes?
[16:33] <rick_h__> deryck: right, it can't be tested like the rest of the JS code because of logic in the .pt files
[16:33] <deryck> rick_h__, can you file a high bug about that and pass me the bug number then please?
[16:33] <rick_h__> deryck: so factoring it out into a init or something that's called from the .pt would allow some better testing in JS tests
[16:33] <rick_h__> deryck: sure thing
[16:39] <rick_h__> deryck: 911857
[16:40] <rick_h__> abentley: thanks, I confirm seeing that FF issue. Created a bug for it and will check it out.
[16:40] <abentley> rick_h__: cool.
[16:42] <deryck> rick_h__, thanks
[16:48] <jcsackett> sinzui: have some time to mumble?
[16:51] <sinzui> yes
[16:59] <rick_h__> abentley: have a sec for a ?
[17:00] <abentley> rick_h__: sure.
[17:00] <rick_h__> so have this bug: https://bugs.launchpad.net/launchpad/+bug/911632 with this mp in progress https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507
[17:00] <rick_h__> abentley: and looking at how to test this?
[17:01] <rick_h__> abentley: it looks like I could try to change the dev data's name in the story, but seems a bit much for it
[17:01] <rick_h__> abentley: so curious if I should try to create a new user with the known xss? Just say this is such a small fix, no new test?
[17:04] <abentley> rick_h__:  I would test it by creating a person with a bogus name, rendering the relevant view (using getViewBrowser) and asserting that the resulting HTML did not have the unescaped version.
[17:05] <rick_h__> abentley: ok cool, will check that out
[17:05] <abentley> rick_h__: I would not touch the doctest.  You are writing a unit test, not documentation.
[17:06] <rick_h__> abentley: yea, you're right. I was just searching for existing tests to latch onto and hit that
[17:06] <rick_h__> abentley: thanks!
[17:06] <abentley> rick_h__: np
[17:08] <abentley> rick_h__: It would be interesting to change factory.makePerson to generate people with bogus names, but I don't think even that would catch all cases.
[17:08] <rick_h__> abentley: yea, you have to be checking for the bad output specifically
[17:08] <rick_h__> abentley: until it renders there's nothing to say <script> is a bad name
[17:10] <abentley> rick_h__: If the bad characters were a consistent string, we could perhaps tweak some common code to puke if it was present.
[17:51] <sinzui> flacoste, I would like your opinion of bug 910876. Choosing to remove code to revert to the 2009 rules makes fixing other bugs easy.
[17:51] <_mup_> Bug #910876: "Remove assignee" no longer shown in bugtask assignee AJAX popup unless logged in user is the assignee <bugs> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/910876 >
[17:54] <sinzui> maybe anyone can unassign a user, but the current rules apply to assigned teams
[18:02] <nigelb> StevenK: HAHA good one
[18:32] <flacoste> sinzui: replied, i basically agree with your first comment
[18:33] <sinzui> thank you
[18:33] <lifeless> morning
[19:06] <cjwatson> argh @gina
[19:06] <cjwatson> it imports dsc_binaries in an invalid format
[19:07] <rick_h__> abentley: can you peek at https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507 when you get some time please?
[19:07] <abentley> rick_h__: sure.
[19:07] <rick_h__> ty
[19:08] <abentley> rick_h__: why are you using getUserBrowser rather than getViewBrowser?  getViewBrowser already does the canonical_url bit.
[19:08] <rick_h__> abentley: when I tried getViewBrowser it failed to generate the url as "xxx broke the chain"
[19:08] <rick_h__> I went off the example from the test above it which was using getUserBrowser
[19:09] <rick_h__> abentley: but now that you say that it makes sense, since I was sending it the canonical url bit
[19:09] <abentley> rick_h__: "xxx broke the chain" is emitted by canonical_url.
[19:09] <rick_h__> abentley: right, makes sense. Basically I copied the test above it.
[19:10] <rick_h__> abentley: looking back at the getViewBrowser
[19:10] <abentley> rick_h__: Perhaps you did not specify rootsite?
[19:10] <rick_h__> abentley: right, I called it wrong. I called it like getUserBrowser
[19:10] <abentley> rick_h__: Ah.
[19:11] <rick_h__> abentley: crossing the streams between copying existing test and looking at getViewBrowser
[19:11] <abentley> rick_h__: I see.
[19:11] <abentley> rick_h__: r=me.
[19:11] <rick_h__> abentley: ty
[19:12] <abentley> rick_h__: However, I don't think the bug is meant to apply only to this issue.
[19:13] <rick_h__> abentley: well, this guy hammered all over the site and this was the instance he found it.
[19:13] <rick_h__> abentley: I've tried to think of how best to *auto* test this, but the cause was that someone at some point told zpt to specifically "not" escape this item
[19:14] <rick_h__> abentley: I could grep through all of the templates looking for structure usage and verify the content is safe
[19:14] <abentley> rick_h__: Okay.  I think you're right.  "persistent" made me think he was going for a broader issue.
[19:14] <rick_h__> abentley: but wasn't sure if I should take the time to go through all that or not tbh.
[19:16] <abentley> rick_h__: Did your second test "self.assertTrue(escapedname in browser.contents)" fail before you changed the template?
[19:16] <rick_h__> abentley: yes, I put back the structure to verify
[19:17] <abentley> rick_h__: I have a hunch it would pass because the user name appears elsewhere on the page.
[19:17] <rick_h__> abentley: the change was in place because I found the issue before finding a good place for the test, but did walk back
[19:17] <rick_h__> abentley: ah, see what you mean. However the first test fails
[19:17] <rick_h__> abentley: that's why I check for both, to make sure there is no non-escape <script> and that there is in fact an escaped one
[19:17] <abentley> rick_h__: I think the second test would not.  Can you check, and if so remove it?
[19:17] <rick_h__> abentley: you're right that the second test doesn't do much since it's in there 3 places
[19:17] <rick_h__> abentley: gotcha, will do
[19:18] <rick_h__> abentley: cool, and got getViewBrowser() to pass and work right
[19:18] <abentley> rick_h__: Great.
[19:19] <abentley> rick_h__: alternatively, you could do a more exact match on the error text.
[19:20] <rick_h__> abentley: right, gotcha
[19:22] <abentley> rick_h__: Does your branch also fix it if the error message is loaded via AJAX?
[19:22] <rick_h__> abentley: I'll double check. I believe so since it's a fix of the template used to generate the table view
[19:24] <cjwatson> Is all the gina code actually in the LP tree?  I can't find any references to ImporterHandler other than its definition.
[19:26] <cjwatson> But it seems like the main operating class ...
[19:27] <cjwatson> see also bug 830904
[19:27] <_mup_> Bug #830904: Is run-newgina.sh dead code? <Launchpad itself:Triaged> < https://launchpad.net/bugs/830904 >
[19:30] <cjwatson> Never mind, I'm talking nonsense
[19:36] <lifeless> wgrant: to answer your question '300'
[19:36] <lifeless> flacoste: did you find a timeslot for us ? :)
[19:37] <flacoste> lifeless: how about in 20 minutes?
[19:39] <lifeless> flacoste: thats the parallel testing call
[19:39] <lifeless> ah no, its not
[19:40] <lifeless> thats me going into hospital for my once a month allergy shot
[19:42] <flacoste> lifeless: when are you getting back?
[19:42] <lifeless> flacoste: its 40m in + 40m back + 30m observation + 15m friction, more or less
[19:43] <flacoste> lifeless: ping me when you get back, i'll probably still be around
[19:43] <lifeless> 1030 appointment, so back ~ 1200, which is 2300UTC
[19:43] <lifeless> flacoste: will do
[19:44] <flacoste> hmm, i got my calculation wrong then
[19:44] <flacoste> i thought that was 22UTC
[19:45] <flacoste> lifeless: if you are back before 23 UTC then ping me, otherwise, we'll have to postpone to tomorrow
[19:45] <flacoste> lifeless: before the parallel testing call, just ping me when you are online
[19:46] <lifeless> flacoste: I will ping you; if you are around, \o/ if you are not tomorrow is go
[19:47] <flacoste> lifeless: great!
[19:52] <lifeless> sinzui: do we have a general 'lp is hard to read bug' ?
[19:53] <lifeless> sinzui: I'd like to dupe https://bugs.launchpad.net/loggerhead/+bug/601392 on it
[19:53] <_mup_> Bug #601392: Loggerhead should have a better text-background contrast with Chromium <css> <ui> <loggerhead:Triaged> < https://launchpad.net/bugs/601392 >
[19:53]  * sinzui looks for mpt's last font bug
[19:54] <flacoste> mpt isn't the one who filed it iirc
[19:54] <flacoste> we won't fix it though
[19:55] <flacoste> might have been poolie
[19:57] <sinzui> lifeless, I thought mpt had reported a bug about fonts that was general to the issue. He wrote the Lp is harder to read than other hosting sites
[19:58] <sinzui> This looks like a WAI issue. Looks like someone removed the the WAI tag I had added
[20:00] <abentley> rick_h__: BTW, we also have assertIn and assertNotIn.
[20:01] <rick_h__> abentley: ooh, thanks. Bookmarked the full list.
[20:02] <lifeless> sinzui: I thought he did too
[20:03] <lifeless> rick_h__: and assertThat(foo, Contains(bar))
[20:04] <rick_h__> lifeless: cool, I saw some work with the containsHTML from the soup stuff, but I wasn't creating full tags
[20:04] <sinzui> lifeless, I ws thinking of bug 883258
[20:04] <_mup_> Bug #883258: Bug descriptions/comments much harder to read on Launchpad than other hosting services <css> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/883258 >
[20:05] <lifeless> sinzui: thanks, do you think this is a dupe, or that the loggerhead thing is different ?
[20:05] <lifeless> sinzui: if its a dupe, I will add a loggerhead task to 883258
[20:08] <sinzui> lifeless, No. I think is a separate bug. It is both a css issue and a WAI comparability issue.
[20:09] <sinzui> compatibility
[20:09] <lifeless> WAI ?
[20:21] <sinzui> lifeless, sorry, I was in another conversation: WAI was established in 1997 to tell web authors to stop messing with users: http://www.w3.org/TR/WCAG/
[20:22] <lifeless> sinzui: I've gardened the bug a little; if you wanted to add analysis to it that would be the bomb
[20:22] <sinzui> lifeless,  I tagged a few things WAI last year when Canonical said it was taking accessibility seriously
[21:59] <jcsackett> sinzui: i'll be a little late to standup; vet just called.
[22:00] <sinzui> okay
[22:02] <wgrant> lifeless: 300?
[22:02] <wgrant> cjwatson: Yes, all of gina is in the tree. Have you grepped scripts/?
[22:04] <deryck> Later on, all.
[22:43] <cjwatson> wgrant: Yeah, when I found scripts/gina.py I said "Never mind, I'm talking nonsense" :-)
[23:07] <lifeless> flacoste: ping
[23:08] <lifeless> wgrant: '6 months worth of bugs'
[23:08] <lifeless> wgrant: our rate was 200 commits/month with all squads; *6/4
[23:08] <wgrant> lifeless: Ah!
[23:39] <wgrant> lifeless: !!
[23:39] <wgrant> YAY
[23:39] <wgrant> kill, crush, destroy
[23:40] <lifeless> heh, happy new years
[23:44] <StevenK> Hm?
[23:44] <lifeless> I just proposed disabling heat aging and max-heat tracking on bug contexts
[23:45] <lifeless> which means changing heat display to a number not a fraction
[23:46] <wgrant> Which makes Launchpad fast :)
[23:51] <lifeless> well, it will remove some causes of slowness
[23:52] <wgrant> Lies.
[23:53] <lifeless> hmm?
[23:54] <wgrant> Destroying bug heat will solve all the world's problems :)
[23:54] <lifeless> Optimism from you? I'm shocked!


[14:28] <willubuntu> Hello everybody. I would like to know if the french term "listage" is often used to speak about the "directory listing" ?
[14:29] <willubuntu> First of all, there is French translators in this chan ?
[14:51] <gtriderxc> yaes there is. but seems to B absent
[14:51] <willubuntu> ok thanks but i have all my answers now thanks
[14:52] <gtriderxc> Qrcze Tomek, chyba z moim angielskim nie jest aż tak źle? ;)
[20:19] <TomaszD_> strasznie ;)
[20:36] <gtriderxc> www.grooveshark.com  <- Free musik for better translations ;)


[00:10] <darkxst> ubuntu GNOME 20130723.2 images have not appeared on cdimage.u.c
[00:10] <darkxst> is something broken?
[00:13] <phillw> darkxst: they are not showing as rebuilding on http://iso.qa.ubuntu.com/qatracker/milestones/270/builds it does not even show a .1 rebuild on there>?
[00:13] <phillw> correction, the .1 rebuild IS there, but it does show as marked for a respin
[00:14] <phillw> *does NOT show*.... wanders off for a ciggie.
[00:17] <slangasek> darkxst, phillw: I think you probably want http://iso.qa.ubuntu.com/qatracker/milestones/299/builds fwiw.  There is a '20130723.2' listed there, but it never built; I don't know what that means, but I'll go ahead and trigger a manual rebuild
[00:17] <slangasek> rsalveti: maliit-frameworks> ack, will have a look :)
[00:19] <phillw> sorry, slangasek I'd moved back to look at the PPC images on the dailes.... Darn easy to be on the wrong area :/
[00:21] <phillw> infinity: are you still around?
[00:22] <jbicha> UG's 20130723.1 amd64 iso was a bit weird too as the .manifest wasn't updated
[01:23] <ScottK> If there's a respin for something, please also let kubuntu-meta and kubuntu-settings through to go with it.
[02:58] <jdstrand> can someone deNEW click-apparmor? it is fine in universe for now
[10:01] <ogra_> infinity, ubuntu-core seems unwell
[10:01] <ogra_> (or rather debootstrap)
[10:16] <infinity> ogra_: debootstrap being unwell is less than good.
[10:16]  * infinity looks.
[10:16] <ogra_> it trips over python2.7-minimal seemingly
[10:16] <infinity> ogra_: Erm, unwell how?  The build log looks sane.
[10:17] <ogra_> not in the mail i just got
[10:17] <ogra_> oh, wait
[10:17] <ogra_> thats precise
[10:17]  * ogra_ missed that in the subject
[10:17] <ogra_> W: Failure while configuring base packages.  This will be re-attempted up to five times.
[10:17] <ogra_> I: Configuring python2.7-minimal...
[10:17] <ogra_> W: Failure while configuring base packages.  This will be re-attempted up to five times.
[10:17] <infinity> Oh, precise may well be sad.
[10:18] <infinity> Breaking the world on the way to the point release.
[10:18] <ogra_> ah
[10:18]  * ogra_ will ignore it then
[10:18] <ogra_> sorry for the noise ... if i had noticed its precise ...
[10:23] <cjwatson> ogra_: that looks like a pandabug to me
[10:26] <ogra_> cjwatson, could well be
[11:39] <phillw> infinity: I have a rather odd email regarding PPC in 13.10. After a month of not working, the ISO from 23rd July now works.... There's nothing more peculiar than testing!
[11:41] <phillw> this has been confirmed by another of the testers....
[13:07] <jdstrand> infinity: hi! I am looking at https://launchpad.net/ubuntu/+source/apparmor/2.8.0-0ubuntu23/+build/4820740
[13:07] <jdstrand> infinity: it looks like the build died, but it is still showing as building and I don't have a way to retry it. can you help?
[13:08] <infinity> jdstrand: I can get it killed, sure.
[13:08] <infinity> jdstrand: Quite possible that the buildd had a sad, given where it's stalled.
[13:11] <jdstrand> infinity: thanks
[13:48] <seb128> infinity, cjwatson: hey, britney question ... maliit has been doing qt4 -> qt5, which means it stopped building on ppc (rather in depwait), what's the right way to get the new version to migrate to saucy? delete the old ppc binaries?
[13:48] <cjwatson> yes, assuming they have no revdeps
[13:48] <infinity> seb128: Yeah, and rdeps.
[13:48] <infinity> (It does have some... I suspect some of those things need rebuilding anyway)
[13:49] <seb128> it does?
[13:49] <seb128> well, maliit has 2 sources
[13:49] <seb128> the rdepends should be only binaries from those
[13:49] <rsalveti> yeah
[13:50] <infinity> * maliit-keyboard               (for maliit-framework)
[13:50] <infinity> * nemo-keyboard                 (for maliit-framework)
[13:50] <infinity> * ubuntu-touch [amd64 armhf i386]  (for maliit-framework)
[13:50] <infinity> One of those is arch:all though, I think.
[13:50] <cjwatson> checkrdepends on lillypilly will tell you
[13:51] <seb128> infinity, which one?
[13:52] <infinity> nemo-keyboard
[13:52] <infinity> Ahh, and it's in -proposed too.  So, yeah.
[13:52] <cjwatson> 'checkrdepends maliit' on lillypilly isn't showing anything
[13:52] <infinity> We can transition this.
[13:52] <infinity> I'll whack the PPC binaries from the release pocket now.
[13:54] <cjwatson> Ah, seb128 didn't give me the exact source name
[13:54] <seb128> cjwatson, sorry
[13:54] <seb128> infinity, cjwatson: thanks for the help
[13:55] <infinity> seb128: Done.  We'll see if that makes it happier.
[13:56] <seb128> rsalveti, ^
[13:56] <seb128> infinity, thanks ;-)
[13:56] <rsalveti> great, thanks all
[14:13] <Riddell> infinity: there's a nasty kmail bug on the candidate images and I think I'd like to respin, can I do that now from the iso tracker?
[14:15] <infinity> Riddell: Yup.
[14:19] <Riddell> infinity: remind me again how?
[14:19] <Riddell> ooh I see a button
[14:20] <Riddell> groovy, rebuilding
[14:25] <slangasek> infinity: when you respun for the kernel update last night, do you happen to know what build # ubuntu-gnome was at?  Because a problem turned up later where the tracker listed a version that had never been built (no log on nusakan, etc)
[14:25] <slangasek> dunno if that was because someone manually fiddled, or because the rube goldberg failed
[14:26] <infinity> slangasek: No idea.  I just clicked the boxes and mashed the button.
[14:26] <slangasek> ok
[14:26] <infinity> slangasek: Logs would be potentially enlightening, and cjwatson and stgraber might care about the above result.
[14:26] <slangasek> infinity: logs of what?
[14:27] <infinity> slangasek: Oh, you said there were no logs on nusakan for that build?  Fun.
[14:27] <slangasek> right
[14:27] <infinity> slangasek: So, this is all stgraber, I guess.
[14:27] <slangasek> stgraber: ^^ fyi, this is all in scrollback from yesterday too (around 1am BST)
[14:30] <mlankhorst> is lts-raring in -updates yet?
[14:31] <jbicha> 0723 was the regular cronjob, 0723.1 was the one for the kernel rebuild (but amd64 didn't have the new kernel and the .manifest was outdated), 0723.2 was the phantom rebuild darkxst triggered last night to correct that (it was announced in this channel but never showed up), finally fixed by 20130724
[14:41] <infinity> mlankhorst: The kernel, or the whole stack?
[14:41] <infinity> mlankhorst: http://people.canonical.com/~ubuntu-archive/pending-sru.html will tell you that the stack is still in proposed.
[14:42] <stgraber> qatracker=> SELECT qatracker_build.id, qatracker_product.title, users.name, qatracker_build_milestone.date, qatracker_milestone.title FROM qatracker_build LEFT JOIN qatracker_build_milestone ON qatracker_build_milestone.buildid=qatracker_build.id LEFT JOIN qatracker_product ON qatracker_product.id=qatracker_build.productid LEFT JOIN users ON users.uid=qatracker_build_milestone.userid LEFT JOIN qatracker_milestone ON qatracker_milestone.id
[14:42] <stgraber>   id   |           title            |  name   |        date         |     title
[14:42] <stgraber> -------+----------------------------+---------+---------------------+---------------
[14:42] <stgraber>  49691 | Ubuntu GNOME Desktop i386  | darkxst | 2013-07-23 20:16:03 | Saucy Daily
[14:42] <stgraber>  49691 | Ubuntu GNOME Desktop i386  | darkxst | 2013-07-23 19:26:56 | Saucy Alpha 2
[14:42] <stgraber>  49690 | Ubuntu GNOME Desktop amd64 | darkxst | 2013-07-23 20:16:03 | Saucy Daily
[14:42] <stgraber>  49690 | Ubuntu GNOME Desktop amd64 | darkxst | 2013-07-23 19:26:56 | Saucy Alpha 2
[14:42] <stgraber> (4 rows)
[14:43] <stgraber> slangasek: so it looks like darkxst manually added 20130723.2 to the tracker, the timing is a bit odd though
[14:43] <stgraber> slangasek: anyway, that's not my script as it'd have shown up as ubuntu-cdimage otherwise
[14:45] <mlankhorst> infinity: the stack parts
[14:46] <slangasek> stgraber: AIUI infinity launched the rebuild and it didn't show up
[14:46] <slangasek> stgraber: n/m, looking at scrollback, infinity's rebuild was 20130723.1
[14:47] <slangasek> so I don't know why darkxst wanted 20130723.2, or why he added it manually
[14:48] <mlankhorst> infinity: yeah I marked it as verification-done now because I've been running it locally for a while :-)
[14:49] <infinity> mlankhorst: Alright.  I'll try to have a look at that all later.
[18:07] <Riddell> is there a current list of flavour leads?  the ReleaseManifest pages don't exist any more and I don't think it can be taken out of iso tracker?
[18:32] <phillw> there is somewhere, but I can't find it at the moment :/
[19:49] <infinity> Riddell: http://iso.qa.ubuntu.com/qatracker/series/37/manifest ?
[19:57] <Riddell> infinity: ooh that website is a mine of cool stuff now
[20:02] <infinity> Riddell: Linked from the front page on the series list, FWIW.
[20:02] <infinity> "Milestones for 'Saucy' series (product manifest | testsuites)"
[20:02] <infinity> etc.
[21:05] <phillw> A quick question.. there was a kernel release yesterday that got into the alpha 2 re-build for lubuntu, uname -a reports me as having 3.10.0-0-generic but bug 1204005 reports 3.10.0-5 has there been an interim kernel release?
[21:05] <ubot2`> Launchpad bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged] https://launchpad.net/bugs/1204005
[21:06] <slangasek> phillw: are you testing on powerpc?
[21:07] <phillw> slangasek: nope, I'm on amd64
[21:07] <slangasek> hmm
[21:07] <phillw> slangasek: ahh, let me just check if my own system has been updated... (egg on face)
[21:08] <phillw> I'm smoke testing 13.10 :)
[21:09] <phillw> sorry, there are updates for my host machine :/
[21:10] <phillw> I'll update and add an 'affects me' to the bug once I confirm it still happens.
[21:12] <phillw> oh,  a kernel developer is on the case, so an affects me will simply subscribe me. Thanks, slangasek
[21:12] <slangasek> sure
[21:23] <phillw> slangasek: sorry to be back, but apt-get upgrade is telling me that it is holding back (amongst others) linux-generic linux-headers-generic linux-image-generic would you know why?
[21:24] <slangasek> because apt-get upgrade is the wrong tool
[21:24] <slangasek> you should be using apt-get dist-upgrade
[21:24] <phillw> thank you, will add that to the wiki page :)
[21:25] <slangasek> what wiki page?
[21:25] <phillw> for how to do upgrades when smoke testing ubuntu+1
[21:26] <slangasek> "what wiki page" - please tell me the url
[21:26] <phillw> the page is going to be written tonight :)
[21:26] <slangasek> hmm
[21:26] <phillw> I don't like to keep coming here asking you guys stuff.
[21:27] <slangasek> I find it hard to believe that there aren't existing wiki pages that cover this stuff... or should do so
[21:28] <phillw> slangasek: I will look, as https://wiki.ubuntu.com/Testing/Testing_The_Devlopment_Release is a header page holding links to others.
[21:29] <phillw> (as is it's parent page)
[22:29] <darkxst> stgraber, yes I manually added ubuntu GNOME  20130723.2 via tracker but the images never showed up on cdimage. ( 20130723.1 still had a broken kernel)
[22:44] <slangasek> darkxst: manually adding is not how you trigger a rebuild
[22:45] <slangasek> darkxst: you should be using the 'request a rebuild' option at the bottom of http://iso.qa.ubuntu.com/qatracker/milestones/299/builds
[22:45] <darkxst> slangasek, manually as in through tracker admin page?
[22:46] <darkxst> oh never saw the box at the bottom there


[09:24] -queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (bionic-proposed) [2.42+18.04.1]
[09:25] -queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42+18.04 => 2.42+18.04.1] (no packageset)
[09:26] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.42+18.04.1]
[09:30] <juliank> Laney: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/344818
[09:30] <Laney> ♥
[14:03] -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.4 => 0.32~16.04.5] (no packageset)
[15:00] -queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.5 => 1.34.0-0ubuntu8.6] (no packageset)
[15:31] <bdmurray> infinity: Should bug 1767610 about an .img file on releases.ubuntu.com be addressed?
[17:18] <sil2100> cyphermox: hey! Could you take a look at https://bugs.launchpad.net/maas/+bug/1437353 and say if the verification provided is enough to make sure the bug is fixed and no regressions introduced?
[17:19] <sil2100> Since without context the verification comment doesn't give me enough information about whether it was tested against the affected hardware
[17:20] <sil2100> cyphermox: I suppose you might have a better idea if that's indeed enough
[17:25] <cyphermox> sil2100: hard to say, I can't test this on my own
[17:25] <cyphermox> sil2100: I read at the end of their comment "Our CI completed successfully with this."; I expect this means they ran the test
[17:26] <cyphermox> ie booted on a system that would otherwise be affected
[17:26] <cyphermox> I'm asking...
[17:26] <sil2100> cyphermox: ok, hm, let me try getting clarification if the system had the required hardware
[17:26] <sil2100> Ok
[17:26] <sil2100> If you're doing that then excellent
[17:29] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (artful-proposed) [1.169.4]
[17:38] <bdmurray> sil2100: Can you do anything about bug 1767610?
[17:39] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.18]
[17:39] <sil2100> bdmurray: looking
[17:45] <sil2100> bdmurray: hmm, I guess I could try that, should just be a matter of removing the symlink and refreshing the md5sum files
[17:46] <sil2100> I'll look into that later today or tomorrow in the morning though since I was about to move for some dinner now
[17:46] <sil2100> Wonder how that symlink got created in the first place
[17:47]  * sil2100 suspends temporarily
[18:02] <infinity> bdmurray: Having the .iso duplicated at a .img was a Mark request many releases ago.  It's been like that since xenial.
[18:02] <infinity> bdmurray: Not saying I agree with it (nor that I'm sure he'd notice if I rolled it back and pretended it never happened), but yeah, hardly new.
[18:06] <bdmurray> infinity: ah okay
[20:19] -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.5]
[23:48] -queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu6 => 3.28.0-2ubuntu7] (ubuntugnome)


[00:52] <Eickmeyer> vorlon: Figured out the ubiquity issue. Even though it was reported as a permissions problem in the logs, it was really whining about not having a slideshow🤦: https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/2008731/comments/5
[00:52] -ubottu:#ubuntu-devel- Launchpad bug 2008731 in ubiquity-slideshow-ubuntu (Ubuntu) "Edubuntu needs slideshow - Ubiquity crashes without it" [Critical, Triaged]
[00:53] <Eickmeyer> (logs were less than helpful)
[00:53] <Eickmeyer> arraybolt3: ^
[00:54] <arraybolt3> Eickmeyer: I don't see how that's possible, Xubuntu Minimal (formerly Xubuntu COre) has been working perfectly fine without a slideshow for a while.
[00:54] <arraybolt3> (I was the main tester for Xubuntu Core last cycle, and have never seen a slideshow in it.)
[00:54] <Eickmeyer> arraybolt3: I don't know. All I know is I installed a slideshow in the live session, and installation worked fine.
[00:54] <arraybolt3> Oh weird.
[00:55] <arraybolt3> I mean I guess we're going to have a slideshow eventually, so no big deal?
[00:55] <Eickmeyer> I'm working on resurrecting the old edubuntu one now so there's at least *something*.
[01:00] <arraybolt3> jbicha: Thanks for the suggestion about python3-distro, I have confirmed that it should do exactly the job needed and am testing Lubuntu's installer with it now.
[02:55] <arraybolt3> Does anyone know of a good alternative to apt-cacher-ng? For some reason it's horribly unstable on my Jammy laptop - it will download about 20 packages if they're missing from the cache and then give 503 errors for everything else. I can run "sudo systemctl restart apt-cacher-ng" and then do another sbuild and another 20 packages or so will download, and then a bunch of 503 errors.
[02:56] <arraybolt3> (On Kinetic this happened sometimes, but much more rarely.)
[02:56] <sarnold> arraybolt3: squid-deb-proxy has been way more reliable than apt-cacher-ng for me
[02:57] <arraybolt3> K, I'll look into it. This is almost unusable.
[02:57] <sarnold> I found it unusuable, yes
[02:59] <arraybolt3> sarnold: Is there a good setup guide for squid-deb-proxy?
[02:59] <arraybolt3> (I don't want to start installing things haphazardly and end up with broken apt or worse, no Internet :P)
[03:01] <arraybolt3> Meh, it looks simple enough.
[03:02] <sarnold> arraybolt3: heh, good question. I set it up so long ago I can't recall much about the initial setup; the recurring problem is /etc/squid-deb-proxy/mirror-dstdomain.acl.d/* -- I had to set up private-ppa.launchpadcontent.net and esm.ubuntu.com since those (weren't? aren't?) in the default policies, and every time my archive mirror gets a new IP address because my home router is just the worst, I have
[03:02] <sarnold> to add the new IP address in a file in there..
[03:03] <sarnold> One Of These Days [tm] I'm going to get all my 'real' computers on static IPs and there will be puppies and unicorns for all
[03:08] <arraybolt3> Hey, this is relatively straightforward so far!
[03:13] <JackFrost> Unfortunately I find acng to be the best, but I use apt-cacher-ng-3.7.4+really3.6.4 :P
[03:13] <arraybolt3> Hah, so something happened in 3.7.4 that ruined it?
[03:17] <arraybolt3> Wow, I am making one config file boffo after another here :P
[03:20] <arraybolt3> sarnold: Could you share your /etc/squid-deb-proxy/mirror-dstdomain.acl? I cannot figure out how to get it to accept the mirror-dstdomain.acl.d directory.
[03:20] <arraybolt3> (I mean I probably could figure it out eventually but you're right here :P)
[03:22] <sarnold> arraybolt3: with the warning that these have grown over time organically... https://termbin.com/9vqn
[03:22] <arraybolt3> No, I wanted the non .d file so I could figure out how to get the directory added.
[03:22] <arraybolt3> I have plenty in the directory, I just can't figure out how to get the directory to be recognized.
[03:23] <arraybolt3> Oh, wait, there it is.
[03:23] <arraybolt3> Wait... you still have the line commented out?
[03:23] <sarnold> hmm, I wonder if it requires a restart to regenerate the configs?
[03:23] <arraybolt3> I restart it every time I change something.
[03:24] <arraybolt3> There was a line I uncommended that you have commented, that's probably the problem.
[03:24] <arraybolt3> Bah. It's ignoring my entire include directory.
[03:24] <sarnold> heh, I think that's 100% a documentation line..
[03:27] <arraybolt3> Yeah, it just is ignoring mirror-dstdomain.acl.d.
[03:27] <arraybolt3> It just gives me 403 Forbidden errors.
[03:27] <arraybolt3> For everything that isn't in the main file, but in the directory instead.
[03:29] <arraybolt3> Found it.
[03:29] <arraybolt3> I had the wrong proxy port set.
[03:29] <arraybolt3> I was trying to access port 8000, I needed to access 3128.
[03:31] <sarnold> aha! :)
[03:31] <arraybolt3> Though now it's even working for sites that I *don't* have set as allowed???
[03:31] <sarnold> hmmm. I wonder if then you've got a 'usual' squid running? o_O
[03:32] <arraybolt3> deb.tuxedocomputers.com should not be allowed yet since I forgot to add it, yet there it is.
[03:32] <arraybolt3> sarnold: Maybe, lets find out.
[03:33] <arraybolt3> Hah, I did in fact have two copies of squid running!
[03:33] <sarnold> that might be worth a bug report; it seems surprising
[03:33] <arraybolt3> Nah, user error.
[03:33] <sarnold> ah good good
[03:33] <arraybolt3> "sudo systemctl restart squid" != "sudo systemctl restart squid-deb-proxy"
[03:34] <sarnold> ahhhhh yeah. I have to imagine I've done that myself.
[03:35] <arraybolt3> Very good. Now it lets through everything I put in and blocks everything I failed to put in :P \o/
[03:36] <sarnold> JackFrost: what I don't understand is that you're not the only one I've talked with who's had better success with acng than with squid-deb-proxy, but I've seen acng give 503s and hash-sum mismatches and file-size mismatches dozens of times over the years. Why does it work okay for some people and not at all for others?
[03:37] <sarnold> JackFrost: and squid has been around for decades as a solid reliable tool that folks forget even exists .. so why does it *not* work for those same people? :)
[03:40] <JackFrost> Rule of "least terrible", not "actually works great" :P
[03:40] <sarnold> ahhhhhhhh
[03:41] <arraybolt3> I'm thankful there's just some other solution that acng, it was getting to the point where I was actually starting to consider doing `while [ true ]; do sudo systemctl restart apt-cacher-ng; sbuild -d lunar-amd64-shm; done`
[03:42] <arraybolt3> Which I'm only now realizing might have left me in a hopeless loop :P
[03:42] <arraybolt3> **DO NOT RUN THE ABOVE COMMAND**
[03:42] <arraybolt3> Probably should have added a counter or something before doing that.
[03:43] <sarnold> arraybolt3: I'm 80% sure I did something similar and it kept corrupting files that it had already downlaoded
[03:43] <arraybolt3> Oh fine.
[03:44] <arraybolt3> Alright, I finally have everything set up right. Now to get all of my sbuild containers to use it.
[04:11] <Eickmeyer> Your first mistake was "while true; do ... done".
[04:13] <arraybolt3> :P
[07:38] <cpaelzer> dannf: now that I understood the case better we have several ways to overcome the momentary test issue, I have filed bug 2008865 and assigned you to pick one
[07:38] -ubottu:#ubuntu-devel- Bug 2008865 in qemu (Ubuntu) "edk2 autopkgtest spotted a real issue, still we need to mitigate for now" [Undecided, Confirmed] https://launchpad.net/bugs/2008865
[07:54] <adrien> can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=llvm-toolchain-13&trigger=ocaml%2F4.13.1-4ubuntu1 ? it's llvm-toolchain tests on arm64 for ocaml and it failed due to the testbed not being ready in time; it's probably the (actual) last test blocking ocaml stuff (at least that I can spot) and hopefully, by the time it runs, runners won't be overloaded
[07:54] <adrien> anymore at all
[08:09] <tjaalton> what does it need to be able to re-run failed autopkgtests? some team membership besides core-dev/motu?
[08:18] <adrien> when I attempt to do so, the service tells me "You submitted an invalid request: You are not allowed to upload llvm-toolchain-13 or ocaml to Ubuntu, thus you are not allowed to use this service."
[08:20] <tjaalton> oh, so it's tied to upload rights
[08:20] <adrien> I think it makes sense (I also think it's frustrating :D )
[11:01] <danilogondolfo> May I ask someone to run this test for me, please? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=pycurl&trigger=curl/7.88.1-1ubuntu1&trigger=pycurl/7.45.2-3
[11:05] <ginggs> danilogondolfo: .
[11:05] <danilogondolfo> thanks ginggs
[11:47] <bluesabre> vorlon: I've got an easy, low-priority item if you want: https://code.launchpad.net/~xubuntu-website/+git/xubuntu-cdimage-css/+ref/master Some minor tweaks to the Xubuntu cdimage css to improve the minimal image and oversized files
[11:55] <bluesabre> vorlon: This one too: https://code.launchpad.net/~bluesabre/ubuntu-cdimage/+git/ubuntu-cdimage/+merge/438004 (sorry for all the tags and things I'm sending your way)
[14:03] <ogayot> Hi, could somebody retry the pycirkuit autopkgtests for me please? Thanks!
[14:04] <ogayot> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=pycirkuit&trigger=m4%2F1.4.19-3
[14:04] <ogayot> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=pycirkuit&trigger=m4%2F1.4.19-3
[14:04] <ogayot> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=pycirkuit&trigger=m4%2F1.4.19-3
[14:04] <ogayot> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=pycirkuit&trigger=m4%2F1.4.19-3
[14:31] <jbicha> ogayot: done
[14:33] <ogayot> jbicha: thanks!
[14:44] <enr0n> Can a core dev please retry the tests blocking libio-socket-ssl-perl (retry-autopkgtest-regressions -s lunar --blocks libio-socket-ssl-perl)? The libhttp-daemon-ssl-perl test passed for me locally on amd64. The failures from other packages look like test bed failures.
[16:19] <vorlon> bluesabre: marking as reviewer is preferable to irc pings, as it gets into a persistent queue :)
[16:22] <bluesabre> vorlon: I added you as a reviewer for ubuntu-cdimage. I don’t think the css has a public branch I can submit a MR for (or does it somewhere?)
[16:22] <bluesabre> Thanks for the review!
[16:23] <vorlon> bluesabre: oh, I guess that one doesn't need review, because that's the branch we pull from!
[16:24] <vorlon> bluesabre: pulled
[16:25] <bluesabre> vorlon: Thanks a bunch!
[17:09] <rbasak> vorlon: marking as reviewer> you mean like https://code.launchpad.net/~racb/ubuntu-archive-tools/+git/ubuntu-archive-tools/+merge/429629? :-P
[17:54] <vorlon> rbasak: I thought we agreed to move that to ubuntu-archive-scripts? :)
[17:55] <vorlon> rbasak: also I said it went into a persistent queue, I didn't say the queue ever emptied
[17:55] <vorlon> (because it's actually a horrible cross between a queue and a stack, enjoy)
[19:00] <rbasak> Ah yes we did, sorry
[19:12] <adrien> I initially thought llvm-toolchain-13 failures on arm64 were testbed/setup issues but there seems to be a number of dumped code
[19:12] <adrien> core*


[19:17] <raevol> is jono's website down?
[19:25] <dragon> yes, jono is down.
[19:36] <raevol> daw
[21:53] <raevol> whoever the hell decides to change all the default directories for everything when packaging stuff should AT LEAST document it somewhere
[21:53] <raevol> ugh
[22:30] <akk> Document changes? What a quaint notion.
[22:45] <grantbow> Interesting. Google Nexus 7 is $199 1280x800 1G RAM 16 GB flash w/ tegra 3 quad core processor. http://www.google.com/nexus/7/specs/
[22:45] <darthrobot> Title: [Nexus 7 Tech Specs]
[22:46] <grantbow> Lenovo Ideatab is $159 of best buy 1024x900 512 MB RAM 8GB flash http://www.bestbuy.com/site/Lenovo+-+IdeaTab+A2107+Tablet+with+8GB+Memory+-+Black/6668354.p?id=1218771804144&skuId=6668354&st=lenovo%20g585&cp=1&lp=6
[22:46] <darthrobot> Title: [Lenovo - IdeaTab A2107 Tablet with 8GB Memory - Black - A2107 - 59346799]
[22:47] <grantbow> manufacturers try to mix up RAM and flash now
[22:48] <akk> Good price. Funny that they don't even mention the size -- that seems critical for a tablet.
[22:48] <grantbow> for comparison: zareason zatab is $299 1024x768 1G RAM 16 G flash http://zareason.com/shop/zatab.html
[22:48] <darthrobot> Title: [Open & Hackable Android tablet]
[22:49] <grantbow> Allwinner A10 SoC not a quad core
[22:49] <grantbow> err, $349, ouch
[22:50] <grantbow> I do like mine and I've had it awhile
[22:59] <akk> I like supporting za, but sometimes it's hard to justify financially.
[22:59] <akk> It's sad that it always costs more to buy the free OS version of something.
[23:09] <grantbow> darn M$FT related kickbacks
[23:11] <akk> yeah
[23:12] <pleia2> both android and ubuntu are free OSes ;)
[23:12] <pleia2> Google's able to get away with it by selling at a loss to get their content out there (Amazon and B&N do the same with their e-readers)
[23:13] <pleia2> ZA needs to make a living on the actual hardware
[23:15] <pleia2> and actually... zatab comes with android too
[23:21] <akk> za lacks the economies of scale that the big manufacturers have.
[23:27] <grantbow> I like my zatab as does everyone who sees it.


[12:20] -SwissBot:#xubuntu-devel- ::xfce-announce:: ANNOUNCE: ristretto 0.12.0 released @ http://www.mail-archive.com/xfce-announce@xfce.org/msg00630.html