[00:10] <persia> SpamapS, `quilt header` might be useful if you're using 3.0 (quilt)
[00:34] <SpamapS> persia: I think I'm just mixing two different dev styles and its messing with my workflow a bit. ;) I see now where if I'm not using bzr branches, its very simple.
[00:34] <SpamapS> Been doing everything with UDD methods but I wasn't sure how to do merges that way.
[00:36] <persia> SpamapS, For UDD, you'd submit a merge request.  Won't change the content of things.
[00:37] <persia> You still need to use `quilt header` or equivalent to set your patch headers, and you still want to review the diff before you request a merge on LP.
[00:38] <persia> Personally, I suspect using `debdiff` is the least annoying way to be able to see the summarised changes between two source packages, but you may be able to convince `bzr diff` to give you that, assuming both branches are in the same (correct) state.
[00:46] <SpamapS> persia: the issue with UDD is that you have to run bzr-buildpackage -S --dont-purge to generate the patches, then copy them back in. Granted, we should use quilt directly, but I'm just suggesting that this, IMO, very cool feature of debsrc 3.0 is sort of broken right now for bzr-buildpackage usage (unless I missed how to make it do this)
[00:46] <persia> You're supposed to use quilt, and then commit that with bzr, or work towards getting 3.0 (bzr) accepted, and work with packages in that source format.
[00:47] <SpamapS> Also I didn't realize that there was any problem with just leaving the generated patch "as is" .. nobody cared the last time I uploaded with the same patch boilerplate in place.
[00:47] <persia> Just changing code using normal bzr workflows is nearly guaranteed to fail.
[00:48] <persia> It ought be done right.  If someone didn't look, that's their mistake.  Folks that intentionally make mistakes usually end up with reprimands, so it's likely not safe to expect the same person to ignore it in the future.
[00:48] <ScottK> SpamapS: I think having the bzr history thanks to UDD is very useful, but I'm not convinced we know how to mix VCS and patch systems in a way that isn't harder than either alone.
[00:48] <SpamapS> persia: this is the first I've known its a mistake, and I'll be correcting it. :)
[00:49] <SpamapS> ScottK: Agreed.. it feels broken as-is. 3.0 (bzr) would be awesome.
[00:49] <persia> ScottK, For Format 1.0 packages, we have a working way to deal with bzr.  For Format 3.0 (quilt), it's sufficiently complex that it's often easier to post a debdiff after using bzr-buildpackage -S --dont-purge or similar, sadly.
[00:50] <persia> SpamapS, 3.0 (bzr) won't help for most packages, as most come from Debian, and the Debian maintainers often don't use bzr.
[00:50] <ScottK> 3.0($VCS) is still pretty well not figured out anyway.
[00:50] <persia> Indeed.
[00:51] <SpamapS> awesome, well its good to know that I am not alone in thinking this feels a bit duct-tape-and-chewing-gum-ish. :)
[00:51]  * SpamapS must be going, and so disappears ... <POOF>
[09:08] <ari-tczew> nxvl: ping
[09:34] <ari-tczew> sponsoring overview not updating anymore again :(
[10:29] <nxvl> ari-tczew: pong
[10:30] <ari-tczew> nxvl: could you take a look whether we can sync terminator from Debian unstable?
[10:30] <nxvl> ari-tczew: yes we can
[10:30] <ari-tczew> nxvl: the one remaining file in Ubuntu delta is /po/.intltool-merge-cache
[10:30] <nxvl> just sync it
[10:31] <nxvl> i only upload to ubuntu when my debian sponsor is taking long and we have a freeze comming
[10:31] <nxvl> and i upload the same to both distros
[10:31] <nxvl> so go ahead
[10:31] <ari-tczew> nxvl: thanks
[14:14] <ari-tczew> debfx: thanks for your working on merges
[14:21] <tumbleweed> ari-tczew: hah, it was AlanBell's merge proposal into lp:asher that broke the sponsoring overview :)
[14:21] <tumbleweed> AlanBell: care to delete that (and yes that bug should be fixed)
[14:22] <vish>  *lp:dasher
[14:23] <tumbleweed> yes. btw easy bug, I'll propose a fix
[14:24]  * vish guilty of asking AlanBell to do that :s …
[14:24] <vish> i dint notice it was the upstream branch at first, took me a couple of mins to realize it but AlanBell was fast ;)
[15:53] <AlanBell> tumbleweed: sure, the conversation is continuing upstream on that one
[15:53] <AlanBell> what do you want me to delete?
[15:53] <tumbleweed> AlanBell: the merge proposal into lp:dasher
[15:54] <AlanBell> it is gone
[15:54] <tumbleweed> AlanBell: thanks :)
[15:55] <AlanBell> I never quite understood the point of the lp:dasher sync from gnome
[15:55] <AlanBell> if the package comes from Debian
[15:56] <tumbleweed> AlanBell: if someone wanted to do a daily-build PPA for dasher, the sync would be a prerequisite
[15:56] <AlanBell> ah ok
[15:56] <tumbleweed> also, if someone wants to work on (or fork) dasher, in launchpad (i.e. someone who doesn't know git), it would be helpful. (although you obviously have to submit something upstream to get upstream's attention)
[15:57] <AlanBell> at the moment as far as I can tell it isn't used for anything
[15:57] <AlanBell> yeah, just confused me because I didn't know where the real upstream was
[15:58] <tumbleweed> AlanBell: yeah, this one looks dead and should be deleted...
[15:58] <AlanBell> a daily build ppa is an interesting thought
[15:59] <AlanBell> but as dasher in Maverick is reasonably non-crashy I am not sure how important it would be
[16:00] <tumbleweed> AlanBell: filed https://answers.edge.launchpad.net/launchpad-code/+question/129762
[16:06] <AlanBell> cool thanks
[16:39] <vish> tumbleweed¦ i asked that Q in #lp about the abandoned svn, and they said someone might have requested it..
[16:39] <vish> also, it seems mirroring from git to svn to lp o.0
[16:41] <vish> hmm, no! its just constantly trying from svn when its now moved to git..!
[17:37] <bilalakhtar> maco: There? Should I go ahead with merging netkit-tftp or you are doing it?
[17:39] <ari-tczew> bilalakhtar: did you see mail about wu-ftpd? it's free for you
[17:43] <bilalakhtar> ari-tczew: ah yes, doing that right now as you speak :)
[18:23] <bilalakhtar> back, sorry for the abrupt quit
[21:35] <sebner> RainCT: debious? Wth?
[21:50] <iulian> Heh.
[22:04] <RainCT> sebner: :P.
[22:05] <RainCT> sebner: I hadn't blogged for a couple weeks, had to write something :P.
[22:05] <sebner> RainCT: yet another dubios gui for debian packaging :P
[22:08] <RainCT> sebner: Well, I got tired of seeing awful GUIs out there so I made this mockup. Turns out it's pretty much like james_w's design (which I had forgotten).
[22:08] <sebner> RainCT: I guess the problem is not the awful GUI but the idea in general :P
[22:09] <RainCT> sebner: Nah, I think a well-done GUI could end up being useful.
[22:11] <sebner> RainCT: dunno about that, what do you criticise on the available guis?
[22:11] <RainCT> Eg. I'd love to be able to open a maverick package, change the target in debian/changelog to lucid, press "upload to PPA" and have it do everything (including test-building if I'd choose to do so)
[22:11] <RainCT> sebner: All GUIs I've seen so far were bad jokes with stuff like "checkinstall" buttons
[22:14] <sebner> heh
[22:14] <sebner> RainCT: sed, dput, pbuilder :P
[22:37] <RainCT> sebner: Yup, that's typing many lines (cp -R <...> /tmp; cd /tmp/...; sed; debuild ....; pbui...; dput;) vs a button. Not really that much difference but the later "feels" easier.
[22:48] <sebner> RainCT: well, if it's done properly
[23:39] <AlanBell> I am having a first play with packaging recipies to do daily builds, but it is failing to build for me, not sure if I have stuffed up the instructions somewhere
[23:39] <AlanBell> https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher
[23:39] <AlanBell> actually, just failed on Maverick and Natty, but build successfully on Lucid
[23:41] <AlanBell> Maverick build log is here http://launchpadlibrarian.net/57749157/buildlog.txt.gz


