[00:07] <poolie> Noldorin: no it doesn't
[00:07] <poolie> there is a bug for this
[00:07] <Noldorin> poolie, ah right. link at hand?
[00:08] <micahg> no, it just links it to the bug, fixed in bzr isn't fixed for most projects
[00:08] <poolie> https://bugs.launchpad.net/launchpad/+bug/318439
[00:09] <poolie> click 'affects' if you like
[00:09] <Noldorin> poolie, thanks. i'll follow that
[00:09] <Noldorin> no big deal for now
[00:09] <Noldorin> as long as i know
[00:10] <micahg> ah, that bug makes sense :)
[00:10] <Noldorin> sounds like a feature
[00:10] <Noldorin> not a fan of the solution either
[00:10] <Noldorin> (proposeD)
[00:10] <Noldorin> but oh well
[00:21] <poolie> which solution?
[00:46] <poolie> lifeless: does this actually mean O(one minute) downtimes?
[00:54] <lifeless> poolie: 300s is the initial window I have gotten an ack for
[00:54] <lifeless> poolie: thats the satisfying criteria
[00:55] <poolie> in the sense of our stakeholders could tolerate more frequent bumps if they're no more than 5m?
[00:56] <lifeless> yes
[00:57] <lifeless> we all want as low as possible
[09:22] <pfarrell> how is the code update going? :-)
[09:23] <dupondje> seems done :)
[09:23] <wgrant> Not quite.
[09:23] <wgrant> Half-way back up.
[09:25] <pfarrell> cool, good luck with it :-)
[09:25] <dupondje> what happens with emails sent to launchpad? they get queued ?
[09:26] <wgrant> dupondje: Right.
[09:29] <wgrant> dupondje, pfarrell: Everything should be back now.
[09:29] <pfarrell> sweet, thanks
[09:30] <dupondje> wgrant: getting timeout error when trying to add patch in a bug
[09:30] <wgrant> dupondje: Do you have an OOPS ID?
[09:31] <dupondje> (Error ID: OOPS-2020CO69)
[09:31] <wgrant> Thanks.
[09:51] <dupondje> something broken ? ;)
[09:56] <dupondje> wgrant: its broken ? :)
[09:56] <lifeless> yes, should be fixed in a minute
[09:57] <wgrant> dupondje: Sorry, yes, in the middle of the fix.
[10:00] <dupondje> aight :D
[10:00] <dupondje> great service
[10:00] <dupondje> :)
[10:26] <apw> any known issues with the launchpad API since the upgrade?  getting "HTTP Error 503: Service Unavailable" from scripts that worked yesterday
[10:27] <wgrant> apw: We have some DB load issues at the moment. Not quite sure if they'll settle down on their own.
[10:27] <apw> wgrant, so keep hammering it until they work :)
[10:27] <wgrant> Something like that...
[10:28] <lifeless> apw: 16 core machines w/128GB of RAM are a little hard to come by on short notice
[10:28] <apw> lifeless, i am sure they are, though i am also sure you didn't release code which you expected to need another one either
[10:29] <wgrant> apw: Well, the normal master DB is getting a disk upgrade.
[10:29] <lifeless> no; so this isn't bad code - we're upgrading the disks on the master machine, so we're running degraded on the replicas
[10:29] <wgrant> apw: So one of the slaves has been promoted.
[10:29] <apw> wgrant, ok so assuming that the issue is just the slave is 'crap', how long is the outage going to be
[10:30] <lifeless> apw: we did anticipate some load (but as the replicas service many requests anyway, no degradation)
[10:30] <lifeless> apw: grab one of the oops ids and get wgrant to look at it; you may be suffering unrelated to load.
[10:31] <apw> lifeless, i am not getting an oops, just a 503 service unavailable responses via the zope api
[10:31] <wgrant> apw: That will have an OOPS ID.
[10:31] <wgrant> apw: Probably in the X-Lazr-OopsID header and the body.
[10:31] <apw> wgrant, ok will try and find it in the 2.5k of html thats its dumping on me :/
[10:32] <wgrant> Yay!
[10:32] <apw>         OOPS-2020CF91)
[10:32] <wgrant> Thanks.
[10:33] <wgrant> Ah, Ubuntu tag searches FTL :(
[10:34] <apw> wgrant, yep one of those painful scripts one has to run because searching in the interface can't find anything
[10:35] <wgrant> Can't find anything?
[10:35] <wgrant> Oh, the CVE FTI thing?
[10:35] <apw> wgrant, yep, the CVE titles don't match, closed development tasks, search issues
[10:38]  * apw notes that nominations have gotten worse, you used to be able to nominate up to two series, now even 1 is too many :/
[10:40] <apw> (Error ID: OOPS-2020DR100)
[10:41] <apw> any idea how long we are going to be degraded, so i know how long to schedule for lunch
[10:43] <wgrant> apw: Potentially up to a day, but we are trying to sort it out.
[10:43] <geser> apw: that will be a long lunch break :)
[10:44] <apw> well as i can't do anything anymore, i guess i have no choice
[11:12] <soren> Argh.. I get a timeout trying to see our PPA page: https://launchpad.net/~nova-core/+archive/trunk  (Error ID: OOPS-2020AS123)
[11:14] <soren> I appreciate you want to track it when things are slow, but I really do wish there was a way I could specify that what I'm trying to do is important to me, and that I'm ok waiting an extra couple of seconds for it.
[11:16] <soren> What I'm trying to say is that I'd rather have a slow Launchpad than no Launchpad at all.
[11:16] <chrisccoulson> hmmm, i'm getting a timeout consistently when trying to access https://code.edge.launchpad.net/~mozillateam
[11:16] <chrisccoulson> OOPS-2020EDGEA42 for example
[11:17] <soren> chrisccoulson: Works for me. (on non-edge)
[11:17] <chrisccoulson> soren, yeah, me too
[11:26] <spiv> soren: it's not just about tracking (we have soft timeouts that are also reported without aborting the page like hard timeouts), it's also about freeing up resources so that other requests aren't overly impacted by the slow parts.
[11:27] <cjwatson> Does anyone know why https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152 might be stuck in "Updating branch..."?  I pushed changes to it yesterday
[11:27] <spiv> (Part of the problem is that if something is slow, it's often *really* slow, more than just "an extra couple of seconds")
[11:37] <soren> spiv: For this particular case, the alternative was to retry 4 extra times before it finally worked. I can't imagine doing the first 9 seconds of each request 4 times is less costly and takes less resources from others than just letting the request run for 12 seconds or however much it would have been the first time around.
[11:38] <soren> ...and I doubt I'm the only one who routinely retries when I'm met by a timeout oops.
[11:39] <wgrant> soren: But then you get a really bad request which goes on for 5 minutes.
[11:40] <soren> wgrant: Maybe the 9 seconds (isn't that what the limit is?) are just a tad optimistic?
[11:40] <wgrant> soren: Around 0.01% of requests time out.
[11:41] <wgrant> soren: Today is special.
[11:41] <soren> wgrant: How so? caches not warmed up yet?
[11:41] <wgrant> (most of that 0.01% is ubuntu tag searches)
[11:41] <wgrant> soren: Our DB master is currently undergoing hardware upgrades, so we're running on inferior slave hardware.
[11:41] <wgrant> 8 cores rather than 16.
[11:42] <soren> wgrant: Oh.
[11:42] <wgrant> Didn't expect it to be quite this bad, though.
[11:42] <SteveExodus> i would like my money back ...
[11:45] <soren> wgrant: Perhaps put that in the /TOPIC or something? Just to help manage expectations.
[11:45] <soren> wgrant: I for one expected it was the code update that caused it and it would be this bad until the next major code update... Which would really suck.
[11:55] <tsarev> Hi there
[11:55] <tsarev> Guys, I have two troubles with launchpad
[11:55] <tsarev> http://img560.imageshack.us/img560/4340/screenshot1t.png - first
[11:55] <tsarev> http://jenkins.percona.com/view/Percona%20Server%205.1/job/percona-server-5.1-param/57/console - second
[11:55] <tsarev> Anybody able to help me?
[11:57] <bigjools> tsarev: yes I can help
[11:57] <tsarev> bigjools: great :)
[11:57] <bigjools> 1. the site is slow today as we are running on degraded hardware
[11:58] <bigjools> keep retrying
[11:58] <bigjools> 2. the output tells you what the problem is
[11:58] <bigjools> "bzr: ERROR: Not a branch: "/var/lib/jenkins/workspace/percona-server-5.1-param/".
[11:58] <tsarev> bigjools: about first - thank you
[11:58] <tsarev> bigjools: No-no, trouble ois before
[11:58] <tsarev> bigjools: bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~percona-dev/percona-server/5.1_slow_extended_tests_fixes/".
[11:58] <tsarev> bigjools: branch is available
[11:59] <tsarev> bigjools: http://jenkins.percona.com/view/Percona%20Server%205.1/job/percona-server-5.1-param/54/console
[11:59] <tsarev> bigjools: ^ here all ok with dir, but bzr branch not available
[11:59] <apw> wgrant, it occurs to me if the machine is half as fast would we not expect to have to proportionatly increase the timeout to match ?
[11:59] <bigjools> tsarev: use lp:~percona-dev/percona-server/5.1_slow_extended_tests_fixes
[12:00] <tsarev> bigjools: https://code.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes
[12:00] <tsarev> bigjools: I trying to build this branch
[12:00] <tsarev> bigjools: All other branch - clones, just for doublecheck what trouble not solved
[12:01] <tsarev> apw: http://bazaar.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes is permanently redirected to http://bazaar.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes/changes
[12:01] <tsarev> apw: Lines from log. Trouble on the launchpad side
[12:01] <bigjools> tsarev: use bzr+ssh:// or lp:
[12:02] <tsarev> bigjools: I used lp:~tsarev/percona-server/5.1_slow_extended_tests_fixes
[12:02] <tsarev> bigjools: in the log this is BZR_BRANCH enviroment variable
[12:02] <wgrant> apw: Not quite.
[12:02] <tsarev> bigjools: Before today all works fine.
[12:02] <bigjools> ok
[12:02] <tsarev> bigjools: We change nothing in our Jenkins
[12:03] <bigjools> the lp: url works fine for me
[12:03] <wgrant> apw: We are already fully utilising all CPU cores, so extending the timeout will just let even fewer requests work.
[12:03] <wgrant> It's not that it's slow.
[12:03] <wgrant> It's that we are over capacity.
[12:04] <wgrant> (so timeouts are fulfilling their goal here, but not quite enough)
[12:04] <apw> wgrant, and we are going to be in this state for 24 hours ?
[12:05] <bigjools> tsarev: ah you're using anonymous access
[12:05] <apw> i think that should definatly be in the topic
[12:05] <tsarev> bigjools: Yes. We allow anynimous access to our repos
[12:05] <bigjools> well I mean to LP's branch
[12:06] <bigjools> wgrant: could that be broken with this rollout?
[12:06] <wgrant> bigjools: Possibly. Just checking branch-rewrite now.
[12:06] <bigjools> I have to run out for a bit
[12:06] <wgrant> There should be maintenance people around :(
[12:06] <wgrant> I would like to leave at some point too.
[12:07] <bigjools> yes, who is on maint?
[12:07] <wgrant> Apparently nobody.
[12:17] <tim> hi, i am trying to backport gcc from oneiric to natty (mainly because of the c++0x support of gcc-4.6). it requires backporting of gcc-4.5 as well, because of a libgcc1 conflict. i got as far as uploading the package to launchpad, but launchpad doesn't start the build because of a g++ dependency conflict: http://pastie.org/2206841 ... any idea, what is going wrong? can i fix it myself, or is it simply not possible to build natty-
[12:17] <tim> provided gcc versions on launchpad?
[12:21] <wgrant> tim: You should try building it in a natty chroot/pbuilder/sbuild locally.
[12:21] <wgrant> tim: You can then diagnose the dependency issues.
[12:21] <wgrant> It's not Launchpad-specific.
[12:28] <tim> wgrant: ok will try to set up such an environment ...
[12:31] <tim> wgrant: however i wonder, why it complains about installing g++ >= 4:4.5.2-1ubuntu3 ... because natty seems to provide 4.5.2-1ubuntu4
[12:32] <wgrant> tim: It's saying that it can't install that combination of three packages.
[12:34] <wgrant> tim: It's likely that your gcc-4.6 backport has clobbered something to make gcc uninstallable in your PPA.
[12:36] <tim> wgrant: i see ... will try to find the reason ... otherwise i'll simply build gcc-4.6 from sources without creating a debian package
[13:05] <geser> tim: IIRC gcc-4.6 in oneiric has a breaks on gcc-4.5 which is newer than the version in oneiric which breakes the installation of gcc-4.5; this is known and hopefully fixed soon
[13:05] <wgrant> tsarev: That branch should be working again now.
[13:06] <tsarev> wgrant: Yes, I see already
[13:06] <tsarev> wgrant: THis was launchpad trouble?
[13:06] <wgrant> tsarev: Yeah, fallout from the rollout earlier.
[13:09] <wgrant> tsarev: Most stuff was still cached, but some new lookups weren't working.
[13:09] <wgrant> Like your branch.
[13:09] <tsarev> wgrant: Cool. I'm happy what you solve
[13:10] <tim> geser: i see ... will keep my eye on the gcc versions of oneiric
[13:33] <dpm> hi deryck, are you around and have got a minute for a translations sharing question?
[13:33] <deryck> dpm, on call, available shortly.
[13:34] <dpm> deryck, no worries, I can also ask henninge now that he's around
[13:34] <dpm> henninge, have you got a minute for a translations sharing question?
[13:34] <henninge> dpm: yes but I might get called in to the doctor's any time.
[13:34] <henninge> ;)
[13:35] <dpm> henninge, ok, we'll try to make it quick and painless then :)
[13:35] <dpm> so here it is:
[13:35] <dpm> I've created a table with the intltool-based source packages that will support upstream sharing, with the intention to give an overview and let the community help in enabling sharing:
[13:35] <dpm> https://wiki.ubuntu.com/Translations/Projects/LaunchpadUpstreamImports
[13:36] <dpm> (I need to remove some redundant fields to make it more readable, though)
[13:36] <dpm> As all of the projects are already linked to a source package, I understand that the next step is to enable translations in the upstream projects, and here is my question:
[13:36] <dpm> Given the following translation_usage in the upstream project, do these settings make sense as the ones to recommend?:
[13:36] <dpm> Projects with external translations:
[13:36] <dpm> • Permissions: Closed
[13:36] <dpm> • Translations group: does not matter
[13:36] <dpm> • Translation Import mode: templates + translations
[13:37] <dpm> Projects with translations in Launchpad:
[13:37] <dpm> • Permissions: Structured
[13:37] <dpm> • Translations group: Launchpad Translators/Ubuntu Translators
[13:37] <dpm> • Translation Import mode: templates only
[13:37] <dpm> henninge, so, does that make sense? ^^
[13:37] <henninge> dpm: those look good
[13:38] <henninge> dpm: maybe even suggest "Restricted" permissions?
[13:38] <henninge> dpm: AFAIK Ubuntu uses that setting nowadays
[13:38] <dpm> henninge, ah yeah, good point, my mistake, I wanted to actually suggest "Restricted", yes
[13:39] <dpm> regarding "Closed" permissions, can one still see the statistics?
[13:39] <henninge> dpm: other than that this looks sane
[13:39] <henninge> dpm: not sure.
[13:39] <henninge> If not, that'd be a bug I think.
[13:39] <dpm> henninge, ok, I guess we'll soon find out. Thanks!
[13:40] <henninge> dpm: pleasure
[14:20] <jam> is the branch scanner stopped, or did I just break it?
[14:20] <jam> I submitted this about an hour ago: https://code.launchpad.net/~jameinel/bzr/2.2-is-up-to-date/+merge/67836
[14:20] <jam> It is based on a fairly old version, but the actual changes are pretty small.
[14:23] <jam> I did do a "commit --unchanged" as the last commit, but I don't see why that would break anything
[14:25] <commandoline> hello, my translations aren't imported from the trunk branch. Does anyone know what the problem can be? https://translations.launchpad.net/openteacher/trunk/+imports
[14:29] <jam> danilos: ^^ any chance you can figure out why the diff is still "pending" after 45 minutes?
[14:41] <rye> hi all, is merge proposal diff generator working or there is a huge backlog of tasks? it's been 3 hours since mp submit :(
[15:04] <soren> Are new uploads not being accepted?
[15:05] <soren> I uploaded a package at 13:24 UTC which made it through just fine.
[15:06] <soren> Then I uploaded another one at 14:31 which, at 14:49 still hadn't shown up so I reuploaded it. Still no trace of it.
[15:06] <bigjools> danilos: ^
[15:07] <soren> The package is called "keystone", uploaded to ppa:soren/keystone
[15:10] <cyberdeck> hi, how long does it usually take until you get an accept/reject mail after uploading some source.dsc to your own launchpad ppa?
[15:10] <cyberdeck> *uploaded with dput
[15:10] <bigjools> there's a problem at the moment it seems
[15:10] <bigjools> looking into it
[15:10] <Logan_> I can't get a public key. :|
[15:11] <cyberdeck> is there any kind of upload/incoming queue where one can take a look at? (sry for the newbie question)
[15:12] <Logan_> nvm
[15:13] <bigjools> cyberdeck: there isn't
[15:13] <cyberdeck> oh, ok. thank you!
[15:13] <bigjools> I think there's just a massive backlog at the moment
[15:13] <soren> cyberdeck: Under normal operations, things don't sit there for more than at the most 5 minutes.
[15:14] <bigjools> there were performance problems earlier and it slowed the upload processor down
[15:14] <cyberdeck> well, i got a reject mail after my first upload pretty soon. then i corrected the error and uploaded again. now, after my fourth coffee i started to wonder if it got lost.
[15:14] <bigjools> ah no it looks like someone uploaded a load of language packs
[15:15]  * soren shakes his fist at language packs
[15:15] <bigjools> be patient, it'll get there
[15:15] <cyberdeck> i'll try. even if its my first ppa upload. ^^
[15:16] <bigjools> I think it'll be about 20-30 minutes before the langpacks are done with
[15:17] <bigjools> (my finger in the air guesstimate)
[15:26] <danilos> jam: there were a few issues with some of the branch scripts, hopefully will get resolved soon
[15:32] <bigon> hi, an idea why I get a timeout? OOPS-2020D184
[15:34] <soren> bigjools: Yup, here they come.
[15:34] <soren> \o/
[15:34] <bigjools> hurray
[15:37] <cyberdeck> yay, in 52 min. my first ppa upload ever will be build. \o/
[15:37] <bigjools> congrats
[15:42] <timrc> Hello, is there a way I can get details on who copied a package into a PPA from the UI (I'm looking for a culprit, not the original uploader)?
[15:43] <bigjools> timrc: no, that's not recorded unfortunately
[15:43] <timrc> bigjools, bummer
[15:44] <timrc> bigjools, that's a particularly useful bit of information if the ppa sits upstream of another archive
[15:44] <bigjools> timrc: file a bug!
[15:49] <timrc> bigjools, oh I will
[15:49] <timrc> :)
[15:49] <candrea> Hello! Could somebody please help me with https://answers.launchpad.net/launchpad/+question/164646 ? It's not very urgent, but the sooner it is solved, the better
[15:49] <timrc> Maybe another opportunity for me to chip-in as well
[15:51] <timrc> bigjools, out of curiosity, can you find the info via the api? (e.g. is this just a case of not be supporting in the UI?)
[15:51] <bigjools> timrc: no, it's not recorded anywhere
[15:52] <bigjools> although some changes I am doing right now to make copying asynchronous could help
[15:53] <timrc> bigjools, okay I'll file the bug and assess if finding a solution is within my capability-bounds :)
[15:54] <bigjools> timrc: well, there's an easy way and a better way
[15:58] <timrc> Really, what I'm trying to solve are collisions that occur in a downstream archive as a result of people submitting packages with the same name / version but different hashsums from more than one location
[15:58] <timrc> If we could provide the URL to the immediate downstream archive, we could do this detection early... but it sounds like opening a can of worms :)

