/srv/irclogs.ubuntu.com/2012/01/22/#ubuntu-devel.txt

jonoanyone here familiar with writing PyGI apps?00:11
=== Alcine is now known as jalcine
=== jalcine is now known as JackyAlcine
=== Laibsch1 is now known as Laibsch
=== arand_ is now known as arand
=== tkamppeter_ is now known as tkamppeter
=== yofel_ is now known as yofel
alabdGood day all , wana chanage perm of a file on ntfs usb external hard disk , but without error chmod 777 does not take affect13:17
commandolinealabd: you might be helped better in the help channel: #ubuntu13:18
commandolinethis channel is about development of Ubuntu13:18
alabdok thanks  bye13:20
valterstrhello13:36
valterstrI would be interested in developing ubuntu13:36
valterstrand this will sound silly, but, what programming language is used?13:37
bkerensavalterstr: A variety13:39
valterstrI am looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise13:39
valterstrlp:ubuntu/bzr13:40
valterstrvala seems to be used13:40
valterstrbut the directory tree is unusual for mee.13:41
penguin42valterstr: I'm not sure if there are many things that use vala; but it's quite neat; but there is a lot of C, Python, C++, perl - everything really13:41
valterstris there an ide?13:42
valterstrwait. valac-*.**13:42
valterstr?13:42
penguin42a few - I don't use them myself; I think anjuta is used by various people, not sure what it's like or which languages it supports13:42
* valterstr googes...13:42
valterstr*googles.13:42
valterstrlooks good. will install.13:43
valterstrmany dependencies...13:43
valterstrI have the source files and I have Anjuta13:49
valterstrNow when I try to import the project, it asks if I want to use makefile backend or directory backend.13:50
valterstrwhich should I choose?13:50
valterstrtesting makefile then...13:51
valterstrlooks ok. but could someone explain which files is the code itself in?13:52
valterstras I have understood, /bzrlib contains the software code in lp:ubuntu/bzr13:59
valterstrbut in lp:ubuntu/cowbell it is /base14:00
valterstr@penguin42: so, there is no "default" directory tree?14:00
udevbot_Error: "penguin42:" is not a valid command.14:00
valterstrpenguin42: so, there is no "default" directory tree?14:00
penguin42I don't know what you mean14:01
valterstrI mean, e.g. all software files are held in /base folder.14:01
valterstrit is different for different packages14:01
valterstrubunte/cowbell package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/cowbell/precise/files14:02
valterstr /base folder is used there14:03
valterstrubuntu/bzr package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise/files14:03
valterstr /bzrlib is used.14:03
valterstrpenguin42: that's what I mean.14:04
commandolinevalterstr: Ubuntu consists about a number of different programs, different packages. They use all kinds of different programming languages and different directory tree structures, it depends on the preference of the developers of the packages.14:04
penguin42valterstr: Some of those directories are just what the author decided they wanted - that's the source tree, and the author can make up those names as they want14:04
valterstrok14:05
penguin42valterstr: There are some that are fixed in debian/ubuntu packages (e.g. the debian directory) and some that are common (e.g. po and lib)14:05
valterstrnoticed.14:05
valterstrthanks for the info.14:05
=== Alcine is now known as JackyAlcine
=== kalosaurusrex is now known as albrigha
glDHi all, I have a problem with new package "esys-particle". It builds fine, but on Ubuntu during start the following error appears20:06
glD"ImportError: /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0: undefined symbol: _ZTIN5boost6python15instance_holderE"20:06
glDIt seems, it is an ubuntu-related problem, because the same package works fine on Debian20:06
glDI would appreciate, if somebody gives an advice how to fix that20:07
glDthere is a corresponding bug on that: https://bugs.launchpad.net/esys-particle/+bug/91672420:07
ubottuUbuntu bug 916724 in ESyS-Particle "ESyS-Particle has linking problems on ubuntu-11.10 variants" [High,New]20:07
glDthanks ahead20:08
jtaylormost likely an as-needed problem20:20
jtaylor /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0 is probably not linked correctly20:20
jtaylorglD: ^20:21
jtaylordo you have a buildlog of it?20:21
glDjtaylor: yes, just a moment20:22
glDDebian: https://buildd.debian.org/status/fetch.php?pkg=esys-particle&arch=amd64&ver=2.1-1&stamp=132459415520:23
glDUbuntu: https://launchpadlibrarian.net/89385870/buildlog_ubuntu-precise-amd64.esys-particle_2.1-1_BUILDING.txt.gz20:23
jtaylorglD: there is a bunch of stuff underlinked, see the dpkg-shlibdeps warnings20:31
jtayloralso in debian20:31
jtaylorthat should be fixed20:31
glDjtaylor: ok, thanks20:35
glDI will try20:35
jtaylorpython is often one of the first to notice that as undefined symbols in pythion extensions are pretty normal (e.g. libpython stuff)20:35
jtaylorthus problems only detected at runtime20:36
glDjtaylor: it means, that the code should be patched somewhere?20:36
jtaylorno its a makefile issue20:37
glDOk, thanks20:37
jtaylorthat package has a bunch of far to general library names20:54
jtaylorlibFields, libParallel20:54
jtaylorlibModel20:54
jtaylorhow did that get through in debian :O20:55
glDjtaylor: it should be something like libEsysModel, libEsysFields..?20:56
jtaylorprobably yes20:56
jtayloror they should be private libraries20:56
jtaylor= installed in a subfolder of usr/lib20:56
glDjtaylor: there are also errors on both buildlogs21:22
glDImportError: libFoundationPy.so.0: cannot open shared21:22
glD|            object file: No such file or directory (line 15)21:22
jtaylorglD: thats a problem of the PYTHONPATH21:29
jtayloror library path not sure21:30
jtaylorshould not be a problem when the package is installed21:30
jtaylorsetting this should work LD_LIBRARY_PATH=debian/tmp/usr/lib/python2.7/dist-packages/esys/lsm/util/21:30
glDah, ok21:31
jtaylorhaving that in PYTHONPATH  should do the same21:31
glDjtaylor: what do you think, why the problem appears in Ubuntu, not in Debian?21:32
glDI mean the first problem, with symbols21:32
jtaylorubuntu enables as-needed during build by default debian does not21:33
jtaylorthis has some effect on indirect links which are used here21:33
glDcan the "quick" workaround be to switch off it? --no-as-needed to make the package working?21:34
glDand then to fix all of other issue21:34
jtaylorthe fix is to link everything properly21:34
jtaylorunderlinking library causes all kinds of issues21:35
jtaylorIn my opionion those dpkg-shlibdep warnisn should be errors, that would save a huge amount of trouble21:35
jtaylornobody reads warnigns ...21:35
glDjtaylor: ok, thank you!21:42
glDwill try to fix that21:42
jtaylorglD: one issue is in debian/rules, LDFLAGS := -lboost_system22:07
jtaylorlibraries do not go in LDFLAGS, those will be placed wrongly by autotools22:07
jtaylorLIBS is normally the correct varaible22:08
mdeslaurhallyn: yes, iso downloads use releases.ubuntu.com22:08
tsdgeostkamppeter: you around by chance?22:24
tkamppetertsdgeos, hi22:28
tsdgeostkamppeter: seen my mail about the huge speed regression?22:29
tsdgeostkamppeter: re poppler and lcms22:30
tkamppeterYes, so you found one PDF where Poppler with lcms2 takes 10 times longer than Poppler with lcms1?22:33
tsdgeosi had found that pdf already in 2010 yes22:34
tsdgeosbut nobody seems to read the mails i sent back then :D22:34
tkamppetertsdgeos, can you attach the file to the thread or at least send it to me?22:34
tsdgeosgoogle for it, it's everywhere22:34
tsdgeoshttp://www.eci.org/doku.php?id=es:downloads22:34
tsdgeosaltona_technical_1v2_x3.pdf22:35
tkamppetertsdgeos, that time you did a migration, nmow Koji Otani did one independently. Did you already try to run the file through Koji Otani's version of the migration?22:35
tsdgeoserr22:35
tsdgeosis my english that bad?22:35
tsdgeosyes, i used koji's version22:35
tkamppetertsdgeos, is this the only file which gets that much slower, you told abot 5-10% performance loss is usual.22:36
tsdgeosthat was koji22:37
tsdgeosand me too probably22:37
tsdgeosoriginally i found it to be even faster on some files22:37
tsdgeosbut going from 0.5 to 5 sec22:37
tsdgeosis a bit of a no go22:37
tsdgeosi did not try any other files22:38
tkamppeterIf it is only that one file, you should perhaps report a bug to the lcms developers with the file attached and also tell Koji as he did the migration (and so he could have done something wrong, too).22:39
tsdgeoshave you even looked at the patch?22:39
tsdgeosthe migration is basically renaming of stuff22:39
tsdgeosyou can't do that wrong22:39
tkamppetertsdgeos, OK, then it looks more like a bug in lcms2 which gets triggered by said file.22:40
tsdgeosi'd agree22:41
tsdgeosi prefer to use software i know it works instead of buggy one22:41
tsdgeosand i'd suggest ubuntu to the same ;-)22:42
glDjtaylor: ok, thanks, will fix that22:42
jtaylorglD: also it appears the libraries don't link with libTml*22:42
jtaylorthat has been patched for the executables, but not for the libraries22:43
tkamppetertsdgeos, to do a real test one should use a large amount of PDF files (you should have some test repository of PDFs for Poppler's QA) and run them all through the current Poppler, once with and once without Koji's patch, afterwards counting how the results compare in speed and also how many crash without and how many with the patch.22:43
tsdgeostkamppeter: i can't make my pdf suite public, i don't have rights to distribute them22:44
tsdgeostkamppeter: how many crash without the patch? none22:45
tkamppetertsdgeos, but you can publish the statistics.22:46
tsdgeossure22:46
tsdgeosi don't feel like doing the work since i've already found a showstopper22:46
tsdgeosi mean, found it two years ago :D22:47
tsdgeosanyhow, sleep time, let's see if either koji or the lcms dude you put in the CC have anything to say in the matter22:53
tsdgeosnight@all22:54
slangasekhallyn: bug #893450> cjwatson is certainly the expert where sector sizes are concerned... not sure how high that'll be on his list though :/  The bug description sounds like a race condition, not a perf problem?23:33
ubottuLaunchpad bug 893450 in libvirt (Ubuntu) "libvirt fails to start correctly because LVM is not ready" [High,Incomplete] https://launchpad.net/bugs/89345023:33

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!