[20:38] <realtime-neil> How do I download a package and all of its dependencies if the package in question `Depends:` on a `libfoobar (<< 1.2.3)` and there are multiple `libfoobar` package versions in the available repositories?
[20:40] <realtime-neil> `germinate` can't do this because "the newest version of each source package across all archives will win" (https://manpages.debian.org/buster/germinate/germinate.1.en.html)
[20:44] <CarlFK> realtime-neil: it sounds like you are saying germinate ignores version requirements?
[20:44] <realtime-neil> it does indeed
[20:46] <CarlFK> sounds like a bug - do you have a simple example?
[20:46] <realtime-neil> CarlFK: it probably wouldn't take me too much to create one ... is (are) the maintainer(s) responsive ?
[20:47] <CarlFK> no clue, but 1/2 of this is to make sure things are as you think they are.
[21:02] <realtime-neil> CarlFK: how does one even write a test unit that checks the germinate-ability of itself?
[21:11] <CarlFK> realtime-neil: "unit test" sounds automated.  manually call it with one package that has a version requirement,  look at the results,  show that it ignores it.
[21:12] <CarlFK> ideally a package with only one dependency, but that might get tedious to find
[21:12] <realtime-neil> I'm trying to create the package with the version requirement along with the script that exposes the bug
[21:23] <CarlFK> I would use a package that is already in the main repo
[22:48] <realtime-neil> CarlFK: got any suggestions? I can't find anything with an uncomplicated `Depends:` stanza that also has a `(<< )` version association
[22:58] <CarlFK> realtime-neil: go with a complicated one.  I think it will be easy enough to show: it should have downloaded X, but it didn't.
[23:00] <CarlFK> the less extra things to deal with the better, but something solid is better than nothing, and also better than something built by hand that might introduce its own problems
[23:12] <realtime-neil> CarlFK: okay, I'm using this https://paste.ubuntu.com/p/f98gzMSj2J/
[23:13] <realtime-neil> and when I `./germinate-this.sh ansible`, I expect to see some kind of version specifier in the `standard.depends` ... but there's literally no version information at all
[23:14] <realtime-neil> Am I assuming too much from `germinate`? I thought it was supposed to generate files that told you what to apt-get download?
[23:21] <CarlFK> do any of ansible s deps have version requirements?
[23:22] <realtime-neil> Yes: `Depends: python-cryptography, python-jinja2, python-paramiko, python-pkg-resources, python-yaml, python:any (<< 2.8), python:any (>= 2.7.5-5~), python-crypto, python-httplib2, python-netaddr`
[23:31] <CarlFK> oh... does germinate only give you lists of package names, not download the package?
[23:31] <realtime-neil> yes, that's correct
[23:31] <CarlFK> hmm
[23:32] <realtime-neil> and (I'm discovering) it only respects package names and not package versions
[23:33] <realtime-neil> I think I need some kind of tool that will `apt-get depends --recurse ...` _and_ give me the versions of every package in the traversal
[23:35] <realtime-neil> Or maybe a `apt install` simulator that attempts to solve the dependency graph and spits a `package=version` list when it finds a solution?
[23:36] <CarlFK> looking at /usr/lib/python3/dist-packages/germinate/germinator.py   At this point, we only copy the parts of this seed that were filled         in by planting;
[23:36] <CarlFK> planting is cute
[23:40] <CarlFK>         # Does this seed still look the same as the one it was copied from
[23:40] <CarlFK>         # after we've finished planting it?
[23:41] <CarlFK> given it doesn't output any version info, and sounds like you need it... hmm...
[23:43] <CarlFK> if apt_pkg.version_compare(last_ver, ver) >= 0:
[23:44] <realtime-neil> huh
[23:44] <realtime-neil> welp
[23:44] <CarlFK> ok, I was hoping "newest version of each package" refereed to "same version number, different dates"
[23:44] <realtime-neil> looks like I'm using the wrong tool
[23:44] <CarlFK> or this tool needs a new feature  ;)
[23:45] <CarlFK> I am a little surprised it is the way it is, and seems pretty intentional, not a oversite
[23:47] <realtime-neil> CarlFK: I'm not crazy, right? I mean, this would be needed to correctly resolve any situation more complicated than "just give me the latest of everything you can see"
[23:48] <realtime-neil> this == "the proposed feature we're discussing"
[23:48] <CarlFK> I don't think you are crazy
[23:49] <CarlFK> cjwatson: yoo-hoo... ^^^
[23:52] <realtime-neil> :D