[15:59] <dpm> deryck, henninge, I'm doing a presentation on upstream sharing in a few minutes on #ubuntu-classroom, as part of Ubuntu Developer Week. (just a heads up if you're interested, no need to be there)
[16:00] <deryck> dpm, great.  Thanks for the heads up!
[16:09] <danilos> candrea, hi, I am not sure what is going on there, I'm looking around
[16:10] <candrea> thank you danilo
[16:15] <Ampelbein> hi there, I just got OOPS-2020DW183 while filing a bug via the api.
[16:38] <zyga> HI
[16:39] <zyga> is there a way to extend the dreaded launchpad timeout?
[16:39] <zyga> I keep getting a problem when trying to copy _ONE_ package from a ppa
[16:39] <zyga> (Error ID: OOPS-2020B220)
[16:42] <danilos> candrea, I can confirm the problem happens with "bzr branch" with "bzr-hg" plugin installed as well, so I suspect that's where the bug is
[16:42] <sladen> could somebody check the LP database.  Have a user<EMAIL_ADDRESS>trying to reset their password
[16:43] <sladen> but when I try subscribing them to a bug report using that email address it is also not found, so it might not be the right one
[16:43] <danilos> zyga, if it is stopping people from doing work, we can certainly do that
[16:43] <candrea> danilos, thanks, I'm opening a new bzr-hg bug right now
[16:43] <zyga> danilos, well it is stopping me now
[16:43] <danilos> candrea, I've already did that based on the question
[16:44] <candrea> danilos, ah, great thanks!
[16:44] <zyga> plars, attempts to copy any packages at https://launchpad.net/~linaro-validation/+archive/ppa/+copy-packages fail with a timeout
[16:45] <zyga> danilos, how can I request a timeout "extension"
[16:47] <danilos> zyga, I am not sure, we'd have to talk to the powers that be and investigate how frequently does the OOPS hit our users like you
[16:47] <danilos> zyga, (and figure out the right override or fix the problem)
[16:48] <plars> danilos: zyga's trying to get through this right now and it's blocking him, is there someone in particular we should talk to
[16:48] <zyga> danilos, well right not it hits me each time I try to copy one package to the same ppa (just different series) and this seriously affects my work, is there a chance to get this resolved quickly?
[16:48] <danilos> zyga, I am also waiting for an OOPS to sync to compare with bug 575450
[16:49] <zyga> danilos, the bug description sounds about right, I think it is the same issue
[16:51] <plars> zyga, danilos: last comment on that bug seems to indicate it is believed to be fixed
[16:51] <danilos> zyga, plars: right, which is why I need to wait for OOPS to sync before I can comment further; zyga, for urgent work-arounds, you can talk to lifeless or flacoste perhaps
[16:52] <zyga> danilos, how soon will we know that the OOPS is indeed bug 575450, what's the next step if that is the case?
[16:53] <danilos> zyga, hopefully in less than 30 mins
[16:53] <zyga> danilos, I'd like to have those packages for my ubuntu-developer-week session at 19:00 UTC
[16:53] <danilos> zyga, also, it's possible that upping the timeout won't help since the query might be taking minutes!
[16:54] <zyga> danilos, minutes!
[16:54] <flacoste> zyga: we are experiencing degraded performance currently because of a DB reconfiguration issue
[16:54] <zyga> oh
[16:54] <flacoste> so that doesn't help that particular issue
[16:54] <danilos> zyga, I am just saying that when something is bad, it can be very bad, but without seeing the OOPS report, we don't know if it's fixable
[16:54] <zyga> ok
[16:54] <danilos> flacoste, oh, I thought that was reported fixed (at least it was on identi.ca/launchpadstatus)
[17:45] <bryceh> When I try to land https://code.launchpad.net/~bryce/launchpad/cronjob-component-deletion/+merge/67782 I get this error:
[17:45] <bryceh> ec2: ERROR: Merge proposal is not approved. Get it approved, or use --force to land it without approval.
[17:46] <bryceh> however the review status is approved, so I'm confused.
[17:56] <bac> bryceh: each reviewer has a review status but then the MP as a whole has a status
[17:56] <bac> yours is still in 'needs review'
[17:56] <bac> it doesn't transition automatically b/c different projects have different requirements as to how many individual approves are required
[17:56] <bryceh> bac, ok, how does that get changed?
[17:56] <bac> bryceh: for LP it is just one and you are free to change the status yourself
[17:57] <bryceh> bac, no that option doesn't appear in the status dropdown for me
[17:57] <bac> bryceh: ok, i'll do it for you
[17:58] <bac> bryceh: done.  if you remember, ask your reviewer to be sure to do it next time
[17:58] <bryceh> I see just 'Work in Progress'/'Needs review'/'Merged'
[17:59] <bryceh> bac, I seem to recall I used to be able to set branches to approved when I was on the bugs team; what has changed that I can no longer do so?
[18:01] <bac> bryceh: you have to be a member of ~launchpad-reviewers.
[18:02] <bryceh> bac, ah ok thanks
[18:06] <bryceh> bac, guess that team is closed to community contributors
[18:07] <bac> bryceh: no, we decided to allow community contributors to become launchpad reviewers.  but then we hired the only person who had expressed interest.
[22:35] <pkern> The latest apt update links to LP: #784473.  Does LP claim that a page doesn't exist when privileges are missing nowadays?  I get OOPS-2020CI278 when I try to access it.
[22:38] <lifeless> pkern: yes
[22:39] <pkern> lifeless: Interesting that MOTU isn't enough.  But ok, thanks.
[22:39] <lifeless> pkern: partial disclosure is very hard to do reliably - we found some paths to inappropriate disclosure due to the older behaviour
[22:39] <lifeless> pkern: and we closed it the most expedient way; we -may- revisit it later
[22:40] <lifeless> pkern: its probably a security bug, which ~ubuntu-security is needed for
[22:40] <lifeless> pkern: I imagine it will be unembargoed once all the series are updated
[22:40] <lifeless> pkern: (I also cannot see it)
[22:41] <wgrant> pkern: It's a security bug, yeah.
[22:41] <pkern> Ah, if it's unembargoed afterwards, that's ok.  I guess the Debian security team is already aware of it, I was just checking the issue.  I also searched for the CVE and there was no bug reference, so I wondered quite a bit. ;)
[22:41] <wgrant> Debian is aware, yes.


