vibhav | dholbach: ping | 03:52 |
---|---|---|
dholbach | good morning | 06:40 |
=== dholbach_ is now known as dholbach | ||
vibhav | dholbach: you there? | 07:10 |
dholbach | hi vibhav, yes | 07:10 |
vibhav | dholbach: PM? | 07:10 |
dholbach | sure | 07:11 |
=== 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 | ||
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:28 |
Laney | + delta for Launchpad to see the upload (some hours, less than a day) | 12:29 |
Laney | directhex: you can syncpackage yourself to not have to wait for that | 12:31 |
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:32 |
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:33 |
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:34 |
Laney | irssi | 12:35 |
Laney | that heart was from the compose key though, if that's what you're after | 12:35 |
vibhav | exactly, I hour left | 12:51 |
cousteau | could someone please fix bug #860045 ? It's quite annoying; I can't have both gdb and gdb-msp430 installed | 12:59 |
ubottu | 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 | 12:59 |
cousteau | basically there are 2 packages that share some file paths they shouldn't share | 13:01 |
=== ninjak_ is now known as ninjak | ||
Laney | directhex: how about that — it just got done! | 13:25 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
=== Guest57033 is now known as yofel | ||
PaoloRotolo | Hi all! | 15:07 |
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:05 |
micahg | utlemming: you need 2 MOTUs to review the package before uploading (can include the uploader) | 16:07 |
tumbleweed | or even better, get them into Debian non-free | 16:08 |
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:09 |
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:10 |
tumbleweed | debian is in freeze, but a new package could probably get through to ubuntu before UBuntu's feature freeze | 16:11 |
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:12 |
utlemming | tumbleweed: okay, I'll take a look at trying to get these into Debian | 16:13 |
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:15 |
micahg | tumbleweed: I think I have a work item to write up a proposal for removal criteria | 16:16 |
tumbleweed | \o/ | 16:16 |
micahg | cousteau: that's been removed from quantal | 16:17 |
tumbleweed | it's on my mind because of bug 881007 | 16:17 |
ubottu | Launchpad bug 881007 in ruby-rvm (Ubuntu) "Remove ruby-rvm" [Wishlist,Confirmed] https://launchpad.net/bugs/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:17 |
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:18 |
cousteau | that's quite sad... | 16:19 |
micahg | so, the ball is in upstream's court at this point | 16:19 |
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:20 |
* cousteau kinda dislikes qt4 | 16:21 | |
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:22 |
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:24 |
cousteau | ...seems to be some sort of work towards qt4 porting going on | 16:28 |
cousteau | is qt4 going to be deprecated too on quantal+1? | 16:29 |
cousteau | (hmm... also a Verilog-AMS interface? cool... what about VHDL-AMS, I wonder? I should contact the authors to get more info) | 16:31 |
micahg | cousteau: probably not for quantal+1, but I'm guessing for the next LTS/Wheezy+1 maybe | 16:36 |
cousteau | ok... | 16:37 |
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:41 |
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. | 17:44 |
=== philipballew_ is now known as philipballew | ||
AmberJ | If an upstream does NOT used have a SONAME (version), where should they start versioning from? | 19:18 |
tumbleweed | 0? | 19:18 |
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:20 |
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:21 |
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:22 |
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:23 |
tumbleweed | fair point | 19:24 |
jtaylor | cmake uses a similar method to libtool to my recollection | 19:24 |
jtaylor | no it has an arbitrary string | 19:25 |
AmberJ | yes, cmake (using a set_target_properties() rule) can put an arbitrary string in SOVERSION property for library targets. | 19:27 |
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:32 |
jtaylor | its not required, but for a public library its a strong must | 19:33 |
AmberJ | Oh yes, it should be a must (since it provides version backwards compatibility information). | 19:34 |
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:35 |
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:36 |
ajmitch | micahg: don't know why you're coughing there :) | 19:37 |
micahg | any staticly compiled language :) | 19:39 |
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:40 |
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:41 |
jtaylor | I think all must start with lib, its the prefix gcc uses with -l | 19:42 |
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:43 |
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:52 |
=== mfisch` is now known as mfisch | ||
epikvision | ./configure doesn't work... the program obviously doesn't have it. | 19:53 |
=== mfisch is now known as Guest84007 | ||
tumbleweed | presumably it has instructions | 19:53 |
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:54 |
epikvision | jbicha: how can I help out with the current eclipse packaging? | 19:55 |
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:56 |
epikvision | ok | 19:57 |
jbicha | epikvision: http://developer.ubuntu.com/packaging/html/ | 19:57 |
epikvision | perhaps the debian maintainer guide is also useful? | 19:59 |
AmberJ | yes, (as a beginner to Debian/Ubuntu packaging), I found out maint-guide very useful. | 20:01 |
thinkndev | The packaging guide suggests to package in the development environment. | 20:10 |
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:11 |
thinkndev | ok | 20:12 |
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:19 |
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:20 |
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 | 20:21 |
jtaylor | my quantal chroots are acting up | 21:52 |
jtaylor | can'T find debhelper when doing --build | 21:53 |
jtaylor | components are correct --login works ... | 21:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!