[00:00] <wgrant> sergio-br2: I think the bug may be that we don't handle implicit revspecs when determining staleness.
[00:00] <wgrant> If you adjust the recipe to explicitly specify "master" it might work.
[00:00] <wgrant> cjwatson: Does that sound plausible?
[00:03] <sergio-br2> yeah, you are right wgrant
[06:58] <karstensrage> well i got further
[06:59] <karstensrage> is there documentation about what my changes file *should* contain for launchpad?
[06:59] <wgrant> karstensrage: dpkg-buildpackage -S or debuild -S will do the right thing.
[06:59] <karstensrage> Rejected:
[06:59] <karstensrage> Unable to find distroseries: unstable
[06:59] <wgrant> Ah, your debian/changelog is wrong.
[06:59] <wgrant> "unstable" is a Debian series.
[06:59] <karstensrage> yeah
[07:00] <wgrant> You want something like "trusty" or "xenial", for the target Ubuntu series.
[07:00] <karstensrage> ok
[07:00] <karstensrage> whats the difference between trusty or xenial?
[07:00] <karstensrage> is that 14.04 vs 16.04?
[07:03] <karstensrage> or could i set it to precise
[07:03] <karstensrage> i want it to work on any version?
[07:03] <wgrant> karstensrage: Any supported Ubuntu release.
[07:04] <wgrant> And yes, trusty is 14.04, xenial is 16.04, precise 12.02
[07:04] <wgrant> er, 12.04
[07:04] <karstensrage> so should i try again with precise?
[07:05] <wgrant> If you want to build for 12.04, yep.
[07:06] <karstensrage> whats the plan after Zippy Zebra?
[07:06] <karstensrage> out of curiosity
[07:06] <wgrant> That's Mark's problem :)
[07:07] <wgrant> But something we've all been wondering for the last decade or so.
[07:08] <karstensrage> accepted!!!!
[07:08] <karstensrage> wooot
[07:09] <karstensrage> thanks wgrant youre awesome
[07:10] <wgrant> Nice, hopefully it'll build!
[07:12] <karstensrage> it didnt
[07:12] <wgrant> :(
[07:12] <wgrant> Did you test build it locally in pbuilder or sbuild?
[07:13] <karstensrage> i dont know what those are ive just been using bzr debbuild
[07:13] <karstensrage> when i dont use -S it builds things
[07:14] <karstensrage> and seems to work
[07:14] <wgrant> pbuilder and sbuild use clean chroots, so you can ensure you have all the dependencies right.
[07:14] <wgrant> Your host system has all sorts of packages installed, which your package might require to build.
[07:15] <wgrant> Launchpad builders only install the packages that are in your package's Build-Depends field.
[07:15] <wgrant> If you're not using a clean chroot, you might not have everything you need listed there.
[07:15] <karstensrage> hmm
[07:15] <karstensrage> well i thought i had my dependencies set correctly
[07:15] <karstensrage> but the error seems to indicate there is no source
[07:15] <karstensrage>  * Source: not available
[07:15] <wgrant> Ah, that's unrelated.
[07:16] <wgrant> Check the build log link.
[07:20] <karstensrage> hmm
[07:20] <karstensrage> i cant tell what the error might me
[07:20] <karstensrage> be
[07:21] <karstensrage> ./configure: line 12134: syntax error near unexpected token `0.25'
[07:21] <karstensrage> ./configure: line 12134: `PKG_PROG_PKG_CONFIG(0.25)'
[07:22] <wgrant> Sounds like a missing build-dep.
[07:22] <wgrant> Try in pbuilder or sbuild locally, so you can immediate feedback rather than waiting for LP to build it.
[07:22] <karstensrage> like maybe there is build-depends on pkg_config
[07:22] <karstensrage> ?
[07:22] <karstensrage> for example?
[07:23] <karstensrage> for chroots there seems to be a lot of setup required is that true to run pbuilder or sbuild?
[07:24] <wgrant> pbuilder and sbuild automate most of the setup.
[07:24] <karstensrage> which one should i use?
[07:24] <wgrant> Try "mk-sbuild" from ubuntu-dev-tools.
[07:26] <karstensrage> installing
[07:48] <karstensrage> do you do mk-sbuild then sbuild
[07:49] <karstensrage> it seems to be downloading a lot in both cases
[07:50] <wgrant> mk-sbuild will download and build a chroot, sbuild will download build dependencies.
[07:55] <karstensrage> i see
[07:55] <karstensrage> it wants a key
[07:56] <ricotz> wgrant, hi :), are you still around for https://answers.launchpad.net/launchpad/+question/284310
[07:59] <wgrant> ricotz: Done.
[07:59] <ricotz> wgrant, thank you!
[08:17] <karstensrage> do things like libxml2-dev and libssl-dev go on the Build-Depends: line
[08:18] <karstensrage> as opposed to build things like debhelper (>= 9), dh-autoreconf, pkg-config
[08:18] <wgrant> karstensrage: They all go there.
[08:19] <karstensrage> ok
[08:20] <karstensrage> youve been a very unexpected and appreciated help wgrant ... the guys in debian-mentor are not very cognizant of the fact that someone new to this doesnt know what he doesnt know, and that the documentation, while enormous, is not very consumable nor applicable to a new person ime
[08:21] <wgrant> karstensrage: np, always happy to help
[08:21] <karstensrage> Log for successful build of identity4c_1.0-1 on i386 (dist=precise)
[08:22] <karstensrage> that was with sbuild
[08:23] <wgrant> Nice.
[08:23] <wgrant> So you should be good to upload, then.
[08:25] <karstensrage> so for uploading ive just been removing identity4c_1.0-1_source.ppa.upload and then dput'ing
[08:25] <karstensrage> is that the proper way to update?
[08:26] <wgrant> Launchpad won't accept the same version a second time.
[08:26] <wgrant> You'll need to change it, since the first version was accepted but failed to build.
[08:26] <karstensrage> and whats the way to change the version?
[08:27] <karstensrage> the first entry in the change log was auto-generated
[08:27] <karstensrage> i dont actually recall what did that
[08:27] <karstensrage> changelog
[08:27] <karstensrage> that seems to be the only place the version is
[08:28] <wgrant> You'd normally use "dch" to edit the changelog.
[08:28] <wgrant> dch -i creates a new entry.
[08:29] <karstensrage> thats creates one with 1ubuntu1
[08:29] <karstensrage> is that typical?
[08:29] <karstensrage> i might have changed that to look like just '1'
[08:31] <wgrant> karstensrage: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning
[08:41] <karstensrage> fingers crossed
[08:47]  * karstensrage drums his fingers nervously
[09:10] <karstensrage> hmm it doesnt seem to have built it
[09:13] <karstensrage> or maybe it did but didnt send an email
[09:58] <kickinz1> o/
[09:59] <kickinz1> Is it possible to add s390x support to ppa:canonical-server/devirt?
[11:54] <cjwatson> wgrant: Yup, definitely.  I think the most coherent approach would be to have GitRepository._getRecipes check for each path whether it matches default_branch and include None in the revspecs sequence if so.  Might require slightly careful handling in SPRD.findRecipes though because SQL.
[11:56] <cjwatson> kickinz1-sprint: done
[12:57] <kickinz1-sprint> cjwatson, thanks
[14:30] <nacc> launchpadlib question: anyone have a quick example of looking up the git repositories owned by a particular user? is that possible with lplib?
[14:37] <cjwatson> nacc: lp.git_repositories.getRepositories(target=lp.people['foo'])
[14:53] <nacc> cjwatson: hrm, so do I need to point at staging for that? production seems tosay that Collection has no attribute getRepositories; and git_repositories is empty, I think
[14:55] <cjwatson> nacc: What's the exact error message?
[14:55] <cjwatson> nacc: Yes, git_repositories appears empty when treated as a collection, but that's because iterating over all repositories on LP using the webservice isn't something we consider sensible.  It's not relevant to this.
[14:57] <nacc> cjwatson: AttributeError: <lazr.restfulclient.resource.Collection object at 0x7f22a9a55a10> object has no attribute 'getRepositories'
[14:59] <cjwatson> nacc: Your wadl might be out of date.  find ~/.launchpadlib/ -name \*wadl\* -delete
[14:59] <cjwatson> (wadl -> machine-readable description of API used by launchpadlib)
[15:01] <nacc> cjwatson: no change
[15:01] <nacc> cjwatson: I did notice that 1.0 doesn't hve a getRepositories method: https://launchpad.net/+apidoc/1.0.html#git_repositories, but devel does https://launchpad.net/+apidoc/devel.html#git_repositories
[15:05] <cjwatson> nacc: Oh, yeah, you have to use devel.
[15:05] <cjwatson> 1.0 is boring.
[15:06] <nacc> cjwatson: is that the distinction between production and staging?
[15:06] <cjwatson> nacc: No.
[15:06] <nacc> cjwatson: ok, how do I specify a different API to use? I'm asking for 'production' in login_with
[15:06] <cjwatson> nacc: There was an attempt to do versioning of the API to make it easier to evolve the API without breaking old scripts, and 1.0 was an attempt to freeze the API.  But the versioning scheme never worked very well; most scripts should probably just use devel.
[15:06] <cjwatson> nacc: version="devel"
[15:07] <cjwatson> as a keyword argument to login_with
[15:07] <nacc> cjwatson: great, that works!
[15:08] <nacc> cjwatson: any way I can submit a patch for the online documentation? that's not mentioned in any obvious places
[15:13] <cjwatson> nacc: I've edited https://help.launchpad.net/API/launchpadlib to make this clearer
[15:45] <nacc> cjwatson: thanks!
[15:45] <nacc> cjwatson: and sorry for the noise :)
[16:04] <karstensrage> im very confused about how packing works with multiple versions
[16:04] <karstensrage> it seems like everything is controlled by the changelog file
[16:04] <karstensrage> and you specify a distribution in there
[16:04] <karstensrage> so if you build your target on a very old version, so precise is specified
[16:05] <karstensrage> how does that work for trusty and xenial
[16:06] <karstensrage> if  you make lots and lots of packages with the version like myapp_1.0-1ubuntu3ppa1~intrepid1 changing the control file each time, doesnt only the last one apply?
[16:07] <karstensrage> and my other question is how do i test with sbuild, if there is a dependency in another ppa?
[16:21] <cjwatson> karstensrage: You can either build for the oldest and use LP's "copy packages" operation to copy source and binaries forward to later series, assuming they'll still work there; or you maintain mini-branches of the changelog file for each series (easier with git)
[16:21] <cjwatson> karstensrage: or use recipes to automatically build the source packages from a branch
[16:23] <cjwatson> karstensrage: With older versions of sbuild it was necessary to modify the chroot's sources.list; with sbuild >= 0.65.0 you can use the --extra-repository option
[16:23] <cjwatson> (and probably the --extra-repository-key option too, added in 0.66.0)
[16:24] <karstensrage> i have git, this doesnt mention the branching https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage?
[16:25] <teward> cjwatson: do recipes using git work yet?
[16:26] <cjwatson> karstensrage: well, you don't *have* to branch, you just might not want the noise from every series you've separately built a given package for
[16:26] <cjwatson> teward: http://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes
[16:27] <teward> cjwatson: thanks
[16:32] <dobey> git->git import + recipes will be nice when it's doable
[16:32] <teward> indeed
[18:35] <om26er> wgrant, Hi!
[18:48] <clivejo> can a project have an associated PPA?
[19:02] <cjwatson> clivejo: no
[19:03] <clivejo> cjwatson: :(
[19:03] <clivejo> thats that idea out the window
[19:05] <clivejo> how do I remove a project?
[19:06] <dobey> clivejo: only people and teams have PPAs. you can make a team for the project, and that team can have a PPA
[19:18] <clivejo> oh maybe thats what I need
[19:18] <clivejo> I want to set up a resource to package kolab on Ubuntu
[19:26] <clivejo> why does it say the team is already registered?
[19:26] <clivejo> https://launchpad.net/~kolab
[19:28] <dobey> because someone registered that username at some point
[19:31] <dobey> hmm, was never activated though it seems; and maybe was automatically registered due to a package upload
[19:32] <dobey> wgrant, cjwatson: if either of you are around, is it ok to rename such accounts with conflicting usernames that have never been activated? ^^
[19:32] <cjwatson> yes, that sohuld be fine
[19:34] <dobey> clivejo: you should be able to register kolab as a team name now
[19:35] <clivejo> dobey: thanks :)
[19:36] <cjwatson> clivejo: LP staff can get rid of old projects for you; ask a question on https://answers.launchpad.net/launchpad
[19:36] <clivejo> cjwatson: its ok now, dobey has explained how it works
[19:37] <clivejo> not sure how all this works
[19:38] <cjwatson> clivejo: right, that has dealt with you creating a team to have a PPA, but not with cleaning up the project you already created
[19:40] <clivejo> well the project would be useful to store the packaging in the git archive
[19:40] <dobey> well, you might want to keep the project to have a mirror of the source on launchpad, for setting up daily build recipes or such
[19:40] <clivejo> or can teams have a git too?
[19:40] <dobey> and yes, to store packaging
[19:40] <dobey> clivejo: projects don't have git. people or teams do. but you can associate a specific branch owned by a person or team, to be the development focus of a project, for example
[19:42] <cjwatson> projects totally have git repositories, that's a very misleading way to describe it!
[19:42] <cjwatson> git repositories do need to be owned by a person/team as well, yes
[19:43] <clivejo> the calligra project seems to have a git repo for packaging, I was planning on doing the same - https://code.launchpad.net/calligra
[19:43] <clivejo> but maybe thats not the right/correct way to do it?
[19:44] <cjwatson> that's in fact bzr, but you can certainly do git that way too
[19:44] <dobey> well, repositories/branches can be associated with a project. projects don't own things. i was trying to state it in a way that makes that clear is all :)
[19:45] <cjwatson> as the person who implemented most of this I don't think that makes it clear :-)  how about: projects don't own git repositories, but they do have them
[19:45] <clivejo> do I have to create a ppa for the team?
[19:45] <cjwatson> you don't have to, but that seems to be your goal
[19:46] <clivejo> yes, I have a package Im trying to upload
[19:46] <cjwatson> if you want it to exist then you do need to create it, yes
[19:46] <dobey> you can create your own ppa, or create a ppa under a team which you administer
[19:47] <dobey> you can upload packages to either your own ppa, or a ppa that is owned by a team you are a member of
[19:47] <clivejo> how do I upload to the kolab team?
[19:48] <dobey> did you create a PPA for that team yet?
[19:48] <cjwatson> https://help.launchpad.net/Packaging/PPA/Uploading   but replace "your-lp-id" in those instructions with the team name
[19:48]  * clivejo shake head
[19:48] <cjwatson> and possibly "ppa" with the name of the PPA, if you didn't use the default name
[19:49] <cjwatson> e.g. to upload to the "buildd-staging" PPA owned by the "launchpad" team, I would use dput ppa:launchpad/buildd-staging
[19:53] <clivejo> ah, found the add PPA
[23:26] <tpham3783> cjwatson, is there a good way to package a debian package without using dpkg-buildpackage, dh_*; like doing it manually, like at the install stage install to the root directory of the build host and also another copy to /debian for packaging?
[23:27] <tpham3783> in short, i just want to be able to build a package, install it, and then install another copy to DESTDIR for packaging to a .deb package
[23:28] <wgrant> tpham3783: You pretty much have to use dpkg-buildpackage.
[23:28] <wgrant> Can you explain what you're trying to achieve?
[23:29] <tpham3783> wgrant, lets say i just downloaded a sourcecode project, i just want to be able to compile it with automake
[23:30] <tpham3783> then at the install stage, I want to install to my build host
[23:30] <tpham3783> but also another copy to another folder for packaging the it to a deb package, by using dpkg-deb -b debian mypackage.deb
[23:31] <tpham3783> dpkg-deb is pretty much the minimal tool to finally create a .deb package, see what i mean?
[23:32] <dobey> well, why do you care about making a .deb if you're installing directly to / anyway? if you care about having things in the dpkg database, then make a deb and install it, instead of installing to / from source
[23:32] <dobey> and i'm not sure what any of that has to do with launchpad :)
[23:36] <tpham3783> dobey, I come here to talk to cjwatson b/c he is familiar with deb packaging the most; I want to create a .deb even when I did an install already b/c I would like to be able to install the software on diff. machine.
[23:39] <dobey> tpham3783: right. the correct answer is "make a deb first, and then install it on both machines"
[23:39] <tpham3783> dobey, the reason i did not want to create a .deb then install it b/c the software I am trying to package is complicated, i will have to build first stage (staging the build machine), then build...
[23:40] <tpham3783> it has all sorts of dependencies with the host and sysroot env.
[23:41] <dobey> what is "it" ?
[23:41] <tpham3783> it=the software package, in this case, e20
[23:42] <tpham3783> a window manager, uses so many other sub resources/libraries
[23:42] <dobey> yes i know what enlightenment is
[23:42] <dobey> it can't be any more difficult to package than the version already packaged in debian/ubuntu
[23:43] <tpham3783> the version shipped with ubuntu is e17/or 18
[23:43] <tpham3783> very old
[23:43] <tpham3783> i want to be able to test daily build of e20, and on many machines
[23:44] <dobey> then set up recipes that build daily?
[23:44] <tpham3783> dobey, i was hoping to setup the recipe once launchpad has fully implimented git recipe
[23:46] <dobey> so you will need to create the packaging to build it from source anyway. you can't install anything to / on launchpad builders
[23:47] <tpham3783> dobey, the original question wasn't for launchpad build, i was going to do it all manually
[23:47] <tpham3783> ***on my dev machine
[23:49] <dobey> so make the packaging and run debuild on your dev machine. you don't want to manually construct binary .debs. it far more work than just making the packaging and building the packages in the first place
[23:50] <tpham3783> dobey, understand, but would like to construct it manually and automake it make,,,,
[23:50] <tpham3783> i am just curious as to how it should be done properly
[23:51] <dobey> properly == use debuild/dpkg-buildpackage
[23:51] <dobey> improperly == you get a tarball that you call a .deb and dpkg won't install anyway
[23:51] <tpham3783> dobey, on top of that, i one day want to be able to build outside of deb distro, and the only tool i have is dpkg-deb
[23:52] <dobey> if you want to build for other distros, then you'll have to use tools for their packaging systems, and build against their libraries, etc…
[23:53] <tpham3783> dobey, understand, so far dpkg-deb is the minimal tool, and its working great, can build and package a deb package from almost on any distro
[23:55] <tpham3783> in a way, i just want to tailor the build process of the e20 project to something like this: make ubuntu_package # for ubuntu, make fedora_package etc....
[23:55] <tpham3783> so pretty much, the packaging process is automated, in the source code/tree of the project
[23:56] <dobey> you have to build ubuntu packages on ubuntu, fedora packages on fedora, etc…
[23:56] <tpham3783> dobey, off course, but you understand the point though?
[23:56] <dobey> keeping the packaging info for all distros in one tree isn't going to work
[23:57] <tpham3783> not ALL, maybe 2
[23:57] <tpham3783> should be acheivable
[23:57] <tpham3783> u know, that's how wireshark does it, packaging is keep in the sourcetree
[23:57] <tpham3783> keep=kept
[23:58] <dobey> it will be a pain to maintain, and it makes it difficult for downstreams when they have to ship patches to the release to fix bugs
[23:59] <tpham3783> dobey, go to go, i will talk to cjwatson on this topic one day... thanks
[23:59] <dobey> i don't know what wireshark does upstream these days. i do know what 20 years of experience dealing with multiple distributions, hundreds of projects, and even writing a packaging system, tells me, though
[23:59] <dobey> well, you may not often find him here at such an hour