[00:08]  * StevenK nails _mup_ to the channel.
[00:18] <wgrant> cjwatson: That looks good.
[00:19] <wgrant> cjwatson: indices look as expected.
[00:20] <cjwatson> great.  where should I look on mawson?
[00:23] <cjwatson> ah, deribuntu/baleful by the looks of things
[00:24] <wgrant> cjwatson: Oh, forgot you had access to mawson.
[00:25] <cjwatson> agreed, that looks cromulent to me
[00:25] <wgrant> cjwatson: Indeed, that's the one I tried. As we don't have any oneiric on there at the moment.
[00:25] <cjwatson> admittedly only a single package but should be fine
[00:25] <cjwatson> I think I whined a few years back until I got it
[00:25] <cjwatson> I wonder why Translations-en is only uncompressed + gzip
[00:26] <cjwatson> maybe should add bzip2 versions at some point, but we'll see how things look in production
[00:26] <cjwatson> ah, need to set Translation::Compress for that
[00:26] <cjwatson> OK.  I think this is good though.  Shall I tell lamont to roll that out to production?
[00:27] <wgrant> I can throw in a few more packages if you want, but I think this seems to work.
[00:27] <wgrant> Please do.
[00:27] <wgrant> Even if it does happen to break on prod, it's going to be pretty obvious within two hours.
[00:28] <cjwatson> I'm fine with that.  I'll be watching shortly after I flick the switch anyway
[00:31] <wgrant> Yep.
[00:31] <cjwatson> RTificated
[00:32] <wgrant> Ah, you exposed it through the API?
[00:32] <wgrant> Handy.
[00:35] <cjwatson> Yup.  You suggested that. :-)
[00:41] <lifeless> wgrant: you're rolling back the db-devel patch ?
[00:41] <lifeless> wgrant: what revno is being reverted?
[00:41] <wgrant> lifeless: Yes, just checking up on what qa-tagger is going to do.
[00:41] <wgrant> 10978
[00:47] <lifeless> mail sent about it
[00:47] <wgrant> Thanks.
[00:47] <wgrant> There seems to be a lot of inclarity over how things work now.
[00:52] <lifeless> wgrant: feel free to update the docs everytime someone is confused ;)
[01:15] <poolie> wgrant, is there any more of a traceback for https://bugs.launchpad.net/launchpad/+bug/847485 ?
[01:15] <_mup_> Bug #847485: process-mail.py crashing with Unicode logging errors <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/847485 >
[01:16] <poolie> it might have been my change that provoked it
[01:27] <wgrant> poolie: There isn't.
[01:27] <wgrant> poolie: I was hoping maintenance squads would intervene on Monday.
[01:27] <wgrant> But nobody did :(
[01:27] <poolie> that's strange
[01:28] <poolie> that there is just a one entry traceback
[01:28] <wgrant> Rather.
[03:21] <StevenK> Hah, it has changed
[03:21] <StevenK> PircBot 1.4.6 Java IRC Bot versus PircBotX 1.5, a fork of PircBot, the Java IRC bot
[03:23] <lifeless> what has changed ?
[03:23] <StevenK> I upgraded Jenkins and then updated all of the plugins
[03:24] <wgrant> StevenK: Is canonistack letting you in yet?
[03:24] <StevenK> No
[03:41] <nigelb> wgrant: BAH! I didn't know :(
[03:42] <wgrant> nigelb: 'tis rolled back and I stopped it getting onto staging, no harm done.
[03:42] <nigelb> Sorry!
[03:42] <nigelb> StevenK: As I said the other day, I don' know how to QA it.
[03:43] <wgrant> nigelb: It's pretty difficult to QA it directly.
[03:43] <wgrant> So I poked around a bit and said it was qa-ok.
[03:44] <lifeless> nigelb: I've tweaked https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[03:44] <wgrant> Thanks lifeless.
[03:45] <lifeless> nigelb: can you tell me if step 6 is clear enough to you?
[03:45] <nigelb> lifeless: Reading
[03:45] <nigelb> It is :-)
[03:46] <nigelb> wallyworld: I tweaked the javascript unit testing and mockio pages after a few hours of headdesk. There were small typos in the code for both.
[03:47] <nigelb> wgrant: Ah, is that why I don't have a success mail? :)
[03:47] <wallyworld> nigelb: hopefully your head doesn't hurt too much :-) is it ready for a formal review?
[03:47] <nigelb> No, not yet :)
[03:47] <nigelb> I want to write more testss
[03:48] <wallyworld> more tests = good :-)
[04:34] <StevenK> wallyworld!
[04:35] <StevenK> wallyworld: Your presence is *required*
[04:35] <nigelb> That is not good :P
[04:35] <wallyworld> StevenK: hello!
[04:35] <StevenK> wallyworld: Can you log into Jenkins using SSO -- check the box for team membership and see if you get buttons on the right hand side
[04:35] <StevenK> nigelb: ^
[04:36] <StevenK> nigelb: You shouldn't get the box and no buttons, but you should be able to log in
[04:36] <nigelb> we dont sleep dot org?
[04:36] <wallyworld> StevenK: i forgot the url
[04:36] <nigelb> https://lpci.wedontsleep.org
[04:36] <StevenK> That's it
[04:37] <wallyworld> ok, i can see a jenkins console
[04:37] <nigelb> What box am I looking for?
[04:38] <StevenK> wallyworld: So it says "wallyworld | log out" on the top right?
[04:38] <wallyworld> StevenK: yes
[04:38] <StevenK> wallyworld: Are there two icons on the far right of devel and db-devel that say "Schedule a build" when you hover on them?
[04:39]  * wallyworld looks
[04:39] <wallyworld> yes
[04:39] <StevenK> wallyworld: Excellent, thanks
[04:39] <wallyworld> np
[04:39] <StevenK> nigelb: Are you logged in?
[04:39] <nigelb> StevenK: http://people.ubuntu.com/~nigelbabu/jenkins.png
[04:40] <StevenK> Excellent
[04:40] <StevenK> Thanks
[04:40] <nigelb> Did you write java code for this?
[04:40] <wgrant> StevenK: You might want to get it authorized to get launchpad membership by default.
[04:40] <nigelb> If so, respect.
[04:40] <StevenK> Doesn't that require an RT?
[04:40] <StevenK> nigelb: I did not
[04:41] <nigelb> It requires an RT
[04:41] <nigelb> and probably grabbing stuart
[04:42] <nigelb> g26
[04:49] <wgrant> A LOSA may be able to JFDI for you. May not require ISD intervention these days.
[04:51] <poolie> wgrant, lifeless, is it ok if i send up my bug 643223 branch to ec2?
[04:51] <_mup_> Bug #643223: should accept dkim based on from address and signing address belonging to the same person <dkim> <lp-foundations> <mail> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/643223 >
[04:52] <wgrant> poolie: Sure.
[04:53] <jtv> Reviewer wanted: https://code.launchpad.net/~jtv/launchpad/katie-and-gina-are-bad-bad-girls/+merge/75472
[04:55] <wgrant> jtv: I can't review right now, but FWIW the katie celebrity is unrelated to gina.
[04:56] <jtv> But is it related to katie.py?
[04:56] <wgrant> Well, related only in that the celebrity represents katie for historical reasons, and gina's katie module was used to talk to katie.
[04:56] <wgrant> gina's katie.py is not katie.
[04:56] <wgrant> katie is part of dak.
[04:56] <wgrant> gina's katie.py reads dak's DB.
[04:57] <jtv> *cry*
[04:58] <wgrant> Yes
[04:59] <jtv> Oh well, it's not a concern for my branch then.
[04:59] <jtv> That's something: Katie will at least mean Katie, not frontend for Dak.
[05:03] <poolie> where should a script for developer-only use go
[05:03] <poolie> specifically process-one-mail
[05:03] <poolie> in scripts? utilities?
[05:03] <poolie> well, perhaps losas will find it useful, but it's not for production
[05:04] <wgrant> utilities, probably.
[05:04] <wgrant> But maybe scripts...
[05:05] <poolie> well, i'll leave it, someone can move it
[05:05] <poolie> no one complained in review
[05:32] <poolie> hm, what would be a clean way to let this hook into sendmail() so that what's going to be sent is instead printed
[05:32] <poolie> i can easily imagine how to do it by, eg, monkeypatching, or adding a new configuration option
[05:33] <poolie> i guess config is done for the special during-testing code, so perhaps i should do the equivalent?
[05:36] <wgrant> poolie: It's... not config.
[05:37] <StevenK> wallyworld!
[05:37] <wallyworld> yo
[05:37] <wallyworld> you rang
[05:37] <wgrant> poolie: lib/lp/services/mail/sendmail.py, search for isZopeless.
[05:37] <wgrant> poolie: That's the right part of the code.
[05:37] <wgrant> poolie: You can see how it handles testing there.
[05:37] <StevenK> wallyworld: var co = new Y.lp.app.confirmoverlay.ConfirmationOverlay({
[05:37] <wgrant> poolie: (you may need to consult a medical professional afterwards)
[05:37] <poolie> i do
[05:38] <poolie> the simplest thing that would possibly work is just to stick another variable on config
[05:38] <StevenK> Sigh, never mind, I see the error
[05:38] <StevenK> It's confirmationoverlay
[05:38] <wallyworld> excellent! pleased to help
[05:38] <poolie> the results are awesome though
[05:38] <wallyworld> :-)
[05:38] <StevenK> wallyworld: JS has the 77 char limit?
[05:38] <wallyworld> StevenK: sadly yes
[05:38] <wallyworld> imho, in 2011, 78 chars is mental
[05:39] <wallyworld> with wide screen monitors etc
[05:39] <wallyworld> should be at least 120
[05:39] <StevenK> wallyworld: http://pastebin.ubuntu.com/689734/
[05:39] <StevenK> wallyworld: Suggestions how to break that up?
[05:39]  * wallyworld looks
[05:39]  * StevenK would like to say "Where's my hammer?" in a Jeremy Clarkson voice.
[05:39] <wallyworld> StevenK: var ns = Y.lp.app.confirmationoverlay;
[05:40] <wallyworld> var overlay = new ns.ConfoimationOverlay()
[05:40] <wallyworld> or something like that
[05:40] <wallyworld> where ns is short for namespace
[05:41] <StevenK> Obviously
[05:41] <StevenK> :-)
[05:41] <StevenK> wallyworld: Where is your cape? :-P
[05:41] <wallyworld> in the wash, it;s dirty :-)
[05:41] <StevenK> From overuse, I bet
[05:41] <wallyworld> you don't want to know :-)
[05:42] <wallyworld> the Wonder Woman costume is also dirty :-P
[05:43]  * StevenK scratches his own eyes out
[05:43] <StevenK> CAN NOT UNSEE
[05:44] <StevenK> Can I tell Firebug to jump to a line number in a JS file?
[05:45] <wallyworld> StevenK: not sure. i usually just search for the loc
[05:45] <StevenK> Oh, look, it has search
[05:45] <wallyworld> you can type pretty well with no eyes :-)
[05:45] <StevenK> I installed a screen reader, duh
[05:46] <StevenK> And I don't need to look at the keyboard
[05:46] <StevenK> wallyworld: Can haz mumble?
[05:46] <wallyworld> StevenK: ok. just a sec. gotta plug in mic
[05:51] <nigelb> jtv: katie and gina are bad girls? BWAHAHA
[05:51] <jtv> Bad, bad girls.
[05:53] <nigelb> *now* I know why lifeless had included "Don't be cute" with names for services :P
[05:56] <lifeless> not to mention e.g. roomba
[05:58] <nigelb> There is a part of launchpad called roomba?
[05:58] <nigelb> Does it suck? :P
[05:58] <lifeless> there was
[06:00] <wgrant> That's news to me.
[06:00] <wgrant> What was it?
[06:00] <wgrant> librarian-gc?
[06:01] <lifeless> import related
[06:01] <lifeless> see circa 2006
[06:01] <lifeless> there was another, named after one of the other automatic vaccums
[06:01] <lifeless> we've done some terrible things
[06:02] <nigelb> what's the origin of "gina"?
[06:02] <lifeless> dak
[06:02] <lifeless> ish
[06:02] <wgrant> Yeah, it's following the dak naming scheme.
[06:02] <wgrant> I forget who exactly it is named after.
[06:03] <wgrant> I think dak's source says...
[06:03] <nigelb> What is dak again?
[06:03] <nigelb> VCS?
[06:03] <wgrant> dak is Debian's archive software.
[06:04] <wgrant> Like Soyuz, except even more of a trainwreck :P
[06:04] <nigelb> heh
[06:05] <wgrant> Blah, elmo deleted README.names in 2006.
[06:05] <wgrant> Bad elmo.
[06:05] <nigelb> heh
[06:06] <wgrant> "Gina (Gershon)" is listed as a future name. 18 months after gina was written :(
[06:18] <StevenK> wgrant: Land demolish-unused-tables-3-db!
[06:20] <wgrant> StevenK: Can't.
[06:20] <wgrant> StevenK: -2 is not deployed to loganberry/ackee yet.
[06:20] <wgrant> And can't be, because garbo-frequently isn't alive yet.
[06:20] <wgrant> Because puppet.
[06:22] <nigelb> What is the "correct" way to split long javascript strings?
[06:23] <nigelb> long strings in javascript rather.
[06:23] <lifeless> nigelb: 'don't' ?
[06:24] <nigelb> oh, lines of length 268 in js is okay?
[06:25] <lifeless> well depends what you mean
[06:26] <lifeless> js source code? no, our normal rules apply.
[06:26] <lifeless> js sent to the browser? see the various compressors out there.
[06:26] <nigelb> https://code.launchpad.net/%7Enigelbabu/launchpad/bug-title-849121/+merge/75267 (line 189)
[06:26] <nigelb> Its a test
[06:27] <nigelb> (also, why I can't I href to those lines :/)
[07:09] <mrevell> Good morning 'padders
[07:10] <rvba> Morning all, morning mrevell.
[07:10] <nigelb> Morning mrevell / rvba :)
[07:10] <rvba> Hey nigelb.
[07:10] <mrevell> Salut rvba! Qu'est-ce qu'i ce pass en France? (/me realises how much he's forgotten)
[07:11] <nigelb> rvba: Reviewing today? I *may* be able to get you something
[07:11] <mrevell> Namaste nigelb ... I might as well try and do a bad job of greeting everyone in something approaching their local manner :)
[07:11] <nigelb> mrevell: Haha
[07:11] <mrevell> heh
[07:12] <rvba> mrevell: Not so bad actually ;). Well, the rugby cup is on. Oh, and the economy is collapsing.
[07:12] <rvba> nigelb: Okay.
[07:12] <poolie> hello rvba
[07:12] <mrevell> rvba, The first one helps us forget the second.
[07:12] <rvba> True ;)
[07:12] <mrevell> heh
[07:12] <rvba> poolie: Hi!
[07:13] <poolie> could someone read https://code.launchpad.net/~mbp/launchpad/mail-script/+merge/75488 for me?
[07:13] <poolie> it's pretty small
[07:14] <rvba> poolie: I can do that but will have to wait a bit for Gavin to double check that my review is ok.
[07:14] <poolie> that's fine, and it would be appreciated
[07:15] <rvba> Okay then, I'm on it.
[07:39] <rvba> poolie: review done.  I'll ping Gavin (my mentor) when he logs in to double check what is actually my first review on lp ;).
[07:45] <poolie> awesome
[07:55] <adeuring> good morning
[07:58] <allenap> rvba, poolie: I'll do that now.
[08:01] <jtv> henninge: while you're still here, are you free for a pre-imp call in an hour or so?  For old time's sake.  ☺
[08:01] <henninge> jtv: yes, please! ;)
[08:01] <jtv> \o/
[08:01] <henninge> jtv: just ping me
[08:01] <jtv> Will do.
[08:01] <jtv> Tu'ich!
[08:04] <poolie> thanks allenap
[09:07] <jtv> henninge: ping :)
[09:07] <jtv> henninge: can I find you on mumble somewhere?
[09:07] <henninge> jtv: In the orange room. Gimme 2 mins.
[09:07] <jtv> OK
[09:30] <jml> jtv: hello. I've made the fix you required. What happens next?
[09:31] <jtv> jml: otp, but if that's fixed, I'll approve right now
[09:31] <jml> jtv: thanks. could you also land it please? I don't have commit access.
[09:31] <jtv> !
[09:31] <jtv> OK
[09:36] <nigelb> How do I get make lint to 'see' files?
[09:36] <nigelb> I commited something before linting and now make lint doesn't see it.
[09:40] <jtv> nigelb: I'll explain in a moment, hang on
[09:41] <jtv> nigelb: moment has passed.  “make lint” looks for files to check in stages:
[09:41] <jtv> If any files have uncommitted changes, it assumes you want to check those.
[09:41] <jtv> If no files have uncommitted changes, it looks for changes compared to the parent branch, and if there are any, assumes you want to check those.
[09:41] <jtv> If it doesn't find any changes at all, it checks everything.
[09:42] <jtv> nigelb: so try running it right after a commit.
[09:42] <nigelb> okay :)
[09:42] <nigelb> I did the hack of making whitespace changes
[09:42] <nigelb> so it found those :D
[09:43] <rvba> nigelb: You probably also can shelve your current changes for a moment.
[09:43] <nigelb> Lint seems to think i should use [09:44] <wgrant> It's right. == is almost never what you want. It does type coersion.
[09:44] <nigelb> Dear god.
[09:44] <nigelb> That's what its been doing all this while.
[09:44] <nigelb> Also, <3 YUI tests now.
[09:45] <nigelb> Easy to run 'em.
[09:49]  * nigelb curses lint.
[09:55] <nigelb> Erm, help. I have this huge string in a line of javascript (for a test), how do I split it?
[09:55] <nigelb> 'foo' + 'bar' + 'baz'?
[09:55] <jml> nigelb: think so.
[09:55] <nigelb> jml: Thanks.
[09:55] <nigelb> its going to end up looking ugly :P
[10:00] <rvba> nigelb: if the string is big but not huge, you can use the 'array trick' (see lib/lp/soyuz/javascript/tests/archivesubscribers_index.js)
[10:00] <rvba> nigelb: if the string is really huge and is html code, the right place for this is the .html file associated with the js test code.
[10:01] <rvba> nigelb: for an example of that, bzr grep derivedtd-template.
[10:02] <nigelb> let me check out the array trick :-)
[10:03] <nigelb> Oh, the array trick is *neat*
[10:10] <nigelb> rvba: Can I add https://code.launchpad.net/~nigelbabu/launchpad/bug-title-849121/+merge/75267 to your list? :)
[10:10] <rvba> nigelb: Sure.
[10:11] <nigelb> Yay for a branch where I knew most of what I wanted to do :-)
[10:36] <jml> jtv: any idea when that branch is going to land? I don't actually know the landing process.
[10:37] <jtv> jml: I'm having some trouble landing it myself.
[10:38] <jtv> jml: it looks like “bin/ec2 land” won't do it; wants a GPG key I don't have.  Do we have anyone who's more familiar with the project?
[10:38] <jml> jtv: benji, I think.
[10:39] <wgrant> which project?
[10:39] <wgrant> launchpadlib?
[10:39] <jml> wgrant: yes.
[10:39] <jml> personally, I would like to have landing and release processes for launchpadlib & other lazr projects in the source trees
[10:39] <jml> (because guess what I'm going to ask for after landing things?)
[10:39] <wgrant> https://dev.launchpad.net/HackingLazrLibraries
[10:40] <wgrant> It's not PQM-managed, let alone supported by ec2test :)
[10:40] <jml> ahh, thanks.
[10:43] <jml> https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520
[10:54] <jtv> jml: how do I run the tests?
[10:55] <jml> jtv: buildout, then ./bin/test
[10:55] <jtv> Thanks.
[10:55] <jtv> How do I get buildout?
[10:57] <jml> jtv: it's documented here: <https://dev.launchpad.net/HackingLazrLibraries>. Essentially, 'python bootstrap.py' and then './bin/buildout'.
[10:58] <jml> I find the dev wiki hard to read. I think it's the grey text.
[10:59] <jtv> It's also a lot of work just to run tests.
[10:59] <jtv> “a non-system Python, or a virtualenv executable that does not include site-packages, is highly recommended, and may be required”
[11:02] <jtv> “Download error: [Errno -2] Name or service not known -- Some packages may not be found!”
[11:03] <jtv> May be normal.
[11:05] <wgrant> jml: There's a bug for that.
[11:05] <jml> wgrant: yeah. I might have filed it.
[11:05] <jml> jtv: that's the glory of buildout. If it's any consolation, it's even more work just to run the tests for Launchpad itself.
[11:06] <jml> jtv: that's not normal.
[11:06] <jtv> Well, the tests ran.
[11:06] <wgrant> Did they pass too?
[11:06] <wgrant> jml: Bug #666143 is for the blog, which is a similar theme.
[11:06] <_mup_> Bug #666143: Launchpad blog uses grey text <css> <lp-web> <Launchpad itself:Won't Fix> <Launchpad Blog WordPress Theme:Triaged> < https://launchpad.net/bugs/666143 >
[11:06] <wgrant> Hah, closed.
[11:06] <jtv> wgrant: yes
[11:07] <wgrant> Oops, still open for the theme.
[11:08] <jtv> jml: landed.
[11:09] <jml> jtv: thanks!
[11:09] <jml> jtv: could I trouble you to review the hacking documentation branch I just put up? https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520
[11:09] <jml> jtv: it's waffer thin
[11:09] <jtv> jml: not tonight, sorry.
[11:09] <jml> jtv: no worries. thanks.
[11:09] <jml> rvba: could I trouble you to review this branch? https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520 I'd land it myself sans review if I had commit access.
[11:14] <rvba> jml: Sure. I'll take care of it after lunch.
[11:21] <jml> rvba: thanks.
[11:24] <nigelb> wgrant: How do I turn on feature flags?
[11:24] <nigelb> You told me a while back and now I forget :/
[11:24] <wgrant> nigelb: https://launchpad.dev/+feature-rules
[11:24] <nigelb> Thanks!
[11:27] <nigelb> Now I need to figure out which was the feature Julian and I were confused about.
[11:29] <nigelb> What's priority?
[11:30] <nigelb> (in the context of feature flags)
[11:32] <wgrant> nigelb: The highest priority matching rule wins.
[11:32] <wgrant> So, say I have 'default' and 'pageid:Person:+index' rules for a particular flag.
[11:32] <nigelb> what's wrong with this line?
[11:32] <nigelb> (code.incremental_diffs.enabled, default$, 1, true)
[11:32] <wgrant> default$?
[11:32] <wgrant> What's that %?
[11:33] <wgrant> $
[11:33] <nigelb> from the https://launchpad.dev/+feature-info page.
[11:33] <nigelb> default$
[11:33] <nigelb> The default scope.  Always active.
[11:33] <wgrant> Ah, that's a bit confusing.
[11:33] <wgrant> That describes the regular expression that is used to match the scope in the rule.
[11:34] <wgrant> so the rule would be something like 'code.incremental_diffs.enabled default 1 true'
[11:34] <nigelb> GAH
[11:35] <nigelb> On each line: (flag, scope, priority, value),
[11:35] <nigelb> How confusing.
[11:35] <jelmer> rvba: hi, can I add a small merge proposal to your queue?
[11:39] <rvba> jelmer: Yes you can ;). You'll be number 3. (I'm working on number 1)
[11:40] <jelmer> rvba: thanks!
[11:40] <rvba> np
[11:45] <jkakar> jml: You merged it!  AWESOME! :)
[11:46] <jml> jkakar: :D
[11:46] <jkakar> jml: Man, that feels so good... that's the longest living branch I've ever had. :)
[11:46] <jkakar> Thanks for picking it up and getting it landed, much appreciated.
[11:47] <nigelb> what do I do to see a diff in an MP for local codehosting
[11:47] <jml> jkakar: my pleasure
[11:47] <jml> jkakar: I know the feeling. I personally resent every unlanded branch I have.
[11:49] <jkakar> jml: Yep, me too. :)
[11:53] <wgrant> nigelb: 'make sync_branches' should scan the branches and generate requested MP diffs.
[11:54] <nigelb> wgrant: I just realized that branch didn't have contnet.
[11:54] <nigelb> This means I have to setup local codehostign to fix a bug I can't even see! :P
[11:55] <wgrant> Heh.
[11:55] <wgrant> make run_codehosting
[11:56] <wgrant> Add http://paste.ubuntu.com/689936/ to your ~/.ssh/config
[11:56] <G> or the make run all option (it's run_all right?)
[11:56] <wgrant> utilities/make-lp-user nigelb
[11:56] <wgrant> bzr push lp://dev/~nigelb/+junk/something
[11:56] <wgrant> G: Or that, yeah.
[11:57] <G> https://dev.launchpad.net/Code/HowToUseCodehostingLocally describes it all
[11:57] <nigelb> I did see that.
[11:58] <nigelb> But I was trying to figure out the effort of fixing a bug I can't see :p
[11:58] <nigelb> (I still can't see it, until I go through all the hoops!)
[12:00] <nigelb> wgrant: heh, a bug you filled seems to be a dup of one I filed
[12:01]  * nigelb marks
[12:01] <nigelb> bug 847556 vs bug 847682
[12:01] <_mup_> Bug #847556: Person picker in the MP ignored the fact that I filled out a review type <Launchpad itself:Triaged> < https://launchpad.net/bugs/847556 >
[12:01] <_mup_> Bug #847682: Can no longer set review type in "Request another review" person picker <disclosure> <person-picker> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/847682 >
[12:01] <wgrant> ni	Bah, sorry.
[12:02] <wgrant> Why does irssi do that...
[12:02] <nigelb> I'm duping mine to yours
[12:02] <G> wgrant: too quick w/ the tab & typing and latency I find
[12:03] <nigelb> wgrant: You're is marked higher than the one I field :D
[12:03] <nigelb> *filed
[12:03] <wgrant> G: Yeah, irssi is currently running on a slow ARMv5 machine which is also a file+print+mail server, so the load sometimes gets a bit high and it lags.
[12:03] <lifeless> nigelb: generally we dup onto the lower bug #
[12:03] <wgrant> G: And about 18 months ago it started interpreting tabs literally during high lag.
[12:04] <wgrant> It's annoyinfuriating.
[12:04] <wgrant> Haha
[12:04] <wgrant> There we go again.
[12:04] <nigelb> His is marked critical, mine is low.
[12:04] <nigelb> and has the right tags :)
[12:04] <wgrant> How did that get marked low :/
[12:04] <G> lifeless: an unnamed bug tracker & project I used to work with had the policy, dupe to the 'best' bug :)
[12:05] <nigelb> That's my policy most of the time :)
[12:05] <lifeless> wgrant: irssi and tabs with lag... thats been like that for many many years
[12:05] <wgrant> lifeless: Hm. Only noticed it in the last couple.
[12:05] <wgrant> Odd.
[12:06] <G> yeah, it used to happen a lot on my Linode
[12:06] <lifeless> wgrant: its the paste detection heuristic
[12:06] <wgrant> Perhaps load has just increased too much.
[12:06] <wgrant> May need to offload some stuff to a pandaboard.
[12:06] <nigelb> wgrant: ARM macine? Your phone?  I have just wondered why patches have an edit sprite. Despite me adding them.
[12:08] <G> lifeless: can't you turn off?  (I thought you could)
[12:08] <lifeless> http://irssi.org/documentation/settings paste_detect_time = 5msecs
[12:08] <lifeless> Irssi will detect pastes when your input has less than this much time between lines.
[12:09] <lifeless> except its a lie
[12:09] <lifeless> its not line based ;)
[12:09] <G> ahh you can yeah
[12:09] <wgrant> paste_detect_time = pleasedie
[12:09] <nigelb> heh
[12:09] <lifeless> and/or paste_detect_keycount = 5
[12:09] <nigelb> wgrant: alternatively, set your irssi as a bouncer :)
[12:09] <lifeless> I think its the latter for the tab breakage
[12:10] <lifeless> note the special special special docs about it on that page
[12:13] <G> wgrant: I guess the other solution is to write a script to detect it happening ;)
[12:14] <lifeless> night all
[12:15] <G> lifeless: have a good one
[12:15] <nigelb> night lifeless
[12:16] <wgrant> Night lifeless.
[12:16] <nigelb> Is bug 845339 already?
[12:16] <_mup_> Bug #845339: Incorrect sorting on "Last Modified" or "Last Commit" in Code page <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/845339 >
[12:17] <nigelb> Not able to reproduce it in production
[12:17] <wgrant> nigelb: It depends on the browser.
[12:17] <nigelb> Firefox 8 works.
[12:19] <nigelb> Ohyes. Chrome.
[12:20] <wgrant> Still reproducible there?
[12:20] <nigelb> yup
[12:21] <nigelb> Hrm, everyone has taken jtv's email to heart! :-)
[12:23] <nigelb> rvba: Hi, I didn't understand the first bit
[12:26] <rvba> nigelb: I think you should keep the logic that was in place before your change and create the list of the invalid bugs like it was done before instead of building it like you do now.
[12:26] <rvba> nigelb: invalid = set(bugs) - set(bug_ids)
[12:26] <nigelb> I can't do that anymore
[12:26] <nigelb> since I don't get bugids
[12:26] <nigelb> I get bugtask objects instead
[12:27] <nigelb> so, doing that means looping through the list again.
[12:27]  * rvba checks again.
[12:29] <nigelb> (interestingly, that logic was written by me as well)
[12:30] <rvba> nigelb: why do you need to deal with bugtasks instead of bugs?
[12:30] <nigelb> rvba: to get the bug title
[12:30] <nigelb> earlier I was just getting bug ID
[12:31] <rvba> I see.
[12:46] <rvba> nigelb: I guess I'll let you get aways with this if you add a comment saying that we're left with the invalid bugs before the second loop ;)
[12:46] <rvba> s/aways/away/
[12:46] <nigelb> rvba: heh, okay :)
[12:47] <nigelb> I hope I didn't make your eyes bleed with that JSON ;)
[12:47] <nigelb> s/bleed/bleed too much/g
[12:47] <rvba> my eysdqsd sqdd sf.
[12:47] <rvba> (I can't see the keyboard anymore)
[12:48] <nigelb> haha
[12:48] <rvba> ;)
[12:58] <rvba> Hi jcsackett!
[12:58] <jcsackett> good morning, rvba. :-)
[12:58] <jcsackett> or good afternoon, in your tz.
[12:59] <rvba> Afternoon, right, good morning to you ;)
[13:01] <jcsackett> timezones are too much to deal with on low levels of coffee. :-)
[13:01] <rvba> hehe
[13:03] <rvba> jcsackett: LP seems to have a problem generating diffs atm.
[13:03] <StevenK> merge-proposal-jobs failed to run
[13:03] <jcsackett> StevenK: someone on maintenance looking at that?
[13:03] <soren> This has been a fascination of mine for a while.. It would seem natural that inhabitants of a country that spans 6 timezones were able to deal with timezones literally in their sleep :)
[13:03] <jcsackett> or does it just appear to be one off death?
[13:05] <wgrant> jcsackett, rvba: See #-ops
[13:05] <jcsackett> wgrant: looking in it now.
[13:06] <G> soren: it's my hope that we ditch TZs all together ;)
[13:06] <jml> soren: they are funny timezones though
[13:06] <jml> soren: I mean, they call their west coast timezone, "Pacific time", as if the great big blue wobbly thing outside their windows stretched only a mile out from the coastline
[13:10] <jml> hey, I just learnt a thing about source package publishing
[13:10] <jml> which is that SPPH.sourceFileUrls() will give you some interesting stuff that's not the same for every package.
[13:11] <james_w> that's links to the .dsc .orig.tar.gz etc?
[13:11] <james_w> or whatever makes up that package?
[13:12] <jml> james_w: yeah. sometimes there's a .debian.tar.gz (e.g. w/ gtk+2.0-0), other times just a diff.
[13:12] <james_w> yeah
[13:13] <james_w> the easy way of reliably getting it is the slow one
[13:13] <james_w> fetch them all and call dpkg-source -x passing the .dsc file with them all in the same dir
[13:13] <james_w> then grab the debian/ dir from the resulting directory
[13:13] <jml> james_w: *awesome*
[13:14] <james_w> you could write something 90% that extracts what you want from the debian.tar.gz or the diff.gz
[13:14] <james_w> but if you want 100% that's the easy way to do it
[13:14] <jml> james_w: I want 100%. Have too many other 90% things in this. They multiply and get smaller pretty quickly.
[13:15] <james_w> yeah
[13:16] <james_w> actually, I'm not experienced with it, but just looking in debian.tar.gz if one is there may be 100% for that subset
[13:16] <james_w> and if there is no diff.gz then there is only one tarball to look in, so that's 100%
[13:16] <james_w> so it's only the diff.gz case that is a bit tricky
[13:16] <james_w> but given that maybe just coding one thing is the easiest for now
[13:17] <jml> +1
[13:18] <jml> james_w: did you not have to solve this for the udd importer?
[13:18] <james_w> jml, we need the whole thing for that
[13:18] <james_w> so I never looked for optimizations
[13:18] <james_w> but yeah, it has code to download the files and extract them
[13:18] <james_w> maybe split across two different places
[13:19] <jml> heh
[13:21] <james_w> import_package.py:dget
[13:22] <james_w> import_dsc.py:SourceExtractor and subclasses in bzr-builddeb
[13:22] <james_w> it doesn't use that API you mention
[13:22] <james_w> and I'm not sure if it's going to be directly applicable to what you want
[13:22] <james_w> the extraction probably does more than you need
[13:23] <nigelb> rvba: I'm fairly sure I updated that MP with the changes you requested. I suspect something broke with diff generation, so you can't review it for a bit anyway.
[13:24] <rvba> nigelb: indeed, wgrant is working on it.
[13:24] <wgrant> Well, I'd prefer to drop it on abentley or a maintenance person :)
[13:24] <wgrant> s/a/another/
[13:25] <rvba> nigelb: I'll grab the branch directly.
[13:25] <nigelb> \o/
[13:25] <jml> james_w: thanks.
[13:28] <nigelb> wgrant: do you have a quick minute to point me in the right direction for bug 843415?
[13:28] <_mup_> Bug #843415: Can't assign people on bugs that affect many projects <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/843415 >
[13:28] <wgrant> nigelb: Do you feel like optiming all of lazr-js?
[13:28] <wgrant> optimising
[13:28] <nigelb> :/
[13:28] <nigelb> I thought it was a simple bug.
[13:28] <wgrant> Well, you could "fix" it by adding an assignee edit link.
[13:29] <nigelb> Yeah, that's what I was looking to fix.
[13:29] <cjwatson> wgrant: would you have time to review https://code.launchpad.net/~cjwatson/launchpad/bzip2-translations/+merge/75547 ?
[13:29] <nigelb> I'm at bugtask-tasks-and-nominations-table-row.pt and can't find anything relevant.
[13:29] <cjwatson> is indeed trivial.
[13:30] <cjwatson> jml: 'man dpkg-source' for the various source package format
[13:30] <cjwatson> s
[13:30] <jml> cjwatson: thanks.
[13:31] <jml> cjwatson: this learning thing is fun
[13:32] <cjwatson> james_w: sadly I'm fairly sure there's a non-zereo number of packages where the tarball has some debian/ bits in it and the diff just mildly patches them.  You're probably right in the case of debian.tar.gz
[13:32] <danilos> matsubara, hi, I've put up a MP for review for oops-tools, I hope you can take that
[13:33] <wgrant> cjwatson: Hm, difficult.
[13:33] <wgrant> Want me to land it?
[13:33] <cjwatson> wgrant: difficult?
[13:34] <nigelb> Probably because diff thing isn't working.
[13:34] <wgrant> Yeah, diffs are broken at the moment.
[13:34] <wgrant> But loggerhead worked.
[13:34] <wgrant> To see the whole one line of non-test diff.
[13:35] <cjwatson> Ah, my sarcasm detector was broken I think.
[13:35] <cjwatson> wgrant: yes please, landing would be good
[13:37] <cjwatson> james_w: indeed, on checking, dpkg-source removes any debian/ directory it finds in the upstream tarball before unpacking debian.tar.gz
[13:37] <cjwatson> which is a much better design than we used to have
[13:37] <jml> rvba, allenap: would one of you please land that branch? I don't have commit access. (https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520)
[13:38] <allenap> jml: Okay, I'll give it a go.
[13:38] <jml> allenap: thanks.
[13:44] <rvba> nigelb: re-reviewed. I've a few more nitpicks but I've asked Gavin to do that final check anyway. After that we'll be good to land.
[13:45] <nigelb> rvba: cool! Thanks :)
[13:45] <rvba> Welcome.
[13:56] <matsubara> danilos, will do. thanks!
[14:00] <matsubara> danilos, I didn't get any email about it yet.
[14:01] <matsubara> oh, just read the backlog. diffs are broken...
[14:31] <wgrant> cjwatson: That branch has been in ec2 for a little while now.
[14:47] <cjwatson> wgrant: great, thanks
[14:56] <jml> LP mail is slow today.
[15:34] <nigelb> rvba: Anything else I need to do?
[15:34] <nigelb> Just wait for allenap? :)
[15:34] <allenap> nigelb: I'm looking at it now.
[15:35] <nigelb> AH!
[15:35] <jelmer> hi jcsackett, can I add a branch to your queue?
[15:35] <nigelb> allenap: I just pushed the last set of changes.
[15:35] <allenap> Okay.
[15:38] <jcsackett> jelmer: you can indeed.
[15:39] <jelmer> jcsackett: thanks :) the MP is at https://code.launchpad.net/~jelmer/launchpad/follow-http-redirects/+merge/75561
[15:39] <jcsackett> i'll start reviewing it in just a moment. :-)
[15:53] <matsubara> danilos, replied
[15:59] <nigelb> diffs still broken?
[16:00] <rvba> nigelb: apparently yes.
[16:00] <nigelb> Ouch.
[16:03] <nigelb> If I visit https://code.launchpad.net/lp-production-configs, for which I don't have permission, Launchpad tells me - "Launchpad Production Configs has 0 active branches."
[16:03] <nigelb> But the very next line is "There were 5 commits by 3 people in the last month. "
[16:03] <nigelb> Pretty much makes the first line a lie. Is this known?
[16:04] <jcsackett> jelmer: quick question; i see this code apparently captures too many redirections, but i see no tests for that. is it tested elsewhere?
[16:04] <jelmer> jcsackett: do_catching_redirects will raise TooManyRedirections in that case
[16:05] <jcsackett> jelmer: that's what i see, but i don't see a test making sure everything works as expeced (e.g. i do see a test for forbidden conditions).
[16:05] <jelmer> jcsackett: ah, yeah, that's true - it's indeed only tested in bzr itself
[16:05] <jml> jkakar: hi
[16:06] <jelmer> jcsackett: would you like me to add a test for that in lp as well?
[16:06] <jcsackett> jelmer: i think it would probably be appropriate, since the lp buildbot doesn't check the bzr tests, to my knowledge.
[16:06] <jcsackett> (and given that my understanding is those also take several hours, that's a very good things. :-P)
[16:07] <jelmer> it's not that bad actually, I think it was just 10 minutes on an 8 core machine :)
[16:08] <jelmer> anyway, I'll have a look at adding a test
[16:09] <jcsackett> jelmer: cool. i've marked the MP as Needs Fixing so i'll remember to take another look. aside from the test, this looks good, so i'll be happy to approve once that's addressed. :-)
[16:10] <jcsackett> nigelb: regarding the lying code page, i'm checking if there's a bug now. we have several related to the disclosure work that are about confusing messages like that.
[16:10] <jml> jkakar: so now I'm trying to use the launchpadlib testing that just got in.
[16:10] <jml> nigelb: known bug. It's filed somewhere.
[16:10] <nigelb> jcsackett: I just filed one, feel free to dup it if there's another
[16:10] <jcsackett> will do. :-)
[16:10] <jml> jkakar: I'm confused as to how to assign collections.
[16:13] <jml> jkakar: and by how the code is supposed to work in that case.
[16:13] <nigelb> jml: Its fun to catch LP lying :)
[16:13] <jml> jkakar: I want to have lp.distributions['ubuntu'] return something useful.
[16:14] <jcsackett> nigelb: can't find any dupes of it, so i've triaged your bug and tagged it with disclosure. concievably it will be addressed as part of our work.
[16:15] <nigelb> cool!
[16:15] <rvba> nigelb: jcsackett seems related to 656941.
[16:16] <rvba> Not the exact same location.
[16:17] <jcsackett> rvba: no, but close enough one could be made a dupe of the other and the summary updated. but i do sort of wonder why that bug wasn't added to the disclosure tag ...
[16:18] <nigelb> I wonder if its simple enough to check if the value of branches is 0 and based on that hide the next sentence.
[16:18] <rvba> nigelb: This won't be sufficent to fix the bug completely I think.
[16:18] <rvba> sufficient*
[16:19] <nigelb> Ah right. Public and private.
[16:19] <nigelb> Tricky!
[16:22] <rvba> nigelb: I'll be off soon.  I'm off tomorrow but I think allenap will be delighted to give you a hand to land your branch when it's fixed.
[16:23] <nigelb> rvba: Ah, thanks again for all the nitpick ;-)
[16:23] <rvba> You're welcome nigelb.
[16:23] <nigelb> Like jtv said in his email, its probably sad when there isn't nitpick :)
[16:23] <jcsackett> nigelb: that depends entirely on how long one reviewer's queue is. :-P
[16:24] <nigelb> heh
[16:32] <nigelb> allenap: Woah. I just learned a lot of Javascript! Thanks :-)
[16:34] <allenap> nigelb: Hehe, cool. Btw, I like the change; it's a neat feature.
[16:36] <nigelb> allenap: It was easier than all the changes I made too. I touched this code before, so I knew what I was doing most of the time :-)
[16:43] <jelmer> jcsackett: I've added a test for the too many redirections issue
[16:44]  * jcsackett goes to look
[16:44] <sinzui> nigelb, you and I are thinking about the issue in the same way. The template already uses the convention of checking the count. The bad chunk violates the rule
[16:44] <sinzui> nigelb, you are now subscribed to the master bug
[16:45] <sinzui> I think you could fix this in a few minutes
[16:46] <jcsackett> jelmer: r=me.
[16:46] <jelmer> jcsackett: thanks!
[16:48] <nigelb> sinzui: But that's only a partial fix.
[16:49] <nigelb> It would fail in the event of a project with public and privuate branches (is that possible?)
[16:50] <nigelb> sinzui: Oh wait. My concerns depends on how private branches work. I don't know :-)
[16:54] <sinzui> nigelb, we show private bug stats in all bug stats because it is too expensive to separate them
[16:55] <sinzui> nigelb, We know something is amiss on the page because of the contradictory statement, and we can see in the template that other parts avoid contradictory statements. only the block we see is misbehaving
[16:57] <nigelb> sinzui: Ah. So, this should be a good fix because its expensive for the "better" fix?
[16:57] <nigelb> I'll take it to go ;-)
[16:57] <sinzui> yes. if there is one public branch, we do want to show data
[16:58] <sinzui> also note that there are now three reported bugs about this issue now, and all are about the one chunk of text, so I believe the hard fix is overkill. Someone has to prove the data is exposed elsewhere to justify a deeper fix
[17:01] <nigelb> heh :)
[17:01] <nigelb> Because this is very apparent. The other situation less so.
[17:03] <nigelb> allenap: Y.Lang.hasOwnProperty isn't working :(
[17:03] <nigelb> (javascript tests++)
[18:00] <nigelb> Any JavaScript / YUI person around for some debugging help?
[18:50] <allenap> nigelb: var a = {fred: 123}; a.hasOwnProperty("fred") // true
[18:50] <allenap> It's part of JavaScript rather than YUI.
[18:55] <nigelb> Oh.
[18:55] <nigelb> allenap: that helps! Thanks
[19:03] <m4n1sh> sinzui: is lp-release-manager-tools mature enough as per your expectations?
[19:05] <nigelb> sinzui: That bug sounds way too easy. Want me add tests as well? :-)
[19:07] <sinzui> m4n1sh, thy are for me
[19:11] <nigelb> allenap: Pushed. Do you have time for another review of that MP?
[19:11] <allenap> nigelb: Sure :)
[19:17] <allenap> nigelb: Looks good. One *tiny* thing:
[19:17] <allenap> bugs_ids = set([int(link[len('/bugs/'):]) for link in links])
[19:17] <nigelb> Sure
[19:17] <allenap> The outermost [] braces are not needed.
[19:17] <nigelb> ah
[19:17] <nigelb> since its a set anyway.
[19:17] <nigelb> Right!
[19:18] <allenap> nigelb: I'll land it as it is; it's not worth changing.
[19:18] <allenap> Unless you're very keen :)
[19:19] <nigelb> allenap: wait, doing set(1,2,3) gives me a traceback in python shell.
[19:20] <allenap> nigelb: That does, but try set(i for i in 1,2,3), which is equivalent to set((i for i in 1,2,3)), i.e. set() gets passed a generator.
[19:20] <nigelb> ah
[19:21] <nigelb> SyntaxError: Generator expression must be parenthesized if not sole argument
[19:22] <allenap> Grr, sorry, let me try again!
[19:23] <allenap> set(i for i in (1,2,3)), which is equivalent to set((i for i in (1,2,3)))
[19:23] <nigelb> aha!
[19:34] <nigelb> allenap: Ah, you landed it? :)
[19:34] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/private-bug-5/+merge/75614
[19:35] <allenap> nigelb: Well, it's in ec2, but if you have another change I can restart it, no problem.
[19:35] <nigelb> nah, let it go :-)
[19:45] <jcsackett> sinzui: sure.
[19:45] <sinzui> thank you
[19:46] <jcsackett> sinzui: this appears to be a big diff. lemme finish poking at one thing first and then i'll get into it. :-)
[19:47] <sinzui> jcsackett, yes. it is larger than anticipated since I updated some supporting classes. I think you will find the implementation is often trivial, though I wanted better tests than what I started with
[19:48] <sinzui> jcsackett, oh yes, I neglected to mention I wrote a test for every class before I made my change...that double the change size
[19:49] <nigelb> sinzui: I'm assigining that bug to myself.
[19:49] <sinzui> nigelb, thanks you very much
[19:53] <jcsackett> sinzui: dig, that'll help me sort the diff out, thanks. :-)
[20:20] <nigelb> sinzui: Hey, do you have a minute for a bit of UI help?
[20:20] <nigelb> I tried fixing bug 806660. It ended up looking very ugly with too much whitespace.
[20:20] <_mup_> Bug #806660: "Add a new address" in e-mail settings does the wrong thing when pressing Enter <easy> <ui> <Launchpad itself:Triaged by nigelbabu> < https://launchpad.net/bugs/806660 >
[20:20] <benji> has anyone seen something like this when trying to run the LP tests? OperationalError: FATAL:  role "benji" does not exist
[20:21] <benji> This is on a brand new oneiric install
[20:39] <sinzui> nigelb, are you splitting the forms or adding a keypress handler?
[20:40] <nigelb> I tried splitting the forms.
[20:40] <nigelb> Its not a pretty approach for the UI.
[20:44] <sinzui> nigelb, I wonder if we can hack the add button to have accesskey="Enter"
[20:45] <nigelb> Hrm, I didn't think of that. That should be easier for sure.
[20:45] <nigelb> The last time I tried it in JS, there was an issue with IE.
[20:45] <sinzui> nigelb, of when something is entered, the other two buttons are deactivated, so the browser will choose the only active button
[20:45] <nigelb> Oh.
[20:45] <nigelb> deactivate the otheres on focus?
[20:46] <nigelb> and activate it back when focus is lost for the text box?
[20:46] <sinzui> nigelb, We may not need hacks. I looked at the template
[20:47] <nigelb> oh.
[20:48] <sinzui> The template is doing the actual layout, explicitly stating which chunk of the for to render. I think we want to call the form twice, each time only rendering the blocks we want
[20:49] <nigelb> Didn't parse that :-)
[20:52] <sinzui> nigelb, something like this: http://pastebin.ubuntu.com/690315/
[20:54] <sinzui> nigelb, I think the table elements need reconciliation in my paste. We only want to render the add field and button in the second call of the form.
[20:54] <nigelb> sinzui: heh, that's very close to what I did
[20:54] <nigelb> Let me see if yours renders better than the mess I made
[20:59] <jcsackett> sinzui: took a bit to read through all the tests, but r=me.
[21:00] <sinzui> jcsackett, thank you for your patience
[21:02] <jcsackett> sinzui: thank you for yours, given the time. :-)
[21:05] <nigelb> sinzui: that didn't work.
[21:05] <nigelb> one form cannot be inside another form.
[21:06] <nigelb> actually, ignore me.
[21:06] <nigelb> I was running the wrong launchpad.
[21:34] <bac> lifeless: ping
[21:55] <lifeless> bac: hi
[21:56] <bac> hi lifeless ... i've been looking at your branch for bug 759467
[21:56] <_mup_> Bug #759467: incomplete-with-response searches require complex searches <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/759467 >
[21:56] <lifeless> bac: cool
[21:56] <bac> lifeless: i'm unsure of your intentions, though.  do you want someone to pick it up or do you plan to fix and land it?
[21:56] <bac> it has considerable bit rot due to the BugSummary work
[21:57] <lifeless> bac: I don't have the cycles to pick it up myself for a few weeks
[21:57] <lifeless> need to get the SOA stuff rolling or risk blocking red
[21:57] <bac> right
[21:57] <lifeless> I would -love- it if someone else picks it up
[21:57] <lifeless> if noone does, it still needs doing and I have the most context on the problem so would indeed pick it up eventually
[21:58] <lifeless> if you're in a position to pick it up, I would love that.
[21:58] <bac> as you said in my MP, the escalated bug i worked on really needs this in place to properly proceed
[21:58] <bac> lifeless: i may need to pick your brain a bit to get through all of the conflicts caused by BugSummary
[22:00] <bac> for instance, would BugSummary.status be the real db status with INCOMPLETE_WITH*_RESPONSE or the visible one?
[22:01] <lifeless> bac: it would transition
[22:01] <lifeless> so 2 stages
[22:01] <lifeless> stage one, we start querying for both the current semi-status + date, *and* the actual explicit status
[22:02] <lifeless> on bugsummary and bug queries
[22:02] <lifeless> we also start *writing* explicit status at this point
[22:02] <lifeless> then we do a garbo job to rewrite every bugtask's status from the semi-status+date into an explicit status
[22:03] <lifeless> lastly we drop the garbo job, and the querying of both the semi status +date
[22:03] <lifeless> so bugsummary.status in stage one will be mixed, until the garbo job has migrated all the rows of bugtask across
[22:03] <lifeless> one sec
[22:04] <lifeless> back
[22:05] <lifeless> the contents of the bugsummary table don't need to be explicitly updated: as the garbo updates bugtask rows, the triggers will auto-update bugsummary for us.
[22:05] <bac> so for writing, the db procedures will simply need to start using BugTask._status rather than BugTask.status
[22:05]  * lifeless refreshes his memory
[22:05] <bac> _status is real, what is in the db
[22:05] <bac> status is the model view showing INCOMPLETE
[22:05] <lifeless> yes
[22:06] <lifeless> ideally we would migrate all the model code to be explicit too, but thats got lots of complicated bits from what I could see
[22:06] <lifeless> and the performance / clarity wins are all db-side.
[22:07] <lifeless> righto, so my branch has all the stage one stuff *except* making queries on bugsummary also include the two new enums
[22:07] <jcsackett> can anyone think of a reason why responses from answers.launchpad.dev is substantially slower than from launchpad.dev?
[22:08] <lifeless> jcsackett: nope :)
[22:08] <jcsackett> i'm running in a vm setup for remote access per the wiki; can't figure out why subdomains are *so* much slower.
[22:08] <jcsackett> lifeless: well damn. :-P
[22:09] <bac> lifeless: ok, i think i have a shove in the right direction
[22:09] <bac> jcsackett: i run with that configurationa and haven't seen such a thing
[22:09] <lifeless> bac: I've just re-read the branch and yeah, I think that that is all thats missing (modulo surprises)
[22:10] <jcsackett> bac: yeah, i've run this way before (new vm, but everything is roughly the same) and haven't seen this either. very perplexed.
[22:10] <lifeless> for clarity 'all that is missing is teaching bugsummary queries that want INCOMPLETE to want INCOMPLETE + INCOMPLETE_WITH_RESPONSE + INCOMPLETE_WITHOUT_RESPONSE'
[22:10] <lifeless> (unless they really want to be narrower anyway, in which case INCOMPLETE + one of the others)
[22:11] <bac> lifeless: right, plus resolving all of the conflicts towards using BugSummary not BugTask in queries
[22:20] <lifeless> bac: yes, though they should be mainly just take trunk's side
[22:21] <lifeless> bac: I think you'll find, if you diff .BASE.THIS that the local changes are all INCOMPLETE -> INCOMPLETE + ... ,or status -> _status
[22:24] <lifeless> flacoste: I think you win on the 'find oldest regression to date'
[23:24] <poolie> hi all


