[03:52] dholbach: ping [06:40] good morning === dholbach_ is now known as dholbach [07:10] dholbach: you there? [07:10] hi vibhav, yes [07:10] dholbach: PM? [07:11] sure === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === yofel is now known as Guest57033 === Guest26014 is now known as Zic [12:28] what's the expected delay between a package landing in Sid, and arriving in Quantal? [12:28] whenever someone runs auto-sync [12:29] + delta for Launchpad to see the upload (some hours, less than a day) [12:31] directhex: you can syncpackage yourself to not have to wait for that [12:32] Laney, i don't like to jump around acting like i'm special if things are Normal(tm) [12:32] i don't think running syncpackage yourself is a problem at all [12:32] but it still will end up in NEW, etc, so may end up not being any faster depending on who does what and when [12:33] /ws 34 [12:33] grr [12:33] nigelb: what's 34 got that we haven't? [12:33] Laney: it's the other channel with conversation [12:34] they smell [12:34] stick over here, it's much nicer ♥ [12:34] haha, I'm always here <3 [12:34] Laney: What IRC client do you use? [12:35] irssi [12:35] that heart was from the compose key though, if that's what you're after [12:51] exactly, I hour left [12:59] could someone please fix bug #860045 ? It's quite annoying; I can't have both gdb and gdb-msp430 installed [12:59] Launchpad bug 860045 in gdb-msp430 (Ubuntu) "package gdb-msp430 7.2~mspgcc-7.2-20110612-1 failed to install/upgrade: trying to overwrite '/usr/share/gdb/python/gdb/__init__.py', which is also in package gdb 7.3-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/860045 [13:01] basically there are 2 packages that share some file paths they shouldn't share === ninjak_ is now known as ninjak [13:25] directhex: how about that — it just got done! === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Guest57033 is now known as yofel [15:07] Hi all! [16:05] howdy, I have three packages that I want to submit to mutliverse, and per the wiki, it looks like I am supposed to come here to find some friendly sponsors. The packages are Amazon AWS Tools for Auto Scaling, Cloud Watch and ElastiCache. [16:07] utlemming: you need 2 MOTUs to review the package before uploading (can include the uploader) [16:08] or even better, get them into Debian non-free [16:09] tumbleweed: yeah, except as I understand it, Debian is not a particular fan of the Amazon Software license [16:09] as long as distribution is allowed, it can go into Debian's non-free archive [16:10] tumbleweed: do we have time for the package to land in debian and then make it into Quantal? In look, it was unclear whether Debian is frozen or not at the moment [16:11] debian is in freeze, but a new package could probably get through to ubuntu before UBuntu's feature freeze [16:12] (new packages aren't really affected by debian's freeze, they just won't go into the next release) [16:12] feature freeze here is august 23rd [16:13] tumbleweed: okay, I'll take a look at trying to get these into Debian [16:15] hmm... something should be done with qucs... it's still in version 0.0.15 but 0.0.16 has been available for a long time [16:15] talking of ubuntu-only packages. I'm wondering if we should make it a standing item for MOTU meetings, to review (say) 20 ubuntu-only packages, and list the ones proposed for removal [16:16] tumbleweed: I think I have a work item to write up a proposal for removal criteria [16:16] \o/ [16:17] cousteau: that's been removed from quantal [16:17] it's on my mind because of bug 881007 [16:17] Launchpad bug 881007 in ruby-rvm (Ubuntu) "Remove ruby-rvm" [Wishlist,Confirmed] https://launchpad.net/bugs/881007 [16:17] RoQA; qt3, no qt4 port [16:17] ok, step 1: contact the debian maintainer to update it [16:17] micahg, what?? [16:17] cousteau: does upstream support qt4 yet? [16:18] cousteau: no, it's not in Debian anymore [16:18] but that program was quite nice! it can't be simply removed... [16:18] yes, it can be if it depends on an outdated software stack that can't be maintained :) [16:19] that's quite sad... [16:19] so, the ball is in upstream's court at this point [16:20] software dies of neglect all the time. It's the most common cause of death, I'd say [16:20] ok, so in order to get qucs back to linux... [16:20] hrm, I guess I"d consider a backport request of 0.0.16-2 to precise-backports [16:20] it should be ported to qt4? [16:21] * cousteau kinda dislikes qt4 [16:22] qt4 would allow backporting to wheezy/precise, qt5 would be in quantal+1/wheezy+1 [16:22] maybe the project could be forked, create a "grandly universal circuit simulator" [16:22] (gucs) [16:24] actually the problem with qucs is that it's developed in slow motion... if the little development effort/resources are channeled into rewriting the (non-broken) GUI to another library, the project will kinda die [16:24] is porting a program from one qt to another complicated? [16:28] ...seems to be some sort of work towards qt4 porting going on [16:29] is qt4 going to be deprecated too on quantal+1? [16:31] (hmm... also a Verilog-AMS interface? cool... what about VHDL-AMS, I wonder? I should contact the authors to get more info) [16:36] cousteau: probably not for quantal+1, but I'm guessing for the next LTS/Wheezy+1 maybe [16:37] ok... [17:41] ok, so... seems that qucs port to qt4 is still going on (I think)... so I think I'm going to keep on Precise for a looong time [17:44] cousteau: I think it will be a few releases before Qt4 is deprecated and even if it is, Qt4 -> Qt5 porting is supposed to be trivial (Qt3 -> Qt4 is not). Sometimes as little as recompiling the package. === philipballew_ is now known as philipballew [19:18] If an upstream does NOT used have a SONAME (version), where should they start versioning from? [19:18] 0? [19:20] tumbleweed, Do I get it right that if upstream's (say libx) version is in between 1.0-1.9 (suppose), the soname will be libx.so.1? For 2.0-2.9, soname will be something like libx.so.2? ...and so on. [19:21] a soname is actually just a string of text [19:21] so, it can be anything [19:21] if they'd like to make the soname the major version number, that's very convenient [19:21] ah, so any 'unique' string of test will suffice. [19:21] pretty much [19:22] if you are using libtool, it thinks sonames are all X.Y.Z (where those are numbers) [19:22] but really, there is no such requirement [19:22] Right then, I'll use the major version numbers as soname then (no need to violate the de facto standard)! [19:23] The upstream is using cmake (no libtool involved)... [19:23] with libtool the soname is .X [19:23] the other numbers are revision and something I forgot [19:24] fair point [19:24] cmake uses a similar method to libtool to my recollection [19:25] no it has an arbitrary string [19:27] yes, cmake (using a set_target_properties() rule) can put an arbitrary string in SOVERSION property for library targets. [19:32] Why don't some shared libs in my /usr/lib/ don't have a version appended at the end of the SONAME? (e.g. libADM_core.so) [19:32] Isn't a version/SOVERSION "required" in SONAME? [19:33] its not required, but for a public library its a strong must [19:34] Oh yes, it should be a must (since it provides version backwards compatibility information). [19:35] often upstreams don't care so much about versioning, but a packages should try to educate them [19:35] if no versioning is intended it should go in a private subfolder so nothing else tries linking against it [19:35] lots of upstrams don't care about stable ABIs [19:36] ok [19:36] In my case, it a public library/upstream... [19:36] * AmberJ writes an email to upstream developers with a cmake/soversion patch [19:36] *cough* boost *coug* [19:36] heh [19:37] micahg: don't know why you're coughing there :) [19:39] any staticly compiled language :) [19:40] Are filenames of all public shared libraries in /usr/lib supposed to start with lib (i.e. of the form lib*)? [19:40] and things that aren't compiled have similar issues in API stability [19:41] In my /usr/lib, I see only 1 .so whose name does not starts with "lib"... [19:41] Or, is it just a matter of personal/upstream choice? [19:42] I think all must start with lib, its the prefix gcc uses with -l [19:43] everything else is a loadable module and usually resides in subfolders [19:43] ah yes [19:43] Thanks tumbleweed and jtaylor :) [19:52] I want to package Eclipse juno, the latest version of the ide. I've already uncompressed it, but I don't know how to prepare for compilation. === mfisch` is now known as mfisch [19:53] ./configure doesn't work... the program obviously doesn't have it. === mfisch is now known as Guest84007 [19:53] presumably it has instructions [19:54] tumbleweed, how do I find the instructions for packaging it? [19:54] epikvision: I'd suggest starting with the current eclipse packaging [19:54] epikvision: you might want to ask in #debian-java on OFTC and see how you can help make it happen [19:55] jbicha: how can I help out with the current eclipse packaging? [19:56] you were just told ... [19:56] if you're a beginner to Debian packaging, Eclipse is probably not a good place to start [19:57] ok [19:57] epikvision: http://developer.ubuntu.com/packaging/html/ [19:59] perhaps the debian maintainer guide is also useful? [20:01] yes, (as a beginner to Debian/Ubuntu packaging), I found out maint-guide very useful. [20:10] The packaging guide suggests to package in the development environment. [20:11] does that mean to use the terminal in quantal? [20:11] most developers run the development release (after the first few months) [20:11] (or at least I think they should) [20:11] but you can work on a stable release, and build in chroots (pbuilder/sbuild), which is a good practice anyway [20:12] ok [20:19] if I forgot to --fixes lp:foo several commits ago, can I go back and add it without having to uncommit all the way down? [20:19] maybe with rebase onto [20:19] Laney: is it in the changelog already? [20:19] or loomifying and then converting back to commits [20:20] it's not a package [20:20] but yes, I find that kind of thing much easier in git [20:20] (it is launchpad) [20:20] (ph33r) [20:20] ooh [20:20] I think I'll just not bother :-) [20:21] what are you fixing for us today? [20:21] hrm, idk of a way to go back [20:21] just proposed notautomatic [21:52] my quantal chroots are acting up [21:53] can'T find debhelper when doing --build [21:53] components are correct --login works ...