[04:03] <toan_> hi, i have a wireshark personal project (+junk) that was built successfully; how do I make sure when the user install "wireshark", it is pulled from my PPA, instead of the version from Ubuntu?
[04:27] <toan_> i am trying to push a bzr but I am getting this error:  bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~tpham3783/%2Bjunk/recipe/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[04:28] <toan_> cjwatson, !
[05:08] <wgrant> toan_: You can't push over HTTP.
[05:08] <wgrant> Have you run 'bzr lp-login' to set your SSH username?
[06:07] <toan_> wgrant, thanks,
[06:08] <toan_> wgrant, how do i make dpkg_buildpackage to call ./autgen.sh before it starts the build process
[06:08] <toan_> internet sources say, add overrid_dh_auto_configure, but it does not work
[06:10] <toan_> or, is there a hook for the build server to run autogen.sh before it runs the main build script, dpkg-buildpackage
[06:11] <wgrant> toan_: You customise the behaviour of dpkg-buildpackage by editing debian/rules.
[06:12] <toan_> wgrant, correct,
[06:12] <toan_> but how do I customize running autogen first
[06:12] <wgrant> You might want to use something like dh-autoreconf.
[06:12] <wgrant> That's generally preferable to running autogen.sh directly.
[06:14] <toan_> nope, that does not work
[06:14] <wgrant> What does it not do?
[06:14] <toan_> my auto build failed here b/c it did not run autogen:  https://launchpadlibrarian.net/234583210/buildlog_ubuntu-wily-i386.edkit_3.2+113+11~ubuntu15.10.1_BUILDING.txt.gz
[06:14] <wgrant> It's better to test this stuff locally, so you can have a quick feedback loop.
[06:15] <wgrant> No need to wait for Launchpad to build it before you can fix the next issue.
[06:15] <toan_> edkit package requires that the user runs autogen.sh right after checkout
[06:15] <toan_> wgrant, i am testing locally too,
[06:15] <wgrant> I don't see dh-autoreconf there.
[06:15] <toan_> but dont know of a hook to run autogen
[06:15] <toan_> there's dh_auto_configure
[06:16] <wgrant> Have you tried dh-autoreconf?
[06:17] <toan_> no such command
[06:17] <wgrant> The latest version that you've uploaded also doesn't even try override_dh_auto_configure.
[06:17] <wgrant> dh-autoreconf is a package containing a debhelper extension that runs autoreconf.
[06:17] <wgrant> Install it and check its manpage.
[06:20] <toan_> wgrant, no go,
[06:20] <toan_> it is not a utility,
[06:20] <toan_> i installed it and ran dpkg-buildpackage again, and got same error
[06:20] <wgrant> Simply installing it does not activate it.
[06:20] <wgrant> Check its manpage.
[06:20] <wgrant> That shows how to use it.
[06:21] <toan_> ic
[06:21] <toan_> now!
[06:26] <toan_> hmmm, did everything in the manual and still not working
[06:26] <wgrant> "not working"
[06:26] <toan_> nope
[06:29] <toan_> i figured out the trick from the log file, i decided to add a tag override_dh_distclean to run autogen.sh, and it worked
[06:30] <toan_> i wish that there's a  hook like post_configure, it would me things easier
[06:30] <wgrant> autogen.sh basically just runs "autoreconf --install", so you can probably just use the --install incantation from dh-autoreconf's manpage.
[06:31] <wgrant> Were you to do it manually you could say:
[06:31] <wgrant> override_dh_auto_configure:
[06:31] <wgrant>         ./autogen.sh
[06:32] <wgrant>         dh_auto_configure
[06:32] <toan_> that did not work
[06:32] <wgrant> ish
[06:32] <toan_> tried it already
[06:32] <wgrant> "did not work"
[06:32] <wgrant> It's difficult to help without details.
[06:32] <toan_> dpkg would run all the clean script first
[06:32] <toan_> i mean, distclean make target first
[06:34] <wgrant> toan_: clean is run before build
[06:34] <wgrant> So make distclean would be run well before override_dh_auto_configure.
[06:34] <wgrant> So I don't see the problem.
[06:35] <toan_> maybe its the way the package edkit is packaged, it forces the user to run autogen.sh first
[06:37] <wgrant> That's fine.
[06:38] <wgrant> dh-autoreconf is designed for that situation.
[06:39] <toan_> thanks
[06:46] <toan_> wgrant, do you think one day LP will allow direct import (merge) from an external git repo, instead of a bzr project on LP
[06:47] <toan_> in other words, i just want to specify github branches directly in the build recipe
[06:48] <wgrant> toan_: Mirroring external Git repositories is quite high on the list, but it's unlikely that we'll support directly using external repositories any time soon.
[06:48] <wgrant> In part because we can't easily automatically trigger builds based on repositories that we're not watching closely.
[06:48] <wgrant> Whereas if they're mirrored then we can.
[06:50] <toan_> understand, but then we dont need LP to watch those branches, LP will only build on a manual build trigger, not source tree change
[06:52] <toan_> ** the fact that i have to use bzr to do all of this, bothers me!!!!
[06:53] <toan_> i can easily stick with git and use the website front end to write the recipe
[07:06] <wgrant> Yes, we're working on deploying Git recipes at the moment.
[10:08] <mapreri> I'm looking at lp #1528605 and wondering why the bug watcher to the debian bug tracker.  I added it 4 days ago, and 4 days seems an excessive amount of time to just query a bug tracker..
[11:34] <mapreri> cjwatson: wgrant ↑
[16:16] <toan_> what do i do to support build for arm:  https://code.launchpad.net/~tpham3783/+recipe/edkit-daily
[16:25] <toan_> can someone tell me why this build broke:  https://launchpadlibrarian.net/234590190/buildlog.txt.gz
[16:30] <cjwatson> You can request ARM builds for a PPA at https://answers.launchpad.net/launchpad
[16:32]  * cjwatson squints at that log
[16:32] <cjwatson> Running autogen.sh in clean is weird
[16:33] <cjwatson> Anyway, your version is wrong again
[16:33] <cjwatson> You need to have the packaging revno come after a "-", otherwise you end up with conflicting generated .orig.tar.gz versions
[16:34] <cjwatson> You have {debupstream}+{revno}+{revno:packaging} right now - try {debupstream}+{revno}-0+{revno:packaging} instead
[16:34] <cjwatson> May need an upstream commit before that'll work, since it needs to be greater than the previous version
[16:49] <toan_> cjwatson, so the vivid build failed b/c of that? versioning convention?
[16:49] <cjwatson> The build didn't fail, but LP refused the upload
[16:50] <cjwatson> https://launchpadlibrarian.net/234590197/upload_1059156_log.txt is reasonably clear about it I think
[16:50] <cjwatson> And it's not just convention - if you get this wrong then the result is that LP would have to try to publish two different versions of the same file with the same name
[16:51] <cjwatson> That's disallowed
[16:54] <toan_> cjwatson, is there a way to tell dh to run a custom build command?
[16:54] <toan_> and then forget everything elses?
[16:55] <cjwatson> override_dh_auto_build is usually the target you want for that
[16:55] <toan_> thanks,
[16:56] <toan_> cjwatson, i changed the version info in the recipe and it still failed
[16:57] <cjwatson> see for instance https://anonscm.debian.org/cgit/users/cjwatson/cccc.git/tree/debian/rules (OK, there's a fair bit of variable setup there, but the actual target is simple
[16:57] <cjwatson> )
[16:57] <toan_> ref: latest vivid build https://code.launchpad.net/~tpham3783/+recipe/edkit-daily
[16:57] <cjwatson> toan_: 16:34 <cjwatson> May need an upstream commit before that'll work, since it needs to be greater than the previous version
[16:57] <mapreri> [10:08:52 AM] <mapreri> I'm looking at lp #1528605 and wondering why the bug watcher to the debian bug tracker.  I added it 4 days ago, and 4 days seems an excessive amount of time to just query a bug tracker..
[16:58] <cjwatson> toan_: or you could use {debupstream}+bzr{revno}-0+{revno:packaging} (inserting the "bzr" there) which will be greater
[17:01] <cjwatson> mapreri: 2016-01-18.log:2016-01-18 00:27:44 INFO    Didn't find bug u'810530' on http://bugs.debian.org (local bugs: 1528605).
[17:01] <cjwatson> not sure why as yet ...
[17:03] <toan_> omg, the tag worked, it finished the upload already
[17:04] <cjwatson> mapreri: investigating via sysadmin
[17:04] <toan_> cjwatson, i have no idea why the new tag worked, but thanks
[17:04] <mapreri> cjwatson: thank you.
[17:05] <cjwatson> toan_: because 3.2+bzr113-0+20~ubuntu15.04.1 is greater than the previous version 3.2+113+20~ubuntu15.04.1, but 3.2+113-0+20~ubuntu15.04.1 is not
[17:06] <cjwatson> toan_: you can use e.g. the exit status of dpkg --compare-versions, or apt_pkg.version_compare() in Python, to check this
[17:09] <toan_> cjwatson, built successfully for vivid, will try arm now
[17:09] <cjwatson> Note that our ARM builds are currently via qemu-user-static rather than on real hardware; if your build involves much in the way of threading or other complex stuff it will probably fail
[17:09] <cjwatson> But a reasonable number of simple builds work
[17:13] <cjwatson> mapreri: out-of-date address for bugs-mirror.debian.org in firewall - sending in a fix now
[17:14] <mapreri> why do you have the need to firewall outgoing connections I never understood
[17:15] <cjwatson> (a) not the LP team's decision (b) I assume it's defence in depth against attacks spreading
[17:15] <mapreri> my loco had to fight with canonical one year because a firewall compared all of a sudden in a machine hosting a planet, so no updates for weeks and they insisted with a "we need to know each address" nonsense...
[17:16] <mapreri> cjwatson: yeah, of course it has nothing to do with LP, it's a IS thing...
[17:16] <toan_> cjwatson, in ref to your commit 17896, do you have a sample project on LP that's use git recipe right now?
[17:17] <toan_> use=using
[17:18] <cjwatson> toan_: No, because we haven't finished deploying the changes to make that possible.
[17:19] <cjwatson> r17896 is part of that but by no means all of it, and in any case r17896 isn't yet on production.
[17:36] <cjwatson> mapreri: firewall change should be live soon; not sure how frequently checkwatches tries, it seems to have tried twice in those four days so far
[17:38] <mapreri> 2 times in 4 days doesn't sound so good.
[17:40] <cjwatson> it may depend on activity, or I may just have misread something
[17:52] <toan_> cjwatson, **stupid question** but is it possible to get ssh access to the buildserver/build env?
[17:53] <cjwatson> toan_: No.
[17:54] <cjwatson> toan_: But you can set up something very similar yourself locally: https://wiki.ubuntu.com/SimpleSbuild
[18:01] <mapreri> is more work on the bug watchers planned?  in particular, adding support to more bug trackers (istr there is a whole tag in launchpad gathering such requests)
[18:09] <cjwatson> mapreri: Not planned at the moment, we have rather a lot of other things that are going to take precedence
[18:12] <mapreri> ok
[18:12] <mapreri> well, I can just say please consider them between a huge thing and another :)
[18:12] <mapreri> at least we're going to have git recipes pretty soon ^^
[18:34] <toan_> cjwatson, I am writing a recipe in which it will pull down all of the enlightenment sourcecode transparently and then build the code... the whole process will probably take about 1+ hour to finish, can you tell me if the buildserver be ok will that, and that it wont cancel the job in the middle of the build!
[18:35] <toan_> cjwatson, BTW, the sourcecode that the buildscript will download isn't hosted on LP, it is on another git repo that bzr wouldn't know about
[18:36] <toan_> cjwatson, the whole fetch and build process will take about 3.5 hours, is that acceptable?
[18:37] <cjwatson> toan_: You won't be able to do that, because the builders are firewalled such that they cannot fetch external code
[18:37] <cjwatson> toan_: Find another approach
[18:37] <toan_> :-(, just dont want to mirror import the code to LP!
[18:37] <daker> hi, does anyone know what's the representation of the webhook response in LP ?
[18:41] <cjwatson> toan_: Maybe recipes are not the right tool for you.  All that recipes are is a convenience for building source packages; you can always build the source packages yourself and upload them directly to a PPA
[18:41] <cjwatson> daker: What exactly do you mean, and which webhook?
[18:42] <daker> cjwatson: like when i setup a webhook, what will LP push to the specified url ?
[18:42] <toan_> cjwatson, the problem is that I do not want to do it myself, i want to whole process to be automated and it will build for all distributions/architures
[18:42] <cjwatson> daker: Ah, you mean the webhook request
[18:42] <cjwatson> daker: https://help.launchpad.net/API/Webhooks
[18:44] <daker> cjwatson: thanks!
[18:44] <cjwatson> toan_: Then your choices are (a) arrange for bzr imports of all the git repositories you need (b) wait for both git recipes and git imports to be implemented (c) wait for git recipes to be implemented, and then set up something external that pushes git mirrors of the repositories you need to LP
[18:48] <toan_> cjwatson, yeah, i will wait for git-recipe; in the meantime, i will build the packages manually then push them to the PPA repo
[19:14] <nacc> have a (hopefully) quick query about the autobuild service... Logs at https://launchpadlibrarian.net/234639697/buildlog_ubuntu-xenial-amd64.phpab_1.21.0-1~ppaubuntu1_BUILDING.txt.gz ... I'd like to use the pkg-php-tools in the PPA itself (as specified in the overrides), but it trips a GPG error so it seems to not be using the PPA's package?
[19:21] <cjwatson> The GPG error is a harmless cosmetic thing
[19:21] <cjwatson> We disable verification anyway since it's entirely within our infrastructure
[19:21] <nacc> cjwatson: ok, that's what i wondered about
[19:22] <cjwatson> "but it is not going to be installed" generally indicates that the package in question is available but that one of its dependencies is uninstallable
[19:23] <nacc> cjwatson: ok, i'll try and see why it's happening
[19:23] <nacc> thanks
[19:24]  * cjwatson is looking
[19:30] <cjwatson> nacc: http://paste.ubuntu.com/14577102/
[19:30] <cjwatson> nacc: looks to me like a problem with various things still built against php5
[19:30] <nacc> cjwatson: hrm, interesting ... ill try and resolve that!
[19:30] <nacc> thanks for the pointer
[19:30] <cjwatson> chdist is really handy
[19:31] <nacc> cjwatson: yeah, i've used it, but not thought about it this way! very useful!
[19:38] <nacc> cjwatson: ok, so i'm now rather confused; i can manually install php-cli, php-json and php-pear from xenial + ppa in my chroot; and chdist also resolves the dependenciees for all 3 packages fine
[19:38] <nacc> cjwatson: that is, i don't get the same errors you did
[19:40] <nacc> cjwatson: chdist apt-get php7 install pkg-php-tools ... Need to get 127 MB/157 MB of archives...
[19:40] <cjwatson> nacc: you need to add phpunit as well
[19:40] <nacc> cjwatson: oh i see!
[19:41] <cjwatson> nacc: that's why I explicitly listed all the build-deps there - you have build-deps that conflict with each other, indirectly
[19:41] <nacc> got it
[19:41] <cjwatson> that is definitely a confusing situation to be in and it unfortunately takes some practice to get apt to be helpful here ...
[19:41] <nacc> feels like that message could be clearer, but that's neither here nor there :)(
[19:41] <nacc> yep, thanks for the tip!
[19:41] <cjwatson> yeah, it's difficult to extract this from apt without human intelligence :-/
[19:42] <cjwatson> one of these days we might stick dose-builddebcheck into the loop
[20:00] <toan_> cjwatson, what's the point of having a project like this on LP:  https://launchpad.net/efl, it has no sourcecode, be better if it was an imported project from git... it looks useless to me
[20:01] <toan_> i can't really write a recipe to pull from it, just curious why!
[20:31] <cjwatson> toan_: Anyone can create a project, so many people do.
[20:33] <cjwatson> Some of them are not very useful.
[20:33] <cjwatson> But we don't generally intervene unless asked by the project owners or unless it causes an actual problem of some kind.
[20:34] <cjwatson> Not least because if we spent time doing that we'd never have time for anything else ...