=== echidnaman is now known as JontheEchidna === RAOF_ is now known as RAOF [09:11] * tumbleweed waves from coatia. Expect to be out of contact for the next week [09:12] slacker ! [09:12] :) === yofel_ is now known as yofel [13:16] tumbleweed: have fun! [14:38] Hello [14:39] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952 says that: "usr/lib/*.so : development linkage file, used when other programs are linked with -lxxx" belongs to -dev package [14:39] What are development linkage files? === mitya57_ is now known as mitya57 [15:04] Anyone? [15:04] I guess everyone is 'busy' enjoying their weekends ;) [15:09] What is your question? [15:43] Hello there hello there can I get some help uploading a debian package to a ppa that I made for friend ? all the code is located http://bazaar.launchpad.net/~josephjamesmills/+junk/zen-koans/files I built the package two different ways and it will still not upload with dput dpkg-builpackage & also with debuild -S -sa uploads great but I get a e-mail saying that it has failed ppa is located https://launchpad.net/~josephjamesmill [15:43] s/+archive/koan Thanks for your time :) [16:22] bobweaver: https://launchpad.net/~josephjamesmill does not exist [16:23] O_o [16:23] https://launchpad.net/~josephjamesmills/+archive/koan [16:23] the all the code is here thou [16:23] http://bazaar.launchpad.net/~josephjamesmills/+junk/zen-koans/files [16:24] I cannot see build logs on PPA url (permissions issue, I guess). Can you upload them to a pastebin? [16:24] sure [16:26] http://paste.ubuntu.com/1032308/ < zen-koans_0.0.1-1ubuntu2_source.ppa.upload [16:26] http://paste.ubuntu.com/1032310/ < zen-koans_0.0.1-1ubuntu2_amd64.ppa.upload [16:28] this is my first time ever using dput and leting launchpad make the build not sure if I am doing something wrong but I went thou all the wiki for LP and also Motu packaging guide [16:29] Not this. [16:30] you want the email that gets sent with rejection ? [16:30] http://paste.ubuntu.com/1032316/ [16:30] When build on PPA fails, you get an email about the same. When you go on your PPA page, you see a build failed message with build log. [16:31] The log is very long spanning many pages. It's PPA build fail log. [16:34] bobweaver: you have wrong Section: field in debian/control [16:34] Thanks mitya57 [16:34] and also AmberJ [16:34] you are welcom [16:34] *welcome [16:34] I will fix control file now [16:37] perl would be the correct section ? [16:37] reading from here http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections [16:38] it's a perl program or modual plug in [16:39] or should it be "contrib" [16:39] I am confused sorry [16:39] Sorry, I am much of a newbie my self to this... [16:41] bobweaver: Those are the archive areas. Have a look at http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Section. [16:41] iulian, yeah I was looking at that and am confused [16:41] seems like there are three main sections [16:41] then there are "sub-sections " [16:42] what is contrib ? [16:42] or should this be "perl" as it is nothing but a new modual and a perl script [16:43] bobweaver: perl is ok [16:44] contrib means that the package depends on non-free components [16:44] thanks a ton ! [16:45] bobweaver: Here, found it. See http://www.debian.org/doc/debian-policy/ch-archive.html. Scroll down to 2.4. [16:45] lol seems like there are a-lot of the same-page :/ [16:46] Hi all! [16:47] Salve [16:47] If a package foo has both some *.so and some binaries, there will still exist a foo-dev.deb for header files for libraries in foo.deb [16:47] ...as is for lib*.deb style packages. [16:48] mitya57, iulian AmberJ Thanks again I will also I will report back on errors or anything with upload of package I am also going to clean up the changelog file [16:50] Could somebody have a look at https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/1010920 ? [16:50] Launchpad bug 1010920 in libvdpau (Ubuntu) "Please merge libvdpau (main) from Debian Unstable (0.4.1-6)" [Undecided,New] [16:50] In other words, lib*.deb has companion lib*-dev.deb packages. Does -dev packages exist for packages that have both binaries and libraries packaged together? [16:57] Ok so this is what I did I rm all the old tar stuff dsc deb ect then changed control and also changelog. made new tar.gz file mv it then ran dh_make -f foo.tar.gz then mv foo.tar.gz ../ then debuild -S -sa [16:57] Now I am going to try to use dput again [16:58] bobweaver: you should use dh_make only when you create initial packaging [16:59] * Elbrus was going to say that [16:59] ;) [16:59] you should just edit d/control and run debuild -S -sa [16:59] mitya57, I can just make tar czf foo.orig.tar.gz foo/ ? [17:00] ahh cool Thanks a ton ! [17:00] bobweaver: yes, if your build directory doesn't yet contain original source [17:02] there are more things that I must must learn because It has been taking me alot time to clear out debian file and all old build stuff then make new tar mv to source tree run dh_make then mv tar back ../ then fakeroot dpkg-buildpackage -f then debuild -S -sa [17:02] dpkg-buildpackage -F * [17:03] less errors this time but I got this error Unable to find distroseries: unstable [17:04] because it is quantel ? [17:04] you shouldn't generally run dpkg-buildpackage, debuild calls it for you [17:04] yes, in ubuntu it's quantal or precise, unstable is for Debian [17:05] Thanks again does dch conform to Ubuntu standers ? meaning it makes control file set up for Ubuntu ? [17:11] Is it better to use dch instead for altering control by hand ? === almaisan-away is now known as al-maisan [17:13] \0/ https://launchpad.net/~josephjamesmills/+archive/koan [17:13] thanks a ton every one ! === al-maisan is now known as almaisan-away [17:20] bobweaver: dch is used for editing changelog, not control [17:20] woops there is a tool like dch for d/control ? [17:42] bobweaver: sorry for the late reply (please call me directly next time); no, there's no such tool [17:49] mitya57, will do thank's for getting back to me :) [18:55] highvoltage: that's the plan, although I clearly made the mistake of getting a local sim and bringing a travel laptop charger :) [19:49] tumbleweed: hehe [20:09] stupid libtool I add something to LDFLAGS its ordered fine in the Makefile, but after libtool mangles it LDFLAGS lands behind the libs oO [20:14] libtool is made of stupid [20:31] If a package foo.deb has both some *.so and some binaries, does foo-dev.deb exist as well (for header files for libraries in foo.deb)? [20:31] Similar to lib*-dev.deb for lib*.deb [20:51] AmberJ_: Well it would depend on the package. But often, yes. [20:57] though in that case it is more common to split the deb into a library and binary deb [20:58] amberJ, it's totally at packager's discretion. [20:58] as having seperate headers implies its a public library [20:58] how about just pcfiles? [20:58] e.g. monodevelop or banshee [20:59] they don'T have libraries [21:19] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id250085 says using libfoo-runtime or libfoo-dev or /usr/lib/libfooX ... [21:21] I used libfoo-bin once [21:22] Someone mentioned that above lined debian library packaging guide is outdated. Can I use above mentioned reocmmendations from that guide? [21:22] s/lined/linked [21:24] There are examples of using -bin, -util, -utils, -tools, -runtime in the archive [21:25] most use -bin [21:25] util is probebly most intuative [21:33] ok [21:44] Huh... I don't understand why some *.so files go in lib*.deb and others in lib*-dev.deb ? [21:44] Source: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id250154 [21:45] AmberJ: *files* or *symlinks* ? [21:45] I would be surprised to see a .so *file* in -dev [21:45] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952 says: "usr/lib/*.sodevelopment linkage file, used when other programs are linked with -lxxx" for *-dev.deb [21:46] maxb: that^ [21:46] right; that would be a symlink to the .so in the libfoo.deb [21:48] maxb: But http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249898 says: "Usually, (libfoo.deb) contains the library file itself, somehow called libfoo.so.X.X.X and its symlink libfoo.so.X ..." [21:48] That link says that there's a symlink in libfoo.deb package... [21:48] Do you mean to say that we add another in libfoo-dev.deb as well? [21:48] yes, there are symlinks there too [21:48] ohk [21:49] Got it now! Thanks everyone. [21:49] The essence of what's going on is: [21:49] * The actual shared library has the most specific versioned name [21:50] * There's a symlink containing (normally) a single integer, which is the name by which the library gets looked up by at runtime [21:50] * There's a symlink containing no version at all (or just the major version) by which the latest version of libfoo can be linked to at build time [21:51] e.g. have a look at the contents zlib1g vs. zlib1g-dev [21:52] hmm, that concisely explains it all. [21:53] :-) [21:54] Are you familiar with the concept of a 'soname'? [21:54] #1 is to facilitate existence of multiple versions of a library. #2 and #3 are to facilitate library lookup at runtime and compile time. [21:55] yes, I read about soname role in packaging at http://developer.ubuntu.com/packaging/html/libraries.html [21:56] the soname is how the linker, accessing the library via #3, knows what the #2 name is to code in to the binary for use at runtime [22:16] ok