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