[16:28] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Podcast from the UK LoCo: S11E33 â Thirty-Three Teeth @ http://ubuntupodcast.org/2018/10/25/s11e33-thirty-three-teeth/
[20:13] -SwissBot:#ubuntu-news- ::Planet:: Julian Andres Klode: Migrated website from ikiwiki to Hugo @ https://blog.jak-linux.org/2018/10/25/migrated-website-from-ikiwiki-to-hugo/
[23:13] -SwissBot:#ubuntu-news- ::Planet:: Serge Hallyn: Outdoors laptop (part 2) @ https://s3hh.wordpress.com/2018/10/25/outdoors-laptop-part-2/


[06:41] <pipegeek> Hi, folks!  Question: why does the ubuntu installer gray out the options to enable lvm and dmcrypt, when the "install ubuntu alongside windows boot manager" option is selected?
[08:44] <xnox> because there is no support to do it.
[08:44] <xnox> use d-i / server installer to do both resize and full disk encryption
[18:26] <pipegeek> Hi, folks!  Question: why does the ubuntu installer gray out the options to enable lvm and dmcrypt, when the "install ubuntu alongside windows boot manager" option is selected?
[22:11] <pipegeek> it doesn't seem like it's documented anywhere and it's kind of frustrating.  Graying out user interface elements without explanation seems like bad UI design.


