[16:53] <toan_> hi, I am creating a build recipe, and that I store the build dependency (debian folder) in a different branch of the dev branch.... ie) dev branch hello/trunk, control files would be in hello/recipe... I want to know if that's acceptable... or is there a better way?
[16:54] <toan_> so, when i build the package, its a matter of merging the dev branch and the recipe branch
[16:55] <cjwatson> That sounds like the kind of thing you can do with "nest" or maybe "nest-part" depending on the exact layout
[16:55] <cjwatson> The directory has to end up being called "debian" and at the top level of the source tree at the point when the source package is built by the recipe build, but it's up to you how you get it there
[16:55] <toan_> cjwatson, yeah you're right, but is it good practice to store the recipe in another branch of the project, or should i create another project just to save the control files
[16:56] <cjwatson> Personally I strongly prefer having full-source branches, so my packaging branches are descendants of the upstream branch and contain the full upstream source code, and I merge when new upstream releases happen.  But there are various schools of thought on this.
[16:57] <cjwatson> Creating another project seems overkill.
[16:57] <toan_> cjwatson, i see that some people create another project for the control files, that's why I am asking
[16:58] <cjwatson> Another project in the technical Launchpad sense, or are you using that term loosely?  URLs would help.
[17:00] <toan_> well, if you look at project enlightenment-svn, some build dependencies are stored in another project... The files are not stored in the same project or in a different branch
[17:00] <dobey> having a branch that contains the contents of debian/ under the same project is fine
[17:01] <cjwatson> Which particular recipe are you talking about?  lp:enlightenment-svn has 23 recipes, I'm not looking through them all
[17:01] <cjwatson> URLs please :-)
[17:01] <toan_> dobey, thanks for the comfirmation, it just makes more sense to do that,,,
[17:02] <toan_> cjwatson, hang on
[17:02] <toan_> https://code.launchpad.net/~hannes-janetzek/+recipe/e20-daily
[17:03] <toan_> in there, he pulls in the debian control folder from ubuntu
[17:03] <cjwatson> Uh ... not as far as I can see
[17:04] <toan_> enlightenment-svn is his personal repo
[17:04] <cjwatson> Everything in that recipe comes from the same project
[17:04] <toan_> but lp:enlightenment-svn is Ubuntu's
[17:04] <dobey> no
[17:04] <cjwatson> No it's not
[17:04] <toan_> i though everything that starts with lp: is from Ubuntu
[17:04] <toan_> Ubuntu repo
[17:04] <cjwatson> No
[17:05] <cjwatson> lp: is just an abbreviation for bzr+ssh://bazaar.launchpad.net/ or https://bazaar.launchpad.net/ depending on what the client can do
[17:05] <cjwatson> It just means it's hosted on Launchpad
[17:05] <dobey> that is a project that person created for building daily packages of enlightenment for ubuntu on launchpad
[17:05] <cjwatson> lp:enlightenment-svn is shorthand for https://code.launchpad.net/~enlightenment-git/enlightenment-svn/packaging
[17:05] <cjwatson> And it's totally user-owned
[17:06] <cjwatson> The two branches in use in that recipe are lp:~hannes-janetzek/enlightenment-svn/e20-git and lp:enlightenment-svn, which are two different branches attached to the same project
[17:06] <toan_> sorry for my ignorance, how do you know this:  lp:enlightenment-svn is shorthand for https://code.launchpad.net/~enlightenment-git/enlightenment-svn/packaging
[17:07] <toan_> the relationship
[17:07] <jelmer> toan_: bzr info lp:enligtenment-svn
[17:07] <cjwatson> Go to https://code.launchpad.net/enlightenment-svn and you'll see a link which goes there
[17:07] <toan_> do you have to search the site to findout
[17:07] <toan_> oh
[17:07] <cjwatson> Or what jelmer said, or https://code.launchpad.net/+branch/enlightenment-svn takes you straight there
[17:08] <cjwatson> (you can always replace lp: with https://code.launchpad.net/+branch/ to find out what it expands to using only a browser)
[17:08] <cjwatson> Anyway, in general, lp:<project name> is whatever the maintainer of that project has designated to be the development focus branch for that project
[17:09] <cjwatson> It usually has nothing much to do with Ubuntu
[17:09] <toan_> oh
[17:10] <cjwatson> You would normally expect lp:~<user>/<project>/<branch> to be branched off lp:<project>, or at least to be closely related, but it's not actually mandatory
[17:10] <toan_> cjwatson, to have a lp:project, one has to register the project with launchpad right?
[17:11] <toan_> b/c I have only been creating personal branches,
[17:11] <cjwatson> Yes
[17:12] <toan_> ok, that's what I haven't gotten into yet, only experimenting with personal/user branches
[17:12] <cjwatson> But if it's based on an existing project's code, you should push branches to that project (lp:~your-username/project/branch-name) rather than creating a new project, which would be clutter
[17:12] <roadmr> hm, how does one create e.g. lp:ubuntu/xenial/checkbox? I tried pushing directly and got an error. The dput went through OK, so it's not critical, just curious
[17:12] <cjwatson> roadmr: one doesn't
[17:13] <cjwatson> roadmr: creating the default branch there is a privileged op, but the importer is currently disabled because it's mostly too broken to live, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
[17:14] <cjwatson> roadmr: basically those branches tended to work until somebody actually tried to use them
[17:15] <roadmr> cjwatson: ah, I was thinking something like that, yes.
[17:15] <roadmr> cjwatson: no biggie, as I said the dput went through just fine so I'm all sorted out.
[17:15] <federico3> hi
[17:15] <roadmr> thanks :)
[17:16] <federico3> is there a way to encrypt/hide/restrict some files uploaded to launchpad?
[17:17] <dobey> why would you do that? launchpad isn't a generic storage service
[17:18] <dobey> if you want private projects/etc… you can get a commercial support contract
[17:18] <dobey> https://launchpad.net/+tour/join-launchpad#commercial
[17:19] <federico3> a bug (which should be public) contains some files uploaded by an users that might contain sensitive data
[17:20] <dobey> verify there is no sensitive data; if there is, then it shouldn't be made public
[17:21] <dobey> there's no way to encrypt/restrict existing attachments. they could be deleted. comments can possibly be hidden
[17:21] <dobey> but the original description will always remain in history i think, even if edited
[17:22] <federico3> the description is ok
[17:23] <toan_> cjwatson, i am writing a recipe to build wireshark from my dev project, it can not find the branch, can you help please:  https://code.launchpad.net/~tpham3783/+recipe/wireshark-daily
[17:23] <toan_> cjwatson, the error was "https://code.launchpad.net/~tpham3783/+recipe/wireshark-daily"
[17:24] <toan_> "bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~tpham3783/wireshark/trunk/"."
[17:25] <dobey> toan_: you have to wait for import to finish
[17:25] <cjwatson> You can see the import progress on https://code.launchpad.net/~tpham3783/wireshark/trunk
[17:26] <cjwatson> IIRC for big branches it takes several passes.  Wait for "Recent revisions" to say something useful
[17:28] <toan_> my bad
[17:32] <federico3> thanks dobey
[21:54] <toan_> my project built successfully when building it locally and with option --allow-fallback-to-native
[21:54] <toan_> however, it failed to build on the launchpad server, how do i fix it
[22:32] <toan_> hi, the auto launchpad build does not create 32bit binaries for vivid, what can I do not make 32bit vivid?
[22:33] <toan_> cjwatson, !
[22:33] <cjwatson> toan_: when you're asking about a failure, please link to it
[22:34] <toan_> https://code.launchpad.net/~tpham3783/+recipe/hello-github-daily
[22:34] <toan_> there's no installer for 32bit vivid
[22:34] <cjwatson> toan_: you've marked your package as architecture-independent
[22:35] <toan_> yeah
[22:35] <cjwatson> Architecture: all
[22:35] <cjwatson> that means it's only built on one architecture, and that build is published for use on all architectures
[22:35] <toan_> its all right now
[22:35] <toan_> it is set to all right now
[22:36] <cjwatson> if you want it to be built separately on each architecture - which you should, because this contains compiled code - then that should be "Architecture: any"
[22:36] <toan_> hmm, thanks, let me try that,,
[22:36] <cjwatson> "Architecture: all" is for things like packages consisting solely of interpreted code or data or whatever
[22:36] <cjwatson> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[22:37] <toan_> cjwatson, gotcha!
[22:39] <teward> cjwatson: so, "all" for things like a set of python scripts that aren't arch-specific (like, utility scripts or such), or Bash scripts or such, then is "all"?
[22:39] <toan_> cjwatson, i feel like launchpad should store/integrate packaging to the website interface, that we we dont have to merge packaging info to the dev branch
[22:39]  * teward wants to make sure that his understanding matches the definitions :)
[22:39] <teward> s/definitions/real meaning of each/
[22:39] <cjwatson> teward: yes
[22:39] <toan_> we=way
[22:39] <cjwatson> toan_: perhaps, but that's a huge project
[22:39] <cjwatson> realistically not likely to happen
[22:40] <toan_> it would be alot easier, i think, we can just create a package, purely from the website interface, everything stored in there too, no need to merge
[22:40] <cjwatson> like I say: perhaps, but that's a huge project, and not likely to happen
[22:41] <cjwatson> any interesting package needs to be maintained over time as well
[22:43] <toan_> cjwatson, can you help me, what's this error: https://launchpadlibrarian.net/234548913/upload_1058815_log.txt
[22:43] <teward> toan_: you can't upload an identical-versioned tarball with different contents
[22:43] <cjwatson> that means that your recipe doesn't include the revision of the packaging branch in its version number
[22:43] <teward> ^
[22:46] <cjwatson> the first line should probably be something like: # bzr-builder version 0.4 deb-version {debupstream-base}+bzr{revno}-0+{revno:packaging}
[22:46] <toan_> thanks
[22:46] <cjwatson> adjust to taste
[22:46] <cjwatson> and see https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[22:46] <cjwatson> (esp near the end)
[22:47] <cjwatson> anyway, got to deal with kids' bathtime now
[22:47] <dobey> i usually use {debupstream}+r{revno}.{revno:packaging}
[22:48] <toan_> cjwatson, thanks alot, i have have i386-32bit for vivid :-)
[22:48] <toan_> have=now
[22:49] <dobey> btw, vivid will be EOL in 2 weeks
[22:52] <toan_> cjwatson, the project at https://code.launchpad.net/~tpham3783/hello-github/trunk does not have any affilication with the "Hello, Github" project, how do i remove that?
[22:53] <toan_> in other words, it is just a personal test branch, somehow launchpad thinks its affilicated with the "hello-github" project
[22:58] <dobey> is it not that project's code?
[23:05] <toan_> no
[23:05] <toan_> it is not, i created a dummy project, but someone, i am not sure launchpad linked with hello-github
[23:06] <wgrant> toan_: The hello-github project already existed, and you pushed your branch into it.
[23:06] <wgrant> You didn't create a new project.
[23:06] <dobey> right
[23:07] <toan_> no, i created a personal project under, ~tpham3783/hello-github, then push some files from my dev machine onto the server
[23:08] <toan_> sorry, i did not push, i imported from github
[23:08] <dobey> no, that isn't a project
[23:08] <dobey> that is a branch
[23:08] <toan_> branch?
[23:09] <toan_> i have two branches, ~tpham3783/hello-github/trunk and .../master
[23:09] <dobey> yes, https://launchpad.net/hello-github is a project
[23:09] <dobey> someone else created and owns that project
[23:09] <dobey> you created an import of unrelated code into a branch under that project namespace
[23:10] <toan_> this is a bit confusing, so I can not have my own project with arbitrary names?
[23:10] <dobey> you can't have your own project with an arbitrary name, when someone else already has a project with that name
[23:11] <dobey> but otherwise, yes you can create any project with an arbitrary name which doesn't already exist
[23:11] <wgrant> The key thing is that projects are namespaced globally.
[23:11] <wgrant> My "hello-github" project and your "hello-github" project are the same project.
[23:11] <dobey> but a project is not a branch; though a project may have branches
[23:11] <wgrant> So anyone can have branches within the main project.
[23:11] <wgrant> So they're listed together, rather than spread across the site.
[23:12] <toan_> wgrant, gotcha, so if i just want to update load sources of unrelated project, i must make it unique, i think it will only be visible to me, (under my username space)
[23:13] <toan_> update=upload
[23:13] <xnox> toan_, all code in launchpad is public =)
[23:13] <xnox> and open source, that's terms of service for personal accounts.
[23:14] <xnox> toan_, so yes everything in https://code.launchpad.net/~tpham3783  is yours. And for any project in launchpad, you can make lp:~tpham3783/$project/$name_of_your_fork_or_branch
[23:14] <toan_> wgrant, so how do i unlink my "hello-github" with the "hello-github" main project?
[23:15] <xnox> toan_, however, they can be viewed both under https://code.launchpad.net/~tpham3783 (along with other code by you) and https://code.launchpad.net/$project (along with branches by other people, but for this project)
[23:15] <xnox> toan_, in bzr there are lp:~/+junk/$branch branches, that is under "project" +junk aka un-affiliated to anything.
[23:16] <xnox> toan_, but then it's not related to any projects, and one cannot do branch merge proposals, etc.
[23:16] <wgrant> toan_: You need to pick a different name for the project, register it at https://launchpad.net/projects/+new, then transfer the branches over using their "Change details" link.
[23:17] <toan_> xnox, that clears up a bit, I should have used +junk since I did not want it be affliate with any other projects
[23:17] <wgrant> Or, as xnox suggests, you can make them not related to any project ("+junk") by selecting Personal on "Change details".
[23:18] <toan_> wgrant, thank you, this whole launchpad dev. is really new to me, i have always been a git user, and did not care about launchpad until I realize I needed it for auto. distribution
[23:22] <wgrant> toan_: The main problem that people have is that LP has overarching global projects, and multiple people can own code within them. GitHub's closest analogue is the "network" of repos that were forked from each other, but it's much less explicit.
[23:25] <toan_> wgrant, thanks, that's a good description.... a general sense, instead of having a button for me a fork a project; i just create one and mark it's affilication to the parent (main) project
[23:26] <toan_> and that's merge requests are implimented, from the affiliation network
[23:26] <wgrant> toan_: You create a Bazaar branch or Git repo within the existing project.
[23:27] <wgrant> GitHub's top-level object is the Git repository, because they primarily focus on Git repositories.
[23:27] <wgrant> But LP does all sorts of things, so the top level object is the project, which can contain numerous Git repositories.
[23:28] <toan_> wgrant, can i have namespace in my personal (+junk) project?
[23:28] <toan_> so i can have something like, ~tpham3783/+junk/project1/test_branch1
[23:28] <cjwatson> Afraid not.
[23:28] <cjwatson> It will be easier once Git recipes exist, though.
[23:28] <toan_> likewise, +junk/project2/test_branch2
[23:29] <cjwatson> Because then you'll have the branch namespace within every repository, and can use it to build recipes.
[23:29] <toan_> cjwatson, git recipes???? can you give me a link to read about it
[23:30] <toan_> when will that happen?
[23:30] <cjwatson> If a branch is actually associated with an LP project, it should be in ~tpham3783/that-project-name/blah, not +junk
[23:30] <cjwatson> toan_: I can't give you a link because I'm still finishing it :-)
[23:30] <cjwatson> toan_: Probably only a week or two out at this point
[23:30] <toan_> it will be available on the site for everyone right?
[23:31] <cjwatson> Yes
[23:32] <wgrant> However, creating a project is easy.
[23:32] <wgrant> If you want to do anything non-trivial then you quite possibly just want to create a project.
[23:35] <toan_> bzr does not have a concept of a project, correct?  b/c in git when you clone, you clone the project
[23:35] <toan_> with bzr, you use bzr branch to clone a branch
[23:35] <wgrant> Neither VCS has the concept of a project.
[23:35] <toan_> that's weird
[23:36] <wgrant> In bzr branch clone a branch, in git you clone a repository.
[23:36] <toan_> wgrant, that's correct,,,,, i think git is still better
[23:36] <wgrant> It's actually Git's model that's weird, but if Git's the first VCS you've used then you might disagree.
[23:37] <toan_> i used svn before, but git is way better
[23:37] <toan_> now, bzr is a bit different
[23:38] <toan_> how would you do this with bzr, git checkout -b "bugtest" # create a new branch from the master branch, which can be merged back later
[23:39] <toan_> since it does not have a concept of multiple branches from the same repo... i dont understand how it would work
[23:40] <wgrant> toan_: I have a directory like ~/src/project/trunk. If I want to create a new branch, from ~/src/project I just "bzr branch trunk some-feature".
[23:40] <wgrant> Bazaar by default has one directory per branch.
[23:40] <wgrant> But it also supports having multiple branches in one directory, if you want to work that way.
[23:40] <wgrant> Both models are supported.
[23:42] <toan_> wgrant, once the git-recipe does out, does that mean that LP will also support git, along with bzr?
[23:42] <toan_> does=goes
[23:43] <wgrant> toan_: LP already supports Git repositories and several common features on top of them. Recipes are the next feature that will support Git.
[23:44] <teward> wgrant: no LP GUI interface for git yet?
[23:44] <teward> or at least, not easily accessible?
[23:44] <toan_> wgrant, I mean use git to push and create repo on LP
[23:44] <teward> LP already supports Git repositories and several common features on top of them
[23:44] <wgrant> toan_: That works fine today.
[23:44] <wgrant> teward: Which bit of UI are you missing?
[23:44] <toan_> really?  b/c all i know is the git import feature,
[23:45] <teward> wgrant: basically, finding a list of Git repos attributed to a given user
[23:45] <toan_> wgrant, so i can just add a git remote and push directly to LP?  can you give me a writeup reference please, cuz i haven't seen anything like that
[23:45] <teward> also haven't checked recently, hence the question if a GUI interface has been made available
[23:45] <teward> (having my own GitLab means I can just drop crap there heh)
[23:46] <teward> (hence not keeping too close an eye on Git support on LP)
[23:49] <wgrant> teward: https://launchpad.net/~wgrant/+git
[23:49] <wgrant> https://code.launchpad.net/turnip
[23:49] <wgrant> etc
[23:49] <wgrant> toan_: https://help.launchpad.net/Code/Git
[23:49] <teward> ah, nice, +git was what i was seeking, cool.
[23:50] <wgrant> teward: There's an obscure link on https://code.launchpad.net/~wgrant
[23:50] <wgrant> For projects it's easy, since we just show whichever VCS the project has set as its primary VCS.
[23:50] <wgrant> But for people we don't have that luxury.
[23:54] <teward> ahhh, there's the obscure link
[23:57] <teward> wgrant: thanks, that's actually what I was looking for heh
[23:57] <teward> i'll have to make some scripts to help me create gitrepos on lp going forward; so used to my GitLab instance, i'll need maintainer scripts for anything else xD
[23:57] <teward> s/maintainer/utility/