[00:17] <lifeless> Bert_2: you may not be aware, but the theme for Launchpad isn't open source - you need to change the theme.
[00:18] <lifeless> Bert_2: for that oops, its because you're missing the ubuntu celebrity
[00:18] <Bert_2> I do know that
[00:18] <Bert_2> I know about the theme I meant
[00:18] <Bert_2> lifeless: and I don't know what the ubuntu celebrity is, that's the problem :S
[00:18] <lifeless> celebrities are well known objects in the system - sysadmin teams, ops teams, various key projects (all from the perspective of launchpad.net of course)
[00:19] <Bert_2> I used wgrant's bootstrap-db-from-scratch
[00:19] <Bert_2> I guess that means I don't have any users
[00:19] <Bert_2> (that would also explain why I can't login)
[00:19] <lifeless> indeed
[00:20] <Bert_2> lifeless: would you happen to know where this information is stored ?
[00:20] <lifeless> there is a script in utilities I think to add a local user
[00:21] <lifeless> as for the celebrities, you probably need to add them directly via sql, though the harness *may* work.
[00:21] <wgrant> Bert_2: Did you run the bootstrap script after you ran make schema?
[00:21] <Bert_2> no, I didn't know I was supposed to, wgrant
[00:21] <Bert_2> is it the bootstrap-lp-db script in utilities I just noticed ?
[00:22] <wgrant> Yeah
[00:22] <wgrant> It's bitrotten a little. I'll fix it in a sec.
[00:22] <Bert_2> so I shouldn't run it yet ?
[00:22] <Bert_2> in the mean time I'll go and brush my teeth then ;)
[00:23] <wgrant> If you run it now it'll crash pretty quickly :)
[00:23] <Bert_2> k, I'll go and brush then :P
[00:29] <Bert_2> clean teeth, feels awesome :D
[00:32] <Bert_2> wgrant: do you have any idea whether you'll be able to clean that file out soon, cause otherwise I'm off to bed, I need to get up again in 5,5hours XD
[00:34] <wgrant> Bert_2: One down, one to go
[00:34] <Bert_2> k, awesome :D
[00:41] <Bert_2> wgrant: when you're done I just merge and run that script ?
[00:41] <wgrant> Bert_2: Right, you'll need to remerge my branch, and 'utilities/bootstrap-lp-db SOME_INITIAL_USERNAME'
[00:42] <Bert_2> bzr merge lp:~wgrant/launchpad/bootstrap-db-from-scratch, right ?
[00:42] <wgrant> Yep
[00:43] <Bert_2> bzr: ERROR: Working tree "/home/ubuntu/launchpad/lp-branches/devel/" has uncommitted changes (See bzr status).
[00:43] <wgrant> Ah, you've already merged it once, but not committed? If you've made no other changes, 'bzr revert' before remerging.
[00:44] <Bert_2> I added my own config and override-includes/mail-configure.zcml
[00:44] <Bert_2> but I can just copy them back afterwards, right ?
[00:44] <wgrant> Yep
[00:45] <wgrant> I've just pushed the latest changes to that branch, which fix bootstrap-lp-db. populate-ubuntu-from-scratch.py (which you probably don't need if you don't care about PPAs) is still broken, however.
[00:46] <Bert_2> yeah, I don't need PPAs
[00:46] <Bert_2> we just need bugs, questions and blueprints
[00:46] <Bert_2> that's why we had to run our own instance, launchpad.net requires us to put code up there
[00:46] <Bert_2> and we prefer to use our own storage for that
[00:47] <wgrant> Well, we don't care where the code is, as long as it's open source or you have a commercial subscription.
[00:48] <Bert_2> well, it's based on drupal, so it's open source by default :p
[00:48] <wgrant> But anyway, 'utilities/bootstrap-lp-db SOME_USERNAME', then you can log in as<EMAIL_ADDRESS>[00:48] <Bert_2> k
[00:48] <Bert_2> example.com can be changed later ?
[00:48] <wgrant> Oh, then why not just use a launchpad.net project without using Launchpad's code hosting?
[00:48] <wgrant> Yes.
[00:49] <Bert_2> I read it's a requirement to have code or a link to code up there ?
[00:50] <wgrant> We recommend you register the location so it can be automatically imported so other users can see it, but it's by no means required.
[00:50] <wgrant> If some docs say that, we should fix them :)
[00:50] <Bert_2> yeah, it was somewhere on launchpad.net
[00:50] <Bert_2> that's why I got into this misery :p
[00:50] <wgrant> We have quite a few projects that use external code hosting but LP for everything else.
[00:51] <wgrant> Some projects just use LP for bugs, or just for translations, etc.
[00:51] <Bert_2> yeah, that's what we want
[00:51] <Bert_2> but they have links to their code up, right ?
[00:52] <wgrant> Sometimes. As long as we can see that the code is under an open source license somewhere, we really don't care.
[00:52] <Bert_2> oh okey
[00:53] <Bert_2> well, that's cause I now got launchpad running XD
[00:53] <wgrant> But it's preferable if it's registered through https://help.launchpad.net/Code/Imports, if possible
[00:53] <wgrant> Heh
[00:53] <Bert_2> thx for both the info and the code
[00:53] <Bert_2> I'll talk to my team about it
[00:53] <Bert_2> but now I'm off to bed
[00:53] <Bert_2> cause it's london tomorrow :D
[00:54] <wgrant> Great, night :)
[00:54] <Bert_2> thx again
[00:54] <Bert_2> goodbye ;)
[01:17] <wallyworld_> sinzui: if you are still around, i like your suggestions to use 'Private' and 'Confidential' for PROPRIETARY and USERDATA respectively so am happy to make those changes
[01:17] <StevenK> The other way around, I'd say
[01:19] <wgrant> sinzui: branch_sharing_policy with ~registry-only UI is ready to be deployed to prod, and we should probably dogfood it on our private projects as soon as it is deployed and +sharing is turned on.
[01:23] <wallyworld_> StevenK: yes, you may be right there, although i was equating Private info type with Private project
[02:12] <sinzui> wgrant, thank you. I agree
[02:12] <sinzui> wallyworld_, I just replied to your text changes
[02:13]  * sinzui looks at query
[02:13]  * wallyworld_ looks at reply
[02:15]  * wallyworld_ can finally do some LOC reduction \\o/
[02:15] <sinzui> oh, do you want a list of methods I saw last week?
[02:17] <wallyworld_> sinzui: ok, why not
[02:18] <sinzui> wallyworld_, your query is very fast in staging. I think it might be doable in on run, but four is safe
[02:18] <wgrant> We're probably also nearly at the stage where we can go through and rationalise all our new methods.
[02:18] <wallyworld_> sinzui: yes, i'd rather err on the side of caution
[02:18] <wgrant> sinzui, wallyworld_: Note that production could be twice as slow as staging.
[02:18] <wgrant> Because production is still using slony
[02:19] <wallyworld_> wgrant: so if it times out, we can just reduce the batch size. is that the SOP for this?
[02:19] <wgrant> Precisely.
[02:19] <wallyworld_> cool. so let's hope 10000 is ok
[02:19] <wgrant> Just be aware that staging write timings are not particularly comparable to production atm.
[02:20] <sinzui> wallyworld_,  this is my revised query. I added the statement timeout for the select. We have no fear of hitting it.
[02:20] <sinzui> https://pastebin.canonical.com/70193/
[02:20]  * wallyworld_ looks
[02:20] <wallyworld_> sinzui: ok. so if i you your pastebin, i can mark that approved and get it actioned?
[02:21] <sinzui> wallyworld_, since we are adding policies in production now, I think we can run this now, starting on staging
[02:21] <wallyworld_> sinzui: yes agreed. so next step for that bug can be to remove and AAG for which there is a APG for the project?
[02:21] <sinzui> yes, it is approved. have you added the request to the sql query page?
[02:22] <wallyworld_> s/and/any
[02:22] <wallyworld_> yes
[02:22] <wallyworld_> pending approval
[02:26] <sinzui> wallyworld_, I do not think these classes in lp.app are used anymore: GotchiTiedWithHeadingWidget, LinkWidget, ContextWidget
[02:27] <wallyworld_> sinzui: cool. will spin up a branch. do you agree with the next step i should take for bug 1008541 ^^^^^
[02:27] <_mup_> Bug #1008541: Sharing policies unconfigure existing projects <bugs> <disclosure> <sharing> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1008541 >
[02:31] <lifeless> well
[02:32] <lifeless> production could be twice as slow as staging if staging had the same hardware.
[02:32] <lifeless> production may need to do twice as many writes, != twice as slow as staging :)
[02:32] <sinzui> wallyworld_, your sql might fix this bug. The ones for security contacts and bug supervisors have structural subscription nuances that I wanted to solve separately.
[02:33] <wallyworld_> sinzui: how? my sql only adds APGs for maintainers
[02:34] <lifeless> sinzui: btw I added a bug driver to obsolete-junk
[02:34] <lifeless> sinzui: and nuked the resulting struct sub
[02:34] <lifeless> sinzui: for less bug spam, I hope.
[02:34] <wgrant> Speaking of obsolete-junk
[02:34] <wgrant> sinzui: Did you nuke null over the weekend?
[02:34] <wgrant> I saw you remove bugs from it
[02:34] <wgrant> And now I can't find it
[02:35] <sinzui> 140 projects have bug supervisors that are different from the maintainers and drivers, and they expect to get notified. They wont be when we remove the code that hard codes structural subscriptions...thus a separate problem from what I asked you to fix
[02:35] <wallyworld_> yes
[02:35] <sinzui> wgrant, I did. mabey i renamed is /null-and-void
[02:35] <sinzui> after I deleted more bugs from it
[02:36] <wgrant> Ah, great.
[02:36] <sinzui> wallyworld_, and the security contact role will be deleted, so we need to setup structural subscriptions for the few projects that use the role, such as ourselved
[02:37] <wallyworld_> yes
[02:37] <wallyworld_> so how does my sql to add APG for maintainers help there?
[02:37] <sinzui> wgrant, I was reading code to follow up on your idea of moving all the pots to one project, then doing real series deletes
[02:38] <wgrant> sinzui: How does it look?
[02:38] <wgrant> I know Translations not well.
[02:38] <sinzui> wgrant, I think it will work. You can obsolete templates too, so they do not appear to accumulate
[02:40] <sinzui> wallyworld_, when I reported the bug, I did not know how few projects used the security and bug roles. Many place the maintainer team in the roles, btu they do not need to underder sharing...you maintainer sql fixes all but 140 cases
[02:40] <wallyworld_> right, understood. thanks
[02:40] <sinzui> wallyworld_, so maybe we want to write the query that finds these 140 exceptions, but we also need to make sure that those exceptions are not open teams
[02:42] <wallyworld_> sinzui: can do. and then we can give APG for embargoes security to those 140 bug supervisors
[02:42]  * sinzui looks for query that identified the bug supervisors
[03:13] <lifeless> sinzui: select count(distinct bugsupervisor) from project ?
[03:14] <sinzui> lifeless, we also want to exclude maintainer. We also saw that if we excluded drivers there was about 140.
[04:03] <huwshimi> Did someone break our js in trunk? Maybe combo related...
[04:03] <StevenK> huwshimi: Hm?
[04:06] <huwshimi> StevenK: Cannot read property 'app' of undefined, same for registry etc.
[04:08] <StevenK> Can I have a bit more context?
[04:09] <huwshimi> StevenK: Load any page, check js errors, that's it.
[04:10] <huwshimi> (On a fresh trunk)
[04:10] <huwshimi> Oh, LP_MODULES is not defined
[04:11] <StevenK> LP_MODULES comes from the meta file, so it looks like it now wants the combo loader set up
[04:12] <StevenK> huwshimi: Real quick: sudo mkdir -p /srv/launchpad.dev ; sudo make copy-apache-config ; make clean && make
[04:17] <huwshimi> StevenK: Perfect, thank you!
[04:18] <huwshimi> StevenK: Oh, except that it appears to break every time I 'make jsbuild'
[04:19] <huwshimi> brb
[04:19] <StevenK> huwshimi: The JS breaks or 'make jsbuild' gives an error?
[04:22] <huwshimi> StevenK: jsbuild runs fine, the js just breaks again
[04:22] <huwshimi> (LP_MODULES is not defined etc.)
[04:22]  * huwshimi ducks out for a minute
[04:23] <StevenK> 'make jsbuild combobuild'
[04:24] <StevenK> jsbuild blows away the combo loader directory, so no meta file again
[04:26] <wgrant> huwshimi: 'make jsbuild_watch' may be of interest
[05:54] <wallyworld_> StevenK: i was thinking - what about 'Private User' for the USERDATA title. That fits in with 'Private Security' and adds the extra qualifier to 'Private' to disambiguate the context
[05:55] <wallyworld_> And then the portlet can this "This report contains Private User information"
[05:55] <StevenK> Hmmmmm, maybe
[05:56] <wallyworld_> i'll hold off landing my branch and we can discuss tomorrow on the call
[05:57] <StevenK> wallyworld_: +1
[05:57] <wallyworld_> i just think 'Private' is too ambiguous and overloaded
[05:57] <StevenK> wallyworld_: The bikeshed should be red. Oh, and on fire.
[05:58] <wallyworld_> and it is private user data after all
[05:58] <wallyworld_> and the bikeshed should be purple, not red
[07:52] <adeuring> good morning
[07:54] <czajkowski> adeuring: morning
[07:54] <adeuring> hi czajkowski!
[07:55] <czajkowski> in the office today, all the orange walls have drawings on them, looks rather cool
[09:50] <mgz> jelmer: python2.7 backport not installable because:
[09:50] <mgz> python2.7: Depends: python2.7-minimal (= 2.7.3-0ubuntu4~lts0) but it is not going to be installed
[09:52] <maxb> mgz: Sounds like apt being typically unhelpful and reporting an intermediate dependency issue instead of the actual problem. Try 'apt-get install python2.7-minimal python2.7'
[09:52] <mgz> maxb: will ssh in and try that
[09:53] <mgz> python2.7-minimal: Depends: python-minimal (>= 2.6.6-3+squeeze1) but 2.6.5-0ubuntu1 is to be installed
[09:54] <mgz> the fun bit is there's no python2.7-minimal in the ~pythoneers/+archive/lts ppa
[09:54] <mgz> but it worked before the update aimed at fixing the ctypes import crash
[09:56] <jelmer> mgz: that lists just the source packages
[09:57] <jelmer> mgz: see https://code.launchpad.net/~pythoneers/+archive/lts/+packages
[09:57] <mgz> that is the page I'm on
[09:57] <jelmer> mgz: expand the python2.7 thingy
[09:58] <mgz> ...I need to enable JS for the page to actually work?
[09:58] <jelmer> mgz: yes, you'll need javascript :)
[09:58] <mgz> >_<
[09:58]  * jelmer drags mgz kicking and screaming out of the nineties
[09:59] <bigjools> how did you get a PPA url with *code*.l.n in it?
[09:59] <jelmer> bigjools: I type them by hand :)
[10:00] <bigjools> lordy
[10:01] <mgz> bigjools: it's either that or spend ten minutes trying to find how to get to a +recipies page from ~person by navigating links
[10:02] <bigjools> can you guess what I am going to say next? :)
[10:02] <czajkowski> bigjools: good night :)
[10:02] <jelmer> bigjools: patches welcome?
[10:02] <bigjools> jelmer: *bingo* :)
[10:02] <jelmer> bigjools: I hate FOSS
[10:02] <bigjools> cztab: almost!
[10:02] <bigjools> lol
[10:03] <czajkowski> bigjools: cheeky
[10:03] <czajkowski> how are the little ones doing?
[10:03]  * czajkowski hugs jelmer at least you didn't say floss!
[10:03] <bigjools> czajkowski: champion thanks!
[10:04] <bigjools> they are asleep right now, so even more betterer
[10:04] <czajkowski> win.
[10:04] <bigjools> so much so I am heading out of the office and into the living room to watch TV and drink some whisky
[10:04] <czajkowski> mate had twins 7 years ago, they are very cute to watch. they had them seperated when they were born into different cots and refused to sleep, their mum moved them into one cot against nurses wishes and they slept
[10:04] <jelmer> bigjools: enjoy your evening :)
[10:05] <bigjools> czajkowski: ours are in the same cot
[10:05] <bigjools> jelmer: cheers, enjoy your day!
[10:05] <czajkowski> bigjools: they stil at times wake up and one climbs into the others bed to sleep it's very cute.
[10:06] <bigjools> ha!
[10:06] <wgrant> mgz: There's a "View source package recipes" link near the PPA listing on Person:+index
[10:08] <bigjools> right, night all
[10:08] <jelmer> wgrant: only if they actually own any recipes
[10:08] <mgz> right, the fun part was the person had a linked ppa, but the team owned the recipes
[10:08] <jelmer> wgrant: which makes sense to some extent, but is confusing if you want to figure out if they own any recipes
[10:09] <mgz> and from the ppa pages there seemed to be no way to get to the recipes that built them
[10:10] <wgrant> mgz: The recipe is linked from the expandy section of the package
[10:10] <wgrant> Since a recipe does not build a PPA, but a package.
[10:11] <wgrant> Also, the expandy bits on +packages fall back to normal links for those who won't enter this century.
[10:11] <jelmer> wgrant: that requires having javascript enabled though
[10:11] <jelmer> wgrant: not everybody has gone with the times ;)
[10:12] <wgrant> I ran NoScript for years, but even I gave in in early 200
[10:12] <wgrant> 2009
[10:35] <mgz> jelmer: so, I don't see why Depends: python-minimal (>= 2.6.6-3+squeeze1) is needed in the context of that ppa
[10:40] <mgz> okay, so updating python2.6 in that ppa is the sensible answer.
[10:40] <jelmer> mgz: yes :)
[11:04] <stub> Looks like a yui tweak has broken buildbot, strangely the db branch
[11:28] <rick_h_> jcsackett: ping, the linkify navigation code has hit qa staging if you get a chance to peek at the sharee side of it
[11:30] <wallyworld_> rick_h_: hi
[11:31] <wallyworld_> rick_h_: i just got back from soccer training and was looking to qa that bug you asked me to look at, but js on qastaging is broken
[11:33] <wallyworld_> rick_h_: gotta run out and pick up my son, back in a bit
[11:39] <rick_h_> wallyworld_: np, looking and starting now
[12:09] <wallyworld_> rick_h_: fyi, combo loader was broken on staging today, i think some scripts were looked at, not sure exactly what was done, may be related
[12:16] <rick_h_> wallyworld_: yea, I'm in -ops looking into it thanks
[12:16] <wallyworld_> cool, thanks
[12:16] <rick_h_> wallyworld_: I was landing the branch to wire up the multi-yui feature flag at the same time so boom
[12:17] <wallyworld_> good luck :-)
[13:42] <mgz> anyone got ideas on what will have broken +branch redirects for bzr branches recently?
[13:43] <mgz> nothing looks obvious from the log from r15627
[13:43] <mgz> 1.067  hpss call:   'BzrDir.open_2.1', '+branch/qbzr/'
[13:43] <mgz> 1.068               (to bzr+ssh://bazaar.launchpad.net/+branch/qbzr/)
[13:43] <mgz> 5.076     result:   ('no',)
[13:44] <mgz> that used to correctly get you to ~qbzr-dev/qbzr/trunk2a
[13:45] <mgz> any tips for debugging what's going wrong?
[13:47] <deryck> abentley, adeuring, rick_h_ -- firing up a stand-up hangout now...
[13:47] <czajkowski> deryck: any of you guys blog and if so want your feeds added to planet.lp
[13:48] <deryck> czajkowski, mine is already on it.
[13:48] <czajkowski> yup
[13:49] <deryck> adeuring, https://plus.google.com/hangouts/_/bb3726a1e785f252b50151030e19c86f5ad6b04f?authuser=0&hl=en
[13:50] <jelmer> one of these days I'm going to accidentally join a standup
[13:50] <mgz> you'd be welcome I'm sure
[13:50]  * jelmer has a tendency to click on any link people post on IRC
[13:50] <mgz> I suspect you might be saved by the google talk plugin crashing or something
[13:50] <czajkowski> jelmer: likewise I almost tempted one day to join wave and say good bye!
[13:51] <czajkowski> in a meeting for the next hour folks so wont be watching #launchpad.
[13:57] <abentley> mgz: Could be bug #1025368
[13:57] <_mup_> Bug #1025368: Launchpad not handling +branch redirects for http anymore <codebrowse> <codehosting> <regression> <Launchpad itself:Triaged by abentley> < https://launchpad.net/bugs/1025368 >
[13:58] <mgz> abentley: thanks, having a look
[13:59] <mgz> ah, the tarball thing, yup, could be the same issue
[14:04] <abentley> mgz: Yes, I'm pretty sure it applies to all loggerhead stuff.
[14:04] <abentley> mgz: I'm working on it.  Kinda confusing, but it looks like it might be a loggerhead bug.
[14:04] <mgz> well, this isn't loggerhead, it's just trying to access the branch at all
[14:05] <mgz> but the redirect/handypath is part of the loggerhead infrastructure?
[14:06] <abentley> mgz: Oh, I misread you because the SSH stuff isn't an actual redirect.
[14:07] <abentley> mgz: I don't know of any ssh issues.  In fact, I thought I'd tested SSH pretty throroughly.
[14:08] <mgz> yeah, bad term, it's like an apache internal redirect
[14:08] <mgz> is there a way I can get more details from inside launchpad than just "no" to is a branch here?
[14:08] <abentley> mgz: e.g. bzr info bzr+ssh://bazaar.launchpad.net/+branch/bzr works just fine.
[14:09] <mgz> right
[14:09] <mgz> most branches are still fine, which is why I suspected privacy/stacking at first
[14:09] <abentley> mgz: What? Is this SSH or not?
[14:09] <mgz> but iwata reported lp:qbzr and lp:tortoisebzr are both borked
[14:09] <abentley> If it's SSH, it isn't an apache thing.
[14:10] <mgz> abentley: sorry, confusing things, I just don't know what we call the +branch aliases
[14:10] <abentley> mgz: We call them aliases.
[14:10] <mgz> okay. :)
[14:10] <abentley> mgz: And the +branch-id ones are called "id aliases"
[14:11] <mgz> so, some of them are borked, but I don't know why and I don't know how to find out
[14:12] <abentley> mgz: Okay, I'd call this a new bug.  Might be related to 1025368, might not.
[14:13] <mgz> will file.
[14:14] <abentley> mgz: I don't know of a way to get more info.
[14:14] <abentley> mgz: I'll check whether getByUrl works.
[14:17] <abentley> mgz: getByUrl returns nothing, so it looks like a it's a problem in their common code.
[14:19] <mgz> okay, so also 15609 related?
[14:20] <abentley> mgz: most likely.
[14:21] <abentley> mgz: The lookup function is BranchLookup.getByHostingPath
[14:24] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/fix-packagediff-private-harder/+merge/115352
[14:24] <cjwatson> (or any OCR come to that)
[14:25] <mgz> he's meant to be on holiday!
[14:26] <cjwatson> So am I :-P
[14:26] <cjwatson> But he threw that critical bug in my direction this morning, seeing as I caused it ...
[14:28] <mgz> :D
[14:28] <rick_h_> cjwatson: will look now to try to get that fixed
[14:28] <abentley> mgz: btw, I doubt stacking is related, because ~qbzr-dev/qbzr/trunk2a is not stacked on anything.
[14:29] <mgz> right, seems like it's just the alias resolution.
[14:29] <mgz> but I'm still not sure what's special about qbzr/tortoisebzr
[14:29] <rick_h_> cjwatson: r=me
[14:30] <cjwatson> Thanks, will land now
[14:30] <abentley> mgz: bzr and qbzr are both public, so I don't see how privacy would affect one but not both.
[14:51] <mgz> so, one thing that strikes me about qbzr and tortoisebzr is they both moved their trunk in the past
[14:52] <mgz> ...but other projects that relocated aren't affected
[15:00] <abentley> mgz: Didn't bzr also relocate its trunk?
[15:01] <mgz> abentley: not sure, but lp:leo-editor did and that resolves.
[15:02] <mgz> (if bzr did it, was before qbzr did the move for 2a, and leo-editor was since then)
[15:02] <abentley> mgz: I may be wrong about bzr relocating.
[15:14] <rick_h_> abentley: as a job expert, just want to sanity check the assertion in this small MP https://code.launchpad.net/~cjwatson/launchpad/simplify-packagecopyjob-tests/+merge/115159
[15:15] <abentley> rick_h_: looking...
[15:16] <abentley> rick_h_: All looks sane to me.
[15:16] <rick_h_> abentley: ok, just wanted to sanity check the idea that it's all the same and makes sense to run the jobrunner directly
[15:17] <rick_h_> vs something that could go bad in tests later
[15:17] <rick_h_> abentley: ty much
[15:17] <abentley> I do think it makes sense to run the jobrunner directly.
[15:18] <abentley> I suppose you could argue it changes the tests slightly, in that it makes assertions about the end-state instead of the exception being raised.  I think the end-state is the most important thing, though.
[15:21] <rick_h_> abentley: yea, was more worried of unexpeced side effects, possible cleanup/test pollution or timing side effects
[15:21] <abentley> rick_h_: I don't see any potential for that.
[15:23] <cjwatson> rick_h_,abentley: The other thing I probably should have pointed out in the MP is that all the other similar tests I could find were already using the jobrunner directly.
[15:23] <cjwatson> I wondered if PCJ was an early adopter or something.
[15:23] <rick_h_> ah thanks cjwatson
[15:31] <sinzui> czajkowski, jcsackett: I am about to fall off the net. My computer reports power problems and I need to power off to investigate.
[15:48] <jcsackett> and away he goes ...
[16:53] <sinzui> rick_h_, I just occurred to me that 3 years ago YUI domready had issues so scripts were trying to mutate the dom during load, which is dangerous, so the spinners were hard-coded into the template
[17:10] <rick_h_> sinzui: where is this? /me is missing the context
[17:12] <sinzui> rick_h_, I was thinking out loud as I was reading code. Why is the spinner hard-coded in the template? why is the script using on load, then I remembered the age of the code and concluded that spinners are hard coded because progressive enhancement can fail if you mutate the dom as it is loaded
[17:13] <rick_h_> sinzui: ah, that's an old IE issue true
[17:13] <sinzui> We were using firefox 3, no webkit browser either.
[17:14] <rick_h_> right, yea understandable for sure
[17:14] <rick_h_> I'm trying to track down the latest IE with the issue, I recall it
[17:14] <sinzui> I think I have an opportunity to clean up this code is my branch has nothing else for me to do
[17:14] <sinzui> s/is/if/
[17:15] <rick_h_> the other thing to realize though with spinners like that is that the combo loader call is async, so there's a delay in kicking in if you need to avoid flashing the user
[17:15]  * rick_h_ isn't sure where you're looking at/etc
[17:16] <rick_h_> http://blog.gidley.co.uk/2009/11/ie-7-and-domloaded.html
[17:16] <sinzui> rick_h_, yes, I think that is a legitimate case to add the spinner right away. The example I see is a user initiated action
[17:17] <rick_h_> ah, here is the thing I was thinking "Internet Explorer note: It isn't always safe to modify content during the available/contentready until after the domready moment. In this browser, domready will execute before the available/contentready listeners.
[17:17] <rick_h_> "
[17:17] <sinzui> YUI 3 ensures that available and contentready fire after domready
[17:18] <rick_h_> right
[17:18] <rick_h_> this was from 3.2 notes http://yuiblog.com/sandbox/yui/3.2.0pr1/examples/event/event-timing.html
[17:19] <sinzui> There was some definite madness in the past. Since it was not documented in the code, I can only guess at why I keep find on load and hidden spinners in the templates
[17:20] <rick_h_> well the biggest thing these days is probably the copy/paste syndrome
[17:21] <sinzui> rick_h_, while i have your attention. I wanted overlays to always return focus to their EDITION when they closed so keyboard navigation does not bounce back to the top of the page.
[17:21] <rick_h_> ah interesting
[17:22] <sinzui> It didn't work, well, this.get('editicon').focus(); didn't work, or what every attr was the supposed trigger for the overlay
[17:23]  * rick_h_ looks
[17:23] <sinzui> I had some unsuccessful tests with activeElement a few weeks ago. I was thinking that when the overlay is displayed, it captures what had focus, then calls focus in destroy or hide
[17:23] <rick_h_> right, was going to ask when you were trying to focus back
[17:24] <rick_h_> I think it'd be a something interesting to do as when visible change or destroy as you say
[17:24] <sinzui> I was playing with IE too, so I may have been dealing with some propagation differences
[17:25] <rick_h_> determining what had focus is hard. I wonder if there's a way to some sort of master 'focus tracker' .delegate() event on BODY to keep tabs on focus and query it
[17:26] <sinzui> We know our overlays use the editicon (or the linked value) so that might be the right answer all the time
[17:27] <rick_h_> yea, I wasn't sure if they could be determined by id/explicitly
[17:29] <sinzui> I agree. this certainly would be problematic if we ever convert help to an overlay
[17:30] <rick_h_> I thought it was?
[17:45] <rick_h_> sinzui: http://jsfiddle.net/mmcTL/11/ is a bad example because you'd want to filter the delegate to only things that are on the main page, not overlays/added content
[17:46] <rick_h_> but it looks like you could delegate onto the body, watch for focus events, track them, and then that tracker could listen for some sort of restore event to refocus manually back where it was left off
[17:46]  * sinzui bookmarks
[17:46] <sinzui> thank you!
[17:46] <rick_h_> so on the destroy/hide events of widgets, you'd fire a Y.fire('returnFocus') or something
[17:46] <rick_h_> sinzui: np, interesting idea
[17:48] <deryck> Ah, the joys of stable internets again.
[17:49] <deryck> abentley, adeuring, rick_h_ -- hi, there. I'm connected again. :)
[17:49] <abentley> deryck: yay!
[17:50] <rick_h_> deryck: welcome back to the land of the wired
[17:51] <deryck> I'm so kicking AT&T to the virtual curb.  Soon as I find another option.
[17:51] <czajkowski> sinzui: comment on your blog post http://blog.launchpad.net/general/launchpad-does-not-have-private-projects-yet
[17:54] <rick_h_> hah, greg causing trouble
[17:54] <czajkowski> you have no idea the amount of trouble that line cause
[17:54] <czajkowski> spend all weekend discussing it in various channels
[17:55] <rick_h_> czajkowski: greg used to be local, started the MI loco, so friend of mine. Not surprised he latched onto that
[17:55] <czajkowski> we're on the loco council together :)
[17:55] <rick_h_> ah right cool
[18:02] <czajkowski> sinzui: to be fair we're moving out stuff outta kanbahns to blueprints I though as they our tool
[18:03] <sinzui> czajkowski, we are not
[18:03] <sinzui> czajkowski, the launchpad team does not use blueprints
[18:04] <czajkowski> no we don't currently
[18:04] <czajkowski> was under the impression that was changing in the future, but it was a slow process
[18:10] <deryck> czajkowski, if that line from sinzui caused a lot of trouble, I'd guess there is more to people's frustrations than any sin caused by a single sentence.
[18:10] <czajkowski> deryck: people dont have much to do at weekends
[18:10] <deryck> czajkowski, said people should game more then.
[18:11] <deryck> open source tempers could be swayed by more gaming.  I swear it's true.
[18:11] <czajkowski> deryck: or submit patches for LP :_)
[18:11] <deryck> well, I was thinking something fun to do. :-P
[18:11]  * deryck totally kids
[18:12] <czajkowski> right finally leaving the office
[18:12] <czajkowski> nn
[18:44] <sinzui> jcsackett, has ec2 explained why it does not want users to hide comments?
[18:45] <jcsackett> sinzui: well, i still don't know why the one run died silently, but i have resolved all the errors in the hate mail and have a run that appears to be going smoothly now.
[18:46] <sinzui> will you lp-land it?
[18:48] <jcsackett> once i get a completed test run back; some of the errors in the hate mail was from a few places where i had been dumb about which code needed to be altered with the feature flag, so i had to update that. i want to see a complete ec2 run.
[18:48] <sinzui> understood
[19:12] <sinzui> rick_h_, do you habe time to review https://code.launchpad.net/~sinzui/launchpad/add-private-member/+merge/115419
[19:20] <rick_h_> sinzui: not atm, sorry. Can later tonight.
[19:20] <sinzui> thats okay, I will ask jcsackett who I discussed the issue with
[19:20] <sinzui> jcsackett,  do you have 10 minutes to review https://code.launchpad.net/~sinzui/launchpad/add-private-member/+merge/115419
[19:21] <jcsackett> sinzui: I will in just a moment.
[19:23] <jcsackett> sinzui: ok, looking now.
[19:25] <jcsackett> sinzui: that's not even a 10 min branch to look at, given we both already know the backstory. :-)
[19:25] <sinzui> I thought as much.
[19:25] <jcsackett> r=me. glad it was what we had assumed.
[21:30] <jcsackett> sinzui: comments branch had a successful testrun, and has landed. should be playing on buildbot soon.
[21:58] <sinzui> \o/
[22:51] <wallyworld_> rick_h_: yo
[22:55] <rick_h_> wallyworld_: hey, howdy. in the last hour before the kid goes to bed so in/out
[22:56] <wallyworld_> rick_h_: just a quick thing - i looked at qa ing the report a bug link and it's still broken
[22:56] <wallyworld_> rick_h_: i can mark it as qa-ok but the bug will need more work
[22:57] <rick_h_> wallyworld_: crap, broken how?
[22:57] <wallyworld_> rick_h_: clicking on it does nothing
[22:57] <wallyworld_> we for me anyway
[22:57] <wallyworld_> well
[22:57] <rick_h_> looking
[22:58] <wallyworld_> i looked at https://bugs.qastaging.launchpad.net/launchpad
[22:58] <rick_h_> hmm, html is fixed
[22:58] <rick_h_> https://bugs.qastaging.launchpad.net/launchpad/+bugtarget-portlet-bugfilters-stats 503?
[22:59] <rick_h_> hmm, not sure why it's not clicking now though, the html is cleaned up correctly so something else is wrong, no idea off the top of my head
[22:59] <rick_h_> will have to look after the boy goes to bed and maybe in the morning. *sigh*
[23:00] <wallyworld_> rick_h_: np. i'll mark as qa-ok and set back to in progress
[23:01] <rick_h_> wallyworld_: yea, so the link is there, has an href, so someone is catching it and killing the event somewhere.
[23:02] <rick_h_> the li has class js-action and inactive on it for some reason, wonder if that's some of it
[23:02] <rick_h_> maybe huw can peek if he's around today as I thought his html updates where part of what changed
[23:02] <wallyworld_> rick_h_: i'll see if i can get to it today, and you can pick it up for your SOD tomorrow
[23:02] <rick_h_> wallyworld_: np, just trying to think out loud while looking.
[23:03] <rick_h_> I could have sworn it worked locally, if you get a sec do me a fav and see if local matches qa please
[23:03] <wallyworld_> ok, sec
[23:05] <wallyworld_> rick_h_: works locally with dev
[23:05] <wallyworld_> go figure
[23:06] <rick_h_> wallyworld_: yea see...ugh so something strange is up...qastaging hates me today.
[23:07] <rick_h_> ok, well that's a hint so will look more. wonder if it's combo loader related
[23:07] <wallyworld_> rick_h_: yeah, i might leave it to you for tomorrow then
[23:07] <rick_h_> see if you can get the combo loader feature flag turned on in qa staging (it's off by default still I believe) and then no idea wtf would be wrong there.
[23:07] <wallyworld_> ok
[23:07] <rick_h_> wallyworld_: rgr, sorry, thanks for the help and report, will stick on it like glue
[23:08]  * rick_h_ is annoyed this 'simple' thing is still broken is
[23:08] <rick_h_> is all, the 24hr to edit/land sucks with this stuff
[23:08] <wallyworld_> yep
[23:10] <wallyworld_> rick_h_: getting flag on qas right now
[23:10] <StevenK> I know we turned it off on staging yesterday, I wasn't sure about qas
[23:10] <wallyworld_> StevenK: it's off, getting it back on to see what happens
[23:14] <rick_h_> StevenK: side note, I asked you to review a branch that adds a dep to launchpad-deps for unzip so we can use the upstream yui .zip files pls
[23:14] <wallyworld_> rick_h_: broken with combo loaded also
[23:14] <wallyworld_> loader
[23:15] <rick_h_> StevenK: can you peek/help me get that updated please?
[23:15] <rick_h_> wallyworld_: ok cool, that actually makes me feel better tbh
[23:15] <rick_h_> ok, bath time for the boy, will check back in later .Thanks again guys
[23:15] <wallyworld_> rick_h_: good luck with this...
[23:22] <cjwatson> Is https://code.launchpad.net/~jml/lazr.restfulclient/multiple-instance-safe/+merge/98873 ever likely to make it into an actual release?  It'd be nice to get this into quantal and precise-updates
[23:31] <cjwatson> bigjools: How would you feel about switching on soyuz.copypackageppa.enabled for everyone and setting soyuz.derived_series.max_synchronous_syncs to 1 for launchpad-beta-testers, now that failed PCJs are shown in the web UI?  I've tried similar things on dogfood and haven't noticed any problems with async copies there.
[23:31] <cjwatson> It'd be pretty awesome to be able to make the async code work for everyone and remove the sync code.
[23:32] <bigjools> I'd feel ecstatic but I also don't feel I'm currently in a good enough position to judge  this since I've not worked on LP since January
[23:32] <bigjools> desperately trying to keep up with developments though!
[23:32] <cjwatson> OK.  Should I get some other TL to have a look?
[23:32] <bigjools> removing the sync code might be problematic
[23:32] <bigjools> some people depend on that behaviour
[23:33] <cjwatson> Hm.  Any pointers?
[23:33]  * bigjools racks brain to think who objected
[23:33] <cjwatson> I'm just talking about the sync mode in Archive:+copy-packages, not the Archive.syncSource API
[23:33] <bigjools> ah!
[23:33] <bigjools> that's probably ok then
[23:34] <bigjools> it might be a good idea to blog/tweet about this change in advance
[23:34] <bigjools> and as you say turn it on for beta testers first
[23:34] <cjwatson> I already know the libreoffice guys will love it :-)
[23:35] <bigjools> :)
[23:35] <cjwatson> (Well, assuming it works)
[23:35] <cjwatson> But yeah, you're right
[23:35] <bigjools> I'd also email the -users list (mmm do we have a beta users list?)
[23:36] <cjwatson> Removing the +copy-packages sync mode is about -200 LoC, but it's one of the last steps on the way for removing delayed copies which is -1100 or so
[23:36] <bigjools> \o/
[23:36] <cjwatson> ~launchpad-beta-testers just tells people to join ~launchpad-users
[23:36] <bigjools> ok
[23:37] <cjwatson> All right then.  I ought to go to bed, but I'll see if I can persuade jam or somebody in the morning to approve a feature flag change, and talk to czajkowski about the comms
[23:37] <cjwatson> Thanks
[23:43] <bigjools> cjwatson: np.  Sorry, I'd love to approve it, I would, but that would make be responsible for something that I wasn't involved in lately :)
[23:43] <bigjools> me*
[23:45] <cjwatson> Yeah, makes sense
[23:45] <cjwatson> I can start writing a blog entry in the meantime
[23:45] <bigjools> cool
[23:53] <rick_h_> StevenK: thanks for the catch on the email. The reason I ping'd you specifically as I wasn't sure how to process from here on it and wanted to make sure I got it right.
[23:53] <rick_h_> StevenK: so do I submit to trunk, then dput up to the ppa, and everything should catch the update there?
[23:54] <StevenK> rick_h_: Just commit to trunk, a recipe does everything else.
[23:54] <rick_h_> StevenK: ah, even better then
[23:55] <rick_h_> StevenK: so then does something cause the ppa to pull updates on the machines? qa/etc?
[23:55] <rick_h_> or do I somehow trigger production/qa servers to run an apt-get upgrade?
[23:55] <StevenK> That happens seperately. You need to talk to webops about it.
[23:56] <rick_h_> ok, cool. I want to make sure I do things in the right order to prevent borking things again
[23:56] <StevenK> But you keep borking things anyway :-P
[23:57] <rick_h_> I try not to!!! lol
[23:57] <rick_h_> I'm cursed this last week I tell you


[12:12] <B1G> Hi all
[12:19] <B1G> i can't connect mythbox addon for xbmc to mythbackend
[12:19] <B1G> anyone can help me?


[17:47] <Kangarooo> Do ubuntu MATE also have wallpaper contest 23.10? https://ubunlog.com/en/ubuntu-23-10-mantic-minotaur-opens-its-wallpaper-contest/