[00:11] anyone here familiar with writing PyGI apps? === 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 [13:17] Good day all , wana chanage perm of a file on ntfs usb external hard disk , but without error chmod 777 does not take affect [13:18] alabd: you might be helped better in the help channel: #ubuntu [13:18] this channel is about development of Ubuntu [13:20] ok thanks bye [13:36] hello [13:36] I would be interested in developing ubuntu [13:37] and this will sound silly, but, what programming language is used? [13:39] valterstr: A variety [13:39] I am looking at https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise [13:40] lp:ubuntu/bzr [13:40] vala seems to be used [13:41] but the directory tree is unusual for mee. [13:41] valterstr: 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 really [13:42] is there an ide? [13:42] wait. valac-*.** [13:42] ? [13:42] a 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 supports [13:42] * valterstr googes... [13:42] *googles. [13:43] looks good. will install. [13:43] many dependencies... [13:49] I have the source files and I have Anjuta [13:50] Now when I try to import the project, it asks if I want to use makefile backend or directory backend. [13:50] which should I choose? [13:51] testing makefile then... [13:52] looks ok. but could someone explain which files is the code itself in? [13:59] as I have understood, /bzrlib contains the software code in lp:ubuntu/bzr [14:00] but in lp:ubuntu/cowbell it is /base [14:00] @penguin42: so, there is no "default" directory tree? [14:00] Error: "penguin42:" is not a valid command. [14:00] penguin42: so, there is no "default" directory tree? [14:01] I don't know what you mean [14:01] I mean, e.g. all software files are held in /base folder. [14:01] it is different for different packages [14:02] ubunte/cowbell package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/cowbell/precise/files [14:03] /base folder is used there [14:03] ubuntu/bzr package files: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/bzr/precise/files [14:03] /bzrlib is used. [14:04] penguin42: that's what I mean. [14:04] valterstr: 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] valterstr: 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 want [14:05] ok [14:05] valterstr: 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] noticed. [14:05] thanks for the info. === Alcine is now known as JackyAlcine === kalosaurusrex is now known as albrigha [20:06] Hi all, I have a problem with new package "esys-particle". It builds fine, but on Ubuntu during start the following error appears [20:06] "ImportError: /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0: undefined symbol: _ZTIN5boost6python15instance_holderE" [20:06] It seems, it is an ubuntu-related problem, because the same package works fine on Debian [20:07] I would appreciate, if somebody gives an advice how to fix that [20:07] there is a corresponding bug on that: https://bugs.launchpad.net/esys-particle/+bug/916724 [20:07] Ubuntu bug 916724 in ESyS-Particle "ESyS-Particle has linking problems on ubuntu-11.10 variants" [High,New] [20:08] thanks ahead [20:20] most likely an as-needed problem [20:20] /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0 is probably not linked correctly [20:21] glD: ^ [20:21] do you have a buildlog of it? [20:22] jtaylor: yes, just a moment [20:23] Debian: https://buildd.debian.org/status/fetch.php?pkg=esys-particle&arch=amd64&ver=2.1-1&stamp=1324594155 [20:23] Ubuntu: https://launchpadlibrarian.net/89385870/buildlog_ubuntu-precise-amd64.esys-particle_2.1-1_BUILDING.txt.gz [20:31] glD: there is a bunch of stuff underlinked, see the dpkg-shlibdeps warnings [20:31] also in debian [20:31] that should be fixed [20:35] jtaylor: ok, thanks [20:35] I will try [20:35] python is often one of the first to notice that as undefined symbols in pythion extensions are pretty normal (e.g. libpython stuff) [20:36] thus problems only detected at runtime [20:36] jtaylor: it means, that the code should be patched somewhere? [20:37] no its a makefile issue [20:37] Ok, thanks [20:54] that package has a bunch of far to general library names [20:54] libFields, libParallel [20:54] libModel [20:55] how did that get through in debian :O [20:56] jtaylor: it should be something like libEsysModel, libEsysFields..? [20:56] probably yes [20:56] or they should be private libraries [20:56] = installed in a subfolder of usr/lib [21:22] jtaylor: there are also errors on both buildlogs [21:22] ImportError: libFoundationPy.so.0: cannot open shared [21:22] | object file: No such file or directory (line 15) [21:29] glD: thats a problem of the PYTHONPATH [21:30] or library path not sure [21:30] should not be a problem when the package is installed [21:30] setting this should work LD_LIBRARY_PATH=debian/tmp/usr/lib/python2.7/dist-packages/esys/lsm/util/ [21:31] ah, ok [21:31] having that in PYTHONPATH should do the same [21:32] jtaylor: what do you think, why the problem appears in Ubuntu, not in Debian? [21:32] I mean the first problem, with symbols [21:33] ubuntu enables as-needed during build by default debian does not [21:33] this has some effect on indirect links which are used here [21:34] can the "quick" workaround be to switch off it? --no-as-needed to make the package working? [21:34] and then to fix all of other issue [21:34] the fix is to link everything properly [21:35] underlinking library causes all kinds of issues [21:35] In my opionion those dpkg-shlibdep warnisn should be errors, that would save a huge amount of trouble [21:35] nobody reads warnigns ... [21:42] jtaylor: ok, thank you! [21:42] will try to fix that [22:07] glD: one issue is in debian/rules, LDFLAGS := -lboost_system [22:07] libraries do not go in LDFLAGS, those will be placed wrongly by autotools [22:08] LIBS is normally the correct varaible [22:08] hallyn: yes, iso downloads use releases.ubuntu.com [22:24] tkamppeter: you around by chance? [22:28] tsdgeos, hi [22:29] tkamppeter: seen my mail about the huge speed regression? [22:30] tkamppeter: re poppler and lcms [22:33] Yes, so you found one PDF where Poppler with lcms2 takes 10 times longer than Poppler with lcms1? [22:34] i had found that pdf already in 2010 yes [22:34] but nobody seems to read the mails i sent back then :D [22:34] tsdgeos, can you attach the file to the thread or at least send it to me? [22:34] google for it, it's everywhere [22:34] http://www.eci.org/doku.php?id=es:downloads [22:35] altona_technical_1v2_x3.pdf [22:35] tsdgeos, 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] err [22:35] is my english that bad? [22:35] yes, i used koji's version [22:36] tsdgeos, is this the only file which gets that much slower, you told abot 5-10% performance loss is usual. [22:37] that was koji [22:37] and me too probably [22:37] originally i found it to be even faster on some files [22:37] but going from 0.5 to 5 sec [22:37] is a bit of a no go [22:38] i did not try any other files [22:39] If 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] have you even looked at the patch? [22:39] the migration is basically renaming of stuff [22:39] you can't do that wrong [22:40] tsdgeos, OK, then it looks more like a bug in lcms2 which gets triggered by said file. [22:41] i'd agree [22:41] i prefer to use software i know it works instead of buggy one [22:42] and i'd suggest ubuntu to the same ;-) [22:42] jtaylor: ok, thanks, will fix that [22:42] glD: also it appears the libraries don't link with libTml* [22:43] that has been patched for the executables, but not for the libraries [22:43] tsdgeos, 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:44] tkamppeter: i can't make my pdf suite public, i don't have rights to distribute them [22:45] tkamppeter: how many crash without the patch? none [22:46] tsdgeos, but you can publish the statistics. [22:46] sure [22:46] i don't feel like doing the work since i've already found a showstopper [22:47] i mean, found it two years ago :D [22:53] anyhow, sleep time, let's see if either koji or the lcms dude you put in the CC have anything to say in the matter [22:54] night@all [23:33] hallyn: 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] Launchpad bug 893450 in libvirt (Ubuntu) "libvirt fails to start correctly because LVM is not ready" [High,Incomplete] https://launchpad.net/bugs/893450