[04:48] Does ubuntu ppa support http transfer? [04:51] while trying dput with configuration method = sftp, I meet Unable to connect to SSH host ppa.launchpad.net; EOF during negotiation [04:51] ista: You can only upload to a Launchpad PPA using SFTP or FTP. [04:51] 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] Uploading to my-ppa (via sftp to ppa.launchpad.net): [04:53] babl_0.1.8-1.dsc: Permission denied (publickey). [04:53] ista: Ah, so you can connect over sftp, but your authentication setup isn't working. [04:53] you need to have your Launchpad username in dput.cf, and your SSH key uploaded to Launchpad. [04:54] but I have set my username [04:54] What is your Launchpad username? [04:54] kaelrenc [04:55] Your Launchpad account doesn't have any SSH keys associated. [04:55] https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair [04:56] I'm sorry I don't remember that, thank you === stub` is now known as stub === zenitraM^away is now known as zenitraM === zenitraM is now known as zenitraM^away [09:03] 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] dpkg-buildpackages -S OR dpkg-buildpackages -B? [09:04] Yes, pretty much [09:04] You must use -S for your uploads to Launchpad [09:05] What's the details? [09:06] source uploads have "Architecture: source" in .changes and include a .dsc file and some other files referenced by it (original tarball, packaging) [09:06] binary uploads have machine architectures or "all" in the Architecture field in .changes and include binary packages such as .debs [09:06] mixed uploads are used in Debian but not in Ubuntu, and have some combination of both [09:07] But I only want to build binary for amd64, [09:08] ista: You don't build the binary, Launchpad does (if you want it hosted on Launchpad) [09:08] 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] But you still use dpkg-buildpackage -S [09:09] Launchpad does not accept *any* binary uploads from any entity other than its own builders. [09:09] But why must run dpkg-buildpackages locally? It takes too much time [09:09] dpkg-buildpackage -S only builds the source package; it's usually quick [09:10] Unless the source package is gigantic [09:10] Ah, If I dont't want to make a local .deb file, then I can simply run dpkg-buildpackages -S? [09:11] Yes [09:11] But it's spelled dpkg-buildpackage not dpkg-buildpackages [09:12] sorry. [09:12] get it. [09:37] Another problem: launchpad.net sent build error [09:38] here is the log: https://launchpadlibrarian.net/153368679/buildlog_ubuntu-precise-amd64.glib_2.39.0%2Bgit20131010-1_FAILEDTOBUILD.txt.gz [09:39] ista: That's an error in your packaging; missing Build-Depends: zlib1g-dev by the looks of it. [09:39] /usr/bin/ld: cannot find -lz [09:40] 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] It's usually not a good plan to repackage things from scratch. [09:41] GLIB 2.36.0 or better is required. The latest version o [09:42] glib v2.32 on ubuntu 12.04 [09:42] ista: Sure, but why not simply backport the glib2.0 source package from raring or saucy? [09:42] 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] use repositories of ubuntu raring? [09:44] 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] 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] (It won't :-) ) [09:46] that should be much easier than build from scratch. [09:47] good idea, I will have a try. === zenitraM^away is now known as zenitraM === zenitraM is now known as zenitraM^away === zenitraM^away is now known as zenitraM === bencer_ is now known as bencer [15:58] 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] Reference 1: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ubuntu-docs/saucy/revision/113 [15:58] 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] 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] You might need to ask #bzr for that [16:03] Oh... O.K. I'll go there. === yofel_ is now known as yofel === zenitraM is now known as zenitraM^away === ahasenack is now known as andreas [20:56] is qastaging having issues? talking to it via the api just returns 403 errors [23:30] 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?