[04:48] <ista> Does ubuntu ppa support http transfer?
[04:51] <ista> while trying dput with configuration method = sftp, I meet Unable to connect to SSH host ppa.launchpad.net; EOF during negotiation
[04:51] <wgrant> ista: You can only upload to a Launchpad PPA using SFTP or FTP.
[04:51] <wgrant> If your network doesn't permit either of those protocols to ppa.launchpad.net, you'll need to find another network from which to upload your packages.
[04:53] <ista> Uploading to my-ppa (via sftp to ppa.launchpad.net):
[04:53] <ista>   babl_0.1.8-1.dsc: Permission denied (publickey).
[04:53] <wgrant> ista: Ah, so you can connect over sftp, but your authentication setup isn't working.
[04:53] <wgrant> you need to have your Launchpad username in dput.cf, and your SSH key uploaded to Launchpad.
[04:54] <ista> but I have set my username
[04:54] <wgrant> What is your Launchpad username?
[04:54] <ista> kaelrenc
[04:55] <wgrant> Your Launchpad account doesn't have any SSH keys associated.
[04:55] <wgrant> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[04:56] <ista> I'm sorry I don't remember that, thank you
[09:03] <ista> After uploading .deb packages, an email noted that Rejected: Source/binary(i.e.mixed)uploads are not allowed. Is there a clear difference between Source and Binary?
[09:03] <ista> dpkg-buildpackages -S OR dpkg-buildpackages -B?
[09:04] <cjwatson> Yes, pretty much
[09:04] <cjwatson> You must use -S for your uploads to Launchpad
[09:05] <ista> What's the details?
[09:06] <cjwatson> source uploads have "Architecture: source" in .changes and include a .dsc file and some other files referenced by it (original tarball, packaging)
[09:06] <cjwatson> binary uploads have machine architectures or "all" in the Architecture field in .changes and include binary packages such as .debs
[09:06] <cjwatson> mixed uploads are used in Debian but not in Ubuntu, and have some combination of both
[09:07] <ista> But I only want to build binary for amd64,
[09:08] <cjwatson> ista: You don't build the binary, Launchpad does (if you want it hosted on Launchpad)
[09:08] <cjwatson> ista: If you only want Launchpad to build your package for amd64, then put "Architecture: amd64" in debian/control in place of "Architecture: any"
[09:09] <cjwatson> But you still use dpkg-buildpackage -S
[09:09] <cjwatson> Launchpad does not accept *any* binary uploads from any entity other than its own builders.
[09:09] <ista> But why must run dpkg-buildpackages locally? It takes too much time
[09:09] <cjwatson> dpkg-buildpackage -S only builds the source package; it's usually quick
[09:10] <cjwatson> Unless the source package is gigantic
[09:10] <ista> Ah, If I dont't want to make a local .deb file, then I can simply run dpkg-buildpackages -S?
[09:11] <cjwatson> Yes
[09:11] <cjwatson> But it's spelled dpkg-buildpackage not dpkg-buildpackages
[09:12] <ista> sorry.
[09:12] <ista> get it.
[09:37] <ista> Another problem: launchpad.net sent build error
[09:38] <ista> here is the log: https://launchpadlibrarian.net/153368679/buildlog_ubuntu-precise-amd64.glib_2.39.0%2Bgit20131010-1_FAILEDTOBUILD.txt.gz
[09:39] <cjwatson> ista: That's an error in your packaging; missing Build-Depends: zlib1g-dev by the looks of it.
[09:39] <cjwatson> /usr/bin/ld: cannot find -lz
[09:40] <cjwatson> ista: There'll be several more.  Why not base your work on the existing glib2.0 source package in Ubuntu, rather than trying to reinvent the wheel?
[09:40] <cjwatson> It's usually not a good plan to repackage things from scratch.
[09:41] <ista> GLIB 2.36.0 or better is required. The latest version o
[09:42] <ista> glib v2.32 on ubuntu 12.04
[09:42] <cjwatson> ista: Sure, but why not simply backport the glib2.0 source package from raring or saucy?
[09:42] <cjwatson> ista: It'll be about a hundred times easier than trying to redo all the work yourself and then somehow keeping it reasonably compatible and not destroying your system when you try to install it
[09:43] <ista> use repositories of ubuntu raring?
[09:44] <cjwatson> ista: You can start by just downloading the source from raring or saucy, tweaking the version (say, add a new changelog entry with ~ppa1 appended to the version number), and uploading that to your PPA
[09:44] <cjwatson> It's possible that will fail but it will be a LOT easier to debug than hoping that dh_make will somehow duplicate the effort of many very experienced packagers over more than a decade
[09:45] <cjwatson> (It won't :-) )
[09:46] <ista> that should be much easier than build from scratch.
[09:47] <ista> good idea, I will have a try.
[15:58] <dsmythies> The revision date and time details seem to be based on the changelog entry and not on when the package import robot actually executed. Is there a way to determine when the import actually occurred and what upstream revision it imported?
[15:58] <dsmythies> Reference 1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntu-docs/saucy/revision/113
[15:58] <dsmythies> Reference 2: https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntu-docs/saucy  (where rev 113 actually appeared on or about October 4th, not September 16th)
[15:58] <dsmythies> Reference 3: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/saucy  (where, as best as I can determine, rev 113 above seems to be based on upstream rev 274, but should have been rev 275)
[16:01] <cjwatson> You might need to ask #bzr for that
[16:03] <dsmythies> Oh... O.K. I'll go there.
[20:56] <bjf> is qastaging having issues? talking to it via the api just returns 403 errors
[23:30] <philsf> hello, I published code for two projects in lp, but in my innocence I used (bzr) tags to identify release versions. what is the best practice to track those in lp? do I need to branch at each version?