[14:25] <odin_> hello, can anyone assist with how to change the URL for automated source code import from remote SCM ?
[14:26] <odin_> gitorious.org is no more, so I need to change the import location to point to github.com
[14:27] <odin_> https://code.launchpad.net/~qtjambi-community/qtjambi/master  this is the relevant SCM import that is now broken
[14:29] <odin_> also both remote SCM systems are git, can it resync, keeping the BZR revision numbers intact ?
[14:29] <dobey> odin_: delete the branch and create a new import
[14:30] <dobey> odin_: no, the bzr revno is unrelated to what the git revision numbers are. they are not persistent, and will change at next import, if someone does a rebase on the git master tree for example
[14:31] <odin_> if I delete the branch, there are 10 recipies using it, they still remain intact (but broken) ?
[14:31] <odin_> when I re-create the branch those recipies will start using the changed data ?
[14:50] <dobey> odin_: oh no, the recipes will be deleted i think
[14:50] <dobey> or they will prevent you from deleting the branch or something
[14:51] <dobey> so you might just need to create a new import and then change the recipes to use the new branch
[14:51] <dobey> or you might be able to just edit the url
[14:51] <dobey> https://code.launchpad.net/~qtjambi-community/qtjambi/master/+edit-import
[14:52] <dobey> sometimes it doesn't work so nice, but since they're both still git, it might be doable
[15:04] <odin_> Not allowed here ... https://code.launchpad.net/~qtjambi-community/qtjambi/master/+edit-import
[15:04] <dobey> what's the new git URL?
[15:04] <cjwatson> It's usually best to create a new import
[15:05] <cjwatson> Although
[15:05] <cjwatson> odin_: Was the gitorious repository just moved directly to github?
[15:05] <cjwatson> Not a reimport or anything?
[15:05] <odin_> moved directly ?  yes I believe the history is intact
[15:06] <cjwatson> OK, bzr history can stay intact then
[15:06] <cjwatson> odin_: Is it https://github.com/qtjambi/qtjambi ?
[15:06] <odin_> does launchpad prefer a git: or https: ?
[15:06] <odin_> yes that is new URL
[15:06] <cjwatson> odin_: I've updated it for you
[15:06] <dobey> ah
[15:07] <dobey> i guess i won't do it then :)
[15:08] <cjwatson> https://code.launchpad.net/~qtjambi-community/qtjambi/master shows the latest revisions now
[15:17] <odin_> ah great all looks to be building now, and some much needed maintenance completed (all but fixing build issues)
[15:17] <odin_> updated project to include: utopic, vivid, wily
[15:31] <Peng> https://blog.benjojo.co.uk/post/auditing-github-users-keys <- wonder if anyone's scanned LP
[16:08] <odin_> in "control" file Build-Depends can I use something like "package-name (>= 3.4 || >= 2:0.0 || >= 3:0.0)"  ?
[16:10] <cjwatson> odin_: That's synonymous with "package-name (>= 3.4)", since 2:0.0 >= 3.4
[16:10] <odin_> but can I use || expression there ?
[16:10] <cjwatson> You could write "package-name (>= 3.4) | package-name (>= 2:0.0) | package-name (>= 3:0.0)", but no point in this case.
[16:11] <odin_> ok understand
[16:11] <cjwatson> You can't use | inside the parentheses.
[16:11] <odin_> well my example is contrived, but am trying to understand why packages are listed in http://packages.ubuntu.com/search but not picked up during build
[16:12] <cjwatson> It would be easier if you linked to the build
[16:14] <odin_> can I make a build package "optional" ?
[16:14] <cjwatson> You can do Build-Depends: foo | base-files
[16:15] <cjwatson> Which has much the same effect.  It introduces variability which may not be a good idea though
[16:54] <jhobbs> are draft inline comments on a MP lost if someone pushes an update to the MP/
[16:59] <jhobbs> yes.. yes they are.
[17:40] <dobey> jhobbs: draft? you mean if you reload the page, before hitting the submit button on the comment form?
[17:41] <jhobbs> dobey: yeah
[17:41] <jhobbs> they are still there if you just reload the page or open it in another window
[17:41] <jhobbs> but if someone pushes a new revision of the branch being merged they go away
[17:42] <dobey> odd. i'm not quite sure how it is implemented, but i'm guessing your browser cleared the form when the page ETag or whatever changed
[17:43] <jhobbs> well, the comments are stored server side, just not published for others to see until you save the comment
[17:43] <jhobbs> inline comments specifically, not the textbox contents
[17:44] <dobey> they only stored on the server after you submit the form, afaik
[17:45] <jhobbs> naw, the inline comments are server side as soon as you add one. just checked and i can see it in firefox when adding in chrome
[17:52] <dobey> oh, weird