[00:13] <nathaneltitane> hello! i would like to become a maintainer for an application that hasn'T been updated for a while as a deb package. I have created my ppa, generated the project, described the branch and asked for a pull (CVS), the first build attempt returned this: https://launchpadlibrarian.net/166382622/buildlog.txt.gz i am not really experienced with any of this.. could someone help me please?
[00:15] <sarnold> nathaneltitane: it looks like your build scripts try to use network resources when building; the buildds do not allow builds to use any networking.
[00:15] <nathaneltitane> sarnold: hence, what should i do? upload the code manually?
[00:16] <TJ-> nathaneltitane: You should be uploading (dput) the debianised package source to the builder
[00:16] <sarnold> nathaneltitane: yeah, either as a new 'upstream tarball' in the build or modify the source via debian patching
[00:18] <nathaneltitane> sarnold: afaik, i'M not familiar with deb patching, though upstream tarball sounds best.
[00:18] <nathaneltitane> give me second to test
[00:19] <nathaneltitane> sarnold: i just pulled the source from cvs on my system and made a tarball
[00:20] <nathaneltitane> how do i push it?
[00:20] <nathaneltitane> please bare with me, it's the first time i do this, and as much as I've read the links and indications, i'M still somewhat confused
[00:20] <sarnold> nathaneltitane: do you have an 'unpacked' tree anywhere, with e.g. debian/control file and debian/changelog and so forth?
[00:21] <nathaneltitane> sarnold: nope
[00:21] <nathaneltitane> did a cvs pull, plain and simple
[00:21] <sarnold> nathaneltitane: indeed, I've been doing it for 1.5 years and still lack the vocabulary to explain what I do and how to make it work :) hehe
[00:21] <nathaneltitane> i need to 'debianize it' using the build-essentials?
[00:21] <sarnold> nathaneltitane: can you apt-get source an existing package from the ubuntu archives? that'd give you an unpacked source tree
[00:21] <nathaneltitane> there is no ubuntu archive
[00:22] <nathaneltitane> i'm the one setting it up
[00:22] <nathaneltitane> the source is in cvs
[00:22] <sarnold> nathaneltitane: oh! okay. then there's a bit more work ahead of you :)
[00:22] <sarnold> (Please forgive me, all I do is pull existing stuff, make tiny changes, and push it back. :)
[00:22] <nathaneltitane> well ideally, that'S what i'll be doing too :)
[00:22] <sarnold> :)
[00:22] <nathaneltitane> so i have a pull.. what now
[00:24] <Unit193> sarnold: Tip, use dh_make, handy for creating a template to work off of.
[00:24] <sarnold> nathaneltitane: well, there's two different ways of doing packaging; there's the newfangled "ubuntu distributioned development" method, which is pretty well dscribed at http://packaging.ubuntu.com/html/ -- but it always felt like a lot of extra overhead compared to the older more traditional debian packaging..
[00:25] <sarnold> Unit193: ooh. that looks cool.
[00:25] <nathaneltitane> let'S get started the 'easy' way then
[00:26] <Unit193> sarnold: Yeah, used it for the first time recently, pretty nifty.  Note that the older release you're running on, the more slightly outdated it'll be (dh8 vs dh9 on saucy)
[00:27] <sarnold> nathaneltitane: Unit193's suggestion of dh_make looks fantastic; apt-get install dh-make and check out the dh_make manpage. it looks straightforward and simple. :)
[00:28] <sarnold> Unit193: yeah, that makes sense. most tools I'm used to using do require running fairly new releases to keep building for fairly new releases. :) hehe
[00:29] <sarnold> Unit193: Thanks for the pointer, this'll save tons of time :)
[00:29] <Unit193> sarnold: Sure, welcome.
[00:32] <nathaneltitane> sarnold: looking into it
[00:38] <nathaneltitane> wow, that seemes to have worked like a charm sarnold
[00:39] <nathaneltitane> so i now have an ldview-4.2.1/debian dir tree
[00:39] <nathaneltitane> i used the Tar.gz i pulled as the original source
[00:44] <sarnold> nathaneltitane: nice!
[00:45] <sarnold> nathaneltitane: check out the debian/changelog file and make sure it looks useful and then try to build with dput: https://help.launchpad.net/Packaging/PPA/Uploading
[00:46] <nathaneltitane> shouldn't i make the install dirs first?
[00:47] <sarnold> nathaneltitane: heh, I was just hoping it would Do The Right Thing :)
[00:47] <Unit193> Also all the debian/*ex files.
[00:48] <nathaneltitane> sarnold, all the ex files look good
[00:54] <nathaneltitane> i have no changes file....
[00:55] <sarnold> nathaneltitane: that might not be an issue for a first upload?
[00:56] <nathaneltitane> sarnold, i still dont get which one i need to upload
[00:57] <nathaneltitane> i have the deb tree and the tar gz that was generated by dh-make
[01:02] <sarnold> nathaneltitane: hrm. sorry, I hadn't realized the dsc wouldn't be sufficient for the upload.
[01:13] <Unit193> You normally dput the changes file.
[01:22] <infinity> Unit193: s/normally/always/
[01:24] <Unit193> Yes.
[11:14] <doko> infinity, can't see that
[11:18] <infinity> doko: https://launchpad.net/ubuntu/+source/gccgo-go/1.2-0ubuntu5
[11:19] <infinity> doko: The FTBFS on armhf and powerpc.
[11:20] <doko> urgh, and the non-build on ppc64el ...
[11:20] <doko> jamespage, ^^^
[11:20] <infinity> doko: The non-build on ppc64el is because we're purging the archive.
[11:20] <doko> ahh
[11:20] <infinity> doko: It'll get a build record tomorrow.
[11:21] <infinity> doko: Shot in the dark, but libgcc-4.8-dev would imply perhaps a mismatch for headers/static library from the 4.9 libgcc1?
[11:22] <doko> no, thats blindly shooting
[11:23] <infinity> Hence "shot in the dark". :P
[11:24] <infinity> doko: Mostly just want to know that whatever that issue is, it's not something that's going to screw the ppc64el rebuild tomorrow.  If it's specific to gccgo, or gccgo-go, then yay, if it's something that needs fixing with libgcc, on the other hand...
[11:28] <infinity> doko: Erk.  So, on x86, I have a /usr/lib/<triplet>/4.8/libgcc_s.so symlink to /lib/<triplet>/libgcc_s.so.1
[11:28] <infinity> doko: On ppc64el, it's a linker script instead of a symlink.
[11:28] <infinity> doko: Seems an odd disparity.
[11:29] <infinity> Oh, maybe that's intentional too, since some arches need -lgcc?
[11:36] <doko> it's intentional. the .so symlink is just missing
[11:39] <infinity> Which symlink?
[13:46] <qengho> Hi all.  I'm trying to boot a CD for the first time in ages.  I find I'm dumped into a initramfs shell, but it's not clear why -- no messages or anything.  A strange thing, I think, is that after the shell prompt, the kernel displays the device-discovery lines for the CD device.  So, I suspect that it's trying to rotate root, hasn't settled USB, aborts silently.
[13:50] <qengho> I found this to be the same for when I'm booting off a UMS stick too.  Device discovered about 1 sec after being dumped into a initramfs shell.
[13:50] <qengho> Trusty daily image of yesterday, for that^.
[18:11] <teward> is there a reason that some packages only have arm64 and ppc64el builds and not builds for other architectures?
[18:15] <Ampelbein> teward: They most likely have been built in earlier releases for i386, amd64 etc
[18:16] <teward> Ampelbein: ah, okay, i see.  it would only show builds for a given release if, say, the version changed?
[18:16] <teward> (the package in question seems to have remained the same version since Quantal)
[18:17] <Ampelbein> teward: Yes, pretty much. Once a binary package is published, that version will not be rebuilt.
[18:19] <teward> okay, that threw me off on Launchpad
[18:19] <teward> thanks
[18:19] <Ampelbein> teward: Like https://launchpad.net/ubuntu/+source/aoetools -> Uploaded in lucid, built for the architectures that lucid was released with. Then, in precise, the armhf was introduced, so it was built there.
[18:19] <Ampelbein> Quantal didn't have a new architecture, so no build records at all.
[18:19] <Ampelbein> Saucy then got arm64 and finally trusty got ppc64el
[18:19] <teward> right
[20:29] <Noskcaj> darkxst, What do we still need to get gnome-desktop 3.10? Also, are there any 3.12 parts we want?
[22:59] <highvoltage> ogra_: thanks so much