ista | Does ubuntu ppa support http transfer? | 04:48 |
---|---|---|
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:51 |
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:53 |
ista | but I have set my username | 04:54 |
wgrant | What is your Launchpad username? | 04:54 |
ista | kaelrenc | 04:54 |
wgrant | Your Launchpad account doesn't have any SSH keys associated. | 04:55 |
wgrant | https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 04:55 |
ista | I'm sorry I don't remember that, thank you | 04:56 |
=== stub` is now known as stub | ||
=== zenitraM^away is now known as zenitraM | ||
=== zenitraM is now known as zenitraM^away | ||
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:03 |
cjwatson | Yes, pretty much | 09:04 |
cjwatson | You must use -S for your uploads to Launchpad | 09:04 |
ista | What's the details? | 09:05 |
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:06 |
ista | But I only want to build binary for amd64, | 09:07 |
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:08 |
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:09 |
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:10 |
cjwatson | Yes | 09:11 |
cjwatson | But it's spelled dpkg-buildpackage not dpkg-buildpackages | 09:11 |
ista | sorry. | 09:12 |
ista | get it. | 09:12 |
ista | Another problem: launchpad.net sent build error | 09:37 |
ista | here is the log: https://launchpadlibrarian.net/153368679/buildlog_ubuntu-precise-amd64.glib_2.39.0%2Bgit20131010-1_FAILEDTOBUILD.txt.gz | 09:38 |
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:39 |
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:40 |
ista | GLIB 2.36.0 or better is required. The latest version o | 09:41 |
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:42 |
ista | use repositories of ubuntu raring? | 09:43 |
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:44 |
cjwatson | (It won't :-) ) | 09:45 |
ista | that should be much easier than build from scratch. | 09:46 |
ista | good idea, I will have a try. | 09:47 |
=== 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 | ||
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) | 15:58 |
cjwatson | You might need to ask #bzr for that | 16:01 |
dsmythies | Oh... O.K. I'll go there. | 16:03 |
=== yofel_ is now known as yofel | ||
=== zenitraM is now known as zenitraM^away | ||
=== ahasenack is now known as andreas | ||
bjf | is qastaging having issues? talking to it via the api just returns 403 errors | 20:56 |
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? | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!