[12:07] <c_korn> can I tell dh_install not to install the symlink but the file the symlink points to ?
[12:54] <directhex> c_korn, not automatically. you need an entry in your debian/install which does what you want
[12:55] <c_korn> so, I have to point to the real file in the install file? currently I use cp -RL in debian/rules
[12:57] <Laney> if you want to use the .install file you do
[12:57] <Laney> doing it in rules is fine too
[12:58] <jtaylor> laney your involved with ghc? maybe check bug 820847
[12:58] <Laney> not going to happen
[12:58] <Laney> you could backport that patch though
[13:01] <jtaylor> I'm not involved, I just recall haskell beeing very abi fragile, not that something gets accidentally synced that shouldn't
[13:06] <geser> Laney: could you please add a comment to that bug saying so (even if the bug is not subscribed to sponsors (yet))
[13:06] <Laney> I am doing it.
[13:06] <geser> thx
[13:07] <Laney> it wasn't a proper sync request btw


[03:24] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1066599
[03:24] <maxiaojun> the solution is pretty clear now
[03:25] <maxiaojun> Mesa needs to build twice: one for OSMesa without --enable-shared-glapi, one for the rest with --enable-shared-glapi
[03:28] <maxiaojun> separate build is done in Mageia and openSUSE, not done in Arch, Debian, Ubuntu
[03:58] <maxiaojun> anyone?
[03:59] <mlankhorst> maxiaojun: worksforme?
[04:00] <maxiaojun> how do you test it?
[04:00] <mlankhorst> just checking if it's found in configure
[04:01] <maxiaojun> using wine?
[04:01] <maxiaojun> wine's test is simple
[04:01] <maxiaojun> it checks whether libOSMesa has symbol glAccum
[04:01] <mlankhorst> yeah and the ubuntu-wine packages have libosmesa, afaict...
[04:02] <maxiaojun> maybe it just bypass the check
[04:02] <mlankhorst> no they don't..
[04:02] <maxiaojun> can you show me source package
[04:03] <maxiaojun> i don't know how to find source package about a ppa
[04:05] <maxiaojun> http://paste.ubuntu.com/5748753/
[04:05] <maxiaojun> gcc foo.c -lOSMesa   -lSM -lICE -lXext -lX11 -lm
[04:05] <maxiaojun> works for you?
[04:06] <mlankhorst> https://launchpad.net/~ubuntu-wine/+archive/ppa/+sourcepub/3232603/+listing-archive-extra
[04:08] <mlankhorst> checking for -lOSMesa... libOSMesa.so.6
[04:09] <maxiaojun> no
[04:09] <maxiaojun> there is a waring at the end of configure
[04:10] <maxiaojun> because Ubuntu's libOSMesa is broken according to wine devs
[04:10] <maxiaojun> can you run ldd on ubuntu-wine's wine?
[04:10] <maxiaojun> i'm still downloading the deb
[04:10] <mlankhorst> it dynamically links against it..
[04:11] <mlankhorst> but it shows up in strings libgdi32.dll.so
[04:13] <maxiaojun> ?
[04:14] <maxiaojun> which file(s) in wine packages links libOSMesa ?
[04:16] <maxiaojun> i cannot find one in ubuntu-wine's amd64 package
[04:17] <maxiaojun> and can you pass the test i mentioned before, the compile a file test?
[04:22] <maxiaojun> broken libOSMesa can break native program also as shown in https://bugs.gentoo.org/show_bug.cgi?id=399813
[04:25] <maxiaojun> and intuitive for OSMesa -- Off Screen Mesa to use pure software GL implementation
[04:28] <maxiaojun> rather share GL API with GPU (can GPU access memory?)
[04:30] <mlankhorst> maxiaojun: are you using binary drivers by any chance?
[04:31] <maxiaojun> not on this box, but gamers are likely to use binary drivers, right?
[04:35] <maxiaojun> anyway, can you acknowledge the problem now?
[04:38] <maxiaojun> ?
[04:42] <maxiaojun> mlankhorst: ping?
[04:49] <maxiaojun> mlankhorst: i have to leave now, hope that you can take care of this issue and make Ubuntu better
[13:09] <seb128> tjaalton, mlankhorst: could you one you review the patch on https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/1180986 ?
[14:50] <mlankhorst> seb128: I'll look at it on monday, today is a free day for me
[14:50] <tjaalton> same here :)
[14:52] <mlankhorst> (and probably commit it upstream if its good)
[14:52] <seb128> tjaalton, mlankhorst: ok, no hurry, thanks
[14:53] <seb128> enjoy your w.e!
[15:05] <mlankhorst> i will, i have a barbecue planned and a horseback ride with my sister in the woods here :D
[16:12] <Sarvatt> ScottK: I know you don't like the aggressive mesa updates, but you do realize the only real changes in mesa at the moment were to fix kwin specifically right?  the aggressive mesa updates are due to waiting for stable releases and new hardware support that is absolutely needed, would it be preferred to get git snapshots in a few months in advance?
[16:12] <Sarvatt> aka https://bugs.freedesktop.org/show_bug.cgi?id=61554
[16:13] <ScottK> Sarvatt: I don't like having kwin developers yelling at us.  Honestly, I know it's not all on one side.
[16:13]  * Sarvatt wishes mesa did real release candidates
[16:14] <ScottK> My fundamental problem is that whatever the situation is now, when I hear people say, "Trust us, it'll be fine", I don't.
[16:15] <ScottK> Nothing personal with you guys.  I know you're trying hard to please everyone.
[16:15] <Sarvatt> I don't see anything that will change personally but that's probably not much of a reassurance, wayland will always be in main, we do maintain it, mesa needs it, mir is just a plugin the same wayland support in it is and won't affect the wayland side
[16:33] <Sarvatt> I doubt mlankhorst would ever want to break something he uses primarily also (kubuntu) :)
[16:36] <ScottK> That's good to know.
[16:56] <mlankhorst> ScottK: but in those cases it's usually upstream, we are just the packagers, is doing everything at the last possible moment better? it reduces the testing matrix immensely just because 1 specific chip of 1 specific manufacturer has problems
[16:59] <seb128> ScottK, your email seems to lack a bit of fact checking before posting (or it would be good to include details about the issues)...
[16:59] <mlankhorst> (I am convinced that if we pushed mesa in raring earlier despite performance issues upstream might have tried harder to fix it, now it looks like upstream doesn't care any more, all solutions suck)
[17:00] <ScottK> seb128: I don't fact check everything I hear from everyone.
[17:01] <seb128> ScottK, well, you should maybe hold from direct accusations then
[17:01] <seb128> ScottK, it's not like it was hard to check if an ubuntu source contains patches from Canonical
[17:01] <seb128> ScottK, easier to listen the haters I guess...
[17:02] <ScottK> It's easier to trust in people that are working in the broader FOSS community over groups going and doing their own thing without worrying overmuch about the broader impacts.
[17:03] <ScottK> It may be 3 years, it may be longer, but I'm pretty convinced nothing not driven by Canonical will survive in Ubuntu.
[17:03] <seb128> ScottK, easier but maybe not better, there is no Mir patch in that source
[17:03] <ScottK> Not yet.
[17:03] <seb128> that's a different topic
[17:03] <seb128> your email suggest that they are already patches in there breaking things
[17:04] <ScottK> When quantal was released, kwin was in fact broken.
[17:05] <seb128> not by mir patches for sure
[17:05] <seb128> there was no mir at this point of time
[17:05] <ScottK> No, by Ubuntu being really aggressive about what version of mesa being shipped.
[17:05] <ScottK> Now the good news about that one is we all worked together and fixed it.
[17:05] <seb128> right, that's a different topic than "your mir patches breaks our compositor"
[17:05] <seb128> which is pure invention
[17:06] <ScottK> Anticipation.
[17:06] <seb128> ...
[17:06] <mlankhorst> anyway I'm off, this can wait until monday :-)
[17:06] <seb128> very constructive
[17:06] <ScottK> mlankhorst: Have a nice weekend.
[17:06] <seb128> I'm out of it, no point trolling
[17:06] <ScottK> I'm not the one that decided that Ubuntu had to go off on it's own on common infrastructure.
[17:07] <ScottK> What's next, a kernel fork?
[17:07] <seb128> ScottK, I understand you have concerns, but speculation on what could broke and how, worded in a way that suggests it already happened is a bit disappointing from you
[17:07] <seb128> that's all I've to say
[17:07] <ScottK> OK
[17:07] <seb128> I don't plant to reply/argue/feed the troll
[17:08] <seb128> ScottK, have a nice w.e anyway
[17:08] <ScottK> I don't think I'm trolling.  I think I'm expressing reasonable concerns that are (while still in the future) a pretty straight line extrapolation from recent history.
[17:08]  * seb128 calls it a week as well
[17:09] <seb128> ScottK, I agree with the concerns, I don't agree with the wrong accusations "
[17:09] <seb128> Upstream kwin tells us they already see bug reports from Kubuntu users due to" ... changes that don't exist
[17:09] <seb128> I get that the kwin upstreams hate us
[17:10] <seb128> and decided to fud us
[17:10] <seb128> it's just a bit sad that you rely those fud in the discussion
[17:10] <seb128> you could made your point about the concerns you have without fud
[17:13] <bjsnider> ScottK, it's the CCLA that causes canonical to be so isolated and "not invented here"-ish
[17:13] <bjsnider> in my view anyway
[17:13] <ScottK> bjsnider: It's a huge factor.
[17:14] <ScottK> KDE was looking for a KDM replacement and although LightDM was the best technical solution available, it got rejected specifically because of that.
[17:17] <seb128> Qt has a CLA and it doesn't block KDE to use it...
[17:18] <ScottK> Different situation.
[17:20] <ScottK> To start with, I don't think any of the various owners of Qt have ever solicited code from KDE developers and then retroactively tried to get a copyright assignment and then thrown the code away when the authors wouldn't agree to what was at the time a VERY poorly written document.
[17:22] <ScottK> In order not to have regressions, we had to add all the thrown away code back as a distro patch.
[17:22] <ScottK> Talk about pointless waste of effort.
[17:24] <seb128_> yeah, not saying that Canonical is perfect, maybe there is a bit too much of history there ... and most people in opensource seems rather happy to behave like hates anyway on those topics
[17:25] <ScottK> Personally, I won't sign a CLA/copyright assignment for anyone unless it's paid work.  I just avoid contributing to things that require it.
[17:26] <ogra_> so you never contribute to anything owned by the FSF ?
[17:26] <ScottK> Or once I wrote a bug report that, instead of including a patch (which would have needed a copyright assignment), I said in text, change line xxx from foo to bar.
[17:26] <ScottK> ogra_: Not so far.
[17:28] <JanC> copyright assignment for non-paid work is legally dubious in many countries anyway
[17:28] <JanC> (and, yes, I know that'snot really required anymore by Canonical)
[17:31] <seb128> JanC, right, that issue is deprecated with the contributor agreement
[17:31] <seb128> you just give the right to use your code
[17:31] <seb128> that doesn't change the ownership of the code or limit your rights in any way
[17:32] <JanC> well, it doesn't limit you rights, but improves Canonical's rights  ;)
[17:34] <ScottK> seb128: It changes the issue, but doesn't resolve it.  You still end up having less rights to the code base that you contribute to than Canonical.  Some people think that's problematic.
[17:35] <ScottK> Personally, I'm not signing any contractual agreements that aren't reviewed by my lawyer and I'm not doing that for stuff I do for free.
[17:37] <JanC> many countries have contract law provisions that protect individuals against companies by requiring proportionality in such a contract
[17:37] <JanC> I'm not sure they apply to this sort of contract though
[17:39] <JanC> in any case, it's a fact that a lot of people object to contributing code to projects that require a CLA or similar contract
[17:39] <seb128> JanC, ScottK: I've no real issue with whoever does 99% of the work having more work that a side contributor doing 1%
[17:40] <seb128> it is
[17:40] <seb128> but, well, companies need to make money in some way, there is only so much you can give away
[17:44] <JanC> seb128, when puttig it black/white, maybe the 99% contributor is just employees working well-paid 9-5, while the 1% contributor is a volunteer spending all his/her free time on it unpaid; that should put some perspective to who really contributes more  ;)
[17:44] <JanC> (and I know a lot of you work more hours than you really have too!)
[17:46] <seb128> JanC, right, I'm just thinking that as somebody owning a business you can't afford to get screwed because you gave contributors rights to block change in your projects
[17:46] <JanC> contributors can never really block a project
[17:46] <JanC> as long as it stays open source
[17:47] <seb128> JanC, not really true, if you need to change the license at some point you need the ack of all the copyright holders
[17:48] <seb128> or to throw out the code of those who refuse
[17:48] <JanC> and what's also important: you certainly block contributions by other companies
[17:48] <seb128> well, you have to decide what line you are walking and what you value most
[17:48] <seb128> I can understand both side
[17:49] <seb128> but I can understand why somebody putting millions of dollars in a projects want to keep the ability to change the license if needed
[17:49] <bjsnider> of course
[17:50] <bjsnider> that argument is not going to move RMS though
[17:51] <JanC> I can understand why somebody thinks more control is important when spending money, but I'm not sure that's always the best decision  ;)
[17:51] <seb128> well, I've no strong feeling either way, I understand some people have and I'm fine with Canonical has a company defining the rules that work for them on the projects they invest in
[17:51] <ogra_> bjsnider, i wouldnt even want to touch RMS ... why do you think anyone would want to move him ?
[17:51] <seb128> at this end of the day I still think that Canonical does more that most closed sources companies
[17:51] <seb128> even if they are not perfect
[17:52] <seb128> it's "funny" how people blame you for "not giving enough" when you are giving time and money away contributing to opensource projects
[17:52] <seb128> even if Canonical was closed source company and Mir was closed source
[17:52] <ogra_> get along with it or don't ... raving about it all the time wont change anything
[17:52] <seb128> there would still be value in the testing, patches, etc we do on other opensource projects
[17:53] <ogra_> yeah
[17:53] <seb128> yet internet comment makes it like Canonical was just stealing and being evil
[17:54] <bjsnider> that's eseentially what RMS is telling them
[17:55] <ogra_> yeah, which is nonsense ... and most half way intelligent people i talk to grasp that
[17:55] <JanC> Canonical isn't stealing (nobody really has to sign the CLA or whatever other contract), but Canonical is losing contributions because they require it, and that is hurting Ubuntu users
[17:57] <ogra_> the CLA exists since years ... isnt not like it is something new ... but loud complaints only started to happen very recently
[17:57] <ScottK> OTOH, everytime someone suggest I fix Launchpad, I say "Sorry, CLA" and they understand, so it's not like it's all bad.
[17:58] <seb128> it would hurt Ubuntu users more if Canonical went out of business and stopped funding working on Ubuntu
[17:58] <ogra_> it didnt hurt the ubuntu users for all these years, why does it now ?
[17:58] <ScottK> ogra_: It's been highly controversial since it was started.
[17:58] <JanC> ogra_, that sounds like you were out f toh for years...
[17:58] <JanC> out of touch
[17:58] <seb128> seems like users are just dreamer
[17:58] <ScottK> ogra_: Because it applies to more and more of what's in Ubuntu as Canonical increasingly goes it's own way on things.
[17:58] <ogra_> ScottK, oh, definitely ... i just dont get why it suddely should be more hurtful than it was 3 years ago
[17:58] <seb128> "would be good if Canonical was just paying people to do free work even if they don't make money"
[17:59] <ScottK> ogra_: It sucked the whole time.
[17:59] <bjsnider> yes, i think RMS is basically against profit
[17:59] <bjsnider> not that canonical has ever made any profit, but it could happen in the future
[18:00] <bjsnider> depending on the phone market
[18:00] <JanC> ogra_, if you are only now hearing it, you have been out of touch with the community for years (sorry if that sounds harsh)
[18:00] <ogra_> ScottK, yes, but it wasnt a widley promoted topic across news sites etc
[18:01] <ogra_> JanC, i dont say i am only now hearing it ... i just say it didnt hurt the users 3 years ago more than it does today
[18:01] <ogra_> yet people behave like it would
[18:01] <JanC> it has been hurting people for years
[18:01] <ScottK> Well, the whole topic of Canonical doing it's own stuff, requiring CLA, etc plays very nicely into the "Canonical doesn't contribute" meme that Red Hat pushes.
[18:02] <ogra_> JanC, i dont think it has hurt my mom in any way, sorry
[18:02] <ogra_> and she is a happy ubuntu user
[18:02] <ScottK> They've been on that for awhile, this stuff just makes it easy for them.
[18:02] <ogra_> neither three years ago, nor today
[18:02] <ogra_> sure
[18:02] <ogra_> we surely feed enoough trolls with it
[18:03] <seb128> well, for sure Canonical doesn't contribute much to RedHat project :p
[18:03] <ScottK> Also, stuff like sending search results even for local searches (AIUI anyway) to Canonical is troubling.
[18:03] <seb128> they contribute a lot to Canonical projects though
[18:03] <ogra_> well, people know about it, it is not like it happens secretly
[18:04] <ogra_> and it is an essential bit of unity (not sure you have looked at the smart scopes)
[18:04] <ScottK> There's just a lot of things that make it easy to say bad things about Canonical and overshadow the good parts.
[18:04] <ogra_> definitely ...
[18:04] <ScottK> I haven't, but if I can't do a local search without network access, I'd call that a fundamental design flaw.
[18:05] <ScottK> I'd breach confidentiality agreements in multiple consulting contracts just to use it, in all likelihood.
[18:05] <ogra_> the new unity largely integrates the internet in everything ...
[18:06] <ScottK> Well, I guess if I wanted Chrome OS, I'd install it.
[18:06] <JanC> I love internet integration, but only when *I* want it  :p
[18:06] <ScottK> Maybe it's because I'm old, but I think I will always want a clear distinction between what's local and what's remote.
[18:07] <JanC> and only with the sites I want it
[18:07] <seb128> you can do local search, just turn off the option in system settings
[18:07] <ogra_> JanC, well, its part of the concept ... and its not a hidden fact
[18:07] <seb128> JanC, in saucy you can select the sources (sites) in the filters
[18:07] <JanC> not to mention that the default internet integration is utterly useless for most people
[18:07] <seb128> that's in the ui
[18:08] <ogra_> if you dont like the concept, reconfigure it or use something else ... its not like there wouldnt be choice enough
[18:08] <ScottK> seb128: Only because people screamed.
[18:08] <ogra_> JanC, not on a tablet or phone ;)
[18:09] <seb128> ScottK, well, they were right, and we got that option at this end
[18:09] <JanC> ogra_, my phone doesn't do anything I don't want and I have no tablet
[18:09] <seb128> so not perfect but not the end of the world either
[18:09] <ScottK> Actually, for me, Ubuntu Phone would be an interesting option if it did give me more control over what went off the device and what didn't compared to Andriod.
[18:09] <ogra_> JanC, so you dont have an iphone/android phone then, ok
[18:10] <ScottK> I do have an Andriod phone and am not happy about this kind of thing.
[18:10] <seb128> reality is that where 95% of the world is going
[18:10] <ogra_> well, you surely have ful control about the ubuntu phone as you have about an ubuntu desktop with the free images
[18:10] <seb128> e.g new xbox announce this week
[18:10] <JanC> dn't (although with an Android phone you could configure it properly, I guess)
[18:10] <seb128> it needs to be always connected
[18:10] <ogra_> i doubt you will have that much contol on a shipped vendor image
[18:11] <seb128> the mics are always on
[18:11] <ogra_> and the kinect too :)
[18:11] <ogra_> you can power it on with a gesture ... so it needs to constantly monitor the room
[18:12] <JanC> my dad is a regular ordinary computer/phone/internet user, and he objects against those things too
[18:12] <ogra_> what does he use on his phone/computer ?
[18:13] <JanC> (maybe because he once worked/lived/travelled in countries where that sort of information got abused to hurt & kill people)
[18:16] <seb128> well, I don't like those either, but reality is that the world is moving there and Ubuntu is still a lot better than Google Apple or Microsoft on those topics
[18:16] <JanC> sure
[18:17] <JanC> in any case, that has nothing to do with the CLA issue  ;-)
[20:26] <tjaalton> flowers, rainbows, ponies, kittens and all that.. :)
[20:27] <tjaalton> will check the thred next week..


 @mitya57 looks like notepadqq can be sync's now, yes?
 the ubuntu delta seem to be in debian
 Yes, looks like that. Can you sync it?
 Done. Thanks :) (re @mitya57: Yes, looks like that. Can you sync it?)


[10:53] <teddy-dbear> Morning peoples, critters and everything else
[16:22] <InHisName> Morning anyone hanging around, today.